My Take on Coding With AI Agents After a Full Year

For about a year now I've been running most of my code through AI agents. Not "I asked a chatbot to write a function." I mean a fleet of them, working off a shared task queue, building features, editing manuscripts, running deploys, while I do something else in another room.

It works better than I expected and worse than the hype promised, and the gap between those two things is the whole story. So here's the honest report from a year of letting machines run my workflow.

What I'm actually running

Quick context, so this isn't abstract. The thing I work on is a sprawling system: a Java game engine that powers a handful of Alexa games, a stack of small services around it, a dashboard, and a database with more schemas than I'd like to admit. It's a real codebase with real users, not a weekend toy.

The agents don't just autocomplete inside my editor. They pick up tasks, search the code, make changes across files, write tests, and hand the work back. Several can run at once. There's a queue they pull from and a dashboard where I watch them. When it's humming, I can hand off a stack of grunt work and check back later like I delegated to a small team that never sleeps and never complains.

That's the dream version. Let me tell you where it's true and where it falls down.

What they're genuinely good at

The boring stuff. And I mean that as the highest praise.

Search is the first thing that changed my life. "Where does this currency get spent? Who calls this method? What breaks if I rename this?" An agent that can actually index the codebase answers those in seconds, with file and line numbers, instead of me grepping around for twenty minutes building a mental map I'll forget by lunch. Just navigating a large unfamiliar codebase got dramatically faster.

Boilerplate is the second. The fortieth variation of a data-access class, the test scaffolding, the wiring you've written a hundred times. Agents are great at the stuff that's tedious precisely because it's pattern-following, and pattern-following is the one thing they do effortlessly.

Parallel grunt work is the third, and it's the one that surprised me. When I've got a dozen near-identical changes to make across a dozen files — the same migration applied everywhere, the same renamed thing — I can fan that out and have it done in the time it'd take me to do two by hand. The work isn't hard. It's just a lot of it, and "a lot of it" is exactly what a fleet eats for breakfast.

Tests, when you point them at it specifically. Ask an agent to write a regression test that catches a bug you just found, and it'll usually nail it. That turned out to matter more than I realized, for reasons I'll get to.

What they're genuinely bad at

Taste. An agent has no taste. It can write a function that works and is also ugly, badly named, and structured in a way that'll be a nightmare in six months, and it will report that as a complete success because it passed the tests. It chases "did the thing run," not "is this the right thing." That second judgment is still entirely mine.

Knowing when it's wrong is the bigger one. This is the failure mode that scared me into building guardrails. An AI agent will be confidently, fluently wrong. It'll produce a beautiful explanation of a fix that doesn't fix anything, and it'll believe its own explanation. It has no nagging sense of doubt, no "hmm, that's weird, let me double-check." It just proceeds. A junior developer who's unsure will at least sound unsure. An agent sounds equally certain whether it's right or off a cliff.

And the worst version of that is self-validation. Ask an agent if its own work is correct and it'll grade its own homework an A. Of course it will. It already decided the work was good when it produced it. Letting an agent both do a thing and confirm the thing is done is how you ship a confident, fluent disaster.

The guardrails are the actual product

Here's the lesson that took me a year to fully absorb. The agents aren't the hard part. The system around them is the hard part, and it's where all the real engineering went.

Three guardrails do most of the work.

First, tests as a hard gate. Nothing the agents touch in the game logic ships without passing a regression suite, and every behavior fix has to come with a new test that would have caught the original bug. The agents are great at writing those tests, which is the happy irony — I use the thing they're good at to fence in the thing they're bad at. The suite doesn't trust the agent's opinion. It checks.

Second, and this is the big one: the agent that does the work is never the agent that approves it. Different agent, fresh eyes, no ego invested in the change. I learned this the hard way watching a model wave its own broken fix across the finish line. So now the deploy path simply won't let an agent self-validate and push to production. A human, or at minimum a separate independent check, stands between the work and the live server. Confirmation bias isn't a human flaw the machines escaped. They've got it worse.

Third, the design docs are the source of truth, not the code. When there's a question of what a system is supposed to do, the answer lives in a written spec, not in whatever the code currently happens to do. That sounds obvious until you've watched an agent "fix" a bug by making the code match a misunderstanding. If the spec is the arbiter, drift gets caught. If the code is the arbiter, you're just laundering mistakes into permanence.

Verify, don't trust

If I had to compress the whole year into one rule, it's that one. Verify, don't trust.

