LLMs are eroding my software engineering career and I don't know what to do

Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product. That first pillar is still there. Maybe the author isn't aware of the impact they have, but I know, with the evidence of reverted PRs, that when I step outside my area of deep knowledge I can no longer call BS on the agents. Our most capable agent, with access to the same kind of distributed systems the author talks about, is regularly wrong, frequently myopic, and just outright dumb constantly. It's the expertise of engineers on the team that push it back on track.

The OPs domain/subject matter expertise is the part that should elevate their career. Understanding how large applications are constructed should also remain a pillar.

The coding and debugging part will be GenAI and possibly guardrails (harness engineering) tuned specifically for fintech, which they are also well-suited to implement.

My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently.

LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is always many things subtly wrong iterating and expanding our domain.

This might be because the companies I worked for happen to be tackling complex domains precisely for moat-building reasons. They stay in business explicitly because there's not a book out there you can read to build a clone, the knowhow stays inside.

Also, a fintech whose managers recommend speeding up design docs with AI sounds way too careless to be in the money handling business. It's way, way too easy to end up with millions incorrectly allocated, particularly if you deal with high volumes of small transactions. These bugs are always a bitch to deal with because correcting the logic is just step one, you then have to correct all the wrongly calculated data in immutable DBs, move around the red tape and client comms, and your fix is bound to become a gotcha that new features and observability have to take into account ("remember that there's a bump in the data in february 2 because we had incident X".)

I always remember of the infamous Steve Jobs quote "Ideas are cheap". If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".

What I think is often overlooked is the human "Willingness" and "Care" of staying with the thing for the lack of a better term. What I mean by that is that a lot of people just don't care enough, or don't want to, build, maintain, and own things. Sure you can ship V1 faster, but will you remain on the grind?

I think a great example of what probably will happen is found in Suno, the AI Music thing. I don't know if y'all have tried it, but it now produces really good stuff. What's happening there? A lot of people play with their own little universe and get tired quickly, move away from it, and only a few prolific creators stay and turn it into a "job like" environment.

We may have shifted the scale and the economics of "delegation" and "execution" but I think there are still a lot of other factors to consider.

I've posted this before but worth posting again:

I work in DevOps at a firm that has been very enthusiastic about using LLMs (in the good sense).

The phases were basically:

- try out having the LLM do "a lot"

- now even more

- now run multiple agents

- back to single agents but have the agents build tools

- tools that are deterministic AND usable by both the humans (EDIT: and the LLMs)

The reasons:

1. Deterministic tools (for both deployments and testing) get you a binary answer and it's repeatable

2. In the event of an outage, you can always fall back to the tool that a human can run

3. It's faster. A quick script can run in <30 seconds but "confabulating" always seemed to take 2-3 minutes.

Really, we are back to this article: https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 aka "make a list of tasks, write scripts for each task, combine the scripts into functions, functions become a system"

-- END of original post --

What I would add:

if you let LLMs do whatever they want, they will happily make code. You can add tests to confirm that the tests work (which you used to do with human code, right?). You can also read the code.

When you read the code, you'll find that they sometimes do totally bananas things that still produce working code (I've seen humans do this too but that's another story).

In other words, you still need to make sure the system being built makes sense.

More succinctly:

Coding may be dead but software engineering is alive and kicking.

> I don't know what to do.

Ride the wave. You rode it when websites/webapps were the wave. I came into software industry before internet, kept changing my horse. You are never too old to learn new tricks. The new wave create new kind of work and workers. Be one of them. Ride the beast, master the tools. It's the same game again.

Domain knowledge and architectural skills are not gone. I can say even Opus 4.7 and GPT 5.5 get domain-specific stuff wrong. I use both, because when I am not sure I ask both and also check with Gemini. But these days, I ask those even when I am sure - its like I get something confirmed from a peer. And yes, you have to be the gate keeper - the speed breaker in a way - LLMs still lack a lot of context. And even if they get more context, they will end up costing a lot and still have no accountability. In accounting, one wrong entry and the whole system can be seen as "unreliable" - thats why you are needed. The interesting part is "who takes over" - accountants who become coders, or coders who become accountants. And the latter looks more likely, in any profession. And when that happens - the bar will be raised in these other white-collar professions too, just like what happening in tech.

