At FutureLab in Pune last month, Ranjeet Walunj described what’s happening inside his team at CleverTap. Sprint cycles have compressed from 14 days to 2–3 day iterations. Prototype-to-production timelines that used to take months are now weeks. And then someone in the room said the thing nobody had quite named yet:
“We’re shipping faster, but everything is piling up at QA.”
That sentence is the whole problem - in how teams work, in how teams train, and in how the industry is hiring. And it has a specific diagnosis.
Most of the conversation about AI and software engineering rests on one unchecked assumption: coding was the hard part, AI has made it easier, and now we’re figuring out what comes next. The assumption is wrong. Coding was never the bottleneck.
Anyone who has shipped real software knows this, even if they’ve never said it out loud. A senior engineer working from a clean specification could out-produce four juniors with unclear requirements long before AI showed up. The constraint was never typing speed. It was never syntax recall. It was never the act of writing a for-loop.
The constraint was everything else. Figuring out what to build. Translating fuzzy human intent into something buildable. Coordinating across five people who each held a different partial picture of the system. Reviewing what came back for fit-with-the-system, not just fit-with-the-spec. Catching the problem that had been solved at the wrong layer. Integrating three features without breaking something two layers away.
That work - the work between humans - is where software has always actually gotten made.
The typing was the visible artifact. The judgement was the invisible one.
And for most of the last thirty years, the industry quietly conflated the two, because the visible artifact was how you measured people and the invisible one was something you developed in the background by doing enough of the visible work.
Then AI arrived and accelerated the visible part.
This is where most of the current conversation goes wrong. People look at Claude or Cursor or Copilot and say “AI is making engineers more productive” or “AI is replacing engineers” or “AI is changing what it means to code.” All three claims are partially true and all three miss the point.
What AI actually did is this: it accelerated the specific part of the job that was already the fastest. Artifact production. The boilerplate, the syntax, the first-pass scaffolding, the code that had to exist but didn’t require thinking. The stuff a competent engineer with five years of practice could already produce quickly, AI now produces quickly for everyone, regardless of experience.
That is genuinely valuable. I am not dismissing it. Anthropic’s own December 2025 study of their engineers found that 27% of their AI-assisted work “wouldn’t have been done otherwise.” Backend engineers built UIs they couldn’t have built alone. Researchers produced visualisations that used to require a dedicated designer. That is real capability expansion. I use these tools daily. The speed is not imaginary.
But it accelerated the easy part of the job. The hard part did not get faster. In fact, the hard part got harder, because there is now more output to coordinate, more intent to specify precisely enough that the generated output is usable, more review to do per unit of time, and more places things can break. The prep, the coordination, the review, the integration - these were always the real work, and AI did not touch them. It just made the artifact they produce land faster.
The practitioners who have figured this out are the ones winning. Not because they type faster. Because they spend less time typing and more time thinking about what to type, and reviewing what came back. They have shifted their own effort allocation from generation to specification and review, and their output has gone up, and the quality has gone up, and they cannot always articulate why it works.
The ones who are losing are the ones still treating coding as the bottleneck, and AI as the thing that removed it. They generate more. They ship more. They spend more time debugging output that is almost right, but not quite. Which brings me to the data.
Stack Overflow’s 2025 developer survey of nearly fifty thousand developers produced a statistic that deserves to be quoted out loud until everyone has heard it. The single biggest frustration with AI tools, cited by 66% of respondents, is “AI solutions that are almost right, but not quite.” The second biggest, at 45%, is that debugging AI-generated code takes longer than writing it themselves. And in the same survey, AI usage went up (84% use it or plan to) while trust went down (only 29% trust the outputs, an eleven-point drop year over year).
Read those numbers carefully. The people who use AI most are the ones who trust it least, because they have seen enough of its failure modes to calibrate. And the thing AI most commonly produces, from the point of view of the practitioner who uses it every day, is work that is convincing enough to look done but wrong enough to require judgement to catch.
Anthropic ran a randomised controlled trial on their own engineers in late 2025. Fifty-two of them learning an unfamiliar async programming library. Half used AI, half didn’t. The AI group finished about two minutes faster, a difference that wasn’t statistically significant. But on the comprehension quiz about the new library afterward - debugging and code-reading and explaining - the AI group scored seventeen points lower. The largest gap was in debugging. Debugging is the skill most tightly coupled to understanding what a system is actually doing. The AI group produced working code faster and understood it less.
The frame people reach for when they see these numbers is “AI makes engineers worse.” That frame is wrong, or at least incomplete. A more accurate frame is this: AI accelerates the production of artifacts while doing nothing to accelerate the judgement required to evaluate them, and it does this while removing some of the practice that used to build that judgement. The productivity gain and the trust gap are not in tension. They are the same phenomenon seen from two angles.
Google’s DORA report from 2025, surveying nearly five thousand technology professionals, reached a version of the same conclusion from the organisational end. “AI doesn’t fix teams. It amplifies what’s already there.” Strong teams with good review discipline, clear specifications, and mature coordination habits got significantly better with AI. Weak teams got worse. Same tool, opposite outcomes. If AI were really about removing the bottleneck of coding, every team that adopted it would get better. The fact that half of them get worse tells you where the actual bottleneck lives.
I don’t want to prescribe anything in this piece. I want to describe what I think changes for the reader who accepts the reframe.
If you’ve noticed that a two-person team with AI can now ship what a ten-person team used to, and that the two-person team still has exactly the same number of hours in the day and the same finite cognitive budget, then you have noticed the real bottleneck. It is human attention, applied to specification and review. It is not a constraint AI removes. It is a constraint AI makes more acute, because the output per unit of attention is now much higher, and the quality depends on whether that attention was spent well.
If you’ve noticed that your best AI output comes from the sessions where you spent thirty minutes writing context, specs, and examples before you prompted anything, that wasn’t a coincidence. That was the work. The thirty minutes was the productive part. The generation was the easy part. Your instinct to spend more time on the prep and less on the generation is correct, and the industry’s current framing of “just prompt it and iterate” is selling you a workflow optimised for the part of the job that was already fast.
If you’ve noticed that reviewing a colleague’s AI-generated pull request takes you longer than reviewing their hand-written code used to, that isn’t because AI writes worse code. It’s because AI writes code without carrying the context that used to come bundled with hand-written code.
You are now doing the cognitive work the author used to do while writing, but doing it after the fact, on someone else’s output, at the worst possible point in the workflow. The review is more expensive because the specification was cheaper.
If you’ve noticed that onboarding a junior engineer feels different now, and not better, it’s because the work they were supposed to be learning through - grinding through small tasks, reading unfamiliar code, debugging at two in the morning - has been quietly automated. The grinding wasn’t important because the outputs mattered. It was important because it was how judgement got built. Shortening the grinding shortened the path, and the skills that used to emerge at the end of the path are now not emerging, because nobody is walking it.
The practitioners I watch doing this right spend their time differently than they did two years ago. They start more slowly. They write specifications that would have seemed excessive before. They build small reference examples before they generate anything. They read AI output with the same suspicion they’d bring to a pull request from a new hire. They refuse to ship things they don’t understand. And they produce, measurably, dramatically more good software than they used to, because the thirty minutes of prep they now do means the three hours of generation-plus-review that used to happen has collapsed into forty minutes of good generation and ten minutes of focused review.
The prep is the work. It always was. AI just made it unmistakeable.
If coding was never the bottleneck, and AI accelerated the non-bottleneck, then almost everything we tell ourselves about AI and engineering is framed wrong. The hiring conversation is framed wrong. The training conversation is framed wrong. The productivity conversation is framed wrong. The “what juniors should learn” conversation is framed wrong. They all assume AI removed the hard part of the job. AI removed the fast part of the job. The hard part is exactly where it’s always been, and it is now under more pressure, not less.
Both FutureLab conversations have circled this without quite landing on it. Leaders describe their teams shipping more and feeling more stretched at the same time - more code, more review debt, more incidents, less certainty about what’s actually correct. The amplifier frame gets them part of the way there. But underneath is this simpler observation: the work that was always hard is still hard, and we built our industry’s productivity story on the assumption that the easy part was the hard part.
The same reframe changes what you hire for. If the bottleneck is now verification - knowing when output is wrong, specifying precisely enough that the output is useful, reviewing at the speed AI generates - then you’re not hiring for the fastest coder. You’re hiring for someone who can reason about what a system is actually doing. That skill doesn’t shift with every framework update. It’s the only thing that doesn’t.
Once you have the reframe, you cannot unsee it. You start reading job descriptions differently. You start reviewing your own workflow differently. You start noticing which of your colleagues have quietly figured this out and which are still optimising for the wrong layer. You start asking what your team is actually training for, and whether that training is still producing what it used to produce.
And you start noticing that the people who seem to be getting the most out of AI are not the ones who prompt the fastest. They are the ones who think the longest before they prompt at all.
This showed up in an unexpected place recently. Muthu, AI Transformation Lead at Sanas, who is a part of the FutureLab community, came to Newton School of Technology’s (NST) Bangalore campus to run a masterclass on AI agents and the future of programming.
His session covered exactly this territory - why vibe coding isn’t sustainable, why copying code without understanding it creates debt that compounds, why the engineer’s role is shifting from writing to reasoning and review. He ran a hands-on workshop alongside it.
By the end of it, he had a clearer read on what our students could actually do than most interview processes would give. Sanas hired from the cohort shortly after. What stood out wasn’t framework knowledge.
It was that the students could reason through unfamiliar problems in real time, debug on the spot, and ask the right questions before writing a line of code. In an AI-era team, that turns out to be exactly what you need.
At NST, we redesigned our first year around this exact shift - what has to survive when AI removes the old scaffolding. We kept debugging without assistance. We kept hand-writing the hard parts. We kept specification exercises before any tool touches the work. Our students are AI-fluent in the sense that matters in 2026: they know when the output is wrong. That substrate compounds into whatever the next framework turns out to be.
If you’re building a team for the verification era, our graduates are worth a conversation.
The prep is the work. That’s the whole game. Everything else is just typing.
Ashwin K is Head of Academics at Newton School of Technology, Bangalore. He writes about engineering, education, and what happens when the two collide. FutureLab is a community for engineering leaders navigating how AI is changing the way teams build shaped by the people in the room.