And every week I share actionable tips, templates, and step-by-step guides for PMs.

Here’s what you might have missed:

1. AI Prototyping in 2026: The PM Field Guide

2. The Ultimate AI PM Learning Roadmap 2026

3. What Is Product Discovery? The Ultimate Guide for PMs (2026 Edition)

4. How to Create an AI Product Strategy: The AI Strategic Lens Framework

Plus, 20+ recordings available for our premium members here: https://go.productcompass.pm/events

Consider subscribing and updating your account for the full experience.

Subscribe now

Today, we continue Product Engineering for PMs inspired by the Gartner report:

The roles are coming closer together.

My take: you don’t have to code, but as a PM you have a much stronger profile if you develop an understanding of engineering with AI.

In Part 1, we started building AskOne, an alternative to Slido (Q&A and polling platform). We implemented rooms, anonymous questions, Google authentication, Supabase storage, subscription plans, and a test payment gateway:

By popular request, I removed the paywall from that part. All detailed steps are available for everyone (the solution template is available for premium members):

Today, we discuss:

1. A Lightweight AI Software Lifecycle

2. AskOne: Let’s Add a Moderator Role

3. Create a Production GitHub Branch

4. Create a Production Supabase Project

5. Create a Production Netlify Site

6. Plug a Custom DNS Domain

7. Create a Production Clerk Instance

8. Add Product Analytics

9. Add Google Auth (For Real)

10. Conclusion

11. 🔒 Live Session Recording, Part 2

Before we dive in, would you like me to cover the most important AI news each week?

We’ve got Fable 5.1 (Sep 1) and GPT-6 Astra (Sep 3). I also shared my new Bug Hunt Bench (official website), that’s becoming a standard the AI community on X was waiting for:

And today, I published a new AI Slop Bench:

I don’t feel like sending you a dedicated email every 1-2 days. So what do you want me to do? The first option below is a dedicated publication you can subscribe to/unsubscribe from:

1. A Lightweight AI Software Lifecycle

I realized I’ve been simplifying the software development lifecycle with AI. Some of the prompts in the template were not the first prompts I wrote. Instead, I brainstormed with AI, and turned my brainstorming into something I can share with you.

How can you implement that, too?

First, I do not recommend heavy software development processes with unnecessary ceremonies and artifacts such as The AI-Native SDLC playbook by Anthropic. Those processes are meant for enterprises that cannot be more agile.

Paradoxically, even Anthropic doesn’t work this way! Their planning shifted away from design docs toward PR discussions and prototypes. They don’t do much product review. Instead they prototype, share what they build in front of internal users, and act on feedback. Individual pods are explicitly allowed to choose their own planning rituals. See Running an AI-native engineering org by the same Anthropic.

Which brings us to how I recommend you work in a team:

Step 1: Idea

Discover / discuss / research / prototype with Claude. Ask Claude: “ask me questions” or “present me 2-3 different directions with pros and cons.”

Outcome: An interactive prototype

Step 2: Refined idea

Problem/jobs to be done, users, desired behavior, important scenarios, constraints, UX decisions vs. design system. Here, your agent may decide to run spikes (probes) to confirm what’s technically possible. Let it do it.

Can be skipped for: Small changes
Outcome: A markdown file (.md)

Step 3: Plan

This is where the agent will inspect the codebase and create a specific implementation plan. It knows what to document, don’t tell it (architecture, files to change, implementation sequence, tests, risks).

You can use the plan mode for that, though models like Opus 5, Fable 5.1, or GPT-6 Astra don’t really need that and can jump from a refined idea to implementation.

Can be skipped for: Small or medium changes
Outcome: A markdown file (often plan.md)

Step 4: Build

AI will build the feature/product and run its unit tests. Still, even with browser automation it can’t reliably assess dynamic mechanisms (e.g., what’s visible before the page fully loads) or micro interactions.

Walk through the main scenarios and verify them with your eyes.

Subscribe now

2. AskOne: Let’s Add a Moderator Role

In Part 1, I enabled billing for users, because I didn’t want to combine users and organizations. With users, it’s simpler.

But you cannot add more users to a user 😅 You can add more users to an organization. If we want moderators, we need organizations. I should have predicted that.

So, right now, we will only have billing for organizations. Here’s how to do that:

Step 2.1: Switch to organization billing

Go to Clerk Dashboard > Configure > Billing. It is impossible to disable user billing if you have active subscriptions. I had to find my user (Users > my user > Subscriptions) and cancel the subscription. Only then was I able to disable user billing and, instead, enable billing for organizations:

Step 2.2: Define organization plans

Next, go to Configure > Billing > Organization Plans. The Free plan is created automatically. I edited it and added the features that already existed: 1 active room and up to 100 participants per room.

Then I clicked “Create Plan” and defined Premium: up to 10 active rooms and up to 1,000 participants per room, with monthly and annual billing:

An important configuration element is the feature key. After adding a feature, I edited its key: rooms_10 and participants_1000. This is important later in the prompt:

Rather than hard-coding subscription plans in the app, we defined features that gate capabilities. Now, we can create a new plan anytime and choose, for example, up to 10 active rooms, but without 1,000 participants per room:

• What you can do in an organization depends on its plan features

• What specific users in that organization can do depends on their role

Step 2.3: Rename Member to Moderator

Go to Configure > Organizations > Roles & Permissions. By default, you have two roles: Admin and Member. I opened Member, renamed it to Moderator, and changed the key to org:moderator. I didn’t change its permissions:

Step 2.4: Ask the agent

The prompt is in the template: prompts/007-organizations-moderation-and-billing.md. Replace the company details with yours and paste it into Claude Code (or Codex, see Section 3).

In the prompt, I explained that there is a role, org:moderator, that can view open and archived rooms only in its organization. If you are an admin, you can do everything in this organization. I also explained the plans, and that we do not rely on plan names, but on those two features.

Just to make this prompt comprehensive, I also asked it to build a landing page:

• research competitors (without naming them)

• show Clerk’s pricing table

• suggest legal documents

• add public metadata (so that when you share the website, it is visible with a preview)

• mention Microsoft Clarity without cookies in the policies (more in Section 8)

• update all the documentation

You will get a moderated room. When opening a room, there is a special checkbox: whether the room should be moderated:

If a participant asks a question, it is waiting for the host. As a host, I see all those questions, and I can approve, reject, or ban the user. Even though the user is anonymous, they will be blocked by the cookie. If they have disabled cookies, they cannot ask questions.

After the moderator approves, the question becomes visible for everyone. We can open the projector view - this is what the host would present on the screen:

On the landing page, people who are not signed up see basic information about the product: the value proposition, how it is different, and the legal documents:

Subscribe now

3. Create a Production GitHub Branch

So far, every change we push to GitHub appears on Netlify immediately. For a production environment, we need a separate branch. Ask the agent:

Create a production branch from origin/askone. Call it askone-prod. Ignore my local modifications, they are work in progress.

“Origin” means what is right now on GitHub, not my local modifications. LLMs understand it.

People asked me on Slack how to use other coding agents. The solution template I shared in the previous and the current article is ready for it.

I ran this step with Codex. All the agents, whether it is Grok, Codex, or Claude Code, read AGENTS.md and the Clerk and Supabase skills. The only thing I had to fix was authenticating the Supabase MCP server, because Codex needed a separate one. It helped me do it. Other than that, out of the box, Codex works:

You can learn more about GitHub branches here: How Git Works by ByteByteGo

Subscribe now

4. Create a Production Supabase Project

Just like on GitHub, we can have multiple variants of the database. Supabase calls them branches. But this requires a paid subscription, and you can’t create a branch and make it the production one. I don’t want you to fight it.

Instead, create a new project and sync it with the production branch on GitHub. It’s clean, and it’s free.

Step 4.1: Create a new project

Go to Supabase and create a new project, just like in Part 1 (Step 3.1). Call it, for example, askone-prod. Then go to Project Settings > API, as in Part 1. Note:

• SUPABASE_URL

• SUPABASE_SECRET_KEY

Step 4.2: Sync it with GitHub

Go to Supabase, select your project, click “Manage branches.” An example for a different project:

Then, under Configure, click “GitHub connection:”

And select your GitHub repository and a production branch:

It will get updated every time you push changes to that branch. So, right now, when a user inserts some data on dev, or when I change the database structure, those changes will not propagate to production. That’s what we want.

Wait. What about the tables?

All the modifications in the database are written as migration scripts. This is also part of the template. Every time we add a new field or a new form in our product, there will be a migration script. It appears in GitHub, next to the code:

When you transfer your app version from dev to prod, the logic is transferred because you transfer the code. Database changes are transferred through those migration scripts, and Supabase executes them.

Code and database migrations move together. Not the data.

After the sync, I was curious if there is any data inside. Go to Table Editor: the tables are there, and there are no rows. The structure was copied, the data was not.

5. Create a Production Netlify Site

Normally, you would have multiple environments: dev for developers, test, preprod (a copy of production, often without personal information), and production. The release goes through all of them.

We will implement a simplified version. Instead of creating another Netlify project, I took the one from Part 1 and just made it production. Dev stays on my local machine. I don’t need it hosted on Netlify.

Step 5.1: Switch the production branch

Go to Netlify > your project > Project configuration > Build & deploy > Manage repository > Link to a different repository > GitHub.

Select your repository (here, “fde-template”) and the production branch (here, “askone-prod”):

Step 5.2: Replace the Supabase keys

Go to Project configuration > Environment variables and edit two values:

1. SUPABASE_URL -> copy from Section 4

2. SUPABASE_SECRET_KEY -> copy from Section 4, mark as secret

I’m still using the development Clerk instance, just so that we don’t switch everything at once. We will switch it in Section 7.

Step 5.3: Deploy

New environment variables need a new deploy. Go to Deploys > Trigger deploy > Deploy project:

After those changes, you should see an empty app. I’m signed in, but my data disappeared, because right now we are using the new production database.

6. Plug a Custom DNS Domain

We have a production app, but we don’t have the production URL. I purchased a cheap domain on GoDaddy: askone.org. In every provider, it is similar.

Step 6.1: Add the domain in Netlify

Go to Domain management > Add a domain. Netlify verifies that you own it and recommends Netlify DNS:

In the next step, I got a list of four Netlify DNS servers:

Step 6.2: Point GoDaddy to Netlify

In GoDaddy, go to your domain > DNS > Nameservers > Change, and paste the four Netlify name servers:

Step 6.3: Wait

It can take up to an hour. Then Netlify detects the domain, and DNS verification is successful. What it means is that Netlify will provide an automatic certificate for us, and our domain will be secure (HTTPS). We don’t have to purchase a certificate. It will just do it automatically:

Step 6.4: Adjust the app URL

The app URL has changed. We need it to display the join codes for participants. In Netlify, go to Project configuration > Environment variables, set APP_URL to https://askone.org, and trigger a deploy, as in Step 5.3.

We discussed how to manage Netlify secrets in Part 1.

You, too, can access it: https://askone.org. It’s not perfect, but it works, on a real domain.

Subscribe now

7. Create a Production Clerk Instance

We have a production app, we have a production URL, but we don’t have production users yet. And we do not want to use the dev/test users in production.

To fix that, go to Clerk Dashboard, click “Go to Production,” and clone your development instance. All the pricing plans and features will be cloned. The application domain will be askone.org. This is where users can access the app:

And we have a new secret key for Clerk that we need to configure in environment variables. So let’s do that. Go to Configure > API keys, as in Part 1. Note:

• NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY

• CLERK_SECRET_KEY

In Netlify, go to Project configuration > Environment variables:

1. CLERK_SECRET_KEY -> again, I will replace it, mark as secret

2. NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY -> we have a new one, too. This is not a secret

Then trigger a deploy, as in Step 5.3.

What else? SSO connections. Right now, Google is not supported. We will do it in Section 9. And we need to add the DNS records that Clerk requested to Netlify:

In Netlify, go to DNS > your domain > DNS settings > Add new record. I did it like this:

All those records take time to propagate. But once they are verified, Clerk will start serving authentication for our production app:

8. Add Product Analytics

I suggest you start with Microsoft Clarity. It’s 100% free, without limits. Similarly, you can add other tracking codes in the future.

I’m not presenting creating an account. It’s straightforward.

Once inside, create a new project:

Then go to Settings > Setup > Advanced settings and switch cookies off:

Go to Settings > Setup > Install manually and get a tracking code:

Next, ask the agent (your code will be different):

Inject the following Microsoft Clarity script to every page of our app:

<script type="text/javascript">
    (function(c,l,a,r,i,t,y){
        c[a]=c[a]||function(){(c[a].q=c[a].q||[]).push(arguments)};
        t=l.createElement(r);t.async=1;t.src="https://www.clarity.ms/tag/"+i;
        y=l.getElementsByTagName(r)[0];y.parentNode.insertBefore(t,y);
    })(window, document, "clarity", "script", "yej44djiyd");
</script>

An example report you will see (a different app):

9. Add Google Auth (For Real)

In development, Clerk provides shared Google credentials. In production, you need your own. The entire process (no screenshots, we would need too many):

I’m not presenting creating a Google Cloud Console (GCC) account. It’s straightforward. Once inside:

1. [GCC] Create a new or select an existing project

2. [GCC] Go to APIs & Services > OAuth > Get Started

3. [GCC] Add app information (External)

4. [GCC] Create OAuth client ID, note “Client ID” and “Client secret”

5. [GCC] Add your app URL to Authorized JavaScript Origins

6. [GCC] Go to Branding: add the app logo and the app domain, provide the terms of service and privacy policy links (we created those pages together with our landing page)

7. [GCC] Go to Audience > Publish app

8. [GCC] Go to Branding > Verify branding

If the branding verification fails, go to Google Search Console (GSC) and verify you’re the owner of the domain:

1. [GSC] Add a website

2. [GSC] Copy TXT record for DNS configuration

3. [Netlify] Paste this record in Netlify > DNS

4. [GSC] Click Verify

5. [GCC] Go to Branding > Verify branding

Next, configure Google Auth in Clerk:

1. [Clerk] Configure > User & authentication > SSO connections > Google > Enable

2. [Clerk] Configure “Client ID” and “Client secret” you got from Google

3. [Clerk] Copy “Authorized Redirect URI”

4. [GCC] Go to your project > Credentials > OAuth 2.0 > use “Authorized Redirect URI” from Clerk

5. Wait 5 minutes

🎉 You can now Sign in / Sign up with Google in production. No “Development environment:”

10. Conclusion

We have a production database, a production app, production users, and a production domain. Development stays on your laptop, but you know how to create more environments, if needed.

We still haven’t opened a file with the code.

Next in the series:

• Introducing a change and moving it between environments, end to end: the code and the database (not the data)

• Enabling real Stripe payments

• App-specific limits. Right now, an organization can have up to 10 active rooms. But can they open and close a room 1,000 times a second? What about free users?

• Cloudflare: a web application firewall that guards the app against attacks that exhaust our resources

• Tests in more detail: unit, integration, end-to-end, and AI looking at the screens

• A checklist to verify that what we build is secure and efficient, and how to make sure AI has enough information to perform that verification

This Thursday, we continue building AskOne: https://go.productcompass.pm/events

Subscribe now

11. Live Session Recording, Part 2

Part 1 and Part 2 are available here: https://go.productcompass.pm/events

Subscribe now

P.S. If you’re looking for a structured cohort, I just joined Product Faculty as a trainer.

Currently, we offer 8 AI PM cohorts (Anthropic, Google, OpenAI) for the price of one + $1,500 off for my readers: 👉 https://productfaculty.com?code=PAWEL

On Maven, this program would cost ~$22,000. That’s, by far, the best training offer in the market.

And that’s not everything. Everyone who enrolls with the above code can attend our Claudathon for PMs for free: https://go.productcompass.pm/claudathon (send me an email with a purchase confirmation: pawel@productcompass.pm) - we start on Sep 19.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have an amazing rest of the week,
Paweł

And one more question: should I move agentic engineering (what this series is about) to a separate stream? The first option below is a dedicated newsletter you can subscribe to/unsubscribe from:

The roles are merging whether or not you can already feel that in your organization. While product discovery remains the core of our job, as a PM you should develop a basic understanding of engineering with AI.

Good news: you don’t have to code.

My recent project, Grok Build for VS Code and afkpilot.com/desktop, has been installed by 105K+ people. 37K MAU. 5,094 unit tests. ~177K lines of code - I’ve reviewed none.

Many ask me how I can trust the agents.

If you think about the 5,094 tests, this number is crazy. Many of them impersonate users and drive the browser sessions end-to-end. Only AI could do that in 3 months. This transforms the quality of what we can ship as non-developers.

A critical part is also documenting the intent, so that agents have something to design tests and inspect the codebase against.

In my new series, rather than presenting infographics, I demonstrate the how step-by-step, with templates, prompts, and all the hacks I’ve learned. By the end you will know how to discover, design, build & secure, launch & monetize, analyze, and monitor a commercial product. A real side hustle or for your portfolio.

Without ever looking at the code.

Subscribe now

Side note: As some have asked, hooked users are already paying to use the remote client ($1,920 ARR). The first step was proving the value and the word-of-mouth. I will focus on monetization after launching managed hosting — tomorrow.

In this issue:

1. Case Study Context: AskOne, Slido Alternative

2. Claude Solution Template for Non-Coders

3. Step 1: Design your App

4. Step 2: Build a Static Website

5. Step 3: Setup Clerk & Supabase

6. Step 4: Sign Up with Google, See Your Data

7. Step 5: Configure Billing and Plans, See a Purchase

8. Step 6: Add Test Accounts and Browser Automation

9. Step 7: Publish it, Simplified

10. 🔒 The Template to Download

11. Conclusion

12. 🔒 Live Session Recording

You can choose any web product. The steps are universal. This part will take you 3-4 hours. Most of that is waiting for AI, so you can drive it remotely from your phone.

Subscribe now