Opus is getting good at architecture - I need lesser "pushbacks" either because I have learnt to say the right thing or it has learnt to do the right thing - I do not know which one.

> The company is now hiring again for a few roles and domain familiarity is not a strong differentiator anymore. We used to list "Software Engineer - Area". Now it's just "Software Engineer" and the team assignment comes after the offer is accepted.

> Of course, this is good for brilliant engineers that never had the chance to get deep into the domain and now have better chances at getting a job, but it's also sad to think that other brilliant engineers that spent their lives collecting domain knowledge are now competing on the same lane.

If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.

Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering. They might still find employment in other areas of the industry where they accumulated domain knowledge.

Agents are getting good but professing they are surpassing you in domain and architectural knowledge with no special prompting is basically self reporting at this point. That could be your job wasn't that complicated or your personal knowledge wasn't that strong, either way, same result.

Don't get me wrong, I am sure we will get to all three of these pillars, probably by next year. I am not naive.

> Maybe I should consider transforming my woodworking hobby into a profession...

Whatever your feelings on the future of the industry are, it's hard to imagine you'll find more professional success in artisan woodworking than artisan software.

I’ve been using Claude Code with Opus 4.7; it’s not that the code it produces is wrong, it simply tends to write too much of it. In my opinion it’s still worth thinking about a particular feature and finding the best way to fit it into your code because Claude will often just pick a layer of the stack (maybe presentation), and jam it in there. A couple weeks later you need this data somewhere else and Claude can’t reuse the code (maybe in the service layer) so it kind of “ports” it over. Unless a person is paying attention we now have the double the amount of code and duplicate logic. I don’t see AI tools like Claude getting better at this anytime soon.

Where I work there’s already pressure to use Opus 4.7 less to save money, someone mentioned using a smaller model for “simple bug fixes”. This might work sometimes but how often do we really know it’s a simple bug fixe ahead of time? I suspect as costs go up we’ll see interest in using these tools to write “all the code” go down. As people migrate to cheaper and less effective models I suspect we’ll see the pressure to skip reviewing that code dissipate as well.

We’ll see where we land, maybe it won’t as dramatically different as the author of this post fears.

I sympathise with the author being in the same boat, largely.

I just want to emphasise a point... Calculators give 100% correct answers and yet we still hire accountants; for the simple fact that we don't want all to be accountants.

People will hire software engineers for the simple fact that they do not want to be software engineers.

It's odd to me how quickly the author devalues their own experience just because AI can do certain things well. There's a huge chasm between what AI can do when prompted by an expert software engineer vs a non-technical person. Sure the models and the tooling will get better, but it still needs to be driven by someone with an intuition for how software works and able to dig in when necessary to unpack and correct the hallucinations, misplaced assumptions, or straight up borked code that will come from the gap between what a human wants and what they can express in words.

I have no idea how things will play out, but so far I am not worried because the amount of software continues to increase, and AI only accelerates that trend. This will require the same mental modeling, first principles thinking, and relentless curiosity that already formed the foundation of the software engineer skillset.

“We were taught that generalists and specialists will always have their roles. But now the market is shaping everyone into becoming a generalist.”

I see this as a negative, the whole once everyone has everything than everyone has nothing type of argument. The company I work for believes strongly in keeping humans in control and in the loop which is something I’m grateful for but at the same time who knows how long that will last. Companies are starting to get their AI bills and realizing how much this AI usage actually costs so only time will tell but I hope, for the sake of everyone, that those with the knowledge described in this article make effort to keep their brains in shape.

> I spent 10 years (even more when you account for non-profession experience) getting good at things that are becoming less and less valuable.

This is just how it is, and has always been in this industry. And it takes about 10 years to realize it.

When I started my career in software, businesses were still writing new code in COBOL. 10 years later those skills were pretty much useless, except for dwindling maintenance roles.

