Chapter 5 — Build the Core

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” — Brian W. Kernighan and P. J. Plauger, The Elements of Programming Style, 2nd ed. (1978)

“Whatever you do, work heartily, as for the Lord and not for men,” — Colossians 3:23 (ESV)

Why This Matters

Four weeks in. You have a charter, a requirements specification with acceptance criteria you wrote, decision records, a technical specification, a plan, a risk register, a walking skeleton that runs in CI, and a design review whose findings you dispositioned last Friday. Eighty hours of the hundred and sixty are gone. The hat is now the developer’s, and for the first time this term it is the only hat that matters most hours of the day. You are in construction. Everything from Weeks 1 through 4 exists so that this week you can sit down and not have to decide anything except how to make the code work. That is the whole return on the front half of an accelerated course. A student with a real specification writes code. A student without one spends this week re-litigating the design and calls it building.

There is a trap sitting in the middle of Week 5, and nearly every capstone student steps in it. Construction is where the process quietly dies. The board stops getting updated because updating it feels like overhead. The hours log goes unlogged because you are busy, and you will catch up Sunday. Commits turn into one enormous midnight dump with the message stuff. The definition of done gets silently downgraded to “it ran once on my laptop.” None of that feels like a decision. It feels like moving fast. In Week 8 it reads, to a grader, exactly like what it is: a project that had no process from Week 5 onward — and in an eight-week term, Week 5 onward is half the course.

The AI thread runs hard through this chapter, from both directions. As a tool, an assistant is genuinely good at construction — scaffolding a module, drafting a client for an API you have never used, writing the boring half of a form handler. Used well it buys hours you do not have. As a workload you are accountable for, it hands you code you did not write and may not understand, and understanding is not free. There is a real debugging tax: heavy assistant use often moves hours out of the writing column and into the figuring-out-what-this-does column rather than removing them. That tax is survivable across two hundred and forty hours. Across a hundred and sixty it is the difference between shipping and apologizing.

Which raises the question for the week, and it is not abstract for your generation: whose work is it when a machine helps you? You will graduate into an industry where a meaningful share of the code in every repository was drafted by a model. Is that code yours? Is the project yours? Is there any honest sense in which you can say I built this — and if so, what makes it true? Push the question away and you end up either paralyzed or shameless. Both are worse than the answer.

Twenty hours. Two or three real slices, each traceable to a requirement, each demoable. A record you can defend. Five minutes of working software. Let’s build.

5.1 — Vertical Slices: One Requirement, All the Way Through

A vertical slice is a unit of work that cuts through every layer of your system to deliver one observable behavior. It touches the interface, the logic, the storage, and whatever integration is involved. When it is finished, a human being can see the software do something it could not do yesterday. The Agile Manifesto’s principles put it in six words — working software is the primary measure of progress — and your Week-8 rubric agrees with them. The alternative, and the way most students naturally work, is horizontal: the whole data layer this week, the whole API next week, the UI the week after. It feels efficient. It is a trap for three reasons. Nothing is demoable until the last layer lands, so you get no feedback. All the integration risk piles into the end, in the exact week you have no slack — and here that week is three weeks away. And if you run out of time you own three-quarters of a system that does nothing, which is worth precisely zero on a rubric that grades working software.

PantryPilot — a household pantry tracker: what food you have, what is about to expire, what you can cook tonight. A real user group (a five-person house), one third-party integration (a product-lookup service), one optional AI feature. It is brief #1 in the Fast-Start Catalog and our worked example all term. Your project will look different. The shape of the work will not.

HORIZONTAL (bad) — a week of tasks that demo nothing:
  [ ] Create all six tables and migrations
  [ ] Write model classes for all six entities
  [ ] Write the repository layer for all six entities
  [ ] Stub all fourteen endpoints

VERTICAL (good) — the same week, sliced by behavior:
  [ ] FR-12  Add a pantry item by scanning a barcode
             -> scan input -> lookup client -> mapping -> same add path
  [ ] FR-04  Add a pantry item by hand (name, quantity, expiration)
             -> form -> validation -> items table -> list view shows it
  [ ] FR-18  Highlight items expiring within three days
             -> query -> date rule -> list view badge

Each of those, finished, is something you can put on a screen and show a human. Together they are the core: an item goes in, and the system tells you when it is about to go bad. Everything else in the backlog is decoration on that core. TraceLens, our contrast example, is a command-line log analyzer with no UI at all, and its slices work identically — tracelens scan <file> reads a file, parses lines, runs one detector, writes one report, exits with a meaningful status code. The observable behavior is a report and an exit code rather than a screen. It is still a vertical slice.