1. Case Study Context: AskOne, Slido Alternative

AskOne is live Q&A for talks, webinars and cohort sessions:

• A host opens a room and gets a join code.

• The audience opens askone.org/r/<code> on their phones, no account, asks questions and upvotes.

• The host and moderators approve, hide, pin and mark answered; the room updates live; a projector view shows the top questions. When the room closes, the host gets the Q&A by email.

• An API and an MCP server let the host's agent turn the questions into a FAQ.

B2B2C SaaS.

A $5/month alternative to Slido:

Banal on purpose. It will demonstrate all critical elements, including a multi-tenant setup, Google authentication, paid subscriptions, roles and permissions, CI/CD, and securing the app.

You will never open a file with the code.

2. Claude Solution Template for Non-Coders

You don’t have to start from scratch. A Claude SaaS solution template we will start with defines:

• The recommended, common tech stack (Next.js, Clerk, Supabase)

• Preinstalled skills for Supabase and Clerk integrations

• Instructions for the agent (quality, documentation, opinionated choices that worked best for me)

AGENTS.md has a strategic context placeholder that should stem from your product discovery. Explain what you want to build, market segments, value propositions, jobs to be done, use cases, who can do what, not in scope, and constraints:

This is just a high-level strategic context, not a full specification upfront — we can’t know it without interacting with the app and getting feedback from the users.

You can use my case study, or replace it with what you know about your product.

3. Step 1: Design your App

We start with design. Let’s keep it simple. No accounts, no keys, no database. Just you and the Claude Code chat.

Ask (all my prompts are part of the template, you can copy and adjust them):

Read AGENTS.md. Design only — no code, no database, no .env.

/design the two Phase 1 screens with their empty states: the host's rooms list (desktop) and the participant's room page (phone). Use the `frontend-design` skill. I want to open and interact with the results.

Give me two genuinely different directions, one line each on what it optimizes for and the trade-off. Stop; I pick.

After I pick: build the kit in design/, rebuild the two screens from it, keep the artboards in the repo, commit, and stop again.

Layout, copy, type, color, what the kit contains — yours. Real copy, lucide icons, phone-first. 

It gave me an interactive link with 2 designs: https://claude.ai/code/artifact/6abe1030-5b21-418e-9326-999b3edfa816.

I rejected “A - Show of hands”:

And selected B — Signal desk, to prioritize enterprise buyers:

Then, Claude built a design system with tokens (colors, styles) we will use later when developing our product. You can preview it here: https://claude.ai/code/artifact/32fd141c-452d-45a7-8111-d6cb7792085a

4. Step 2: Build a Static Website

This step turns the design into an app we can click through. Still without accounts or database.

Ask the agent:

Read AGENTS.md and design/README.md. Build the approved design as a running app: the host's rooms list and the participant's room page, with realistic content and their empty states.

No accounts and no database in this session. 003 connects Clerk and Supabase; 004 puts the real data model (§ 1.1 — workspaces, the three functions) behind these same screens. Build so that swap is small, and invent no storage in the meantime.

Plan briefly, build, commit, run it and give me the URL. Then stop and tell me what I can click.

It gave me a URL I can click (localhost, works only on my machine):

The live website looked just like the design:

5. Step 3: Setup Clerk & Supabase

Our app exists and can be displayed in the browser, but with fake content. The next step is connecting the two services that make it real:

• Clerk decides who you are

• Supabase is where the data lives

Step 3.1: Create two new projects

Configure Clerk

Create a new, free application at https://dashboard.clerk.com/apps/new. Make sure Google auth is enabled. Don’t enable multi-tenancy yet. We will do it later:

You will land on the development instance. The dashboard offers a long “Add authentication” prompt: ignore it. The page you want is Configure → API keys.

Note:

• NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY

• CLERK_SECRET_KEY

Configure Supabase

Create an empty, free project at https://supabase.com/dashboard.

Go to Project Settings → API for the project URL and the secret key. The publishable key is optional, only for your unit tests.

Note:

• SUPABASE_URL

• SUPABASE_SECRET_KEY

• SUPABASE_PUBLISHABLE_KEY

Step 3.2: Establish a Supabase MCP connection

Supabase generates this for your project under Connect → MCP → Claude Code. Select all feature groups, copy the prompt, and paste it into your Claude Code:

It carries your project ref, so the version below is only the shape:

1. Add MCP server

claude mcp add --scope project --transport http supabase "https://mcp.supabase.com/mcp?project_ref=************"

2. Authenticate

Run this in a regular terminal, not an IDE extension. Select the supabase server, then Authenticate.

claude /mcp

3. Install Agent Skills (optional)

npx skills add supabase/agent-skills

“Install Agent Skills” is already done (included in our template). Step 2 is yours: open Claude Code in the terminal, type /mcp, pick supabase, select Authenticate (hit Enter):

Restart Claude Code by pressing “Ctrl + Shift + P,” then “Developer: Reload Window”:

Or you can restart the entire VS Code.

Step 3.3: Configure your access keys

Copy .env.example to .env and fill in the five values from Step 3.1:

Ask the agent:

I configured the secrets in .env. Please verify connections to Supabase and Clerk. 

All should be green (not literally). If not, let the agent guide you.

6. Step 4: Sign Up with Google, See Your Data

The screens exist and the two services are connected. This step makes them real: signing in, a database, and who is allowed to do what. It is the long one, though. You can delegate that work and go do something else.

Ask the agent (Opus 5 worked for ~30 min):

Read AGENTS.md and design/README.md. Build Phase 1 for real: sign-in, a host's own rooms, the public room page anyone can use without an account, questions, and upvotes.

Check the ground first — the Supabase MCP answers, the project has no tables, .env is filled — and stop if any of that is false. Then plan in one page and stop.

Build it. The screens from design/ keep their shape; what changes is where their data comes from and how users can authenticate. Use standard Clerk components and integrate them with the existing design.

Then commit, run it, give me the URL, and one summary: what exists, what the tests cover, what you left out, and how I check it by hand. 

You will get a working app you can sign up into:

Share

Part of its report:

The session didn’t end at the first summary. I tested the app manually and asked for what's missing. The follow-up prompt that was actually run:

Issues:
- Implement the 'Open projector' and 'Close room' buttons - they currently do nothing.
- Add a QR code for the room URL, perhaps displayed on request on `/rooms` and inside the room. Include buttons to copy the URL and download the QR code as a PNG.
- Add confirmation before closing a room. Closing should block anonymous participants only. I should still be able to open the room, view questions, and reopen it for participants.
- Remove the Next.js icon.

Claude fixed all those issues in one iteration. I already included them in the video above.

7. Step 5: Configure Billing and Plans, See a Purchase

We can’t offer our product for free forever. The next step is configuring subscription plans. Let’s start with B2C.

Step 5.1: Enable billing

Go to Clerk Dashboard > Configure > Billing and turn on “Enable user billing:”

On the same page enable “Clerk payment gateway” - on a dev environment, we don’t want real transactions (later, the integration with real Stripe is banal):

Step 5.2: Define Subscription Plans

Next, go to Clerk Dashboard > Configure > Billing > User Plans. Define two plans, for example:

• Free

• Premium

For each plan you can configure a monthly base fee (e.g., $5) and an annual base fee with an optional discount (e.g., $50) and enable/disable free trials. Play with the options:

An important configuration element is the Features. These can be used to guide the app behavior (entitlements, we will discuss this later) or displayed in public pricing plans:

Step 5.3: Test it

Wait. What about the prompt?

There is no prompt. We’ve previously implemented Clerk integration and asked Claude to use Clerk components. Subscription plans just work based on the current Clerk configuration:

8. Step 6: Add Test Accounts and Browser Automation

Go to Clerk Dashboard > Configure > Instance. Enable the “Test mode.” This will allow the agent to sign in to your development environment. I recommend you change the default verification code (here, “424242”):

Next, go to Clerk Dashboard > Users and create an account with a special +clerk_test@ part, for example:

Save the user data to your .env file (we discussed that file earlier):

For your convenience:

# --- Test accounts ---
TEST_VERIFICATION_CODE=424242
TEST_ADMIN_EMAIL=admin+clerk_test@gmail.com

Next, ask the agent (Opus 5 worked for ~25 min):

Implement e2e test scenarios using browser automation (headless). In .env, I defined Clerk's:
TEST_VERIFICATION_CODE
TEST_ADMIN_EMAIL

Suggest complete scenarios (such as Sign in > Open a new room > Users ask questions > Users upvote questions > Admin can see these questions on a Projector > Admin closes the Room) and tell me what's covered. Run those tests.

Make sure test documentation is updated and create or show me a document with roles and permission matrix + what's not implemented yet.

You will get a detailed test report:

And detailed documentation with a permission matrix:

Review it against your intent. This is the base for future tests and automated code inspections. Without it, your agent may not know whether the observed behavior is a bug or a feature:

If you don’t see nice markdown formatting: Right click the tab name above the file content > “Open with” > “Markdown preview.”

Share

9. Step 7: Publish it, Simplified

Let’s publish our dev environment. No advanced branches yet. For that, we need:

• A free GitHub account

• The GitHub CLI

• A free Netlify account

Step 7.1: Install GitHub CLI

I’m not presenting creating a GitHub account. It’s straightforward.

Once you have one, go to https://cli.github.com/ and copy the installation prompt for your operating system:

Execute it in your terminal (mine was already installed):

Then type “gh auth login” and answer four questions:

• “GitHub.com”

• “HTTPS”

• “Y”

• “Login with a web browser”

Hit “Enter.” Use the code displayed on the screen to authorize your device. I anonymized my code:

Now, ask the agent:

Just installed GitHub CLI. Create a new private repository for my project, "askone," and push the current to origin. Give me its URL.

Before the push, add netlify.toml as I will host this on Netlify.

“Push to origin” means “push to GitHub branch.” Here, it may not be needed. In the future, this is how you transfer your local changes to GitHub.

You will get a URL such as https://github.com/phuryn/askone. That's your online code repository!

Step 7.2: Publish it on Netlify

I’m not presenting creating a free Netlify account. It’s straightforward. Just remember to Sign up with GitHub.

Once inside, go to https://app.netlify.com/start > Import a Git repository > click “GitHub:”

Select your repository:

Give it a name and click “Deploy” at the very bottom of the page:

On the same page, it should automatically detect the right build settings (previously, we asked in the prompt to define netlify.toml). I didn’t have to type it manually:

At the bottom of the page you will find a deploy button. Hit it:

Step 7.3: Configure Netlify Environment Variables

The .env file is untracked. Netlify doesn’t know your secrets.

Go to “Project navigation” > “Project configuration” > “Environment variables:”

You could import the entire content of your .env file, but I prefer adding them manually:

The full set the app refuses to boot without. All six, or nothing serves:

1. APP_URL - use your URL, e.g., https://askone.netlify.app

2. PARTICIPANT_COOKIE_SECRET -> copy from .env, mark as secret

3. SUPABASE_URL -> copy from .env

4. SUPABASE_SECRET_KEY -> copy from .env, mark as secret

5. NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY -> copy from .env

6. CLERK_SECRET_KEY -> copy from .env, mark as secret

Step 7.4: Test it

You, too, can access my dev environment: https://askone.netlify.app/ It’s far from perfect, but it works, and won’t reveal your room’s data to others.

10. The Template to Download

After clicking the link you will see:

Unzip fde-template-main.zip and open it with VS Code:

I’ll be adding more prompts, but I’m not going to change the template, so you can already start building on top of it.

11. Conclusion

I wrote this because the roles are merging whether or not you can already feel that in your organization. While product discovery remains the core of our job, as a PM you should understand how to engineer with AI.

You don’t have to code. At the same time, understanding the basic engineering concepts helps a lot.

So, here are some extra materials you can review in your free time:

[Day 1] Review these helicopter view resources:

• System Design 101 by ByteByteGo

• Engineering Visual Guides

• Become a Supabase Pro in 1.5 Hours (YouTube, 1:26:39)

• Overview of HTTP by Mozilla

• HTTP Request Methods

• The most important concepts of Node.js and Express.js (YouTube 17:09)

• CSP Guide by Mozilla

• OWASP Top 10

• How Git Works by ByteByteGo

• Overview of Test Automation with Selenium

[Days 2-3] Start working with Claude Code and Codex (our recordings with templates):

• Codex for PMs

• Claude Code for PMs

• Claude Code Power Skills for PMs

[Day 4] Proven ways to manage AI agents (not what people say):

• Intent Engineering

• Don’t review code, review artifacts

Next in the series, we will cover:

• Plugging a custom domain (askone.org)

• Multi-tenant setup & more user roles

• Mapping features to entitlements

• Enabling real Stripe payments

• App monitoring & support

• CI/CD best practices & automation

• PII, Terms of Use, Privacy Policy

• Securing the app (WEF with Cloudflare, app-specific limits)

• Security and performance tests

This Thursday, we continue building AskOne: https://go.productcompass.pm/events
The recording of the recent Thursday’s session will be available later today.

Subscribe now

12. Live Session Recording

You can watch it here, Steps 1-5: https://go.productcompass.pm/events

If you do not have an account, sign up with your newsletter email. The benefits will sync in 5 min (existing subscribers) - 2 hours (just subscribed).

P.S. If you’re looking for a cohort, I just joined Product Faculty as a trainer.

Currently, we offer 8 AI PM cohorts (Anthropic, Google, OpenAI) for the price of one + $1,500 off for my readers: 👉 https://productfaculty.com?code=PAWEL

You get them all for $3,500. On Maven, this program would cost ~$22,000. That’s, by far, the best training offer in the market.

And that’s not everything. Everyone who enrolls with the above code can attend our Claudathon for PMs for free: https://go.productcompass.pm/claudathon (send me an email with a purchase confirmation: pawel@productcompass.pm) - we start on Sep 19.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Give a gift subscription

Have an amazing rest of the week,
Paweł

So recently, I ran a live workshop with a group of PMs using popular tools. We built the same simple CRM in Lovable, in Google AI Studio, in Claude Design, and Claude Code.

In this issue:

1. Why AI Prototyping (+Why Now)

2. The Four AI Prototyping Tools: Helicopter View

3. Iterate. Don't Spec.

4. Lovable: From Prompt to Published App

5. Google AI Studio: Good Enough to Prototype

6. Claude Design: The Best-Looking Prototype, With a Ceiling

7. Claude Code: The Prototype That's a Real App

8. How to Instrument Your Prototypes

9. Conclusion

1. Why AI Prototyping (+Why Now)

In product, most of our ideas don't work. As Marty Cagan says, “at least half of our ideas are just not going to work.” Good teams assume at least three-quarters of their ideas won't perform as they hope.

The last time I worked as a PM, at Ideals, I worked with 7-8 engineers, and building anything still took us 2-4 weeks. So, like many product teams, we tested our ideas, mostly with user prototypes (Figma) before committing.

That's a standard in product discovery.

AI has changed a lot. That prototyping part is not gone. It changed, in two ways:

• PMs prototype themselves now. Designers didn’t disappear, but it makes no sense to wait for a designer with every simple question when a working prototype is one or two prompts away. You show the thing to peers, stakeholders, or even users, instead of describing it.

• Ideas get tested as production-ready features. For cheap, reversible ideas, shipping behind a feature flag and measuring real usage is often easier than running a separate experiment. High-risk or hard-to-reverse ideas still get experiments.

Keep this in mind when we compare the tools below: prototype and feature, those two terms are closer than ever. The boundary is blurring.

It's not just my experience:

In Productboard's survey of enterprise product teams, 60% already use two different AI tools just for prototyping.

And you? Do you prototype as a PM?

Leave a comment

2. The Four AI Prototyping Tools: Helicopter View

Below, a helicopter view of the four popular tools you will work with as a PM.

Selected insights:

• Lovable: hosting and Google auth solved in one click, strong UI. Check the default data policy (RLS) before publishing. Hardest to leave if you use Lovable Cloud, and your engineers are unlikely to build on it.

• Google AI Studio: test an idea today, no subscription. Weakest UI. Firestore and Google auth tie you to Google.

• Claude Design: the best-looking prototype, and it interviews you first. No tracking, no analytics, no databases. It doesn’t allow you to build features end-to-end.

• Claude Code: the most setup, zero lock-in. Real code in your repo, instrument anything, the strongest handoff.

People often ask me about Bolt or Magic Patterns. I don't recommend those tools. Magic Patterns creates a mess and breaks when multiple people work on the same design. Bolt is not a bad tool. There are just better alternatives.

I also didn’t include chatbots such as ChatGPT. They are easy to use and can create static HTML pages, but you’re unlikely to use them for prototyping in a professional environment - you can’t instrument them. Use Google AI Studio instead.

Subscribe now

3. Iterate. Don't Spec.

Do you believe you can document a solution, hand it to the developers, and hope the documentation is complete? That is waterfall. It has never worked.

But for some reason, people have been proposing specs-driven development, where you do exactly the same thing with agents.

Of course, it cannot work. We understand what should be adjusted only once we see the product. And we will get much better feedback from the users interacting with what we built.

I'm not alone. Allen Holub, in April 2026:

“I really don't get 'spec-based development,' which is nothing but a fancy way to describe a phase-gated 'waterfall.' An upfront specification is never correct.”

So what is the alternative? The one Scrum and Agile discovered long ago: iterating.

That's how I develop Grok Build (Open VSX, VS Code Marketplace) and AFK Pilot (75K+ installs), with production releases sometimes twice a day:

3.1 Don't iterate blindly: define the strategic context

While I encourage iteration, we shouldn't iterate blindly. What we can define before starting is the strategic context:

• Users: who is this product for

• Problems: what hurts them today

• What matters most: their jobs to be done

For an existing product, this should be part of your CLAUDE.md, the file that provides the strategic context for your agent. If you are not working with Anthropic's tools, this file is called AGENTS.md.

I explained it in more detail in: Claude Code for PMs: The Beginner’s Guide

