This post is my submission for DEV Education Track: Build Apps with Google AI Studio.
What I Built
I built ArchShield, an AI-powered architecture visualizer and security baseline assistant for developers.
The goal was to turn a natural-language software architecture description into a structured, interactive architecture diagram while also checking for basic security controls across the detected components.
The main prompt I used was:
Build a web application called ArchShield that analyzes a software architecture described in natural language. Identify components such as frontend, backend/API, database, cache, authentication, storage, external services, AI/LLM providers, and CDN/WAF. Visualize the architecture as an interactive multi-tier technical diagram with communication paths and network exposure. Add a basic security baseline review that distinguishes CONFIRMED, NOT MENTIONED, POTENTIAL CONCERN, and NOT APPLICABLE controls. Provide actionable security recommendations and integrate Imagen to generate a visual architectural blueprint.
I then iterated on the generated application to refine the architecture visualization, security analysis, error handling, and generated blueprint experience.
Demo
Live application: https://archshield.ai.studio
ArchShield can:
- Interpret architecture descriptions using Gemini
- Detect frontend, backend, databases, caches, authentication, storage, external services, AI/LLM providers, and edge components
- Render an interactive multi-tier architecture diagram
- Inspect individual architecture components
- Perform a basic security baseline review
- Generate actionable security recommendations
- Generate a visual architecture blueprint using Imagen
- Export architecture and security information as Markdown and JSON
My Experience
This track was a great demonstration of how quickly an AI-assisted development workflow can move from an idea to a working application.
What surprised me most was not the initial code generation, but the iterative workflow. Gemini could generate a functional application quickly, but getting the result to behave exactly as intended still required testing, inspecting failures, and refining the instructions.
I also ran into an XML parsing issue during the process. Instead of treating the generated application as finished once it worked in the preview, I used the error output to guide another iteration and corrected the generated implementation.
The project also made me think about the difference between generating an application and engineering one. A working UI is only part of the result. Clear boundaries, predictable behavior, useful security guidance, and honest handling of uncertainty matter just as much.
ArchShield deliberately treats NOT MENTIONED differently from POTENTIAL CONCERN: the absence of evidence is not automatically treated as evidence of a vulnerability.
Overall, the track gave me a practical look at Google AI Studio's Build workflow and how Gemini can act as an implementation partner while still requiring engineering judgment, testing, and iteration from the developer.
Top comments (2)
I took a look at ArchShield — really like the NOT MENTIONED vs POTENTIAL CONCERN distinction.
That maps very closely to how I’m thinking about agent reputation: a successful task or no visible failure isn’t the same as evidence that the underlying property was actually verified.
The “generated vs engineered” point also resonates a lot. I think this kind of explicit uncertainty + verification will be important for agent trust systems.
Thanks for taking the time to actually look at ArchShield and make that connection.
That's exactly why I wanted to keep NOT MENTIONED separate from POTENTIAL CONCERN. I didn't want the system to turn missing evidence into a vulnerability finding, because uncertainty and insecurity are not the same thing.
Your point about agent reputation is really interesting for the same reason. A successful outcome does not automatically prove that the underlying property was verified, just as the absence of evidence does not automatically prove that the property is broken.
I think there is a useful common principle here: trust should reflect the quality and strength of the evidence, not just the outcome.
Really appreciate you drawing that connection. I'll be following how you develop the reputation side of this, because I think there is a lot of overlap with the verification work I've been exploring. 🔐