The Agent-Era Engineer: From Prompting to Software Factories

Do you read the diffs your agent writes?

I did. Every one of them, for about a year.

I do not type code any more, and if you are reading this, neither do you. The agent writes it, runs the tests and opens the PR. For a while that felt like the whole shift. Then I noticed where my day had gone. I was reading. Four hundred lines here, nine hundred there, all afternoon, at a pace the agents had passed months earlier.

Two things that year taught me:

1. Generation is solved. Not perfect, but solved in the way that matters: the code arrives faster than anyone can check it.
2. So the bottleneck moved. It is no longer writing. It is knowing that what came back is right. Right now, that bottleneck is a person, and the person is you.

Once you see that, every other question about agentic coding gets easier. You stop asking how to get more out of the model. You start asking what has to be true before you trust its output without opening the diff.

Most engineers put their trust in one of two wrong places

The first is the agent’s word. It says “done, all tests pass,” and the PR merges. Sometimes the agent wrote the tests to pass. Sometimes they pass and the feature does not work in a browser, because nothing in the loop ever opened one.

The second is your own eyes. Nothing else in the pipeline has earned your trust, so you read everything. That works until the agents outrun you, and then it fails in the worst way: you skim, you approve, and you feel like you checked.

Both are the same mistake. The check lives in a person or in the author. It needs to live somewhere else.

First: decide what has to be true

Before any code exists, a change already has a definition of correct. It is in your head. The work is getting it out.

It starts at intake. Tasks pour in, and most of them can go straight to an agent. A person looks only at the ones that need a judgment call. That decision, made once and up front, is the first verifier you build. It continues through alignment, where an interview and multiple proposals surface what you wanted before an agent commits to a guess. It lands in the spec, where the question is not whether the spec is good but which verifier will say the work is done. Some tasks do not need a spec at all. There is a lesson on that too.

Second: build the check, and put it inside the loop

An instruction is hope. You wrote the rule in CLAUDE.md, the agent ignored it on Thursday, and you wrote it again in capitals. A verifier does not need to be remembered. It runs, it fails, the agent goes again. Prefer a verifier over an instruction, every time you can.

A real verifier touches reality: the deployed app, the real database shape, a browser that clicks through the flow, a Slack workspace that receives the message, a voice call that connects. A mock will pass anything. Building the environment where an agent can be checked against the real thing is most of the engineering in this course, and almost nobody teaches it.

Then the check goes inside the loop, not after it. A builder and a verifier, so the model grading the work is not the model that did it. Back pressure, so a failing check stops the agent and not you. Adversarial review from a different model with a reason to attack. The loop runs until it converges. You do not need the first draft to be right. You need a signal you trust to say when to stop.

Now: let it merge

Once the checks exist, the merge gate becomes a policy instead of a person. A copy fix with a passing run merges itself. A schema migration gets a verification environment, a test matrix and a hold for you. Verification scales with blast radius, and the skill is deciding that in advance so the agent knows too.

Your job changes shape. You stop reading diffs. You read outcomes, and you spend your attention on the changes that can actually hurt.

What I have built this way

I run 21 Dreams, a holding company that builds, scales and exits software products. AgentStack and Impello are two of the current ones, and they are the backbone of hundreds of companies. Every one of them is built and maintained the way this course teaches, and I have put 4,500+ hours into Claude Code and Codex doing it. Nobody at 21 Dreams types features by hand. Every change goes through agents, through the checks above, and through a merge gate that decides how much of it I need to see.

That is not a claim that it always goes smoothly. Verifiers go stale as a codebase moves under them. A reviewer model will agree with whatever it is shown unless you build it not to. Those failures are in the course, with lesson names like Verifiers Go Stale and Is Your Reviewer Any Good?, because you will meet them too.

Before and after

If you already ship with an agent most weeks and want the reasoning, not a list of settings, this cohort is for you.