Draft pull requests: buying early feedback before the polish

The most expensive feedback in software is the kind that arrives after the polish. You spend two days refining an approach, open the PR, and the first comment questions the approach itself. A draft pull request exists to make that conversation happen two days earlier, while the change is still cheap to redirect. GitHub’s own docs define the mechanics simply: a draft cannot be merged until you mark it ready for review, and marking it ready is what triggers review requests to code owners. Everything interesting about drafts follows from those two properties.

What a draft pull request is for

Drafts decouple “the code is pushed” from “the code is ready for your judgment.” That gap is where cheap feedback lives. Open a draft when the skeleton of an approach exists: the new module boundary, the schema change, the API shape, with half the error handling missing and the tests stubbed. A colleague can look at the direction in five minutes and either nod or save you days. This is the same economics that make small PRs work: feedback value decays with the amount of work already stacked on top of the decision being questioned. A draft moves the review of the riskiest decision, the design, to the moment it is cheapest to change. The state costs you nothing to enter: open the PR as a draft from the start, or convert an existing one back to draft when review reveals the design needs another lap. CI keeps running either way, so the feedback you get is grounded in a building change, not a sketch.

Etiquette: say what feedback you are asking for

The failure mode of drafts is ambiguity. A reviewer opens one and does not know whether to comment on the approach, the naming, the missing tests, or nothing at all, so they either waste effort nitpicking scaffolding or skip it entirely. The fix costs one sentence at the top of the description: “Looking for feedback on the retry strategy in client.ts; ignore the tests, they are placeholders.” Scope the ask, name the files that matter, and state what is deliberately unfinished. Reviewers of drafts are volunteering time ahead of the formal request, and the same courtesy that makes any PR reviewable, context up front, applies double when the code itself is admittedly rough.

Drafts vs the WIP title convention

Before drafts existed, teams typed WIP into titles and hoped. The difference is enforcement. A WIP title is a string; nothing stops a distracted teammate from merging it, and deleting the prefix notifies no one. A draft is a state: GitHub blocks the merge until you mark it ready, and the ready-for-review transition requests reviews from code owners at that moment, which makes the start of formal review an explicit, logged event rather than a title edit someone may or may not notice. You can also convert a ready PR back to draft when review surfaced something structural, and people already subscribed stay subscribed. If your team still uses WIP titles, the migration is one click per PR and a habit change, and the habit pays for itself the first time a half-finished change does not get merged on a Friday.

Drafts and agents: the holding pen for generated code

Agent-written code gives drafts a second career. The person who ran the agent is the author of record, but they have not read the diff yet, and until they have, the change should not be asking for anyone else’s time. Landing agent output as a draft makes that state explicit: CI runs, the diff is visible, nothing can merge, and no code owner has been paged. The human then does author self-review inside the draft: read every line, delete the weirdness, and write down what was asked for and what the agent chose, the intent capture we argued for in capturing intent for AI changes. Only after that does the draft become ready. The conversion is the accountability boundary: it is the author asserting that a human has read this code and stands behind the request for review.

When to convert to ready

Convert when three things are true. The open questions you wanted early feedback on are resolved or explicitly deferred with a note. The change is complete enough that a reviewer’s comments will target real code, not scaffolding you already planned to replace. And you have done a self-review pass, because the ready button is a request for someone else’s scarce attention. Convert too early and you burn reviewer goodwill on churn; every force-push that rewrites half the diff after review started is a tax on the reviewer. Convert too late and you have used the draft as a private branch with extra steps, forfeiting the early feedback that justified it. The draft state is cheap to hold and cheap to leave. What is expensive is pretending a change is ready when the honest answer is “almost.” If you live in the terminal, gh pr ready makes the transition a one-liner, which removes the last excuse for leaving a finished change marked as a draft overnight.