---
title: "A Senior Engineer Demonstrates a Spec-Driven AI Development Flow"
author: "Live — Spec-Driven Development with AI (Sam Breed, Augment Intent)"
description: "Hello everyone. I’m AJ, technical content lead at Augment, and we’re starting a series where we bring on real senior and staff engineers to show how they’re actually coding with AI. It’s a chance to..."
source: "https://adhenawer.net/posts/original/senior-engineer-demonstrates-spec-driven-ai-development-flow.html"
lang: en
---

TL;DR · key points

1. Hello everyone.
 2. Today I’m joined by Sam Breed.

## INTRODUCTION — A SENIOR ENGINEER SHOWS HIS REAL WORKFLOW [0:01](https://www.youtube.com/live/Ednpn1mjKiY?t=1)

Hello everyone. I’m AJ, technical content lead at Augment, and we’re starting a series where we bring on real senior and staff engineers to show how they’re actually coding with AI. It’s a chance to see how they work and ask them questions directly.

Today I’m joined by Sam Breed. Sam was previously a senior staff engineer at Credit Karma and is now a partner at Sutter Hill Ventures. He’s one of the lead engineers building the Intent app, and he was part of Augment back when it was just Eigor, one of our founders.

Sam: “Happy to be here. We’re going to have some fun and build some websites.”

## THE TASK — TURNING A FIGMA COMP INTO A REAL WEBSITE [1:24](https://www.youtube.com/live/Ednpn1mjKiY?t=84)

This is a real-world task I did in the last week or so. We’re taking a design a designer made, fully comped out in Figma. It’s about ten pages, with a design system, custom colors, gradients, reusable components, and full content for seven or eight pages of a website.

Using the Figma MCP integration inside Intent, we’re going to pull content directly into Intent’s context and drive the build from there.

Honestly, if I were doing this by hand — writing all the markup, getting it responsive, pulling all the assets out, handling the looping videos and carousels — I could probably do it in a day or two if I’m fast and already know the stack. It’s a lot more if you’re learning a framework while building. With Intent, I was able to rip through it in about 45 minutes and get to roughly 95% fidelity. The designer now has Intent too and is iterating the last 5% himself — and this is a person who had never used Git before.

## SETTING UP THE FIGMA MCP INTEGRATION [2:32](https://www.youtube.com/live/Ednpn1mjKiY?t=152)

The Figma MCP is already connected. If you’re curious how it works, go into workspace setup and turn on custom MCP servers. I have two configured: one for Vercel and one for Figma.

Figma makes the URL really hard to find — you have to search their docs for it. It’s `localhost:3845/mcp`. You set it up as a custom MCP. A remote Figma MCP with Augment compatibility is coming very soon — this month.

To bring context in, I go into Figma, right-click on frames, and copy links to the selections. That’s the current way to pipe artboards or layers from Figma into the MCP integration. In the future, hopefully you’ll just say what you want. For now there’s a bit of manual shoveling back and forth.

## OPENING MOVES — SEEDING THE PROJECT YOURSELF [4:01](https://www.youtube.com/live/Ednpn1mjKiY?t=241)

For things like this, one technique I really like is to do the opening moves myself. I have an idea of how I want to build this — Astro, Tailwind, a few other choices — and I tend to run those init commands first.

Two reasons. One, the init commands are good generators; they give you the latest versions, properly patched. Model training data is often months old, so for frameworks where you want the latest, you don’t want choices buried in weights from six months ago. Two, by seeding the project with what you want as a developer, you get your opinions into the codebase instead of relying on whatever default comes spitting out of the weights.

Once the project has a little starter content and the Astro server runs, Intent has already been pulling context from Figma in the background. It found the design system layer, pulled a bunch of custom colors, noticed it’s Tailwind v4 — so it’s not going to write a Tailwind v3 config — and wrote a small spec to add the custom colors to the Tailwind config.

## ON AGENT SAFETY AND SANDBOXING [6:42](https://www.youtube.com/live/Ednpn1mjKiY?t=402)

Someone asked how I prevent an agent from silently editing files outside the workspace.

Honestly, I’ve never seen that happen. For context: I’ve been using AI for code since about 2021, joining Sutter in 2020 to prototype around GPT-3. My defaults are sensible. I use Auggie for everything. Auggie runs scoped to the directory. It’s exceptionally well-prompted and I’m running frontier models — I’m not using Haiku to do this, and I’m not running local inference through something like OpenCode, where I might be more cautious.

