Product and brand are one thing. The interface, the identity, and the voice are all the same experience, so I design them as one system, from the first sketch to launch and scale. Browse the work by what it is, and you'll see the same thinking in each.

Nate Amarose, designer and AI builder

The job is unblocking

In late 2024, Marc Andreessen went on Chris Williamson's Modern Wisdom podcast and described how Elon Musk runs his companies. Musk, he said, "shows up every week at each of his companies, identifies the biggest problem the company's having that week and he fixes it." Then he does it again the next week, and the week after that. Across a year, that's 52 of the biggest problems solved at each company.

The part that stuck with me was how he does it. When Musk finds the bottleneck, Andreessen said, he isn't asking a VP to ask a director to ask a manager to get a report written. He "personally finds the engineer who actually has the knowledge about the thing, and then he sits in the room with that engineer and fixes the problem with them."

Walter Isaacson's biography has a name for the floor version of this. At Fremont, every station on the line had a green or red light, and Musk would walk the floor to the trouble spots. His team called it "walk to the red."

Whatever you think of Musk (I'm an admirer), the bigger idea is about leadership in general. Besides being the lead engineer and designer, his most important job may be unblocking. Delegate almost everything, then put your own attention on the one thing holding everyone else back.

That's the closest description I've found of how I work with AI agents now.

Agents are fast. They stall on human things.

I run a small team of agents for my design and product work: a builder that writes and ships code, a QA agent that acts as a release gate, research and copy agents, and a hub that routes work between them. They work faster than any team I've managed, and they rarely get tired of a hard problem.

But they get stuck in predictable places. Usually it isn't a lack of intelligence. They hit something only a person can resolve: a login, a judgment call, a decision with no right answer, a requirement nobody wrote down. An agent that's stuck doesn't always say so, either. It keeps working, politely, on the wrong thing.

So my job has three parts.

Ask big. I give agents whole outcomes instead of small tasks. Small asks get small results, and they keep me stuck as the bottleneck on every step.

Design the loop. I set up work so progress builds on itself. The builder ships to a QA gate, and nothing goes live until the gate passes. Failed checks send the work back with notes, and the builder tries again. A critic agent reviews copy before I ever see it. When something breaks, the fix gets written back into shared memory or a reusable skill, so the next run starts smarter. Over time it stops looking like a list and starts looking like a graph: specialists around a hub, handing work to each other, checking each other, and getting better each round.

Walk to the red. Then I go to wherever the work is stuck and clear it.

What unblocking actually looks like

Most of the job falls into a handful of types:

  1. Make the call. Two good options, no clear winner. Agents can lay out tradeoffs all day, but a tie needs a person to break it. Isaacson quotes Musk on the Model 3 ramp: "At least twenty percent are going to be wrong, and we're going to alter them later. But if I don't make decisions, we die." A decision that's slightly wrong is usually better than one that never gets made.
  2. Do the manual step. Sign in, approve the 2FA prompt, confirm a payment, click the button only a human account can click. These steps take thirty seconds, and if I'm not around they can hold up the work for hours.
  3. Grant access, deliberately. I decide which agent gets which keys, with the smallest scope that does the job.
  4. Hold the quality bar. "Works" and "good" aren't the same thing. Taste is still the most human input in the loop, and I'm the one who says, "Not yet. Tighter."
  5. Delete the requirement. Musk's algorithm starts with "question every requirement" and then "delete any part or process you can." Agents are great at satisfying requirements, including ones that shouldn't exist. Often the fastest fix is to say, "We don't need that."
  6. Supply the missing context. Who the customer really is, what we tried last year, why the brand never uses that color. Agents only know what's written down, so a lot of unblocking is writing down what's in my head.
  7. Settle conflicting instructions. When the copy agent and the brand guide disagree, or two agents are working from different specs, someone has to say which one wins and then fix the spec.
  8. Reframe the problem. When an agent loops on the same failure three times, the answer is rarely a fourth try. I step back and change the question.
  9. Bring in a real person. Some blockers live outside the system entirely: a stakeholder's sign-off, a vendor's answer, a teammate's opinion. The agents can draft the note, but I'm the one who sends it.
  10. Turn the failure into a rule. Every unblock is a lesson. I write it into a guardrail, a checklist, or a skill so the agents can handle that problem without me next time.

That last one is the real goal. A good unblock is one you never have to do twice.

This is design leadership, again

None of this feels new to me. It's the same job I've done leading design teams, just at a different speed.

A good design lead is a player-coach. You stay close enough to the work to know where it's stuck, and skilled enough to sit down and fix it alongside the team. You set the quality bar and defend it. You turn vague direction into something clear enough to build. And you protect the team from the slow, report-on-a-report work that Andreessen describes Musk throwing out the window.

Agents raise the stakes of all of this. A team of people might hit a blocker a few times a day. A graph of agents running in loops can hit one every few minutes. If I'm slow to respond, everything waits. If I'm vague, they confidently build the wrong thing. If I'm clear and quick, the whole system speeds up.

The close

I used to think the hard part of working with AI would be prompting: finding the right words to get the right output. It turns out the harder and more valuable work is what leaders have always done. Ask for something ambitious. Build a system that improves itself. Then find the red light and go fix it.

Delegate almost everything. Own the bottleneck.

Flowchart. Ask big, an outcome rather than a task, points to the hub agent. The hub routes to Builder, Research, and Copy, and Copy points to Critic. Builder points to a QA release gate: fail plus notes returns to Builder, and pass goes to Ship. Dashed blocked paths run from Builder, Research, and Critic to Nate, who walks to the red. Nate sends a decision, a manual step, access, taste, a deleted requirement, or context back to the hub, and writes shared memory and skills. The QA gate also sends learnings into that memory, which returns to the hub.

See more workGet in touch

© Nate Amarose 2026