Comment by osigurdson

To correctly vibe code something useful, I find that I need to religiously give faith to the tool and forget all about SWE principles and best practices and instead treat it like a child who makes mistakes and corrections while the adult must not intervene or admonish too much but rather nudge it to right direction.

Also vibe code has a parallel feature, while the code is generating, you are also doing live review and correcting it towards right direction, so depending on your experience, the end product can be a bad mess or wonderful piece of creation and maintenance dream.

The issue with seasoned SWE is that, the moment a mistake(or bad pattern) is made, the baby is thrown with bath water.

For a tiered app like the one presented, 35k LOC is not really that impressive if you think about it. A generic react based front end will easily need a large number of LOC due to modular principle of components, various amounts of hooks and tests(nearly makes us 25-40% of LOC). A business layer will also have many layers of abstractions and numerous impl. to move data between layers.

The vibe code shines, when you let it build one block at a time, limit the scope well and focus. Also, 2-3 weeks is a lot of time to write 35k LOC. at start of any new project, LOC generation rate is very high. But in maintenance phase it significantly falls as smaller changes are more common.

> LLMs are super useful but currently, the primary use case is teaching, not doing.

For code? Autocomplete on steroids is the killer-app.

The other things the LLMs give me are prone to be over-engineered/overly verbose code or similar.

I went through a lot of "Why are you also doing $FOO then $BAR? Doesn't seem necessary if we skip them and do $BAZ which will make one or both of those redundant" and it responding "You're right! Lets use $BAZ instead".

And giving them code to make a small change to was pointless - they would often, but not always, make an incidental change far from the point where you asked for the change.

But autocomplete? That works just great and because I've already got context of the code I am writing I can check it in (at most) two seconds and move on.

I have very similar experience.

After seeing how people like Andrej Karparthy used vibe coding to generate applications https://x.com/karpathy/status/1903671737780498883?s=61 I realize that

you need to be clear on what you want the LLM to do break down the tasks and give byte sized tasks to llm to do specific thing and sometimes I had to tell it not go and change random files because it found the need to refactor them.

Full Disclosure: I'm building a LLM chat app for software developers and domain experts

> I struggle to find much utility in terms of actually writing code.

I personally feel you need to give up some control and just let the LLM do its thing if you want to use it to help you build. It honestly does a lot of things in a more verbose way and I've come to the conclusion that it is an LLM writing code for another LLM. As long as I can debug it, I'm okay with the code, as I can develop at a pace that is truly unreal.

I finished my "Recent" contexts feature in a half a day, today. Without the LLM, this would have taken me a week I think. I would say 98% of my code in the past few months has been AI generated. You can see a real life work flow here:

https://app.gitsense.com/?chat=eece40e2-6064-46d2-9bf1-d868c...

I truly believe if you provide a LLM with the right context, it can meet your functional specs 90% of the time. Note the emphasis on functional and not necessary style. And if *YOU* architecture your code properly, it should be 100% maintainable.

I do want to make it clear that what I am doing right now is not novel, but I believe most problems are not. If the problem is not well understood, it can be a challenge like my my chat bridge feature. This feature allows you import Git repos for chatting but I will probably need to rewrite 50% of the LLM code since the solution it built is not scalable.