Then there was the client/server era. Then the web era. Then mobile. Then cloud, etc.

All the same functionality, written and re-written time and time again, using the latest popular stacks and methodologies.

I hope to be retiring in a few years and pretty much everything I have learned over nearly 40 years is no longer applicable or is at best losing relevancy to the way sofware is built today. And that's how it's always been.

To me looks like, if we're not collectively careful, civilisation will soon be on a path to an evolutionary dead-end.

Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack, meaning that only the owners of capital will be left, and they too will soon fade as the economy falls off a cliff and money has no value, because the only value that money has is the value of a human backing that, with thought, with ideas, with human output.

Whether you like it or not, "Economic output" is just a different phrase for "Human output that is valuable". When all human output is valued at the fractions of a penny per month of work, there is no future.

I think the one thing the author is underestimating, especially in his "first pillar" is that he is able to coach the models into great results because he already knows the lay of the land. I often make the same mistake. I see people struggle with GenAI, and feel flabbergasted how they succeed to fail, but then if you observe how they work the tool, it is clear they have no idea what to ask or how to evaluate and iterate on the responses.

> And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless.

How is that true? I've been using Opus on an industry scale over last 6 months and this is just not real.

It has consistently with a certain percentage of chance each time (and no claude.md and skills do not stop it fully):

* Suggested to remove tests to allow for things to pass

* Suggested remove an error so that things can be "unblocked"

* Suggested to use a second path when the original path ran into problem instead of making the original path accomodate for that possibility.

* Suggested or silently added "features" or "guardrail" that I don't want.

* Can be left unsupervised only if given a goal that it can verify against itself. Without such clear goal (e.g. this test in the integration environment must be fixed), it flounders.

I'm not using just the native harness (e.g. CC) either, with additional, customized harness, the behavior improves somewhat but are still fundamentally constrained and cannot really be trusted without verification.

See my methodology (100% handwritten): https://aperocky.com/blog/post.html?slug=agentic-development....

Being a heavy user I think I've ran into every single hallucination that the model can do over development release and operations. I am still a heavy user but there are a lot of value in recognizing where exactly LLM's limit is and work around that.

This feels fake/engineered but regardless of that also redundant.

It's the exact same story that we've heard countless times by now. Hosted on a blog with just a single post. Named in a way that suggests that said blog was created for this very single post.

What is there to learn from this other than LLMs seem to be bad for some people's psyches and that AI companies need these very stories to not get their funding shut down?

This doesn’t read to me as someone who is sincerely impressed or rather surprised what ai is capable off.

This reads like someone is trying to convince me, that ai is just this good, and that the author is telling me to use more ai.

To me this sounds like: Trust me, it’s really bad, i know what I’m talking about. Just lean into it, or change profession.

The bitter lesson is that there is no domain that will be left which AI won't get good at eventually. So really you have two options: if you actually believe the timeline is long you can keep retreating to the sectors that will be taken over last (emotional support nurse etc) or you can just say if you can't beat me join em and try to supercharge your career/project/life with AI now so it improving helps you rather than hurts you.

