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..
The best take I've seen on the whole `AI will replace all devs' is a way for big tech to walk back the disastrous over hiring they did around Covid without getting slaughtered in the stock market.
However, admitting to have massively over hired and wasted a lot of money does not make the management involved look good. No one wants to admit they made a massive blunder.
The market doubly rewards companies that lay off workers and have a story about how they're automating everything with AI, even if that story is just a story.
> investors are simultaneously punishing hyperscaler stocks because AI capex might generate weak returns, while destroying software stocks because AI adoption will be so pervasive it renders all existing software obsolete. Both cannot hold simultaneously.
I don't understand this point. Can't it be possible that the ultimate effect is to devalue, hugely, software? As in it can totally both be true that AI capex has weak returns and at the same time most SaaS companies go bankrupt. To take an analogy: if ever we manage to successfully mine asteroids, and find some vast quantity of platinum, it could both be true that every existing platinum miner loses their shirt, and also that the value of platinum sinks so far that the asteroid mining company cannot cover its costs.
It is an AI thing though. AI makes it far easier to create bespoke software targeted at narrow specialized domains, which is the mainstay of modern SaaS. We'll probably see "proper" FLOSS expand into these sectors too, such that the software won't be simply a matter of internal vibecoding by any single business - instead, the maintenance work will be shared.
AI makes it easier to create something, but that thing is not enterprise software with support contracts and conformance to mandatory regulations and 4 hour bug turnarounds and real people on the end of the phone who understand how it works.
Sometimes I just wonder at how HN has no idea what enterprise software involves.
With this kind of niche sector-specific offering, creating a prototype that works properly for what the industry needs is the main hurdle. The rest is just the same sort of ordinary software engineering work that applies to any FLOSS project already - and we know that FLOSS (with optional 3rd party support covering "enterprise" needs) is quite viable.
I don't see AI easily creating a DataDog. You need it for reliability for example.
You can always also deploy open source since forever. What happens when it randomly drops logs or changes the text? If you get an alert and it is noise it starts becoming pointless.
And yet these type of stocks were at 50-100x earnings etc.
How is AI code generation a "innovation bazooka"? Last time I checked, innovation required creativity, context, and insight. Not really fast boilerplate generators.
AI allows innovative people to create more innovations by reducing a lot of the non-innovative grunt work in an efficient manner. It isn't the AI doing the innovation, but allows innovators to focus more on innovating.
Or at least that is the theory. It is certainly true from observations of those around me. It also scales well. Even someone a bit innovative gets a multiplier by using AI intelligently. Those that just focus on the grunt work are the ones in trouble.
> Even a16z is walking this back now. I wrote about why the “vibe code everything” thesis doesn’t hold up in two recent pieces:
The next one a16z should walk back on is "AGI" given that they have just admitted that "vibe code everything" was just a sign of them being consumed by the hype.
All that is correct and well-written, however I fear in most cases "good enough" will be good enough for Business. If Business can do something to 80% the same but with a large cost cutting they likely go for it, we have seen this with shrinkflation (reduced portion sizes for the same price), to using cheaper ingredients to practically everything that is not a knowledge-heavy industry. The big change is now the "shrinkflation" is coming to knowledge domains too, which will likely lower the quality of healthcare, software etc.
AI being a next-token predictor will produce cheap and average products, we will likely see some (most?) software become a commodity, that goes through the same product development and "manufacturing" as a breakfast cereal. Made in a "dark factory", 24/7, with little supervision.
However I think down the line we will see many industries popping up that are like "organic food", "mechanical watchmaking" that provide above the usual slop that large businesses produce.
Using vibe coding to build a small specialized tool for a small company that can be used instead of single feature of a commercial SaaS is doable and brings value.
Using vibe coding to build something to replace an enterprise SaaS offering for a medium to large company is not something to be taken lightly. The tool and the code is not everything. The operating environment, security guarantees, SLAs, support, and a bag of features you don't need today but might tomorrow is what the SaaS offerings bring to the table.
Imagine that I run a really good software house. I can literally build anything you want, feature wise, better than most. I do it quickly. You come to me and say you want to replace Slack for your team of 200, because Slack got too expensive. I say I can do it. Because I am feeling generous and you're my good friend, I will do it for free. However, I will just give you the code, a CI/CD script, and a README.md file. I will disappear and will not maintain or support your software, nor will I give you any guarantees on how well it will work, other than a "trust me."
The question is how much further and faster can these tools evolve.
Right now, you may not be faced with a valid choice to vibe code your own hubspot, but maybe some contractor firm will do it for you and sell an ultra low cost version.
Will opus 6 do the same thing without the contractors while managing the deployment and maintenance as a claw?
The Matrix folks have covered the "replace Slack internal chat" case already. They will give you the code so that you can bring the service up internally, or you can use any 3rd party hosted solution that provides the usual support and "enterprise" guarantees, for a price. Why can't this model generalize to sector-specific SaaS offerings that can now be prototyped cheaply via AI vibecoding?
As much as the Slack UX has somewhat enshittified at this point, the UX of Matrix is still so so so far behind Slack that it's often not even worth considering.
I hear Zulip could actually be a real alternative, though I have no experience with it.
People are overestimating the value on having AI create something given loose instructions, and underestimating the value of using AI as a tool for a human to learn and explore a problem space. The bias shows on the terminology (“agents”).
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.
Because that would mean AI isn't going to replace entire industries, which is the only way to justify the, not billions, but trillions in market value that AI leaders keep trying to justify.
Exactly my thoughts - the value in AI is not auto-generating anything more than something trivial, but there's huge value in a more customized knowledge engine - a targeted, specific Google if you will. Get answers to your specific question instead of results that might contain what you were looking for if you slog through them.
AI is hugely beneficial in understanding a problem, or at least getting a good overview, so you can then go off and solve/do it yourself, but focusing on "just have the AI generate a solution" is going to hugely harm AI perception/adoption.
I once built a CRM in Google Sheets fully mirroring the data model of Salesforce. For contact, company, deal, and call tracking for a one sales rep business. (Before XLookup was in Google Sheets)
Did it work? Yes. Was it worth my time to maintain and scale the “platform” with the company rather than outsource all that to a CRM company? Not at all.
Time is finite. Spend your time doing what you do best, pay others to do what they do best.
Yup, my experience has been that vibe-coding is very time-consuming. It reminds me very much of how LLMs are great at creating mind-blowing images, but you get what you get. Once you decide that you need to modify the image you get, it becomes a time sink. You might be able to change it and get what you need, but there is no guarantee and it's a never ending task.
The same thing happens with code; you may get great results from your prompt, but trying to customize it will drive you nuts and you may never get what you want.
Maintenance is another hurdle. How do you maintain code you might not have the skills to maintain?
Vibe-coding may reduce software creation time, but it's not taking over software engineering. The SaaS business is going nowhere. Most people, by far, will continue to rely on someone else for their software needs. But be very aware that the software business will change. We are seeing that already.
It doesn't make sense for every company to make their own Salesforce clone.
The key is that it makes new companies entering the market to compete with Salesforce immensely easier. More competition will just force lower overall margins in SAAS.
I don't know, I mean for most SaaS products this is true. But for something like Salesforce, the feature set is incredibly broad. The coding is not hard, so much as it is just an enormous volume of code.
It was never the only hard part, but it definitely was a hard part (at least in most cases; obviously there are some monopolies with relatively simple software - mostly where there are network effects like WhatsApp).
But give me the source code for something competitive with Solidworks, Jasper Gold, FL Studio, After Effects, etc. and I'm sure as hell making a business out of it!
Furthermore while good software may not guarantee business success, it is pretty much a requirement. I have seen many projects fail because the software turned out to be the hard part.
Yeah, but its still usually cheaper to pay for software than build and support it. I think that will be true for a long time going forward, its just that you can't plan on extracting a ransom for your SAAS.
But a query optimizer only matters once you have an established business with large customers.
You seem to be implying Salesforce’s business is successful because they have their own query optimizer. But the causality is reversed. Salesforce has their own query optimizer because they’ve built a successful business.
Thought exercise for those in disagreement: why would every company use AI to build their own payroll/ERP/CRM, when just a handful of companies could use AI to build those offerings better?
This is largely how things work now; AI may lower the cost and increase margins, but the economics of build vs buy seem the same.
To avoid CRAZY SaaS charges. I left a comment further down about how the challenge is first getting a reliable stack running underneath whatever ends up being fast-coded. The trend will be more decentralization - I think that'll be AI 2.0. Increasing centralization is AI 1.0.
But if that was a goal, or a marketable feature, SaaS and cloud would have competitors out there selling software with perpetual licenses to be run on premises
Yes, the vendors want subscriptions and cloud and not owning anything, but customers also don't want to hire people to operate the infrastructure required to run this stuff themselves. That's the whole point of SaaS, and why some companies just run entirely on that model and basically have no in-house IT staff
That AI means you can write and run your own payroll system doesn't mean all of a sudden a world of people with zero technical skills can start doing it on their own
...unless they have an agent "IT Guy" who can either do it for them or show them what to do. Perhaps UIs will change and be designed half for a human operator, and half for the IT Guy to copilot with them.
The person with zero technical skills could start learning primitive technology: youtube.com/@primitivetechnology9550 - living off the land really is the job for the unemployed. We've done it before! As long as there is a safe place to actually do it and a planet that can support it. Those'll be the problems.
Every company that I’ve worked at has had to do significant additional development work on their instance of salesforce to make it work for them. Like 6-12 months of work with 1-3 people. I don’t know if this is common but in that case maybe going custom might be the way to go. You get something lean, without all the cruft, specifically built for your usecase and nothing more.
Well the answer is because the cost of that software is lower than somebody building the other software.
What happens is that all these SaaS drop in value because it is now realistic to build them internally
Oh sure! My conclusion is that they will drop in value, not disappear.
Basically I expect way smaller companies popping up competing with the big ones and their offering will be priced way lower because their payroll is way smaller.
While there is no competitor, internal tools will pop up now.
I believe that. Companies will build cheap tools today while competitors are spinning up to undercut ADP, Salesforce, and SAP. But what happens tomorrow? There are plenty of examples in IT today where the reasonable option is to outsource in 90% of cases: don’t roll your own auth, don’t host your own email server, don’t build your own data center. I don’t see how AI can change that, when the people who build specialized software also have access to AI.
Another great example is open source. I think PostgreSQL being free and usable by everyone is a more economic outcome than every Fortune 500 company building their own database engine. Payroll, ERP, and CRM fall into the same category of being commodity software in a lot of cases.
My experience is that the folks in charge of spending and making decisions are looking at AI as another means of outsourcing. Payroll, ERPs and CRMs went from commodity software to subscription services and anything that is subscription based is getting scrutinized much more heavily now.
Slack is a good example. When the cost of Slack is an unreasonable amount of your operating costs then it makes sense to clone and maintain. The product is simple, you can basically recreate the main functionality in a sitting. Why would you pay hundreds of thousands of dollars for it?
That’s a fine example, but my question then is why does Slack exist? Surely Fortune 500 companies are smart enough to realize that building a slack clone is cheaper, yet they don’t do that.
So now consider AI, perhaps the cost of building has decreased from 100k to 10k. What stops a Slack competitor from also building the product for 10k and reselling it at 10% of the cost of Slack? My point is that I don’t see how AI has changed the value prop.
I do not actually believe that you can trivially vibe code a viable slack replacement. But even if one day we could it wouldn’t mean that Slack as a company would just disappear overnight.
They would hang around serving companies who haven’t got the memo yet, or who are locked in a contract, or where the internal political situation is against such a move. The innertia of a bunch of humans behaving like a bunch of humans would provide a sort of “coyote time” effect where the fundamentals could fall out from under Slack yet the company would keep “floating” for a while.
It is funny how much of your question sounds like the old joke where an economist can’t believe their eyes that a $20 bill is laying on the pavement, because surely if it were so someone would have already picked it up. In a steady state the logic might hold up, but we are not in a steady state.
And that is separate from why do I think it is not realistic to just replace slack with vibe coded alternative: just in my company some people use the web interface, some the ios app and some the android app. To be a viable replacement you would need all 3 platforms supported with all features. That sounds in itself a nightmare. Then figuring out what features my company members really use is an other nightmare. There are some who craft custom emojis all the time, some who integrate all kind of weird apps. We various CI and data pipeline processes integrated with slack reporting. And then comes huddle. Video and voice chat and screen sharing. You can even draw on someone else’s screen with it! IT has their needs to archive things (maybe?) or snoop on certain things. Then comes of course interfacing with single-sign-on. I wouldn’t even volunteer to enumerate all the different features people just at my company depend on, let alone offer to replace it.
Is it the sla and maintenance cost ? As silly as it seems it is important for slack to work reliably, especially in case of court orders and legal retention.
Also Is there not a self hosted open source solution that companies can host ? That’s easier than ai?
There is value in taking a product to market and hardening it, and no one wants to invest in something that requires headcount for cost-savings. They want upside. But if it doesn't require headcount and/or unlocks functions they have to negotiate for, and the AI can keep it online and troubleshoot, that is a different story.
Slack exists in part because ten years ago it was a lot harder for big orgs to make good/modern software.
Mattermost is FOSS. Why aren't companies running their own servers to avoid Slack? Prior to OneDrive and web integration, LibreOffice was 95% as good as MS Office, better than VibeOffice will likely be, and it still failed to gain much traction.
This is the key point. We've already run the experiment where the code is free and all you need to do is host it yourself and people still didn't opt to do that work. I don't see how AI changes the situation.
I don’t doubt it but that doesn’t negate the fact that Slack as a company exists and makes money by selling software. My question is this: AI makes it cheaper to build software, but ADP, SAP, and Salesforce also have access to AI and could make cheaper versions of their products. How does AI change the build vs buy trade off in a way that eliminates economies of scale? My opinion and that of the article is that it doesn’t.
> How does AI change the build vs buy trade off in a way that eliminates economies of scale?
I think a more likely scenario here is that something good and free escapes containment at some point and Slack’s core product just kind of deflates. Not something better than Slack, but something good enough that people don’t care about Slack any more.
I don’t see it as a question of whether you build it or buy it, but a question of the time horizon for selling messaging software as a business strategy. Most business strategies have a finite time horizon. How long can you continue to sell messaging software before there are too many competing solutions available and you stop making money from it?
I don’t think “categorically different” has legs. I work on the operations & hosting side of applications like this. There’s an operations burden to maintain, deploy, and scale web servers. There’s a burden to rolling out new Linux kernel versions to servers. But we still do it! There would be a burden to running your own Slack, just like there is a burden to running your own email, and people will choose to pay for hosted versions or host it themselves.
And then there are companies and organizations who have strong incentives to self-host to make compliance easier.
I guess to provide a counterpoint to my own comment, even I worked for a company that created their own internal social network similar to Facebook (this was 15 years ago).
Of course it sucked and no one used it except executives and VPs. Everyone else did just enough to meet the minimum quarterly engagement metrics right before performance reviews.
2. They did, and then exited the market. Employees gradually migrated off the internal platform.
3. They weren’t in the business of selling software, and didn’t sell their internal messaging platform (which is idiosyncratic and closely integrated with other internal system).
I mean once campfire is full featured free and easy to self host. Completely open source slack replacement.
I imagine it's also infinitely better than anything an in house team could vibe code.
You don't need AI for a cheap slack alternative.
That's why I don't buy any of this.
Companies are not bothering with the free/open alternatives.
Unless the real power of LLMs is making it easy for greg in HR to self host these existing alternatives. But, that a trillion dollar market does not make.
Anyone who's seen an enterprise deal close or dealt with enterprise customer requests will know this, the build vs buy calculus has always been there yet companies still buy. Until you can get AI to the point where it equivalent to a 20 person engineering team, people are not going to build their own Snowflake, Salesforce, Slack or ATS. Maybe that day is 3 years away but when that happens the world will be very different
Companies do make/buy decisions on everything, it just software. Cleaning services are not expensive, yet companies contract them instead of hiring staff.
This is called transaction cost economics, if anyone’s interested.
We’ve also got to consider the fourth dimension, what happens over time.
Salesforce is getting LLM superpowers at the same time the Enterprise is, so customizing and maintaining and extending Salesforce are all getting cheaper and better and easier for customers, consultants, and Salesforce in parallel.
Unless the LLMs are managing the entire process there’s still a value proposition around liability, focus, feature updates, integrations, etc. Over time that tech should make Salesforce get way cheaper, or, start helping them upsell bigger and badder Sales things that are harder to recreate.
And, big picture, the LLMs are well trained on Salesforce API code. Homegrown “free” versus industry-standard with clear billing, whatever we know versus man-decades of learning at a vendor, months of effort and all the risk & liability versus turnkey with built-in escape goats… at some point you’re paying money not to own, not to learn, not to be distracted, and to have jerks to sue if something goes bad.
I agree generally, but some of these enterprise contracts are eye-watering. If the choice is $2M/year with a 3-year minimum contract, or rolling your own, I think calculus really has shifted.
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.
> If the choice is $2M/year with a 3-year minimum contract, or rolling your own, I think calculus really has shifted.
But why? It was always dramatically cheaper for enterprises to build rather than buy. They stopped doing that becuase they did that in the 90s and ended up with legacy codebases that they didn't know how to maintain. I can't see AI helping with that.
This might be the biggest benefit of AI coding. If I have a large legacy code base I can use AI to ask questions and find out where certain things are happening. This benefit is huge even if I choose not to vibe code anything. It ends up feeling a lot like the engineer that wrote the code is still with you or documented everything very well. In the real world there is a risk that documentation is wrong or that the engineer misremembers some detail so even the occasional hallucination is not a particularly big risk.
> This might be the biggest benefit of AI coding. If I have a large legacy code base I can use AI to ask questions and find out where certain things are happening. This benefit is huge even if I choose not to vibe code anything.
If you consider total cost of ownership including long-term maintenance costs, it means building has not always been cheaper than buying. I think what's changing is that it's now becoming dramatically cheaper to build AND operate AND maintain "good enough" bespoke software for a lot of use cases, at least in theory, below a certain threshold of complexity and criticality. Which seems likely to include a sizeable chunk of the existing SAAS market.
I can't believe I'm saying this, but I guess you don't even really need to maintain software if it's just a tool you hacked together in a week. You can build v2 in another week. You'll probably want to change it anyways as your users and your org evolve. It's a big question for me how you maintain quality in this model but again, if your quality standard is "good enough", we're already there.
Oh I don't know, I think AI is very helpful at maintaining and modernizing legacy codebases. And in the old days, the "build" option was often not really cheaper once you factored in four salaries for developers to maintain the product. But now…
Exactly. I was building an app to track bike part usage. It was an okay app, but then I just started using ai with the database directly. Much more flexible, and I can get anything I need right then. AI will kill a lot of companies, but it won’t be the software it develops, it will be the agent itself
"This entire stack could give you computing power equivalent to a 25k euro/month AWS bill for the cost of electricity (same electricity cost as running a few fridges 24/7) plus about 50k euros one-time to set it up (about 4 Mac Studios). And yes, it's redundant, scalable, and even faster (in terms of per-request latency) than standard AWS/GCP cloud bloat. Not only is it cheaper and you own everything, but your app will work faster because all services are local (DB, Redis cache, SSD, etc.) without any VM overhead, shared cores, or noisy neighbours."
Makes me think there will be these prompts like "convert this app to suit a new stack for my hardware for locally-optimized runtime."
How are people building the best local stacks? Will save people a ton of money if done well.
Yep, we'll evolve patterns which facilitate system to system interaction better than the ones we had built for human in the loop by humans. That's inevitable. CRUD apps with a frontend will be considered legacy etc. They'll be replaced by more efficient means we haven't even considered. We live in an exciting time.
> we'll evolve patterns which facilitate system to system
We have! It has different names, shapes and forms. For example WiFi. Last I checked, it’s not designed for human in the loop and you need multiple levels of decoding for a human to make sense of it.
Speaking of AI taking over the world, have you seen how many projects on ShowHN are using GitHub? Do you think that's by accident or is it trying to normalize a place for an AI to lurk about like a crocodile hanging around a river outlet?
If an AI agent ever became as productive at writing code as a well-organized 20 person engineering team you'd still need to run it for a year or more to replicate any nontrivial SaaS product.
And the thing about many of these products isn't their feature set, it's their stability. It's their uptime. It's how they handle scaling invisibly and with no effort on your part. These are things you can't just write down from whole cloth, they are properties that emerge over time by adapting the the reality of scale. Coding isn't the whole deal, and your 20x clanker which can do nothing but re-arrange text in interesting patterns is going to have some trouble with the realities of taking that PoC to production. You'll still need experienced, capable people for that. And lots of time.
A lot of this "ermahgerd everything will change" drivel is based on some magical fundamentally new technology emerging in the near future that can do things that LLMs cannot do. But as far as anyone knows, that future may be never.
So even given a large improvement in agentic coding I'm not convinced it really changes the build vs buy equation much.
I sort of agree with this, but what a lot of people are missing is it's unbelievably easy to clone a lot of SaaS products.
So I think big SaaS products are under attack from three angles now:
1) People replacing certain systems with 'vibe coded' ones, for either cost/feature/unhappiness with vendor reasons. I actually think this is a bigger threat than people think - there are so many BAD SaaS products out there which cost businesses a fortune in poor features/bugs/performance/uptime, and if the models/agents keep improving the way they have in the last couple of years it's going to be very interesting if some sort of '1000x' engineer in an agent can do crazy impressive stuff.
2) Agents 'replacing' the software. As people have pointed out, just have the agent use APIs to do whatever workflow you want - ping a database and output a report.
3) "Cheap" clones of existing products. A tiny team can now clone a "big" SaaS product very quickly. These guys can provide support/infra/migration assistance and make money at a much lower price point. Even if there is lock in, it makes it harder for SaaS companies to keep price pressure up.
But have you ever tried to clone a product or tool for yourself before? At first it’s great because you think that you saved money but then you start having to maintain it… fixing problems, filling in gaps… you now realize that you made a mistake. Just because AI can do it now doesn’t mean you aren’t just now having to use AI to do the same thing…
Also, agents are not deterministic. If you use it to analyze data, it will get it right most of the time but, once in a blue moon, it will make shit up, except you can’t tell which time it was. You could make it deterministic by having AI write a tool instead… except you now have the first problem of maintaining a tool.
That isn’t to say that there isn’t small low hanging fruit that AI will replace, but it’s a bit different when you need a real product with support.
At the end of the day, you hire a plumber or use a SaaS not because you can’t do it yourself, but because you don’t want to do it and rather want someone else who is committed to it to handle it.
I'm not saying _the end user_ clones it. I mean someone else does (more efficiently with agents) and runs it as a _new_ SaaS company. They would provide support just like the existing one would, but arguably at a cheaper price point.
And regarding agents being non deterministic, if they write a bunch of SQL queries to a file for you, they are deterministic. They can just write "disposable" tools and scripts - not always doing it thru their context.
The challenge to this is that so much of the difficulty in getting people to switch products is trust, and a couple of people running saas with claude code has no differentiation and no durability.
I think it will be a little different: black box the thing, testable inputs and outputs, and then go to town for a week or two until it is reasonable. Then open source it. Too big/complex for an agent? Break down the black box into reasonable ideas that could comprise it and try again. You can replace many legacy products and just open source the thing. If the customer can leave behind some predatory-priced garbage for a solution where they get the code I think they would be a lot more likely to pay for help managing/setting it up.
It would be interesting if, with all the anxiety about vibe coding becoming the new normal, its only lasting effect is the emergence of smaller B2B companies that quickly razzle dazzle together a bespoke replacement for Concur, SAP, Workday, the crappy company sharepoint - whatever. Reminds me of what people say Palantir is doing, but now supercharged by the AI-driven workflows to stand up the “forward deployed” “solution” even faster.
"You have this innovation bazooka. Why would you point it at rebuilding payroll?" — a partner at the firm whose thesis was literally "software is eating the world."
Apparently the meal is over and now we're just rearranging the plates.
> One who thinks that complex software can be "vibe coded", hasn't worked on complex codebases.
I do think that I have worked on somewhat complex code bases. The reason why they are complicated is often "political" (e.g. at some point it was decided that this is the way to go, and from then on the specific abstraction was used. It turned out these wishes were not a good idea, but the code was never re-developed with a "more proper" architecture (also for the reason that removing some insanely convoluted feature would anger some users)).
I see no reason why some (hypothetical) AI couldn't come up with a much better architecture (also good programmers are capable of this). The problem is rather "getting this architecture through politically"; for some reason "AI suggested/created it" is much more socially accepted by managers than "programmer X considers this change to be necessary" (I cannot understand why).
it can but it will take one person just as long as a small team without "AI" and that one person will carry all the frustration, doubt, all the to do lists and imaginary pin boards and all that other stuff programmers carry around in their heads, at work and back home. have fun with all that.
side note: indie games are not complex software.
and most "overvalued" and "impossible" and "walking it back now" comments are true in as many cases as they are not true and I really do not understand these commenters. smart people should not fall into the same category as people who think that "nobody cares" because they never met devoted lawyers, investigative journalists and law enforcers passionate about justice AND law. it's all so weird, man ...
> He said that software accounts for 8% to 12% of a company's expenses, so using vibe coding to build the company's resource planning or payroll tools would only save about 10%. Relying on AI to write code also carries risks, he said.
> "You have this innovation bazooka with these models. Why would you point it at rebuilding payroll or ERP or CRM," Acharya said
> Instead, companies are better off using AI to develop their core businesses or optimize the remaining 90% of their costs
The bottleneck will always be humans. You could get AI to write a million lines of code a day, but you’d still need humans to review and test that code. We are a very long way from being able to blindly trust AI’s outputs in production.
I don’t even think it’s about reviewing and testing. The bottleneck will always be humans.
We don’t like to always admit it but most jobs are fairly straightforward, as in the actual day to day tasks. Yes being smart is great and useful etc. but after a certain point it’s diminishing returns on the actual tasks you have to do. Dealing with other humans and their egos and eccentricities and the multitude ways each person sees the world is always what makes all jobs tricky. I suspect this whole ai wave/hype/reality is going to open many people’s eyes to this. We will laugh that we use to call them “soft” skills.
IMO I would have agreed with this statement 2 months ago but now it’s clear AI is already much better at reviewing and even testing code (via spinning up simulators, etc) much better than we can. We’re already using AI’s outputs in production and not writing much code these days.
Both AI Fanatics and AI Luddites need to touch grass.
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.
There is a lot of work that goes on before even reaching the point to write code.
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.
> The reality is, professional software engineering is about translating business requirements into tangible products.
and most requirements (ime anyways) are usually barely half-baked and incomplete causing re-testing and re-work over and over which are the real bottlenecks...
ai/vibe coding may make that cycle faster but idk it might actually make things worse long-term because now the race course has rubber walls and there is less penalty just bouncing left and right instead of smoothly speeding down the course to the next destination...
> most requirements (ime anyways) are usually barely half-baked and incomplete causing re-testing and re-work over and over which are the real bottlenecks...
> ai/vibe coding may make that cycle faster but idk it might actually make things worse long-term
By making the cycle faster it reduces the impact while also highlighting issues within the process - there are too many incompetent PMs and SWEs.
Additionally, in a lot of cases a PM won't tell you that you might actually be working on checkbox work that someone needs to do but doesn't justify an entire group of 2-3 SWEs because then you obviously won't do the work. This kind of work is ripe for being automated away via vibecoding or agents.
A good reference for this is how close is the feature you are working on directly aligned with revenue generation - if your feature cannot be directly monetized as it's own SKU or as a part of a bundle, you are working on a cost center, and cost centers are what we want to reduce either by automating them away, offshoring them, or doing a mix of both.
The reality is that perfection is the enemy of good, and this requires both Engineers and PMs working together to negotiate on requirements.
If this does not happen at your workplace, you are either working on a cost center feature that doesn't matter, you are viewed as a less relevant employee, or you are working at a bad employer. Either way it is best for you career to leave.
In my experience, if you've actually chatted with executive leadership teams in most F500s, when they are thinking about "AI Safety" they are actually thinking about standard cybersecurity guardrails like zero-trust, identity, authn/z, and API security with an added layer of SLAs around deterministic output.
But by being able to constantly interate and experiment, companies can release features and products faster with better margins - getting a V1 out the door in 1 sprint and spending the rest of the quarter adding guardrails is significantly cheaper than spending 1 quarter building V2 and then spending 1 more quarter building the same guardrails anyhow.
Basically, we're returning to the same norms in the software industry that we had pre-COVID around building for pragmatism instead of for perfection. I saw a severe degradation in the quality of SWEs during and after COVID (too many code monkeys, not enough engineers/architects).
i think that is the ideal situation, but i am probably a bit pessimistic from my experience; i feel like people will experiment more but it will be more like throwing things at the wall to see what sticks instead of more focused customer research (by devs or pm/pdms alike)... anyways just my feels...
> reality is that perfection is the enemy of good
not to take too much from your point, but i would slightly modify this to something like "perfection is the enemy of good but good can be the enemy of what is needed"; we should know what the customer needs and build that, not just something (more) good... sorry for the pedantry lol we are probably not disagreeing here but anyway
AI assisted coding is going to make it easier to create software. Developers will be more productive. Non developers will be able to create some stuff.
What this means is that very simple apps will become easy to create quickly. So a todo manager is probably not going to be a very successful business. You’ll be competing with many many people and it will be commoditised.
But ultimately what happens here is the “complexity threshold” of a sufficiently complex product needed to make money will be raised. Existing products will become more sophisticated or, if there is not more “sophistication ladder to climb” then they will be commoditised.
There’s just no way people are going to vibe all their software, that’s a very self absorbed nerd take. But on the supply side we’ll see commoditisation, price drops, and increasingly good value for the user as features are shipped faster.
I also think that software quality is really going to tank, because using validation to test the output of Claude is not a good way to ensure quality or correctness. It’ll get you some of the way but you need powerful reasoning. The most obvious evidence for this is security flaws in AI code. We’ll see a new era of enshitification caused by AI code. Like outsourced manufacturing though, people will buy worse stuff at a cheaper price. That makes me sad, because I thought we were on a path to better software, not buggier software.
I just recreated most of Linear for my company in a few days. Making it hyper specific to what we want (metrics driven, lean startup style).
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.
I don't understand this because who's gonna maintain it in the future? Surely that costs more to pay even one person to add features that Linear had than to pay Linear themselves. I'd do this for personal projects but never for my work company lest I be the one to maintain it indefinitely on top of my current work.
one thing annoying with premade solutions is that it only does 90% of what you want, its livable but still doesn't quite meet your needs.
Its not just adding features that Linear already provides but adding features and integrations that mets 100% your needs.
The full decision making equation is (cost of implementing it yourself + cost of maintenance + 10% additional benefit for a solution that fully meets your needs) versus (cost of preexisting solution that meets 90% of your needs). Cost of implementing it and cost of maintenance has just gone down. Surely that will mean on a whole more people as a whole will choose to make inhouse rather than outsource.
Thus demand for premade solutions will go down, Saas providers won't be able to increase their prices as this will make even more people choose to implement it themselves. The cost of producing software will continue to drop due to agentic coding and maintenance cost will drop as well due to maintenance coding agents. More people will choose their own custom solutions and so on. Its very possible we are in the beginning of the end for Saas companies.
It seems to be premised on the idea we would vibe code a replica of what we get from SaaS. But the real point is, we would not do that. We would vibe code something that exactly fits our business.
We have products we're paying $100k a year for and using 3% of the functionality. And they suck. This is the target.
Using non-deterministic LLMs to vibe code applications is a “workshop” activity - meaning it is iterative and the greater the complexity, the more complex it is to workshop the fixes. At some stage you realize that while you’re blown away by how sophisticated the LLM is, playing go-fish with it is a larger time suck than you expected. It’s like being asked to read a friend’s term paper only to find it’s beyond saving and you just say “good job”. Now scale this up to ever evolving, highly complex systems that have to work with five-nines regularity. When we don’t need the humans to workshop the fixes, things will be different.
> "You have this innovation bazooka with these models. Why would you point it at rebuilding payroll or ERP or CRM"
They invested in ERP/CRM? I built one (fairly complete to the German/Italy/EU tax system) and it saves a ton of money vs commercial offerings. So yeah, of course we will.
All these articles seem to think people will vibe code by prompting:
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.
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.
I think something like an x86 -> ARM change is perfect example of something where LLM assisted coding shines. lots of busywork (i.e. smaller tasks that don't require lots of context of the other existing tasks), nothing totally novel to do (they don't have to write another borg or spanner), easy to verify, and 'translation'. LLMs are quite good at human language translation, why should they be bad at translating from one inline assembly language to another?
Yeah. Lots of busywork where if you had to assign it to a human you would need to find someone with deep technical expertise plus inordinate, unflagging attention to detail. You couldn’t pass it off to a batch of summer interns. It would have needed to be done by an engineer with some real experience. And there is no way in the world you could hire enough to do it, for almost any money.
I’m not worried about the personal character of diligence. I’m interested in what the technology unlocked and how things made with it are materially different in terms of labor configurations.
If you're trying to automate all coding activity, writing tests is coding activity. Arguably the greater fraction of effort between implementation, and verifying said implementation. If the only thing making your problem space tractable for the automation to be able to replace the lesser half of coding activity is an authored test suite you couldn't generate via your automation, then you really need to admit that.
"Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles. Spent quite a few years as a dedicated tester once I developed the knack for it. Everybody gangsta til it's time to prove the damn thing works.
> "Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles.
Here it’s a climb-down. Writing tests to validate translation is orders of magnitude less work (and less likely to fail or be too dull to do properly) than the alternative available prior to 2025.
The fact that they wrote tests and clearly established operational control is not some kinda gotcha! It’s how they managed to get this piece of technology to allow them to do the IMPOSSIBLE.
I am just really struggling to understand someone who reads that paper and thinks “yup, everything is still the same and we don’t need to re-evaluate any ideas” Like, if you want to say that they still need engineering discipline in order to do ISA transitions at scale then…ok? That’s true? But Gemini meant that this formerly impossible thing was now not only within reach but done.
Exactly, if the engineers know where to look for the solution in open-source code and point the AI there, it will get them there. Even if the language or the tech stack are different, AI is excellent at finding the seams, those spots where a feature connects to the underlying tech stack, and figuring out how the feature is really implemented, and bringing that over.
The value in enterprise SaaS offerings isn't just the application functionality but the IaaS substrate underneath. The vendor handles server operations, storage, scalability, backups, security, compliance, etc. It might be easier for companies to vibe code their own custom applications now but LLMs don't help nearly as much with keeping those applications running. Most companies are terrible at technical operations. I predict we'll see a new wave of IaaS startups that sell to those enterprise vibe coders and undercut the legacy SaaS vendors.
I've been confronting this truth personally. For years I had a backlog of projects that I always put off because I didn't have the capacity. Now I have the capacity but without the know how to sell it. It turns out that everything comes back to sales and building human relationships. Sort of a prerequisite to having operations.
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.
Sensible people would do that (asking for just the features they need), but look at us, are we sensible?
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.
So maybe the saas will pivot to just sell some barebone agents that include their real IP? The rest (UI, dashboards and connectivity) will be tailored made by LLMs
There was a short moment in history where it seemed that the sentiment was: people will soon 3D-print 99% of their household items themselves instead of buying them.
You absolutely could print things like cups, soap holders, picture frames, the small shovel you use for gardening, and so on an so on.
I think some or maybe even many of those shortcomings will apply to software, too. Making actual good software is not as trivial as writing “make me an app”, much as making an actual good spoon is not as trivial as throwing an STL at a printer and calling it a day.
I'm curious about your reasoning. Jira/Trello etc. are like $10/mo/seat, why bother rewriting them from scratch? You'll spend more in tokens doing so. Same for gmail/google calendar, what's the ROI? Those tools are reliable and cheap, why bother creating your own?
jira/trello: ergonomics. to set them up correctly exactly the way i want would take me 20 hours (or hire a PM), i can vibecode for 20h and get the same result.
plus, being able to crossref internal data types is chef's kiss.
im paying for claude pro so it's use it or lose it. when i finish everything and have it battle tested i can end my claude code. and anyways when i have 10 employees, it's parity.
for gsuite: i want to own everything internally eventually ans having internal xrefs will be nice. the gsuite data is incidental, what is truly valuable about gsuite is spam detection and the oauth capability
Sometimes value is not in the code or the product. But the fact that leg work is done and something is generally accepted for the purpose. For me it looks like type of product where the pain is not making the software. It is getting everyone you will deal with to agree that software is acceptable.
the common factor was sort of left as an exercise to the reader to think about moats in the age of AI... but basically anything that has touchpoints to the legal and financial systems im not gonna touch with a 20 ft vibecoded pole.
Arguably it does, because being able to experience something gives you much more insight into whether it's right or not - so being able to iterate quickly many times, continuously updating your spec and definition of done should help you get to the right solution. To be clear, there is still effort involved, but the effort becomes more about the critical evaluation rather than the how.
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.
If you’re able to articulate the issues this clearly, it would take like an hour to “vibe code” away all of these issues. That’s the actual superpower we all have now. If you know what good software looks like, you can rough something out so fast, then iterate and clean it up equally fast, and produce something great an order of magnitude faster than just a few months ago.
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 was trying to formulate my argument to disagree with the "cost center" thinking in https://news.ycombinator.com/item?id=47107553, until I saw this comment. Now I feel that 'alephnerd might be right after all.
> (...) ops (...) a bunch of scripts to manage deployments.
Devops is prime example of work to be minimized and ultimately eliminated entirely by automation. Yes, it's a complex domain rich in challenges and there's both art and skill to do it right, but at the same time, it's also not the thing we want, just the thing we have to do to get the thing we want, because we can't yet do better.
The post you’re r replying to gets this right- lead time is everything. The fast you can iterate, the more likely that what you are doing is correct.
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.
Of course it needs human supervision, see IBM 1979. Oversight however doesn’t mean the robots wait for approvals doing r&d and that’s where the magic is - the magic being robots overseeing their training and improvement of their harnesses.
IOW only the ethics and deployment decisions need to be gated by human decisions. The rest is just chugging along 1% a month, 1% a week, 1% a day…
This is what always confused me about VC AI enthusiasm. Their moat is the capital. As AI improves, it destroys their moat. And yet, they are stoked to invest in it, the architects of their own demise.
> If AI gets so good that it can replace all human labor, will capital like money and data centers be the only moat left?
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.
Money is useful mostly for hiring human labor to outcompete others, e.g. Satya Nadella has 100K employees under his command, you don't, so you can't realistically compete with MS today - this is their main moat.
If AI renders human labor a cheap commodity (say you can orchestrate a bunch of agents to develop + market a Windows competitor for $1000 of compute), what used to be "Satya + his army vs. you" now becomes mostly a 1:1 fair fight, which favors the startup.
The incompetent have always pantomimed the competent. It never works. Although the incompetent will always pay a huge amount to try to achieve this fantasy.
The buy vs build discussion has dramatically changed with GenAI. Some enterprise systems need to remain vendor based, but there’s a ton of space for mid-size and smaller companies to build and maintain their own systems and tons of software that were excel apps could be fully realized departmental systems.
That's a short term view. Any system you build inhouse has to be maintained until you replace it, and often the longer it remains in place the harder it is to do that. You might save a small amount of cash (which might be important at the time tbf) but you're creating a major headache for later. Legacy code is debt, and that includes all your code. It's also a huge problem if the maintainer leaves because typically those small systems are owned by an individual dev who set it up in the first place.
Everyone who founds a company needs to remember that they're building a system of systems that all interact and influence each other, and you have to balance short term cash flow against long term strategy.
> It's also a huge problem if the maintainer leaves because typically those small systems are owned by an individual dev who set it up in the first place.
It's not uncommon that this maintainer actually wants to get away from maintaining this code, and would actually be quite willing to teach some successor how everything works.
The problem is that it is often hard to find someone who is similarly passionate about this system (often the system only keeps working because the original maintainer invests a lot of energy into keeping it alive), and is thus brutally willing to learn this system inside out. You can't force this mentality from above: either a suitable programmer has this mentality or he is typically not suitable.
I don't understand why you appear to be downvoted for this (your comment is faded at the time I'm reading this). It sounds like a perfectly reasonable take.
I've certainly inherited and also caused these problems in my younger years.
Sorry, this take just shows that you probably are not running a business. Having someone dedicate their whole business to a solution to one of your problems will most likely get a better result than you doing a hackjob you can't even maintain. Let alone the maintenance, logistics, complexity, time etc. The economics just aren't there to vibe code even more than 30% of the software you use.
People running businesses want to focus on their core business and are happy to pay for pain points to go away, for money to come in or less money to come out. It's that simple.
I’ve been a consultant to fortune 100 companies throughout my career and the amount of pain they willingly endure supporting Excel, Access, and .NET/Java applications is astounding. The desire to eliminate these things is high, but there’s no political will over cost and appeasing departmental management.
I think GenAI opens Pandora’s box and all of these decisions change.
Yeah, and we'll see them fail trying to roll their own excel. It's such a stupid economic decision to even think of that ... I can't even. So I heavily disagree, still. Software doens't need to be perfect, it needs to be good enough and the economics need to work.
You sound like a salesman. Small business will always choose 1 hour free "hack" fix, over $50k solution with "complexity, maintenance..". Shitty python script with DuckDB running locally on laptop, can get you long long way.
If someone chooses the 1h free hack, sorry, you're doing business wrong and focus on the wrong things. A mindset that keeps you small. You gotta invest in stuff that makes you money and solves your problems. If that's what makes me sound like a salesman, again, I don't think you own a business as well or are struggling to make a living with that.
Theres a whole lot between "I waste my time and do non-scalable things" and "I need an enterprise contract as a SMB".
> Shitty python script with DuckDB running locally on laptop, can get you long long way.
Yeah ... no. You do you, but if you want to get your business to a good size you need proper tools. Like a chef needs a good knive, your business needs good tools as well. That's not to say that a quick DIY integration is off the table, but the one thing you don't get back is time, not money. So when you waste time by doing shit that can go away with minimal investment, you're preventing your business from getting traction.
Sorry but that's a coder mindset. "I can do this myself". That's what's keeping you stuck. You need to think about every decision as an investment. Time vs money. What's the ROI for all alternatives? Then you decide on what moves the needle. It's that easy.
The calculation is simple: every minute you do stupid stuff like coding shit, you can't sell to someone paying you to make things. So you lose twice by doing something yourself: a) you can't sell your services or time in the mean time and b) you add complexity and maintenance to your very complex business life as well. For me, the biggest problem is too much to do and not enough time. So to scale my business I need to reduce complexity. If I can throw reasonable money for that to go away: good, I'll do it. Most business owners I know think like that. That's business, not sales.
There are so many good SaaS for cheap or even with a good free tier that get you started that it's just incredibly junior to just build it yourself.
A few reasons, "AI" as used by non-experts often has correctness and security issues. Even when it doesn't, its outputs are often not reproducible/predictable because they're probabilistic systems.
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.
Some of that latter part depends on how good and cheap open weight systems get. The ability to deploy your own will strictly limit the price of closed models if they aren't dominant in functionality.
a lot of low level ops stuff is going to be eaten up imo. half the bullshit you have to deal with is integrating data across every platform you are using or other supposed products to help you integrate the integrators lol. i guess if you're a huge company with 1000s of people this is an inherent problem anyway, one you can spend millions of dollars on.
it's not just "replace snowflake", there are a lot of times i wish i could build a very focused thing to accelerate some of our internal workflows and the nocode solutions either were too simplistic that you ended up spending just as much time trying to wrangle some generic solution to your own use case. OR it was not worth throwing significant engineering resources behind internal ops stuff. now that barrier is dropping fast and it's feasible for us.
whoever can create the framework/tooling for people build their own systems will win this, but i don't think it's something that can be "productized" like a saas.
>> Anish Acharya says it is not worth it to use AI-assisted coding for all business functions. AI should focus on core business development, not rebuilding enterprise software.
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.
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 have thought about this a lot, and I have no idea. I work for an "AI-first" company, and we're kind of required to use AI stuff as often as we can, so I make very liberal use of Codex, but I've been shielded from the interview process thus far.
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.
Let's just look at Dijkstra's On the Foolishness of "Natural Language Programming". It really does a good job at explaining why natural language programming (and thus, Vibe Coding) is a dead end. It serves as a good reminder that we developed the languages of Math and Programming for a reason. The pedantic nature is a feature, not a flaw. It is because in programming (and math) we are dealing with high levels of abstraction constantly and thus ambiguity compounds. Isn't this something we learn early on as programmers? That a computer does exactly what you tell it to, not what you intend to tell it to? Think about how that phrase extends when we incorporate LLM Coding Agents.
| 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
All of you have experienced the ambiguity and annoyances of natural language. Have you ever:
- 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)
Congrats, you have experienced the frustrations and limitations of natural language. Natural language is incredibly powerful and the ambiguity is a feature and a flaw, just like how in formal languages the precision is both a feature and a flaw. I mean it can take an incredible amount of work to say even very simple and obvious things with formal languages[1], but the ambiguity disappears[2].
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?
[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.
It's extra sad because they would be more profitable if they recognized this.
Sometimes I wonder why companies are so resistant to making profits. It can be really strange. To be so profit focused yet throw away so much just because it is a bit more effort or a bit slower. But I guess most people are penny wise and pound foolish.
> It's extra sad because they would be more profitable if they recognized this.
definitely. its just a guess but probably many businesses look at long-term as unknown risk and would rather have the short-term profits now cause who knows whats happening in 5 years... after working at a few large places thats the vibe i get anyways...
> Vibe Coding has its uses and I'm sure that'll expand, but the idea of it replacing domain experts is outright laughable.
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.
> 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.
It never worked because a lot of times, domain experts are stuck in their ways of doing things and the real innovation came from engineers learning from domain experts but adding their technically informed insights on the recipe to create novel ways of working.
A Lotus 1-2-3 vibecoded by a Product Manager in 1979 would probably had a hotkey for a calculator.
> The argument I'm seeing most is that most of us SWEs will become obsolete
That is equivalent to "replacing domain experts", or at least was my intent. But language is ambiguous lol. I do think programmers are domain experts. There are also different kinds of domain experts but I very much doubt we'll get rid of SWEs.
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.
I know I'm shooting myself in the wallet here, but I honestly don't think that SWE is an "essential" domain. To explain, as one who has taken relational data modeling classes, it's obvious to me that everything that can be spoken about can be treated as a "domain", but if you'll allow me the terminology, I think that some are "essential", and others are "accidental".
I believe that business analysis and computer science are essential domains, of (respectively) properly defining the logical/mathematical constraints of problems, and of understanding what it means to solve such problems. But software engineering is "accidental", in the sense that no one other than us in the industry actually cares about what we do, but rather only about their use-cases implemented; what we do is just implementation details.
I don't have a magic ball, but I wouldn't be surprised if in a century, (human) software engineering goes the way of the switchboard operator, elevator operator or knocker-upper.
Dijkstra also said no one should be debugging and yet here we are.
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.
Given how you're implying things, you're grossly misrepresenting what he said. You've either been misled or misread. He was advocating for the adoption and development of provably correct programming.
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
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.
Yes, I even provided the source...
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
Either I did or didn't. What is not in question is that I provided a source.
> I read what you wrote, pal.
Forgive me for not believing you. I linked a source and you made speculations about what was in it. If you can't bother to read that then why should I believe you read anything else? Reading requires more than saying the words aloud in your head. At least if you want to read above a 3rd grade level. Yes, I'm being mean, but if you don't have the patience to actually read the comment you're responding to you then you shouldn't expect anyone to have the patience to respond to your rude behavior with kindness.
Please just read what I wrote. Please. You and I are talking about different things. You showed me a source for your claim and then acted like I was somehow misreading your source when I just wasn't talking about it.
We're basically in agreement, but you want to act like you're teaching me something. It's irritating.
One can fully understand that the goal is to write provable programs and yet we do not, we write programs that need debugging. So therefore, I don't think it's hard to imagine that if we get along with that, we may get along with natural language in the control channel, despite that being also proscribed in that vaunted essay you linked to me.
I hear and read so much shit by VCs. Both in LinkedIn and in private meetings. Specially Menlo says a lot of shit (check LinkedIn). Deloitte and McKinsey, also full of crap. Really.
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.
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).
I will not claim to be an expert historian but one general belief I have is that nomenclature undergoes semantic migration over a century. So for the sake of conciseness I will quote the first demand of each portion of the Fascist Manifesto. This isn't to obscure, because it is in Wikipedia[0] and translated in English on EN Wikipedia[1], but so I can share a sample of whether this is something we can relate to our present day political orientation. Hopefully it will inform what you believe "author of the Fascist Manifesto" to imply:
> ...
> 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.
Sure. They're making a strong claim, but I think they mean "author of the Fascist Manifesto" as shorthand to say Marinetti was an ardent supporter of fascism and Mussolini. His support continued throughout the 30's and 40's, even after the Pact of Steel and the Racial Laws etc, even volunteering to go to the Eastern Front. I think we can say with the benefit of hindsight that the fascists' attempts to ingratiate themselves to the worker's movement were sort of ancilliary to the whole political/ideological project... I mean I'd hope any student of history agrees with that...
I’m not particularly political and am also not a historian but I don’t think it’s necessarily correct to equate the literal text of the manifesto with the principles and practices of fascism.
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.
They don’t make money by being right, they make money by exposing LPs to risk. Zero commitment to insight. Intellectual production goes only so far as to attract funding.
Also... they don't make money by promoting things that are good ideas that make sense. That's why every lucky billionaire tech bro that gets into VC ultimately invests in smart toilets. Ultimately, they just keep putting money into each slot machine they can find until one of them pays out a jackpot. Eventually one of them will make up for all the other losses.
Sadly, this is the most serious comment here. People who are not shocked are people who haven’t seen what a highly educated computer scientist can do in single player mode.
Well, yeah. Vibe coding as in letting AI one-shot an app with a vague description still doesn't work except on trivial, throwaway stuff. But... spec-driven development with automated stepwise refinement by agents recursively generating, testing, and improving the code is how software engineering is done in the late 2020s.
You write that in italics as if to imply it’s a law that cannot be questioned. Quite a number of shops do not engineer software like that, or only engineer software like that where it fits the environment the software lives in, or otherwise sit at numerous points along the gradient between “software engineering as it has been known for decades” and “fully computer generated software”.
The laws of scale are stone cold bitches, and so you really don't need a weatherman to tell which way the wind is blowing. By 2030 writing code by hand in an IDE will almost certainly be a curiosity for retro enthusiasts, like programming a C64 in BASIC is now. The field as a profession will be unrecognizable and, as things become more automated and even self-improving, have far fewer people working in it, by 2030.
> "You have this innovation bazooka with these models. Why would you point it at rebuilding payroll or ERP or CRM"
Most SaaS companies are just expensive wrappers on top of existing tools. For non-VC-funded companies, SaaS tools are a serious cost. If you can re-create them in-house with AI, why wouldn't you? The result is saving capital (which you can then employ to do the more innovative things), and being in control over your own data.
Even a16z is walking this back now. I wrote about why the “vibe code everything” thesis doesn’t hold up in two recent pieces:
(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..
The best take I've seen on the whole `AI will replace all devs' is a way for big tech to walk back the disastrous over hiring they did around Covid without getting slaughtered in the stock market.
I don't understand this take. The market tends to positively value layoffs.
However, admitting to have massively over hired and wasted a lot of money does not make the management involved look good. No one wants to admit they made a massive blunder.
The market doubly rewards companies that lay off workers and have a story about how they're automating everything with AI, even if that story is just a story.
> investors are simultaneously punishing hyperscaler stocks because AI capex might generate weak returns, while destroying software stocks because AI adoption will be so pervasive it renders all existing software obsolete. Both cannot hold simultaneously.
I don't understand this point. Can't it be possible that the ultimate effect is to devalue, hugely, software? As in it can totally both be true that AI capex has weak returns and at the same time most SaaS companies go bankrupt. To take an analogy: if ever we manage to successfully mine asteroids, and find some vast quantity of platinum, it could both be true that every existing platinum miner loses their shirt, and also that the value of platinum sinks so far that the asteroid mining company cannot cover its costs.
SaaS companies were just overvalued. They had crazy multiples. Not even an AI thing.
It is an AI thing though. AI makes it far easier to create bespoke software targeted at narrow specialized domains, which is the mainstay of modern SaaS. We'll probably see "proper" FLOSS expand into these sectors too, such that the software won't be simply a matter of internal vibecoding by any single business - instead, the maintenance work will be shared.
AI makes it easier to create something, but that thing is not enterprise software with support contracts and conformance to mandatory regulations and 4 hour bug turnarounds and real people on the end of the phone who understand how it works.
Sometimes I just wonder at how HN has no idea what enterprise software involves.
With this kind of niche sector-specific offering, creating a prototype that works properly for what the industry needs is the main hurdle. The rest is just the same sort of ordinary software engineering work that applies to any FLOSS project already - and we know that FLOSS (with optional 3rd party support covering "enterprise" needs) is quite viable.
I don't see AI easily creating a DataDog. You need it for reliability for example.
You can always also deploy open source since forever. What happens when it randomly drops logs or changes the text? If you get an alert and it is noise it starts becoming pointless.
And yet these type of stocks were at 50-100x earnings etc.
> Benedict Evans called me out on LinkedIn for this take, which I take as a sign the argument is landing.
Excellent. And correct lol.
[flagged]
How is AI code generation a "innovation bazooka"? Last time I checked, innovation required creativity, context, and insight. Not really fast boilerplate generators.
AI allows innovative people to create more innovations by reducing a lot of the non-innovative grunt work in an efficient manner. It isn't the AI doing the innovation, but allows innovators to focus more on innovating.
Or at least that is the theory. It is certainly true from observations of those around me. It also scales well. Even someone a bit innovative gets a multiplier by using AI intelligently. Those that just focus on the grunt work are the ones in trouble.
> Even a16z is walking this back now. I wrote about why the “vibe code everything” thesis doesn’t hold up in two recent pieces:
The next one a16z should walk back on is "AGI" given that they have just admitted that "vibe code everything" was just a sign of them being consumed by the hype.
All that is correct and well-written, however I fear in most cases "good enough" will be good enough for Business. If Business can do something to 80% the same but with a large cost cutting they likely go for it, we have seen this with shrinkflation (reduced portion sizes for the same price), to using cheaper ingredients to practically everything that is not a knowledge-heavy industry. The big change is now the "shrinkflation" is coming to knowledge domains too, which will likely lower the quality of healthcare, software etc.
AI being a next-token predictor will produce cheap and average products, we will likely see some (most?) software become a commodity, that goes through the same product development and "manufacturing" as a breakfast cereal. Made in a "dark factory", 24/7, with little supervision.
However I think down the line we will see many industries popping up that are like "organic food", "mechanical watchmaking" that provide above the usual slop that large businesses produce.
Using vibe coding to build a small specialized tool for a small company that can be used instead of single feature of a commercial SaaS is doable and brings value.
Using vibe coding to build something to replace an enterprise SaaS offering for a medium to large company is not something to be taken lightly. The tool and the code is not everything. The operating environment, security guarantees, SLAs, support, and a bag of features you don't need today but might tomorrow is what the SaaS offerings bring to the table.
Imagine that I run a really good software house. I can literally build anything you want, feature wise, better than most. I do it quickly. You come to me and say you want to replace Slack for your team of 200, because Slack got too expensive. I say I can do it. Because I am feeling generous and you're my good friend, I will do it for free. However, I will just give you the code, a CI/CD script, and a README.md file. I will disappear and will not maintain or support your software, nor will I give you any guarantees on how well it will work, other than a "trust me."
I wouldn't take the offer.
The question is how much further and faster can these tools evolve.
Right now, you may not be faced with a valid choice to vibe code your own hubspot, but maybe some contractor firm will do it for you and sell an ultra low cost version.
Will opus 6 do the same thing without the contractors while managing the deployment and maintenance as a claw?
As with cold fusion, I think the answer is "it will happen", but no one can predict how soon.
The Matrix folks have covered the "replace Slack internal chat" case already. They will give you the code so that you can bring the service up internally, or you can use any 3rd party hosted solution that provides the usual support and "enterprise" guarantees, for a price. Why can't this model generalize to sector-specific SaaS offerings that can now be prototyped cheaply via AI vibecoding?
Zulip is an actual slack upgrade
Or Mattermost, or Rocket.Chat, or... there’s tons of alternatives now. That’s not the point.
As much as the Slack UX has somewhat enshittified at this point, the UX of Matrix is still so so so far behind Slack that it's often not even worth considering.
I hear Zulip could actually be a real alternative, though I have no experience with it.
People are overestimating the value on having AI create something given loose instructions, and underestimating the value of using AI as a tool for a human to learn and explore a problem space. The bias shows on the terminology (“agents”).
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.
Because that would mean AI isn't going to replace entire industries, which is the only way to justify the, not billions, but trillions in market value that AI leaders keep trying to justify.
Exactly my thoughts - the value in AI is not auto-generating anything more than something trivial, but there's huge value in a more customized knowledge engine - a targeted, specific Google if you will. Get answers to your specific question instead of results that might contain what you were looking for if you slog through them.
AI is hugely beneficial in understanding a problem, or at least getting a good overview, so you can then go off and solve/do it yourself, but focusing on "just have the AI generate a solution" is going to hugely harm AI perception/adoption.
> AI create something
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.
Problem space is rich. The thing doesnt actually know what a problem is.
The thing is incredibly good at searching through large spaces of information.
42
Not sure what you mean by that lol
The answer.
[flagged]
[flagged]
Don't post AI slop here please.
I normally would not, as is evidenced by my comment history.
However, in this one case, it seemed approporiate.
Right! It's like maybe the AI is more of a threat to the accounts payable person than the accounts payable software. At least in terms of head count.
100% agree. I’d add we are underestimating our contributions in making the code agents do the right thing as well.
I once built a CRM in Google Sheets fully mirroring the data model of Salesforce. For contact, company, deal, and call tracking for a one sales rep business. (Before XLookup was in Google Sheets)
Did it work? Yes. Was it worth my time to maintain and scale the “platform” with the company rather than outsource all that to a CRM company? Not at all.
Time is finite. Spend your time doing what you do best, pay others to do what they do best.
Yup, my experience has been that vibe-coding is very time-consuming. It reminds me very much of how LLMs are great at creating mind-blowing images, but you get what you get. Once you decide that you need to modify the image you get, it becomes a time sink. You might be able to change it and get what you need, but there is no guarantee and it's a never ending task.
The same thing happens with code; you may get great results from your prompt, but trying to customize it will drive you nuts and you may never get what you want.
Maintenance is another hurdle. How do you maintain code you might not have the skills to maintain?
Vibe-coding may reduce software creation time, but it's not taking over software engineering. The SaaS business is going nowhere. Most people, by far, will continue to rely on someone else for their software needs. But be very aware that the software business will change. We are seeing that already.
It doesn't make sense for every company to make their own Salesforce clone.
The key is that it makes new companies entering the market to compete with Salesforce immensely easier. More competition will just force lower overall margins in SAAS.
It's not really that hard to make a Salesforce clone now though. Writing the software was never the hard part of building a business.
> Writing the software was never the hard part of building a business.
This is such an important key insight that will take the vibe coding folks another few years to really internalize.
> few years to really internalize.
Given that many engineers have never internalized this, you’re more confident than I am.
I don't know, I mean for most SaaS products this is true. But for something like Salesforce, the feature set is incredibly broad. The coding is not hard, so much as it is just an enormous volume of code.
It was never the only hard part, but it definitely was a hard part (at least in most cases; obviously there are some monopolies with relatively simple software - mostly where there are network effects like WhatsApp).
But give me the source code for something competitive with Solidworks, Jasper Gold, FL Studio, After Effects, etc. and I'm sure as hell making a business out of it!
Furthermore while good software may not guarantee business success, it is pretty much a requirement. I have seen many projects fail because the software turned out to be the hard part.
Yeah, but its still usually cheaper to pay for software than build and support it. I think that will be true for a long time going forward, its just that you can't plan on extracting a ransom for your SAAS.
Salesforce literally has its own query optimizer, you are vastly underestimating the complexity of its software.
But a query optimizer only matters once you have an established business with large customers.
You seem to be implying Salesforce’s business is successful because they have their own query optimizer. But the causality is reversed. Salesforce has their own query optimizer because they’ve built a successful business.
Thought exercise for those in disagreement: why would every company use AI to build their own payroll/ERP/CRM, when just a handful of companies could use AI to build those offerings better?
This is largely how things work now; AI may lower the cost and increase margins, but the economics of build vs buy seem the same.
To avoid CRAZY SaaS charges. I left a comment further down about how the challenge is first getting a reliable stack running underneath whatever ends up being fast-coded. The trend will be more decentralization - I think that'll be AI 2.0. Increasing centralization is AI 1.0.
But if that was a goal, or a marketable feature, SaaS and cloud would have competitors out there selling software with perpetual licenses to be run on premises
Yes, the vendors want subscriptions and cloud and not owning anything, but customers also don't want to hire people to operate the infrastructure required to run this stuff themselves. That's the whole point of SaaS, and why some companies just run entirely on that model and basically have no in-house IT staff
That AI means you can write and run your own payroll system doesn't mean all of a sudden a world of people with zero technical skills can start doing it on their own
...unless they have an agent "IT Guy" who can either do it for them or show them what to do. Perhaps UIs will change and be designed half for a human operator, and half for the IT Guy to copilot with them.
The person with zero technical skills could start learning primitive technology: youtube.com/@primitivetechnology9550 - living off the land really is the job for the unemployed. We've done it before! As long as there is a safe place to actually do it and a planet that can support it. Those'll be the problems.
Every company that I’ve worked at has had to do significant additional development work on their instance of salesforce to make it work for them. Like 6-12 months of work with 1-3 people. I don’t know if this is common but in that case maybe going custom might be the way to go. You get something lean, without all the cruft, specifically built for your usecase and nothing more.
Well the answer is because the cost of that software is lower than somebody building the other software. What happens is that all these SaaS drop in value because it is now realistic to build them internally
Why does AI make it cheaper to build internal but not cheaper for SaaS competitors to pop up? Everyone has access to the same tools.
Oh sure! My conclusion is that they will drop in value, not disappear.
Basically I expect way smaller companies popping up competing with the big ones and their offering will be priced way lower because their payroll is way smaller.
While there is no competitor, internal tools will pop up now.
I believe that. Companies will build cheap tools today while competitors are spinning up to undercut ADP, Salesforce, and SAP. But what happens tomorrow? There are plenty of examples in IT today where the reasonable option is to outsource in 90% of cases: don’t roll your own auth, don’t host your own email server, don’t build your own data center. I don’t see how AI can change that, when the people who build specialized software also have access to AI.
Another great example is open source. I think PostgreSQL being free and usable by everyone is a more economic outcome than every Fortune 500 company building their own database engine. Payroll, ERP, and CRM fall into the same category of being commodity software in a lot of cases.
My experience is that the folks in charge of spending and making decisions are looking at AI as another means of outsourcing. Payroll, ERPs and CRMs went from commodity software to subscription services and anything that is subscription based is getting scrutinized much more heavily now.
It does make it cheaper, obviously. But the barrier to entry is almost zero, like panhandling. That's why it can't substitute a job.
Slack is a good example. When the cost of Slack is an unreasonable amount of your operating costs then it makes sense to clone and maintain. The product is simple, you can basically recreate the main functionality in a sitting. Why would you pay hundreds of thousands of dollars for it?
That’s a fine example, but my question then is why does Slack exist? Surely Fortune 500 companies are smart enough to realize that building a slack clone is cheaper, yet they don’t do that.
So now consider AI, perhaps the cost of building has decreased from 100k to 10k. What stops a Slack competitor from also building the product for 10k and reselling it at 10% of the cost of Slack? My point is that I don’t see how AI has changed the value prop.
> my question then is why does Slack exist?
I do not actually believe that you can trivially vibe code a viable slack replacement. But even if one day we could it wouldn’t mean that Slack as a company would just disappear overnight.
They would hang around serving companies who haven’t got the memo yet, or who are locked in a contract, or where the internal political situation is against such a move. The innertia of a bunch of humans behaving like a bunch of humans would provide a sort of “coyote time” effect where the fundamentals could fall out from under Slack yet the company would keep “floating” for a while.
It is funny how much of your question sounds like the old joke where an economist can’t believe their eyes that a $20 bill is laying on the pavement, because surely if it were so someone would have already picked it up. In a steady state the logic might hold up, but we are not in a steady state.
And that is separate from why do I think it is not realistic to just replace slack with vibe coded alternative: just in my company some people use the web interface, some the ios app and some the android app. To be a viable replacement you would need all 3 platforms supported with all features. That sounds in itself a nightmare. Then figuring out what features my company members really use is an other nightmare. There are some who craft custom emojis all the time, some who integrate all kind of weird apps. We various CI and data pipeline processes integrated with slack reporting. And then comes huddle. Video and voice chat and screen sharing. You can even draw on someone else’s screen with it! IT has their needs to archive things (maybe?) or snoop on certain things. Then comes of course interfacing with single-sign-on. I wouldn’t even volunteer to enumerate all the different features people just at my company depend on, let alone offer to replace it.
Is it the sla and maintenance cost ? As silly as it seems it is important for slack to work reliably, especially in case of court orders and legal retention.
Also Is there not a self hosted open source solution that companies can host ? That’s easier than ai?
There is value in taking a product to market and hardening it, and no one wants to invest in something that requires headcount for cost-savings. They want upside. But if it doesn't require headcount and/or unlocks functions they have to negotiate for, and the AI can keep it online and troubleshoot, that is a different story.
Slack exists in part because ten years ago it was a lot harder for big orgs to make good/modern software.
Mattermost is FOSS. Why aren't companies running their own servers to avoid Slack? Prior to OneDrive and web integration, LibreOffice was 95% as good as MS Office, better than VibeOffice will likely be, and it still failed to gain much traction.
This is the key point. We've already run the experiment where the code is free and all you need to do is host it yourself and people still didn't opt to do that work. I don't see how AI changes the situation.
I have to imagine that companies pay so much money for Slack because it's actually not that simple.
At the very least, the return is not worth the time and effort.
If Slack is so simple why haven’t companies created their own internal versions 10 years ago?
Every company I worked at in the past 10 years has created an internal version of Slack. Four companies.
I don’t doubt it but that doesn’t negate the fact that Slack as a company exists and makes money by selling software. My question is this: AI makes it cheaper to build software, but ADP, SAP, and Salesforce also have access to AI and could make cheaper versions of their products. How does AI change the build vs buy trade off in a way that eliminates economies of scale? My opinion and that of the article is that it doesn’t.
> How does AI change the build vs buy trade off in a way that eliminates economies of scale?
I think a more likely scenario here is that something good and free escapes containment at some point and Slack’s core product just kind of deflates. Not something better than Slack, but something good enough that people don’t care about Slack any more.
I don’t see it as a question of whether you build it or buy it, but a question of the time horizon for selling messaging software as a business strategy. Most business strategies have a finite time horizon. How long can you continue to sell messaging software before there are too many competing solutions available and you stop making money from it?
We've already ran this experiment with Zulip and Mattermost. Slack still won.
N=2, no thank you.
Web browsers used to be exclusively paid software, if you were serious. So did operating systems, SQL databases, C++ compilers, and video codecs.
Local software is categorically different that hosted software.
You're too heavily discounting the effort to maintain, deploy, and scale a service like Slack.
Kind of like databases and web servers, then?
I don’t think “categorically different” has legs. I work on the operations & hosting side of applications like this. There’s an operations burden to maintain, deploy, and scale web servers. There’s a burden to rolling out new Linux kernel versions to servers. But we still do it! There would be a burden to running your own Slack, just like there is a burden to running your own email, and people will choose to pay for hosted versions or host it themselves.
And then there are companies and organizations who have strong incentives to self-host to make compliance easier.
I guess to provide a counterpoint to my own comment, even I worked for a company that created their own internal social network similar to Facebook (this was 15 years ago).
Of course it sucked and no one used it except executives and VPs. Everyone else did just enough to meet the minimum quarterly engagement metrics right before performance reviews.
Why don't they sell them?
A list of outcomes:
1. They did, and still sell it. You can buy it.
2. They did, and then exited the market. Employees gradually migrated off the internal platform.
3. They weren’t in the business of selling software, and didn’t sell their internal messaging platform (which is idiosyncratic and closely integrated with other internal system).
Slack is an hilarious example.
I can't wait for orgs to try to vibe roll their own dozen clients, security models, and then try to talk to handle external integrations of some kind.
I mean once campfire is full featured free and easy to self host. Completely open source slack replacement.
I imagine it's also infinitely better than anything an in house team could vibe code.
You don't need AI for a cheap slack alternative.
That's why I don't buy any of this.
Companies are not bothering with the free/open alternatives.
Unless the real power of LLMs is making it easy for greg in HR to self host these existing alternatives. But, that a trillion dollar market does not make.
Anyone who's seen an enterprise deal close or dealt with enterprise customer requests will know this, the build vs buy calculus has always been there yet companies still buy. Until you can get AI to the point where it equivalent to a 20 person engineering team, people are not going to build their own Snowflake, Salesforce, Slack or ATS. Maybe that day is 3 years away but when that happens the world will be very different
Companies do make/buy decisions on everything, it just software. Cleaning services are not expensive, yet companies contract them instead of hiring staff.
This is called transaction cost economics, if anyone’s interested.
We’ve also got to consider the fourth dimension, what happens over time.
Salesforce is getting LLM superpowers at the same time the Enterprise is, so customizing and maintaining and extending Salesforce are all getting cheaper and better and easier for customers, consultants, and Salesforce in parallel.
Unless the LLMs are managing the entire process there’s still a value proposition around liability, focus, feature updates, integrations, etc. Over time that tech should make Salesforce get way cheaper, or, start helping them upsell bigger and badder Sales things that are harder to recreate.
And, big picture, the LLMs are well trained on Salesforce API code. Homegrown “free” versus industry-standard with clear billing, whatever we know versus man-decades of learning at a vendor, months of effort and all the risk & liability versus turnkey with built-in escape goats… at some point you’re paying money not to own, not to learn, not to be distracted, and to have jerks to sue if something goes bad.
I agree generally, but some of these enterprise contracts are eye-watering. If the choice is $2M/year with a 3-year minimum contract, or rolling your own, I think calculus really has shifted.
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.
> If the choice is $2M/year with a 3-year minimum contract, or rolling your own, I think calculus really has shifted.
But why? It was always dramatically cheaper for enterprises to build rather than buy. They stopped doing that becuase they did that in the 90s and ended up with legacy codebases that they didn't know how to maintain. I can't see AI helping with that.
This might be the biggest benefit of AI coding. If I have a large legacy code base I can use AI to ask questions and find out where certain things are happening. This benefit is huge even if I choose not to vibe code anything. It ends up feeling a lot like the engineer that wrote the code is still with you or documented everything very well. In the real world there is a risk that documentation is wrong or that the engineer misremembers some detail so even the occasional hallucination is not a particularly big risk.
> This might be the biggest benefit of AI coding. If I have a large legacy code base I can use AI to ask questions and find out where certain things are happening. This benefit is huge even if I choose not to vibe code anything.
I definitely agree with this.
If you consider total cost of ownership including long-term maintenance costs, it means building has not always been cheaper than buying. I think what's changing is that it's now becoming dramatically cheaper to build AND operate AND maintain "good enough" bespoke software for a lot of use cases, at least in theory, below a certain threshold of complexity and criticality. Which seems likely to include a sizeable chunk of the existing SAAS market.
I can't believe I'm saying this, but I guess you don't even really need to maintain software if it's just a tool you hacked together in a week. You can build v2 in another week. You'll probably want to change it anyways as your users and your org evolve. It's a big question for me how you maintain quality in this model but again, if your quality standard is "good enough", we're already there.
Oh I don't know, I think AI is very helpful at maintaining and modernizing legacy codebases. And in the old days, the "build" option was often not really cheaper once you factored in four salaries for developers to maintain the product. But now…
> Until you can get AI to the point where it equivalent to a 20 person engineering team
I think that’s gonna happen when you don’t need software and AI just does it all.
Exactly. I was building an app to track bike part usage. It was an okay app, but then I just started using ai with the database directly. Much more flexible, and I can get anything I need right then. AI will kill a lot of companies, but it won’t be the software it develops, it will be the agent itself
Do you run the app locally?
If it's not local, I saw this comment: https://news.ycombinator.com/item?id=47085906
"This entire stack could give you computing power equivalent to a 25k euro/month AWS bill for the cost of electricity (same electricity cost as running a few fridges 24/7) plus about 50k euros one-time to set it up (about 4 Mac Studios). And yes, it's redundant, scalable, and even faster (in terms of per-request latency) than standard AWS/GCP cloud bloat. Not only is it cheaper and you own everything, but your app will work faster because all services are local (DB, Redis cache, SSD, etc.) without any VM overhead, shared cores, or noisy neighbours."
Makes me think there will be these prompts like "convert this app to suit a new stack for my hardware for locally-optimized runtime."
How are people building the best local stacks? Will save people a ton of money if done well.
Yep, we'll evolve patterns which facilitate system to system interaction better than the ones we had built for human in the loop by humans. That's inevitable. CRUD apps with a frontend will be considered legacy etc. They'll be replaced by more efficient means we haven't even considered. We live in an exciting time.
> we'll evolve patterns which facilitate system to system
We have! It has different names, shapes and forms. For example WiFi. Last I checked, it’s not designed for human in the loop and you need multiple levels of decoding for a human to make sense of it.
That could be AI 2.0 vs AI 1.0 like what we're in now?
Better and cheaper hardware too. Maybe it'll be DeAI? (decentralized)
Will combine with Crypto 2.0 - whatever that may be.
The only real downside is we will collapse society but that's a small price to pay for progress.
Think of the shareholder value we made!
Speaking of AI taking over the world, have you seen how many projects on ShowHN are using GitHub? Do you think that's by accident or is it trying to normalize a place for an AI to lurk about like a crocodile hanging around a river outlet?
If an AI agent ever became as productive at writing code as a well-organized 20 person engineering team you'd still need to run it for a year or more to replicate any nontrivial SaaS product.
And the thing about many of these products isn't their feature set, it's their stability. It's their uptime. It's how they handle scaling invisibly and with no effort on your part. These are things you can't just write down from whole cloth, they are properties that emerge over time by adapting the the reality of scale. Coding isn't the whole deal, and your 20x clanker which can do nothing but re-arrange text in interesting patterns is going to have some trouble with the realities of taking that PoC to production. You'll still need experienced, capable people for that. And lots of time.
A lot of this "ermahgerd everything will change" drivel is based on some magical fundamentally new technology emerging in the near future that can do things that LLMs cannot do. But as far as anyone knows, that future may be never.
So even given a large improvement in agentic coding I'm not convinced it really changes the build vs buy equation much.
Imagine a 20 person engineering team that hallucinates on a regular basis and is incapable of innovation.
I think you’ve just described an average Accenture setup.
I sort of agree with this, but what a lot of people are missing is it's unbelievably easy to clone a lot of SaaS products.
So I think big SaaS products are under attack from three angles now:
1) People replacing certain systems with 'vibe coded' ones, for either cost/feature/unhappiness with vendor reasons. I actually think this is a bigger threat than people think - there are so many BAD SaaS products out there which cost businesses a fortune in poor features/bugs/performance/uptime, and if the models/agents keep improving the way they have in the last couple of years it's going to be very interesting if some sort of '1000x' engineer in an agent can do crazy impressive stuff.
2) Agents 'replacing' the software. As people have pointed out, just have the agent use APIs to do whatever workflow you want - ping a database and output a report.
3) "Cheap" clones of existing products. A tiny team can now clone a "big" SaaS product very quickly. These guys can provide support/infra/migration assistance and make money at a much lower price point. Even if there is lock in, it makes it harder for SaaS companies to keep price pressure up.
But have you ever tried to clone a product or tool for yourself before? At first it’s great because you think that you saved money but then you start having to maintain it… fixing problems, filling in gaps… you now realize that you made a mistake. Just because AI can do it now doesn’t mean you aren’t just now having to use AI to do the same thing…
Also, agents are not deterministic. If you use it to analyze data, it will get it right most of the time but, once in a blue moon, it will make shit up, except you can’t tell which time it was. You could make it deterministic by having AI write a tool instead… except you now have the first problem of maintaining a tool.
That isn’t to say that there isn’t small low hanging fruit that AI will replace, but it’s a bit different when you need a real product with support.
At the end of the day, you hire a plumber or use a SaaS not because you can’t do it yourself, but because you don’t want to do it and rather want someone else who is committed to it to handle it.
I'm not saying _the end user_ clones it. I mean someone else does (more efficiently with agents) and runs it as a _new_ SaaS company. They would provide support just like the existing one would, but arguably at a cheaper price point.
And regarding agents being non deterministic, if they write a bunch of SQL queries to a file for you, they are deterministic. They can just write "disposable" tools and scripts - not always doing it thru their context.
The challenge to this is that so much of the difficulty in getting people to switch products is trust, and a couple of people running saas with claude code has no differentiation and no durability.
I think it will be a little different: black box the thing, testable inputs and outputs, and then go to town for a week or two until it is reasonable. Then open source it. Too big/complex for an agent? Break down the black box into reasonable ideas that could comprise it and try again. You can replace many legacy products and just open source the thing. If the customer can leave behind some predatory-priced garbage for a solution where they get the code I think they would be a lot more likely to pay for help managing/setting it up.
But isn’t this what the article is saying? Even with AI you’re still not going to build your own payroll/ERP/CRM.
Insightful points!
It would be interesting if, with all the anxiety about vibe coding becoming the new normal, its only lasting effect is the emergence of smaller B2B companies that quickly razzle dazzle together a bespoke replacement for Concur, SAP, Workday, the crappy company sharepoint - whatever. Reminds me of what people say Palantir is doing, but now supercharged by the AI-driven workflows to stand up the “forward deployed” “solution” even faster.
Thanks,yes exactly what I think.
Or an industry specific Workday, with all of workdays features but aimed at a niche vertical.
I wrote about this (including an approach on how to clone apps with HAR files and agents) if you are interested. https://martinalderson.com/posts/attack-of-the-clones/
"You have this innovation bazooka. Why would you point it at rebuilding payroll?" — a partner at the firm whose thesis was literally "software is eating the world."
Apparently the meal is over and now we're just rearranging the plates.
My first thought as well - they suddenly realized they have an interest in AI not cannibalizing their existing SaaS portfolio
One who thinks that complex software can be "vibe coded", hasn't worked on complex codebases.
> One who thinks that complex software can be "vibe coded", hasn't worked on complex codebases.
I do think that I have worked on somewhat complex code bases. The reason why they are complicated is often "political" (e.g. at some point it was decided that this is the way to go, and from then on the specific abstraction was used. It turned out these wishes were not a good idea, but the code was never re-developed with a "more proper" architecture (also for the reason that removing some insanely convoluted feature would anger some users)).
I see no reason why some (hypothetical) AI couldn't come up with a much better architecture (also good programmers are capable of this). The problem is rather "getting this architecture through politically"; for some reason "AI suggested/created it" is much more socially accepted by managers than "programmer X considers this change to be necessary" (I cannot understand why).
it can but it will take one person just as long as a small team without "AI" and that one person will carry all the frustration, doubt, all the to do lists and imaginary pin boards and all that other stuff programmers carry around in their heads, at work and back home. have fun with all that.
side note: indie games are not complex software.
and most "overvalued" and "impossible" and "walking it back now" comments are true in as many cases as they are not true and I really do not understand these commenters. smart people should not fall into the same category as people who think that "nobody cares" because they never met devoted lawyers, investigative journalists and law enforcers passionate about justice AND law. it's all so weird, man ...
> He said that software accounts for 8% to 12% of a company's expenses, so using vibe coding to build the company's resource planning or payroll tools would only save about 10%. Relying on AI to write code also carries risks, he said.
> "You have this innovation bazooka with these models. Why would you point it at rebuilding payroll or ERP or CRM," Acharya said
> Instead, companies are better off using AI to develop their core businesses or optimize the remaining 90% of their costs
The bottleneck will always be humans. You could get AI to write a million lines of code a day, but you’d still need humans to review and test that code. We are a very long way from being able to blindly trust AI’s outputs in production.
I don’t even think it’s about reviewing and testing. The bottleneck will always be humans.
We don’t like to always admit it but most jobs are fairly straightforward, as in the actual day to day tasks. Yes being smart is great and useful etc. but after a certain point it’s diminishing returns on the actual tasks you have to do. Dealing with other humans and their egos and eccentricities and the multitude ways each person sees the world is always what makes all jobs tricky. I suspect this whole ai wave/hype/reality is going to open many people’s eyes to this. We will laugh that we use to call them “soft” skills.
IMO I would have agreed with this statement 2 months ago but now it’s clear AI is already much better at reviewing and even testing code (via spinning up simulators, etc) much better than we can. We’re already using AI’s outputs in production and not writing much code these days.
> how does it know what is correct for what the customer wants/needs?
The way NASA does it so that they can trust deliverables from the lowest bidder.
That is, have developers translate the wants/needs into detailed contracts of work.
Both AI Fanatics and AI Luddites need to touch grass.
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.
The irony is, AI coding only works after and if you put a lot of work on engineering, like creating a factory.
There is a lot of work that goes on before even reaching the point to write code.
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.
ai/vibe coding may make that cycle faster but idk it might actually make things worse long-term because now the race course has rubber walls and there is less penalty just bouncing left and right instead of smoothly speeding down the course to the next destination...
> most requirements (ime anyways) are usually barely half-baked and incomplete causing re-testing and re-work over and over which are the real bottlenecks...
> ai/vibe coding may make that cycle faster but idk it might actually make things worse long-term
By making the cycle faster it reduces the impact while also highlighting issues within the process - there are too many incompetent PMs and SWEs.
Additionally, in a lot of cases a PM won't tell you that you might actually be working on checkbox work that someone needs to do but doesn't justify an entire group of 2-3 SWEs because then you obviously won't do the work. This kind of work is ripe for being automated away via vibecoding or agents.
A good reference for this is how close is the feature you are working on directly aligned with revenue generation - if your feature cannot be directly monetized as it's own SKU or as a part of a bundle, you are working on a cost center, and cost centers are what we want to reduce either by automating them away, offshoring them, or doing a mix of both.
The reality is that perfection is the enemy of good, and this requires both Engineers and PMs working together to negotiate on requirements.
If this does not happen at your workplace, you are either working on a cost center feature that doesn't matter, you are viewed as a less relevant employee, or you are working at a bad employer. Either way it is best for you career to leave.
In my experience, if you've actually chatted with executive leadership teams in most F500s, when they are thinking about "AI Safety" they are actually thinking about standard cybersecurity guardrails like zero-trust, identity, authn/z, and API security with an added layer of SLAs around deterministic output.
But by being able to constantly interate and experiment, companies can release features and products faster with better margins - getting a V1 out the door in 1 sprint and spending the rest of the quarter adding guardrails is significantly cheaper than spending 1 quarter building V2 and then spending 1 more quarter building the same guardrails anyhow.
Basically, we're returning to the same norms in the software industry that we had pre-COVID around building for pragmatism instead of for perfection. I saw a severe degradation in the quality of SWEs during and after COVID (too many code monkeys, not enough engineers/architects).
i think that is the ideal situation, but i am probably a bit pessimistic from my experience; i feel like people will experiment more but it will be more like throwing things at the wall to see what sticks instead of more focused customer research (by devs or pm/pdms alike)... anyways just my feels...
not to take too much from your point, but i would slightly modify this to something like "perfection is the enemy of good but good can be the enemy of what is needed"; we should know what the customer needs and build that, not just something (more) good... sorry for the pedantry lol we are probably not disagreeing here but anywayAs a researcher in formal methods, I totally get you
AI assisted coding is going to make it easier to create software. Developers will be more productive. Non developers will be able to create some stuff.
What this means is that very simple apps will become easy to create quickly. So a todo manager is probably not going to be a very successful business. You’ll be competing with many many people and it will be commoditised.
But ultimately what happens here is the “complexity threshold” of a sufficiently complex product needed to make money will be raised. Existing products will become more sophisticated or, if there is not more “sophistication ladder to climb” then they will be commoditised.
There’s just no way people are going to vibe all their software, that’s a very self absorbed nerd take. But on the supply side we’ll see commoditisation, price drops, and increasingly good value for the user as features are shipped faster.
I also think that software quality is really going to tank, because using validation to test the output of Claude is not a good way to ensure quality or correctness. It’ll get you some of the way but you need powerful reasoning. The most obvious evidence for this is security flaws in AI code. We’ll see a new era of enshitification caused by AI code. Like outsourced manufacturing though, people will buy worse stuff at a cheaper price. That makes me sad, because I thought we were on a path to better software, not buggier software.
I just recreated most of Linear for my company in a few days. Making it hyper specific to what we want (metrics driven, lean startup style).
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.
I don't understand this because who's gonna maintain it in the future? Surely that costs more to pay even one person to add features that Linear had than to pay Linear themselves. I'd do this for personal projects but never for my work company lest I be the one to maintain it indefinitely on top of my current work.
one thing annoying with premade solutions is that it only does 90% of what you want, its livable but still doesn't quite meet your needs.
Its not just adding features that Linear already provides but adding features and integrations that mets 100% your needs.
The full decision making equation is (cost of implementing it yourself + cost of maintenance + 10% additional benefit for a solution that fully meets your needs) versus (cost of preexisting solution that meets 90% of your needs). Cost of implementing it and cost of maintenance has just gone down. Surely that will mean on a whole more people as a whole will choose to make inhouse rather than outsource.
Thus demand for premade solutions will go down, Saas providers won't be able to increase their prices as this will make even more people choose to implement it themselves. The cost of producing software will continue to drop due to agentic coding and maintenance cost will drop as well due to maintenance coding agents. More people will choose their own custom solutions and so on. Its very possible we are in the beginning of the end for Saas companies.
I think even with vibe coding people definitely still underestimate the stuff mentioned in this comment about IaaS:
> server operations, storage, scalability, backups, security, compliance, etc
https://news.ycombinator.com/item?id=47097450
It seems to be premised on the idea we would vibe code a replica of what we get from SaaS. But the real point is, we would not do that. We would vibe code something that exactly fits our business.
We have products we're paying $100k a year for and using 3% of the functionality. And they suck. This is the target.
Using non-deterministic LLMs to vibe code applications is a “workshop” activity - meaning it is iterative and the greater the complexity, the more complex it is to workshop the fixes. At some stage you realize that while you’re blown away by how sophisticated the LLM is, playing go-fish with it is a larger time suck than you expected. It’s like being asked to read a friend’s term paper only to find it’s beyond saving and you just say “good job”. Now scale this up to ever evolving, highly complex systems that have to work with five-nines regularity. When we don’t need the humans to workshop the fixes, things will be different.
> "You have this innovation bazooka with these models. Why would you point it at rebuilding payroll or ERP or CRM"
They invested in ERP/CRM? I built one (fairly complete to the German/Italy/EU tax system) and it saves a ton of money vs commercial offerings. So yeah, of course we will.
All these articles seem to think people will vibe code by prompting:
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.
The right move is this, turned to 11.
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.
I think something like an x86 -> ARM change is perfect example of something where LLM assisted coding shines. lots of busywork (i.e. smaller tasks that don't require lots of context of the other existing tasks), nothing totally novel to do (they don't have to write another borg or spanner), easy to verify, and 'translation'. LLMs are quite good at human language translation, why should they be bad at translating from one inline assembly language to another?
Yeah. Lots of busywork where if you had to assign it to a human you would need to find someone with deep technical expertise plus inordinate, unflagging attention to detail. You couldn’t pass it off to a batch of summer interns. It would have needed to be done by an engineer with some real experience. And there is no way in the world you could hire enough to do it, for almost any money.
You've missed the subtlety here.
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.
I missed the subtlety?
I linked the paper! I read the paper. Yeah. they wrote the tests, which is how this worked! how the heck do you think it was supposed to work?
the fact that they needed to write the tests was just the means to implementation. It didn't change the non-LLM labor economics of the problem.
No, I meant subtlety of definition, you've attributed the diligence to the LLM when in fact it's the tests that provide that.
You've unfortunately committed the big sin of anthropomorphizing the LLM and calling it diligent.
An LLM cannot be diligant, it's stochastic so it's literally impossible for it to be diligant.
Writing all those tests was diligant.
I didn’t attribute diligence to anything.
I’m not worried about the personal character of diligence. I’m interested in what the technology unlocked and how things made with it are materially different in terms of labor configurations.
Lmfao I’ve committed the sin of anthropomorphism.
Fadda forgive me!
C’mon pal.
Who wrote the tests?
The meat wrote the tests. As I've been telling you, they're made out of meat.
And how does the answer to your question bear on the claim I’m making?
If you're trying to automate all coding activity, writing tests is coding activity. Arguably the greater fraction of effort between implementation, and verifying said implementation. If the only thing making your problem space tractable for the automation to be able to replace the lesser half of coding activity is an authored test suite you couldn't generate via your automation, then you really need to admit that.
"Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles. Spent quite a few years as a dedicated tester once I developed the knack for it. Everybody gangsta til it's time to prove the damn thing works.
> "Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles.
Here it’s a climb-down. Writing tests to validate translation is orders of magnitude less work (and less likely to fail or be too dull to do properly) than the alternative available prior to 2025.
The fact that they wrote tests and clearly established operational control is not some kinda gotcha! It’s how they managed to get this piece of technology to allow them to do the IMPOSSIBLE.
I am just really struggling to understand someone who reads that paper and thinks “yup, everything is still the same and we don’t need to re-evaluate any ideas” Like, if you want to say that they still need engineering discipline in order to do ISA transitions at scale then…ok? That’s true? But Gemini meant that this formerly impossible thing was now not only within reach but done.
Exactly, if the engineers know where to look for the solution in open-source code and point the AI there, it will get them there. Even if the language or the tech stack are different, AI is excellent at finding the seams, those spots where a feature connects to the underlying tech stack, and figuring out how the feature is really implemented, and bringing that over.
> Google would have let that sit forever because the labor economics of the problem were backwards.
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.
I really don't think we're living in a "linearly interpolate from past behavior" kinda situation.
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.
Google3 was already PPC clean when they did that. Not as impressive as made out to be.
The value in enterprise SaaS offerings isn't just the application functionality but the IaaS substrate underneath. The vendor handles server operations, storage, scalability, backups, security, compliance, etc. It might be easier for companies to vibe code their own custom applications now but LLMs don't help nearly as much with keeping those applications running. Most companies are terrible at technical operations. I predict we'll see a new wave of IaaS startups that sell to those enterprise vibe coders and undercut the legacy SaaS vendors.
I've been confronting this truth personally. For years I had a backlog of projects that I always put off because I didn't have the capacity. Now I have the capacity but without the know how to sell it. It turns out that everything comes back to sales and building human relationships. Sort of a prerequisite to having operations.
Are the infrastructure tools available already not easy enough to build on? We have all these serverless options already.
I highly doubt that, and its in OPs article.
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.
Sensible people would do that (asking for just the features they need), but look at us, are we sensible?
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.
So maybe the saas will pivot to just sell some barebone agents that include their real IP? The rest (UI, dashboards and connectivity) will be tailored made by LLMs
There was a short moment in history where it seemed that the sentiment was: people will soon 3D-print 99% of their household items themselves instead of buying them.
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.
That has more to do with the shortcomings of 3d printing.
Are you saying vibed code doesn’t have shortcomings
I think some or maybe even many of those shortcomings will apply to software, too. Making actual good software is not as trivial as writing “make me an app”, much as making an actual good spoon is not as trivial as throwing an STL at a printer and calling it a day.
you cant easily vibecode everything. in my startup this is what I am not buying (and vibecoding):
- JIRA/trello/monday.com - benchling - obsidian
this is what i buy and have no intent to replace:
- carta - docusign - gusto/rippling - bank
this is what might be on the chopping block:
- gsuite
I'm curious about your reasoning. Jira/Trello etc. are like $10/mo/seat, why bother rewriting them from scratch? You'll spend more in tokens doing so. Same for gmail/google calendar, what's the ROI? Those tools are reliable and cheap, why bother creating your own?
jira/trello: ergonomics. to set them up correctly exactly the way i want would take me 20 hours (or hire a PM), i can vibecode for 20h and get the same result.
plus, being able to crossref internal data types is chef's kiss.
im paying for claude pro so it's use it or lose it. when i finish everything and have it battle tested i can end my claude code. and anyways when i have 10 employees, it's parity.
for gsuite: i want to own everything internally eventually ans having internal xrefs will be nice. the gsuite data is incidental, what is truly valuable about gsuite is spam detection and the oauth capability
Why not Docusign? Not challenging, just curious why that is specifically on your list. Reputation?
Sometimes value is not in the code or the product. But the fact that leg work is done and something is generally accepted for the purpose. For me it looks like type of product where the pain is not making the software. It is getting everyone you will deal with to agree that software is acceptable.
the common factor was sort of left as an exercise to the reader to think about moats in the age of AI... but basically anything that has touchpoints to the legal and financial systems im not gonna touch with a 20 ft vibecoded pole.
Just in case you weren't aware, Gsuite has a clone of Docusign built into it now.
hate to say it, because who likes monopolies, but it's easier to send people docusign because then they don't go Wtf?
Just because we can code something faster or cheaper doesn't increase the odds it will be right.
Arguably it does, because being able to experience something gives you much more insight into whether it's right or not - so being able to iterate quickly many times, continuously updating your spec and definition of done should help you get to the right solution. To be clear, there is still effort involved, but the effort becomes more about the critical evaluation rather than the how.
But that's not the only problem.
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.
If you’re able to articulate the issues this clearly, it would take like an hour to “vibe code” away all of these issues. That’s the actual superpower we all have now. If you know what good software looks like, you can rough something out so fast, then iterate and clean it up equally fast, and produce something great an order of magnitude faster than just a few months ago.
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.
How do we learn what a good output actually is?
Care to actually show us any of these PRs?
I was trying to formulate my argument to disagree with the "cost center" thinking in https://news.ycombinator.com/item?id=47107553, until I saw this comment. Now I feel that 'alephnerd might be right after all.
> (...) ops (...) a bunch of scripts to manage deployments.
Devops is prime example of work to be minimized and ultimately eliminated entirely by automation. Yes, it's a complex domain rich in challenges and there's both art and skill to do it right, but at the same time, it's also not the thing we want, just the thing we have to do to get the thing we want, because we can't yet do better.
The post you’re r replying to gets this right- lead time is everything. The fast you can iterate, the more likely that what you are doing is correct.
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.
Iteration only matters when the feedback is used to improve.
Your model doesn't improve. It can't.
The magic of test time inference is the harness can improve even if the model is static. Every task outcome informs the harness.
> The magic
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?
Goalposts wooshing by at maglev speed.
Of course it needs human supervision, see IBM 1979. Oversight however doesn’t mean the robots wait for approvals doing r&d and that’s where the magic is - the magic being robots overseeing their training and improvement of their harnesses.
IOW only the ethics and deployment decisions need to be gated by human decisions. The rest is just chugging along 1% a month, 1% a week, 1% a day…
Your model can absolutely improve
How would that work out barring a complete retraining or human in the loop evals?
The possibility that anyone can easily replicate any startup scares A16Z.
This is what always confused me about VC AI enthusiasm. Their moat is the capital. As AI improves, it destroys their moat. And yet, they are stoked to invest in it, the architects of their own demise.
Don't you have that backwards? If AI gets so good that it can replace all human labor, will capital like money and data centers be the only moat left?
> If AI gets so good that it can replace all human labor, will capital like money and data centers be the only moat left?
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.
Did you see those Chinese robots from last week? I’m pretty sure they’ve got their moats covered
Which is bought by money in the first place, see billionaire doomsday bunkers. The poor will not have such a bunker.
Unless they intend on generating their own oxygen to breathe, I don't see how these bunkers stand a chance.
Fortunately they do.
For how many weeks? Or months? Or years? Then what?
Money is useful mostly for hiring human labor to outcompete others, e.g. Satya Nadella has 100K employees under his command, you don't, so you can't realistically compete with MS today - this is their main moat.
If AI renders human labor a cheap commodity (say you can orchestrate a bunch of agents to develop + market a Windows competitor for $1000 of compute), what used to be "Satya + his army vs. you" now becomes mostly a 1:1 fair fight, which favors the startup.
Frankly, you have a pretty good chance of displacing windows right now. You should go for it.
How powerful is the device you wrote this comment from? On prem or self hosted affordable inference is inevitable.
There’s no alternative, they can’t collectively freeze out all AI investment and force it to die.
The incompetent have always pantomimed the competent. It never works. Although the incompetent will always pay a huge amount to try to achieve this fantasy.
You're joking. Most startups are the incompetent. Throwing enough money at sales and marketing can make anything work.
A16Zs opinion is worthless to me, they know very little about the market. Furthermore, they're notorious for having a lot of "partners".
Pretty worthless take posting an ad-hominem attack instead of addressing the actual content of the article/ statement.
Their whole game is just pump and dump
Depends on the partner, Peter Levine is a pretty damn good picker (supported us series A to IPO). https://en.wikipedia.org/wiki/Peter_J._Levine
Has everyone forgotten about when they pumped absurd crypto scams like NFTs
The buy vs build discussion has dramatically changed with GenAI. Some enterprise systems need to remain vendor based, but there’s a ton of space for mid-size and smaller companies to build and maintain their own systems and tons of software that were excel apps could be fully realized departmental systems.
That's a short term view. Any system you build inhouse has to be maintained until you replace it, and often the longer it remains in place the harder it is to do that. You might save a small amount of cash (which might be important at the time tbf) but you're creating a major headache for later. Legacy code is debt, and that includes all your code. It's also a huge problem if the maintainer leaves because typically those small systems are owned by an individual dev who set it up in the first place.
Everyone who founds a company needs to remember that they're building a system of systems that all interact and influence each other, and you have to balance short term cash flow against long term strategy.
> It's also a huge problem if the maintainer leaves because typically those small systems are owned by an individual dev who set it up in the first place.
It's not uncommon that this maintainer actually wants to get away from maintaining this code, and would actually be quite willing to teach some successor how everything works.
The problem is that it is often hard to find someone who is similarly passionate about this system (often the system only keeps working because the original maintainer invests a lot of energy into keeping it alive), and is thus brutally willing to learn this system inside out. You can't force this mentality from above: either a suitable programmer has this mentality or he is typically not suitable.
Trading one single point of failure for a different single point of failure is never the answer.
I don't understand why you appear to be downvoted for this (your comment is faded at the time I'm reading this). It sounds like a perfectly reasonable take.
I've certainly inherited and also caused these problems in my younger years.
Sorry, this take just shows that you probably are not running a business. Having someone dedicate their whole business to a solution to one of your problems will most likely get a better result than you doing a hackjob you can't even maintain. Let alone the maintenance, logistics, complexity, time etc. The economics just aren't there to vibe code even more than 30% of the software you use.
People running businesses want to focus on their core business and are happy to pay for pain points to go away, for money to come in or less money to come out. It's that simple.
I’ve been a consultant to fortune 100 companies throughout my career and the amount of pain they willingly endure supporting Excel, Access, and .NET/Java applications is astounding. The desire to eliminate these things is high, but there’s no political will over cost and appeasing departmental management.
I think GenAI opens Pandora’s box and all of these decisions change.
Yeah, and we'll see them fail trying to roll their own excel. It's such a stupid economic decision to even think of that ... I can't even. So I heavily disagree, still. Software doens't need to be perfect, it needs to be good enough and the economics need to work.
You sound like a salesman. Small business will always choose 1 hour free "hack" fix, over $50k solution with "complexity, maintenance..". Shitty python script with DuckDB running locally on laptop, can get you long long way.
If someone chooses the 1h free hack, sorry, you're doing business wrong and focus on the wrong things. A mindset that keeps you small. You gotta invest in stuff that makes you money and solves your problems. If that's what makes me sound like a salesman, again, I don't think you own a business as well or are struggling to make a living with that.
Theres a whole lot between "I waste my time and do non-scalable things" and "I need an enterprise contract as a SMB".
> Shitty python script with DuckDB running locally on laptop, can get you long long way.
Yeah ... no. You do you, but if you want to get your business to a good size you need proper tools. Like a chef needs a good knive, your business needs good tools as well. That's not to say that a quick DIY integration is off the table, but the one thing you don't get back is time, not money. So when you waste time by doing shit that can go away with minimal investment, you're preventing your business from getting traction.
Sorry but that's a coder mindset. "I can do this myself". That's what's keeping you stuck. You need to think about every decision as an investment. Time vs money. What's the ROI for all alternatives? Then you decide on what moves the needle. It's that easy.
The calculation is simple: every minute you do stupid stuff like coding shit, you can't sell to someone paying you to make things. So you lose twice by doing something yourself: a) you can't sell your services or time in the mean time and b) you add complexity and maintenance to your very complex business life as well. For me, the biggest problem is too much to do and not enough time. So to scale my business I need to reduce complexity. If I can throw reasonable money for that to go away: good, I'll do it. Most business owners I know think like that. That's business, not sales.
There are so many good SaaS for cheap or even with a good free tier that get you started that it's just incredibly junior to just build it yourself.
Big difference between a startup or small business and any company with 500+ employees.
Not sure I get your point, care to explain? I wasn't talking about enterprises at all anyway.
its the same as why roads are still built by hand a lot and houses etc..
it is not needed to automate everything. some joys should not be automated away, people wont let them be either way.
the world could be much more optimal in .any place, but its boring, so the optimisations go elsewhere.
Why is it bad for AI to replace an enterprise software layer? Other than invalidating past investments.
A few reasons, "AI" as used by non-experts often has correctness and security issues. Even when it doesn't, its outputs are often not reproducible/predictable because they're probabilistic systems.
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.
Some of that latter part depends on how good and cheap open weight systems get. The ability to deploy your own will strictly limit the price of closed models if they aren't dominant in functionality.
AI is eating the software https://a16z.com/why-software-is-eating-the-world/
a lot of low level ops stuff is going to be eaten up imo. half the bullshit you have to deal with is integrating data across every platform you are using or other supposed products to help you integrate the integrators lol. i guess if you're a huge company with 1000s of people this is an inherent problem anyway, one you can spend millions of dollars on.
it's not just "replace snowflake", there are a lot of times i wish i could build a very focused thing to accelerate some of our internal workflows and the nocode solutions either were too simplistic that you ended up spending just as much time trying to wrangle some generic solution to your own use case. OR it was not worth throwing significant engineering resources behind internal ops stuff. now that barrier is dropping fast and it's feasible for us.
whoever can create the framework/tooling for people build their own systems will win this, but i don't think it's something that can be "productized" like a saas.
so are they saying this based on their analysis, or because they are trying to stir up support for a non-vibe-coding startup they have have invested.
I can’t believe I’m responding to an AOL article, but…
You don’t understand what’s happening if you dismiss the leverage provided by AI as “vibe coding”.
Never say never, vibe coding is not even 4 years old.
I cannot believe there has been no mention of things like n8n, activepieces and windmill in this thread. SaaS will utterly collapse in 18 months.
https://github.com/n8n-io/n8n
https://github.com/activepieces/activepieces
https://github.com/windmill-labs/windmill
>> Anish Acharya says it is not worth it to use AI-assisted coding for all business functions. AI should focus on core business development, not rebuilding enterprise software.
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.
He is lowkey right
AOL still exists?
I dunno.
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 largely agree with you. And, given your points about “not going back” — how do you propose interviewing SWEs?
I have thought about this a lot, and I have no idea. I work for an "AI-first" company, and we're kind of required to use AI stuff as often as we can, so I make very liberal use of Codex, but I've been shielded from the interview process thus far.
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.
aol.com...? wow what year is this
"aol.com"?
A16z partners don't know shit. Brain dead nepo-babies - how's Cluely?
Let's just look at Dijkstra's On the Foolishness of "Natural Language Programming". It really does a good job at explaining why natural language programming (and thus, Vibe Coding) is a dead end. It serves as a good reminder that we developed the languages of Math and Programming for a reason. The pedantic nature is a feature, not a flaw. It is because in programming (and math) we are dealing with high levels of abstraction constantly and thus ambiguity compounds. Isn't this something we learn early on as programmers? That a computer does exactly what you tell it to, not what you intend to tell it to? Think about how that phrase extends when we incorporate LLM Coding Agents.
All of you have experienced the ambiguity and annoyances of natural language. Have you ever: Congrats, you have experienced the frustrations and limitations of natural language. Natural language is incredibly powerful and the ambiguity is a feature and a flaw, just like how in formal languages the precision is both a feature and a flaw. I mean it can take an incredible amount of work to say even very simple and obvious things with formal languages[1], but the ambiguity disappears[2].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.
It's extra sad because they would be more profitable if they recognized this.
Sometimes I wonder why companies are so resistant to making profits. It can be really strange. To be so profit focused yet throw away so much just because it is a bit more effort or a bit slower. But I guess most people are penny wise and pound foolish.
> Vibe Coding has its uses and I'm sure that'll expand, but the idea of it replacing domain experts is outright laughable.
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.
> 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.
It never worked because a lot of times, domain experts are stuck in their ways of doing things and the real innovation came from engineers learning from domain experts but adding their technically informed insights on the recipe to create novel ways of working.
A Lotus 1-2-3 vibecoded by a Product Manager in 1979 would probably had a hotkey for a calculator.
Yes, 4GL and 5GL failed, but authoring Access applications should be a breeze now.
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.
I know I'm shooting myself in the wallet here, but I honestly don't think that SWE is an "essential" domain. To explain, as one who has taken relational data modeling classes, it's obvious to me that everything that can be spoken about can be treated as a "domain", but if you'll allow me the terminology, I think that some are "essential", and others are "accidental".
I believe that business analysis and computer science are essential domains, of (respectively) properly defining the logical/mathematical constraints of problems, and of understanding what it means to solve such problems. But software engineering is "accidental", in the sense that no one other than us in the industry actually cares about what we do, but rather only about their use-cases implemented; what we do is just implementation details.
I don't have a magic ball, but I wouldn't be surprised if in a century, (human) software engineering goes the way of the switchboard operator, elevator operator or knocker-upper.
How do you get domain experts?
Dijkstra also said no one should be debugging and yet here we are.
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.
Interestingly I think his "gospel" is only more meaningful today.
I think it's worth reading in fullhttps://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...
>no one should be debugging
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.
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
I sincerely doubt you produced the source where he asked that question in the middle of someone else’s job talk.
Which is what I was referring to. I read what you wrote, pal. Did you read what I wrote?
Please just read what I wrote. Please. You and I are talking about different things. You showed me a source for your claim and then acted like I was somehow misreading your source when I just wasn't talking about it.
We're basically in agreement, but you want to act like you're teaching me something. It's irritating.
One can fully understand that the goal is to write provable programs and yet we do not, we write programs that need debugging. So therefore, I don't think it's hard to imagine that if we get along with that, we may get along with natural language in the control channel, despite that being also proscribed in that vaunted essay you linked to me.
..said the guy, who doesn’t code anyway
I hear and read so much shit by VCs. Both in LinkedIn and in private meetings. Specially Menlo says a lot of shit (check LinkedIn). Deloitte and McKinsey, also full of crap. Really.
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 bullshit people love the bullshit generators.
a16z talking again?
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).
This wasn't a16z monolithically speaking as a firm, it was Anish Acharya talking on a podcast.
Seems like he's focused on fintech and not involved in many of their LLM investments
I will not claim to be an expert historian but one general belief I have is that nomenclature undergoes semantic migration over a century. So for the sake of conciseness I will quote the first demand of each portion of the Fascist Manifesto. This isn't to obscure, because it is in Wikipedia[0] and translated in English on EN Wikipedia[1], but so I can share a sample of whether this is something we can relate to our present day political orientation. Hopefully it will inform what you believe "author of the Fascist Manifesto" to imply:
> ...
> 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...
1: https://en.wikipedia.org/wiki/Fascist_Manifesto#Text
Sure. They're making a strong claim, but I think they mean "author of the Fascist Manifesto" as shorthand to say Marinetti was an ardent supporter of fascism and Mussolini. His support continued throughout the 30's and 40's, even after the Pact of Steel and the Racial Laws etc, even volunteering to go to the Eastern Front. I think we can say with the benefit of hindsight that the fascists' attempts to ingratiate themselves to the worker's movement were sort of ancilliary to the whole political/ideological project... I mean I'd hope any student of history agrees with that...
I’m not particularly political and am also not a historian but I don’t think it’s necessarily correct to equate the literal text of the manifesto with the principles and practices of fascism.
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.
I suppose we should, in being intellectually consistent, take the appropriate position that 8 hours / day and a wealth tax are fascist principles.
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
Sounds like a16z has some rapidly depreciating software equity they want to sell you.
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.
They don’t make money by being right, they make money by exposing LPs to risk. Zero commitment to insight. Intellectual production goes only so far as to attract funding.
Also... they don't make money by promoting things that are good ideas that make sense. That's why every lucky billionaire tech bro that gets into VC ultimately invests in smart toilets. Ultimately, they just keep putting money into each slot machine they can find until one of them pays out a jackpot. Eventually one of them will make up for all the other losses.
Vibecoding is a net wealth transfer from frightened people to unscrupulous people.
Machine assisted rigorous software engineering is an even bigger wealth transfer from unscrupulous people to passionate computer scientists.
Sadly, this is the most serious comment here. People who are not shocked are people who haven’t seen what a highly educated computer scientist can do in single player mode.
[flagged]
[flagged]
[dead]
Well, yeah. Vibe coding as in letting AI one-shot an app with a vague description still doesn't work except on trivial, throwaway stuff. But... spec-driven development with automated stepwise refinement by agents recursively generating, testing, and improving the code is how software engineering is done in the late 2020s.
You write that in italics as if to imply it’s a law that cannot be questioned. Quite a number of shops do not engineer software like that, or only engineer software like that where it fits the environment the software lives in, or otherwise sit at numerous points along the gradient between “software engineering as it has been known for decades” and “fully computer generated software”.
The laws of scale are stone cold bitches, and so you really don't need a weatherman to tell which way the wind is blowing. By 2030 writing code by hand in an IDE will almost certainly be a curiosity for retro enthusiasts, like programming a C64 in BASIC is now. The field as a profession will be unrecognizable and, as things become more automated and even self-improving, have far fewer people working in it, by 2030.
> "You have this innovation bazooka with these models. Why would you point it at rebuilding payroll or ERP or CRM"
Most SaaS companies are just expensive wrappers on top of existing tools. For non-VC-funded companies, SaaS tools are a serious cost. If you can re-create them in-house with AI, why wouldn't you? The result is saving capital (which you can then employ to do the more innovative things), and being in control over your own data.
If this is actually viable, then SaaS will (be forced to) lower costs until it is no longer worthwhile.
Yup, it becomes a race to the bottom. And honestly that's a good thing, everyone hates paying for all of these subscriptions.