Step 1 Intent: Say What You Are Building, for Whom and How You Will Know

Every build starts with a sentence, and most builds that go wrong started with the wrong one. This chapter concerns Step 1 Intent, the first of the twelve steps defined in Chapter 4, and the developer function behind it, D1 Frame: understanding the problem and fixing intent before anyone writes or generates code. It teaches one artefact, the one-page intent, which says what you are building, for whom, what is wrong today, how you will know it works, what finished looks like, what the build will not do and who else is affected. It also teaches how to use an AI assistant for the part it does well, which is asking questions, and how to keep it from the part it does badly, which is deciding what you meant.

The reader is not assumed to be a developer. Terms are explained when they first appear. A requirement is a statement of what the software must do or be. A success measure is a number or an observable event that tells you whether the software has helped. A baseline is the value of that measure before the software exists, without which no change can be shown. A non-goal is something a reader might reasonably expect the software to do and that it deliberately will not. The build record is the file, introduced in Chapter 4, that carries one build from its first sentence to its handover; its first section is the intent, and this chapter writes it.

From a first prompt to a one-page intent with a gate

Figure 5.1: From a first prompt to a one-page intent: the assistant asks, the builder answers, a colleague reads the page back and the line manager approves scope and non-goals.

The chapter builds on two conclusions of the earlier volumes. AI Developer, Chapter 5, set out framing as the first of the five developer functions and showed that the cost of an ambiguous requirement is paid later, in rework, by someone else (86, Nordqvist, 2026). AI Governance, Chapter 22, set the habit of labelling every statement about the future as observable, expected or speculation (75, Nordqvist, 2026), which this chapter applies to its own claims about what assistants can do.

What a developer does at this step

A developer who is handed a request does not start by building. The first act is to find out what problem sits behind the request, and the usual way is to ask. Who will use the result? What do they do today? What happens when it goes wrong? How would we know it had worked? What is out of bounds? The questions look slow, and they are cheap compared with the alternative, which is to build the wrong thing quickly and discover it in use.

Frederick Brooks put the difficulty in terms that have lasted. In "No Silver Bullet", reprinted in the anniversary edition of The Mythical Man-Month, he argued that the hardest single part of building a software system is deciding precisely what to build (125, Brooks, 1995). The essay is an argument from experience, not a measured effect, and it predates generative AI. Its relevance is structural. If a tool takes over the work of turning a description into code, the work that remains is the deciding, and a builder who skips it has skipped the part that was always hard.

Professional practice gives this deciding a form. Requirements engineering standards such as ISO/IEC/IEEE 29148 describe the information a requirements process should produce and keep (18, ISO/IEC/IEEE, 2018); the entry in the bibliography rests on the catalogue record, since the text of the standard was not read, and it is cited here only for the existence of that body of practice. A developer does not apply the standard to a small internal tool. A developer asks its questions in proportion, and writes the answers down in a place where the next person will find them.

The cost of ambiguity

Ambiguity is a gap between what the person who asked meant and what the person who builds understood. It is invisible when it is made, because both people believe they agree. It becomes visible when something is built that satisfies the words and misses the purpose. A request such as "show the opening hours of all our service points" can mean a page for residents, a report for managers or a check on three data sources, and each of these is a different build with different users, different data and a different test of success.

The cost has two parts. The first is rework, which is visible and counted. The second is the decision that nobody made: where a gap is left open, whoever builds fills it with a plausible choice, and the choice stays in the software unrecorded. Chapter 8 returns to this under Step 4 Specification. At Step 1 the aim is smaller: to reach the point where the purpose can be stated in one sentence that a colleague reads and understands without being told more.

The seven parts of the one-page intent

The one-page intent has seven parts. None needs more than a few lines. Together they fit on a page, which is the point: a builder who cannot fill a page has not finished thinking, and a reader who must read ten pages will not.

Purpose, in one sentence. What the build does, for whom, in a form that names the thing and the action. "A tool that helps with opening hours" is not a purpose. "Report every week where the opening hours of the service points differ between three sources" is. A test for the sentence is whether a colleague could say what the build would not do, from the sentence alone.

