AI Assisted C and C++

Part V · Generic Code, Data Structures, and Agent Teams

19 Directing a Team of Agents

TeamCapstoneLab: The alerts moduleInterfaces

What still holds

The student makes the final call and answers for it.

The agent may: implement, review and test, each from your written plan.

Learning objectives

After this chapter you should be able to:

Do unaided:

  1. Write a plan that divides a feature among Writer, Reviewer and Tester agents along interfaces, with one owner for every shared piece.
  2. Write a definition of done (build, tests, sanitizers, Valgrind, reviewed diff, checked callers, explain-back) and apply it to a merge you did not write.
  3. Read a git diff hunk by hunk, find the callers it does not show, and explain what the change does to ownership.
  4. Compute an estimate correction from your own work log and apply it to a new plan.
  5. Explain, with a count at the stated bound and a measurement, when the simple quadratic solution is the right one.

May delegate:

  1. Implementation, review and testing of the alerts module, each as a separate agent session working from your plan, your header and your definition of done.

Opening case

A composite case, not a real student or course.

Two days before the capstone deadline, Priyanka splits the station's last feature in two and starts two Writer sessions at once. One builds a fault counter for the alerts module on a branch called alerts. The other builds a recent-readings summary for the daily report on a branch called summary. Both need "the last n readings," so her plan names one shared helper, declared in window.hpp:

The chapter continues from here.

The loop in this chapter

Open a step to see what it asks of you and how it plays out in the Team phase.

  1. Predictwhere two Writers will disagree on the fault rule, your corrected estimate, and the first defect the instruments will find.

    Step 1 of 6 · You, no AI

    What you hand in: A written prediction: the output, the memory state, the operation count, and how sure you are.

    Why this step: A prediction written before the run is the only way to learn whether your model of the machine is right. A miss is the most useful result there is, because it shows exactly where the model is wrong.

    The first prediction is never delegated.

    Ask yourself: What will this print, what will memory look like when it ends, and how many operations will it take?

    Log the prediction in your work log · Predict in every chapter · ← Predict in Chapter 18 · Predict in Chapter 20 →

  2. Writethe plan, the alerts header with its ownership and cost comments, and the memory trace of the opening case's merge, by hand.

    Step 2 of 6 · You, no AI

    What you hand in: One small piece written by hand, to build the mental model.

    Why this step: You can only check what you could have built. Writing a small piece yourself gives you the model you will need to judge the agent's version later.

    Ask yourself: Could I write this piece again tomorrow without notes?

    Browse the companion code · Write in every chapter · ← Write in Chapter 18 · Write in Chapter 20 →

  3. Specifyalerts.hpp, the definition of done with its make done target, and the Tester's brief, with every Section 19.2 ambiguity decided.

    Step 3 of 6 · You

    What you hand in: The header or class interface, unit tests, a complexity budget and the ownership rules.

    Why this step: The specification is the contract the code will be held to. Tests written first, a cost budget and ownership rules turn "looks right" into something you can check.

    The ownership and lifetime section of a specification is never delegated.

    Ask yourself: Who allocates, who frees, what does it cost, and what input would break it?

    Prompt and specification templates · Specify in every chapter · ← Specify in Chapter 18 · Specify in Chapter 20 →

  4. Delegatethe Tester, then Writers on separate branches, then a Reviewer per diff, each a separate session with only its role's inputs.

    Step 4 of 6 · The agent

    What you hand in: The implementation from your specification, or an explanation in the Tutor phase, with the prompts and transcript saved.

    Why this step: The agent does the typing; you keep the judgment. Saving the prompts and the transcript makes the delegation something you can audit afterward.

    Team Team phase: several agent sessions work in separate roles (Writer, Reviewer, Tester). You direct them and make the final call.

    Ask yourself: Did I hand over my specification and tests, and did I save what the agent said?

    Prompt templates · Delegate in every chapter · ← Delegate in Chapter 18 · Delegate in Chapter 20 →

  5. Auditread each diff and its callers, classify each review, run make done after every merge, add a test, and compare actual hours with the estimate.

    Step 5 of 6 · You and the tools

    What you hand in: The Audit Report: tests, sanitizer and Valgrind output, your own cost derivation against a timing plot, the defects found, and a keep-or-rewrite decision.

    Why this step: What the agent says is testimony until an instrument confirms it. Tests, sanitizers, Valgrind and a timing plot are evidence.

    The final judgment that the code is correct is never delegated.

    Ask yourself: What did the sanitizer report, does the timing plot match my derivation, and would I keep this code or rewrite it?

    The Audit Report template · Audit in every chapter · ← Audit in Chapter 18 · Audit in Chapter 20 →

  6. Defendwhy you accepted each merge, where every allocation is freed, and why the quadratic check is right at the stated bound.

    Step 6 of 6 · You, live

    What you hand in: A five-minute oral defense.

    Why this step: If you can explain it live, you own it. The oral checks that the understanding is yours and not the agent's.

    Ask yourself: Why this bound, what input breaks it, and where is this memory freed?

    How the loop works · Defend in every chapter · ← Defend in Chapter 18 · Defend in Chapter 20 →

