Welcome

--:--recording — let's go

Week 3

Backpressure

the model generates

the harness says no

what changed this week?

“believe in yourself” and make progress on the Riemann hypothesis

DeepSeek V4 Pro 0813

today’s beats

code generation is cheap, so pushing back and saying no is the key

SSGs: a website build step

short feedback loops

demo: what will the checks say?

starting from MARKDOWN, a C2 pick, copied into the demo repo as-is

Our brand guidelines say this site should be red, white and blue. Add a check that enforces that, then make the site pass it.

the harness pushes back

are we there yet?

(decent) code generation so fast and easy now

(Simon Willison files this as a principle of its own: writing code is cheap now)

what’s still scarce is good sources of pushback

negative feedback in both senses:

  • the loop that steers a system
  • the crit comment about the prototype rather than the author

guides and sensors

guides steer before doing (i.e. codegen): your CLAUDE.md (week 2), a skill (week 4), the published spec, the plan.md you wrote

sensors measure what was generated: exit codes, lint output, type errors, test results, the rendered page

this week is mostly sensors

words; what do they even mean?

what makes a sensor worth ‘wiring in’

specific: pinpoints file/line, concrete “expected versus actual” output

fast: the correction lands in the same turn as the mistake, in the current context

automatic: it fires on every change

trustworthy: a red check that’s sometimes wrong teaches you to ignore red checks

your attention is the scarcest thing in the loop

the sensors your repo already runs

types, the build, lint, stylelint and the tests (invariants included): pnpm check runs the lot before you push

CI runs that again, then the ones only a runner can: your process evidence, internal links, committed secrets, and whether the deployed page is really up

a type error, as the agent reads it

src/data/posts.ts:14:24 - error TS2551: Property 'titel' does not
exist on type 'Post'. Did you mean 'title'?

a nag to you; a rule name and a location to the agent

plausible code — the agent’s failure mode — is exactly what a type checker turns red

agents are better at reading errors

a wall of red is demoralising to you and just input to it — every line, every time, without getting bored or taking it personally

so the part that stays yours moves up a level: deciding which failures are worth hearing about at all

a stylelint error

src/styles/main.css
 42:3  ✖  Unexpected duplicate "color"
          declaration-block-no-duplicate-properties
 58:1  ✖  Unexpected unknown pseudo-class ":focus-visble"
          selector-pseudo-class-no-unknown

CSS is where agents bluff hardest, because nothing else objects to a selector that matches nothing

a failing test

FAIL  spec/invariants.test.ts > every page links home
AssertionError: expected 3 pages to link home, got 2
  dist/about/index.html

lint and types reject code that’s malformed; only a test rejects code that’s wrong*, because only a test knows what it was supposed to do

one well-aimed failing test will reorganise an agent’s whole approach

Ben uses… only push on green

commit at each logical checkpoint, but only when the full suite of tests, lints, and other checks passes — never commit a red state

that line is in my ~/.claude/CLAUDE.md — the user-level one included in every session

claude knows what “green” means in each project

changes (and reverts) are cheap

interrupt mid-response (Esc), rewind the conversation (/rewind), revert the commit (git revert) — which one is cheap depends on how early you are

agents know git far better than most of us, and as long as you have a good mental model you can be fearless

what should it do next?

on screen: the check it wrote

(half a minute with the person next to you, then call it out — one of them gets typed in and run)

back to the demo

Web

what a static site generator is

the build step between what you write and what you ship: content in (often .md), plain HTML, CSS and JavaScript out

Astro is the course default from C2; Eleventy and Jekyll are the same idea with different opinions about the input

whichever you pick, GitHub Pages serves it

which box does what?

why use a build step?

one copy of the repeated parts: the layout, the nav and the footer written once

content/presentation separation: a restyle touches the layout, not every page in the site

easier authoring: markdown is easier to write by hand than html

no include in html

why not use a build step?

adds a config file, a dependency tree

more stuff to fail and go out-of-date

sometimes just writing html files is the best way (esp. with agents)

the cheapest backpressure is a shorter loop

pnpm dev serves from source and rebuilds on save, and hot reload pushes the result into the browser

a shorter loop makes every other signal arrive sooner

the dev server is not the built site

a site can run perfectly at localhost and fail once built (e.g. base path shenanigans)

pnpm build then pnpm preview is what CI runs, and the check to trust before you push

it’s always safest to check it in ‘prod’

can the agent see what it built?

everything so far checks the code, but can’t tell the agent what the page looks like

agent-browser drives a real browser: screenshots, the accessibility tree, the console

works in dev and prod

(used deliberately rather than defensively, this is a named pattern — agentic manual testing, week 5)

Ben uses… a format-on-edit hook

every file the agent writes gets reformatted immediately by the same formatter my editor runs on save

so claude and I never have to fight over whitespace

it’s a PostToolUse hook — bin/claude-format in my dotfiles

what should it do next?

on screen: the check, then the page

(half a minute with the person next to you, then call it out — one of them gets typed in and run)

Predict, then watch

predict, before we read it back

the site colour-codes five departments; the brand rule allows three colours

where does that information go?

(chat with the person next to you)

what should it do next?

on screen: the page you predicted

(half a minute with the person next to you, then call it out — one of them gets typed in and run)

C3: the assignment 1 retro

no fresh provocation this week — the crit reflects on A1, due noon, Monday 17 August (for everyone)

you present it in your pod crit

discuss the breakthrough (a prompt idea, a harness change, etc.) and show the before and after: what the agent was doing, what changed it, why it worked

what goes in PROCESS.md

one paragraph on what you built, then the moments that mattered (three or four of them, 400–600 words)

what you did instead of the obvious thing, and how you knew it helped

each cites a commit link (can be a deletion)

the strongest moments landed in the harness (a rule, a check, an attempt thrown away) rather than in a retry

your Claude budget is $200 this week

up from $100, for the run-up to Monday’s assignment 1 deadline

it went live before this morning’s reset and carries the whole week; back to $100 at the Thursday 20 August reset

(announced on Ed; your status line reads the figure live)

the comp4020 plugin will install Astro

update the plugin, then use the /stack skill

Astro, the Pages base path, the lockfile, the CI link check — and hands it back as one staged diff to review

it’s a default, not a requirement (spec doesn’t require any specific stack)

your C4 starter repo is much thinner

the CLAUDE.md we ship dropped from ~1700 words to ~200 — the checks are named, not explained, and no stack or harness decisions are made for you

(from Monday’s C4 repos on; your A1 repo keeps the file it was provisioned with)

deadline radar

/comp4020:radar reads every cutoff and deadline off the course site, so it can’t go stale

let’s run it

tl;dr

code generation is cheap; building the thing that pushes back is most of the work

a sensor earns its place by being specific, fast, automatic and trustworthy

a build step costs you a dependency tree and buys you DRY-ness

a shorter loop makes every other signal arrive sooner

recovery is cheap: interrupt, rewind, revert

See you in the studio

ask your agent

ask until you can explain these back:

  • guides and sensors: which files in my repo steer you, and which ones push back
  • pnpm check: what does each part of it run, and what does none of it catch
  • the dev server: what can pass tests at localhost and still fail once built