The user. The people who will use the result, by role, and the person who will act on what it says. A tool whose report nobody reads has no user, whatever it computes.

The problem now. What happens today, without the build, in observable terms: who does what by hand, what goes wrong, how often. This part is the evidence that the build is worth making, and it is the part builders most often leave out because the need seems obvious to them.

The success measure. What will be counted or observed to show that the build helped, with the source of the count, the baseline and a target. The baseline is what makes the measure honest; a measure without a baseline reports a number and cannot report a change. The measure also states its limits. A before-and-after count of one category, with no comparison group, shows that the number moved and does not show why, and the intent says so in a note beside the target.

What done looks like. Three to five statements, each of which a person other than the builder can check by looking or running the build. "It works" is not one. "One command compares all 24 service points and writes a report" is. These statements become the first acceptance criteria when Chapter 8 writes the specification.

Non-goals. What the build will not do. This is the part of the page that prevents scope drift, which is the slow growth of a build beyond what was agreed, one reasonable addition at a time. A non-goal is most useful when it names something someone will ask for. "Writing to the claims system" is a useful non-goal. "Anything unrelated" is not.

Who else is affected. The people who are not users and who will nevertheless notice: those whose figures are compared, whose work changes, who receive a message the build produces, whose data it touches. This part is also where the question of personal data first appears, and Chapter 6 takes it up under Step 2 Tier.

The page ends with the gate record (who read it back, who approved it, when, and when it must be reread), which is described in the practical guide below.

What vibe coding does instead

Vibe coding, in the dictionary's sense, is writing code with AI assistance in a somewhat careless fashion, where the person describes what is wanted and often does not fully understand the result (55, Merriam-Webster, 2025). Its first step is the prompt, and the prompt is a solution. "Build me an app that shows opening hours for all our service points" names a thing to be built. It does not say who will use it, what is wrong today or how anyone will know that it helped. The assistant does not ask. It builds, and the result is immediate, fluent and plausible.

Three consequences follow, and they are the gap this step closes.

First, the prompt fixes the solution before the problem is understood. An app that displays hours is not a tool that finds disagreements between sources, and a builder who has received the first is less likely to see that the second was needed. The thing exists, and its existence is persuasive.

Second, there is no definition of done. Without a statement of what finished looks like, the build is finished when the builder stops, and the builder stops when the conversation stops being fun or the output looks right. Nobody else can check, because nobody else was told what to check.

Third, scope drifts in the direction of the conversation. Each new prompt adds a feature, and no prompt removes one, because nothing was written down to measure against. The build records what was said last, not what was agreed first.

What the research shows about this is limited, and the book says so. An interview study of 22 product team members from enterprises, startups and academia found that vibe coding, in which people describe intent in natural language and AI turns it into prototypes and code, moves through four stages of ideation, generation, debugging and review; participants reported faster iteration, lower barriers to taking part and concern about unreliable code, integration problems and over-reliance on AI (104, Li et al., 2025). The study is a preprint based on interviews, and only its abstract was read for this book. It describes how people work. It does not measure scope drift or the cost of a missing intent, and no study read for this book does. The claim of this section is therefore the book's own conclusion from the structure of the practice: when the first act is a solution, there is no earlier place in the process at which the problem was written down.

A separate result concerns what a model does with whatever the description leaves out. A 2025 preprint on underspecification in prompts reports that language models infer unspecified requirements by default in 41.1 per cent of cases, and that underspecified prompts are twice as likely to regress when the model or the prompt changes (154, Yang et al., 2025). The study concerns requirements inside prompts to language models, and its models and tasks are not the builder's. The mechanism is what matters. A gap does not stop the tool; the tool fills it with the most plausible content, and the fill is invisible in the output. The ambiguity has not been removed. It has moved from a question somebody would have asked to a decision nobody made.

