I wrote my first paid line of code in 1999. Servers you could hear. Deploys over FTP. If something broke at 2am, you SSH'd in and read logs until your eyes hurt.
So when people tell me AI made them 10x faster, I want to believe it. I use it every day — I build bots on Claude and GPT, I've got AI running in production on my own projects. It's the best tool I've picked up in years.
But faster? Where it actually counts, no. And I think a lot of us are measuring the wrong thing.
Typing was never the bottleneck
Here's the uncomfortable part. The slow bit of this job was never the typing.
I can bang out a CRUD endpoint in ten minutes with or without AI. That was never what ate my week. What ate my week was understanding why the payment webhook fired twice, or why a site behind a CDN was fast in the test and dead for real users, or which of forty plugins was quietly holding the main thread hostage.
AI is fantastic at producing code. It's much weaker at understanding a system it can't see — your traffic, your data shape, the three weird decisions someone made in 2021 that everything now depends on. That understanding is the job. The code is just what falls out at the end.
So when AI writes the endpoint in 30 seconds, I didn't save a week. I saved ten minutes. The week is still there, waiting, in the part AI can't do for me.
The trap I catch myself in
There's a subtler cost, and it's the one I actually worry about.
When a tool hands you working code instantly, it's really tempting to skip the understanding step. It runs, tests are green, ship it. I've done it. I've shipped something an AI wrote, felt great about the speed, and then spent two days a week later untangling a problem I'd have seen in five minutes if I'd read the thing properly the first time.
The code "worked." That's the trap. Working and understood are not the same state, and production only cares about the second one.
I saw this on a real job — I'll keep it vague. A bot was sending conversion events to an ad platform and the numbers were off. The generated code was clean. It sent the events, got a 200 back, looked perfect in every test. The actual problem was two layers up in how an ID got passed between systems, somewhere no amount of "make the code correct" would ever fix, because the code was correct. You only find that by understanding the whole path. No model was going to hand me that. I had to sit and think.
What actually got faster
I don't want to sound like AI is a toy. It's not. Some things genuinely changed:
- The boring first draft. Boilerplate, config, a test harness — AI gets me to something I can react to instead of a blank file. Reacting is faster than starting.
- Unfamiliar territory. Dropped into a language or an API I don't use often, AI is a better first guide than skimming docs for an hour.
- The rubber duck that talks back. Half the value is just explaining the problem out loud to something that pushes back. I catch my own bad assumptions faster.
Notice what those have in common. They speed up the edges — the start, the unfamiliar, the stuck. None of them touch the core: knowing the system well enough to make the right call. That part still runs at human speed, and I've made peace with it.
Why 1999 me would recognize this
The tools have changed beyond recognition. The habit that separated the people who could fix things from the people who could only write things — that hasn't changed at all.
Back then it was the guy who actually read the manual versus the guy who copy-pasted from a forum until it compiled. Both shipped. One of them could fix it at 2am. AI just made the copy-paste path frictionless and fast, which means the gap between "it runs" and "I understand it" is easier than ever to skip over. The discipline of not skipping it is worth more now, not less.
That's the thing I'd tell someone starting today. Let AI write the code. Then read every line like you'll be the one paged when it breaks — because you will be. Speed at typing is cheap. Understanding is the whole job, and it's the one thing nobody can generate for you.
I run production systems and build AI-driven tools for a living — the kind of work where "it ran in the demo" isn't good enough. If your stack has one of those problems where the code looks right but the behavior is wrong, that's the part I actually enjoy.
Genuine question for the room: where has AI actually made you faster — the core work, or just the edges around it? I'd like to know if I'm the outlier here or if we're all quietly measuring the wrong number.
Top comments (0)