Building cloud infrastructure discovery tool

I'm a designer who works in the code, and AI is genuinely how I work here: it does the reading and the grunt work so I can spend my time on design judgment. Engineers owned the backend; I owned the design, and I ran the same loop on every problem.

1. 01

   Understand

   AI reads the real backend and data and runs fast competitor analysis, so I design against what the product can actually do and how it fits with Wallarm's other products, instead of guessing.

2. 02

   Explore

   I quickly assemble several directions as working prototypes in code, not flat mockups, so I can get them in front of users and test as early as possible.

3. 03

   Spec

   I write the decision down: the options, the choice, the risks. The spec is the design artifact.

4. 04

   Build

   I take the chosen design into the live product myself, driving coding agents across parallel git worktrees, and because our design system is built to be machine-readable, I ship my own updates and new concepts to production.

5. 05

   Validate

   I put the prototype in front of potential users, running on real seeded data and real topology rather than a happy-path mock, and iterate on their feedback.

6. 06

   Ship

   The design merges into the live product as merge requests.

My setup: Claude Code with custom skills and subagents, our LLM-adapted design system, all in the product's real React stack.

On this project, that meant: I designed against real data, which is how I caught that the crown-jewel attack paths weren't buildable yet and rescoped before we wasted weeks. I compared more concept directions than a static mockup workflow could. And I shipped my own UI changes and type fixes as merge requests.

The design system all of this ran on was being rebuilt to be machine-readable at the same time, a parallel track with its own case study →

The centerpiece was an interactive topology graph. It looked impressive on a demo account and collapsed into an unreadable hairball on a real one, where a critical internet-exposed asset looked the same as a benign one. It answered "what do I have," when what a security team needs to know is where it is exposed and what to fix first.

It was also read-only, with only structural data collected, so risk had to be inferred from configuration, not content.

Eight interviews with security engineers said the same thing: they don't open the tool to admire a map, they open it to find the one exposed path that matters. That split the work in two: a redesign to ship now, and an attack-path concept to pitch.

The feedback came in with very little time left to act on it. The job was to pick the few things that mattered most to users and were realistic to build in what was left, and what they asked for lined up with the directions we had already been leaning toward. I ran a couple of sessions with the engineering team: every idea went up on the board, grouped by direction, then ranked by impact against effort. What came out was a short list we could actually ship.

Three moves turned the inventory map into a triage view. Each one was a spec.

The redesign shipped: a clustered, severity-first graph, five security views that speak one severity language, and a guided onboarding flow, all built on the new design system as it migrated. We showed it at AWS Summit.

From the launch feedback, I explored where the product goes next: an attack-path concept. Instead of showing everything, it surfaces the paths an attacker could actually walk, ranked by what matters. I built it as a clickable prototype, with AI.

• —The layout stopped contradicting the product: the old simulation spaced assets evenly regardless of severity, so severity now decides where things sit.
• —Risk legible at a glance: the product now hands you an answer instead of raw data.
• —A strategic reframe delivered to product as a costed, phased proposal.
• —Designing against real backend data rather than happy-path mocks, so testing showed real behaviour instead of a clickable illusion.
• —AI compressed the delivery: within the six-week build, the concept went from first working version to user-validated and shown at AWS Summit in about three weeks, with a base ready for the next round of improvements.

This is an internal B2B tool, so the evidence is the work itself: a graph that survives real topology, and a shift in what the product is for.

What I'm proudest of isn't the prettiest screen. It's the shift from inventory to risk, a layout that keeps the dangerous assets in view, and the speed. AI let me take a working concept to user-tested and release-ready quickly, and still lay the groundwork for where the product goes next.