How many slices. Here is where this edition parts company with the long one. A sixteen-week capstone asks for three to five slices in its first construction week. You have twenty hours, and after the chapter, the reps, the quiz, the reviews, the tests, the logs, and the demo, roughly eight of them are typing. So: two slices, three if the third is genuinely small. That is the two-thirds rule showing up where it always shows up — 160 hours buys a project about two-thirds the size of a sixteen-week capstone, three to four Must features rather than five-plus, and a construction week sized to match. A student who plans five slices this week finishes Sunday with five things that are eighty percent done, which on a rubric is zero things.

Which slices, and in what order. Take the Must-have functional requirements that are not yet built and order them by one rule: the slice that would hurt most if it turned out to be impossible goes first. For PantryPilot that is FR-12, the lookup integration, because it depends on somebody else’s service and somebody else’s uptime. Discovering in Week 7 that the service rate-limits you is a catastrophe. Discovering it on Tuesday of Week 5 is a Tuesday.

Coach’s Note — A slice is not finished when the code exists. It is finished when you can show it. If you cannot describe how you would demo a task in one sentence, it is not a slice — it is a chore, and chores belong inside slices, not on the board as work of their own.

5.2 — A Definition of Done, Applied Without Mercy

You wrote a definition of done in Week 2 and reviewed it in Week 4. This is the week it stops being a document and becomes a gate.

Its purpose is to make “done” mean the same thing on Tuesday at 10 a.m. and on Saturday at 11 p.m. when you are tired and the milestone is due tomorrow. Without it, done drifts — always in the same direction, always toward “it worked when I tried it.” Most students write this:

Definition of Done
- Code is written
- It works
- Committed to GitHub

Every line is unfalsifiable. Code is written — of course it is, that is what makes it a task. It works — under what input, on whose machine, against which acceptance criterion? Committed — a commit is evidence that a file changed, not that anything finished. A grader in Week 8 cannot check one of those lines, which means they contribute nothing to your 50%.

The version to use is in code/definition-of-done.md: ten checks, each one verifiable by someone who is not you. That is the test of a good definition of done — if a line cannot be checked by a stranger with your repository open, rewrite it or delete it. Copy the file into your repository as docs/definition-of-done.md, adapt the bracketed parts to your stack, and paste the checks into your pull-request template.

One step before you commit that file, and it is the first live test of your baseline. docs/definition-of-done.md was baselined at the Week-4 design review, and item 5 of the threshold rule in Chapter 4 is changes the definition of done. So if the adapted version is materially different from the one you wrote in Week 2 — checks added, checks dropped, a standard raised — raise a CR-nnn file in docs/change-requests/ before the replacement lands: what changed, why, the impact on your remaining hours if the stricter checks add time per task, and the decision. Fifteen lines. It is the smallest change request you will write all term, and it is the one that proves the baseline meant something — a silent post-baseline overwrite is exactly what the Week-8 change-control line is looking for. If your Week-2 list already says these things in different words, keep your wording, fold in whatever it was missing, and say so in the commit message; a baseline is not a reason to keep the worse document.

One check in that file does not exist in the long edition, and it is the accelerated one:

2. Those criteria describe MY project — not the catalog brief I adapted.

You did not author your requirements from nothing; you adopted a brief and adapted it, which is the skill this course is actually teaching. The signature failure of an accelerated capstone is a requirement that quietly still describes somebody else’s project — the brief assumed a store scanner, your user has a phone camera; the brief assumed three roles, your house has one. Week 2 exists to catch most of it. Construction catches the rest, because a criterion that was never about your user turns into a feature nobody asked for, built correctly, at full price. Eight hours of typing is too small a budget to spend any of it on the catalog’s imaginary user.

Now the part that matters more than the list: apply it without mercy. A definition of done only works if it is allowed to say no. The first time you finish a slice at 11 p.m. and realize the test check is missing, you have a decision to make, and it is a decision about what kind of engineer you are becoming. Write the test. It is twenty minutes. The alternative is a project where “done” is a mood.

Coach’s Note — Put the definition of done where you cannot avoid it: a pull-request template, a pinned issue, a comment at the top of your board. Discipline that depends on remembering is not discipline; it is luck with good branding.

5.3 — Reviewing Your Own Code When There Is No Reviewer

In industry someone else reads your code before it merges. You do not have that. You have you, and you already believe your code is correct — you wrote it fifteen minutes ago on exactly that belief. Reading your own work honestly is a real skill with real technique: four passes, in this order, on every slice. Twenty minutes for a normal diff, and they routinely find what testing does not. The full expansion, with the hostile-input table, is in code/definition-of-done.md.

