> The code may work, but there’s no guarantee about its behavior (including error handling and edge cases).
But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden.
My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
This is exactly true in my experience. I find myself trusting the LLM better than I ever trusted a development team to deliver accurate work. Just like you would managing a team of junior developers, you have to keep an eye on the output, but I think the agent is more transparent about that than your team would be. And it works faster, and you don't have to deal with emotional meltdown or active sabotage if you criticize in the wrong way.
The trick for the guy controlling the agent is to know about the gotchas that one would normally encounter when doing the work. Asking the right questions and mentioning the right things to pay extra attention to can make all the difference.
I think that's why it will be much more difficult for people to learn how to make software now. Those of us who have been doing it for years and years have experience that is valuable in steering the LLM. It will be hard for people new to software to get that same experience. But then things are changing so quickly right now, everything I just wrote my be irrelevant in a week.
> find myself trusting the LLM better than I ever trusted a development team to deliver accurate work
That’s the main issue. You’re talking about the development side guarante, while the most important is the user side guarantee. There’s a lot of talk about liking LLM interaction, but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.
Which is why the most enthusiastic comments are about projects not released yet. Greenfield and released projects are different.
> but no comments about the software quality, which for a lot of SaaS has gone downhill. It’s why they emphasized LoC and number of PRs but hide the number of bug tickets.
Here's someone's breakdown (with some things from the full report that aren't in the Faros blog post), showing how it's even worse than first impressions: https://unessays.substack.com/p/talk-is-cheap
> it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
What makes you confident the Microsoft and Google software isn't vibecoded slop?
Certainly Microsoft has made a lot of noise about all their software being LLMgen these years, and also gotten into hot water with their users for Windows 11's crappiness.
Very good point. I would respond that I saw the deterioration several years before vibe coding became a thing, but maybe they did have a head start on the tech.
>My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
As in you get more mad at software you actually use being broken than software that you aren't using and just exists in blogposts?
I personally work a lot with vibe coded software, both my own and of others. And I do encounter a lot of issues, but in general they annoy me less than the enterprise engineered ones.
It's such an uninspired prompt. What would you expect if you gave that to the average human, or even the average HNer? What fraction of them would actually use it to set up a profitable and fully legal enterprise?
But if you give any more specific direction, then the result is partly the result of your input, not the ai. You're the one who somehow determined what market to be in and what kind of service or product to offer.
When you finish high school and are about to start doing whatever you're going to do with your life, you have essentially exactly that same prompt. The rest of the world doesn't tell you what to do and then you do that as well as you can, you have to decide what to do also, and then do it.
The essential elements were to succeed without having been given any direction or opinions as to how.
The detail was to get money. Yeah ok, so what? The experiment was to be a company not a person, and there is no other definition of success for a company.
Earn, steal, gamble, beg, whore, all on the table. The same is true for a person.
But the goal here is not to run 42km; to stay with the outdoors metaphor, it's more like deciding where and how to set up a bivouac - use whatever tools you have at your disposal to analyze the area you're in, and find the best site to stay in overnight.
But it's not "waiting on the output of an LLM for 40 hours" any more than a regular hackathon is "waiting for my damn teammates to finish their part for 40 hours". From my experience using agentic coding for hackathons, the best teams are those that coordinate with the AI agents in relatively quick cadence, generally giving it small tasks and steering it often. Teams may want to run some long-running sessions too, especially closer to the deadline, but even then, they'd probably want to run and follow several sessions in parallel, and continuously inspect their work so that they have reasonable confidence that their main efforts will wrap up before the deadline. There is an art to it.
I can't wait to see if the team that fares best is the one that steers often or the one that interferes the least.
So far humans failed at those problems. Also IIRC there was a guy that proved a substantial problem 2-3 months ago by basically pasting over and over "keep looking for a solution" or something like that for 2 days with little formal math background.
But the painful reality is that we never had any such guarantees in industry code to begin with; despite decades of writing on software engineering best practices, software from the biggest companies is often bug ridden.
My experience might not be representative, but when I do my "old man yells at clouds" routine (which I do multiple times a day), it's a lot more often targeted at Microsoft and Google software than at "vibe coded slop".
reply