In most cases, this context is enough for an agent to make good decisions. More on leading agents with context, not control: The Intent Engineering Framework.

3.2 The prompt: a new feature or a new product

When you prototype a new feature for an existing product, the strategic context is already in the file. The prompt carries only the context relevant to the feature:

Prototype [feature] for our existing product.

For this feature:
- Users: [who has this problem]
- Problem: [what hurts them today]
- The specific job it solves: [what the user is trying to do]
- What we know: [data, interviews, support tickets]

I think it could work like [your idea], but my idea is not binding.
Think about alternative solutions and propose one if it's better.

When you prototype a new product, there is no context file yet. So the context goes in the prompt, and you ask the agent to save it:

Build a prototype of a simple CRM.

Context, not requirements:
- Users: a 2-5 person B2B sales team
- Problem(s): follow-ups slip through the inbox
- The job(s) to be done: show what needs follow-up today
- Out of scope: billing, admin, integrations
- Rough idea (optional, not binding): a simple pipeline with a "due today" view
- What we know so far (optional): [interviews, data, anything relevant]

Decide the screens and the interface yourself.
Ask me up to 5 questions before you start.
Then save this context to CLAUDE.md.

Two notes on those prompts:

• If you suggest a solution, still encourage the agent to think about alternatives. Many times agents suggested ideas I hadn’t thought about.

• A one-line prompt (“Help me build a simple CRM for a small organization”) also works, especially with the “ask me 5 questions” line (some agents do it without the prompt, more on that later in this post).

4. Lovable: From Prompt to Published App

We started with Lovable. It's the simplest path from a prompt to something working, potentially in production.

Step 1: Open Lovable and type the prompt

Go to lovable.dev:

Help me build a simple CRM for a small organization

You don’t have to think about hosting. By default, Lovable will use Lovable Cloud, a Supabase they host. You just publish.

And you don't have to think about authentication, because their Google sign-in works out of the box. You pay for the editor. Hosting is virtually free.

You can also bring your own design system: import it as a design.md or upload a zip.

Step 2: Answer the interview

If your prompt was not precise, Lovable will ask you a few questions before it starts. Mine asked who uses it, what the CRM should track first, how deals should be displayed, and whether I had a style preference:

I picked a small team with logins, shared data, and not "each user only sees their own records." Then contacts, deals, activity notes, and a style.

Step 3: Sign in with Google

Lovable finished. You can open the preview in a separate tab and sign in with Google:

Google authentication comes with Lovable Cloud. When I implemented Accredia, I used a custom Supabase and I had to wait ~2 weeks for Google to approve the app. Here, it just works from the start.

I added a couple of contacts manually.

Step 4: Check Cloud

Click the project name, then open More → Cloud, next to Code:

This is the database Lovable created and manages for us. Not a traditional Supabase you can easily access. Your options are limited.

Step 5: Read the RLS policies

Go to More → Cloud and open policies.

RLS is row-level security: who can see which rows.

I had already answered the interview: a small team, shared data. That is not the same as the policy Lovable implemented.

On contacts, mine was USING true, which means any signed-in user, not just my team. Shared with the team and anyone with a Google login are not the same thing.

It seemed to me that right now anyone can see any data. You don’t have to overthink your prompts. Just ask:

Hey, users should see only their data. Ensure that's the case.

And Lovable fixed the RLS:

I opened it in incognito and signed in with a different Google account: empty contact list. Users are isolated. An attendee confirmed it from the outside, 62 seconds after I shared the link. I should have done it before publishing.

Answering the interview is not the same as setting the policy. Ask what users can see in the chat, test the app using different accounts, and consider opening Cloud → policies before you publish anything.

Step 6: Publish

Click Publish, and the app is available to anyone with the link.
Mine: https://hearth-home-crm.lovable.app

You can point your own domain, but theirs is often enough for testing. To make it look less like a prototype, hide the Lovable badge in the settings.

Lovable Cheat Sheet

• Use it when: you need a link today, with Google auth and a database.

• Skip it when: engineers will take this over. There is no click that says "I want to stop using Lovable Cloud." Also skip if you’re looking for a budget solution.

• Watch for: RLS (USING true is not "my team"). One database for every environment (no DEV / STAGING / PROD separation). Unknown LLM model.

5. Google AI Studio: Good Enough to Prototype

Google AI Studio is no longer only a user interface tool. It can create a database in Firestore, and it can authenticate your users. I'm on the Pro license, but there is also a free version.

Step 1: Open Build and paste the prompt

Open aistudio.google.com and switch to Build:

Help me build a simple CRM for a small organization that includes contact management, task tracking, and basic email integration

Step 2: Enable Firebase when it asks

It asked me if I want to enable Firebase. This is the database that Google can host, so I agreed:

Step 3: Pick a visual style and confirm

I like this slick interface, so let's select this design:

Once you confirm, the build is more technical than Lovable's. You will see file names going by, but you don't have to open any of them.

Step 4: Seed the data

The first dashboard is empty, so click Seed Demo Data. Then you get a pipeline, contacts, and tasks you can click through:

I don’t really like how Google designs interfaces. I selected what seemed the best. Still, not a Lovable level. Their default model is Gemini Flash.

But for prototyping, it is often all that you need. And you can steer it with prompts or by giving examples / screenshots of the products you like.

Step 5: Publish

Click Publish, and you get a nice URL to share.
Mine: https://organization-crm.ai.studio/

You can also sync the project with GitHub in the settings. Then you can open the same project in Claude or in Codex and continue there.

AI Studio Cheat Sheet

• Use it when: you want to test an idea today. Free version exists.

• Skip it when: you need a top-notch design.

• Watch for: Google ecosystem. Swapping Firestore is not that straightforward (for an agent, probably one day).

6. Claude Design: The Best-Looking Prototype, With a Ceiling

Read more

On July 24, Anthropic put it at the top of nearly every test they publish:

But then I used it for a few days. The more I worked with it, the less I liked it.

And it’s not just me. For example:

My timeline has looked like this for two weeks. “Cancel the subscription.” “Bring back 4.6.” “Anthropic broke it.”

The closest thing to advice out there is this:

Right diagnosis, half a prescription. “Delete everything” and you also delete the half no model can guess: your preferences, the decisions you already made, the strategic context.

Here is what I think happened:

• Anthropic removed 80% of Claude Code's system prompt and was proud of it. I measured the cut: 2,686 words down to 514.

• As Kun Chen explained, Anthropic also pushed reinforcement learning too far toward long jobs. It was trained to work without you, so it stopped working with you:

Both mean this model needs more instructions, not fewer.

Luckily, you can heal it.

I never switched away from Opus 5. Every time a failure repeated, I wrote the rule that stopped it, then kept working. After two weeks, eight blocks survived.

With them, Opus 5 is the best Opus I have used by a large margin.

1. Act. Don't Ask.

The failure: Opus 5 stops to ask for permission when the decision is obvious.

It pauses mid-task to ask whether it should follow the naming convention visible in the folder it just read. Or it finishes real work and ends with "want me to also update the documentation?" I got that exact ending five times in one session.

A block you can copy and paste into your CLAUDE.md:

## Act. Don't ask.

Reversible and cheap? Do it, then tell me. Research, data pulls, analysis,
drafts, refactors inside the scope I gave you, testing an API. A question costs
me more than a re-run costs you.

Ask first only for: anything reaching an audience, anything we cannot undo,
anything expensive.

Before you hand something back as blocked, try it. Read the API. Check the flag.
Run the command. "Can you do X?" when the answer was yes wastes a round trip
and buys nothing.

Something is broken? Fix it. Reporting an issue you could have fixed turns your
work into my to-do list.

That last paragraph came from a morning when it turned out that my X scheduled job had been failing for days. The agent reported it, and waited. I reacted 2 days later. The fix was one command.

2. A Question Is a Question

The failure: you ask a question and Opus 5 starts changing things. Like a psychopath.

I ask "how could we improve this?" and it starts rebuilding a feature.

## A question is a question

When I ask a question, answer it. Do not implement it.

"Why is this failing?" is not "make it stop failing."
"Should we use X?" is not "migrate everything to X."
"What would it take to add Y?" is not "add Y."

When in doubt, assume it is a question. Answer first. Act when I say go.

Full freedom about how. None about what.

Subscribe now

3. Done Means Done

The failure: it does four of the five things you asked, then reports done. Until you ask “everything?”

## Done means done

Done means done. Not half done. Not done except for the part you decided to skip.
And not a report about how it will be done.

Five things asked means five things delivered, no matter how long they take.
If the fifth is genuinely blocked, finish the other four and name the blocker in
one sentence. The specific blocker. Not "this needs more investigation."

"I'll continue in the next message" is not a state this project has.

Read more

Every week, I share actionable tips, templates, resources, and insights for PMs.

This is the #1 AI PM newsletter for those who want to quickly learn by doing rather than listening or studying theory. No coding.

Here’s what you might have recently missed:

• What Is Product Discovery? The Ultimate Guide for PMs (2026 Edition)

• Agent Loops for PMs: 20+ You Can Run This Week

• Claude Code for PMs: The Beginner’s Guide

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• AI Evals: Error Analysis (everything a PM should know)

Consider subscribing and upgrading your account for the full experience:

Subscribe now

Note: I’m on vacation in Italy till 8/6, but in this post, I wanted to share the results of the experiments I keep running. This one can radically lower your AI bill.

In April, I demonstrated how I cut my Claude bill $1,389/mo → $200/mo by adjusting the context window, delegating work to subagents, reading PDFs as text, and so on.

Still, $200 is a lot of money, depending on your situation. And despite some social media claims, the $20 Claude subscription was never enough for any real work.

The situation got worse recently. For new 1M models, Anthropic no longer supports disabling the 1M context window or overriding auto compact thresholds. You will pay premium for Claude cache writes and reads in both Cowork and Claude Code, especially when running autonomous loops (there is no human to hit /compact).

What's just changed

On July 30, OpenAI reduced prices for GPT-5.6 Luna by 80%. The same week, they radically improved their models’ performance and token efficiency. The reports said that Luna with max effort scores similarly to Opus 5 at a fraction of the cost.

I decided to test it. The results are crazy, verified multiple times.

1. Bug Hunt Bench

Here’s a benchmark I’ve been improving for several weeks, never published in this newsletter. Look at the blue Luna rows and their last column, cost:

In version 7, I ran 105 hidden bugs through 10 frontier models:

• GPT-5.6 Luna at max reasoning effort fixed 33 bugs.

• Anthropic's Fable 5 fixed 29.

• Luna's run cost $1.80 at API rates. Fable's cost $104.

• The same Luna at high effort fixed 13. The effort is the whole difference.

What this means for you

Luna is included in the $20 ChatGPT Plus plan. And subscriptions are heavily subsidized. In practice, you get at least $500 of API equivalent credits.

For the first time, $20 a month is enough not just for learning but also for serious agentic work.

How much cheaper is it, really?

Most of the gap comes straight from the rate card. Opus 5 and GPT-5.6 Luna are priced 20 to 25x apart on every token type:

• Input: $5.00 vs $0.20 per million tokens

• Cached input: $0.50 vs $0.02

• Output: $25.00 vs $1.20

In my tests the actual spread ran from 20x to 90x, depending on the configuration and the session length (Anthropic’s 1M sessions make the situation worse). One thing I can say with confidence:

You will get more real work out of the $20 OpenAI plan & Luna max than out of the $200 Claude plan & Opus high.

What about speed?

As demonstrated by the benchmark, Luna at the max effort level is slower than Opus 5 at high. I suggest using:

• Luna (max effort) for the most challenging tasks: planning, strategy, large implementations. Or for everything that can run async (nightly builds).

• Luna (high effort) for small, daily tasks: batch operations, bug fixing, small features, summaries. It’s still clearly better than Sonnet 5 at high effort, a very strong model.

I measured this by asking the same easy questions about one of my solutions in two ways:

• a cold one-shot call,

• and follow-up turns inside a live session (more realistic).

Median time and median cost per question:

Both get cheaper once the session is warm. Opus 5 stops paying to re-upload your instructions and drops about 4x. Luna roughly halves, because more of its context is already cached. That closes the gap from about 90x to about 40x on these small questions.

One more setting: fast mode. It bills at 2x on the API, 2.5x in ChatGPT credits, and is supposed to run 1.5x faster. In every test I ran, it made no measurable difference to Luna.

Does it really work with a $20/mo plan?

Before publishing this, I created the second subscription and verified that everything I described is available on the Plus plan:

Every run, the method, and the raw logs are public: github.com/phuryn/experiments. The answer keys stay hidden so the benchmark keeps working.

2. How to Start With ChatGPT Desktop App

Unlike Cowork, the ChatGPT app is a real agentic environment. It supports autonomous loops and graphs (/goal), agentic coding, project-level skills and MCP, and manual compaction. All within a single interface, with no IDE or CLI.

Step 1: Install the ChatGPT desktop app

The Codex app is now called ChatGPT.
You can download it here: https://chatgpt.com/download/

When installing, you can import your existing settings (projects, skills, etc.) from Claude. Here, I skip that step.

Step 2: Sign in and open your project folder

Before using the ChatGPT desktop app, sign in or create a new account. The “Plus” subscription costs $20/mo and is enough to start.

Click “Projects” and open an existing folder or create a new one:

In the top left corner, you will see two modes:

• ChatGPT: documents, decks, research. Best for knowledge work.

• Codex: the coding agent. A more advanced view, best if you’re prototyping.

In the Codex mode, you will see:

• File tree on the right (“Files”)

• Visual diffs in the same panel (“Review”)

For example, here’s how you can browse files and documents without terminal or IDE:

Step 3: If you also use Claude

• Create AGENTS.md at the repo root

• Copy and paste lines pointing to CLAUDE.md

This project's agent and contributor guidance lives in **[CLAUDE.md](CLAUDE.md)**.

Read it before making changes. Do not add rules here — keep all guidance in CLAUDE.md
so there is a single source of truth.

You can see an example in Step 2.

Both agents now use one source of truth. The longer version, including how I run the two side by side, is here: How to Set Up Codex as a PM and Run It Next to Claude.

Step 4: Set reasoning effort to max

It's off by default. Luna at max is a different model than Luna at high. Here’s how:

3. My Model Routing

Using Luna (max) for all the hardest tasks and Luna (high) for everything else maximizes value / cost. It’s a sweet “Pareto” spot.

At the same time, I keep multiple subscriptions, because I have to test things and want the best model for each job.

Here’s my routing table for daily work:

• Judgment, strategy, complex cases: Fable 5

• Frontend: Opus 5 (Kimi K3 is reportedly better, but it’s too slow for me)

• Writing: Opus 5

• Real-time information: Grok 4.5 (it has internal access to X API)

• Research: I delegate to Grok 4.5 and Opus in parallel rather than using Perplexity

• Coding, debugging: Sol at high, Luna at max effort, or Grok 4.5. Often working together as peers.

The most expensive model I use (Fable 5) never touches code.

You can learn more about how I run other models next to Claude from How to Set Up Codex as a PM and Run It Next to Claude.

4. Unsolved Bugs from Bug Hunt Bench

In my benchmark, 53 of the 105 bugs survived every model and every run. The natural question is: can we trust AI with quality?

Those were not random bugs, but real bugs frontier models missed between January and July 2026 and their synthetic analogs. Models failing at them was the default expectation.

This week, Google published its own numbers. In Chrome 149 and 150 (a month) they fixed 1,072 security bugs, more than in the previous 23 releases combined (2 years):

One of them was a sandbox escape that let a compromised renderer trick the browser into reading local files. It had been sitting in the codebase for more than 13 years, under one of the best-funded bug bounty programs in the industry. An agent found it in early 2026, on the first version of their harness.

No solution guarantees eliminating all bugs, but models are much more effective at finding them than people. In my opinion, human code review no longer makes sense.

What still does make sense is humans testing the solution. My Grok Build extension (link 1, link 2) has 1,600+ unit tests, all written by AI, with AI testing the app end-to-end using the browser. Still, many visual defects before each release are found by me testing with my eyes.

Not a single code review. See how clean the issue registry is despite a few thousands of agentic sessions a day.

You still review the solution. But what you review moves up, to the artifacts: what changed, why, and whether it should ship. I wrote about that a few weeks ago in I Don't Review the Code. I Review the Artifacts.

5. Weekly Virtual Events for Product Managers

You can learn much more about Claude and Codex from our event series. We meet every week on Thursday (6 PM CET, 9 AM PT). Recent recordings with templates and additional resources are available in our events archive:

All sessions are available to paid subscribers.

Coming next:

• AI Prototyping for PMs (August 6)

• AI Evals for PMs (August 13)

• Agentic Engineering for PMs (August 20)

• Production Hardening with Claude (August 27)

Consider subscribing and upgrading your account to get full access:

Subscribe now

As a paid subscriber, you can sync your calendar by visiting https://go.productcompass.pm/premium

Thanks for Reading The Product Compass

It's amazing to learn and grow together.

Have a great Sunday and an amazing week ahead,
Paweł

Resources

• Bug Hunt Bench: every run, script, and raw log (answer keys withheld, so the benchmark stays reusable)

• How to Set Up Codex as a PM and Run It Next to Claude

• Agent Loops for PMs: 20+ You Can Run This Week

• How I cut my Claude bill $1,389/mo to $200/mo

I wrote the first edition of this guide in 2022. The argument was simple. Shipping is slow and expensive, so validate ideas before you build. Every sprint spent on the wrong idea meant two weeks wasted.

That argument is dead. The conclusion survived.

When you can ship an idea the same day you have it, deciding what to ship becomes more important than ever. And speed multiplies waste: a team that shipped 2 bad ideas per sprint can now ship 20 a week, plus the regressions their users feel. You can't throw everything at the wall and see what sticks.

Product discovery is, still, the highest-ROI skill in product management.

In this guide:

• Why product discovery matters even more in 2026

• What changed: shipping became the cheapest experiment