Pass 1 — Diff (mechanical). Do not read the files. Read the diff:

git add -A
git diff --staged            # every line you are about to commit
git diff --staged --stat     # and the shape of it

You are hunting accidents: the debug print, the commented-out block, the file you did not mean to stage, the hard-coded localhost, the TODO you wrote three hours ago. This pass catches roughly half of everything you will find, and it costs five minutes.

Pass 2 — Stranger (comprehension). Read the changed code from the entry point as if you had never seen it. The question is not is this right? — it is could someone who has never met me follow this? Ambiguous names, a function doing three jobs, a magic number, nesting four deep. If you have to reconstruct your own reasoning to read it, so will your Week-7 self.

Pass 3 — Adversary (destruction). Attack it. For every input ask what the worst thing a user, a network, or a clock could hand it: empty and ten thousand characters, zero and negative and the type’s maximum, a leap day and a different time zone, a timeout and a 429 and valid HTTP with a garbage body, an empty collection and a million-element one. You are not fixing everything you find — you are deciding: fix now, log a defect, or accept with a written reason. All three are legitimate. Silence is not.

Pass 4 — Contract (traceability). Open the requirement. Read its acceptance criteria out loud. Point, in the code, at the line that satisfies each one. If you cannot point at a line, the criterion is not met, however good the feature feels. And while you are there: is this criterion about my user? Pass 4 is where inherited scope finally surfaces, and Week 5 is the last cheap week to cut it. Two amplifiers sharpen all four. Sleep on it — a twelve-hour gap between writing and reviewing is worth more than any tool, because you cannot see your own assumptions from inside them. And open a pull request to yourself: branch, push, review the diff in the web interface, merge. The web view is unfamiliar enough to feel like someone else’s code, CI runs on the branch, and the pull request becomes a permanent record of what you reviewed and why you merged it.

Coach’s Note — The bug you cannot find is almost always in the code you are proudest of, because pride is where you stop reading carefully. When a section of your diff makes you feel clever, slow down there.

5.4 — AI-Assisted Implementation, and the Line Between Using and Submitting

An assistant will hand you a compact, confident, idiomatic function in four seconds. Your ability to debug that function at 2 a.m. in Week 7 is exactly your ability to understand it — and understanding was the part you skipped. That is Kernighan and Plauger’s warning at the top of the chapter, aimed at code you did not write at all.

This course permits and expects assistant use. The authoritative statement is the Grading Contract; the practical version is one sentence: you may use any tool to help you build, and you must be able to defend every line you ship as your own decision. The line is not drawn at how many characters the model typed. It is drawn at judgment and accountability, and that is testable.

The three tests. Before assistant-drafted code merges, run all three. Ten minutes, and they are the whole difference.

1. Explain it. Out loud, line by line, without re-reading. Stall on a line and you do not own that line yet. Read it, look it up, or delete it.
2. Break it. Feed it the hostile inputs from Pass 3. Assistant code is famously optimistic: it assumes the network works, the field is populated, the list is non-empty, the date parses. Find the assumption. That is where the real bugs are.
3. Rewrite it. Take the hardest function and retype it from memory, in your own naming, in your project’s style. If you cannot, you have found the piece you do not understand — and now you know exactly what to study. This one test is worth more than the other two combined.

Write a prompt contract, not a wish. The quality of what comes back tracks the specificity of what you asked — and a specific ask is also a record of the judgment you exercised.

Bad — the wish:

write me the barcode scanning feature

You will get a plausible file that assumes a library you are not using, a framework version you do not have, an API shape you did not design, and error handling you never specified. Then you will spend two hours reconciling it with your actual system. On a twenty-hour week, that is a quarter of your typing budget spent on a misunderstanding.

Good — the contract:

Context: <language/framework and version>, existing module `pantry/items` with
an addItem(name, qty, expiresOn) function I already wrote and tested.
Task: write a client for the product-lookup HTTP API below. Do NOT change
addItem; the client returns a product name or null and the caller decides.
Contract:
  - lookupProduct(barcode: string) -> {name: string} | null
  - timeout 3 seconds, at most 1 retry on a 5xx, no retry on 4xx
  - a 404 means "unknown product" and returns null, not an error
  - never throws; on any other failure return null and log at warn
  - the API key comes from an env var, never a literal; no new dependencies
Constraints: match the error-handling style in `pantry/items` (attached).
Then list every assumption you made that I did not state.

That last line is the highest-leverage sentence you can put in a prompt to a coding assistant: the assumptions it lists are the bugs it was about to hand you.

