Keep Drawing: Architecture in the Age of Vibe Coding

A note up front: this one is for a technical audience — architects, engineers, CTOs, and the technically-minded leaders who buy and govern software. If that's not you, feel free to scroll on. No hard feelings.

I'm writing this not as a founder or a builder, but as a career architect. Most of my working life has been spent with whiteboards, boxes, arrows, and the unglamorous discipline of trying to make a system legible to the next person who has to live with it. So forgive me if what follows reads like a craftsman defending his bench — that's exactly what it is.

We are living through the "vibe coding" moment. A prompt becomes a prototype in minutes. A prototype becomes a product over a weekend. The friction that used to separate an idea from a running application has largely collapsed, and the velocity is real. I use these tools every day, and I'm glad they exist.

I'm also thoughtful about what they let us skip. Speed is not the same as soundness, and the fact that something runs is not evidence that it should.

But I want to make a case that's getting harder to hear in the noise: the artifacts of design — the diagrams, the boundaries, the named components, the documented decisions — are not vestigial. They are not the cost of doing software the old, slow way. They are the thing that distinguishes a system you can operate, audit, defend, and evolve from a pile of generated code that happens to run on Tuesday.

The craft argument

Architecture is the practice of deciding what something is before deciding what it does. It's where you answer the questions code can't: What are the trust boundaries? Where does data cross a regulated perimeter? Who owns this component when it breaks at 2 a.m.? What changes if we double the load, or lose a region, or get acquired?

You cannot prompt your way to those answers. You can prompt your way to code that appears to address them, which is a more dangerous thing. A model trained on a million repositories will happily emit a service that "handles authentication" without any opinion on where your authorization boundary lives, what your token lifetime should be, or whether the thing it just wrote leaks PII into a log line that gets shipped to a third-party observability vendor.

The architect's job hasn't changed. The temptation to skip it has just gotten more seductive.

When I look at a system someone has built — mine, a vendor's, a team I'm advising — the questions I'm trying to answer are almost never about the code itself. They're about the shape of the thing. What are the parts? How do they talk? What's inside the trust boundary and what's outside it? Where does state live, and what happens when it doesn't? Code can be read, but shape has to be drawn.

The buyer's argument

If you purchase software for your business — and especially if you purchase it for a regulated business — you should be asking your vendors to show you their architecture. Not as a marketing exercise. As due diligence.

Ask for a system context diagram. Ask where customer data flows. Ask what's in their trust boundary and what's outside it. Ask which components are theirs, which are third-party, and where the seams are. If the answer is a hand-wave, a screenshot of a marketecture slide, or "our AI handles that" — that is information. Useful information. It tells you something about whether the people building the thing have ever had to defend it to anyone who matters.

A vendor who can produce a clear, current, honest architecture diagram has done a thing that's hard. They've thought about their system the way you'll need to think about it when something goes wrong. A vendor who can't is asking you to take their word for it.

The auditor's argument

This part is coming whether we're ready or not. Anywhere software has to answer to someone — regulators, auditors, security reviewers, enterprise procurement, your own internal risk function — the questions about how a system was built are going to get sharper.

It's already true in financial services, healthcare, and critical infrastructure, where examiners have always asked how systems are designed, who owns them, and where the data flows. But the same dynamic is showing up in less obvious places: SOC 2 reviews, ISO 27001 audits, enterprise security questionnaires, due diligence in M&A, even the procurement processes inside large companies that have started asking vendors to disclose AI usage in their development pipelines. None of these frameworks were written with generative AI in mind, and all of them apply.

What's changing is the burden of proof. When a human team builds a system, the architecture is implicit in the team — you can interview the engineers, read the design docs, follow the commit history. When significant portions of code are generated, the human reasoning has to be made explicit somewhere else, or it effectively doesn't exist. The diagram, the decision record, the trust-boundary map — these stop being "good hygiene" and start being the only durable evidence that a person was meaningfully in the loop.

The question I expect to show up everywhere, in some form: Show me how this system was designed, by whom, and what decisions were made about where AI-generated components are and aren't trusted. Teams that treated their architecture as a first-class, versioned artifact all along will have an answer. Teams that can't produce a current Context diagram, can't articulate their trust boundaries, and can't tell a reviewer which parts of their stack were human-authored versus model-generated are going to have a harder time than they're expecting.

"We vibe-coded it" is not an audit response. Neither is "the AI handles that." Provenance matters, and the artifacts of architecture are how you produce it on demand.

C4 — a quick primer

If you don't already have a documentation discipline, the C4 model by Simon Brown is the cheapest, highest-leverage thing you can adopt. It's four nested levels of diagram, each answering a different question:

• Context — Who uses the system, and what does it talk to? One box for your system, surrounded by users and external systems. This is the diagram you give to a board, a regulator, or a new employee on day one.
• Container — What are the deployable/runnable units? Web app, API, database, queue, batch worker. This is the diagram that tells you where things run and how they communicate.
• Component — Inside a container, what are the major logical pieces and how do they collaborate? This is where most architects spend their time and where most teams stop documenting.
• Code — Class or schema-level detail, usually generated rather than hand-drawn. Most teams don't need this level often, and that's fine.

The genius of C4 is that it's just enough structure. Four levels, consistent notation, no UML priesthood. A small team can adopt it in an afternoon and have something useful by the end of the week. A buyer evaluating a vendor can ask for "your C4 Context and Container diagrams" and get a meaningful answer in a vocabulary the vendor's engineers already understand.

Where this leaves us

I am bullish on AI-assisted development. I use it. I ship with it. I think the productivity gains are real and durable.

But the gains compound when the human in the loop is doing the work that the model can't: deciding what the system is, where its boundaries live, who owns its parts, and what the next person needs to know to keep it alive. That work shows up as diagrams. It shows up as written decisions. It shows up as architecture.

If you build software, keep drawing. If you buy software, ask to see the drawings. And if you review, audit, or sign off on software — start asking now. The teams who've been doing this all along will be ready. The ones who haven't will have a long week ahead of them.