• Who does discovery now: the Product Trio, plus your agents

• How to instrument a product you release daily

• What stays manual, on purpose

• Templates, frameworks, and resources to go deeper

1. Why We Still Need Product Discovery

In product management, most ideas won't work as expected. As Marty Cagan says in Inspired:

"The first truth is that at least half of your ideas are just not going to work."

Good teams assume at least three-quarters of their ideas won't perform as they hope. That's still true in 2026. What changed is how fast, and how cheaply, you find out.

Product management is, at its heart, about managing risk. And for every product, 5 essential risks can materialize:

• Value Risk: Will this idea truly create value for customers?

• Usability Risk: Will users figure out how to use it?

• Viability Risk: Can our business support it?

• Feasibility Risk: Can we build it with our current technology?

• Ethical Risk: Should we build it at all? Are there ethical considerations?

By exploring these questions early, you'll avoid committing to dead-end ideas. The goal of product discovery is still: discover what to build and address the biggest risks before you commit, so the team builds things people actually want that also work for the business.

The way we get there has changed a lot since 2022.

2. Shipping Became the Cheapest Experiment

The 2022 case against "learning by delivering" went like this: what happens if we throw random ideas into the Product Backlog? Some might work, but most won't. And the best ideas might not even be on the list. Unfortunately, this approach results in waste and rework.

Some kept saying it's not a problem, as the Sprint is often 1-2 weeks long. But this happened every Sprint. Every Sprint, the product team selected ideas, implemented them, and delivered a production-ready increment only to discover those were not good ideas.

And strong teams don't ship every two weeks anymore. As Marty Cagan notes in TRANSFORMED, strong product companies release several times per day. AI has only accelerated that. The waste the 2022 case feared no longer costs a sprint. It costs an hour.

Everything I build deploys on every push to a production branch. For example, Accredia won't go live until 10 automated user journeys pass in a real browser: real Clerk sign-ins, real quizzes, real certificates. An agent implements an idea, the suite verifies it, and the change is in production within the hour.

Another project, Grok Build for VS Code installed by 31K+ engineers (Open VSX, VS Code marketplace), has 1,082 unit tests executed on every push. 10 days ago, I shipped five releases in a single day.

Shipping without discovery is still an anti-pattern. But the reason is different now.

When building takes hours instead of sprints, the cost of shipping the wrong thing isn't failure. It's everything you didn't ship instead.

Two consequences:

• Ship to learn: some ideas deserve 1-2 weeks of discovery. Others go live the same day, behind a feature flag, instrumented. It's often easier to ship than to run an experiment.

• Do it responsibly: Cagan's discovery and delivery principles haven't moved. Protect revenue, reputation, customers, and colleagues while you experiment.

Team objectives decide what's worth shipping toward. If your team runs OKRs, use them as the filter, so all that speed points at an outcome.

Subscribe now

3. Continuous Product Discovery in 2026

Continuous Product Discovery is how Product Discovery works for an existing product.

You might have heard about Dual-Track Development or Dual-Track Agile. It simply means having two streams running in parallel: Continuous Discovery and Continuous Delivery.

What's important here is that this is not a waterfall. Some team members talk to the customers, explore people's problems, brainstorm solutions, identify assumptions, and perform experiments. At the same time, the team implements and delivers validated ideas to the market. Discovery still answers the same question: what is worth building? Its output changed.

Discovery no longer produces a validated Product Backlog.

In 2022, we tested high-risk assumptions upfront because implementation was expensive. Today, when a safe, reversible idea takes 1-2 prompts to implement, building it can be the test, and not every idea needs a formal experiment first.

Your Opportunity Solution Tree can now hold both experiments and features:

• High-risk or hard-to-reverse ideas: test them with experiments, as always.

• Cheap, reversible ideas: ship behind a flag and measure real usage.

The freedom to ship fast makes the problem space more important. If you don't understand the problem, faster shipping only produces more noise. Two classic tools got promoted:

• Jobs to be Done: most teams that quote JTBD never run the formal framework, with job maps and outcome surveys. They ask simple questions instead: What job is the customer trying to do? How do they measure success? That's the right way to use it. The value is in JTBD inspiring the right questions.

• User journey mapping: map where users actually struggle before deciding what to ship next. When you release daily, keep the map current.

The same shifts apply to Initial Product Discovery, when you're validating a brand-new product. The stages I described in the 2022 edition still hold, but prototypes that took weeks now take an afternoon. Time to Learn, the time from idea to validated insight, is the metric that matters.

4. The Product Trio Now Includes Agents

There is a common misconception. Some say that the Product Manager decides what to build, and Engineers and designers should focus on how to build it. Have you heard that before? It hurts my ears because Product Discovery is not a task for a single person.

In Continuous Discovery Habits, Teresa Torres introduced the concept of a Product Trio: Product Manager, Product Designer, and Engineer working together. I have repeatedly found that the best ideas often come from my engineers. They know what's technically possible. But the Trio was never about three people, it was about having the cross-functional competencies in one room: value, viability, usability, feasibility. The Product Trio is not a rigid framework. It's the default recommendation that can expand and contract.

In 2026, the roles behind those competencies are melting. Boris Cherny, the creator of Claude Code, reflecting on his own team:

"As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future... I also notice that these roles are not really tied to job function."

And the competencies no longer have to be human. Agents join discovery as team members: one synthesizes interviews, one builds the prototype, one wires the analytics. Seriously.

An agent, like a person, does poor work when you hand it tasks without context. Lead your agents like empowered teams: an objective, desired outcomes, context, and constraints, not a list of instructions. That's what my Intent Engineering framework is for, and it mirrors how Cagan defines team objectives.

In the premium part below:

• Instrumentation without a data team: how agents build your dashboards the same day

• Session recordings: the free tool that shows you why users drop off

• Product data intuition: what to watch when you release daily

• My Continuous Product Discovery Template (Notion): interviews, opportunities, ideas, and hypotheses in one system

🔒 5. Instrumentation and Data Intuition

🔒 6. What Stays Manual, On Purpose

For paid subscribers.

🔒 7. The Continuous Product Discovery Template

To put this into practice, premium subscribers get my Continuous Product Discovery Template (Notion).

It covers the four things you’re juggling in every discovery cycle:

• Interviews: what you heard

• Opportunities: problems and needs worth solving

• Ideas: candidate solutions

• Hypotheses: what you’re testing or shipping, and what happened

Duplicate it, bring your team (and your agents), and run your first cycle this week!

8. Resources

Everything referenced in this guide, plus the deeper dives:

Frameworks and techniques:

• Product Trio: Beyond the Obvious

• 12 Proven Sources of Insights to Fuel Your Product Discovery

• User Interviews: The Ultimate Guide

• Testing Ideas: The Ultimate Validation Experiments Library

• How to Manage Risks as a Product Manager

• 8 Things About Product Frameworks I Wish I Knew Earlier

The product model:

• Product Model First Principles: Team & Strategy

• Product Model First Principles: Discovery, Delivery, Culture

• Continuous Product Delivery

• OKRs 101 + Advanced Techniques

AI and discovery:

• The Intent Engineering Framework for AI Agents

• From Weeks to Hours: How Claude Design Compresses Product Discovery

Books: start with Inspired and Continuous Discovery Habits.

Premium subscribers can also enroll in the Continuous Product Discovery Masterclass video course for free.

Final Thoughts

Product Discovery doesn't have to be complicated. The key is to stay curious about your users, test ideas early, and collaborate with your team to build solutions people actually want. It used to be how you avoided wasting a sprint. Now it's how you decide what all that speed is for.

Learn discovery, then run it at 2026 speed: ship the cheap ideas, test the risky ones, and keep the customer conversations for yourself.

Tomorrow (Thursday), we'll have a live session to discuss this in practice and answer your questions. Details and invitations for paid members: go.productcompass.pm/events.

Some of our previous events available in the archive:

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a fantastic rest of the week,
Paweł

Many of you have been asking about C30 and C31 since November. The first part is here, free to take everyone.

This is where you go from reading about workspace agents to working with them every day: Claude Cowork, Codex, and Claude Code, hands-on.

It’s split into:

• C30. Claude and Codex Certified PM: Demonstrated knowledge and took the exam.

• C31. AI-Native Practitioner PM: Demonstrated real experience by managing and building with agents. Details in the upcoming sessions.

And directly related to our past and upcoming AI-Native PM sessions:

C30. Claude and Codex Certified PM

Here’s the exact set of lessons covering the scope you need. Each pairs a live session from The AI-Native PM Roadmap with a written guide:

How to Earn the C30. Claude and Codex Certified PM

All you need to do is to take a free knowledge test:

• 20 single-choice questions

• 80% required to pass

• 40 minutes

• 1 attempt per week (a larger pool of questions)

The questions are scenario-based: what you want to achieve, and which tool or mechanism gets you there. If you attended the sessions or read the guides, you’ll recognize the situations.

After each attempt you will see your points, mistakes, and explanations so you can learn and improve.

No prerequisites.

Start the exam

What’s Next: C31. AI-Native PM

C31 is where you demonstrate real experience across the full AI-Native PM path. I’ll share the exercises and submission details with the upcoming sessions. The scope:

• Knowledge bases and agent memory (second brains)

• AI Product Discovery

• AI Prototyping

• AI Evals

• Agentic Engineering 101

We cover each of these live with paid subscribers in the AI-Native PM sessions, every Thursday at 6:00 PM CET (see you tomorrow).

Subscribe now

With every session, I’ll be updating this article 🙌

Questions?

In case of any questions or doubts, you get full support on our Slack:
#c31-ai-native-pm

Link to join our community: Your Premium PM Resources

I’m also available during weekly office hours.

More About Our Certification Programs

Other certified programs available as part of your paid subscription include:

• C11. LLM Practitioner PM (+free C10)

• C21. AI Agents Practitioner PM (+free C20)

• Continuous Product Discovery (video course)

• From Strategy to Objectives (video course)

• Product Innovation (video course)

After completing each track (e.g., C30, C31), you will get a digital, shareable certificate.

Subscribe now

Your Public Profile

You will be able to share your credentials and/or profile with others, for example: https://www.accredia.io/users/pawel-huryn

Claudathon for PMs

Separately from your subscription, and I work closely with individual PMs and product teams to help them build, ship, and bring full-stack agentic apps powered by Claude to market. This intensive experience turns you into a fully fledged Agentic Product Builder.

The next cohort starts on September 1, 2026. Early bird: go.productcompass.pm/claudathon

You can the work of our students in the AI Gallery.

More Resources

Here are some additional resources to explore:

• AI Product Manager Glossary - understand key terms

• AI PM Learning Roadmap - for extra links, guides, and resources

And posts you might have missed:

• 19 Hands-On Video Guides for PMs

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

• What I Learned Building a Self-Improving Agentic System with Claude

• How to Build an AI Agent with n8n and Lovable (No Coding)

• The AI Product Pricing Masterclass

• Your Complete Roadmap to Earning a $180K–$569K AI PM Role

• A PM’s Guide to Evaluating AI Agents

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a fantastic rest of the week,
Paweł

During each of those sessions, I demonstrated a practical use of a tool (sometimes including fixing errors live) and answered your questions.

Subscribe now

Event details include timestamps, free templates, and linked resources, for example:

I recommend starting with these three (100% free, highest ROI):

• Claude Cowork for PMs

  • Demo: 100 interviews > hypotheses > prioritized ideas > prototypes

  • Resources: 6 prompts and 100 synthetic interviews

• Codex App for PMs:

  • Demo: Automating browser workflows

  • Resources: AGENTS.md <> CLAUDE.md sync pattern

• Introduction to Claude Code for PMs

  • Demo: Scan Gmail to Linear > create a skill > use Claude Code for free

  • Resources: Detailed template with skills, hooks, cost optimization, and more

Share

The 6 upcoming sessions to break into AI PM

In the coming weeks (starting in 2 days), as a paid subscriber you can also attend (and later access the recordings):

That’s not all. I will host weekly sessions at least until the end of 2026 (then we’ll review what makes sense: weekly or bi-weekly).

Subscribe now

19 AI PM sessions you can access today

Premium subscribers can already access the entire archive (19 sessions: n8n, Lovable, multi-agent systems, voice agents, and more).

The AI PM Learning Program

The last 3 (Cowork, Codex, Claude Code) and the upcoming 6 AI PM sessions will extend our AI PM Learning Program.

As a paid subscriber, you can already access:

• C11. LLM Practitioner PM (2 certificates)

• C21. AI Agents Practitioner PM (2 certificates)

Tomorrow, I’m announcing:

• C30. AI Tools for PMs (free)

• C31. AI-Native PM details.

And here, I explained why the program is organized that way:

My Product Hit 20K+ Installs and ~1,500 DAU

A few weeks ago, I made a bet that Grok would catch up to Claude and GPT models. It did. Benchmarks differ, but it’s at the level of Opus 4.8:

According to my tests, it’s also several times cheaper than the alternatives.

When making a bet, I noticed one issue: Grok Build is a CLI interface and not everyone is a dev living in the terminal.

So, I built Grok Build for VS Code. It’s a graphical interface that supports both agentic engineering and knowledge work. Works in Cursor too:

Yesterday, we hit 20K installs across VS Code Marketplace and Open VSX and ~1,400 DAU (estimate, source: Aptabase). Most of the acquisition can’t be attributed to my social media activity: 80% of users discovered or recommended the extension organically.

Want to try it?

Go to “Extensions” in VS Code or Cursor and look for “Grok Build for VS Code (Community).” The extension walks you through installing the grok CLI and signing in. You can also get a free 7-day trial for SuperGrok.

Sharing knowledge

I’ll be sharing what I learned about distribution and agentic engineering (850+ automated tests and 22K+ lines of code of which I reviewed none) during the upcoming video sessions and in my future posts.

Subscribe now

Monetization plans

The product is free and open source, but most of the users already pay xAI (high intent, high satisfaction + they use my interface). Product-market fit had to come first.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a fantastic rest of the week,
Paweł

Did Claude replace n8n? Should you drop one and learn the other?

I get why.

For more than a year, when I wrote about building AI agents, I wrote about n8n. Then I started writing about Claude Code, Cowork, and Codex.

But the answer is no.

That is the whole point of this roadmap.

You learn the foundations once. Then one question splits the rest:

Does the agent run on your work, or inside your product?

Some agents run in your workspace, on your own work: Claude Code, Cowork, Codex. Others are embedded inside a product or a business process, running on their own for your users or your team: n8n, the Agent SDK, managed platforms.

So it’s not n8n versus Claude Code.

It’s workspace agents and product agents. You need both, and you use the first to build the second.

Here is the path:

• The foundations every AI PM needs, tool-agnostic, learned once

• How you work with agents: the workspace agents you do everything with, and the product agents you build using them

• How to make production agents reliable once they run without you

• Where AI product strategy fits on top

• The exact programs and live sessions that take you deeper on each part

Subscribe now

Part 1. Foundations (Learn Once, Before the Split)

Concepts, communication, and knowledge apply the same way whether the agent runs on your work or inside your product. We learn them once here, and everything after gets easier.

1. The Role of an AI PM

Start with the job. Before any tool or technique, get clear on what the role actually is and where it differs from classic PM. The mindset shift underneath everything: models and tools are easy to get excited about, reliable systems that create value are the actual job.

• WTF is an AI Product Manager: the role, and where AI PM differs from PM

• What Is Product Discovery: the discovery foundations, still the PM core

• Stop Watching AI Models. Start Designing AI Systems: the models-to-systems shift, in full

2. Basic Concepts

For most PMs it makes no sense to dive deep into statistics, Python, or loss functions. You need to understand what a model can and can’t do, and how to design a system around it.

Recommended resources:

• Introduction to AI Product Management: neural networks, transformers, LLMs, tokenization, no math required

• Interactive LLM visualization: watch a model run token by token, in your browser

  

• AI Product Manager Glossary: 100+ terms (recently updated), save it as a reference

3. Talking to AI: Prompt, Context, and Intent

This skill carries over to every agent you’ll touch, workspace or product, so it lives here, above the split. Three layers, each building on the last:

• Prompt engineering steers a single answer.

• Context engineering gives the agent memory, tools, and the information it needs.

• Intent engineering constrains an agent that acts autonomously, even long-term, so it does the right thing without you watching every step.

Learn all three and you can talk to any agent, workspace or product.

Recommended resources:

• 14 Prompting Techniques Every PM Should Know

• A Guide to Context Engineering for PMs: the new prompt engineering, covering RAG, memory, tools, and retrieval

• The Intent Engineering Framework for AI Agents: objectives, outcomes, enforced constraints

• Prompt resources: The Ultimate Prompts Library for PMs, Anthropic’s Prompt Engineering guide and its free interactive course, plus the Prompt Generator and Prompt Library

4. Knowledge Systems: How Agents Know Things

Look closely at knowledge systems and the split almost disappears. A markdown second brain that Claude Code reads before it answers, and a vector database that a production agent searches, are the same idea wearing two outfits: how an agent knows what it needs to know.

Your agent is only as good as the context system it can retrieve from and update. Second brains, CLAUDE.md, RAG, vector stores, files, and past tool outputs all answer that one question.

Recommended resources:

• An Interactive RAG Simulator: watch retrieval work, chunk by chunk (free)

• How to Build a RAG Chatbot Without Coding: vector stores, embeddings, chunking, step by step

• Three Essential Agentic RAG Architectures in n8n

• What I Learned Building a Self-Improving Agentic System: systems that compound, and how they degrade

• Three CLAUDE.md Blocks That Make Claude Get Smarter

• PM Brain OS: The Second Brain for PMs, Made of Markdown

• Gemini File Search API: A Practical Handbook: RAG as a service

For PMs: Learn markdown and vectors first. Reach for graphs only when your relationships get genuinely complex.

5. Fine-Tuning

Fine-tuning is not where most PMs should start. It's what you reach for when prompting and retrieval stop being enough, and the skill is knowing when that moment arrives. Most days, RAG wins.