The debugging tax, honestly. Assistant use does not automatically make you faster, and you must not plan as if it does. A 2025 randomized trial by METR found that experienced open-source developers working in repositories they knew well took roughly 19% longer on tasks when allowed to use early-2025 AI tools — while believing they had gone faster. It was a small study, sixteen developers in mature codebases, and it does not settle the question for every setting, least of all a greenfield student project where scaffolding is a genuine win. But it should make you suspicious of your own sense of speed. Your hours log knows the truth and your feelings do not. Where assistant help reliably pays in a capstone: boilerplate you have written before, a client for an API whose docs you have read, test scaffolding, unfamiliar syntax, and explaining an error message. Where it reliably costs: anything touching your architecture, anything where the requirement is subtle, and anything you could not fix yourself.

Coach’s Note — The rule I would tattoo on a capstone student’s wrist: never merge code you could not have written, only code you did not have to. The gap between those two sentences is the entire ethics of this chapter.

5.5 — The Disclosure Log: What to Record, and Why It Protects You

Your final package includes docs/ai-usage.md. It is required, it is graded in Week 8, and it is the most misunderstood artifact in this course. Students treat it as a confession. It is your defense.

Think about what happens without it. In Week 8 a grader reads a file that does not sound like the rest of your repository. They have two hypotheses: you learned something and grew, or you pasted something you do not understand. With no log, the burden is on you to prove the first one, live, under pressure, in a thirty-minute presentation. With a log — dated, specific, showing what you asked, what you took, what you changed, and how you checked it — you answered the question in writing before it was asked. Documented use is use. Undocumented use looks like concealment, and that is an integrity matter, not a style preference. Log at the level of a session or a contribution, not a keystroke, with five fields: the date; the tool and, if you know it, the model or version; what you asked for in one line, naming the actual task rather than “help with code”; what you accepted, meaning the file or function and roughly how much survived; and what you changed and how you verified it.

Bad entry — useless to you and to the grader:

2/10 - used AI for the barcode stuff

Which assistant? Which file? Did any of it survive? Did anyone test it? A grader learns nothing except that you know the word “AI,” and a hostile reading is the only one available — you handed it to them.

Good entry — same session, honestly recorded:

### 2026-02-10 — product lookup client for FR-12
Tool: <assistant name>, <model/version if known>
Asked for: an HTTP client `lookupProduct(barcode)` — 3s timeout, one retry on
  5xx only, 404 => null, never throws. Full prompt in prompts/2026-02-10-lookup.txt.
Accepted: `pantry/barcode/client.*` — the retry loop and the response mapping,
  roughly 40 of 95 lines survived.
Changed: rewrote error handling to match `pantry/items` (the draft swallowed
  timeouts silently); replaced a hard-coded key with PANTRY_API_KEY; renamed
  three variables; deleted a caching layer I did not ask for and do not need.
Verified: 4 unit tests with a stubbed HTTP layer (200 / 404 / 500-then-200 /
  timeout), green in CI on feat/fr-12-barcode. Checked against FR-12 AC-1 and
  AC-3. DEF-014 filed for the retry-count edge case.

Read those two again. The second is not a longer confession — it is a portrait of an engineer at work. Judgment: deleted a caching layer nobody asked for. Verification: four named cases. Traceability: FR-12, DEF-014. Honesty about proportion: 40 of 95 lines. That entry earns points; the first loses them. Start from code/ai-usage-log-template.md, commit it as docs/ai-usage.md, and write the entry in the same session as the work. Reconstructing this file in Week 8 is impossible — you will not remember which of forty files the assistant touched, and the guessing will show. One more thing the log does for you, quietly. Reading back three weeks of entries tells you something no rubric can: which parts of your own system you actually understand. Where the entries are thin and honest, you built it. Where they say “accepted mostly as-is” and the Changed line is empty, you have found the module that will humiliate you in the Week-8 question period. Go read it now, while three weeks remain.

5.6 — Commit Hygiene Under Deadline Pressure

Your commit history is a graded artifact. It is also, in Week 7 when something breaks, the only tool that can tell you when the system last worked. Both facts are invisible today and decisive later.

Deadline pressure produces one particular failure: the midnight dump — forty-one files, one commit, message iteration 1. It costs nothing tonight and everything later, because git bisect is useless, git revert is all-or-nothing, and a grader cannot see a single decision you made across four days.

The discipline is small. One commit per coherent change, staged deliberately:

git add -p                     # stage hunk by hunk; you will see what you wrote
git status                     # staged, unstaged, untracked
git diff --staged              # pass 1 of the self-review, for free
git commit                     # write a real message in an editor, not with -m

