There’s a lot of writing about AI changing design. Most of it is abstract and hype. This is a record of specific work. Tickets, specs, shipped code, blocked states, QA passes. I did this alongside an AI coding agent named Patches while I was the lead product designer at Aampe.com.
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.
But I also built the tool that made it all possible: a Chrome extension that let the design and CS teams file structured tickets directly from the browser, with screenshots and context, without rebuilding everything from scratch in Linear.
The interesting part isn’t just using the agent. It’s building the system around it.
What is Patches?
Patches is Aampe’s internal AI coding agent. It was built to clear 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.
A button a few pixels off. Copy that reads awkwardly. An empty state that doesn’t explain itself. Each one is five minutes of actual work. But the overhead of picking up any ticket at all used to eat an hour of engineering time before a line of code was written. Patches changed who could move a ticket forward.
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. The gap between noticing and filing was wide enough that 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. You add the problem statement and desired outcome. You submit. Patches gets a ticket it can act on.
The quality of Patches’ output is almost entirely a function of the quality of the input. Filing from the browser, with a screenshot already attached and the URL captured, meant tickets arrived with the context that changed what Patches could do. Ed, who built Patches, put it simply: the extension made it easy for the whole team to file tickets “complete with screenshots and other context.” I recorded a short walkthrough showing how it works in practice:
The range of tickets
Not every ticket was a big redesign. Most weren’t. A lot of what Patches handled was genuinely tiny: a nav label that said “Home” when it should say “Dashboard”, a typeface that needed changing, a UUID showing up in a breadcrumb where a name should be. Each one took less than a dollar and one or two sessions. Filed, picked up, done.
Then there were medium tickets: a Wrap Text toggle across all the dense tables in Composer, a system-wide redesign of success state modals, a full illustration audit across the product. More sessions, more QA rounds, but still well under $12. And then the large ones under $20.
Two large tickets that show the full picture
Of the 99+ issues Patches worked through, two were the most substantial. Both filed on the same day, after a single session reviewing the Surfaces flow in staging.
Replacing the vertical stepper
Surface creation in Composer is a 5-step wizard. The stepper showing those steps was laid out vertically, down the left side of the screen. It created excessive height and contradicted every other multi-step pattern in the product. I filed it the moment I saw it: problem statement, screenshot of the broken state, desired outcome, implementation note pointing to the horizontal component in the design system.
The existing interface needed to be fixed:
Patches picked it up within hours. Then it hit a Blocked state.
Not because the problem wasn’t clear. When Patches actually flipped the orientation, spacing and connector-width issues surfaced that needed a design decision. Which tokens to apply. How the step indicator should size against the content area. Patches flagged it rather than guessing. I made the call, work resumed.
That’s the thing I keep coming back to. The agent stopping and asking, instead of assuming. The state history: Needs triage, In Progress, Blocked, Ready, In Progress, In Review, QA, Done. Not a clean shot. A real back-and-forth, compressed into 10 days. What shipped was the horizontal stepper with correct spacing, step indicators aligned with the main content, the right button placement, and several QA-caught fixes. Eight screenshots document the progression in the linear thread.
The surface details view
The problem statement: Clicking any row in the Surfaces list took you straight into edit mode. No read state, no overview, no confirmation of intent. A misclick on a live surface could put you in a modification flow without meaning to.
The fix was a new interaction pattern: a read-only details view as the default when you click a surface row, with an explicit Edit button to enter modification mode. I wrote the spec with a mockup of the tabbed details screen, a problem statement, and acceptance criteria specific enough that Patches could build without asking anything first.
The initial build came back in 3 days. QA flagged two gaps: a missing Status field label and a Template tab that needed to be added. Both fed back as notes, Patches implemented them, and we marked it done. Ed later called this out specifically in a blog post. A brand-new view for the Surfaces feature, multiple tabs, built over 25 sessions at a total cost of about $17.
A new product view, QA’d and shipped, for $17. The economics work because the spec was tight enough that very little iteration was wasted.
What these two tickets show together
These two changes together redesigned the entire Surfaces entry experience: how you create a surface, and how you read one. They weren’t planned as a pair. They came out of a single review session. The Chrome extension made that possible. The gap between “I see a problem” and “Patches is working on it” was minutes.
The stepper ticket also shows what a healthy block looks like. The agent hitting a wall isn’t failure. It’s the signal that a design decision needs a human. Patches surfaced it explicitly. I made the call. Work resumed.
The broader Surfaces work
These tickets sit inside a larger arc of work on Surfaces as a product feature.
Surfaces is Aampe’s system for delivering personalised, structured content to any placement in a customer’s app. Recommendation carousels, offer cards, banners. Unlike push or email, Surfaces serve a JSON response to a screen position via API. The customer’s app does the rendering. As a designer, that means there’s no canonical visual output. Only the system that enables one.
This is live product, used by current customers. The work happened in the existing experience while the team was simultaneously building a new experience (NX). That’s the context worth holding: these weren’t greenfield experiments. Every spec, every ticket, every QA pass was on something real people were actively using.
The Aampe Surface Creator Figma Plugin (April 2025) was the first tool that let designers and Customers import a Surface into Figma and see actual content combinations. Before this, you could configure a Surface in Composer but had no visual way to verify what would render.
The Surface Template JSON Builder (Feb 2026) is a self-serve tool where a PM or engineer can define a surface template, preview the JSON contract in real time, and publish a live mock API endpoint for testing before any production backend work exists. It shipped as a part of apps.aampe - internal App Store for Customers and CSMs.
I also wrote a follow-on proposal after identifying that teams were waiting 24 hours between meaningful tests because iteration was coupled to the live scheduling workflow, which is yet to implemented.
And Surfaces in Relay, Aampe’s next-generation message creation interface. I specced Surfaces as a first-class creation flow alongside push and email, with a rotating JSON preview as a v0 for the unsolvable “what does a Surface look like” problem. On hold, but the design decision is documented and ready.
What I’ve learned
The intake is the design work. The Chrome extension wasn’t a side project. It was product design applied to the system itself. I prototyped it with Claude Code, which meant I could move from idea to working extension without waiting on engineering. The agent didn’t change. What changed was the quality and consistency of what it received.
Blocked is useful. The most useful thing Patches did on the stepper ticket was stop when it hit a decision it couldn’t make. The alternative is silent assumption, which is much harder to catch.
QA is where you find out what your spec actually said. I used to think of QA as checking someone else’s work. In this model, it’s where you find out which edge cases you didn’t anticipate and which design decisions you left implicit. The gaps are diagnostic.
By halfway through the month, the first reply to any Slack thread raising a frontend issue had changed. It stopped being “I’ll file a ticket for engineering” and became “Can Patches take this?” That shift changes what you bother to notice. And what you bother to say out loud.
For more on how Patches works from the engineering side, Ed wrote about it here: Sweating the small stuff with Patches.