How to govern AI-generated code without reading every line yourself

Gogol probably didn't realise he was describing the fundamental architectural flaw of the LLM era, but he nailed it.

In The Government Inspector, the chaos stems from a single character who is, as Gogol put it, ‘without a king in his head’. Khlestakov isn't a villain. He isn't even particularly clever. He's a high-velocity reactor - no internal state, no guiding logic, no plan. He reflects the expectations of whoever he's talking to. He ‘speaks and acts without any consideration’, spinning increasingly absurd hallucinations that the town's entire bureaucracy accepts as truth. By the time anyone thinks to verify his claims, the damage is done and he's in the next town.

It's the most accurate description of an unmanaged AI agent ever written, 190 years early.

The play works because it reveals a system failure, not a character failure. Khlestakov doesn't need to be malicious. He doesn't even need to be competent. The town has no apparatus for verification. Nobody checks credentials. Nobody cross-references his stories. Nobody stops the line to ask whether any of this is true. The bureaucrats are so accustomed to performing governance without actually practising it that a man with no substance at all passes through the entire system unchallenged.

Replace 'town' with 'codebase' and you have a precise description of what happens when you point an LLM at a repository and say 'go'.

My version of avoiding a Gogolian meltdown has been the close pairing approach - what I'd describe as twitchy, adversarial pair programming with continual micro-steers. I watch everything. Every line, every suggestion, every test. One lapse of concentration in the small hours, the agent slips an rm -rf past you, and you sail into a ravine. I'm still happy to call it vibe coding, but only in the sense that I'm in the back seat alternately giving directions and screaming as we accelerate towards a wall.

It works. In the way that manually deploying to production via SSH works: carefully, slowly, and only if nobody sneezes. The human plays king in the head to the agent here - the thing that keeps it anchored - and you accept that your attention is the bottleneck because the alternative is chaos.

This is fine for individual assistance. Copilot in your editor, a chat window for boilerplate, Claude writing your unit tests while you review them in real time. The blast radius is small because the human is always in the loop, always reading, always the final gate.

But assistance and delegation are fundamentally different problems.

I had a revelation building a library with ~200 functions. I expected it to be a schlep but Claude decided to surprise me with a new feature and fan out about 10 sub-agents. Coding machine went brrr and within minutes I had a full library passing first time. Once you experience that, something shifts in how you look at this. Because suddenly the volume is real - not ‘one day this will be possible’ but ‘this just happened on my machine in the time it took to make coffee’.

The problem is that the thing that kept me safe - my attention, my ability to read every line - doesn't scale to that. You can't closely pair with ten agents simultaneously. You can't be the king in the head of a hundred concurrent tickets. The approach that was responsible at pair-programming speed becomes performative at production-line speed. You're not actually reviewing anymore. You're just... watching it go past.

This is the same transition the industry went through with infrastructure. When deployments were weekly, a checklist and a careful engineer were sufficient. When deployments became daily, then hourly, the manual process didn't scale. The answer wasn't ‘be more careful’. The answer was to encode the carefulness into the system itself - CI/CD pipelines, infrastructure as code, automated testing, blue/green deployment. The process became the source of truth and safety, not the person.

AI-generated code is at that same inflection point. The agents are fast enough to be useful. The question is whether we can govern them without strangling them.

This was buzzing in my mind when Steve Yegge released Gas Town. Agents roaming free as polecats, working a backlog autonomously. I set it to work on a big stack of tasks and watched from afar as the citizens of Gas Town did their thing. It was genuinely fun - like having a coder ant farm.

But with my real project code, the tickets came in 0-60% done, like your worst outsourcing nightmare. And often it felt like I was lobbing a message in a bottle combined with peering through a keyhole trying to figure out what was going on.

Steve recently looked at the current agentic frameworks and had a key insight that most were looking at it in an agent-centric way whereas he had put the unit of work, the ticket, at the centre. So I’ve taken that and run with it a bit. And I've approached it generally as a systems problem. If the fundamental issue is that agents are reactive and unanchored - Khlestakov in a terminal - the solution isn't better agents. It's a better harness. The agent needs a king in its head. Not a human watching every keystroke - a manifest. Khlestakov's power comes from ambiguity. Remove the ambiguity and the agent’s hallucinations have nowhere to land.

This is where ting comes in. What I ended up building is a system where the unit of work - the ticket - carries everything the agent needs to stay on the rails and everything a reviewer needs to verify that it did. Now this is not a Jira ticket nor a paragraph of intent. It is a self-contained execution manifest. Like we might have infrastructure-as-code where you can automatically spin up and tear down full environments from a manifest, tickets in ting are similarly executable. They create a full dev and testing environment, apply gates and process to dev, and merge finished code - in a single unified process. I have been thinking of them as nano-factories for code. And the great thing is that because they are JSON manifests, they are versionable. In fact when we run commit, it also commits the current state of that ticket so that you can see the exact conditions that created that code.

Everything is recorded. Every iteration, every review, every test run, every piece of feedback - captured and exportable. The ticket isn't just a unit of work; it's an audit trail. When someone asks 'how was this code generated, and how do we know it's correct?' the answer isn't 'an AI wrote it and a human glanced at it'. The answer is a complete, reproducible record of specification, generation, testing, review, and iteration. Portable, replayable, and auditable. This matters more than people think right now. It's going to matter a lot more soon.

Individually, these are sensible engineering practices. Together, they compose into something more interesting: a production line for code.

Each ticket moves through a pipeline - spec, develop, test, review, iterate, commit - with quality gates at every stage. Multiple tickets run concurrently through the system. You can see the state of each one. You can pause any ticket mid-flight, give the agent feedback, and resume. You can stop the entire line if something looks wrong.

With AI-generated code right now, we don't have the apparatus. We have agents that can write code at extraordinary speed, and we're governing them with the equivalent of a nervous bureaucrat squinting at a letter of introduction.

So that's what I've been building. You can read about it at https://ting.pm

It's invite only for now but if you're running an engineering team and want to put real work through it, I'd like to hear from you.