An agent writes most of the code in Giant Context, and it deploys to production where real customers depend on it. That only works if I can trust code I did not type, and no single check is enough to earn it. The trust comes from eleven checks stacked one behind another.

The frame is James Reason's Swiss cheese model, drawn up for accident analysis in aviation and medicine. Every defence a system has contains holes, and the holes move, because the system keeps changing. A hazard gets through when a hole in the first defence lines up with a hole in the second, and a hole in every one after it. Nothing in the model asks a defence to be perfect. It asks how many have to be crossed at once, because each one multiplies against the others and the probability of a failure crossing all of them falls to near zero.

The next two layers assume something did get written and try to catch what is wrong or missing.

Slice four, tests, forced and generated. No API route can exist until it has a passing test. The generation step supplies the scaffolding, the mocks and the factories, so what the agent writes is the assertion rather than the apparatus around it. The hole is that the assertion is still the agent's, and an assertion written from the same misunderstanding as the code will agree with it.

Slice five, checks for what a unit test cannot see. Some obligations are not attached to any one route. Every string a customer sees has to exist in three languages, and a feature can be complete and correct with its French and Spanish entries missing, because translating strings was a rule about the task rather than the task. No route test fails, because no route is wrong. A separate completeness check reads the locale files and goes red.

Slices one to four all examine the code that was written. This one asks whether the work is finished.

Now the code is written, generated, and checked locally. Two layers stand between it and production.

Slice six, a pipeline that gates in more than one place. Continuous integration runs the full suite and the checks on every push to the shared branch, and runs them again at deploy.

The hole is that the pipeline runs only the checks that exist, so every gap in slices four and five is a gap here too. It adds no new judgement. It adds repetition, which is worth having, because a bug now has to survive the same check twice and survive it in a second environment.

Slice seven, deploy itself. The build and deploy step occasionally fails, and when it does it is almost always a dependency or a lockfile rather than a logic error that reached this far.

No honest model stops at the release, because the premise is that something can get through. The last four layers watch what happens once the code is live.

Slice eight, the check at deploy. The moment a service deploys, a health job polls it until the exact version that just shipped is the version answering, per service across the fleet. Two failures die here. A revision that cannot come up healthy never takes traffic, so a bad deploy leaves production on the last good version. And a deploy that reports success while the old revision is still serving fails the version match. The hole is that the check asks the service whether it is up. It does not ask it for a page.

Slice nine, the continuous check. The deploy check runs once. This one runs on a short interval for as long as the service exists, recording whether it answered and how quickly. It catches what was fine at deploy and broke later, a dependency that went down, a service that slowed under load, a certificate that lapsed. The public status page is where that history is published. The hole is slice eight's hole on a timer. It polls the same health endpoint, so it knows the service is up and knows nothing about what the service returns to a reader.

Slice ten, production errors go to Brain. Anything that throws in production is captured and sent to Brain, the platform's own error-triage service, which investigates it and returns a root cause and a fix for me to confirm. Some failures reach production. Brain is what turns one of them into a fixed bug rather than a standing one.

Slice eleven, the fix arrives where I already work. Brain runs an MCP server, so the error, the diagnosis and the proposed fix land on my command line inside the tool I am already in. An error in production is only cheap if the distance between finding it and shipping the fix is short.