As a practical matter, in several years of writing code with AI in basically every conceivable way, I’ve never had sandboxing problems. I’m team YOLO. The “dangerously skip permissions” thing should just be on by default. In Auggie there’s no safety net — you’re playing with live rounds.

## ISOLATED WORKSPACES VS. WORKING DIRECTLY ON A BRANCH [12:50](https://www.youtube.com/live/Ednpn1mjKiY?t=770)

Someone asked if the isolated workspaces feature is optional. Yes — on the home screen, when you click your main branch, there’s a checkbox at the bottom of the menu that says “work directly on the branch.” It also works for other branches in the repository. It says “no work tree” when you’re doing this.

Arguably there should be a bigger, more prominent setting to turn work tree mode off entirely, but for now it’s in that submenu. It’s actually quite useful when you tee something up, get it good, and then want to make minor edits directly.

## STORING SPECS IN GIT [13:30](https://www.youtube.com/live/Ednpn1mjKiY?t=810)

Can Intent store the spec in Git? Yes. The spec files end up on disk — click the “open in” menu to open them in Finder or your editor of choice. They live in the home/intent directory. If you want the spec to be a long-term, durable object, you’d need to move the files into your repo. The sub-items are separate files with the subspecs.

You could potentially symlink to have it live in both places — I’d want to test that first. You could type it in the box and see if it goes.

## THE FIGMA COMP — WHAT THE DESIGNER HANDED OVER [16:19](https://www.youtube.com/live/Ednpn1mjKiY?t=979)

Let me show the Figma comp I’m pulling from. It’s in developer mode — shift+D in Figma to flip back and forth. Developer mode mutes a bunch of features so you don’t accidentally change stuff or rotate a thing when you’re trying to grab its corner. Classic foibles developers run into.

The first frame has spacing conventions, custom colors, custom gradients, specific type annotations with a licensed font, some reusable components common across pages, and a grid system. Plus a lot of actual content — this is a landing page with real copy, looping videos, a carousel, mobile views, all of it.

## ITERATING ON PLANS AND ASSUMPTIONS [18:38](https://www.youtube.com/live/Ednpn1mjKiY?t=1118)

How do you iterate on the spec and artifacts?

Personally, I find Intent produces an assumptions section, and that’s what always needs the most attention. Sometimes the assumptions won’t align with what I intended, so that’s where I iterate most. The plans themselves are usually pretty good.

There are two ways to adjust. You can re-engage the coordinator — “hey, there are some things wrong with the plan, change X, Y, Z” — or you can make the edits yourself directly. I tend to favor editing directly, because the coordinator writes prompts that are a little more fully specified than I’d be willing to write.

You fall into one of two camps: you either read the plans, or you hit go and see what they do. I’m more of a “let’s go” person. Sometimes I spot something glaringly wrong in the plan and ask the coordinator to change it.

## WHERE INTENT SHINES — PR-SIZED TASKS [19:37](https://www.youtube.com/live/Ednpn1mjKiY?t=1177)

Intent really shines on tasks that are roughly the size of a PR — a single pull request to a repository. You can do ambitious PRs that change hundreds of files and tens of thousands of lines, but those are much harder to evaluate and need a lot more planning.

My workflow reflects this: I get to a decent stopping point, merge, and start a new workspace. Because adding more to an existing plan tends to invalidate 40% of what was already there.

If you’ve been working with large language models for a long time, you develop these instincts about where context is going to be most useful. The less accurate context you throw in, the better. Even with a million-token context window — a million tokens is a lot of text. It’s easy to say “a million,” but if you printed those tokens on paper, it’s a stack of phone books two meters tall. Do you need all that?

Models keep getting better, but keeping things on track and being fast matters. These models attend to everything in their context. A smaller, more relevant context gives you faster responses and less opportunity for the model to wander off the path.

## MODEL CHOICE — OPUS, CODEX, AND THE TRIBAL DEBATES [21:50](https://www.youtube.com/live/Ednpn1mjKiY?t=1310)

Do I always use Opus?

In technology you always get these dichotomies — Vim vs. Emacs, tabs vs. spaces, and now Opus vs. Codex, Claude Code vs. the OpenAI models. I think they’re very equally capable tools. The subtleties come in with how you prompt and use them.

