What do you wish you'd done differently before you started you first vibe-coding project?
by•
Mine has two phases
My first project was a prototype in lovable, worked great. Then I started adding features such as login and storage/database. Then things started breaking. I started researching and realized I should have
Planned for authentication from day one
Connected a database from day one
Phase 2, when I eventually moved it to Claude Code, I should have researched the model capabilities instead of choosing the cheapest model (Haiku 😆) to build main features. Learned the hard way
40 views
Replies
Mine: rules for running more than one agent session in the same repo, written before the second session ever started. A plain commit takes everything that is staged, so one day another session's staged rename and deletion went out inside an unrelated commit and left main unable to build until the next commit put the files back. Now every commit names its own files, and nothing gets staged with a blanket add. Your auth point is a good one too: the things that touch every screen are the ones to decide on day one.
@gbasovv Oh yes, I made that mistake too. And they were working on the same files. One agent actually told me someone else is working and it suggested opening a worktree where it could do it's work "without interruptions" 😂
@davidoduk Ha, the agent asking for a worktree is the sensible answer. I kept one tree and made the rules stricter instead: stage only your own files by name, never revert or tidy up a change you didn't make, and when one file holds both, stage only your own hunks. A worktree would avoid all of that, the price is merging later.
@gbasovv That's a good one. It's funny how you have to be very explicit to these agents. "Common sense" is not a thing with them
@davidoduk Exactly, which is why my rule is that anything I'd call common sense goes into the project notes the first time an agent misses it. Written once, it never has to be common sense again.
Mid-task the agent lost earlier context and rebuilt a helper that already sat two files away, just with a different name. That left two subtly divergent implementations doing the same job. The model has to check an explicit list of existing helpers before it writes a line.
@konstantin_tikhaev that sounds about right. And when the list gets long, the agent can "conveniently" decide to skip the list lol
@davidoduk Do not rely on prompt instructions for this. Make it a blocking tool call where the runner refuses to apply the edit if the model does not query the helper index first.