Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product. That first pillar is still there. Maybe the author isn't aware of the impact they have, but I know, with the evidence of reverted PRs, that when I step outside my area of deep knowledge I can no longer call BS on the agents. Our most capable agent, with access to the same kind of distributed systems the author talks about, is regularly wrong, frequently myopic, and just outright dumb constantly. It's the expertise of engineers on the team that push it back on track.
Posting this under a burner so I don't dox myself: I work in FinTech on a regulated product. We have access to Mythos. Mythos identified part of our codebase that it confidently asserted was not complaint with a particular regulation and we were at grave risk by allowing it to operate the way it was.
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.
I have worked on highly regulated areas in finance (risk). Compliance is a highly creative art, often requiring lots of out-of-the-box thinking and non-obvious solutions. The people I found worst at this were IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.
My guess is the model makes the same mistakes as the programmers: taking 'rules' literally, unaware of sectoral joint understanding, validated interpretations and habits. (btw. this is often on the non-tech side also a difference between regulatory and legal. The former are much more result oriented while the latter are primarily risk averse.
Ha. I've worked in a fairly strongly regulated sector (energy, in the Netherlands), where I collaborated closely with our head of compliance, and she heavily over-interpreted the regulations while I often tried to find more pragmatic solutions.
I think adherence to regulation and compliance is nothing to do with whether you're a SWE, a risk officer, or C-level, and everything to do with your own principles, ethics, professional attitude, and pragmatism.
> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.
IME this is less the fault of IT and more so bad auditors that won't consider, or just don't understand, what compensating controls are. If it doesn't meet their little checklist exactly, they fail the audit.
> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.
This is such a nonsensical claim. If a company is asking someone from IT to read the regulations and implement them, then obviously you’re going to get something that conforms to the written specification they were provided.
But a company that does that is basically delegating both compliance and legal functions to IT. No sane company does that.
It's cause IT never has to live with the consequences of their decisions. Who cares if the other department keeps bleeding talent because you twisted the knobs so hard no one wants to work in your system?
Contrary to what you indicate rules are not declared in a vacuum, for people to read and then algorithmically 'implement'. There are many ways to interpret regulation, and there will be both accompanying clarifications, as well as compliance departments negotiating with regulators on what is an acceptable and sufficient compliance action. Then there furthermore is a risk that will be calculated vs the cost and opportunity costs etc.
As an enterprise architect, these are all part of the meetings you have with compliance when you are working on major projects. I have had the privilege of working with some excellent compliance officers, and they are the opposite of the nay-saying caricature that is often painted of them. I found these people to be extremely creative and helpful, working together towards solutions rather than stalling or nixing viable progress.
I also work in finance and my recent experience with regulators is really discouraging. DOGE wiped out a large amount of the regulators in government. It seems like most of the regulators remaining are the inexperienced and low tenure. Within the past few months we've attempted to roll out new financial products. When we attempt to send our proposal to them, they can't even tell us who we're supposed to send it to.
It doesn't feel like we're living in the same world of regulation that existed prior to DOGE.
'The company' would be on the hook. Inside, it might be the compliance team that signed off on the solution, but it usually is not the sort of blame game at that point. I'm not saying these scapegoat trails do not exist, but they are far less common than you would imagine if you only read about them in the press.
Company politics, feudal wars, fiefdom protections, backstabbing and outright sabotaging, now there's a daily occurrence and many minions are cannon fodder in those skirmishes, but they usually stay clear of regulatory issues minefields.
I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.
If the company you work for actually had such a no-fault culture, I doubt you'd be criticizing programmers so aggressively for being sticklers, but would instead be trying to understand and account for the systemic factors (including human factors) behind their behavior.
>I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.
I don't see why developers should be in trouble. Developers don't make unilateral decisions on non-trivial compliance matters. A finding of non-compliance at a financial institution would typically be the result of an investigation, a disagreement with the regulator or a court ruling. It would come years after the organisation as a whole decided to adopt the interpretation in question.
Then the rules should enumerate all the ways. From your posts, you come across as if programmers don't know what they are doing which is insulting to those who work in mission critical industries like aviation where a programmer could be criminally charged if he/she didn't implement the specs STRICTLY.
That's why you work with your Legal/Compliance Team to make sure you stay in line. They can explain when a rule applies and when it doesn't. This needs the engineering side to be able to explain what's happening, and translate it into the business process as closely as possible, and the legal side to be able to apply the law to the case.
They could but they don't. That's pretty much the whole job. You can also appeal decisions to a more reasonable party if you draw RobotJudge3000 for your trial
I've worked in fintech for 30 years. I've never seen a product that was intentionally "only pretending to be compliant" with laws.
I've seen accidental non-compliance. I've seen what I would call negligent compliance, where a company attempted to be compliant but didn't meet full, correct compliance (one example I've seen is that a company assigned resources to compliance and forgot to increase resources as workload increased, causing them to be increasingly behind on compliance work), but I've never seen a company that just decided to pretend to be compliant knowing that they were not.
In my experience this is not representative of most fintechs. Of course there are both cases of real intentional noncompliance, and accidental, but by and large it seems like everyone’s trying to innovate within the law.
This makes sense because these companies want to become large companies and contract with large companies. Large companies, by and large, try to follow the law (while trying to bend it to the limit) because they're aware they have a big target on their back and no CEO wants to be on the front page of the papers for tanking a company in such a stupid fashion.
Even if that's the case, I feel like accurately knowing which regulations you're in compliance with and not is would be kind of important from a risk management perspective. From a "maximize profits" perspective (which I'm not saying is good but what you're saying you thought they operated with), you'd want to know the potential gain from ignoring a given regulation and the likelihood of getting caught (along with the cost of the punishment if that's happens). This is the kind of math that I'd expect a finance company to be pretty familiar with, and giving that up for a fuzzy "idk if we're in compliance or not" check seems like a pretty huge liability (unless there's confidence in not being liable for blindly trusting the LLM, which I hope is not the future we're headed for but I guess I can never be totally confident in us not somehow ending up with rules that defy common sense).
Companies that are growing tend towards faking compliance. Many financial rules like pci only kick in at certain scales. So a company growing very quickly will often be behind the curve but will do everything to seem like they are compliant. Then they would hire people like me to come in and make them actually compliant. More often than not, making an effort at improvement was enough to keep the ball rolling.
I think it's the same throughout startup software to be honest. It's just easier to point out when there's clear rules.
Security, GDPR, backups, build pipelines, disaster recovery, most of it will be faked, half-heartedly done once or ignored entirely.
Then there's the more abstract things like scalability, idempotency when integrating with external APIs, error recovery, accessibility, UX, etc.
Almost always that sort of stuff will have been entirely ignored, or there will be a fig leaf over a real mess of misunderstood standards or manual intervention steps.
Startup developers usually have to be generalists as they often wear many hats, so things that need deeper domain knowledge get done to a bare minimum.
IMHO even if we are using auditing tools I believe we must use deterministic tools for critical analysis like this. Such rule and pattern based systems may not scale beyond certain point but they can be accurate.
The dynamic of agent codes human reviews does seem like the only sane one for the foreseeable future. Even Anthropic themselves still fall back to this.
The problem is that sucks, even if all software engineers keep their jobs and salaries, the floor is still pulled out from under us. Imagine if a surgeons job was to supervise robot surgeons from a remote computer, or a woodworker just signs off on work before the machines do all the cutting and assembly. Sure they still have important jobs in their field but the soul & humanity of their skill is gone.
Does the woodworker who shape using a handsaw use less "soul" than the one who uses a machine?
Does the musician who use a DAW and VSTs instead of analogue tape recorders create music with less "soul"?
Does the painter who buys acryllic paint instead of synthesizing their own dye from plants use less "soul"?
As technological innovation progresses, the barrier to creation falls. The process of creating something is not to be conflated with the final piece of art itself.
Does the carpenter who used to build custom fit cabinets with hand and power tools put in the same creativity when he just carries around a scanner, scans the area, the customers use software to select the layout, approve the work, then the CNC cuts out the wood, then all that's left is to put the screws in the holes and go home.
This isn't like the step from hand saws to power saws, and it's disingenuous to pretend like it is. This is what the startup machine has been doing to every industry... finding... "inefficiencies" and "optimizing" them.
Not _my_ opinion, but I just wanted to share that many people (in the Midwest) do believe that anything synthetic that it not readily made from simple materials has "less soul". It's a sorta test of "if I dropped you off in the jungle, can you still produce works of soul? Or are you just another cog in the machine.".
Your analogies are flawed. DAWs and skill saws generate nothing. They take skill to operate, and a novice cannot use these tools at all unless they know the craft.
Compare to this to prompting an LLM: “Generate a third person where game with a view from above where you can steal cars, shoot at people, run from the police, etc.” Anybody with access to the tool can do this, and the results are just another uninspiring GTA clone that you would imagine.
The latter is more like a carpenter ordering their “work” from alibaba then it is like using a skill saw.
It's when a woodworker, musician or painter completely outsources their work and just marks what's wrong, sending those parts back. Yes, the final art piece might be the same, but the artist definitely uses less of their "soul".
I never found there to be much soul and humanity in the job to begin with. Coding personal projects has soul, but for me at least the demands of high-velocity sprint-based software development to match business needs removed most of the soul and humanity long before AI got good at coding. And I mean, I totally understand why it has to be like that. In most businesses, you do better by shipping decent software fast than by shipping great software slowly. I don't have a problem with that in principle. But it does mean that for me, the software development side of things has never had much soul and humanity to begin with. It was just being a glorified assembly line worker, with the sprints being the assembly line. Of course, others may have had very different experiences, but that has been mine.
For me, AIs have actually made the job more soulful, not less. For one thing, it lets me use the part of my mind that is good at human language, not just the part of my mind that is good at software. This makes the job feel a bit less one-dimensional in terms of what parts of me are engaged while doing it. For another, I find it liberating to no longer have to think much about boilerplate code or to spend time roaming around the Internet looking up documentation of various language syntax and API details, the vast majority of which are arbitrary rather than being based on any kind of mathematical beauty. For me it makes the job more soulful that I can think of the job on a higher level instead of having to spend effort on arbitrary and tedious details.
Of course there is still the question of "will the job even exist in a few years, at least for more than a relatively small number of people?". But that's a separate question. For now at least, I am finding that for me AIs have brought a lot more soul and humanity to the job than it ever had before.
That's an interesting perspective. It's hard for me to relate to it because I haven't worked in a job where I just have to ship code 'for work' in so long. Being a more or less one-man software company, all my work projects, but especially our products, feel like personal projects.
However, if I were just having to do things for the man, I might have a rather different take on all this.
Yup, I can definitely imagine that it's different if you're working directly for customers and have the freedom to do things however you want to do them as long as you still make a living.
I think there is a big difference between a surgeon, who is performing a specific task with a clear outcome, to a woodworker, who might produce a unique piece of art or a functional chair. I think the surgeon-type tasks will be replaced eventually. More interesting are the woodworker types, which has some similarities to SWEs.
When industrialization hit, we definitely lost a ton of craftsmanship and craftsman, but a standard Ikea chair is less likely to wobble than the average chair at a much better price (for a random example). Yes, we traded artistry for convenience, but what we really did was bifurcate our needs between "some place stable to sit" from "a beautiful chair for my home". Most people wanted the former more than the latter, and the same applies to software.
If we split the roles into buckets, many woodworkers disappeared, some became artisans, some became designers for industrially-produced products, and some catered to Luddites for a long transitional period. Despite Anthropic's claims, SWEs won't disappear in a year but over a generation or two, no matter how good LLMs become.
Obviously software is much more complicated and integrated into other elements of business, which in a way makes it more vulnerable to AI taking over and in another way will be at the mercy of larger shifts to how businesses organize human roles and responsibilities. What we call "taste" comes down to "intent" - what the hell does a company do? What should it be doing and how should it operate? These will be the only questions that matter and the one thing LLMs can't replace since they will always choose the most default path. So I think human's roles will be to inject intent/taste at different levels of abstraction throughout an organization.
3 years max. Maybe 5 if you are lucky.The models will continue to improve. The exponential gains in compute efficiency that have been ongoing for 70+ years will continue and that will result in even smarter models. There are dramatic hardware changes in the pipeline.
But really that particular issue could have been solved by literally just telling it in a markdown file or instructions something like "verify all facts or compliance requirements with web search and include citations in responses".
“Verify all facts and compliance requirements” leaves enormous holes even if you assume the LLM has a concept of facts and requirements (it does not).
What facts? What requirements? For what industry? For what subset of that industry? For what country or countries that you will be doing business in? Are these current “facts” and “requirements” or is the LLM referencing a dusty article from 1992 for which the subject matter has been radically overhauled?
In my job I regularly see small but incredibly important mistakes like this lead to major issues. Some of those are human driven but increasingly the defense of the person responsible has turned into “Claude said it was fine though!”
It can make mistakes and will sometimes, but what he specifically mentioned was a case where it did not pull up a reference that it needed. So using a web search tool effectively would make a big difference.
It still does not rise the standard he requires which your response indicated would be easy for the model to achieve with a simple prompt.
Additionally, using a specific tool does not suddenly give the model common sense enough to say “this piece of information doesn’t answer the question of whether this solution fits in this specific industry at this time in this place”.
Stuff like that is risk tolerance... its not strictly codified and its more akin to probability. Different companies at different stages, in different industries will all interpret their risk differently... how will a smarter model improve that?
Ah yes, the magical equivalent of "you are a senior software engineer who writes bug-free code".
IME people would benefit greatly from the process, albeit tedious and time-consuming, of testing out the same prompt sequence/session with the exact same model multiple times. It becomes clear extremely quickly how capable but unreliable and inconsistent a model can be even when given the same context. If you have ever completed a long, complicated task with an agent and then lost the session and tried doing the same thing again from scratch you may have had the experience of seeing the subtle changes that come up in the model's thinking which lead it to accept or reject certain paths and ignore or incorporate prompt instructions like the one you've provided.
I've worked on projects in the airline and health industry which are highly regulated too. The regulations can be incredibly difficult to process and implement, and make sure you adhere to everything correctly. I've been involved in multiple scenarios where people have made false assertions about compliance or lack of. I'd still place a bet that the SOA models make _far_ less mistakes than humans.
They might make fewer mistakes, but they aren't evenly distributed. They don't use logic when making mistakes, it is gaps in the training data and now large of a span they have to bridge in the latent space. Just as they aren't smart like humans, they aren't stupid like humans. Don't mistake rate for quality.
Yeah, this starts to overlap with some autonomous vehicle stuff, where I like to say that the rate of errors is not the shape or distribution of errors.
We have long historical experience and innate tools for detecting and mitigating errors made by humans. If we can't apply those to automation, then even fewer total mistakes may end up being a worse outcome.
For some reason, tons of people seem to be in camps at both extremes. It's either "AI sucks don't trust it!" or "AI is so much better than humans!"
But the most reasonable take, which I'm happy to see reflected in so many comments in this thread, is… use both.
Do an AI pass, and have humans verify, and vice versa. Let the humans drive the AI. Then the unique shortcomings of each party can be covered by the other's strengths.
AI review is never going to beat a fully resourced human review.
It might beat an underresourced human review, on time, efficiency, cost metrics. But on the metric of accuracy, throwing unlimited humans at a problem will still beat throwing unlimited AI at it
That's an irrelevant comparison because cost is always a constraint, so there are not going to be unlimited AI or humans. The question is how to optimally combine them for a given cost.
> Do an AI pass, and have humans verify, and vice versa. Let the humans drive the AI.
You can do that, sure. But doing so negates any improvements in speed the LLM brought. And at that point, you may as well just do it yourself to begin with.
When Google showed up on the scene I found I no longer needed to memorize basic syntax and other such things. If I couldn't remember on the fly, i'd just do a quick google search and move on. This freed space in my mind to instead focus on bigger & better things.
I use GenAI tools when coding a lot, but I do not vibe code. I go through everything it generated, and we iterate. And yes, it doesn't save me a lot of time. But what it does do is free up mental capacity in a similar manner. But instead of syntax, it's more complicated patterns. Maybe I don't remember how to stitch something together, but i know it can be done. Instead of spending the time to look it up and then code it, I just tell it to do it for me.
Yeah, humans reviewing the AI review can only detect the false positives, where the LLM claims something is non-compliant and flags it for review/correction by a human or another agent. Human review can’t find the false negatives (true deficiencies not flagged) unless you do a full audit yourself to find whatever deficiencies the AI missed.
This is commonly known as "LLM-as-a-judge" and anecdotally multiple people I know who write code using OpenRouter or using multiple models say it's surprisingly effective. It's strange that there don't appear to be any major papers on it since ~early 2025, which at this point is basically ancient history.
>I'd still place a bet that the SOA models make _far_ less mistakes than humans.
Genuine question: your top coder seems to be producing the most error-free code from your perspective, has the deepest knowledge of the architecture and codebase, and is faster on the trigger than the others.
But your top coder has proven and verifiable dementia, where they will confidently assume the existence of apis and code that do not exist, mix up the purpose of others and forget other things, and you can't predict when and how they will introduce errors into the system or the severity of such errors.
Are you really comfortable letting this person with dementia generate most of your codebase in the airline and health industry?
I also hope you have an iron-clad agreement that prevents the model provider from doing silent updates because all your evidence of correctness you collected thus far goes out the window in that case.
Another genuine question:
You have witnessed a human coder and the AI you're using make the same important mistake. Assuming you do not have the time and resources to retrain, fine tume, and test your frontier model:
Who would you trust not to make the same mistake multiple times in the future after you have warned them that their job depends on it, the AI or the human?
Your top coder has guard rails in place to prevent him autonomously going free - right? This is how you should approach agentic development with LLMs. Like it or not, we are the final bastion, the gatekeepers. The hallucination thing I think is mostly overblown and from speaking to colleagues it seems to vary wildly depending on which model and harness you are using - always go for SOA. In the last 3 months I can count on one hand where it's done something wrong and that's primarily as I'm operating it with guard rails and giving it context.
>Your top coder has guard rails in place to prevent him autonomously going free - right?
The parent is implying they would prefer an AI when working in the airline and health industry because it makes less errors. Read the comment again.
They have not said, "Hey, I work in the airline and health industry and I'd love to use AI for a couple of the bullshit IT UIs we have as long as we can put guardrails on the AI to stay in its lane."
I asked a yes or no question. The guardrails you can put to mitigate errors are the same guardrails pre-AI for the humans (tests, regressions, reviews). If you were wary of employing a top lead engineer with verifiable dementia prior to AI for a mission critical system, logic implies you should think twice giving that much responsibility to an AI as well.
> The hallucination thing I think is mostly overblown
Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.
>from speaking to colleagues it seems to vary wildly depending on which model and harness you are using
You have partially answered my question it would seem.
> Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.
No, but the same can be said for your colleagues. You might call what the LLM does hallucinations, I'd call them mistakes. I think we have totally forgotten that humans make them all the time and are confidently wrong too.
Your original question, doesn't really get to the bottom of the point I'm trying to make, and I don't really feel it fairly represents the issue we are talking about here. They are not the same things.
This is such a tired, meaningless argument. I've never seen a human in 10 years of professional software engineering at a large company ever so confidently, consistently create and send out seemingly well-reasoned code that's as wrong as what SOTA models using CC or Codex do. If a human did this, they would be fired or perpetually remain a junior who no one wants to work with.
Also, if a human does this, you can replace them and get a human who will not do it. The default for an LLM is to generate plausible-looking text that may or may not be completely incoherent. That is not the default for a human. Again, if you find that your colleague consistently fabricates APIs, you can hire someone who isn't crazy instead, but you cannot do the same with LLMs.
>No, but the same can be said for your colleagues.
That's absolutely false. My collegues don't routinely and confidently invent apis that are not there, or spectacularly and repeatedly misunderstand the purpose of certain functions or exhibit extreme forgetfullness. Especially when I've warned them. Hallucinations and confabulations in otherwise healthy individuals are mental disorders. When I ask them why they made an certain kind of error, I can expect to get a reasonable answer. No one has uttered the phrase "Bob hallucinated again while writing those tests" when the Bob in question is a human.
Well, your experience doesn't align with mine. I have been using, and in part of an organisation that is extensively using, Claude with Opus for everything for about 3 months now and I am not experiencing the problems you describe. We'll have to agree to disagree here.
That is fine. "Your experience may vary" is the crux of my argument amusingly. You can't have just realized that people are having different experiences using AI, or even that the same person has different experiences when they change domains or technical contexts. There's been lots of comments littered on this forum to that effect.
Calling hallucinations simply mistakes does not seem to me to be a healthy way to reason about LLMs. I can ask a collegue how well they can program in Ada and adjust my expectations on productivity and bug rates. I can't ask an LLM how well they can code in Ada (just a throwaway example), or even how much of Ada was in its training data. I have to actually spend money and spend time code reviewing before I can even formulate any expectations at all.
This stupid argument again. The number of mistakes _does not matter_. Get. This. In. Your. Head. The predictability of the _type_ of error is what matters. For LLMs and machine learning in general the error distribution is not what you would expect and it is not possible to predict either.
Opus 4.8 and gpt constantly hallucinate stuff as well. If you haven’t encountered or caught it that’s something different. Of course these days it’s mostly confidently asserting a wrong thing.
And this is fine. Developing new software with a really smart intern is the same, you, as an expert, need to bring your experience/expertise on the table to have everything right. Because experience needs time.
What I usually do when in doubt is challenge the AI. “Please quote the section of regulation the product is non compliant with”. It usually admits it hallucinated the whole thing.
100%. Unfortunately those not in the depths of mission critical systems or regulated products will continue to believe that producing tons of code quickly using LLMs without humans in these systems is acceptable.
Here's an example of what we will continue to see with folks fully immersed in gen AI psychosis:
"The creator of claude code said that he no longer writes code for about 6 months and now has Claude doing all his work now. He also said recently that he no longer prompts Claude and now has it running in loops and it is self-improving itself and performing better than a human!"
If the code produced by the LLM is perfect, the LLM takes the credit. But when a disaster happens, you cannot blame the LLM and it then falls on the human who did it.
I don't think SWEs heavily vibe-coding with LLMs realize the risk in not understanding what the code the LLM being produced is doing even after generating tests (lol). We will see more of this too. [0]
Why is it such a dramatic statement for Boris to claim that he no longer writes code?
Are people on HN still typing out functions by hand one character at a time?
It would be like a developer in 2020 claiming that he only writes assembly because compilers can’t be trusted. No one is taking that person seriously. If you chose a career in tech you made a decision to work in one of the fastest moving fields in human history. Now it’s time to get over it, learn the new tools and adapt.
>Are people on HN still typing out functions by hand one character at a time?
Well I use tab completion, of course. And I copy-paste snippets from LLM more often than from SO now. But otherwise not much has changed in my career in the last 5 years. Is this different for you?
I'm not fundamentally opposed to code generation, and I use LLMs for some taks, but I don't see myself vibecoding whole pages of production code. I vibecoded a throwaway note-taking app for myself though.
> Now it’s time to get over it, learn the new tools and adapt.
No, thank you. I have used the new tools, determined that they aren't helpful to me, and set them aside as I would with any other bad tool. I don't feel the need to let hype take the steering wheel.
> Now it’s time to get over it, learn the new tools and adapt.
Exactly. You are free to use openclaw or a coding agent to build a competing bank, hedge-fund, hospital or even a new airliner because the previous ones were built by humans. Surely an AI can do it better by itself.
> Are people on HN still typing out functions by hand one character at a time?
Yes, me. Yes, I tried LLMs for what I am doing and will try again in few months. No, there was no noticeable or clear improvement over doing it manually.
Yes, I am using some LLMs for some purposes but Claude Code had slight improvement, if any, not worth introducing proprietary dependency.
It is because HN is contrarian and behind the times.
I work at a big tech company and I don't know a single person that still hand writes code. Most people haven't hand written code for at least half a year now.
I do wonder what sort of bug is making its rounds on HN that people here find this so shocking and unbelievable.
> Why is it such a dramatic statement for Boris to claim that he no longer writes code?
Because we can actually see the disjointed slop that Anthropic produces. And when issues happen, they can't fix them for weeks on end because no one understands what code does anymore, and all of their "hard problems causing issues" they blog about are literally "if we had actual engineers this wouldn't even be an issue to begin with". Like this bullshit they had in spring: https://www.anthropic.com/engineering/april-23-postmortem
> It would be like a developer in 2020 claiming that he only writes assembly because compilers can’t be trusted.
LLMs are not compilers. For a few very obvious reasons I'll leave as an exercise to figure out
False-positive rate is so high with Mythos according to friends and other reporting I have seen.
The original Mythos release used ASan to filter false-positives so it was able to maintain a good FPR, but when Mythos moves into domains that don't have a readily available oracle to help filter hits, the result is a deluge of false bullshit.
My current favorite in that area ( because I saw it in the wild ) is:
"Make it better" with no additional or reasonable previous explanation of what better might mean.
"AI will figure it out" not for pattern extraction, but for a full blown analysis with equally generic prompt all confidently stated by an executive telling people working it how it works
If you talk to it like a programmer talks to a computer, it works a lot better.
So the question remains if non-programmers will adapt, the LLMs will accept wider range of input styles, or .. its just another abstraction layer for devs to use.
I've observed this in the wild where someone is iterating with an LLM and giving it only negative feedback. For example responding to edits with "don't make it blue" rather than "keep the existing button shape, and change the color back to green".
The LLM doesn't really come back the way a human would and say "so what color do you want?".. it just, guesses. Now abstract that to more complex tasks.
>you take a spec and create tests, every little thing
A spec detailed enough and unambiguous enough to be translated into machine execution deterministically is called code.
Unlike a compiler, AI can build with a spec that is not detailed enough or unambiguous enough: It does so by filling in the gaps with educated guesses.
This is safe if and only if you take the time to later read the output, understand what its guesses were, and judge wether they were acceptable. No AI can do this for you because the truth lies in your original intentions, which it does not have access to.
The jury is out there on how reliable and time consuming this is vs writing the code yourself; it is not immediately obvious that is faster or requires a smaller cognitive load.
Code is not a spec. It's an instruction set. It can be a spec if you try hard but that's not an inherent property of code. For example you can write code to be a compiler..that makes it a spec. But hello world is not a spec.
As for whether or not LLMs can write unit tests. The answer is yes.
If each step requires micro-steps iterating with an LLM with human review to prevent hallucinations creeping in.. at some point you might just be better off letting the human do the work.
Particularly as tokenmaxxing has ended and people are being charged more economic prices. If the pricing 5-10x the way Uber,etc did on the path to profitability.. even more so.
IME, regulatory compliance is something you are rarely able to test for in a nice little box or with well-known suite. So there's no easy "this complies" in many situations, no matter how many lawyers, compliance officers, and llm's you run it past.
I walked down that path for a few months. The more you constrain LLM's, the more underhanded they behave in order to produce something that satisfies all the constraints.
Doing the above doesn't actually make the model smarter, so, if it couldn't get to correct code with fewer steps, then the light you see at the end of the tunnel is an oncoming train.
This is such an abstract principle that the principle itself cannot be refuted. The plan sounds fine on paper. "Just iterate bro". But it entirely depends on what rational agents you put into the system. Obviously, if I sub in a 5 year old child everywhere, this loop breaks. Humans and AI, sometimes one is better than the other at certain things, we're still learning.
The only way to test this is to test it out, in real life. Sometimes people see results, sometimes people don't. Note that yes, I am including the entire iteration process - even after iterating, people still don't see results with AI.
I have had both positive and negative experiences with AI, over multi-week projects. But apparently on hackernews, anything positive about AI is proof that AI is superhuman and taking over, and all follies about AI are lies by stupid humans who secretly have psychological dispositions to fear AI. Sometimes the AI genuinely isn't good enough. Are we not allowed to say that now? We might not know why, but it's just the truth.
The other solution is to formally analyze the entire space of possible actions the agent can take a priori. Then yes, you can definitively say whether or not the principle breaks or not. Can you, though? Can you give a formal specification for the space of possible actions for AI and show that your loop never breaks, or breaks less than humans, or any other sensible criteria? If not, then you can't just give an abstract principle and start making inferences from that.
It’s impossible to write a spec that’s not ambiguous , complete and correct in natural languages. Thus prompts will always generate unreliable software.
I think that what technical people fail to understand is that a lot of the time, "compliance" is not the same as a binary compiles/does not compile. For a lot of rules/regulations, compliance means "making enough effort that legal is willing to back you up".
A system which will just randomly decide to give the legal team reasons to not back you up is:
* A system whose output will get brought up in lawsuits and make legal's job harder.
* A system that will make the dev team perpetually chase its tail while it oscillates between the several different valid interpretations of the rules.
Odd take. So if it identified 17 real gaps and helped fix them, the fact it was wrong about one gap, and the appropriate humans caught it and no harm was done, the whole thing is useless?
Not saying that is the situation, I don’t know. But if “one error is too many” is your point of view… do you think the humans in these orgs are 100% perfect 100% of the time?
> So if it identified 17 real gaps and helped fix them, the fact it was wrong about one gap, and the appropriate humans caught it and no harm was done
How many gaps have humans not caught?
> But if “one error is too many” is your point of view
Yes, in regulated industries "one error is too many" is the only right approach.
Yes, humans also make errors, and there you have a range of options: from tracing and finding the causes of the error (and tightening processes) to literally jailing those responsible. Your hallucination machine will happily "identify" 17 gaps, and create 34 more. And no, there are no processes to make it better. The "make no mistakes" incantation will happily be ignored for obvious reasons, regardless of how many forms of it you throw at it.
Isn't that a net positive though? (not sure about the cost human and tech cost). I'm guessing that without using Mythos, those conversations would never have been had, and confidence in the compliance of the product would've been lower.
I love using AI tools as casinos. It's epic in helping to forge ideas and kickstart thought processes. You basically have the entirety of world knowledge at your fingertips to have a pint with.
> I'm guessing that without using Mythos, those conversations would never have been had, and confidence in the compliance of the product would've been lower.
The conversations had already been had and the product made compliant. Mythos just pulled new rules out of its ass and of course the product wasn't compliant with those. So they do a fire drill and find that to be the case at great expense.
Yeah you can frame it as "more checking is always better" if you wanted but that's just the same old "other people's resources are valueless" slight of hand we see on everything. It probably was mostly wasteful work.
There's a chapter in Simple Sabotage about how to undermine a white collar organization from the inside. One of the key tactics is to hold meetings that revisit decided upon points, and to invent unnecessary process / checking.
So, in this case, the LLM's behavior was equivalent to the behavior of the resistance during WWII.
I think that book should be required reading for all engineering students.
> It's the expertise of engineers on the team that push it back on track.
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.
The corporations and executives are already winning if you swallowed the concept of 'rockstar' engineer. Sure there are more and less experienced engineers, but even interns can and often do provide good input and spot mistakes made by seniors. The 'rockstar' engineer at most tech companies simply equates to the somewhat autistic guy with a brown nose who's working 15 hour days for a pat on the head from management (and making many mistakes in the process).
The study that defined the 10x engineer defined him as 10x as good as the worst engineer. If there is a 0.1x engineer, and a 1x engineer, that 1x engineer is the very definition of a 10x engineer.
I've long thought a 10x engineer is one with just the right amount of analysis paralysis - not too much or too little. It's not that they're 10x engineers, it's that everyone else is 0.1x due to a confluence of reasons. And the ones we call 0.1x are 0.01x.
Even if we forget "rockstar", there are certainly different levels of engineers. More experience doesn't automatically mean better either. That is not to say experience doesn't matter. It matters quite a bit.
Sure , good interns can sometimes have good feedback or spot mistakes. But not consistently enough.
All of this to say that it's not just experience that makes one a better engineer.
Experience is one of the only objective signals we have, but you're right it's not the only one. I've seen plenty great junior engineers and interns, and plenty of incompetent staff/principal engineers.
> because nobody needs mediocre engineers anymore.
This is giving too much credit to LLM. I think LLMs are great and it is incredibly useful both in personal and professional settings. However, it exist on a separate plane than human workers in the tools category.
Sooner or later, people will find out that LLMs only overlaps with existing human hierarchy (e.g. junior dev X%, senior dev Y%, etc), but almost never 100%. If it was 100% to a certain position, you are probably using the humans wrong to begin with there - since humans have one of the most priced thing that I don't see an single ounce out of LLMs: initiative
Very well said and if you look at some of the other threads on hacker news about why people don’t like AI it specifically because they like typing and coding
The majority of my time is an engineering manager has been teaching “engineers” how to actually do engineering with any kind of rigor
The number of engineers who have an absolutely no theoretical structural or system basis for what they’re doing is the vast vast majority
> With LLMs, only the "best" engineers will survive, because nobody needs mediocre engineers anymore.
I don't think this is true.
A good engineer doesn't have infinite throughput. In my opinion the best engineers should be constantly bottlenecked because they solve difficult problems. They don't have time for grunt work. Every company needs less than perfect engineers, AI assisted or not.
There was also another study I cannot find where 56% of engineering graduates struggled to write a fizz buzz.
I think people highly underestimate how long is the average developer, closed in their bubbles of mostly well established software teams that forget that for each of them there's 10 software consultants in southern Europe glueing APIs with trial and error on Java 8 monstrosities.
> Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product.
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?
Sorry if I was unclear. I don't work in finance. I do work with agents. I think expert engineers in finance who are guiding agents are adding a lot of value because of their knowledge of finance. Because I lack that knowledge of finance, even given access to agents, I would not accept a role guiding agents in a finance company because I wouldn't be able to guide the agents well and my/our output would be bad.
Unfortunately every software related industry is embracing LLM/Codegen. Your banks, fintechs, insurance. Everyone. Your concerns are the same I'm having, yet it's regularly dismissed or hand-waved away as "don't worry about it the delivery velocity/ROI is worth it"
It's not so much about velocity or quality, both of which LLM do (or will) provide.
The real question is about accountability and liability.
When a major data leak is going to happen, who will they sue or fire ? That is the value engineers provide. They understand, confirm, and take ownership.
This is what I'm wondering too. We've signed a confidentiality agreement with all the big players (as I'm sure all other companies have done), which is supposed to ensure our data is both segregated and not used for training. I don't trust these companies not to do just that; their business is in taking what we have and training their models.
Yeah, I always wonder if they do some type of obfuscation and transformation on the private data and find a way to backdoor the info without technically using it directly.
This question has been easily answered by many companies.
You, the IC, the developer prompting the code extruder, are ultimately responsible for its outputted code and its behaviour.
You may feel pressured to push out thousands of lines of code a day. You may see those thousands of lines refactored several times over the lifespan of a merge request. You may be asked to do this continue this in the long term with all the mental fatigue that entails.
When it's too much for you to sustainably deal with and you turn to using LLMs to review the code, that will still, presumably, fall on you at the end of the day.
Ostensibly, due-diligence should not change. But people are lazy, just as they've always been around testing/QA/definition-of-done.
I'm not even certain that laziness gets them further along than it used to; I think it's that people have not had their overconfidence painfully corrected yet. Behaviors will re-align pretty fast when people realize that no, they're not going to get away with just pressing a button and saying everything is "good". That is happening right now.
> When a major data leak is going to happen, who will they sue or fire ? That is the value engineers provide. They understand, confirm, and take ownership.
This goes for serious incidents, disasters, outages and security breaches.
If there was an investigation and the answer was "a piece of software was vibe coded with AI" why would anyone trust the software vendor after that?
EU companies are judged guilty of negligence because backups were not totally disconnected (even though distant site) and ransomware did destroy them.
So that is starting to dig deeper than a plain mistake. I guess we will soon-ish witness the first AI slop trial going on, this will be interesting to follow
Just having this discussion with someone about AI in healthcare and how issues are going to be handled.
If a nurse does something incorrectly, they can lose their license. Ensuring that nurse will never be a nurse again. There is a very clear path of accountability and very clear ways to mitigate it.
For instance, if a nurse is drunk and you recognize there is a pattern of people showing up drunk, you institute drug tests and breathalyzers and move on.
While we probably won't have LLM's autonomously performing procedures, they are 100% parsing documentation, reading lab results, making suggestions, etc. And right now, the burden has been placed squarely on the clinicians themselves. It'll feed them them the data, ask if they approve/agree, and then essentially wash their hands of accountability. Let's say an LLM starts incorrectly reading lab results, how is that fixed/remedied? A prompt update? Additional safeguards? Adjusting the temperature? Changing a model?
This is a far different type of engineering that still feels pretty new. Granted, I'm still an amateur in this space (I use Claude Code a decent bit), but it feels really opaque to me right.
Are banks that concerned about velocity? Because moving fast and breaking things in the banking sector can get extremely expensive. It's also not a who-gives-a-shit industry like operating a taxi service or hosting images, but a very tightly regulated sector.
I might have been a bit broad with the brush. I can't speak for banks, but I can speak for the the fintech/money-movement space (e.g. Remitly, Wise, Revolut).
It's a race to get first-to-market for backend integrations/features. It's given rise to a culture of "move fast break things" where safety is only for some core features, but absolutely not for the constellation of other services we provide. Failure rates have increased almost a percentage point since Codegen/LLM adoption was mandated from up top.
You would think regulators would be on top of this, but our industry runs on all actors "self reporting" their outages. Most don't unless they can't hide it (>1h)
'Keeping up with regulations' may as well be a separate field from the core stuff. It has the same pressures as any other development effort. Managers will want the integration to the KYC service LLM'd as quickly as possible.
Not in the universe where I live. Having worked in a variety of web tech, and then working at a fintech with a partner bank, traditional banks move incredibly slow compared to nearly every other tech company out there, and for good reason.
Norwegians have a saying: “Den som er ferdig utlært, er ikke utlært – men ferdig.” Meaning if you are finished with learning the one that is finished is you. Typical scandinavic hard cold truth…
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.
Reg PRs - for the ones with complex requirements what I am seeing is that time to initial PR is very short, and a ping-pong between the reviewer and developer begins, because in my cases (not all) the developer vibe-coded parts, and they didn't really understand the requirements deeply or their code, and it takes multiple iterations for them to fix it. You can argue this is a human problem but this is the net effect I'm seeing.
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.
> That first pillar is still there. Maybe the author isn't aware of the impact they have, but I know, with the evidence of reverted PRs, that when I step outside my area of deep knowledge I can no longer call BS on the agents. Our most capable agent, with access to the same kind of distributed systems the author talks about, is regularly wrong, frequently myopic, and just outright dumb constantly. It's the expertise of engineers on the team that push it back on track.
I'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.
Yeah I'm constantly shocked at how simultaneously smart and dumb Opus can be. It can tell me a LOT about my codebase but it will miss very critical clarifications that I begin with. And when I call it out it obviously remembered it, it just ignored it.
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 explicit
3) 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
I agree with this experience. LLMs are great and save me a lot of time, but they need frequent nudges to avoid going down a completely wrong path. I just don't feel like the management dream of "every engineer has 3 agents working for them full time" is quite a reality yet. I'm not saying it won't get there, or that I feel secure being a software engineer until I'm of retirement age, but I also think it's important to understand the limitation of the tools. You do need to know your codebase. You do need to iterate on small chunks of it at a time. You do need to carefully understand every line of code you're putting into production. LLMs are amazing at generating a lot of proposals, but you need to carefully consider each one.
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.)
What about autonomous drones then? They are not planes?
The real reason we have pilots in commerical jets is that they are a failsafe because a mistake in your automated system can kill 100+ people and guess what? It still does from time to time even with a human piloting the "beast."
It is not impossible to have fully automated planes. We just cannot afford to make any mistakes otherwise people will die so we keep pilots as failsafes.
a slightly different metaphor. Copilot suggests it is next to you, helping you pilot... something else. The computer? The system? But "piloting the LLM" changes the relationship. The LLM is the thing that is being piloted.
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).
a year ago I would have agreed, but the gap is getting smaller all the time... these things can do 90% of the work, and how many people does a company really need for the remaining 10%? certainly not as many as they needed before
With opus 4.8 we're frankly aproaching the 100% of the work, but only if tasked by the right people. A decade ago I worked as an enterprise architect and left it because I preffered coding. Now I'm an enterprise architect again, and we're at the point where I've setup a Microsoft Fabric and integrated a ADLS Gen2 with a Lakehouse building Dimension and Fact tables for our Business Intelligence people with Cowork. A month ago I didn't know what Dimension and Fact tables were in a datawarehouse and now I've not only setup a flow for it I've made it more accurate than what they had before because I understood how BC365 worked and the previous consultants didn't.
We had a PoC in place to get fabric, it had like 500 hours allocated for what I did in a week with cowork, and my product is actually on secure vnet network with Azure identity security with both a test and a production environment delivering actual data.
Cowork even made the damn powerpoint slideshows for decision makers.
The single saving grace right now is that it apparently isn't easy for everyone to do this yet. But I didn't use a whole lot of my knowledge on software engineering to make any of it happen, not even the pandas and arrow code that moves the data behind the scenes. I mainly used my knowledge of NIS2 compliance and general data architecture in a step-by-step process. To me anyone with common sense should be able of doing this, and I really don't think I'm special... but then I teach other people AI at our company and they can barely get it to create a running program. Which is fine for now, but I have to work another 20ish years before I retire, and by then a lot of young people will have grown up with AI, and like I said, I'm not special. I think the only thing that differentes me is that I mash the buttons until it works but also have decades of security and compliance hammered into me.
sure but even if it's one talented dev doing work that 2 would have done before... where's that work going to go? I don't think we need twice the amount of software
My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently.
LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is always many things subtly wrong iterating and expanding our domain.
This might be because the companies I worked for happen to be tackling complex domains precisely for moat-building reasons. They stay in business explicitly because there's not a book out there you can read to build a clone, the knowhow stays inside.
Also, a fintech whose managers recommend speeding up design docs with AI sounds way too careless to be in the money handling business. It's way, way too easy to end up with millions incorrectly allocated, particularly if you deal with high volumes of small transactions. These bugs are always a bitch to deal with because correcting the logic is just step one, you then have to correct all the wrongly calculated data in immutable DBs, move around the red tape and client comms, and your fix is bound to become a gotcha that new features and observability have to take into account ("remember that there's a bump in the data in february 2 because we had incident X".)
This. Once you're building something that genuinely hasn't been built before, LLMs cannot be trusted with any architectural decisions. I'm building a product based around various physics simulations, so it's purely first principles, but without active research, thinking, and challenging, it produces computational code literally hundreds of orders of magnitude slower WHILE implementing absurd fallbacks and shortcuts that effectively result in a useless calculation.
This is the case perhaps 95% of the time.
Oversight is very important, and architectural thinking cannot yet be outsourced, only execution.
LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
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.
I can't even get Claude or GPT-5 to consistently produce good flows for common use cases, much less domain-specific shit. They have deep vocabulary though, which makes them sound better informed than they are.
They are very good at writing code and debugging visible errors- but that's like 50% the harness.
> LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
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.
> 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
This kind of works but the difficulty is that you have to be very explicit about everything. It was mentioned in a spec document that a particular excel file is treated as a source of truth throughout the whole company and it is treated as an append only database. The agent still decided to add a check to see if a previous row was modified. It pushed back on its decision when asked why it decided to do so. "What if someone entered it wrong and had to correct it"? Valid question but it's not my teams responsibility to check for it
This check makes sense from a traditional development view point and that's why the agent did it. I would say it's good practice too but it's beyond the scope of the project it was working on. If what you are doing is beyond the norm you have to watch out for things like this
Sure but finding their shortcomings and patching them with skills takes real trial and error. They are incapable of identifying their own shortcomings for you.
>> LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
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.
I always remember of the infamous Steve Jobs quote "Ideas are cheap". If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".
What I think is often overlooked is the human "Willingness" and "Care" of staying with the thing for the lack of a better term. What I mean by that is that a lot of people just don't care enough, or don't want to, build, maintain, and own things. Sure you can ship V1 faster, but will you remain on the grind?
I think a great example of what probably will happen is found in Suno, the AI Music thing. I don't know if y'all have tried it, but it now produces really good stuff. What's happening there? A lot of people play with their own little universe and get tired quickly, move away from it, and only a few prolific creators stay and turn it into a "job like" environment.
We may have shifted the scale and the economics of "delegation" and "execution" but I think there are still a lot of other factors to consider.
> Suno, the AI Music thing. I don't know if y'all have tried it, but it now produces really good stuff
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.
i actually was discussing that with a guy i met the other day, an old school producer, did succesful stuff 30 years ago. He used SUNO to reinterpret old and ideas of his, in his judgement it did an excellent job and lets him create many songs daily if he want.
Sounds familliar? the good old "let AI be steered by experienced X and boost productivity".
All in all, gun to the head, i think i am so critical because to use these tools is surrendering to big corpos. It is not a democratic tool. If it was i would probably be using it. I have finally given up and started messing with local models (well, i did already with images) but general local models are useless.
OR maybe it's me? i cannot for one moment let go and converse with the machine. I can give order to the machine.
The tech is fantastic, but the fact that it's in the hand of corpos with all interests in never letting us be able to do shit without them, makes me one hundred and one percent against it.
Have you tried the open weight models, but not locally? Like, using it from a provider. That way, you get access to better models while still not using private closed models, anyone with enough compute can host them, not just the big AI corps.
Suno is completely incapable of producing heavy metal. I can't speak for other genres bc I don't listen to them, but what it produces is completely hollow and devoid of what makes metal metal. I also think most metal fans will categorically reject AI-made metal on principle.
just verified, it cant make a decent techno track, nor a drone track nor anything experimental. Its creativity is subpar, it feels like listening to a producer that knows where things go but is tired of playing, zero interest in creating/ performing, it gives off that kind of vibe
Metal, punk, hardcore - any type of heavy music, really, should reject AI-made slop. If you’re a fan and/or maker of them and are not just wearing the genres as an aesthetic, you fully know they are a rejection of corporate and governmental control.
I mean, even if could produce generic metal would it produce Igorrr? Meshugga? Tim Henson? Baby Metal? All of these are driven by other things then just producing metal. I agree pure AI music would properly rejected unless there was some point to it. I could see it have some part, but then as a weird instrument. Take a model for music, randomly mutate internal weights and then let it produce a drum beat. Keep doing that unless you hit some limit and perhaps that is interesting.
I think this is a question of how much control the user is able to have over the end product. Music creation in particular is very difficult... I've produced music for 4-5 years, and the granularity with which one has to control the finest pieces is often mindblowingly frustrating. It takes years to develope a decent ear for mixing.
By giving up that control, you do get to a quality end result sooner, but that end result can only be an approximation to your original vision, since you're giving up the control required to shape the sound to that granular level.
Additionally, without the knowledge of how you got from A to B, you don't know what else is possible (or impossible.) In the process of doing something manually, you may stumble across a particular setting or effect that creates something you never even considered. And now, that is knowledge you can use on the next project.
Yeah I have played with Suno a lot and I find that no matter how I change the genre, lyrics, etc. there's some underlying quality I can't quite name that my brain recognizes and quickly gets tired of. It's fun in a novelty sense, for now.
> 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.
It's like any LLM, it's not a tool for if you know exactly what you want with all these knobs and fine grained controls.
> 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.
I don't think that's a bug or unexpected, it's what AI is good for. I do these (very) old Blues covers of modern songs and it's terrific at that sort of conversion thing.
> If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".
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.
Execution has just moved up the conceptual stack. We once wrote assembly, and then changed to higher order languages. Same is happening with lexical work generally.
Totally, I meant that more in the lenses of how folks are perceiving it. They solve the execution part of the "one shot" aspect mentioned in the post. You still need to do a lot of plumbing, orchestration, supervision, etc. I think it will get cheaper and cheaper over time, though not magical enough to one shot a Rust compiler from "write a Rust compiler make no mistakes" haha.
Suno is a good example. I've written lyrics for a lot of songs and then "produced" them with Suno, a process that involves dozens to hundreds of remix/cover/extend revisions or a lot of time in their editor to get it sounding the way I want it to. The songs are songs that I like and will listen to in my playlist but they haven't gotten much traction on Suno's algorithm. I haven't tried to promote them much elsewhere either but when I have posted them they get a few likes at best. I'm not disappointed because I was creating the music for myself and just sharing it as a side effect but what I take away from this is that getting people to pay attention to and enjoy something that you've created takes a lot of work. You have to market it, get it in front of them, get them to pay attention to it and I'm convinced you also need to give them a reason to like it by associating it with something whether that's a video, a story, a persona or some other vibe. If you want it to "stick" you need to do all of that over and over again for the same audience so that they learn it.
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.
Same here, I vibe coded my perfect alarm & reminders & productivity app for Android, (Promptly AI link below) that does TTS and Gemini calls and other things that rapacious alarm-clock marketing masters charge dozens of bucks per month for, but at some point the day job and dislike of the marketing grind is just too much, summer is here and yeah...
This starts from a false premise. Ideas aren't cheap.
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.
To continue paraphrasing Steve Jobs, focus is the most important thing. When the cost to produce new features/implementations goes down, focus is even harder (and even more important).
> I always remember of the infamous Steve Jobs quote "Ideas are cheap". If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".
> 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.
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.
Could you elaborate on the AI Music tool? My impression was that it's used as a one-shot generation tool. I don't know much about music but I imagine artists need intermediary steps, track separation, instrument customization and other stuff I'm oblivious about. Without these, it's hard for me to imagine it being used for professional work.
The frontier music models, the paid/pro Opus 4.8 equivalent ones, are more capable now, and Suno has a "harness" like Claude Code on their Studio tool that lets you iterate on the generation by doing stem splitting, track separation, edits that stay within the tempo, rhythmic structure, etc.
Sumo produces plausible cheesy stuff that is otherwise sonically awful, ringing alongside the full spectrum due to how it works. As a musician I would not use it - I like to keep some creative power. Some people use it around me for samples… and then their tracks ring. But it works for them as they be advertising producers. Mind u - I’ve used paid version and I know one or two about music production.
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.
I guess we have very different ideas around what makes good music. Every single Suno produced song sounds like a 60kbps extremely compressed mp3 while also having extremely generic, uninspiring structures and complete lack of interesting sonic/instrumental layers.
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.
suno produces 7m "professional" songs per day. Can't think of a better example of a slop generator. Many songs that will never get more than a handful of listens if it all.
I've made songs on Suno that I actually like and have listened to tons of times, not to mention just having fun in general making music, seeing what comes out of the box.
The future is going to be different.
Right now, people effectively spend ~0% of their time entertaining themselves with their own music, art, writing, film, etc.
True of human-made things as well. Most video essays don't get more than a dozen views, most gameplay streams similarly. People playing their guitar and uploading, same. SoundCloud, YouTube, twitch. Human-made app store apps is the same story. Most are not downloaded by even 100 people. Most Github repos don't even get a handful of stars.
The high watermark of what can be "solved" (read: one shotted) is rising, and will continue to rise. Look at the gig economy (Fiver etc) for simple programming/design tasks, LLMs have taken over completely with their execution.
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.
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.
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.
> Overall society feels more turbulent, but this is otherwise all the same song and dance all over again.
The thing is... everything you mentioned had only brought the need to retrain.
This new hotness AI? It's bringing actual layoffs, and not just of the boom bust cycle kind, but permanent, industrial-revolution kind that lasts for decades.
Covid overhiring, no more 0% interest rates, that one accounting change, and companies needing a "growth" sounding way to announce layoffs. Maybe that's bringing actual layoffs in the name of AI?
Based on what I've been seeing/reading online the past ~6 months or so, I think there's a self-fulfilling prophecy going on here.
Developers are concerned about jobs going away, but how often are they pushing back in their orgs about how AI works? In response to "are you using AI to move faster," how many are responding with "yes, but there are some things you should know..."?
If there's no pushback and just pure acceptance of stuff like tokenmaxxing, then what does anybody expect when the broader narrative around AI is that it can help a novice to grind out miracles (i.e., "holy crap, if this is what a novice can do, what can an expert do?!")?
Of course leadership is confused because (it seems) few are asserting expertise, saying "no," and stating a clear case as to why they're doing that.
The default excuse is "I don't want to lose my job" (which is a fair reaction to all of this, especially these days), but it's worth considering when/how that choice is actually just shooting future you in the foot later. It seems there's a broader trend toward compliance more than there is "you hired me to do this job properly, did you not?"
> The company is now hiring again for a few roles and domain familiarity is not a strong differentiator anymore. We used to list "Software Engineer - Area". Now it's just "Software Engineer" and the team assignment comes after the offer is accepted.
> Of course, this is good for brilliant engineers that never had the chance to get deep into the domain and now have better chances at getting a job, but it's also sad to think that other brilliant engineers that spent their lives collecting domain knowledge are now competing on the same lane.
If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.
Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering. They might still find employment in other areas of the industry where they accumulated domain knowledge.
And I'd still question it. The experience of just… knowing how a good architecture looks like without being able to really put it in words is what makes a good engineer to me. These people can pick up relevant regulations or industry terms and deliver value quickly enough.
> 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.
I think this is true in some things and less true in others.
It's a pretty high moat getting into stuff like simulation software because the people working on numerical methods overwhelmingly have PhDs and it's a mixed skill set. Domain expertise here requires you to know maths to a high level. Even mechanical engineers often struggle here; it's often applied mathematicians and physicists turned devs that work on this stuff.
I worked on a fairly gnarly signal processing thing a while back that required bringing together knowledge of physics and software and maths and I found explaining it to people was tricky as their eyes glazed over at some point because their knowledge typically only covered one part of those.
How is "without being able to really put it in words" a mark of experience? Surely an engineer should be able to justify why an architecture should be arranged the way it is!
There are plenty of deeply skilled, experienced people (in all fields, not just ours) who struggle to explain that knowledge to others. Being a practitioner and being a teacher aren't the same skill.
Somethings are true not because of one big cause but 10,000 tiny paper cuts. Trying to explain it all just becomes a laundry list where each problem seems solvable but really each problem is there at the same time and inter-linked in non-obvious ways. And the experienced person just comes across as a nay sayer who doesn’t welcome innovation.
It's perfectly possible to put that sort of knowledge into words, but not in a condensed "recipe" that can be explained in a meeting, that will go into a single Hacker News comment, that will cover all cases, or that will satisfy LLM users looking for the easy way out.
Pretty much every area of knowledge is full of those. That's why people publish books, that's why people go to college or get PhDs, that's why people with experience gets hired.
>>"Domain knowledge can be learnt much quicker than how to apply good engineering principles."
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.
> Good software engineers who are arrogant about easily acquired domain knowledge
This is a problem of arrogance, not of domain expertise.
Having worked in a few different industries, I'd wager that for the vast majority of them, a competent person can probably learn 80% of the required domain knowledge in under 6 months. For the latter 20%, as long as the person is not arrogant, they will seek help from colleagues who have been around for longer.
On the other hand, solid engineering principles will take 10-15 years of actually experimenting and learning in practice what makes a system resilient and durable.
> Domain knowledge can be learnt much quicker than how to apply good engineering principles.
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...
>Domain knowledge can be learnt much quicker than how to apply good engineering principles.
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.
The development and acquisition of valuable domain knowledge is a hard, risky, expensive and slow process. Because the valuable domain knowledge isn't yesterday's, it's today's and tomorrow's. In fields where domain knowledge matters, it is also deeply intertwined with engineering - you won't task Jeff Dean to develop Unreal Engine from scratch.
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.
This same complaint comes up on the topic of generic coding interviews, although shadowed behind the bigger complaints about simply disliking them. When people develop domain expertise they want to use that as a moat around their job. They want interviews to focus on stories about the things they’ve been exposed to on their past jobs, not test their abilities.
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.
That's the right question. I don't like this dichotomy between domain and engineering. It seems to come from people who just build different CRUD apps for mobile and websites for businesses in different industries and that's what they call domain.
Not like a webdev entering game engine design or a database engineer entering computer vision research, or someone working in embedded hard-realtime systems switching to making video editing GUIs.
That's a fair question. I suspect highly specialised industries are harder (rocket and space, defense, nuclear, etc), but for things like finance (most of it, anyway) and retail, which IME make the bulk of the tech jobs out there, it's certainly nothing out of this world.
That's an extraordinarily rosy view of the future.
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.
There's quite a large cushion for software salaries to decline before permanent structural unemployment were to set in.
It's not really feasible for "normal" businesses to hire developers at current salaries.
Tech companies will probably shrink in headcount, but all the non-tech kind of businesses can increase developer headcount.
Current Tech salaries are far above other fields while requiring (used to) significantly less training or time investment to get into.
Phase 1 is more likely that software comp will normalize with other professions, and more hiring will happen at the fringes rather than being concentrated in a few big companies.
> There's quite a large cushion for software salaries to decline before permanent structural unemployment were to set in
Maybe in some markets but in many places around the world software salaries already weren't that high. Or at least not really much higher than other white collar professions
That isn't going to happen. To me what is going on is that no one really reads anything positive so there is all the incentives to write as hyperbolic + negative as possible to try to rise through the noise.
The reality is this all the standard lump of labor fallacy. I am not a software engineer but it is obvious to me at some point I will be using claude code or whatever to automate tasks. I won't be taking software engineering jobs, I will be using code to do what is done manually today that you wouldn't bother paying a software engineer to handle.
Today's software engineers will just be higher up the stack from me the same way they are today.
In 20 years, many of us will be working in sectors of the economy that don't exist today.
The idea we get something as powerful as AI and it doesn't create new businesses and sectors is just stupid.
Imagine telling someone in 1997 they are going to be getting deliveries from Amazon all the time in the mail. What kind of idiot would believe this? I don't even read that many books!
There will be a handful of people who make stratospheric compensation, a bit like we have now.
Everyone else will have extreme job uncertainty, getting laid off multiple times, losing compensation as a result (ie equity vesting) with compensation that at first stagnates and then starts to slowly decline in real terms.
A lot of the big tech companies will likely spend less effort on non-core activities. Think of all the things Google does. Anything that's purely internal will be gutted staffing-wise because it's the safest testbed for shifting the engineer-AI balance on teams before rolling it out further.
If you listen to non-tech people now you hear tales of applying for hundreds of jobs and getting no response. That will become more normal. What's worse is that AI seems to be to blame here. Companies all use the same AI ATS systems and I've seen allegations that candidate scoring gets cached for upwards of a year. So if the system happens to give you a bad score, literally nobody will see your application because you'll get filtered out before any human sees you.
I was watching a VC give a talk from some conference in France and the general sentiment is that no companies are being funded with teams greater than 5. Why? AI. So don't think you can startup your way out of this slump unless you're somebody who has the connections and CV to get funded anyway, in which case you might well have some of those stratospheric options anyway, at least for now.
This is exactly opposite my experience in my 25 year career.
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.
I’ve been using Claude Code with Opus 4.7; it’s not that the code it produces is wrong, it simply tends to write too much of it. In my opinion it’s still worth thinking about a particular feature and finding the best way to fit it into your code because Claude will often just pick a layer of the stack (maybe presentation), and jam it in there. A couple weeks later you need this data somewhere else and Claude can’t reuse the code (maybe in the service layer) so it kind of “ports” it over. Unless a person is paying attention we now have the double the amount of code and duplicate logic. I don’t see AI tools like Claude getting better at this anytime soon.
Where I work there’s already pressure to use Opus 4.7 less to save money, someone mentioned using a smaller model for “simple bug fixes”. This might work sometimes but how often do we really know it’s a simple bug fixe ahead of time? I suspect as costs go up we’ll see interest in using these tools to write “all the code” go down. As people migrate to cheaper and less effective models I suspect we’ll see the pressure to skip reviewing that code dissipate as well.
We’ll see where we land, maybe it won’t as dramatically different as the author of this post fears.
I have the same criticism of AI writing too much code. It's surprisingly effective to just tell the AI to cut the (prod) line count in half and look at whether there are other libraries it could reuse. I think you could probably also have a refactor bot that spots duplication and pulls it out.
None of this comes out of the box atm, but it's not clear that it's not possible.
> Maybe I should consider transforming my woodworking hobby into a profession...
Whatever your feelings on the future of the industry are, it's hard to imagine you'll find more professional success in artisan woodworking than artisan software.
Custom furniture/cabinetry is already a pretty tough market, and woodworking is such a common programmer hobby that if a significant chunk of us decided to make a go of it the market would get heavily oversupplied pretty fast :).
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'm threading this now and have paired AI-assisted development with woodworking knowledge. Partially chose to work on this because I wanted to build in a domain that the models might have a tougher time understanding.
Parallels and interests overlap everywhere between programming and woodworking; decisions about tooling, tolerances, sequencing, and what can be easily fixed later.
The models get rectangles pretty well and has been fun exploring a parametric casework planner for my own shop.
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)
Wood construction is not typically considered woodworking, although there is often a lot of overlap. But the skills needed to make furniture are pretty different from the skills needed to make decks, fences, etc.
Carpentry is not the same thing as woodworking, to be fair. The latter has the connotation of making furniture, trim, and other such items that people want to look nice. Carpentry does not necessarily have that connotation. It's a kind of "all squares are rectangles, but not all rectangles are squares" situation.
I have a historic house with a hand carved/ uniquely shaped door. The jamb rotted and we paid a woodworker $4k to create a replacement. The door itself would easily cost $25k to replace. So, move to a major historic area with hand carved doors and you could make some decent money.
You assume there are enough of these jobs to go around and that you can just show up and do some extremely intricate work. Repairing historic doors and more elaborate woodworking isn’t easy to learn as the knowledge mostly doesn’t exist online anywhere, I also own a historic house and often ask the top tier LLMs for details e.g. about my staircase, they always give wrong answers as this knowledge is simply too exotic and not in their training set. And no one online talks about these things, 99 % of woodworking videos on YouTube are focus on beginners, you can’t replace a professional education watching videos and reading books. That will protect woodworkers with these skills of course but it’s wrong to assume you can just break into this market and be successful, most devs with woodworking hobbies are really shit at their craft and struggle to create even a regular elaborate cabinet, no way they will be able to compete with good craftsmen for these few lucrative projects.
look at layoffs.fyi. chances are he will be laid off pretty soon. and if not tomorrow, give it couple extra years until AI gets even better. it is one-way road, down the hill.
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.
My comment was about the fact that even if you're laid off, you're more likely to find success in artisanal software than artisanal woodworking. That statement is not an assertion that you're guaranteed success, just that it's more likely to sustain yourself than woodworking is.
Layoffs also don't really tell you anything. Is it actually LLMs that are causing layoffs or is it deteroriating economic conditions and uncertainty amidst war, oil shocks, etc.? Is it junior employees being laid off, or seniors? If it's the former, someone with 10+ years of professional experience might not have reason to be concerned. I happen to believe that, LLMs or not, the software development field already had far too many jobs, employing a large number of clueless people who contributed somewhere between zero and negative value to their organizations, and that it was overdue for a correction anyways.
You are not allowed to have land without participating in the economy. The government forced you to acquire land by buying it, and to pay taxes in dollars.
I mean you can sell surplus to market. but key point you do not pay taxes on food you grown on your backyard and eat yourself! nor you are subject to any market collapse. as long as sun shines and raind pours, your food grows in your backyard, no matter S&P or inflation rates.
"industrialized society" just rejected 160,000 sofware engineers this year. other industries are no better. you are either wage-slave barely making it. or getting laid off, as those people are not needed.
Artisanal food for hipsters is always going to be a market. People are willing to pay a premium for locally or regionally grown produce, fruit, eggs and meat.
However, it's a risky business so I'd only recommend getting started if you either (!) are FIRE already even after sinking 3 million bucks into purchasing land and machinery as well as constructing all the buildings or if you join a cooperative/union or if you got experienced farmers in your family.
Everything else - especially following "prepper" influencers shilling books and holding more public speeches to shill for said books than they are actually working on their farm - is a recipe for certain disaster.
If in doubt... first try raising a few dozen chickens in your yard as a starting point.
> 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.
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.
It is fairly obvious that the majority of people who buy software (>99%) don't really care how it's built. They care a lot about the outcome of using it, they care a little bit about whether there are bugs or not, and they care about the cost a lot, but beyond that nothing seems to matter to the purchaser. Even obvious things like whether or not there are tests, documentation, SLAs for fixes, or backwards compatibility between versions don't really seem to matter much.
That doesn't mean you couldn't carve out a niche providing hand built software to people it does matter to, because the software industry is large, but saying 'zero percent of the market isn't willing to pay for it' isn't really wrong. It's just a rounding error that does care.
(One massive caveat though ... the argument assumes that 'hand built' means 'higher quality than AI-assisted', and that's probably not true for >99% of developers.)
We are less than a year into good-enough coding agents, and as of right now there is not a single job opening I see that offers a salary for non-AI output.
> Exactly zero percent of the market is willing to pay for hand-built software.
This is a provably false statement, given that eg. Handmade Hero exists and sold a bunch of pre-orders despite never coming close to completion, and spawned an entire community that prides themselves on handmade software. There are also content creators like Tsoding who make a living by having people watch them do handmade coding for the love of the craft.
Some non-zero percentage of people will also always be willing to pay a premium for superior-quality software. The author's thesis isn't that LLMs can produce S-grade software but that 'nobody cares' about quality and that C-grade software is good enough. While it's true that software quality isn't greatly valued at scale, I think the minority who care is larger than the minority who care about premium woodworking goods, particularly because as an artisan software developer you more or less have access to the global market of every single person who cares, while as an artisan woodworker you mostly only have access to the market of people in your town who care.
This also overlooks that LLMs are politically divisive and there are movements to boycott them and shame people for using them. There's a niche for organic, free-range, vegan, etc. products at the supermarket for conscientious objectors, there will undoubtedly be such a niche for software. All the more so if LLMs reach a point where they actually are putting everyone out of a job, they will get much more divisive. There was already an assassination attempt against Altman and his promises to destroy everyone's livelihood haven't even come to fruition.
I think this can happen in technical communities - people who can write/read/understand code. Who really cares about software size/performance/usability/minimalism.
This is a small part of the whole users, but.. why not. People who value hand-by wood goods are also a small part.
Also, there are also communities which slow down AI integration - like Zig. Maybe they will alive
Only if the quality is bad. And users normally can only judge this when something is not working. So maybe only badly written/tested software will get labeled ai slop.
I sympathise with the author being in the same boat, largely.
I just want to emphasise a point... Calculators give 100% correct answers and yet we still hire accountants; for the simple fact that we don't want all to be accountants.
People will hire software engineers for the simple fact that they do not want to be software engineers.
With todays LLMs, yes. But if they can ever reach a level of a contractor in a reliable way and companies offering them willing to take responsibility (because confidence is high and rest is insured), then one can just hire a cheap AI agent to fulfill a contract - design, implement, deploy, run and maintain your service/website like the engineer before.
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.
People don't make their own bread. They buy it from an expert.
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.
In the US, all you need to work in tax prep is a high school diploma and most individuals are not worth the cost of an audit.
I wouldn't say it's particularly brave, in fact LLMs are probably better at identifying mistakes than most tax payers. The % of Americans using a CPA to file taxes is fairly small.
> I spent 10 years (even more when you account for non-profession experience) getting good at things that are becoming less and less valuable.
This is just how it is, and has always been in this industry. And it takes about 10 years to realize it.
When I started my career in software, businesses were still writing new code in COBOL. 10 years later those skills were pretty much useless, except for dwindling maintenance roles.
Then there was the client/server era. Then the web era. Then mobile. Then cloud, etc.
All the same functionality, written and re-written time and time again, using the latest popular stacks and methodologies.
I hope to be retiring in a few years and pretty much everything I have learned over nearly 40 years is no longer applicable or is at best losing relevancy to the way sofware is built today. And that's how it's always been.
Sure, but those are cherrypicked cases where a technology became obsolete. There are many counterexamples of decades-old technologies that are still actively chosen for greenfield work today, in 2026.
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.
This is a good point. I started with Turbo Pascal in school and my first job was writing VB 5 Windows apps for local businesses. SQL (and C, but I haven't written it in ages) is probably the only thing I learned in the late 90s that has been a constant my entire career. Languages and frameworks seemed to change so frequently that I never thought too much about them. I was always focused on the end goal of solving some business problem.
Maybe denial is a river in Egypt, but I (most of the time) believe that the glass is half full and we will need MORE humans as LLMs gain in ability. My thesis:
1. most jobs are created by small to medium size enterprise
2. the throttle for new SMEs has been people, money and ideas, in that order
3. with LLMs being a force multiplier, fewer technical people are needed but some people still ARE needed
4. with less throttling, MORE SMEs will be created with more jobs - they will be able to do more, faster, but still need some human oversight.
Also, what is the point of software if it is not to serve human needs?
Also, in open source, community building and tending is a very human enterprise that will not be replaced by bots any time soon. So, as coding becomes commoditised, perhaps the soft skills backed by technical knowledge will be the complementary
skill that increases in value.
Or, maybe it's time for me to become an itinerant folk musician.
Software boom due to SMEs looks very unnatural to me, because what makes software so special is its ability to scale, so it naturally tends to monopolization
It's odd to me how quickly the author devalues their own experience just because AI can do certain things well. There's a huge chasm between what AI can do when prompted by an expert software engineer vs a non-technical person. Sure the models and the tooling will get better, but it still needs to be driven by someone with an intuition for how software works and able to dig in when necessary to unpack and correct the hallucinations, misplaced assumptions, or straight up borked code that will come from the gap between what a human wants and what they can express in words.
I have no idea how things will play out, but so far I am not worried because the amount of software continues to increase, and AI only accelerates that trend. This will require the same mental modeling, first principles thinking, and relentless curiosity that already formed the foundation of the software engineer skillset.
I think the core issue is not AI itself, it's people.
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.
The other thing is that a lot of this thread is talking about domain knowledge and ignoring it forgetting that a massive number of jobs in this industry are in web app crud.
There is a massive number of software engineers that are closer to plumbers than computer scientists and for them the progressing AI models are going to be a problem.
There's no point debating people who are in a blind mania. Sometimes it's better to just keep your head down and focus on what you can control while "mistakes are made". You will be infinitely more appreciated once they acknowledge that help is needed.
Sadly while I agree with this attitude, from experience they will ever get to the point of acknowledging help is needed. Eventually they'll find a way to blame the workers again to justify laying them off and double downing on doing things the stupid way.
> It's horrible to be a software dev right now, you've to deal with AI and lunatics.
Yes, yes, 1000x yes.
As a bit of an aside, I have been toying with the idea of adding some sort of second pass/security auditing/scaling offering to my consultancy for people vibe coding projects which wind up generating interest. (Not sure what the fuck else I'm going to do!) I have a few non-technical friends who have found themselves in this situation and there's a real need for it.
The aspects of it which I find daunting are the ones you've referenced, though. I imagine many people -- especially the ones who've built mobile apps for $300 in tokens -- are going to balk at the costs I'd have to charge for such a service. We're also now living in an era where everyone is an "expert" (lunatic) ... with just a little help from Claude/Gemini/Grok/whatever. I can already foresee people second guessing every suggestion, decision, line item, etc. I'd also be taking on a liability that'd be tricky to completely work around via legal language for any bugs or security issues which might/would inevitably slip through review. Ironic because nobody blinks when LLMs excrete those things.
But, anyways, circling back around. Yeah, trying to find work in this market has been a new exercise in frustration. AI is all anyone wants to talk about, it's driven hourly rates through the floor and most of the open gigs revolve around model training and carry an implicit expiration window for the trainer. It sucks and I really don't know what I'm going to do to keep my consultancy open going forward. (As signs of how desperate I'm getting, I recently signed up for Task Rabbit and am seriously considering applying for a job at Tractor Supply.)
I agree here. Sure, certain tasks that would take weeks are just one prompt away now. But out of a group of 100 people, how many are able to come up with the correct prompt?
To me looks like, if we're not collectively careful, civilisation will soon be on a path to an evolutionary dead-end.
Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack, meaning that only the owners of capital will be left, and they too will soon fade as the economy falls off a cliff and money has no value, because the only value that money has is the value of a human backing that, with thought, with ideas, with human output.
Whether you like it or not, "Economic output" is just a different phrase for "Human output that is valuable". When all human output is valued at the fractions of a penny per month of work, there is no future.
>Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack
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.
the grandparent commentor predicts 'that which replaces a sweng can replace anything'. llms sure do replace certain language related tasks, sometimes, when correctly piloted. however the majority of the world do not work language related jobs. perhaps if robotics firms bridge the gap to reality using some novel architecture this prediction could come a bit more true? until then it does seem blinkered to assume a set of weights could build a house.
hard agree on the last statement. programming is language. if you're literate you can code.
A new generation of AI companies is out there to take over blue collar jobs as well. Check recent YC batches.
Software engineering was a nice target because inputs and outputs are just data and you don't need to figure out robotics. But idk, 3 years ago it seemed illusory (at least for me) that LLMs could take over software engineering, but now here we are. They are still not 100% there yet (software engineers still have jobs), but we are getting ever closer.
Companies are in the process of figuring out robotics, and even if it's not figured out, then we might introduce a gig-ified blue collar economy where an unskilled, underpaid gig worker implements instructions by AI. Plus a lot of blue collar work already today involves robots (cranes, excavators, trucks, etc).
LLMs not but generalized multi-modal VLA models, yes.
Seems some on HN haven't been keeping up with progress in physical robotics. Unique physical work is lagging behind a bit, but not by much. Expect to see robots doing simple plumbing jobs within a few years, not a few decades.
>> Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack
> Direct quote
And, in your (and GP's mind), that means the same thing as "LLMs can replace plumbers"?
After all, I said:
>>>> When all human output is valued at the fractions of a penny per month of work, there is no future.
I mean, I know it's fashionable to not read the article, but are we all really responding without even reading the comments? Are two paragraphs well beyond the attention span of the readers here?
Okay, lets go with that asinine comeback: What do you think happens when the only work left for humans to do involves 100% physical labour and 0% thought?
How many plumbers does a society need? Electricians? Even in construction, you can automate almost everything away with cranes and similar.
Now imagine that all the doctors, all the office workers, all the warehouse workers, all the bankers, lawyers, teachers, ... basically any job that requires thought ... all those people are now joining the legions of plumbers.
That sort of 1000x increase in supply will drive prices to pennies.
The LLM doesn't need to replace plumbers directly; all it needs to do is replace everyone else, and the value of plumbers approach zero anyway.
Are plumbers not "in the employment stack"? How about hairdressers? Are they in the employment stack?
I have zero doubt that half of humanity can all have jobs continuously expanding the mansions of the other half who don't do any work but receive all the benefits.
Nope, just a specific kind. Those who developed and cultivated only a very specific skill set at the expense of all others.
I used to think being a generalist, and having persued technical roles with a people facing element was to my detriment, but it’s turned out to be the best decision I ever made.
Being a generalist was very useful to me 5 years ago. Now AI models have made everyone a generalist. That wide but not terribly deep skillset was immediately devalued by the AI models.
You can argue that the models fuck up 20 percent of the time, or that they make poor code but there is a massive part for the industry that is totally fine with that and I think people ignore it to their detriment.
The major blocker for manual labor automation in that fashion is cheap energy. China is ahead of the pack with the States' weight behind aggressive expansion of solar tech, and still can't do that.
That sounds more like a problem of close minded narrow focus on economic output instead of culture, virtue and spiritual traditions.
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.
> That sounds more like a problem of close minded narrow focus on economic output instead of culture, virtue and spiritual traditions.
I’m starting to be more sensitive to the argument that without god, people are unable to have a strong moral foundation. Not for the people expressing creativity in how they fuck, but as a check on those in power.
It takes a special kind of issues-riddled mind in very unhealthy place, for the lack of better words, to assume that people without strong faith have less morals.
In my own experience such people are often far from objectively moral or good people themselves, and overcompensate some deep issues.
> In my own experience such people are often far from objectively moral or good people themselves, and overcompensate some deep issues.
It is very true in my experience. It is also very not true in my experience.
FWIW I’m an atheist. Curious what you mean by issues-riddled mind. What issues? What’s the unhealthy place? There is no one person I’d accuse of lacking morality through godlessness, but I do see a trend. Most particularly in the people and communities who would have previously chosen godliness and replaced it with nothing, not those who previously would have chosen godlessness.
>i’m starting to be more sensitive to the argument that without god, people are unable to have a strong moral foundation. Not for the people expressing creativity in how they fuck, but as a check on those in power.
If this were true, why did the medieval peasant have less rights and autonomy in society than we do now?
There has been said so much about it in the past and I always believed it to be true, as an atheist.
I like to think that one of the symptoms is politics becoming really absolutist, idealistic and cultish. You do not debate followers of a different religion. But many topics really becoming kind of a mini religions.
I don’t know for sure though, there are arguments against it too and other factors.
I think substantial amount of people really need some kind of subjective spiritual experience to their life and maybe ignoring that need breeds some maladaptive tendencies
maybe if people werent busy fucking around so creatively they could band together as families and follow agreed social practices to ensure distribution of labor and charitable action in their local communities, maybe then people would care more about their neighbours and less about consuming shit. no thanks ... everyone too busy creatively fucking around and consuming shit while ignoring reality (eg partner count directly correlates to divorce rate, fill the blanks what divorce correlates with).
maybe thats a reason that god was deleted from the western cultural lexicon, so that broken communities could be capitalized upon? no way, surely god is merely a deprecated irrelevant vestige. it's not like a fractured social fabric is a ripe substrate of raw suffering to mine profit from. surely a few hundred generations were enough for our morals to have been encoded into genetics, we don't have to bother consciously practicing morality any more. that's for the narrow minded.
<alt version of above paragraphs from ludicrous perspective of individual experiencing theocracy and its own form of propaganda>
..... this isn't intended to be aimed at anyone except those who delete god to make money, and those who use god to make money. there's plenty of negative aspects to religion. the argument is intended to focus on the sheer idiocy of expecting morality to spontaneously manifest in the absence of external motivation or any teaching of lessons already collectively learned the hard way.
I think that social justice replaced the religious preaching of values in many circles but it was well… it’s not a sort of thing that many find appealing to follow.
Concepts like "checking your privilege" or being "canceled" closely parallel religious ideas of original sin and repentance, where individuals must acknowledge their unearned moral failings to become "good".
Actions like using specific pronouns, displaying yard signs, or performing land acknowledgments function similarly to reciting a catechism; they signal allegiance to a shared belief system and reassure the in-group
Protests and social movements often evoke the communal, revival-like atmosphere of religious gatherings, providing participants with a sense of purpose and belonging
> "Now I have CLIs that one-shots bugs across distributed systems for me. Bugs that I couldn't solve in the past. Bugs that would take 2 days of full-time debugging. Bugs across distributed systems that lack distributed observability. 90% of the bugs are one-shotted now, including bizarre race conditions, unexpected corner-cases, third-party integration issues, undocumented API edge cases, everything. I hardly have to intervene."
The fact that the author can articulate _why_ the AI is getting so good is kind of a moat for specialist, right? Imagine a layman prompting without domain expertise:
"There is likely a race condition here + [long-winded explanation and analysis carefully guiding the AI]"
Degenerates to:
"This button is not working, please fix. I don't care about code. Decide yourself"
> And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless.
How is that true? I've been using Opus on an industry scale over last 6 months and this is just not real.
It has consistently with a certain percentage of chance each time (and no claude.md and skills do not stop it fully):
* Suggested to remove tests to allow for things to pass
* Suggested remove an error so that things can be "unblocked"
* Suggested to use a second path when the original path ran into problem instead of making the original path accomodate for that possibility.
* Suggested or silently added "features" or "guardrail" that I don't want.
* Can be left unsupervised only if given a goal that it can verify against itself. Without such clear goal (e.g. this test in the integration environment must be fixed), it flounders.
I'm not using just the native harness (e.g. CC) either, with additional, customized harness, the behavior improves somewhat but are still fundamentally constrained and cannot really be trusted without verification.
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.
I think the one thing the author is underestimating, especially in his "first pillar" is that he is able to coach the models into great results because he already knows the lay of the land. I often make the same mistake. I see people struggle with GenAI, and feel flabbergasted how they succeed to fail, but then if you observe how they work the tool, it is clear they have no idea what to ask or how to evaluate and iterate on the responses.
He says that taste doesn't matter and it hasn't in the past. However, in an era of "extruded code product" (by analogy to https://tvtropes.org/pmwiki/pmwiki.php/Main/ExtrudedBookProd... ) automatically generated by the truckload at negligible cost, the differentiator for software developers will necessarily be the ability to create a product that doesn't reek of extruded code product, i.e. the things like quality that he labels taste.
(Whether any one reading this, myself included, survives in the industry long enough to reach the other side of that transition is a different question.)
[EDIT] The reason I use books as an example is that 4.2 million books were published in 2025 (https://ideas.bkconnection.com/10-awful-truths-about-publish...); 3.5m self published (with most likely LLM assisted or wholly generated) and the remainder traditionally published. (That's ~9,600 new self-published books a day.) Who actually still sells enough copies to make money in this paradigm and why offers hints as to where the software industry is likely headed.
This feels fake/engineered but regardless of that also redundant.
It's the exact same story that we've heard countless times by now. Hosted on a blog with just a single post. Named in a way that suggests that said blog was created for this very single post.
What is there to learn from this other than LLMs seem to be bad for some people's psyches and that AI companies need these very stories to not get their funding shut down?
Domain knowledge and architectural skills are not gone. I can say even Opus 4.7 and GPT 5.5 get domain-specific stuff wrong. I use both, because when I am not sure I ask both and also check with Gemini. But these days, I ask those even when I am sure - its like I get something confirmed from a peer.
And yes, you have to be the gate keeper - the speed breaker in a way - LLMs still lack a lot of context. And even if they get more context, they will end up costing a lot and still have no accountability. In accounting, one wrong entry and the whole system can be seen as "unreliable" - thats why you are needed. The interesting part is "who takes over" - accountants who become coders, or coders who become accountants. And the latter looks more likely, in any profession. And when that happens - the bar will be raised in these other white-collar professions too, just like what happening in tech.
Opus is getting good at architecture - I need lesser "pushbacks" either because I have learnt to say the right thing or it has learnt to do the right thing - I do not know which one.
Same boat here, just a couple years more experience.
Current LLMs are still kind of shit at actually programming so many jobs do still care to have professional programmers. However, I think it's evident that if things stand where they are, employers will care to have far fewer of them, at least of highly paid highly experienced programmers. If this is the state we're in with LLM adoption when they can't help but create the same helper functions 15 times, god knows we're screwed.
So we should probably work on clearing out our debts and figuring out what else we might want to do with our time, I reckon.
I'm still going to try to do a good job. I'm still trying to learn the best effective ways to apply current LLMs (Right now I still prefer to mostly write code myself but have been using LLMs to bang code into shape via iterative code review; this is a way to exploit LLMs to make better code, especially applicable if your velocity was already good.)
There are lots of positives that have resulted from using AI in software engineering. (1) No more long repetitive text editing sessions. I.e. changing namespaces or replacing deprecated APIs with the "correct" ones. AI will make nearly perfect text modifications with ease. (2) No more bike-shedding code reviewers nitpicking over every tiny coding decision. I.e, "you should use std::format instead of std::stringstream". AI will match the existing set of nitpicks so you don't have to. (3) Average Joe's and Jane's can craft applications by just talking to the computer. This might inject a freshness to the current state of software. Currently, we are all forced to use the same bloated applications like Word, Excel, Jira, and Photoshop. We are currently forced to deal with the same set of monopolistic SW companies. Now average folk can solve problems and avoid dealing with Microsoft for a spreadsheet program.
There's a certain irony in masters of automation lamenting that their roles are being automated. I wonder whether the jobs their efforts eroded in the past ever got the same thoughts...
Programming, logic, etc are skills and toolkits. The optimal state of society is everybody being able to apply them, not just the enlightened compsci caste. There was a time in the past where scribes were paid nice cash for their efforts, too.
I guess the lesson to learn here is treating a toolkit as an identity and job for life. By virturee of the essence of the job itself - if the tool gets cheaper and more widespread, it's aactually success, not betrayal.
You say that the optimal state of society is for everyone to apply programming and logic etc. but the obvious final result of these developments is that no one will.
Maybe the artform will be lost, but surely humanity will inherently be more 'logical' and systems driven afterwards?
Maybe using writing as an analogy is flawed, but most of humanity having 'writing' as a core skill did enable many other things, even if oral storytelling cultures suffered at its hand.
At its core, tech is all about breaking through inefficiencies and barriers. Does it matter if people can't code python if people demand government systems be frictionless in the year 2500?
Being able to program isn't the end game of critical thinking. Programming languages are just a way of representing the processes. The thinking underneath was always more important, and there's now technically more time freed up to focus on that.
Billions of people now have access to tools which will aid them in reasoning through complex problems without needing a $100k CS degree. Of course some people are using LLMs to get recipe inspiration, but others are now empowered to do things which were impossible for them before.
I personally think the alarm ringers are mainly the privileged elite who are scared of their moats beyond filled in. LLMs have effectively broken down the gates of access to knowledge. In a diverse world, having more people being empowered to do more things has to be a net positive.
I've come across lots of novel uses, though. I've seen non-technical people in law, education, hr, all spin up interesting projects/workflows which have helped their jobs/lives. The most interesting was a teacher who's dropped powerpoint, and is creating interactive lesson experiences; mainly presenting the content through popular games and creating engaging activities to apply the content. A recent one was a mock UN summit presented like a game of Civ with territory mechanics. Absolutely zero tech background, just curiosity.
Once people get over a few hurdles, things like:
>tech's too confusing
>$20 is a lot of money to spend on a subscription
>AI is just a fancy search engine
>AI will do all the work for me
You start unlocking a fair bit of creativity in people. I mean, all this is brand new stuff even for tech-savvy people. It'll take a while for the genuinely useful uses to dissipate out into the maasses.
Not everything has to be a billion dollar business.
My prediction is that the review / human in the loop part will become much bigger and more discussed.
Current transformer technology will either plateau or eventually we will get to that singularity bracket. (I was a skeptic once but all signs point there)
And this means models will eventually get better.
The main human value will be
- intent (we call the shots of why and what, AI will take care of the how)
- taste (everyone now immediately identifies Claude designed landing pages, they all look the same, taste changes with time, and can’t be predicted)
- supervision, both before and after AGI, to ensure no accidental damage, no misaligned decision drift, or in the unlikely but still statistically possible case of AI going rouge
Anything else (if we don’t plateau) can be eventually achieved.
Having that said, the fact AI can do it, doesn’t mean we’ll want AI to do it.
If there will be enough demand for handmade creations (with the current anti AI sentiment I can see it having an impact at least as similar to organic food) then we have some hope.
The bitter lesson is that there is no domain that will be left which AI won't get good at eventually. So really you have two options: if you actually believe the timeline is long you can keep retreating to the sectors that will be taken over last (emotional support nurse etc) or you can just say if you can't beat me join em and try to supercharge your career/project/life with AI now so it improving helps you rather than hurts you.
The supercharge bit missed an important fact: that strategy is very temporary. Getting expertise in software development takes a long time. Getting expertise in these LLM tools takes a lot less time— the combination of LLM expertise and dev expertise is the useful part. If LLMs make working developers, say, 35% more efficient, that’s going to be many thousands of people out of work, many of them being the most experienced and expensive we have. It’s not like those people are all going to give up immediately and become DoorDash drivers — they’re going to fight tooth and nail to get a job that uses their existing hard-won expertise. That means they’re going to level up their LLM knowledge, be willing to work for a LOT less money, and bring down everybody’s wages in the process. Companies don’t pay people based on the amount they bring to the company — they pay people based on the going market rate. That’s about to be a whole lot lower. So no matter how much you supercharge, you’re only buying yourself a little while until the labor market catches up. Nobody in development is safe. The entire field was so busy seeing how fast they could saw branches off of a tree that they didn’t realize they were standing on the wrong side of the cut, and the business side of the industry could not be happier about it. You’re basically working as a manufacturing engineer in the 90s US specializing in moving processes to offshore facilities. Probably felt pretty clever for a few years until they got the pink slip.
Honestly, the only hope that the dev field has is this all being so economically inefficient that the industry as we know it collapses after the VC subsidies run out, and we’re going to pivot towards much more reasonable interventions with local models and such.
I've consulted with some big companies on AI strategy. I tell them there are two approaches to AI.
1) Train AI to replace human work. This gives you 50% quality for 10% cost.
2) Train AI to assist human workers. This gives you 200% quality for 110% cost.
Most companies will go with option 1, and it's a race to the bottom. Eventually, someone will go with option 2 and gather up all of the pieces and take over the market.
“We were taught that generalists and specialists will always have their roles. But now the market is shaping everyone into becoming a generalist.”
I see this as a negative, the whole once everyone has everything than everyone has nothing type of argument. The company I work for believes strongly in keeping humans in control and in the loop which is something I’m grateful for but at the same time who knows how long that will last. Companies are starting to get their AI bills and realizing how much this AI usage actually costs so only time will tell but I hope, for the sake of everyone, that those with the knowledge described in this article make effort to keep their brains in shape.
> I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
Don’t sell yourself short! Taste is not promptable, I suspect good taste is AGI-complete.
Especially in domains like fintech, there is a lot of accumulated wisdom, and that is what you’ll be handsomely paid for (for at least the next couple years :/ )
For example, architectural patterns, when you need bitemporality, immutable logs, CQRS, all these good patterns that can only be learned by owning years of system architecture - none of these feedback loops are in the training set.
And from a product design side, agents will just miss key concepts and you need a few words to prompt a fix - but that might represent a massive tree search optimization, or the agent on many cases would just fail to identify the requirement. These small steers feel small, but by evaporation our work has distilled down to just the extremely high value insights.
METR task time is still at weeks, doubling every 7 months; it’s years (assuming we keep riding this crazy exponential) until you hit multi-year tasks. I don’t see wisdom / Métis being solved in 2027.
All this said - I think it’s important to extrapolate forwards, if the trend continues, this will may all be true in 3-5 years. Now is the time to pre-register what metrics would make you worried, so that you can define your red lines. There will be a rapid consolidation of power and wealth if these tools continue on their existing growth trajectory.
Agents are getting good but professing they are surpassing you in domain and architectural knowledge with no special prompting is basically self reporting at this point. That could be your job wasn't that complicated or your personal knowledge wasn't that strong, either way, same result.
Don't get me wrong, I am sure we will get to all three of these pillars, probably by next year. I am not naive.
The OPs domain/subject matter expertise is the part that should elevate their career. Understanding how large applications are constructed should also remain a pillar.
The coding and debugging part will be GenAI and possibly guardrails (harness engineering) tuned specifically for fintech, which they are also well-suited to implement.
Many people share this sentiment, many people don't.
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).
> LLMs are regression-to-the-mean machines--they pull junior developers up, and drag senior developers down. Taming them requires trading the romance of 'code as craft' for the physics of manufacturing.
The thing I don't know is: how do we decide which direction is most valuable? I can see arguments in both directions--quality vs quantity, essentially. I think there's a strong argument for the value of both:
- we need more quantity of software: for a long time, the ability to write software has been locked up, confined to a closed cabal of specialists
- we need more quality in software: we depend more and more on software in every aspect of our lives, mistakes are intolerable and should be avoided
I have not seen evidence that they are regression to the mean machines.
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.
I'm curious what you think of as "the mean"? I consider the input training set for an LLM to contain its mean. My hypothesis would be: an LLM alone cannot consistently produce code above the mean of the quality it was trained on.
The input training doesn't matter much, besides, the input training is already skewed for code that has been submitted after much trial and error by a dev locally and possibly reviewed. And input has an over bias over open source projects, not crap internal tools no llm has ever seen.
There's more to the quality of the output, like prompts, the quality of the codebase (from which the llms learn), the documentation/harnessing, the feedback an engineer provides while reviewing multiple times (in the chat, in the diff, in the pr) etc, etc.
The problem with “code quality” and LLM’s taking over your first 3 “pillars” is basically that LLM’s don’t care.
I recently had Cursor evaluate a huge code base that we took over. All public stuff, nothing scary security wise, but it was so convoluted that it was taking me forever to find the bugs. It was written by a person, I should add.
I did this in cursor and after one prompt using Plan, it found all the bugs, created a plan to fix them, it looked good, and I had the agent create the fix.
It took 30 minutes.
The client had this project in the hands of another company without ai tools and they couldn’t fix the bugs she told them about.
So my point is, if we are holding on to our jobs for dear life on the basis that “code quality” matters, you might as well kick down the 4th pillar. Like I said, the LLM does not care.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
I think the author downplays how much of that knowledge is used on knowing what to zoom in on, what to prompt, or what to look for.
Like all my C skills that I spent ten years mastering aren’t that useful either. But being a hard worker, smart, able and eager to learn new things, and able to judge accurately if I am helping people out (boss, coworkers, customers), these are and always have been the keys to my being a good hire. It’s a great world for smart, kind and hard working people. No idea where the LLMs are going but it will be interesting and I will be able to use and explain them in useful ways for people.
Yeah the writing is on the wall. Not just for knowledge work, but for jobs in general, as I've been saying in other comments. The era of wage labour, and this dominant economic system, is coming to an end. There's no way it can coexist with AI, but it also needs to continuously push for better AI, which means there's no stopping it. The only thing to do really is brace for the disruption - which will likely be pretty rough - and hope governments play their role properly to ease the transition.
I agree but I think it would take awhile. Some of us here seem to believe 2026-2027 is the end of programming jobs. At least that's Amodei seemed to be saying but then changed his mind later on?
Well given the pace of improvement so far, it's possible - though not given, IMO - that before 2028 we'll have models that make programming jobs fully obsolete. But that doesn't mean jobs will suddenly disappear; many places, especially in 3rd world countries, will continue to have humans programming for a while yet. Just that the available positions will slowly taper out over several more years, until only the most critical systems are maintained by a few humans, and programming - and other knowledge work - becomes purely hobby. Manual work will follow the same trajectory as AI also accelerates innovation in robotics.
Interesting that this dev sees domain knowledge as the most important part of his job. Over my nearly 30 year history, I consider domain knowledge as the least important aspect, and in fact have experience of many varied domains. 3 years web development, 2 years systems administration, 5 years point-of-sale / payment systems, 3 years performance management software, 16 years games development, 2 years GPU development tools, etc.
In every case when I've shifted domains, the skills that have got me the job were demonstrable solid programming experience on a wide variety of systems, with only a tangential link to the new company's business. In each case, I've gone in knowing almost none of the domain knowledge, but it's never been a problem because the business analysts know that stuff and tell me what they want me to do, or it's been stuff I've been able to pick up in the first few months.
For example, when I switched to games development it was the combo of systems admin and web backend development that the company wanted, I actually used none of those skills in the first year doing what they hired me for, and pretty quickly I'd transitioned from that to become a rendering engineer, and I've now spent the majority of my career optimising shaders and game engines.
So for me, it's certainly the case that I value my adaptability across domains, and I'm not worried about having to shift to another business domain because I know I'll be able to produce whatever it is they want if there's a reasonable spec in place.
Sure, when hiring if you have 2 candidates - 1 with the exact domain knowledge you want, and 1 without, the one with domain knowledge has a head start, but in the case where nobody has that domain knowledge (or in the case of the article, it doesn't matter because AI levels the field), then I don't think it matters much. Personally, I'd rather be the person with the broadest skills and able to pick up what I need than to have been stuck doing the same thing my entire career.
Most people don't really want to acknowledge this because most people have optimized only for learning domains and are still terrible at the job of actually putting together solutions, writing software, etc., even after 8+ years of work ostensibly doing exactly that. Constantly falling standards agree with them, though; no one really cares to have good software that is well put together, it's more important to have surface level knowledge about frameworks and domain knowledge that can be taught in less than a month (though most people think their particular domain is oh-so-complex and difficult to deal with).
There’s one force where software engineering is being automated by LLMs, but the other force is that there isn’t really much more software that needs to be built. Even before AI coding became big, back in 2021, we were already in late stage SaaS territory where each new idea was an increasingly minor variation of an existing idea. There were no new GitHubs, Herokus, Stripes, Salesforces, Instagrams, Reddits, just variations of those for more specialized markets.
It’s really unfortunate that AI hasn’t raised the ceiling on the space of possibilities as much as it’s raised the floor on how much can be automated, we’re all getting squeezed in the space between.
Can't disagree more! There's bottomless demand for more software. Here's a few examples I encountered just in the last few weeks that wouldn't be feasible before LLMs:
- More localism. Are you afraid of being cut off from tech by some future US government? Now it's feasible for your local culture to grow its own office suite, operating systems, Active Directory competitor etc. A less interdependent world with more competition does have its advantages.
- The building management company for my apartment sucks. Basic problems go unfixed because they appear to suffer extreme labour shortages and serious problems with flaky labour e.g. employees that just randomly go AWOL in the middle of conversations without bothering to tell anyone. A lot of the work of these employees is actually just coordinating and paying contractors in response to problem reports, something that can now be automated by AI ... but they haven't done it yet.
- I just finished assembling some flatpack furniture. Every time I do this it reminds me why IKEA dominates the market. Other furniture companies give the strong impression they don't usability test their instruction leaflets. This should and could be massively better: AR assistance during the build would be great, AI stress-testing instructions to verify they make sense would be great, AI checking every packet has the right number of components in it would be great. And there are lots of furniture companies out there. They don't all need to use a single SaaS to do this.
+ in general robots will require tons of software/models to make them do tasks usefully, especially as they lack training data.
That's just a few examples of places software could have made my life easier in just the last few weeks.
> there isn’t really much more software that needs to be built
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.
The saying goes... first we shape our tools, then they shape 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?
Interesting Tony, you seen to have been working for the AI since long time. We others are catching up but eventually all of us will be working for it, as directly or indirectly we are already doing. The "robot" was figurative cause we are no different from a machine, but that is too much for humans to comprehend.
I work for myself and the world, not for Ai. It's a tool without identity, but a damn good one that multiplies my capabilities.
I anticipate the first bifurcation to be wheat from chaff. Ai is going to do better at a job than say half the people, those who don't care about the effort they put in or the quality of their output. These people will have to come to terms with their mediocrity or blandness.
I'm still unsure what the good ideas are for when we reach a world without labor scarcity.
<I'm still unsure what the good ideas are for when we reach a world without labor scarcity.
It should be real creativity the final goal to this life optimization. For now many of us need to fight for survival, for food, shelter... so is a bit difficult to be purely creative. But is also true that given all the benefits (taking off the survival instinct) makes creativity obsolete.
>I work for myself and the world, not for Ai.
Yourself really? Start by defining "I", "work" or "yourself"... then we may proceed to the next LOL
From someone who thinks there's too much AI doom right now and is a glass half full optimist: If you are a software engineer reading this and panicking, don't. The author only mentions his codified, stable knowledge like you'd get from a distributed systems O'Reilly book.
There's no mention of the functional elements of a software engineering role - incident response, working with auditors to define and maintain controls for internal services, handling escalated account support & fraud, working on DevEx, selling shovels (MCPing your consumer-facing APIs/services), getting on customer calls to help sell your company's X feature, managing people downwards and upwards.
The piece kinda reads like remorse over sunken costs and attachment of knowledge to personality. If you twiddle your thumbs and stay static in your role, you will be replaced. It's the differentiation that sets employees apart. And attaching yourself to functions instead of knowledge is the only way to stay afloat.
Yes, Code Monkey jobs are gone... I can assure you though that there are plenty of hard problems that reduce human suffering which still need humans to solve them.
Do any of us? But I think it's kind of backwards the way it's presented in this article; the raw code part it has down more so than the design sense.
I also would point out that, while this thought has occurred to me about the skills being commoditized, in practice I don't see that everyone's getting the same results from the tools. Not sure what's going on but that's interesting.
Author says Claude now one-shots distributed systems bugs that used to take him two days but most top comments here are still playing down frontier model capabilities.
Are we collectively in denial? It's understandable as the craft as we knew it is being disrupted by tools that have improved at an astonishing pace.
I’m excited about the genAI future. I’m a software engineer interested in product, user experience, architecture, and entrepreneurship. After 4 years in the industry, mostly within fintech, I have gotten tired of slow organizations, company politics, nontechnical managers doing the decisions etc.
I’ve saved up a couple of months of salary, have a couple of bootstrap ideas that I believe are within reach for me equipped with a coding agent to build. Hosting can be done almost for free. What used to take entire teams and hence millions of dollars to build can now be done a lot cheaper. If I’m lucky one of those ideas can pay my bills soon. If not I’ll go back to consulting for a couple of months.
> I still have one pillar standing, though: code quality and software architecture - what's now being reduced to being called "taste".
Genuine question: what exactly is "quality"?
It's something I've been trying to understand for a very long time. It seems like it's entirely contextual, and it has both subjective and objective facets (the latter only for quantifiable things, and still entirely contextual).
If you're using the product, and you want to question or debug what's going on, you can:
* Jump directly to the single relevant part of the frontend responsible
* Likewise with the backend. The layout and naming of the code should scream its purpose.
* Once you're looking at the code, it should be trivial to run it, right now, instantly, in unit test, or cli. You shouldn't need to stand up a database to see whether your code rounds taxes the expected way.
The system contains its own checkability. You can, for instance, just sum up all the incoming money and outgoing money and see if your balance is correct. (It's not enough to have good tests today, if you're working on data that was incorrectly calculated and stored yesterday)
Ah the age old question: what makes something good? I think you’re already describing it well at a high level; context matters, and there are multiple axes to consider. But that’s extremely vague and doesn’t help you identify or measure quality, so it might be worth listing as many specific axes as you can.
Maybe ask the same question about other things. What makes a good guitar? What makes a good chair? What makes a good airplane? What makes a good book? What makes a good song? What makes good art? Each of these has a long list of very specific goals and concerns. And to help define the boundaries, also ask what makes something bad, and what makes something mediocre.
Code quality starts with functionality. Does it perform the stated requirements? Does it have testing in place to catch breaking changes in functional requirements? That’s the basic stuff that probably isn’t part of “taste”. A lot of code quality goals center around how code changes over time, and beliefs about designing to avoid functional breakage.
For example you can ask things like does the code use minimal dependencies? Is the code organized into clean classes/modules/functions that each have a single clear role? Is the API easy to read, understand, and use? Is the API hard to misuse accidentally? Is all the code easy to read? Is there documentation, and is the documentation useful, and more than a list of contents? Is the code self-documenting? Is the code efficient, both in how it executes, and in its use of code itself? Is the code designed so that it won’t fail when someone runs it with different sized types, or a different compiler or execution environment, or on a different architecture? Is the code surprisingly elegant and fun to use?
Those are just the beginning. There are of course more layers of application-specific and environment-specific and audience-specific qualities. The good news is that quality depends on your own goals, you can decide which aspects of taste matter to you, and ignore the ones that don’t. It’s fine if your taste & goals change over time.
Good question indeed, I think quality matters less these days because it's trivial for an LLM to increase code quality.
Quality is usually observed from a human perspective. But in my experience, codebases that humans would judge as "low quality" are actually fine for LLMs. They don't have as much trouble as we do with spaghetti code. They don't have problems with readability or obscure syntax, it's all perfectly fine for them. They don't care about indentation either.
Also it's really easy to increase the quality of the code base. You can just prompt to add unit test coverage and it will. You can prompt the LLM to handle edge cases better and it will (you don't even have to specify which, it helps, but it's optional). If you want to have better separation of concerns, just ask the LLM to have more separation of concerns and you'll have it. Documentation lacking? Just one prompt away. More robust build pipeline? You get the idea.
I still struggle to accept this when my colleagues are producing implementations with AI assistance that are consistently broken and don't do what they think they do. As yet I can't square this circle, no one is better at their job than they were before.
I feel that I am faster and better, sure, but trusting self perception would be an absurd thing to do.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
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.
I’ve found it extremely hard to get LLMs to exit the basin of your current knowledge.
One of my tests for new models is to ask about a concept I already know the mathematical model for, but as if I don’t. So far, they all answer the same way:
1. Convoluted explanations about how it kinda-sorta is common terms.
2. If you follow up with the correct mathematical term, it immediately claims that’s correct and the right way to model it.
3. If you ask it why it didn’t use that term for your question, the LLM gives some version of explaining that it tried to match your language.
I have no choice but to assume the model behaves similarly other times — and that I am largely trapped in a basin of my own ignorance, when using LLMs.
LLMs mean less devs are needed, not no devs. even after serveral more decades, they'll need steering. I've seen agents stuck chasing one issue, when to me the issue was obvious, but I can see how the model would rule out the obvious easily and move on, but my instinct/experience tells me that's where I need to focus time on. This translates into costly token-waste. Secondly, it isn't simply "quality", the LLM might generate something that's good quality from its perspective, but it simply won't consider things unless it's explicitly told to in excruciating detail, and even then! understanding things from a simian point of view can't be perfected without that simian experience as part of its training. It can come very close but not quite.
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.
Jobs have always been a bad deal, especially for most people. Very unfair. Less unfair is entrepreneurship. LLMs (VLMs) etc. should make that more feasible for a broader range of people.
Realistically, what should we have done instead? Not invent LLMs? What happens when a couple thousand people invent the next disruptive technology and even more of the population loses their jobs?
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.
I don't believe agents care less about architecture than us. Badly architected code has the same effect on them as on us, namely to slow them down and degrade the quality of their output. Which translates to the same thing as well, loss of revenue.
Coding agents are driving up the value of architectural skills to the detriment of more specialized/technical skills.
I think that the domain knowledge still matters: if for nothing else, then at least it can make the communication both with savvy AI tools and savvy humans more effective compared to "outsiders": acquired vocabulary, truly grokked concepts in the field of target expertise etc… -- that all seem like a huge competitive advantage over folks having to learn all that "on the go", constantly struggling to pick the right nomenclature or using wrong or vague terms. It's mostly that domain knowledge what makes experts understand problems faster or at all, even.
I code myself now and have given up on LLMs, no matter what, they eventually make a codebase unmaintainable. The uncertainity of LLM generated code has been screwing up with my peace and guarantee I have when I wrote code myself. LLMs are not AI they are Jack. Jack of all trades, Master of None.
Engineering hasn't gone away, you're now just directing things at a higher level. You are now a architect & manager (but you're managing agents not people).
Who sometimes has to deep dive & mentor a agent on solving the right problem.
AI is beat thought of as an exoskeleton, you'll be at a huge advantage if you learn how to use it properly, and you will, unfortunately fall behind if you don't. I still think we're going to need people who can reason about code, and the amount of code to reason about is exploding in volume. Think of it as doctors having access to better drugs and techniques - they can can cure more illness, but the bar and expectation of what they can do will just raise. And doctors are still well paid, because what they do is important and needs doing well.
Well, not a single 20th-century science fiction novel features programmers; instead, there are platonologists, biologists, and linguists. Humanity is twenty years behind in development because the previous twenty years were spent solely on e-commerce.
>Agents do a really bad job at keeping codebases organized.
If you do a disciplined way of development with agents by keeping all Documentation in markdown format, repo structure, Decision records and architecture, they do absolutely organized. Every new module should be documented and the editor configuration and coding patterns can be given as reference. this worked well for me. and it make enhancements, extensions development without any big troubles.
I’m just continuing to get paid as long as I can, while also going back to school part time to train in a role that’s insulated from AI. Having a backup plan at least makes me feel better day to day.
I am mostly worried about the current AI use in management. I’ve met a few with ”AI hubris” making poor managerial decisions that stem from their poor usage of ChatGPT (not understanding the importance of context, model sycophancy, etc).
Coding taste and good architecture are the final pillars because AIs are trained on a ton of bad examples that are presented as good examples. That pillar will stand until AIs are able to reconsider and re-evaluate the material they've been trained on.
That should help, but there is a fundamental problem. A conscious entity exercising good judgement can say they don't know a good answer or method for getting one, but an LLM will always compose a response for a given prompt.
"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.
> 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.
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?
I think that huge deflation will follow for everything except land value.
If automation makes producing food so cheap that it is almost free than it is ridiculously easy to acquire it. Similarly automated construction.
The way I see it the economy will point towards outer space. That’s where most jobs and flow of economy will be.
However most people will have 10x times uplift in purchasing power compared to today so their relative poverty will be ridiculous for us to call it the poverty but they will still think they are poor and troubled.
Generally I don’t think it will be utopia for the people living in that moment but if you look from medieval times at today it looks like utopia for serfs from the past. You however wouldn’t call it an utopia because your standards grew as fast as your purchasing power.
I think that rich and poor will be separated by accessibility to anti age treatment and other bodily improvements.
The tragedy of the poors in the future will be living measly 80 year old life like a today millionaire and that will be considered lower class. Those people with wrinkles we don’t want to look at because of uncomfortable pangs of guilt.
So you believe that your work will be done by AI and you will enjoy life more? This is not a loaded question, just trying to understand what your future ideal day / week would look like as an "ai optimist".
That’s just not economically viable. Even if it becomes viable after some singularity event the path there will be 1000 the upheaval seen during the wipe out of manufacturing and mining
LLMs can synthesize the domain knowledge so long as it's within their training data. At some point, blindly trusting the decisions they make becomes gambling.
There is this over indexing in training data that I find quite problematic.
I have really good results getting LLMs to read documentation and work of these. This is in domains probably sparsely represented in the training data.
I used to be in the "AI will soon do all your thinking for you" camp, but I was overlooking a scenario: sometimes the gap between what you understand and what you're trying to achieve is so wide that no prompt can bridge it. Simply asking "what's the right question to ask?" doesn't feel enough, no matter how advanced LLMs become.
Even if the model can replace a domain expert on the software side, you still need a human who can decide if the technical solution actually meets the business needs and that would require a human with domain expertise.
Software engineers with low self-esteem who built their entire identity as mechanical cognitive workers are having an identity crisis and spreading FUD.
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.
It doesn't matter to your boss. He will still fire you and replace you with a slop machine. Then you will not be able to get a job again and you will have low self-esteem.
That is limited thinking. People are replacing their bosses, and your boss will be bossing what exactly? Right now LLMs cant' replace the entire spectrum of human intelligence. But if your entire work is just translating your boss ask to for-loops & if-statements, the I guess yes, I would be worried.
If you really think those layoffs are due to AI, then you haven't worked in corporations long enough. If companies are not hiring, and are firing, then what do we need middle managers for? In fact, if an engineer is really smart and masters the tools, what do you need POs, managers, executives, and even sales for? If you stretch things to the max, those who master the tools are positioned to automate everyone aside from the capitalist, as they are protected legally
Chinese Gen Zers are starting companies before graduating, people are generating music and starting their own studios, others are improving models and building harnesses, and the rest are on a mission to automate the entire knowledge economy—from healthcare to governance.
Regarding your employer's bank account: if that is all you were doing before, then that is all you will be doing after. You are just complaining about capitalism now. The irony, is that the means of production is now in the hands of millions. Those who are crying are those who paid their mortgages with for loops..well, I think they will continue doing so, with less hubris that's all. LLMs are nowhere near replacing full engineer.
>Chinese Gen Zers are starting companies before graduating, people are generating music and starting their own studios
Both of these have been happening before the advent of LLMs
>The irony, is that the means of production is now in the hands of millions
The "means of production" means jack shit unless you have the capital to scale up rapidly
>Those who are crying are those who paid their mortgages with for loops..well, I think they will continue doing so, with less hubris that's all.
Why is it hubris to give a damn about you spend 40 hours a week doing, or to lament change when it works against your enjoyment of those 40 hours a week. God forbid people value their time in any way that isn't monetary.
> Both of these have been happening before the advent of LLMs
I'm not sure about that. I read they are making better use of AI to accelerate building their businesses. Apparently, in China, people were not looking to work in corporations anyway, so they saw AI as a means to escape them.
> The "means of production" means jack shit unless you have the capital to scale up rapidly
There are people topping music charts without even having a brand; they just produce good music. There are people automating entire marketing pipelines to minimize capital expenditure, and there are people building niches for small crowds and making a good living out of it. Not everything needs scaling.
> Why is it hubris to give a damn about you spend 40 hours a week doing, or to lament change when it works against your enjoyment of those 40 hours a week. God forbid people value their time in any way that isn't monetary.
If you enjoy writing loops and if/else statements, you can still do it, but the market won't pay you when there is a tool that does it faster. That is the nature of the domain. Have you ever thought about the jobs that software engineers automated? What do you think those people did? They adapted, learned the tools, and moved on. This is the first time we are seeing automation at this scale in software engineering, and the reaction of software engineers is exactly the same as those in other fields.
Regarding hubris, I've been in this field for 20 years, and there are people in it who are just intolerable, frankly. They memorize every Vim command, refuse to use any other tools, and treat everyone else as less intelligent simply because they can write code... those people are getting humbled hard right now.
What work remains valuable when implementation becomes cheap? How about moving closer to ownership?
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.
Businesses like a record of reliability, so devs going solo with AI is going to be a hard sell. I think we will know that AI is actually good enough when these AI providers start absorbing project management companies and hiring contractors to use their product instead of selling subscriptions.
I am also feeling anxious. I lucked out by having natural inclination towards software development, career which can provide good upper middle class life to anyone. But I feel like writing is on the wall. If I don’t find a way to pivot to something else, I might experience class migration, but in the opposite direction this time.
It’s a good time to save and move out to a cheaper country to buy money generating assets here. It’s not easy but if you have at least one million dollars in investment money, it’s arguably wiser than staying in US that penalises such passive lifestyle heavily. Sooner or later some medical bill will leave you bankrupt. Unlike in EU.
It's not just our careers. In the hunks versus nerds wars, it is now clear who has won. The nerds have made themselves obsolete and put the continued evolution of homo sapiens to an abrupt halt.
I wonder how do people use LLMs so it does not hallucinates. Like 90% of the time the code is impeccable, but the remaining 10%... Let's say I determine the expertise by how well do people act of these 10%. For me, the first pillar is still there, but not in a good condition
Easy just add "Make no mistakes" to the proompt, clear skill issue.
In reality people who use LLMs so it does not hallucinate are the ones that just have to little knowledge to actually see when it does, because LLMs do and they always will. That is the only thing you can get with a stochastic word predictor.
This reads like a self thought ecommerce/small company employee finding its place in the tech world. These people were erased first, understandably. I am meeting more and more of the same type of people.
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.
"Except that nobody cares anymore." Noone (from mid-management) cared about it also before. You hit the deadline, get promoted and leave the technical debt to the next one. Even if you're the one to deal with it, you set up the next project, get the budget, prioritize the issues etc. Not much changed in this regard with LLMs
Agents may have made 80% of your experience go to $0, but the other 20% is exponentially more valuable now. This outweighs your other losses.
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.
It's not just about it taking the technical competence away from our job, it's taken away the joy [1] which I wrote about.
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.
I don't know how else to say this but LLMs are just word calculators. They are becoming better for sure but at this point even Claude 4.8 is absolute shit at any complex task in a not so common field. I have been working on terrain contour matching algorithms for the last few days and, oh boy are the predictions about AI taking over the world wrong. Its the highest level of bullshit I have ever come across in my life. I ended up writing 100% of the actual algorithm myself. It's a productivity mess.
That's an extremely niche specialty though. 99% of software development jobs are web frontend/backend or mobile/desktop apps and they are more at risk from LLMs.
I read all the posts in this thread - but no one has a good idea to avoid software developer obsolescence. My guess is this profession has 5 more years. It was a good run while it lasted.
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.
Ok so it’s five years now? I’ve heard for the last three years that software developers will be out of job within the next 6-18 months. I’m glad to hear I’ll have a job for a little bit longer.
5 more years? That’s quite pessimistic, given how much evidence we have that LLM coding has as much of a long tail problem as any other tech we’ve created.
Don't need much training data for bank/insurance/retail analyst work - it's just basic reasoning and data retrieval. If AI could crack the programming nut - one of the most intellectually challenging professions - it can handle the rest with ease. The only human role will be high level monitoring - and even this will be largely automated so fewer will be required.
Sorry to reply to myself but I just recalled the recent Apple ad that ran last year about a corporate goofball who got his Apple device to fire off well crafted email slop to his manager who looked surprised/impressed. That trick will only last for a short time. The joke is that people like him and his manager will be the first to be fired.
The direction I'm given is to take humans out of the loop. As much as possible. Everything AI. Automate everything. If you are in the loop you are overhead.
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?
I think this experience is universal. The answer is the same as always has been - develop skills that are becoming most important.
Right now that is (at least from what I can see):
- Data analysis, data pipelines, models, etc.
- Tacit business knowledge
- architecture and design patterns (always has been, but now the scale os larger so this is even more important)
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.
One other thing I find it is bound to happen is that this domain knowledge you speak of is just going to shift towards LLM domain knowledge.
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.
Hear me out: what about just refusing to use them?
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.
My boss came up to me and said a coworker using LLM tools has shipped more customer solutions in a week than basically what I've done in 3 months.
The bosses are out to force people like you to use AI. And have been for months.
Maybe not your boss yet, but it swept through my office dramatically. Maybe two or three months from limited tests to now today FORCED usage of AI (people going around the office asking constantly if there's any AI that can help today).
----------
This has a few toxic effects.
1. You are not allowed to complain about code quality issues anymore. Any complaints are met with okay, we will get the AI to fix it.
No discussion, no elaboration. No one in the office is even interested anymore. AI solves everything.
2. You are basically in a position where you are forced to use AI, whether you want it or not.
3. I expect code quality at my office to drop dramatically as fewer and fewer office mates give a shit
The reason that I’m looking for an out is that it’s turned everyone I work with into imbeciles.
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 am kind of like of in the same place though roughly 5 years more than author.
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-dev
While LLM's are beyond junior level at this point, they're still just that. I don't really agree that the first two pillars have been affected.
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.
LLMs are good at general solutions but not specific solutions. As industries evolve and laws, regulations, and practices change LLMs will struggle because those things are not included in its training set yet. We'll always need humans to push companies in new directions in order to compete, unless we eradicate capitalism altogether and then we're all out of luck. No competition means no incentive to try and be better than the next guy which means no new products and services for humans to develop that AI hasn't seen already.
LLM is a powerful tool but it still doesn’t have the context that a person would have. A million tokens is a drop in the bucket compared to the overall context that the person guiding the LLM needs to keep it on track and being productive.
If 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.
“even though you're delivering code at a good pace, you're taking too long to deliver those Design Docs. Are you using AI? You should use more AI.”
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.
> when I step outside my area of deep knowledge I can no longer call BS on the agents
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.
That’s why I use AI more like: Write a tool for me that does this.
Instead of directly: do this.
Preferably I would interweave code and AI queries where some function waits on prompt result too I think?? To avoid too big context hallucinations
I mean that would work for my use cases.
At least what I learned is that the less AI itself does in the context is the better so to say as critical LLM mistakes are approaching 100% of probability over time.
The crazy thing is how many people who can write code (with or without uAI) are in fact using the LLMs in the latter "go do this" mode.
There are a lot of non-tech people using these products in this manner.
Along these lines my friend is CTO at a non-tech firm and theres vibe coding happening in one department on a project that is going to churn $1M of tokens. Head of that department told him it's OK because instead of paying a SWE annual salary, they'll just pay $1M of tokens once forever.
People don't know what they don't know about software, SDLC, support, maintenance, etc. If code was something you write once and never think about again, most tech orgs could be 75% smaller.
Code quality and architecture still matter, because they also make it easier for LLMs to reason about the system.
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.
Regarding code quality, the largest issue I've run into is pollution that stems from committing too much unfiltered LLM code. They introduce some type of structures into the codebase that are hard to read for a human, then start reusing them or use them as example to create new ones, then when a human needs to quickly hop in and make changes, it's not as easy to do.
> Of course, I'm still employable because someone has to review the code and steer the robot. But I'm just another off-the-shelf engineer now. I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
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.
I started feeling like a factory worker well before LLMs. My reputation and network stopped mattering and it all came down to take this assessment and do this Leetcode to prove you are a good enough replaceable cog. I have about 15 more years before retirement and I doubt there is anything left to look forward to in my career.
This anonymous article is likely more FUD from the AI industry. "Just give up,you can't beat the machine. Please go quietly, we want to take your place and it's easier for everybody if you don't resist because you believe it's pointless"
It's futile to race against the money hungry capitalistic machine, but it's not futile to steer your own career into work that's more lucrative or is more enjoyable, be it with our without AI tools.
My job as a staff engineer has turned into just reviewing slop farm vomit from offshore devs in Pakistan making pennies on the dollar given a slop code subscription and going wild.
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.
I've wondered about this a lot. I am brand new to software engineering, fully powered by AI coding. Traditional software engineers have to pivot hard or the are going to be left in the dust. The slow, methodical, take two days to put a change on a production site approach are over. I'm shipping exponentially faster than a co-worker who hasn't embraced AI yet.
I think the author missed the forest for the trees - the domain knowledge is what allowed him to successfully use the AI because he instantly knew what was correct or not.
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.
If corporations really thought LLMs were a great cost-savings tool, then the obvious target for replacement are not the lower-paid staff, but the higher-paid staff - the ‘product managers and stakeholders’. That justifies token burn, replacing the 7- and 8-figure people, right?
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?
The idea is to start with the largest, easiest lever. The one which will accelerate all _other_ automation. That lever is software development itself.
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.
Am I the only one that has noticed the massive increase in buggy software across almost every domain? Like, EVERYTHING has so many more bugs now. Things just break constantly. AI isn’t one shotting fixing bugs, it’s one shotting making hundreds of new ones every time it writes anything.
I have no idea what you guys are up to, but it is just a job, it is just a role, it says nothing about you or who you are and it is not tied to your meaning. If you make it so and your perception is aligned with that, then you are not in control of what happens to you. What kind of slavery it is to give other people so much control over you is crazy
The glory days are over. In the future, one software engineer will be able to support multiple product areas much like how one HR team can support 1,000's of employees.
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.
> The glory days are over. In the future, one software engineer will be able to support multiple product areas much like how one HR team can support 1,000's of employees.
I mean, it seems within the realm of possibility that much more productive software engineers make more and not less money.
I think we are all vulnerable and need to reassess what it is we bring.
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.
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.
> 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.
Sales are going to be drowned by AI soon enough. The low end is already getting yeeted by webshops, dropshippers and AI powered bots and a lot of B2C and B2B sales are shifting off of the classic representative sales model as well (towards self-service) because everyone that does not is cheaper. Basically if I have the choice between a SaaS that says "contact for a quote" and "X users => Y $/month", I'll always go with the latter option. And on top of that comes offshoring, that has gotten surprisingly good with ever increasing voice call quality.
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?
I'm not worried. You cannot hold a machine accountable and there's no way OpenAI, Anthropic, etc. are going to take on that kind of liability if some code resulted in a major outage or a lawsuit. Perhaps that's the signal I'd be looking for: so much confidence in the product that they put their money where their mouth is.
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? ;)
Well... accountability is a myth, primarily used to justify obscene paychecks for executives aka "you can't get fired for buying IBM". Basically, as long as you follow what everyone else is doing at the time, even catastrophic losses won't result in consequences. Just look at the recent AWS outages and issues - if you're a CTO and you'd have your webshop running on-prem, you'd get axed for a multi hour downtime. But since your webshop runs on AWS, you're following "industry best practice".
So instead of a programmer, you become a software designer. I recently came across the idea of building fantasy for the player (in context of games), but now that I think more about it. Onlyfans, is just that. Advertising, Beauty products, novels, games, TV shows, and so on. You're really just creating / selling a fantasy for vast majority of people. Most people will never lose that 30 lbs, but you can sell them all kinds of products to fuel the fantasy of them losing that weight, being beautiful, rich, healthy and so on. So an LLM replacing the need for you to write every piece of code, is actually kind of freeing. You as a a former programmer, should embrace your new creative role. Writing code, at least for me was always slow and tedious. I just want to be able to express the ideas I have, so LLMs just make it possible to build things I never could otherwise.
Maybe just maybe here in HN we are in an echo chamber that is convincing us that there is a theoretical limit to how far the LLMs can make progress. It’s not unthinkable that LLMs will make better overall architectural decisions or follow the good practices better or understand the problem in bigger picture (more access to company/product context already makes a huge difference)
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.
computers are made for automation. programmers were always working on automating things, making other things obsolete, and we have been killing jobs for decades. did you really think we would suddenly stop when it's your job? i'm happy this is happening, genuinely giddy
But this raises the barrier to entry into programming if LLMs are capable of doing the vast majority of junior/mid level tasks. This can ruin the lives of many average people for whom programming was one of the few truly possible jobs. I have a friend whose initial interests are not related to IT and he is not particularly passionate about programming, but it still brought him a decent income (unlike the profession he was passionate about). This is the people I'm talking about, they need some fucking stable job that brings income.
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
People are missing the long-term horizon on this. Yes, definitely, you can automate most of your workflows as a software engineer with today's LLM frontier capabilities fully E2E. But many things are still super open:
-First, cost is not a settled topic yet. We have no indication that automating everything E2E will be a cost-effective way of doing stuff. So the bare minimum is that you will need some expert designing the workflows in a token-efficient way. Worst-case scenario, tokens become super expensive and only certain parts of the job can be efficiently automated and many companies are not even able to afford tokens.
-Second, the system you just "created" is just a static snapshot of today. Yeah it may work fully automated for 6 months, maybe a year. What then? Breaking changes? Updates? Re-designs? What if the quality slowly degrades until nothing ever works again? Who will fix that? There are so many unknowns that it is borderline irresponsible to make guesses on what can be automated sustainably long-term or not. Unless you are OpenAI's Codex team wasting a billion tokens a day on automating and self-improving everything, there is a high chance that everything you set up today is completely useless in a year.
-Third, the core engineering workflow hasn't changed a single bit. People like stakeholders, product owners, PMs, etc. can come up with ideas and things to build but someone needs to take decisions on what gets built and what doesn't, balance out paying down technical debt vs. feature development, incorporate new domain knowledge into the system (Or would you expect your PM to be tweaking the prompts about a new regulation regarding GDPR or a completely new legal framework that changes the whole thing?)
-Fourth, probably the most important one. If you think AI will soon get good enough to get self-improving and self-sustaining enough to replace full engineering departments E2E with no supervision then nothing else matters because we will all end up without a job and living on UBI (not only tech people). So why do you even care? If it happens it doesn't matter, and if it doesn't happen we just continue doing what we were doing until now. Why do you care?
> Maybe I should consider transforming my woodworking hobby into a profession...
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.
> And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless.
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
This was a good summary. I feel similar. At this point I think 95% of the skills I've developed over the 2 decades are basically useless. Prior to 2023 I felt like every new skill only made me more employable, but now I don't really see any software skills that are safe from AI today. Even the ones that are very likely won't be in a year or two so there's no point in learning.
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.
1) How long has full self driving been just six months away? The last mile often tends out to be the hard part.
2) If the catastrophic scenario comes true where white collar work essentially disappears, what does "preparing" actually mean? There's not a whole lot I can do about that. It's like trying to make plans for what I'm going to do if I get into a coma.
The fact the whole world is going down with me is of some help actually. I can't stop the world. There is no preparing for that. We'll figure something out and if not, then not.
My non-tech friends will not suddenly be able to run servers or oversee AI systems. They will come to me with their ideas and I will turn the crank. My role will probably be named differently, something like "Intent Manager" or "Architecture Developer" or whatever but I have a strong feeling much of it will basically remain the same. The politics, the egos, the personality differences, AI has changed nothing in that regard. The jocks will not suddenly sit in front of laptops prompting Claude to debug their MQTT setups. You can say AI will do that and sure it will, prompted by me. If AI will do it autonomously then we're all fucked and I don't care about my "career" by that point. It'll be survival of the species time.
Much of accounting could have been automated. A good friend of mine has been manually entering paper receipts and whatever for well over 20 years now and his work load has actually increased. It's all automatable, but there are so. much. more. levers. Possible != will happen.
I do agree it's not the time to empty your savings account. Get ready for some rough times.
There is an element of human nature that is known as self delusion and it is extremely common. Almost everyone on HN is suffering from a form of self delusion.
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.
At the risk of being voted down for stating an unpopular opinion, the problem is that faith is neither provably true nor provably false. That's what makes it faith, not science.
Even though you clearly believe very strongly that religion is wrong, that's not a scientific viewpoint because science doesn't and cannot disprove the fundamentals of religion. Taking it further, you can't actually prove anything is true with science, because fundamentally it is about making hypotheses and attempting to disprove them, and those that remain and can't be disproved you accept as "scientific truth". But many "laws of science", we have already disproved but we still use them as approximations because they are useful.
One final thought is that people frequently have conflicting internal world views. Some people cannot tolerate that, and require a consistent set of rules that govern their idea of the world, but the majority of people are comfortable with some degree of ambiguity in that. In general, the more rigid and coherent your worldview, the less likely you are to accept that it might be wrong, which is why many scientists devote their efforts to disproving other ideas they disagree with, rather than trying to disprove the things they believe themselves.
I don't see it as negatively, in that there are specific trade-offs.
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 secretly wish LLMs take my job away because I'll get about two years of unprogrammed rest, which I absolutely will not take of my own accord. But it's unlikely to happen.
Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product. That first pillar is still there. Maybe the author isn't aware of the impact they have, but I know, with the evidence of reverted PRs, that when I step outside my area of deep knowledge I can no longer call BS on the agents. Our most capable agent, with access to the same kind of distributed systems the author talks about, is regularly wrong, frequently myopic, and just outright dumb constantly. It's the expertise of engineers on the team that push it back on track.
Posting this under a burner so I don't dox myself: I work in FinTech on a regulated product. We have access to Mythos. Mythos identified part of our codebase that it confidently asserted was not complaint with a particular regulation and we were at grave risk by allowing it to operate the way it was.
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.
I have worked on highly regulated areas in finance (risk). Compliance is a highly creative art, often requiring lots of out-of-the-box thinking and non-obvious solutions. The people I found worst at this were IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.
My guess is the model makes the same mistakes as the programmers: taking 'rules' literally, unaware of sectoral joint understanding, validated interpretations and habits. (btw. this is often on the non-tech side also a difference between regulatory and legal. The former are much more result oriented while the latter are primarily risk averse.
Ha. I've worked in a fairly strongly regulated sector (energy, in the Netherlands), where I collaborated closely with our head of compliance, and she heavily over-interpreted the regulations while I often tried to find more pragmatic solutions.
I think adherence to regulation and compliance is nothing to do with whether you're a SWE, a risk officer, or C-level, and everything to do with your own principles, ethics, professional attitude, and pragmatism.
> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.
IME this is less the fault of IT and more so bad auditors that won't consider, or just don't understand, what compensating controls are. If it doesn't meet their little checklist exactly, they fail the audit.
> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.
This is such a nonsensical claim. If a company is asking someone from IT to read the regulations and implement them, then obviously you’re going to get something that conforms to the written specification they were provided.
But a company that does that is basically delegating both compliance and legal functions to IT. No sane company does that.
It's cause IT never has to live with the consequences of their decisions. Who cares if the other department keeps bleeding talent because you twisted the knobs so hard no one wants to work in your system?
Sounds like communication between departments sucks. If IT develops for them, you’d expect there to be a feedback loop?
Yes. Exactly. This is not a reflection of where I am now in any way shape or form. Just my observation of previous places I've worked.
Who gets in trouble if it turns out you are actually held to the literal rule?
Contrary to what you indicate rules are not declared in a vacuum, for people to read and then algorithmically 'implement'. There are many ways to interpret regulation, and there will be both accompanying clarifications, as well as compliance departments negotiating with regulators on what is an acceptable and sufficient compliance action. Then there furthermore is a risk that will be calculated vs the cost and opportunity costs etc.
As an enterprise architect, these are all part of the meetings you have with compliance when you are working on major projects. I have had the privilege of working with some excellent compliance officers, and they are the opposite of the nay-saying caricature that is often painted of them. I found these people to be extremely creative and helpful, working together towards solutions rather than stalling or nixing viable progress.
I also work in finance and my recent experience with regulators is really discouraging. DOGE wiped out a large amount of the regulators in government. It seems like most of the regulators remaining are the inexperienced and low tenure. Within the past few months we've attempted to roll out new financial products. When we attempt to send our proposal to them, they can't even tell us who we're supposed to send it to.
It doesn't feel like we're living in the same world of regulation that existed prior to DOGE.
The point was about who is on the hook and why they might be less permissive.
I'm not implying anything else. I used your own "literal" wording to refer to the "more strict than yours" interpretation.
I suppose I should have used scare quotes around "literal".
'The company' would be on the hook. Inside, it might be the compliance team that signed off on the solution, but it usually is not the sort of blame game at that point. I'm not saying these scapegoat trails do not exist, but they are far less common than you would imagine if you only read about them in the press.
Company politics, feudal wars, fiefdom protections, backstabbing and outright sabotaging, now there's a daily occurrence and many minions are cannon fodder in those skirmishes, but they usually stay clear of regulatory issues minefields.
I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.
If the company you work for actually had such a no-fault culture, I doubt you'd be criticizing programmers so aggressively for being sticklers, but would instead be trying to understand and account for the systemic factors (including human factors) behind their behavior.
>I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.
I don't see why developers should be in trouble. Developers don't make unilateral decisions on non-trivial compliance matters. A finding of non-compliance at a financial institution would typically be the result of an investigation, a disagreement with the regulator or a court ruling. It would come years after the organisation as a whole decided to adopt the interpretation in question.
> There are many ways to interpret regulation,
Then the rules should enumerate all the ways. From your posts, you come across as if programmers don't know what they are doing which is insulting to those who work in mission critical industries like aviation where a programmer could be criminally charged if he/she didn't implement the specs STRICTLY.
"you come across as if programmers don't know what they are doing"
Is neither what I said nor believe.
That's why you work with your Legal/Compliance Team to make sure you stay in line. They can explain when a rule applies and when it doesn't. This needs the engineering side to be able to explain what's happening, and translate it into the business process as closely as possible, and the legal side to be able to apply the law to the case.
If you think rules are literal than you aren’t aware how the world works.
There’s a reason it’s called “judgement”
In your world, do subordinates ever get scapegoated for bending the rules at a boss's behest?
...And that judgement could take them literally. So what is your point?
My point was simply that it's easy to scoff at someone else being careful if it's their neck and not yours.
They could but they don't. That's pretty much the whole job. You can also appeal decisions to a more reasonable party if you draw RobotJudge3000 for your trial
It was my impression that a whole lot of products are only pretending to be compliant, and that it's much more profitable to operate like that.
I've worked in fintech for 30 years. I've never seen a product that was intentionally "only pretending to be compliant" with laws.
I've seen accidental non-compliance. I've seen what I would call negligent compliance, where a company attempted to be compliant but didn't meet full, correct compliance (one example I've seen is that a company assigned resources to compliance and forgot to increase resources as workload increased, causing them to be increasingly behind on compliance work), but I've never seen a company that just decided to pretend to be compliant knowing that they were not.
In my experience this is not representative of most fintechs. Of course there are both cases of real intentional noncompliance, and accidental, but by and large it seems like everyone’s trying to innovate within the law.
This makes sense because these companies want to become large companies and contract with large companies. Large companies, by and large, try to follow the law (while trying to bend it to the limit) because they're aware they have a big target on their back and no CEO wants to be on the front page of the papers for tanking a company in such a stupid fashion.
Even if that's the case, I feel like accurately knowing which regulations you're in compliance with and not is would be kind of important from a risk management perspective. From a "maximize profits" perspective (which I'm not saying is good but what you're saying you thought they operated with), you'd want to know the potential gain from ignoring a given regulation and the likelihood of getting caught (along with the cost of the punishment if that's happens). This is the kind of math that I'd expect a finance company to be pretty familiar with, and giving that up for a fuzzy "idk if we're in compliance or not" check seems like a pretty huge liability (unless there's confidence in not being liable for blindly trusting the LLM, which I hope is not the future we're headed for but I guess I can never be totally confident in us not somehow ending up with rules that defy common sense).
Companies that are growing tend towards faking compliance. Many financial rules like pci only kick in at certain scales. So a company growing very quickly will often be behind the curve but will do everything to seem like they are compliant. Then they would hire people like me to come in and make them actually compliant. More often than not, making an effort at improvement was enough to keep the ball rolling.
I think it's the same throughout startup software to be honest. It's just easier to point out when there's clear rules.
Security, GDPR, backups, build pipelines, disaster recovery, most of it will be faked, half-heartedly done once or ignored entirely.
Then there's the more abstract things like scalability, idempotency when integrating with external APIs, error recovery, accessibility, UX, etc.
Almost always that sort of stuff will have been entirely ignored, or there will be a fig leaf over a real mess of misunderstood standards or manual intervention steps.
Startup developers usually have to be generalists as they often wear many hats, so things that need deeper domain knowledge get done to a bare minimum.
Where did you get this impression from?
A worldview built on reading comments from news aggregators.
IMHO even if we are using auditing tools I believe we must use deterministic tools for critical analysis like this. Such rule and pattern based systems may not scale beyond certain point but they can be accurate.
The dynamic of agent codes human reviews does seem like the only sane one for the foreseeable future. Even Anthropic themselves still fall back to this.
The problem is that sucks, even if all software engineers keep their jobs and salaries, the floor is still pulled out from under us. Imagine if a surgeons job was to supervise robot surgeons from a remote computer, or a woodworker just signs off on work before the machines do all the cutting and assembly. Sure they still have important jobs in their field but the soul & humanity of their skill is gone.
"Soul and humanity" is doing a lot of work here.
Does the woodworker who shape using a handsaw use less "soul" than the one who uses a machine?
Does the musician who use a DAW and VSTs instead of analogue tape recorders create music with less "soul"?
Does the painter who buys acryllic paint instead of synthesizing their own dye from plants use less "soul"?
As technological innovation progresses, the barrier to creation falls. The process of creating something is not to be conflated with the final piece of art itself.
Does the carpenter who used to build custom fit cabinets with hand and power tools put in the same creativity when he just carries around a scanner, scans the area, the customers use software to select the layout, approve the work, then the CNC cuts out the wood, then all that's left is to put the screws in the holes and go home.
This isn't like the step from hand saws to power saws, and it's disingenuous to pretend like it is. This is what the startup machine has been doing to every industry... finding... "inefficiencies" and "optimizing" them.
Not _my_ opinion, but I just wanted to share that many people (in the Midwest) do believe that anything synthetic that it not readily made from simple materials has "less soul". It's a sorta test of "if I dropped you off in the jungle, can you still produce works of soul? Or are you just another cog in the machine.".
Your analogies are flawed. DAWs and skill saws generate nothing. They take skill to operate, and a novice cannot use these tools at all unless they know the craft.
Compare to this to prompting an LLM: “Generate a third person where game with a view from above where you can steal cars, shoot at people, run from the police, etc.” Anybody with access to the tool can do this, and the results are just another uninspiring GTA clone that you would imagine.
The latter is more like a carpenter ordering their “work” from alibaba then it is like using a skill saw.
Except it's not just a tool.
It's when a woodworker, musician or painter completely outsources their work and just marks what's wrong, sending those parts back. Yes, the final art piece might be the same, but the artist definitely uses less of their "soul".
I never found there to be much soul and humanity in the job to begin with. Coding personal projects has soul, but for me at least the demands of high-velocity sprint-based software development to match business needs removed most of the soul and humanity long before AI got good at coding. And I mean, I totally understand why it has to be like that. In most businesses, you do better by shipping decent software fast than by shipping great software slowly. I don't have a problem with that in principle. But it does mean that for me, the software development side of things has never had much soul and humanity to begin with. It was just being a glorified assembly line worker, with the sprints being the assembly line. Of course, others may have had very different experiences, but that has been mine.
For me, AIs have actually made the job more soulful, not less. For one thing, it lets me use the part of my mind that is good at human language, not just the part of my mind that is good at software. This makes the job feel a bit less one-dimensional in terms of what parts of me are engaged while doing it. For another, I find it liberating to no longer have to think much about boilerplate code or to spend time roaming around the Internet looking up documentation of various language syntax and API details, the vast majority of which are arbitrary rather than being based on any kind of mathematical beauty. For me it makes the job more soulful that I can think of the job on a higher level instead of having to spend effort on arbitrary and tedious details.
Of course there is still the question of "will the job even exist in a few years, at least for more than a relatively small number of people?". But that's a separate question. For now at least, I am finding that for me AIs have brought a lot more soul and humanity to the job than it ever had before.
That's an interesting perspective. It's hard for me to relate to it because I haven't worked in a job where I just have to ship code 'for work' in so long. Being a more or less one-man software company, all my work projects, but especially our products, feel like personal projects.
However, if I were just having to do things for the man, I might have a rather different take on all this.
Yup, I can definitely imagine that it's different if you're working directly for customers and have the freedom to do things however you want to do them as long as you still make a living.
I think there is a big difference between a surgeon, who is performing a specific task with a clear outcome, to a woodworker, who might produce a unique piece of art or a functional chair. I think the surgeon-type tasks will be replaced eventually. More interesting are the woodworker types, which has some similarities to SWEs.
When industrialization hit, we definitely lost a ton of craftsmanship and craftsman, but a standard Ikea chair is less likely to wobble than the average chair at a much better price (for a random example). Yes, we traded artistry for convenience, but what we really did was bifurcate our needs between "some place stable to sit" from "a beautiful chair for my home". Most people wanted the former more than the latter, and the same applies to software.
If we split the roles into buckets, many woodworkers disappeared, some became artisans, some became designers for industrially-produced products, and some catered to Luddites for a long transitional period. Despite Anthropic's claims, SWEs won't disappear in a year but over a generation or two, no matter how good LLMs become.
Obviously software is much more complicated and integrated into other elements of business, which in a way makes it more vulnerable to AI taking over and in another way will be at the mercy of larger shifts to how businesses organize human roles and responsibilities. What we call "taste" comes down to "intent" - what the hell does a company do? What should it be doing and how should it operate? These will be the only questions that matter and the one thing LLMs can't replace since they will always choose the most default path. So I think human's roles will be to inject intent/taste at different levels of abstraction throughout an organization.
After a couple of years of this their expertise will be gone too and then nobody is qualified to supervise the clankers.
3 years max. Maybe 5 if you are lucky.The models will continue to improve. The exponential gains in compute efficiency that have been ongoing for 70+ years will continue and that will result in even smarter models. There are dramatic hardware changes in the pipeline.
But really that particular issue could have been solved by literally just telling it in a markdown file or instructions something like "verify all facts or compliance requirements with web search and include citations in responses".
This is akin to “don’t make mistakes”
“Verify all facts and compliance requirements” leaves enormous holes even if you assume the LLM has a concept of facts and requirements (it does not).
What facts? What requirements? For what industry? For what subset of that industry? For what country or countries that you will be doing business in? Are these current “facts” and “requirements” or is the LLM referencing a dusty article from 1992 for which the subject matter has been radically overhauled?
In my job I regularly see small but incredibly important mistakes like this lead to major issues. Some of those are human driven but increasingly the defense of the person responsible has turned into “Claude said it was fine though!”
It can make mistakes and will sometimes, but what he specifically mentioned was a case where it did not pull up a reference that it needed. So using a web search tool effectively would make a big difference.
It still does not rise the standard he requires which your response indicated would be easy for the model to achieve with a simple prompt.
Additionally, using a specific tool does not suddenly give the model common sense enough to say “this piece of information doesn’t answer the question of whether this solution fits in this specific industry at this time in this place”.
A web search tool to pull up the law that is relevant?
Stuff like that is risk tolerance... its not strictly codified and its more akin to probability. Different companies at different stages, in different industries will all interpret their risk differently... how will a smarter model improve that?
Ah yes, the magical equivalent of "you are a senior software engineer who writes bug-free code".
IME people would benefit greatly from the process, albeit tedious and time-consuming, of testing out the same prompt sequence/session with the exact same model multiple times. It becomes clear extremely quickly how capable but unreliable and inconsistent a model can be even when given the same context. If you have ever completed a long, complicated task with an agent and then lost the session and tried doing the same thing again from scratch you may have had the experience of seeing the subtle changes that come up in the model's thinking which lead it to accept or reject certain paths and ignore or incorporate prompt instructions like the one you've provided.
The classic 3-5 year window for a new technology that is uncertain and requires just a few more breakthroughs to get there...
Like full self driving!
I've worked on projects in the airline and health industry which are highly regulated too. The regulations can be incredibly difficult to process and implement, and make sure you adhere to everything correctly. I've been involved in multiple scenarios where people have made false assertions about compliance or lack of. I'd still place a bet that the SOA models make _far_ less mistakes than humans.
They might make fewer mistakes, but they aren't evenly distributed. They don't use logic when making mistakes, it is gaps in the training data and now large of a span they have to bridge in the latent space. Just as they aren't smart like humans, they aren't stupid like humans. Don't mistake rate for quality.
Yeah, this starts to overlap with some autonomous vehicle stuff, where I like to say that the rate of errors is not the shape or distribution of errors.
We have long historical experience and innate tools for detecting and mitigating errors made by humans. If we can't apply those to automation, then even fewer total mistakes may end up being a worse outcome.
For some reason, tons of people seem to be in camps at both extremes. It's either "AI sucks don't trust it!" or "AI is so much better than humans!"
But the most reasonable take, which I'm happy to see reflected in so many comments in this thread, is… use both.
Do an AI pass, and have humans verify, and vice versa. Let the humans drive the AI. Then the unique shortcomings of each party can be covered by the other's strengths.
AI review is never going to beat a fully resourced human review.
It might beat an underresourced human review, on time, efficiency, cost metrics. But on the metric of accuracy, throwing unlimited humans at a problem will still beat throwing unlimited AI at it
That's an irrelevant comparison because cost is always a constraint, so there are not going to be unlimited AI or humans. The question is how to optimally combine them for a given cost.
> Do an AI pass, and have humans verify, and vice versa. Let the humans drive the AI.
You can do that, sure. But doing so negates any improvements in speed the LLM brought. And at that point, you may as well just do it yourself to begin with.
When Google showed up on the scene I found I no longer needed to memorize basic syntax and other such things. If I couldn't remember on the fly, i'd just do a quick google search and move on. This freed space in my mind to instead focus on bigger & better things.
I use GenAI tools when coding a lot, but I do not vibe code. I go through everything it generated, and we iterate. And yes, it doesn't save me a lot of time. But what it does do is free up mental capacity in a similar manner. But instead of syntax, it's more complicated patterns. Maybe I don't remember how to stitch something together, but i know it can be done. Instead of spending the time to look it up and then code it, I just tell it to do it for me.
Yeah, humans reviewing the AI review can only detect the false positives, where the LLM claims something is non-compliant and flags it for review/correction by a human or another agent. Human review can’t find the false negatives (true deficiencies not flagged) unless you do a full audit yourself to find whatever deficiencies the AI missed.
I feel like you're missing the point that it's more thorough to use both. Speed isn't the only factor that matters.
This makes sense, but a logical next step is to have one AI write code, and then have another AI, instead of humans, verify it.
Or are current AIs too similar for that to be fruitful?
This is commonly known as "LLM-as-a-judge" and anecdotally multiple people I know who write code using OpenRouter or using multiple models say it's surprisingly effective. It's strange that there don't appear to be any major papers on it since ~early 2025, which at this point is basically ancient history.
not according. to my experience.
regulation questions. even the simple ones, AI gets all the time wrong. it wasn't Mythos, but other models like opus.
I can adjust the view on this topic if/when we get access to mythos.
>I'd still place a bet that the SOA models make _far_ less mistakes than humans.
Genuine question: your top coder seems to be producing the most error-free code from your perspective, has the deepest knowledge of the architecture and codebase, and is faster on the trigger than the others.
But your top coder has proven and verifiable dementia, where they will confidently assume the existence of apis and code that do not exist, mix up the purpose of others and forget other things, and you can't predict when and how they will introduce errors into the system or the severity of such errors.
Are you really comfortable letting this person with dementia generate most of your codebase in the airline and health industry?
I also hope you have an iron-clad agreement that prevents the model provider from doing silent updates because all your evidence of correctness you collected thus far goes out the window in that case.
Another genuine question:
You have witnessed a human coder and the AI you're using make the same important mistake. Assuming you do not have the time and resources to retrain, fine tume, and test your frontier model:
Who would you trust not to make the same mistake multiple times in the future after you have warned them that their job depends on it, the AI or the human?
Your top coder has guard rails in place to prevent him autonomously going free - right? This is how you should approach agentic development with LLMs. Like it or not, we are the final bastion, the gatekeepers. The hallucination thing I think is mostly overblown and from speaking to colleagues it seems to vary wildly depending on which model and harness you are using - always go for SOA. In the last 3 months I can count on one hand where it's done something wrong and that's primarily as I'm operating it with guard rails and giving it context.
>Your top coder has guard rails in place to prevent him autonomously going free - right?
The parent is implying they would prefer an AI when working in the airline and health industry because it makes less errors. Read the comment again.
They have not said, "Hey, I work in the airline and health industry and I'd love to use AI for a couple of the bullshit IT UIs we have as long as we can put guardrails on the AI to stay in its lane."
I asked a yes or no question. The guardrails you can put to mitigate errors are the same guardrails pre-AI for the humans (tests, regressions, reviews). If you were wary of employing a top lead engineer with verifiable dementia prior to AI for a mission critical system, logic implies you should think twice giving that much responsibility to an AI as well.
> The hallucination thing I think is mostly overblown
Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.
>from speaking to colleagues it seems to vary wildly depending on which model and harness you are using
You have partially answered my question it would seem.
> Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.
No, but the same can be said for your colleagues. You might call what the LLM does hallucinations, I'd call them mistakes. I think we have totally forgotten that humans make them all the time and are confidently wrong too.
Your original question, doesn't really get to the bottom of the point I'm trying to make, and I don't really feel it fairly represents the issue we are talking about here. They are not the same things.
This is such a tired, meaningless argument. I've never seen a human in 10 years of professional software engineering at a large company ever so confidently, consistently create and send out seemingly well-reasoned code that's as wrong as what SOTA models using CC or Codex do. If a human did this, they would be fired or perpetually remain a junior who no one wants to work with.
Also, if a human does this, you can replace them and get a human who will not do it. The default for an LLM is to generate plausible-looking text that may or may not be completely incoherent. That is not the default for a human. Again, if you find that your colleague consistently fabricates APIs, you can hire someone who isn't crazy instead, but you cannot do the same with LLMs.
>No, but the same can be said for your colleagues.
That's absolutely false. My collegues don't routinely and confidently invent apis that are not there, or spectacularly and repeatedly misunderstand the purpose of certain functions or exhibit extreme forgetfullness. Especially when I've warned them. Hallucinations and confabulations in otherwise healthy individuals are mental disorders. When I ask them why they made an certain kind of error, I can expect to get a reasonable answer. No one has uttered the phrase "Bob hallucinated again while writing those tests" when the Bob in question is a human.
Well, your experience doesn't align with mine. I have been using, and in part of an organisation that is extensively using, Claude with Opus for everything for about 3 months now and I am not experiencing the problems you describe. We'll have to agree to disagree here.
That is fine. "Your experience may vary" is the crux of my argument amusingly. You can't have just realized that people are having different experiences using AI, or even that the same person has different experiences when they change domains or technical contexts. There's been lots of comments littered on this forum to that effect.
Calling hallucinations simply mistakes does not seem to me to be a healthy way to reason about LLMs. I can ask a collegue how well they can program in Ada and adjust my expectations on productivity and bug rates. I can't ask an LLM how well they can code in Ada (just a throwaway example), or even how much of Ada was in its training data. I have to actually spend money and spend time code reviewing before I can even formulate any expectations at all.
> I'd still place a bet that the SOA models make _far_ less mistakes than humans.
Well too bad, the problem is that they also produce things much faster than humans so errors will compound quicker.
This stupid argument again. The number of mistakes _does not matter_. Get. This. In. Your. Head. The predictability of the _type_ of error is what matters. For LLMs and machine learning in general the error distribution is not what you would expect and it is not possible to predict either.
In some sense, you should still act on this, since if an external auditor relies on the same stack, it'll still cause you headaches.
The models can change at any time and behave differently.
I use Opus 4.8 and GPT 5.5 and haven't suffered from hallucinations in months. But we also put a lot of effort into our harness.
Opus 4.8 and gpt constantly hallucinate stuff as well. If you haven’t encountered or caught it that’s something different. Of course these days it’s mostly confidently asserting a wrong thing.
Sometimes the harness can only be a human.
And this is fine. Developing new software with a really smart intern is the same, you, as an expert, need to bring your experience/expertise on the table to have everything right. Because experience needs time.
> it had of course hallucinated what the regulation actually required
Did it do the correct job once you put the regulations doc(s) in the context?
What I usually do when in doubt is challenge the AI. “Please quote the section of regulation the product is non compliant with”. It usually admits it hallucinated the whole thing.
It sometimes says that even if it hasn't though, so like everything with LLMs, you can't actually rely on that.
100%. Unfortunately those not in the depths of mission critical systems or regulated products will continue to believe that producing tons of code quickly using LLMs without humans in these systems is acceptable.
Here's an example of what we will continue to see with folks fully immersed in gen AI psychosis:
"The creator of claude code said that he no longer writes code for about 6 months and now has Claude doing all his work now. He also said recently that he no longer prompts Claude and now has it running in loops and it is self-improving itself and performing better than a human!"
If the code produced by the LLM is perfect, the LLM takes the credit. But when a disaster happens, you cannot blame the LLM and it then falls on the human who did it.
I don't think SWEs heavily vibe-coding with LLMs realize the risk in not understanding what the code the LLM being produced is doing even after generating tests (lol). We will see more of this too. [0]
[0] https://sketch.dev/blog/our-first-outage-from-llm-written-co...
Why is it such a dramatic statement for Boris to claim that he no longer writes code?
Are people on HN still typing out functions by hand one character at a time?
It would be like a developer in 2020 claiming that he only writes assembly because compilers can’t be trusted. No one is taking that person seriously. If you chose a career in tech you made a decision to work in one of the fastest moving fields in human history. Now it’s time to get over it, learn the new tools and adapt.
>Are people on HN still typing out functions by hand one character at a time?
Well I use tab completion, of course. And I copy-paste snippets from LLM more often than from SO now. But otherwise not much has changed in my career in the last 5 years. Is this different for you?
I'm not fundamentally opposed to code generation, and I use LLMs for some taks, but I don't see myself vibecoding whole pages of production code. I vibecoded a throwaway note-taking app for myself though.
> Now it’s time to get over it, learn the new tools and adapt.
If the AI is producing what you tell it to, why are you needed?
> Now it’s time to get over it, learn the new tools and adapt.
No, thank you. I have used the new tools, determined that they aren't helpful to me, and set them aside as I would with any other bad tool. I don't feel the need to let hype take the steering wheel.
> Now it’s time to get over it, learn the new tools and adapt.
Exactly. You are free to use openclaw or a coding agent to build a competing bank, hedge-fund, hospital or even a new airliner because the previous ones were built by humans. Surely an AI can do it better by itself.
So why haven't you done it yet?
> Are people on HN still typing out functions by hand one character at a time?
Yes, me. Yes, I tried LLMs for what I am doing and will try again in few months. No, there was no noticeable or clear improvement over doing it manually.
Yes, I am using some LLMs for some purposes but Claude Code had slight improvement, if any, not worth introducing proprietary dependency.
It is because HN is contrarian and behind the times.
I work at a big tech company and I don't know a single person that still hand writes code. Most people haven't hand written code for at least half a year now.
I do wonder what sort of bug is making its rounds on HN that people here find this so shocking and unbelievable.
C'mon, the LLM/compiler false analogy? In 2026?
> Why is it such a dramatic statement for Boris to claim that he no longer writes code?
Because we can actually see the disjointed slop that Anthropic produces. And when issues happen, they can't fix them for weeks on end because no one understands what code does anymore, and all of their "hard problems causing issues" they blog about are literally "if we had actual engineers this wouldn't even be an issue to begin with". Like this bullshit they had in spring: https://www.anthropic.com/engineering/april-23-postmortem
> It would be like a developer in 2020 claiming that he only writes assembly because compilers can’t be trusted.
LLMs are not compilers. For a few very obvious reasons I'll leave as an exercise to figure out
False-positive rate is so high with Mythos according to friends and other reporting I have seen.
The original Mythos release used ASan to filter false-positives so it was able to maintain a good FPR, but when Mythos moves into domains that don't have a readily available oracle to help filter hits, the result is a deluge of false bullshit.
Have you added "Make no mistakes" to the proompt? Mythos can't go wrong then, must be a skill issue.
its shocking people don't realize you're being ironic
AI cannot fail, it can only be failed
My current favorite in that area ( because I saw it in the wild ) is:
"Make it better" with no additional or reasonable previous explanation of what better might mean.
"AI will figure it out" not for pattern extraction, but for a full blown analysis with equally generic prompt all confidently stated by an executive telling people working it how it works
If you talk to it like a programmer talks to a computer, it works a lot better.
So the question remains if non-programmers will adapt, the LLMs will accept wider range of input styles, or .. its just another abstraction layer for devs to use.
I've observed this in the wild where someone is iterating with an LLM and giving it only negative feedback. For example responding to edits with "don't make it blue" rather than "keep the existing button shape, and change the color back to green".
The LLM doesn't really come back the way a human would and say "so what color do you want?".. it just, guesses. Now abstract that to more complex tasks.
I realize they’re being ironic, it’s just a poor contribution to an otherwise productive conversation.
what am i missing?
you take a spec and create tests, every little thing
you use another ai to verify these tests against the spec
you review the tests vs the spec (at one point human review)
you put the tests off limits to change / wall them.
you let the ai write the software that fulfills the tests.
there will be some gaps where you repeat the cycle above
if the tests fulfill the spec, the code will fulfill the spec
>you take a spec and create tests, every little thing
A spec detailed enough and unambiguous enough to be translated into machine execution deterministically is called code.
Unlike a compiler, AI can build with a spec that is not detailed enough or unambiguous enough: It does so by filling in the gaps with educated guesses.
This is safe if and only if you take the time to later read the output, understand what its guesses were, and judge wether they were acceptable. No AI can do this for you because the truth lies in your original intentions, which it does not have access to.
The jury is out there on how reliable and time consuming this is vs writing the code yourself; it is not immediately obvious that is faster or requires a smaller cognitive load.
Code is not a spec. It's an instruction set. It can be a spec if you try hard but that's not an inherent property of code. For example you can write code to be a compiler..that makes it a spec. But hello world is not a spec.
As for whether or not LLMs can write unit tests. The answer is yes.
Hello world is a spec. The spec says to produce the text hello world on standard output.
Try running it without a compatible ABI. See how far you get.
Not sure what the point is. We can update the spec with "in the presence of a compatible ABI".
All I'm saying is a program isn't VHS. It's a VHS tape. At that point it's largely philosophy. Can you reconstruct a VHS format from a VHS tape? Sure.
If each step requires micro-steps iterating with an LLM with human review to prevent hallucinations creeping in.. at some point you might just be better off letting the human do the work.
Particularly as tokenmaxxing has ended and people are being charged more economic prices. If the pricing 5-10x the way Uber,etc did on the path to profitability.. even more so.
IME, regulatory compliance is something you are rarely able to test for in a nice little box or with well-known suite. So there's no easy "this complies" in many situations, no matter how many lawyers, compliance officers, and llm's you run it past.
so, whats the difference to human engineering?
other than there are "internal micro feedback loops" during development?
I walked down that path for a few months. The more you constrain LLM's, the more underhanded they behave in order to produce something that satisfies all the constraints.
Doing the above doesn't actually make the model smarter, so, if it couldn't get to correct code with fewer steps, then the light you see at the end of the tunnel is an oncoming train.
This is such an abstract principle that the principle itself cannot be refuted. The plan sounds fine on paper. "Just iterate bro". But it entirely depends on what rational agents you put into the system. Obviously, if I sub in a 5 year old child everywhere, this loop breaks. Humans and AI, sometimes one is better than the other at certain things, we're still learning.
The only way to test this is to test it out, in real life. Sometimes people see results, sometimes people don't. Note that yes, I am including the entire iteration process - even after iterating, people still don't see results with AI.
I have had both positive and negative experiences with AI, over multi-week projects. But apparently on hackernews, anything positive about AI is proof that AI is superhuman and taking over, and all follies about AI are lies by stupid humans who secretly have psychological dispositions to fear AI. Sometimes the AI genuinely isn't good enough. Are we not allowed to say that now? We might not know why, but it's just the truth.
The other solution is to formally analyze the entire space of possible actions the agent can take a priori. Then yes, you can definitively say whether or not the principle breaks or not. Can you, though? Can you give a formal specification for the space of possible actions for AI and show that your loop never breaks, or breaks less than humans, or any other sensible criteria? If not, then you can't just give an abstract principle and start making inferences from that.
It’s impossible to write a spec that’s not ambiguous , complete and correct in natural languages. Thus prompts will always generate unreliable software.
Is that all that Mythos did?
Did it find any real potential issue, optimization/simplification opportunities, or sparked any thought-provoking discussion within your organization?
Or was it purely a net negative experience?
Read their comment. It's a negative anecdote surrounded by them using genAI all the time.
You're the only one coming away thinking there was a net negative experience.
In regulated industries none of those matter if the tool invents compliance issues or breaks compliance.
The only thought-ptovoking discussion should be "why the hell do we have this stochastic parrot anywhere near out codebase"
I think that what technical people fail to understand is that a lot of the time, "compliance" is not the same as a binary compiles/does not compile. For a lot of rules/regulations, compliance means "making enough effort that legal is willing to back you up".
A system which will just randomly decide to give the legal team reasons to not back you up is:
* A system whose output will get brought up in lawsuits and make legal's job harder.
* A system that will make the dev team perpetually chase its tail while it oscillates between the several different valid interpretations of the rules.
Odd take. So if it identified 17 real gaps and helped fix them, the fact it was wrong about one gap, and the appropriate humans caught it and no harm was done, the whole thing is useless?
Not saying that is the situation, I don’t know. But if “one error is too many” is your point of view… do you think the humans in these orgs are 100% perfect 100% of the time?
> So if it identified 17 real gaps and helped fix them, the fact it was wrong about one gap, and the appropriate humans caught it and no harm was done
How many gaps have humans not caught?
> But if “one error is too many” is your point of view
Yes, in regulated industries "one error is too many" is the only right approach.
Yes, humans also make errors, and there you have a range of options: from tracing and finding the causes of the error (and tightening processes) to literally jailing those responsible. Your hallucination machine will happily "identify" 17 gaps, and create 34 more. And no, there are no processes to make it better. The "make no mistakes" incantation will happily be ignored for obvious reasons, regardless of how many forms of it you throw at it.
Isn't that a net positive though? (not sure about the cost human and tech cost). I'm guessing that without using Mythos, those conversations would never have been had, and confidence in the compliance of the product would've been lower.
I love using AI tools as casinos. It's epic in helping to forge ideas and kickstart thought processes. You basically have the entirety of world knowledge at your fingertips to have a pint with.
your parent:
> the code in question had already been reviewed by human counsel
They cant read all comments they comment on...
> I'm guessing that without using Mythos, those conversations would never have been had, and confidence in the compliance of the product would've been lower.
The conversations had already been had and the product made compliant. Mythos just pulled new rules out of its ass and of course the product wasn't compliant with those. So they do a fire drill and find that to be the case at great expense.
Yeah you can frame it as "more checking is always better" if you wanted but that's just the same old "other people's resources are valueless" slight of hand we see on everything. It probably was mostly wasteful work.
There's a chapter in Simple Sabotage about how to undermine a white collar organization from the inside. One of the key tactics is to hold meetings that revisit decided upon points, and to invent unnecessary process / checking.
So, in this case, the LLM's behavior was equivalent to the behavior of the resistance during WWII.
I think that book should be required reading for all engineering students.
> It's the expertise of engineers on the team that push it back on track.
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.
The corporations and executives are already winning if you swallowed the concept of 'rockstar' engineer. Sure there are more and less experienced engineers, but even interns can and often do provide good input and spot mistakes made by seniors. The 'rockstar' engineer at most tech companies simply equates to the somewhat autistic guy with a brown nose who's working 15 hour days for a pat on the head from management (and making many mistakes in the process).
For the most part there aren’t 10x engineers
But there are certainly 0.1x engineers
The study that defined the 10x engineer defined him as 10x as good as the worst engineer. If there is a 0.1x engineer, and a 1x engineer, that 1x engineer is the very definition of a 10x engineer.
I've long thought a 10x engineer is one with just the right amount of analysis paralysis - not too much or too little. It's not that they're 10x engineers, it's that everyone else is 0.1x due to a confluence of reasons. And the ones we call 0.1x are 0.01x.
There certainly are 10x engineers just that they get most of the x from turning down bad ideas and saving work.
and -10x
Even if we forget "rockstar", there are certainly different levels of engineers. More experience doesn't automatically mean better either. That is not to say experience doesn't matter. It matters quite a bit. Sure , good interns can sometimes have good feedback or spot mistakes. But not consistently enough.
All of this to say that it's not just experience that makes one a better engineer.
Experience is one of the only objective signals we have, but you're right it's not the only one. I've seen plenty great junior engineers and interns, and plenty of incompetent staff/principal engineers.
> because nobody needs mediocre engineers anymore.
This is giving too much credit to LLM. I think LLMs are great and it is incredibly useful both in personal and professional settings. However, it exist on a separate plane than human workers in the tools category.
Sooner or later, people will find out that LLMs only overlaps with existing human hierarchy (e.g. junior dev X%, senior dev Y%, etc), but almost never 100%. If it was 100% to a certain position, you are probably using the humans wrong to begin with there - since humans have one of the most priced thing that I don't see an single ounce out of LLMs: initiative
It's hard to show initiative without a pulse. Most agents don't have that (yet). But can't be too hard to build.
Exactly. Same with tractors. Once they arrived, nobody benefited except Big Tractor.
Famously a net loss for humanity.
At the very least _big_ tractor (John Deere) is a net drain on society
> With LLMs, only the "best" engineers will survive, because nobody needs mediocre engineers anymore.
LLMs are going to show that there's a huge divide in "engineers" between people who love "coding" and people who like "engineering".
The group of people kicking and screaming the most are the people who love code and don't want to see their coding go away.
These are typically the build vs buy folks. "We can't use anything anyone else wrote, I can do it better..."
What do you think Staff level engineers do? They don't sit around coding all day.
Writing the code is just something you had to do in the past to get the job done.
What you get paid to do is "engineer" and the two are separate. Coding is very small part of the average engineer's job.
And yet the vast majority of engineers think that the world is going to end if they aren't spending most of their time "coding".
Very well said and if you look at some of the other threads on hacker news about why people don’t like AI it specifically because they like typing and coding
The majority of my time is an engineering manager has been teaching “engineers” how to actually do engineering with any kind of rigor
The number of engineers who have an absolutely no theoretical structural or system basis for what they’re doing is the vast vast majority
> With LLMs, only the "best" engineers will survive, because nobody needs mediocre engineers anymore.
I don't think this is true.
A good engineer doesn't have infinite throughput. In my opinion the best engineers should be constantly bottlenecked because they solve difficult problems. They don't have time for grunt work. Every company needs less than perfect engineers, AI assisted or not.
Well almost 70% of the developers in the industry can't write a fizz buzz.
But, besides coding skills (which some possess), the engineering, social, and business ones are close to non existent.
Did you pull this 70% out of your ass or from some other place? It's quite obviously not reality.
https://blog.codinghorror.com/why-cant-programmers-program/
There was also another study I cannot find where 56% of engineering graduates struggled to write a fizz buzz.
I think people highly underestimate how long is the average developer, closed in their bubbles of mostly well established software teams that forget that for each of them there's 10 software consultants in southern Europe glueing APIs with trial and error on Java 8 monstrosities.
> Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product.
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?
Sorry if I was unclear. I don't work in finance. I do work with agents. I think expert engineers in finance who are guiding agents are adding a lot of value because of their knowledge of finance. Because I lack that knowledge of finance, even given access to agents, I would not accept a role guiding agents in a finance company because I wouldn't be able to guide the agents well and my/our output would be bad.
Unfortunately every software related industry is embracing LLM/Codegen. Your banks, fintechs, insurance. Everyone. Your concerns are the same I'm having, yet it's regularly dismissed or hand-waved away as "don't worry about it the delivery velocity/ROI is worth it"
It's not so much about velocity or quality, both of which LLM do (or will) provide.
The real question is about accountability and liability.
When a major data leak is going to happen, who will they sue or fire ? That is the value engineers provide. They understand, confirm, and take ownership.
This is what I'm wondering too. We've signed a confidentiality agreement with all the big players (as I'm sure all other companies have done), which is supposed to ensure our data is both segregated and not used for training. I don't trust these companies not to do just that; their business is in taking what we have and training their models.
Yeah, I always wonder if they do some type of obfuscation and transformation on the private data and find a way to backdoor the info without technically using it directly.
This question has been easily answered by many companies.
You, the IC, the developer prompting the code extruder, are ultimately responsible for its outputted code and its behaviour.
You may feel pressured to push out thousands of lines of code a day. You may see those thousands of lines refactored several times over the lifespan of a merge request. You may be asked to do this continue this in the long term with all the mental fatigue that entails.
When it's too much for you to sustainably deal with and you turn to using LLMs to review the code, that will still, presumably, fall on you at the end of the day.
The output is your responsibility.
Ostensibly, due-diligence should not change. But people are lazy, just as they've always been around testing/QA/definition-of-done.
I'm not even certain that laziness gets them further along than it used to; I think it's that people have not had their overconfidence painfully corrected yet. Behaviors will re-align pretty fast when people realize that no, they're not going to get away with just pressing a button and saying everything is "good". That is happening right now.
Don't worry, we can throw in all in 55 gallon drums and dump it over a cliff when the time comes.
> When a major data leak is going to happen, who will they sue or fire ? That is the value engineers provide. They understand, confirm, and take ownership.
This goes for serious incidents, disasters, outages and security breaches.
If there was an investigation and the answer was "a piece of software was vibe coded with AI" why would anyone trust the software vendor after that?
When has any company ever faced consequences from atrociously bad code leaking data or negatively impacting their customers?
Even Solarwinds is still alive.
EU companies are judged guilty of negligence because backups were not totally disconnected (even though distant site) and ransomware did destroy them.
So that is starting to dig deeper than a plain mistake. I guess we will soon-ish witness the first AI slop trial going on, this will be interesting to follow
Knight Capital
Just having this discussion with someone about AI in healthcare and how issues are going to be handled.
If a nurse does something incorrectly, they can lose their license. Ensuring that nurse will never be a nurse again. There is a very clear path of accountability and very clear ways to mitigate it.
For instance, if a nurse is drunk and you recognize there is a pattern of people showing up drunk, you institute drug tests and breathalyzers and move on.
While we probably won't have LLM's autonomously performing procedures, they are 100% parsing documentation, reading lab results, making suggestions, etc. And right now, the burden has been placed squarely on the clinicians themselves. It'll feed them them the data, ask if they approve/agree, and then essentially wash their hands of accountability. Let's say an LLM starts incorrectly reading lab results, how is that fixed/remedied? A prompt update? Additional safeguards? Adjusting the temperature? Changing a model?
This is a far different type of engineering that still feels pretty new. Granted, I'm still an amateur in this space (I use Claude Code a decent bit), but it feels really opaque to me right.
Are banks that concerned about velocity? Because moving fast and breaking things in the banking sector can get extremely expensive. It's also not a who-gives-a-shit industry like operating a taxi service or hosting images, but a very tightly regulated sector.
I might have been a bit broad with the brush. I can't speak for banks, but I can speak for the the fintech/money-movement space (e.g. Remitly, Wise, Revolut).
It's a race to get first-to-market for backend integrations/features. It's given rise to a culture of "move fast break things" where safety is only for some core features, but absolutely not for the constellation of other services we provide. Failure rates have increased almost a percentage point since Codegen/LLM adoption was mandated from up top.
You would think regulators would be on top of this, but our industry runs on all actors "self reporting" their outages. Most don't unless they can't hide it (>1h)
'Keeping up with regulations' may as well be a separate field from the core stuff. It has the same pressures as any other development effort. Managers will want the integration to the KYC service LLM'd as quickly as possible.
> Are banks that concerned about velocity?
Yes
Not in the universe where I live. Having worked in a variety of web tech, and then working at a fintech with a partner bank, traditional banks move incredibly slow compared to nearly every other tech company out there, and for good reason.
Norwegians have a saying: “Den som er ferdig utlært, er ikke utlært – men ferdig.” Meaning if you are finished with learning the one that is finished is you. Typical scandinavic hard cold truth…
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.
Reg PRs - for the ones with complex requirements what I am seeing is that time to initial PR is very short, and a ping-pong between the reviewer and developer begins, because in my cases (not all) the developer vibe-coded parts, and they didn't really understand the requirements deeply or their code, and it takes multiple iterations for them to fix it. You can argue this is a human problem but this is the net effect I'm seeing.
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.
> That first pillar is still there. Maybe the author isn't aware of the impact they have, but I know, with the evidence of reverted PRs, that when I step outside my area of deep knowledge I can no longer call BS on the agents. Our most capable agent, with access to the same kind of distributed systems the author talks about, is regularly wrong, frequently myopic, and just outright dumb constantly. It's the expertise of engineers on the team that push it back on track.
I'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.
> AI systems will never learn to anticipate the future
Citation needed. I don’t see any reason these systems shouldn’t be able to speculate; indeed some would say that’s all they do, even about the past.
Yeah I'm constantly shocked at how simultaneously smart and dumb Opus can be. It can tell me a LOT about my codebase but it will miss very critical clarifications that I begin with. And when I call it out it obviously remembered it, it just ignored it.
In software dev, for a big finance corp
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 )
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
I agree with this experience. LLMs are great and save me a lot of time, but they need frequent nudges to avoid going down a completely wrong path. I just don't feel like the management dream of "every engineer has 3 agents working for them full time" is quite a reality yet. I'm not saying it won't get there, or that I feel secure being a software engineer until I'm of retirement age, but I also think it's important to understand the limitation of the tools. You do need to know your codebase. You do need to iterate on small chunks of it at a time. You do need to carefully understand every line of code you're putting into production. LLMs are amazing at generating a lot of proposals, but you need to carefully consider each one.
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.)
> I pilot LLMs all day
Love the metaphor. Planes are sophisticated machines capable of auto-piloting, but humans are still needed to ultimately pilot the beast.
What about autonomous drones then? They are not planes?
The real reason we have pilots in commerical jets is that they are a failsafe because a mistake in your automated system can kill 100+ people and guess what? It still does from time to time even with a human piloting the "beast."
It is not impossible to have fully automated planes. We just cannot afford to make any mistakes otherwise people will die so we keep pilots as failsafes.
Nobody will die if your claude code hallucinates.
There is a product called Microsoft Copilot...
a slightly different metaphor. Copilot suggests it is next to you, helping you pilot... something else. The computer? The system? But "piloting the LLM" changes the relationship. The LLM is the thing that is being piloted.
You pilot LLMs all day but that might not last.
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).
a year ago I would have agreed, but the gap is getting smaller all the time... these things can do 90% of the work, and how many people does a company really need for the remaining 10%? certainly not as many as they needed before
The things can do 90% of the work ... but only if used by the right people.
I've seen first hand what less experienced developers produce using the same models, your 90% accuracy suddenly drops to 50%...
With opus 4.8 we're frankly aproaching the 100% of the work, but only if tasked by the right people. A decade ago I worked as an enterprise architect and left it because I preffered coding. Now I'm an enterprise architect again, and we're at the point where I've setup a Microsoft Fabric and integrated a ADLS Gen2 with a Lakehouse building Dimension and Fact tables for our Business Intelligence people with Cowork. A month ago I didn't know what Dimension and Fact tables were in a datawarehouse and now I've not only setup a flow for it I've made it more accurate than what they had before because I understood how BC365 worked and the previous consultants didn't.
We had a PoC in place to get fabric, it had like 500 hours allocated for what I did in a week with cowork, and my product is actually on secure vnet network with Azure identity security with both a test and a production environment delivering actual data.
Cowork even made the damn powerpoint slideshows for decision makers.
The single saving grace right now is that it apparently isn't easy for everyone to do this yet. But I didn't use a whole lot of my knowledge on software engineering to make any of it happen, not even the pandas and arrow code that moves the data behind the scenes. I mainly used my knowledge of NIS2 compliance and general data architecture in a step-by-step process. To me anyone with common sense should be able of doing this, and I really don't think I'm special... but then I teach other people AI at our company and they can barely get it to create a running program. Which is fine for now, but I have to work another 20ish years before I retire, and by then a lot of young people will have grown up with AI, and like I said, I'm not special. I think the only thing that differentes me is that I mash the buttons until it works but also have decades of security and compliance hammered into me.
similar experience here, I don't think I've run into a challenging problem that I've had to solve directly for months
I've been a developer for 25 years
sure but even if it's one talented dev doing work that 2 would have done before... where's that work going to go? I don't think we need twice the amount of software
My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently.
LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is always many things subtly wrong iterating and expanding our domain.
This might be because the companies I worked for happen to be tackling complex domains precisely for moat-building reasons. They stay in business explicitly because there's not a book out there you can read to build a clone, the knowhow stays inside.
Also, a fintech whose managers recommend speeding up design docs with AI sounds way too careless to be in the money handling business. It's way, way too easy to end up with millions incorrectly allocated, particularly if you deal with high volumes of small transactions. These bugs are always a bitch to deal with because correcting the logic is just step one, you then have to correct all the wrongly calculated data in immutable DBs, move around the red tape and client comms, and your fix is bound to become a gotcha that new features and observability have to take into account ("remember that there's a bump in the data in february 2 because we had incident X".)
This. Once you're building something that genuinely hasn't been built before, LLMs cannot be trusted with any architectural decisions. I'm building a product based around various physics simulations, so it's purely first principles, but without active research, thinking, and challenging, it produces computational code literally hundreds of orders of magnitude slower WHILE implementing absurd fallbacks and shortcuts that effectively result in a useless calculation.
This is the case perhaps 95% of the time.
Oversight is very important, and architectural thinking cannot yet be outsourced, only execution.
I have had similar when trying it too. I couldn't even drive Claude Opus 4.7 to get PETsc to compile properly (with all the optional dependencies)
I find that too, Claude Code is constantly trying to break the architecture patterns and do hacky stuff
Like its only focused on solving the local problem as easy as possible
LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
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.
I can't even get Claude or GPT-5 to consistently produce good flows for common use cases, much less domain-specific shit. They have deep vocabulary though, which makes them sound better informed than they are.
They are very good at writing code and debugging visible errors- but that's like 50% the harness.
> LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
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.
https://www.youtube.com/watch?v=6BB6exR8Zd8
> 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
This kind of works but the difficulty is that you have to be very explicit about everything. It was mentioned in a spec document that a particular excel file is treated as a source of truth throughout the whole company and it is treated as an append only database. The agent still decided to add a check to see if a previous row was modified. It pushed back on its decision when asked why it decided to do so. "What if someone entered it wrong and had to correct it"? Valid question but it's not my teams responsibility to check for it
This check makes sense from a traditional development view point and that's why the agent did it. I would say it's good practice too but it's beyond the scope of the project it was working on. If what you are doing is beyond the norm you have to watch out for things like this
Sure but finding their shortcomings and patching them with skills takes real trial and error. They are incapable of identifying their own shortcomings for you.
>> LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations.
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.
I always remember of the infamous Steve Jobs quote "Ideas are cheap". If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".
What I think is often overlooked is the human "Willingness" and "Care" of staying with the thing for the lack of a better term. What I mean by that is that a lot of people just don't care enough, or don't want to, build, maintain, and own things. Sure you can ship V1 faster, but will you remain on the grind?
I think a great example of what probably will happen is found in Suno, the AI Music thing. I don't know if y'all have tried it, but it now produces really good stuff. What's happening there? A lot of people play with their own little universe and get tired quickly, move away from it, and only a few prolific creators stay and turn it into a "job like" environment.
We may have shifted the scale and the economics of "delegation" and "execution" but I think there are still a lot of other factors to consider.
> Suno, the AI Music thing. I don't know if y'all have tried it, but it now produces really good stuff
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.
re: SUNO
i actually was discussing that with a guy i met the other day, an old school producer, did succesful stuff 30 years ago. He used SUNO to reinterpret old and ideas of his, in his judgement it did an excellent job and lets him create many songs daily if he want.
Sounds familliar? the good old "let AI be steered by experienced X and boost productivity".
All in all, gun to the head, i think i am so critical because to use these tools is surrendering to big corpos. It is not a democratic tool. If it was i would probably be using it. I have finally given up and started messing with local models (well, i did already with images) but general local models are useless.
OR maybe it's me? i cannot for one moment let go and converse with the machine. I can give order to the machine.
The tech is fantastic, but the fact that it's in the hand of corpos with all interests in never letting us be able to do shit without them, makes me one hundred and one percent against it.
Have you tried the open weight models, but not locally? Like, using it from a provider. That way, you get access to better models while still not using private closed models, anyone with enough compute can host them, not just the big AI corps.
Suno is completely incapable of producing heavy metal. I can't speak for other genres bc I don't listen to them, but what it produces is completely hollow and devoid of what makes metal metal. I also think most metal fans will categorically reject AI-made metal on principle.
just verified, it cant make a decent techno track, nor a drone track nor anything experimental. Its creativity is subpar, it feels like listening to a producer that knows where things go but is tired of playing, zero interest in creating/ performing, it gives off that kind of vibe
Metal, punk, hardcore - any type of heavy music, really, should reject AI-made slop. If you’re a fan and/or maker of them and are not just wearing the genres as an aesthetic, you fully know they are a rejection of corporate and governmental control.
I mean, even if could produce generic metal would it produce Igorrr? Meshugga? Tim Henson? Baby Metal? All of these are driven by other things then just producing metal. I agree pure AI music would properly rejected unless there was some point to it. I could see it have some part, but then as a weird instrument. Take a model for music, randomly mutate internal weights and then let it produce a drum beat. Keep doing that unless you hit some limit and perhaps that is interesting.
I think this is a question of how much control the user is able to have over the end product. Music creation in particular is very difficult... I've produced music for 4-5 years, and the granularity with which one has to control the finest pieces is often mindblowingly frustrating. It takes years to develope a decent ear for mixing.
By giving up that control, you do get to a quality end result sooner, but that end result can only be an approximation to your original vision, since you're giving up the control required to shape the sound to that granular level.
Additionally, without the knowledge of how you got from A to B, you don't know what else is possible (or impossible.) In the process of doing something manually, you may stumble across a particular setting or effect that creates something you never even considered. And now, that is knowledge you can use on the next project.
Yeah I have played with Suno a lot and I find that no matter how I change the genre, lyrics, etc. there's some underlying quality I can't quite name that my brain recognizes and quickly gets tired of. It's fun in a novelty sense, for now.
> 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.
It's like any LLM, it's not a tool for if you know exactly what you want with all these knobs and fine grained controls.
> 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.
I don't think that's a bug or unexpected, it's what AI is good for. I do these (very) old Blues covers of modern songs and it's terrific at that sort of conversion thing.
In 2024 some people were saying, illustrators will be fine, the models can't even get the number of fingers right! They were wrong.
> If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".
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.
Execution has just moved up the conceptual stack. We once wrote assembly, and then changed to higher order languages. Same is happening with lexical work generally.
Totally, I meant that more in the lenses of how folks are perceiving it. They solve the execution part of the "one shot" aspect mentioned in the post. You still need to do a lot of plumbing, orchestration, supervision, etc. I think it will get cheaper and cheaper over time, though not magical enough to one shot a Rust compiler from "write a Rust compiler make no mistakes" haha.
Today is when ground needs to be broke on the data centers to run it in 3 years.
Suno is a good example. I've written lyrics for a lot of songs and then "produced" them with Suno, a process that involves dozens to hundreds of remix/cover/extend revisions or a lot of time in their editor to get it sounding the way I want it to. The songs are songs that I like and will listen to in my playlist but they haven't gotten much traction on Suno's algorithm. I haven't tried to promote them much elsewhere either but when I have posted them they get a few likes at best. I'm not disappointed because I was creating the music for myself and just sharing it as a side effect but what I take away from this is that getting people to pay attention to and enjoy something that you've created takes a lot of work. You have to market it, get it in front of them, get them to pay attention to it and I'm convinced you also need to give them a reason to like it by associating it with something whether that's a video, a story, a persona or some other vibe. If you want it to "stick" you need to do all of that over and over again for the same audience so that they learn it.
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.
Same here, I vibe coded my perfect alarm & reminders & productivity app for Android, (Promptly AI link below) that does TTS and Gemini calls and other things that rapacious alarm-clock marketing masters charge dozens of bucks per month for, but at some point the day job and dislike of the marketing grind is just too much, summer is here and yeah...
https://play.google.com/store/apps/details?id=com.sixteenam....
This starts from a false premise. Ideas aren't cheap.
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.
To continue paraphrasing Steve Jobs, focus is the most important thing. When the cost to produce new features/implementations goes down, focus is even harder (and even more important).
> I always remember of the infamous Steve Jobs quote "Ideas are cheap". If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".
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.
Could you elaborate on the AI Music tool? My impression was that it's used as a one-shot generation tool. I don't know much about music but I imagine artists need intermediary steps, track separation, instrument customization and other stuff I'm oblivious about. Without these, it's hard for me to imagine it being used for professional work.
The frontier music models, the paid/pro Opus 4.8 equivalent ones, are more capable now, and Suno has a "harness" like Claude Code on their Studio tool that lets you iterate on the generation by doing stem splitting, track separation, edits that stay within the tempo, rhythmic structure, etc.
Sumo produces plausible cheesy stuff that is otherwise sonically awful, ringing alongside the full spectrum due to how it works. As a musician I would not use it - I like to keep some creative power. Some people use it around me for samples… and then their tracks ring. But it works for them as they be advertising producers. Mind u - I’ve used paid version and I know one or two about music production.
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.
I guess we have very different ideas around what makes good music. Every single Suno produced song sounds like a 60kbps extremely compressed mp3 while also having extremely generic, uninspiring structures and complete lack of interesting sonic/instrumental layers.
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.
> I don't know if y'all have tried it, but it now produces really good stuff.
Does it? It produces passable stuff that is fine. However the lack of passion and care completely disinterests me.
Passable and fine is the Hallmark of capitalism.
Code has never been the execution of the ideas is cheap mantra.
It is the whole business flow chain of value to the end user what is valuable.
> I don't know if y'all have tried it
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)
suno produces 7m "professional" songs per day. Can't think of a better example of a slop generator. Many songs that will never get more than a handful of listens if it all.
I've made songs on Suno that I actually like and have listened to tons of times, not to mention just having fun in general making music, seeing what comes out of the box.
The future is going to be different.
Right now, people effectively spend ~0% of their time entertaining themselves with their own music, art, writing, film, etc.
In the future, it's going to be >0%.
Will it be >10%? Who knows.
True of human-made things as well. Most video essays don't get more than a dozen views, most gameplay streams similarly. People playing their guitar and uploading, same. SoundCloud, YouTube, twitch. Human-made app store apps is the same story. Most are not downloaded by even 100 people. Most Github repos don't even get a handful of stars.
LLMs don’t “solve” execution at all. They aid and accelerate it.
Don't kid yourself.
The high watermark of what can be "solved" (read: one shotted) is rising, and will continue to rise. Look at the gig economy (Fiver etc) for simple programming/design tasks, LLMs have taken over completely with their execution.
I've posted this before but worth posting again:
I work in DevOps at a firm that has been very enthusiastic about using LLMs (in the good sense).
The phases were basically:
- try out having the LLM do "a lot"
- now even more
- now run multiple agents
- back to single agents but have the agents build tools
- tools that are deterministic AND usable by both the humans (EDIT: and the LLMs)
The reasons:
1. Deterministic tools (for both deployments and testing) get you a binary answer and it's repeatable
2. In the event of an outage, you can always fall back to the tool that a human can run
3. It's faster. A quick script can run in <30 seconds but "confabulating" always seemed to take 2-3 minutes.
Really, we are back to this article: https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 aka "make a list of tasks, write scripts for each task, combine the scripts into functions, functions become a system"
-- END of original post --
What I would add:
if you let LLMs do whatever they want, they will happily make code. You can add tests to confirm that the tests work (which you used to do with human code, right?). You can also read the code.
When you read the code, you'll find that they sometimes do totally bananas things that still produce working code (I've seen humans do this too but that's another story).
In other words, you still need to make sure the system being built makes sense.
More succinctly:
Coding may be dead but software engineering is alive and kicking.
> I don't know what to do.
Ride the wave. You rode it when websites/webapps were the wave. I came into software industry before internet, kept changing my horse. You are never too old to learn new tricks. The new wave create new kind of work and workers. Be one of them. Ride the beast, master the tools. It's the same game again.
This here.
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.
> Overall society feels more turbulent, but this is otherwise all the same song and dance all over again.
The thing is... everything you mentioned had only brought the need to retrain.
This new hotness AI? It's bringing actual layoffs, and not just of the boom bust cycle kind, but permanent, industrial-revolution kind that lasts for decades.
It is?
Covid overhiring, no more 0% interest rates, that one accounting change, and companies needing a "growth" sounding way to announce layoffs. Maybe that's bringing actual layoffs in the name of AI?
Based on what I've been seeing/reading online the past ~6 months or so, I think there's a self-fulfilling prophecy going on here.
Developers are concerned about jobs going away, but how often are they pushing back in their orgs about how AI works? In response to "are you using AI to move faster," how many are responding with "yes, but there are some things you should know..."?
If there's no pushback and just pure acceptance of stuff like tokenmaxxing, then what does anybody expect when the broader narrative around AI is that it can help a novice to grind out miracles (i.e., "holy crap, if this is what a novice can do, what can an expert do?!")?
Of course leadership is confused because (it seems) few are asserting expertise, saying "no," and stating a clear case as to why they're doing that.
The default excuse is "I don't want to lose my job" (which is a fair reaction to all of this, especially these days), but it's worth considering when/how that choice is actually just shooting future you in the foot later. It seems there's a broader trend toward compliance more than there is "you hired me to do this job properly, did you not?"
> The company is now hiring again for a few roles and domain familiarity is not a strong differentiator anymore. We used to list "Software Engineer - Area". Now it's just "Software Engineer" and the team assignment comes after the offer is accepted.
> Of course, this is good for brilliant engineers that never had the chance to get deep into the domain and now have better chances at getting a job, but it's also sad to think that other brilliant engineers that spent their lives collecting domain knowledge are now competing on the same lane.
If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.
Engineers whose main competitive advantage is domain knowledge are probably not that brilliant at engineering. They might still find employment in other areas of the industry where they accumulated domain knowledge.
> Domain knowledge can be learnt much quicker than how to apply good engineering principles.
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
And I'd still question it. The experience of just… knowing how a good architecture looks like without being able to really put it in words is what makes a good engineer to me. These people can pick up relevant regulations or industry terms and deliver value quickly enough.
> 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.
I think this is true in some things and less true in others.
It's a pretty high moat getting into stuff like simulation software because the people working on numerical methods overwhelmingly have PhDs and it's a mixed skill set. Domain expertise here requires you to know maths to a high level. Even mechanical engineers often struggle here; it's often applied mathematicians and physicists turned devs that work on this stuff.
I worked on a fairly gnarly signal processing thing a while back that required bringing together knowledge of physics and software and maths and I found explaining it to people was tricky as their eyes glazed over at some point because their knowledge typically only covered one part of those.
How is "without being able to really put it in words" a mark of experience? Surely an engineer should be able to justify why an architecture should be arranged the way it is!
There are plenty of deeply skilled, experienced people (in all fields, not just ours) who struggle to explain that knowledge to others. Being a practitioner and being a teacher aren't the same skill.
Somethings are true not because of one big cause but 10,000 tiny paper cuts. Trying to explain it all just becomes a laundry list where each problem seems solvable but really each problem is there at the same time and inter-linked in non-obvious ways. And the experienced person just comes across as a nay sayer who doesn’t welcome innovation.
It's perfectly possible to put that sort of knowledge into words, but not in a condensed "recipe" that can be explained in a meeting, that will go into a single Hacker News comment, that will cover all cases, or that will satisfy LLM users looking for the easy way out.
Pretty much every area of knowledge is full of those. That's why people publish books, that's why people go to college or get PhDs, that's why people with experience gets hired.
You're not wrong that a rationale is required.
But the master knowing when to break the rules because of tacit knowledge without being able to explain it is a real effect
>>"Domain knowledge can be learnt much quicker than how to apply good engineering principles."
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.
> Good software engineers who are arrogant about easily acquired domain knowledge
This is a problem of arrogance, not of domain expertise.
Having worked in a few different industries, I'd wager that for the vast majority of them, a competent person can probably learn 80% of the required domain knowledge in under 6 months. For the latter 20%, as long as the person is not arrogant, they will seek help from colleagues who have been around for longer.
On the other hand, solid engineering principles will take 10-15 years of actually experimenting and learning in practice what makes a system resilient and durable.
"The first 80% is easy... it's the second 80% that gets you."
> Domain knowledge can be learnt much quicker than how to apply good engineering principles.
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...
>Domain knowledge can be learnt much quicker than how to apply good engineering principles.
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.
The development and acquisition of valuable domain knowledge is a hard, risky, expensive and slow process. Because the valuable domain knowledge isn't yesterday's, it's today's and tomorrow's. In fields where domain knowledge matters, it is also deeply intertwined with engineering - you won't task Jeff Dean to develop Unreal Engine from scratch.
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.
This same complaint comes up on the topic of generic coding interviews, although shadowed behind the bigger complaints about simply disliking them. When people develop domain expertise they want to use that as a moat around their job. They want interviews to focus on stories about the things they’ve been exposed to on their past jobs, not test their abilities.
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.
How is software engineering not a domain? If other domains can be easily learnt, sure this one can too
> Domain knowledge can be learnt much quicker than how to apply good engineering principles.
What kind of domains did you have in mind?
That's the right question. I don't like this dichotomy between domain and engineering. It seems to come from people who just build different CRUD apps for mobile and websites for businesses in different industries and that's what they call domain.
Not like a webdev entering game engine design or a database engineer entering computer vision research, or someone working in embedded hard-realtime systems switching to making video editing GUIs.
That's a fair question. I suspect highly specialised industries are harder (rocket and space, defense, nuclear, etc), but for things like finance (most of it, anyway) and retail, which IME make the bulk of the tech jobs out there, it's certainly nothing out of this world.
That's an extraordinarily rosy view of the future.
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 think people are being naive here thinking this can't or won't happen in tech.
What would this future look like? Software developer salaries burrowing into the ground?
There's quite a large cushion for software salaries to decline before permanent structural unemployment were to set in.
It's not really feasible for "normal" businesses to hire developers at current salaries.
Tech companies will probably shrink in headcount, but all the non-tech kind of businesses can increase developer headcount.
Current Tech salaries are far above other fields while requiring (used to) significantly less training or time investment to get into.
Phase 1 is more likely that software comp will normalize with other professions, and more hiring will happen at the fringes rather than being concentrated in a few big companies.
> There's quite a large cushion for software salaries to decline before permanent structural unemployment were to set in
Maybe in some markets but in many places around the world software salaries already weren't that high. Or at least not really much higher than other white collar professions
That isn't going to happen. To me what is going on is that no one really reads anything positive so there is all the incentives to write as hyperbolic + negative as possible to try to rise through the noise.
The reality is this all the standard lump of labor fallacy. I am not a software engineer but it is obvious to me at some point I will be using claude code or whatever to automate tasks. I won't be taking software engineering jobs, I will be using code to do what is done manually today that you wouldn't bother paying a software engineer to handle.
Today's software engineers will just be higher up the stack from me the same way they are today.
In 20 years, many of us will be working in sectors of the economy that don't exist today.
The idea we get something as powerful as AI and it doesn't create new businesses and sectors is just stupid.
Imagine telling someone in 1997 they are going to be getting deliveries from Amazon all the time in the mail. What kind of idiot would believe this? I don't even read that many books!
There will be a handful of people who make stratospheric compensation, a bit like we have now.
Everyone else will have extreme job uncertainty, getting laid off multiple times, losing compensation as a result (ie equity vesting) with compensation that at first stagnates and then starts to slowly decline in real terms.
A lot of the big tech companies will likely spend less effort on non-core activities. Think of all the things Google does. Anything that's purely internal will be gutted staffing-wise because it's the safest testbed for shifting the engineer-AI balance on teams before rolling it out further.
If you listen to non-tech people now you hear tales of applying for hundreds of jobs and getting no response. That will become more normal. What's worse is that AI seems to be to blame here. Companies all use the same AI ATS systems and I've seen allegations that candidate scoring gets cached for upwards of a year. So if the system happens to give you a bad score, literally nobody will see your application because you'll get filtered out before any human sees you.
I was watching a VC give a talk from some conference in France and the general sentiment is that no companies are being funded with teams greater than 5. Why? AI. So don't think you can startup your way out of this slump unless you're somebody who has the connections and CV to get funded anyway, in which case you might well have some of those stratospheric options anyway, at least for now.
This is exactly opposite my experience in my 25 year career.
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.
Only if the domain is shallow and mostly digital.
Applied to real world complex businesses good luck.
I’ve been using Claude Code with Opus 4.7; it’s not that the code it produces is wrong, it simply tends to write too much of it. In my opinion it’s still worth thinking about a particular feature and finding the best way to fit it into your code because Claude will often just pick a layer of the stack (maybe presentation), and jam it in there. A couple weeks later you need this data somewhere else and Claude can’t reuse the code (maybe in the service layer) so it kind of “ports” it over. Unless a person is paying attention we now have the double the amount of code and duplicate logic. I don’t see AI tools like Claude getting better at this anytime soon.
Where I work there’s already pressure to use Opus 4.7 less to save money, someone mentioned using a smaller model for “simple bug fixes”. This might work sometimes but how often do we really know it’s a simple bug fixe ahead of time? I suspect as costs go up we’ll see interest in using these tools to write “all the code” go down. As people migrate to cheaper and less effective models I suspect we’ll see the pressure to skip reviewing that code dissipate as well.
We’ll see where we land, maybe it won’t as dramatically different as the author of this post fears.
I have the same criticism of AI writing too much code. It's surprisingly effective to just tell the AI to cut the (prod) line count in half and look at whether there are other libraries it could reuse. I think you could probably also have a refactor bot that spots duplication and pulls it out.
None of this comes out of the box atm, but it's not clear that it's not possible.
I do this several times per week. You can ask Claude to hunt down duplication, brittle scripty code, overly defensive fallbacks, and footguns.
I had a scenario the other day where the codebase had two functions
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 hack in the same extended params to the first function
It's like I had to keep arguing with it not to do that, it's actually so frustrating sometimes.
> Maybe I should consider transforming my woodworking hobby into a profession...
Whatever your feelings on the future of the industry are, it's hard to imagine you'll find more professional success in artisan woodworking than artisan software.
Custom furniture/cabinetry is already a pretty tough market, and woodworking is such a common programmer hobby that if a significant chunk of us decided to make a go of it the market would get heavily oversupplied pretty fast :).
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'm threading this now and have paired AI-assisted development with woodworking knowledge. Partially chose to work on this because I wanted to build in a domain that the models might have a tougher time understanding.
Parallels and interests overlap everywhere between programming and woodworking; decisions about tooling, tolerances, sequencing, and what can be easily fixed later.
The models get rectangles pretty well and has been fun exploring a parametric casework planner for my own shop.
Depends what you mean by woodworking
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)
Most people would just call that construction
Specifically a carpenter.
Construction working entirely with wood
If only there was another word for that...?
Wood construction is not typically considered woodworking, although there is often a lot of overlap. But the skills needed to make furniture are pretty different from the skills needed to make decks, fences, etc.
Carpentry is not the same thing as woodworking, to be fair. The latter has the connotation of making furniture, trim, and other such items that people want to look nice. Carpentry does not necessarily have that connotation. It's a kind of "all squares are rectangles, but not all rectangles are squares" situation.
I have a historic house with a hand carved/ uniquely shaped door. The jamb rotted and we paid a woodworker $4k to create a replacement. The door itself would easily cost $25k to replace. So, move to a major historic area with hand carved doors and you could make some decent money.
You assume there are enough of these jobs to go around and that you can just show up and do some extremely intricate work. Repairing historic doors and more elaborate woodworking isn’t easy to learn as the knowledge mostly doesn’t exist online anywhere, I also own a historic house and often ask the top tier LLMs for details e.g. about my staircase, they always give wrong answers as this knowledge is simply too exotic and not in their training set. And no one online talks about these things, 99 % of woodworking videos on YouTube are focus on beginners, you can’t replace a professional education watching videos and reading books. That will protect woodworkers with these skills of course but it’s wrong to assume you can just break into this market and be successful, most devs with woodworking hobbies are really shit at their craft and struggle to create even a regular elaborate cabinet, no way they will be able to compete with good craftsmen for these few lucrative projects.
you need some explicit /s in there, i'm afraid it's too dry
You paid $4k because it's a niche task that isn't much in demand.
look at layoffs.fyi. chances are he will be laid off pretty soon. and if not tomorrow, give it couple extra years until AI gets even better. it is one-way road, down the hill.
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.
My comment was about the fact that even if you're laid off, you're more likely to find success in artisanal software than artisanal woodworking. That statement is not an assertion that you're guaranteed success, just that it's more likely to sustain yourself than woodworking is.
Layoffs also don't really tell you anything. Is it actually LLMs that are causing layoffs or is it deteroriating economic conditions and uncertainty amidst war, oil shocks, etc.? Is it junior employees being laid off, or seniors? If it's the former, someone with 10+ years of professional experience might not have reason to be concerned. I happen to believe that, LLMs or not, the software development field already had far too many jobs, employing a large number of clueless people who contributed somewhere between zero and negative value to their organizations, and that it was overdue for a correction anyways.
true, agree on later point.
but for "woodwork" / personal-farm still belive he is better off than software. at least he will be employed and have food on the table.
You are not allowed to have land without participating in the economy. The government forced you to acquire land by buying it, and to pay taxes in dollars.
I mean you can sell surplus to market. but key point you do not pay taxes on food you grown on your backyard and eat yourself! nor you are subject to any market collapse. as long as sun shines and raind pours, your food grows in your backyard, no matter S&P or inflation rates.
You pay tax on owning land.
> get a pot of land and grow your own food
Rejecting industrialized society is actually very expensive
"industrialized society" just rejected 160,000 sofware engineers this year. other industries are no better. you are either wage-slave barely making it. or getting laid off, as those people are not needed.
There were layoffs yes. The solution is to pursue something that on a small scale is net negative financially? Get out of here.
Artisanal food for hipsters is always going to be a market. People are willing to pay a premium for locally or regionally grown produce, fruit, eggs and meat.
However, it's a risky business so I'd only recommend getting started if you either (!) are FIRE already even after sinking 3 million bucks into purchasing land and machinery as well as constructing all the buildings or if you join a cooperative/union or if you got experienced farmers in your family.
Everything else - especially following "prepper" influencers shilling books and holding more public speeches to shill for said books than they are actually working on their farm - is a recipe for certain disaster.
If in doubt... first try raising a few dozen chickens in your yard as a starting point.
> If in doubt... first try raising a few dozen chickens in your yard as a starting point.
No. Just try to make a 5x8 plot to grow vegetables and realise how ridiculously hard it is.
> 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.
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.
> Exactly zero percent of the market is willing to pay for hand-built software.
You took this statistic out of your rear end?
It is fairly obvious that the majority of people who buy software (>99%) don't really care how it's built. They care a lot about the outcome of using it, they care a little bit about whether there are bugs or not, and they care about the cost a lot, but beyond that nothing seems to matter to the purchaser. Even obvious things like whether or not there are tests, documentation, SLAs for fixes, or backwards compatibility between versions don't really seem to matter much.
That doesn't mean you couldn't carve out a niche providing hand built software to people it does matter to, because the software industry is large, but saying 'zero percent of the market isn't willing to pay for it' isn't really wrong. It's just a rounding error that does care.
(One massive caveat though ... the argument assumes that 'hand built' means 'higher quality than AI-assisted', and that's probably not true for >99% of developers.)
> You took this statistic out of your rear end?
We are less than a year into good-enough coding agents, and as of right now there is not a single job opening I see that offers a salary for non-AI output.
> Exactly zero percent of the market is willing to pay for hand-built software.
This is a provably false statement, given that eg. Handmade Hero exists and sold a bunch of pre-orders despite never coming close to completion, and spawned an entire community that prides themselves on handmade software. There are also content creators like Tsoding who make a living by having people watch them do handmade coding for the love of the craft.
Some non-zero percentage of people will also always be willing to pay a premium for superior-quality software. The author's thesis isn't that LLMs can produce S-grade software but that 'nobody cares' about quality and that C-grade software is good enough. While it's true that software quality isn't greatly valued at scale, I think the minority who care is larger than the minority who care about premium woodworking goods, particularly because as an artisan software developer you more or less have access to the global market of every single person who cares, while as an artisan woodworker you mostly only have access to the market of people in your town who care.
This also overlooks that LLMs are politically divisive and there are movements to boycott them and shame people for using them. There's a niche for organic, free-range, vegan, etc. products at the supermarket for conscientious objectors, there will undoubtedly be such a niche for software. All the more so if LLMs reach a point where they actually are putting everyone out of a job, they will get much more divisive. There was already an assassination attempt against Altman and his promises to destroy everyone's livelihood haven't even come to fruition.
> Exactly zero percent of the market is willing to pay for hand-built software.
People are increasingly associating “AI art” with cheap slop. I wonder if the same will ever happen to programming.
I think this can happen in technical communities - people who can write/read/understand code. Who really cares about software size/performance/usability/minimalism.
This is a small part of the whole users, but.. why not. People who value hand-by wood goods are also a small part.
Also, there are also communities which slow down AI integration - like Zig. Maybe they will alive
No it won't. Everyone knows their favourite film director.
Virtually nobody has their favourite app developer.
Only if the quality is bad. And users normally can only judge this when something is not working. So maybe only badly written/tested software will get labeled ai slop.
People can’t even reliably recognize AI art anymore.
The classic “AI images were everywhere in 2023, but I rarely see them now” phenomenon.
I see a lot more bad art now. I suspect most of it is AI, but I can’t prove it.
What are you talking about? They’re so ubiquitous.
this only ones you can recognize What about others which you think is made by human?
I sympathise with the author being in the same boat, largely.
I just want to emphasise a point... Calculators give 100% correct answers and yet we still hire accountants; for the simple fact that we don't want all to be accountants.
People will hire software engineers for the simple fact that they do not want to be software engineers.
"calculator" ("computer") was a profession. not anymore.
https://en.wikipedia.org/wiki/Computer_(occupation)
With todays LLMs, yes. But if they can ever reach a level of a contractor in a reliable way and companies offering them willing to take responsibility (because confidence is high and rest is insured), then one can just hire a cheap AI agent to fulfill a contract - design, implement, deploy, run and maintain your service/website like the engineer before.
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.
I mean, if they can do that, then game over Terminator style.
People don't make their own bread. They buy it from an expert.
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.
Accountants have specialized domain knowledge (laws, regulations, procedures, bureaucracy etc.) that goes well beyond what a calculator can do.
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.
Learning a company and it's product is so natural to us that we hardly talk about it. It's a key skill for reliable workers.
It's probably impossible for LLMs to learn and apply that wisdom reliably.
funny i was able to do all my taxes this year with ai help and not needing accountant.
Lol thats brave on your part, given that a mistake can cost thousands and you have no accountability (punch!) from an LLM
Your account has no accountability. Do your taxes wrong and the tax payer is liable.
Ask me how I know.
At least he has a reputational/commercial risk. LLM has none
In the US, all you need to work in tax prep is a high school diploma and most individuals are not worth the cost of an audit.
I wouldn't say it's particularly brave, in fact LLMs are probably better at identifying mistakes than most tax payers. The % of Americans using a CPA to file taxes is fairly small.
Are you in the USA? Brave person if so.
> I spent 10 years (even more when you account for non-profession experience) getting good at things that are becoming less and less valuable.
This is just how it is, and has always been in this industry. And it takes about 10 years to realize it.
When I started my career in software, businesses were still writing new code in COBOL. 10 years later those skills were pretty much useless, except for dwindling maintenance roles.
Then there was the client/server era. Then the web era. Then mobile. Then cloud, etc.
All the same functionality, written and re-written time and time again, using the latest popular stacks and methodologies.
I hope to be retiring in a few years and pretty much everything I have learned over nearly 40 years is no longer applicable or is at best losing relevancy to the way sofware is built today. And that's how it's always been.
Sure, but those are cherrypicked cases where a technology became obsolete. There are many counterexamples of decades-old technologies that are still actively chosen for greenfield work today, in 2026.
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.
This is a good point. I started with Turbo Pascal in school and my first job was writing VB 5 Windows apps for local businesses. SQL (and C, but I haven't written it in ages) is probably the only thing I learned in the late 90s that has been a constant my entire career. Languages and frameworks seemed to change so frequently that I never thought too much about them. I was always focused on the end goal of solving some business problem.
Maybe denial is a river in Egypt, but I (most of the time) believe that the glass is half full and we will need MORE humans as LLMs gain in ability. My thesis:
1. most jobs are created by small to medium size enterprise
2. the throttle for new SMEs has been people, money and ideas, in that order
3. with LLMs being a force multiplier, fewer technical people are needed but some people still ARE needed
4. with less throttling, MORE SMEs will be created with more jobs - they will be able to do more, faster, but still need some human oversight.
Also, what is the point of software if it is not to serve human needs?
Also, in open source, community building and tending is a very human enterprise that will not be replaced by bots any time soon. So, as coding becomes commoditised, perhaps the soft skills backed by technical knowledge will be the complementary skill that increases in value.
Or, maybe it's time for me to become an itinerant folk musician.
Software boom due to SMEs looks very unnatural to me, because what makes software so special is its ability to scale, so it naturally tends to monopolization
It's odd to me how quickly the author devalues their own experience just because AI can do certain things well. There's a huge chasm between what AI can do when prompted by an expert software engineer vs a non-technical person. Sure the models and the tooling will get better, but it still needs to be driven by someone with an intuition for how software works and able to dig in when necessary to unpack and correct the hallucinations, misplaced assumptions, or straight up borked code that will come from the gap between what a human wants and what they can express in words.
I have no idea how things will play out, but so far I am not worried because the amount of software continues to increase, and AI only accelerates that trend. This will require the same mental modeling, first principles thinking, and relentless curiosity that already formed the foundation of the software engineer skillset.
I think the core issue is not AI itself, it's people.
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.
The other thing is that a lot of this thread is talking about domain knowledge and ignoring it forgetting that a massive number of jobs in this industry are in web app crud.
There is a massive number of software engineers that are closer to plumbers than computer scientists and for them the progressing AI models are going to be a problem.
There's no point debating people who are in a blind mania. Sometimes it's better to just keep your head down and focus on what you can control while "mistakes are made". You will be infinitely more appreciated once they acknowledge that help is needed.
Sadly while I agree with this attitude, from experience they will ever get to the point of acknowledging help is needed. Eventually they'll find a way to blame the workers again to justify laying them off and double downing on doing things the stupid way.
> It's horrible to be a software dev right now, you've to deal with AI and lunatics.
Yes, yes, 1000x yes.
As a bit of an aside, I have been toying with the idea of adding some sort of second pass/security auditing/scaling offering to my consultancy for people vibe coding projects which wind up generating interest. (Not sure what the fuck else I'm going to do!) I have a few non-technical friends who have found themselves in this situation and there's a real need for it.
The aspects of it which I find daunting are the ones you've referenced, though. I imagine many people -- especially the ones who've built mobile apps for $300 in tokens -- are going to balk at the costs I'd have to charge for such a service. We're also now living in an era where everyone is an "expert" (lunatic) ... with just a little help from Claude/Gemini/Grok/whatever. I can already foresee people second guessing every suggestion, decision, line item, etc. I'd also be taking on a liability that'd be tricky to completely work around via legal language for any bugs or security issues which might/would inevitably slip through review. Ironic because nobody blinks when LLMs excrete those things.
But, anyways, circling back around. Yeah, trying to find work in this market has been a new exercise in frustration. AI is all anyone wants to talk about, it's driven hourly rates through the floor and most of the open gigs revolve around model training and carry an implicit expiration window for the trainer. It sucks and I really don't know what I'm going to do to keep my consultancy open going forward. (As signs of how desperate I'm getting, I recently signed up for Task Rabbit and am seriously considering applying for a job at Tractor Supply.)
I agree here. Sure, certain tasks that would take weeks are just one prompt away now. But out of a group of 100 people, how many are able to come up with the correct prompt?
To me looks like, if we're not collectively careful, civilisation will soon be on a path to an evolutionary dead-end.
Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack, meaning that only the owners of capital will be left, and they too will soon fade as the economy falls off a cliff and money has no value, because the only value that money has is the value of a human backing that, with thought, with ideas, with human output.
Whether you like it or not, "Economic output" is just a different phrase for "Human output that is valuable". When all human output is valued at the fractions of a penny per month of work, there is no future.
>Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack
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.
This is so blinkered and egocentric.
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 grandparent commentor predicts 'that which replaces a sweng can replace anything'. llms sure do replace certain language related tasks, sometimes, when correctly piloted. however the majority of the world do not work language related jobs. perhaps if robotics firms bridge the gap to reality using some novel architecture this prediction could come a bit more true? until then it does seem blinkered to assume a set of weights could build a house.
hard agree on the last statement. programming is language. if you're literate you can code.
No lelanthran, software engineering and plumbing are not the same job. No lelanthran, LLMs can't be plumbers.
A new generation of AI companies is out there to take over blue collar jobs as well. Check recent YC batches.
Software engineering was a nice target because inputs and outputs are just data and you don't need to figure out robotics. But idk, 3 years ago it seemed illusory (at least for me) that LLMs could take over software engineering, but now here we are. They are still not 100% there yet (software engineers still have jobs), but we are getting ever closer.
Companies are in the process of figuring out robotics, and even if it's not figured out, then we might introduce a gig-ified blue collar economy where an unskilled, underpaid gig worker implements instructions by AI. Plus a lot of blue collar work already today involves robots (cranes, excavators, trucks, etc).
LLMs not but generalized multi-modal VLA models, yes.
Seems some on HN haven't been keeping up with progress in physical robotics. Unique physical work is lagging behind a bit, but not by much. Expect to see robots doing simple plumbing jobs within a few years, not a few decades.
> No lelanthran, software engineering and plumbing are not the same job. No lelanthran, LLMs can't be plumbers.
Who said that?
More to the point, how many plumbers does society need?
> Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack
Direct quote
>> Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack
> Direct quote
And, in your (and GP's mind), that means the same thing as "LLMs can replace plumbers"?
After all, I said:
>>>> When all human output is valued at the fractions of a penny per month of work, there is no future.
I mean, I know it's fashionable to not read the article, but are we all really responding without even reading the comments? Are two paragraphs well beyond the attention span of the readers here?
Okay, lets go with that asinine comeback: What do you think happens when the only work left for humans to do involves 100% physical labour and 0% thought?
How many plumbers does a society need? Electricians? Even in construction, you can automate almost everything away with cranes and similar.
Now imagine that all the doctors, all the office workers, all the warehouse workers, all the bankers, lawyers, teachers, ... basically any job that requires thought ... all those people are now joining the legions of plumbers.
That sort of 1000x increase in supply will drive prices to pennies.
The LLM doesn't need to replace plumbers directly; all it needs to do is replace everyone else, and the value of plumbers approach zero anyway.
Are plumbers not "in the employment stack"? How about hairdressers? Are they in the employment stack?
I have zero doubt that half of humanity can all have jobs continuously expanding the mansions of the other half who don't do any work but receive all the benefits.
> Anything that can replace a deeply experienced s/ware engineer can replace anyone in the employment stack
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.
> Nope, just knowledge workers. We’re decades away from automating many manual labor professions, even “unskilled” ones.
How do you figure? We’ve already automated away way more manual labor jobs than we currently have.
> Nope, just knowledge workers.
Nope, just a specific kind. Those who developed and cultivated only a very specific skill set at the expense of all others.
I used to think being a generalist, and having persued technical roles with a people facing element was to my detriment, but it’s turned out to be the best decision I ever made.
I had the opposite thought.
Being a generalist was very useful to me 5 years ago. Now AI models have made everyone a generalist. That wide but not terribly deep skillset was immediately devalued by the AI models.
You can argue that the models fuck up 20 percent of the time, or that they make poor code but there is a massive part for the industry that is totally fine with that and I think people ignore it to their detriment.
The major blocker for manual labor automation in that fashion is cheap energy. China is ahead of the pack with the States' weight behind aggressive expansion of solar tech, and still can't do that.
That sounds more like a problem of close minded narrow focus on economic output instead of culture, virtue and spiritual traditions.
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.
> That sounds more like a problem of close minded narrow focus on economic output instead of culture, virtue and spiritual traditions.
I’m starting to be more sensitive to the argument that without god, people are unable to have a strong moral foundation. Not for the people expressing creativity in how they fuck, but as a check on those in power.
Most people already have god.
It takes a special kind of issues-riddled mind in very unhealthy place, for the lack of better words, to assume that people without strong faith have less morals.
In my own experience such people are often far from objectively moral or good people themselves, and overcompensate some deep issues.
> In my own experience such people are often far from objectively moral or good people themselves, and overcompensate some deep issues.
It is very true in my experience. It is also very not true in my experience.
FWIW I’m an atheist. Curious what you mean by issues-riddled mind. What issues? What’s the unhealthy place? There is no one person I’d accuse of lacking morality through godlessness, but I do see a trend. Most particularly in the people and communities who would have previously chosen godliness and replaced it with nothing, not those who previously would have chosen godlessness.
>i’m starting to be more sensitive to the argument that without god, people are unable to have a strong moral foundation. Not for the people expressing creativity in how they fuck, but as a check on those in power.
If this were true, why did the medieval peasant have less rights and autonomy in society than we do now?
Balance in all things.
Also, I’m “starting to be more sensitive to” I’m not fully bought in.
There has been said so much about it in the past and I always believed it to be true, as an atheist.
I like to think that one of the symptoms is politics becoming really absolutist, idealistic and cultish. You do not debate followers of a different religion. But many topics really becoming kind of a mini religions.
I don’t know for sure though, there are arguments against it too and other factors.
I think substantial amount of people really need some kind of subjective spiritual experience to their life and maybe ignoring that need breeds some maladaptive tendencies
maybe if people werent busy fucking around so creatively they could band together as families and follow agreed social practices to ensure distribution of labor and charitable action in their local communities, maybe then people would care more about their neighbours and less about consuming shit. no thanks ... everyone too busy creatively fucking around and consuming shit while ignoring reality (eg partner count directly correlates to divorce rate, fill the blanks what divorce correlates with).
maybe thats a reason that god was deleted from the western cultural lexicon, so that broken communities could be capitalized upon? no way, surely god is merely a deprecated irrelevant vestige. it's not like a fractured social fabric is a ripe substrate of raw suffering to mine profit from. surely a few hundred generations were enough for our morals to have been encoded into genetics, we don't have to bother consciously practicing morality any more. that's for the narrow minded.
<alt version of above paragraphs from ludicrous perspective of individual experiencing theocracy and its own form of propaganda>
..... this isn't intended to be aimed at anyone except those who delete god to make money, and those who use god to make money. there's plenty of negative aspects to religion. the argument is intended to focus on the sheer idiocy of expecting morality to spontaneously manifest in the absence of external motivation or any teaching of lessons already collectively learned the hard way.
Part of the problem is some of the most creative fuckers are those spearheading the “band together as families” movement.
I think that social justice replaced the religious preaching of values in many circles but it was well… it’s not a sort of thing that many find appealing to follow.
Concepts like "checking your privilege" or being "canceled" closely parallel religious ideas of original sin and repentance, where individuals must acknowledge their unearned moral failings to become "good".
Actions like using specific pronouns, displaying yard signs, or performing land acknowledgments function similarly to reciting a catechism; they signal allegiance to a shared belief system and reassure the in-group
Protests and social movements often evoke the communal, revival-like atmosphere of religious gatherings, providing participants with a sense of purpose and belonging
Owners of capital, yes, but also owners of the means of production (which now means AI companies). See https://blog.oberbrunner.com/blog/ai-risks-taxonomy/#economi...
That's what capital means.
> "Now I have CLIs that one-shots bugs across distributed systems for me. Bugs that I couldn't solve in the past. Bugs that would take 2 days of full-time debugging. Bugs across distributed systems that lack distributed observability. 90% of the bugs are one-shotted now, including bizarre race conditions, unexpected corner-cases, third-party integration issues, undocumented API edge cases, everything. I hardly have to intervene."
The fact that the author can articulate _why_ the AI is getting so good is kind of a moat for specialist, right? Imagine a layman prompting without domain expertise:
"There is likely a race condition here + [long-winded explanation and analysis carefully guiding the AI]"
Degenerates to:
"This button is not working, please fix. I don't care about code. Decide yourself"
Degenerates to:
"Claude make me money"
This doesn’t read to me as someone who is sincerely impressed or rather surprised what ai is capable off.
This reads like someone is trying to convince me, that ai is just this good, and that the author is telling me to use more ai.
To me this sounds like: Trust me, it’s really bad, i know what I’m talking about. Just lean into it, or change profession.
I was thinking maybe the author really likes Datadog MCP or has some kind of conflict of interest. It's weird to see this content in HN.
yes, I stopped reading it because of that, and because it felt AI generated.
> And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless.
How is that true? I've been using Opus on an industry scale over last 6 months and this is just not real.
It has consistently with a certain percentage of chance each time (and no claude.md and skills do not stop it fully):
* Suggested to remove tests to allow for things to pass
* Suggested remove an error so that things can be "unblocked"
* Suggested to use a second path when the original path ran into problem instead of making the original path accomodate for that possibility.
* Suggested or silently added "features" or "guardrail" that I don't want.
* Can be left unsupervised only if given a goal that it can verify against itself. Without such clear goal (e.g. this test in the integration environment must be fixed), it flounders.
I'm not using just the native harness (e.g. CC) either, with additional, customized harness, the behavior improves somewhat but are still fundamentally constrained and cannot really be trusted without verification.
See my methodology (100% handwritten): https://aperocky.com/blog/post.html?slug=agentic-development....
Being a heavy user I think I've ran into every single hallucination that the model can do over development release and operations. I am still a heavy user but there are a lot of value in recognizing where exactly LLM's limit is and work around that.
To me the greatest monument to Claude's poor software quality is Claude Code itself.
Yes, let's build a 40K line main loop! I wonder if they thought claude code need to be more like an LLM to work lmao.
I think the one thing the author is underestimating, especially in his "first pillar" is that he is able to coach the models into great results because he already knows the lay of the land. I often make the same mistake. I see people struggle with GenAI, and feel flabbergasted how they succeed to fail, but then if you observe how they work the tool, it is clear they have no idea what to ask or how to evaluate and iterate on the responses.
He says that taste doesn't matter and it hasn't in the past. However, in an era of "extruded code product" (by analogy to https://tvtropes.org/pmwiki/pmwiki.php/Main/ExtrudedBookProd... ) automatically generated by the truckload at negligible cost, the differentiator for software developers will necessarily be the ability to create a product that doesn't reek of extruded code product, i.e. the things like quality that he labels taste.
(Whether any one reading this, myself included, survives in the industry long enough to reach the other side of that transition is a different question.)
[EDIT] The reason I use books as an example is that 4.2 million books were published in 2025 (https://ideas.bkconnection.com/10-awful-truths-about-publish...); 3.5m self published (with most likely LLM assisted or wholly generated) and the remainder traditionally published. (That's ~9,600 new self-published books a day.) Who actually still sells enough copies to make money in this paradigm and why offers hints as to where the software industry is likely headed.
This feels fake/engineered but regardless of that also redundant.
It's the exact same story that we've heard countless times by now. Hosted on a blog with just a single post. Named in a way that suggests that said blog was created for this very single post.
What is there to learn from this other than LLMs seem to be bad for some people's psyches and that AI companies need these very stories to not get their funding shut down?
>Hosted on a blog with just a single post
Would you put a "Hey i'm feeling a little useless" post on your main blog / linkedin?
It's 100% fake, and half the comments here are from 20 year olds working at AI companies.
I mean I kinda get that it sucks being a junior now, but otoh, it might also not?
It might be easier to adapt to this new tech when you're 19 compared to when you're 59.
But honestly, this discussion _also_ has happened ad-nauseam by now. Everything that was worth saying has been said. And then some.
People don't actually want to talk about LLMs. They want a hug. And that's fine, human and all.
But could you please just start asking for hugs instead of encoding that into vaguely profound sounding takes on AI? I'm tired of this play pretend.
Domain knowledge and architectural skills are not gone. I can say even Opus 4.7 and GPT 5.5 get domain-specific stuff wrong. I use both, because when I am not sure I ask both and also check with Gemini. But these days, I ask those even when I am sure - its like I get something confirmed from a peer. And yes, you have to be the gate keeper - the speed breaker in a way - LLMs still lack a lot of context. And even if they get more context, they will end up costing a lot and still have no accountability. In accounting, one wrong entry and the whole system can be seen as "unreliable" - thats why you are needed. The interesting part is "who takes over" - accountants who become coders, or coders who become accountants. And the latter looks more likely, in any profession. And when that happens - the bar will be raised in these other white-collar professions too, just like what happening in tech.
Opus is getting good at architecture - I need lesser "pushbacks" either because I have learnt to say the right thing or it has learnt to do the right thing - I do not know which one.
Same boat here, just a couple years more experience.
Current LLMs are still kind of shit at actually programming so many jobs do still care to have professional programmers. However, I think it's evident that if things stand where they are, employers will care to have far fewer of them, at least of highly paid highly experienced programmers. If this is the state we're in with LLM adoption when they can't help but create the same helper functions 15 times, god knows we're screwed.
So we should probably work on clearing out our debts and figuring out what else we might want to do with our time, I reckon.
I'm still going to try to do a good job. I'm still trying to learn the best effective ways to apply current LLMs (Right now I still prefer to mostly write code myself but have been using LLMs to bang code into shape via iterative code review; this is a way to exploit LLMs to make better code, especially applicable if your velocity was already good.)
There are lots of positives that have resulted from using AI in software engineering. (1) No more long repetitive text editing sessions. I.e. changing namespaces or replacing deprecated APIs with the "correct" ones. AI will make nearly perfect text modifications with ease. (2) No more bike-shedding code reviewers nitpicking over every tiny coding decision. I.e, "you should use std::format instead of std::stringstream". AI will match the existing set of nitpicks so you don't have to. (3) Average Joe's and Jane's can craft applications by just talking to the computer. This might inject a freshness to the current state of software. Currently, we are all forced to use the same bloated applications like Word, Excel, Jira, and Photoshop. We are currently forced to deal with the same set of monopolistic SW companies. Now average folk can solve problems and avoid dealing with Microsoft for a spreadsheet program.
Average folks like their Excel and Word. Most families have MS subscriptions like they have Netflix subscriptions.
Monopolies will continue as Token prices continue to rise.
There's a certain irony in masters of automation lamenting that their roles are being automated. I wonder whether the jobs their efforts eroded in the past ever got the same thoughts...
Programming, logic, etc are skills and toolkits. The optimal state of society is everybody being able to apply them, not just the enlightened compsci caste. There was a time in the past where scribes were paid nice cash for their efforts, too.
I guess the lesson to learn here is treating a toolkit as an identity and job for life. By virturee of the essence of the job itself - if the tool gets cheaper and more widespread, it's aactually success, not betrayal.
You say that the optimal state of society is for everyone to apply programming and logic etc. but the obvious final result of these developments is that no one will.
Maybe the artform will be lost, but surely humanity will inherently be more 'logical' and systems driven afterwards?
Maybe using writing as an analogy is flawed, but most of humanity having 'writing' as a core skill did enable many other things, even if oral storytelling cultures suffered at its hand.
At its core, tech is all about breaking through inefficiencies and barriers. Does it matter if people can't code python if people demand government systems be frictionless in the year 2500?
Sincerely, how is prompting an AI to build software for you building "logic and systems thinking"?
The thing many people are ringing the alarms over is the offloading of critical thinking and knowledge work to LLMs.
Being able to program isn't the end game of critical thinking. Programming languages are just a way of representing the processes. The thinking underneath was always more important, and there's now technically more time freed up to focus on that. Billions of people now have access to tools which will aid them in reasoning through complex problems without needing a $100k CS degree. Of course some people are using LLMs to get recipe inspiration, but others are now empowered to do things which were impossible for them before.
I personally think the alarm ringers are mainly the privileged elite who are scared of their moats beyond filled in. LLMs have effectively broken down the gates of access to knowledge. In a diverse world, having more people being empowered to do more things has to be a net positive.
You clearly haven’t observed anyone actually using AI.
I've come across lots of novel uses, though. I've seen non-technical people in law, education, hr, all spin up interesting projects/workflows which have helped their jobs/lives. The most interesting was a teacher who's dropped powerpoint, and is creating interactive lesson experiences; mainly presenting the content through popular games and creating engaging activities to apply the content. A recent one was a mock UN summit presented like a game of Civ with territory mechanics. Absolutely zero tech background, just curiosity.
Once people get over a few hurdles, things like: >tech's too confusing >$20 is a lot of money to spend on a subscription >AI is just a fancy search engine >AI will do all the work for me
You start unlocking a fair bit of creativity in people. I mean, all this is brand new stuff even for tech-savvy people. It'll take a while for the genuinely useful uses to dissipate out into the maasses.
Not everything has to be a billion dollar business.
My prediction is that the review / human in the loop part will become much bigger and more discussed.
Current transformer technology will either plateau or eventually we will get to that singularity bracket. (I was a skeptic once but all signs point there)
And this means models will eventually get better.
The main human value will be
- intent (we call the shots of why and what, AI will take care of the how)
- taste (everyone now immediately identifies Claude designed landing pages, they all look the same, taste changes with time, and can’t be predicted)
- supervision, both before and after AGI, to ensure no accidental damage, no misaligned decision drift, or in the unlikely but still statistically possible case of AI going rouge
Anything else (if we don’t plateau) can be eventually achieved.
Having that said, the fact AI can do it, doesn’t mean we’ll want AI to do it.
If there will be enough demand for handmade creations (with the current anti AI sentiment I can see it having an impact at least as similar to organic food) then we have some hope.
The bitter lesson is that there is no domain that will be left which AI won't get good at eventually. So really you have two options: if you actually believe the timeline is long you can keep retreating to the sectors that will be taken over last (emotional support nurse etc) or you can just say if you can't beat me join em and try to supercharge your career/project/life with AI now so it improving helps you rather than hurts you.
The supercharge bit missed an important fact: that strategy is very temporary. Getting expertise in software development takes a long time. Getting expertise in these LLM tools takes a lot less time— the combination of LLM expertise and dev expertise is the useful part. If LLMs make working developers, say, 35% more efficient, that’s going to be many thousands of people out of work, many of them being the most experienced and expensive we have. It’s not like those people are all going to give up immediately and become DoorDash drivers — they’re going to fight tooth and nail to get a job that uses their existing hard-won expertise. That means they’re going to level up their LLM knowledge, be willing to work for a LOT less money, and bring down everybody’s wages in the process. Companies don’t pay people based on the amount they bring to the company — they pay people based on the going market rate. That’s about to be a whole lot lower. So no matter how much you supercharge, you’re only buying yourself a little while until the labor market catches up. Nobody in development is safe. The entire field was so busy seeing how fast they could saw branches off of a tree that they didn’t realize they were standing on the wrong side of the cut, and the business side of the industry could not be happier about it. You’re basically working as a manufacturing engineer in the 90s US specializing in moving processes to offshore facilities. Probably felt pretty clever for a few years until they got the pink slip.
Honestly, the only hope that the dev field has is this all being so economically inefficient that the industry as we know it collapses after the VC subsidies run out, and we’re going to pivot towards much more reasonable interventions with local models and such.
We have all the AI tools you could bare to mention, but we still don't have anyone but programmers shipping things.
Why aren't the designers and PMs shipping things if these tools are so good?
I don’t know about your co but at my job we very much have non SWE shipping their own (mostly garbage) apps
I've consulted with some big companies on AI strategy. I tell them there are two approaches to AI.
1) Train AI to replace human work. This gives you 50% quality for 10% cost. 2) Train AI to assist human workers. This gives you 200% quality for 110% cost.
Most companies will go with option 1, and it's a race to the bottom. Eventually, someone will go with option 2 and gather up all of the pieces and take over the market.
“We were taught that generalists and specialists will always have their roles. But now the market is shaping everyone into becoming a generalist.”
I see this as a negative, the whole once everyone has everything than everyone has nothing type of argument. The company I work for believes strongly in keeping humans in control and in the loop which is something I’m grateful for but at the same time who knows how long that will last. Companies are starting to get their AI bills and realizing how much this AI usage actually costs so only time will tell but I hope, for the sake of everyone, that those with the knowledge described in this article make effort to keep their brains in shape.
> I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
Don’t sell yourself short! Taste is not promptable, I suspect good taste is AGI-complete.
Especially in domains like fintech, there is a lot of accumulated wisdom, and that is what you’ll be handsomely paid for (for at least the next couple years :/ )
For example, architectural patterns, when you need bitemporality, immutable logs, CQRS, all these good patterns that can only be learned by owning years of system architecture - none of these feedback loops are in the training set.
And from a product design side, agents will just miss key concepts and you need a few words to prompt a fix - but that might represent a massive tree search optimization, or the agent on many cases would just fail to identify the requirement. These small steers feel small, but by evaporation our work has distilled down to just the extremely high value insights.
METR task time is still at weeks, doubling every 7 months; it’s years (assuming we keep riding this crazy exponential) until you hit multi-year tasks. I don’t see wisdom / Métis being solved in 2027.
All this said - I think it’s important to extrapolate forwards, if the trend continues, this will may all be true in 3-5 years. Now is the time to pre-register what metrics would make you worried, so that you can define your red lines. There will be a rapid consolidation of power and wealth if these tools continue on their existing growth trajectory.
Agents are getting good but professing they are surpassing you in domain and architectural knowledge with no special prompting is basically self reporting at this point. That could be your job wasn't that complicated or your personal knowledge wasn't that strong, either way, same result.
Don't get me wrong, I am sure we will get to all three of these pillars, probably by next year. I am not naive.
The OPs domain/subject matter expertise is the part that should elevate their career. Understanding how large applications are constructed should also remain a pillar.
The coding and debugging part will be GenAI and possibly guardrails (harness engineering) tuned specifically for fintech, which they are also well-suited to implement.
Every 3 lines coming out of Claude has got a bug in it.
There is going to be a lot of demand for people to clean it up.
I think this is the first time I saw someone describe so clearly my concerns and experience with LLMs.
I have little to add to it, except that I agree completely. Not sure what’s next
Many people share this sentiment, many people don't.
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).
I posted this elsewhere, but I think it still has a valuable insight to bring to the table: https://halecraft.org/software-engineering-is-the-new-manufa...
> LLMs are regression-to-the-mean machines--they pull junior developers up, and drag senior developers down. Taming them requires trading the romance of 'code as craft' for the physics of manufacturing.
The thing I don't know is: how do we decide which direction is most valuable? I can see arguments in both directions--quality vs quantity, essentially. I think there's a strong argument for the value of both:
- we need more quantity of software: for a long time, the ability to write software has been locked up, confined to a closed cabal of specialists
- we need more quality in software: we depend more and more on software in every aspect of our lives, mistakes are intolerable and should be avoided
I have not seen evidence that they are regression to the mean machines.
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.
I'm curious what you think of as "the mean"? I consider the input training set for an LLM to contain its mean. My hypothesis would be: an LLM alone cannot consistently produce code above the mean of the quality it was trained on.
The input training doesn't matter much, besides, the input training is already skewed for code that has been submitted after much trial and error by a dev locally and possibly reviewed. And input has an over bias over open source projects, not crap internal tools no llm has ever seen.
There's more to the quality of the output, like prompts, the quality of the codebase (from which the llms learn), the documentation/harnessing, the feedback an engineer provides while reviewing multiple times (in the chat, in the diff, in the pr) etc, etc.
The problem with “code quality” and LLM’s taking over your first 3 “pillars” is basically that LLM’s don’t care.
I recently had Cursor evaluate a huge code base that we took over. All public stuff, nothing scary security wise, but it was so convoluted that it was taking me forever to find the bugs. It was written by a person, I should add.
I did this in cursor and after one prompt using Plan, it found all the bugs, created a plan to fix them, it looked good, and I had the agent create the fix.
It took 30 minutes.
The client had this project in the hands of another company without ai tools and they couldn’t fix the bugs she told them about.
So my point is, if we are holding on to our jobs for dear life on the basis that “code quality” matters, you might as well kick down the 4th pillar. Like I said, the LLM does not care.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
I think the author downplays how much of that knowledge is used on knowing what to zoom in on, what to prompt, or what to look for.
Like all my C skills that I spent ten years mastering aren’t that useful either. But being a hard worker, smart, able and eager to learn new things, and able to judge accurately if I am helping people out (boss, coworkers, customers), these are and always have been the keys to my being a good hire. It’s a great world for smart, kind and hard working people. No idea where the LLMs are going but it will be interesting and I will be able to use and explain them in useful ways for people.
Yeah the writing is on the wall. Not just for knowledge work, but for jobs in general, as I've been saying in other comments. The era of wage labour, and this dominant economic system, is coming to an end. There's no way it can coexist with AI, but it also needs to continuously push for better AI, which means there's no stopping it. The only thing to do really is brace for the disruption - which will likely be pretty rough - and hope governments play their role properly to ease the transition.
I agree but I think it would take awhile. Some of us here seem to believe 2026-2027 is the end of programming jobs. At least that's Amodei seemed to be saying but then changed his mind later on?
Well given the pace of improvement so far, it's possible - though not given, IMO - that before 2028 we'll have models that make programming jobs fully obsolete. But that doesn't mean jobs will suddenly disappear; many places, especially in 3rd world countries, will continue to have humans programming for a while yet. Just that the available positions will slowly taper out over several more years, until only the most critical systems are maintained by a few humans, and programming - and other knowledge work - becomes purely hobby. Manual work will follow the same trajectory as AI also accelerates innovation in robotics.
It's possible , yes. For now I'm betting against it, we'll see.
Amodei has a track record of saying blatantly false shit in order to drive hype. At this rate, I see him as a snake oils salesman.
10 years of software development is still young and inexperienced.
Interesting that this dev sees domain knowledge as the most important part of his job. Over my nearly 30 year history, I consider domain knowledge as the least important aspect, and in fact have experience of many varied domains. 3 years web development, 2 years systems administration, 5 years point-of-sale / payment systems, 3 years performance management software, 16 years games development, 2 years GPU development tools, etc.
In every case when I've shifted domains, the skills that have got me the job were demonstrable solid programming experience on a wide variety of systems, with only a tangential link to the new company's business. In each case, I've gone in knowing almost none of the domain knowledge, but it's never been a problem because the business analysts know that stuff and tell me what they want me to do, or it's been stuff I've been able to pick up in the first few months.
For example, when I switched to games development it was the combo of systems admin and web backend development that the company wanted, I actually used none of those skills in the first year doing what they hired me for, and pretty quickly I'd transitioned from that to become a rendering engineer, and I've now spent the majority of my career optimising shaders and game engines.
So for me, it's certainly the case that I value my adaptability across domains, and I'm not worried about having to shift to another business domain because I know I'll be able to produce whatever it is they want if there's a reasonable spec in place.
Sure, when hiring if you have 2 candidates - 1 with the exact domain knowledge you want, and 1 without, the one with domain knowledge has a head start, but in the case where nobody has that domain knowledge (or in the case of the article, it doesn't matter because AI levels the field), then I don't think it matters much. Personally, I'd rather be the person with the broadest skills and able to pick up what I need than to have been stuck doing the same thing my entire career.
Most people don't really want to acknowledge this because most people have optimized only for learning domains and are still terrible at the job of actually putting together solutions, writing software, etc., even after 8+ years of work ostensibly doing exactly that. Constantly falling standards agree with them, though; no one really cares to have good software that is well put together, it's more important to have surface level knowledge about frameworks and domain knowledge that can be taught in less than a month (though most people think their particular domain is oh-so-complex and difficult to deal with).
There’s one force where software engineering is being automated by LLMs, but the other force is that there isn’t really much more software that needs to be built. Even before AI coding became big, back in 2021, we were already in late stage SaaS territory where each new idea was an increasingly minor variation of an existing idea. There were no new GitHubs, Herokus, Stripes, Salesforces, Instagrams, Reddits, just variations of those for more specialized markets.
It’s really unfortunate that AI hasn’t raised the ceiling on the space of possibilities as much as it’s raised the floor on how much can be automated, we’re all getting squeezed in the space between.
Can't disagree more! There's bottomless demand for more software. Here's a few examples I encountered just in the last few weeks that wouldn't be feasible before LLMs:
- More localism. Are you afraid of being cut off from tech by some future US government? Now it's feasible for your local culture to grow its own office suite, operating systems, Active Directory competitor etc. A less interdependent world with more competition does have its advantages.
- The building management company for my apartment sucks. Basic problems go unfixed because they appear to suffer extreme labour shortages and serious problems with flaky labour e.g. employees that just randomly go AWOL in the middle of conversations without bothering to tell anyone. A lot of the work of these employees is actually just coordinating and paying contractors in response to problem reports, something that can now be automated by AI ... but they haven't done it yet.
- I just finished assembling some flatpack furniture. Every time I do this it reminds me why IKEA dominates the market. Other furniture companies give the strong impression they don't usability test their instruction leaflets. This should and could be massively better: AR assistance during the build would be great, AI stress-testing instructions to verify they make sense would be great, AI checking every packet has the right number of components in it would be great. And there are lots of furniture companies out there. They don't all need to use a single SaaS to do this.
+ in general robots will require tons of software/models to make them do tasks usefully, especially as they lack training data.
That's just a few examples of places software could have made my life easier in just the last few weeks.
> there isn’t really much more software that needs to be built
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.
>Of course, I'm still employable because someone has to review the code and steer the robot...
We will work for the robots, steering them to steer us.
The saying goes... first we shape our tools, then they shape 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?
Interesting Tony, you seen to have been working for the AI since long time. We others are catching up but eventually all of us will be working for it, as directly or indirectly we are already doing. The "robot" was figurative cause we are no different from a machine, but that is too much for humans to comprehend.
I work for myself and the world, not for Ai. It's a tool without identity, but a damn good one that multiplies my capabilities.
I anticipate the first bifurcation to be wheat from chaff. Ai is going to do better at a job than say half the people, those who don't care about the effort they put in or the quality of their output. These people will have to come to terms with their mediocrity or blandness.
I'm still unsure what the good ideas are for when we reach a world without labor scarcity.
<I'm still unsure what the good ideas are for when we reach a world without labor scarcity. It should be real creativity the final goal to this life optimization. For now many of us need to fight for survival, for food, shelter... so is a bit difficult to be purely creative. But is also true that given all the benefits (taking off the survival instinct) makes creativity obsolete.
>I work for myself and the world, not for Ai. Yourself really? Start by defining "I", "work" or "yourself"... then we may proceed to the next LOL
From someone who thinks there's too much AI doom right now and is a glass half full optimist: If you are a software engineer reading this and panicking, don't. The author only mentions his codified, stable knowledge like you'd get from a distributed systems O'Reilly book.
There's no mention of the functional elements of a software engineering role - incident response, working with auditors to define and maintain controls for internal services, handling escalated account support & fraud, working on DevEx, selling shovels (MCPing your consumer-facing APIs/services), getting on customer calls to help sell your company's X feature, managing people downwards and upwards.
The piece kinda reads like remorse over sunken costs and attachment of knowledge to personality. If you twiddle your thumbs and stay static in your role, you will be replaced. It's the differentiation that sets employees apart. And attaching yourself to functions instead of knowledge is the only way to stay afloat.
Yes, Code Monkey jobs are gone... I can assure you though that there are plenty of hard problems that reduce human suffering which still need humans to solve them.
Do any of us? But I think it's kind of backwards the way it's presented in this article; the raw code part it has down more so than the design sense.
I also would point out that, while this thought has occurred to me about the skills being commoditized, in practice I don't see that everyone's getting the same results from the tools. Not sure what's going on but that's interesting.
Author says Claude now one-shots distributed systems bugs that used to take him two days but most top comments here are still playing down frontier model capabilities.
Are we collectively in denial? It's understandable as the craft as we knew it is being disrupted by tools that have improved at an astonishing pace.
I’m excited about the genAI future. I’m a software engineer interested in product, user experience, architecture, and entrepreneurship. After 4 years in the industry, mostly within fintech, I have gotten tired of slow organizations, company politics, nontechnical managers doing the decisions etc.
I’ve saved up a couple of months of salary, have a couple of bootstrap ideas that I believe are within reach for me equipped with a coding agent to build. Hosting can be done almost for free. What used to take entire teams and hence millions of dollars to build can now be done a lot cheaper. If I’m lucky one of those ideas can pay my bills soon. If not I’ll go back to consulting for a couple of months.
> I still have one pillar standing, though: code quality and software architecture - what's now being reduced to being called "taste".
Genuine question: what exactly is "quality"?
It's something I've been trying to understand for a very long time. It seems like it's entirely contextual, and it has both subjective and objective facets (the latter only for quantifiable things, and still entirely contextual).
Off the top of my head:
If you're using the product, and you want to question or debug what's going on, you can:
* Jump directly to the single relevant part of the frontend responsible
* Likewise with the backend. The layout and naming of the code should scream its purpose.
* Once you're looking at the code, it should be trivial to run it, right now, instantly, in unit test, or cli. You shouldn't need to stand up a database to see whether your code rounds taxes the expected way.
The system contains its own checkability. You can, for instance, just sum up all the incoming money and outgoing money and see if your balance is correct. (It's not enough to have good tests today, if you're working on data that was incorrectly calculated and stored yesterday)
Ah the age old question: what makes something good? I think you’re already describing it well at a high level; context matters, and there are multiple axes to consider. But that’s extremely vague and doesn’t help you identify or measure quality, so it might be worth listing as many specific axes as you can.
Maybe ask the same question about other things. What makes a good guitar? What makes a good chair? What makes a good airplane? What makes a good book? What makes a good song? What makes good art? Each of these has a long list of very specific goals and concerns. And to help define the boundaries, also ask what makes something bad, and what makes something mediocre.
Code quality starts with functionality. Does it perform the stated requirements? Does it have testing in place to catch breaking changes in functional requirements? That’s the basic stuff that probably isn’t part of “taste”. A lot of code quality goals center around how code changes over time, and beliefs about designing to avoid functional breakage.
For example you can ask things like does the code use minimal dependencies? Is the code organized into clean classes/modules/functions that each have a single clear role? Is the API easy to read, understand, and use? Is the API hard to misuse accidentally? Is all the code easy to read? Is there documentation, and is the documentation useful, and more than a list of contents? Is the code self-documenting? Is the code efficient, both in how it executes, and in its use of code itself? Is the code designed so that it won’t fail when someone runs it with different sized types, or a different compiler or execution environment, or on a different architecture? Is the code surprisingly elegant and fun to use?
Those are just the beginning. There are of course more layers of application-specific and environment-specific and audience-specific qualities. The good news is that quality depends on your own goals, you can decide which aspects of taste matter to you, and ignore the ones that don’t. It’s fine if your taste & goals change over time.
Good question indeed, I think quality matters less these days because it's trivial for an LLM to increase code quality.
Quality is usually observed from a human perspective. But in my experience, codebases that humans would judge as "low quality" are actually fine for LLMs. They don't have as much trouble as we do with spaghetti code. They don't have problems with readability or obscure syntax, it's all perfectly fine for them. They don't care about indentation either.
Also it's really easy to increase the quality of the code base. You can just prompt to add unit test coverage and it will. You can prompt the LLM to handle edge cases better and it will (you don't even have to specify which, it helps, but it's optional). If you want to have better separation of concerns, just ask the LLM to have more separation of concerns and you'll have it. Documentation lacking? Just one prompt away. More robust build pipeline? You get the idea.
I still struggle to accept this when my colleagues are producing implementations with AI assistance that are consistently broken and don't do what they think they do. As yet I can't square this circle, no one is better at their job than they were before.
I feel that I am faster and better, sure, but trusting self perception would be an absurd thing to do.
> All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
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.
I’ve found it extremely hard to get LLMs to exit the basin of your current knowledge.
One of my tests for new models is to ask about a concept I already know the mathematical model for, but as if I don’t. So far, they all answer the same way:
1. Convoluted explanations about how it kinda-sorta is common terms.
2. If you follow up with the correct mathematical term, it immediately claims that’s correct and the right way to model it.
3. If you ask it why it didn’t use that term for your question, the LLM gives some version of explaining that it tried to match your language.
I have no choice but to assume the model behaves similarly other times — and that I am largely trapped in a basin of my own ignorance, when using LLMs.
What I tell my team to do is to drop using so many cloud saas apps, and build more themselves using LLMs.
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.
How strange or at least unintuitive. Buying should be cheaper than creating for a customer of 1
Think about the worst enterprise SaaS apps you have used…
you dont need to vibe code shitty apps. you just need to learn how to use apps like codex, claude desktop.
I don’t get it. That’s what I am using.
LLMs mean less devs are needed, not no devs. even after serveral more decades, they'll need steering. I've seen agents stuck chasing one issue, when to me the issue was obvious, but I can see how the model would rule out the obvious easily and move on, but my instinct/experience tells me that's where I need to focus time on. This translates into costly token-waste. Secondly, it isn't simply "quality", the LLM might generate something that's good quality from its perspective, but it simply won't consider things unless it's explicitly told to in excruciating detail, and even then! understanding things from a simian point of view can't be perfected without that simian experience as part of its training. It can come very close but not quite.
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.
Jobs have always been a bad deal, especially for most people. Very unfair. Less unfair is entrepreneurship. LLMs (VLMs) etc. should make that more feasible for a broader range of people.
Realistically, what should we have done instead? Not invent LLMs? What happens when a couple thousand people invent the next disruptive technology and even more of the population loses their jobs?
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.
I don't believe agents care less about architecture than us. Badly architected code has the same effect on them as on us, namely to slow them down and degrade the quality of their output. Which translates to the same thing as well, loss of revenue.
Coding agents are driving up the value of architectural skills to the detriment of more specialized/technical skills.
I think that the domain knowledge still matters: if for nothing else, then at least it can make the communication both with savvy AI tools and savvy humans more effective compared to "outsiders": acquired vocabulary, truly grokked concepts in the field of target expertise etc… -- that all seem like a huge competitive advantage over folks having to learn all that "on the go", constantly struggling to pick the right nomenclature or using wrong or vague terms. It's mostly that domain knowledge what makes experts understand problems faster or at all, even.
I code myself now and have given up on LLMs, no matter what, they eventually make a codebase unmaintainable. The uncertainity of LLM generated code has been screwing up with my peace and guarantee I have when I wrote code myself. LLMs are not AI they are Jack. Jack of all trades, Master of None.
Engineering hasn't gone away, you're now just directing things at a higher level. You are now a architect & manager (but you're managing agents not people).
Who sometimes has to deep dive & mentor a agent on solving the right problem.
AI is beat thought of as an exoskeleton, you'll be at a huge advantage if you learn how to use it properly, and you will, unfortunately fall behind if you don't. I still think we're going to need people who can reason about code, and the amount of code to reason about is exploding in volume. Think of it as doctors having access to better drugs and techniques - they can can cure more illness, but the bar and expectation of what they can do will just raise. And doctors are still well paid, because what they do is important and needs doing well.
Well, not a single 20th-century science fiction novel features programmers; instead, there are platonologists, biologists, and linguists. Humanity is twenty years behind in development because the previous twenty years were spent solely on e-commerce.
Use the LLMs to improve your career as software engineer
>Agents do a really bad job at keeping codebases organized. If you do a disciplined way of development with agents by keeping all Documentation in markdown format, repo structure, Decision records and architecture, they do absolutely organized. Every new module should be documented and the editor configuration and coding patterns can be given as reference. this worked well for me. and it make enhancements, extensions development without any big troubles.
I’m just continuing to get paid as long as I can, while also going back to school part time to train in a role that’s insulated from AI. Having a backup plan at least makes me feel better day to day.
> to train in a role that’s insulated from AI
Would love to know more about that role
>Would love to know more about that role
Anything that can't be done with a screen and internet connection is a good start
I am mostly worried about the current AI use in management. I’ve met a few with ”AI hubris” making poor managerial decisions that stem from their poor usage of ChatGPT (not understanding the importance of context, model sycophancy, etc).
Coding taste and good architecture are the final pillars because AIs are trained on a ton of bad examples that are presented as good examples. That pillar will stand until AIs are able to reconsider and re-evaluate the material they've been trained on.
That should help, but there is a fundamental problem. A conscious entity exercising good judgement can say they don't know a good answer or method for getting one, but an LLM will always compose a response for a given prompt.
The last sentence in the article is correct:
"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.
> 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.
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?
I think that huge deflation will follow for everything except land value.
If automation makes producing food so cheap that it is almost free than it is ridiculously easy to acquire it. Similarly automated construction.
The way I see it the economy will point towards outer space. That’s where most jobs and flow of economy will be.
However most people will have 10x times uplift in purchasing power compared to today so their relative poverty will be ridiculous for us to call it the poverty but they will still think they are poor and troubled.
Generally I don’t think it will be utopia for the people living in that moment but if you look from medieval times at today it looks like utopia for serfs from the past. You however wouldn’t call it an utopia because your standards grew as fast as your purchasing power.
I think that rich and poor will be separated by accessibility to anti age treatment and other bodily improvements.
The tragedy of the poors in the future will be living measly 80 year old life like a today millionaire and that will be considered lower class. Those people with wrinkles we don’t want to look at because of uncomfortable pangs of guilt.
So you believe that your work will be done by AI and you will enjoy life more? This is not a loaded question, just trying to understand what your future ideal day / week would look like as an "ai optimist".
That’s just not economically viable. Even if it becomes viable after some singularity event the path there will be 1000 the upheaval seen during the wipe out of manufacturing and mining
LLMs can synthesize the domain knowledge so long as it's within their training data. At some point, blindly trusting the decisions they make becomes gambling.
There is this over indexing in training data that I find quite problematic.
I have really good results getting LLMs to read documentation and work of these. This is in domains probably sparsely represented in the training data.
I used to be in the "AI will soon do all your thinking for you" camp, but I was overlooking a scenario: sometimes the gap between what you understand and what you're trying to achieve is so wide that no prompt can bridge it. Simply asking "what's the right question to ask?" doesn't feel enough, no matter how advanced LLMs become.
It feels like it's time to start turning the screws on regulation of software engineering.
If productivity is really getting better, regulation can force that productivity to go into increasing software quality.
looks like you just need a bit of harness for your AI: https://leestack.dev/writing/nasa-rules-for-code-that-cant-f...
Even if the model can replace a domain expert on the software side, you still need a human who can decide if the technical solution actually meets the business needs and that would require a human with domain expertise.
This post is sad. Hacker news is turning into /cscareerquestions as someone who's watched this for last 15 years it's going downhill.
Software engineers with low self-esteem who built their entire identity as mechanical cognitive workers are having an identity crisis and spreading FUD.
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.
It doesn't matter to your boss. He will still fire you and replace you with a slop machine. Then you will not be able to get a job again and you will have low self-esteem.
That is limited thinking. People are replacing their bosses, and your boss will be bossing what exactly? Right now LLMs cant' replace the entire spectrum of human intelligence. But if your entire work is just translating your boss ask to for-loops & if-statements, the I guess yes, I would be worried.
If you really think those layoffs are due to AI, then you haven't worked in corporations long enough. If companies are not hiring, and are firing, then what do we need middle managers for? In fact, if an engineer is really smart and masters the tools, what do you need POs, managers, executives, and even sales for? If you stretch things to the max, those who master the tools are positioned to automate everyone aside from the capitalist, as they are protected legally
>You can sit and cry, or you can learn the tools and help shape the future.
What exactly are you helping shape? The volume of your employers bank account?
Chinese Gen Zers are starting companies before graduating, people are generating music and starting their own studios, others are improving models and building harnesses, and the rest are on a mission to automate the entire knowledge economy—from healthcare to governance.
Regarding your employer's bank account: if that is all you were doing before, then that is all you will be doing after. You are just complaining about capitalism now. The irony, is that the means of production is now in the hands of millions. Those who are crying are those who paid their mortgages with for loops..well, I think they will continue doing so, with less hubris that's all. LLMs are nowhere near replacing full engineer.
So get a grip fellow engineers.
>Chinese Gen Zers are starting companies before graduating, people are generating music and starting their own studios
Both of these have been happening before the advent of LLMs
>The irony, is that the means of production is now in the hands of millions
The "means of production" means jack shit unless you have the capital to scale up rapidly
>Those who are crying are those who paid their mortgages with for loops..well, I think they will continue doing so, with less hubris that's all.
Why is it hubris to give a damn about you spend 40 hours a week doing, or to lament change when it works against your enjoyment of those 40 hours a week. God forbid people value their time in any way that isn't monetary.
> Both of these have been happening before the advent of LLMs
I'm not sure about that. I read they are making better use of AI to accelerate building their businesses. Apparently, in China, people were not looking to work in corporations anyway, so they saw AI as a means to escape them.
> The "means of production" means jack shit unless you have the capital to scale up rapidly
There are people topping music charts without even having a brand; they just produce good music. There are people automating entire marketing pipelines to minimize capital expenditure, and there are people building niches for small crowds and making a good living out of it. Not everything needs scaling.
> Why is it hubris to give a damn about you spend 40 hours a week doing, or to lament change when it works against your enjoyment of those 40 hours a week. God forbid people value their time in any way that isn't monetary.
If you enjoy writing loops and if/else statements, you can still do it, but the market won't pay you when there is a tool that does it faster. That is the nature of the domain. Have you ever thought about the jobs that software engineers automated? What do you think those people did? They adapted, learned the tools, and moved on. This is the first time we are seeing automation at this scale in software engineering, and the reaction of software engineers is exactly the same as those in other fields.
Adapt.
Regarding hubris, I've been in this field for 20 years, and there are people in it who are just intolerable, frankly. They memorize every Vim command, refuse to use any other tools, and treat everyone else as less intelligent simply because they can write code... those people are getting humbled hard right now.
What work remains valuable when implementation becomes cheap? How about moving closer to ownership?
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.
Businesses like a record of reliability, so devs going solo with AI is going to be a hard sell. I think we will know that AI is actually good enough when these AI providers start absorbing project management companies and hiring contractors to use their product instead of selling subscriptions.
I am also feeling anxious. I lucked out by having natural inclination towards software development, career which can provide good upper middle class life to anyone. But I feel like writing is on the wall. If I don’t find a way to pivot to something else, I might experience class migration, but in the opposite direction this time.
It’s a good time to save and move out to a cheaper country to buy money generating assets here. It’s not easy but if you have at least one million dollars in investment money, it’s arguably wiser than staying in US that penalises such passive lifestyle heavily. Sooner or later some medical bill will leave you bankrupt. Unlike in EU.
It's not just our careers. In the hunks versus nerds wars, it is now clear who has won. The nerds have made themselves obsolete and put the continued evolution of homo sapiens to an abrupt halt.
No software developers == no humans?
No, homo sapiens degenerating into homo stupidus.
I wonder how do people use LLMs so it does not hallucinates. Like 90% of the time the code is impeccable, but the remaining 10%... Let's say I determine the expertise by how well do people act of these 10%. For me, the first pillar is still there, but not in a good condition
Easy just add "Make no mistakes" to the proompt, clear skill issue.
In reality people who use LLMs so it does not hallucinate are the ones that just have to little knowledge to actually see when it does, because LLMs do and they always will. That is the only thing you can get with a stochastic word predictor.
The market still seems to be hot for roles that provide leverage like platform engineers and Staff+ engineers
The company is hiring; the author mentioned they are talented and unemployed for the past 8 months. Why not remind the company to re-hire them?
This reads like a self thought ecommerce/small company employee finding its place in the tech world. These people were erased first, understandably. I am meeting more and more of the same type of people.
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.
"Except that nobody cares anymore." Noone (from mid-management) cared about it also before. You hit the deadline, get promoted and leave the technical debt to the next one. Even if you're the one to deal with it, you set up the next project, get the budget, prioritize the issues etc. Not much changed in this regard with LLMs
> And we all know the demand is drying up.
I don’t think the data really supports this? Last I checked at least.
This person was hired, from the beginning, to be a meat shield. To be responsible for decisions they won't be allowed to make.
I like the term "human crumple zone"
Agents may have made 80% of your experience go to $0, but the other 20% is exponentially more valuable now. This outweighs your other losses.
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.
Software engineers are fungible commodities, in the wake of the LLM.
Reads like “AI is inevitable” propaganda to me
It's not just about it taking the technical competence away from our job, it's taken away the joy [1] which I wrote about.
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 don't know how else to say this but LLMs are just word calculators. They are becoming better for sure but at this point even Claude 4.8 is absolute shit at any complex task in a not so common field. I have been working on terrain contour matching algorithms for the last few days and, oh boy are the predictions about AI taking over the world wrong. Its the highest level of bullshit I have ever come across in my life. I ended up writing 100% of the actual algorithm myself. It's a productivity mess.
> "terrain contour matching algorithms"
That's an extremely niche specialty though. 99% of software development jobs are web frontend/backend or mobile/desktop apps and they are more at risk from LLMs.
I read all the posts in this thread - but no one has a good idea to avoid software developer obsolescence. My guess is this profession has 5 more years. It was a good run while it lasted.
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.
Ok so it’s five years now? I’ve heard for the last three years that software developers will be out of job within the next 6-18 months. I’m glad to hear I’ll have a job for a little bit longer.
5 more years? That’s quite pessimistic, given how much evidence we have that LLM coding has as much of a long tail problem as any other tech we’ve created.
Which other profession has the same amount of training data freely available for the taking?
Don't need much training data for bank/insurance/retail analyst work - it's just basic reasoning and data retrieval. If AI could crack the programming nut - one of the most intellectually challenging professions - it can handle the rest with ease. The only human role will be high level monitoring - and even this will be largely automated so fewer will be required.
Sorry to reply to myself but I just recalled the recent Apple ad that ran last year about a corporate goofball who got his Apple device to fire off well crafted email slop to his manager who looked surprised/impressed. That trick will only last for a short time. The joke is that people like him and his manager will be the first to be fired.
The direction I'm given is to take humans out of the loop. As much as possible. Everything AI. Automate everything. If you are in the loop you are overhead.
this is the exact WRONG approach. AI is a power tool not a fucking human replacement.
Though I doubt I'm telling you anything YOU didnt know...
Like I said, this is the direction I'm given. :|
> I'm just another off-the-shelf engineer now
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?
I think this experience is universal. The answer is the same as always has been - develop skills that are becoming most important. Right now that is (at least from what I can see): - Data analysis, data pipelines, models, etc. - Tacit business knowledge - architecture and design patterns (always has been, but now the scale os larger so this is even more important)
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 .
One other thing I find it is bound to happen is that this domain knowledge you speak of is just going to shift towards LLM domain knowledge.
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.
Hear me out: what about just refusing to use them?
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.
My boss came up to me and said a coworker using LLM tools has shipped more customer solutions in a week than basically what I've done in 3 months.
The bosses are out to force people like you to use AI. And have been for months.
Maybe not your boss yet, but it swept through my office dramatically. Maybe two or three months from limited tests to now today FORCED usage of AI (people going around the office asking constantly if there's any AI that can help today).
----------
This has a few toxic effects.
1. You are not allowed to complain about code quality issues anymore. Any complaints are met with okay, we will get the AI to fix it.
No discussion, no elaboration. No one in the office is even interested anymore. AI solves everything.
2. You are basically in a position where you are forced to use AI, whether you want it or not.
3. I expect code quality at my office to drop dramatically as fewer and fewer office mates give a shit
The title should be: LLMs are changing my software engineering career and I know what I should do
This is good. We want less barrier to entry and more competition in software.
The reason that I’m looking for an out is that it’s turned everyone I work with into imbeciles.
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 am kind of like of in the same place though roughly 5 years more than author.
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".
While LLM's are beyond junior level at this point, they're still just that. I don't really agree that the first two pillars have been affected.
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.
Advertisement piece for the IPOs. We get this multiple times daily to pump the stocks and demoralize programmers.
find another job but software engineering :) simple
LLMs are good at general solutions but not specific solutions. As industries evolve and laws, regulations, and practices change LLMs will struggle because those things are not included in its training set yet. We'll always need humans to push companies in new directions in order to compete, unless we eradicate capitalism altogether and then we're all out of luck. No competition means no incentive to try and be better than the next guy which means no new products and services for humans to develop that AI hasn't seen already.
LLM is a powerful tool but it still doesn’t have the context that a person would have. A million tokens is a drop in the bucket compared to the overall context that the person guiding the LLM needs to keep it on track and being productive.
If 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.
“even though you're delivering code at a good pace, you're taking too long to deliver those Design Docs. Are you using AI? You should use more AI.”
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.
I'm thinking about taking a plumbing course.
> when I step outside my area of deep knowledge I can no longer call BS on the agents
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.
That’s why I use AI more like: Write a tool for me that does this.
Instead of directly: do this.
Preferably I would interweave code and AI queries where some function waits on prompt result too I think?? To avoid too big context hallucinations
I mean that would work for my use cases.
At least what I learned is that the less AI itself does in the context is the better so to say as critical LLM mistakes are approaching 100% of probability over time.
The crazy thing is how many people who can write code (with or without uAI) are in fact using the LLMs in the latter "go do this" mode.
There are a lot of non-tech people using these products in this manner.
Along these lines my friend is CTO at a non-tech firm and theres vibe coding happening in one department on a project that is going to churn $1M of tokens. Head of that department told him it's OK because instead of paying a SWE annual salary, they'll just pay $1M of tokens once forever.
People don't know what they don't know about software, SDLC, support, maintenance, etc. If code was something you write once and never think about again, most tech orgs could be 75% smaller.
Code quality and architecture still matter, because they also make it easier for LLMs to reason about the system.
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.
Regarding code quality, the largest issue I've run into is pollution that stems from committing too much unfiltered LLM code. They introduce some type of structures into the codebase that are hard to read for a human, then start reusing them or use them as example to create new ones, then when a human needs to quickly hop in and make changes, it's not as easy to do.
Running a couple of "scan for potential refactors"/"any duplicated code" prompt threads is already a long way there.
> Of course, I'm still employable because someone has to review the code and steer the robot. But I'm just another off-the-shelf engineer now. I have no domain expertise that another Sr. engineer steering an LLM cannot match. All my finance and payment domain expertise, all the debugging intuition and distributed system knowledge earned through hours of sweat and tears, is now promptable.
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.
I started feeling like a factory worker well before LLMs. My reputation and network stopped mattering and it all came down to take this assessment and do this Leetcode to prove you are a good enough replaceable cog. I have about 15 more years before retirement and I doubt there is anything left to look forward to in my career.
Shoemakers and horseback messengers complaining while Nike and FedEx deliver a million shoes or packages per day
We won't miss them
This anonymous article is likely more FUD from the AI industry. "Just give up,you can't beat the machine. Please go quietly, we want to take your place and it's easier for everybody if you don't resist because you believe it's pointless"
'Maybe I should consider woodworking' - Fuck off.
resistance is futile
It's futile to race against the money hungry capitalistic machine, but it's not futile to steer your own career into work that's more lucrative or is more enjoyable, be it with our without AI tools.
don't worry, soon there will be no "software engineering" careers anymore.
My job as a staff engineer has turned into just reviewing slop farm vomit from offshore devs in Pakistan making pennies on the dollar given a slop code subscription and going wild.
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.
I will be happy if Claude lets me eliminate my offshore Genpact team. I don’t need slop from slop.
I’m the one that needs to support it in production and fix the bugs anyway. Offshore is pointless.
I've wondered about this a lot. I am brand new to software engineering, fully powered by AI coding. Traditional software engineers have to pivot hard or the are going to be left in the dust. The slow, methodical, take two days to put a change on a production site approach are over. I'm shipping exponentially faster than a co-worker who hasn't embraced AI yet.
As someone who's not a programmer, how did you discover HN?
So blog with single post hyping LLMs. Oh and the domain name "human-in-the-loop". Call me suspicious.
If the majority of the people have selected a direction you either opt in or opt out.
That's the hard truth.
Governments do dot care on our future, only on who pays them. This is the tragedy.
I think the author missed the forest for the trees - the domain knowledge is what allowed him to successfully use the AI because he instantly knew what was correct or not.
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.
If corporations really thought LLMs were a great cost-savings tool, then the obvious target for replacement are not the lower-paid staff, but the higher-paid staff - the ‘product managers and stakeholders’. That justifies token burn, replacing the 7- and 8-figure people, right?
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?
The idea is to start with the largest, easiest lever. The one which will accelerate all _other_ automation. That lever is software development itself.
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.
I agree, we are still waiting to see the billion dollar valuation startup that fully vibe-coded their product
Am I the only one that has noticed the massive increase in buggy software across almost every domain? Like, EVERYTHING has so many more bugs now. Things just break constantly. AI isn’t one shotting fixing bugs, it’s one shotting making hundreds of new ones every time it writes anything.
I have no idea what you guys are up to, but it is just a job, it is just a role, it says nothing about you or who you are and it is not tied to your meaning. If you make it so and your perception is aligned with that, then you are not in control of what happens to you. What kind of slavery it is to give other people so much control over you is crazy
Just want to point out that code quality and architecture is actually eroded by codes 5.5. It’s over for this job I think.
The glory days are over. In the future, one software engineer will be able to support multiple product areas much like how one HR team can support 1,000's of employees.
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.
This has been said millions of times but yet you felt the need to say this again. maybe our jobs are safe :)
> The glory days are over. In the future, one software engineer will be able to support multiple product areas much like how one HR team can support 1,000's of employees.
I mean, it seems within the realm of possibility that much more productive software engineers make more and not less money.
move yourself to regenerative ag. take a look.
I think we are all vulnerable and need to reassess what it is we bring.
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.
Isn't the solution to learn business skills?
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.
> 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.
Sales are going to be drowned by AI soon enough. The low end is already getting yeeted by webshops, dropshippers and AI powered bots and a lot of B2C and B2B sales are shifting off of the classic representative sales model as well (towards self-service) because everyone that does not is cheaper. Basically if I have the choice between a SaaS that says "contact for a quote" and "X users => Y $/month", I'll always go with the latter option. And on top of that comes offshoring, that has gotten surprisingly good with ever increasing voice call quality.
Think of it like this
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?
I can't write what I really think because my name is attached to my account.
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.
I'm not worried. You cannot hold a machine accountable and there's no way OpenAI, Anthropic, etc. are going to take on that kind of liability if some code resulted in a major outage or a lawsuit. Perhaps that's the signal I'd be looking for: so much confidence in the product that they put their money where their mouth is.
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? ;)
0: https://www.0xsid.com/blog/meta-account-takeover-fiasco
> You cannot hold a machine accountable
Well... accountability is a myth, primarily used to justify obscene paychecks for executives aka "you can't get fired for buying IBM". Basically, as long as you follow what everyone else is doing at the time, even catastrophic losses won't result in consequences. Just look at the recent AWS outages and issues - if you're a CTO and you'd have your webshop running on-prem, you'd get axed for a multi hour downtime. But since your webshop runs on AWS, you're following "industry best practice".
So instead of a programmer, you become a software designer. I recently came across the idea of building fantasy for the player (in context of games), but now that I think more about it. Onlyfans, is just that. Advertising, Beauty products, novels, games, TV shows, and so on. You're really just creating / selling a fantasy for vast majority of people. Most people will never lose that 30 lbs, but you can sell them all kinds of products to fuel the fantasy of them losing that weight, being beautiful, rich, healthy and so on. So an LLM replacing the need for you to write every piece of code, is actually kind of freeing. You as a a former programmer, should embrace your new creative role. Writing code, at least for me was always slow and tedious. I just want to be able to express the ideas I have, so LLMs just make it possible to build things I never could otherwise.
Maybe just maybe here in HN we are in an echo chamber that is convincing us that there is a theoretical limit to how far the LLMs can make progress. It’s not unthinkable that LLMs will make better overall architectural decisions or follow the good practices better or understand the problem in bigger picture (more access to company/product context already makes a huge difference)
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.
> But now the market is shaping everyone into becoming a generalist.
This is interesting because in my field of VC everyone says generalists are dying.
The issue is that the people evaluating you don't know the difference between legit domain expertise and pure bullshit.
computers are made for automation. programmers were always working on automating things, making other things obsolete, and we have been killing jobs for decades. did you really think we would suddenly stop when it's your job? i'm happy this is happening, genuinely giddy
But this raises the barrier to entry into programming if LLMs are capable of doing the vast majority of junior/mid level tasks. This can ruin the lives of many average people for whom programming was one of the few truly possible jobs. I have a friend whose initial interests are not related to IT and he is not particularly passionate about programming, but it still brought him a decent income (unlike the profession he was passionate about). This is the people I'm talking about, they need some fucking stable job that brings income.
These are the last days of software. Use the AI's and build cool shit NOW.
Yes this has been my experience as well.
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
People are missing the long-term horizon on this. Yes, definitely, you can automate most of your workflows as a software engineer with today's LLM frontier capabilities fully E2E. But many things are still super open: -First, cost is not a settled topic yet. We have no indication that automating everything E2E will be a cost-effective way of doing stuff. So the bare minimum is that you will need some expert designing the workflows in a token-efficient way. Worst-case scenario, tokens become super expensive and only certain parts of the job can be efficiently automated and many companies are not even able to afford tokens. -Second, the system you just "created" is just a static snapshot of today. Yeah it may work fully automated for 6 months, maybe a year. What then? Breaking changes? Updates? Re-designs? What if the quality slowly degrades until nothing ever works again? Who will fix that? There are so many unknowns that it is borderline irresponsible to make guesses on what can be automated sustainably long-term or not. Unless you are OpenAI's Codex team wasting a billion tokens a day on automating and self-improving everything, there is a high chance that everything you set up today is completely useless in a year. -Third, the core engineering workflow hasn't changed a single bit. People like stakeholders, product owners, PMs, etc. can come up with ideas and things to build but someone needs to take decisions on what gets built and what doesn't, balance out paying down technical debt vs. feature development, incorporate new domain knowledge into the system (Or would you expect your PM to be tweaking the prompts about a new regulation regarding GDPR or a completely new legal framework that changes the whole thing?) -Fourth, probably the most important one. If you think AI will soon get good enough to get self-improving and self-sustaining enough to replace full engineering departments E2E with no supervision then nothing else matters because we will all end up without a job and living on UBI (not only tech people). So why do you even care? If it happens it doesn't matter, and if it doesn't happen we just continue doing what we were doing until now. Why do you care?
"Except that nobody cares anymore."
:-(
> Maybe I should consider transforming my woodworking hobby into a profession...
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.
> And then I started realizing: all the knowledge I have accumulated over the years: the trade-offs between implementations, how acquiring works, how to structure idempotency to prevent double-charges, everything, was becoming useless.
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
This was a good summary. I feel similar. At this point I think 95% of the skills I've developed over the 2 decades are basically useless. Prior to 2023 I felt like every new skill only made me more employable, but now I don't really see any software skills that are safe from AI today. Even the ones that are very likely won't be in a year or two so there's no point in learning.
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.
Well, are they? I think two things are at work:
1) How long has full self driving been just six months away? The last mile often tends out to be the hard part.
2) If the catastrophic scenario comes true where white collar work essentially disappears, what does "preparing" actually mean? There's not a whole lot I can do about that. It's like trying to make plans for what I'm going to do if I get into a coma.
The fact the whole world is going down with me is of some help actually. I can't stop the world. There is no preparing for that. We'll figure something out and if not, then not.
My non-tech friends will not suddenly be able to run servers or oversee AI systems. They will come to me with their ideas and I will turn the crank. My role will probably be named differently, something like "Intent Manager" or "Architecture Developer" or whatever but I have a strong feeling much of it will basically remain the same. The politics, the egos, the personality differences, AI has changed nothing in that regard. The jocks will not suddenly sit in front of laptops prompting Claude to debug their MQTT setups. You can say AI will do that and sure it will, prompted by me. If AI will do it autonomously then we're all fucked and I don't care about my "career" by that point. It'll be survival of the species time.
Much of accounting could have been automated. A good friend of mine has been manually entering paper receipts and whatever for well over 20 years now and his work load has actually increased. It's all automatable, but there are so. much. more. levers. Possible != will happen.
I do agree it's not the time to empty your savings account. Get ready for some rough times.
There is an element of human nature that is known as self delusion and it is extremely common. Almost everyone on HN is suffering from a form of self delusion.
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.
At the risk of being voted down for stating an unpopular opinion, the problem is that faith is neither provably true nor provably false. That's what makes it faith, not science.
Even though you clearly believe very strongly that religion is wrong, that's not a scientific viewpoint because science doesn't and cannot disprove the fundamentals of religion. Taking it further, you can't actually prove anything is true with science, because fundamentally it is about making hypotheses and attempting to disprove them, and those that remain and can't be disproved you accept as "scientific truth". But many "laws of science", we have already disproved but we still use them as approximations because they are useful.
One final thought is that people frequently have conflicting internal world views. Some people cannot tolerate that, and require a consistent set of rules that govern their idea of the world, but the majority of people are comfortable with some degree of ambiguity in that. In general, the more rigid and coherent your worldview, the less likely you are to accept that it might be wrong, which is why many scientists devote their efforts to disproving other ideas they disagree with, rather than trying to disprove the things they believe themselves.
I don't see it as negatively, in that there are specific trade-offs.
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.
OK, but that same argument applied to getting on one of like four cloud providers and essentially everyone did that.
I secretly wish LLMs take my job away because I'll get about two years of unprogrammed rest, which I absolutely will not take of my own accord. But it's unlikely to happen.