Ko and colleagues, surveying end-user software engineering in 2011, cited a projection of fewer than 3 million professional programmers against more than 55 million people using spreadsheets and databases at work in the United States (105, Ko et al., 2011). The second figure counts users of a kind of tool, and the projection is American and predates present low-code platforms. It shows that building outside the development organisation is old and large. Panko's review of field audits of real organisational spreadsheets found errors in 24 per cent of 367 spreadsheets across audits from 1987 to 2000, and in 91 per cent of the 54 audited from 1997 onwards, which used better methods (106, Panko, 2000). Most audits counted only substantive errors, the spreadsheets are not AI-built applications, and the methods varied. The conclusion the book draws is its own: software built by the person who needs it, and checked by nobody else, has a high base rate of error, and the first line of defence is an intent that someone else has read.

How AI helps and where it misleads

The assistant is useful at this step in one role, interviewer, and dangerous in another, author. Four things are observable in ordinary use, and none of them changes who owns the intent.

It asks questions you had not thought of. An assistant can be told to ask rather than answer, and a list of questions the builder had not asked is cheap and real. The research on this is on small programming tasks. ClarifyGPT, a 2023 preprint, has a model detect whether a requirement is ambiguous, generate clarifying questions and regenerate code from the answers; on four function-level benchmarks, with simulated user answers, the average Pass@1 of GPT-4 rose from 68.02 to 75.75 per cent and that of ChatGPT from 58.55 to 67.22 per cent, and in a human evaluation with ten participants on two benchmarks GPT-4 rose on MBPP-sanitized from 70.96 to 80.80 per cent (155, Mu et al., 2023). Asking before generating helped on small, well-defined tasks. The study does not show that the same holds for the intent of a service used by 24 managers, where the answers are not in a benchmark and the person asked may not know them.

It drafts the page. Given the answers, an assistant will write a tidy first version of the seven parts. The draft is fast and fluent, and fluency is the risk: a well-formed sentence reads as if it had been thought through. The draft is a proposal for the builder to edit against what the builder knows.

It checks the page for gaps. Given a finished page, an assistant will list what a reader might ask and the page does not answer: who owns the notices after a manager leaves, what happens to a claim in two languages. This is cheap and useful, provided the builder answers from knowledge or from the source, not by asking the assistant to answer its own question.

It shapes the answer to the question. A model trained on human feedback may produce answers that match the view the user has already stated. Sharma and colleagues found such sycophancy across several assistants and settings (43, Sharma et al., 2023). At Step 1 this means that a builder who describes the problem with a solution already in it will get questions and a page that assume the solution. The remedy is in the prompt and in the process: ask for questions before any proposal, describe the problem and not the remedy, and have a person who was not in the conversation read the result.

The assistant as interviewer

The pattern is short. State the role, forbid the thing you do not want, set the pace and say what to produce at the end. An ordinary instruction to the assistant is enough, and nothing in it is a trick.

I want help to write down what I am going to build before I build it.
Act as an interviewer, not as an author.
Ask me one question at a time. Do not propose a solution, a design or any
code. Do not answer your own questions. If I do not know an answer, write
"open question" and move on.
Cover: the problem as it is today, who uses the result, how we will know
it helped (with a number and where it comes from), what finished looks
like, what the build must not do, and who else is affected.
When I say "summarise", write a one-page intent in seven headed parts,
using only what I told you, and list every open question at the end.
Do not fill any gap with a guess.

Three habits make the pattern work. The builder answers from knowledge or a source and says "I do not know" when that is true, because an invented answer in an interview becomes a requirement. The builder keeps the edited summary as the intent. And every line of the summary is checked against what was said, and any line the builder did not say is struck out or turned into an open question.

The place where this misleads is the plausible requirement. An assistant that is asked to complete a page will complete it with statements that are reasonable for a service of that kind and untrue of this one: that the report goes to a manager, that the data refreshes nightly, that the users are residents. None of these were said. They read as requirements and they are guesses. The defence is the read-back in the gate below, in which a colleague checks every statement against what is known, and the rule that an unsupported statement becomes an open question.

