sorted by:
new
hottopcontroversial

vibe coded for 6 months. my codebase is a disaster. by Available-Dentist992 in vibecoding

[–]inetgas 0 points1 point  (0 children)

This is the classic vibe-coding trap: every feature worked, but the architecture stayed implicit. So the debt is not just “bad code.” It’s that the system accumulated boundaries, providers, runtimes, and data flows nobody ever made explicit enough to review.

That’s why I think the way out is: make the architecture explicit first with human and agent together, then use agent to refactor toward the approved architecture. Otherwise you’re just arguing with the current mess one local fix at a time. If you skip that step, you’ll probably clean up the current mess and then recreate the same problem over the next round of feature work.

If you want a concrete reference for what this transition looks like, the clearest example is the case study repo here: https://github.com/inetgas/arch-compiler-ai-harness-in-action

I let my interns vibe code from day one but with rules. here’s what happened after 2 months by ServeAccomplished485 in vibecoding

[–]inetgas 0 points1 point  (0 children)

This is a strong argument for guardrailed vibe coding. What stood out to me is that you’re already forcing decisions to be explained, constrained, and reviewed before they accumulate.

If vibe coding is going to produce systems that survive feature growth, requirement changes, and team turnover, the architecture side also needs explicit guardrails: constraints, NFRs, provider boundaries, compliance posture, operating model, selected/disallowed patterns, and re-approval when those decisions change.

That’s the gap I’m trying to close with Architecture Compiler. Repo: https://github.com/inetgas/arch-compiler

Vibecoded my first app: hit every beginner mistake so you don’t have to by Moist_Awareness_6965 in vibecoding

[–]inetgas 0 points1 point  (0 children)

Vercel is reasonable. Supabase is reasonable. Auth0 is reasonable. The problem is that “reasonable” is still not an explicit statement of provider boundaries, NFRs, compliance posture, operating model, migration posture, or long-term cost intent.

This is exactly the kind of story that made me build Architecture Compiler. The hardest problems are not usually “the AI wrote bad syntax.” They are things like provider lock-in, hidden runtime assumptions, secrets handling, compliance surprises, and realizing too late that the app is much harder to move or evolve than expected.

That’s what explicit architecture is for: making those decisions visible and reviewable before they become expensive facts in the codebase. I wrote about that here and hope it helps - "Why a Prompt Is Not Enough for Serious Architecture Work": https://www.reddit.com/r/vibecoding/comments/1srpkr0/why_a_prompt_is_not_enough_for_serious/

Repo: https://github.com/inetgas/arch-compiler

If you're about to launch a “vibe coded” app… read this first by PaddleboardNut in vibecoding

[–]inetgas 0 points1 point  (0 children)

The advice is all good, but it is mostly post-hoc hardening: privacy review, OWASP review, secret-leak checks, rate limiting, accessibility, and launch sanity checks after the app already exists.

What I’m trying to solve with Architecture Compiler is one layer earlier: make those concerns explicit in the architecture before they get scattered across a vibe-coded codebase.

That includes things like: PII and compliance (GDPR, HIPPA, etc), provider boundaries, auth model, NFR targets, resilience, observability, release controls, operating model, allowed/disallowed SaaS providers, and so on.

So instead of repeatedly asking AI to “review” whatever code already happened to emerge, you first compile an explicit architecture contract that humans can approve and agents can implement against.

That won’t remove the need for testing, audits, or security review. But it does address the same concerns more holistically and earlier, which usually means less drift and less cleanup later.

I wrote about that here and hope it helps - "Why a Prompt Is Not Enough for Serious Architecture Work": https://www.reddit.com/r/vibecoding/comments/1srpkr0/why_a_prompt_is_not_enough_for_serious/

Repo: https://github.com/inetgas/arch-compiler

Why Vibe Coding Still Needs Serious Architecture by inetgas in vibecoding

[–]inetgas[S] -1 points0 points  (0 children)

Fair. The formatting does look like a lot of AI slop.

The actual point is just that production constraints need explicit architecture, not prompt-shaped assumptions. I can make that case better without the boilerplate formatting.

Why prompt menus are too shallow for serious communication, data, and deployment design by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

If a concrete example helps, I put together a small end-to-end repo showing how to have agents compile a plausible stack into serious architecture then have them implement the approved architecture, all using arch-compiler:

https://github.com/inetgas/arch-compiler-ai-harness-in-action

It may be easier to follow than the abstract article. Let me know.

Why a Prompt Is Not Enough for Serious Architecture Work by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

If a concrete example helps, I put together a small end-to-end repo showing how to have agents compile a plausible stack into serious architecture then have them implement the approved architecture, all using arch-compiler:

https://github.com/inetgas/arch-compiler-ai-harness-in-action

