It’s a strange time to be a software engineer. We’re speedrunning a technical revolution that transforms our industry from one of craftsmanship to mass production and cheap code. This is painful to those who, like me, identified with the art and elegance of programming, and now have to reckon with the fact that we’re no longer artists but just people who type for money.

I’m sympathetic to those who initially rejected the usefulness of LLMs, citing hallucinations and so on, but at some point over the last year it became absurd to hold on to this claim. Today it seems like willful ignorance to reject a future where AI writes 90-100% of the code.

Indeed, at the leading AI labs, some engineers no longer write any code themselves. Startups and eventually enterprises are following suit. If your daily routine as a SWE doesn’t already look vastly different than it did in 2022, it soon will. Yet in spite of these rapid changes, I’ve found some relief in the fact that many of the fundamentals are staying the same, at least for now.

Software engineering has always really been about outcomes, not code. This is why strong engineers spend much of their time thinking about productivity and team coordination. We’re fortunate, because the principles and tools that make a team operate fast also tend to make coding agents work better: small, stacked diffs? Works great for human understanding and also for swarms of agents making concurrent changes. Continuous deployment, automated testing, and easy rollbacks? Already a good idea, and even better when you’re shipping more code than ever before.

What makes a good software engineer? I think a lot of it comes down to taste and intuition (often built up through years of experience). This will remain true, though this intuition increasingly operates at the level of architecture rather than individual lines of code. Junior engineers now have to start developing this architectural taste immediately out of the gate, largely sidestepping the need for code-taste. Frontier models are writing ever-cleaner code, especially when paired with a good AGENTS.md to guide them. But they continue to fall short when it comes to understanding and really engaging with the constraints (both social and technical) that define much of our jobs.

I’ve been telling myself that this is enough; that my identity as a builder can remain intact. In the short-to-medium term (<5 years), I’m pretty confident that these principles will hold true. Beyond that, I’m less sure. LLMs can, in theory, automate anything that can be expressed symbolically, and I think that engineering principles, and even taste, can be.

Adam Leventhal and Simon Willison coined the term Deep Blue for the pervasive feeling of dread that many software engineers are sitting with these days. I have days where I feel this deeply. But on other days, when I really lean into this new way of building, it’s hard not to get caught up in the sheer joy of the insanely fast feedback loop and the feeling of expansiveness you get when you’re orchestrating concurrent agents all building towards something new at once.

Not everyone will enjoy this kind of work, and many engineers (especially earlier in their careers) won’t have the experience and professional networks that can cushion the tumult. We’re all living through the creative destruction. There’s real excitement, but also grief — and it can be painful to hold both at once.