I manage four product teams at a large bank. The standard load is one. Three of my teams are conventional: engineers, designers, sprint boards, standups. The fourth is different. It has no engineers. I write specifications, artificial intelligence agents write the software, and a human still reviews every line before it ships.
The practice is called spec-driven development, or SDD. The idea is simple to state. Instead of translating what you want into code, you write down what you want precisely enough that an agent can do the translation. The spec is the source of truth. The code is an output of it.
Most of what gets written about this comes from two camps: people selling the future and people defending the present. My experience matches neither, so this is a field report from someone actually running one of these teams, with the caveats left in.
How the Loop Actually Works
I write a spec. Agents build from it. I review the output, sharpen the spec, and run it again. When the work is ready to ship, a human engineer reviews and approves the merge, the same gate any code faces. That checkpoint is deliberate and I have no plans to remove it. The goal was never zero humans. The goal is humans where their judgment matters most, and that place turned out to be review, not typing.
The split surprises people. Roughly seventy percent of my effort goes in before the agents write anything, front-loaded in the spec. Twenty percent is reviewing what comes back. The last ten percent is the loop between the two.
The management rhythm is unlike any team I have run. A conventional team takes a chunk of work, disappears, and resurfaces in two weeks with something to demo. With agents I run frequent, small check-ins instead of one big ship. On paper that sounds inefficient. In practice it fits an enterprise calendar perfectly, because a check-in fits in the ten minutes between meetings. I review output, adjust the spec, kick off the next iteration, and walk into my next meeting. The other side of the loop does not have a calendar, does not lose context overnight, and does not mind being interrupted. Maybe that cadence changes as the tools mature. For now it is one of the quiet advantages.
The Week That Replaced a Quarter
Here is the story I tell when people ask whether this is real. A major feature came through estimation the normal way: two engineers for a quarter. I built it myself, with agents, in a week. The human code review stayed, to be safe. Everything else about the quarter, the standups, the sprint planning, the coordination overhead, simply did not happen.
I want to be careful with that story, because it invites a lazy conclusion, which is that the engineers were the problem. They were not. The estimate was honest. That is genuinely what the feature costs when it is built the traditional way, across team boundaries, in the gaps between everyone's other commitments. What changed is where the time goes. The bottleneck moved from writing the software to specifying and evaluating it, and those turn out to be things one person with deep context can do.
Context Is King, and the Agent Starts With None
The single biggest lesson so far: context is king, and the agent begins with none of it. Every unwritten assumption in your head is a defect waiting to happen. The failure mode is not that the agent is dumb. The failure mode is that it is very good at building exactly what you asked for, which is not the same as what you meant.
The technique that changed my results was flipping the direction of the interview. Early on I tried to guess what the agent did not know and write it all down up front. You cannot. You do not know what you know. Now I have the agent interview me before it builds anything of consequence. Its questions expose the assumptions I could not see on my own. Letting the machine ask is better than guessing at its blind spots.
The other habit you have to break is the agent's instinct to impress you quickly. Left alone, it optimizes for looking done over being right. I tell it directly, every time: ask me, do not assume. In back-end data work, accuracy is king, and a fast wrong answer costs more than a slow question.
This is also why the popular prediction, that AI makes the product job shallower, has it exactly backwards. SDD demands more product depth, not less. On a conventional team, a vague requirement gets rescued by an engineer's judgment in the moment, or by a hallway question you never hear about. On the SDD team, vagueness ships. You need to know your domain to the bottom, because you are the last line of defense between a fuzzy idea and running code.
The Part Nobody Predicted
The biggest efficiency gain had nothing to do with typing speed. It was political.
A feature of any size at a large company crosses territory: several teams, several backlogs, several sets of priorities. A real fraction of enterprise product management is negotiating those boundaries, and a real fraction of the calendar is the meetings where the negotiating happens. The agent does not know the boundaries exist. Given the end-to-end problem, it optimized the full pipeline instead of the slice any one team owned. Work that would have been three teams' worth of dependencies became one spec.
I keep describing it to colleagues the same way: it was a good teammate. It did not protect turf, did not relitigate settled decisions, and did not need the pre-meeting before the meeting. Whole categories of coordination just evaporated. I am not claiming politics is gone. The humans around the work still have priorities and opinions, as they should. But the machine in the middle has none, and that subtraction was worth more than the speed.
What Is Still Hard
Evaluation. Writing the spec is the famous part, but designing the tests that tell you the output is right is the real skill, and it is genuinely hard. You need domain expertise and technical or interface expertise at the same time, because you have to know what correct means for the business and how software quietly fails, both at once.
That requirement reshuffles who is good at this job. In some ways a strong designer might be a better front-end SDD product manager than a traditional product manager, because a designer already thinks in exact states and edge cases rather than user stories. I run back-end data products, and I lean on my data science background and statistics training constantly: distributions, reconciliation checks, knowing which anomalies matter and which are noise. The discipline that sits closest to the output is the discipline that knows how to evaluate it.
The other cost is trust. Stakeholders weigh work differently once they learn no human wrote it. Some over-scrutinize it. A few quietly assume it must be sloppy. The honest answer is the same one that applies to human-built software: judge it by the tests and the outcomes, not the author. That argument is winnable, but you have to keep making it, and the human review gate is part of what makes it winnable.
What I Would Tell a PM Handed One of These Teams
The agent will say it is done long before it actually is. It is up to you to challenge it and know the truth.
That is the whole job in two sentences, and everything else follows from it. Testing and context are what matter, and both demand domain depth. Assume the agent knows nothing and let it interview you until it does. Keep human review at the gate, because it is cheap insurance and it buys trust. Check in small and often instead of waiting for a big reveal. And invest in your evaluations like they are the product, because in this model they are.
The junior version of the product job, the ticket writing and the status chasing, is what the agents replaced. What is left is the senior version: knowing the domain cold, deciding what is worth building, and being able to show with evidence that the thing in front of you is right. That job got bigger this year, not smaller.