Why Every AI Coding Task Should Start With a Brief
A brief records what you asked for, verbatim, before any agent interprets it. Why Monday Morning makes the brief the first artifact of every coding task.
Most AI coding failures are not coding failures. They are interpretation failures that happened before the first line was written, and nobody kept a record of the moment they happened.
You say "make onboarding faster." The agent decides that means caching the checklist. You meant cutting three steps. By the time you see the pull request, the original ask exists only in your head, and the agent's guess is now the requirements.
Monday Morning fixes this with a deliberately small artifact: the brief. Every unit of work starts as one, and this post is about why that rule matters more than it looks.
What a brief is
A brief is a spec that has not been interpreted yet. It holds four things and nothing else:
- Intent. The request, verbatim. Not a summary, not a rewrite. The words you used.
- Parent. The roadmap milestone this work serves, by name. A brief without one is refused.
- Guide. Attachments, if any: a screenshot, a design canvas, a reference file.
- Via. Who filed it: the roadmap, the board's dispatch bar, an issue, an idea, the command line.
There are no requirements. There is no out-of-scope list. The tasks section is present but empty. That emptiness is the point. Zero tasks is how the board recognises a brief as unshaped, and unshaped is an honest state rather than a missing one.
If you have read our earlier piece on spec-driven development, a brief is the stage before that spec exists. It is the input to shaping, not the output.
The problem a brief solves: interpretation without a record
Every time you hand a request to an agent, an interpretation happens. Someone turns "make onboarding faster" into a list of concrete things to build. The question is only whether that interpretation is visible.
When you prompt an agent directly, the interpretation happens inside the model, in the first few seconds, and is never written down. The agent proceeds as if its reading were the ask. Later, when you review the work, you are comparing the output against the agent's reading, because that is the only thing on paper.
A brief separates the ask from the reading. The intent is frozen first, in your words. Shaping then produces numbered requirements from that intent, and those requirements are a distinct artifact you can look at and disagree with before any code exists.
This sounds like ceremony. It is the opposite. It is the minimum record needed to answer the question "did we build what was asked?" with something other than memory.
Why intent is stored verbatim
The intent field on a brief is double-quoted, escaped, and copied exactly. Monday Morning does not tidy it, expand it, or turn it into a title. The title and the one-line summary are derived separately.
This is a design decision with a specific reason. Any rewrite of your ask is already an interpretation. If the tool paraphrases you at filing time, the paraphrase becomes the record and the original is gone. Verbatim intent means the shaped requirements can always be checked against the source, and a reviewer can say "R3 is not in the brief" and be right or wrong on evidence.
It also keeps the field addressable. A UI, a verifier, or another agent can read the intent to learn what was asked for, without parsing prose that a human wrote for another human.
Why a brief must name a milestone
A brief cannot be filed without a parent. Try, and the writer refuses before anything touches disk. Off-roadmap work is allowed, but you have to say so explicitly and give a reason.
The reason is orphan work. On a team where agents can run unattended, work that serves no stated objective tends to accumulate. Each piece looked reasonable when it was dispatched. Six weeks later there are forty finished specs and nobody can say which milestone any of them moved.
Naming a parent at filing time costs one decision. It buys you two things. First, the roadmap derives its own state: a milestone is shipped when every brief under it is done, with no checkboxes to maintain. Second, when a spec is verified, the verifier reads the milestone's claim as the spec's objective. The work is measured against the reason it exists, not just against its own task list.
Why a brief has no requirements yet
The obvious shortcut is to write the requirements at the same time as the ask. Monday Morning deliberately does not let a brief carry a placeholder requirement, and the shaping stage refuses to run on anything that already has tasks.
Requirements are where interpretation lives. Writing them in the same breath as the ask collapses the two states back together, and you lose the thing the brief was protecting. Shaping is a separate act, done later, possibly by an agent, and the result is reviewable precisely because it was not baked in at filing time.
There is a corollary that took us a while to learn and is now a standing rule on our own team: a brief is always shaped before implementation, whatever its size. Never write the requirements after the code to satisfy a verifier. Requirements authored after the fact are a description of what was built, not of what was asked, and a verifier keyed to them will pass everything.
What shaping does with a brief
Shaping takes a brief and produces a real spec from the brief's own record, in one unattended pass. The agent reads the verbatim intent, the milestone's claim, and whatever the guide points at. It writes numbered requirements, an out-of-scope list, and tasks that each cite the requirement they satisfy.
That last part matters. Every task carries an R-id. The verifier keys its scorecard to those ids and checks that every requirement has a task. A task that cites nothing, or cites a requirement that does not exist, is rejected at creation. The join from intent to requirement to task to verification is unbroken, and it began with the brief.
Because shaping is a distinct step, it can run headless. A brief dispatched from the board at 5pm can be shaped by an agent overnight and waiting for your review in the morning, with the proposed requirements laid out beside the intent that produced them. You approve the interpretation, not the code.
A brief is the smallest honest unit of work
Here is the framing that made the rule stick for us. A brief is the smallest thing you can file that is still honest about what it is.
It does not pretend to know the requirements. It does not pretend to be scoped. It says: this was asked, by this person, for this reason, with these references. Everything after that is derived and can be regenerated. The brief cannot be, because it is the only artifact that records the ask before anyone touched it.
That is why it is significant. Not because the format is clever, but because it is the one moment in the lifecycle of a task where you can capture the truth cheaply. Every later artifact is an interpretation of it.
How to file a good brief
The bar is low on purpose, but a few habits make shaping go better:
- Say it the way you would say it to a teammate. One or two sentences. "Users are dropping out of the first-run checklist" is a complete intent.
- Attach the thing you are looking at. If a screenshot or a design canvas prompted the ask, put it in the guide. The shaper will read it.
- Pick the milestone honestly. If the work fits nowhere on the roadmap, say so with a reason rather than forcing it under something adjacent. The board will offer to mint a new milestone.
- Do not pre-scope. Resist writing "but not X" into the intent. Out-of-scope is a shaping decision, and you will get to review it.
- Shape before you start. However small the ask looks. The one-line briefs are the ones most likely to be misread, because everyone assumes they are obvious.
The takeaway
Agents are good at building what they are told. The failure mode is that "what they are told" is usually reconstructed from a prompt that was never saved, interpreted in a way that was never shown, and verified against requirements that were written afterward.
A brief is the fix for the first of those, and it makes the other two fixable. File the ask before anyone interprets it. Shape it as a separate step. Verify against the shape. It is one small artifact, and it is the reason the rest of the chain can be trusted.
Frequently Asked Questions
- What is a brief in Monday Morning?
- A brief is a spec that has been filed but not yet shaped. It records the request verbatim as an intent, names the roadmap milestone it serves, carries any attachments as a guide, and has no requirements or tasks yet. Shaping turns it into a spec with numbered requirements and tasks.
- How is a brief different from a spec?
- A brief is the earliest state of a spec. It holds the ask and the reason for it, in your words. A spec adds the interpretation: numbered requirements, an out-of-scope list, and tasks that cite those requirements. Every spec in Monday Morning starts as a brief, whether it is one sentence or a design handoff.
- Why should I write a brief before letting an AI agent code?
- Because the agent will otherwise invent the requirements itself, and you will have no record of what you actually asked for to check the result against. A brief freezes the ask before interpretation begins, so verification has something honest to measure against.
- How long does a brief need to be?
- One sentence is enough. The intent field is meant to hold the request as you would say it to a teammate. Detail belongs in attachments and in the shaped spec that comes later, not in the brief itself.
- Can an AI agent shape a brief into a spec on its own?
- Yes. Monday Morning shapes a brief into requirements and tasks in one unattended pass from the brief record alone. The agent reads the intent, the milestone claim, and the attachments, and proposes requirements you can review before any code is written.