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 Portla...
For further actions, you may consider blocking this person and/or reporting abuse
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?