Estimate, Then Build With the Agent

Where we are

Today's build: not.md, the approved design

Count the code?

• A controller, a SubmissionStatusService, a scheduler change, a dialog, their tests.
• Lines of code, times hours per line.

It is not this afternoon

Your feeling of speed is not data

• Before: developers expected AI to make them 24% faster.
• Measured: they took 19% longer.
• After: they still believed they had been 20% faster.

The hours moved

A range, made twice

• Always a range: "3 to 5 hours, most likely about 3.5."
• When the use case is written: a coarse estimate, by the team, for ordering and the release plan.
• When its design is approved: the refined estimate, the one you give a date from.

Where the hours go now

• Clarify: settling the use case with the client.
• Design: the challenge loop and the design-of-record, until it merges.
• Build and review: driving the agent, reading every line of the diff.
• Verify: seeing each test row pass, end to end.

Planning poker, in hours

• Each teammate writes a range per part, privately.
• Reveal at once.
• Highest and lowest explain.
• Agree on a range.

Size it by the test list

• Each row is one behavior a person has to see working.
• It counts what the software must do. It is not yet hours.
• First estimate: by analogy to a finished change of the same size.
• After two or three use cases: your own hours per row.
• The open risks set the width of the range.

The reminder, estimated

Write it down before you build

On the issue:

Estimate: clarify and design 0.5–1 h, build and review 1.5–2 h, verify 1–2 h

In every weekly activity report line about it:

UC-NOT-remind-non-submitters: reviewed the agent's diff against the sequence diagram

Calibrate

• Estimated 8 to 16, logged 18: ratio 1.5.
• Next use case you would call 4 to 8: say 6 to 12.
• A slip you see coming goes to the client at the next meeting, not on the date.

Then look back

• Which part missed most?
• What did you not know when you estimated?
• What will you do differently next time?

In your team meeting, by Sunday

• Your build-context issue gets a refined estimate before the agent builds.
• Before Checkpoint 2: planning poker for every use case not yet designed, its coarse estimate on its issue.
• Your weekly activity report lines carry the use case ID.
• Checkpoints 2 and 3: estimate, actual, ratio, and one sentence on the biggest miss.

Size the step to the review

The reminder, in four commits

• Trunk: SubmittableItem, WeekKeys, SubmissionStatusService, ReminderService, two new queries. Pause.
• The two route rules in SecurityConfiguration, alone.
• ReminderController and the dialog.
• The moved WeeklyReminderScheduler.

The team's settings file

{
  "permissions": {
    "deny": [
      "Bash(git push --force *)",
      "Bash(gh pr merge *)",
      "Bash(gh repo delete *)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)"
    ]
  }
}

Before Friday

• Read deny rules for your secrets in the team's .claude/settings.json, by pull request.
• Ask the agent to read .env. Watch it refused.
• Charter line: no dependency without a person's check.
• Checked at Checkpoint 2.

Code you did not write

• Asked to document existing code, the agent writes down what it does, bugs included.
• A missing check, read back, becomes a requirement nobody chose.
• The client calls each one intended, corrected, or a defect. Not you.

The catch-all logs nothing

@ExceptionHandler(Exception.class)
Result handleOtherException(Exception ex) {
    return new Result(false, INTERNAL_SERVER_ERROR,
        "A server internal error occurs.", ex.getMessage());
}

The logging rule, for your charter

• One logger per class, one name.
• error: someone must act. warn: degraded. info: a business event. debug: development.
• Parameterized: "Sent {} of {} reminders", never concatenation.
• Every catch that does not rethrow logs the exception object.
• Identifiers, never content: no secrets or passwords; a person's ID, not their email or scores.

Review what was logged, not only whether

LOGGER.error("Could not send the weekly reminder to {} in section {}",
        student.getEmail(), section.getSectionName(), e);

Several agents at once

• Side task: it searches and reports; it edits nothing.
• Writer and reviewer: a fresh session reviews the diff.
• Fan-out by leaf: after the trunk merges.

`/implement` is a file

Write your own

• Package what your team has done by hand twice.
• A skill: .claude/skills/<name>/SKILL.md, about 20 lines.
• Copy the skeleton, not Project Pulse's paths.
• /design and /implement for your repository.
• /close-use-case: the closing checklist and the three retrospective questions.
• /estimate: count the rows and risks; leave the hours blank for a person.

Before your agent builds the slice

• Charter: your logging rule.
• Build trunk first; read it before the leaves.

Checkpoint 2: Oct 23

• The slice runs from a tagged release, v0.1.0, with release notes.
• .claude/settings.json denies reads of your secrets.
• The charter: the dependency rule, and never remove the Co-Authored-By trailer.
• The calibration table.
• The release plan: a Release value on every traceability row.