"Measuring programming progress by lines of code is like measuring aircraft building progress by weight" — Bill Gates
That's an insight we understood once, and have quietly forgotten.
The editor wars of Vim vs Emacs and who can type faster, we always knew were a little silly. Tabs vs spaces, same thing. But at least those debates were harmless. The current obsession with AI-powered "productivity" is not.
Deleting code remains the hardest and most valuable thing you can do in a code base. To delete code from a running system you need to verifiably prove it's no longer used and won't affect running state. That's already hard but it's an order of magnitude harder in a system you never wrote.
Look Ma, How Fast I'm Going!
One of the most addictive things about these tools is the illusion of productivity. You can generate a lot of things very quickly. That feels good but it is not the same as making progress.
I've been reading Why Nations Fail, which argues that liberal institutions, while slow, bureaucratic, apparently inefficient compared to autocracies are actually doing something autocracies skip. Front-loading the hard work of building consensus. Autocracies don't eliminate that work. They defer it, push it past the point of construction, where fixing things costs ten times more. And when the bill comes due, they point everyone at the next shiny project instead.
I think we're doing the same thing with software.
We're skipping the vital consensus-building step. "What should this thing actually be?" and using generative tools to produce something that looks close enough to avoid real scrutiny. The cost doesn't show up today. It shows up six months from now, when the code base is a negotiation between things you wanted, things the model assumed, and fixes layered over fixes. Ask any engineer whether they'd rather work on a greenfield or brownfield project and you'll get the same answer every time. It's significantly harder to fix the car while it's driving than to build it right before you set off.
I got the opportunity to see my girlfriend (a very talented UX designer) describing the same issues in the field of product design, innovation and marketing. Clients get frustrated with conversations about what they want, how it should work, what the edge cases are. They consider anything other than visual output "wasting time." They just want it built. But everything built from that point is tainted, nothing fits cleanly, everything is just wrong. The design equivalent of a code base full of AI fixes.
AI Slop Brain Rot
I'm learning Spanish. Mi español es muy malo, pero. One of the things becoming clear as I practice is the difference between recognition and recall. Duolingo has built an entire dopamine loop around the former. It pats you on the back for recognizing something you half-remember, hands you a star, and very rarely asks you to produce anything from cold.
A lot of AI-assisted programming works the same way. It's easy to convince yourself you understand code you're reading. But reading and generating are different skills, and if you stop generating you atrophy the muscle that can produce it.
Yes, hunting through documentation is frustrating. And it's getting harder. Stack Overflow, once the bedrock of practical technical knowledge, is a ghost town. Partly because the people who used to answer questions are now just asking an LLM instead, and partly because the LLMs hoovered up that accumulated knowledge to train on and gave nothing back to the commons. The ouroboros is complete. Meanwhile, official documentation has quietly gotten worse: thinner, more generic, optimised for search rather than understanding. The kind of deep technical discussion that used to live in mailing lists, forums, and long-form blog posts has largely just... stopped. Everyone is shipping, nobody is writing.
This makes the friction of learning without AI assistance feel worse than it used to be. But the answer isn't to give up on the friction. It's to recognize that the friction was always the point. That discomfort is how the skill gets practiced. And if you find the level of abstraction you're working at genuinely too painful, wrap it. Functions in functions in functions, until the problem feels tractable again. That's engineering. That's the job.
I've had this exact problem building the data acquisition service for Covet. It felt like trying to untangle those venetian blinds, you know the ones, twisted and broken, the joke we used to make about CSS. Fix after fix, each one creating new problems, the model understanding eroding with every iteration until I'm further from working software than when I started. The awful feedback loop: 80% of what I wanted, moving backwards.
So I'm deleting that repo and starting fresh. By hand.
Keeping Up With the Joneses
No industry does this quite like tech. We're so desperate to be on the bleeding edge that we forget it's called the bleeding edge for a reason.
LinkedIn is the worst accelerant for this. People jostle for engagement on whatever the hottest trend is this week. Not because it makes them better engineers, but because engagement means status means money. I feel it too. There's an anxiety that says: learn this, adopt that, pick up those new tools, or you'll be left behind. But we need more confidence that years of hard-won skills are actually worth something. They are.
When it comes to doing the real work, we need to ask harder questions. Does this tool help us build better software, or just more of it, faster? Is speed of delivery the only metric that matters?
If you're building a throw-away proof of concept, or the latest Web3-Crypto-NFT-Agentic-AI thing, maybe it is. But if you're building something that decides whether a couple gets a mortgage, who receives medical treatment, what premium someone pays on their life insurance then maybe slow is okay. Maybe we don't need the experimental toys.
Turkey Time
I didn't say this process would be easy, and sure in a few days I might be clawing at the walls. But the decision is made.
I'm stopping using LLMs for code generation. Not because they can't produce code. Clearly they can, a lot of it, fast. But because fast and a lot turns out to be exactly the wrong thing for me right now. I don't want a code-base I half-understand, built on fixes layered over fixes, growing in directions I can't fully see. I've already got one of those. I'm deleting it.
What I want is to write software I can hold in my head. Software I can delete with confidence. Software that, when it breaks at 2am, I have a fighting chance of actually debugging. None of that is compatible with outsourcing the generation step.
Maybe in a year I'll have a different view. Maybe there's a version of these tools that genuinely augments rather than replaces the thinking. But right now, for me, the costs are higher than the benefits and I think more of us should be honest enough to say that out loud rather than pretending the emperor's new clothes are a perfect fit.
So. Cold turkey. Let's see how this goes.
