A reply to "LLMs are eroding my software engineering career, and I don't know what to do"
If you didn't yet, I would recommend you first read this article before mine.
I read a piece this week by an engineer with ten years in fintech, watching his career get hollowed out by language models. It is honest and a little heartbreaking, and I do not think he is wrong about what he describes. But I think his list of what makes an engineer valuable is missing a few things, and they happen to be the hardest for a model in a box to reach.
His argument rests on three pillars that used to make a software engineer hard to replace, and he watches each one get absorbed by the models.
The first is domain knowledge: ten years learning payment systems, ledger accounting and PCI compliance, now promptable, because a model can synthesize all of it from its training data faster than he can apply it.
The second is debugging: he assumed that untangling a gnarly distributed system would stay human work, until newer models started one-shotting production bugs that used to cost him days.
The third is architectural taste: the craft of organizing a codebase well, which starts to feel pointless when the main reader and maintainer of the code is a machine that does not care whether the structure is elegant. By the end he wonders whether woodworking is the safer career.
I have felt some of the same thing. But there are three things that are not on that list.
The first is taste, but not the taste he means.
In the article, taste is architectural taste: how to organize a codebase, A-grade structure versus C-grade structure. Fair, and yes, that kind of taste matters less when a machine is the main reader and maintainer of the code. But that is only one kind of taste, and it is the most internal one.
There is another taste that points outward: the sense of what a product should feel like, and where it should go. When I look at a screen, I am not grading the code behind it. I am feeling whether it is right for the person who will use it, and whether it fits the direction we have chosen.
A model can generate ten versions of a checkout page. It cannot tell you which one belongs in your product, because it has no product, no direction, and no stake in where the thing is heading. That judgment is not about being able to draw a button. It is about holding a vision and measuring everything against it.
The second is where new ideas actually come from.
Not from inside the codebase, and not from inside the model. They come from friction with the real world. A merchant fighting their own checkout on a busy afternoon. A conversation at a conference. Your own irritation at a competitor's payment flow. A constraint a real customer hits that nobody in the room had imagined.
Last week I was at WordCamp Europe in Krakow, not to sell anything, just to be in the room and feel how that community thinks. I came back with more product ideas than a month of reading would have given me. A model trained on everything ever written is extraordinary at recombining what already exists. But it is not in the world. It does not run a shop, stand at a booth, or feel the specific pain that makes you think "what if we did this differently." Those inputs only reach a person who is out there collecting them.
The third is reputation.
Anyone can prompt a model now. That is the part that just got cheap, and it is why the article feels the floor falling out: if producing code is free, what is a coder worth. But producing output and being trusted to deliver are not the same thing. The scarce skill is no longer typing the code. It is prompting the model, then reading what it gave back with a sharp enough eye to catch what is subtly wrong, and putting your name on the result.
A model does not carry a reputation. It cannot be held responsible when the payment flow drops a transaction at two in the morning. A person can. The engineer whose name means "if he shipped it, it works" becomes more valuable when everyone around them can generate plausible code that may or may not be correct. When output is infinite, the trusted judge of that output is the bottleneck.
What's next ?
None of this is comfort food. A large part of everyday engineering, the commodity part, is genuinely being automated, and pretending otherwise helps no one. But I read the article's real question as "what do I do," and I think the answer is in these gaps. The value is moving away from writing the code, toward the things the box cannot do for you: having taste about where a product should go, bringing back ideas from a world the model cannot enter, and being the person trusted to judge what the machine produces and stand behind it.
That favors a particular kind of engineer. Not the one who waits for a ticket and writes the code in isolation, because that is exactly the part the machine now does well. The one who talks to users, builds and owns a product, goes to the event, runs the thing in the real world and feels where it hurts, and has earned the trust that their work holds up. The model in the box makes the code cheap. It makes everything that has to come from outside the box more valuable, not less.
But what about juniors?
This is the part that worries me too, and it is the strongest objection to everything above. All three fronts I just described reward experience, and the traditional way to earn them. The grind of entry-level work, is exactly the part being automated. The optimism for someone ten years in is partly paid for by the person trying to get through their first year. An honest version of this argument has to say that out loud.
But I do not think these fronts are actually closed to juniors. They are reached differently now.
Taste is not purely a function of years: it comes from caring and from looking hard at a lot of work, and plenty of juniors have sharper product sense than seniors who stopped paying attention.
Real-world embeddedness is not a seniority thing at all, because a junior lives in the world too, often closer to contexts a senior has aged out of, and the friction they feel is real signal.
Reputation is the hard one, because it is a track record by definition. But the same tools that threaten juniors also let them build and ship whole, real things on their own and in public, years earlier than my generation could. You can build the evidence that your work holds up now, by shipping and by becoming a careful, visible reviewer of what the model produces, instead of waiting through a decade of tickets to earn it.
The part I will not pretend away is structural. Companies used to train juniors as a side effect of needing the grunt work done. If that work is gone, many will quietly skip the junior and starve their own senior pipeline ten years out. That is a collective problem, larger than any advice to an individual, and the people who should lose sleep over it are the ones doing the skipping.
Conclusion
The author ends by wondering whether woodworking is safer. I understand the feeling. But I would not put away the keyboard. I would spend less time being a code generator, which I am about to lose to a better one, and more time being the human who decides what is worth building, who brings the ideas back from the world, and whose name on the work still means something. That part still has to come from someone who lives in the world.
Top comments (0)