git add -p is the highest-value five minutes in this chapter. It forces you to look at every hunk before it becomes history, and it catches the debug print and the stray key more reliably than any checklist.

Messages that explain themselves. The subject says what; the body says why. Why is the part that is unrecoverable later — the code always shows what.

A full message, for the record:

feat(barcode): add product lookup client for FR-12

Adds lookupProduct(barcode): 3s timeout, one retry on 5xx only. A 404 maps
to null ("unknown product") rather than an error, because FR-12 AC-2 requires
an unknown barcode to fall through to manual entry instead of failing the add.

Rejected an in-memory cache for now: NFR-03 does not require it and it would
need an invalidation story we have not designed. Revisit in Week 6 if the
rate limit bites.

Closes #34. Refs FR-12.

Two paragraphs of why, one deferred decision recorded, one issue closed, one requirement referenced — ninety seconds of typing. Many teams format subjects with the type(scope): summary convention documented at https://www.conventionalcommits.org/; adopt it or do not, but pick one shape and hold it for four weeks.

The commit you cannot take back. Under pressure is when secrets get committed — an API key, a database URL with a password, a .env you meant to ignore. Two facts to internalize: deleting it in a later commit does not remove it from history, and a key pushed to a public repository should be treated as compromised the moment it lands, because automated scrapers find them fast. The fix is not a follow-up commit — it is rotate the credential immediately, then clean the history. GitHub also runs secret scanning and can block pushes containing recognizable credential formats, but that is a backstop, not a strategy, and coverage varies by credential type. Read the diff yourself.

Coach’s Note — At the end of every working session run git log --oneline -10 and read it as a stranger. If those ten lines do not tell the story of what you built, the history is already failing at its job — and it only gets harder to fix.

5.7 — Keeping the Hours Log Honest in the Busiest Week

This is the week the hours log dies. Not Week 1, when logging felt novel. Week 5, when you are actually working and stopping to type a line into a file feels like theft from the work. So let us be blunt about what it is for, because “the rubric says so” will not survive a hard week.

1. It is your only calibration instrument. You estimated these tasks in Week 4. This week you find out what they really cost. Estimate versus actual is the most valuable professional habit this course can hand you, and it does not exist without the log. Engineers who can estimate get trusted with schedules. Engineers who cannot spend their careers apologizing.
2. It is the early-warning system for scope. Three weeks remain and sixty hours with them. If the log says you have burned a hundred and the board says half the Musts are open, you have a scope conversation to have this week, while cutting is still cheap. The brief you adopted came with a what-to-cut-first list; this is the night it earns its keep.
3. It is evidence. In Week 8 the log is part of what earns your 50%. A log that reads as if it was kept is worth points. A log that reads as if it was invented is worth less than nothing, because it puts everything else you claim under suspicion.

Log at the end of each session, in under thirty seconds. Not at the end of the week. The file is docs/hours-log.csv and the columns are the ones from Appendix A — date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes — plus one you add this week if it is not there already: ai_assisted.

date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes,ai_assisted
2026-02-10,19:00,22:30,3.50,construction,developer,FR-12 lookup client: prompt contract and draft,2.50,0.00,,yes
2026-02-10,22:30,23:30,1.00,construction,developer,FR-12 timeout the draft was swallowing,0.50,0.00,the debugging tax - in my own data,yes

Note the second row. That is the debugging tax, visible, in your own data. Do not fold it into the first — separating writing from understanding what I was handed is exactly the measurement that makes the log worth keeping.

Whatever else you shorten this week, do not shorten the schema. estimate_hours above all. It is the only value in the file that cannot be recovered afterward, it is what turns a diary into a calibration instrument, and the Week-8 estimate-versus-actual analysis is computed straight out of it. A blank estimate on a row you genuinely forgot to estimate is honest and costs one number. A log with no estimate column at all is a Week-8 deliverable you threw away three weeks before you find out.

A realistic sample covering Weeks 1 through 5 of the running example is in code/hours-log.csv — a hundred hours, uneven, with the blocked time and the debugging tax showing. Copy code/hours_report.py into your repository as tools/hours_report.py — the same tools/ directory that holds the Week-1 audit script, not script/, which is reserved for one-word command verbs — and run it every Friday:

python3 tools/hours_report.py docs/hours-log.csv

It prints the weekly rollup against plan, the phase distribution, the burn against 160 with the pace you now need, your estimate-to-actual calibration factor, and the pattern checks a grader runs. On the sample log the factor comes out 1.27× — that student’s tasks cost twenty-seven percent more than they promised, which is not a scandal, it is a multiplier to apply to every remaining estimate before promising anything in Weeks 6 through 8.

