Your PM Team Stopped Prompting. Now They're Building Loops.

Let me catch you up. The way your team uses AI shifted this year, and it went past typing questions into a chat box. The people getting real work out of Claude are building it like software: saved playbooks, connected tools, and jobs that run on their own. Some of it is powerful. Some of it is a token bill waiting to happen. Here is what changed and what to do about it.

Claude has five layers, and your team lives on one of them

Jyothi Nookula, a former FAANG AI PM, lays out the Claude ecosystem as five layers: models at the bottom, then surfaces, then knowledge, then integrations, then agents on top. The point is to climb one layer at a time. Most PMs stall on the knowledge layer, which is the one that actually makes Claude know your world.

Her model advice is simple. Default to Sonnet for about ninety percent of PM work: PRDs, research synthesis, roadmap thinking. Hand the boring volume like tagging and triage to Haiku to save tokens. Save Opus for the high-stakes calls where you need second and third order thinking. She won her company's hackathon against 30 engineering teams using this stack, so it is not theory.

The knowledge layer is where the leverage sits. Projects hold your context. Skills are saved playbooks Claude reaches for on its own. Her warning: write the skills yourself. Her read of the research is that AI-written skill files underperform human-written ones. Draft with Claude, then add your template and domain knowledge.

Skills, not prompts, are the thing to version

A prompt is a one-time instruction. A skill is a reusable playbook, and Jyothi says to treat it like code. Version it. Roll back bad changes. Review it when your domain shifts or when output quality slips. Declining output is your cue the playbook went stale, and quarterly review is a fine default.

Her highest-value skills to build first are prioritization, PRD writing, customer interview synthesis, and turning support tickets into Jira issues. Her interview synthesis skill is the one to copy: it has a when-to-use trigger, a checklist, numbered steps, and a rule to keep behavioral observations separate from stated preferences so it hallucinates less.

For your team, this is a concrete move. Stop letting each PM reinvent the same prompt every week. Build a small shared library of skills, written by your best people, and put it under version control. That is the difference between a chatbot and a system your team can trust.

The loop is the new prompt, and that cuts both ways

The bigger shift is that some builders stopped prompting at all. At Anthropic's developer conference, Boris Cherny, who created Claude Code, said the plain version: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." A loop keeps an agent working toward a goal until it hits a defined finish line, instead of waiting for you after each turn.

The honest reporting here matters. Gergely Orosz asked around 210 devs how they actually use loops, and the answers were mostly triggers and cron jobs: an agent kicks off when an error logs or a ticket lands, or runs on a schedule. One director of engineering put it bluntly, that a lot of this is old-school automation that AI enthusiasts forgot already existed.

And loops break. Several devs rejected them after trying: agents drift, the human in the loop gets better results, and at companies paying API prices for tokens, loop engineering gets expensive fast. One distinguished engineer thinks the whole loop technique was a temporary hack while the tools caught up, since Codex, Hermes, and Claude Code all shipped a single /goal command by May that does the same thing.

The harness is the honest version of "just use AI"

Claire Vo made the sharpest practical case. A harness is just code around an AI agent, nothing more mysterious than that. She built one to automate Sentry bug triage at ChatPRD. Rather than giving the agent broad access to a tool and letting it wander, she wrote a custom adapter that pulls exactly what a bug report needs and nothing else. That makes it faster, cheaper, and less likely to go off-script.

Her rule for when to build one: the same workflow needs the same setup and the same outcomes every time, part deterministic and part not. The payoff is structured artifacts. Every run outputs the same bundle, a task log and issue brief and summary, so the whole team gets a scannable record without anyone writing it up by hand.

Her shift in thinking is the takeaway. The open chat field was good enough until it wasn't. Now she uses general agents to orchestrate specialized harnesses, not to do every job themselves. A constrained agent with a specific harness beats a powerful agent with an open prompt.

The mirror check nobody asked for

Anthropic also shipped a tool pointed back at the user. Claude Reflect works like Spotify Wrapped for your chat history, summarizing how you've used the bot over a month or a year. It scores your "AI fluency": delegation, discernment, and description. It flags where a vague prompt cost you and shows a better version.

David Nield's test found the summaries mostly fair, if a bit too polished, since Claude wants a neat narrative over an accurate one. It also skips your most recent chats and short one-offs. Useful as a self-audit, not a scoreboard. For a leader, it's a low-cost way to see whether your team is delegating real work or letting the tool do their thinking.

The deep cut

Match the model to the task, and match the effort to the payoff. Alex Finn's local AI fleet makes the point in dollars: he runs a cheap local model to scan code every 20 minutes and dumps findings to a file, then lets Claude Code review that report once a day. The local model does the volume, the frontier model does the judgment. Running the expensive model every 20 minutes would cost thousands a month for the same result.

That pattern scales down to your team without buying a single Mac Studio. Cheap model for volume, expensive model for judgment, and a hard look before you automate. The teams burning money are the ones running Opus on everything and building loops for work a plain cron job would handle. The teams winning are picking the smallest tool that does the job and versioning the parts that repeat.

Three questions for your team

1. Which four skills should we build and version first, and who on the team writes them, given that AI-written playbooks underperform human ones?
2. Where are we running our most expensive model on work a cheaper model or a plain automation could handle, and what would that save us monthly?
3. Which repeated workflow is stable enough to deserve a real harness, with structured artifacts, versus one we should leave as a manual prompt for now?