The tools change every decade. The work doesn’t. #
Programming goes through a technology shift roughly every decade. Punch cards gave way to COBOL and personal computing. The web followed, then mobile platforms, then blockchain experiments.. Now AI agents.
The boundaries are fuzzy and the durations vary. But the direction is consistent: each cycle made it faster and easier to produce software, and each time, the software development industry treated the shift as a clean break from what came before.
Not even close.
The tools changed but the engineering fundamentals never did.
Within each wave, the same principles resurfaced with new names.
Doug McIlroy articulated Unix’s philosophy of small composable programs in a 1978 Bell System Technical Journal foreword. Stateless resource access existed before Roy Fielding named it REST in 2000. His dissertation described constraints the Web already embodied.
Patrick Debois coined “DevOps” in 2009, months after Allspaw and Hammond described the same feedback loop at Flickr. Architects started calling Unix-style composition “microservices” at a workshop near Venice in 2011. Lewis and Fowler canonized the term in 2014.
What happened next followed the same arc each time. The community argued about what the term really means. That argument created a vocabulary barrier. Engineers without the context to decode the jargon couldn’t participate.
So they went and built things. Along the way, they rediscovered the same principle, then a new name followed and the cycle restarted. The experienced minds jumped the bandwagon to not look "old" and then the term was given credibility.
The vocabulary became the gatekeeping mechanism. The pattern wasn’t intentional.. Naming invites debate and the debate requires context newcomers don’t have. The barrier built itself.
Renaming is not purely cosmetic. REST added rigor to what the Web was already doing. The jump from SOA to microservices brought deployment automation and team-level ownership. Often these things do mark real advances but the principle and fundamentals remain the same.
New names often mark real advances. The principle underneath predates the name in many, if not all, of these cases. AI is the latest version of both patterns: the technology shift and the naming trap.
Get Fayner Brack’s stories in your inbox #
Join Medium for free to get updates from this writer.
McCulloch and Pitts modeled the first computational neuron in 1943. Yes, you read it right, 1943! Expert systems dominated the 1980s. “Machine learning” became the standard label in the 1990s and 2000s. “Deep learning” took over around 2012. Now we say “AI” and split hairs between LLMs, foundation models, AGI, and narrow AI, vibe coding, prompt engineer, and... ugh! My head hurts 🤯.
The principle hasn’t changed: machines that learn patterns from data and generalize from those patterns. Tooling got better by miles, but we still use technology from the 80s in some circumstances and call it an "AI agent".
But this cycle is showing something the previous five proved too. Coding was never the bottleneck.
Fred Brooks made this argument in 1986. His “No Silver Bullet” essay distinguished the essential complexity of software, understanding what to build, from the accidental complexity of coding it. No single tool, he argued, would yield a 10x productivity gain
I'd argue 10x is achievable by working smart and applying decent software infrastructure/design practices, so let's read that as 100x productivity instead.
The hard part was never the typing.
The data supports Brooks. Surveys put the time developers spend writing code at somewhere between 11% and 32%. The rest went to meetings, maintenance, reviews, and figuring out what the system should do.
Here's a shiny new research for the mix: a March 2026 engineering analysis at Agoda confirmed the pattern for AI tools specifically. Teams raised individual output and project-level velocity barely moved. The bottleneck shifted upstream to specification and verification.
The Anthropic example landed the point publicly. In February 2026, a viral tweet noted that Claude Code writes almost all of its own codebase. Anthropic’s company-wide figure sits at 70 to 90 percent AI-generated code. Boris Cherny, the tool’s creator, replied: the non-coding work remains. Someone still has to talk to customers, coordinate across teams, and decide what to build.
The tool that writes the code changed. The work of deciding what to build, and why, still stayed the same.
The software industry celebrates frameworks and conference talks that coin new terms. You can spot the trap by watching where the debates heads to. A team arguing about whether their architecture “counts as microservices” or their way of working is "agile enough" is debating vocabulary. A team arguing about where to draw a service boundary in their specific business domain and how quick we can get an idea to the hands of the users is debating the principle.
The closest thing I’ve seen to a fix: teach principles without branding them. “Make your services independently deployable” transfers across technology cycles. “Adopt microservices” has an expiry date.
The name is the most perishable part of any programming idea.
DevOps became a job title and a vendor category instead of the practive of the developers being accountable for production operations, but the feedback loop it described was the same that engineers closed in the 1990s.
If you want to transfer knowledge that lasts, teach the principle. Skip the name. People run into the names and then, eventually, they’ll recognize what’s underneath. Come on.. We all know it's POTATO not POTATO.
If you liked this, you might like readplace.com, built for exactly this kind of reading. Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or Github.