The Loop I Keep Building

Every engineer has a shape they keep drawing. Mine is four boxes: a way to explore the data, a way to evaluate what it says, a way to ship the result, and a way to measure whether it helped. I’ve built some version of this at a startup I co-founded, at two big cloud companies, and now at Waymo. So instead of writing an intro post that walks through my résumé top to bottom, I figured I’d walk through the loop and let the jobs fall where they fall.

The loop #

None of the four stages is interesting on its own. The thing I actually care about is cycle time: how fast a question makes it all the way around. At Waymo the version of this that matters is research velocity, the gap between a researcher having a hypothesis and having a training run that tests it,

$$\Delta t \;=\; t_{\text{training run}} - t_{\text{hypothesis}},$$

and most of my job is making $\Delta t$ smaller. Everything below is that same obsession at different companies.

A platform team’s product isn’t the platform. It’s how fast the people on top of it can move.

Where I’ve run it #

Waymo #

I work on the exploration and evaluation layer of Waymo’s systems intelligence platform. It’s the tooling researchers use to find, slice, and validate every dataset the company has collected, and to trace where each one came from: semantic search, validations, visualizations, dataset lineage. The difference it makes is whether a researcher spends their morning thinking or digging.

Two pieces I’m proud of. The ETL pipelines produce training sets and validation reports in the same pass, so quality problems show up before they cost anyone a training run. And we built agents that scan our services for vulnerabilities and operational gaps, which cut that discovery work by about 90%. With MCP and agent skills wired into the platform, a researcher can ask for an artifact in plain language and the system assembles it.

After every launch we track adoption numbers to see what actually landed. That part is less fun to build and it changes what you build next, which is the point.

AWS #

On QuickSight Q Business I designed the permission framework that lets admins set custom user and role access, and shipped multi-tenancy on AWS Identity Center so customer data stays isolated across workloads. The thing people actually thanked me for was an API reporting service that saved each team a couple hours in weekly ops reviews. I also wrote CRUD APIs for 15+ QuickSight asset types. Tedious work, but it’s what made customer migrations possible, and nobody migrates to a product they can’t get their data into.

Bench AI #

At 20 I co-founded Bench AI^[1], an automated cloud for ML workloads, offered as IaaS and SaaS. As a founder you are every box in the diagram at once. I built the financial models, raised from institutional investors, designed the system end to end (data model, ORM, public API), and set up the CI/CD, Nginx, Docker, and AWS underneath it. Tuning the Spring Boot backend and shortening Lambda durations cut our compute costs by 30%. When the money is your own runway, you chase every percent.

VMware and before #

At VMware I wrote the UI and API automation that caught regressions across vRealize Automation’s CI/CD pipeline, and helped the product expand into Brazil and the UK without dropping availability. Before any of that, in school, five of us built Spacepark^[2]: portable hardware plus a mobile app that detected traffic flow in parking garages (object size, velocity, direction) and streamed it over wifi. First version of the loop I ever shipped.

The tools that keep showing up #

The stack changes, the shape doesn’t. Inventory:

languages:      [java, javascript, typescript, python, c++]
infrastructure: [aws, gcp, grpc, spanner, apache beam, docker,
                 nginx, spring, react, django, postgres]
ml:             [ml platform, distributed systems, mcp, rag,
                 post-training, agent skills, etl, data lineage]
degree:         cum laude, computer science, san jose state

What I care about now #

What I’m curious about right now: agents that do real operational work instead of demos, the data infrastructure underneath ML research, physical AI (systems that have to act in the world, not just describe it), and RL environments as products in their own right. That’s what this blog is for.

If any of that overlaps with what you’re building, say hi: email · github · linkedin. Or wander the portfolio, which has a LiDAR city hiding in it.