Podcast
The Productivity Paradox- Why More AI Code Is Slowing Down Shiptimes
The Reasoning Show
- Engineering Degree Didn’t Teach Business Value
- Jeff recounts building an AR client-server accounting system at 24 and being assigned an AP module before knowing what AP meant.
- That moment exposed the gap between technical training and business understanding.
- He realized an engineering degree and software skills alone wouldn’t get him where he wanted to go.
- Jeff wishes more engineers spoke the language of business because Agile’s goal is to produce value faster.
- He contrasts business value with nerdy engineering terms like story points and releases. Transcript: Jeff Keyes I’m like, okay, we were divvying out the work at Jeff. You’re going to own the AP module. And I was like, awesome. What’s AP? And then, you know, it’s like, ah, you can see all the eye rolls and things like, well, what do you want to do that for? You know, what’s this thing about GL and T accounts? And I, and ever since then, I realized that having an engineering degree, being a software developer, wasn’t going to get me to where I really wanted to go. I wish more people spoke in the language of the business. The point of Agile even is to produce more value faster. (Time 0:04:12)
- Engineering Leaders Are Gasping To Keep Up With AI
- Brian asks what Jeff is seeing as AI overtakes engineering organizations, prompting a high-level lay of the land.
- Jeff says leaders are “gasping for air” trying to keep up while still handling day-to-day delivery.
- Teams face staff reductions and role consolidation (loss of agile coaches, product owners, TPMs) as companies push everyone toward hands-on delivery.
- Organizations must both maintain the delivery “factory” and adapt processes, team roles, and expectations for moving faster.
- This creates pressure and shifting bottlenecks: tools and investment alone won’t solve the mismatch between expectations and operational reality. Transcript: Brian Gracely What are you seeing as this new AI capability is, like you said, sort of overtaking a lot of engineering organizations? It’s changing really, really fast. So you’re never quite sure what the next three months are going to look like. What are you, you know, what’s surprising you the most? Where are you seeing gaps? Where are you you seeing successes? Kind of give me the lay of the land, you know, at a high level for what, you know, for the people you’re engaging with these days. Jeff Keyes That’s a great question. You know, the first answer is like people are trying to, you know, gasping for air, trying to keep up. There’s already a day job and you got to get all that stuff done. At the same time, engineering leaders that I talked to are facing staff reductions because it’s so popular right now. Get rid of all the, anybody that has been an agile coach or a product owner or scrum role, it’s like, I am sorry, technical program managers, engineering operations. There’s been such pressure to turn everyone into hands-on delivery. And yet we still need to make sure that the factory is moving and get (Time 0:06:01)
- AI Shifts The Bottleneck Away From Coding
- AI amplifies individual developer productivity but doesn’t automatically increase delivery into customers’ hands.
- Jeff Keyes observed the bottleneck shifting to planning, decision-making, and verification as coding compresses with AI. Transcript: Jeff Keyes That’s a great question. You know, the first answer is like people are trying to, you know, gasping for air, trying to keep up. There’s already a day job and you got to get all that stuff done. At the same time, engineering leaders that I talked to are facing staff reductions because it’s so popular right now. Get rid of all the, anybody that has been an agile coach or a product owner or scrum role, it’s like, I am sorry, technical program managers, engineering operations. There’s been such pressure to turn everyone into hands-on delivery. And yet we still need to make sure that the factory is moving and get all that done at the same time as the process is changing dramatically, not just the process, but the teams and the roles, How things work at the same time as the expectation of why aren’t you moving faster? Hey, we just spent real money on all these tools. Maybe it’s up to, is it 10% of a salary in each person? What’s it look like? So what I’m seeing as I talk to people is overload. And in fact, as the coding phase, which wasn’t ever really the, you know, the truest long pole in the project plan. But now as that compresses, it’s, you know, leadership is facing this information overload. There’s more decisions and bigger decisions that are happening faster. (Time 0:06:26)
- Plan Role Changes Carefully To Prevent Overload
- Anticipate rising information overload and role changes; plan for changed responsibilities before cutting roles.
- Jeff notes layoffs and role fungibility risk when teams expect everyone to become hands-on delivery without preserving necessary functions. Transcript: Jeff Keyes That’s a great question. You know, the first answer is like people are trying to, you know, gasping for air, trying to keep up. There’s already a day job and you got to get all that stuff done. At the same time, engineering leaders that I talked to are facing staff reductions because it’s so popular right now. Get rid of all the, anybody that has been an agile coach or a product owner or scrum role, it’s like, I am sorry, technical program managers, engineering operations. There’s been such pressure to turn everyone into hands-on delivery. And yet we still need to make sure that the factory is moving and get all that done at the same time as the process is changing dramatically, not just the process, but the teams and the roles, How things work at the same time as the expectation of why aren’t you moving faster? Hey, we just spent real money on all these tools. Maybe it’s up to, is it 10% of a salary in each person? What’s it look like? So what I’m seeing as I talk to people is overload. And in fact, as the coding phase, which wasn’t ever really the, you know, the truest long pole in the project plan. But now as that compresses, it’s, you know, leadership is facing this information overload. (Time 0:06:26)
- Agentic Development Raises PR Review Costs
- Agentic development will accelerate code generation but risks introducing low-quality “slop” into codebases.
- Jeff warns this will increase PR size and review burden, turning developers into reviewers rather than writers. Transcript: Jeff Keyes And then once it’s at a stage where we’ve thought through a little bit of the completeness, it’s changed again. You know, the big shift of 2026, I think is going to be not the shift of using AI, but it’s going to be the shift to agentic development, meaning it truly is this world where I stop, I as a developer And I as a dev manager have my team stop writing code, just have the agent do it. But it means you got to be really smart because if you’ve seen AI slop for different things, get ready. That’s what’s coming to your code base unless you know what you’re doing and how to iterate through the prompts and do it in a way where you’re not going to end up with slop. It also is going to put more pressure on the PR process. And I think one report I read is that, and I hear this all the time, people are complaining about, what do I do with a 5,000 line PR? It’ll take me so much time to review it that I just can’t even keep up. So dev teams are becoming reviewers versus writers. They’re just like, oh, I don’t know how I manage this. (Time 0:12:07)
- Healthcare Team Used POCs To Reverse Engineer Requirements
- A healthcare customer used platform teams to build proofs of concept first, then derived requirements from working software.
- They successfully replatformed legacy products by reverse-engineering specs from the running product and iterating with agents. Transcript: Jeff Keyes They’re in the health care space, highly regulated. And so they effectively took a platform team and enabled them to move forward with the idea that their handshake is the proof of concept, not a requirements doc. They would then use that to generate the requirements and the dev-oriented specs would then get handed off to groups of agents to go build and iterate on the feedback as they go with the Intent that they would increase the cycles between ideation and customer feedback. They found it works so well for them that they’re trying to now use that for the entirety of the organization, including, which is another interesting case, they need to replatform One of their products. Product was built on a platform that they don’t really want to support. They want to move it from NetWorld to Java platform. Great. How are they going to do it? Reverse engineer the requirements and the specs from the product and the code and then move it forward using the same model, getting things in a way that where, you know, the requirements And the specs become more of what they’re actually building than the code itself. It’s a fascinating model because it changes everything. (Time 0:15:15)
- Run End To End Experiments Focused On Customer Value
- Experiment end-to-end across idea to production and measure customer value, not just isolated stages.
- Jeff advises teams to blur traditional handoff contracts and align on success metrics that track value reaching customers. Transcript: Jeff Keyes It’s interesting. The reframing conversation still has, with most people I talk to, the reframing conversation still has the same contract boundaries in place. If you talk to product people, their contract is a series of tickets and, you know, PRD. If you talk to dev, their contract is they consume that and they consume a user experience and produce said code. And, and it’s, it’s funny because it’s this reframing of, well, what are you actually responsible for? If you back to the point of, if you fix one point, that was a bottleneck you now need and didn’t fix anything else. It could be that you’re at a bottleneck to just slow you down, which is kind of what we see. I think code review time has jumped to, it’s almost to 25% to a third of the time of most dev teams now as they’re the more AI adoption, get ready, code review, PR, reviews now consumes just As much time. Made worse by the fact that some teams had a bad habit of just rubber stamping these in the first place. You know, imagine your face melt as you see a really significant PR come through that’s going to take you half a day. They just rubber stamp it. And so management came in and said, well, we’re just going to get rubber stamping. Let’s have two people review it. Great. Now we’ve slowed down even further focusing on this next bottleneck. Then comes AI to go fix that problem. On the requirement side, the next bottleneck is this massive void for filling in requirements for what development actually builds. And dev teams are saying, well, you know what? I got this cool Claude tool here. I can jump into Claude code and spec kit and a few other things and I can go write me up some good requirements. It’s good enough, right? They look great. Is it the right thing? In fact, you know, this is where it just gets funny. The roles blur and they should a little bit. In fact, they should a lot while we try to figure this out. The point for engineering leaders and product leaders is you need to do some experimentation here without being constrained to the traditional contracts that you had before of the Handoff points. The handoff points have always been the problem. How can you speak in a common language of what does success look like and what are the things that are coming out? (Time 0:18:19)
- Avoid Chasing Misleading Productivity Metrics
- Don’t optimize for easy proxy metrics like lines of code or deployment frequency. Measure outcomes and value instead.
- Jeff calls out rising code review time and warns against gaming metrics that don’t reflect business impact. Transcript: Jeff Keyes I think code review time has jumped to, it’s almost to 25% to a third of the time of most dev teams now as they’re the more AI adoption, get ready, code review, PR, reviews now consumes just As much time. Made worse by the fact that some teams had a bad habit of just rubber stamping these in the first place. You know, imagine your face melt as you see a really significant PR come through that’s going to take you half a day. They just rubber stamp it. And so management came in and said, well, we’re just going to get rubber stamping. Let’s have two people review it. Great. Now we’ve slowed down even further focusing on this next bottleneck. Then comes AI to go fix that problem. On the requirement side, the next bottleneck is this massive void for filling in requirements for what development actually builds. And dev teams are saying, well, you know what? I got this cool Claude tool here. I can jump into Claude code and spec kit and a few other things and I can go write me up some good requirements. It’s good enough, right? They look great. Is it the right thing? In fact, you know, this is where it just gets funny. The roles blur and they should a little bit. (Time 0:19:02)
- Smaller Autonomous Teams Become The Norm
- Future teams will be much smaller and more autonomous, combining builders, engineers, designers, and quality into one team.
- Jeff predicts single-pizza or smaller teams owning direction and delivery, enabled heavily by tooling and AI. Transcript: Jeff Keyes Well, first of all, I think themes are smaller, dramatically smaller, in fact, owning their own direction because if they’re not autonomous, they’re, you know, figured out, figure Out what your platform teams, your common stuff, figure out what your actual product are that go to market. The idea of a two pizza team is dead in my mind. We’re going to go to, you know, is it single pizza team? Is it less than that? Is it half a pizza? It’ll include a builder, someone who owns what it is, the innovation side. It’ll include a code who’s got to own the actual technology and throughput. It’ll own some aspect of the design and quality and all the rest of that stuff gets built in that has to be highly autonomous, highly enabled with the tooling so that their contracts work Together well. I think AI is going to impact every single aspect of this from the ideation and summarizing how quickly can we get ideas that we’re hearing as mixed with usage data that translate into Features that have to get built so that the actual coding part, you know, is it kind of compresses and goes to zero. All we’re doing is deciding like what’s the best bet to make and deliver it out. I think over this next year, that’s become so autonomous that we just are filling in the gaps running, you know, managing around it. I think developers are going to spend more time managing and communicating and reviewing and judgment and architecture than anything else. And this becomes a new job. (Time 0:27:43)
- Correlate Engineering Spend With Business Signals
- Use AI to correlate investment, usage, and business signals to measure near-real-time value.
- Jeff recommends tying spend and engineering activity to sales calls, usage, and pipeline to close the value loop faster. Transcript: Jeff Keyes I think AI is going to impact every single aspect of this from the ideation and summarizing how quickly can we get ideas that we’re hearing as mixed with usage data that translate into Features that have to get built so that the actual coding part, you know, is it kind of compresses and goes to zero. All we’re doing is deciding like what’s the best bet to make and deliver it out. I think over this next year, that’s become so autonomous that we just are filling in the gaps running, you know, managing around it. I think developers are going to spend more time managing and communicating and reviewing and judgment and architecture than anything else. And this becomes a new job. And telling the agents where they screwed up on the building, I think product people are going to, I mean, right now is like the time for product people, man. The number of sources that you have to take in and consume of different data sets, all of a sudden everything came to your fingertips. And it’s awesome. I think people that are over this as an executive layer, now we’re going to have even more visibility than they ever had before, because now you can use the tooling with AI to pull together Analytics that you never thought possible. You could correlate how much spend did you have in a particular area and look at it in terms of the number of agents and AI coding with the quality that you did to look at consumption versus How many times was that feature used on a sales call and how much is it driving future pipeline and do some real business cost analysis that’s way more real time. Funny side note, right? We always talk about value. The ideal wonder that no one’s ever achieved is like, we invested X dollars and we got this dollars out. No one’s ever been able to do that because the dollars out is always a lagging number that’s so far in the future that you can’t ever get there. Well, as you start to correlate the investment that you have and how it’s being treated in sentiment in phone calls, in sales calls, like it’s game changing. Listening to current customer adoption, those feedback loops are dramatically compressing. (Time 0:28:38)
- Every Knowledge Worker Will Produce Some Code
- Non-engineering knowledge workers will increasingly generate small automation or code for their jobs.
- Jeff ran an agent to analyze his calendar and adjust meeting load, illustrating personal automation use cases. Transcript: Jeff Keyes I mean, I hate to say it, like it was just this week that I ran an agent to analyze my calendar for what kind of meetings versus thinking time I had over the last month and how do I revise it So I have more thinking time with this, you know, what meetings do I get rid of? Yeah. That’s awesome. I wrote my own, you know, no code, but just ran that. (Time 0:32:02)