Stephan Smith Fractional CTO
← Vibe Coding 101

Chapter 2 of 5

Change It Without Breaking It (i.e. spaghetti code)

You need consistent patterns so nobody can dismiss what you built at a glance.

What you'll see developers say online

The second reason developers write vibe-coded apps off: your code has no consistent patterns, no code hygiene. Everything’s shoved in different places, like a hoarder’s house. They’ll call it spaghetti: messy names, inefficient loops, code only a junior would write, and use that as proof your app isn’t production-ready and will fail the first time someone serious reviews it.

The solution: code hygiene in plain language

Code hygiene means consistent patterns, everything organized, not shoved in different places. Fix that and your app looks production-ready, like a senior dev wrote it, even if you’ve never typed a line and AI did the work. People say AI code is “spaghetti”: messy names, loops, inefficient. Humans write plenty of spaghetti too. AI can clean it up just as fast. You don’t need 30 years of experience to get organized code.

If you do this yourself

Cleaner patterns → better AI output on the next pass. You stay vibe coding longer with code that holds up to a glance.

Developer perspective

Spaghetti code is real, whether a human or AI wrote it, and it kills readability. If a developer is called in to fix it and sees a mess, they’re right to pause before touching it.

What to do

Set hygiene to your app’s goal. Over-tune and you get an over-combed codebase that slows shipping. Build a system that works for you and your AI, but stays consistent enough that an outside dev can follow it. Don’t one-shot this; build up with the prompts so AI writes better code next time.

If you skip this

You’ll get called spaghetti even when the app works. Devs and stakeholders judge. This turns off the judginess and makes your AI more efficient.

My Go To Prompts

I review codebases all the time. I’m a battle-tested CTO. I’ve built startups. Here are three prompts I use every day. These aren’t theoretical. They’re the actual prompts I run, tune, and build skills around.

1. Framing prompt

Your starting point. This sets the pattern for how you and the AI will figure out what needs to change in the code before anything gets rewritten. It tells the AI who to be and what “good enough to pass a senior review” means for your app, so the rest of the conversation stays about your situation, not generic style rules.

Assume the role of a senior developer who has reviewed thousands of PRs across many codebases, stacks, and team styles. You know how production apps are actually structured, that every codebase has its own patterns, and that consistency, not perfection, is what gets past a serious review. Hygiene, naming, layout, and reusability are proxies for quality. Hold that stance as we assess this app. Do not refactor yet. Help me see what a reviewer would notice.

2. Current state prompt

Use this after the framing prompt. You are not asking the AI to fix anything yet. You are building a picture of how hygienic your code is today and what is out of alignment. That stops random refactors and helps you see what actually needs to change. Expect a table you can read and push back on with follow-up questions.

Using your senior reviewer role, review what we have built so far, our code, stack, folder layout, and how features are wired together. Give me an overview of our current code hygiene: what is consistent, what is scattered, and what would worry someone in a PR review. Do not make changes yet. Return a markdown table with one row per core hygiene area (naming, file and folder structure, component and modal reusability, function and API argument patterns, state management, data fetching and caching, routing, error handling, testability). For each row include: the area, a score from 1-5 for where we are today, highest value / lowest effort / highest impact (rank or note), a plain-language sentence on why it matters, and one question I should ask next to go deeper. Sort the table so the best next conversations are at the top.

Follow-up questions you can ask

Paste these after you have the table. Same chat, still no code changes. They push into the details a senior reviewer would ask about before trusting the codebase.

  • Modals and reusability

    Are we structuring modals and shared UI for reusability, or is the same pattern copy-pasted in different shapes across the app? Score it and tell me where inconsistency will hurt us first.

  • Argument structure

    Do we have a consistent argument structure across functions and API calls (objects vs positional params, naming, optional args), or does every file invent its own style? What would a reviewer flag on the next PR?

  • State management

    Are we mixing Redux, context, local component state, and localStorage without a clear rule for what lives where? Map what we use today and whether that will confuse the next feature we add.

  • Caching

    Is caching centralized (one pattern, one place to look) or decentralized (every feature caches differently)? Where would stale data, duplicate fetches, or “it works on my machine” bugs show up first?

  • Routing

    Does our routing structure create paths where errors are easy to miss, deep links, lazy-loaded routes, unhandled params, redirects? What breaks first when something goes wrong in production?

  • If we skip it

    For the lowest-scored rows in your table, what happens if we skip them for the next 30 days: what gets harder to change, and when would a senior dev call this spaghetti?

3. Capture the Wins and Patterns

Run this when you are ready to save what you learned. It creates a markdown file in your project root so the next code hygiene conversation picks up where you left off. You are not re-explaining your app from scratch every time.

Using your senior reviewer role, create a markdown file at the root of this project named code-hygiene-status.md. Document what we found in this conversation: patterns we agreed on, current hygiene scores if we used them, what is consistent, what is scattered, and priorities for the next pass. Write it in plain language so that in future chats about code hygiene you read this file first and treat it as the starting context. Do not make code changes in this step, only create or update the file.