Personally, I’ve used Claude as my go-to for about two years. The work Claude did with the 3.5 Sonnet release to make tool calling good enough for a semi-autonomous agent to drive a task through dozens of tool calls — that was the first time I saw that happen in a model. It felt like the sign that coding was going from what it used to be to something new. It took two years for that to bear out, and tool calling is the way.

That said, I try everything. When new models come out it’s really useful to try them. GPT-5.4 is genuinely good. I’ve been playing with it this week as we pre-flight it for Intent. If you’ve been using OpenAI models and like them, more good stuff is coming. Competition is only going to drive this forward faster.

## MIXING FAST AND SMART MODELS — A FADING PATTERN [28:24](https://www.youtube.com/live/Ednpn1mjKiY?t=1704)

People used to ask a lot about switching between Haiku, Sonnet, and Opus or between GPT tiers.

In earlier runs of this kind of app, before Opus 4.6 in December 2025 — a pretty memorable moment for a step change in quality — that mattering a lot. We’d all been using Auggie CLI in tmux with six split panes, writing specs. The workflow was: smart model writes the spec, fast model verifies, middle-of-the-road model with medium thinking does the implementation, and you loop. You could get a lot of juice out of it, but it was like tuning a carburetor — you had to listen to it and try a bunch of stuff.

When a better model generation comes along, a lot of those concerns evaporate. A model like GPT-5.4 or Opus 4.6 is just good at this stuff. They can go fast, they can go far, they can drive specs really well. Just staying in those models is the sweet spot now. Different strokes for different folks, though — you can get this done a lot of different ways.

## SPECIALISTS — PR SHEPHERD, UI DESIGNER, AND THE PROMPT ECOSYSTEM [32:41](https://www.youtube.com/live/Ednpn1mjKiY?t=1961)

On specialized agents: I’m team “don’t mess with it.” That’s part of why I use Intent — these things are built in and exceptionally well-prompted.

There are specialists I invoke directly. A favorite recently is PR Shepherd. Currently it works with Augment and Augment Code Review. When you have an open pull request with failing CI and review comments from humans or automation, you can launch this specialist in an Intent workspace. It long-polls against the comment thread and chases down a green PR like the Terminator hunting for John Connor. It leaves detailed comments rather than just pushing a commit and marking resolved.

This is an outgrowth of a skill Intent already has: when GitHub is wired up, you can ask the coordinator “hey, are there any comments on this PR? Can you address them?” and it writes to the spec and fires away. But PR Shepherd makes it a one-click specialist.

There’s also a UI Designer specialist that Amelia wrote — more on that later.

The fun thing about prompts, and why the skills ecosystem is exploding, is that the best prompt is the one you didn’t have to write yourself. Be a discerning user — spend enough time thinking about prompts, but don’t over-index. The difference between a pretty good prompt and a perfect prompt is limiting. More inference is probably the better way to reach better code than spending lots of time specifying the perfect prompt.

## HIDDEN FEATURES AND NAVIGATION [41:23](https://www.youtube.com/live/Ednpn1mjKiY?t=2483)

A few keyboard and UI features people often miss. All your VS Code muscle memory works: cmd+J to dismiss the terminal, cmd+B to dismiss the sidebar — especially when you want to look at a browser side by side.

There are views that show you a tile of all the agents that have launched in your chat — standard pane interactions. My favorite is the one that takes me back to the planning spec after I’ve been messing around. It gives a two-up view: here’s everything you’ve done, here’s the plan so far, here’s the coordinator.

The coordinator is the boss. It’s the best person to talk to.

## RUNNING THINGS IN PARALLEL — QUEUEING TASKS [42:50](https://www.youtube.com/live/Ednpn1mjKiY?t=2570)

Next up: breaking out the header and footer into reusable components, then building the rest of the pages, then a verification pass against Figma.

The magic of working in an agent orchestration workspace like Intent is that you can do a bunch of things in parallel — especially when they’re not writing over the same lines in the same file. I go back to Figma, grab a link from a comp, full-send. Then I queue up the next prompt. You can add tasks and let them fire in sequence.

## REVIEWING CODE — INFORMED READING VS. VALIDATION [45:05](https://www.youtube.com/live/Ednpn1mjKiY?t=2705)

Do you still review code? Yes — a lot.

The thing exploding right now with our ability to write more is that we’re writing much more code. I do a mix of reviewing inside Intent and occasionally opening an IDE, but a lot of my review work happens directly in Intent.

