Nobody Knows What to Hire For. This is the Only Stable Bet.
FutureLab's Substack
SubscribeSign in
Nobody Knows What to Hire For. This is the Only Stable Bet.<br>By Ashwin Krishnamoorthy
FutureLab by NST<br>Apr 28, 2026
Share
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:<br>“We’re shipping faster, but everything is piling up at QA.”
Engineering Leaders engaged in a discussion at FutureLab<br>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.<br>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.
What the work actually was
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.<br>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.<br>That work - the work between humans - is where software has always actually gotten made.<br>The typing was the visible artifact. The judgement was the invisible one.<br>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.<br>Then AI arrived and accelerated the visible part.<br>What AI actually changed
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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>The data is telling us this already
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...