From code to production | Blog

~/blog/guide/delivery

From code to production

The agent writes it in an afternoon. Getting it into production still takes a week.

What this guide covers

Writing code got cheap. Reviewing it, testing it, deploying it, keeping it alive and explaining at three in the morning what went wrong all still cost what they cost last year, except a lot more of it arrives now. This cluster is about that second half.

It is also the half I run into hardest myself. I administer my own servers and run my own deploys, so a faster agent reaches me as more review, more deploys and more things to keep alive.

The bottleneck moved downstream

Your 10x developer is gated by a 0.1x pipeline is the piece this guide is built around. Code got cheap, the pipeline that turns code into value never grew with it, so the bottleneck moved on to review, deployment and decision-making. Adding a second agent just pushes that problem into the queue in front of it.

That is why this cluster sits alongside the other four. The rest of the blog covers producing code and judging it. This covers everything that still has to happen before anyone gets any use out of it.

When the answer is more checking

Review is the first thing that broke under the new volume, and the damage is measured. The AI code review bottleneck works through Faros AI's telemetry on 22,000 developers, corrects a figure this site itself had wrong, and lands on the finding the headline buried: reviewers are no longer checking code so much as finishing it.

The tempting fix for that load is one more automated check. The bureaucracy of bots shows where that ends up: a bot reviewing a bot, with nobody at either end who can explain it once it goes wrong. Checking that nobody can account for is not review, it is a rubber stamp.

What you are actually looking for in that review is in the checklist for AI-generated pull requests. The rule underneath it stays never ship code you do not understand, and it weighs more the more of it arrives.

Where it runs

Deploying is half of it. After that it has to keep running, somewhere you understand. Take back control of your data is about where your stack really sits and what that means the moment the rules or the vendor change. More control over your server is the practical side, with Fail2Ban, ModSecurity and AIDE on a machine I administer myself.

Both also belong in the MCP and security guide. Where something runs and who can reach it are the same question, asked twice.

What is still missing here

This is the youngest of the five guides and it shows. I know what is still absent: what a pipeline costs when an agent pushes ten times a day, how you deploy what nobody read, what on-call looks like for code a model wrote, and why a migration is the one file where rollback is a promise the database never made.

Below are three starting points, then everything in this cluster, newest first.