We built an AWS tool with AI agents — that's exactly why we could be strict about correctness

Design Beaver is open in soft launch — an AWS architecture diagramming tool that validates as you draw, catching missing queues, invalid connections, and security anti-patterns while you’re still sketching. It was built by a very small team leaning hard on Claude agents, and the natural worry when you hear that is slop: AI-built tools have a reputation for confident, plausible wrongness. So here’s the claim this whole post defends — the agents are the reason we could be stricter about correctness, not sloppier. “Built with AI” usually means “generated fast, checked loosely.” We did the opposite: we made grounding and review so cheap that skipping them was never on the table. Here’s how the pieces fit.

One rule: vibe-code what has no right answer, spec-drive what does

We split the product down a single line. Things with no ground truth — the canvas, the drag feel, the shape of a node — we build by feel, because trying things is the fastest honest way to find what feels right. Things with a ground truth you can be wrong about — every rule for how AWS actually behaves — we never improvise.

We wrote about the moment that line forced itself on us in an earlier post: the day “just keep building by feel” stopped being enough. This post is about what grew out of that rule once we took it seriously across the whole project — not just the validation engine, but the blog, the docs, the SEO pages. All of it.

Spec-driven means the rules live outside the code

Design Beaver knows about 42 AWS services today, and not one of their connection rules is hand-typed into application logic. Each service is a plain-text spec file: what it is, which services it connects to, in which direction, what each connection requires, and which pairings are forbidden and why. Every fact is grounded against official AWS documentation with a note on the source — never written from memory. A build step compiles those files into the exact rules the product validates against.

That indirection is the point. The spec on disk and the diagram on your screen can’t drift apart, because one is generated from the other. When we disagree about whether a connection is valid, we don’t argue from experience — we read the file, and if the file is wrong, we fix the file and the product follows.

The same discipline shows up in smaller places. The knowledge base is split in two: a public half (names, descriptions, curated connection summaries — safe for this marketing site) and an internal half (the full validation mechanics the app enforces). This blog is built from the public half only.

And here’s the honest version of that boundary — it isn’t a sealed wall. It’s the package’s export map plus a rule we hold ourselves to, and our own engineering notes say so out loud: there’s no lint check catching a violation yet, so “don’t pull the internal rules into the marketing site” is written down where the next person will see it. Naming the gap is the point. The boundary you pretend is airtight is the one that quietly leaks.

The part most “AI-built” projects skip: the review gate

Generation is the easy half. Anything can generate 42 service files or a 1,500-word post. The half that separates rigorous from sloppy is what happens after the draft — and it’s the half that usually gets waved through.

So every generator in this project is paired with a skeptical reviewer. The blog has a writer skill and a separate cold-review skill that scores each draft as a skeptical AWS engineer who has actually used the competing tools — weighted on technical accuracy, voice, and whether the post says anything a reader couldn’t get elsewhere. A failing score blocks publish. It’s not advice to consider; it’s a gate.

And the rubric has a floor most review processes skip: one wrong AWS fact sinks the whole post, no matter how well it scores on everything else. A sharp read with one bad connection fact isn’t a sharp read — it’s a confidently wrong one, which is worse than a boring-but-correct one. The per-service SEO pages have the same setup: a writer, and a reviewer whose entire job is to catch thin, templated, plausible-but-empty content before it ships.

This post you’re reading ran that loop. An earlier draft came back from the reviewer with a correctness fix — I’d overstated how airtight that public/internal boundary was, and the gate caught it before you did. That’s the system working, not failing. The anti-slop mechanism isn’t “we’re careful” — carefulness doesn’t scale to a tiny team. It’s that the careless path is closed off by construction.

Why this beats both hand-building and naive AI

Hand-authoring 42 services’ worth of connection facts from memory is how plausible-but-wrong slips in. We know because it happened: an early pass on VPC endpoints wrongly claimed DynamoDB has no interface endpoint. It does. That’s exactly the kind of fact that feels right, renders fine in a diagram, and quietly teaches the reader something false. Naive AI generation makes the same mistake — just faster and at more services.

Grounded generation plus a review gate is the only version that avoids both. Take a concrete rule. Chaining one Lambda straight into another under load can silently drop work. The correct pattern puts a queue between them — and a dead-letter queue behind that, so messages that repeatedly fail get isolated for inspection instead of retried into oblivion. We wrote up the full case separately. The point here is that Design Beaver enforces that rule because it’s written down, sourced, and compiled in — not because someone remembered it correctly the day they typed it.

The method is the product’s promise, applied to ourselves

If there’s one takeaway for anyone building with agents right now, it’s this: the real advantage isn’t generation speed. It’s that agents let you make grounding and review non-optional — checks a human team would skip under deadline, an agent runs every single time without getting tired of it. Point that at the parts of your work that have a right answer, and “built with AI” stops meaning “trust me” and starts meaning “here’s the source and here’s what checked it.”

That’s the same deal Design Beaver offers you. Correctness you don’t have to take on faith, because the tool checked it against how AWS actually works — the way we check every rule before it ships. If that’s the kind of tool you want pointed at your own architecture, join the waitlist — the same discipline that checked this post is the one that’ll check your diagrams.