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.
> he people I found worst at this were IT.
My experience as IT in modern banks was the opposite. The legal department were absolute assholes when it came to software features. And I'm talking absolutely 100% ok features, like paying your bills from the banking application.
The least fun, trigger happy, cover their buts people I've ever seen.
Like all they could ever say was NO. I guess they were heavily incentivized to just say NO to everything.
I once worked on a data compliance job, and the auditor would fail everything he possibly could. He was there for data destruction compliance, but like many such people, he came from an engineering background. He would complain about everything. Gaps between pallets. OHS. Whatever he could to justify his decisions. He never found a bit on a disk out of place and he still made our lives hell. Failure for the floor didnt feel solid enough. Failure because he didnt feel comfortable in a warehouse environment. And when the management had had enough and decided to refuse him entry and ask for someone else, we had to hold ourselves to an even higher standard to compensate.
Later I worked in a role, attempting to achieve PCI compliance. The Auditor was a really nice guy, but there was always a short list of 10 things that he wasn't quite happy with. We kept increasing the scope of compliance to keep up with him. Everyone talked about him (Semi famous local celebrity security consultant/researcher/lecturer) and claimed that if we just stuck it out we would be super duper compliant and basically unassailable. Except that it never ended. Went 12 months with the guy. Then they just stopped paying his bills and brought in another auditing firm. Compliant immediately. You never know in a situation like that whether we were actually compliant or if there was graft. But we got there. Knowing that organisation I lean towards graft. They then failed their first audit after achieving compliance.
I have done a few PCI compliance operations since. And what I have found that you cant control for the auditor, so what good IT management does, is make every single requirement completely unassailable. If you cant write a very obvious compensating control in 5 sentences, then you just move heaven and earth to comply with the letter of the requirement (even if the project to become compliant, is itself a compensating control for a while). If you get an over achieving auditor, you wont spend 200 billable hours arguing about compensating controls. If you have a shit auditor, you know you are compliant even if they aren't being as thorough as they could possibly be. Its the only ethical way to navigate the situation.
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.
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.
"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.
> 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.
Do they? I saw some crazy stat from the guy who built claude code that he was pushing hundreds of PRs a day. There's no way you can human review that much code. It's probably closer to heavily AI assisted review and planning.
I don't know if I agree that's the only sane workflow; the problem is, I am way less invested doing code reviews of agents than I am reviewing code by human colleagues.
I would love to be able to say I pay the same amount of attention and am just as diligent and communicate as clearly with an agent, but it wouldn't be honest: I scan agent PRs for obvious mistakes or misinterpretation of what they've implemented.
With human colleagues I usually know them and their style, their way of working, so have a better idea what to look for. You also have a genuine return on providing feedback that helps coworkers learn and improve, whereas with agents, all the feedback you write is gone when the thing gets merged (unless your org has some kind of shared memory for its agents).
I don't have the answer for what the future looks like, but I suspect agent-type-1 reviews agent-type-2 is actually where we'll end up.
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.
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.
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.
> 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 '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).
I love it! And posts on HN about Big Ideas and uses corpspeak to justify driving people to long hours. The engineer who's picked up talking points of his employer because he's well-paid and trapped on the spectrum, making it hard to comprehend a life of Play outside of work.
For the most part there arenât 10x engineers
But there are certainly 0.1x engineers
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.
> 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.
> 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.
Perhaps that's true of the top 5% engineers. But the question is if the top 40% of engineers can replace the bottom 60%.
The LLMs don't need to be perfect, they just need to be good enough so that the cost of fixing their code is lower than the communication overhead and the 'lost in translation' overhead from delegating tasks to mediocre engineers.
> 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". The two are related, but they are separate. Coding is a very small part of the average engineer's job (and almost none at staff level and above).
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".
I disagree with most of this. I'm kicking and screaming pretty hard, and yet I'm not one of the "I can do it better" folks. My whole career has been in open source. I'm all about choosing the right tool. I'm also tech lead on a team of seven, so I'm not writing a lot of code anyway. What I am doing all day is sending AI-generated code back to be rewritten, rethought, re-architected. I'm starting to think we would get more done if nobody on my team used Copilot.
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
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.
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.
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.
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.
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
I work in a large, established fintech and we're in no rush to shove LLMs everywhere. We have access to all the AI tooling we'd ever need with basically no limits, but AI or not, you're responsible for what you ship, so most people are less YOLO about the whole thing. From the quarterly surveys, most people in the co view it as a slight productivity boost but nothing dramatic, and most features we're releasing are still human reviewed anyways.
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.
I see many comments saying, "AI can't do X with 80-100% accuracy; therefore our professions are in good hands."
While I don't want to sound overly pessimistic, the models are improving at a rapid rate. If asked ~3 years ago where the state of the models are today, it would sound like sci-fi if answered, "the models are creating full MVP apps in ~30 minutes with one prompt".
The hurdles the models are facing now, like reducing hallucination rates, ensuring compliance, and keeping a clean codebase, do not seem far away from being resolved IMO. Fetching specific information is already partially done with various MCP servers / RAG.
I am, of course, a bit worried about the future of software engineers. If these quirks are resolved, where do their professions fit in the industry? Delegating tasks to the AI model? Unfortunately, this does not require years of expertise, which is a double-edged sword. Reviewing AI's output? Ask it to explain each line not understood.
I think we will see more waves of larger layoffs, similar to how human computers were replaced by digital computers. To some, doing complex mathematical calculations mentally is a fun task / challenge, but it is ultimately significantly slower and more error-prone than calculating with a computer. In the same way, I think hand-crafting code will be seen as a fun "challenge" and AI will be seen as the "modern-day calculator".
> the models are improving at a rapid rate. If asked ~3 years ago where the state of the models are today, it would sound like sci-fi
Absolutely true, many things will continue to improve in significant ways. However, if we look at the modern history of rapid disruptions driven by technology (a side interest of mine), persistent patterns emerge. Similar to avalanches or flash floods, such periods of very rapid disruption are often triggered by one or more significant breakthroughs in certain technologies. Early rates of change tend to be fast and furious but eventually begin to taper as recently unlocked low-hanging fruit is harvested and those racing through newly found terrain encounter all-new significant barriers and points of friction. Early in such periods, extrapolating the recent extraordinary rates of change forward has poor predictive power. Sudden extreme bursts tend to regress back toward the long-term trend line.
Arguably, the current disruption in LLMs can be traced to post ~2010 research slowly building to the 2017 transformer paper and the adjacent work it quickly inspired. So today is, arguably, mid or late-ish in the LLM rapid burst phase. The rate of fundamental, broad-based breakthroughs lifting all LLM applications has clearly slowed with many of the most impactful recent discoveries being in scaling, optimization, tuning and productization toward specific domains. That doesn't mean there can't be another transformer breakthrough tomorrow but, historically, black swans rarely travel in flocks.
> The rate of fundamental, broad-based breakthroughs lifting all LLM applications has clearly slowed with many of the most impactful recent discoveries being in scaling, optimization, tuning and productization toward specific domains.
To me it definitely feels like it's still accelerating, with the most impactful recent discovery being RL training reasoning models (late '24, early '25).
There's an interesting article called "sigmoids won't save you" https://www.astralcodexten.com/p/the-sigmoids-wont-save-you which argues that (unless you have privileged information) you should always assume a process will continue about as long as itâs continued already. (Lindy's Law)
With that in mind the current disruption should last another 10-15 years (assuming it started in '10 or '17.)
This is of course true in general. But the question is not "how with this evolve" but how will we deal with the rapid changes in the industry? I suspect a long term k-shape salary curve, even worse than today, with the lower 80-90pctile salaries bottoming out such that many have to exit the industry to make ends meet. You can laugh and blame them for not saving as much as they should, but that's still a fairly horrifying prospect for most of us.
I think a _lot_ about stock trading a profession vs algorithmic trading. It was brutal - suicides, many pivoting out to doing car dealership-style work. Probably a 1/10 or 1/20 survivor rate every couple years, with almost all of it a very painful five year period.
I would ask for references for the suicide claims, so others can assess the impact themselves. That's a very serious claim to provide without any proof, especially to a group of people who very well be going through the same thing. I am not saying it did not happen, only it's the right thing to do.
And it was the dumbest and least valuable stock traders that exited the industry. The industry is alive and well today.
Progress happens in a series of S-curves. While your observation is correct that advances occur initially rapidly then taper off, the next step tends to arrive sooner than the previous, and with greater magnitude [1]. Tim Urban's article from 2015 has a great explanation of this phenomenon [2].
[1]: https://ourworldindata.org/technology-long-run
[2]: https://waitbutwhy.com/2015/01/artificial-intelligence-revol...
> The rate of fundamental, broad-based breakthroughs lifting all LLM applications has clearly slowed with many of the most impactful recent discoveries being in scaling, optimization, tuning and productization toward specific domains.
What this means is that the disruption across industries not even truly begun, because it's not the generic chatbot models that are going to kill labor, it's all the domain-specific applications that leverage those models to perform work that was performed by humans
Why would it stop with just developer layoffs? When software companies rely on LLM providers to run their business, Iâd argue weâll see a massive bust of these companies around the world - from on-prem products to SaaS.
Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.
> Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.
Already happening. I know of a few places that have gotten such large gains from LLMs that they know have their engineers working on creating homegrown ports of popular services (Docker etc.).
It seems to me that Docker should be far, far down the list on services to recreate in-house with AI.
Why would you create a homegrown port of Docker? Docker the container software, or Dockerhub the image repository? This is just confusing. If you didn't want to use Docker there is a perfectly good well tested alternative called Podman with wide adoption.
Not sure about Docker (lol) but stakeholders are definitely more open to "building your own" now. It used to be that to be agile as a business you would seek out already built software and rent it, as it typically was cheaper than building and maintaining your own (I say typically due to stuff like vendor lock-in and such). But these days, and especially in 2026 with the widespread use of agents and harnesses, that formula has started to change. Even though the SOTA models are really good now, it's the harness and the "fluff" around the model that makes it a game changer. The developer is no longer the one writing or even gluing the code together, the harness does that. Pair that with context preserving mechanisms and tools that emerged (automatic context compaction, AGENTS, TOOLS, MCP...) and you can get to a state where you start a new thread in Codex and it knows your systems, your dbs, can smartly explore code it doesn't know and db data patterns etc., it can explain stuff to a new developer (and be correct most of the time and have time to spend on the developer)... all of which SIGNIFICANTLY reduces the risk you take on yourself as a company when you "build your own". What's $10k/year to any half-working semi-profitable company? Nothing. But in 2026, you can build and maintain A TON of software for that, much more than your "average IT needs" company may ever use.
I'm sure the very large (and very small) businesses will keep their absolute need for (or the lack of) inhouse developers, but everything in between will probably get compressed to one or two inhouse architects in direct contact with the stakeholders and the rest will be contractors working with Codex-like automation.
Homegrown ports of calendly or jira seem feasible, and arguably a good business decision. Homegrown versions of docker seem ridiculous as a starting point, even if its possible to do today there is much lower hanging fruit to go after first.
This won't happen in most cases because the valuable thing is largely the knowledge encoded in the software, which the buyers of the software don't have and don't want to have since they're focused on their own business.
There's also, of course, the not insignificant value in the software itself actually working, being operated, being updated when necessary, all of that. Again just extra hassle no business will want to shoulder when they can just buy something that does it for them.
agreed. Also, data security, data compliance, legal, customer support, operations... Yeah, SaaS is not going anywhere soon.
Why would I build my own CRM instead of paying 50k a year or whatever? The engineer plus tokens for maintenance will cost you way more than 50k.
These people are delusional and just repeating delusional vibe coder tweets.
Nothing corroborated this. Performance on benchmarks has practically leveled off. The big gains have come from architecture (have a secondary LLM review output) or searching the internet. Also prices are going up. Everything points to the likelihood that we're at the top of the curve.
> Nothing corroborated this. Performance on benchmarks has practically leveled off.
[There is plenty of data to support the claim that AI continues to improve, even exponentially.](https://epoch.ai/trends)
As for benchmarks I feel compelled to remind you that as soon as a metric becomes a goal, it ceases to be a useful metric. The models optimise for solving the benchmark and we create new benchmarks to assess broader intelligence. As models converge on 100%, progress obviously slows. That doesn't mean intelligence isn't improving fast. It just means that that benchmark is being well served and we need other benchmarks to assess other forms of intelligence.
I would like to take your bet that we're near the top of the curve. I take the side of Geoffrey Hinton, the Nobel Prize laureate scientist known for his work on artificial neural networks. He believes AI is getting better even faster than he predicted. He estimates that every seven months AI becomes able to handle tasks twice as long.
> [There is plenty of data to support the claim that AI continues to improve, even exponentially.](https://epoch.ai/trends)
This doesn't look at all exponential to me: https://epoch.ai/benchmarks?view=graph&tab=eci. OpenAI models went from 137 ECI to 159 ECI over about a year and a half, and the trends are similar for Anthropic and Google. These things have never been exponential.
> The models optimise for solving the benchmark and we create new benchmarks to assess broader intelligence. As models converge on 100%, progress obviously slows.
We are nowhere near 100% on important benchmarks like hallucinations: https://artificialanalysis.ai/evaluations/omniscience?model-...
...also, progress isn't improving with model releases.
---
We're running out of money. While we don't know how much it cost to train things like Claude, most (all?) industry reports indicate that a significant gain in function (2x) would require an exponential amount of resources (20x). No one's yet been able to convince investors that's worth it.
Also, we're running out of data: https://epoch.ai/publications/will-we-run-out-of-data-limits....
Also, we're running out of of low hanging fruit: "We find that the level of compute needed to achieve a given level of performance has halved roughly every 8 months, with a 95% confidence interval of 5 to 14 months. This represents extremely rapid progress, outpacing algorithmic progress in many other fields of computing and the 2-year doubling time of Mooreâs Law that characterizes improvements in computing hardware (see Figure 2)." (https://epoch.ai/publications/algorithmic-progress-in-langua...). Maybe you think we'll continue along this breakneck pace, but again no investor thinks that, which is why prices are going up (investment is drying up).
Also we're running out of compute. Data center projects are stalling. Some of this is spiking energy prices, some of this is politics, much of this is grid constraints and supply chain problems: https://tech-insider.org/us-ai-data-center-delays-cancellati....
---
Finally, and perhaps worst of all, despite unprecedented investment data on the productivity gains is mixed. This is the biggest difference from other technological leaps like electricity, the industrial revolution, literally fire, etc. Those things were immediately, undeniably more productive. AI is not like that. You're not seeing an AI Microsoft, an AI Salesforce, an AI Oracle, an AI SAP, etc. You can argue that their advantages are structural, but there are no successful AI-powered alternative products (no AI Office, no AI ERP, no AI database, etc).
> Performance on benchmarks has practically leveled off
Ehm, no? DeepSWE[1] for example shows that new models like gpt-5.5 continue to show big improvements compared to older models.
> Also prices are going up.
Prices for frontier intelligence have gone up, but prices for the same level of intelligence have gone way down (what you can get for pennies now was SOTA just a couple of years ago). The pareto frontier is still expanding.
Most benchmarks can be trained for as well, so they are over-representative of model's engineering skills. The entire nature of a benchmark is collapsing some qualitative work (software engineering task, architecture choice, code quality) into a quantitative score which can be optimized for.
That's what the AI comapnies would like, but they can't pay back the 100's of billions they are blowing without 10,000x the price they charge. The investors won't allow it. we're not even in a revenue cycle yet and they are already trying to dump their deep losses on retail by trying to IPO
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.
How many of us here are building something genuinely new, though?
Hopefully everyone? Else your job could have been outsourced or replaced by a junior with access to Google and StackOverflow way before LLMs (it just wasnât due to zero interest rates and proliferation of bullshit jobs in tech companies).
Sure. But where do you think AI will be in a year? Or do you think that AI is just an advanced Markov chain? Like âAI will never be able to write code. Ok AI will never be able to debug code. ok ai will never be able to write design docs. Ok AI will never be able to architecture. Ok ai will never be able to do distributed systems architecture. Ok ai will never be able to design new products completely from scratch. Ok AI will never be able to run a company. Ok AI will never be able to run a city. Ok AI will never be able to run a government. Ok ai will never be able to run the world economyâŚâ Itâs Robin Williams Gaddadi sketch âOk you cross this line you die!â [1].
[dead]
And to close the loop - there is no architectural thinking without experience in execution. The highly productive people who are all-in on agentic coding today are powered by their previous experience doing implementation. As time goes on their powers will wane unless they make a point to keep them sharp by doing enough hands-on implementation.
Itâs the same as a ânon-coding architectâ role (remember those). Most of them are absolutely full of shit architecture astronauts.
>literally hundreds of orders of magnitude slower
I'm sure this is just a slip of the tongue (finger), but the idea of being a numerical googol times slower is funny.
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.
>This is domain expertise - software engineers are not needed for that. Ofc often senior sws are expert in it, but they aren't necessary.
Our engineers frequently need to be on the loop with product and stakeholders: Due to real world messiness, many times the only true answer to "how does this currently work" is in the code. Enabling product and stakeholders to fetch that knowledge would be a giant time saver, so we've experimented with LLMs.
I recommend you try this exercise: place a non technical person in front of a complex business' codebase with an agent in between and get them to extract or shape business knowledge through it.
I'm serious, it's not a rethorical device, genuinely do try with a coworker or a friend. It will teach you a lot seeing how the way they approach the problem is different to yours.
All our attempts failed miserably.
"...place a non technical person..."
I'm not suggesting that and agree it would fail. Engineer expertise is important, but not in the old way.
> This is domain expertise - software engineers are not needed for that.
I want to work with the business domain experts you work with. The ones Iâve worked with are experts in their domain, not modeling that domain in software.
Left to their own devices with Claude Code, they produce some great POCs. Then those POCs buckle under their own weight they pile on contradicting requirements and have opus spinning to fix bugs.
Maybe the models will get good enough to solve for this, but theyâre not there yet.
As in my reply to the sibling comment, I am not disputing that engineer expertise remains important; I'm saying the nature of it is now different and will continue to rapidly change in its place in the business stack.
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.
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.
I think the general local models are better than you are giving them credit for--I have heard/read good things, at least.
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.
Suno's incapable of making psytrance, which is mind-boggling as that is an intensely repetitive, machine-like genre that should be water off a duck's back to produce.
The problem is that it's doing it by diffusion techniques, so all its high percussion is totally vague and indistinct. Hell, it can't even do a decent psy kick because that too is unspecific and you can't have a psy track that is vague and blunted.
Turns out you can have a production that is hollow, weak and devoid of what makes purely synth machine tracks. It can't get trancey in a serious way because it's not capable of being sharp enough.
Got an example of the genre done properly: https://www.youtube.com/watch?v=Va1KBtI81TY or alternately you could just look up some Infected Mushroom early tracks :)
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
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.
Just tested google's (lyria, integrated into gemini), and it made an honestly not bad progressive death metal song with female vocals alternating growling and melodic (though I accidentally used gemini pro to forward the prompt to the actual music gen model, so I assume it augmented with something to make it not "generic heavy metal").
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.
> 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.
Today is when ground needs to be broke on the data centers to run it in 3 years.
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...
https://play.google.com/store/apps/details?id=com.sixteenam....
"getting people to pay attention to and enjoy something that you've created" is a lot harder still if you didn't really create the thing. I'm not trying to be snide, but the tools that allow you to produce that kind of output being available to everyone else kind of makes the point. That's why statistics show that barely anyone on Suno listens to anything but their own stuff.
And of course, especially for music, the human element is pretty much the entire point, so while a lot of people enjoy it for a while as a toy to play around, I don't think many people would seriously consider listening to AI music as being worth their time. It would be like knowingly and deliberately reading fake news.
[dead]
> 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.
I spent most of the last two years making a rather large hobby project. A 3D renderer for cad/visualization. It's pretty hard and slow work because getting anything wrong is usually hard to debug. Get a sign wrong and you have a black image suddenly, with painstaking debugging following. I worked on it for evenings and weekends, probably totaling a man-month of work or so.
As a fun experiment, yesterday I asked a model to create this for me. It almost one shotted it. After a couple of iterations and 30 minutes I had made what I made over two years. The total AI cost (deepseek api, so entirely usage based) was $0.5.
Now, I didn't enjoy making this AI guided version. And I didn't learn anything. But terrifyingly it has removed the drive to make another 2 year project "by hand". The end result (the runnihg demo) was never the goal. But still I can't now make myself hand-craft what an AI can spit out in an hour for $1!
This is what bothers me the most. I'm old and senior enough that I don't fear for my job. But the AI thing just swallowed my hobby.
You knew exactly what you wanted, since you already built it. All decisions were already made, all tradeoffs reached. LLMs are definitely helpful, but try exploring something new with them and you'll slow down significantly.
Its surprising, how this key insight is lacking, even in the best of developers.
It happened fast, as you prompted it just the right way. Another person, who doesn't have all that context in the mind, would fail quickly.
For example I have decades of Software experience, but wont know where to even begin what OP did.
Most of my time these days is learning about domains, not technical skills. I keep programming books around for references, but the books I read most are books that go deep into some domain, either technical like operating systems or network, or soft skills like planning, design and communication.
Itâs kinda the old saying about $900/hr expert that only taps with an hammer. The price is not about tapping, itâs about knowing where to tap.
> For example I have decades of Software experience, but wont know where to even begin what OP did.
Simple, you start by asking LLM for more info.
Not to mention the poster understands what the output is, what it's supposed to do, and can judge that it is the thing that they intended to build.
But this has always been a developer's work, it's understanding what is needed, translating it to working software, and judging the result, and doing so at scale, over time, and with other people.
Yes, and that's also why I'm really effective at using AI when the context is one I'm comfortable with. Still - it doesn't feel like I'm actually doing anything. The product was never the goal for me. The craft was. I feel like someone who always loved to be a blacksmith who is now in charge of a production line of 10 CNC mills that produce coat hooks. The fact that I know what makes a good coat hook doesn't really help make it a job I don't really enjoy.
no matter how good AI gets, i think it will never reach human-level in our ability to move goalposts
You shouldnât be bothered that someone else does your hobby better. Itâs a hobby, itâs meant to be for you, for no purpose other than fun, experimentation, entertainment, what have you. The outcome isnât as important as the process.
Thatâs my take on this, at least. Iâll never be very good at Scythe, or the most creative role-player, certainly never managed to do anything beautiful in pottery class (although the glazing is pretty).
Thatâs fine. I achieve enough in other areas ._.
> you shouldn't be bothered that someone else does your hobby better
I don't know, I'd feel this way a little. if it's something that's not obvious how much effort goes into the underlying process, it can feel pretty deflating if the craft behind it has felt like it's eliminated.
I can't really think of a good example, but if my hobby was glueing precision glueing little 3d models, then suddenly the hobby has exploded because 3d printers have made it easy, it suddenly feels like it's devalued my collection of manually crafted plastic models
3D printing nonsense can be its own hobby! Letâs be happy that more people are getting back into hobbies over doom-scrolling all evening.
Aside: I had to get into puzzling to manage stress, my doctor actually âprescribedâ it, and hours go by while you mindlessly hunt for sky-blue pieces. Thereâs no point thinking about people that puzzle faster than you :)
I think we need to enjoy the process of things more. Life is precious. If someone else does your thing harder/faster/better/stronger, what are you gonna do? Doom-scroll? Nah, enjoy your special little thing.
Imagine taking up a hobby of drawing, then bemoaning the existence of a printer. Or learning spanish, and bemoaning google translate. Or trying out woodworking, and bemoaning IKEA.
I don't think painting and photography (Which was when painters perhaps feared for their jobs at first) are equivalent. If I paint, it's not because I want an exact "photo" of a person or scene. The fact that its painted by hand makes it fundamentally different from a photograph. With software, you can't really see that. It's compiled and you just see the end result.
How many of the learnings over the past two years went into the prompt that you gave the model? Is it possible that you wouldn't have been able to prompt it so well without those learnings?
Some, but actually surprisingly little. The thing is that my hobby projects are usually extremely "prior art". It's like "make a renderer (just like one that 1000 people have made before)". It's not novel. I just needed a renderer and none was suitable. But the AI knows exactly what to do with almost no context and almost no decisions.
> 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.
Seconded.
If there is any skill in consistent demand it is the ability to wrap your head around the new work, new processes, new people, whatever it all may be.
For me, understanding and development of this skill into a keen tool happened while I worked as a prototype mechamic. For those unfamiliar, a prototype mechanic does what it takes to make often demanding parts on consistently short timelines week after week.
Metals, plastics, you name it.
One gets good at ramping up on processes, machine tools, materials. And after doing that for a while, you end up able to very rapidly absorb new info and understand work far more quickly and accurately than many.
Anyone can start this.
Just get curious and build things. Then build more things.
Share your builds and build things other people want made!
I tell my boys ( age 16 and 14 ), get good at learning and you don't have to get good at anything else!
Question: How do you find work? Reputation? (That is, people know you by now?)
If so, how did you get to that point? How did you publicize that you can do this?
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?
Having lived through all of that as a professional dev, AI is completely different. There was no career anxiety of any significance for OOP or Code Gen (certainly no code gen) or TDD or Agile - there was annoyance at it by some, sure, but not the existential angst the industry is currently experiencing.
> AI is completely different.
Okay?
> existential angst
I don't know, maybe there's just too many juniors on social media posing as senors spreading existential angst? I mean if GC was introduced in a time where there was an engagement AI spreading dread far and wide then I suspect we could have had the same thing.
I certainly wish people would be less sad, but I'm not sure that means that things are meaningfully different on a technical level.
>master the tools
Except the entire value proposition of these tools is that there is no skill or mastery to be built.
The entire slop factory workflow, or sorry I mean "AI-native" workflow is:
"Woah, I cajoled a chatbot into building something I don't understand at all, I'm so good at my job!"
It's the participation trophy of building. Something else builds it, I take credit for it despite not understanding much about about it. There's no compounding return on my effort. No lessons learned. No understanding built. No insights gleaned for possible future innovation. No differentiation. Just mind-numbingly screaming into a void until the slot machine shits out some slop amalgam that seems "good enough", and then I do it all again the next day.
If that's the game, count me out. It's nice that others apparently enjoy it, I guess. But to think there's any sort of mastery here is delusion. The only requirement to be "successful" with these tools is to stop giving a shit and surrender to it.
I think there will always be some sort of mastery element to communicating with AI. You can see that nowadays with juniors who blow through tokens and still donât produce good results. There will always be some group of people using AI better than others. Maybe the results will be equal in the far future, but some other dimension like cost may be better used by some people
>> Something else builds it, I take credit for it despite not understanding much about about it.
How much you understand what was built is entirely up to you. Literally nothing is stopping you, or anyone else, from having the AI walk you through it, or reading the code yourself if you donât trust the AI.
> Literally nothing is stopping you
What about the threat of unemployment due to not meeting AI usage/output metrics? I've personally found it has effectively coerced me to stop trying to understand pretty much anything, and instead just send out whatever passes basic test to "keep up".
Unless you want to just play bad-faith word games and say that "technically it's still not stopping you" in which case yeah man you got me good job buddy.
these tools cannot read your mind. every time you prompt it you condition what it will give you on what you gave it. there will either always be a limit to how good that will be or none of this will matter because no human will ever matter again.
so far the skill is to condition it to give you the best results.
there used to be a time where you had to hack together silly idiosyncratic prompts to get the model to do what you wanted. now you just go into the engineering and describe the object you want it to conjure for you in as much detail as possible (including the high level description of the internals if able) and any constraints you want on it.
"Woah, I cajoled a chatbot into building something I don't understand at all, I'm so good at my job!"
That ship sailed when people started using compilers and stopped learning assembly language.
Never really understood this comparison, as it always felt intentionally obtuse to me, but thanks for replying, friend!
So, this is a complete nonsense take. Why do people keep making this kind of comparison? Is there really such a lack of critical thinking being taught these days?
That's good advice to stay employable.
But I used to enjoy learning - I think most of us did. The existential crisis many are experiencing is about the lack of fulfilment in rolling an LLM slot machine all day in an already dopamine depleting environment.
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.
This is pretty much how I've been operating. While the C-suits have been always encouraging everyone- technical and non-technical folks alike- to use AI, the ask from my manager and skip level has always been for deterministic output. Before last December or January I was mainly using LLMs for autocomplete, whereas now it looks more like "given this input write script to generate this output", and after some corrections, "summarize/update this session into a skill". Script for future humans, skill for future agents.
This is the way to do it.
You can have the Big Boy LLM do _everything_. It can and it will do it. It will also cost fucktons of money and take a long time.
But if you build tools (with AI) that do as many tasks in the process deterministically as possible and let the AI use those, it'll be a lot faster and cheaper to run it.
As a bonus you can eventually drop the expensive cloud AI and run a small/medium sized local model instead.
You know, i think harnesses and tools are the next "webapps" for the industry. Everyone is going to be making their own. Some will be great some will be meh but i think that's where things are headed.
Yep, there are actual papers written on how you can have a mid-tier model punch way above its weight with an optimised harness and toolset.
Claude is still the best commercially available harness IMO, pi.dev is super good but not something I'd give to non-enthusiasts or would recommend using in an enterprise environment.
I see companies writing their own custom harnesses on top of opencode/pi.dev/crush later down the line. Instead of having a set of skills or MCPs you can just have all of the default stuff built in and automatically updated via normal IT workflows.
LLMs, Jenkins for the entire software universe :-D
For those unaware, Jenkins (Hudson), is a CI server that supports all sorts of pipelines. Those pipelines can very easily be turned into huge balls of mud by putting logic in them. The proper way to do it is to put that logic into simple scripts and tools and have Jenkins just do high level orchestration.
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.
It's kind of dumb that we have to do this as a separate process, which introduces even more churn and review burden, rather than having this out of the box in the code generation process.
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 add in the same extended params to the first function
Even after telling it not to do that it kept suggesting the same thing again later, its so annoying sometimes
I have also noticed the too much code issue.
The open question for me is whether too much code is actually a problem.
These tools are a fact of life now. If we can solve problems or debug faster, and the software is less buggy, than it's not too much lines of code, it's just right.
I hear what youâre saying, Iâve wondered this myself. My suspicion is that if we let duplicate or very similar code accumulate, eventually weâll have enough that it will start to slow down or impact the success rate of the AI tooling. It might update two chunks of relevant code but miss the third, leading to a bug. Or it might grow confused over which of three similar chunks of code are providing the âcorrectâ behavior.
Meanwhile most of the software I use seems to become less reliable every month.
Too much code means more complexity for humans and LLMs to comprehend. More complexity means harder to change and more prone to bugs.
This is not just right, no matter on which side of the argument you are.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.