10 min opening, 65 min feedback loops, with a live demo, the rest together
0:00
Opening·the questions engineers ask
0:10
Feedback loops·with a live demo
0:45
Break
0:50
Loops for your stack·and a look at one real project
1:20
Homework, close
1:30
End
Once the tool does real work for you, the hard questions start.
The questions engineers ask
How do I stay sharp and keep my judgment if I no longer write most of the code?
What should a junior or an apprentice do?
What is my job now, if Claude does it all?
I don't have definitive answers, but I, too, think about this all the time.
How do I stay sharp and keep my judgment?
Review
Read every change as if you had to defend it. Approving out of habit is how the overview gets lost.
Reports
Read the discovery and spike reports. They are the repository, condensed.
The hard part
Write the core of a difficult change yourself now and then.
Consequences
Judgment comes from the consequences you own, and you still own them.
What you need to stay sharp in moves up a level, as it did when compilers replaced assembler. For now, that still includes reading code, because someone has to judge what the agent writes.
Beginners still need to put the manual work in.
Learn to write code without the agent first, the way you learn arithmetic before you use a calculator. You learn to read and judge code by writing it.
“The dumbest thing I've ever heard. … How's that going to work when ten years in the future you have no one that has learned anything?”
Matt Garman, CEO of AWS, on replacing junior staff with AI, August 2025
What is my job now, if Claude does it all?
The spec
You decide what gets built and what done means.
The loops
You build the checks that tell the agent whether it is right. That is today.
The review
You read the result and decide whether it goes into main. That is next week.
The system
You know the codebase well enough to judge all of the above.
Claude writes more of the code. You are still responsible for all of it.
What would you build if you had the time?
The agent gives you time back. Use it for the work you never got to.
Where we are
01Core concepts
02Preparing the codebase for agents
03Writing a good spec
04TodayFeedback loops
05Workflow integration and code review
06Claude Code in depth
07Orchestration and subagents
08Claude Code alternatives
Codebase, spec, and now the check. Next week: how the result gets into main.
The spec says when it is done. Today: how the agent finds out for itself.
Today, you will go from babysitting AI to agentic, long-running AI.
Feedback loops are the key to letting AI iterate tirelessly and autonomously until your job is done.
What we cover today
Test commandExit code/goalChrome
Unit testFeedback loop
Stop hookPlaywrightFailure message
react-native-webFlaky testLocal environment
Part one
Theloop
A command that says pass or fail.
If nothing can tell the agent that it failed, it stops at its first guess.
Feedback loop
A command the agent can run that tells it whether it is right.
Tests, a build, a type check, a linter, a screenshot compared with the design.
The loop is only as good as its failure message
two failures, same test
FAILED cart.test.tsFAILED cart.test.ts > applies voucher to reduced items expected total 4990, received 5490 at applyVoucher (src/cart/voucher.ts:42)
The agent reads output, not intent. The second one tells it where to look and what was expected.
Unit tests are the primary loop because they are fast, local and repeatable.
Dozens of runs in one session cost seconds. That is what makes the loop worth having.
Ask the agent to write the tests first, then the code.
A test written after the code tends to confirm the code.
Watch for the agent changing the test.
A hook blocks skipped tests and removed assertions. Changes to existing tests go to QA review. New tests are always welcome.
The agent cannot start the app without seeing the test result.
Hooks the tests run whether the agent remembers or not
/goal
A condition such as "all tests pass", re-checked after every turn until it holds.
A separate model does the checking, not the agent doing the work.
Live: test first, then the fix
prompt
In the cart, the voucher AUTUMN10 takes only 5 € off the reduced
jumper. It should take 10 €, on reduced items too.
First write a Playwright test that reproduces this. Run it and
check that it fails for the right reason.
Then fix the code until the test passes.
Do not change the test once it fails for the right reason.
A Stop hook runs the tests whenever the agent wants to finish. While they fail, it has to keep going.
Claude time!
Part three
Real examples of loops foryour stack
These loops cover the browser, the app and the API, and show where loops stop.
The fastest loop is the type checker, which takes seconds instead of minutes.
vue-tsc, tsc, PHPStan, the Java compiler: after every change. Unit tests after every step, the full suite before the commit.
2.1 seconds
$ npx tsc --noEmit
src/cart.ts:8:49 - error TS2339: Property 'grossPrice' does not exist on type 'CartItem'.
Found 1 error in src/cart.ts:8
The browser can be a loop too.
Playwright opens the page, clicks through, compares a screenshot with the design. The Chrome integration does the same in your own browser, and reads the console.
ExpectedActual
Diff
2116 pixels (ratio 0.01 of all image pixels) are different.
The design can be a loop too.
The agent takes a screenshot of its result and compares it with the Figma frame it can request via MCP. Differences go back into the loop, not into review.
Figma frameBuilt
1Spacing below the icon
2Button order
3Link color
The app gets the same loop.
React Native renders in the browser through react-native-web, so Playwright drives the app too. Detox and Browserstack stay for what only a device shows.
React Native code
react-native-web
renders it in the browser
Playwright
after every change
Device or simulator
Detox and BrowserStack
for what only a device shows
Testing API endpoints: a skill, not a script
.claude/skills/test-endpoint/SKILL.md
---
name: test-endpoint
description: Test a new or changed API endpoint against its contract
---
1. Read the contract: openapi.yaml, or schema.graphql
2. Start the service locally: make run-local
3. Get a token: ./scripts/dev-token.sh
4. Call the endpoint with valid input, then with every
error case the contract defines
5. Report every status code or body that differs from the contract
The loop can cover several repositories.
One contract, the OpenAPI definition, generates the client for the frontend and the gateway. A change that breaks the contract fails the type check in the other repository.
openapi.yaml
price is renamed
Gateway repository
client regenerated, passes
Frontend repository
type check fails
error TS2339: Property 'price' does not exist on type 'Product'.
The loop has to run locally.
Tests only on a staging branch means no loop. A local Kubernetes setup is the start of one.
Through staging
PushCIDeployTest
About 20 minutes, so 3 loops per hour.
Locally
Test
About 5 seconds, so hundreds of loops per hour.
Loops work without a staging environment.
Testcontainers starts Kafka, Elastic, Redis and the database locally. Recorded responses stand in for the commerce platform, the CMS and the ERP interfaces.
Containers
Kafka
Elasticsearch
Redis
Database
Service under test
runs locally
Recordings
Commerce API
CMS
ERP interfaces
A production error becomes a failing test.
A Sentry error becomes a failing test first. Then the fix, then the test passes.
Production error
TypeError: Cannot read properties of undefined (reading 'price') at CartSummary (CartSummary.tsx:42)
✗ FAIL CartSummary.test.tsx renders an item without a price
✓ PASS CartSummary.test.tsx renders an item without a price
Budgets are loops too.
Lighthouse for performance, axe for accessibility: over budget fails like a broken test.
Automating QA means every ticket starts with writing tests, every time.
The agent writes and runs the QA scenarios for its own change. A person reviews the scenarios, not every click.
qa-scenarios.md
Voucher on reduced items
✓A voucher applies to a reduced item
✓Below the minimum order value it is rejected
✗A voucher plus a second reduction expected 49,90 €, got 54,90 €
✓Removing the item removes the voucher
✓The mobile layout at 375 pixels
A loop the agent can run unattended
Allowed commands: no permission prompt in the middle
No interactive prompts from the tools themselves
Short output: the failure, not ten thousand log lines
No flaky tests: random failures teach it to ignore failures
Some things no loop can check.
Visual judgment, business correctness, anything that needs production data.
Sidebar
Tests I am usingin a typical project
These are the kinds of tests in one of my own projects.
The project in lines of code
Lines
Files
App code
88,789
578
Backend
46,253
252
Frontend
38,756
310
Database migrations
3,780
16
Tests
131,135
529
Backend tests
89,381
351
Frontend tests and mocks
33,524
130
End-to-end tests
8,230
48
Other
12,117
37
Fake external services for dev and test
4,608
15
Dev scripts
4,442
10
Deploy and CI
3,067
12
Total
232,041
1,144
1.5×
There are one and a half lines of test code for every line of app code.
About 8,100 automated tests
fastslow
Static checks17 guards, lint and types run first
Unit2,784
Database2,059
API1,168
Frontend~1,965
Integration33
End-to-end52
Release rehearsals4 scripts
Most of the tests run in milliseconds. Only a few are long runs through a real browser.
Static checks and guards run before any test
Every change
Lint, format, strict types
Backend and frontend, before any test runs.
17 guards
Project rules as code
No direct clock calls, no floats for money, one choke point for sensitive writes.
108 operations
Contract drift
The API schema is regenerated and has to match what is committed.
A rule in CLAUDE.md can be ignored. A guard that fails the build cannot.
Unit tests: pure logic, milliseconds each
2,784 tests
Domain rules and pinned edge cases
A false positive that was fixed keeps a test that holds it fixed.
21 properties
Property-based tests
Invariants such as "the parts sum to the total" are checked over thousands of generated inputs.
88 signatures
Contract pins
Public signatures, fields and enum values fail the build when they change.
74 snapshots
AI prompts and templates
Prompts, tool definitions and emails are compared byte for byte.
A real database instead of mocks
Fresh database
Every test gets its own Postgres, cloned from a migrated template.
Real SQL
Transactions, locks, concurrency and queues run against the real engine.
Migrations
141 tests run each migration up and down and compare the result with a freshly seeded database.
Tenant isolation
An auditor flags any SQL statement that is not scoped to a tenant.
Matrices instead of examples
Route
Anonymous
Member
Other tenant
GET /accounts
401
200
404
POST /transactions
401
201
404
GET /reports/{id}
401
200
404
DELETE /rules/{id}
401
204
404
530 checks cover every route for every kind of caller. Tests this exhaustive used to be too tedious to write by hand, and an agent writes them quickly.
The expected numbers come from a separate oracle
If the agent writes both the code and the expected values, the test only shows that the code agrees with itself.
No test talks to a real external service*
Fixed dataset
Two tenants, a year of transactions
A seeded script writes it, and CI checks it for drift.
Fake servers
Every external API
Bank feed, email and captcha serve the fixed data.
Fake LLM
80 canned answers
Directives force refusals, failures and delays.
Clock
Injected, frozen or offset
Dates are the same on every run.
Factories
Valid rows with defaults
Each test overrides only what it is about.
Frontend
Typed mocks of 108 endpoints
They follow the same rules as the real API.
* Only real touchpoints, none of them a regular test: a disposable copy of the production database for migration rehearsals, a live AI check using three made-up transactions, and read-only production queries after each deploy.
What this means for your team
Caveat: This project was built with a test-first mindset. Your codebases will need to catch up.
Start with type checks and guards. They are cheap and catch whole classes of bugs.
Start by religiously adding tests for code you change going forward.
Where there is no staging environment, fake the external services.
Claude time!
The most important loops at a glance
Loop
The agent runs
When
Enforced by
Types and lint
vue-tsc, tsc, phpstan, eslint
After every edit
PostToolUse hook
Project guards
A script that fails on forbidden patterns
After every edit
PostToolUse hook and CI
Unit tests
vitest, phpunit on the changed code
After every step
Stop hook
Full suite
pnpm test, ./mvnw test
Before every commit
PreToolUse hook on commit
API endpoints
The /test-endpoint skill
Changed endpoint
Done criteria in the spec
UI and design
Playwright, compared with Figma
After every UI change
Done criteria in the spec
External services
Testcontainers, recorded responses
Inside the test run
Part of the test command
Production bugs
The Sentry error becomes a failing test
Every bug ticket
The failing test comes first
Example homework, to be tailored to your team
Homework: one ticket, end to end, everyone
The ticket
Everyone picks one real ticket and takes it with the agent from the ticket to the pull request: spec, tests, code.
Problem log
One problem log for the whole team: every problem anyone ran into, consolidated.
Summary
One slide with a table the team fills in together: who, which ticket, how many tests it added, and a short review of how it went.
Share
Be ready to walk through the table and the problem log in 5 minutes.
Done means everyone in the team has a row in the table. As a team, before the next session.
>Yo, look at slides 43-54 for inspiration and give me a comprehensive list of suggestions for this codebase.
? for shortcuts
What you will run into, and what you already know
Missing tests
Add them first, and work with your QA engineer if you need to. That was today.
Missing fakes and test data
Mock APIs, fake servers and demo data to seed a test database are one-time work you benefit from anyway. The agent builds them quickly.
Missing integrations
This should not be a blocker anymore. You should already have them set up.
A ticket without details
You now know how to write a good spec. That was session 03.
A codebase the agent misreads
Improve your CLAUDE.md and standards as you go. That was session 02.
Everything this ticket needs, you have learned in the last four sessions.
Do not pick an easy ticket. Do not stop after the first failed attempt. Do not keep what you learn to yourself.
Pick one that would take you days to work on. Iterate until it works. Share what you learn with the team.
Next session: workflow integration and code review.
