Comment by thousand_nights
2 days ago
because the preachers preach how amazing it is on their greenfield 'i built a todo list app in 5 minutes from scratch' and then you use it on an established codebase with a bigger context than the llm could ever possibly consume and spend 5x more time debugging the slop than it would've taken you to do the task yourself, and you become jaded
stop underestimating the amount of internalized knowledge people can have about projects in the real world, it's so annoying.
an llm can't ever possibly get close to it. there's some guy in a team in another building who knows why a certain weird piece of critical business logic was put there 6 years ago, the llm will never know this and won't understand this even if it consumed the whole repository because it would have to work there for years to understand how the business works
A completely non-technical saleslady on our team prototyped a whole JS web app that generated some data based on some user inputs (and even generated PDFs), which solved a problem our customers were having and our devs didnt have the time to develop yet.
This obviously was a temporary tool we'd never let touch our github repo but it still very much worked and solved a niche problem. It even looked like our app because the LLM could consume screenshots to copy our designs.
I'm on board with vibe coding = non-maintainable, non-tested, mostly useless code by non-devs. But the plus side it will expose many many people to learn basic programming and fill many tiny gaps not solved by bigger more serious pieces of code. Especially once people start building infrastructure and tooling around these non-devs, like hosting, deployment, webhook integrations, etc.
Do people actually learn when using these tools though? I mean, I’m sure they can be used to learn, just like TikTok could be used to read John Stuart Mill. But I doubt that’s what it’s going to be used for in real life.
If the barrier to entry is lower then more people will engage with it. Everything in life is about incentives. This is a hugely powerful tool for people working in the information industry, which is most people with office jobs. A sales person who can overcome a simple customer objection without a major time investment with devs is a sales person who makes more $$ and gets more promotions.
Most people in practice won't, they'll stick to what they know, but there's tons of semi-nerds on the edges who are going to flourish in the next decade. Which is great news for the economy.
1 reply →
But that’s not good. You don’t want Bob to be the gate keeper for why a process is the way it is.
In my experience working with agents helps eliminate that crap, because you have to bring the agent along as it reads your code (or process or whatever) for it to be effective. Just like human co-workers need to be brought along, so it’s not all on poor Bob.
totally. Especially when i'm debugging something for colleagues or friends, given a domain and a handful of ways of doing it, if i'm familiar with it I generally already get a sense of the reasons why its failing or falling short. This has nothing to do with the code base, any given language not withstanding. It comes from years and decades of systems and idiosyncratic behaviors of systems and examples which strangely rear their heads in notable ways.
Theese notable ways may also not be commonly known or put into words, but they persist nevertheless.