Most developers are mediocre.
Not average. Mediocre. As in: they write code that only works because the universe hasn’t gotten around to punishing them yet. Half the systems you depend on right now are standing on a pile of duct tape, broken abstractions, and blind faith, and the people who built them are still out here bragging about “moving fast.”
I get why it happens. Startups train you to ship first and think later. That’s fine when you’ve got five people, no users, and two months of runway. But developers never outgrow it. The company scales, the codebase mutates into an unholy swamp of side effects and “temporary” hacks, and they just… keep going. Those clever shortcuts that were supposed to last a week are still running in prod three years later. Those “we’ll refactor this later” tickets are fossilized in Jira. Nobody remembers how half the thing works, but hey, at least we launched another feature on time.
And now we’ve added AI into the mix, which is like giving a chainsaw to someone who can’t cut straight with scissors. Tools like Copilot, Cursor, Claude, and GPT are trained on the same codebases written by these same developers, which means they’ve absorbed every bad habit the industry has normalized. You ask for “clean, maintainable code” and it confidently spits out something that looks fine, compiles fine, and quietly plants a landmine under your future self’s desk.
AI doesn’t know your architecture, your invariants, your scaling bottlenecks, or the nightmare edge cases that keep you up at night. It just predicts what code “probably” looks like. And since most code out there is mediocre, what you’re getting is mediocre code at lightspeed. Polished junk. Garbage with good indentation.
The real punchline is watching developers treat AI like it’s a genius senior engineer instead of what it actually is: autocomplete with a god complex. They stop questioning it. They stop thinking. They just hit Tab and move on. The AI mirrors their bad habits, they feed those habits back into the system, and the next generation of AI learns from that garbage. Congrats, you’ve built a self-replicating mediocrity machine.
And here’s the part nobody wants to admit: writing good software is hard. It’s supposed to be hard. It takes thought. It takes restraint. It takes looking at the clever trick your AI just suggested and saying, “That’s going to bite someone in six months,” and writing the boring, obvious version instead. But the industry doesn’t reward that. The industry rewards speed. It celebrates shipping. It fetishizes “impact.” And then, when the system inevitably collapses under its own weight, everyone acts shocked — as if we didn’t all see it coming.
AI isn’t going to fix this. It doesn’t know the difference between elegant and awful. It gives you what “most developers would do,” which is exactly the problem. That’s why your codebase already has five half-broken auth flows, three duplicated JSON parsers, two abandoned feature flags, and a migration script from last year that nobody dares to run because nobody remembers what it does.
If you want better software, stop coding like everyone else. Stop trusting an autocomplete engine to think for you. Slow down. Understand what you’re building. Write code your future self won’t want to delete on sight.
Because if you don’t, we’re headed for a future where developers don’t even write bad code anymore. AI writes bad code for them. Faster. At scale. With silly tests. And somehow, we’ll still be standing around asking why everything keeps breaking.
Top comments (4)
I think AI as a concept is not a bad thing. Feed a machine brain all the knowledge and let it form an answer based on the scientific method.
The problem is that not everything can be answered by using the scientific method. But the AI companies, and their funders, of today think they can solve all the problems. That is why they think AI can take over a lot of job sectors.
I don't agree that most developers are mediocre. I think a more than fifty procent of the loudest voices on the internet produce mediocre code because they want to prove a point. That is why you never should copy paste examples from tutorials or books or forums.
I agree that many of the highly visible software companies have that disruption mindset. Doing hackathon after hackathon for years isn't the way good software is build.
It are the teams with good leadership that come up with the great solutions in those companies.
I think there are many good companies and many good developers who just keep doing their thing, even with AI. And we should focus on longevity instead of hype.
🙌 You’re so right. And just to be clear — I use AI assistants constantly. The line for me is autonomous coding.
If I’m the one driving, watching, and double-checking every line, then Copilot can absolutely ride along. Docs? Sure. React UIs? Definitely (it’s better at them than me anyway 🤣). Debugging, reviews, pattern checks — yep. Tests are iffier — they can work, but only if I’m willing to do a much deeper review to make sure Copilot didn’t just rubber-stamp broken code.
What it is great at: exploring your ideas, poking holes in designs, surfacing gaps, documenting patterns, and my new favorite—writing formal proposals and ADRs.
Exactly. That’s why I built a chat mode that grills a senior dev Q&A-style and folds their answers straight into Copilot’s instructions. Ten minutes, and now it knows that the cursed corner doesn’t get touched — else production burns for a week 🤣.
Some jobs AI can do, others it shouldn’t. The difference is knowing which is which — and that call belongs to the developer (preferably after a little RAI boot camp 🏕️).
Unfortunately, this is entirely true. I keep saying the same thing: the internet is flooded with junior-level code, and since AI learns from that code, it inevitably produces more of it—creating an endless cycle of poor-quality development.
It’s crucial to encourage people to first understand what actually needs to be built before asking for solutions (a challenge that existed even before AI). Just as important, they should carefully review what these tools produce and iterate on it. The value of these tools is undeniable, but they are also incredibly easy to misuse.
Google's SRE book notes that roughly 70% of production outages are caused by changes—“move fast” just widens the blast radius of those changes.