What agents get wrong here

Patterns observed in agent-written code, to test for, not guarantees. If the agent no longer makes the mistake, your job is to prove it got it right, with the same instrument.

A Reviewer agreeing with the Writer in the Writer's own words

How to catch it Give the Reviewer the diff and spec only; check each claim with git grep or an instrument

Section 19.3.1 · Build tools

A review of style with nothing about memory

How to catch it Classify every comment; a memory-changing diff with no memory comment is unreviewed

Section 19.3.2

A plan that counts only generation time

How to catch it Compare with your work log; multiply your own estimate by your recent ratio

Section 19.3.3

What the chapter covers

  1. 19.1 The concept, by hand: dividing work and the definition of done
    • 19.1.1 One director, three roles
    • 19.1.2 Dividing work along interfaces
    • 19.1.3 Estimating the plan from your own work log
    • 19.1.4 The definition of done
    • 19.1.5 Branches, commits and diffs
    • 19.1.6 Reading a merge for memory: a worked trace
    • 19.1.7 Making the type carry the rule
    • 19.1.8 When the simple quadratic solution is right
  2. 19.2 Predict and check: where will two Writers disagree?
  3. 19.3 What agents get wrong here
    • 19.3.1 Agents agreeing with each other
    • 19.3.2 Reviewing style instead of memory
    • 19.3.3 Plans with unrealistic estimates
  4. 19.4 Working with the agent: the team in full
    • 19.4.1 Roles and prompts
    • 19.4.2 Reading a review critically
    • 19.4.3 What never to hand over
  5. 19.5 Lab: The alerts module
  6. 19.6 Defend it: why accept this change?

Cost thread

Two costs are measured here. The program's: frost pairing is n² comparisons, under a millisecond for a day and about a minute and a half predicted for a year, so the spec's bound, not the algorithm's name, decides whether quadratic is acceptable. And yours: the last row of the semester's work log, shown for Maya in Table 19.4 (illustrative).

Summary

  • An agent team needs a director who writes the plan and headers and routes decisions through one place, because separate sessions share nothing you do not write down.
  • Divide work by interface: every shared helper has one owner who goes first, and every declaration that returns a pointer, reference or view says who owns the result.
  • The definition of done has a machine half (one make done) and a human half (a critically read review, checked callers, explain-back). The opening case's bug passed through the human half.
  • A diff shows lines that changed, not lines whose meaning changed. Search for the callers of every changed contract, and in C++ change the type so the compiler rejects mismatched assumptions.
  • Agreeing agents are testimony twice, reviews drift toward style, and agent plans estimate the cheapest sixth of the work. Correct estimates with your own log's ratio.
  • The simple quadratic solution is right when the spec bounds n, the count at the bound is small, and a measurement agrees; write down what would change your mind.

Key terms

  • director: the person who plans a team's work, writes the shared interfaces, merges, and makes and answers for the final call.
  • definition of done: a checklist, written before work starts, of the evidence a change must produce before it is merged.
  • explain-back: explaining, with the agent closed, every line of a change that allocates, frees or stores a pointer, reference or view, and drawing its memory.
  • conceptual integrity: the property of a design whose decisions come from one consistent source (Brooks 1975).
  • commit: a saved snapshot of a project's tracked files, with a message giving the reason.
  • branch: a name for a line of commits, used to keep one task's changes separate until they are merged.
  • merge conflict: the state in which two branches changed the same lines, so git stops and the person merging must choose.
  • diff: a listing of the lines removed and added between two versions of a file.
  • hunk: one block of a diff, headed by @@ -old_start,old_count +new_start,new_count @@.
  • estimate ratio: actual hours divided by estimated hours over past tasks, used to correct a new estimate.

Connections

Where this chapter and another point to each other most often.

See it on the map

Further reading

  • Brooks (1975), The Mythical Man-Month: the essays on the man-month and on conceptual integrity, whose arguments about coordination apply to agent teams almost unchanged.
  • Fagan (1976): the paper that made code inspection a checklist-driven, measured activity.
  • Parasuraman and Manzey (2010): a review of complacency and automation bias, the human half of the agreement trap.
  • Myers et al. (2011), The Art of Software Testing, early chapters: why a test exists to find failures.
  • Smith (2026a), the companion book: estimation and agent teams at professional scale.