What a dishonest log looks like, and why it is obvious. Backfilled logs have tells, and each one is a fingerprint of reconstruction rather than recording:

2026-02-09,,,3,construction,developer,worked on project,,,,
2026-02-10,,,3,construction,developer,worked on project,,,,
2026-02-11,,,3,construction,developer,worked on project,,,,
2026-02-12,,,3,construction,developer,worked on project,,,,

Four identical durations. Every value a whole number. One description repeated verbatim. Start, end, and estimate_hours blank on every row, which is what happens when rows are typed at once from memory. No debugging, no reading, no dead ends, no interruptions — which is to say, no life. Real work is 1.25 here and 3.75 there, with a session that produced nothing but a fixed environment variable. Compare that block against the commit timestamps for the same days and the story falls apart in thirty seconds. Graders check. Then there is the classic fourteen-hour Sunday — one row, 14.0, “caught up.” Nobody does focused engineering for fourteen consecutive hours. What that row records is a student rebuilding a week from memory, and it converts a required artifact into evidence against you.

Reconstructing honestly, when you have genuinely fallen behind. This is allowed, and it is far better than inventing. Rebuild from evidence — git log --since=... --date=short --pretty='%ad %s', browser history, editor recents, your board — estimate in quarter hours, and mark the row:

2026-02-12,,,2.50,construction,developer,FR-04 validation and list view,,,[reconstructed from commits],no

A logged estimate labeled as an estimate is honest. An unlabeled guess is not. Those brackets cost you nothing and buy your credibility. And leave estimate_hours blank on a reconstructed row rather than back-filling it: a number invented after the session is not an estimate, and one empty cell costs far less than a calibration factor built on fiction.

Coach’s Note — Thirty seconds at the end of a session. That is the whole practice. If you cannot spare thirty seconds, you were not going to spare the four hours it takes to fake it convincingly in Week 8 either.

5.8 — The Demo: Working Software, Not Slides

Milestone 5 ends with a five-minute demo. It is small on purpose: it is the rehearsal for the thirty minutes in Week 8 that carry 10% of your grade, and rehearsal is cheaper now. The rule is absolute — a demo shows software running. Not a diagram. Not a slide reading “implemented barcode scanning.” The software, on a screen, doing the thing. Five minutes, three acts:

Act 2 is where students improvise and die. Do not. Write the script — the literal clicks or commands, in order, with the exact input values — and rehearse it once end to end. Then: seed your data (never demo on an empty database and never type a dataset live; commit a seed fixture, because typing “asdf” into a form in front of a grader makes real software look like a toy); record a fallback before the live run, because Wi-Fi fails and third-party services go down, and “here is the recording I made this morning” reads as prepared where “it worked earlier” reads as every student who ever said it; cut the setup, so nothing installs on camera; and show one failure path — an unknown barcode, a past date — because handled errors impress more than happy paths. Everyone’s happy path works.

The opening line. Compare:

Bad: “So, um, this is my project, I’ve been working on the pantry thing, let me just find the — okay, there’s a lot still to do but basically you can add items, hold on, let me restart the server…”

Good: “PantryPilot now closes FR-12, FR-04, and FR-18: a housemate can add an item by hand or by scanning a barcode, and the list flags anything expiring within three days. Here it is. I’m starting from the seeded pantry.”

Same project, same code. One of those students sounds like an engineer.

Act 3 earns the points, and students skip it. Say plainly what is not done and what it will take. “Recipe suggestion is not started. It is one slice, I have estimated six hours, and it is scheduled for Week 6 — and it is marked Should-have, so it is the first thing I cut if the lookup rate limit bites.” That paragraph demonstrates project management, honesty, and a plan, and it cannot be faked. Compare it with “yeah, there’s some stuff left.” One of those is a status report; the other is a shrug.

5.9 — Where Your Hours Went This Week

Twenty hours. A realistic Week 5 for a student on pace:

Three things to notice. Implementation is under half the week — it always is, and students who plan for twenty hours of typing finish Sunday with untested code and no demo. Debugging gets three hours by default, not “whatever is left over”; if your own log shows it eating six, that is not a personal failing, it is data — feed it into your Week 6 estimates and notice whether the six hours cluster around code you wrote or code you accepted. And by Sunday night your cumulative burn should read about 100 of 160, with sixty hours and three weeks left. That is the whole schedule, on one line.

5.10 — Interactive Lab: The Honest Hours Log

