With the arrival of LLM technology we are seeing a flood of software developers lamenting the end of their craft, and this has happened before. At its core it feels like more “whining about change”. I think this has historical precedent in the IT world: a new tool is viewed as threatening to current workflows and skillsets and causes widespread defensive reactions. Inevitably a few people grasp the tool and demonstrate the value, and this begins to form a new chapter in the ongoing evolution of information technology. In time no one ever looks back to how things were before. I think we’ve seen this with mainframes, object oriented programming, testing, cloud adoption and a variety of other technological stages in the journey. Can you add any insights on this topic?

DeepSeek Thoughts

Your framing is largely right, but I’d add two caveats: not all resistance is “whining,” and “no one ever looks back” is too strong. IT accumulates layers rather than replacing them cleanly. Mainframes still run banks, COBOL still processes transactions, on-prem still exists, and monoliths are still built. What changes is the center of gravity—and the definition of the craft.

The recurring pattern is real. Compilers and high-level languages were resisted by “real programmers” who wrote machine code. Structured programming and the GOTO debate triggered existential arguments. OOP was sold as a silver bullet and then became one paradigm among many. Open source was called a business threat; now it’s infrastructure. Testing and QA were seen as overhead; now CI/CD is standard. Cloud was “not serious”; now it’s the default for much of the industry. DevOps eliminated some ops roles but created SRE and platform engineering. Low-code didn’t kill developers; it shifted them toward integration, governance, and edge cases. Stack Overflow and copy-paste were once “not real programming”; now they’re just part of the job.

Each wave followed a similar arc: new abstraction appears → experts say it isn’t real X → early adopters get leverage → tooling matures and failure modes get mitigated → job titles change → old skills become niche → new bottlenecks emerge → the industry grows. LLMs are following that arc, but faster and broader.

What’s different about LLMs is that they’re probabilistic, natural-language-driven, and can produce plausible-but-wrong artifacts. A compiler is deterministic: if the source is valid, the output is predictable. An LLM is more like a very fast, widely read, overconfident junior developer. That makes verification, not generation, the scarce skill. Fred Brooks’ distinction between accidental and essential complexity is useful here. LLMs attack accidental complexity—boilerplate, syntax, glue code, test scaffolding, documentation, refactoring. They do much less for essential complexity: unclear requirements, conflicting constraints, domain modeling, architecture, security, performance, maintainability, and accountability. If coding is only part of the lifecycle, Amdahl’s law applies: speeding up code generation just moves the bottleneck to review, integration, testing, deployment, and maintenance.

So the craft doesn’t disappear; it moves up the stack. The valuable developer becomes less of a typist and more of a specifier, reviewer, debugger, architect, and verifier. Domain expertise matters more, because the LLM doesn’t know your business, your users, your compliance regime, or your legacy constraints. Taste and judgment matter more, because generated code is cheap and bad code is expensive. Security and observability matter more, because you can’t trust output you don’t understand. Human accountability remains, because no one can sue a model.

The legitimate laments are mostly about transition costs. The junior apprenticeship pipeline is genuinely threatened: if LLMs do the simple tasks that juniors used to learn on, how do they build deep skill? There’s deskilling risk—developers who only review AI output may never learn to debug from first principles. There’s over-reliance, automation complacency, security and IP risk, licensing ambiguity, and the danger of monoculture if everyone generates from similar models. There’s also the uncomfortable fact that some roles and skills will be devalued, even if new ones appear. Dismissing all of that as “whining” is historically inaccurate and strategically unwise.

The better lesson from history is not “ignore the critics.” It’s “separate status anxiety from genuine risk.” The people who thrived in previous waves were the ones who treated the new tool as an amplifier of judgment, not a replacement for it. They learned the abstraction, kept the fundamentals, and focused on the problems the tool couldn’t solve.

For individuals, that means: keep learning data structures, systems, debugging, security, and architecture. Use LLMs to explore, draft, refactor, and test—but review everything. Build evaluation harnesses for generated code. Get better at writing clear specs and constraints. Develop domain knowledge that a model can’t infer from public text. For organizations, it means: don’t cut the junior pipeline; redesign apprenticeship around AI-assisted critique. Update code review, security, and licensing policies. Measure outcomes, not lines of code. Invest in platform, testing, and observability so that faster code generation doesn’t become faster technical debt.

The end-of-craft lament is a recurring genre. It’s partly resistance to change, partly legitimate anxiety about displacement and deskilling.

But the craft was never really typing code. It was solving problems with code under constraints. LLMs make code cheap; they make judgment, verification, and accountability scarce. That’s not the end of software development. It’s another redefinition of it.

