This is called transaction cost economics, if anyone’s interested.
With that said, the entire business world does not understand that software is more than just code. Even if you could write code instantly, making enterprise software would still take time, because there are simply so many high-stakes decisions to make, and so much fractal detail.
(1) https://philippdubach.com/posts/the-saaspocalypse-paradox/
(2) https://philippdubach.com/posts/the-impossible-backhand/
Acharya’s framing is different from mine (he’s talking book on software stocks) but the conclusion is the same: the “innovation bazooka” pointed at rebuilding payroll is a bad allocation of resources. Benedict Evans called me out on LinkedIn for this (https://philippdubach.com/posts/is-ai-really-eating-the-worl...) take, which I take as a sign the argument is landing..
Excellent. And correct lol.
We finally made the computer able to speak “our” language - but we still see computers as just automation. There’s a lot of untapped potential in the other direction, in encoding and compressing knowledge IMO.
To have AI recreate something that was already in it's training set.
> in encoding and compressing knowledge IMO.
I'd rather have the knowledge encoded in a way that doesn't generate hallucinations.
The thing is incredibly good at searching through large spaces of information.
All state changes are made with MCP so it saved me from having to spend time on any forms and most interactions other than filtering searching sorting etc.
Means we will be ditching Linear soon.
I know I’m an outlier but this sort of thing will get more common.
- JIRA/trello/monday.com - benchling - obsidian
this is what i buy and have no intent to replace:
- carta - docusign - gusto/rippling
this is what might be on the chopping block:
- gmail - google calendar
AI systems are also prone to writing code which they can't effectively refactor themselves, implying that many of these code bases are fiscal time bombs where human experts are required to come fix them. If the service being replaced has transactional behaviour, does the AI produced solution? Does the person using it know what that means?
The other side is that AI as an industry still needs to recoup trillions in investment, and enterprise users are potential whales for that. Good prices in AI systems today are not guaranteed to last because even with hardware improvements these systems need to make money back that has been invested in them.
If AI gets good enough to replace all human labor then actual physical moats to keep the hungry, rioting replaced humans away will be the most important moats.
You absolutely could print things like cups, soap holders, picture frames, the small shovel you use for gardening, and so on an so on.
99% of people still just buy this stuff.
make me my own Stripe
make me my own Salesforce
make me my own Shopify
It will be more like:
Look at how Lago, an open-source Stripe layer, works and make it work with Authorized.net directly
Look at Twenty, an open-source CRM, and make it work in our tech stack for our sales needs
Look at how Medusa, an open-source e-commerce platform, works and what features we would need and bring into our website
When doing the latter, getting a good enough alternative will reduce the need for commercial SaaS. On top of that, these commercial SaaS are bloated with features in their attempt to work with as many use cases as possible and configuring them is “coding” by another name. Throw in Enshittification and the above seems to the next logical move by companies looking to move off these apps.
Most of us* are working for places whose analytics software transitively asks the user for permission to be tracked by more "trusted" partners than the number of people in a typical high school, which transitively includes more bytes of code than the total size of DOOM including assets, with a performance hit so bad that it would be an improvement for everyone if the visitor remote desktop-ed into a VM running Win95 on the server.
And people were complaining about how wasteful software was when Win95 was new.
* Possibly an exaggeration, I don't know what business software is like; but websites and, in my experience at least, mobile apps do this.
Velocity or one-shot capability isn't the move. It's making stuff that used to be traumatic just...normal now.
Google fucking vibe-coded their x86 -> ARM ISA changeover. It never would have been done without agents. Not like "google did it X% faster." Google would have let that sit forever because the labor economics of the problem were backwards.
That doesn't MATTER anymore. If you have some scratch, some halfway decent engineers, and a clear idea, you can build stuff that was just infeasible or impossible. all it takes is time and care.
Some people have figured this out and are moving now.
LLMs don't have attention to detail.
This project had extremely comprehensive, easily verifiable, tests.
So the LLM could be as sloppy as they usually arez they just had to keep redoing their work until the code actually worked.
This has been how all previous innovations that made software easier to make turned out.
People found more and more uses for software and that does seem to be playing out again.
https://arxiv.org/abs/2510.14928
Just read some of that. It's not long. This IS NOT the past telescoping into the future. Some new shit is afoot.
First, a vendor will have the best context on the inner workings and best practices of extending the current state of their software. The pressure on vendors to make this accessible and digestable to agents/ LLMs will increase, though.
Secondly, if you have coded with LLM assistance (not vibe coding), you will have experienced the limited ability of one shot stochastic approaches to build out well architected solutions that go beyond immediate functionality encapsulated in a prompt.
Thirdly, as the article mentions, opportunity cost will never make this a favorable term - unless the SaaS vendor was extorting prices before. The direct cost of mental overhead and time of an internal team member to hand-hold an agent/ write specs/ debug/ firefight some LLM assisted/ vibe coded solution will not outweigh the upside potential of expanding your core business unless you're a stagnant enterprise product on life support.
I really hate the expression "the new normal", because it sort of smuggles in the assumption that there exists such thing as "normal". It always felt like one of those truisms that people say to exploit emotions like "in these trying times" or "no one wants to work anymore".
But I really do think that vibe coding is the "new normal". These tools are already extremely useful, to a point where I don't really think we'll be able to go back. These tools are getting good enough that it's getting to a point where you have to use them. This might sound like I'm supportive of this, and I guess am to some extent, but I find it to be exceedingly disappointing because writing software isn't fun anymore.
One of my most upvoted comments on HN talks about how I don't enjoy programming, but instead I enjoy problem solving. This was written before I was aware of vibe coding stuff, and I think I was wrong. I guess I actually did enjoy the process of writing the code, instead of just delegating my work to a virtual intern while I just watch the AI do the fun stuff.
A very small part of me is kind of hoping that once AI has to be priced at "not losing money on every call" levels that I'll be forced to actually think about this stuff again.
I think I would still kind of ask the same questions, though maybe a bit more conceptual. Like, for example, I might see if I could get someone to explain how to build something, and then ask them about data structures that might be useful (e.g. removing a lock by making an append-only structure). I find that Codex will generally generate something that "works" but without an understanding data structures and algorithms, its implementation will still be somewhat sub-optimal, meaning that understanding the fundamentals has value, at least for now.
To illustrate, I'll share what I'm working on now. My companies ops guy vibe coded a bunch of scripts to manage deployments. On the surface, they appear to do the correct thing. Except they don't. The tag for the Docker image used is hardcoded in a yaml file and doesn't get updated anywhere unless you do it manually. The docs don't even mention half of the necessary scripts/commands or implicit setup necessary for any of it to work in the first place, much less the tags or how any of it actually works. There are two completely different deployment strategies (direct to VM with docker + GCP and a GKE-based K8s deploy). Neither fully work, and only one has any documentation at all (and that documentation is completely vibed, so has very low information density). The only reason I'm able to use this pile of garbage at all is because I already know how all of the independent pieces function and can piece it together, but that's after wasting several hours of "why the fuck aren't my changes having an effect." There are very, very few lines of code that don't matter in well architected systems, but many that don't in vibed systems. We already have huge problems with overcomplicated crap made exclusively by humans, that's been hard enough to manage.
Vibe coding consistently gives the illusion of progress by fixing an immediate problem at the expense of piling on crap that obscures what's actually going on and often breaks exiting functionality. It's frankly not sustainable.
That being said, I've gotten some utility out of vibe coding tools, but it mostly just saves me some mental effort of writing boring shit that isn't interesting, innovative, or enjoyable, which is like 20% of mental effort and 5% of my actual work. I'm not even going to get started on the context switching costs. It makes my ADHD feel happy but I'm confident I'm less productive because of the secondary effects.
A few times a week I’m finding open source projects that either have a bunch of old issues and pull requests, or unfinished todos/roadmaps, and just blasting through all of that and leaving a PR for the maintainer while I use the fork. All tested, all clean best practice style code.
Don’t complain about the outputs of these tools, use the tools to produce good outputs.
I’ve had a similar experience to what you’re describing. We are slower with AI… for now. Lean into it. Exploit the fact that you can now iterate much faster. Solve smaller problems. Solve them completely. Move on.
Your model doesn't improve. It can't.
Hilarious that you start with that as TAO requires
- Continuous adaptation makes it challenging to track performance changes and troubleshoot issues effectively.
- Advanced monitoring tools and sophisticated logging systems become essential to identify and address issues promptly.
- Adaptive models could inadvertently reinforce biases present in their initial training data or in ongoing feedback.
- Ethical oversight and regular audits are crucial to ensure fairness, transparency, and accountability.
Not much magic in there if it requires good old human oversight every step of the way, is there?
Machine assisted rigorous software engineering is an even bigger wealth transfer from unscrupulous people to passionate computer scientists.
https://news.ycombinator.com/item?id=47083506
https://news.ycombinator.com/item?id=47045406
I'll take all comers, any conceivable combination of unassisted engineers of arbitrary Carmack/God-level ability, no budgetary limits, and I'll bet my net worth down to starvation poverty that I will clobber them flat by myself. This is not because I'm such hot shit, it's a weird Venn that puts me on the early side on this, but there are others and there will be many more as people see the results.
So there are probably people who can beat me today, and that probability goes to one as Carmack-type people go full "press the advantage" mode on a long enough timeline, there are people who are strictly more talented and every bit as passionate, and the paradigm will saturate.
Which is why I spend all my time trying to scale it up, I'm working on how to teach other people how to do it, and solve the bottlenecks that emerge. That's a different paradigm that saturates in a different place, but it is likewise sigmoid-shaped.
That, and not single-player heroics, stunts basically, is the next thousand-year paradigm. And no current Valley power player even exists in that world. So the competition I have to worry about is very real, but not at all legible.
I don't know much about how this will play other than it's the fucking game at geopolitical levels, and the new boss will look nothing like the old boss.
We work in Software ENGINEERING. Engineering is all about what tools makes sense to solve a specific problem. In some cases, AI tools do show immediate business value (eg. TTS for SDR) and in other cases this is less obvious.
This is all the more reason why learning about AI/ML fundamentals is critical in the same way understanding computer architecture, systems programming, algorithms, and design principles are critical to being a SWE, because then you can make a data-driven judgment on whether an approach works or not.
Given the number of throwaway accounts that commented, it clearly struck a nerve.
For example, being able to vibecode a UI wireframe instead of being blocked for 2 sprints by your UI/UX team or templating an alpha to gauge customer interest in 1 week instead of 1 quarter is a massive operational improvement.
Of course these aren't completed products, but customers in most cases can accept such performance in the short-to-medium term or if it is part of an alpha.
This is why I keep repeating ad nauseum that most decisionmakers don't expect AI to replace jobs. The reality is, professional software engineering is about translating business requirements into tangible products.
It's not the codebase that matters in most cases - it's the requirements and outcomes that do. Like you can refactor and prettify your codebase all you want, but if it isn't directly driving customer revenue or value, then that time could be better spent elsewhere. It's the usecase that your product enables which is why they are purchasing your product.
I don't even know what this means, but my take: we should stop listening to VCs (especially those like A16Z) who have an obvious vested interest that doesn't match the rest of society. Granting these people an audience is totally unwarranted; nobody but other tech bros said "we will vibe code everything" in the first place. Best case scenario: they all go to the same exclusive conference, get the branded conference technical vest and that's were the asteroid hits.
Vcs are choke full of companies that can be cloned over night, SaaS companies that will face ridiculously fast substitution, and a whoooole lotta capital deployed on lousy RAGs and OpenAI Wrappers.
| The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.
- Dijkstra
- Had a boss give you confusing instructions?
- Argued with someone only to find you agree?
- Talked with someone and one of you doesn't actually understand the other?
- Talked with someone and the other person seems batshit insane but they also seem to have avoided a mental asylum?
- Use different words to describe the same thing?
- When standing next to someone and looking at the same thing?
- Adapted your message so you "talk to your audience"?
- Ever read/wrote something on the internet? (where "everyone" is the audience)
Vibe Coding has its uses and I'm sure that'll expand, but the idea of it replacing domain experts is outright laughable. You can't get it to resolve ambiguity if you aren't aware of the ambiguity. If you've ever argued with the LLM take a step back and ask yourself, is there ambiguity? It'll help you resolve the problem and make you recognize the limits. I mean just look at the legal system, that is probably one of the most serious efforts to create formalization in natural language and we still need lawyers and judges to sit around and argue all day about all the ambiguity that remains.
I seriously can't comprehend how on a site who's primary users are programmers this is an argument. If we somehow missed this in our education (formal or self) then how do we not intuit it from our everyday interactions?
[0] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
[1] https://en.wikipedia.org/wiki/Principia_Mathematica
[2] Most programming languages are some hybrid variant. e.g. Python uses duck typing: if it looks like a float, operates like a float, and works as a float, then it is probably a float. Or another example even is C, what used to be called a "high level programming language" (so is Python a celestial language?). Give up some precision/lack of ambiguity for ease.
I don't think that's the argument. The argument I'm seeing most is that most of us SWEs will become obsolete once the agentic tools become good enough to allow domain experts to fully iterate on solutions on their own.
That’s been the argument since the 5PL movement in the 80s. What we discover is that domain expertise an articulation of domain expertise into systems are two orthogonal skills that occasionally develop in the same person but, in general, requires distinct specialization.
> The argument I'm seeing most is that most of us SWEs will become obsolete
Though my big concern right now is that we'll get rid of juniors and maybe even mid levels. There's definitely a push for that and incentives from an economic point of view. But it will be disastrous for the tech industry if this happens. It kills the pipeline. There can be no wizards without noobs. So we have a real life tragedy of the commons situation staring us in the face. I'm pretty sure we know what choices will be made, but I hope we can recognize that there's going to need to be cooperation to solve this least we all suffer.
He's not wrong about the problems of natural language YET HERE ARE. That would, I think, cause a sensible engineer to start poking at the predicate instead of announcing that the foregone conclusion is near.
We should take seriously the possibility that this isn't going to be in a retrenchment which bestows a nice little atta boy sticker on all the folks who said I told you so.
> Dijkstra also said no one should be debugging
Interestingly I think his "gospel" is only more meaningful today.
| Apparently, many programmers derive the major part of their intellectual satisfaction and professional excitement from not quite understanding what they are doing. In this streamlined age, one of our most under-nourished psychological needs is the craving for Black Magic, and apparently the automatic computer can satisfy this need for the professional software engineers, who are secretly enthralled by the gigantic risks they take in their daring irresponsibility. They revel in the puzzles posed by the task of debugging. They defend —by appealing to all sorts of supposed Laws of Nature— the right of existence of their program bugs, because they are so attached to them: without the bugs, they feel, programming would no longer be what is used to be! (In the latter feeling I think —if I may say so— that they are quite correct.)
| A program can be regarded as an (abstract) mechanism embodying as such the design of all computations that can possibly be evoked by it. How do we convince ourselves that this design is correct, i.e. that all these computations will display the desired properties? A naive answer to this question is "Well, try them all.", but this answer is too naive, because even for a simple program on the fastest machine such an experiment is apt to take millions of years. So, exhaustive testing is absolutely out of the question.
| But as long as we regard the mechanism as a black box, testing is the only thing we can do. The unescapable conclusion is that we cannot afford to regard the mechanism as a black box
https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...
He literally said those exact words out loud from the audience during a job talk.
And yeah, the total aim and the reason why he might just blurt that out is because a lot of the frustration and esprit de corps of programming is held up in writing software that's more a guess about behavior than something provably correct. Perhaps we all ought to be writing provably correct software and never debugging as a result. We don't. But perhaps we ought to. We don't.
Is control via natural language a doomed effort? Perhaps, but I'd be cautious rather than confident about predicting that.
> He literally said those exact words out loud from the audience during a job talk.
Unfortunately despite being able to provide a summary I'm unable to actually read it for you. You'll actually need to read the whole thing and interpret it. You have a big leg up with my summary but being literate or not is up to you. As for me, I'm not going to argue with someone who chooses not to read
Which is what I was referring to. I read what you wrote, pal. Did you read what I wrote?
> I sincerely doubt you produced the source
> I read what you wrote, pal.
This is your regular reminder that
1) a16z is one the largest backers of LLMs
2) They named one of the two authors of the Fascist Manifesto their patron saint
3) AI systems are built to function in ways that degrade and are likely to destroy our crucial civic institutions. (Quoted from Professor Woodrow Hartzog "How AI Destroys Institutions"). Or to put it another way, being plausible but slightly wrong and un-auditable—at scale—is the killer feature of LLMs and this combination of properties makes it an essentially fascist technology meaning it is well suited to centralizing authority, eliminating checks on that authority and advancing an anti-science agenda (quoted from the A plausible, scalable and slightly wrong black box: why large language models are a fascist technology that cannot be redeemed post).
Seems like he's focused on fintech and not involved in many of their LLM investments
> ...
> For this WE WANT:
> On the political problem:
> Universal suffrage by regional list voting, with proportional representation, voting and eligibility for women.
> ...
> On the social problem:
> WE WANT:
> The prompt enactment of a state law enshrining the legal eight-hour workday for all jobs.
> ...
> On the military issue:
> WE WANT:
> The establishment of a national militia with brief educational services and exclusively defensive duty.
> ...
> On the financial problem:
> WE WANT:
> A strong extraordinary tax on capital of a progressive nature, having the form of true PARTIAL EXPROPRIATION of all wealth.
> ...
0: https://it.wikipedia.org/wiki/Programma_di_San_Sepolcro#Test...
The message of universal suffrage vs. that of preventing an out group from “stealing” an election are not far apart semantically. Same with workers rights - in practice the worker protection laws that were passed in Italy at this time were so full of loopholes and qualifications that ultimately the workers do not gain power in that system.
It is this fair, in my view, to question the spirit of the manifesto in the first place.
Or maybe they own the debt.
Listen to some of the Marc Andreessen interviews promoting cryptocurrency in 2021.
Do that and you will never listen to him or his associates again.