Code is cheap now. Your team structure probably isn't ready.
Before you mandate AI-assisted development, rethink who does what, and how fast you actually want to move.
For most of software's history, writing code was the slow and expensive thing, so we organised around it. We split teams into backend, frontend, architects and platform: specialists who could each produce their slice faster than a generalist could. We worked in two- to three-week sprints, at the end of which we could evaluate the progress. All of it, the specialties and the long cycles, was a response to one constraint: coding was slow.
No longer. In my experience, the frontier AI is, for all practical purposes, a mid-to-expert full-stack developer. It will generate thousands of lines across the stack in a few minutes. So the bottleneck is no longer writing code. It's understanding it: holding the whole system in your head well enough to judge whether a change is sound, what it touches, and whether it should have been built at all.
If your engineering team is still carved into narrow lanes, AI-led development won't give you what you're hoping for.
Narrow ownership is where it breaks
Picture a backend developer who changes a service without fully grasping how it interacts with the frontend, the database and the systems downstream. Now hand that developer an AI agent. The agent will make changes whose implications across those other components the developer isn't equipped to see. The code looks fine in isolation and quietly breaks an assumption somewhere else.
This is made worse by how agentic coding behaves today: it builds more than you asked for. Some of that extra is genuinely useful. A lot of it isn't. Either way, someone has to understand the blast radius of every change, and a specialist who only sees one layer can't.
The cost argument
And it isn't even cheaper.
Say you adopt AI-led development on top of your existing structure. Your backend developer makes a clean, surgical change, exactly what was asked, and hands it off: to the frontend developer, to whoever owns the next module, to the reviewer. At each stop, the AI reads that same change again, a second time, a third time, once per handoff. And those re-reads aren't free, or even consistent: the model is non-deterministic, so how each developer frames the prompt shapes what comes back. Hand the same code to two people and you get two different readings of it. That's where the tokens go: rework and context thrash. A handoff misses a cross-component implication, something breaks, and now you're paying for debugging round-trips and for rebuilding context in every new session. The spend balloons, easily several times what the change should have cost.
And it's cumulative. To see how fast, I traced a single prompt to an agentic coding tool. Of the 626,538 input tokens it billed, only 67,306 were new. The other 559,232 were the same context, re-sent on every one of its 11 internal calls. This is for one developer and one prompt. Now extrapolate across developers and prompts, and the token count spirals.
Even though 80 to 90 percent of those tokens are cached, and cached tokens are cheap to process, when the numbers are huge it stops being a rounding error and becomes a line item. Across teams the cache benefit might not even accrue.
What the team should look like
The goal should be to reduce handoffs and promote as much co-development as possible. Before you push developers to adopt AI, change the shape of the team. In a first-class AI-led setup, I'd build around three people working in tight collaboration:
- A product owner who can define, clearly and concretely, what's worth building, and validate each piece the moment it lands.
- A full-stack architect who understands backend and frontend, keeps the system reliable and operable, and makes sure the AI's changes are sensible and clean. That last part matters more than it sounds. Even when you instruct the model to follow SOLID or DRY, it will ignore some of it. It is not unusual for AI to emit a single monolithic file thousands of lines long. Keeping the codebase clean is a continuous, deliberate job, not an afterthought.
- A tester who reviews changes thoroughly.
These three pair-program. They work closely and ship deliberately, with handoffs measured in hours, a day at most. A sprint shouldn't run longer than about three days, and you're delivering epics, not stories, because a single well-scoped story should now take minutes to implement, with the product owner reviewing and validating it almost as fast.
Code is cheap. Slow down anyway.
There's a thrill to watching AI produce a thousand lines in minutes, a real dopamine kick. And the agent feeds it. It keeps asking: should I build this next feature for you? The urge to say "yes, go" is strong, and that urge is the new failure mode.
So revisit the pace at which you churn out features. Take your time. There will be stretches where your developers don't have much to do, and that should be fine: idle hands are far cheaper than the wrong feature shipped fast. Your PMs and product owners, meanwhile, will need more time, not less, to decide what's actually worth building, because they are now the real constraint on the system.
And it isn't only your team that has to keep up. Your users do too. Every shipped change is something they have to absorb, and a firehose of new experiences is its own kind of harm, not a gift. So the constraint moves: from writing code to deciding what's worth writing.
That judgement, what to build, what to hold, what to never build at all, is the most important thing now, and it won't come from the agent. It will come from humans.