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

> ”If you don't steer them, they'll hit a circular dependency issue sooner than you think. Will duplicate code. Add unnecessary comments. Mix up pure functions and side-effects. Disregard the principles of SOLID.”

This is one thing I worry about with AI-driven development on large projects. Every time someone comes along to add a feature it’s likely to lead to wheel-reinvention: dropping in a new bunch of AI-generated code rather than specialising, refining, and reusing some existing code. As the years go by this is going to lead to complex, hugely bloated code bases that are only maintainable by AI tools…

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.

I see many comments saying, "AI can't do X with 80-100% accuracy; therefore our professions are in good hands."

While I don't want to sound overly pessimistic, the models are improving at a rapid rate. If asked ~3 years ago where the state of the models are today, it would sound like sci-fi if answered, "the models are creating full MVP apps in ~30 minutes with one prompt".

The hurdles the models are facing now, like reducing hallucination rates, ensuring compliance, and keeping a clean codebase, do not seem far away from being resolved IMO. Fetching specific information is already partially done with various MCP servers / RAG.

I am, of course, a bit worried about the future of software engineers. If these quirks are resolved, where do their professions fit in the industry? Delegating tasks to the AI model? Unfortunately, this does not require years of expertise, which is a double-edged sword. Reviewing AI's output? Ask it to explain each line not understood.

I think we will see more waves of larger layoffs, similar to how human computers were replaced by digital computers. To some, doing complex mathematical calculations mentally is a fun task / challenge, but it is ultimately significantly slower and more error-prone than calculating with a computer. In the same way, I think hand-crafting code will be seen as a fun "challenge" and AI will be seen as the "modern-day calculator".

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 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.

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.

> 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.

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.

> 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.

There's no doubt that LLM increased our efficiency, be it producing prototypes, generating production code, debugging our systems, and more. So, if there's no more demand or reduced work hours, some of us will lose our jobs. I certainly hope the Jevon's Paradox kicks in faster, as in months instead of years, let alone decades.

If we don't consider the potential loss of our jobs, on the other hand, isn't it great that we don't have to repeatedly do what we already know how to do? I mean, how many times can we feel the thrill by writing the same CRUD applications? How many times do we have to design the same idempotent APIs? It's also a relief that we could spend way less time figuring out mitigations or root causes when there is a production incident.

This reminds me of the scribes before Gutenberg's moveable-type printing press. They spent their life in scriptoriums copying the manuscripts by hand. They earned three times of the average income of their times. They were highly skilled labor. It required years of training, deep literacy, and a high level of domain expertise. Yet, history showed that even highly specialized expertise can be mechanically reproduced.

That appears to be exactly what LLMs are doing for us: automating the digital equivalent of manual transcription, such as setting up the repetitive boilerplate, sketching out the standard APIs, finding predictable bug fixes.

I'm not sure about others, but I have to face the same existential question today: as software engineers, where does our true value lie? Is it merely in learning, memorizing, and, reproducing patterns that others have already built. More often than not, patterns that an LLM can now piece together better and faster? Or is it in taking everything we’ve learned and applying it to solve entirely new, messy, and uniquely human problems? If our worth is tied to how well we copy the past, we are already obsolete. Our value has to shift from being human repositories of known solutions to being creators who venture into the unknown.

It is, of course, easier said than done. Hence I have likely the same level of stress as other software engineers.

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.

> 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.

Maybe denial is a river in Egypt, but I (most of the time) believe that the glass is half full and we will need MORE humans as LLMs gain in ability. My thesis:

1. most jobs are created by small to medium size enterprise

2. the throttle for new SMEs has been people, money and ideas, in that order

3. with LLMs being a force multiplier, fewer technical people are needed but some people still ARE needed

4. with less throttling, MORE SMEs will be created with more jobs - they will be able to do more, faster, but still need some human oversight.

Also, what is the point of software if it is not to serve human needs?

Also, in open source, community building and tending is a very human enterprise that will not be replaced by bots any time soon. So, as coding becomes commoditised, perhaps the soft skills backed by technical knowledge will be the complementary skill that increases in value.

Or, maybe it's time for me to become an itinerant folk musician.

> "Now I have CLIs that one-shots bugs across distributed systems for me. Bugs that I couldn't solve in the past. Bugs that would take 2 days of full-time debugging. Bugs across distributed systems that lack distributed observability. 90% of the bugs are one-shotted now, including bizarre race conditions, unexpected corner-cases, third-party integration issues, undocumented API edge cases, everything. I hardly have to intervene."

The fact that the author can articulate _why_ the AI is getting so good is kind of a moat for specialist, right? Imagine a layman prompting without domain expertise:

"There is likely a race condition here + [long-winded explanation and analysis carefully guiding the AI]"

Degenerates to:

"This button is not working, please fix. I don't care about code. Decide yourself"

Degenerates to:

"Claude make me money"

Based on what I've been seeing/reading online the past ~6 months or so, I think there's a self-fulfilling prophecy going on here.

Developers are concerned about jobs going away, but how often are they pushing back in their orgs about how AI works? In response to "are you using AI to move faster," how many are responding with "yes, but there are some things you should know..."?

If there's no pushback and just pure acceptance of stuff like tokenmaxxing, then what does anybody expect when the broader narrative around AI is that it can help a novice to grind out miracles (i.e., "holy crap, if this is what a novice can do, what can an expert do?!")?

Of course leadership is confused because (it seems) few are asserting expertise, saying "no," and stating a clear case as to why they're doing that.

The default excuse is "I don't want to lose my job" (which is a fair reaction to all of this, especially these days), but it's worth considering when/how that choice is actually just shooting future you in the foot later. It seems there's a broader trend toward compliance more than there is "you hired me to do this job properly, did you not?"

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.

> 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.

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.

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.

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.)

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?

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.

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.

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.

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.

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.

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.

> 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.

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

“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.

We have all the AI tools you could bare to mention, but we still don't have anyone but programmers shipping things.

Why aren't the designers and PMs shipping things if these tools are so good?

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

> 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.

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.

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.

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.

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.

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.

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.

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.

Software engineers really need to unionise. ASAP.

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.

Every 3 lines coming out of Claude has got a bug in it.

There is going to be a lot of demand for people to clean it up.

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.

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.