Juilee in the wild

There is no such thing as vibe coding

One of the things I missed most when I stepped into a leadership role was my ability to build and ship code. But AI has made the barrier lower. Recently at my company’s annual hackathon I built two products - A native calendar feature prototype to make touring easier and a marketing budget scenario planning tool which went on to become a production tool in two weeks!

Both made one thing really clear - there is no such thing as vibe coding.

To build a real, reliable, production ready tool you need good architecture, detailed specs and proper context not just good prompts.

Here’s my learnings from building a 0 → 1 production tool in two weeks

Shipping code is the easy part, building a reliable product is harder

The core product I set out to build was a marketing scenario planning tool which simulated incremental KPI volumes, revenue, and ROAS based on user media mix and budget inputs. Under the hood, it projected marketing outcomes and ROAS using a mix of forecasting approaches and response curves from causal marketing mix models and experiments.

The starting point was a Replit tool stitched together by stakeholders using scattered context and code. The tool worked, but underneath, the backend was held together by hardcoded values, local files, manual uploads, and primitive math. It ran but didn’t yet contain the complete data, logic, or infrastructure needed to produce reliable outputs.

My core job was to build it into a tool that worked—and, more importantly, could be trusted.

Attempt one - pure prompting

I started with simple prompting. Having a general idea of the tool and purely prompting my way to features.
Prompting implemented the features fast, made the tool look pretty.
But the actual outcomes? Nonsense.
The code kept getting stuck in the same loop and every fix introduced a new inconsistency somewhere else. Untangling one piece took a dozen iterations just to get back to where the tool had been stuck all along.

Attempt two - more context , same problem

The second attempt corrected for the obvious gap: “Context”. I wrote a detailed “tool vision” document describing what the tool should look like, functionality, user flow, data context, metric computation etc . Feeding that directly to Claude Code did produce a better result than vibe coding, but still didn’t stop Claude from making assumptions and discarding guidelines the moment it encountered ambiguity.
The result - made up numbers, messy backend, poorly designed, force-fit, umbrella functions.
A working prototype, but not a tool built to be extended or trusted with a real number.

What actually worked: separate the thinking from the doing

The method that held up was splitting the work across two passes instead of one. I fed the vision doc to Claude Opus, running at high reasoning effort, and asked it to break the vision into a detailed spec that Claude Code could execute against. The most important addition to this architecture was execution checkpoints and negative prompts - explicit instructions to coding agents on what not to do.

That discipline turned out to matter more than it sounds like it should. Vibe coding optimizes for the next prompt looking right, not for the system underneath holding together. But explicit negative prompts and execution checkpoints control for rogue LLM rabbit holes and hard-to-detect assumptions that force-fit specs. This is especially important for workflows that produce numbers. Unlike a product flow, which has a bounded set of user paths that can be tested, outputs of numerical tools can vary—making it impossible to verify every output individually. Reliability must therefore come from a trusted computational layer: reviewed formulas, standardized queries, validated statistical packages, and trusted data sources, rather than logic an LLM invents on the fly.

Another breakthrough was modular design. I explicitly instructed Opus to make the build modular, so a piece like response-curve prediction could be developed, tested, and modified independently of a piece like ROAS calculation and an individual module could be updated or replaced without compromising the structural integrity of the system.

Once the spec had that scaffolding, I had Opus design the actual implementation prompts, one per module and build phase. Even at that point, review stayed essential - reasoning models, especially at higher effort, tend to overcomplicate and over-engineer, and the design specs Opus produced still made assumptions during the build that had to be caught and redirected back to the central objective. I fed those prompts to Claude Code section by section, and reviewed and corrected the output of each one before moving to the next, rather than letting the whole build run unsupervised.

None of that is a prompting trick. It’s closer to a checklist an engineer would use, translated into instructions a model has to follow.

The workflow I’d use again

  1. Write the product vision, including objective, end outcome, user experience, context, data sources, and computation logic yourself.
  2. Give that vision to a high-reasoning model to design the architecture, identify ambiguity, and design explicit negative instructions.
  3. Break the architecture into scoped implementation prompts with clear inputs, outputs, tests, and stopping conditions.
  4. Give each prompt to the coding agent separately.
  5. Add a human review gate after every section. Build and ship incrementally instead of a giant system.

What made the tool prod ready in two weeks was not perfect prompts. It was structure:

The bottleneck is AI slop, not code complexity.

AI has really compressed the distance between an idea and a working product. But that also means the bottleneck has shifted from speed to design. The failure mode is no longer complexity of code. It is designing a system that holds under change and produces reliable outcomes consistently.

Through it all - one thing is clear - there is still no elevator to success. Outcomes, whether vibe coded or hand-written, are still directly proportional to effort put in producing them. AI has lowered the barrier for execution but it cannot do the thinking for you. When code becomes cheap, judgment is really what makes the difference.