> LLMs are eating specialty skills. There will be less use of specialist front-end and back-end developers as the LLM-driving skills become more important than the details of platform usage. Will this lead to a greater recognition of the role of Expert Generalists? Or will the ability of LLMs to write lots of code mean they code around the silos rather than eliminating them?

This is one of the most interesting questions right now I think.

I've been taking on much more significant challenges in areas like frontend development and ops and automation and even UI design now that LLMs mean I can be much more of a generalist.

Assuming this works out for more people, what does this mean for the shape of our profession?

I've faced the same but my conclusion is the opposite.

In the past 6 months, all my code has been written by claude code and gemini cli. I have written code backend, frontend, infrastructure and iOS. Considering my career trajectory all of this was impossible a couple of years ago.

But the technical debt has been enormous. And I'll be honest, my understanding of these technologies hasn't been 'expert' level. I'm 100% sure any experienced dev could go through my code and may think it's a load of crap requiring serious re-architecture.

It works (that's great!) but the 'software engineering' side of things is still subpar.

Code is, I think, rapidly becoming a commodity. It used to be that the code itself was what was valuable (Microsoft MS-DOS vs. the IBM PC hardware). And it has stayed that way for a long time.

FOSS meant that the cost of building on reusable components was nearly zero. Large public clouds meant the cost of running code was negligible. And now the model providers (Anthropic, Google, OpenAI) means that the cost of producing the code is relatively small. When the marginal cost of producing code approaches zero, we start optimizing for all the things around it. Code is now like steel. It's somewhat valuable by itself, but we don't need the town blacksmith to make us things anymore.

What is still valuable is the intuition to know what to build, and when to build it. That's the je ne sais quoi still left in our profession.

Both forces are playing out simultaneously - which is what makes this hard to forecast.

The generalist capability boost is real. I'm shipping things that would have required frontend, backend, and devops specialists two years ago. But a new specialization is quietly emerging alongside that: people who understand how LLM pipelines behave in production.

This is genuinely hard knowledge that doesn't transfer from traditional engineering. Multi-step agent pipelines fail in ways that look nothing like normal software bugs - context contamination between model calls, confidence-correlated hallucinations that vary by model family, retry logic that creates feedback loops in agentic chains. Debugging this requires understanding the statistical behavior of models as much as the code.

My guess: the profession splits more than it unifies. Most developers will use LLMs to be faster generalists on standard work. A smaller group will specialize in building the infrastructure those LLMs run on - model routing, context management, failure isolation, eval pipelines. That second group isn't really a generalist or a traditional specialist. It's something new.

The Fowler article's 'supervisory middle loop' concept hints at this - someone has to monitor what the agents are doing, and that role requires both breadth and a very specific kind of depth.

No one will hire expert generalists at any kind of scale worth caring about. They are WAY too hard to evaluate as such and basically no pipelines exists to do so. Big software companies with cutesy riddles thought they were hiring for this, but they just got specialists with a culture fit.

Expert generalists are also almost impossible to distinguish from bullshitters. It’s why we get along so well with LLMs. ;)

I’ve become the same way. Instead of specializing in the unique implementations, I’ve leaned more into planning everything out even more completely and writing skills backed by industry standards and other developer’s best practices (also including LOTS of anti-patterns). My work flow has improved dramatically since then, but I do worry that I am not developing the skills to properly _debug_ these implementations, as the skills did most of the work.

isn't it just one more step up the hierarchy. 10 years ago most developers have forgotten how to code in machine language because you didn't need to know it. Now, we're jsut going one step higher.

[dead]