The pipeline that writes and lands most of this code

Most of the code across these six products was written by AI agents. That claim is easy to make and usually means someone autocompleted a function. Here it means specifications go in, pull requests come out, and continuous integration decides whether they land.

What makes it survivable is not the model quality. It is a small number of gates, each of which exists because something got through.

Specification, plan, execute

Work moves through three artifacts before any code exists.

A specification says what is being built and, more usefully, what is deliberately not being built and which decisions were already taken. The out-of-scope list matters more than the scope list, because an agent with an ambiguous boundary will expand into it confidently.

A plan breaks the specification into tasks with exact file paths, the interfaces each task produces, and the test that proves it. Vagueness here is where agent work fails: "add appropriate error handling" is not an instruction, it is a wish.

Execution runs task by task, with a fresh context per task and a review between them.

The reason to separate these is that mistakes get cheaper the earlier they surface. A wrong assumption caught in the specification costs a paragraph. The same assumption caught in review costs a day.

The rule that matters most

Everything above is ordinary process. This is the part that was learned expensively:

A green test suite is not evidence.

Four specific failures taught us that, and every one of them passed continuous integration at the time.

Assertions that cannot fail. A test asserting a result equals an empty list passes whether the function works or returns nothing because it crashed internally and swallowed the exception. It is green forever and tests nothing.

Hand-authored fixtures. A test where both the input and the expected output were written by the same agent checks that the agent is self-consistent. It does not check that the code matches reality. Fixtures for anything crossing a process or network boundary have to be captured from the real system.

Ambient credentials. A suite passed on the workstation and failed everywhere else because a test was making live calls using an API key that happened to be in the environment. It was not testing the code path, it was testing that the developer was logged in.

Absent evidence read as evidence of absence. An agent that cannot access something reports "nothing found," which reads identically to "there is nothing there." A search that silently returned zero results because the path was wrong once produced a confident all-clear on a question nobody had actually asked.

That last one generalises beyond testing, and it is the one to internalise: "I could not look" and "there is nothing to see" must never render as the same sentence.

Gates that are executable, not written

The pattern we keep landing on is turning a rule into a test rather than documenting it.

This site has one. Posts here draw on internal engineering notes, and those notes are dense with ports, private network addresses and absolute file paths. The rule is that none of that gets published. That rule could live in a contributing guide, where a future agent would not read it.

Instead it is a test. It walks every published post and fails the build on a port number, a private address, or an absolute path. The rule cannot be forgotten because forgetting it breaks the build.

A written rule is a hope. A test is a gate. Where you can convert one into the other, do.

What humans still decide

Anything that spends money, sends mail, publishes in a person's name, or changes a client's live configuration. Not because agents cannot do those things: because the cost of being wrong is borne by someone who did not consent to the experiment.