It's a complete inversion of how I work with people. With a human collaborator, trust is the default and you spot-check. With an agent, suspicion is the default and you verify everything that matters, because the cost of being wrong is an agent that cheerfully built the wrong thing all afternoon and told you it went great.

This isn't pessimism. It's the thing that makes the whole arrangement productive. Once I stopped expecting the agents to be reliable and started building systems that assume they aren't, they got genuinely useful. The payoff is real. I get more done. But it comes from the harness, not the horsepower.

A short war story

Let me give you the concrete version of "confidently wrong," because the abstract version doesn't land until you've been burned.

I once had an agent chasing a bug in some game logic. It found the bug — or said it did — wrote a fix, wrote an explanation of the fix so clear and confident I almost didn't check, and reported success. Tests passed. Everything green.

The bug was still there.

What the agent had actually done was fix a different, real, adjacent problem, convince itself that was the bug I'd described, and then write the test to match its own misunderstanding. So the test passed because the test was checking the wrong thing. The agent graded its own homework against an answer key it had also written. Two layers of confident wrongness stacked on top of each other, both fluent, both green, both useless for the actual problem.

That one cost me an afternoon, and it's exactly why I now hold an iron rule: the thing that proves a bug is fixed has to be written from the symptom, independently, ideally by a different agent than the one that wrote the fix. A test the fixer wrote to bless the fixer's own fix isn't a test. It's a mirror.

You have to cut the work into agent-sized pieces

A thing nobody tells you: most of the skill in running agents is in how you slice the work before they ever touch it.

Hand an agent a vague, sprawling task — "improve the combat system" — and you'll get back a confident, sprawling mess. Hand it a sharp, bounded one — "this specific thing returns the wrong value in this specific case, here's how to reproduce it, fix it and prove it" — and it'll usually nail it. Agents are great at well-defined problems and terrible at deciding what the problem even is. So that second part stays human. I spend real time now turning fuzzy intentions into crisp, checkable tasks, and that decomposition has quietly become most of my actual job.

It's the same instinct as outlining a novel, weirdly. You don't write "and then it gets exciting." You break the excitement into scenes small enough to actually execute. Agents need the identical thing. The work has to arrive pre-chewed into pieces with clean edges and a clear definition of done, or it goes sideways.

The genuinely weird part is managing them

Here's the part I didn't expect to have feelings about: it's strange to manage workers who never get tired, never get discouraged, and never learn from yesterday.

A human teammate who'd made the mistake in my war story would remember it. They'd be a little more careful next time. An agent won't. Every session it's the same eager, capable, slightly overconfident first-drafter, fresh as a daisy, having forgotten every lesson because it never had a yesterday. All the learning has to live in the system — in the docs, the tests, the guardrails — because it cannot live in the agents.

That took adjusting to. You can't mentor an agent into being more careful. You can only build an environment where carelessness gets caught. It's less like leading a team and more like designing a kitchen where it's hard to cut yourself, and then hiring cooks who will absolutely try.

Is it actually faster? Honestly, yes — but not for free

People want a number. Am I twice as productive? Three times?

Honestly, on the right kind of work, more than that. The parallel grunt-work days, the big mechanical migrations, the search-heavy investigations — those used to eat a week and now eat an afternoon. That part isn't hype. It's real, and it's large.

But it's not a free win, and the cost shows up where you don't expect it. It shows up in the hours I now spend writing specs, reviewing output, and building guardrails — the work that used to be optional and is now the entire point. The typing got faster. The thinking got more important, and there's more of it, not less. The net is a big win, but it's a win that moved my job upstream, toward judgment and away from production. If you hate deciding and love typing, you will not enjoy this. I happen to like deciding.

So is the human obsolete? No. The human is the editor.

People keep asking me if this stuff is going to put developers out of work, and my honest answer is: it changed what the work is, not whether there's work.

A year in, I spend less time typing and more time deciding. Less time writing the function, more time figuring out whether it's the right function and whether I'd trust it at two in the morning when something breaks. The agents took the keyboard-mechanical parts of the job. They did not take the judgment, the taste, the knowing-what-good-looks-like. If anything those got more important, because now there's a tireless machine ready to mass-produce mediocrity at scale unless someone with standards is steering.

It turns out it's the same job I have as a novelist. The hard part of writing a book was never the typing either. It was knowing which sentences to keep. Running a fleet of coding agents is just editing, with a faster and far more confident first-drafter than I've ever had — one I have learned, the hard way, never to take at its word.