Code review comes in two flavors. The first is informed reading — literate reading of the code. That works if you can keep the project in your head, if the theory of the program is crisp in your mind. The second is validation and QA — do the things that need to run, do smoke tests pass, can you actually run the app?

For Intent itself, which we dog-food aggressively, every PR I pull down locally into a work tree, spin up the server, and drive the app around. We have automation for this, but the manual pass matters — you need to know what changed, what to look for, and actually exercise the feature.

For lighter web-dev tasks, it’s more vibes-based: content coming in, looks good, dev server already running, I run lint and formatting. Direct integration with npm or node scripts, Makefiles, and the like is coming soon, so you’ll get one-click affordances instead of coming into the terminal like a caveman.

## WORK TREES — SETUP SCRIPTS AND MENTAL MODEL [45:38](https://www.youtube.com/live/Ednpn1mjKiY?t=2738)

On setup scripts for work trees: when you spin up a fresh work tree, it doesn’t have node_modules or binaries installed. We have a bunch of pre-canned templates. On the home page, when you launch a project, there’s a button to choose the script. The default is to copy config files — if you have `.env` or other common culprits, you can copy them recursively. There are scripts that copy config and then run pnpm install, npm, yarn, pip, etc. You can write your own or generate them from the repo.

The mental model for work trees takes some getting used to. If you’ve been using Git for any length of time — I’ve been using it since 2008 and didn’t know work trees were a thing until last June — Git is a huge universe. Work trees feel weird at first.

Once you’re comfortable, the key insight is: if I’m in a work tree, I can’t check it out on main. To get it into main or see it on another branch, my options are to merge it. There is a force way, but I’ve never used it — you can end up with disconnected heads where branches don’t sync easily.

That’s why the terminal is a first-class entity in Intent, why work trees live in a discoverable location you can control, and why there are affordances at the top to open the tree in your common apps or copy the absolute path.

Work trees aren’t meant to be super long-lived in my mind. If they live for multiple days, weeks, or months, you’ll commonly need to merge main back into them from the terminal. I’m also in the squash-commit camp for merges into main — a bunch of ugly merge commits on a long-running feature branch is a sin that gets washed away when you ultimately squash in.

Cleanup: Intent has two modes. Archive is a soft deletion — the work tree stays on disk but doesn’t show in Intent. Delete removes the files. Either way, the branch remains in Git, so you’re free to check it out wherever.

## THE OLD WORKFLOW — THREE CHECKOUTS AND DIFFERENT VS CODE THEMES [49:29](https://www.youtube.com/live/Ednpn1mjKiY?t=2969)

Funny story: before I knew what work trees were, I was on a really busy project doing maybe 20 to 30 PRs a day, reviewing some and working on multiple features at the same time. I had three checkouts of the project, moving between them manually, using different VS Code themes so I’d know which one I was in — this one is main for reviewing PRs, that one is the feature branch.

It was a lot to keep in my head. That mode of working — Intent makes it ten times easier.

## CODE QUALITY — DUPLICATION, CIRCULAR DEPENDENCIES, AND VERIFICATION [49:32](https://www.youtube.com/live/Ednpn1mjKiY?t=2972)

Do I do anything special for code duplication, circular dependencies, or style violations?

Nothing beyond the normal quality metrics — linting, formatting, unit tests. I haven’t felt burned by circular dependencies. Duplication is real, though. That’s something you need to catch in code review.

Part of the reason Intent runs in a multi-phase process — plan, spec, delegate, verify — is so the verification pass catches things like this. But I’ve seen humans fail at this in equal measure: not looking carefully, adding a third or fourth copy of a date-formatting util that was already in the project.

One workflow that works well: create a workspace, tell it “go find duplicate code in this repo, look at utils, make sure things are abstracted, make sure things are reasonably DRY.” Most big codebases will have some duplication, and you can usually come back with something worth cleaning up.

## SENTRY TO PR — THE ERROR-TO-FIX LOOP [53:30](https://www.youtube.com/live/Ednpn1mjKiY?t=3210)

Sentry is super cool. Every website, application, mobile app, or game throws more errors in production than you ever see in dev mode, no matter how rigorously you test. I’ve got a lot of history with Sentry — was an early customer in 2014 and did open-source work with them in 2014 and 2015, back when they were four or five people. They’re a huge company now, and I think they’re best-in-class for error tracing.