Proportion: what each tier needs

The tiers of AI Developer, Chapter 19, set how much structure a build needs, and Chapter 6 teaches how to choose one. At Step 1 the intent exists at every tier. What changes is how formal it is, who reads it and how long its evidence lasts.

Tier	The intent	Who reads it back	Who approves	Review
A personal	Five lines in a note: purpose, what done looks like, what it will not do; no file needed	Nobody; the builder reads it aloud once	The builder	At each new use
B team	The seven parts in the build record, short	A colleague in the team	The line manager, by reply or signature	Every 90 days or when scope changes
C business	The seven parts in full, with a baseline recorded with its method and date	A colleague who is not in the team, and the deputy	The line manager and, where personal data is involved, the data protection officer's screening is attached (Chapter 6)	Every 90 days, when scope changes, and at each tier change
D project	Not a citizen build; the intent is the first section of a project brief written with the development organisation	A developer	The sponsor and the development organisation	As the project directs

The review period of 90 days is illustrative and follows the rule of this book that evidence about a running tool is valid for a stated time (authoring guide, rule 21). An intent is evidence that someone understood the problem on a given date. It expires with the work: when the users change, when a data source is replaced, when a second unit starts to rely on the build, the page is reread and, where it is no longer true, rewritten.

Practical guide: Writing the one-page intent

Practical guide: Writing the one-page intent with an assistant as interviewer

Purpose. Produce a one-page intent that a colleague can read in five minutes and understand without further explanation, and record it as the first section of the build record, so that every later step has something to check against.

Roles.

The builder owns the page and answers the questions.
The deputy, the colleague named in the build record who will be able to take over, reads the page back. The deputy is chosen because they were not in the interview.
The line manager approves scope and non-goals, because a manager is the person who will be asked later why the build does what it does.
The assistant interviews and, afterwards, checks the page for gaps. It does not write the requirements.

Inputs. The request in the builder's own words; whatever the builder knows about the problem today (calls, complaints, hours spent); the source of any number to be used as a baseline; and the approved conversational assistant. No personal data and no code is needed, and none should be pasted in.

Steps.

Write the first sentence and keep it. Write down what you would have typed as the first prompt. Do not improve it. It is the record of where you started, and comparing it with the final purpose sentence shows what the interview changed.
Interview. Run the interviewer prompt above. Answer from knowledge or from a source. Say "I do not know" when that is true.
Summarise and edit. Ask for the one-page intent. Read each line against what you said. Strike out any statement you did not make, or move it to the open questions.
Find the baseline. Name the source of the number that will show change, and take the value before the build exists. If the month has not closed, record the method and the date the value is due, not a guess.
Set the non-goals. For each thing someone will ask for that you will not do, write one line. Ask the assistant to list what a reader would expect the build to do that the page has not covered, and decide each yourself.
Put the page in the build record. The intent is the intent section of docs/build-record.yaml in the repository, in the form shown below.
Read-back. Give the page to the deputy, without explanation. The deputy answers five questions in writing: what is it, who uses it, how will we know it worked, what is out, who else is affected. Where the answers differ from yours, the page is wrong, not the reader; revise it.
Approval. The line manager reads purpose, done and non-goals and approves them in writing. The approval is recorded with a date.
Run the check. Run the script below. It cannot judge whether the page is true. It checks that it is complete, that the measure has a source and a baseline or a plan for one, and that the read-back was not made by the builder.

Exit gate. The gate is met when the build record contains an intent in which all seven parts are filled, the success measure has a source, a baseline (or a method and a due date) and a target, the read-back has been made by a named person other than the builder on a stated date, the line manager's approval is recorded, and the check below passes. The gate is not "when you feel ready".

Artefact. The intent section of the build record BLD-*, with the gate record and a review date. The first sentence and the interview transcript may be kept beside it, but they are not part of the gate.

The form of the section is shown with the Nordvik Region build; the section for Hansa Mutual is shown in the next part of the chapter.