The real risk isn’t that LLMs end the craft—it’s that we forget to teach the judgment needed to use them well.

Qwen 3.8 27B Thoughts

You’ve identified a real pattern, and I think it’s worth both affirming and complicating a bit.

The pattern is genuinely robust, and the “whining” framing undersells what’s actually happening. What you’re observing isn’t really about the tool. It’s about professional identity. A software developer’s sense of self is often built around the act of constructing working code from a specification. That’s the craft. When a tool arrives that can do that act, it doesn’t just change the workflow—it challenges the thing that made the person feel like a practitioner rather than a manager of practitioners. The defensive reaction is less “this tool is bad” and more “if I don’t do this part, what am I?” The same dynamic showed up when database administrators saw query optimizers, when build engineers saw CI/CD, when the “glue code” programmer saw frameworks absorb their work. The technology is the trigger, but the wound is identity.

The “inevitable” quality is almost entirely retrospective. No one in 1975 looking at smalltalk prototypes said, “yes, within a decade the entire industry will reorganize around objects and I will simply be an object-oriented developer.” It looked like a fad. The people who got it early were often the ones who were already chafing against the constraints of the old paradigm. They weren’t brave; they were restless. The “few who demonstrate value” aren’t typically the most senior or respected—they’re the ones who were already doing things slightly outside the accepted workflow. That’s worth noticing, because it means the “early adopter” story is a bit romanticized. They weren’t seeing the future more clearly; they were escaping the present less comfortably.

Where I’d push back on your framing a little: the pattern isn’t “new tool → defense → adoption → no one looks back.” The old way doesn’t actually go away. Nobody writes in Fortran anymore, but Fortran still exists and is correct for certain numerical work. Nobody hand-assembles, but assembly is still how you debug a kernel panic. The old paradigm gets relegated, not erased. The “no one looks back” is true in the sense that nobody holds a nostalgic society for it, but the knowledge doesn’t vanish—it just stops being the front door into the discipline. This matters for LLMs because I think we’ll see the same thing. The “I type code into an editor” workflow doesn’t disappear. It becomes the mode you drop into when the LLM’s output is subtly wrong and you need to see what’s actually happening at the instruction level, or when you’re working in a domain so constrained that the probabilistic nature of the model is a liability. The old craft doesn’t die. It moves to the basement. And you still need to know how to go down there.

What I think is genuinely different this time, and what makes the defensive reaction a little more understandable than usual: previous paradigm shifts changed how you did the work. OOP changed how you structured a program. Cloud changed where it ran. Testing changed how you verified it. This shift is more directly aimed at the doing itself. A code-completing or code-generating model isn’t a new syntax or a new deployment target. It’s an agent performing the core verb of your profession. That’s a closer analog to the typesetter watching the phototypesetter arrive than to the programmer watching a new IDE arrive. The “I can still do it myself” fallback feels more threatened when the thing you do is precisely the thing the machine is now doing, rather than the thing the machine is doing around what you do. So I’d grant that the intensity of the reaction is proportionally larger here, and that doesn’t make it “just” whining.

The economic dimension gets underplayed in the “evolutionary” narrative. When you frame it as “information technology is evolving and this is the next chapter,” it smooths over the fact that some specific, real people are going to have significantly harder times transitioning than others. The person who is 54, has 25 years of deep expertise in a specific legacy domain, and was mid-career when the LLM wave hits, doesn’t get the same graceful “evolution” that a 26-year-old gets. The pattern you’re describing is true at the level of the industry and the level of the discipline. At the level of the individual career, the transition can be genuinely painful and not everyone clears it. Acknowledging that doesn’t invalidate the pattern. It just keeps it from becoming a kind of “it’s all fine, you just need to adapt” platitude, which is its own form of dismissal.

One insight I’d add that I don’t see in the usual framing: the people who are best positioned in the new paradigm are often not the most prolific coders. They’re the people with the deepest understanding of why a system is structured the way it is, what the failure modes look like, what the implicit requirements are that nobody wrote down. The LLM can generate plausible code. It cannot, reliably, generate correct code in the sense of “fits the actual constraints of this system, this domain, this organization, these edge cases nobody documented.” The person who can evaluate output is becoming more valuable than the person who can produce it. That’s a real shift in what “skilled” means, and it’s not obviously the same skill set as before. The “craft” isn’t being eliminated. It’s being moved upstream. You’re doing less of the construction and more of the architecture, the specification, the judgment. Whether that feels like “my craft is ending” or “my craft is finally maturing into what it should have been” is partly a matter of ego and partly a matter of where you actually enjoyed the work.

