Context

"Loops are the new prompts" gets repeated constantly, but rarely explained. In this episode of The Growth Podcast, host Aakash Gupta gets Tyler Folkman (Chief AI Officer and Head of Product at JobNimbus, which just raised Utah's largest Series B at $303 million) to build product loops live and narrate the reasoning. It's a hands-on, PM-focused walkthrough: what actually separates a loop from a skill, how to design the validation "gate" that makes a loop useful, where deterministic hooks belong, and how the product, engineering, and design roles start merging into a single "builder." The value is in the practical detail, not the hype.

The Big Idea

A skill that runs the same way forever is just a skill. It becomes a loop only when it takes the log of what happened and rewrites itself to be better next time. The whole point of a loop is a self-improving flywheel, and the hardest, most important part of building one is designing a validation gate that can tell good output from bad, ideally deterministically.

Folkman's framing: prompting keeps you constantly in the loop, so you never feel the gains; an agent takes a task plus a way to verify itself and executes on its own, which is what actually scales you.

Key Insights

A loop is a skill that learns

The core distinction Folkman keeps returning to: a static skill can sit unchanged forever, which is fine, but it becomes a loop the moment you feed the session log back in and have the AI improve the skill itself. Any good loop ends with "let's review what I did, look at the log of the back and forth, and improve it." Miss that learning step and you just have a skill. For a PM, this reframes automation: the goal isn't a one-off prompt that works today, it's a system that gets better every time it runs.

The gate is the whole game

Every loop has the same shape: fetch its own inputs, do the work, pass through a gate that validates the work, write an artifact, then learn. Folkman is emphatic that the gate "is almost always the most important part," and that making it deterministic is critical. AI is genuinely good when it has clear boundaries and a clear definition of done, which is why loops work so well for code (tests either pass or fail) and get hard when the real gate is a human or a customer who you cannot lock in a room. The insight: your loop is only as good as the check that decides whether its output is acceptable.

Build a synthetic gate from research you already have

When the true gate is the customer, Folkman's team manufactures a fast proxy. They inject all their customer research (call recordings, interview transcripts) into a data warehouse, then have AI role-play the customer to inspect a prototype and catch low-hanging failures. It's not a high bar, but it lets them go from 100 ideas to the best 5 quickly, before spending scarce real-customer time. The lesson: mine the customer signal you already own to build a cheap first filter, so humans only see the ideas worth their time.

Generate many prototypes, then filter

Because AI can build a prototype almost instantly, the workflow inverts: instead of building the one thing you think is right and running the normal cycle, you spin up many divergent prototypes and filter down. JobNimbus generates three variants of every idea (minimal, full-featured, and creative), then narrows with the synthetic gate, then real customers, then A/B tests in production. Folkman cites Microsoft research that only about a third of shipped product changes deliver value, so getting far more cheap at-bats before committing is a direct hedge against that waste.

Deterministic hooks, not polite prompts

Hooks are code that fires at specific points in the agent's loop (session start, session close, before a tool runs), and they matter because they are deterministic where a prompt is not. Telling Claude "never share credentials" or "never delete everything" can fail because the model may just not follow it that turn; a hook that triggers on an rm -rf or a credential pattern will actually stop it. Folkman also uses a session-close "learning" hook to inspect the logs and build his own evals of where the agent struggled. The principle: put anything that must always happen into a deterministic hook, not into instructions the model can ignore.

Loop on quality or customers feel the bugs

Folkman's sharpest engineering point: customers don't experience your defect rate, they experience the number of defects you ship. If AI lets you ship twice as fast at the same 1% defect rate, customers hit twice as many bugs, which is why big companies are seeing worse uptime even though their quality didn't drop, they're just shipping more code. His prescription is to point loops at quality (standards checks, automated end-to-end tests, 100% unit-test coverage, which is now basically free) so the velocity gain doesn't degrade the customer experience.

Never ship AI slop up the chain

Passing unreviewed AI output to people above you is, in Folkman's words, "career reputation suicide" for a PM. It just offloads your thinking to people who are even busier, and everyone now recognizes unreviewed AI work on sight, so it no longer even looks impressive. Use AI to gather data, research competitors, and push your thinking, but if your answer in a meeting is "Claude said so" (outside of pure data-gathering), that's a failure. The judgment is the job; the AI is the research and code machine, not the decision-maker.

Docs for AI and docs for humans differ

Length used to signal effort, so people equate long documents with rigor, but a 10-to-20-page AI-written doc now just gets fed straight back into someone else's AI, defeating the purpose. Folkman splits it: some documentation should be AI-written for AI (rich context the model uses to answer questions and guide people, which no human is meant to read end to end), while documents actually meant for humans should be succinct and visual, one to three pages max. And if the author used AI rather than their own thinking to produce it, it's not reasonable to expect readers to spend their own energy consuming it.

Mental Models & Frameworks

The five-part product loop

The reusable anatomy of any loop Folkman builds:

• Fetch inputs: the agent gathers what it needs itself (you say "go research this," you don't hand it the research).
• Do the work: it produces a draft or artifact.
• Gate: validate the work, deterministically wherever possible; this is the hardest and most important step.
• Write the artifact: if it passes, push a PR (or equivalent) for a human to review and merge into the canonical version.
• Learn: feed the log back in so the skill improves itself, which is what turns a skill into a loop.

The four risks as a division of labor

Using Marty Cagan's four product risks to decide who "vibe-does" what: feasibility is where engineers are already strong, usability is mostly design's domain, and value plus viability (will people want it, can the business make money on it) is the PM's territory. The failure mode of an engineer "vibe-PMing" is precisely shipping something nobody wants or that isn't viable, so the framework tells each role where they can safely stretch and where they can't.

Two-way doors and blast radius

In the live "decide" skill demo, the AI reasons with Amazon's reversibility framing: is this a one-way or two-way door, how large is the blast radius, and how urgent is it. A decision that is hard to reverse, high blast radius, and low urgency is the textbook case for not deciding yet. Use it both as a personal decision aid and as the logic to bake into a decision-support skill.

Fix forward instead of reverting

Folkman version-controls skills with Git so he can always roll back, but in practice he rarely reverts. Instead he "fixes forward": rather than returning to an old version, he tweaks the current one to recover the specific thing he misses, since a new version is rarely uniformly worse than the old. The mental shift is to treat the latest version as the base and adjust it, not to treat rollback as the default recovery move.

Decision Principles

Principle: Write the first skill by hand

• When: authoring a new skill or loop.
• Why: Folkman cites research suggesting human-authored skills are often better than AI-authored ones, because you know more about what you actually want the skill to do. His e-bike analogy: people say they'll still pedal, but once the motor is running they stop; once you're on the fast, dopamine-rich AI loop it's very hard to inject your own thinking. Writing the first pass yourself forces that thinking in before the loop takes over.

Principle: Match the role stretch to the system

• When: deciding whether a PM should push code, or an engineer should do product work.
• Why: great systems (good CI/CD, decoupled front end and back end, strong automated testing) do really well with AI and make it safe for anyone to contribute; systems that relied on human slowness to stay safe do not. A PM pushing a front-end tweak behind a good test suite is fine; a PM changing the backend billing system is not. And agree it with the team first, or an unplanned PR becomes hours of unbudgeted review "shadow work" for engineers.

Principle: Always spin up divergent options

• When: starting any product decision or feature.
• Why: it used to cost real time and design effort to explore multiple directions, so teams skipped it; with AI it takes ten minutes to generate a few divergent ideas and some synthetic analysis. Given that roughly two-thirds of shipped changes don't move the business, the extra cheap at-bats are close to free insurance against building the wrong thing. Don't just accept what the AI says, but let it surface the angle you'd have missed.

Common Mistakes

Mistake: Accepting every AI improvement

When you close a loop and ask the AI how to improve the skill, it will always have suggestions, it never says "nothing to change." If you accept all of them, the skill becomes too opinionated, too full of context, too many tokens, and its value dilutes. Claude in particular tends to build "mega skills" that jam ten use cases into one, against even Anthropic's own best practices. The moment the AI proposes changes is exactly when to get off the treadmill and decide deliberately what belongs.

Mistake: Staying on the AI treadmill

The loop moves fast and feels good, which makes it hard to stop and apply your own judgment. Folkman's repeated warning is to deliberately get off the treadmill at the decision points (which changes to accept, whether an idea is actually viable) rather than letting the momentum carry unreviewed output forward. Teams that don't build "thinking" skills to force this end up outsourcing judgment instead of doing product work.

Mistake: Assuming a new model keeps skills working

A skill tuned for one model can get worse on a supposedly better one. Folkman found many of his core skills regressed moving to newer models, partly because he had forced behaviors that no longer needed forcing, and notes Opus 5 became noticeably more verbose than its predecessors. Build skills so you can roll back and re-tune when you change models, rather than assuming an upgrade is strictly better.

Practical Application

Build a customer-outreach loop

Run a scheduled loop that each day or week identifies customers worth contacting from your product data (a usage drop in Pendo or Amplitude, use of a feature you're working on), and, with the right guardrails, even drafts the outreach. Folkman calls this one of the best loops a PM can build, because it removes the biggest barrier to staying close to customers: the time to figure out who to reach out to and what to say.

Build a project-status loop

Have a loop pull tickets from Linear or Jira, check where each is, when it was last updated, what the risks are, and who is blocked or idle, then synthesize it so you never assemble that status by hand. It keeps you on top of execution without the manual reporting scramble.

Turn onboarding into a loop

AI is very good at systematizing an existing process, so first write down what your onboarding should be, then codify the mechanical parts: laptop setup, auto-scheduling first-week meetings from your calendar, and a "product tutor" skill in the repo that walks a new hire through the product and answers questions. Keep the human parts (customer field time, judgment calls) human. JobNimbus reports onboarding became both more efficient and more enjoyable because people aren't spending all their time just getting up to speed.

Add safety hooks before autonomy

Before letting a loop run more autonomously, add deterministic hooks: a startup hook that reports the repo and branch state, tool hooks that block destructive commands (rm -rf) and credential sharing, and a session-close hook that reviews the log for where things went wrong. These give you determinism around an inherently probabilistic agent, so a forgotten instruction can't blow away your data.

Questions to Consider

• For each thing we've automated with AI, is there a real learning step that feeds the log back to improve it, or is it a static skill we've mislabeled a "loop"?
• What is the validation gate for our most important AI workflow, and can we make it more deterministic, or are we relying on an LLM judging its own work?
• If we're now shipping product changes faster, have we added quality loops so customers don't simply experience proportionally more bugs at our unchanged defect rate?
• Where on our team is unreviewed AI output getting passed up the chain because the tool made it fast, and how do we force the human judgment step back in before it ships?

Bottom Line

A loop is not just an agent doing work, it's an agent whose work is validated by a real gate and whose skill improves from the log every run. Build the gate first (deterministic where you can, a synthetic customer from your own research where you can't), protect the loop with deterministic hooks, point loops at quality as much as speed, and never let the AI's momentum carry unreviewed output past your own judgment.

Tools & Products

People to Follow

Tyler Folkman

Chief AI Officer and Head of Product at JobNimbus, with a data-science and engineering background, leading both product and engineering. He writes a Substack newsletter called The AI Architect about his hands-on AI tinkering, and is a strong advocate of the "product builder" who merges product, design, and engineering with AI. Worth following for concrete, practitioner-level detail on building loops, skills, and hooks rather than high-level AI commentary.

Notable Quotes

"A skill goes to a loop when you feed back the learning so that it continues to improve." (Tyler Folkman)

"The customer doesn't experience your defect rate. They experience the number of defects that you push out there." (Tyler Folkman)

"If you end up in a meeting and your answer is Claude said that or told me that ... that's bad." (Tyler Folkman)