I spent a couple of hours in Zapier once trying to build an agent. What I ended up with was an automation that sprouted another branch every time I touched it, and eventually I closed the tab and walked away. I told myself the technology wasn’t there yet.

The technology was fine. I quit at the wrong moment. I treated the first bad answer as a verdict instead of a starting position, and I have watched a lot of smart people do the same thing since.

Here is what I have come to believe about that moment. The gap between people who get real leverage out of AI and people who stay stuck in Pilot Purgatory is not prompt skill. It is what they do in the ninety seconds after the model hands them something that almost works.

Why the first answer is almost always the wrong one to keep

Think about how you actually use these tools on a Tuesday afternoon. You have a backlog, three approvals waiting, and a deliverable due. You ask for a caption set, a summary, a shot list. Something comes back. It is 80% right, so you fix the 20% yourself and move on, because fixing it yourself takes four minutes and arguing feels like it will take twenty.

Multiply that by a quarter, and you can see the problem. You have paid for hundreds of outputs, and you own nothing. Next month the same task arrives, and you start from zero again, because every conversation ended the moment the asset was good enough to ship.

That is renting. And renting is fine for one-off work, but it is a terrible way to build capability into a team that is already underwater.

What Jeff Sieh did differently

Jeff came on The AI Social Playbook to walk through the animated open he built for The Makers Table, the craft show he hosts with Katie Fawkes. Most of that conversation is about the animation pipeline, and it is worth your time. But the part I keep thinking about is a small side project he mentions near the end.

He wanted an old-school karaoke bouncing ball over the lyrics of his theme song. He is a video producer with decades of experience, and he did not know how to build one. So he asked Claude.

The first answer was a browser-based tool that ingested his caption file and gave him some sliders. It was, in his words, wonky. This is the exact fork in the road where I closed my Zapier tab. Jeff did something else. He told it plainly: that’s not working, Claude.

What came back was not another attempt at the same thing. Claude offered to build him a rig inside After Effects instead, wrote the connector, and put squash and stretch into the animation. Jeff already knows After Effects. He now animates that bouncing ball with a couple of keystrokes, and it saved him hours of keyframing.

Read that sequence again, because the important part is easy to miss. He asked for a video. He walked away with a tool. The tool works on every episode he will ever produce.

The mechanics, step by step

Jeff credits Allie K. Miller for the posture behind this. Her advice, as he relays it, is to argue with your AI and ask it why it cannot do the thing you want. That is the whole idea, and there is more structure underneath it than the phrasing suggests. Here is how to run it.

  1. Pick a job you can describe but cannot execute. Not a task you already do faster by hand. Something you have wanted for a while and have never built, because the skill gap was too wide. Jeff had wanted that bouncing ball for months.
  2. Bring the real artifact, not a description of it. Jeff handed over an actual SRT caption file exported from Descript. That file carries the exact timing of every lyric, which means the model is solving against real constraints instead of a paraphrase. A spreadsheet, a transcript, a brand guide, a sample export – the file is the spec.
  3. Reject the first answer in plain language. Four words did the work here. Not a re-prompt, not a longer prompt, not a rewritten system message. A flat statement that the thing does not work, in the same tone you would use with a contractor.
  4. Ask why, and name your environment. This is the step people skip. Jeff’s second answer landed in After Effects because the conversation knew what he could actually operate. If you tell the model you live in Excel, or Canva, or your CRM, you will get a proposal that lands somewhere you can maintain it.
  5. Keep the tooling, discard the output. When the answer arrives, ask yourself which part of it you will still be using in six months. Save that. Jeff’s rendered animation was a one-time asset. The After Effects rig is permanent.

Jeff also describes this same posture inside the animation work itself, and it is the clearest description of AI art direction I have heard. He tells Cowork what is not landing, it proposes alternatives, and some of those alternatives are better than his original plan. Having Katie welcome the viewer in the opening sequence was Claude’s suggestion, not Jeff’s. It stayed in the final cut.

Where this breaks down

I want to be honest about the limits, because this approach gets oversold and then people feel lied to.

You have to be able to evaluate what comes back. Jeff could accept the After Effects rig because he knows After Effects well enough to tell a good rig from a bad one. If Claude had offered him a rig in Blender, he would have been stuck holding something he could not judge. Arguing productively requires enough domain knowledge to recognize when the second answer is genuinely better and not just different.

It also depends on a model that can build and run things rather than only describe them. Jeff works through Cowork, the Claude desktop app, and talks to it with Wispr Flow instead of typing. That combination matters less than the capability underneath it: the model has to be able to produce a working artifact you can open.

And sometimes the first answer is wrong because your spec was wrong. My Zapier project failed partly because I never decided what the agent was supposed to own. No amount of arguing fixes an unclear ask. If you push back twice and the answers get worse instead of narrower, stop and rewrite the request.

One more note on cost, since Jeff is candid about it in the episode. The animation side of his project ran roughly $100 in rendering credits. The bouncing ball rig cost him nothing but the back and forth. Tool-building conversations are usually the cheapest thing you will do with AI all week, which is a strange thing to realize when you have been paying per render.

What this means for the next tool you try

The lasting lesson has almost nothing to do with animation.

Every model you will use for the rest of your career is going to hand you a first answer that is close. That is what these systems do. When you accept it and patch the rest by hand, you have bought one deliverable. When you push back and ask what it would take to do the job properly in the environment you already work in, you sometimes walk away with a piece of infrastructure.

Nobody thinks less of Da Vinci because he had a workshop full of assistants prepping canvases and grinding pigments. He was the architect of the final piece. What made the workshop valuable was not any single painting that came out of it – it was that the workshop existed at all and kept producing.

So the question I would put in front of your team this week is not which AI tool to adopt next. It is simpler than that. Look at the last five things AI made for you and ask which of them you can use again. If the answer is none of them, you have been renting, and the fix is not a better prompt. The fix is refusing to accept the first answer.

Jeff’s full walkthrough of the animation pipeline, including the Suno workflow, the character reference sheets, and the storyboard document Claude produced, is in the episode. Go watch the screen shares. The bouncing ball is worth the trip on its own.