You can vibe-code a canvas. You can't vibe-code correctness.

Design Beaver started with a conversation with a friend who ships products for a living. I’d had the itch to build something of my own for a while — the low-grade restlessness most engineers know. The plan was almost embarrassingly simple: vibe-code an AWS diagramming canvas. Drag some boxes, draw some connections, wire it up, see where it went. No spec, no architecture doc.

That worked right up until it didn’t. This post is about where the line was — the exact point where “just keep building by feel” stopped being enough, and what we had to change to get past it.

What vibe-coding got us, fast

For the canvas itself, vibe-coding is genuinely the right tool. Drag a box. Drag another. Draw a line between them. Make the box a little rounder, the shadow a little softer, the snap-to-grid a little tighter. There’s no wrong answer to “what should a service node look like” — only answers that feel better or worse, and you find those by trying them, not by writing them down first.

So the early days moved quickly. Nodes rendered, edges connected, the thing looked like a diagramming tool. If Design Beaver were only a place to arrange AWS icons on a grid, we’d have been most of the way done. Iterating by feel gets you a long way when the only thing at stake is how something looks.

The moment it broke

Then you get to the part that’s the actual point of the tool: knowing which of those connections are valid.

And “valid” isn’t a matter of taste. Whether a queue can talk to a database directly, whether a connection runs one way or both, whether a given pairing is a real AWS integration or a line that only looks plausible — none of that is something you can eyeball and tweak until it feels right. There’s a correct answer, it lives in AWS’s actual behavior, and you either match it or you’re wrong.

That’s where vibing fell apart. A diagramming tool that draws a pretty but incorrect connection is worse than no tool at all — it launders a mistake into something that looks reviewed. The whole promise of Design Beaver is that it validates as you draw, and you can’t improvise your way to trustworthy validation. The first wrong rule you ship quietly poisons every diagram after it.

Why correctness resists vibe-coding

A UI has no ground truth to be wrong about. A rule does.

Every connection in Design Beaver encodes a specific fact about how AWS actually works — the direction it’s allowed to run, what it requires to be valid, and, when it’s forbidden, the reason why. Take Route 53 and Lambda. Pointing a DNS record straight at your function feels like a perfectly reasonable thing to draw — you want traffic for a hostname to hit some Lambda, so you connect the two. But Lambda isn’t a DNS-addressable target; Route 53 can’t point a record directly at a function. A Lambda Function URL has its own HTTPS endpoint you could aim a record at, but that’s a Route 53–to–HTTPS-endpoint edge, not a Route 53–to–Lambda relationship.

Draw that edge and the diagram still renders. It just tells the reader something false — that a DNS record is wired to a function it can’t actually reach. Multiply that by every service pairing, every “these two can’t connect directly,” every “this one needs a consumer in between,” and you have hundreds of small facts that are each easy to get plausibly wrong from memory — and impossible to get right by feel. This is exactly the kind of knowledge you can’t vibe-code.

What “getting serious” actually meant

The fix wasn’t more discipline about vibe-coding. It was admitting that the correctness layer needed a different way of working entirely: spec-driven.

Instead of encoding AWS rules directly in application code where they’d be invisible and unauditable, we made the rules their own source of truth. Each AWS service gets a plain-text knowledge file — what it is, which services it can connect to, in which direction, what each connection requires, and which pairings are forbidden and why. Every one of those files is grounded against official AWS documentation, with a note on the source, not written from memory. A build step compiles those files into the exact rules the product validates against, so the diagram on your screen and the spec on disk can never drift apart.

The spec became the product’s memory of what’s true. When we disagree about whether a connection is valid, we don’t argue from experience — we go read what the file says, and if the file is wrong, we fix the file and the product follows.

Where the agents came in

There was still one problem: researching a single AWS service properly — reading the docs, pinning down every valid connection and every anti-pattern, citing sources — is slow, and doing it from memory is exactly how a plausible-but-wrong fact slips in. So the research itself became an agentic workflow.

We built a dedicated research agent whose only job is to take one AWS service, work through the official documentation, and produce that service’s spec file — flagging clearly what it verified against a source versus what still needs a human to confirm. Nobody hand-authors a new service’s rules anymore. The agent grounds the facts, a human reviews them, and the spec goes in. Agentic development isn’t a novelty bolted on here; it’s the thing that makes “ground every rule in a real source” survivable at more than a handful of services.

The shift, start to finish, looked like this: the parts of the product with no ground truth — the canvas, the interactions, the feel — we still build by vibe, because that’s the fastest honest way to build them. The parts that have to be correct — every rule about how AWS actually behaves — we build spec-first, grounded, and reviewed, because there’s no vibing your way to a fact.

The takeaway

If there’s a lesson in here for anyone building something of their own, it’s this: figure out early which parts of your product have a right answer and which parts only have a good-enough one. Vibe-code the second kind freely — it’s the fastest way to find the feel. But the moment you hit something with a ground truth you can be wrong about, stop improvising and write it down. For us that line ran straight between the canvas and the correctness engine, and the whole shape of how we build changed the day we admitted it.

If you want a tool that treats AWS correctness as something to get right rather than something to render, open Design Beaver — it’s live in beta, free, and runs in your browser with no account required.