Every technology shows up with a pitch attached. Someone stands on a stage, describes a world where the hard part is gone, and for a while the room believes it. Reverse Pitch is about what that same technology looks like once it’s in production, under real traffic, on a real bill.
We start with the biggest pitch on the table.
The pitch
The claim is not that language models are useful. That one is settled. The claim is stronger than that: coding agents write the code now. You describe the feature, the agent plans it, edits across the repo, runs the tests, fixes what it broke, and opens the pull request. The engineer moves up a level, from writing software to specifying it.
And the demo works. That’s the uncomfortable part. Hand an agent a well-scoped CRUD endpoint in a codebase with clear conventions and it will produce something close to what you’d have written, in a fraction of the time, with tests. I’ve watched it happen. Anyone telling you the demos are fake hasn’t run one.
So the pitch isn’t a lie. It’s a measurement taken under conditions that don’t survive contact with a real codebase.
The reality
I’ve spent the last eight months using coding agents on production work: established systems, greenfield projects that made it to production, and personal ones. Here’s what the ledger actually looks like.
The speedup is real, but not where the pitch says it is.
What got dramatically faster was the work I already knew how to do and didn’t want to do. The DRF serializer for a model I’d already designed, a backfill script, the scaffolding for a new project. On that class of task, an afternoon of work now takes less than an hour.
What got slower was the work I hadn’t finished thinking about. When I handed an agent a problem I didn’t fully understand, I got a confident, plausible, well-formatted implementation of the wrong thing. Then I spent the afternoon I’d just saved reading it closely enough to realize it was wrong. Reviewing code you didn’t write is slower than writing it. That cost never shows up in the demo, because in the demo the specification was already correct.
The unmaintainable-project failure mode is structural, not a skill issue.
Ask for a feature without architectural constraints and you get code that works and doesn’t belong. On larger codebases I hit this constantly: an N+1 query introduced because the agent couldn’t see the access pattern behind an imported dependency, a duplicate helper written because it didn’t know the utility already existed. Each instance is small. The problem is that each one is individually reasonable, so nothing trips your review instinct, and sixty of them arrive in a week.
The fix is organizational rather than personal, which is what makes it hard. Keeping a codebase legible to an agent is a convention every engineer follows, not a document one engineer writes. At enterprise scale that’s a company-wide change, and company-wide changes take quarters. The models ship faster than that. By the time the rules are actually enforced, they were written for a model two generations back.
Context is the bill.
The most expensive thing about agentic coding is not the subscription. It’s that useful output requires the model to hold your architecture in its head, and holding your architecture in its head costs tokens on every single turn. A single deep session on a mature repo burns 40 to 50% of my usage window of a Max subscription. Multiply that across a team and the “just use AI” line item stops being a rounding error.
The counterintuitive part: the fix for bad output is usually more context, which is also the thing that costs money. The cheap prompt gives you the result you have to throw away.
What I got wrong.
I assumed supervision was enough on its own: that I could skip the design thinking as long as I read every diff. It isn’t. Letting the agent choose the abstraction and reviewing only the result meant closing tasks faster while understanding the system less, and after a few weeks of it I found reviewing code I hadn’t written more draining than writing it myself, even when writing it myself took longer.
Where the pitch is right
Three conditions, and when all three hold I’ll take the agent every time.
The problem is already solved in your head. If you can describe the implementation in a single paragraph, the agent is faster than you and the review is cheap. Not the feature. The implementation.
The codebase has enforced conventions. Not documented ones. Enforced ones: linters, type checks, a test suite that fails loudly, a directory structure that makes the wrong thing awkward. Agents follow the constraints that exist in the repo, not the ones in the README. Every hour spent making a convention mechanical pays back on every future generation.
The blast radius is small and the feedback is fast. Scripts, migrations you can review in one screen, test coverage, one-off data work, the tedious middle of a refactor you’ve already planned. Low stakes and immediate signal is exactly where the technology is strongest.
That’s a genuinely large fraction of the job. The pitch oversells it by suggesting it’s all of the job.
What I’d actually do today
Four rules. Each one costs something, and the cost is the point.
Argue before you delegate. Think the problem through and reach your own solution first. Then don’t hand it over. Open a planning session, give the agent the constraints without your answer, and let it propose one. Now you have two solutions to compare, and a real technical discussion of the kind you’d have with a coworker at a whiteboard. Put a clock on it. Ten minutes is usually enough to land on something neither of you would have reached alone: better than mine because of what the model was trained on, better than its because of what I know about the project. Cost: you give up the fantasy of describing a feature in one sentence and getting it back. That fantasy was never real.
Make one thing mechanical every week. A lint rule, a test, a project convention that fails CI. Cost: an hour that produces no visible feature. It’s the highest-leverage hour in the week, because it constrains every generation after it.
Read the diff as if you’re reviewing a contractor’s first PR. Not “does this work” but “does this belong in the system I’m responsible for.” Reject on architecture, not just correctness. Cost: you will reject working code, and it will feel wasteful. Reject it anyway.
Keep one thing a week that you build entirely yourself. The data layer of a new feature, the base implementation of a pattern everything else will extend. The parts where the design decision is the work. Cost: it’s slower. That’s what you’re paying for. The judgment that makes you worth asking is built by doing the hard part, and it’s the only asset here that doesn’t depreciate when the next model ships.
The agent isn’t the junior engineer in this story. You are the senior one, and the whole value of that role is knowing what should exist before anything gets written. That part hasn’t been automated. It’s just been made much easier to skip.
Reverse Pitch is one post a week on software engineering and the career around it, written from inside the work. Opinions, with receipts.