Notable Quotes — Batey, "Building Product Teams in the Age of AI"

Quotes preserve speech-to-text artifacts verbatim. Line references are by section in transcript.md.

On AI as amplifier (§ 6)

"AI is an amplifier. So for the things that we did really well as a company, it allows us to do it much quicker. ... So the things that we did really badly ... then all it's done is amplified the things that we didn't do so well."

"It's really enabled like delivery focused engineers. ... And my company certainly wouldn't be in the position it is right now if AI didn't exist because you know we couldn't have afforded probably to hire a 10 person like product team to two years ago."

On vanity metrics (§ 5, § 16)

"out of all that code and if I look at my main branch of any of our products, it's all written by AI now. But how much of it was written without any human intervention? With software engineers like using critical thinking. And I think the answer is probably like zero."

"Do not get sucked in by vanity metrics that measure one little bit in the middle like token usage or commit or PRs merge. It has to be adoption."

On the real fear (§ 4, § 6)

"we're rapidly approaching a world where software, no human has ever seen reaches production. And I don't think this is hypothetical anymore"

"the thing which like worries me more and more important is what percentage of your code ... what percentage of your system goes to production without human understanding."

On systems thinking (§ 7)

"let's not delegate systems thinking to agents."

"maybe a pull request is going to land which is maybe 7,000 changes. And then what would I be reviewing it for? Well I first want to review it for the systems thinking."

On ADR-first workflow (§ 8)

"from now on we're going to start with the ADR. I'm me as a human, I'm going to spend a lot of time reviewing it. I want diagrams. I want them to visual so I can understand them."

"agents loved writing ADR they're very good at seeing that we had ADR so they wrote more ADRs and our ADR is much longer more verbose and not a single human understood them which completely defeated the point of having them."

"Agents are really really good at reviewing implementations against a well structured architectural decision report."

On the producer black box (§ 9)

"really your back box is made of three things that you don't understand."

"Vendor lock in is fine as part of your development process. ... but make it a conscious choice in your organization and understand the consequences of that producer going down at key points for your business."

On adoption ownership (§ 11)

"engineers aren't allowed to go build the next feature until they've done everything they possibly could to get that feature adopted."

"for now it's like you build it, you run it and you have to drive the adoption of that feature. Otherwise you just send them too many features, unused features in production."

On parallelism limits (§ 13)

"if let's say people had three complex tasks. ... The first one would be fantastic. The second one would be that's a bit. By the time you got to the third one would be a load of rubbish."

"work in parallel. Absolutely, but only work on one complex. Task at a time."

On review being the bottleneck (§ 14)

"the most common complaint in AI software ... Reviews of the bottleneck. This is crazy. ... we're complaining that we can build so much valuable software that we don't have the time to look at it."

"rather than having our normal team sizes in six to eight people we've made them much more smaller. So they're now two almost four and we give them a mission and the remission is based on adopted software by a particular customers."

On engineering practices under AI velocity (§ 15)

"It's 15 minutes for me is absolute maximum for running a full suite of tests which gives me a high level of confidence that thing works."

"if we're going to modify software more quickly blast radius really matters. What is the worst thing that can go wrong ... and the only really way to do that is to design those systems and so that if one of these components goes down most of your product functionality still works."