It's not a brag for me to say "I've been visualizing infrastructure since 2018" - it's the actual truth. That was the year I joined a lovely Portland-based startup called Stackery, which took infrastructure as code (IaC for those familiar) and generated an architecture diagram that looked like this:
The secret sauce was that it went both ways: drag and drop resources, get IaC back that you can then deploy. Though the startup has not existed since 2021, you can actually still play with the live editor ;)
Why am I bringing up ancient history? Well, Stackery went on to be acquired by AWS (something I can say now that I'm no longer employed by them) and became AWS Infrastructure Composer (née Application Composer), which takes infrastructure as code and generates an architecture diagram that looks like this:
And it also works both ways: drag and drop resources, get a Cloudformation template that you can then deploy. More importantly though, it's a powerful way to visually understand the distributed systems that make up serverless services and how they interact with each other.
Modern times
Today I'm at Stripe, which is not a cloud provider, so one would think there's no use case for visualizing IaC at my new job.
That was true until last month, when Stripe Projects was released and suddenly the Stripe CLI became a means to building anything!
With Projects, anyone can use the Stripe CLI to provision services from a quickly-expanding catalog of providers for hosting, auth, AI, databases, and so on - just about anything a hobby or real-world application may need. More commonly though, users are setting up their agents with the CLI and saying "build me an app that does X" and the agent can figure out that this use case requires a database and provision it straight from the CLI, as the gods intended.
So now we have an application composed of multiple services with increasing complexity that the developer may not fully understand - sound familiar for anyone around in the #believeinserverless days?
Visualizing Projects
I used Projects recently to build a transcription app for my team and wrote about the process here: From init to deploy. Even though that application is fairly simple and uses just two providers, Vercel and OpenRouter, I still thought a visualization would be useful for any of my teammates wanting to contribute to it, so I built a stripe-projects-visualizer app in a somewhat manic single afternoon.
This app looks at a project's .projects/state.json file, which is the source of truth for its provisioned services, analyzes how provider environment variables are used throughout the codebase, and comes up with an architecture diagram showing how your provisioned services connect and how data flows between them.
For example, here's the generated diagram for my transcription app:
From years to hours
Is this tool cool and useful? Sure, I'd like to think so. Is it missing features? Of course, but not as many as one would think for the time spent on it. My biggest takeaway from building it in one afternoon is that I could.
Stackery took six engineers many, many years to build and maintain. Infrastructure Composer started with five engineers, then expanded to nearly a dozen plus a UX team, but even the initial preview version launched at re:Invent 2022 took over 9 months of intense building. Then, my former team spent another year re-architecting the canvas part of it to be more portable and extensible.
The Stripe Projects Visualizer took one person one afternoon to build. I could probably launch a web app version of it tomorrow. This is an entirely different paradigm than I was in eight years ago. It's entirely different from eight months ago, when I was still fumbling while trying to use Kiro and Claude Code to improve the underlying canvas tech of Infrastructure Composer.
I almost titled this post "The Terrifying Reality of Years to Hours" because in some aspects (the ones where I would very much like to stay employed), this is terrifying. Security aspects as well, for that matter, though my adversarial agent assures me there are no security gaps in my repo (whew!).
But this is also exciting, because projects that would have taken years or never gotten off the ground now have a chance to at least exist in a rough state that a team can polish and maintain.
So I guess I'm along for the terrifyingly awesome ride.
If you want to be as well, give Stripe Projects a try:
brew install stripe/stripe-cli/stripe && stripe plugin install projects
then visualize your terrifyingly awesome creation with:
npx stripe-projects-visualizer visualize
Let's see what you come up with!
Top comments (12)
Interesting project. I'm curious about the security concerns you mentioned with rapid development. How do you balance the speed of prototyping with making sure the visualizer doesn't expose sensitive data? For design mocks, I've been using some resources from prachub.com. Their banks align well with what comes up in system design interviews, which helps in knowing what to expect. This might be useful if you're looking to visualize more complex systems in the future.
I think the scariest security concern is devs using agents to build production apps without thinking through threat models, which should be part of an initial design.
This is a great callout though - I'm going to update the system prompt to make sure it doesn't expose any PII or keys!
The progression from Stackery to Infrastructure Composer to agent-driven architecture generation is a good case study of how tooling evolves. The interesting part is that each generation didn't replace the previous one — it wrapped it. IaC is still underneath, the agent just removes the manual translation layer. The real test is whether these agents can handle drift detection and reconciliation, not just the initial generation.
Generating accurate architecture diagrams from IaC used to be an absolute nightmare. The fact that the tooling has evolved from requiring months of proprietary engine development to something you can spin up so rapidly is a testament to how far infrastructure tooling has come since 2018. It makes documenting cloud architecture so much less painful!
the diagram round-trip is still useful but the speed claim breaks for anyone inheriting a production account with years of manual drift. greenfield only.
Can you expand on that?
Currently Projects does work best greenfield, but IMO visualizing architectures is most useful for brownfield for someone not familiar with an app, which includes a greenfield app someone used an agent to build.
If the
/.projects.state.jsonis the source of truth as well as the codebase at a point in time, there is no chance for manual drift. For traditional IaC, thetemplate.yamlshould also be the source of truth unless devs are making manual edits in the console, which should never happen in production apps with good CI/CD practices.the source-of-truth claim holds as long as the state file gets updated consistently - agents are better at this than humans are. brownfield drift is basically months of PRs that skipped the state file. the diagram round-trip is still useful, you're just visualizing the last time someone cared.
For Projects, the state file should never be updated manually, it's only updated by the CLI when a provider is added or removed. A PR would include this update.
fair point for greenfield - the brownfield case is the messier one where state files exist but weren't CLI-managed from the start, and reconciling that without touching the file manually is the harder problem
The Stackery comparison is provocative in a good way, but I'd push back gently on one part of it. The visualizer-in-an-afternoon framing measures prototype-to-working-demo time, which has genuinely collapsed thanks to agent tooling. What hasn't collapsed nearly as much is the long tail: the security review, the edge cases (what happens when
.projects/state.jsonreferences a deprovisioned service?), the production observability, the docs that don't go stale.Stackery's "years of engineering" included all of that scaffolding, not just the rendering. So the more honest claim might be: agents collapse the novel logic time by 100x, while everything-else time collapses maybe 2-3x. That's still a huge productivity gain — just not as cinematic.
The Vercel + OpenRouter example is the strongest part of the post though. The fact that an agent can determine infra needs from requirements alone, without a human writing the provisioning DSL, is the actual structural shift. Curious whether you've seen the agent ever pick wrong infrastructure (e.g. choosing a database type that fits the prototype but not the workload), and how you'd surface that as a warning rather than a silent decision.
Oh for sure, I'm definitely not trying to discount the value of a team (especially a UX team attached to engineering) when it comes to building a full-featured app rather than my little library, but what blew my mind was that I could build something in an afternoon that previously would have taken several people weeks of trial and error and screaming at ELK.
Absolutely agree with your last point! Projects is only a month or so old, so we're definitely still gathering feedback. I'm going to be using it to build a much more complex project in the very near future, so that will be part of my benchmarking as well. My hypothesis is that the more thorough your initial plan and requirements, the better the agent will be at choosing the right infra - i.e. saying from the start "I plan to scale this app to support thousands of concurrent users" rather than "I need a database for my app".
Love the Stackery origin story — infrastructure visualization has come a long way since 2018. We're seeing the same acceleration with Hermes agents generating infrastructure diagrams directly from natural language requests.
The "years to hours" framing is spot on for AI-augmented infra work. Curious — did the AI integration change how your team approaches the initial design phase, or is it more about speeding up the existing workflow?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.