Automate software delivery

How much of a software delivery run can happen without a person typing: a real 10-step build run counted at 70%, what the three human steps are, and how to count your own team's run.

Software delivery can run 70% automatic today, counted on a real build run: ten steps from problem described to go-live, seven done by systems, three kept by a person on purpose. AI made the coding fast; what makes delivery automatic is putting the process itself inside the AI, so research, planning, tests, checks and packaging happen the same way every run and a person decides only at the gates.

A real run, step by step

This is the delivery run behind that number: an agent build, from first description to shipped. Tags follow the counting method.

#	Step	Who
01	Problem described: who you are, the pain, the users, the red lines	HUMAN
02	Follow-up questions asked: data, tools, what must never happen	AI
03	Plan and specs written: architecture and acceptance criteria before any code	AI
04	Plan approved: one read, one decision	HUMAN
05	Tests written first: the exam before the class	AI
06	Code written until the tests pass, guardrails built in	AI
07	Evals scored: a report card the work ships with	AI
08	Gate checks: permissions, secrets, red lines, unwaivable	AI
09	Package and delivery report, in plain language	AI
10	Go-live approved: a person signs off, it ships	HUMAN

7 AI, 3 HUMAN: 70%. The three human steps are the point, not the leftover: describing the problem, approving the plan, approving go-live. Judgement stays; typing goes.

Why the human steps are these three

A step stays with a person when it carries judgement, risk or a final yes; the full rule is on what automates. In software delivery that means the intent (what should exist), the plan (is this the right shape), and the release (does this ship). Everything between those gates is repeatable, checkable and reversible, which is exactly the work systems hold well.

Spec first, code second

The order inside the run matters as much as the automation. The plan and the acceptance criteria are written and approved before any code, and the tests are written before the implementation. That order is what makes step 06 checkable: code is finished when the agreed tests pass, not when it looks done. Rework drops because the definition of done existed first.

What this is not

Not autocomplete. Faster typing still leaves a person holding every step. This moves whole steps, not keystrokes.
Not unattended. Three gates are in the run on purpose, and the gate checks at step 08 do not bend.
Not only for new code. The same shape counts for fixes, migrations and upgrades; the steps change, the tags behave the same way.

Count your own team's run

Write down one real delivery, one line per step, from request to shipped, and tag each step with the method. Teams adjacent to this one count high: in the record's worked counts, an agentic AI service lands at 73% and a SaaS support run at 78%, each with its judgement calls kept human. Your number will be your own.

When you want it counted with you, that is the workflow audit; bring the six answers and it goes fast. Or attach this record to ChatGPT, Claude or Codex and ask it to build your step table: the addresses are at razarizwan.com/access.html.

Common questions

Does this replace developers? It replaces the typing share of delivery. Someone still owns intent, architecture judgement and release risk, and those seats get more important, because they are the only three left.

How is quality held without a person watching every step? By making every step checkable before it runs: acceptance criteria before code, tests before implementation, scored evals before delivery, and gates that cannot be waived. A run that fails a check stops.

Where does a team start? Count one run. The step table shows which gates you already have and which steps are typing; the audit turns that into a build order.