{"id":405,"date":"2026-07-12T18:50:46","date_gmt":"2026-07-12T18:50:46","guid":{"rendered":"https:\/\/marcinzygmunt.pl\/blog\/?p=405"},"modified":"2026-07-12T19:00:07","modified_gmt":"2026-07-12T19:00:07","slug":"vibe-coding-was-the-warm-up-real-work-with-ai-starts-after","status":"publish","type":"post","link":"https:\/\/marcinzygmunt.pl\/blog\/vibe-coding-was-the-warm-up-real-work-with-ai-starts-after\/","title":{"rendered":"Vibe Coding Was the Warm-Up. Real Work With AI Starts After"},"content":{"rendered":"\n

This is Part 2 of two. In Part 1 I argued that AI doesn’t take the job \u2014 it takes the mechanical typing, and makes your knowledge matter more than ever. If you buy that, the obvious next question is: okay, so how do I actually work with it? This is the how.<\/em><\/p>\n\n\n\n

\n

Stop trying to win with a single prompt. One-shot prompting \u2014 describe a feature, accept whatever comes back \u2014 falls apart the moment the system gets real, and no amount of prompt-polishing saves it. What works is a workflow that plans before it codes, and turns you from the one typing into the one deciding. The rest of this is why, and how.<\/p>\n<\/blockquote>\n\n\n\n

There was a moment when we all believed asking was enough. “Write me a login endpoint,” enter, and the agent spits out code. It works in the demo, works in the side project, wows the room at a workshop. This is vibe coding \u2014 you describe a feature in one sentence and accept whatever comes out. And for a moment it looks like the end of the software profession.<\/p>\n\n\n\n

Then you open that same workflow on a production system with two hundred thousand lines you didn’t write yourself, and the magic runs out.<\/p>\n\n\n\n

Why vibe coding wastes your time, money, and momentum<\/h2>\n\n\n\n

The problem isn’t that the model is dumb. The problem is that a single prompt carries too little context for the agent to understand why<\/em> the system works the way it does.<\/p>\n\n\n\n

Anyone who’s tried knows the symptoms:<\/p>\n\n\n\n

    \n
  • Code drifts from intent<\/strong> \u2014 you asked for one thing and got something that satisfies the prompt but not what you meant.<\/li>\n\n\n\n
  • The agent hallucinates APIs<\/strong> that don’t exist, because the real signature was never in its context window.<\/li>\n\n\n\n
  • You get a 2,000-line PR<\/strong> that takes half a day to review, because you don’t know where to start.<\/li>\n\n\n\n
  • A week later nobody remembers<\/strong> \u2014 you included \u2014 why that function looks the way it does.<\/li>\n<\/ul>\n\n\n\n

    Bad names are bad<\/h3>\n\n\n\n

    Here’s a subtler one that catches people off guard: the model reads intent from your names<\/em>, not just your logic. Name a variable users<\/code> when it actually holds orders, or isValid<\/code> for a flag whose meaning is inverted, and the agent leans on the label \u2014 especially when the behavior isn’t obvious from the code in front of it.<\/p>\n\n\n\n

    It builds the next ten lines on what the name promised<\/em>, not what the code does<\/em> \u2014 and the bug that follows looks perfectly reasonable until you trace it. You skim past a misleading name because you know the domain; the model takes it at face value.<\/p>\n\n\n\n

    Architecture by accident<\/h3>\n\n\n\n

    But the most dangerous layer runs deeper than typos in the code. It’s the architectural decisions the agent had no business making well<\/strong>. Vibe coding optimizes for “works right now, in this file,” not for “fits the rest of the system.”<\/p>\n\n\n\n

    So the agent drops business logic into a controller because that was the nearest spot. It reaches for a pattern that clashes with how the rest of the app is built \u2014 a repository where the project consistently uses something else, a synchronous call where the design calls for an event. It breaks layer and module boundaries it never knew about, because they weren’t in the prompt. It ignores the style and conventions your team spent years shaping.<\/p>\n\n\n\n

    Each such decision looks harmless on its own \u2014 the trouble is they accumulate and quietly erode the consistency that the whole system’s maintainability rests on.<\/p>\n\n\n\n

    Small is fine \u2014 big isn’t<\/h3>\n\n\n\n

    And here’s the key distinction: vibe coding is fine for small, local changes \u2014 it’s cheaper and faster, and there’s no point wrapping a typo fix or a single new field in process.<\/strong><\/p>\n\n\n\n

    But the more mature the project, and the wider the blast radius of a change \u2014 something touching many modules, crossing layer boundaries, or moving the business domain model \u2014 the worse vibe coding performs. Because there the price of a bad architectural decision isn’t local. The whole system pays it, for a long time.<\/p>\n\n\n\n

    This is a real cost. Not abstract “technical debt,” but your hours spent debugging hallucinations, your tokens burned on regenerating from scratch, and \u2014 worse \u2014 your momentum draining away as the tool that was supposed to speed you up starts slowing you down. Ambition turns into frustration, and the knowledge you hold as an experienced developer \u2014 about architecture, patterns, domain boundaries \u2014 sits idle, because the workflow never taps it.<\/p>\n\n\n\n

    The good news: this isn’t AI’s fault. It’s the method’s fault. And the method can change.<\/p>\n\n\n\n

    Where I hit the wall myself<\/h2>\n\n\n\n

    For a long time I thought the answer was a better prompt \u2014 sharper wording, more detail. But a prompt is a single shot. You compress everything you know about a system \u2014 its constraints, its conventions, the edge cases you’d never think to write down \u2014 into one paragraph, and you always<\/em> leave something out. Not out of carelessness; nobody holds all of it in their head in the second they hit enter.<\/p>\n\n\n\n

    Structure that pushes back<\/h3>\n\n\n\n

    What fixed it wasn’t a better prompt \u2014 it was structure that pushes back. A good plan doesn’t just record what I asked for; it questions what I forgot to address, works the implementation out in detail, and forces a critical rethink before anything gets built. A review stage challenges the result and catches drift a prompt can’t even see.<\/p>\n\n\n\n

    \n

    The prompt asks the agent<\/em> to be complete. The plan and the review interrogate me<\/em> until I am.<\/p>\n<\/blockquote>\n\n\n\n

    So I stopped running it by hand and built it into my own toolkit. I thought I’d stumbled onto something personal \u2014 turns out someone had already turned it into a principle.<\/p>\n\n\n\n

    The answer: stop prompting, start engineering context<\/h2>\n\n\n\n

    The most practical answer to the chaos of vibe coding didn’t come from some big lab \u2014 it came from watching how an agent actually works. It was articulated by Dex Horthy of HumanLayer in the essay Advanced Context Engineering for Coding Agents<\/em> (ACE-FCA for short), and the core is brutally simple:<\/p>\n\n\n\n

    \n

    An agent’s turn is a stateless function. Context in, next step out. The contents of the context window are the only lever you have on output quality \u2014 so it’s worth obsessing over.<\/p>\n<\/blockquote>\n\n\n\n

    Everything else follows. Horthy’s rule of thumb is to keep context-window utilization in the 40\u201360% range<\/strong> (it depends on the problem’s complexity). Push past that \u2014 keep cramming in \u2014 and recall and reasoning start to crumble. The more you stuff in, the worse the result. You can’t prompt your way back out; you have to design the whole workflow so context is managed deliberately, not piled up by accident.<\/p>\n\n\n\n

    The instrument of that discipline is a loop you’ve probably seen under various names: Research \u2192 Plan \u2192 Implement (RPI)<\/strong>.<\/p>\n\n\n\n

    The RPI flow: three phases, one rule<\/h2>\n\n\n\n
    \n

    \ud83d\udca1 The one rule:<\/strong> we don’t write a single line of code until an approved plan-artifact exists. Everything else is a consequence.<\/p>\n<\/div><\/div>\n\n\n\n

      \n
    1. Research.<\/strong> The agent doesn’t touch code \u2014 it maps the terrain: where functionality lives, the conventions, what calls what. Findings land in a doc with concrete file:line<\/code> references and open questions. Verifying it takes minutes; debugging a decision made on bad reconnaissance takes hours.<\/li>\n\n\n\n
    2. Plan.<\/strong> From the research, a plan takes shape: what changes, in what phases, the success criteria, and \u2014 just as important \u2014 what we deliberately are NOT doing. This is the only right place for architectural decisions<\/strong> \u2014 which pattern, where a boundary sits, how it maps to the domain. You approve them here, on a cheap artifact, before the agent guesses them wrong in code. No open questions survive. This file becomes the source of truth.<\/li>\n\n\n\n
    3. Implement.<\/strong> Only now, code \u2014 launched in a fresh<\/em> window loading only the plan. The exhausting research-and-planning session that ate 60\u201380% of the context distills into a ~200-line artifact taking a dozen-odd percent (Horthy calls this frequent intentional compaction<\/em>). The agent codes in phases and verifies after each.<\/li>\n<\/ol>\n\n\n\n
      \"The<\/figure>\n\n\n\n

      Notice where you are in all of this. You’re not banging out code \u2014 you’re reviewing the research and the plan<\/strong>. And as Horthy aptly puts it, reviewing a plan gives you more leverage than reviewing code.<\/strong> Because at the plan stage a fix costs a sentence; at the code stage it costs a refactor.<\/p>\n\n\n\n

      This skeleton has a wider family. The whole Spec-Driven Development movement (tools like OpenSpec, GitHub Spec Kit, or Kiro) grows from the same intuition: spec\/plan before code, code as a derived artifact. RPI is its most “context-first” variant \u2014 less ceremony, more emphasis on what the agent actually holds in its window.<\/p>\n\n\n\n

      Don’t wheel it out for everything<\/h2>\n\n\n\n

      Two caveats before you reach for this on every task.<\/p>\n\n\n\n

      First: don’t. RPI is heavy machinery. For a small, self-contained change \u2014 a typo, one new field, a fix you can hold in your head \u2014 a single prompt, spelled out with care, is the right tool; wrapping it in research, plan, and review costs more than the change is worth. The dividing line is simple: if every relevant detail fits in one prompt without you leaving anything out, just prompt it. It’s when it doesn’t<\/em> that the structure earns its keep.<\/p>\n\n\n\n

      Reach for a single prompt<\/th>Reach for RPI<\/th><\/tr><\/thead>
      A typo, one field, a small fix<\/td>A change touching many modules or layers<\/td><\/tr>
      Everything fits in one prompt<\/td>You’d inevitably leave something out<\/td><\/tr>
      Blast radius is local<\/td>A bad call costs the whole system<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Second, and less obvious: even when RPI feels like overhead, it pays a dividend beyond the change itself. Working through research and a plan builds your<\/em> understanding of the system, forces the architecture into the open, and leaves durable artifacts behind.<\/p>\n\n\n\n

      The research doc, the plan, the review notes don’t evaporate when the code merges \u2014 they become documentation: the context you (and the next agent) load at the start of the next task, so every future session begins already knowing the terrain.<\/p>\n\n\n\n

      \n

      The plan isn’t a cost you pay once \u2014 it’s an asset that compounds.<\/p>\n<\/blockquote>\n\n\n\n

      How to start \u2014 today, without a revolution<\/h2>\n\n\n\n

      You don’t have to rewrite how you work overnight. Three moves to begin:<\/p>\n\n\n\n

      Create a CLAUDE.md<\/code> (or AGENTS.md<\/code>) in the repo \u2014 a project constitution: conventions, stack, security rules, what not to touch. It’s persistent context the agent always reads.<\/p>\n\n\n\n

      # CLAUDE.md \u2014 project constitution\n\n## Stack\n- Java 25 + Micronaut, Postgres, Docker\n\n## Conventions\n- Controllers stay thin; business logic lives in services\n- Map DTOs in dedicated mappers, never in controllers\n- One reason to change per class\n\n## Security\n- Never log secrets or PII; validate external input at the boundary\n\n## Do not touch\n- Generated code, lockfiles, CI config \u2014 unless asked<\/code><\/pre>\n\n\n\n
      On your next non-trivial task, force the order on yourself: research first (the agent only reads and summarizes), then a plan (which you<\/em> read), then code. Even with no tooling at all, the sheer discipline of “plan before code” changes outcomes.<\/p>\n\n\n\n
      Guard the context window. When a session gets long and sluggish, clear it and come back in with the plan instead of dragging a clogged thread along. The public .claude\/commands\/<\/code> from HumanLayer’s repo are a ready starting point if you want slash-commands research \u2192 plan \u2192 implement<\/code> right away.<\/p>\n\n\n\n
      The flow is not dogma \u2014 grow it to fit you<\/h2>\n\n\n\n
      The most important thing to grasp: RPI is a skeleton<\/em>, not scripture. Once you feel it, you’ll start seeing what you<\/em> are missing \u2014 and that’s the right moment to extend it.<\/p>\n\n\n\n
      A good example of how far this can be taken is Maister<\/strong> \u2014 an open project (SkillPanel) that packages the same core as a Claude Code plugin and adds things plain RPI doesn’t have:<\/p>\n\n\n\n