id: BLD-NR-2031-0001
name: service-point-check
opened: 2031-09-08
builder: Hanna Wikström
deputy: Elin Berg
intent:
  purpose: >-
    Report every week where the opening hours and service notices of the
    24 service points differ between the citizen portal, the phone-service
    script and the notices spreadsheet.
  user: >-
    The e-services team, who correct the sources, and the service-point
    managers, who read the weekly report.
  problem_now: >-
    The three sources disagree after every change. Residents travel to a
    service point that is closed and then phone the phone service.
  success_measure:
    what: Calls to the phone service categorised "wrong opening hours" per month
    source: Phone-service call log, category count
    baseline: {value: 41, period: 2031-08}
    target: At most 20 a month in the first full month on a schedule
    note: Before-and-after count of one category; no control group
  done:
    - One command compares all 24 service points, SP-01 to SP-24
    - The report names every mismatch with the service point and the field
    - The tool only reads; it never writes to any of the three sources
  non_goals:
    - Correcting the sources automatically
    - The printed leaflet, which is produced from the portal export
    - Opening hours of anything other than the 24 service points
  affected:
    - Service-point managers, whose figures are compared
    - Phone-service agents, who answer the calls
    - Residents, who rely on the published hours
  open_questions:
    - Who owns the notices spreadsheet after a manager leaves?
  gate:
    status: met
    date: 2031-09-10
    read_back_by: Elin Berg
    approved_by: Gunilla Roos
    review_by: 2031-12-09

The check is a short Python script. Python is the programming language used throughout this book, and PyYAML is a library that reads files in the YAML format, the plain-text format of the record above. The script reads the build record and prints either the problems it finds or a statement that the gate is met.

"""Step 1 gate check: is the intent section of a build record complete?"""
import re
import sys

import yaml

REQUIRED = ["purpose", "user", "problem_now", "success_measure", "done",
            "non_goals", "affected"]


def check(record: dict) -> list[str]:
    problems = []
    intent = record.get("intent") or {}
    for key in REQUIRED:
        if not intent.get(key):
            problems.append(f"intent.{key} is empty")
    purpose = str(intent.get("purpose", ""))
    if len(re.findall(r"[.!?](\s|$)", purpose)) > 1:
        problems.append("intent.purpose is more than one sentence")
    measure = intent.get("success_measure") or {}
    for key in ("what", "source", "baseline", "target"):
        if not measure.get(key):
            problems.append(f"success_measure.{key} is missing")
    baseline = measure.get("baseline") or {}
    if baseline and "value" not in baseline and not (
            baseline.get("method") and baseline.get("due")):
        problems.append("baseline needs a value, or a method and a due date")
    gate = intent.get("gate") or {}
    if gate.get("status") == "met":
        for key in ("date", "read_back_by", "approved_by"):
            if not gate.get(key):
                problems.append(f"gate.{key} is missing")
        if gate.get("read_back_by") == record.get("builder"):
            problems.append("the read-back must be by someone other than the builder")
    else:
        problems.append("gate is not met")
    return problems


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as handle:
        found = check(yaml.safe_load(handle))
    print("\n".join(found) if found else "Step 1 gate: met")
    sys.exit(1 if found else 0)

Saved as check_intent.py beside the record and run with python check_intent.py docs/build-record.yaml, it prints Step 1 gate: met for the record above. Change the read-back to the builder's own name, or empty the non-goals, and it lists the problem. The script is a gate in the sense of Chapter 4: a check that the builder cannot talk round, because it reads the file and not the builder's account of it. It is also limited. It cannot tell whether a non-goal is a useful one, which is why the read-back by a person exists.

The two builds at this step

Both builders did this step in September 2031. Neither organisation had yet opened its builder workspace: the Region's opens on 6 October and the group's lane on 13 October (Chapter 17). The interview was therefore held with the conversational assistant that each organisation already approved, which is Mode 1 Conversational assistants, with a description of the problem typed in and no data, no repository and no code. The builders did not yet hold a mandate for the assistant, and none was needed, because at this step the assistant had no access to anything.

