AI-Native Design: Designing with AI, and for It

• Migration blockers cleared in days, not sprints. When a feature the old app had stood between a customer and the move, I scoped, designed, and handed it off fast enough that migrations weren't waiting on design. That helped cut the migration timeline by 87.5%, alongside AI-assisted development and DevOps changes. Some customers asked for more time to train their people or clean up their data.
• My own velocity jumped, and in June I took on a second team. I was the only designer at Thrive carrying two teams, and AI let me carry far more than one designer normally can. From January to October 2026 I worked on 52 projects, 37 of them large features, and handed off or shipped 40, well beyond the year before. The other 12 weren't dropped: about six were still in design or review when I left, and about six were paused, waiting on an approval, moved to another team, or cancelled.
• I pushed for code prototypes for more than six months before the team made the switch. I kept making the case, wrote up why the AI design tool kept inventing parts of our UI, and proved the alternative on a real project. Once we moved, handoff fidelity improved, and daily pulls from the real code caught bugs and regressions before release, so there were fewer patches and hotfixes.
• Handoffs turned into better conversations with dev. We review every handoff live before dev starts. With a clickable code prototype in the room, dev's questions got specific and direct, so gaps were fixed in the review instead of in the build.
• The client reports portal is ready for review. I designed it as an interactive draft with scoped AI suggestions and kept refining it while migration came first, so the team can pick it up whenever there's room.

For most of 2026 the roadmap was migration: moving customers onto the new platform. That left little room to design AI into the product, so the AI work that shaped my days was how I design: prototyping in code, triaging migration blockers in days, and leading the team toward a better way to hand off AI-built work. I also build and train with AI well outside my job.

• Apps I build for myself. I've built several apps with Claude and put them on my own phone with Apple's developer tools, despite never having worked with Swift before.
  • One app, Fronds, used Apple's built-in services, which aren't hooked up properly to Apple Intelligence, for early agent-style work before agents were widely available. I retired it once Claude and ChatGPT could handle what I'd designed it for.
  • Grab the Popcorn started from my own lists of movies that hit certain vibes. It syncs with a free API that updates streaming availability daily, and lets me mark which movies I own digitally or on disc. It is in App Store review now, to launch free.
  • With TestFlight, I can build an app for one person's need and put it on my family's phones without a public release.
• AI data trainer. I'm a contract AI data trainer for DataAnnotation.tech. I review other trainers' responses and have watched two years of what gets trained and tested. That shows me how these models actually behave, and it shapes how I design features that use them.

Clients already had a gated portal for their search, but it was just a long list of candidates in their stages, with no analysis or synthesis and barely a dashboard. Reports were either built by hand each week by some customers, or generated as a static PDF that could only show or hide fields. In August 2026 I drafted a replacement: point-in-time reports that are interactive and more in-depth for clients, easy for recruiters to create and polish, and customizable far beyond showing or hiding fields. The recruiter prepares each update on their own cadence, usually weekly, in one view, and previews exactly what the client will see in another.

Most teams reach for a chatbot when they add AI to something like this. I didn't because in a report the visualizations carry the meaning and the person editing usually wants to change one small thing, not talk to a bot about the whole page. So the AI does the part it's good at, reading the search, and a small set of controls does the rest:

• It reads the search and suggests what matters. Based on what changed in the project this week, since the last report, or overall, it suggests charts and headlines.
• Suggestions, not a blank page. For each section, it offers a few options: a chart or other visualization built from components already in the system, chosen only where there's enough data, or a text-only section when a chart isn't the right fit. Each has a live preview, and it can also suggest how to rearrange the report.
• Prompt small, edit directly. Any section can be changed by a short prompt, scoped to that section only. Or the recruiter can click in and change the words by hand, with no prompting at all.
• Privacy per section. The recruiter chooses what's private, what's shared, and how it displays.
• One component system, quick publish. Everything is built from the same reusable components, so a customized report for one client publishes in a click, with the metrics that client wants every week.
• On brand for each firm, set once. I connected the portal to the Admin Branding section I had already designed and shipped earlier in the year, so colors and fonts can be adjusted tenant-wide and every report matches the firm.

I made the call to keep the chatbot small. Scoped prompts, clickable suggestions, and plain editing are other kinds of AI interaction, and for this job they're more relevant than one big chat box. A recruiter fixing one headline shouldn't have to re-prompt the whole page.

Scoping also keeps the model working on a small amount of data at a time. That means fewer chances for it to hallucinate and fewer tokens used per change, which matters when you add LLM features to a B2B product; otherwise a customer's usage can become prohibitively expensive.

I also decided what a client may see. Funnel progress, time in stage, and momentum are in. Internal numbers, like how a firm sources or how its team spends time, stay out.

This work was paused when migration blockers took priority. I kept exploring it whenever I had room, so it would be ready for review whenever the team could pick it up again.

Migration blockers were features the old app had that the new one had to match before a customer could move. They arrived unpredictably, often mid-sprint. AI is how I kept design from being the wait. Before, speed was a tradeoff: a fast turnaround meant fewer options explored and thinner edge cases. With AI, I compared several directions, tested edge cases in a code prototype, and still handed off in days. Speed stopped being a limitation.

Speed also changed when design joins the conversation. When a PM was still writing the brief for a new discovery page for connected tools, I built a rough code prototype and sent it to her, and it was in front of the design team on the same day the brief was posted. Their feedback went straight into the prototype, so the conversation was about something people could click, not a page of requirements.

Using AI well is mostly decisions about tools and handoff. Three that mattered:

• Code prototypes over AI mockups. AI design tools produce something that looks right but hands off poorly. I wrote up why the AI design tool kept inventing parts of our UI: it retrieves fragments of the code instead of reading the whole app, so it fills the gaps. On a large project in September 2026, I branched off a code prototype instead of working in Figma, and the team pivoted from the AI design tool to code prototypes, with copies of the real repos available for review. Developers get the real components and states, not a picture of them. A complex app also needs its back end logic in the prototype, not just the front end, with anything sensitive stripped out first. And because the prototypes pull from the real repos at least once a day, we kept finding new bugs and regressions before release instead of after, which meant fewer patches and hotfixes.
• Figma still wins when flows are settled. On a compliance project in July, the AI tool kept inventing emails and pages even with the real design system (wrong sizes, half a logo). Once the flows were settled, Figma was faster and more accurate, so I moved there.
• Smaller tickets beat one giant one. While dev moved to an AI-assisted engineering process, there was a push to put everything for a feature into one giant ticket for the AI coding agents to interpret. With humans guiding the AI, that wasn't the most efficient way to work, even with code prototypes and repos. It felt counterintuitive, but breaking tickets down the traditional way, with story decomposition and mapping, was faster and more accurate on both the back end and the front end. It helped QA most, since they had been testing huge features on a tight migration turnaround. Pieces merged as they were finished, and I got several checkpoints to answer questions and give design QA instead of waiting for a giant feature to be done. The whole team shifted back, and that is what took dev velocity from 2x to 3x and beyond. Smaller chunks also fought token and component drift and sloppy code that was hard to update later.

My own prototyping works the same way. I plan with AI around the whole brief, with a detailed back and forth to clear up anything unclear and to look at edge cases. But the updates I make to a code prototype are chunked like dev tickets, so I get the output I want with less token waste and can explore several directions instead of taking the first thing the AI produces.