Exploring safe autonomy for product teams

The handoff between design and engineering creates a strange bottleneck.

A designer can see a small change that needs making. A PM can identify a simple product improvement. But even a five-minute change can wait for a ticket, a sprint, an engineer and a release.

I wanted to explore whether AI could close that gap without removing engineering from the process.

Not another prototype that looks like the product.

A real change to the real codebase, with a developer still responsible for approving what ships.

The key question was not:

Can AI edit code?

It obviously can.

The question was:

Can AI make a change that already belongs to the product?

That requires more than giving a model access to a repository.

It needs to understand the actual design system, the actual component implementations and the way those components are used in the product.

So Proffer grounded its AI in the repository itself.

The codebase became the source of truth.

I designed the experience around three simple moments.

01 / Build

Describe the change in plain English and watch it appear in a live preview.

02 / Approve

When the change is ready, send it for developer approval.

No branch terminology. No commit terminology. No Git workflow exposed to the person making the change.

03 / Ship

The developer reviews the pull request and merges it.

The person who requested the change gets notified when it goes live.

The complexity stays underneath the experience.

The hardest part was working inside existing repositories.

A model can know React, shadcn/ui or Material UI and still produce something that doesn't belong in a particular product.

Proffer inspected the repository before making a change and generated a machine-readable description of its actual design system.

For each component it could capture things such as the real prop signature, an example from the repository and the underlying component library.

I tested the approach against 111 real design-system repositories.

One of the most useful findings was that compatibility cannot be predicted reliably from the technology stack alone.

Some repositories looked compatible on paper but were structurally hostile to automated changes.

The repository's own build became the final test.

If it builds, it can move forward. If it doesn't, Proffer stops.

The most important design decision was knowing what not to automate.

Before making a change, Proffer checked whether it touched protected surfaces such as authentication, routing, the application shell, server APIs, configuration or dependencies.

If it did, Proffer stopped and escalated to a human.

This became the central principle:

Good automation isn't the automation that does the most. It's the automation that knows its own edges.

I wanted the person to own intent without forcing them to understand the implementation.

For example, when adding a component, Proffer asks a simple question:

Where should it go?

Top. Bottom. Or let Proffer decide.

The person owns the what and where.

The AI owns the how.

That division of responsibility became more important as the system became more capable.

AI operations are not instant.

Some changes took 60–100 seconds of model work. At one point a failed stream left the interface looking as though it had crashed when it was actually still working.

I treated that as a product problem, not just an engineering problem.

The solution combined polling fallback, a live progress indicator and a rule that the interface could never leave the user in an unexplained dead state.

The principle was simple:

The difference between “broken” and “working” can be one honest status message.

One edit was taking around 60 seconds.

Instead of guessing, I instrumented the operation.

The data showed that 92% of the time was being spent on the model writing files across two passes. The first pass was rewriting an entire file only to discard it.

I changed the first pass to return only the path it needed.

60.4 seconds → 26.0 seconds

About 2.3× faster, at roughly half the cost.

Performance became part of the UX.

Proffer started as an experiment in removing the design-to-engineering handoff.

It became an exploration of safe autonomy.

The interesting problem wasn't getting AI to make changes. It was deciding:

What does the AI need to know?

What should it be allowed to touch?

When should it stop?

What must a human still decide?

Those questions became the product.

While I was building Proffer, Vercel shipped a very similar repository-aware design-to-code workflow. That effectively validated the product direction, but also meant there was little reason to continue developing Proffer as a standalone product.

I stopped building it.

The experiment had answered the question I was interested in.

I built Proffer solo with Claude Code as the implementation partner, directing the product, interaction model, architecture, testing and technical decisions while rapidly learning the engineering concepts required to make those decisions.

Three weeks took the idea from a blank repository to a working system tested against 111 real design-system repositories.

The value of the experiment wasn't the amount of code.

It was discovering where AI could safely take responsibility, and where the product needed to give control back to a human.