A case study from building a part of the Surfaces experience at Aampe

There is a lot of writing about AI changing design. Most of it is abstract. This is a record of specific work: tickets, specs, shipped code, blocked states, and QA passes — done alongside an AI coding agent named Patches while I was lead product designer at Aampe.

In one month, Patches closed 99 Linear issues across our product. I filed around 60 of those issues, wrote the specs, ran the QA, and signed off. I also built the tool that made it all possible: a Chrome extension that let design and CS file structured tickets directly from the browser, with screenshots and context pre-filled.

---

What is Patches?

Patches is Aampe's internal AI coding agent. It clears the backlog of small frontend issues that never quite made it to the top of the priority list. It works through Linear and GitLab, so everything happens in tools the team already uses.

When a ticket is labelled correctly, Patches picks it up, asks clarifying questions if needed, plans the implementation, opens a draft merge request, deploys to staging, and asks the ticket creator to QA it. The engineer comes in at the end to review code that already works.

---

The Chrome extension

Before Patches could work well, someone had to make it easy to give it good problems. The old process: notice something broken, open Linear, reconstruct context from memory, file a ticket. Most small issues went nowhere.

I built a Chrome extension to close that gap. You spot a problem, hit the extension, get a structured ticket form pre-filled with the current URL, a screenshot, and the element context. Output quality is almost entirely a function of input quality.

---

Two large Surfaces tickets

Of the 99+ issues Patches worked through, two redesigned the entire Surfaces entry experience. Both came out of a single review session after I filed from the extension.

Replacing the vertical stepper

Surface creation in Composer used a vertical stepper that created excessive height and contradicted every other multi-step pattern. I filed it with problem statement, screenshot, desired outcome, and a note pointing to the horizontal component in the design system.

Patches picked it up within hours, then hit a Blocked state when spacing and connector-width issues needed a design decision. I made the call; work resumed. What shipped was the horizontal stepper with correct spacing and several QA-caught fixes.

The surface details view

Clicking any row in the Surfaces list took you straight into edit mode. The fix was a read-only details view as default, with an explicit Edit button to enter modification mode.

The initial build came back in three days. QA flagged two gaps; Patches implemented them. A brand-new view shipped over 25 sessions for about $17 because the spec was tight enough that very little iteration was wasted.

---

What I learned

The intake is the design work. The Chrome extension was product design applied to the system itself — not a side project.

Blocked is useful. An agent stopping to ask beats silent assumption. The block is the signal that a human decision is needed.

QA is where you find out what your spec actually said. In this model, QA surfaces which edge cases you left implicit — gaps are diagnostic, not blame.

By halfway through the month, the first reply to any Slack thread raising a frontend issue had changed from “I'll file a ticket for engineering” to “Can Patches take this?”