For most of the history of software, the expensive bit was building it. Teams spent months turning ideas into working code, and that scarcity shaped everything about how the work got organized.
Roadmaps got sequenced around whatever engineering capacity was available; architects earned their seat at the table because they understood systems nobody else did; product managers spent their weeks translating vague business asks into something a developer could act on. Writing software was the bottleneck, and naturally, writing it was where the leverage lived.
That’s no longer true, and the shift happened faster than most engineering leaders have had time to metabolize.
AI coding tools have collapsed the cost of implementation. So, work that took a team of engineers weeks now takes an agent a couple of hours. And the obvious assumption was that faster building would translate directly into faster value delivered.
What’s actually happened, however, is messier: teams can now produce more software than they know what to do with, and the thing slowing them down has quietly moved somewhere else.
“You can’t apply AI to a broken process,” said Pablo Gamba, head of technology Americas at global software and AI solutions startup intive. “It’s like giving a faster shovel to a worker. He’ll work faster, but only in the wrong direction.”
Faster Execution, Same Old Constraint
Every major inflection in technology- the internet, cloud, and offshoring has followed an identical shape. Something that used to be expensive became cheap almost overnight, and everything a firm had built on the assumption of that expense had to be torn down and rebuilt.
This time, the thing getting cheap is applied technical intelligence itself, which happens to be exactly what services firms and engineering teams have spent decades charging for, Gamba claims.
Cheaper execution doesn’t make the constraint disappear, though. It just moves it somewhere less visible. The coding bottleneck, for example, in migrating upstream, has sped up implementation, but the hurdle is now in code review. Automate code review and it shows up in testing and deployment; automate that, too, and eventually it lands on the humans writing the specifications the agents are working from.
Because an agent can only build what’s been described precisely enough to act on without guessing.
That’s the trap a lot of teams are walking into right now, often without noticing. If you can build almost anything in a fraction of the time it used to take, the cost of building the wrong thing goes up, not down, because you’ll find out you were wrong faster and with more already shipped.
An assumption that used to surface slowly, over weeks of manual coding, can now therefore become load-bearing infrastructure before anyone thinks to question it. Prioritization, not raw output, ends up deciding whether the AI investment actually pays for itself.
In this paradigm, Gamba believes companies should be tracking not development speed, but the full cycle from intention to production. “If you improve development speed but QA is your bottleneck, you’ve just reached QA faster. Then you fix QA and the bottleneck moves to requirements,” he said.
The numbers back him up, too. Fortune 50 enterprises using AI-assisted development are shipping commits 3x-4x faster than their peers, as per research from the Cloud Security Alliance, but introducing new security findings at roughly ten times the rate.
Speed without a clear destination, in this sense, doesn’t just waste effort; it compounds risk faster than most security teams can keep pace with.
Getting Requirements into a Language AI Can Actually Leverage
If definition is where the real constraint now sits, the fix isn’t more documentation. It’s different documentation, written in a form an AI system can execute against without filling gaps on its own.
That means retiring the requirements doc written for a human to interpret with judgement and replacing it with structured acceptance criteria, explicit domain models, and contract tests that spell out what a feature should never do as clearly as what it should.
Agents, after all, fill ambiguity the same way a junior engineer might, with a confident guess. The difference is the latter’s guess comes wrapped in some hesitation, a flag to a senior colleague, a sense that something might be off.
An agent’s guess looks nothing like that. It shows up as clean, fluent, fully-formed code, and there’s no hedge in it anywhere, even when it’s wrong.
Writing a spec precise enough to survive that gap starts to feel less like drafting a product brief and more like drafting a contract. You name every actor, map every state transition the system’s allowed to make, and account for the edge cases instead of quietly leaving them to the happy path, the way most requirements docs still do.
Teams that treat this as a documentation chore learn the hard way that vague intent just produces vague software at machine speed.
The teams actually capturing the productivity gains are those treating such spec-writing as its own engineering discipline, with the same version control, review cycles, and testing rigor that used to be reserved for the code itself.
In Gamba’s words, AI-native isn’t permission to skip process, but a demand to redesign from scratch. “Many organizations are trying to apply AI to old processes. That’s not transformation. AI-native organizations start with a different question: if AI existed from day one, how would we design this process today?”
Backlog Managers, Curators of Intent
Product, architecture, and engineering used to run as three separate functions with clean handoffs between them: product decides what to build, architecture figures out how, engineering ships it.
Once implementation gets cheap and fast, those handoffs turn into the slowest part of the whole chain. What ends up mattering here is whoever can hold the entire picture at once, translate intent into something an agent can execute, and catch a bad assumption before it turns into shipped code nobody wanted.
That redesign is quietly shaping who does the defining, and what the job even is anymore.
“Think about what’s happening to the software engineer role. They’re no longer just writing code. They’re overseeing the output of agents, defining specs, preparing tests, validating outcomes. That’s merging what used to be three separate roles into one,” said Gamba.
In other words, what’s valuable now isn’t knowing how to write a ticket or run a sprint. It’s knowing what “great” looks like before the work even starts, being able to tell the difference between what’s intellectually interesting and what customers actually need, and having the nerve to kill an idea quickly when it clearly doesn’t clear that bar.
Those are judgement calls that used to get distributed across a product manager, an architect, and a tech lead comparing notes. Increasingly, they’re landing on whoever is closest to defining the work in the first place.
And it’s also worth remembering: none of this makes the titles disappear. But the lines between them are getting harder to defend, while the people thriving in that blur are the ones acting as curators of intent.
Fast Execution Without Guardrails Isn’t a Win
There’s a risk that’s easy to lose sight of once intent is clear, and the AI pipeline is genuinely humming: fast, well-defined execution can still introduce failures a slower, more human-mediated process would have caught almost by accident.
The numbers here are not even close. Veracode’s spring 2026 testing across leading models found that only 55% of code generation tasks produced secure output when no explicit security guidance was provided, a figure that has barely budged in two years even as functional accuracy has jumped considerably.
It’s clear getting the syntax right stopped being the hard part a while ago. The judgement calls a human engineer used to make instinctively while typing, around security, compliance and what data should and shouldn’t touch what system, are the parts that’s hard to replace.
This means the same rigor applied to defining what to build has to extend to defining what’s off limits, such as compliance boundaries, data handling rules, and ethical constraints spelled out with the same care as functional requirements.
Leaving those implicit and hoping an agent infers them correctly is the same mistake as leaving product requirements vague and crossing fingers so the build somehow turns out fine.
What Leadership Looks Like
None of this argues against AI-accelerated development; building has never been faster or cheaper, and there’s no putting that back in the bottle.
But what hasn’t gotten any easier, and arguably got harder, is deciding with real precision what’s worth building, describing it well enough for a machine to execute faithfully, and drawing the lines it isn’t allowed to cross while doing so.
At the enterprise level, the teams pulling ahead aren’t the ones with the fastest coding agents, that part’s clear. It’s those who worked out, before their competitors did, that definition was always going to be the harder problem – and started treating it that way.
