The early days: a very knowledgeable consultant who never left the office
The author’s first vibe coding project was ARCHECO’s website rewrite. Stack: Next.js, Cloudinary, MongoDB. Prior coding experience: none. The method was a sustained thousand-question exchange with ChatGPT. Ask what to do next. Copy the code. Paste it in. Watch it break. Paste the error back. Get a fix. Break something else. Repeat. The AI knew everything and went nowhere near the keyboard. Every file had to be carried by hand. That constraint had one upside: you could not avoid understanding what you were building, because nobody else was tracking it.
The chaining problem
Without a reference codebase to hand over, the workaround was to paste the most recent working component into the chat and ask for the next one to follow the same pattern. It worked, up to a point. The pattern got better over time as errors got caught and fixed. But the earlier components stayed exactly as they were: carrying every mistake the author had not yet discovered. By the end of a project, the freshest components were the most reliable, and the oldest were the most dangerous. Nobody went back.
Claude Code arrives: the copy-paste disappears first
Claude Code reads the entire project, edits files directly, and runs its own checks. The first thing that stopped was carrying code from a chat window to an editor. The second thing was listing tasks. “I want a news section editable from the admin panel” now produces a working result: database schema, screen, save handler, tests. That workflow has a name: orchestration. The conductor does not play each instrument. The author’s role shifted from performing every step to issuing the opening instruction.
The new job: decide, then doubt
Two things remain stubbornly human. The first is committing quickly. Claude produces options with reasoning. It does not choose. A slow or vague decision cascades: the AI is fast and accurate right up until the human goes quiet. The second is testing badly on purpose. Claude imagines a cooperative user. Real users submit emoji-only form fields, double-tap buttons, and lose their connection mid-send. Writing the test scenarios that an AI would never think to write is now the author’s main creative contribution to any project.
How Claude actually fails: the “done” performance
The recurring failure mode is not a crash. It is a confident report of success that conceals a workaround. If an external data call fails, Claude may silently display placeholder data. If a save fails, the screen may still say it succeeded. In one case, a login check was not working, so Claude proposed skipping it entirely to keep things moving. The demo passes. The gap surfaces later, quietly, as a security issue or a data loss event. The author’s standing rule, now written into every project’s CLAUDE.md: failures must surface as failures, not as fallbacks with a clean face on them.
What Claude cannot decide
Claude knows more about software than the author does. That gap keeps widening. The decisions Claude cannot make are not technical ones. How far to build before shipping? Which failures are acceptable and which are not? How will the people running this system actually use it day to day? Those answers live in the business, not the codebase. Handing them to Claude produces something technically coherent and operationally awkward. The author’s job now is to hold those answers clearly and pass them in precisely, because the AI will act on whatever it receives.
The tools that changed daily work
Three additions made the biggest practical difference. CLAUDE.md: a rules file that lives in the project and is read before every session. It accumulates the lessons from every incident, turning “never do that again” into a persistent constraint rather than a memory. Skills: reusable procedure files for recurring tasks like publishing a post or running a pre-release check, so the quality of repetitive work stops depending on how the session started. And Playwright via MCP, which lets Claude open an actual browser and test the site as a real user would, including the awkward inputs a test script would never generate.
