--- title: "Shipping production software in plain English: what it actually takes" url: "https://toddpaulbrownjr.com/writing/shipping-software-in-plain-english/" author: "Todd Paul Brown Jr." description: "What it actually takes to ship production software in plain English: the gates, the status words, the failures, and the parts that still need a human." kind: "article" updated: "2026-09-26T02:50:39+00:00" --- # Shipping production software in plain English: what it actually takes I've been building production systems in plain English for the past year and a half. Not prompting a chatbot for code snippets—building real software that serves real users, with Claude Code writing the implementation while I direct, decide and verify every piece that ships. The claim sounds overclaimed the moment you say it, which is why I don't say it without the receipts in the same breath. Here's what it actually takes, with the numbers and the gates that make the difference between a claim and marketing copy. ## The layer thesis, with verification Every computing layer—machine code, assembly, C, Python—has been a conversion step that moves something machine-readable closer to plain human language. Agentic coding is the next layer in that sequence, the first one that runs directly in my native language instead of requiring translation into a programming syntax. That's the thesis. Here's the verification: I'm building a game in Unreal Engine C++. On 2026-09-20, I measured the project's git history against the Claude Code transcripts from the window when most of the code was written. The two-week span from 2026-09-07 to 2026-09-20 holds about 75% of the production C++ and roughly 90% of the project's commits. In that window: 157 prompts, about 53,000 typed characters of direction from me, and the agent produced 81,707 lines of gameplay code plus 30,069 lines of automated tests to check its own output. The game also carries 104,912 lines of documentation across 381 files—1.28 lines of documentation per line of code. About 40% of that markdown exists for the agent to read itself back into context at the start of a session, not for a human maintainer. Documentation became source code. When the industry converged on orchestration as its own architectural layer—OpenAI on 11 March 2025, Google Cloud on 24 March, Google again on 9 April—I was building around the same insight in the same weeks. My initial LEGION attempts began in March 2025. Anthropic named it a "harness" on 26 November 2025; OpenAI called it "harness engineering" on 11 February 2026. I wasn't first and I didn't invent orchestration—AutoGen, LangGraph and SWE-agent all predate my work. But I was building the same architecture while the vocabulary was still forming. ## The accurate frame, every time The agent writes the code, tests and documentation. I direct, decide, purchase infrastructure and validate everything before it ships. Never "built entirely by AI." Here's what that looks like in practice: **[Sadyr](/builds/sadyr/)**: a revenue agent for company websites. Blueprint to production in twelve days. First commit 18 June 2026, live 30 June, 63 commits across eight working days. Day one was the blueprint, the scaffold and the first sprint backlog. Claude Code wrote the implementation—three apps, 17 packages, 2,816 automated tests. I set the backlog, reviewed every pull, decided what shipped and what got parked. **[Content Ops](/builds/content-ops/)**: a console for running a client's knowledge and content, with discovery notes, an editorial lifecycle, a content plan built from keyword data, and a drafting pipeline that writes only from approved sources. Currently at version 5.12, live in production. 839 TypeScript tests plus 57 Python tests passing at the last full run. It drafted 92 of 95 planned pages for Adroit's own website in two days of batch runs; 74 pages updated and 17 created, now live. **[LEGION](/builds/legion/)**: the system I run Adroit on. 64 capability packages across five folders, measured 2026-09-25. It deploys apps, checks production health, runs WordPress commands, writes product code and keeps its own records. The idea hasn't changed since March 2025; what was missing for most of a year was operator skill and model capability, and I could tell which was which because I kept building other things in between. ## Gates before anything ships Status words are separate claims, never upgraded. Built means it exists and passes tests. Live means it's serving real users. Demo means a working demonstration; nobody pays for it. Shipped means released. Sold means someone pays. Sadyr is live—the platform has run in production since 30 June 2026. It also runs two working demos: a plan explainer for an insurance provider and a rulebook assistant for a national amateur sports league's managers. Both are on the production API, one behind sign-in with real documents, the other on sample content. Status word: demo. It is not sold—nobody is paying for it yet. Every number carries its label: measured, recorded but not re-run, estimated, declared plan. Content Ops test counts come from the last full test run at commit f861f98. Sadyr's 2,816 tests are recorded from the repo's own architecture doc and not re-run for this piece. The game's prompt-to-code measurement was a one-time check against git blame coverage. Where I haven't measured something, I don't publish a number—Content Ops cost per page is on hold because there isn't enough measured history yet. ## What breaks, and how you catch it The first time Content Ops ran at real concurrency—rewriting Adroit's live website—it produced three production defects in one night. All three traced to the same habit in agent-written code: writing to a database by deleting the whole table and re-inserting every row. Harmless at one job at a time; colliding when two jobs run together. The runs table failed within seconds. Fixed that evening. The artifacts table carried the same whole-table-rewrite pattern—found through a postmortem export tool I'd built hours earlier that same night. It summarized 227 failure entries into one screen: 29 duplicate-key errors and 151 stopped projects. Fixed the same night. The third: the content-plan screen polled the jobs table separately for each of roughly 92 cards every 10 seconds. A later log upload showed 311 of 323 API errors were pool timeouts. Fixed with one batched request. The lesson: agent-written code can carry one bad habit across several unrelated tables, so finding it once doesn't mean it's gone. And build the diagnostic tool before the incident that needs it—the postmortem exporter paid for itself before midnight on the night it shipped. Sadyr's first live answer gate divided the retrieval confidence score by the number of words in the question. Against the mock adapter, which returned a raw word count, that math looked right and every test passed. With real embeddings, scores around 0.4 to 0.6 became 0.03 to 0.05—under the 0.62 threshold—and every multi-word question abstained. Found on the first live run; fixed the same day, 15 lines added, 6 removed. ## Governance that the tooling enforces LEGION runs Adroit's hosted systems—Content Ops, Sadyr and the company website—on four rules: - **Observe freely.** Reading logs, checking health, listing deployments: any time, no gate. - **Change only with a flag.** A deploy or a write to production needs the explicit flag the script demands (--yes, --confirm). - **Destructive is mine.** Delete, reset, rotate a secret, push a database to live: never run by an agent. It hands me the exact command instead. - **No standing autonomy.** Sessions run the backlog I set. LEGION documents and operationalizes strategy I've approved; it doesn't author strategy, and when direction is unclear it stops and asks. On 2026-09-21, a LEGION session needed both hosted operator consoles and found them signed out. It did not attempt to sign in—it works inside a browser tab I've already authenticated. It finished every other item on the backlog and handed me one line: log in here. The lesson I kept: a rule an agent has to remember is a suggestion. A rule the tooling checks before execution is a boundary. I tried enforcing another rule the same way. My own instructions ban shell heredocs because they had repeatedly mangled scripts. In one session, the agent used a heredoc three separate times anyway, apologizing each time. Awareness didn't change the behavior, so I had the agent write a 40-line pre-execution hook wired as a global check on the Bash tool. It denies any shell command containing a heredoc pattern before the command runs. The next deliberate heredoc attempt was refused before execution. ## Documentation drift, and the fix that still has limits Agents trust whatever the docs say, so a stale fact can make a long unattended run confidently wrong for hours. LEGION's fix keeps machine-derivable facts—versions, test counts, git state, whether a file exists—in one generated file, regenerated by a small deterministic script. Judgment stays in files only I edit. A second run of the sync script has to print "already in sync." The fix still has a limit: it only protects what it actually derives. On 2026-09-21, while cross-checking numbers for an unrelated batch, I found that the hand-typed source file the generated panel quotes from had drifted—it declared Sadyr at 1,175 tests when the deployed commit actually had 1,334. The generated panel's own inventory section doesn't track a Sadyr number at all, since Sadyr is an independent repo observed read-only, so the stale figure was sitting one level up in a hand-written source the generator trusts without re-verifying. I caught it by hand. ## The receipts Every claim above links to a build page with the full story, or to the [receipts](/receipts/) table where every number sits next to its source file, test run or git log, with the label that says whether it's measured, recorded or estimated. At the frontier isn't a boast when you can show the commit history, the test counts and the production status word for every piece you've shipped. That's the discipline: the claim and the proof in the same breath, every time.