Where Are You Spending Your 10x?

Clients want it for yesterday, even if they didn’t know they wanted it until today.

That part hasn’t changed. What’s changed is that now we can almost deliver on it. We have superpowers. The models can produce an absurd amount of working code in an afternoon, and most of us are 10x more productive than we were two years ago.

Which is exactly why I think we’re walking into the oldest trap in this job, multiplied by ten. I see it in my own work, and I hear it from every developer I talk to.

The trap was always there

Someone is putting money into a product and they want it back as fast as possible, and they want to see you sweating for them while they wait. That’s the deal, like gravity, and it’s not the interesting part.

The interesting part is what we do under that pressure. We want the client happy, we want them to keep buying from us, so we take the fastest route to whatever they’re asking for. We skip the test for the hard case because the happy path works. We handle the error by logging it and moving on. We leave the edge cases for later.

It works for a while. Then the problems pile up like a river that never stops: errors thrown all over the place, crashes in users’ hands, features that don’t survive their first real user. And the people who own the mess, us, end up burned out, because every new request lands on top of a codebase nobody trusts.

In the pre-AI world this loop had a natural speed limit: how fast one person could read and write code. The mess grew at human speed.

Now it grows at model speed

Clients believe they can get whatever they want, and they’re somehow right. We believe we can deliver it, and we’re also somehow right. Honestly, this is an amazing time to be a developer.

But if I can write ten times more code, I can ship ten times more problems. Ten times more ways for the app to crash. Ten times more untested paths. The mess no longer grows at human speed.

The obvious defense is that finding and fixing bugs got faster too, and that’s true. I fix things in an afternoon today that used to take me a week. But that misses where the cost actually is. The expensive part was never the fix. The expensive part is the bug reaching the client in the first place: the trust you lose when it shows up in a demo or in a user’s hands, the refactor you now owe on code that was written in a hurry, the regressions that refactor drags along, and the people and tokens burned on all of that instead of on the next thing. Every one of those costs is paid in human hours, and no model makes those cheaper.

Speed of fixing is not the problem. Volume of what needs fixing is.

Uncle Bob said it years ago: “The only way to go fast is to go well.” It was true then. It’s more true now, precisely because the tools make going badly so much easier and so much faster.

Spend the 10x on one feature, not ten

The productivity gain is real. The question is where we spend it.

The default, the one the client is pushing for and the one the tools make trivially easy, is volume: more features per week, more screens, more tickets closed. Ten small features, shipped fast, that don’t survive first contact with a user.

The alternative is to spend the 10x on one feature and make that one world class. Concretely, on the things we always skipped under time pressure:

• The requirement itself. A one-line ticket means three different things to three different people, and the developer picks the fastest one to build. Today we can turn that one-liner into a real spec in minutes: edge cases listed, open questions surfaced, acceptance criteria written, before a line of code exists. Hand the product owner something concrete to react to instead of guessing and rebuilding.
• The tests we used to skip. The hard cases, not just the happy path.
• Errors that are typed and handled, not logged and forgotten.
• Lifecycle handling. The app behaves when it’s backgrounded, killed, or offline.
• Defensive parsing at the boundaries, because the API will lie to you eventually.
• Honest UX for the edge cases. What does the user see when things go wrong?
• A delivery cadence that’s delightful because it’s steady, not because it’s frantic.

None of this is new. It’s the same “do it well” list from twenty years ago. What changed is that the excuse for skipping it, “there’s no time,” is much weaker now. The careful work that used to cost a day now costs an hour. If we still skip it, it’s not because we couldn’t afford it.

Stay the smartest thing in the loop

The more code the tools produce, the more the value of a developer shifts from producing code to being responsible for it. We need to be 10x more careful, 10x more professional, and remain the most intelligent thing in the loop, because we’re the only thing in the loop that gets woken up at 3am when it breaks. The model won’t push back on a vague ticket or a missing test. We have to.

The client is always right, and we want to please them. Fine. But the way to please a client is not to hand them whatever they asked for today at the fastest possible speed. It’s to hand them something that still works in six months, that their users trust, and that doesn’t turn every future request into archaeology.

So the honest question, the one I’m asking myself every week:

Are we using AI to deliver the best possible value to our clients and their users, or are we using it to say yes faster?

How are you spending your 10x?

Thanks for reading!