Build: Writing Code and the Tools of the Craft

All courses / AI Developer / Module 2 / Chapter 7

Learning objectives

After the lesson the participant can:

Classify a coding tool by usage mode from what it may touch, the unit of review and the identity it uses
Explain how task, experience, codebase and measure account for the differences between the productivity studies
Apply the four rules of prompt and context craft to a coding task
Draft a coding-assistant usage profile that narrows the delegation profile and never widens it

Key concepts

Unit of review: What the developer must read to accept a tool's output: a few lines for completion, a snippet for chat, a diff and a command log for edit and agent mode. The chapter says risk grows with this unit and with the identity the tool uses, not with the sophistication of the model.
Four variables behind the studies: Task, experience of the person, codebase and measure. Self-contained tasks showed speedups, real issues in familiar mature repositories did not, and measures such as pull requests, commits and acceptance rates count output that a tool can inflate.
Vibe coding: Not a tool but a way of working in which generated code is accepted without being read. The chapter gives it a legitimate place only in a throwaway prototype in a sandbox with no credentials and no data, because it sits outside framing, reading and ownership.
Coding-assistant usage profile: A file that turns the statement that the team uses an assistant into something that can be checked: tool, mode and hosting, ceilings copied from the delegation profile, what may not be given to the tool, merge criteria, measurement plan, evidence age and a stop rule.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

The form of the tool and what the developer reviews

Match each form of coding tool to the unit the developer must review, as the chapter's table gives it.

Interactive exercise 2 · Scenario

The prototype that works

Apply what the chapter says stays human in building, and where vibe coding has a place.

Teaching plan

10 min	The teacher presents Table 7.1 and participants place their own tools by what they may touch and the unit they must review.
20 min	Lecture on what the studies measured, in whom and with what limit, ending with the METR trial and its redesign as a lesson in measurement.
10 min	Demonstration and discussion of prompt and context craft: a task stated so it can be checked, deliberate context, known failure modes and a small unit of review.
25 min	Exercise: groups write a usage profile for one assistant, using the NR-DEV-001 example as a model.
10 min	Groups read out their stop rule and the claim they marked as asserted.

Discussion

In the trial of 16 experienced developers, completion took 19 per cent longer while the developers believed they had been faster. What does that imply for a survey of time saved in your own organisation?
The chapter calls Mode 0 the most common error: an assistant that arrived in an update and was decided afterwards. How would you find such features in your own tools?
Why does the usage profile measure at team level, and what changes when a tool reports a named developer's acceptance rate to a manager?

Written exercise

Exercise · 25 minutes

A usage profile for one coding assistant

For one assistant your team uses, or for the pilot NR-DEV-001 at Nordvik Region, write a usage profile. Identify the tool, its usage mode and where the model runs. Copy the ceilings per work class from the delegation profile. List what may not be given to the tool. Write acceptance criteria for merging a change that contains generated code, with one criterion each for Name, Understand and Revert and an oracle the generator did not write. Write a measurement plan using outcomes already measured at team level, record the evidence age of every claim relied on, mark unverified claims as asserted, and write the stop rule and who decides.

Deliverable: A usage profile with ceilings, exclusions, merge criteria, measurement plan, evidence ages, a stop rule and a review date.

Your work

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

In the study by Peng and colleagues, what was measured and with what result?
Show the answer
B. Time for 95 freelance programmers to complete one JavaScript task: 71.17 against 160.89 minutes
Peng and colleagues recruited 95 freelance programmers for one synthetic HTTP server task; the treated group took 71.17 minutes against 160.89, reported as 55.8 per cent faster. Code quality was not examined.
According to the chapter, what does the risk of a coding tool grow with?
Show the answer
D. The unit the developer must review and the identity the tool uses
The chapter's first observation on Table 7.1 is that risk grows with the unit of review and with the identity the tool uses, not with the sophistication of the model.
How does the usage profile for NR-DEV-001 show the quoted claim that developers are a third faster?
Show the answer
A. As asserted, beside the measurement plan that would verify it
The worked example marks the quoted claim as asserted next to the plan that would verify it; nobody had measured delivery time, and the unit of measurement is the team.