Hanna Wikström and service-point-check

Hanna Wikström, product owner of the e-services team at Nordvik Region, opened the build record BLD-NR-2031-0001 on 2031-09-08. Her first sentence was: "Make an app that shows the opening hours of all our service points." She had been building prototypes with the assistant since 2030 and was used to receiving a working page within minutes.

The interview changed the sentence. Asked who would use the app, she found she had been thinking of residents, who already have the portal. Asked what was wrong today, she described the phone service: residents who had travelled to a closed service point and phoned. Asked what the cause was, she said the opening hours and notices were kept in three places that were edited by different people at different times, and that they disagreed after nearly every change. The problem was not that hours were hard to see. It was that the sources did not match. The app she had asked for would have shown one of the three sources more attractively, and the disagreement would have remained.

The purpose became: report every week where the opening hours and service notices of the 24 service points differ between the citizen portal, the phone-service script and the notices spreadsheet. The user became the e-services team and the service-point managers. The success measure used a number the phone service already kept: calls categorised "wrong opening hours", 41 in August 2031. Hanna set a target of at most 20 a month in the first full month on a schedule, and wrote beside it that the comparison was a before-and-after count of one category with no control group. The assistant suggested, as a non-goal, that the tool should correct the sources automatically; Hanna adopted the opposite, because the people who own each source should decide what is right, and wrote it as a non-goal and, later, as a never-do rule in the specification. The printed leaflet was excluded because it is produced from the portal export, and a match with the portal covers it.

Elin Berg, a business analyst in the e-services team and Hanna's named deputy, read the page back on 2031-09-10 without having been in the interview. Her written answers matched Hanna's on four of the five questions. On the fifth, who else is affected, she added the phone-service agents, who answer the calls and would see them fall or not. Hanna added them. Her line manager, Gunilla Roos, approved purpose, done and non-goals the same day. One open question stayed open: who owns the notices spreadsheet when a manager leaves. It is recorded in the intent, and Chapter 15 on Step 11 Own answers it.

Gate status recorded in BLD-NR-2031-0001: Step 1 met on 2031-09-10; read-back by Elin Berg; approved by Gunilla Roos; review by 2031-12-09.

Katarzyna Nowak and claims-doc-check

Katarzyna Nowak, team lead of a motor claims team in the Polish service centre of Hansa Mutual, opened BLD-HM-2031-0001 on 2031-09-15. She had ten years of claims experience and no experience of building. Her first sentence was: "Build me something that tells the handlers what is missing from a claim." The group's approved conversational assistant interviewed her. Her answers contained none of the claimants' data, and she pasted none in.

The interview narrowed the sentence in three places. Asked which claims, she began with all motor claims and, asked what the handlers did with each type, realised that injury claims are handled differently and by different people; she moved them to a question for the data protection officer, and Chapter 6 shows what came of it. Asked who would send a request for a missing document, she first said the tool would, then, asked what would happen if the tool were wrong about a claimant, said the handler would: the tool would draft, the handler would review and send. Asked in what language, she answered that claimants write in Polish, German and English, and that a request in the wrong language is worse than a late one.

The purpose became: list the documents still missing from each motor property-damage claim file and draft a request text for the handler to review and send. The success measure was the median number of calendar days from registration of a claim to a complete file in the pilot team, taken from the claims core. The September figure was not yet available when the intent was written, because the month had not closed. Katarzyna recorded the method, the source and the date the value was due, 2031-10-02, and the gate accepted that; the value came afterwards: 6.8 days over 212 claims. The target was below 6.0 days in the first full month of use, with a note that the comparison would be before and after, and that other changes in the same period would not be controlled.

