Dania / AI  ·  a field lab

How I build with AI.

I'm a builder at heart, so over the last few months I've been building prototypes with AI, each testing a principle for becoming a more effective product leader.

Principle 01

Collaborative design with AI needs visual tools.

Reading pages of generated text on a black screen wore me out fast. So I started building throwaway visual test tools in HTML that help me make better decisions, quickly.

Try it Drag on the canvas to paint. The eleven sliders are the live knobs, non-Newtonian dials included.

drag on the canvas to paint · tune the sliders →

The WebGL fluid sim I used to tune the paint. The app is on the Google Play Store.

I first needed a tool like this while designing Ultramarine, an ASMR paint-mixing game for oil and acrylic painters, built so the colors mix the way real paint does. It had to mix like paint, move like paint, and look beautiful enough for an audience of artists.

Paint is a non-Newtonian fluid. It moves with the resistance of a gel and mixes like pigment, not like light on a screen. So I built the game on a real fluid physics engine, and getting that to run on a phone meant writing the simulation from scratch.

A model like that lives or dies by its parameters. AI wrote the helper code for the harness. I dragged sliders until the paint read as real, down to that perfect ketchup-y ooze, then had it write the parameter set straight into the app. The tool above is the actual harness for the gel movement, not a mockup. I loved it, and I happily threw it away once the app launched.

Non-Newtonian Physics Engine · WebGL fluid sim · Human-in-the-loop eval · AI-generated helper code

Principle 02

Build systems that put guardrails around "good."

Ovo's design system and its eval pipeline. Every screen, mine or the model's, has a standard to clear before it ships. That lets me automate away some of the generated slop.

What you're looking at The design system components, the Journal screen I designed, and the "Your Day" screen that was generated. The design system and evals are why they still feel like one product instead of ten.

Ovo Figma design system — components, text styles, and tokens
Ovo Journal — free-form entries kept as written
Ovo — the day as a timeline of captured entries

The Ovo design system in Figma. The same eval and CI/CD pipeline shipped Ultramarine (shown above).

Ovo is a women's health app I designed in Figma. It lets women journal the messy way they actually do, then structures those entries into insights about how we work, exercise, eat, and relate to ourselves. The goal is insights that fit the routine a woman already has.

As a PM, it feels pretty great to get closer to building real software, so for this app I intentionally went HAM on test-driven development: a design system, standard components, and a CI/CD pipeline, so anything I generated with Claude could plug right in. I designed the Journal input screen and the main flows myself. Then I used the pipeline to generate a new onboarding flow and custom screens for logging food and fasting protocols.

Design systems · Evals / acceptance criteria · CI/CD + staging · Unstructured → structured

Principle 03

Great AI accelerates human judgment and expertise.

I built a tutor to find out whether people who already have expertise can learn faster with AI, instead of quietly outsourcing their thinking and losing their professional edge.

Try it This is a scripted simulation. The panel on the right is the mechanism, not decoration: the concept it's teaching, what the classifier decided, and whether the gate is open or armed.

Loop encounter → practice → test → reflect
I teach one concept at a time — Jobs To Be Done, today. Ask anything; I'll meet you where you are. Sometimes I'll teach, sometimes I'll ask you to predict before I reveal.

A scripted simulation of the engine's logic. The working version runs on the Claude API.

AI has removed the need for juniors to do the grunt work. That sounds like progress, but grunt work was how the apprenticeship model worked: you learned judgment by doing the small things badly first, next to someone who did them well. Take that away and the next generation of architects, engineers, and lawyers has no path to expertise, while the experts who already have it risk letting it go soft.

Most AI tutors make this worse. They optimize for answer fluency: you ask, it explains beautifully, and you move on feeling smarter than you are. I think of that as borrowed intelligence, fluent output that skips the thinking it was supposed to build. Learning sticks through experimentation and failure, so the fix is to put the human back in the driver's seat.

That is what the tutor does. It runs on the Claude API and is grounded in the National Research Council's How People Learn, Daniel Jackson's concept design, and Anthropic's own interpretability work. A classifier reads every turn and picks a mode: acquisition, practice, self-test, or reflect. Ask for a definition and it answers. Ask for a judgment call and it asks what you would do first, then holds its answer until you commit. The gate only arms in practice and self-test, which is the whole design: teaching mode shouldn't withhold, testing mode shouldn't hint. For the prototype I loaded it with widely taught PM concepts, but the knowledge base is swappable for any indexed body of knowledge.

Claude API · How People Learn (NRC) · Evolving Human Expertise · Anthropic's AI-fluency framework

Where this is going

AI makes options cheap, so the craft of product leadership moves closer to human judgment.

Better tools take some of the drudgery out of the work. The real gain comes when AI sharpens our ability to make better decisions, faster. Each prototype trained one part of that. The paint harness made the work visible so I could judge it. Ovo's design system and evals defined "good" before anything was generated. The tutor kept my judgment sharp instead of outsourcing it.

I'm taking that to the physical world next. I started my career on construction sites, coordinating foremen and 3D models on $300M+ projects, then ran AutoCAD for a decade. A building doesn't forgive a wrong answer the way a screen does, and that is the problem I want to work on.

If you're building AI for the built world, I'd like to hear about it. Tell me about your product, your .md files, and your bold ideas.

More experiments

The rest of the lab.

Empire Lights LED map — the four facades, each with its crown and base blocks and the LED index range that addresses them

Empire Lights

A LEGO Empire State Building wired to mirror the real building's lights. The digital twin maps tens of thousands of real lights onto 859 addressable LEDs.

My first step toward AI that has to drive a physical object.

Digital twins · Spatial mapping · Hardware–software systems

Forebuilder site — 'Your tools record what happened. Nothing records why.'

Forebuilder

Built to investable and deliberately held there. A real AEC product, a co-founder, a working site.

Knowing something is good and knowing it's the right moment are different calls.

Venture · AEC

forebuilder.com →
Moat Fight arena on mobile — Autodesk against Buildots and OpenSpace, scored round by round

Moat Fight + AI Strategy Team

A multi-round simulation of strategy in architecture, engineering, and construction (AEC), and a team of named agents I ran against it. The personas didn't help; that was the useful part.

One piece survived: the market scanner, which still feeds a live market board.

Multi-agent · Simulation · Negative result

Job search system architecture — state, lens, dossiers and insights markdown files and how they feed each other

Job Search System

Four markdown files with defined relationships: state, lens, dossiers, insights. An information architecture, not a to-do list.

Deliberately simple. The structure is the product; get that right and the rest gets easier.

Systems design · Context architecture

Read the piece →