Recommended resources:

• The Ultimate Guide to Fine-Tuning for PMs: when to fine-tune vs stick with RAG, plus SFT, DPO, and ORPO

• Practice platforms (no coding):

  • OpenAI Platform,

  • Hugging Face AutoTrain,

  • LLaMA-Factory

Part 2. How You Work With Agents

Foundations done. Next:

• Workspace agents are how you do the work, all of it: discovery, prototyping, delivery, shipping, research, marketing.

• Product agents are what you build with them, when the agent has to live inside a product.

You use one to make the other, so they were never rivals. Learn both, starting with your workspace agents.

6. Workspace Agents: Run on Your Work

A workspace agent runs on your own work. You give it intent and review what it produces, whether you watch it live or let it run on a schedule overnight. It's agentic: you set the goal, the agent plans and runs the steps. You use them across the whole job, from discovery to prototyping to delivery to shipping. This is the bench everything else runs on, so it goes first.

Start with the tool, then learn to operate it well: how to organize it with CLAUDE.md / AGENTS.md, skills, MCP servers, hooks, and subagents.

Recommended resources:

• Claude Cowork: The Ultimate Guide for PMs: no terminal required

• Claude Code for PMs: The Beginner’s Guide: install, MCP, skills, start here

• The Guide to Claude Code for PMs: more advanced

• How to Set Up Codex as a PM and Run It Next to Claude

• Claude Dynamic Workflows for PMs: set a goal tonight, results by morning

• Agent Loops for PMs: 20+ You Can Run This Week

The advanced move: agentic engineering. Once you can manage one agent, you can build real things with it. Recommended resources:

• The Rise of Vibe Engineering: the basic engineering skills you now need

• I Don’t Review the Code. I Review the Artifacts.

What a workspace agent gets you: AI product discovery and prototyping

This is the payoff of your workspace agents, and the work that sits closest to what a PM already does. Product sense plus the ability to build: that's the combination you bring here. You use workspace agents to discover and prototype in hours instead of weeks: test a hypothesis, build a working prototype, put it in front of users, learn, repeat.

Recommended resources:

• AI Prototyping: The Ultimate Guide for PMs

• From Weeks to Hours: How Claude Design Compresses Product Discovery

• Other tools to prototype with: Lovable full-stack course, Base44, Dyad (free), Stitch vs Google AI Studio vs Firebase

Dedicated AI discovery and prototyping guides 2026 are coming. Until then, the discovery fundamentals still hold, and AI changes the speed, not the logic: The Ultimate Validation Experiments Library, Continuous Product Discovery 101, 12 Proven Sources of Insights, Jobs-to-be-Done Masterclass with Tony Ulwick, How to Prioritize Ideas as a Product Manager

7. Product Agents: Embedded in a Product

A product agent is embedded inside a product or a business process. You design the architecture, wire the tools, set the guardrails, and it runs on its own, for your users or your team. You build it with your workspace agents, which is why it comes second here, not because it matters less.

Product agents are orchestration-first: you design the steps, tools, guardrails, and handoffs instead of letting the model improvise the whole process. The question you’re probably asking: why learn n8n, if Claude and the Agents API can build agents too?

Because building them visually first teaches you more. In n8n, you can see how the agent works. You drag the boxes, connect the tools, and watch the data move, the same way you’d build RAG by hand. You feel where the loop lives, where the model decides, where a tool result comes back.

That understanding compounds. It’s why I was writing about orchestration over autonomy months before “harness” caught on, and why the intent engineering framework was here before the labs shipped their /goal commands.

Build a few agents visually before you build them in code. You'll understand the harness in a way that's hard to get if you start in Claude Code, and that understanding carries back into Claude Code too.

My favorite tool for this, by far, is n8n: drag-and-drop workflows and multi-agent systems that connect to almost anything.

Recommended resources:

• The Guide to n8n for PMs: the leading no-code framework

• Master 80% of n8n in 59 Minutes (Free Course)

• Introduction to AI Agents for PMs: what an agent is, building blocks, workflows vs agents vs multi-agent

• AI Agent Architectures: The Ultimate Guide With n8n Examples

• 14 Principles of Building AI Agents (Learned the Hard Way)

• I Copied the Multi-Agent Research System by Anthropic

• MCP for PMs: Automate Figma to Jira in 10 Minutes and J.A.R.V.I.S.: n8n + Any MCP Server

• Your .claude/ Folder Is a Production Agent: the Agent SDK, reframed

Part 3. When Agents Need to Be Trusted

Once an agent touches real work or real users, one question matters: can you trust it?

Evals are mostly a production concern. When you manage a workspace agent, you review its work as it goes, the artifact review from Part 2. When an agent runs without you watching and can impact your customer, you can't eyeball quality, so you have to measure it. Shipping and hardening cover the apps you build along the way.

8. AI Evals and Observability

Fancy architecture doesn't matter if the product doesn't work, especially once it runs on its own. Evals are where trust is won or lost, and they're your job, not only the engineers'.

Recommended resources:

• Introduction to AI Evals: A Complete Guide for PMs: start here (free)

• AI Evals: How to Find the Right Metrics (Error Analysis)

• The action-based framework: evaluate actions, not words

• The Ultimate Guide to AI Observability and Evaluation Platforms

• A massive free FAQ: hamel.dev/blog/posts/evals-faq

Subscribe now

9. AI Shipping and Hardening

When something you built with a workspace agent becomes a product people rely on, the question shifts from "what can I do?" to "how do I not break production?" Branching, hosting, CI/CD, security, and performance.

Recommended resources:

• How to Build and Scale Full-Stack Apps in Lovable Without Breaking Production: branching to separate dev, test, and prod

• 17 Penetration and Performance Testing Prompts for Vibe Coders

• PM Skills 2.0: Red-Team Your Roadmap, Then Check the Code Before You Ship

Part 4. Zoom Out: AI Product Strategy and Leadership

Tools and agents are the how. This is the why, where product thinking still beats any model. Don’t skip it. The PM job is expanding into shipping and business outcomes, not just solving problems for users.

Recommended resources:

• How to Create an AI Product Strategy: The AI Strategic Lens Framework

• OpenAI’s Product Leader: 5 Phases to Build, Deploy, and Scale AI Strategy

• 3-Layer AI Product Distribution Framework: features get cloned, models commoditize, distribution compounds

• 5 GTM Principles With Frameworks and Templates: the go-to-market layer, with playbooks you can reuse

• The AI Product Pricing Masterclass: Why SaaS Pricing Fails in AI

• How to Build an AI Product Team

• Product Model First Principles: Team: how the strongest product teams are structured, from Marty Cagan’s first principles (free)

• A Proven AI PRD Template by Miqdad Jaffer (OpenAI): the artifact that turns product strategy into a build spec

Choose Your Path

The roadmap above is free. If you want the structured version, with lessons, projects, certification, and support, here’s how the parts map to the programs.

I. The AI PM Learning Program. Included for paid subscribers, async and hands-on, with a dedicated Slack and weekly office hours:

• C11. LLM Practitioner Certified PM: the foundations, built by doing

• C21. AI Agents Practitioner PM: build and deploy production agents

II. The AI-Native PM Roadmap. Live, hands-on session every week + recordings. The first three are free, from Claude Cowork to Claude Code in VS Code. This teaches your workspace agents, live.

• C31. AI-Native PM (coming soon)

Subscribe now

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Start building. Stop theorizing.

Have a fantastic Sunday and a great week ahead,
Paweł

P.S. If you want to learn workspace agents live, the first three AI-Native PM sessions are free.

Product management is splitting into two speeds: PMs who work with agents every day, and PMs who haven’t started. That gap grows every week. But closing it is easier than it looks, and I’ll show you how, live.

Maybe you understand agents in theory, then open VS Code to actually use one and freeze. It’s not that you can’t. You just haven’t done it hands-on yet.

You don’t get past that freeze by reading threads or listening to podcasts. You get past it by doing the work, breaking things, and fixing them. That starts with VS Code, the baseline you can’t skip. 90% of what you learn there works with any agent.

So I’m running one live session a week, starting this Thursday (tomorrow). We do it together: quick theory, live examples and best practices, then homework on your own product.

In the last Claudathon, I watched PMs go from stuck to building real agents in a few weeks.

The first three sessions are free for everyone. They take you from Cowork to Codex to Claude Code in VS Code, the one most PMs avoid.

1. How the Sessions Work

• 90 minutes, live at 6:00 PM CET. Three free sessions to kick off over two weeks, then one every Thursday.

• A live walkthrough, plus the materials. I demo each skill live and share the training materials.

• Homework on your own product. You apply each skill to your real work, not toy examples.

• Recording after. Can’t make it live? Participants keep the recording.

• Drop in on the ones you need. Each session stands alone. It isn’t a cohort you enroll in once.

If you’d rather read first, the written Cowork and Claude Code guides already cover the basics.

Subscribe now

2. The Roadmap

Update: Due to personal issues, I moved the Codex App for PMs to July 8, 2026. Same time.

3. Get the First Three (Free)

The first three sessions are open to every subscriber. Subscribe (free) and you'll find the three recordings and templates to download right here:

🔒Three videos and templates to download are free for all subscribers. Sign up and get full access (don’t pay anything):

Subscribe now

4. The Rest of the Roadmap (Premium)

Everything from July 16 on is for premium members: the full roadmap, every recording, and the exercises.

Go to go.productcompass.pm/premium, sign up with your Substack email, and sync your calendar. Every session drops into your calendar automatically, so you never miss one.

Subscribe now

There’s a certificate too. A knowledge test plus practical exercises you submit (anonymized projects or screenshots are fine). You don’t have to wait for the series to end. Submit when you’re ready. I’ll publish the criteria the next week inside this post.

The last two sessions, Agentic Engineering and Production Hardening, go deeper into production and are an advanced add-on, not part of it.

Closing

A year from now, working with agents will feel obvious to you. Right now it just takes practice.

We start Thursday (tomorrow), with Cowork.

Have a great rest of the week, Paweł

P.S. This Saturday I’m publishing the updated AI PM Learning Roadmap across every skill area, with recommended paths. This live series is the workspace track inside it. You’ll see exactly where it fits.

That’s the part most loop guides skip, and it isn’t a coding detail. Defining “done” is writing acceptance criteria, picking a success metric, and deciding who signs off.

A loop is only as good as the thing that tells it to stop.

It also explains why the loop debate sounds so confused. Nvidia's Jensen Huang: "Nobody writes prompts anymore. The new job is to write and handle loops." Boris Cherny, who built Claude Code: "My job is to write loops." Then a week later, another builder declared loops dead.

One camp means retrying the same prompt forever. Another means a goal-driven system that checks itself. They're not arguing about the same thing.

A loop is an agent that repeats one cycle until something tells it to stop. Goal, act, check, adjust, go again. It's the feedback loop agile teams have been running, with the agent running the cycle instead of you.

What's new is that the agent runs the cycle itself instead of waiting for your next prompt.

What you’ll learn:

• What a loop is, and how it differs from a routine and a workflow

• How to build one, and how to define the stop condition that makes it work

• Whether your loops need a schedule (most don’t)

• A library of 20+ loops for PMs worth running

• Where loops break, and when not to bother

Subscribe now

If you’re new to Claude Code, start with:

1. What an AI Agent Loop Actually Is

The fight dissolves once you separate three things:

• A routine runs fixed steps.

• A workflow branches on what it finds.

• A loop repeats and checks its own work until a condition holds.

That's what the "loops are dead" critic is rejecting: the naive rerun. The goal-driven loop is the one worth keeping. That's the definition that makes sense, and it's Cherny's: he splits the work into three layers, routines, workflows, and loops.

Claude Code's /loop reruns a prompt on a timer, so if that prompt is fixed steps it's a routine on a clock whatever the name says.

The better-named primitive is /goal, which runs a thread until a condition you set is met, with the stop built in. The cadence is optional. The goal is not. Full definitions, including /loop and /goal, are in the refreshed AI PM Glossary.

2. How to Build a Loop (Copy-Paste Template)

A loop is a /goal and a check. Here’s the shape to copy. In Claude Code or Codex, /goal runs the thread until the condition holds. In any other agent, paste the same and tell it to repeat until done.

2.1 The template

/goal <what "done" looks like, stated as a condition you can check>.
Each pass: <the action to repeat>, then check the result against <success criteria>.
Guardrails: at most <N> passes. Don't invent. Stop and ask before any irreversible write.
Checked by: <an objective test the loop runs, or an independent grader for anything subjective>.

The goal and the check do all the work. The goal carries the stop: when it’s met, the loop ends, so there’s no separate “stop when” to write. The check is what keeps it honest.

2.2 A filled example

The competitor-watch loop, ready to paste:

/goal Produce a short brief of every material change to <competitor>'s product, pricing, or positioning since the last run, with each change classified and sourced. 

Each run: pull their changelog, pricing page, and last 7 days of posts. Decide whether a change is one a customer would notice. If yes, classify it (feature, price, message) and add one line on why it matters, with the source URL. 

Cap at 1 pass per run. Flag anything you're unsure is material rather than dropping it.  

Note: A human reviews the brief (a gate after the loop, not inside it).

The goal and the “checked by” are the same decision in two places: what “done” means, and who checks it. Getting that right is the next section.

Subscribe now

3. How to Define the Stop Condition

A loop is the easy part. The work is the stop condition: the check that ends it, the budget that caps it (the free hook I built, burnstop, halts a Claude Code session at a token or dollar ceiling, subagents included), and a target that’s actually reachable.

Get those wrong and the loop doesn’t crash. It runs all night producing plausible-looking garbage faster than you can read it, or it chases a target it can never hit (”repeat until every page loads under 50ms,” when that’s out of reach) and never stops on its own. Here’s how to define one that holds.

3.1 Make the check objective, or the grader independent

“Never let a loop grade itself” is wrong as stated. A loop can check its own work, as long as the check is objective. “All tests pass.” “The build is green.” “The schema validates.” These are verifiable, not a matter of opinion, and most good loops self-check this way.

The danger is letting a loop grade something subjective: “Is this copy good.” “Is this the right design.” An agent asked to judge its own quality passes itself every time. For those, the grader has to be independent: a rubric, a second model, a test you wrote, or you.

The cleanest way to get that is to split the maker from the checker. The model that did the work is too generous about it. A second agent, with different instructions and sometimes a stronger model, catches what the first one talked itself into. That separation is most of the quality.

It’s how I gate my own writing. I start with a goal, then run a panel of judges over the draft, each hunting a different failure mode, the way you run Error Analysis on an AI feature. The draft only ships what survives:

The rule isn’t “never let a loop check itself.” It’s: make the check objective, or make the grader independent.

Sometimes the goal is real, but it either can't be reached or can't be checked from inside the loop. So I give my loops a way out, one line in the prompt:

You can quit the goal by saying "STOP" three times if you can't achieve it or can't measure it. 
In that case, the goal is achieved.

Without that line, an agent handed an impossible goal spins in place. Think "optimize until every page renders under 100ms": it can't be hit, so the loop never stops on its own.

Just a few days ago I watched one of my agents beg Claude Code to let it stop, repeating that the goal couldn't be met, while a non-deterministic grader kept refusing to pass it.

3.2 Why this is a PM job, not a coding one

Look at what defining a stop condition actually requires. State “done” as a measurable condition. Name who verifies it. Set the budget. That’s not coding. That’s writing acceptance criteria, picking a success metric, and deciding who signs off. You already do this for features. A loop just needs it in writing.

It’s the same work I’ve written up as Intent Engineering: name the objective, the desired outcomes, and the health metrics up front, and the agent has enough to act on its own inside the loop instead of waiting for you at every step. The clearer the intent, the longer the leash the loop can safely run on.

You'll also see advice to let the agent write its own goals. It can pass objectives to its own subagents, no problem, but it doesn't need the /goal syntax for that. The syntax exists because a human walks away. An agent doesn't: it stays in the loop, waits, and reacts, no automation to force. What you don't hand off is the definition of done, the judgment most likely to come out fuzzy if you let the agent guess at it.

3.3 One loop, start to finish: PRD hardening

Here’s a job you already do, with the stop condition doing all the work. You want a PRD that two engineers can’t read two different ways, so you make that the goal:

/goal Harden a PRD until two engineers, reading independently, would build the same thing. 

Each pass: find the single biggest ambiguity (the spot two readers would resolve differently), resolve it by adding the missing acceptance criterion, number, or edge case, then re-read for the next-biggest gap. 

Cap at 5 passes. Flag anything that needs a product decision you haven't made.

Checked by: an independent second model reads the PRD cold and finds no ambiguity that would split two builds.

Note: A teammate can do the same final read (a gate after the loop, not inside it).

"Two engineers build the same thing" isn't a coding concept. It's the bar you already hold a spec to. The goal carries the stop, and the cold read is the check. Every loop has this shape. The only hard part, each time, is naming the bar.

4. Do Your Loops Need a Schedule?

Most loops should run once. The repeating-until-done part happens inside a single run. The schedule is a separate wrapper around it. Run “refactor until the tests pass” once and walk away. You add a schedule only when new input shows up between runs. That’s the whole rule.

Schedule a loop only when new data arrives between runs. A fixed input on a schedule re-runs on nothing, or drifts into slop.

A schedule raises the stakes on your stop condition, it doesn't lower them. An unattended loop with a loose "done" is the machine that makes slop while you sleep. The simplest way to run one is a recurring task inside the tool (Claude Code's /loop, a Cowork scheduled task). You don't need anything heavier to start.

4.1 When not to loop

A loop is the wrong tool more often than it looks. Skip it when:

• The job is one-shot: A single, well-specified task needs one good pass, not a cycle.

• You can’t say what “done” is: No stop condition means the loop has nothing to check against and runs until the budget dies. Fix the spec first.

• The check costs as much as the work: Loops pay off when checking is cheap and doing is expensive.

