200PRsandCounting:ADesigner’sRetrospective

If you spend any time on X, you've seen the two dominant modes of AI discourse. There's the doomer camp — AI is coming for your job, creativity is dead, nothing matters anymore. And there's the hype camp — "I just built a full-stack app in 45 minutes! Ship or die!" Both are exhausting. And neither reflects what it actually feels like to adopt AI tools inside a real product team.

Karri Saarinen , the designer/founder of Linear , put it well recently: "Group 1: A solo builder with agents, their preferred stack, and a pile of markdown files, working on their own apps, is the right way to build and everyone else ngmi Group 2: A much larger group building with agents at scale inside companies, where coordination, reliability, shared systems, and organizational complexity create a very different set of problems which most people don't hear about....All ideas are good but much of the AI narrative still very confidently comes from group 1 too little from group 2 (with few notable exceptions)."

Karri's ask was simple: more intellectual honesty. Present workflows as they are, and the value they actually provide, without hyperbole.

This is our attempt to do that. At Dune, one of our values is Get To The Heart Of It — communicate directly, tackle difficult topics head on. So that's what we're going to do here.

About a year ago, designers at Dune started experimenting with AI coding tools. Today, we regularly push 5–15 PRs per week. A year ago, most of us had never opened a terminal.

This is the story of how that happened — in phases — what we got wrong, and what we're still figuring out.

Until recently, our design workflow looked like most modern product teams: design in Figma, review internally, align with PMs, hand off to engineering, support implementation. It worked. But it created distance between ideas and execution that we'd stopped questioning.

Our first real experiment was low-stakes and almost accidental. We created a Slack channel called #project-vibe-code where designers could tag Cursor directly — fix this bug, update this color token, change this copy. Small issues got resolved quickly. It worked surprisingly well for one-shot fixes.

But it had limits. We were touching the product without truly understanding it. It was like being able to send a text message in a foreign language using a translation app — functional, but you haven't learned anything.

The real shift came when our engineering team, led by our Director of Engineering Garrett Hughes, helped designers set up local development environments. That meant the terminal, Git, GitHub, local repos, the Cursor CLI. For designers, this was genuinely disorienting. Branches. File systems. Merge conflicts. Everything about the form factor felt foreign — like asking a salesperson to open Figma and create a vector illustration from scratch.

But one thing was immediately clear: we didn't have to wait anymore. And that changed the psychology of the entire team. We have a value at Dune called Sense of Urgency — a bias for action, because action produces information we can iterate on. Suddenly, designers could act on that value in a way we never could before.

From small fixes to big features.

Once designers could run the product locally, we started shipping code. The numbers surprised us — designers now push 5–15 PRs per week, which is historically an engineering metric. And the pace is ramping up aggressively.

But here's what matters more than the numbers: our core job hasn't changed. Designers still focus on product decisions, UX, visual craft, and taste — what we call Create Magic at Dune: taking pride in your work and going the extra mile to make something exceptional. The difference is that we now implement many of those decisions ourselves. The distance between idea, prototype, and production has collapsed.

What made this sustainable — rather than a novelty that burned out in two weeks — was discovering that AI isn't just a code-writing tool. It's a learning engine.

Early on, our pull requests were rough. We often didn't fully understand the feedback engineers gave us in reviews. Before AI, the loop was painful: ask a developer, wait, get a clarification, attempt a fix, ask again. Now it looks like: ask AI to explain the PR comment, understand the possible fixes, learn which approach a senior engineer would choose, and fix it immediately.

We regularly use AI as a private tutor for software engineering. "Explain this error." "What are the tradeoffs between these two approaches?" "Why did the linter flag this?" The learning velocity is remarkable — and it compounds. Concepts that were opaque a few months ago are now intuitive.

This extends well beyond code. MCPs (Model Context Protocols) have dramatically reduced the barrier to entry for complex tasks that used to require specialized knowledge. Designers on our team now write SQL queries directly on Dune, spin up dashboards in Amplitude, triage issues in Linear, and communicate updates through Slack — all through AI-assisted workflows. Things that would have previously required filing a ticket and waiting for an analyst or switching between five different tools. The walls between "who's allowed to do what" are coming down across the board, not just in code.

We're currently identifying low-risk PRs — copy changes, color tokens, spacing adjustments, minor UI tweaks — that can ship with designer review only, without requiring an engineering review cycle. The goal is twofold: unburden developers from reviewing changes that designers are best positioned to evaluate anyway, and increase overall shipping velocity. It's early, but it's a sign of where this is heading — toward real autonomy, not just participation.

If we stopped here, this would be one of those articles we're tired of reading. So let's talk about what's actually hard.

AI dramatically reduces the cost of writing code. But review is still human. More PRs from designers means more review load for engineers. Our designer-reviewed PR experiment is one response to this, but we haven't fully solved it yet — it's an ongoing conversation about how to scale review without sacrificing quality.

