Shipping a product with AI agents: what actually changes

I've worked with AI agents on nearly every engagement for over a year now. Not because it's fashionable, but because it genuinely changes my delivery speed, provided I'm honest about what it does and doesn't replace. It doesn't replace engineering judgment. It moves where that judgment gets spent.

The shift, concretely

Before agents, a large share of my time went into writing code: typing the lines, handling plumbing, repeating patterns I already knew. With an agent that writes fast and plausibly, that time collapses. But a new bottleneck shows up immediately: if the spec is vague, the agent produces code that compiles, looks reasonable, and solves a problem slightly different from the one you had in mind. The work doesn't disappear, it moves upstream, into the clarity of what's being asked and the architecture that constrains the possible choices, and downstream, into verifying what got produced.

Concretely, that means I spend more time than before breaking a problem into small, verifiable tasks, and less time typing code myself. It also means I spend more time in review, because plausible-but-wrong code is more dangerous than code that doesn't compile: it passes the eye test, sometimes it passes existing tests, and it quietly breaks something else.

How I structure the work

The principle that works is treating every task as a verifiable contract before handing it to an agent. First a plan: what are we building, why, what are the steps. Then break that plan into tasks small enough that only one thing can go wrong at a time, and precise enough that you know what success looks like before you start. Then tests as the gate: for a feature or a fix, write first what proves it works (or reproduces the bug), before letting the agent implement it. Finally, review: I read the diff, I don't skim it, because that's the only point where human judgment actually acts on what ships to production.

This cycle, plan then small verifiable tasks then tests as the gate then review, isn't new in itself: it's just serious software engineering. What changes with agents is the speed at which you can cycle through it, and therefore how tempting it is to skip a step because you're moving fast, and how important it is not to.

What breaks if you're not careful

Three things break regularly on teams that use agents without discipline. Context loss first: an agent working on a long task forgets or bends constraints set earlier, and produces a solution that looks coherent but contradicts a decision made twenty exchanges ago. Plausible-but-wrong code next: the most dangerous trait of an LLM is that it never writes code that looks uncertain. It carries the same apparent confidence whether it's right or wrong, and that's no accident of manufacture: these models were trained and evaluated against scoring schemes that reward taking a shot and never credit abstention. Silent regressions last: an agent fixing a local bug can, along the way, change an adjacent behavior nobody was testing, and that only surfaces weeks later.

What these three risks share is that none of them shows up while the agent is writing. They show up later, downstream. Which is precisely what the 2025 DORA report measures, across nearly 5,000 software professionals. It finds two things at once, and you have to hold both. AI adoption does correlate with higher delivery throughput: teams genuinely ship more code, faster. But it also still correlates with greater instability: more change failures, more rework, longer times to restore. The gain is real and so is the bill; the bill simply arrives later, and it doesn't arrive in the same place.

The authors' own formulation captures what I see in the field better than I could: AI doesn't improve a team, it amplifies what the team already is. A team with solid tests, clean version control and fast feedback loops absorbs the extra volume and moves faster. A team without those nets watches its weaknesses arrive sooner and in greater number. The agent doesn't create the problem, it raises the rate at which the problem surfaces.

So the defense against all three is the same, and there's nothing exotic about it: small tasks, tests that cover the behavior before you touch it, and human review that does more than check that it compiles.

What it means for a client

For a client, this doesn't mean "cheaper because fewer human hours." It means faster without a quality trade-off, because the time saved on writing is reinvested into spec and verification, not cut. The speed doesn't come from skipping steps, it comes from the steps that already mattered (understanding the need, breaking down the work, verifying the result) cycling faster with a collaborator that doesn't tire on the mechanical part.

I'm not selling a promise of magic automation. I'm selling a faster engineering process where I remain the decision point on architecture, product trade-offs and final quality. That discipline, not the agents themselves, is what separates a project shipped fast and well from one shipped fast and regretted six months later.

A concrete example, taken end to end with this approach: Project A, a B2B prospecting platform I designed, built and shipped on my own.