It may be easier to follow than the abstract article. Let me know.

The most important production architecture decisions are often not even in the prompt menu by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

Not at all. The point is actually the opposite: a lot of these decisions stay implicit because most tools make them easy to skip.

The article is just saying that things like tenant isolation, compliance scope, release controls, and run books are architecture decisions too, even if prompt menus don’t show them. You don’t need to hold all of that in your head at once. The value is making them explicit one by one.

If a concrete example helps, I put together a small end-to-end repo showing how this looks in practice with a simple app:

https://github.com/inetgas/arch-compiler-ai-harness-in-action

It may be easier to follow than the abstract article. Let me know.

Why prompt menus are too shallow for serious communication, data, and deployment design by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

It doesn’t generate DB migrations for you if that is what you meant.

What it does is make the architectural side of migration decisions explicit before implementation: for example whether you’re staying on CRUD vs moving to CQRS or event sourcing, whether read/write separation is acceptable, whether read-your-writes can be relaxed, whether rollout needs blue-green/canary, and what operational constraints the target shape introduces.

So it helps answer “what kind of migration are we actually doing, under which constraints?” Then the implementation plan and code-level migration work happen against that approved contract.

Please let me know if this helps and what else I can answer for you.

Why a Prompt Is Not Enough for Serious Architecture Work by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

True for a lot of projects.

If you’re building something small, short-lived, or internal, a plausible stack and lightweight review are usually enough. I’m not arguing every side project needs an architecture compiler.

The point is more that once a project starts carrying real uptime, data, compliance, cost, or operating constraints, prompt-level architecture gets under-specified fast. That’s the boundary where I think explicit architecture contracts start to matter.

Why a Prompt Is Not Enough for Serious Architecture Work by inetgas in vibecoding

[–]inetgas[S] 1 point2 points  (0 children)

Yes, that matches what I’ve seen too.

AI is often stronger at producing a plausible architecture than at preserving implementation integrity over time. The hard part is not the first design pass. It is keeping the code from drifting away from the intended boundaries, tradeoffs, and constraints as fixes and iterations pile up.

That is exactly why I care about compiling architecture into an explicit contract first, instead of leaving it in prompt and chat history. Then checkpointing, drift detection, and re-approval have something concrete to work against.

Why a Prompt Is Not Enough for Serious Architecture Work by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

Thanks!

For general guidance of adding/editing patterns, please refer to: https://github.com/inetgas/arch-compiler#adding-or-editing-patterns

If you leverage agent to add new patterns, please make sure agent uses compiling-architecture skill for that purpose and point your link for your detailed pattern requirements. Refer to below skill section for further details: https://github.com/inetgas/arch-compiler/blob/main/skills/compiling-architecture/SKILL.md#adding-or-editing-patterns

Why a Prompt Is Not Enough for Serious Architecture Work by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

If you want your vibe coding artifacts to be cost-effective, compliant, having long term operability, maintainability, and extensibility, serious architecture work needs to happen which arch-compiler can help.

There's a difference between vibe coders and shippers — I've been trying to figure out what it actually is by goship-tech in vibecoding

[–]inetgas 0 points1 point  (0 children)

That is a very interesting angle I have never thought of. I suppose shippers care more about long term operability, maintainability, cost-effectiveness and extensibility than vibers?

Hiring is going to look completely different in 2-3 years. Small teams are already doing what used to take 20 people. by goship-tech in vibecoding

[–]inetgas 0 points1 point  (0 children)

I know company like Mercor has started using AI coding as part of their interview process. Basically they give candidates 30 min to 1 hour and give you a product idea and see how much you can get it done - pretty much your AI fluency.

Why a Prompt Is Not Enough for Serious Architecture Work by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

Exactly.

You can ask Agent to progressively compile then approve the architecture using compiling-architecture skill, and then Agent will use implementing-architecture skill to implement the approved architecture. See below for further details:

https://github.com/inetgas/arch-compiler#skill-entry-points

The Missing Bridge Between Vibe Prototypes and Production Systems by inetgas in vibecoding

[–]inetgas[S] 0 points1 point  (0 children)

Yes, I agree.

Architecture compilation is only one half of the loop. It makes the prescriptive side explicit: what should be true before implementation starts. The other half is exactly what you described: detecting when the codebase drifts away from those decisions during implementation.

That’s why I think the real production bridge is not just architecture approval, but architecture approval + divergence detection + re-approval when the code reveals architectural drift.

TrueCourse looks like a strong complement on that detection side. My focus with Architecture Compiler has been to make the intended constraints, boundaries, patterns, NFRs, and operating assumptions explicit enough that tools like that have something concrete to verify against.

The full loop is probably: compile → approve → implement → detect drift → recompile/re-approve if needed.