In Intent, you connect GitHub via standard OAuth in the Connections tab. Sentry currently needs you to mint an API key — a smoother rail is on the roadmap. I also use the Sentry CLI, which is quite good.

When you click “Add Context,” Intent pulls context for your specific Sentry projects. My favorite example: if you run Intent out of the downloads directory, one error spews like a piece of radioactive uranium. It’s not actually anything, but Sentry catches a lot of it. For something like that I just say “hey, big dog, fix this error.”

If you talk to the models with the big-dog lingo, they’ll occasionally throw you a big shaka emoji when they’re done.

For this kind of thing I use rapid-fire mode — it creates a workspace in the background so I can walk away and keep hitting check as many times as I need.

## THE TEAM — COORDINATOR, IMPLEMENTER, VERIFIER, DEVELOPER [53:33](https://www.youtube.com/live/Ednpn1mjKiY?t=3213)

A high-level picture of the default team:

The coordinator is the boss. It’s the best way to use Intent — always start with a workspace where you create a coordinator and give it your high-level plan. The plan can be really high level. You can type out elaborate prompts, but you can also just say “hey, take a look at this thing” or “hey, fix this thing.” It’ll go out, write a spec, and you iterate.

The coordinator farms out to implementers, which are pretty generic. None of this is remote or secret — the prompts are in the application, you can edit them, you can change behavior, and you can reset to base. We tell you when you’ve modified them.

The verifier checks the work at the end of the multi-phase process.

The developer is essentially a combination of coordinator and implementer. It writes plans but also just goes and does them. No subprocess fan-out — a single-threaded agent that grinds away at a problem, writes plans, makes good documents, follows best practices. It’s meant to meet people where they are with a more traditional single-agent chat experience. Faster for certain tasks, or when you don’t want a bunch of subprocesses running.

Agents are jokingly stochastic parrots — they do things a little differently each time, with some smear in their distribution. You steer them through in-context learning and prompting. There’s no big hidden system prompt beyond “this is your intent, you’re an agent, this is the time, this is the model, this is the working directory,” and then the specialist prompts for coordinator and implementer.

## CUSTOM SPECIALISTS AND TRIGGERING THEM [56:28](https://www.youtube.com/live/Ednpn1mjKiY?t=3388)

Specialists are detected and dispatched automatically — the coordinator is prompted to dispatch implementers and verifiers. But you can manually trigger a specialist through prompting. Live example: “Hey bro, let’s use the UI Designer specialist to do a separate pass at this. Thanks, dog.”

You can also @-mention the persona directly — experimental feature I didn’t know about.

The UI Designer was one Amelia wrote. It does design token extraction, among other things. Agents are like people: they’re lazy. They’ll do inline Tailwind pixel values instead of using design tokens, especially if that pattern already exists in the codebase because some pesky human put it there. They repeat what they see. The UI Designer specialist forces the right abstractions.

If you have something very specific you need regularly, you can write your own custom specialists.

## PRO TIPS AND FINAL THOUGHTS [58:15](https://www.youtube.com/live/Ednpn1mjKiY?t=3495)

A few things I didn’t get to show:

Multiple windows. I often have four or five Intent windows open with different workspaces or work trees. Cmd+Shift+N to open a new window is tattooed into my brain. You can also do it from the menu via Cmd+N.

MCP integrations. The Figma MCP honestly shocked me the first time I used it — it’s always been the classic “shovel stuff from one app into another” problem. Setting up custom MCP servers with Auggie is super good.

Caution on MCP: don’t light it up like a Christmas tree with eleven servers on at once. MCP servers add tool definitions into the system prompt, so context management matters. That’s part of why the skills ecosystem has grown where it has — skills are more auto-discoverable. MCP used appropriately, in a targeted way, makes Intent multiplicatively better.

Intent is a “yes, and” product. It doesn’t obviate the IDE. I usually have an IDE open. If I’m writing a lot of code without AI, I’m still opening an IDE. I also use the CLI a lot — Auggie CLI is goated for quick questions about a codebase, direct control, and running anywhere. Intent adds all the extra machinery you need to go really far really fast in a short amount of time. Auggie CLI does a lot of the same things super fast, super targeted, and it works anywhere — I run it on servers, on my OpenCode setup, everywhere.

That’s the workflow. Thanks for tuning in.