Back

The shift

Foundry began when AI started changing what was possible for product teams. Developers were already experimenting with vibe-coding tools and new models, while designers were still mostly working inside the canvas. It became clear that the distance between a polished design and the product people actually used was shrinking.

With AI in the loop, designers could start working closer to the code, tune the final pixels, and test ideas where they mattered most: in the real interface.

The shift from describing the pixels to working inside the product itself.

It started with DQA

The first steps were small. We built plugins for design quality assurance that scanned a website against its Figma design and surfaced visual mismatches. If a page fell below the quality threshold, the team could see exactly where the drift was and what needed attention.

That changed the conversation. Rather than handing developers a long list of fixes, designers could use those signals with AI, make the corrections themselves, push a branch, and review the result on staging.

Foundry workspace. A product view with current work, release context, and prompt activity in one place.

From QA to working in code

As Figma MCP and the models improved, so did the output. Designers began adding the details that usually lost out to product priorities: subtle motion, hover states, and the small moments that make an interface feel considered. We cloned repositories, worked in branches, and started raising our own PRs.

Prototypes were no longer just HTML sketches for someone else to rebuild. They became working starting points. Still, moving that work into a legacy React codebase was difficult. Variables differed, context was missing, and a prototype built in isolation could create more work than it saved.

A high-fidelity Foundry walkthrough, from product context to a working branch.

Why Foundry

I kept seeing the same friction across designers, product owners, and engineers: cloning repositories was intimidating, creating the right branch took setup, and every prototype needed to relearn the product it was meant to improve.

Foundry was my answer. I pitched it as a sandbox for a complete product clone, already carrying the codebase context, reusable skills, and the conventions of the existing system. A team could explore a feature without touching the real product until it was ready.

The platform as a shared capability layer rather than another isolated prototyping tool.

Inside the sandbox

Foundry removes the setup work so a team can focus on the feature. The backend prepares the workspace, while the product context stays available throughout the build.

  1. Open the product. The relevant repository and branch context are already prepared.
  2. Build the feature. Use AI with the existing codebase, conventions, and reusable skills in view.
  3. Mock what is missing. Create APIs when the real service is not ready, so the experience can still be tested at high fidelity.
  4. Bring design context in. Send selected Figma elements through MCP when a visual refinement needs a closer read.
Connected product context.
Visual exploration in the branch.

Built to ship safely

The sandbox lets teams iterate without affecting the live product or the shared staging environment. When a direction is strong, the work is reviewed by engineering, checked against the codebase, and taken through the normal QA process before it reaches production.

Foundry is not about bypassing engineers. It is about giving design and product a safer, more fluent way to build alongside them, then handing over work that is already grounded in the system it needs to join.

Building with the product context in view.
A reviewable interface before merge.

When code came back

I studied computer science, but working in design gradually pulled me away from writing code every day. When AI entered the picture, that part of my brain switched back on. I began making prototypes, trying WebGL experiments, and rebuilding the frontend instincts I had left unused.

My engineering background helped me understand what the models were doing, but the interesting part was not the code alone. It was seeing how design judgment and machine speed could work together.

The learning space in motion, from the course surface to the tools around it.

Learning in public

I kept experimenting and posting the work on X. People began asking how I made the prototypes, how the WebGL pieces worked, which tools I used, and what my process looked like from idea to build.

The questions turned into DMs, calls, and small sessions where I helped other designers recreate the workflow. I had already built plugins for design QA and had enough frontend context to explain what was happening beyond the prompt box.

Then 350 people raised their hands

Shashi and I started by running workshops. Designers and product people joined from Microsoft, Google, Delhivery, Newton School, Amber, Smallcase, Pocket FM, and other teams. When we opened a wider registration form, more than 350 people said they were interested.

That was the signal. Designers were not short on curiosity. They were short on a structured way to keep up with a field that seemed to change every week.

An early public invitation to learn the workflow together.
Turning a fast-moving practice into something people could hold, discuss, and learn together.

From a workshop to a learning space

The gap was not another list of tools. Designers needed a path through models, tokens, frontend concepts, APIs, MCPs, and the messy loops that turn an attractive prototype into something that actually ships.

Building the course also became a challenge for me. I wanted to explain the fundamentals clearly enough that someone without an engineering background could go from zero to one. Teaching forced me to study more carefully, test every claim, and understand the basics by heart.

Follow the spark Refine with taste Turn skill into value
The course made tool choice legible without turning the curriculum into a list of product names.

My first rodeo in front of a camera

I had never taught a full course on camera before. The early recordings took many attempts. I was learning how to explain a concept, watch my pacing, keep the example useful, and still sound like myself.

Workshops gave me confidence, and repetition did the rest. By the end of the course, speaking to the camera no longer felt like a performance. It felt like another design problem: understand the person on the other side, remove friction, and make the next step obvious.