The AI tooling landscape evolves weekly. New IDEs, new agents, new workflows. It's easy to spend half a day in a configuration rabbit hole instead of doing actual work. Some teams embrace this churn — Ramp, for example, operates with the explicit expectation that their internal tools have a shelf life of weeks, not months. We've taken a more conservative approach: switch tools only when the improvement is obvious and immediate. For designers still building comfort with the fundamentals, stability matters more than novelty.

This is the one nobody talks about, and it's the most interesting tension. As designers started writing code, some developers began treating us — understandably — like junior engineers. In some sense, that's a recognition that we're learning — and we appreciate the patience our engineering team has shown. But it can also erase what designers uniquely bring to the table.

Karri Saarinen flagged a version of this concern too — that when everyone is building with the same AI tools, you risk "the same patterns, the same flows, the same ideas repeated across different tools and teams." The antidote, I think, is remembering that designers and developers start from fundamentally different places. Designers start with a blank slate and dedicate themselves to what to build — incorporating customer signals, exercising visual craft, making taste-driven decisions. Developers start with a solution and figure out the best way to how to build it — architecture, performance, scalability. AI lets both groups cross into each other's territory, but the core expertise still matters. Maybe more than ever.

Developers typically treat code as execution. Designers increasingly use code for exploration. Some of our PRs are prototypes; some are features. This created friction until we started labeling PRs explicitly: Feat, Fix, or Prototype, and keeping experiments in draft PRs. A small process change that made a big difference.

Teams evolve through roughly four stages as AI enters their workflow.

The first stage is AI as assistant — it helps individuals write copy, generate SQL, summarize docs, but the workflow stays the same.

The second is AI in the workflow — it starts assisting implementation directly, fixing bugs, generating code snippets, updating components. This is where our Slack experiment started.

The third stage is AI as a learning engine — and this is the one that changed everything for us. When AI becomes a teacher, not just a tool, people start understanding unfamiliar domains. They interpret PR feedback. They debug problems independently. Learning velocity increases dramatically, and the gap between "I can't do this" and "I can do this" shrinks from months to weeks.

The fourth stage — and we're only beginning to enter it — is the builder organization. Role boundaries start to blur. Designers ship code. Developers shape product ideas. PMs prototype features. Teams move from role-based execution to idea-driven building.

We're not the only ones seeing this. Geoff Charles at Ramp recently shared that non-engineers now account for 12% of all human-initiated PRs on their production codebase — thousands per month. Ramp arrived at a similar proficiency framework independently: they call it L0 through L3, from ChatGPT dabbler to systems builder. The convergence is telling. Across companies, the progression looks the same: use AI, then build with AI, then learn through AI, then reshape how your team works.

The most interesting shift isn't designers learning to code. It's the expansion of who gets to build. AI is flattening traditional role boundaries — not by making everyone the same, but by giving people access to capabilities that used to require years of specialized training. What matters more now is taste, judgment, curiosity, and creative confidence. The people who combine those traits with their existing expertise will define the next generation of product teams.

Here's what stands out.

The biggest barrier was psychological, not technical. Running the product locally changes everything — it transforms your relationship to the thing you're designing. AI is an extraordinary teacher, and learning velocity compounds faster than you'd expect. Geoff Charles at Ramp put it simply: the world's best teacher is staring right in front of you — it's AI. Our experience confirms this. No workshop or onboarding doc moved the needle the way a designer's first successful PR did. Designers often implement UI details with a level of care that surprises everyone, including themselves. Strong engineers remain absolutely essential — this isn't a replacement story. And taste matters more in this new world, not less.

We're not sharing this because we've figured it out. We're sharing it because — and this matters to us — Our Integrity Is Priceless. The honest, messy, middle-of-the-journey stories are exactly what's missing from the AI conversation right now. Too much doomerism. Too much hype. Not enough "here's what it actually looks like on a Tuesday afternoon when a designer is trying to resolve a merge conflict for the first time."

This shift is happening across the industry. And if we're being honest, it's as scary as it is exciting. At Dune we talk about Embracing The Rollercoaster — discovering opportunities to learn and grow where others see crises. A roller coaster ride is uncomfortable, but it will also make you smile and laugh if you embrace it. That's exactly what this past year has felt like.

Humans have never been the strongest or the fastest. What has always set us apart is that we learn, we adapt, and we build tools — and then we learn to build with those tools.

Let's enter this next phase with confidence, integrity, humility, curiosity, and optimism. And let's remember that none of us are figuring this out alone.

We're all on this ride together.

None of this happens without the people willing to try something new and the people willing to support them through it.

Garrett Hughes — for encouraging early experimentation and creating the conditions where designers felt safe to fail. This started with your belief that it was possible.

Our design team — Alanna Fischer, Rob Nichols, and Gerard Cadiach — for the courage to open a terminal, push through the discomfort, and ship real code. You proved that the barrier was never ability.

Our engineering team — Cláudia R., Norbert Durcansky, Arne Mæhlum, Ivan Pusic, Wilhelm van Der Walt, Richard K., Charis Rafailidis — for the patience, the PR reviews, the Slack explanations, the pair debugging sessions, and for never making us feel like we were in the way. This worked because you made room for it.

One Team, One Dream.

Austin — Designer at Dune