troels.im

Vibe Engineering ≠ Prompt and Pray: Why AI + Structure = Speed

There's a phrase making the rounds that captures something important: "Vibe Engineering ≠ Prompt and Pray." I've been seeing it in LinkedIn posts and industry discussions.

The observation is correct. But the conclusion most people draw from it is backwards.

The common interpretation goes something like this: AI removes boilerplate, shortens feedback loops, and frees teams to focus on design and risk. Sounds great. Except that's only half the story—and it's the half that leads teams into what I call the "Day 2 problem."

The Day 2 Problem

Speed on Day 1 is meaningless if it creates fragility on Day 2.

I've spent over $10,000 on AI coding tools last year, logged hundreds of development sessions with Claude, and built production systems with varying degrees of AI assistance. The pattern I see is consistent: treating AI as a boilerplate eliminator eventually hit a wall. Treating AI as a boilerplate accelerator compound their velocity. That is, if you don't set out the rules for what your structure, the structure will vary a great deal when auto-generated by AI. And ironically, this means that using boilerplates with AI gives far superior results.

The distinction matters more than it might seem.

The Case Against Removing Boilerplate

Here's the counterintuitive insight: AI + Boilerplates + strong error checking = Accelerated workflow.

This flips the narrative. Instead of AI replacing scaffolding, scaffolding becomes the structure that makes AI-generated code reliable.

Consider what happens when you "vibe code" a new feature from scratch:

  • The AI generates code based on patterns it's seen
  • Those patterns might not match your architecture
  • Edge cases get missed because there's no template enforcing them
  • Type mismatches surface at runtime instead of compile time
  • Each new feature is a fresh adventure in debugging

Now consider what happens when you have a well-structured boilerplate:

  • The AI fills in the implementation within defined boundaries
  • Type constraints catch errors before execution
  • Architectural patterns are enforced by the scaffold
  • Code review becomes "does this fit the pattern" rather than "what even is this"
  • Each new feature builds on proven foundations

The difference isn't subtle. It's the difference between sustainable velocity and a ticking time bomb.

Why Rust Changes the Equation

This is where Rust becomes interesting—not as a trendy language choice, but as a strategic decision for AI-assisted development.

Google's Android team recently published data showing that Rust code in Android is measurably safer than their historical C/C++ codebase. More relevant for our discussion: Rust's compiler catches entire categories of bugs at compile time that would otherwise surface in production.

When AI generates code, it occasionally gets things wrong. That's not speculation—it's empirical reality. The question becomes: how quickly do you discover those mistakes? and at what rates do they compound?

In Python or JavaScript, you might not discover type mismatches until runtime. In production. At 2 AM.

And what more is, undiscovered issues compound! Eventually it becomes a can of worms, where, while fixing one issue, you get plagued by another issue.

In Rust, the compiler won't let you ship that code in the first place. AI can generate incorrect logic, but it cannot generate code that violates the type system. The feedback loop tightens from "deploy → monitor → debug → fix" to "generate → compile → fix → compile → done."

The ownership model compounds this advantage. Memory safety issues, data races, use-after-free—these aren't categories you need to worry about in code review. The compiler handles them. Your review time focuses on business logic and architecture, the parts that actually require human judgment.

The ACE Framework: Structure for AI-Assisted Development

At CompoundCoders, I teach a methodology called ACE—Accurate prompting, Chaining, and Evaluation. It's designed precisely for this problem: how do you get consistent, production-grade results from AI assistance?

Accurate prompting means providing the AI with structured context. Not "build me an API," but specifications that include types, constraints, architectural boundaries, and reference implementations. The more structure you provide, the more reliable the output.

Chaining means breaking complex tasks into verifiable steps. Generate the data types first. Then the validation logic. Then the business logic. Then the error handling. Each step builds on verified foundations.

Evaluation means testing AI output against explicit criteria. Does it match the type signatures? Does it handle the specified edge cases? Does it integrate with the existing patterns?

Notice what all three components share: they assume structure exists. Boilerplates, type systems, architectural scaffolds, test frameworks—these aren't obstacles to AI-assisted development. They're the foundation that makes it work.

Context Engineering: The Industry Shift

The broader industry is arriving at similar conclusions through different paths.

MIT Technology Review recently described the shift "from vibe coding to context engineering." The core insight: prompts alone aren't enough for complex applications. You need structured context—schemas, patterns, specifications, constraints.

GitHub's Spec-Kit formalizes this as "Spec-Driven Development": specifications become executable, directly generating working implementations rather than just guiding them. AWS Kiro takes it further, requiring formal specifications before AI begins generating code.

Collins Dictionary named "Vibe Coding" their 2025 Word of the Year, which is telling. The hype cycle peaked. Now comes the engineering discipline.

The pattern across all these developments is consistent: the future of AI-assisted development isn't less structure. It's more structure, more thoughtfully applied.

Practical Implications

If you're leading a team that's adopting AI-assisted development, here's what I'd recommend:

Invest in boilerplates. Not as bureaucratic overhead, but as multipliers for AI effectiveness. Every well-designed scaffold is a template the AI can reliably fill. Every type definition is a constraint that prevents category errors.

Consider Rust for new systems. Not because it's fashionable, but because the compiler becomes your first line of defense against AI-generated mistakes. The upfront learning curve pays dividends in reduced debugging time.

Structure your prompts. The 15-second rule applies: if your prompt takes less than 15 seconds to write, it's probably too vague. Invest the time to specify constraints, types, edge cases, and architectural boundaries.

Chain your operations. Don't ask AI to generate entire features. Ask it to generate verified components that you assemble. The compound effect of small, correct pieces far exceeds the speed of large, uncertain chunks.

Evaluate systematically. AI output is a draft, not a deliverable. Build review checklists, run automated tests, validate against specifications. The organisations that sustain momentum will be the ones that adopt AI deliberately, with clear governance and ownership.

The Gap That's Widening

The gap is widening. On one side, developers treating AI as magic that sometimes works—vibe coding their way through projects, celebrating speed on Day 1 while accumulating technical debt for Day 2.

On the other side, developers with frameworks, evaluation systems, and compounding skills. They're not slower. They're building on foundations that scale.

Which side are you building toward?

This post is part of my work at CompoundCoders, where I teach developers the ACE framework for AI-assisted development. If you're spending on AI tools but not seeing the productivity gains you expected—or if Day 2 keeps catching up to you—that's exactly the gap I help close.

Currently building: Wonop Code, a Rust-based development tool that puts these principles into practice.