Agentic Engineering Is Building the Check

I wrote about four systems this month. A delivery pipeline, a search index, a cluster, and a backend moved from Java to TypeScript. Different problems, different stacks, nothing in common on the surface.

By the fourth one I noticed I kept writing the same paragraph.

Every one of them turned on a check. Not on the model, not on the prompt, not on the framework. On whether something at the end could tell finished from finished-looking, without me in the room.

The word is not the point

Agentic engineering, agent-native, whatever it settles on. I am not going to argue about the name, and I am not going to define it. Name a thing once and then go after the substance.

The substance is that the expensive part of the work moved. It used to be producing the thing. Producing the thing is now cheap and getting cheaper, and what is left is deciding what should exist, bounding what may be attempted, and proving that what came back is real.

Two of those three I have written about. The third is the one nobody wants to do.

A check a person performs is not a check

This is where it gets uncomfortable, because the obvious answer is to read the output.

I do read it. That is not a check. A check that a tired person performs at midnight is not a check, it is a hope with a timestamp. It works on the days it works, and the day it fails is the day it was needed.

An agent produces more output than a person can read with attention. That is the entire reason to use one. So any verification that scales with output volume and depends on a human staying sharp is already broken, and it breaks quietly, at exactly the moment the volume gets interesting.

What makes a check real

Four properties, and I have watched all four fail.

It runs without me. A green suite. A policy gate. A score threshold. If the last step is a person saying yes, the person is the bottleneck and the guarantee is only as good as their afternoon.

It fails specifically. Not "the port is wrong" but the file, the line, the expected value. In that backend port every behavioural decision in the research had to cite the exact lines in the Java it matched, or deliberately broke from. Not a paraphrase. Line numbers. That is what turns "did we get this right" from a feeling into something with an answer.

It is cheap enough to run every time. A rendered diff, a dry run, a lint pass. An expensive check gets run at the end, and a check at the end is a check you will be tempted to skip when you are close.

It cannot be satisfied by looking finished. This is the hard one. An agent optimises for the check, so a weak check teaches it to produce work that passes rather than work that is correct. The check is not a measurement sitting outside the system. It is part of the system, and the agent will find its edges.

Which is why this ends up being infrastructure

A check that runs without me has to run somewhere.

That sounds trivial until you try it. A test suite is only a check if it is fast, deterministic and trustworthy. A suite that fails randomly teaches everyone to re-run it, and a suite people re-run is not a gate, it is a coin they flip until it lands right. Getting from "we have tests" to "a red suite means something is broken" is most of the work, and it is work on the suite, not on the feature.

Then the suite needs somewhere to run that resembles production. A real database with real data shaped like the real thing. The credentials. The services it talks to. Get that wrong and the check passes on a machine that does not exist, which is the most expensive green tick there is.

So it lands on the environment. One per project, carrying the exact runtime, database, credentials and test data that project needs, and nothing shared between them. Ten agents working at once need ten of those, and they need them to come up in seconds and be thrown away without ceremony.

That is not a testing problem any more. That is infrastructure, and it is why the question "how do we use agents" turns into a platform question within about a week. The bottleneck is not the model. It is how many trustworthy environments you can stand up, and how quickly a green result in one of them can be believed.

The check you cannot write

Some things have no automatic check. Whether this is the right feature. Whether the tone is right. Whether a migration that passes every test is still a bad idea.

That is where a person belongs, and only there. The mistake is not putting humans in the loop. It is putting them everywhere in the loop, which spreads attention so thin that the places that needed it get the same glance as the places that did not.

Every review slot you spend on something a machine could have checked is a slot not spent on something no machine can.

What it costs

Writing the check is slower than writing the thing. That is a real trade and on a small job it is a bad one. For something you run once and throw away, build it and look at it.

The worse cost is subtler. A check that exists but is weak is more dangerous than no check, because it licenses you to stop reading. No check at all keeps you nervous, and nervous is a kind of safety. A green tick you have not earned is the most expensive thing on this list.

What is actually new

None of the skills. Specification, boundaries, test design, failure paths, verification. This is the oldest part of the discipline and it has been the least fashionable part of it for twenty years.

What is new is the ratio. Producing the thing used to be most of the work and checking it was the tax you paid at the end. Now producing it is the cheap half and the checking is the job.

Build the check first. If you cannot describe how you would know it worked, you are not ready to ask for it, and no agent is going to tell you that.