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 played with it a bit, and no, it doesn't! And I am talking as someone with limited music culture, musicians are likely to be even more critical.
For the first few tries, it sounds impressive and the tunes are catchy. It used to sound wrong in the background but they mostly (but not completely) fixed that. However, after a few dozen songs, it starts to always sound the same. It is all generic stuff, the songs tell no story, it is a bit like the kind of music that accompany corporate advertisement. You can try to be more precise in your prompt, but I never had any success, it will just ignore most of the details that could make your song interesting.
The most interesting result I had was actually when I managed to get it off rails, a bug more or less. I asked it to mix two very different genres together, and it made something unsettling in a way I don't remember hearing before. But as always, further working on it proved extremely difficult, as it always tried to go back to making generic stuff, ignoring the details you give it.
Suno can do remixes though. And it is a bit like with code. LLMs are very good at porting, when you already have something that works, it can make it work in another language. But if you just have an idea, it will screw up at anything original. If you want a LLM to implement your idea properly, you have to give it so much guidance that it amounts to writing the code yourself, while struggling with the ambiguousness of natural languages.
They don't "solve" execution.
If you're willing to push them enough, and put in place the system that they can actually get working code, they can solve execution - but that IS engineering!!
They are far from doing that by default now (replacing engineering).
Maybe in 3 years. They're moving fast.
But you can't ask them to build you a better Rust compiler, sit back and watch, and get a result today.
That is what takes determination and why you have to really care about the thing you are trying to sell to people. You have to stick to it before they will stick to it.
https://x.com/chamath/status/2033385903520129161
> 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.
https://en.wikipedia.org/wiki/Sturgeon%27s_law
Sturgeon's law states, "Ninety percent of everything is crap". The adage was coined by American science fiction author and critic Theodore Sturgeon while defending the merits of the genre. Sturgeon observed that most works in any field were low quality. Therefore, science fiction was not uniquely inferior.
As an information architect I find it amazing it works so good, but is useless to me except being a great think to play with… a toy really. I’m much more fascinated by Strudel.cc and LLMs do a great job to educate me into it, myself being mostly an autodidact.
As a dev I struggle to maintain coherence with Claude Code even though I’ve piped more than 10b tokens since Jan. Certain trivial stuff is easily remedied but even more devil lives in abundance of details now. So the task moves one level above in terms of abstraction, but is not solved.
If guys were good at typing one and the same thing in one and the same lang, which is nothing wrong about given how crafts went for ages, then they will be struggling to compete with the GPTs. But if they are in the architectural and operational perspective … well - work and demand just increased, so please stop whining.
Steve Jobs didn't mean "writing good code" as "execution", he meant "making things that align with how people want to use the product". Frontier LLMs are not solving Steve Jobs-level execution (even in the near future) because what that would mean understanding human nature – something that Steve Jobs or Henry Ford were much better than most in the industry today, so at best we're going to see LLMs making things that are as good as the majority of products. Because AI does not see whether something is perfect-according-to-Steve-Jobs or merely good-code-according-to-engineering-practices.
Good ideas are expensive. They're expensive because you have to weed through all the bad ones to identify them, find a market, and turn them into a product. You don't know that from the start, which is why the landscape is littered with millions of dead projects from thousands of dead companies.
Even if the execution were cheap and implementation were perfect, if the starting idea was bad, it's all been a waste.
Ideas aren't cheap, because bad ideas are expensive and good ideas cost money to vet.
Does it? It produces passable stuff that is fine. However the lack of passion and care completely disinterests me.
In this case, it's difficult for me to see what exactly is gained by offloading all of those decisions to a mean regression algorithm. I agree it's a fun toy, but I can't imagine actually listening to or deeply enjoying any song made with these music models.
I could imagine it being used successfully in some targeted part of the process. For example, manipulating drums or changing the timbre of some previously recorded instrument. In that case it's not much different than traditional music creation tools like sampling.
Suno doesn't make music, it makes simulacra of music. Music is only made by humans.
It's great that people find joy in it, but as someone that is critical of both music production and fidelity, the current offerings fall incredibly short of anything I would ever want to listen to.
It is the whole business flow chain of value to the end user what is valuable.
No. I assumed that at best it will be not better than average human-made music available to listeners.
> but it now produces really good stuff.
Does it? Do you have examples?
(note: I actually do not care about all "hand-made" and have no preference for once-off over serially made products)
The same is true for LLMs. You can get Claude to spew 2,000 lines of garbage in 15 minutes, but the number of developers actually willing to sit there and reason over the output and make the tweaks--often very minimal tweaks--that make it go from 90% correct to 100% correct are vanishingly few. And it's typically just laziness and a lack of any kind of genuine interest in the field.
Except this was not the case, it had of course hallucinated what the regulation actually required (I know this because the code in question had already been reviewed by human counsel). This is (supposedly) the most bleeding-edge model available.
We use a lot of genAI to help us write code, but there is no way in the mid-term we could ever rely on these tools to actually build compliant financial products. We'd have to be totally mad. Yes, lots of Fintech companies are using these agents to accelerate, but anyone who's using them to actually ship product without a human actually digging into it is opening themselves up to a world of risk.
But how are you so sure your colleagues are not more "expert" than you? Prior LLMs there was room for very good engineers and mediocre engineers to work together in 99% of the companies out there. With LLMs, only the "best" engineers will survive, because nobody needs mediocre engineers anymore.
This being HN, I imagine every engineer reading this thinks they are in top the 10-5% of their company/city/country, and therefore they think they are not "mediocre" engineers that can get affected by the introduction of LLMs. Statistically, they are probably wrong. So, it's all about ego. Chances are you are not a rockstar and LLMs will eventually take over your job.
As usual, the only winners here are corporations and executives. Most of us are the last monkeys in the chain, and so we'll get screwed.
I understand the frustration of spending years nurturing a skill and then seeing its value decline.But this isn’t really an LLM problem. The same thing happened to factory workers, typists, draftsmen, and many others before. The technology changes, but the underlying issue is the economic system we live in, where the market can suddenly decide that something you’ve spent years mastering is worth much less than before.
LLMs are not creating that dynamic. They’re just accelerating it.
I am not sure but for complex cases it seems to me that the earlier sum of moderately long PR time + moderately long review time has been replaced by very short PR time + even longer review time. I am not sure if there's a net gain in these cases. Sometimes even if the code is functionally correct, it's verbose enough (e.g., too many intermediate functions) that I think they will impact future reviews.
Dunno how much longer that is going to remain true for your specific employer - all the fintech companies I deal with personally have had some sort of AI account for their devs since last year.
Even places like jane street have employees posting blogs (one of which was on HN frontpage about 60m ago) saying they mostly direct agents.
How long do you think your specific employer is going to hold out?
I'd posit there's another layer. You have domain knowledge, certainly. But more valuable still is the wisdom to find more.
Anthropic and OpenAI can stick financial regulations in the training data all they want, but the AI systems will never learn to anticipate the future, or reach out to clients, partners, or regulators in complicated situations.
A lot of companies are investing money on “ai factories” that are join to automate a lot of software development (that is, steer LLMs) on the basis of jira tickets (or linear/trello cards or whatever).
Most surprising to me about the article was the desire for OP's company to use AI for design docs. I feel like AI-generated design docs are some of the worst -- basically treating English as a programming language. They aren't enjoyable to read, and they often miss the forest for the trees. A human written sketch explaining why we're here and what we're working towards is still meaningful and important. If you want code-level details of every decision and algorithm, we have code for that.
I have mixed feelings on whether these documents are useful LLM inputs. I did a project where I carefully paired with Claude Code on producing a specification that another model would actually implement. I'm not sure it saved me any time, and it was very un-fun. (I kind of blame Opus 4.7 xhigh for this. It ain't speedy.) I feel like I can nitpick code to get exactly what I want, but defining exactly what I want an auto-mode LLM to go and do, in English, is much more difficult. I don't think the PLAN.md I generated would have been useful for a human trying to understand the system (too verbose), and Claude Code still made its usual mistakes that I have reminded it a billion times not to make (t.Context() in tests, not context.Background()!), so I'm just not sure it was worth it. I would say I probably wouldn't do it again in the near future. A rough sketch to get humans on board and to get the high level details worked out, written by hand, and then pairing with the LLM on actually typing in the code seems the most productive to me. But I do try to go outside my comfort zone once in a while to test the edges of these tools. They are very impressive and are worth a lot of the hype. (I know I will never write a YAML file again. I hate it more than anything, and Claude is amazing at it. But I worry I wouldn't feel the same way if I hadn't already had 8 years of k8s experience.)
If you build your environment to be specification based, you have to make sure you have good specifications. If your "memory solution" uses freeform markdown notes, you already lost from the start.
Also choose languages with good unit testing built-in, and languages with unified code styles, and unified toolchains. If you use C++, assume that there's a million ways to build your algorithm. If you use JS, assume 10 different build pipelines. If you use java, assume bloat by dependency hell.
LLMs mimic the ecosystem's variety and variadicity(?). Languages like Go shine so well because it's a very opinionated language, where there's only one proposed way on how to implement things. And that's a good harness to begin with. LLMs are like children on the playground. You have to build better rulesets and fences to make them behave how you expect them to.
Also, check out qwen3.6 coder and heretic models. 30b is the sweet spot for coding and unit testing. For planning and designing, gemma4 is pretty good.
Love the metaphor. Planes are sophisticated machines capable of auto-piloting, but humans are still needed to ultimately pilot the beast.
it only matters what upper management think, and its clear that more and more companies value "good enough" and reducing costs over "good"
I give LLMs snippets of text messages exchanges with my wife and I can't believe how dumb the LLMs are of getting basic facts right let alone nuance.
I'm 100% not one those "LLMs are just stochastic parrots" people, but coding and coding-like activities are extraordinarily well fit for LLMs, but for things that there's less training data, LLMs probably do a lot worse
I like your comment, want to try to expand on it
Comment long but there is a TL;DR at the bottom
My theory is that there are 4 areas to domain knowledge worth taking about here - there may be more but I like 2*2 matrices
1) explicit internal requirements - core of how the how the app should work towards achieving your business objectives - code expresses what should be done and to a pretty large extent, why it should be done - from business unit requirements - we are building a tool to do “X”
2) implicit internal requirements - core of how the how the app should work towards achieving your business parameters and constraints
eg profit = selling price - ( total of costs )
- code expresses what should be done but really can’t express why. At best it is in the comments
eg if market is EU then tax = 30% (or some value for a table), AI can see what is being done but rationale is not explicit3) implicit internal requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments
eg if item is “rocket” , shipping = $1m ( we only make rockets in Antarctica and shipping from there is $1m)
4) implicit external requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments
eg if item is “rocket” , add a 3 month gating stage to get approval from government to sell the item and do not collect payment till gating approved - AI can see the code but has no idea why it has to be done
These come from partners, regulation, compliance, auditability etc
So, my theory
AI can be good at the explicit stuff trivially (1, 2) but cannot be good at the implicit stuff (3,4)
It might be able to figure out implicit stuff needs to be done but will probably not be able to figure out why it needs to be done and it will definitely not be able to definitively figure out edge cases for when to do it / not do it
As long as you focus on implicit stuff, you will be fine for a little bit
TL;DR - become good and keep being good at being the person who understands the implicit external drivers of software dev
> 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.
There was an entire thread a week ago about how domain expertise has always been the real moat: https://news.ycombinator.com/item?id=48340411
I'm old enough to remember the dot-com crash, specifically the years afterwards. In 2002-2003, the unemployment rate of software engineers was something like 40%. In fact, the only reason it wasn't higher was because of the number of people who had permanently left the field to become plumbers (or other trades).
I think this is going to be worse. In the dot-com crash, what really happened is that non-businesses got funded and it basically the capital markets ceased to function to a large degree. That's not what's happening now. Yes, huge amounts of money are going into AI companies but the change is more structural.
Other industries have gone through this. In the 1980s a bunch of industries were intentionally destroyed or offshored in areas that have never recovered. This has continuing social, economic and political impacts. I think people are being naive here thinking this can't or won't happen in tech.
I'm not sure that's universally true. Good software engineers who are arrogant about easily acquired domain knowledge have been the downfall of many an ERP system.
There's SO much IT that's literally all about putting business rules into the system.
Partially disagree. Broad-strokes domain knowledge can be learned quickly, but honing that domain knowledge with nuance and consideration for complexity, particularly for organisations that are unique and are not often thought of as 'software development houses', can take years if not decades.
Yet I still see (and code review) 'professional' software developers that don't follow good software engineering practice.
> Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering.
The same is also true of engineers without domain knowledge, certainly in my experience. Maybe we just got unlucky...
Can it? I'm of the opposite opinion. You can improve methodology much faster than gaining specialized knowledge.
You can enforce and fast-track the former because it's a matter of approach.
The latter is subject to the person's learning affinity, capacity and availability at the time and can't be forced beyond reasonable facilitation. It also builds on itself, with the corollary that there's a much steeper curve early on.
With that said, there are still many SWE principles that are not fully internalized or adequately practiced by domain knowledge experts, and that will remain the case as much as domain knowledge remains valuable, because software engineering is yet but another domain.
If you’ve been lucky enough to get jobs that expose you to the right things then you have a big advantage when the interviewers are looking for those specific things instead of your generic abilities or potential. It feels nice because you’re competing against a much smaller pool of people.
Unless you are not lucky enough to have been exposed to those specific domains yet. You can be a great engineer and even someone who learns quickly, but if you can’t point to the lines on your resume that match the job description then nothing else matters when the interviewers are playing experience bingo with your resume.
The move to generic coding interviews changed that. It was no longer enough to say that you had exposure to a topic at a past job. You had to show your coding skills, too. It wasn’t enough to ride on your credentials any more, which was highly frustrating to the well-credentialed.
However if you didn’t have the exact experience then the world of job opportunities becomes much larger. The people I know who like coding interviews the most (other than the rare competitive programming enjoyer) are people who are highly talented but came from less credentialed backgrounds: They don’t have an amazing university on their resume, they had to work at some company you’ve never heard of in their small town, but they are great at programming and just want a chance to prove that so they can move up to better companies. They’re never going to be picked by a company that’s looking for exact domain experience, but as companies open up job listings to people without that exact experience they have a chance to prove themselves.
The other people who relied on that domain experience to lock other candidates out of the hiring process don’t like it at all, though.
What kind of domains did you have in mind?
The best people I've worked with were the people who learned the ins and outs of the business they were making software for, not the people who learned how to write code really well or read logs or learn software architecture patterns. Those people (and I've been one of those people) often go around looking for nails for their hammers rather than really focusing on the customer need.
It takes a really sharp brain to pick up and learn an area of expertise that has nothing to do with software development, and figure out how software development makes that domain better.
Applied to real world complex businesses good luck.
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".
Absolutely true, many things will continue to improve in significant ways. However, if we look at the modern history of rapid disruptions driven by technology (a side interest of mine), persistent patterns emerge. Similar to avalanches or flash floods, such periods of very rapid disruption are often triggered by one or more significant breakthroughs in certain technologies. Early rates of change tend to be fast and furious but eventually begin to taper as recently unlocked low-hanging fruit is harvested and those racing through newly found terrain encounter all-new significant barriers and points of friction. Early in such periods, extrapolating the recent extraordinary rates of change forward has poor predictive power. Sudden extreme bursts tend to regress back toward the long-term trend line.
Arguably, the current disruption in LLMs can be traced to post ~2010 research slowly building to the 2017 transformer paper and the adjacent work it quickly inspired. So today is, arguably, mid or late-ish in the LLM rapid burst phase. The rate of fundamental, broad-based breakthroughs lifting all LLM applications has clearly slowed with many of the most impactful recent discoveries being in scaling, optimization, tuning and productization toward specific domains. That doesn't mean there can't be another transformer breakthrough tomorrow but, historically, black swans rarely travel in flocks.
Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.
The first one-shot app was created with ChatGPT in June 2023 - 3 years ago. In my experience, the current result of one-shotting apps is just as bad today as it was back then.
What “full MVP app” are you talking about? I know of none that have been anywhere near production ready. With all due respect, I think you’re portraying fantasy as reality. I would love to be proven wrong.
Ironically, I don’t think tech support is going to be fully replaced by these anytime soon. That’s one place you definitely need to have actual people talking to other people. Lawyers and doctors are gonna be legally protected too because you still need a human to sign off on all those actions though we will probably need far fewer.
Also MVP apps are great and all, but I've seen 0 evidence of actually useful software from all this tooling, if anything all the software I'm using has just become more buggy and less reliable over time
As a fun experiment, yesterday I asked a model to create this for me. It almost one shotted it. After a couple of iterations and 30 minutes I had made what I made over two years. The total AI cost (deepseek api, so entirely usage based) was $0.5.
Now, I didn't enjoy making this AI guided version. And I didn't learn anything. But terrifyingly it has removed the drive to make another 2 year project "by hand". The end result (the runnihg demo) was never the goal. But still I can't now make myself hand-craft what an AI can spit out in an hour for $1!
This is what bothers me the most. I'm old and senior enough that I don't fear for my job. But the AI thing just swallowed my hobby.
That’s my take on this, at least. I’ll never be very good at Scythe, or the most creative role-player, certainly never managed to do anything beautiful in pottery class (although the glazing is pretty).
That’s fine. I achieve enough in other areas ._.
I also don't fear for my job, but it's because I was already laid off 1.5 years ago, right at the start of this AI boom. :/
However, I love coding with the AI. I can get it to handle all the crap that I know what it should look like, but don't want to spend the time doing myself. Instead, I get to focus on making the thing work well and do what I want. I am so much happier coding with it than without it.
Now if I can just find a job to do it in, I'll be set. :/
So first off, I mean, of course you didn't, right? You had already learned most of what you were going to learn from this specific project by doing it by hand.
But yes, if you use AI to do projects that might have been at the edge of your abilities pre-AI, you will learn a lot less. The solution, I've found, is to get more ambitious until you're back to the edge of your abilities even with AI. You should be asking the agent questions like "has anyone tried?" and keep pushing until it isn't sure, and you're not sure you have any idea what you're doing. Then ask questions until you feel like you sort of know what you're doing, and verify your understanding by directing the agent to build.
Such fuzzy times...
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.
Just because LLMs are good at translating English to code, doesn’t imply they are good at many other jobs.
Coding isn’t that hard, it’s just not enjoyable to most people. The enjoyment has always been the barrier to entry.
The people and companies leaning into fully autonomous agents are high on their own supply, in my opinion. They're kicking back in their beach chairs as their pipelines spit out Stüssy S after Stüssy S, with massive architectural flaws and attack surfaces, just lighting gobs of money on fire.
Yesterday, I created a fully functional POC for something really cool, it took me all day as I reshaped the agent's rough boilerplate ideas into usable components, and I never once hit a session limit on my $100 month Claude sub. I spent the majority of my time thinking about how I needed to prompt to turn what was in my head into working and secure code. You can't just give the agent a vague idea and expect anything less than a dumpster app.
It's probably enough to fool C Suite people into believing the AI apocalypse is coming, which is the crux of the problem, and what is fueling what is certainly a gigantic bubble — but when it comes down to it, shitty software is shitty software. To fix it, you have to know what good software looks and feels like under the hood, and why it's shitty or feels bad to use. It might start up, but mutability, staying up, remaining stable, and remaining secure are very different stories.
The clock is ticking on everything that has been developed by a LLM with a novice user behind the prompts.
AI is fundamentally an equivalent to slave economy. Cheap, plentiful workforce. This time ethically neutral. You either get Greece or Rome. I’d prefer Greece but it will probably be Rome. From the past we can predict the future.
Well, except for roles where being human is an inherent part of the value for customers: bartender, prostitute, certain kinds of boutique sales, professional athlete, stage actor, etc. And for roles that have to be human for legal reasons.
Of course such roles make up a small part of the entire job market.
Nope, just knowledge workers. We’re decades away from automating many manual labor professions, even “unskilled” ones.
Turns out brains just aren’t as special as we thought.
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".)
This is the case perhaps 95% of the time.
Oversight is very important, and architectural thinking cannot yet be outsourced, only execution.
This is domain expertise - software engineers are not needed for that. Ofc often senior sws are expert in it, but they aren't necessary.
Traditionally its been useful for frictionless production to have engineers to be able to do maybe 90% of their work without consulting the business experts but this is the whole crux of the moment TFA discusses - "tradition" is over.
In this new world its now the job of a senior engineer not to have this domain expertise themselves, but to know how to ensure the agents have it, or can acquire it and it be verifiably correct.
Senior engineers who hang on to the idea that their advanced business domain expertise makes them safe will soon be as dead in the water as juniors who haven't pivoted.
They are very good at writing code and debugging visible errors- but that's like 50% the harness.
My company also deals with a lot of complex regulations and domain-specific system implementations, which AIs used to struggle with. We were able to solve the problem with well-organized claude.md/agents.md files. On top of that we also implemented supermemory.ai, so newly made decisions are always recalled by AI agents when starting new sessions.
Would a skill which forces you and LLM to reach a shared understanding of the product features and the regulations those features are supposed to capture be of help here? The main idea is we provide documents to the LLM and it asks lot of questions which clear ambiguity and possible misconceptions the LLM might have. I would suggest please take a look at skills. They are really helpful.
So there is a spectrum here, and i dont know what i dont know - meaning i can just be wrong. But we're both on that spectrum and are you sure its not a skill issue?
All of the specifics you list seems so fundamental that in similar projects I've inserted them straight into the AGENTS.md or a strong reference and where to look them up.
If you boil it down to it, you're quite literally saying the problem is the LLMs dont have access to a bunch of facts.
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.
If there is any skill in consistent demand it is the ability to wrap your head around the new work, new processes, new people, whatever it all may be.
For me, understanding and development of this skill into a keen tool happened while I worked as a prototype mechamic. For those unfamiliar, a prototype mechanic does what it takes to make often demanding parts on consistently short timelines week after week.
Metals, plastics, you name it.
One gets good at ramping up on processes, machine tools, materials. And after doing that for a while, you end up able to very rapidly absorb new info and understand work far more quickly and accurately than many.
Anyone can start this.
Just get curious and build things. Then build more things.
Share your builds and build things other people want made!
Overall society feels more turbulent, but this is otherwise all the same song and dance all over again.
The 90s and 00s had this wave of "object oriented programming changes everything". Hey we're doing this thing that's been done successfully 100s of times before, but now it's OO. Writing some code in involving an airplane? Just purchase this omni-airplane object that does everything for airplanes (an actual thing I was told in college).
That's weird OO isn't the be all end all? Code gen, get this Ruby on rails running. Look at me building this website in two seconds. Code gen everywhere.
Huh, that's going to a funny place... TDD. If you aren't TDDing then you're such a bad engineer that you should be locked in prison (real conversation I observed). Oh wait, not TDD, BDD. That fixes it.
Lean, no Agile, no agile like with a small a ... but it was first, no scrum, no xml wait that was last decade, json, and finally SAFe.
Hey, have you seen this chat bot thingy?
Every iteration brings good stuff if you're paying attention. But it also brings a lot of hype and anxiety. Experiment and learn.
The one thing that's remained constant for me is that nearly everyone would rather die than to think carefully about the consequences of their dreams coming true. And as long as that remains true they'll continue to pay for someone else to ride the hype dragon on their behalf.
Except the entire value proposition of these tools is that there is no skill or mastery to be built.
The entire slop factory workflow, or sorry I mean "AI-native" workflow is:
"Woah, I cajoled a chatbot into building something I don't understand at all, I'm so good at my job!"
It's the participation trophy of building. Something else builds it, I take credit for it despite not understanding much about about it. There's no compounding return on my effort. No lessons learned. No understanding built. No insights gleaned for possible future innovation. No differentiation. Just mind-numbingly screaming into a void until the slot machine shits out some slop amalgam that seems "good enough", and then I do it all again the next day.
If that's the game, count me out. It's nice that others apparently enjoy it, I guess. But to think there's any sort of mastery here is delusion. The only requirement to be "successful" with these tools is to stop giving a shit and surrender to it.
But I used to enjoy learning - I think most of us did. The existential crisis many are experiencing is about the lack of fulfilment in rolling an LLM slot machine all day in an already dopamine depleting environment.
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 had people tell me I should try selling some of the furniture I make and my response is always that I made the mistake of turning a hobby into a career once, I don’t intend to make that mistake again, and at least software still pays pretty well.
I work with a guy who does decking (gardens, caravans, etc) and builds sheds, fences, things like that and he does very well indeed (he's also incredibly good at it to be fair)
A small percentage of the market, maybe a fraction of a percent, are still willing to pay for hand-built goods - bonus if it's thoroughly modern but retro (steam-punk keyboards, maybe).
Exactly zero percent of the market is willing to pay for hand-built software.
not woodworking. farming. get a pot of land and grow your own food. do not participate in economy at all. that's the only survival.
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.
Calculators are not a replacement for accountants, online accounting services are in many cases. Which again can be run by an AI if they reach that level of reliability.
Today with LLMs this is still sci-fi, though.
But bread shops are available on every corner. Will software jobs become as common as bread shops? If yes, what happens to the salaries? Something to think about.
If we apply the same argument to software engineering I think it's a good point... just maybe not the one you intended to make.
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.
So in this thread there is a mix of genuine edges that LLMs need harness and guidance with tasks that when given to a human will not perform well in that LLM is supposed to suddenly solve.
Like the thread above about financial compliance, without knowing specifics it can be very vague in language and confusing unless you apply to precedents and exact scenarios that can give you a range for what is acceptable/unacceptable. Mythos or any LLM isn't going to magically figure these edges out for you because a human would also struggle at such task.
My advice is don't let what you read here including my comment dictate your own decisions, but apply the same common sense, apply it in ways that it can help you and figure out when to use determinism vs LLM in the context of your jobs.
These lazy comments that simply try to paint a black and white categorization of AI/LLM are just noise.
Just because an AI seems to know finance/architecture/debugging doesn't devalue authors knowledge of said domain. Its essentially like your coworker having the same knowledge. There's space on the market for both. And if AI gets to the point that it can in fact replace engineers (somehow also claiming accountability?) I'd expect it to be priced competitively enough to make every manager think hard whether to buy and become hopelessly dependent on some 3rd party service or hire an engineer. The market is not a zero sum game.
"Maybe I should consider transforming my woodworking hobby into a profession."
As an AI optimist, I think all forced labor should eventually be done by AI. People can then spend their time pursuing their own hobbies. Just as many people still play Go after AlphaGo appeared, because they genuinely love the game.
In the future, coding may return to being an art form. People will no longer focus on utility alone, but instead on the enjoyment of the process of writing code itself.
And what sort of economic system do you imagine will be in place to support billions of people being able to just play Go all day long? How do you imagine the large capitalistic global powers transitioning into that state?
Great, if someone will find it in them to pay me. Real bad, if not.
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.
You can have the Big Boy LLM do _everything_. It can and it will do it. It will also cost fucktons of money and take a long time.
But if you build tools (with AI) that do as many tasks in the process deterministically as possible and let the AI use those, it'll be a lot faster and cheaper to run it.
As a bonus you can eventually drop the expensive cloud AI and run a small/medium sized local model instead.
For those unaware, Jenkins (Hudson), is a CI server that supports all sorts of pipelines. Those pipelines can very easily be turned into huge balls of mud by putting logic in them. The proper way to do it is to put that logic into simple scripts and tools and have Jenkins just do high level orchestration.
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.
None of this comes out of the box atm, but it's not clear that it's not possible.
fooBar() and fooBarExtended()
The latter had additional params and functionality that was needed for the current problem.
Instead of calling that function though Claude kept trying to add in the same extended params to the first function
Even after telling it not to do that it kept suggesting the same thing again later, its so annoying sometimes
The open question for me is whether too much code is actually a problem.
These tools are a fact of life now. If we can solve problems or debug faster, and the software is less buggy, than it's not too much lines of code, it's just right.
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.
SQL was first released in 1973. More new SQL is being written today than ever.
C++ (1985) is the de facto standard implementation language for web browsers, JavaScript engines, networking stacks, telecommunications, video games, high speed trading, CAD/CAM, video rendering and editing, audio processing, filesystems, databases, hardware drivers, automotive, aerospace, and robotics, among others.
Is Rust making inroads? Sure, and it's a tiny fraction of C++ still. It's a long ways from being the standard.
Likewise, Python is often cited as the "AI language," but that's on the surface -- CUDA, tensor libraries, inference languages, GPU kernels, compiler stacks, and so on are usually C++.
Then there's C -- introduced in 1972. Still widely used for greenfield in kernels, device drivers, embedded systems and microcontrollers, filesystems, firmware, network stacks, cryptography, databases, compilers.
LaTeX, MATLAB, Erlang, Verilog, PostScript, Lisp (including Scheme and Clojure), shell scripting (and the UNIX paradigm itself)... the list of old tech that still sees new projects in 2026 goes on.
You seriously believe some vibecoder can write anything remotely similar to MS Excel, which took probably thousands man-hours to create?
Monopolies will continue as Token prices continue to rise.
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.
Right now non-tech people just think AI will do anything they want and are the one in charge of hiring/firing, managing, etc. It's horrible to be a software dev right now, you've to deal with AI and lunatics.
Of course Domain Knowledge is important but, right now it's very hard to have reasonable conversation because... you know... AI this, AI that. I had a customer showing me a Claude vibe coded atrocity trying to convince me it's was a great app, now ask yourself: How are devs even supposed to collaborate with this without going insane? Simple, you can't.
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?
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.
Your local restaurant with thin margins and underpaid staff is an SME
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.
What companies do you consult and on what
If you train an AI in one thing it will become better in the other.
That said, Opus 4.8 and Codex 5.5 both can write code that is higher quality than your average engineer. They are not quite there yet in terms of code re-use, but I think that's a solvable problem.
But that’s not the real goal, is it? The goal is to inflate the stock value, take the cream off the top, and dump the whole business on the pension funds, maybe creating a too-big-to-fail scenario where the government steps in an bails out the industry as with the airlines during Covid.
This is why all the testimonials and narratives are so suspect - nobody knows what fraction of online posts were created simply to sell the narrative that LLMs are this incredible disruptive tool that will change the world, solely in order to create FOMO in the investor class.
In this particular case, I’d like to see links to samples of LLM created codebases for “PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles, bank transfer idempotency”. It should be easy to put an open-source LLM-generated version up on github, right? And if not, why not?
Say you are Anthropic and want to shake up the world of law or medicine or whatever. What will you need? Product managers? You need tooling, software, infrastructure and a lot of it and quickly and you need to iterate really F fast on it as well.
If you automate the development of software itself you will enter a new era in which automation of All The Things becomes an engineering problem instead of a pipe dream. Besides software engineering there is (AI) research/science and robotics. That is the holy trinity. Crack that and it's over.
BTW: "double-entry ledgers, escrows, reconciliation, payment lifecycles, bank transfer idempotency", these all sound like solved problems and also things that are festering with accidental instead of essential complexity. I won't bet my career on those things. Now if you say something like physics or geology, that's a tougher nut to crack.
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.
Yup. Most everything we need was already built in the 1970s. Programmers have been kept busy because we've kept introducing incompatibilities into the mix, like DOS programs needing to be rewritten for Windows, and then the web, and then mobile.
And now they're being rewritten for AI platforms. It may be giving the squeeze due to being the first platform that will also help with the rewrite effort, but it is also the thing that kept the industry going. As you point out, there wasn't any work left to do until AI showed up.
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.
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.
For context, I use Claude and Codex (side projects, Max and Pro plans respectively) and Gemini at work.
The key takeaway I have is: These tools have let me climb up the value chain ladder.
Even with Claude (Max plan, Opus 4.8, High Effort), it makes tons of mistakes, assumes a lot, misses nuance and doesn't really think through every aspect of the problem from every angle. Limited memory, lack of full context and a lack of experience with real world distributed systems means that the initial solutions they offer need a lot of iteration and refinement. Just like any junior engineer would need to do.
So, you might feel that with a LLM, "this should just be an hour" but it usually becomes a 2-week exercise for me.
Which brings me to what I tell my team repeatedly: "the only person with the big picture is you." I ask them to focus on thinking, ideating, refining. Do quick PoCs, talk to customers, discern what they are trying to achive, and what you can do to solve those problems. Work with Gemini (we can only use Gemini at work) to iterate until you are comfortable with the full solution end to end with all the nuances. Then let the agent code.
This moves you up the value chain from being a programmer to a problem solver. That's what software engineering has always been about: solving problems. Don't be discouraged. In fact, I am having more fun, am more energized and loving my craft even more now with LLMs. I am able to write down my thoughts, iterate on them and create a one-pager for ideas fast and get them to my team for them to think about. Sure, probably half of them we discard because it's usually not a "now" problem but we put that in our backlog to dust off when the first customer asks for it.
Problem-solving can be done by an "analyst" or whatever these types of jobs are usually called.
I have little to add to it, except that I agree completely. Not sure what’s next
Who you belong to depend on at least two things: A) How knowledgable is the AI on what you are working on, B) How well do you wield these new tools to work better than before? (Better here can mean many different things).
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.
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.
It was about knowing how to fit the new use case into an existing code base, respecting the architecture, and sometimes rearchiteting the solution. How easy the latter was is really dependent on whether the code/arcitecture respected the low coupling, high cohesion principle.
Now, some of this can be coerced into LLMs but it takes work and careful study of the changes. Sometimes they get it right, many times they do not. So, you have to go back and forth with them. If you know what they should have produced.
SWE is far from dead. We just let too much slop into the codebase because we're overwhelmed by it and not incentivized by leadership to care. Code quality will likely drop to the point where even the leadership will notice and it will normalize again. There's nothing like a high profile customer calling out a problem that was vibe coded. It has started already and will be happening more and more.
Don't worry, the hype will be over in some time.
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?"
However with AI, it feels different. I have seen both technical and non-technical managers tell engineers something to the effect of "you aren't prompting correctly" if they aren't able to get the task done within some preferred time frame.
We are seeing the industry revive metrics like lines of code, number of tickets closed, bug's found (looking at you Mythos), and now even "tokenmaxxing". It's exhausting to push back on. These are all things that we know will be gamed. But the individual that brings this up might be viewed as "anti-ai" or something.
If you're an IC, I do think the best thing to do is just go along with it. Sooner or later we will see more shocked-pikachu-faced executives when they realize that engineers are spending tokens just for the sake of it.
> 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'm lucky to work with great engineers and their productivity and code quality has become even higher. Wish that wasn't the case, but it is, and that puts also lots of pressure on myself to work more and better all the time. It's exhausting.
There are cons too, system's understanding sometimes is not as intimate, which in turn produces less "gotcha" moments that may lead to better design. There's less time to review PRs and make it a choral work.
On the other hand way more refactors and experiments can be run, so again, code quality has improved just because if you have a hunch that something could be done better, you can test it for cheap.
We will work for the robots, steering them to steer us.
We are now manufacturing intelligence (why it's artificial) and it shall be interesting to see how it shapes us individually and as a whole.
While marching on May Day, the woman next to me made the comment that Ai will force every human and humanity to reflect on what it means to be human, all of us at the same time over a short time period. What makes a human valuable beyond their work? Why do we go to other people when their expertise is at everyone's fingertip? What value are we giving, trading, or sharing in the time we have in this world?
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"
(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.
In ML it was even worse, we had to throw away a decade of experience, made irrelevant by the new approaches. Even the most revered activity - designing new architectures - became too expensive to do in real life. Fine-tuning models is what we do now, prompting and evals. Like 90% of what we used to learn is no longer needed. And yes, LLMs can do most new ML activities too, they just need light supervision. I am sometimes ashamed to admit I have stopped coding 12 months ago and never wrote one more line, that after 35 years of coding manually. But I also think we will never be without LLMs again, so no point in preparing for 2016 in 2026
Because the reality is: A generalist can simply not guide the LLMs through the system nor can he/she verify the output. LLMs are force-multipliers and if there is nothing to multiply, it won't work.
As long we don't have AGI, humans will guide AI and if we get AGI, that's not something to even think of anymore. Software engineering was always about automation, if you want to be an artist, you better look for something else.
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.)
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.
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…
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 feel that I am faster and better, sure, but trusting self perception would be an absurd thing to do.
LLMs do not think. Someone has to be in the driver's seat. You're fooling yourself if you think that 99% of the population can use an LLM to write software. Or that they even have the desire to. I can cook, but I often go out to eat. I could repair a leaky sink, but a plumber will always do a better job. The specifics of our jobs are constantly changing, but our role in society will remain the same.
One-off scripts can be written with non-technical prompts, but this work was already cheap. To do anything meaningful you need to be able to reason about a hard problem as a whole and at the implementation level simultaneously. Specifying context, tasks, structure and style, data representation and control flow, these things are software engineering. You are simply writing software in natural language. It has never been about the syntax.
There are also practical constraints that could slow or reshape this trend: the growing cost of AI infrastructure and data centers, environmental impact, regulation around copyright and training data, and a likely shift toward specialized domain-specific models instead of a few generic ones. On top of that, if LLMs become the new search engine, advertising and commercial incentives may erode their neutrality.
Finally, LLMs depend on a constant supply of high-quality human-generated data, but they are also reducing the production of that data (e.g., the collapse in Stack Overflow activity). We are also in a very unusual market phase, with a handful of companies heavily investing in and cross-subsidizing each other. It is not obvious that the current pace of scaling can continue indefinitely, or that today's AI landscape represents a stable long-term equilibrium.
There are other factors, like adoption of frontiers LLM in the market that is anyway slow, also the impact of AI in the economy that is anyway based on humans that must be controlled (because it has consequences when it comes pensions, consumptions of goods, etc.. )
Sorry: I used LLM to summarise my points to avoid long wall of text :D
Only the best humans with insight, intuition and pattern recognition and application in non trivial scenarios can fill that gap.
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 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.
But however effective LLM may be now, shouldn't they be even better if trained on and working in really, really good codebases?
We have a senior guy who is like a walking cybersecurity library - knowing all the protocols, standards, vendors, threats. He is quite desperate atm. There is nothing he can add to what LLM already knows or can research in 30 seconds. He was building his profile for 30+ years.
I am on the side that AI will change everything. The reason why it has not yet is the lack of skills on the market - no AI transformation leaders. My strategy is to be closer to AI - number of nano startups with few people on board building smth AI related is exploding and they need expertise with AI engineering.
Let me just say AI is not nearly as good as the billions of dollars in marketing spend say.
We are months away from catastrophic bed shitting and the tech industry will pay the piper.
The time ahead may be rough given the transition period we're in but Software Engineering role (or whatever we will call it in 1-2 years) should not go away.
LLMs surely will be able to do most of the individual work Software Engineer needs to do, but blending them all together is a lot harder task. And once we have AI doing that too, well, I believe at that point vast majority of knowledge work can be replaced by AI too and this is not a Software Engineering problem anymore.
Think of it this way, who needs engineering managers, project managers, scrum masters,etc.. if they're employable then surely actual devs that can tell what good architecture is vs bad, good code vs potentially bug code is are also employable.
But the number of devs needed, that demand will obviously decline dramatically. At the same time though, there are other careers that require programming and software dev as part of your skill set. Simply integrating LLM-enabled solutions into real world workflows is a new area that's very young and immature.
Let's not act like we're suddenly in some sort of post-scarcity utopia where all problems are solved by LLMs, where tech can solve problems, there is demand for those who can use technology to do so. However, I see a lot of people attacking the technology and resisting change a lot, and to those I suggest they look up every single technological revolution and see about the fate of such people.
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).
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.
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.
Besides, you can look at the websites/apps/software you use everyday and evaluate whether or not the agentic era has produced better results. Personally, there's still plenty of bugs and annoyances. Banks still using SMS 2FA, library breakages in minor version bumps, inconsistent UIs between web and mobile, etc.
If all that was a hurdle before... because humans, regulations, or something else... then surely these magical machines that can supposedly replace us and do it much faster would've handled it by now? And they wouldn't introduce more bugs[0], would they? ;)
I think that if you are a skilled software engineer and can adapt, you will be amplified in all aspects. If you just like writing artisanal code, you might have a bad time.
I’m not planning on firing people, but I am planning on building more, using more tokens, and less app subscriptions.
One aspect of building that doesn’t erode is human values.
LLMs don’t create software with zero direction and although I do have 12 agents building constantly, I run out of attention to increase that to 100.
Is it really though? Access to information is quicker, but you still need to know what ‘good’ looks like to leverage it effectively. I can prompt my way to a medical diagnosis, but I’d still want to run it by a doctor.
They're often wrong, dumb, and would turn any code into an unmaintainable mess in days if left unchecked.
I use LLMs every day because I can do less work at my job, but they suck and I would never use them for a personal project besides for very isolated and self-contained components.
It's a lot of marketing and hype.
It seems like new tech is something most of us have to lie down and accept as the new reality each time it's invented, barring full-scale rioting. Much as with the Cold War.
Or maybe it's more than that: maybe I'm off-put by people who have no need to be in the immediate AI race spending a lot of money to get ahead without asking what near-term problem they are trying to solve. It's depressing and makes the whole field more depressing. My advice for them (if they cared) would be that soon all this will be even more batteries-included, to where any dunce can dial up a production-ready app with a sentence. There's no need to rush; when it happens you'll be better off not having wasted millions trying to be on the bleeding edge.
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.
Nobody wants to think anymore. Coworkers are now just intermediaries for their LLMs. Talking to them is just talking to the LLM - sometimes directly copied and pasted, sometimes minimal effort to conceal what they’re doing. It is so disheartening.
And the sad part is, LLMs are incredible and can enable you to do much better work if you can stay in the loop, and stop focusing only on shipping speed. But from what I have observed, very few people care to do this. Who cares about substance when middle management thinks your productivity is 10x?
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.
Who sometimes has to deep dive & mentor a agent on solving the right problem.
Usually when a human self deludes they do it when they're identity is under threat. People would rather hold on to identity then face the truth at the cost of their identity. That is what is going on in almost every HN thread that has to do with this topic.
A good example is religion. Someone who is intelligent, but born into a religion, will have a hard time giving up that religion EVEN when presented with logical/rational/realistic arguments for why that religion is false. They will rationalize the most convenient reasoning to maintain their own identity.
I mean think about it. Even the concept of religion is obviously false. It's not science, it talks about phantasmic beings that OBVIOUSLY don't exist. It's inconsistent among different groups as in there's thousands of religions in the world and nobody thinks the obvious of the fact that if only religion can be correct, then most of the world is fundamentally believing a total lie.
Anyway, the same thing is happening with AI. AI is eroding our identity as software engineers. So you'll see rationalizations in this thread in attempt to protect that identity. The biggest excuse is LLMs are hallucinate and are often wrong and fortunately for humans... this rationalization still works because it's still very true.
However what people are not mentioning is the obvious. People are avoiding it because they are delusional. The topic of this thread is "erosion" of "software engineering career" AND that is utterly true. ADDITIONALLY the error rate of LLMs have been going down. AI in general is improving. The erosion is real and obvious.
But you will see here on this thread that people are not talking about the erosion. They are holding on to the one last rationalization that is a differentiator without ever thinking about how that differentiator is "eroding" even though "erosion" is the LITERAL topic of the conversation.
If productivity is really getting better, regulation can force that productivity to go into increasing software quality.
Why aren't the designers and PMs shipping things if these tools are so good?
Your job is now to get the LLMs to write good code the same way you would do it if instead of AI agents, you would be leading a team of humans.
Does this imply the future of LLMs is either that they acquire reasoning, or that they (or even engineering itself?) reach a plateau if humans are no longer writing about how to do things because the humans are using AI?
Look at prompt engineering, and how quickly it became a hot thing. Does everyone know to steer their AI well? There's only so much a harness can do for you once you start attempting to one shot with a single sentence of 4 words.
As others said, "write a Rust compiler make no mistakes" can only work if you overfit a harness to that single prompt. Nobody is going to do that.
So the part you mentioned about the knowledge you accumulated around how to know that "trade-offs between implementations" and "idempotency to prevent double-charges" is just moving to the domain of the english language and tokenizers. One could argue here that this is far more interesting as it requires you to explore deeper into how we communicate and describe the world around us. Reminds me of physics and math.
I think there's an optimism lenses to it if you can grasp it as an opportunity rather than an inevitable doomsday apocalypse.
I guess they don't want just any script kiddie. And that seems very logical to me. So I don't really see the big issue. They still want experts. You just shouldn't do the same stuff you did last 10 years.
I feel like many of my peers are beating around the bush on this topic and in denial. Even if you accept it can do a large portion of the technical part of our work, we are just supervisors at this point making sure it doesn't do any stupid shit. What is the point? Where is the fun in this? Where is the challenge? At least I have enjoyed building my career over the last 20+ years and building software, but find little joy in the work I'm doing now.
I think we're going to see a massive exodus of folks leaving the profession and a huge mental health crisis, long before the folks working in other sectors realise what's hit them.
[1] https://deanclatworthy.com/2026/02/09/the-joy-of-programming...
I had a friend in LA who was sure that CSS and HTML were enough for her to be a "Senior frontend developer". This year she moved to Tennessee and is trying to find a rich husband because she can't find a single job.
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.
Constant use of AI will probably erode that knowledge over time just because of not practising it, but successful use in complex domain needs the domain knowledge to steer it away from icebergs or hallucination or model flaws.
'Maybe I should consider woodworking' - Fuck off.
To me, the game has shifted from just “knowing how to code” to being really good at something specific. General software work is becoming cheaper, while deep knowledge in a niche is still hard to replace.
LLMs are speeding this up, but I don’t think they started it.
Coding agents are driving up the value of architectural skills to the detriment of more specialized/technical skills.
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.
You’ve already faced this the entire time with… libraries on github.
If employers knew how much you can just use a new standard library, or ask you to “use React”, that’s a lot like asking you to use an LLM to speed things up. You also benefit from the collective wisdom of a lot of people. Do you write assembly or pixel shaders by hand?
The ability to orchestrate intelligence is a magnificent power that few have, and while barriers to entry will be eroded, it will take time and they won't be eroded fully. This is your edge.
I think that in a product-centric or mission-centric perspective, effective automation is good, because it frees you up to do other important things. E.g., in gardening, time spent weeding, is time not spent surviving slug armageddon.
All the other white collar workers are in the same boat. A pillar of the economy is going to be destroyed with no obvious replacement in sight.
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.
Ironically the entire blog title is the "human in the loop", is probably the biggest counter argument for this FUD. The AI will never ever be concious and responsible, and to function and govern properly in the universe you need to be concious. AI I repeat will never ever becomes one. Not even in the popular fictional Star Wars movie franchises where you can have cute robots but they all devoid of the conciousness for the ever powerful force. Heck even the clones cannot control and balance the force, the Star Wars ultimate conscience.
>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.
Actually overall it's definitely a very good thing for humanities. For example, currently it's very difficult to become a medical specialist and most medical students just stop at GP. But globally there are severe shortages of medical specialists for example typical cardiologists to patients ratio in developing countries is about 100,000:1, and for neurologists it's even worst.
Let's say with AI enabled tools and LLM now these GP can upgrade themselves to become cardiologists easier than before. Let's say due to AI/LLM suddenly there's a big jump of the ratio to 10,000:1 or 10x incraese and improvement in the number of cardiologists without degrading much of the quality of services. Imagine if the typical waiting time for important and necessary procedures like angiography now is reduced to merely days or weeks rather than several months or up to a year. Thus naturally the salary of cardiologists will be not be as high as now, but they still will be compensated handsomely. But as humanity do we really care the cardiologists family just live in semi-D landed houses instead of bungalows, not much me think.
My challenge is seeking good resources for the business skills. I'm doing sales for a passion project for the first time, and it's teaching me a lot. I'm just confused still on why it feels so hard and why I can't find an easier way.
Agents merely accelerate and equalize the playing field. And they cost money. We might be a dying breed, but we are the best operators of this technology. And if we want it, this is our moment.
Yes, get into wood working.
I've shared a story before that between now and 2 years ago a developer who solely relied on AI has produced the same hot garbage instancing system within the same time period. For example back in my day in 2 years I went from writing a system that struggled with few hundred players to one that could handle thousands and far beyond that. The person using AI 2 years ago wrote a system that didn't work and wrote a system 3 months ago that doesn't work.
Everyone is saying how great AI is, but they're missing that the driver is just as important AI wouldn't be able to achieve any of this without capable (often seniors) using it and giving it guidance. It's really a difference between "it works" and "it works without flaws".
Of course AI can produce things that also "work without flaws" with solved problems and someone "recreating" something that already exists with AI is not that special, a junior developer could accomplish the same thing given the time.
But I do agree that AI becoming part of performance reviews and all that is producing more productive developers which is going to drive the cost way down. In a way AI is stealing from a developers salary and giving it to the AI companies which is pretty ironic considering how cold developers seem towards artists.
I thought about going back to college, learning Math, Statistics, advanced Machine Learning and applying for research role at a frontier lab.
That's a super silly take. As much as I did math and even course on machine learning back in the days and I was making basic perceptron in code at university - to get back and be able to do so on frontier level that's years I don't have anymore.
Anthropic is doing all that also with their LLMs so that ship sailed.
Big thing is — business people are not going to spend time prompting LLM to make an application. If they do then they will become "programmers" and we all (experienced developers) know — you touch it you own it — they (business) will not bother running or taking responsibility.
Right now on r/sysadmin there was bunch of posts where admins have "vibe coded apps" requested to be "productionized". Those business types requesting don't know yet — you touch it you own it — they think they can vibe code app drop it at ops and it is all fun and games. When people will start requesting features, start nagging about bugs, start cursing on whatever changes they introduced it will be back to "hey maybe we will just get someone to do that for us".
You might not need as deep software dev knowledge but with deep software dev knowledge you still will be faster operating LLM to build systems than non-devIf you’re not a good engineer and you don’t have the domain knowledge, your token costs will be very high for whatever gets shipped, because you won’t be able to provide the context necessary to prompt machine efficiently.
Claude will still very often hallucinate bugs, explanations, domain requirements, that have no basis in reality. It will offer fixes and improvements that are pretty standard but not optimal. This is correctable if you catch it, but you need to review every line of code and comment, because in addition to being obviously wrong, it is often very subtle in the wrongness. For every bit of “slop” there is almost microslop, the places where it just kind of confidently guesses… and doesn’t tell you… but sometimes is correct anyway.
The “problem” is there’s less low hanging fruit. You have to know a lot to add value beyond being a middleman gating the slop. You have to really pay attention to the details to find some of the errors that it’s making.
I've said this in other threads, but it concerns me how little the average person is preparing for what's coming right now... It seems people are making decisions as if their jobs and income are safe when in reality their entire profession could be gone in less than a decade. People in this comment thread saying crap like "yea, but the code LLMs write still isn't that good by my standards" are totally missing the trend. The fact LLMs are even one-shotting extremely technically difficult problems was something almost no one thought they'd be able to do by now a couple of years ago. Even I as someone who pushed back against this and thought they would become extremely competent within years am genuinely amazed at just how good they are. Trust me, regardless of your opinions, your job and career is at risk.
Another thing to understand is that if AI replaces workers in a variety of fields from SWE, accounting, customer support, graphic design, etc. Then it's likely going to be hard to fine other jobs to pivot into because when unemployment increases that significantly everyone will competing for the same limited number of jobs. Some will fine something, but most will struggle to find anything.
I hear a lot of people talking about how they'll just go into 'x' field if AI comes for their job, but realistically you'll need years of reskilling and you're assuming that in a world where other people are also losing their jobs, and where AI is touching ever more forms of work, that you'll easily be able to get a job in that other field. And I'm not saying that won't happen, just that this isn't as realistic or as safe of a bet as some people seem to think it is. You're also likely deluded about how hard it is to find work because you've been in software for the last decade.
Please, please, please, start preparing for what's coming. The economy is going to get extremely rough over the next 10 years. You need to be prepared to be without income for years, if not indefinitely.
That's the hard truth.
Governments do dot care on our future, only on who pays them. This is the tragedy.
You're wrong there. You are capable of judging the outcome of the llm.
> But I don't know what to think about the long-term.
Don't you think it all has taken long enough. When I look back at the beginning of my career and compare what we do now ... I cannot shake the feeling we're essentially still solving he same problems and we have accepted that as being normal. Complexity skyrocketed, (abstraction) layers got added but the needle didn't move exponentially together with that. I think the IT industry as a whole gets what it deserves, thinking that we would remain the maze masters of the mazes we create.
> Maybe I should consider transforming my woodworking hobby into a profession...
I'm looking for 8 (affordable) oak panel doors with the exact same measurements as my current doors so I can replace them. That shouldn't be too hard to find you'd think right?
It's still funny that 4 years into this mania the models can hallucinate basic ground truths, humans are increasingly not reviewing the output, and misusing LLMs where simple automation would suffice.
My wife does project management and works with a lot of tech leads. They came to her with a project plan deck, and she started questioning some weird dates.
The LLM was able to pull artifacts out of their issuer tracker, but it just.. hallucinated some of the dates in the process of creating a project plan deck out of the underlying data. These guys didn't care to review and notice, and who knows what else it hallucinated content wise. They were happy to send this project plan multiple levels up the food chain with hallucinated unreviewed dates.
5 years ago they would have just written a script and had none of this mess.
It's harsh but nobody cares if a model or a human made a system.
The "good" bits are that now automating anything and providing value from software is much easier. If I have an idea or a nitpick somewhere, I can just do it, up to a limit (which is quickly rising).
I have always been a generalist and generally interested in a very wide array of things, and this period has been the most exciting in my engineering career (13y now). Learning about anything is so frictionless, looking back at my first learning experience - picking up a fat C++ book and spending days/weeks debugging, while I can romanticize that, I would never go back.
I can also now write software solo or with an extremely small team at a huge scale in comparison, and that is super exciting.
A lot of skills that took sleepless nights to acquire, they are "gone", but I still don't regret anything or wouldn't go back. Their "usefulness" has degraded, true, but this has always been the case with engineering.
We are now able to spend much more time thinking about utility rather than low level implementation and imo that's great.
We have many challenges ahead of us, and there are seriously bad things, the biggest one I have experienced is the hours are increasing and mental load is vastly increasing as well. As capacity, speed and leverage increases, so do expectations and hours, and that is probably a social problem.
Sorry for the unstructured stream of thoughts, and this is just an opinion (quite an unpopular one I believe), I hope your distress decays away for a new excitement and new opportunities.
Thanks for the article .
But for me, the real catastrophe is that they took away all my motivation to learn which was the main work driver for me. Anything I can learn now, the models probably already know or will learn soon enough. Steering LLMs isn't anywhere near being a "deep" skill I'm used to having and it too is being eaten by the agentic tools faster than we learn it. The "make it good" button is coming. And I hate it.
There is going to be a lot of demand for people to clean it up.
I don’t think the data really supports this? Last I checked at least.
Currently, LLMs are nothing more than amplification tools that require significant steering. If you think your job is mainly to take input from POs or managers, translate it into if/else statements and loops, and review PRs, then you never really understood your role. Software engineering—for those who went to university and studied it—is fundamentally about complexity management and cognitive automation. People in the field, or at least those with some math background who studied software engineering properly, understand that it's all about managing complexity; current tools are nowhere near replacing a software engineer. What they call "taste" is imagination, creativity, embodiment, a more intuitive understanding of context, and yes, superior intelligence compared to current AI. However, AI and LLMs are excellent at mechanical work and mimicking human intelligence, so use them for what they are, and stop whining.
Going forward, the world is ever-growing in complexity, and automation will become widespread everywhere. LLMs just unlocked another level. So basically, cognitive work will be automated—perhaps up to 90%—until the next breakthrough (if ever). You can sit and cry, or you can learn the tools and help shape the future.
Software engineers can automate the entire economy now, including the executives, yet they just sit there whining and crying. This is a self-esteem, confidence, and identity issue more than anything else.
I’ve lately just turned to having Claude do a quick /review, spot checking it, doing my own review and the. firing up some web agents to make the needed changes and just ignoring the back and forth because they don’t give a fuck anyway.
Just waiting for someone to notice and ask the obvious question at this point.
LLMs have made domain knowledge and reasoning "cheap"; it doesn't matter if the output is lower quality - look around you for countless examples of where cheap wins and "cheap" continues to improve.
Good luck out there; we will all need it.
It’s not useless, at least not yet. And the fact that you recognize this puts you way ahead of the typical HN user constantly crying about how AI could never
What’s going to make you a good AI-augmented engineer is going to be treating AI like a good partner
Not like a genius, not like an idiot - these are extremes where all the memes on LinkedIn are generated
Like any partnership you will see it comes with bad ideas and good ideas - that it will challenge your own ideas and be sometimes wrong and sometimes right
Approaching it this way, I think my learnings only accelerated - the conversation is of much higher value because it’s a fast back and forth where I can take a moment to learn on those occasions where its ideas beat mine
You are feeling a little insecure, paranoid is not the word, and that’s a good thing
Tackle the problem for what it is: I have this sidekick now that can help me bang shit out in a fraction of the time it used to
Use the the brain that got you here to figure that out - don’t waste your time on these debating whether ai is good or not or listening to stories about how it’s stupid because one time it suggested something that wrong
You’re going to be fine, put AI to work for you
Ask me again in a few months but for now you’re fine
Ownership and responsibility are the new currency for the engineering staff. Willingness to implement these tools and then own the consequences of their use is what leadership is looking for. They want their cake while they eat cake, and they will keep those around who enable something approaching that experience. Owning the side effects of LLM use is more challenging than our own natural output because of the radical volume increase and unfamiliarity with low level details. However, I argue it is still possible. It has always been significantly more expedient to poke holes in someone (something) else's work than it is to perform that same work. And, the executives know this. They leverage this capability too.
The relationship between the business and the development team has been tenuous at best. I've rarely seen a technology team that was properly subservient to the business that ultimately signed their paychecks. I every case I have personally experienced, it is was like a hostage situation where the business owners are in constant terror of the technology people screwing them over in some infinitely nuanced way they or their lawyers could never understand. Many business owners are looking at this technology as a way out of the hostage situation. They noticed a window that was left unlocked. They are going for it right now. Whether or not they will succeed in their escape is a separate matter. Whether or not them being held hostage was justified is also a separate matter. It really helps to keep these things in their own lanes.
This here is the crux of it I think… it’s often promoted that AI will give us the time to do the “real” engineering work of designing systems and really serving the user, but in practice all I’ve seen is further attempts at optimizing every last process with AI - just homogenizing every product and feature into slop.
It feels like every leader has been to some talking points boot camp where they’re incentivized to apply pressure to every part of their process - sort of a desperate attempt to justify the costs they’re incurring. I think we will look back at this and see how obviously short sighted it was.
Yeah. There is no future in IT any more, let's be real. Enough CEOs have drunk so much AI kool-aid that they'll lay off so many people it will become outright impossible to get re-hired again when the incompetent CEOs have gotten fired - too much competition.
The only industry that's going to give reliable employment in the future is the trades, especially the regulated/licensed ones. Gas, water, electricity, structural engineers - basically everything where there is actual human lives on the line when things go south.
why would i ever want to use a tool that remove the part of my job that brings me joy? Fuck productivity, we were already doing good, when we were able to actually do our job, i.e.: not wasting hours in useless meetings, or doing customer care to idiots who could not be bothered to follow instructions, which i shouldn't be doing in the first place. let the LLM do that, or let the human assisted by the LLM do that. Not my job.
I see many posts like this every month, and have many conversations with friends and colleagues who think the same, and I see two trends - like this author, they all joke about becoming carpenters, or electricians. Overwhelmingly, electricians. These two professions seem to be held in special regard by software engineers craving the simple life.
I hate to burst yet another bubble, but supply and demand economics apply here too folks. We can't all become electricians and carpenters. The work isn't there. In fact there's gonna be less work there than there is now of the economy tanks and nobody can afford to build or even renovate a house anymore
We are in trouble. Not from a "no more devs" side, but from a "we only need one of you 7 to remain .." side
Lots of jobs have been automated away and careers based on those jobs faded away in history. Maybe in near future there won’t be a ton of opportunities for software engineers in the traditional form. I’m also embracing for that future.
There were people called calculators that did manual calculations in the past. There were people hand weaving all the fabric. There were people painting cars in the factory. All those jobs are gone for the most part.
We are sitting here portending there is going to be demand for software engineers managing those engineer robots but let’s be real. The demand for software is not increasing at the rate software engineering is becoming efficient using those robots. Some (many) of us have to find new careers.
It's crazy the crazed anti-AI people yelling with foam with their mouth that it's useless, meanwhile Claude for me at work oneshots complex bugs in a massive project with a 95% success rate. And the customer happiness survey has never been as good as it's now btw
Sounds like the Dunning-Kruger effect to me. "I can do this with LLMs, therefore any Sr. engineer can do this with LLMs"
This is what getting left behind looks like.
Get your thumb out of your ass and learn the damn tools.
This is interesting because in my field of VC everyone says generalists are dying.
For one: LLMs make a lot of mistakes. We all see that when they hallucinate search results and what not. But, possibly even more important than that, you ultimately become dependent on some big company via LLMs. Perhaps that trade-off is worth it for some companies, but I personally don't want to become dependent on these companies. I actually consider it a hostile attack from the USA, and under Trump this is even more obvious.
Another thing that sucks by LLMs is documentation. They generate a lot of crap that is useless. So that's another area where humans could be better.
Admittedly a lot of vibe-coded AI slop is also useful in some ways, but it has started to make me rather angry in general - youtube already spoiled me here. I no longer want to see ANY AI videos at all whatsoever. It just wastes my time. I am not here to empower skynet version 20.2.
:-(
I love that Codex added "Steer" to the chat, because I fucking pay attention to the conversation traces on coding agents and I was tired of the PANIC ESC - "No, that's not what you should do! We use a visitor to calculate all that stuff, I just need you to implement another visit method for this new Stuff according to the rules".
Nothing says you shouldn't write any code, in fact, I think that starting from a n interface and a few clients is superior to simply describing things only in natural language. Lots of refactors like extracting method, extracting interface, renaming symbol are way faster, cheaper (no tokens) and less error prone using the IDE.
When I am not sure about the concrete design to implement something, I talk to the coding agent, we discuss types, i suggest patterns, I wrote a small stub here and there, maybe a couple unit tests, but I like to activelly engage with the coding agent as if I was pair programming.
Yeah, I am not a fan of fire and forget, I see no point in being able to control agents remotelly, but nobody is complaining I am not fast enough. It is perfectly possible to have the huge productivity gains coding agents give you without entering vegetative programmer mode. You just need to engage yourself in the process.
You can describe the different categories of something, or you can go ahead and create an enum in rust, you can create a pydantic validator, a few tests here and there. The agent now has something more concrete than a natural language description, it has the compiler to check his code, it has the unit test. The flow becomes faster.
You can mention in your prompt that the agent should use AWS SDK v2 in your Go service, or you can go ahead and add the imports and the initialization somewhere in your code, the second option is a far stronger nudge towards the right direction.
The time you used to waste trying to shoehorn some stack overflow answer to your problem, now you can use to actually read the documentation of whatever you're trying to use. Go ahead, read it fully, you now have time to understand it deeply. The grunt work, the toil will be taken care of by the agent in a few minutes when you're finally feel yourself ready to move to implementation, because now you have the deep knowledge to take the best possible decisions.
There are plenty of places for you to apply your knowledge: the agent may write a correct function, but then this function does a remote HTTP call in the context of a database transaction, so, what happens when the remote http endpoint has a spike on latency? And what if the tables involved on this transaction are a hotspot in your application? You can't add all those small details in your context all the time, you can't add all single corner case and potential pitfall to your AGENTS.md.
Of course, you have to up your game. If all you ever did was completing JIRA tickets without thinking much about it, yes, there's no much you can add to the process beyond what your coding agent can do. But this is a choice.
We can either create a humongous era of slop and technical debt with coding agents, or we can use its hability to free ourselves from toil so we can finally improve our code in correctness, performance, efficiency, efficacy, security and compliance all the while keeping the business happy.
We can either use LLMs to have tens, hundreds, thousands of THERAC-25, or we can use them to liberate our time so we can do the deep work that ensures that you can't possibly deploy a THERAC-25 in production.
> I'm still employed and I see myself employed for a foreseeable future. But I don't know what to think about the long-term ... Maybe I should consider transforming my woodworking hobby into a profession.
This one is notable for having all the clues pointing to why that's not the end-state this is headed toward, and yet... still not quite see it.
> I have no domain expertise that another Sr. engineer steering an LLM cannot match.
It's clear he's developed a significant competence in "steering an LLM" but the depth and value of that aren't apparent yet. After ~70 years, software development is now in the early stages of its first tectonic disruption. In the moment, these kinds of tech disruptions mostly appear to be displacing jobs but, historically, we understand the displacement is one part of a larger shift that's vertically compressing roles, functions and labor value. One steam shovel doesn't just displace dozens of pick-axe swinging diggers, it changes the roles, functions and competencies required across the entire supervision and management stack of "make tunnel through mountain" from the crew bosses and site managers to the tunnel engineers and business owners.
The author seems to be successfully navigating this shift but is still mid-disruption, so he and his management aren't yet able to see all the new competencies required or appreciate their value because it's all so new and still evolving. The rapid shock of agentic coding LLMs is especially disorienting because it's the first dramatic disruption in the field.
> review the code and steer the robot.
Historically, it's not surprising those few words are bearing so much weight and unappreciated value. Steam power was a similar shock to every field which relied on earth-moving and shaping. The big machines were quickly deployed, but it took quite a while for all the disruptions to both new and existing roles, functions and necessary competencies to be understood and appropriately valued. I imagine some top pick-axe swingers who'd graduated to being crew bosses and site foremen ended up driving or directing early steam shovels. In the first months they probably had little appreciation for the tremendous amounts of tacit new knowledge and practical expertise they accrued while keeping the steel beasts working. They were too busy being both amazed at the sheer power and frustrated by the constant scalding burns, tip-overs, blown boilers, landslides (too much weight, too little support) and cave-ins (dug too much tunnel, too fast with too little scaffolding), etc.
A big difference in the analogy is the first 100,000 steam shovels weren't sold at ~1/10th their actual cost and simultaneously delivered to job sites worldwide in six months. Software engineering is also unlike earth-moving and tunnel digging, in that the full costs and consequences aren't as visible or immediate as cave-ins and avalanches. The prices of 'steel beasts' are already going vertical with no end in sight and, over the next 18 months, I suspect "management" is about to gain a more viscerally accurate appreciation of the catastrophic costs of digging 'too much tunnel, too fast' absent the close supervision of highly skilled experts in directing all that newfound power constructively and not destructively. Between the skyrocketing full cost of operation and the consequences of poorly managed, non-expert execution - we'll start to see the broad outlines of the new equilibrium take shape.
In the steam era it over a decade for the ecosystem to understand how to even draw a new org chart accurately, label the boxes and appropriately value proven competency where it mattered. The faster the disruption, the longer it can take for all the pieces to rebalance and stabilize around a new equilibrium. Today, the author doesn't know all that he already knows and doesn't yet have the visibility to see how the new domain competencies he's rapidly accruing are creating a different kind of role that could be even higher value.
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.