The 30-Minute Lie
Last month, I spent 30 minutes in Lucidchart before a design review.
I dragged every box. Connected every arrow. Labeled every subnet, every security group, every load balancer. It looked beautiful.
By the next sprint, half of it was wrong.
A new service had been added. The auth flow had moved to a different VPC. Someone swapped Redis for DynamoDB. Nobody updated the diagram. Why would they? It lived in a tool nobody opened unless there was a meeting.
That diagram — the one I spent 30 minutes on — became a lie.
And here's the thing: this happens in every team I've worked with.
We Solved This Problem Everywhere Else
Think about what DevOps has automated in the last decade:
- Infrastructure → Terraform, Pulumi, CloudFormation
- Configuration → Ansible, Chef, Puppet
- Deployments → ArgoCD, Flux, GitHub Actions
- Monitoring → Prometheus rules as code, Grafana dashboards as JSON
- Security policies → OPA, Sentinel
- Documentation → Markdown in the repo, generated API docs
We version control everything. We code-review everything. We automate everything.
Except the one thing every engineer asks for in their first week:
"Do we have an architecture diagram?"
And the answer is always the same: "There's one in Confluence, but it's probably outdated."
Why Diagrams Resist Automation
I've thought about this a lot. Here's why diagrams have stayed manual while everything else moved to code:
1. The tools are built for designers, not engineers
Lucidchart, Draw.io, Miro — they optimize for visual fidelity and drag-and-drop. None of them treat diagrams as artifacts that should live next to code.
2. PlantUML and Mermaid exist, but they have a learning curve
Yes, you can write diagrams in code today. But the syntax is unfamiliar, the AWS/GCP icon libraries are clunky, and most engineers give up after their first attempt.
3. There's no source of truth
Your Terraform describes what exists. Your diagram describes what someone thought existed three months ago. They drift, and there's no reconciliation.
4. Diagrams die in PR review
You can't review a .png in a pull request. You can't diff two versions of a Lucidchart export. So diagrams stay outside the review process — and outside, they rot.
What Would "Diagrams as Code" Actually Look Like?
If we applied the same principles to diagrams that we apply to infrastructure, here's what changes:
| Before | After |
|---|---|
| Open Lucidchart | Type a description |
| Drag boxes for 30 minutes | Generate in 5 seconds |
| Export to PNG | Commit the source to git |
| Forget to update | Diff in pull requests |
| One source of truth in someone's head | One source of truth in the repo |
The diagram becomes a build artifact, not a manual task.
You describe your system in plain English. A tool turns that description into a clean, accurate diagram. The description lives in your repo. It gets reviewed in PRs. When the system changes, the description changes with it.
The diagram stops being a lie.
What I'm Building
This is the problem I'm trying to solve with SketchMyInfra.
The idea is simple: type what you're building, get an accurate architecture diagram in seconds. No drag-and-drop. No icon libraries to learn. No more 30-minute Lucidchart sessions before design reviews.
I'm building it in public — backend is in progress, frontend waitlist is live. If this resonates with you, I'd love to hear:
- Have you experienced the diagram-rot problem? How does your team deal with it today?
- What would make a tool like this actually useful to you in your workflow?
- What's the worst outdated diagram you've ever inherited? (We've all got one.)
Drop your thoughts in the comments. And if you want to follow along or join the beta when it ships, you can sign up at sketchmyinfra.com.
I'll be writing about the architecture, the AI prompt engineering, and the deployment as I build. Follow along if you're into build-in-public stories.
Top comments (0)