One document, three jobs

A plan isn't owned by one role. The same document that a developer reads as an implementation gets read by a PM as a set of product decisions and by an architect as the shape of the system. inplan is built around that: your coding agent drafts the plan and raises its open questions inline — many at once, as threads that can each go a few rounds deep — and each person answers the ones that are theirs to answer, before any code exists. Here's what that looks like from three seats.

The developer

Turning a one-line ticket into something buildable

A backend engineer picks up a ticket: “Add CSV export to the reports page.” It's five words and a dozen unstated decisions. Instead of letting the agent guess its way through them, they let it draft a short plan first — and the agent, rather than pretending it knows, marks its open questions right on the lines it's unsure about. What encoding: UTF-8, or the BOM that makes Excel behave? How should a two-million-row export come out — streamed, or built in memory? Which timezone do the date columns use? What happens if the query fails halfway through?

The engineer answers each one in a sentence, in place, and fixes the two the agent had guessed wrong. Ten minutes, mostly reading. Then the agent builds against decisions a person actually made, and the pull request that comes back is code that already does the right thing — not a confident first draft full of assumptions to unwind in review.

The product manager

Deciding the product questions without reading a diff

A PM writes the intent for a new feature — letting people invite teammates. They aren't going to write the code, and they shouldn't have to read a diff to catch a product problem hiding in it. So the agent drafts the flow and surfaces the calls that are really theirs, as inline questions. What happens when you invite someone who's already on the team? An address that isn't a registered user yet? Can any member send an invite, or only admins? What does the invitee actually see before they accept?

The PM answers in plain language, in the document, next to the step each question is about. Engineering picks the plan up already decided — no “quick question” landing in Slack halfway through the sprint, no empty state that ships because nobody said what it should say. The product thinking happened where it's cheap: before the build, not during review.

The architect

Pinning the cross-cutting decisions before anyone builds

An architect worries about the decisions that are expensive to change and easy to get subtly inconsistent once a team — and a handful of coding agents — are all moving at once. Where the service boundary sits. The shape of the data model. The order migrations have to run in. Which feature flags must move together. How the thing rolls out.

In inplan those go on the page and get resolved up front, and then the plan becomes the reference everyone builds against. That last part is the point: when three engineers are each driving a coding agent, you do not want each agent quietly re-deciding the schema or picking its own migration order. They build against one document that already answered it — consistently, because the answer is written down where every one of them can see it.

The agent drafts and asks. Each person decides in their own lane. Everyone reviews the thinking while it's still cheap to change.

Why a document, not a chat

What all three of them are leaning on is a handful of things a chat window simply can't do. You can point at the exact spot a question is about — a line, a phrase, one specific decision — instead of describing it in prose and hoping the agent looks where you meant. You can go deep on that one thread without derailing the rest, because it's its own conversation anchored to its own line. And you can leave a dozen comments in a single pass — far faster than typing them one at a time into a CLI and waiting for a reply between each. And none of it evaporates: a CLI session scrolls off and is gone within days, but the comments stay in the document — so months later the reasoning behind every decision is still right there, instead of a choice nobody can explain.

Those sound like small conveniences; in practice they change behavior. When raising a concern is that cheap and that precise, people actually raise all of them — and plan and design far more thoroughly instead of bailing into implementation before the hard questions are settled. The friction that used to make “just start coding and fix it later” the path of least resistance is gone.

The common thread

None of these three is doing anything exotic. The developer is settling implementation calls, the PM product calls, the architect structural ones — the same decisions good teams have always made. What changes with a coding agent in the loop is that these decisions get made whether you make them or not: leave one unstated and the agent fills it in, fast and plausibly, and you inherit the choice. inplan just puts the document in the middle so the right person makes each call on purpose, in one place, before it becomes a diff nobody wants to unwind.