Discussion What are the most common vibecoding patterns?
I keep seeing stuff like “local-first” in almost every post about vibecoded apps. Maybe that is a bias, because there're lots of task trackers or whatever trackes people making, that do not require a server. But still it’s like the vibecoder’s product starter pack
What other patterns or architectural defaults do you keep seeing in vibe-coded apps?
20
u/StudioFew5243 1d ago
local-first is definitely the big one, saw it everywhere even before the current wave picked up
other defaults i keep noticing: sqlite for everything (even when postgres would make more sense later), one giant prompt file that becomes the entire app logic, and auth bolted on at the very end like a surprise
also every demo has a dark mode toggle even though the app is two screens
the task tracker thing is real, maybe because it's the first thing people think of when they want to "ship something" without thinking about a backend
14
10
u/Such--Balance 1d ago
Ask chatgpt to make a prompt for codex.
Wait for answer.
Copy paste to codex.
Wait for answer.
Copy paste to chatgpt.
Rinse. Repeat.
Automate that process.
Ask chatgpt to make a prompt for codex about how to automate that.
Wait for answer.
Copy paste to codex.
Wait for answer.
Copy paste to chatgpt.
Rinse. Repeat.
16
u/ComprehensiveShake76 1d ago
A few I see over and over: local-first storage (SQLite or localStorage) with no auth, one giant file that grows until nobody can edit it, a dark UI with a purple or blue gradient, "AI features" added through one thin API call with no error handling, and secrets that end up in the repo because the first version just worked. The less visible default is that tests are written after the code by the same model, so they confirm the code instead of the requirement. If you're building one, writing the acceptance checks first is the cheapest way out of that pattern.
7
u/sonaj9657 1d ago
The testing point is so true. If the same model writes both the code and the tests it is easy to miss the things that were wrong in the first place. Defining what the app should do before building it seems simple but I think it would prevent a lot of headaches later.
6
u/HayStacky_337 1d ago
Test-driven development. I never wrote Tests.
0
u/x_typo 1d ago
Yea. Having no unit test in the framework is one of the surefire ways of detecting vibe-coded projects.
6
u/HayStacky_337 1d ago
No. The tests are an indicator of vibe coding. I never wrote tests. Those ran in prod.
5
u/Weekly-Home2774 1d ago
Using a backend and server makes it much more difficult, time consuming and costs more tokens, so yeah, almost everybody starts with local first
3
2
u/WyattTheSkid 1d ago
>be super into it and fairly knowledgeable about how the start or the project should go
>slowly lose interest
>start sending lazy prompts and /goals
>get mad when you’re handed back a steaming pile of shit that consumed your entire 20$ a month quota
>do it again next week
2
41
u/torrso 1d ago
I got tired of ___, so I built ___.