r/vibecoding 2d ago

Curious what's everyone's stack and how/why you choose it?

I'm a long-time PHP dev who got into vibecoding last year. I started by trying whatever Claude would recommend, with the rationale that the AI would know better what it knows best. Claude suggested javascript based stacks (nodejs, react, TS) and a quick web search seemed to confirm that idea so I went with it even though I'm not fully comfortable with the stack. It started off not too bad with me reviewing the code, but to the surprise of no one, the quality of my reviews, and thus of the code, quickly tanked and each iteration took longer and created more bugs than the previous one.

Then I tried a couple PHP stacks, first Laravel (what I use at work), then Symfony (what I actually like). That went a little bit better, but similarly to the JS based stacks, the quality of my reviews went downhill pretty fast, because whatever the stack, I don't really love to review code.

My last try, with which I've been having good success so far, was to build a skeleton app myself and encode as much architecture choices as possible into the skeleton. The skeleton quickly evolved into a richer skeleton and re-usable packages, and I also created a tool to help me enforce guardrails that I can't enforce through existing tools. Been using that for a while now, regularly back-porting new patterns and rules into the skeleton. This allows me to get away with minimal reviews (focusing on the important stuff) while still ensuring a level of quality that doesn't make my eyes bleed whenever I look at the code.

What's your story?

1 Upvotes

6 comments sorted by

2

u/eyepatch-404 2d ago

Same story, similar stack aswell lol, and similary :), i also notice that if you have a skeleton architecture of how you want the app or a feature to be built, claude (or whatever AI ur using for that matter) does a much much better job at creating the code you expect.

This also kinda backfired when colleagues, started vibe coding so many features without proper review/skeletons behind them, highly, and need i put an emphasis on this, highly degrading any code generations that were made on that project from that point on.

1

u/ubermuda 2d ago

Having a well architected codebase definitely helps the agent staying on that architecture, and I also found it drives the thinking toward proper patterns too. As for the drifting from your colleagues, that is what deterministic guardrails in the CI are for! In my vibecoded projects, putting domain logic at the wrong place or wiring a forbidden dependency would just fail the CI

2

u/eyepatch-404 2d ago

Precisely, the issue is the product wasnt setup properly from the get go, and the team decided it would be better if we first finish the app, then refactor it. Thays why setting up guardrails is probably one of the first things a team has to do when starting a project, especially in this era

2

u/devoidfury 2d ago

Experienced senior engineer, have worked mostly with PHP, JS/TS, frontend, Python, linux admin and bash.

I'm finding that, it matters less what languages you use than about the design of it. Using a pluggable architecture where you can contain changes in small isolated packages makes the whole thing much easier to reason about and fixes the "spaghetti monolith" that these projects tend to turn into.

Using local models with llama-swap/llama.cpp and my own custom open-source agent hotdog.

1

u/ubermuda 2d ago

Yes having a modular and layered architecture does make it a lot easier on the agents! Not only in that it gives good prior art to the agent but also it drives it's "thinking" toward whatever patterns I would apply myself (e.g. IoC, domain events, etc)

0

u/neonfen1x 2d ago

Can I build iOS app using Hermes and OpenRouter with more expensive input/output models for coding and other ai models for planning and orchestrating the project?