Reflecting on 4 years of LLM software development evolution
Shifting left and how LLM coding feels like the final evolution of DevOps
10/20/2026
We're roughly 4 years in to this ride of LLMs writing software. I took the week off this week to enjoy some fall hiking but felt like reminiscing on what our AI journey has looked like to date.
The timeline is roughly:
2023: IDE Assistant
- Skilled developers driving the process
- AI suggesting code in-line for boilerplate and rote features
2024: Junior Dev
- AI writing full features with defined scopes and heavy management
- Large code bases often result in context degradation
- Human-designed architecture still required
2025: Mid-Level Engineer
- AI executing end-to-end within a code base
- Human-designed architecture still recommended for anything complex
- Human code review still critical
2026: Senior Engineer
- AI proposing solutions to complex business problems
- AI handling end-to-end work across the technical surface (many code bases, clouds, systems)
- AI UI/UX and design is great
This shift obviously has labor implications as the kinds of teams I spent most of my career building are tough to justify as the work moves more to management than IC execution. Teams will continue to shift to be smaller and more senior as AI handles more and more of the technology surface area of businesses. This does have one interesting benefit to businesses, we shift the ability to impact business objectives further left.
The big transformation in the first half of my career was "DevOps", the idea that by building guardrails and automations we could empower developers to directly deploy, debug, and support the software they built. Before DevOps a Software Engineer would write the software, QA would test and sign off, and then some sort of System Administration team would "ship" it, usually on a set release cadence, and very often off business hours. Invariably bugs would be found in production (because reality is that software is rarely perfect if you're moving fast enough) and the Sys Admins would get paged, troubleshoot it, report back to the Software Engineers who would author a patch, give that back to QA, then the Sys Admins to release a hotfix.
All of this was very slow. We used to describe the process as "throwing it over the wall", and teams would often resent each other as they would point fingers in both directions when things didn't work in production. DevOps changed all this, Sys Admins instead built smart build and release tooling that allowed for the safe automated testing and deployment of software. Pretty soon Software Engineers could author code and have a high degree of confidence it was going to work in production, then send it live themselves, see some amount of production logs, and roll it back quickly (or automatically) when things went wrong. Continuous integration / continuous deployment pipelines continued to get more and more advanced and release cadences sped up for monthly to weekly to several times a day. DevOps was a triumph for building software.
The role of Sys Admins changed. Scripting went from a nice to have to a must have. You were building release pipelines and fleet orchestration software. You spent less time troubleshooting production apps and more time troubleshooting the guardrails that supported the entire software lifecycle. It required managing through the growth of teams who supported the apps and systems, as well as the rest of the organizations who had to get comfortable with going from monthly to daily software releases. This was what we described as "shifting left".
We're living through another shift now. Now with AI a business leader can describe their business initiatives to a frontier model and get high quality software out. A business leader who wants to launch a new initiative or tweak the way a core application works can simply describe their goal to a properly configured agent and the AI will build, release, and monitor the results of that. Sure this does not work out of the box the day an organization, it takes an investment in building the framework, harnesses, monitoring, and guardrails to do this safely: this feels very similar to the DevOps transition.
The role of Software Engineers is changing in the way Systems Administrators did. You are no longer writing lines of Application code, you're building the guardrails (skills, release pipelines, deterministic guards) to allow business leaders to build software. Just like Sys Admins had to build the guardrails to allow Software Engineers to release software to production, we're living through this again. Further shifting left.
Just like the DevOps "revolution" which now feels like ancient history, the transition will be rocky. There will be companies releasing broken and buggy software. Just like not all Sys Admins wanted to become DevOps Engineers, not all Software Engineers will want to become AI wranglers for their business leaders. The frontier will be scary and uncomfortable, but ultimately the shift left is coming and we need to figure out how to navigate it.