Below this chapter on the website is The Honest Hours Log. Do this lab before you touch your own log this week.

Add entries the way you would after a real session: date, duration, work package, phase, and one line about what you actually did — a deliberately trimmed subset of your real columns, because the lab is about the shape of the data, not the schema of your file. The widget builds the weekly rollup, the phase distribution, and the cumulative burn against 160 hours as you type, with the pace you would need to finish. Watch what happens to that pace number when a week comes in at twelve hours instead of twenty; in an eight-week course, one light week is an eighth of the term.

Then open the “what your grader sees” panel. It runs the same pattern checks a reader applies: identical durations repeated, round numbers everywhere, a single implausible fourteen-hour Sunday, silence in weeks your commit history says you were working. Feed it a backfilled week deliberately and watch every flag light up. Then fix the entries into something that resembles a real week — a 1.25, a 3.75, a session that produced nothing but a fixed environment variable — and watch the flags clear. What it teaches is not how to avoid getting caught. It is what an honest record looks like from the outside — and, more usefully, what your own distribution of hours has been telling you for four weeks while you were too busy to read it.

5.11 — Whose Work Is It When a Machine Helps You?

“Whatever you do, work heartily, as for the Lord and not for men.” (Colossians 3:23, ESV)

There are two cheap answers on offer, and you deserve better than both. The first is “none of it is mine.” It sounds humble. It is a way of putting down responsibility: if the machine wrote it, the machine is answerable for it, and I am off the hook when it fails. That is abdication wearing humility’s coat. The second is “all of it is mine, and I do not have to say anything.” That is not confidence; it is concealment, and it is precisely what integrity policies exist to name.

Christian thinking has a durable category that cuts between them, and it is far older than software: stewardship. “Moreover, it is required of stewards that they be found trustworthy” (1 Corinthians 4:2, ESV). A steward does not own the materials. A steward is answerable for what is done with them. The tools, the languages, the libraries, the machine on your desk, the intelligence you are using to read this sentence — none of it originated with you. Every engineer who ever worked, worked with borrowed materials, and no engineer was ever less accountable for the building because the timber grew somewhere else.

So is this code mine? is the wrong question. It asks about origin, and craft has never been settled by origin. The steward’s question is the right one: am I answerable for it? And that has a hard, checkable answer.

You are answerable for code when you chose the design it implements. When you can explain it without re-reading it. When you tested it against a requirement you wrote. When you know what breaks it. When you changed it because your judgment differed from what you were handed. When your name is on the commit and you would defend it in a room. Every one of those is a judgment a model cannot make for you, because judgment requires someone who can be held to it — and a tool cannot be held to anything. That is not a limitation of current models. It is what accountability means. Notice, too, that Scripture is comfortable with skill in a way our culture often is not. Exodus 31 tells of Bezalel, the craftsman of the tabernacle, described as filled by God with ability and intelligence and knowledge and craftsmanship — a passage that treats technical skill as a gift and as a genuine human accomplishment at once, embarrassed by neither. Gift and work are not competitors. The craftsman is fully the craftsman even though nothing he used began with him.

And notice what Colossians 3:23 changes about this particular week. “Work heartily, as for the Lord and not for men” moves the audience. Working for men, only the visible matters — the demo runs, the feature looks done, nobody knows which lines you accepted at 1 a.m. without reading. Working for the Lord, the unseen parts are the same work as the seen parts: the test you wrote when nobody would have checked, the log row for a session you could have skipped, the function you rewrote because you could not explain it. The next verse gives the reason — the reward comes from the Lord, and it is the Lord Christ you serve. That is a strange and freeing thing to believe on a Thursday night in Week 5, because it means the honest log matters even in the universe where no grader ever opens it.

“One who is faithful in a very little is also faithful in much, and one who is dishonest in a very little is also dishonest in much” (Luke 16:10, ESV). This week the very little is a spreadsheet row and a five-line entry in docs/ai-usage.md. Nobody is watching. That is exactly what makes it a test worth passing.

The practical landing: use the tool, log the use, own the result. Three clauses, and the middle one is what makes the other two honest. A student who does all three can say “I built this” with a completely straight back — not because no machine helped, but because at every point where judgment was required a person exercised it, and that person’s name is on the repository.

5.12 — Common Pitfalls

Pitfall: Planning five slices in a twenty-hour week. Example: Five requirements start on Monday; on Sunday all five are eighty percent done, none is demoable, and the milestone scores as zero features complete. Fix: Two slices, three if the third is genuinely small. The two-thirds rule is not encouragement to be modest; it is arithmetic about eight hours of typing.

