# Deciding whether to build it at all

> An agent makes building cheap, so the judgment moves before the code. Find the problem behind a request, price the change by what the team owns afterwards, and write success criteria a stranger could check.

Page: https://schubergphilis.github.io/ai-training/coding-with-agents/deciding-what-to-build/
License: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/

A feature request arrives for the to-do program from the first lesson:
"Add due dates. I want to type `todo add "Renew the domain" due friday`
and see what is late." The agent could have it working in twenty minutes,
tests included. In this lesson we decide whether it should. We ask who has
the problem before we propose a change, and we weigh what the change costs
to keep against what it costs to write. The request that passes both
questions gets criteria a stranger could check. The lesson has no code to
run. The to-do program is a fixture, so treat it as a small internal tool
that a team of four uses every day.

Cheap implementation moves the engineer's work earlier. When writing the
code took a week, a bad idea died of its own cost before it shipped. When
the agent writes it in an hour, the idea ships. The team then finds out
what it costs over the years of keeping it. Brilliant's skills map for
coding with AI files this judgment under taste and treats it as a skill
of its own, separate from getting the agent to produce code (Taste: what is worth building, Brilliant, Coding with AI skills map).
Claude Academy's fluency course for builders makes the same split between
deciding what to hand over and judging what comes back
(AI Fluency for builders, Claude Academy). The decision is yours, and it comes
before the brief.

## Who has the problem

A request names a solution. Your first job is to find the problem behind
it and the person who has it. "Add due dates" came from one colleague.
Ask what happened last week. The answer might be "I forgot to renew the
domain and the site went down for an hour". That problem costs the team
an hour of downtime a year, so it deserves a fix. A calendar reminder
solves it for that one colleague today. So does a line in the team's
weekly checklist, or a note in the item text (`Renew the domain before
Oct 1`).

Write the alternatives down before you choose, and always include doing
nothing. Doing nothing has a cost too, and naming it is what makes the
comparison fair. If the domain lapses once a year and takes an hour to fix,
the cost of not building is an hour a year and some embarrassment. If four
people each miss a deadline a week, it is a different decision.

The comparison turns a wish into a decision. "We could add due dates,
put the date in the item text, or use the shared calendar. The calendar
already sends reminders, and the item text works with no change to the
program, so we start with the item text and revisit when a second person
asks." Anyone reading that sentence in six months knows what was
considered and why the team chose as it did. A second request is then
evidence, and the decision is reopened on evidence instead of on
enthusiasm.

## The cost of keeping the change

The build cost is the part the agent removes. The team still pays the
cost of keeping the change: every change you accept is code the team reads,
tests, patches and explains for as long as the program exists. For due dates in the
to-do program that means a date format to document, a parser to keep
working, a `list` output that got longer, a test file that grew, and a
question every new user asks about what `friday` means on a Saturday.
None of that shows up in the diff the agent hands you. All of it shows
up in the next year.

Two more questions belong in the same weighing. What does the change
displace? A program with `add`, `list` and `done` fits in one screen, and
its README fits in ten lines. Each feature makes the next one a little
harder to add and the whole a little harder to hand to a new colleague.
And what happens if it is never built? Say it out loud. Often the
answer is "nothing much", and that answer ends the discussion.

#### Pitfall: A package for one date format

An agent was asked for due dates and added `dueparse`, a small package
that turns phrases like `friday` and `in 3 days` into dates. It worked on
the first try, and the request was closed the same afternoon. The
package pulled in two others. The next year, one of them changed its
license, and the year after that a security advisory named the parser,
and its single maintainer had stopped answering. The team patched around
it four times and finally replaced it with a twelve-line function that
accepts one format, `YYYY-MM-DD`. The rule: a change that takes an hour
to write and years to own is priced by the years. Ask what the team
keeps before you accept what the agent wrote.

#### Checkpoint: Which costs stay?

Buckets:

- Paid once, while building
- Paid for as long as the feature exists

Items:

- The hour the agent spends writing the date parser and its tests
- Reading the diff before merging it
- Patching the date package when a security advisory names it
- Explaining to each new colleague what "due friday" means on a Saturday
- Writing the first version of the README section on due dates
- Keeping the date tests passing when the operating system updates its time zone data

Building as asked is one outcome. The request can also be shrunk to the
part that solves the stated problem. Or it can be answered without code,
with a line in the README, a change to a default, or a pointer to a tool
the team already has. Shrinking is the outcome that gets missed most. The
colleague who asked for `due friday` and a late list may be served by a
date that is stored and shown. That version skips weekday parsing
and leaves out any rule for what late means. It is a dozen lines with one format,
and it can grow later if the second request ever comes.

#### Checkpoint: The undo request

