← Back to writing

AI Made Us Fast. But Did It Make Us Better?

Shipping faster doesn't feel the same as knowing more.

aiengineeringproductivitydevelopment

I’ve been using agents for work for months now: AI programs that take a request and write the code on their own. Cursor, Claude, automated flows, the whole stack. I’ve shipped things in hours that used to take days. I’ve built weekend prototypes that would’ve landed on next quarter’s to-do list.

And I still catch myself wondering whether I’m getting better or just moving faster.

What happens when there’s 10x more code

Something I notice in my own PRs (the bundles of changes I send for review before they join the team’s code): when an agent writes way more code than I would, there’s way more code to review. There are more places for a bug to hide, and more small decisions buried in the diff, the list of lines that changed.

We’re supposed to not worry about that because “the AI probably nailed it.” I fell into that too. Once it fixes the regex you’ve been avoiding, that cryptic expression for matching patterns in text. Another time it refactors that ugly function, leaving it cleaner without changing what it does. And suddenly you’re reading fewer lines, trusting a little too much, vibecoding without meaning to: accepting what comes out because it seems to work, without reading all of it.

Reading AI-generated code bores me, I’ll admit it. It’s like proofreading someone else’s work. The general shape looks fine and your eyes slide past the details. But bugs live in the details. And the small decisions about how the code is organized are the ones you live with for two years.

Code flow
Agent produces Code at speed, unfiltered.
Human review Does this make sense? Do tests cover edge cases?
Slop `any`, happy-path-only tests, small decisions buried in the diff.
Learning What you correct flows back into the system. Style guides, preferences, notes.
Repetition Correcting the same thing in the next PR. And the next.
Ship Code you stand behind, not just code that works.
Dams don't slow the flow just to annoy you. They contain it so what comes out has controlled pressure, not slop.

I don’t see a comfortable middle ground

I’ve been turning this over in my head and I still haven’t worked it out.

If you delegate everything to agents that produce a hundred times more than you, you can’t keep up with the review. You’d have to delegate the review, then the testing, then the architecture decisions. It’s delegation all the way down until you’re not really looking at anything.

Teams built guardrails, brakes in the process, for a reason: checklists, double approval, a senior who blocks a rushed merge (the step where a change joins everyone’s code). That wasn’t free bureaucracy: it was a way to enforce slowness on purpose.

Those processes still exist in a lot of places. But the vibe shifted: from “let’s be careful” to “let’s be fast.” And I’m not sure how long that works.

Judgment, not speed

The hardest thing for me to delegate isn’t typing but judgment. Knowing when to push back, or when a request sounds reasonable but will become a maintenance nightmare six months later.

Agents don’t do that. You ask them to build something and they build it. They won’t tell you that new feature isn’t worth the complexity it adds. They don’t have an opinion on whether that data migration is the right call, or on whether you’re building too much for a problem that doesn’t exist yet.

That judgment, I think, comes from years of getting things wrong, of maintaining your own bad decisions, and of going slow until intuition shows up. I can’t prove it. It’s what I see in the seniors I respect and in my own work when things get messy.

The day I stopped on an SVG

The other day I was about to ask Claude for an SVG animation, SVG being the drawing format web pages use for icons and graphics. I had the prompt almost ready, the written request for the AI. And I stopped.

Not because the AI couldn’t do it: it would probably beat me on the first try. I stopped because I didn’t really understand how an SVG gets animated. And if I don’t understand it, I can’t properly review what comes out.

The productivity I have with AI today comes from years of learning without it. All that slow stuff before was the foundation: tutorials, Stack Overflow, the “why doesn’t this work” frustration. Without it, writing prompts feels like guessing. With it, at least you can steer the AI and check what it gives back.

I worry a bit that this atrophies if I never stop to learn by hand. I’m not saying everything should be done without AI. That would be ridiculous. But there are things where I stick it out and go slow: patterns I’ll use often, CSS for how a page looks, SQL for querying data, the design of large systems. These are things where the AI gets it wrong often and I have to filter.

The rule I use, holes and all, is this: if something’s going to need judgment from me in six months, I try to learn it now. If it’s disposable and low risk, I leave it to the AI.

Better, or just faster?

I still don’t have a settled answer, and I’m not going to tell you to stop using AI: I’m not stopping.

But I do think there’s a trade-off we don’t talk about much, something we gain in exchange for something we lose: we can ship more without necessarily knowing more, produce more without producing more judgment. The developer who can do the thing without AI has an edge when they use it. Not because they’re faster, but because they know what they’re looking at.

I try to keep learning by hand every so often: SVGs, weird regexes, new things I could solve with a prompt. The agents are going to keep getting faster. The question I’m left with is whether we’re going to keep getting better, or whether we’ll get used to running without really knowing where.