My AI-Native SDLC Has Three Stages, Not Six

A decision, a build loop, and a proof gate. That is the entire software lifecycle behind seven live products, more than 10,000 paying users and members, and a Hebrew-native ad studio I run without a team. The AI-native SDLC playbooks circulating this week count six stages. I run three, and not because I skip work. Most stages in a normal lifecycle exist to move context between people, and I do not have people to move context between.

Most Lifecycle Stages Are Handoffs Wearing a Costume

Pick any stage in a standard process and ask what it actually produces. Grooming produces a ticket precise enough for someone who was not in the room. Estimation produces a number a manager can plan a quarter around. A QA handoff produces a queue, so a tester can work while the developer moves to the next thing. A status update produces visibility for people who cannot see the branch. Every one of those outputs is a message between humans holding different context, and the stage exists to carry the message, not to improve the product.

When Claude Code writes the code and I am the one reviewing it, the context never leaves one head. There is nobody to brief. There is no second person whose idle time an estimate protects. There is no queue to feed. So the stage stops producing anything at all, and a stage that produces nothing is overhead with a calendar invite. I did not optimize those stages. I deleted them, and nothing downstream noticed.

Stage One: Decide, In Writing, Before Any Code Exists

This is the only stage I made slower. On Tadam, the AI ad creative studio, the hard part was never generating an ad. It was deciding what the product refuses to do: which Hebrew layouts it will not attempt, which brand inputs it demands before it renders anything, what happens when a generation looks wrong rather than fails. Those are product decisions, and an agent will happily build either answer at the same speed. If I enter the build loop with that unresolved, I get working code for the wrong product, and working code is much harder to throw away than an empty editor.

Arvuyot Yashir, the digital rental guarantee product, made the point permanent. Money and legal documents have no safe default. Every rule has to be written down before the loop starts, because the agent cannot infer an Israeli landlord's expectations from the surrounding code. So stage one ends with a file, not a conversation, and the file is the only artifact I hand to the agent.

Stage Two: One Build Loop Instead of Four Phases

Stage two is a loop, not a line. I give Claude Code the decisions from stage one, it writes, I read the diff, I correct the direction, it writes again. The phases a traditional process would draw around that work, implementation, then code review, then testing, then integration, all collapse into the same loop because the same person is at every point in it. Here is what came out of the process entirely:

• Ticket grooming. The decision file from stage one is the ticket, and it is written for an agent rather than for a teammate who joins next month.
• Estimation. A loop that finishes in an afternoon does not need a number attached to it the day before, and the number was always for someone else's planning anyway.
• The QA handoff. Nothing sits in a queue waiting for a second person, so the test run belongs inside the loop that caused the change.
• Status reporting. The branch, the pull request and the deployment are the status, and I am the only person reading them.
• Separate design review. On Luma and Tadam the agent builds the screen, I open it in the browser, and the call happens right there in the same loop.

Stage Three: Proof, Which Is Now the Expensive Part

Deleting handoffs did not make the lifecycle cheaper overall. It moved the cost. When code appears faster than I can read it, the only thing standing between a confident diff and a broken product is proof: the narrow test that fails if the logic breaks, the security pass, the live check on the real deployment with the real data. Stage three is the one place I refuse to compress, because it is the only stage whose output is still about the product rather than about coordination. That is the whole trade. A team spends its process budget on keeping people in sync, and a solo AI-native setup spends it on verifying work that was produced faster than any human could have produced it. Six stages of coordination plus weak proof is the worst version of this. Three stages with proof that actually runs is the version that ships.

Where Three Stages Stop Working

The moment a second person touches the code, the handoffs come back, and they should. I mentor more than 600 students at nCode, and I do not tell them to run my process. I tell them to audit theirs the same way: take each stage, name the human whose missing context it exists to supply, and if that human does not exist on your project, the stage is not protecting you. On a team of five the ticket is real, the estimate is real, and the review queue is load bearing. On a team of one with an agent in the loop, most of it is theatre you perform for an empty room. So the question is not how many stages the AI-native playbook recommends. It is which of your stages would still produce something useful if nobody but you ever read the output. Mine answered that question three times, and the other answers got deleted.