A colleague who uses their own copy of the to-do program writes: "Please
add an `undo` command. I keep marking the wrong item done." What do you
do first?

- Build it as asked: an `undo` command that reverses the last change, with a history file.
- Shrink it: a `reopen` command that flips one item back to not done.
- Ask which item they typed and which one got marked, before proposing anything.
- Decline: they can edit `todos.json` by hand, and the README says where it is.

## Writing down what success requires

Suppose due dates pass both questions, in the shrunk form: a date is
stored with an item and shown in the list. The next job is to write what
a finished result must do, before the agent starts. These success
criteria become the agent's target while it works and your checklist when
it hands back, and they are what stops a plausible result from being
accepted as a correct one. The brief you learned to write in the
delegating lesson had done-criteria you could tick. The same rule
applies here, and code makes it easier to follow, because behavior can be
observed and stated.

A criterion is observable when a person who was not in the conversation
could check it and get the same yes or no as you. "Due dates work" fails
that test. `todo add "Pay rent" due 2026-10-01` stores the date, and
`todo list` shows the item as `1. [ ] Pay rent (due 2026-10-01)` passes
it. Add the edge cases that matter here: an item added without a date
shows exactly as before, and `due tomorrow` is rejected with a message
that names the one accepted format.

The criteria also say what must keep working. An agent that optimizes
for the new behavior trades away anything you did not list. For the
to-do program that means the existing tests still pass, the `add`,
`list` and `done` commands still take the same arguments, and a
`todos.json` written by the old version still loads. The `AGENTS.md`
in the fixture already fixes some of these, and repeating the ones that
matter for this change costs one line each.

Last, write the out-of-scope line. The gap between "done" and
"everything the program could do better" is where the agent makes its
own choices, and one line closes it. "Not in scope: weekday names,
relative dates, any notion of overdue, color in the output." The agent
that would have added `dueparse` reads that line and doesn't.

#### Checkpoint: Which criterion can a reviewer check alone?

Four lines were proposed as success criteria for the due-date change.
Which one could a reviewer check without asking the author what it
means?

- Due dates work well for the team, and the team lead agrees with that when asked.
- A bad date such as `2026-13-45` is handled gracefully by the date parser.
- After `todo add "Pay rent" due 2026-10-01`, `todo list` prints `1. [ ] Pay rent (due 2026-10-01)`.
- The date handling code is clean, well commented, and easy to extend when reminders come later.

#### Checkpoint: Which lines belong in the criteria?

Which of these lines belong in the success criteria for the due-date
change?

Select exactly 3.

- `todo add "Pay rent" due 2026-10-01` stores the date, and `todo list` shows it after the item text.
- `python3 -m unittest -q` passes, and `todo list` prints an item without a due date exactly as it did before.
- Not in scope: weekday names, relative dates, overdue marking, color.
- The agent should make the date handling as flexible as it reasonably can.
- Store the date as a Unix timestamp in `todos.json` and format it with `strftime` in `list`.

## Exercise

Three requests have come in for the to-do program from the first lesson.
The first asks for due dates with phrases like `next friday` and `in 3 days`.
The second asks for done items to be shown in green. The third asks for the list to
be shared between a laptop and a desktop. For each, write the problem
behind it and who has it. Name at least one alternative, including doing
nothing, and then decide: build, shrink or answer without code. Reject or
shrink at least one. For each request you keep, write the success
criteria as a short list a stranger could check, including what must
keep working and a final out-of-scope line. Ten to fifteen lines per
request is enough. You do this so that the agent's speed never decides
what your team owns.

A good result names a concrete problem for each request or says that
none was found, has a decision with a reason that a colleague could
disagree with on the facts, and has criteria where every line is a yes
or no that does not need you in the room. Reflect: for the request that
cost the most to keep, how much of that cost would have shown in the
agent's diff?

Stretch: For the request you shrank, write the one-paragraph note to the person who asked, saying what you are building instead and why.

## Recap

1. A request names a solution. Find the problem behind it and the person who has it before you propose a change. Then write the alternatives down, including doing nothing (Taste: what is worth building, Brilliant, Coding with AI skills map).
2. Price a change by what the team owns after it ships, and the hour the agent spends writing it is the smaller part. A dependency for one format is patched for years.
3. Building as asked is one outcome. A request can also be shrunk to the part that solves the stated problem, or answered without code.
4. Success criteria are observable outcomes a person other than the author could check, and they include what must keep working (AI Fluency for builders, Claude Academy).
5. End the criteria with an out-of-scope line, because the agent fills the gap between done and everything it could improve with its own choices.

## References

- Taste: what is worth building, Brilliant, Coding with AI skills map
- AI Fluency for builders, Claude Academy, https://academy.claude.com/courses/ai-fluency-for-builders