How I learned to ship production apps in under 72 hours, and how you can too.

Not prototypes. Not demos. Not vibe-coded throwaways. Real applications: Postgres backends, auth flows, payment integration, accessibility audits, end-to-end tests, deploy pipelines, post-deploy health checks, the whole stack. From empty directory to live URL, in three days.

Most people assume the unlock is the model. It is not. The models have been good enough for a year. The unlock is the system around the model.

The wrong mental model (and the right one)

The dominant framing of AI coding treats the model like a vending machine: insert prompt, receive output, evaluate, repeat. That works for snippets. Production software is not a snippet problem. It is a thousand small judgment calls about scope, security, testing, error handling, deployment, and the parts of the codebase no one has looked at yet.

A coding agent makes those judgment calls at superhuman speed. When the calls are right, you ship in 72 hours. When even five percent of them are wrong, you ship an incident in 72 hours.

The difference between those two outcomes is not the prompt. It is whether the agent is operating inside a system that catches the wrong calls before they land.

Here is the right mental model: a coding agent is a junior engineer with infinite patience and zero memory. Not magic. Not autocomplete. A junior engineer who never gets tired, never pushes back on a bad idea, and forgets everything you taught them the moment the conversation ends.

A real junior engineer ships production code every day. They do it by working inside a system: code review, CI, lint rules, type checks, test suites, deploy gates, incident postmortems that turn into runbooks, and a senior engineer who notices when the same mistake happens twice and writes it down somewhere the team will read.

That system is what makes a junior engineer trustworthy. The same system, adapted, is what makes a coding agent trustworthy. The default workflow right now is to give the agent the IDE and skip the system. I did this too, for longer than I would like to admit.

Three layers, one loop

My system has exactly three layers, and they fit together as a loop.

Rules are the file the agent reads at the start of every session. Mine is around 6,000 tokens. It contains the things I have learned to never let the agent do: ship without a failing-test-first reproduction, echo a secret into a commit message, lower a security setting to make a slow test pass, claim a deploy is done because git push returned zero. Each rule is short. Each rule has a why. Each rule has a date it was last validated. The file is bounded by a token budget. New rules pay for themselves by deleting equal weight.

Hooks are scripts wired into the agent's tool layer. They run before the agent's actions land and they can refuse the action. A hook is the only layer of the system the agent cannot rationalize past. If the rule says secrets never appear on a command line (because argv leaks to four surfaces simultaneously), the hook is what catches the agent when it tries. Rules are advice. Hooks are walls.

Memories are per-project notes that persist across sessions. They are what gives the agent context I would otherwise have to re-explain every conversation. When something goes wrong, the lesson goes into a memory file. When the same lesson recurs across multiple projects, it climbs into the rules file. When a rule starts firing reliably, it climbs into a hook. The promotion path is what turns one bad day into a permanent improvement instead of a recurring tax.

The retirement path matters as much as the promotion path. A rule that has not fired in 90 days demotes back down. A hook that has not blocked anything in 90 days is reconsidered. The system trims itself. I learned this the hard way. My first rules file was over 800 lines and the agent started ignoring half of it, which is exactly what a human would do with an 800-line document they are expected to read before every task. Now the file has a token budget, and trimming is part of the process.

What it looks like when the system is missing

Early in this workflow, before the hooks existed, I was building a deploy pipeline. The agent needed a database URL to run migrations. It had access to the secret. It constructed the migration command by interpolating the connection string directly into the shell command.

The migration ran. The deploy succeeded. I did not catch it during review because everything looked correct from the output. Three hours later, while debugging an unrelated CI issue, I found the full Postgres connection string sitting in plaintext in the CI runner's process log, accessible to anyone with access to the build.

Nothing bad happened. But the window was open for three hours before I noticed. The agent had done exactly what I asked. It had also done the one thing I would never have done manually: passed a secret as a positional argument to a shell command.

That failure became a memory. The memory became a rule. The rule became a hook that now checks every shell command the agent constructs for anything that looks like a secret. The hook has fired eleven times since I wrote it. Eleven incidents I did not have to catch with my eyes.

What the loop unlocks

I stop spending time on the tax of AI coding. The tax is the moments where the agent does something almost right and a human has to notice, correct, and re-prompt. Across a 72-hour build, that tax compounds into days. A well-governed agent pays the tax exactly once per failure mode, because the second occurrence is caught by the hook that the first occurrence taught me to write.

I stop reviewing the agent's work the way I would review a stranger's code. I review it the way I review the work of someone whose blind spots are already mapped, whose recurring mistakes are already enforced against, and whose successes are already promoted into the standard. The review is faster because most of what would have been review is now mechanical.

I stop being the bottleneck. The hard thing about AI-assisted development is not generating code. It is the human attention required to verify the code is right. The system moves verification from my head into bash and grep. Verification at machine speed is what makes 72 hours possible.

The system is not bulletproof. I still catch things manually that no hook anticipated. But each of those catches feeds back into the loop, and over time the surface area of what I have to watch for with my own eyes keeps shrinking.

The thesis

The future of AI-assisted development is not better models. The models we have today are already capable of shipping production software in three days. The reason that is not the default experience is that the default workflow does not include a system. Most of us, myself included at first, are prompt-engineering in the IDE and accepting whatever drifts back.

The unlock is treating the agent like a member of an engineering team that needs the same things every junior engineer needs: a written standard, mechanical enforcement, and a memory of what went wrong last time. Build the system and the agent becomes a senior engineer's force multiplier. Skip the system and the agent becomes a fast path to incidents you would never have shipped on your own.

I ship in 72 hours because the system is built. The system took longer than 72 hours to build the first time. Every project after the first has been compounding interest on the same investment.