Pitfall: Slicing horizontally — a week spent on “the data layer.” Example: Six tables, six model classes, fourteen endpoint stubs. Nothing a human can look at, and in Week 7 the interface still does not exist. Fix: Every task on this week’s board must end in observable behavior. If you cannot say in one sentence how you would demo it, fold it into a slice.

Pitfall: Building a requirement that still describes the catalog brief’s user. Example: FR-07 assumes three roles because brief #4 had three roles. Your project has one user, and you spent five of your eight typing hours on a permissions model nobody will ever exercise. Fix: Pass 4 of the self-review, every slice: point at the line, then ask whether the criterion is about your user. Adapting is the skill; inherited scope is the failure mode.

Pitfall: Merging assistant-drafted code you cannot explain. Example: A retry loop with an exponential backoff you did not ask for and a swallowed timeout you did not notice. It works in the demo and fails silently in Week 7, with no idea where to start. Fix: Explain it, break it, rewrite it — all three, before merge. Ask the assistant to list every assumption it made that you did not state, then check each one.

Pitfall: The midnight commit dump. Example: 41 files, one commit, message iteration 1. git bisect is useless, the revert is all-or-nothing, and the history shows a grader four days of invisible work. Fix: git add -p, one commit per coherent change, a subject that says what and a body that says why, with the issue and requirement ids referenced.

Pitfall: Backfilling the hours log on Sunday night. Example: Four rows of exactly 3.0 hours, all described “worked on project,” on days your commit history is empty. Fix: Thirty seconds at the end of each session. If you genuinely fall behind, reconstruct from commits and browser history, estimate in quarter hours, and label the row [reconstructed from commits].

Pitfall: Demoing slides, or demoing without seeded data. Example: A slide reading “barcode scanning implemented,” or a live run that begins with an empty database and a student typing test test test into a form. Fix: Working software only, from a committed seed fixture, following a written script, with a recording made in advance as the fallback. Close by naming what is not done and when it is scheduled.

5.13 — Reps

The reps are in the exercises. They are not warmups beside the milestone — done in order, they are the increment. Preview:

• Rep 1 — cut this week’s two or three slices from your Must list and write a slice card for each.
• Rep 3 — adapt the ten-check definition of done, then apply it to something you already called done and find the gap.
• Rep 6 — write a prompt contract instead of a wish, then run explain / break / rewrite on what comes back.
• Rep 9 — reconstruct one honest day from git log, then run code/hours_report.py over your real log and read the calibration factor out loud.

Do the on-page Check Your Reps quiz when you finish the chapter. It is one of the eight weekly quizzes that make up 15% of your grade, and it is the early-warning system that tells you whether this week landed.

5.14 — This Week’s Milestone

Milestone 5 — Milestone 5: Core Increment & Demo. Two to three vertical slices closed against their acceptance criteria, a definition of done that was actually applied, a four-pass self-review record, an honest docs/ai-usage.md, a commit history that tells the story, a current hours log, and a five-minute demo of working software with a recorded fallback. Remember the shape of this course: the milestones carry 25% between them — about 4.2 points each — and that is the smaller half of what they are worth. The Week-8 submission is worth 50% and it awards points for exactly these artifacts again. What you skip this week is not forgiven — it is deferred, to a term with three weeks left in it. In an eight-week course one week is an eighth of everything, so falling behind here costs you twice what the same slip costs a student in the long edition. Build it now, once, while it is cheap.

5.15 — Coach’s Final Word

This is the week the course stops being about documents and starts being about whether you can build the thing you described. That transition breaks students, and almost never because they cannot code. It breaks them because construction feels like permission to abandon everything that got them here — the slices, the gate, the log, the history, the review. Do not take that permission. The process is not a tax on the building. It is what makes the building survive contact with Week 7, when you are tired and something is broken and the only things that can save you are a history you can read and a log you can trust.

Two slices, three if the third is small. Each one demoable. Each one you can explain, line by line, including the lines a machine drafted — especially those. A log that reads as if a person kept it, because a person did. And five minutes where the software runs and you say plainly what is not finished yet.

Work heartily. The unseen parts count.

See you on Monday.

Up next: the exercises builds the increment rep by rep · Milestone 5 is Milestone 5 · then Chapter 6 — where verification stops being something you do at the end and becomes a phase with a plan, and where you decide what gets cut. Reference appendices: Appendix A (the workbench and the log columns), Appendix B (the Fast-Start Catalog, including the cut-first lists), Appendix C (the Document Kit), Appendix D (the grading contract and the AI-use policy), Appendix E (glossary). Previous: Chapter 4.