He says that taste doesn't matter and it hasn't in the past. However, in an era of "extruded code product" (by analogy to https://tvtropes.org/pmwiki/pmwiki.php/Main/ExtrudedBookProd... ) automatically generated by the truckload at negligible cost, the differentiator for software developers will necessarily be the ability to create a product that doesn't reek of extruded code product, i.e. the things like quality that he labels taste.

(Whether any one reading this, myself included, survives in the industry long enough to reach the other side of that transition is a different question.)

[EDIT] The reason I use books as an example is that 4.2 million books were published in 2025 (https://ideas.bkconnection.com/10-awful-truths-about-publish...); 3.5m self published (with most likely LLM assisted or wholly generated) and the remainder traditionally published. (That's ~9,600 new self-published books a day.) Who actually still sells enough copies to make money in this paradigm and why offers hints as to where the software industry is likely headed.

There are lots of positives that have resulted from using AI in software engineering. (1) No more long repetitive text editing sessions. I.e. changing namespaces or replacing deprecated APIs with the "correct" ones. AI will make nearly perfect text modifications with ease. (2) No more bike-shedding code reviewers nitpicking over every tiny coding decision. I.e, "you should use std::format instead of std::stringstream". AI will match the existing set of nitpicks so you don't have to. (3) Average Joe's and Jane's can craft applications by just talking to the computer. This might inject a freshness to the current state of software. Currently, we are all forced to use the same bloated applications like Word, Excel, Jira, and Photoshop. We are currently forced to deal with the same set of monopolistic SW companies. Now average folk can solve problems and avoid dealing with Microsoft for a spreadsheet program.

10 years of software development is still young and inexperienced.

Same boat here, just a couple years more experience.

Current LLMs are still kind of shit at actually programming so many jobs do still care to have professional programmers. However, I think it's evident that if things stand where they are, employers will care to have far fewer of them, at least of highly paid highly experienced programmers. If this is the state we're in with LLM adoption when they can't help but create the same helper functions 15 times, god knows we're screwed.

So we should probably work on clearing out our debts and figuring out what else we might want to do with our time, I reckon.

I'm still going to try to do a good job. I'm still trying to learn the best effective ways to apply current LLMs (Right now I still prefer to mostly write code myself but have been using LLMs to bang code into shape via iterative code review; this is a way to exploit LLMs to make better code, especially applicable if your velocity was already good.)

My prediction is that the review / human in the loop part will become much bigger and more discussed.

Current transformer technology will either plateau or eventually we will get to that singularity bracket. (I was a skeptic once but all signs point there)

And this means models will eventually get better.

The main human value will be

- intent (we call the shots of why and what, AI will take care of the how)

- taste (everyone now immediately identifies Claude designed landing pages, they all look the same, taste changes with time, and can’t be predicted)

- supervision, both before and after AGI, to ensure no accidental damage, no misaligned decision drift, or in the unlikely but still statistically possible case of AI going rouge

Anything else (if we don’t plateau) can be eventually achieved.

Having that said, the fact AI can do it, doesn’t mean we’ll want AI to do it.

If there will be enough demand for handmade creations (with the current anti AI sentiment I can see it having an impact at least as similar to organic food) then we have some hope.

There's a certain irony in masters of automation lamenting that their roles are being automated. I wonder whether the jobs their efforts eroded in the past ever got the same thoughts...

Programming, logic, etc are skills and toolkits. The optimal state of society is everybody being able to apply them, not just the enlightened compsci caste. There was a time in the past where scribes were paid nice cash for their efforts, too.

I guess the lesson to learn here is treating a toolkit as an identity and job for life. By virturee of the essence of the job itself - if the tool gets cheaper and more widespread, it's aactually success, not betrayal.

Yes, Code Monkey jobs are gone... I can assure you though that there are plenty of hard problems that reduce human suffering which still need humans to solve them.

The problem with “code quality” and LLM’s taking over your first 3 “pillars” is basically that LLM’s don’t care.

I recently had Cursor evaluate a huge code base that we took over. All public stuff, nothing scary security wise, but it was so convoluted that it was taking me forever to find the bugs. It was written by a person, I should add.

I did this in cursor and after one prompt using Plan, it found all the bugs, created a plan to fix them, it looked good, and I had the agent create the fix.

It took 30 minutes.

The client had this project in the hands of another company without ai tools and they couldn’t fix the bugs she told them about.

So my point is, if we are holding on to our jobs for dear life on the basis that “code quality” matters, you might as well kick down the 4th pillar. Like I said, the LLM does not care.

I've consulted with some big companies on AI strategy. I tell them there are two approaches to AI.

1) Train AI to replace human work. This gives you 50% quality for 10% cost. 2) Train AI to assist human workers. This gives you 200% quality for 110% cost.

Most companies will go with option 1, and it's a race to the bottom. Eventually, someone will go with option 2 and gather up all of the pieces and take over the market.

