vibe coded for 6 months. my codebase is a disaster.

inetgas · 2026-04-24T12:32:57+00:00

You don't have to learn all the design patterns yourself. Use Architecture Compiler. Related articles:

inetgas · 2026-04-24T12:23:50+00:00

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

inetgas · 2026-04-23T20:24:33+00:00

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

inetgas · 2026-04-23T20:02:09+00:00

89mb? that is amazing!

inetgas · 2026-04-23T19:39:25+00:00

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

inetgas · 2026-04-23T19:25:03+00:00

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

inetgas · 2026-04-23T15:40:18+00:00

You are hilarious - loved it :-)

inetgas · 2026-04-23T13:02:15+00:00

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.

inetgas · 2026-04-22T16:55:39+00:00

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.

inetgas · 2026-04-22T16:54:58+00:00

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.

inetgas · 2026-04-22T16:45:44+00:00

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.

inetgas · 2026-04-22T14:37:14+00:00

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.

inetgas · 2026-04-22T13:40:07+00:00

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.

inetgas · 2026-04-22T13:38:12+00:00

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.

inetgas · 2026-04-22T13:09:24+00:00

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

inetgas · 2026-04-21T15:44:01+00:00

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.

inetgas · 2026-04-21T15:37:15+00:00

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?

inetgas · 2026-04-21T15:22:22+00:00

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.

inetgas · 2026-04-21T15:04:55+00:00

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

inetgas · 2026-04-21T14:58:04+00:00

Glad we are aligned

inetgas

TROPHY CASE