The non-goals were the ones the interview had produced: the tool decides nothing about a claim, a claimant or a handler; it sends nothing and writes nothing to the claims core; it does not process injury claims or any free-text field. Marek Zieliński, senior claims handler and the named deputy, read the page back on 2031-09-17. His answers differed on one point: he took "complete file" to mean complete in the claimant's view, and Katarzyna meant complete by the group's rules. The difference mattered because the two can disagree. She added the group's rules as the definition and listed the document types per claim type as an open question, to be answered from the rules at Step 4. Joanna Kaczmarek, head of claims operations at the centre, approved the page.

Gate status recorded in BLD-HM-2031-0001: Step 1 met on 2031-09-17, with the baseline method and due date 2031-10-02 recorded and the value to follow; read-back by Marek Zieliński; approved by Joanna Kaczmarek; review by 2031-12-16.

Across the degrees of delegation

The table sets out what the builder's assistant may do at this step, by degree of delegation and usage mode. Both builders used the assistant at Mode 1; the table also shows where the work would go if a builder used a tool at a higher mode.

Work at this step	Usage mode	Degree of delegation	Condition
Ask the builder questions about the problem	Mode 1 Conversational assistants	Level 1 Assisted	The builder answers from knowledge or a source; the assistant does not answer its own questions
Draft the one-page intent from the builder's answers	Mode 1 Conversational assistants	Level 1 Assisted	The builder edits each line; unsupported lines become open questions
List gaps in the finished page	Mode 1 Conversational assistants	Level 0 Advisory	The builder decides each gap
Write the success measure, choose the target or approve the scope	Not delegated	Not delegated	The builder proposes, the line manager approves
Read the intent back as the gate	Not delegated	Not delegated	A person other than the builder, named in the record
Act on the intent without a person (an agent that builds from the intent unattended)	Mode 3 Agentic work tools	Not at this step	A mandate and a workspace come at Chapter 7; Mode 5 is not for builders

Level 4 Autonomous does not apply at this step, because the assistant takes no action. The prohibition that bites is the one on a decision about a named person: an intent for a build that would rank or decide about a named person's employment, pay or access to work is stopped at Step 2, not drafted at a higher level. The stewardship tests apply to the page. Name: the builder, the deputy and the approving manager are named in the record. Understand: the builder can state the problem, the measure and the non-goals without the assistant. Revert: an intent is changed by an edit to the record that shows who changed it and why, and the earlier version stays in the history.

Nordvik Region and Hansa Mutual

The two intents show different failures of the same first sentence. Hanna's first sentence named a solution that would have left the problem in place, and the interview moved her from a display to a comparison. Katarzyna's first sentence named a problem correctly and left open who acts, what is in scope and in whose language; the interview fixed each. Both pages record an open question rather than a guess: who owns the notices spreadsheet (Nordvik Region) and which documents the group's rules require for each claim type (Hansa Mutual). Both baselines come from a count the organisation already kept, and both state that the comparison has no control group.

The read-backs found what the builders could not. Elin Berg added a group of people affected, and Marek Zieliński exposed two meanings of "complete". In neither case did the assistant find the gap, which supports the design of the gate: a colleague who was not in the interview is the cheapest independent reader available.

When to call a developer

Step 1 rarely needs a developer. It does need one, or a conversation with one, when the intent shows any of the following, which are stop signs for this step.

The build ranks, scores or decides about a named person, or its output will be used to do so. This is a Tier D sign, and Chapter 6 treats it. Stop and call the development organisation.
The success measure is a measure of people. A target that counts how fast or how much named staff do something is a decision about people, however it is phrased, and needs the employer's rules and the employee representatives, not a builder.
The intent cannot be written without a source the builder cannot read, such as a system whose data is needed but whose owner has not agreed. A developer or the system's owner can say what is possible.
The read-back keeps failing. If two readers in turn understand the page differently from the builder, the problem is not yet understood. A developer or an analyst can help frame it.
The build would run unattended, write to a shared system or act on money, which moves it up a tier. Chapter 6 gives the signals; the point at Step 1 is not to find this out in Step 9.

Calling a developer at this step is the method working, not failing. A developer's first contribution is usually a question the builder had not been asked.