REC · take 37
A real lesson recording, from the first rodeo to a repeatable teaching practice.

Six modules, built with Shashi

Shashi and I shaped the material into six connected modules. Each one closes the distance between understanding the technology and using it with intent.

  1. Understand the shift. Build a practical mental model of AI, models, tokens, context, frontend, backend, and APIs.
  2. Choose the right tools. Learn where prototyping tools help, where they stop, and how MCP, CLI, and reusable skills fit together.
  3. Build for the web. Move from a Figma frame to a working interface and learn the iteration loop around it.
  4. Ship a mobile app. Build with React Native, connect real services, debug the rough edges, and put the result on a phone.
  5. Ship a native Mac app. Work with SwiftUI, interactions, sound, and packaging to make something people can install.
  6. Work in production. Use Git, branches, PRs, and team context so the work can move beyond a personal experiment.
Visit designengineer.proSee the curriculum, outcomes, and current course
The course dashboard, designed as a learning space rather than a folder of recordings.

The course needed a life after lesson six

We did not want the learning to stop when someone finished the modules. So we started building a job dashboard for designers ready to move into design engineering, along with a living newsletter and resource feed that can keep pace with the field.

The jobs view collects relevant roles in one place. The daily feed brings together AI design engineering articles, designers worth following, useful posts from their work, and free resources people can try immediately.

designengineer.pro / desk updating
Design EngineerRemote · Product teamNew
Product Designer, AIBengaluru · Hybrid2d
Design Systems EngineerGlobal · Remote4d
Open the evolving dashboard
A living map of opportunities for designers moving closer to code.

What building it changed

The project began with me helping a few people understand my workflow. It became a learning space for designers who want to keep pace with AI without giving up the taste, care, and product judgment that made them designers in the first place.

It also changed me. I became a clearer teacher, a more confident speaker, and a more deliberate builder. The best proof of learning was no longer a prototype I could post. It was watching someone else understand the idea and ship something of their own.

Native utility experiments

I built Tofu to learn how a real Mac app comes together.

The experiment began with two things I understood personally. I wanted to build my first native Mac app, and I had started spending far too many uninterrupted hours in front of a screen.

The MacBook notch felt like useful space hiding in plain sight. Tofu turned it into a small assistant that could help me look after myself, present with more confidence, and reach common controls without leaving the work in front of me.

The goal was never to make another dashboard. It was to keep a few high-value utilities exactly where my eyes already were, present when needed and quiet the rest of the time.

Wellbeing reminders
Custom hydration, stretch, and screen-break nudges that appear gently inside the notch.
Invisible teleprompter
A script placed close to the camera for steadier eye contact during calls, lessons, and recordings.
Quick context
Upcoming calendar events and music controls without interrupting the task already in progress.
A tiny companion
An animated character that reacts to reminders and gives the utility a little warmth and personality.
Tofu in motion: wellbeing reminders, the teleprompter, calendar context, music controls, and the companion living in the MacBook notch.

Start with the shape of the problem

Before Foundry came into the picture, my process began away from the model. I would first ask whether I was solving an optimization problem or a zero-to-one problem. The answer changed what kind of exploration the work needed.

I would think through a few directions, sketch them on paper, and build my own point of view before prompting anything. That gave me something concrete to test rather than asking a model to invent the direction for me.

The problem starts with a point of view. The model joins after there is something concrete to challenge.

Use the model as a critic

Once the problem and my early thinking were clear, I would give the same problem statement to a model. I compared its directions with mine, looked for assumptions I had missed, and kept the parts that made the solution stronger.

The model became a second perspective in the room. It helped me challenge the work, but the product judgment still came from understanding the people, the constraints, and what the team was actually trying to change.

Move the decision into code

I then used Claude Code or Codex to build the prototype. I made multiple versions, reviewed them with the product team, and used those conversations to decide which direction deserved a more polished build.

Once leadership gave the direction a positive signal, I refined the interaction and prepared the code for engineering review. A frontend engineer could read through it, flag anything that needed to change, and decide whether it was ready to merge. By February and March, I was raising PRs again instead of stopping at a handoff.

Two plugins that removed repeat work

DQA plugin

The DQA plugin reads a working website and compares it with the source design through Figma MCP. It checks where the implementation has drifted, surfaces visual mismatches, and gives designers and developers a clearer signal of whether the build quality is ready or still needs attention.

Instead of handing engineering a long subjective list, the team gets a shared quality check with specific differences to review and fix.

Pocket FM file-maintenance plugin

The second plugin solved a quieter but constant source of friction. When someone starts a new Pocket FM design file, running the plugin creates the expected structure directly in the file, including the thumbnail, notes, component areas, and the other foundations the team uses.

It turns a repeated setup ritual into one action, so the file begins organised and the designer can spend time on the actual problem.

One clear choice at the beginning of a new file.
The notes, context, and component structure the plugin helps standardise.

The project