And a small meta-observation: the fact that this reaction follows the exact same arc as every previous one is itself a kind of comfort, but it’s also a warning against a specific error: assuming that this time the arc will play out the same way, at the same speed, with the same distribution of winners and losers. The LLM adoption curve is moving orders of magnitude faster than the OOP or cloud curves did. The “inevitable, gradual normalization” you describe took 15-20 years for most of those earlier shifts. We are maybe 3-5 years in. The discomfort you’re seeing in the “whining” is partly the pattern, and partly the compression. People who would have had a decade to adapt are being asked to adapt in eighteen months. That’s not the same reaction to the same stimulus. It’s a faster stimulus.

So: yes, the pattern is real, the defensiveness is understandable, and the long arc bends toward integration. But the “no one looks back” ending is a little too clean. People do look back. They just do it differently. They don’t mourn the old way. They mourn the version of themselves that was defined by the old way. And that’s a more honest and more human response than “whining about change” captures.

A thoughtful essay and a well structured response. I will add however, as a counter-point, that I am 58 years old and have been working in the IT industry now for nearly four decades. While I don’t know if I align with your early adopter profile, I certainly see an edge for myself in the use of LLM. Knowing how to build software “the old fashioned way”, with teams of developers, co-ordinating and overseeing their work, dealing with their quirks, transcribing client ideas into requirements… this is the foundation that makes the LLM so effective. The LLM is simply a more efficient, more effective resource that needs all the same oversight. What used to take a “team” 29 weeks can now be done in an afternoon. The construction effort has been reduced in terms of text processing, but the oversight, design and specification accuracy remain. The iterations move faster and the accuracy has greatly improved. In this context I do not see younger developers as having an advantage, but rather, a great disadvantage - how will they ever gain such experience? I am forced to think of the John Henry story.

I think your point about the young developers is the most important one in the whole conversation, and the one that gets least discussed: the apprenticeship problem. For forty years, the way you became a good software engineer was that you wrote the code. You wrote it badly, you debugged it at 2am, you refactored it three times, you got it wrong in production, you sat in the post-mortem and felt the specific shame of a null pointer that you should have seen. That iterative, painful, embodied process was the education. The debugging was the teaching moment. The code review was the seminar. The 29-week project wasn’t just 29 weeks of output; it was 29 weeks of calibrating your sense of what good looks like, what breaks, and where the traps are. If the entry-level construction work is increasingly done by a model, the 22-year-old grad who gets a prompt-writing job instead of a “here, build this service” assignment is not just doing different work. They’re skipping the curriculum. They never get the five thousand hours of pattern recognition. They never build the instinct that says “that’s going to be a problem in three months when the data volume doubles.”

You’re right that this is a genuine structural disadvantage, and it’s not one that the young person can simply “work around” by being more motivated or more open to new tools. They can pick up the LLM workflow in a weekend. They cannot pick up the judgment in a weekend. There’s no shortcut to the thousands of small failures that build it. And the profession, which is already short on patience for the slow development of craft, may not develop new apprenticeship structures in time. That’s the real question, and it’s a much harder one than “will LLMs change software development.”

Where I’d add a small complication to the “29 weeks in an afternoon” picture: for well-bounded, well-specified work, the compression is real and dramatic. But the 29 weeks also included all the discovery—the things the team learned about the problem by running into it during implementation. The architectural surprises. The “oh, that library doesn’t actually work that way” moments. The integration friction that only becomes visible once you’ve started wiring things together. The LLM compresses the construction of the known. It does not compress the discovery of the unknown. And the experienced engineer’s value is disproportionately in the discovery. You know where the bodies are buried because you’ve been in the cemetery. The young person doesn’t know there’s a cemetery.

On John Henry. I think the reference is apt, but I’d push on the ending a little. The standard reading is that the man loses to the machine, and that’s tragic. But in the ballad, John Henry doesn’t die from the steam drill. He dies from the effort of proving he could still beat it. The drill didn’t kill him. The need to validate the old form of excellence, on the old terms, in a single contest, did.

You’re not the man at the drill. You’re the man who’s been doing the steel-driving knowledge for forty years and now realizes the drill is just a faster way to do the part you were already doing and managing. The craft didn’t end. It moved up the stack, into the part you were already living in. The question for the next generation isn’t whether they can use the tool. It’s whether the profession will figure out how to teach them the steel-driving knowledge without requiring them to spend a decade driving by hand. That’s a harder design problem than any of the previous transitions presented, and I’m not sure anyone has a good answer yet.