The Industry Is Forgetting How To Build Software
The history of software development didn’t begin five years ago although it seems that some in the industry would have you believe this.
Why? I don’t know. The thing is some people seem to enjoy the same bad ideas cycling around every few years. They promote bad idea with a shiny new name, and act like other engineers are cavemen who haven’t yet seen the light.
The cycle is turning right now, we are entering a ship faster than the others (at all costs) section of the cycle.
It’s a disaster (just like last time).
You? You’re Going to Work 10 Times Faster
We’ve just been told that we need to work 5x faster than before. This is on top of our company values which include “take a reasonable estimate and half it”, which means that we need to work 10 times faster than without AI.
Let me give you more context. We need to go faster than any other company, at all costs. The company is (apparently) worried about getting left behind by our competitors who will (apparently) be shipping features so fast that we are going to be left behind.
We aren’t given the opportunity to ask questions (and imagine telling people you doubt something in an all-hands!). So nobody is ever going to ask whether we are shipping the right features, nobody asks whether our architecture is being destroyed by AI. Nobody asks anything. Because they are too busy managing their own Claude tabs in desperation trying to meet PR targets and keep their jobs.
The Outcome
I’ve noticed something interesting over the years. The developers who talk the most about velocity are often the same people creating systems nobody can understand. Every layer becomes abstraction on top of abstraction until simple features require architectural archaeology.
You ask where a value comes from and someone opens six files, two generated folders, three dependency injection containers and a state manager invented by a startup with 11 GitHub stars.
Brilliant.
AI is accelerating the trend of underrating clarity and prioritising velocity over maintenance. It used to be true that a senior engineer could unwind a confusing solution developed by a junior in ten minutes, understanding the code and thinking out a proper solution. Now AI is writing code that looks good on the surface, but hides a rat nest of bugs that are difficult to fix and might raise their heads at any time in the future.
The poor solution is the easy path, getting Claude to quickly write a solution (while not understanding it) is leading us to a place where code can no longer be fixed when there is a real bug, a production incident.
A good, simple solution requires thought, and this is something that we are outsourcing to Sam Altman these days. That’s a mistake and it’s fracturing teams.
What We Should be Asking
We all need to take responsibility for solutions.
We all need to ask:
Does this solve a real problem?
Can new developers understand it?
What happens when the maintainer disappears?
Are we becoming dependent on external libraries we barely understand?
Like we used to. Like when we worked to avoid engineering driven by fashion.
Performative software development needs to stop. AI is facilitating huge pull requests, complex abstractions and those endless architectural diagrams (that only AI likes to read).
It’s kind of funny that the following is becoming more and more common.
broken releases
endless regressions
late projects
exhausted developers
confused onboarding
constant rewrites
Perhaps it’s not surprising.
Conclusion
Technology changes constantly.
Human beings don’t.
Developers still misunderstand requirements.
Managers still chase deadlines.
Teams still accumulate technical debt.
People still leave companies halfway through projects.
And somebody still has to wake up at 2 a.m. to fix production.
Plus de change.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com
The Secret Developer is jealous of vibe coders.