I don't write much code anymore. Well, almost none.

I've been building software for 25 years. Payment systems, document pipelines, bank software, high-load transactional systems, the kind of code that breaks badly when you get it wrong. So when I say the human is no longer the one writing the code, I'm not guessing. I've watched my own job change while I was doing it.

AI agents do that now. What's left for me is different work. I decide what to build, I set the rules, I check the result, and I own what ships. Less typing. More judging. More creative and productive.

Many people still insist that AI writes bad code and makes mistakes. Sure. So do humans. That is exactly why I don't trust a single agent. I make two of them argue.

I run a consensus environment: Claude Code builds, Codex reviews, I judge.

Two different models on purpose: each one is blind in its own way, and they rarely fail in the same direction. Claude is strong at moving through the codebase and turning the plan into code. Codex is the one that comes in cold, reads the plan, looks at the diff, and challenges what Claude produced. The point is not that either agent is always right. The point is that they are not wrong in the same way.

And right now this combination works really well. It produces working, clean, reliable code, as good as what a strong developer would write, sometimes better, and obviously far faster than a human could.

Using AI agents is not vibe coding. It's a skill.

You build it, you sharpen it, and you keep it current as the tools keep changing under you. In that sense it is no different from any other skill in this job: learning a language, learning patterns, learning architecture. Nobody is good at it by accident, and nobody stays good at it without practice.

AI agents are already smart enough that you can hand them a task and say "go build it." Try that on anything complex and the result will disappoint you. Software development is a branching problem. There are many ways to reach the same goal, and one wrong turn early sends everything after it in the wrong direction, no matter how cleanly that branch is written.

Spec first, code later. The industry calls it spec-driven development.

So for complex work, and for any change to production code, I never start with code. I start with a plan, a spec. Depending on the task, getting that plan right can take dozens of iterations, all of them done with the agents. Only when the plan holds do I let Claude and Codex write and review the code against it.

Yes, it is slower at the start. But that upfront time is what makes everything after it faster. You pay early instead of paying double later.

And this is not just my personal habit. The whole industry is moving the same way: GitHub's Spec Kit, AWS's Kiro, tools that treat the spec as the source of truth and make the agents build against it. For a quick prototype or a throwaway script I skip all of it. The plan only earns its cost when a wrong call is expensive.

From there the spec and the code go through the same back and forth between Claude Code and Codex, and I sign off at the end. The full loop:

Explore → Draft spec → Claude + Codex review → Fix the spec → Implement → Claude + Codex review → Tests → Human validation → Commit

Don't waste time crafting the perfect prompt. Your spec matters more.

The prompts themselves are nothing clever. These are the kind I actually use:

• Implement the plan.
• Review the changes against the spec.
• Review this plan against the codebase as an independent reviewer.
• Critically validate this review, and apply only the points that make sense.

It surprises people, but the style, the phrasing, even the typos make no real difference. What matters is the spec behind the prompt and the judgment reading the output. A clever prompt on top of a weak spec still gives you weak code.

The useful findings are almost never about syntax. They are things like: this quietly breaks another input type, this ignores what happens on retry, this hardcodes a value the spec says must be configurable, this handles the new data but not the old data. Real problems. The kind that costs you a weekend later.

Reviewer feedback is not the final word. Claude applies only what holds up, never the whole list. Accepting every suggestion is just a different way of not thinking.

The job moves up, not away.

None of this is magic, and most of it can be automated. I'm sure it will be. The next step is obvious: multi-agent development environments where the agents plan, build, review, and argue with each other on their own.

And the last step is always me. The agents build, they argue, they fix. But I'm the one who decides what's true and puts my name on it. If it breaks at 3am, no agent gets the call. I do.

So here is my honest question. If you're not the one writing most of the code anymore, what do you call your job now? And if you still write all of it by hand, how long do you think that lasts?