MediumSame Idea, Different Decade | by Fayner Brack | MediumSitemapOpen in appSign up<br>Sign in
Medium Logo
Get app<br>Write
Search
Sign up<br>Sign in
Same Idea, Different Decade
The tools change every decade. The work doesn’t.
Fayner Brack
4 min read·<br>Jun 6, 2026
Listen
Share
Five identical wooden chairs in a row, each painted a different solid color against white.
Want to come back later? Save this to readplace.com.<br>Same Idea, Different Decade | Reader View<br>Tools change every decade, but software engineering principles remain the same. Skip the names, teach the principles.
readplace.com
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.<br>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.<br>Not even close.<br>The tools changed but the engineering fundamentals never did.
Within each wave, the same principles resurfaced with new names.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>Get Fayner Brack’s stories in your inbox
Join Medium for free to get updates from this writer.
Subscribe
Subscribe
Remember me for faster sign in
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 🤯.<br>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".<br>But this cycle is showing something the previous five proved too. Coding was never the bottleneck.<br>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<br>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.<br>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.<br>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.<br>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...