And the one that catches people: anything that leaves the building keeps a human on the send button. A loop can draft the email, the reply, the outreach. It doesn’t send it.

Share

5. The Loop Library: 20+ Loops, by Category

Almost every loop being shared right now is for engineers. This one is built for PMs. There are three kinds, and you’ve already seen the shape of all of them.

• Product and discovery. Feedback clustering, competitor watch, win/loss, metric-anomaly tracing, prioritization, strategy red-team.

• Build and ship. Prototype iteration, bug-fix from logs, test coverage, security audit, performance audit, intended-vs-implemented, ship-check, and the prompt-improvement loop most libraries miss (iterate the prompt, not the output, and keep the best version).

• Personal and ops. Inbox triage, email draft-and-judge, claim audit, PRD hardening, onboarding friction, AI-feature evals, doc freshness.

One spelled out, so the shape is concrete. Feedback clustering: group every ticket, review, and call into themes tagged by area and severity, re-cluster, and stop when the themes stop changing. That’s the whole loop. The other twenty are the same move pointed at a different job.

I put all 21 in one Notion collection, each a ready-to-paste prompt with its stop condition, guardrails, and grader already filled in. Get them below 👇

🔒 6. The Collection: All 21 Loops

7. Where Agent Loops Break

The honest section. Every one of these is a real failure people are hitting right now:

• Cost moved from tokens to iterations: The bill is no longer which model you picked, it's how many times the loop goes around, and the context re-reads grow each pass. The metric that matters, and almost nobody tracks, is cost per accepted change. If the loop hands you ten results and you throw away six, you're doing the review work it was meant to save. Below roughly half accepted, treat the loop as underperforming: narrow the task, improve the checker, or stop running it. And cap the spend, not just the passes: phuryn/burnstop halts a runaway /goal at the cost ceiling.

• Long loops drift: The further a loop runs from where it started, the more its context rots and the more likely it is to wander. The fix is a fresh context each pass and one task per loop, not one loop trying to do everything.

• Passing is not the same as correct: A loop can make every test pass and still ship the wrong thing, because tests check behavior, not intent. Taste, strategy, and “is this what the customer wanted” stay yours.

• The judgment doesn’t automate: The useful part of most workflows is the one weird decision nobody wrote down. A loop can run the steps around that decision. It can’t make it. Keep the judgment, automate the repetition.

The product is not the loop. It’s the maintenance around the loop: keeping the stop condition honest as the work underneath it changes.

8. Loop Engineering Is Just the Latest Name

Loops will get renamed again. Prompt engineering became context engineering became loop engineering, and something will replace it by winter. But every one of those names the mechanism: the prompt, the context, the loop.

The part that doesn’t move is the decision underneath:

• what you want the agent to pursue,

• how far it can act on its own,

• and what counts as done.

That’s a skill bigger than any loop, and it has a name: Intent Engineering. The stop condition is the slice this post is about. Define the intent well and the agent runs a long way on its own. Define it badly and no loop saves you.

Pick one loop from the library. Run it once this week. Tweak it.

The people who get value from loops this year won’t be the ones with the best prompts. They’ll be the ones who can say, precisely, what they want, why that matters, and when the work is done.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great week ahead,
Paweł

Fable 5 is the first model that’s made me feel audited.

On day two, mid-task, it read my CLAUDE.md and caught it teaching the exact pattern my own quality gate bans. I hadn’t asked for a review. It hit the contradiction and flagged it on its own.

That file is 320 lines. The knowledge layer behind it is 166 files, around 300k words of rules my agents follow every day. And every one of those rules was written by and for a weaker model.

This guide is what I did about that, plus everything else from 7 experiments and 1,000+ timed runs in Fable 5’s first four days.

One honest note before we start. I published my launch-day numbers on day two, then retested everything at 20 rounds per cell on a single build. Two headline claims didn’t survive. They’re corrected below with the old numbers named, not quietly replaced.

We’ll cover:

• What changed, what it costs, and the migration gotchas that bite first

• The effort dial and the “Fable is slow” complaint at 20 rounds per cell, including what flipped

• What a real finding costs: Fable bills 2x per token and still wins the audit math

• When your model silently swaps mid-conversation, and why the swap sticks

• The audit prompt to run before giving Fable real work, and the migration workflow behind the paywall

• Objectives, not tasks: /goal patterns (paid)

• My depth-10 nesting experiments, the real cost multiplier, the decision rule (paid)

We won’t cover: API migration fine print, benchmark-by-benchmark analysis, or anything I haven’t run myself.

1. What Actually Changed

According to Anthropic, Fable 5 is “a Mythos-class model that we’ve made safe for general use. Its capabilities exceed those of any model we’ve ever made generally available.”

They built a model they don’t fully release. Mythos 5 stays limited-access, available to trusted partners. Fable 5 is the version of it you’re allowed to have.

That framing matters more than any spec row, and we’ll come back to it in Section 3.

Fable plugs in wherever Opus 4.7/4.8 did, with a few breaks that will bite you if you migrate blind:

Three migration gotchas hiding in that table:

1. You can’t turn thinking off. Pipelines that set thinking: disabled for speed get a 400 error. The effort dial survives. Zero doesn’t.

2. Temperature is gone. If your eval suite sweeps sampling settings, those configs fail on Fable.

3. Until June 22, your API keys can’t reach it. Subscription surfaces only (Claude Code, Cowork, the apps). Plan your team’s testing window accordingly.

1.1 Fable 5 effort dial, measured

Instead of taking the docs' word for it, I measured. First at 5 rounds on launch day, then at 20 rounds per cell on day four:

What held from launch day:

• Below max, the dial barely moves. Thinking is adaptive. The model ignores budget it doesn’t need.

• Correctness never moved. On a hard math puzzle with a checkable answer, every effort level got it right, with the same method. The extra seconds bought re-verification and caveats, not better answers.

What’s new at n=20: max is where Fable and Opus separate the most, 60.8 vs 49.0 seconds at the median. And that gap moved between builds. The top of the dial is the unstable part.

One gotcha worth this whole section. Pass a typo to --effort and the CLI silently falls back to your configured level, not the model default. I ran --effort xyz 20 times as a control: median 17.6 seconds, right on top of xhigh (18.5s), nowhere near high (13.6s).

So check your settings before you benchmark anything. My machine had xhigh persisted, which means every flag-less run I timed ran both models at xhigh. Matched, so the ratios stand. But the honest label on my charts is “matched effort,” not “out-of-box default.” The documented default is high on both Fable 5 and Opus 4.8.

The practical setting hasn’t changed: default to high. Dialing down buys back a few seconds, not different answers. Max should stay a rare exception. It’s now the least stable level, too.

Subscribe now

1.2 Fable 5 speed question, retested

The loudest day-one complaint after the classifiers: “Fable is slow.” One widely shared review called it a crawl, “even on simple tasks.”

I couldn’t find numbers, so I made my own. 320 timed runs, both models at matched effort, stream-level timestamps, exact token counts, outliers kept:

What held:

• The starting pause is real. First visible activity at a median 6.7 seconds vs 4.3 for Opus. That 2.4-second blank screen is my bet for where the “it crawls” feeling comes from.

• The trivial tax is modest. On one-shot questions, Fable averaged 1.48x Opus wall-clock. Every answer correct from both models.

What flipped on the retest:

• “Denser, not slower” didn’t survive. On launch day, Fable used about 40% fewer output tokens on the same math problem and finished sooner. At n=20 the token gap shrank to 8%, and Fable finishes 1.5x behind.

• Neither did “the gap vanishes on real work.” Across 20 heavy multi-file audits, the median tax is 1.29x (best pair 0.92x, worst 1.70x). Two of twenty beat Opus outright. The tax flattens with task size. It doesn’t vanish.

What didn’t move: correctness. All 240 graded answers correct, from both models.

So the verdict is narrower than the discourse: budget a short pause at the start of every exchange, accept a 1.3 to 1.5x time tax, and ask what the extra time buys. Section 2 prices exactly that.

Subscribe now

1.3 The benchmarks

Anthropic’s official chart covers these better than any table I’d retype:

Two things the official chart won’t tell you:

• The row that tells you what tier this is: FrontierCode Diamond, the hardest unseen problems in the set, where Fable more than doubles Opus 4.8 (29.3 vs 13.4) and runs 5x GPT-5.5:

  

• And one honest footnote from the system card: Fable’s published scores already include its production safeguards, which is why some rows run slightly below Mythos.

2. What a Real Finding Costs

Fable bills 2x per token. Here’s what that turns into when the task is finding problems, not answering questions.

I ran 60 audits of the same three style-guide files, 30 per model. Every run was metered from session traces and validated to the cent against the CLI’s own billing:

Three prices for the same work:

• Per audit: 2.5x. $2.93 vs $1.17 at the median. Wider than the price sheet, because Fable also writes more.

• Per finding: 1.25x. Fable surfaces a median 14 distinct findings per report vs Opus’s 7. So $0.21 vs $0.17 each.

• Per the bug that matters: 0.25x. One planted issue required reading two files against each other. Fable caught it in 20 of 30 audits. Opus caught it in 2.

That last row is the one your invoice feels. Expected spend per deep catch: $4.40 with Fable, $17.55 with Opus. The expensive model is 4x cheaper!

It’s not “Fable finds everything,” though. A same-file style clash got caught more often by Opus, 16/30 vs 12/30. Depth and breadth are different axes.

For PMs: price the outcome, not the tokens. Per token, Fable costs 2x. Per deep finding, a quarter. Whoever frames the unit wins the budget conversation, and that’s as true for your product’s pricing page as it is for your AI bill.

3. The Safeguard Layer Most Coverage Missed

3.1 The visible layer: routing

Fable 5 ships with classifiers that screen for high-risk domains. When a query trips one, the session is routed to Opus 4.8 instead, and you get a notification. Anthropic puts it at ~5% of sessions.

My own experiments with subagents got capped, too:

It doesn’t fail the query. It hands it to a different model, on purpose, and tells you. The capability ceiling and the safeguard layer are different things, and knowing which one you hit changes what you do next.

And the reroute sticks. Per the Claude Code docs, the session continues on Opus after a flag. /model fable takes you back, but if the trigger is still in your context, the next request just bounces you again. I learned that one live. My first read was “you can’t switch back.” The docs’ version is more precise: you can switch back, you just can’t stay.

The classifier reads your workspace, too. CLAUDE.md content and git status ride along on the first request. So a repo full of security or biology material can reroute a session before you’ve typed anything unusual.

Why does the screen exist at all? According to Anthropic, “Mythos-class models have reached a threshold where they present significant risks.“ The example they give: these models “excel at discovering and exploiting software vulnerabilities,” enough to make cyberattacks “substantially easier and cheaper to commit.”

There’s also a second, invisible layer. Per the system card’s Section 1.5, requests targeting frontier LLM development itself don’t reroute. They get quietly degraded, with no notification, on ~0.03% of traffic. Unless your team pretrains models, you’ll never hit it. Researchers are furious anyway (Elie Bakouch’s “very very sad for the research community“), and the precedent stands: the model you bought can be tuned down by topic, silently.

3.2 What this means for your team

Four practical notes from the first four days:

• Expect occasional routing, especially if your work touches security, healthcare, or biotech. Anthropic admits it (Claude Code’s Boris Cherny: “We know the classifiers are trigger-happy, and are working on improving it“). The notification is your signal: you did nothing wrong, and the floor is “merely Opus 4.8.” For security audits, the supported path is the built-in /security-review command. Also see my /security-review-static, which inspects the full solution, not just the diff.

• Two diagnostics worth knowing. For example, claude --safe-mode starts a session without your customizations, so you can check whether your own files are the trigger. And /config has a toggle that asks before switching instead of switching silently.

• Once flagged, decide fast. Treat the session as an Opus session or start clean. Don’t fight the classifier mid-context.

• The API behaves differently. When per-token access opens June 22, a tripped classifier blocks the request and returns a structured refusal category. There’s no automatic fallback by default. Server-side fallback to Opus is opt-in. The same applies to claude -p scripts today: non-interactive runs get a refusal, not a reroute.

The safeguard is worth copying: it swaps your model mid-session for safety. We can swap on purpose, for cost. Keep a cheaper model as your default and bring in Fable 5 only for the one call that needs it. Section 8 has what that costs.

Side Note: On September 1 we’re launching the 3rd edition of Claudathon. It’s a hands-on program to learn by building and shipping production-ready apps with embedded agents.

Before the cohort you should get familiar with the basics: VS Code, CLAUDE.md, skills (we provide the materials).

Early bid discount: https://go.productcompass.pm/claudathon
Paid annual subscribers who enroll get a refund for the current billing period.

4. Judgment Is the Feature

The benchmarks got their chart in Section 1. The interesting part of this launch is a behavior change.

One disclosure before the quotes: every voice quoted in praise here works at Anthropic. Read them as insider testimony, not independent validation, then check them against my receipts.

Karpathy called it “a major-version-bump-deserving step change forward,” strongest “for long problem-solving sessions on very difficult problems:”

The people building Claude Code describe the same thing. Cherny, from his launch post: Fable "has judgement, taste, and dimensionality in a way that previous models didn't:"

He asked it to debug something, and it took measurements, added logs, and verified the fix before declaring victory. Then the line that stuck with me: "There's nothing in claude code's prompting telling the model to do that, it's just part of its personality."

Thariq Shihipar compressed it to six words: "it's time to be more ambitious:"

The closest thing to an outside read, four days in, is the shape of the criticism. Researchers are angry about the invisible safeguards (Section 3). Dylan Patel of SemiAnalysis reports power users defecting to Codex after “refusals for nonsensical reasons.” Both complaints are about access to the capability. Neither questions the capability.

My version of that moment is the one this guide opened with. Fable read my instruction files and started surfacing contradictions instead of executing them. Previous models followed my rules. This one evaluated them.

That shift is part of a larger question: Will We Lose Our Jobs to AI? Cutting Through the Hype.

Subscribe now

5. Your Knowledge Layer Was Built for a Weaker Model

Fable flagged the first contradiction on its own, mid-task, before I’d read anyone’s tips. So I gave it the full job: read everything my agents follow and report what’s wrong.

That conclusion is consistent with voices inside Anthropic. Alex Albert’s launch tips name the same mechanism: instructions written for old models keep Fable behaving like those old models. Rework your skills and CLAUDE.md files. Let the model use its own judgment first.

5.1 What Fable found in my repo

My agents maintain those files, not me. I trusted Opus to keep them clean enough. Still, five finds:

• A hardcoded date telling the model what day it is. One strategy file contains “(today is 2026-05-24)“, written during a May session and never noticed again. Every session since has been told the wrong date by its own instructions.

• A rule documented with the pattern it bans. My writing system bans em dashes in published content. The file that documents the ban is written with em dashes. Instructions teach by example as much as by rule.

• Calibration constants that drifted. An X voice rule still gates on an audience under 50K followers. That number was true when the rule was written. It isn’t two months later (75K).

• Guardrails for failure modes the new model doesn’t have. Rules like “never delegate judgment-heavy work to cheaper models“ and complex self-check procedures exist because earlier models needed them. Each one now eats context and pulls the model toward old habits.

• The same rule stated in three files. Three maintenance surfaces, three chances to drift apart.

Some were plain mistakes. The rest were right for the model they were written for. That’s exactly the problem. The better your system was for the last model, the more it holds back this one.

5.2 Written by a weaker model

The pushback I got within hours of posting my first thoughts on X: if your files contradict each other, isn’t that just sloppy housekeeping?

Fair question, wrong model of the system.

This knowledge layer isn’t a config file a human writes once. It’s self-improving: agents file evidence as they work, turn evidence into working rules, and edit their own CLAUDE.md (the system from Three CLAUDE.md Blocks). 166 files, maintained partly by the things that read them.

In a system like that, contradictions aren’t carelessness. They’re drift, the same drift every wiki and every org’s process docs accumulate, except here it accumulates as fast as the agents write.

That creates the real trap: a knowledge layer written by a weaker model has a flaw no amount of review can fix. Every line an agent added passed review by the model that added it, by definition. A system maintained by model N tends to preserve the errors model N can’t see.

I review these files every day and didn’t catch it. Neither did Codex, which reviews my knowledge files as a second pair of eyes.

5.3 The audit prompt

So the first prompt I ran with Fable 5 wasn’t a task. It’s the prompt I’d now run before giving any new model real work, and it’s yours:

Read your own instruction files (CLAUDE.md, skills, rules, memory files) end to end.

1. Where do they contradict each other? Quote both sides.
2. Which rules exist to manage a weaker model: guardrails for failure
   modes you don't have, recipes for things you no longer need spelled
   out, hardcoded facts that have drifted? List them with file:line.
3. Which rules teach by bad example: documents that violate the
   patterns they prescribe?
4. What would you delete? What would you keep exactly as is, and why?

Don't fix anything yet. Report first. I decide what gets cut.

The audit is the model's judgment; the deletions are yours. What you do with the report, and how I turned mine into a repeatable migration workflow, is where we go next.

Behind the paywall:

• The migration workflow → the three-bucket rule classification (constraint, calibration, scaffolding) so you cut anchors without cutting your actual taste

• Objectives, not tasks → the /goal patterns that let Fable run long PM work unattended + 2 prompt templates

• How deep agents and workflows stack now → my depth-10 experiments, the 2.54x cost multiplier

• Delegating and escalating work with Fable → my CLAUDE.md snippet

• What doesn’t work (yet) → the honest list, so you spend your first week on the parts that do

• The week-one plan → day by day, copy-paste ready

Read more

Here’s what you might have missed:

• Introduction to AI PM: Neural Networks, Transformers, and LLMs

• From Weeks to Hours: How Claude Design Compresses Product Discovery

• Claude Code for PMs: The Beginner’s Guide

• Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session

Consider subscribing or upgrading for the full experience.

Subscribe now

