The exhilarating pace of AI-driven development, experienced firsthand

The post that named it

Almost a year ago, AWS renamed the way we build software. The post announcing it, the AI-Driven Development Life Cycle, AI-DLC for short, arrived with a whole new vocabulary. Sprints became Bolts, shorter cycles measured in hours. Epics became Units of Work. Solo coding gave way to Mob Elaboration, where the team gathers around an AI to shape requirements together. Work that once took weeks, the post promised, would now take days.

I read it twice, nodded along, and was left with one question. What does this look like on a Tuesday?

Not in a keynote. On a real Tuesday, with a real repository, a real deadline, and an AI that is confidently wrong at least once before lunch. The AWS post names three phases and five benefits, and it does not show a single day of the lifecycle in motion. Fair enough. It is a framework post, and frameworks describe the ideal. But somebody should show the Tuesday.

For the past five weeks, I have. My logs kept score.

The scoreboard

Between June 16 and July 21 I ran my own product studio through this lifecycle: Blue Motion Academy, which teaches app-building to middle and high schoolers; Maitri, an AI care companion; a curriculum site; interview systems; research engines. One person, directing a fleet of AI agents. Here is what the meter read.

Two labels before you trust any of this, because the numbers deserve their labels. The dollar figures are what this volume would cost at API list prices; my actual cost is a flat monthly subscription, so they measure intensity rather than spend. And the labor equivalence is a modeled estimate. No one kept a timesheet. The measuring tool’s own guidance says to discount its raw estimate to a quarter or half once you account for review and reuse. Discounted that way, five weeks of output still lands between $115K and $230K of Bay Area product work. I flag the method so you can argue with it. The logs are real either way.

The mob turned out to be me

Here is the first thing the framework missed. AWS draws the AI at the center of the diagram, with a cross-functional team gathered around it. Mob Elaboration assumes a mob.

My mob was one person. And the diagram inverted.

The agents write the code, the pages, the tests, and the first drafts of nearly everything. I write the intent: the specifications, the architecture decisions, the acceptance gates, and the final yes. On my heaviest day I had 36 sessions running across projects. The day after that, the fleet pushed 1.59 billion tokens through the pipeline. A mob was standing around the work after all. It reported to one person, and most of it was software.

The lifecycle I run

Every piece of work in those five weeks walked the same road, whether it was a payment screen, a curriculum page, or a legal document. Six stages, three of them gates.

Stage one will look familiar to anyone who read the AWS post: the human supplies intent, the AI elaborates. The difference is everything after that. Their model trusts the AI to generate quality. Mine assumes the AI will be confidently wrong on a schedule, and builds the tollbooths where the wrongness gets caught.

Every gate has a scar

None of those gates came from theory. Each one exists because something specific went wrong, and my own retrospective describes the pattern better than I can paraphrase it: a named failure became a written rule, the rule became a mechanism, the mechanism got an enforcement point, and the enforcement point produced a documented catch.

Three scars, told plainly.

The morning two sessions collided. On July 8, one of my parallel sessions checked out a branch and silently moved a sibling session’s work. Files blinked in and out of existence as two fleets edited one shared tree. Before that morning I had roughly fifty commits pushed straight to trunk and zero pull requests. The fix took one day: an isolated git worktree per session, a branching contract, and hooks that refuse any edit on trunk. After July 8, every single change landed through a pull request. The next day was the heaviest of the whole five weeks, and it went through without one collision.

The test suite that never ran. Early in the window, an agent produced 7,500 lines of tests that never compiled. They sat there for days, radiating false confidence. A test that does not run still changes what you believe, and in the wrong direction. The dead tests got deleted and replaced, in three days, with a small green suite wired into the deploy: fewer tests, all real. Weeks later that same gate blocked a broken trunk from deploying three times in a single day. Every block was a bug that would have reached production.

The sentence that cost 44 pages. One machine-sounding sentence slipped into the curriculum, the kind of hollow flourish AI writing produces when nobody is watching. Cleaning it up meant sweeping the whole site and retranslating four languages: 44 pages of rework from a single line. Now a voice linter reads every page before it ships, and it gates hard. The linter is not there because I lack taste. It is there because taste gets tired at session thirty.

What the framework posts leave out

Here is the part no vendor post will tell you, so a practitioner has to. The gates fired on me constantly. In one measured week, the verify gate stopped me about forty times. The dash linter caught my writing six times. The trunk guards blocked more than ten attempts to commit where I had promised not to. My retrospective for that week contains a sentence I keep rereading: I have been treating the enforcement hooks as the process instead of the backstop.

That sounds like an indictment of the lifecycle. It is the opposite. The whole design assumes the operator will get sloppy at speed, because five weeks of logs prove the operator does. The AWS post promises that AI will apply your standards while generating comprehensive tests. My logs say something more useful: the standards hold when they are wired into the pipeline, and only then. Jocko Willink compresses this into three words, discipline equals freedom, and the numbers back him. The week with the most gate firings was also the most productive week of the five.

The rigor did not slow the throughput. The rigor is what made the throughput survivable.

Start on a Tuesday

You do not need my whole apparatus to try this. Three moves capture most of the value. Write the specification before the prompt, in a file, so the reasoning outlives the chat window. Put one hard verification step between the agent’s output and the word done, even if that step is rendering the thing and looking at it. And keep a decision log, because in week four you will not remember why week one chose that architecture, and neither will your AI.

The AWS post ends by inviting you to start your AI-DLC journey. I will end differently: the lifecycle is real, it works, and it will humble you roughly three times a week. The full method, taught step by step against real projects, is what Blue Motion Academy is for.

As for me, I am writing this from a fjord in Norway, on vacation, where my agents cannot reach me. Mostly.

Next field note: Where the saved hours go, on the two industry reports that just measured the paradox these gates exist to fix.