Thinking on product truth, behavior specs, and building software teams can reason about.
Subscribe via RSSAI-native teams need three layers of durable memory — behavior, decisions, execution. Execution has mature tooling. Some domains have decision substrates. Most product teams don't, and that's where the behavior layer matters.
As engineers take on more product ownership (and AI accelerates shipping), product decisions disappear into Slack and pull requests. A living behavior contract makes intent durable.
AI makes rebuilding cheap. But product decisions are expensive to recreate from memory. Here's how a behavior spec makes 'start fresh' a feature, not a failure.
Paste a prompt into Claude or ChatGPT, describe your product module in a few sentences, and get a .pbc.md behavior spec you can view, edit, and commit to your repo.
CLAUDE.md and AGENTS.md tell agents how to work in your repo. They don't tell agents what your product promises. That's a different problem — and it needs a different artifact.
A step-by-step guide to writing a .pbc.md file for your product's most critical module. Start with plain Markdown, then add structured blocks that tools and agents can read.
Shipping fast with AI agents feels productive. But the costliest mistake isn't bad code — it's building confidently in the wrong direction because nobody wrote down what was actually decided.
PRDs capture intent. Test suites verify assertions. But between those two, there's no artifact that tracks what the product promises to do — grounded in code, confirmed by humans. That's the PBC layer.
AI coding agents now have AGENTS.md, memory banks, harnesses, evals, and monitors. They still lack product context: what the product promises to do and which behaviors must stay true.
When an outsourcing engagement wraps up, product knowledge walks out the door. A living behavior spec keeps it in the codebase — not in someone's head.
AI can now extract product logic from your codebase. Stewie builds a living behavior spec your whole team can read — no code, no stale docs, no waiting on engineers.
Product owners confirm behaviors. BAs clarify domain logic. QA knows what to protect. New hires onboard in hours. Vendor teams skip the reverse-engineering phase. Here's how each role contributes to a living behavior spec.
Strategic leaders shouldn't need three meetings to verify whether a product decision was implemented correctly. A living behavior spec gives you a direct line to what's running in production.
Your coding agent ships correct-looking code that breaks product promises. The problem isn't capability — it's a missing context layer that AGENTS.md and memory banks were never designed to provide.
Your repo has workflow instructions, session context, and feature specs. None of them answer: what does the product promise to do? That's a different layer — and it needs its own artifact.
Shipping fast with AI coding tools is genuinely good. The problem isn't the speed — it's what gets left behind. Product reasoning doesn't survive the vibe.
A .pbc.md file opens in VS Code, renders on GitHub, and reads like any other Markdown document. Drop it into pbc.stewie.sh and the same file becomes navigable structured UI. One source of truth, two reading experiences.
After running into the same product knowledge gap across multiple SaaS products, I built an open Markdown spec for capturing what your product promises to do. Here's what's in it and why.
A Product Behavior Contract (PBC) is a living, code-grounded spec that describes how your product actually behaves — not how you think it does.
Product knowledge lives in heads, not docs. Here's why that gap compounds — and what a behavior spec does about it.