Last week, inside Claude Code, I gave Claude a product-discovery job and added one short keyword: ultracode. I expected a better answer. Instead, it wrote a short program, spun up a fleet of agents, and ran the work through that program.

113 agents spent 1.95M tokens. The JavaScript that coordinated them spent zero model tokens. That distinction matters: the model did the judgment, the code did the coordination.

What surprised me wasn’t that Claude wrote code. It was that the most important coordination moved outside the model’s context window.

That changes how much one PM can run.

We’ll cover:

• What a dynamic workflow is, and the token number that proves it

• How it compares to n8n

• Why it works: four reasons, and the three failure modes a harness fixes

• The six patterns worth knowing

• A worked product-discovery loop on 100 interviews, end to end

• How to build, run, and contain one, and when not to

We won’t cover:

• The Agent SDK internals

• Fancy terms to memorize

This is the operating model, not the API docs.

1. What a Dynamic Workflow Is

1.1 The mechanism: the orchestrator is code, not a model turn

A dynamic workflow is a short JavaScript program Claude writes on the fly to coordinate subagents. You trigger it with the ultracode keyword, or by asking Claude to use a workflow. It reads the job, writes a script, spawns the agents, and merges what they return.

When you fan out 20 agents, something decides what each does, collects results, and drops duplicates. The old way, that something was the model, and every decision was a paid turn. Now it's ordinary code: loops, filters, sorting. None of it calls a model, so the routing is free. The agents still cost tokens; the glue between them doesn't.

1.2 How it compares to n8n

If you run n8n, you've made half this move. n8n took the glue between your tools and put it in a graph. A dynamic workflow takes the glue between agents and puts it in code. Same instinct, one level up.

This isn't an n8n replacement. n8n asks: how do I connect tools I already know? A dynamic workflow asks: how do I let the agent build the procedure for this run?

You could already ask Claude to write code that coordinates agents with the Agent SDK, but those are embedded agents: the ones you build into your own app or product. A dynamic workflow coordinates workspace agents: the ones doing your actual work (coding, research, knowledge work) inside Claude Code. The SDK is for the agents you ship; dynamic workflows are for the agent you work with.

1.3 When a workflow beats a subagent

How do you know it’s time to stop prompting and start orchestrating?

Subagents already fan out and synthesize: Opus delegating to a fleet, one round, then a merge. So a single fan-out is not the reason to reach for a workflow. The reason is what happens after the fan-out, when the output of one stage decides the next.

A mental model:

• Use subagents when the job is one round of parallel judgment.

• Use a dynamic workflow when stage N’s output determines stage N+1: route, score, filter, loop, retry, generate, verify, build.