I posted this elsewhere, but I think it still has a valuable insight to bring to the table: https://halecraft.org/software-engineering-is-the-new-manufa...

> LLMs are regression-to-the-mean machines--they pull junior developers up, and drag senior developers down. Taming them requires trading the romance of 'code as craft' for the physics of manufacturing.

The thing I don't know is: how do we decide which direction is most valuable? I can see arguments in both directions--quality vs quantity, essentially. I think there's a strong argument for the value of both:

- we need more quantity of software: for a long time, the ability to write software has been locked up, confined to a closed cabal of specialists

- we need more quality in software: we depend more and more on software in every aspect of our lives, mistakes are intolerable and should be avoided

> I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.

Don’t sell yourself short! Taste is not promptable, I suspect good taste is AGI-complete.

Especially in domains like fintech, there is a lot of accumulated wisdom, and that is what you’ll be handsomely paid for (for at least the next couple years :/ )

For example, architectural patterns, when you need bitemporality, immutable logs, CQRS, all these good patterns that can only be learned by owning years of system architecture - none of these feedback loops are in the training set.

And from a product design side, agents will just miss key concepts and you need a few words to prompt a fix - but that might represent a massive tree search optimization, or the agent on many cases would just fail to identify the requirement. These small steers feel small, but by evaporation our work has distilled down to just the extremely high value insights.

METR task time is still at weeks, doubling every 7 months; it’s years (assuming we keep riding this crazy exponential) until you hit multi-year tasks. I don’t see wisdom / Métis being solved in 2027.

All this said - I think it’s important to extrapolate forwards, if the trend continues, this will may all be true in 3-5 years. Now is the time to pre-register what metrics would make you worried, so that you can define your red lines. There will be a rapid consolidation of power and wealth if these tools continue on their existing growth trajectory.

Like all my C skills that I spent ten years mastering aren’t that useful either. But being a hard worker, smart, able and eager to learn new things, and able to judge accurately if I am helping people out (boss, coworkers, customers), these are and always have been the keys to my being a good hire. It’s a great world for smart, kind and hard working people. No idea where the LLMs are going but it will be interesting and I will be able to use and explain them in useful ways for people.

From someone who thinks there's too much AI doom right now and is a glass half full optimist: If you are a software engineer reading this and panicking, don't. The author only mentions his codified, stable knowledge like you'd get from a distributed systems O'Reilly book.

There's no mention of the functional elements of a software engineering role - incident response, working with auditors to define and maintain controls for internal services, handling escalated account support & fraud, working on DevEx, selling shovels (MCPing your consumer-facing APIs/services), getting on customer calls to help sell your company's X feature, managing people downwards and upwards.

The piece kinda reads like remorse over sunken costs and attachment of knowledge to personality. If you twiddle your thumbs and stay static in your role, you will be replaced. It's the differentiation that sets employees apart. And attaching yourself to functions instead of knowledge is the only way to stay afloat.

I think this is the first time I saw someone describe so clearly my concerns and experience with LLMs.

I have little to add to it, except that I agree completely. Not sure what’s next

> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.

I think the author downplays how much of that knowledge is used on knowing what to zoom in on, what to prompt, or what to look for.

Author says Claude now one-shots distributed systems bugs that used to take him two days but most top comments here are still playing down frontier model capabilities.

Are we collectively in denial? It's understandable as the craft as we knew it is being disrupted by tools that have improved at an astonishing pace.

Yeah the writing is on the wall. Not just for knowledge work, but for jobs in general, as I've been saying in other comments. The era of wage labour, and this dominant economic system, is coming to an end. There's no way it can coexist with AI, but it also needs to continuously push for better AI, which means there's no stopping it. The only thing to do really is brace for the disruption - which will likely be pretty rough - and hope governments play their role properly to ease the transition.

Do any of us? But I think it's kind of backwards the way it's presented in this article; the raw code part it has down more so than the design sense.

I also would point out that, while this thought has occurred to me about the skills being commoditized, in practice I don't see that everyone's getting the same results from the tools. Not sure what's going on but that's interesting.

