During my entire professional career as a software engineer (a little over 20 years!), humans lived at the boundary between intent and implementation. This meant that software was a very very personal field.

Dogma, personality, and philosophy has dominated the way we write code, and I've worked with productive and valuable engineers from everywhere in a large spectrum of perspective. There are lots of folks who believe that software is a pure science and that the best interview question would be an algorithm optimization - and plenty who believe that implementation matters little, and that product insight and empathy, assisted by plenty of googling, should drive codebases.

Recent progress in LLM-assisted software development has convinced me that we've now collapsed that entire spectrum into a narrow archetype. If you believe that everyone should be able to choose an appropriate sorting algorithm for a given task, and then hand write it on a whiteboard, or if you believe that a person should merely be able to propose a working architecture for a given user need, you're still on one side of a larger argument - one around decision making in software.

I see this as roughly akin to the lore around vim vs emacs or tabs vs spaces that dominated the conversation early in my career. This seemed trivial to me, but I'm sure was a legitimate and frustrating reality for the prior generation of engineers. When I became professional, version control was somewhat fragmented and not always the norm (remember subversion?), and "developer experience" was mostly LLDB and Firebug - tools with learning curves almost as steep as the tools they were meant to debug. Autoformatting wasn't even a consideration, so the tools you used mattered a lot.

But early in my career, this conversation shifted away from formatting and into abstractions. Browser Javascript speeds improved dramatically, Android brought GC to mobile, ARC simplified memory management, and features became a lot more about architecture than implementation. And yet, Robert Martin still inspired many engineers to pursue pedantic levels of control and dogma, and the spectrum shifted from tools to implementation.

I've been convinced based on my own productivity with LLM tooling that we will soon bring this era to a close, and enter into a new one, where we move the pedantic frontier from implementation to architecture. It matters little in 2026 if you know how to implement B-Trees, and it probably barely matters that you even know that it exists - more than likely, an LLM will choose the most appropriate pattern at the implementation level, even when you wouldn't have.

However, this exposes a critical problem that we will soon encounter: cargo-culted architecture. Much of the justification for fairly dubious architecture choices in the past (I will refrain from naming specific frameworks, but most if not all modern frameworks fall into this category) have been motivated by maintainability. This has been a really good argument for 20 years or so. The primary cost in software is long tail maintenance - and this gets harder over time with many hands. Context is difficult to manage and separation of concerns isn't always a performance or compatibility decision, it can often just be "confusion insurance" which will pay deep dividends much later in the software development cycle. These frameworks came with a major tradeoff though. For all the productivity gains in maintenance and shared understanding they provided, they lock codebases into an almost-never-appropriate architectural stack. SQL where it barely made sense, overly complex lifecycle code, stacks that work better on a developer machine than they did in production.

The decisions made to make humans more productive have now become the training data for a different kind of worker - one where DRY code gives little by way of readability, is now almost always factored earlier than it should be. Annoyingly, these LLMs are best at writing code that they have seen before - and not at writing code that is actually appropriate for a model where codebase churn is dramatically higher, and architecture matters far more than maintainable implementations.

So we get the worst of both worlds for now, but I anticipate an exciting era for those of us who have spent years making architectural concessions because of implementation bottlenecks. I can comprehensively unit test a distributed system in a few days now. E2E testing brittleness is something you can delegate.

If nobody is looking at the implementation layer, soon it will be as irrelevant as if you used tabs or spaces. LLMs are autoformat for implementation details, and the job of being a software engineer will soon be to focus on the system, not the code.