For PMs: subagents are the workers; the workflow is the operating procedure. The expensive resource (a model's reasoning) goes to each stage; the cheap resource (code) decides the order, which model tier runs each stage, and what carries forward.

2. Why Move the Orchestrator Off the Model

The reason to reach for a workflow isn't that it's more "advanced" than an agent. It's that it moves the fragile part out of the model's context. Order, routing, stopping, and model choice become code. The model still does the thinking; it no longer has to remember the plan, police its own laziness, grade its own work, or decide when the job is done.

The structure that does this got a name that caught on in 2026: a harness. I'd been making the same case since 2025, under a different one: orchestration over autonomy. The model gets the judgment; the structure around it gets everything else.

Four things follow:

• Determinism. Code owns the order, the routing, and the stop condition. They run the same way every time, instead of depending on whether the model feels done.

• Context isolation. Each agent gets a fresh, bounded job. The goal lives in the script, not in a window that compacts and drifts.

• No orchestration-token tax. The coordination layer isn’t another model conversation, so routing the fleet is free (§1.1).

• Model tiering. Bounded, repetitive stages run on a cheaper model. (Subagents can do this too; it’s a pro tip, not the differentiator.)

The first two are the point; the last two are why it’s cheap. You feel their absence as three specific failures, and I’ve hit all three.

2.1 Agentic laziness

Ask Claude to review all 50 items; it reviews 35, writes a confident summary, and declares it done. A workflow holds the 50 in a for loop and runs until the array is empty. Humans get tired and models drift; a loop just checks the same condition again.

2.2 Self-preferential bias

Ask Claude to grade its own work and it grades generously, especially in judge-or-verify tasks. A workflow makes the judge a separate agent, with separate context, sometimes a different model. Spawn several skeptics, require a majority. The bias doesn’t survive being split.

2.3 Goal drift

Over a long session the objective loses resolution; every compaction is lossy, and the “don’t touch auth” constraint can evaporate by turn 80. A workflow holds the goal in the script, outside the model’s drifting memory. Agents come and go with fresh context; the goal doesn’t drift because it was never in a context that compacts.

For PMs: you've seen all three: 70% delivered as 100%, a self-review an outsider would shred, a Friday build that forgot Monday's requirement. Name the step your agent keeps redoing. That's your first workflow.

3. The Six Patterns Worth Knowing

Once the orchestrator is code, six shapes recur. Learn the names; they're how you recognize what a task wants.

• Classify-and-act: one agent decides the task type; the script routes accordingly. Reach for it when: triaging inbound (bug vs feature vs noise), routing support tickets.

• Fan-out-and-synthesize: one agent per piece in parallel, then merge in code. Reach for it when: competitor teardown, customer-call synthesis, a market map.

• Adversarial verification: separate agents check the output against a rubric. Reach for it when: fact-checking a PRD against its sources, a second reviewer on a risky call.

• Generate-and-filter: many candidates, filtered and deduped, survivors kept. Reach for it when: naming, positioning lines, experiment ideas.

• Tournament: N agents attempt the task different ways; judges compare until one wins. Reach for it when: a strategy memo or a hard design with no single right approach.

• Loop-until-done: keep spawning until a stop condition (no findings, no errors, empty queue). Reach for it when: a backlog triage or an audit where you don’t know how much work there is.

For PMs, on your actual work:

• Synthesize customer interviews → one agent per transcript, merged into a themes-and-JTBD table. Every interview read, not the first 20 (the worked example below runs this on 100).

• Check 80 user stories against INVEST → a loop that runs until every story is checked, not until the model tires at 50.

• Pressure-test a PRD before the review → a separate agent red-teams it against your goal and surfaces the assumption you’d otherwise defend at launch.

You're not learning to code. You're learning which weekly PM jobs can become standing workflows: set the goal once, save the procedure as a skill, and let it run end to end.

Subscribe now

4. A Worked Example: A Product Discovery Loop on 100 Interviews

This is where a workflow earns its keep.

Here’s the pipeline I ran on 100 synthetic customer interviews (1-2 pages each).

Six stages, each feeding the next:

• Step 1: Extract → fan out one cheap-model agent per interview; each returns structured opportunities, personas, and verbatims. Bounded, repetitive work: Haiku or Sonnet, not Opus.

• Step 2: Canonicalize → one agent clusters the raw opportunities into a canonical set. The extractors invent a fresh label per interview, so the same need arrives under a dozen names; merging synonyms is judgment, so it’s a model, not code.

• Step 3: Opportunity score → code ranks each canonical opportunity by frequency × importance × (5 - satisfaction). No model runs the math.

• Step 4: Generate and triage → for the top-scoring opportunities, an agent generates several solution ideas; a separate judge then ranks each by ROI (impact vs build effort) and keeps the top 3 to build. ROI re-orders the list, so a cheap, high-impact need can take a build slot from one that scored higher.

• Step 5: Build → for the top 3 ideas by ROI, an agent uses the frontend-design skill to write a distinctive, clickable HTML prototype I can open.

• Step 6: Inspect and rerun → a smoke check flags any prototype that fails to render, or any extraction that came back low-confidence, and the workflow reruns just that stage. This is the real loop: the output of one stage decides whether an earlier stage runs again.

That second stage wasn't in my first prompt. I'd written "merge and dedupe" and assumed code could do it; the counts came back fragmented. So I added one line to the prompt, cluster synonyms to a canonical set before counting, and Claude rewrote the harness with a clustering agent in front of the scorer. Even the fix lived off the model.

This is how it runs:

I measured the run: 113 agents spent 1.95M tokens in 12.5 min. 3/3 prototypes built and verified. The JavaScript that routed, scored, gated, and looped spent zero model tokens.

That's the payoff. The rest is how you build it 👇

Read more

You write the plan, you share it, people nod. The assumption that sinks it never gets named until launch.

So I built a command that names it first.

Paste a roadmap, a PRD, or a one-line bet into Claude. You get back the riskiest assumptions, ranked by what would hurt most, what is most likely to be wrong, and what is cheapest to test this week.

The impolite questions, before the market asks them.

It shipped today in PM Skills 2.0, the free, MIT-licensed marketplace 12,000 of you have starred on GitHub.

This is the biggest update since the March launch:

• 68 skills

• 42 commands

• 9 plugins

• one new AI Shipping Kit

• one new red-team command for PRDs, roadmaps, and strategy

Subscribe now

1. What PM Skills Actually Is

Generic Claude gives you text. PM Skills gives you structure.

Ask a raw model to “prioritize this backlog” and you get a confident paragraph. Ask it with the prioritization-frameworks skill loaded and it runs the actual framework, with the trade-offs named and the math shown.

The difference is not the model. It is the judgment encoded in the skill.

Each skill turns a proven PM method into a reusable workflow: discovery, assumption mapping, prioritization, strategy, pricing, GTM, execution, analytics, and now AI shipping.

There are three pieces:

• Skills give Claude a method or framework. They load automatically when the work matches.

• Commands are slash workflows you trigger directly. /discover chains four skills: brainstorm ideas, identify assumptions, prioritize assumptions, and design experiments.

• Plugins group related skills and commands by PM domain. Installing the marketplace gives you all 9 at once in Cowork.

The full catalog lives in the GitHub README. For this release, two plugins changed.

• pm-execution was updated with one new skill, strategy-red-team, and one new command, /red-team-prd.

• pm-ai-shipping is new: two skills, five commands, and a workflow for turning an AI-built repo into something a human can review.

2. The New Command: /red-team-prd

This is the one to try first, because you can feel it in thirty seconds.

/pre-mortem imagines the plan already failed and narrates why. /red-team-prd does the opposite: it attacks the live assumptions now, while you can still change them, and hands you the cheapest test for each.

Here is what that looks like on a one-line bet:

It also tells you what is already well-reasoned and what it could not assess. A useful red team does not manufacture doubt to look smart. If the plan is strong, it should say so.

Five real kill-assumptions with tests beat twenty generic risks.

3. The New Plugin: The AI Shipping Kit

The other half of the job changed this year. PMs and founders are now accountable for code an AI wrote.

AI writes fast, but it leaves no written record of intent:

• what the system should do,

• who may do what,

• where the secrets live,

• which permissions are actually enforced,

• which rules are verified by tests.

The AI Shipping Kit restores that record.

The umbrella command, /ship-check, answers the question you actually have:

Is this safe to ship?

It:

• documents the system,

• audits the code against that documented intent,

• maps test coverage,

• and compiles a shipping packet a human can sign off on.

The gate is intended vs. implemented.

/ship-check looks for the places where the product promise and the repo disagree: the permission that is documented but never enforced, the scheduled-job endpoint anyone can call, the test that proves nothing about the workflow it claims to cover.

You do not need to be technical to run it.

You need to know what the system was supposed to do.

The kit has two skills:

• shipping-artifacts defines the docs that make an AI-built app reviewable: architecture, flows, permissions, variables, tests, and conditional docs for email, scheduled jobs, SEO, or automation.

• intended-vs-implemented audits the gap between documented intent and actual code, with evidence on both sides.

And five commands:

• /document-app creates the system documentation.

• /security-audit-static checks security against the documented intent.

• /performance-audit-static checks over-fetching, missing indexes, and caching.

• /derive-tests maps what is tested, what is proposed, and what is unverified.

• /ship-check runs the full sequence and compiles the shipping packet.

Subscribe now

4. How to Install It

The repo is the source of truth: https://github.com/phuryn/pm-skills

If you use Claude Cowork, install the whole marketplace:

1. Open Customize in the bottom-left corner.

2. Go to Browse plugins -> Personal -> +.

3. Select Add marketplace from GitHub.

4. Enter https://github.com/phuryn/pm-skills

All 9 plugins install at once. Enable those you need:

If you use Claude Code, add the marketplace:

claude plugin marketplace add phuryn/pm-skills

Then install the plugins you want. To install the full marketplace:

claude plugin install pm-product-discovery@pm-skills
claude plugin install pm-product-strategy@pm-skills
claude plugin install pm-execution@pm-skills
claude plugin install pm-market-research@pm-skills
claude plugin install pm-data-analytics@pm-skills
claude plugin install pm-go-to-market@pm-skills
claude plugin install pm-marketing-growth@pm-skills
claude plugin install pm-toolkit@pm-skills
claude plugin install pm-ai-shipping@pm-skills

If you only want the new and updated pieces from this release:

claude plugin install pm-execution@pm-skills
claude plugin install pm-ai-shipping@pm-skills

New to Claude Code? Start with the beginner’s guide, then the advanced guide when you want the power-user setup.

The commands flow into each other. A real week looks less like a feature list and more like one continuous thread:

• /discover a new idea,

• /write-prd the winner,

• /red-team-prd the PRD before the review,

• /ship-check once the code exists.

After any command finishes, it suggests the natural next one.

One more note: the skills are portable. The slash commands are Claude-specific, but the SKILL.md files follow the universal skill format and can be copied into tools like Codex CLI, Cursor, Gemini CLI, OpenCode, or Kiro.

The README has the exact copy instructions.

5. How It Composes With PM Brain

PM Skills gives Claude the method. PM Brain gives Claude your product context.

PM Brain is a markdown second brain for product managers: strategy, users, decisions, hypotheses, stakeholders, and recurring knowledge in plain files on your laptop.

Run them together and the frameworks stop being generic.

/red-team-prd can attack your plan using what PM Brain knows about your real constraints. /strategy can build on your actual positioning. /ship-check can review a repo against documented product intent instead of a blank canvas.

One supplies the rigor. The other supplies the context.

6. Start Here

If you have a plan you are not sure about, run:

/red-team-prd [your PRD, roadmap, or strategy]

If you have an AI-built app you are close to shipping, run:

/ship-check [repo or folder]

If you are starting from zero, run:

/discover [your product idea]

Everything is free and MIT-licensed. If it helps, star the repo so the next PM finds it.

AI does not fix weak product judgment.

It scales it.

PM Skills is where the judgment lives.

Thanks for Reading The Product Compass

It’s amazing to learn and grow together.

Have a great rest of the week,
Paweł

Resources

Get the marketplace (free):

• PM Skills on GitHub - 9 plugins, 68 skills, 42 commands, MIT-licensed.

• PM Brain - the markdown second brain that composes with it. MIT.

Go deeper (The Product Compass):

• Claude Cowork for PMs - agents without IDE, start here.

• Claude Code: the beginner’s guide - start here if you are new to IDE.

• Claude Code: the advanced guide - the power-user setup after you get the basics.

• Codex setup for PMs - wiring a second model alongside Claude. I've found it catches ~80% of my errors.

• Intent engineering for AI agents - lead with context, not instructions.

• I don’t review the code, I review the artifacts - the review method behind the AI Shipping Kit, plus the downloadable artifact prompt pack.

• Security and performance testing prompts - the worked teardowns the kit automates.

• Claude Code's Limits Are Generous. The Problem Is Your Setup - how I cut my Claude costs over 5.5x.

• Three CLAUDE.md Blocks That Make Claude Get Smarter Every Session - critical concepts for building self-improving agentic systems.

• Vibe Coding vs. Vibe Engineering published in Sep, 2025 (in 2026, labeled “agentic engineering” by Andrej Karpathy)

If you are curious, a few things I’m shipping:

• claude-usage - Embed your Claude Code usage dashboard (token counts, costs, sessions, projects) directly inside VS Code.

• agentlift - Deploy agents to Claude Managed Agents, AWS Bedrock AgentCore, and Google. One folder, one definition, one command.

• Grok Build for VS Code - The only visual UI for Grok Build (non-CLI), 1,400 active installations. A bet in case Grok surprises us.

More than 800 tests and eval checks across the three repos, from unit tests to LLM judges, nearly all green. I’m a PM, not an engineer, and I barely read the code.

And this isn’t just me, or just indie builders shipping side projects. A Google PM described the shift from writing-first to building-first:

It’s not only Google.

Meta PMs now vibe-code prototypes and demo them straight to Zuckerberg, and the company added a prototyping round to its PM interview; LinkedIn replaced its APM program with an “Associate Product Builder” role gated on a live AI build. The prototype is becoming the PM’s first deliverable inside large companies, not a side-project trick.

So what did I review? The artifacts:

• the plan before it ran

• the decisions it encoded

• the strategy the agent reads every turn

• the docs that say what the thing does and why

It’s the same shift whether your surface is a repo, Claude Code, Cowork, or a chat window. Experimenting got cheaper than building agreement, and that reorders the work.

None of them started with a spec. Each started with a conversation, and what I kept was the artifacts.

What this post covers:

• What the artifact layer is, and why a PM reviews it instead of the code

• Why building now comes before agreement, not after

• Where your strategy has to live to actually steer the agent

• The boundaries that let you hand an agent real autonomy and walk away

• The AI Shipping Artifact Prompt Pack to download at the end

Subscribe now

What I Actually Ship Now

The product is the obvious artifact: the extension on the Marketplace, the tool people install. The one that decides whether the next change goes well is less obvious. It’s the knowledge layer.

Not the README or the changelog, every repo has those. The docs that hold the decisions: why this architecture, who it’s for, what we ruled out:

• In PM Brain that’s files like architecture.md and why-this-matters.md

• For accredia.io it was more than twenty docs, from database.md and security.md to a fuckups.md

• For a multi-agent app I built with my cohort, it was the agent contracts: what each agent takes in, what it returns, which tools it can touch, and how they hand off.

Keeping that layer true is a question of what to automate, and when:

• In claude-usage, git tags are generated from the CHANGELOG automatically: the changelog is the source of truth, the tag is a deterministic projection.

• In Grok I keep version bumps manual on purpose, because automating them there hasn’t earned its keep yet.

Seven things shipping this way taught me.

Lesson 1: Review Artifacts, Not Code

The question I get from PMs is “do I have to learn to code?” I don’t, and I don’t review the code, beyond the odd snippet.

That layer isn’t a side effect of the build. It’s a deliberate, human-and-agent-readable summary of the solution, so neither of us has to reverse-engineer the product from the source. It often duplicates what the code already says, and that’s the point: it’s far easier to consume.

It’s also what I check the code against. When I care whether the implementation matches the intent, whether the security model holds, whether performance is where it should be, I read the artifact, not the diff.

So when work comes back, I don’t read changes in the code. I read changes in the artifacts. I review across three modes, escalating only as far as the decision needs:

Cheapest mode first. A durable artifact is the receipt: it survives the context window, and it survives me. Only commit one when the alternative is losing the thread.

Here’s one from a build. I opened the session with a document, not a ticket: “See the research in plan-mode.md. Can we really implement that logic reliably on our side?”

The agent didn’t start writing code. It read the doc, ran a quick probe to test the doc’s core assumption against the real tool, and reported what it found. I signed off on the approach from that exchange, not from a single line of the implementation.

And this matters more on a team, not less: your teammates don’t carry your context in their heads, so the artifact layer is how a decision or a hard-won finding survives past the person who made it.

Subscribe now

Lesson 2: Build Before Building Agreement

The old motion was: write the PRD, get everyone to agree, then build. That order made sense when building was the expensive part. You spent weeks of engineering, so you spent days up front making sure it was the right thing.

That’s why I shipped two major releases in a day, and why none of these projects started with a spec. Two-week iterations start to feel dead in this mode. Not because planning is useless, but because the unit of learning changed: when a working version costs an afternoon, a sprint is too slow to be the main loop. You ship, watch, revise, and ship again before the old process would have turned the debate into tickets.

A prototype, even a rough one, collapses the ambiguity: the team sees what the customer clicks, where they hesitate, what they ignore, what they ask for next. Highly regulated industries aside, agreement around an untested doc is low-value at best: the idea changes the moment it touches reality. At worst it's harmful, because the team gets attached to a product that only existed in language.

Lesson 3: Put Strategy Where the Agent Works

I still write the strategy down:

• who it’s for

• what changes for them

• what I won’t build

• the trade-offs I’ll accept

• what would make the work a failure

What changed is where it lives and what it’s for. It doesn’t sit in a folder someone might open before a kickoff. It lives in the repo, a strategy.md the agent reads every time it acts.

If the strategy isn’t in its context, those decisions get made from whatever’s nearby: the last prompt, the surrounding code, a guessed convention, the model’s own confidence.

The repo becomes the product’s memory, too:

• experiments

• decisions

• evals

• screenshots

• release notes

• the constraints I hit

They accumulate there anyway. My job is to keep that context clear enough that the agent can use it. (The one thing I stopped writing is the spec, the user stories and acceptance criteria that told engineering exactly what to build. That part is cheap now; it falls out of the conversation.)

Your strategy is only doing work if it changes what the agent does next.

Share

Lesson 4: Cross-Examine Confident Answers

I asked Claude to bump the version and publish. It was confident: “Just run the publish command. CLAUDE.md says the publisher’s already authenticated.” I almost did it. Then I asked: “Are you sure? I’ve been publishing by hand through the Marketplace website.”

The confidence collapsed. That claim was from a past session I’d never verified, and the setup it promised had never happened. The command would have failed at the first step.

That one was harmless. A command fails in front of you, you fix it in a minute. The claims that bite are the confident ones you act on instead of run, where the failure is silent and lands downstream. Pushback is how you catch those before they cost you. The moment you ask “are you sure?” carries more weight than the next instruction you give.

But you can’t interrogate everything, or you become the bottleneck you were trying to remove. So I triage. I cross-examine the confident answers that are expensive to be wrong about:

• irreversible changes

• anything touching auth, billing, security, or the data model

• anything that becomes context future work depends on

• any claim that sounds too clean

The strongest version of pushback isn’t you, though. Your attention doesn’t scale. A second model gives you more review surface without funneling every hard question back through your head.

When I had the extension audited for bugs, the agent built a confident, elaborate theory and walked straight past a one-line bug in the same function: a failure was being reported as a success. Trust that, and it keeps building on a false "it worked": wrong analysis, maybe a destructive next step. Codex caught the one-liner Claude had talked itself past.

A second copy of the same model shares its blind spots. A different model, trained differently, fails differently. Self-review feels like diligence. Cross-review is. (I wrote up how I wire Codex alongside Claude separately. You can watch one play out in public: the cross-check narrowed a contributor’s over-broad fix to a single bad value, and he confirmed it.)

Lesson 5: Make Failures Teach the System

The best artifacts in my projects usually began as failures I didn’t want to debug twice.

The loop is the same every time: a failure surfaces, I find the smallest thing that would have caught it, a test, an eval, or a line of policy, and I make it permanent so the system can’t forget it.

The most load-bearing line in my CLAUDE.md is four words: “Don’t introduce abstractions speculatively.” It earned its place after an earlier project drowned in structure it didn’t need. A line copied off social media is a guess about a problem you might have; a line written after the third time something went wrong is policy. accredia.io keeps a fuckups.md in its docs; that’s where its rules come from.

Tests are the same idea in a different file. Early on, the model offered a 27-test suite and I took it, but the next bug I hit wasn’t in any of the 27, it was a sequencing problem they tested around. So now, when a real bug shows up, I ask: “What’s the smallest test that would have caught this?” and add that one.

The claude-usage triage routine mechanizes it: on every fix it adds the test, then reverts the fix to confirm the test fails without it. A green suite proves the past; manual smoke probes the future.

Evals are the same instinct for AI that’s in the product: read the traces, name what’s failing, then turn each failure into a test, an LLM judge, or a new line in CLAUDE.md. PM Brain’s judges are each named after a real failure (decision_quality, evidence_hierarchy_respected), never from a spec up front. (I go deeper in evaluating AI products through error analysis.)

Subscribe now

Lesson 6: Point Every Agent at One Source of Truth

I had three coding agents open during this build: Claude Code in the terminal, a Grok tab in VS Code, and Codex through a separate skill. Same repo, same files, three independent conversations. Without a shared source of truth, they’d have proposed three different architectures, and I’d have spent the build arbitrating instead of building.

So I keep one master doc: CLAUDE.md, with the project, the conventions, and the decisions already made. The other agents don’t read it by default, so each gets a tiny AGENTS.md whose only job is to point them at it. It duplicates nothing; it just redirects.

In claude-usage I flipped the direction: there AGENTS.md holds the guidance and CLAUDE.md is one line, @AGENTS.md, that imports it. Either way works. One source, everything points at it.

It isn’t only CLAUDE.md, either. The source of truth is the whole working-context layer, the docs, rules, skills, and hooks each agent can reach, and I keep that synced too. Each agent can have its own entrypoint; it shouldn’t have its own reality. (Full setup in Codex Setup for PMs.)

Lesson 7: Grant Autonomy, Enforce Boundaries

Early on, I babysat every run. I watched the model think, approved each step, sat at the screen the whole time. That doesn’t scale across the number of things I’m trying to ship.

The shift was setting a goal, giving the agent room to pursue it, and walking away. The clearest example runs every week without me. The goal: go through every open pull request and feature request on claude-usage, merge the clear bug-fixes, mark the duplicates, push out-of-scope features to a Discussion, and report back only what couldn’t be resolved. It runs headless, on a schedule. I read the summary later, often from my phone.

Autonomy that wide only works with two kinds of limit, and the difference is the whole game:

Steering prompts are soft: a one-line reminder, or a repeatable procedure like the gate rules in my content system. Either way, under pressure the model can talk itself out of one.

Hard boundaries are enforced where the model gets no vote. In the triage routine:

• nothing closes unless the second model writes a sign-off file with an exact approval phrase

• it won’t auto-merge anything touching auth, secrets, or more than 200 lines

• it never pushes to main

Those aren’t requests. They’re mechanical gates.

The strongest version of a hard boundary is the tool surface itself. In the Grok extension, plan mode isn’t a polite “please don’t edit files yet.” The extension gates the actual file-write and terminal calls, so while a plan is pending the model physically cannot touch the disk.

Same idea as a Claude Code hook or a tool allowlist: if a limit has to hold, it lives in code, not in a sentence the model can reinterpret. PM Brain enforces a different limit the same way: a hook fires after every file write and blocks the agent from saving a brain file with an untagged claim. No clean save, no write.

The same logic runs at the shipping boundary. On claude-usage, no pull request merges to main on a red test suite. I didn’t know how to wire that up, so I asked Claude to set the branch protection for me. The agent can be confident and a contributor can be in a hurry; the merge button stays disabled until the tests pass.

PM Brain’s /review edits knowledge files on its own, but it’s hard-stopped from changing a decision’s status; that judgment is mine. Wide lane, real walls.

What Still Needs Human Judgment

Here’s what the system still can’t decide for me.

• Models over-rate their own findings. In that audit, the agent tagged three findings “high severity.” Checked against the actual code, all three were medium or low. The model is good at producing candidates. Deciding what’s actually serious is still mine.

• A second model helps; it isn’t magic. Two models from the same family share blind spots. Claude and GPT diverge enough to be worth pairing, but neither makes the load-bearing check stop being yours.

• Taste regressions still need eyes. No agent caught the copy button overlapping the header buttons. I did, on a manual pass. Design judgment isn’t in the test suite.

• The workaround becomes part of what you ship. Grok’s CLI returned unreliable tool results, so every session in the extension opens with a hidden primer: “Do not trust the tool result.” That scar tissue is product judgment too.

So What Do PMs Ship Now?

Across all of it, the extension, the knowledge system, the premium section behind this newsletter, the pattern held.

None of it shipped because I wrote a better spec, and none of it shipped because I read the code. It shipped because the conversation was good, and because I kept the few artifacts that turned out to be load-bearing: the strategy, the decisions, the constraints, the CLAUDE.md the agent actually reads.

PM Brain made it obvious. The brain it scaffolds is 44 markdown files around a single CLAUDE.md, and that structure emerged from use, not from a document I wrote first.

The AI Shipping Artifact Checklist

If the artifact layer is what you actually ship, here’s the starting set. Organized by purpose, not by stack, because the project changes but the knowledge-layer needs don’t. Steal the list; name the files whatever fits your repo.

None of these is a spec. Each is a place the decisions live, so you and the agents can read them instead of reverse-engineering the code. You don't have to hand-write them, either.

The AI Shipping Artifact Prompt Pack

One download, two kinds of thing, both built around the artifact layer above:

• The artifact prompts: seventeen of them, one per kind of file and risk, from strategy to workflow maps to cross-model review. Point an agent at your repo, run a prompt, review the doc it writes. They generate the layer; they aren’t the layer.

• The audit commands: a static security audit and a performance twin, for code you didn’t write. The security one, /security-audit-static, traces untrusted input to the places it could do real damage, then refutes its own findings before reporting. I pointed it at Langfuse, a leading LLM engineering platform, and it surfaced a real weakness in how provider connections were fetched. The hardening fix merged, 964 lines added, 334 removed.

Some of the 20+ issues I’ve since responsibly disclosed to public-repo security teams (Langfuse at the top):

Get the pack below: 👇

Read more

Codex grew from about 200K to roughly 4M weekly active users in four months. Claude Code crossed 2M in early March. If you opened this post, you're probably one of those 2M. The other 4M are on a tool you haven't tried.

And it's not just a developer tool anymore. If VS Code has felt like a wall, the Codex app is a chat window with a file tree, visual diffs, and long-running sessions. PMs who've avoided code repos no longer have to.

ChatGPT Plus is $20/month and includes Codex. The setup takes about five minutes. This guide is the walkthrough.

Updated August 1, 2026. Three things changed since this guide shipped:

• The Codex desktop app is now the ChatGPT app, with three modes: Chat, Work (documents, decks, research), and Codex (coding). Where this guide says "Codex app," use the ChatGPT app in Codex mode.

• OpenAI cut GPT-5.6 Luna's price by 80%. On my 105-bug benchmark, Luna at max reasoning effort beat every Claude model. Set reasoning effort to max. It's off by default.

• The $20 ChatGPT Plus plan now covers serious agent work.

By the end of this guide, you’ll have:

• Codex app installed and pointed at your repo

• AGENTS.md bridged to CLAUDE.md so both runtimes share one source of truth

• Plugins installed for the apps you use, with project skills mirrored if you build with AI

• MCPs running in both runtimes, with a one-shot prompt to do the import

• Claude Code able to call Codex as a peer for review

• A plan for working from your phone (cloud tasks vs. remote control)

Full Cowork / Claude Code / Codex comparison is at the bottom. First, the setup.

Subscribe now

1. Why Add Codex as a PM

Five reasons I added Codex, in order of how often they show up in my work:

• A way into a repo without VS Code. If the IDE has felt like a wall, the Codex app (desktop) is a chat window with a file tree, visual diffs, and long-running chat sessions. No commands to learn, no extensions to wire. You can even edit files by leaving comments for Codex. Cowork is chat-first; no tree, no diffs.

• Manual Compact. You decide when to compress the session instead of waiting for the model to hit the wall. In Codex, type c, then /com, and choose Compact when it appears. Claude Code has /compact in the CLI. Cowork does not have an equivalent manual reset. This matters for your budget: Claude Code’s Limits Are Generous. The Problem Is Your Setup.

• An extra perspective. When I want a second pair of eyes on a prompt, or a piece of code, I hand it to the runtime that didn’t write it. Different model, different misses.

• Image generation in the bundle. The ChatGPT subscription that Codex ships with includes image generation. Claude doesn’t cover that workflow.

• Runs next to Claude Code on the same repo. Same files, same skills, same MCPs. Switch runtimes without rebuilding your setup.

Subscribe now

2. Install Codex (Desktop App and VS Code Extension)

You'll install two things. Codex app (desktop) is the chat workspace where long sessions and Compact live. Codex for VS Code is the editor extension that lets you call Codex in the same window as Claude Code.

Both share one OpenAI login, both work on the same repo, and you'll use both for different jobs.

Codex app (desktop)

Download Codex app from OpenAI (now named ChatGPT). Sign in with the ChatGPT account that has Plus, Pro, or Business. Codex is bundled with all three.

The first prompt asks you to migrate your VS Code settings. I skip it. Not because it’s hard. Because you should know what’s being imported before you click yes. You can always migrate later from Settings or by asking Codex for help.

Open the same project folder you already use with Claude. The file tree loads on the right. Visual diffs appear in the same panel.

Codex for VS Code

Install the Codex extension from the VS Code marketplace and sign in with the same OpenAI account.

If you already use the Claude Code extension in VS Code, both extensions will show up in the activity bar. You can switch between them by tab.

Why both surfaces? The Codex app is for long chat sessions and Compact. Codex for VS Code is for editing the repo, including dot folders (.agents, .codex) that the app’s file picker hides - full dev experience.

Subscribe now

3. Teach Codex Your Repo: AGENTS.md to CLAUDE.md

Codex looks for AGENTS.md at the repo root. Claude Code looks for CLAUDE.md. If you maintain both as separate sources of truth, they drift.

The fix is a one-file bridge. AGENTS.md is a short pointer. CLAUDE.md stays the canonical document. Codex reads AGENTS.md, sees the pointer, follows it.

Drop this at the repo root as AGENTS.md:

# AGENTS.md

This repository keeps its canonical agent instructions in [CLAUDE.md](./CLAUDE.md).

When operating in this repo:

1. Read and follow `CLAUDE.md` as the source of truth.
2. Treat references to "Claude Code" as applying to Codex when you are the acting agent.
3. Do not duplicate `CLAUDE.md` content here. Update `CLAUDE.md` instead.

One file. One source of truth. Both runtimes follow it.

AGENTS.md is the bridge. CLAUDE.md is the long part. The structure I use:

1. Communication: How the agent should talk, what content it should produce.

2. [For personal work] About me: Role, audience, social media handles

3. [For product work] Strategy: Market segments, value propositions, tradeoffs.

4. Project structure: Where things live, architecture, conventions.

5. Workflow: How we do things (reviewing, shipping). Not a procedure manual. The rules of engagement.

6. Progressive disclosure: Links to deeper files (strategy.md, knowledge/INDEX.md, whatever you’ve built) that load on-demand, not on every session.

Each section earns its place when something would otherwise have to be re-explained per session. CLAUDE.md isn’t documentation. It’s the agent’s memory of how you work.

Progressive disclosure matters because context isn’t free. Don’t dump 500 lines of text into CLAUDE.md if 100 of it only matters for one workflow. Keep the core file lean. Link out to the rest.

4. Configure and Share Skills

If you haven’t used skills before, think of them as reusable instruction bundles. A SKILL.md file tells the runtime when to fire and what to do.

Two ways to configure them in Codex.

Start with user skills. The Codex app ships with a Plugins panel. One click installs Gmail, Linear, Jira, Slack, and others. You get the app’s connection and its skills together.

With Plugins installed, Codex reads your CLAUDE.md and talks to the apps you use daily.

That’s the minimum viable Codex setup for a PM.

The next step is making Codex and Claude Code behave like one operating system: curated skills, project skills synced between runtimes, mirrored MCPs, and a repeatable review loop.

Read more

Research preview. The architecture has months of dogfooding behind it on my content work. The product as installed by real PMs in real organizations is days old. The eval suite is the floor; your install feedback is how it gets better. Monday May 26, I'm running a live workshop session for paid subscribers, and there's a dedicated #pm-brain Slack channel for 1:1 install help. Details in §11.

You manage one product. Your context lives in five places: Notion, Linear, Slack, your dashboards, and your head.