In Part 1 of this series, I wrote about what AI is reshaping at the structural level: roles, service models, and agile. This piece is about what all of that looks like once it hits daily work.
AI Is a Super-Power, But It Needs Help to Work
AI isn't a super-power on its own. It becomes one only when the entire ecosystem around it creates the right conditions. That sounds obvious, but in practice it isn't. What I've seen over the past year is AI tool adoption without updating existing processes. The result? Even when teams could write more code in far less time, that didn't necessarily translate into more value delivered.
Why? Loss of focus on the actual problem being solved. Introducing tools just to introduce them doesn't do much — the same thing happened years ago with every tech stack or agile framework adopted just because everyone else was doing it. AI needs your entire set of processes adapted to get the most out of it, and it needs organizational alignment behind that. Without it, implementing AI ends up making existing problems worse - and creating new ones on top.
There's a practical layer to this that's easy to miss in the hype: a lot of the conversation around AI-driven engineering assumes an automation maturity most companies don't have - plenty are still without continuous delivery, to name just one example. Layering AI-assisted coding on top of a pipeline that still needs manual deployment steps doesn't remove the bottleneck — it just moves it earlier.
The New Bottlenecks: From Coding to Reviewing, From Building to Deciding
Writing code is no longer the time-consuming part. With generative AI coding tools, what used to take hours, days, entire sprints, or even months can now be done far faster. So why aren't we shipping to production at the same velocity? Beyond the need to update processes across the SDLC, what's actually happening is that the bottlenecks have moved.
We can produce a lot more code, yes — but we don't have the capacity to review all of it as quickly. We can automate code review, yes — but manual intervention is still needed: AI can make mistakes, we as engineers remain responsible for what reaches production, and human judgment still decides whether a change makes sense right now. We can automate testing, yes — but most companies still have a layer of manual testing, which is now its own bottleneck. We can have new features ready to ship, yes — but do we have the infrastructure to actually deploy all of them that fast?
There's a quieter version of this bottleneck too. Some PRs are so large they're basically unreviewable — and sometimes that's not by accident. A giant PR is also a convenient place to bury a change that wouldn't survive review on its own. It gets worse across teams: when the review crosses team lines, unadapted processes plus different expectations turn it into friction instead of a safety net.
And it's not only technical. Now that engineering can move faster, it needs faster decisions to match. Product is becoming part of the new bottleneck too, since requirements need to be far more defined, far earlier, given how much more can get built in the same amount of time. Product and engineering staying tightly aligned isn't a nice-to-have anymore — it's what determines whether the extra speed turns into anything useful at all.
AI Saves Time, But Developers Still Feel Burnout. Why?
Now that developers are supposed to have more time to do the things they couldn't do before, there's a clear sense that they're burnt out and frustrated instead. Several things contribute to this, but a few patterns keep repeating.
Beyond the uncertainty this era brings to their future — adapting to a new way of working while redefining their own role — developers are being pushed to be more productive than ever now that the "super-power" is enabled. In some cases, team sizes were reduced, so the same people are doing even more work than before. Pressure has always been part of this industry, but it increased sharply once AI tooling entered daily workflows. And metrics — which were always there — now seem to be adding to the frustration rather than easing it. There's real research on this: Laura Tacho has written specifically about how applying the wrong metrics to individual performance erodes trust between developers and their leadership.
On the other hand, some of the frustration comes from processes that were never really refined in the first place — the bottlenecks I just described don't help. Code review is where it shows up fastest, since it was already a touchy subject long before AI got involved. Add an automated reviewer that gets the tone or the context wrong, and it doesn't take long for frustration to turn into indifference toward the whole review process. And metrics aren't just failing to capture that frustration — in some cases, they're actively feeding it.
Measuring What AI Made Invisible
Metrics have been around for decades, met with more than a little resistance from software engineers — but they're finally having their moment as more teams are openly admitting how hard they've become to get right — partly because companies need to verify the return on their investment in expensive AI tooling, and partly because more teams are openly admitting how hard they've become to get right. So they've mostly settled on two dimensions: AI adoption and productivity. For the first, it's easy enough to check token consumption per engineer. For the second, most companies — surprisingly or not — are reaching for old metrics: pull request or commit counts, story points completed, tickets closed, just to name a few. These show activity, but they also miss most of what developers now spend their time on: reviewing AI-generated implementations, comparing design approaches, refining specifications and constraints, validating security and compliance, evaluating generated tests, improving prompts and workflows, and making the architectural calls that shape what gets built next. In other words,
the more leverage AI provides, the less visible the resulting work becomes.
So the first question that comes to mind is: are we measuring what actually matters?
Maybe the better question isn't how productive developers are, but how we should measure an engineering organization where humans and AI operate as a single delivery system.
For all the certainty flooding your feed right now — which tool to learn, which framework to adopt, which role to chase next — the honest answer, after two pieces on this, is that most of it is still being figured out as we go. None of this — the new roles, the new pricing models, the new agile, the new bottlenecks — is really about AI. It's about an industry that scaled its tools faster than it scaled its judgment about how to use them.
Roles will keep shifting. Service models will keep getting renegotiated. Agile will keep bending into whatever shape teams actually need. None of that settles anything on its own — because the real gap isn't in what AI can do, it's in what we've chosen to measure, define, and reward while it does it.
I don't think that gap closes with a better prompt or a bigger context window. It closes the way it always has: teams and leaders deciding, on purpose, what they actually want to optimize for — and building the roles, processes, and metrics that reflect that choice, instead of inheriting the old ones by default.
Top comments (1)
The broken-metrics angle matters. AI can make throughput look better while review load, context switching, and decision risk get worse. I would rather measure cycle confidence than raw generated output.