I am pretty sure that, even though this project is generated by AI, there will be a large majority of quicks and edge cases and bugs, just like as if a bunch of people would have written it. It's just that the initial bulk of the code was produced in a fraction of the time. All those bugs, quicks and edge-case still need to be resolved (if you were to actually use this). If you prompt your own version of this you just end up with your own set of bugs, quirks and edge-cases. The nature of software hasn't changed, just the speed with which we produce it.

This is a question that pops up all over the place these days. I can offer one answer.

System design is principally a process of identifying the best possible points at which to decouple the components that will make up the system. A clean design means that components can be swapped out for alternatives easily. Messy designs result in interlocking complexity.

Structuring your components as a general-purpose re-usable library forces you to consider how it is decoupled from consumers. If you do a good job designing it, it should be usable by all sorts of consumers, so you might as well make it a standalone library.

To a first approximation, I think this process of identifying clean decoupling points is the main thing that humans still need to babysit their agents over.

~200 USD in 1mo of claude, and 4 days of developer time -- call it 5000 USD

Very little. The motivation of contributing the open source is almost never a product, it is the feedback loop of work and achievement. Nobody will contribute to this kind of thing, because there is no feedback loop here.

It has no value, and you can tell basically immediately.

People are becoming extremely lazy and shipping the first slop the model generates because they get a rush from putting their stuff in tot he world as fast as possible.

However, I would bet significant money that all the projects like this (where every aspect has hallmark slopisms (the vibe interface design, the copy) will lose out to projects that are also heavily AI coded but that took the time and care to actually polish and differentiate themselves and thus are later to the game because they shipped after a few weeks or a month of work and refinement instead of a day.

AI can save you a lot of time but it can't save you from your own lack of restraint and your inability to discern and be an objective judge of the value your thing will have to other people. For software, mere existence is no longer sufficient anymore. Anyone can generate whatever you made instantly if you put zero effort or discernment into it. This is why so many of the Ainfluencers are emphasizing "taste".

But even taste won't save you on the end either, since anyone can clone your stuff as soon as it ships.

I personally think the future of software is probably just two extremes:

1. Personal dinky vibe coded apps that all have their individual creator as the sole user.

2. Large scale apps that don't work without significant marshaling of hard physical resources (e.g. LLMs themselves).

All the middle bits, user applications that target a specific problem space but that run locally and/or don't need legions of data centers and networks to run, will probably just die eventually. Maybe a couple of established apps will stick around in business contexts because employees all using their own personal apps and workflows causes too much coordination overhead, but at the consumer level I fully except everyone will be just vibing their own stuff pretty soon here.

Yea, there's some nuance here. If you're a senior engineer in the pre-LLM world, you're likely spending more of your time guiding a team than you are writing lines of code. Perhaps you're writing prose for code review guidelines and guardrails around architectural patterns, with trust that this is followed and propagates to the org. Perhaps you're giving guidelines that anything that implies a business-level decision needs to be escalated and have a rollout plan, not just hardcoded.

The question is: if you're doing this same thing, but with LLMs as your "reports," is it vibe coding? The term was once an epithet, but I think it's expanded to refer to the technique of not living in an IDE, not the objective function.

If your objective function places an emphasis on maintainability: vibe coding can be a positive. If not: it can be a source of great pain. As with many things, it's the wielder, not the technique.

> No one needs another C UI library.

Well, actually they do, but the LLM wouldn't know why. You gotta have used all these to figure it out, and then spend months wondering upon a better design, researching old experiments by random people in archived repos for inspiration. LLMs are useful only for that last part, quickly comprehending a strange repo you found from 15 years ago.