The Monkey Work of Coding Is Over

Coding’s monkey work is over, and I think a large part of our industry is still defending it. I see this legacy thinking in real projects and in LinkedIn posts, and I believe it comes from underestimating what AI agents can do. Too much of it still assumes that software quality depends on a person checking how every piece of code is arranged.

By monkey work I mean repetitive labor: turning a known decision into source, following the house style, checking names and layout, verifying that the rules were obeyed. The phrase is about the work and says nothing about the worth of the people doing it. Much of my own professional strength came from structuring code so that humans could read, understand and maintain it.

I carried that strength into my first agent-assisted projects. I wrote detailed skills that told the agents to reproduce structures I understood, and then I checked by hand whether they had followed them. Today I question how much of that instruction was necessary engineering and how much was inherited habit. I don’t have a clean answer yet, but asking changed how I work.

Over the last months I kept observing the agents and experimenting with delegated roles: implementation, code review and audit, specification checking, UI and UX. Eventually I stopped routinely reading their code. What I had been reading was very well written. That is my judgment, with no defect rate behind it, and I’m not claiming generated code is always right. But when nearly everything looks good, looking good becomes weak evidence.

The Pleasure of Arranging Code

My LinkedIn feed is still full of sermons about source code. Do this, never do that. Discussions about syntax preferences, the optimal length of methods, and the best folder structure. Let’s call much of it what it is: self-gratification. It feels like craft and earns applause from people who share the taste, while less and less of it decides whether the software does the right thing.

The rules had a purpose. Many so-called architectures are, in my view, code organization patterns that help a person find the right place and change it without breaking its neighbor. We invested a lot of time and money in that, and while people did the work by hand, it paid.

Now applying a convention is work you can hand to an agent, and so is moving the code to a different one. Rust’s formatter and linter had already taken the most mechanical part. So you get a senior engineer defending a folder structure that a machine can rewrite, while nobody has written down what the system does when a dependency fails halfway through. The most experienced attention on the team goes to what has become cheapest to change. Ugh, it’s over!

What’s over is the ritual. Other decisions carry the name architecture and have little to do with navigation: who owns this state, what happens when two writers arrive at once, where the security boundary sits. You can rename every module without changing one of those answers, and a system with beautiful folders can still lose data. A leaked credential is a code detail too, so it belongs in a stated constraint with a check behind it.

What Agentic Engineering Actually Is

Agentic engineering is what replaces the ritual, and it asks more of you than prompting does. It starts with what the system must observably do and which qualities it must keep: what must never happen, which failures are acceptable, what limits it has to fit. Agents can help draft and challenge this, but someone still owns what the system should do.

Modular boundaries stay because they limit how far a change reaches and give a check somewhere to attach. Inside them the work splits into roles: one agent implements, another reviews and audits, another compares the result with the specification, another looks after UI and UX. Expected outcomes stay apart from the implementation. Checks run, the observed result counts instead of an agent’s report, and failures go back for revision.

What changes for the person is the question. I used to ask whether the code looked the way I would have written it. Now I ask whether we have said precisely enough what correct means, and what evidence I would accept. That is still directing and challenging the work. You state the behavior and qualities you expect and what you will accept, then hold the result against them. When it misses because the intent was unclear, you revise the intent rather than police every implementation choice. When the system does the wrong thing, “the review agent approved it” is no answer.

This is the line against what people call vibe coding: prompt, look, tweak until it seems to work. For a throwaway prototype that can be a fine deal. For a system people depend on, the definition of “works” lives in the head of whoever watches the demo and drifts toward whatever the agent produced. Engineering fixes the target first and lets the evidence say whether you hit it.

Fixtures are one way I do that. A fixture fixes a small world of input, requests against it and the answers they must produce, reasoned from the requirement in advance. In a simplified search case, two places share a name, one near and one far: a position alone should favor the near one and return both, a radius should drop the far one. A harness runs the actual core against those answers, and the implementation agent isn’t allowed to move them just to get a pass. So I can check essential behavior before a database, a service or deployment exists. That covers the stated cases; infrastructure needs its own checks.

When Everyone Agrees on the Wrong Thing

Agents can share a mistake. If nobody decided what a requirement means, one agent may pick a reading, write a test expecting it, and get a green run a second model may confirm. A sharp reviewer, human or agent, may spot the gap, but reading every diff gives no guarantee of discovering a rule nobody wrote down. Expected outcomes need a source of their own, derived from the requirement. Anthropic’s guide to agent evals similarly stresses explicit success criteria and outcome checks. It’s vendor guidance, and it warns that automated checks can miss nuance.

Risk decides how far this goes. Payments, security boundaries and irreversible data changes can justify a person reading a critical path with a specific question in mind.

My experience doesn’t mean AI makes every developer faster. In METR’s early 2025 study, the experienced open-source developers it studied took longer with AI tools. My argument is a different one, and METR doesn’t prove it: once agents write the code, human attention should move from code details toward specifying what the system must do and verifying that it does.

Conclusion

My forecast is that routine reading of generated source will come to feel the way formatting by hand feels now.

Take one rule from your agent instructions and ask what behavior it protects. If you can name it, write the check. If you can’t, you may be looking at what I keep questioning in my own skills: an inherited habit, faithfully passed on to a machine.

Cheers!