Interesting that this dev sees domain knowledge as the most important part of his job. Over my nearly 30 year history, I consider domain knowledge as the least important aspect, and in fact have experience of many varied domains. 3 years web development, 2 years systems administration, 5 years point-of-sale / payment systems, 3 years performance management software, 16 years games development, 2 years GPU development tools, etc.

In every case when I've shifted domains, the skills that have got me the job were demonstrable solid programming experience on a wide variety of systems, with only a tangential link to the new company's business. In each case, I've gone in knowing almost none of the domain knowledge, but it's never been a problem because the business analysts know that stuff and tell me what they want me to do, or it's been stuff I've been able to pick up in the first few months.

For example, when I switched to games development it was the combo of systems admin and web backend development that the company wanted, I actually used none of those skills in the first year doing what they hired me for, and pretty quickly I'd transitioned from that to become a rendering engineer, and I've now spent the majority of my career optimising shaders and game engines.

So for me, it's certainly the case that I value my adaptability across domains, and I'm not worried about having to shift to another business domain because I know I'll be able to produce whatever it is they want if there's a reasonable spec in place.

Sure, when hiring if you have 2 candidates - 1 with the exact domain knowledge you want, and 1 without, the one with domain knowledge has a head start, but in the case where nobody has that domain knowledge (or in the case of the article, it doesn't matter because AI levels the field), then I don't think it matters much. Personally, I'd rather be the person with the broadest skills and able to pick up what I need than to have been stuck doing the same thing my entire career.

Jobs have always been a bad deal, especially for most people. Very unfair. Less unfair is entrepreneurship. LLMs (VLMs) etc. should make that more feasible for a broader range of people.

There’s one force where software engineering is being automated by LLMs, but the other force is that there isn’t really much more software that needs to be built. Even before AI coding became big, back in 2021, we were already in late stage SaaS territory where each new idea was an increasingly minor variation of an existing idea. There were no new GitHubs, Herokus, Stripes, Salesforces, Instagrams, Reddits, just variations of those for more specialized markets.

It’s really unfortunate that AI hasn’t raised the ceiling on the space of possibilities as much as it’s raised the floor on how much can be automated, we’re all getting squeezed in the space between.

>Of course, I'm still employable because someone has to review the code and steer the robot...

We will work for the robots, steering them to steer us.

I’m excited about the genAI future. I’m a software engineer interested in product, user experience, architecture, and entrepreneurship. After 4 years in the industry, mostly within fintech, I have gotten tired of slow organizations, company politics, nontechnical managers doing the decisions etc.

I’ve saved up a couple of months of salary, have a couple of bootstrap ideas that I believe are within reach for me equipped with a coding agent to build. Hosting can be done almost for free. What used to take entire teams and hence millions of dollars to build can now be done a lot cheaper. If I’m lucky one of those ideas can pay my bills soon. If not I’ll go back to consulting for a couple of months.

I code myself now and have given up on LLMs, no matter what, they eventually make a codebase unmaintainable. The uncertainity of LLM generated code has been screwing up with my peace and guarantee I have when I wrote code myself. LLMs are not AI they are Jack. Jack of all trades, Master of None.

I don't believe agents care less about architecture than us. Badly architected code has the same effect on them as on us, namely to slow them down and degrade the quality of their output. Which translates to the same thing as well, loss of revenue.

Coding agents are driving up the value of architectural skills to the detriment of more specialized/technical skills.

> I still have one pillar standing, though: code quality and software architecture - what's now being reduced to being called "taste".

Genuine question: what exactly is "quality"?

It's something I've been trying to understand for a very long time. It seems like it's entirely contextual, and it has both subjective and objective facets (the latter only for quantifiable things, and still entirely contextual).

I still struggle to accept this when my colleagues are producing implementations with AI assistance that are consistently broken and don't do what they think they do. As yet I can't square this circle, no one is better at their job than they were before.

I feel that I am faster and better, sure, but trusting self perception would be an absurd thing to do.