We’re live on Product Hunt. You don’t have to run the coding agent to shape what it builds. Review its plan in your browser, answer its open questions, and approve the version it builds. producthunt.com/products/pat…

The person who knows what should happen for customers may not be the person running the coding agent. Pathmode gives them a place to review the proposal, correct it, and approve the version the agent builds from. pathmode.io/compare/agent-pl…

Really liked @jboogie’s piece on turning a product hypothesis into an AI eval before building. Write down what would prove you wrong, test on real inputs, agree on the passing bar upfront. A few things we learned the hard way building Pathmode’s intent checks: • Check the grader. Ours agreed with the bad answer it was meant to catch, 2 runs out of 2. • Run the known-bad version too. One eval passed both the fixed and the broken prompt, 36 of 36 each. It couldn’t see the bug. • Keep some cases out of sight. A perfect score means nothing when the cases resemble examples already in your prompt. And passing the eval is still just a reason to try it with users. You still have to find out whether it helps. jeffgothelf.com/blog/how-to-…

We built Pathmode because the person running the coding agent isn’t always the person who should decide how the product behaves.

An agent can implement today’s request correctly and still undo something your team learned months ago. We’re building Pathmode to carry those decisions and the evidence behind them into the next build.

We replaced the robot with Agent Smith. Better? See it live: pathmode.io/

“Build a duck.” ✅ Is duck ✅ Stands up ✅ No parts left over “It was supposed to be a pirate.” New ticket: make duck eligible for maritime crime. This is why we're building Pathmode. Settle the missing decision before the build. pathmode.io

Cleaned up github.com/pathmodeio. Check an intent.md → CLI Draft specs in Claude Code → plugin Cursor/Codex/Desktop → MCP server Validate in CI → Action Implement the format → IntentSpec Start here: github.com/pathmodeio

Before handing an intent.md to a coding agent, what decisions are you leaving it to guess? I ran Pathmode’s preflight on a worked example following the structure of Anthropic’s AI-native SDLC playbook. The original spec said: “Customers see shipment status and the expected delivery date in their account.” But what should happen when the shipment API is down? Preflight flagged the missing failure behavior. The revised spec adds: “The shipment API is down: the page shows the last known status and when it was checked.” That’s one less product decision left for the coding agent to guess. The check also flagged gaps in outcomes and verification. The additions kept the author’s context and open questions intact. Try it against your existing file: npx @pathmode/cli preflight It finds files under intent//intent.md too. Free, local, no account. Worked example with the before-and-after specs and verdicts: intentspec.org/intent-md

“Add a cancel button” leaves a product decision unanswered: Does access end immediately, or when the paid period ends? Pathmode brings that choice back to your team, and carries the answer into the coding agent’s next session. The agent proposes. You decide.

Product decisions and coding agent setup often belong to different people. We rebuilt Pathmode for that handoff: invite the teammate running the agent, start the brief while they connect, and follow it to a verified repository connection. An invite isn’t a connection. pathmode.io

Google’s new whitepaper on vibe coding makes a strong case: as AI accelerates implementation, specification, verification, and human judgment become more important. That’s the part I keep coming back to: judgment. We’re getting better at telling agents how to work. Repository instructions, tools, guardrails, tests, evals. But there’s another set of questions: Why is this the right problem to solve? Which customer evidence supports it? What tradeoff did we make? Who approved the direction? What would make us reconsider? A test can verify that a payment retry works. It can’t establish that payment retries were the reason customers abandoned checkout. You can pass every check and still build the wrong thing. The paper argues that intent is becoming the interface for software development. I agree. But intent needs to carry more than a description of the desired implementation. It needs the reasoning behind the work—and a way to change that reasoning when implementation or customer behavior reveals something new. That’s what we’re building with Pathmode: a connected record from evidence to intent, through implementation, and back to outcomes. Our starting point is simple: an intent.md alongside your code. What problem you’re solving, why it matters, what success looks like, and the boundaries an agent must respect. The bigger opportunity is keeping that intent alive: recording decisions, bringing implementation findings back into refinement, and checking whether what shipped actually helped. Faster coding makes it cheaper to build an idea. We still need to know which ideas deserve to become software. kaggle.com/whitepaper-the-ne…

Most agent failures start before the first line of code. The spec was vague and nobody checked. Pathmode's MCP server checks it. Six calibrated gates, no model call, names the exact blockers. Free, no account. The spec lives in intent.md in your repo. npx @pathmode/mcp-server

Direct Design removes the handoff between design and code. But it leaves the harder handoff untouched: user reality → product decisions. AI lets us ship polished experiences faster. Without structured intent, we also ship polished guesses faster. pathmode.io/blog/direct-desi…

Most product loops close on the wrong node. Signals from Slack, calls and analytics pile up as context. Agents turn the pile into PRDs, prototypes and PRs. Something ships. Then comes the arrow everyone draws dotted: shipped back to context. It stays dotted because the loop was never anchored to a decision. Context is what we know. It says nothing about what we decided it means, who confirmed that, or what outcome we expected. We put the decision in the middle instead. -Signals become evidence with a source and a date. -Evidence anchors the claims in an intent that lives in the repo, next to the code. -A person confirms, rejects or amends each claim, by name. -The agent builds only once the intent is ready, and the PR is checked against it. -The shipped outcome is measured against the outcome the intent promised. Then the outcome becomes evidence, and stale evidence reopens the intent. That arrow is solid. Context isn't judgment. A loop that only remembers what happened can't tell you whether it worked.

Anthropic’s AI-native SDLC playbook maps the execution loop. I wrote the companion I think product teams need: the loop that turns evidence into decisions, intent, and outcome learning. Sense → Decide → Specify → Learn pathmode.io/playbook/product…

OpenSpec structures the change. We built a small layer for what comes before it: who is affected, what should observably change, what supports the decision, and how you’ll know it worked. Free local preflight + an experimental intent.md schema: pathmode.io/openspec