Observable, expected, speculation

Observable. Assistants can be told to interview rather than answer, and doing so is common practice. An interview study of 22 product team members describes vibe coding as a workflow that begins with description in natural language (104, Li et al., 2025). A preprint on code generation reports that asking clarifying questions before generating raised pass rates on small benchmark tasks (155, Mu et al., 2023), and one on prompts reports that models fill unspecified requirements by default (154, Yang et al., 2025). Neither study concerns the intent of a service built by a non-developer.

Expected. That assistants will ask clarifying questions more often by default is expected, because the research on doing so is public and the benefit on small tasks is measured. It would not remove the need for a person to own the page, because the cost of a plausible invented requirement lies in what the builder accepts, and no tool can accept it on the builder's behalf.

Speculation. That an intent, once written, stays valid is not supported by any evidence in this book, and the opposite is the working assumption: an intent expires with the work, which is why it carries a review date. No study read for this book measures how often intents of citizen builds go out of date.

Summary

Step 1 Intent asks the builder to say, before building, what is being built, for whom, what is wrong today, how it will be known to have worked, what finished looks like, what the build will not do and who else is affected. The chapter concerns D1 Frame. Vibe coding begins with a solution in a prompt and has no earlier place at which the problem was written down; the research read for this book describes the workflow and measures related effects, and none measures the cost of a missing intent, so the argument is the book's own conclusion. The assistant is a good interviewer and a poor author: it asks questions the builder had not thought of, and it fills gaps with plausible content that reads as a requirement and may be false.

The practical guide produces the one-page intent in seven parts as the first section of the build record. The gate is met when the page is complete, the success measure has a source, a baseline or a plan for one, and a target, a named person other than the builder has read it back, the line manager has approved scope and non-goals, and a short script finds the section complete. The intent carries a review date, because it is evidence that someone understood the problem on a given day, and it expires with the work. Both builds met the gate in September 2031: Hanna Wikström's on 2031-09-10 and Katarzyna Nowak's on 2031-09-17. Each started from a first sentence that the interview changed, and each recorded an open question in place of a guess.

Chapter 6 takes the next step, Step 2 Tier: deciding, from five questions, how much structure the build needs, and when to stop.

Sources

Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition. Addison-Wesley Professional, 1995. (125, Brooks, 1995)
ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018 Systems and software engineering: Life cycle processes: Requirements engineering. 2018. (18, ISO/IEC/IEEE, 2018)
Merriam-Webster. Vibe coding. Slang and trending entry. (55, Merriam-Webster, 2025)
Li, J., Hou, Y., Lin, L., Zhu, R., Cao, H. & El Ali, A. Vibe Coding in Product Teams: Reconfiguring AI-Assisted Workflows, Prototyping, and Collaboration. arXiv:2509.10652, 2025. (104, Li et al., 2025)
Yang, C., Shi, Y., Ma, Q., Liu, M. X., Kästner, C. & Wu, T. What Prompts Don't Say: Understanding and Managing Underspecification in LLM Prompts. arXiv:2505.13360, 2025. (154, Yang et al., 2025)
Ko, A. J., Abraham, R., Beckwith, L., et al. The State of the Art in End-User Software Engineering. ACM Computing Surveys 43(3), Article 21, 2011. (105, Ko et al., 2011)
Panko, R. R. Spreadsheet Errors: What We Know. What We Think We Can Do. Proceedings of the EuSpRIG Spreadsheet Risk Symposium, 2000. (106, Panko, 2000)
Mu, F., Shi, L., Wang, S., Yu, Z., Zhang, B., Wang, C., Liu, S. & Wang, Q. ClarifyGPT: Empowering LLM-based Code Generation with Intention Clarification. arXiv:2310.10996, 2023. (155, Mu et al., 2023)
Sharma, M., Tong, M., Korbak, T., et al. Towards Understanding Sycophancy in Language Models. arXiv:2310.13548, 2023. (43, Sharma et al., 2023)
Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
Nordqvist, G. AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)