A public field report worth mining for these notes: a non-programmer describing four months of building a browser-based racing game with AI coding agents, posted to r/ClaudeCode on 2026-08-22 ("Vibe coded this game in four months", ActionLittle4176), with the author answering process questions in the comments. It is unusually specific about cost, division of labour, and where the time went, and its comment thread doubles as a cautionary case about validation.
I have checked the existing content before proposing anything, and most of this is a refinement of rather than an addition to what is already here. Details per item below.
1. The division-of-labour claim refines what relative-advantages-ai-humans.qmd already says
That fragment closes with: for most tasks you will not need to manipulate code yourself, "However, you'll still need strong coding skills to: Supervise and validate AI-generated code / Handle edge cases that agents struggle with / Make creative decisions about architecture and design / Understand when agent suggestions are incorrect or suboptimal."
The field report is a datapoint that pushes against the phrase coding skills specifically, and it is interesting precisely because it agrees with the underlying point. The author says he has no coding experience at all, but does know the tech behind games, game design, and has spent a lot of time working with language models -- and that this let him plan properly and catch important decisions before they became problems. His own framing: if he could not code and did not know the rest either, he would have hit a wall after about two prompts. Elsewhere he says human decision-making was the biggest factor, that the engine underneath is just objects moving through space with no animation, that the polish on top is all human design, and that working out how to operate within the agent's limits is not something you can delegate.
So the requirement the fragment is really naming looks like enough domain judgement to supervise, of which coding skill is one route rather than the only one. That is a small rewording of the existing list plus a sentence of attribution, not a new section -- and it makes the list more true rather than less demanding, since it keeps the supervision requirement while dropping an unnecessary precondition.
2. Model tiering for cost, which has no general home yet
The author's stated main cost lever: plan with the strongest model, implement with cheaper ones. He also constrains scope deliberately -- his phrasing is to keep the vision to what you can realistically deliver, so the result is a working product rather than a promise, and to iterate from there. Total spend was roughly $200 over four months on subscriptions taken out specifically for the project, on top of a shared general-purpose subscription.
Existing coverage is vendor-specific: gemini-spend-management.qmd is about one provider's API spend, and small-local-models-agentic.qmd is about running cheap models rather than about routing between tiers. There does not appear to be a general "plan expensive, implement cheap" section. That is a candidate for a short new fragment under ai-tools/, or a few paragraphs added to one of those two.
Worth noting the lab's machine-facing corpus (Morrison-Lab/ai-config) already states this rule for agents. This would be the human-facing statement of the same idea, which seems like exactly the wai/ai-config split -- but if you would rather not restate it here, say so and I will drop this item.
3. Where the time actually goes
Two commenters independently identified manual testing as the dominant cost. One, a former software project manager, said an application that used to take a year now takes a week and that manual testing is what consumes most of the time. Another put it as: to get something defect-free you need either deep experience in the domain or heavy testing.
This belongs with agents-benefits-and-hazards.qmd or agents-best-practices.qmd. I have not read either closely enough to say whether it is already covered -- flagging rather than asserting a gap.
4. The cautionary case, which is the most useful part
The author says most things worked first try. His own comment thread contradicts that, and the contradiction is the teaching point. Players reported a minimap announcing a turn in the wrong direction when the track turned the other way, speed boosts not visible from any distance, an orbit track where you could not tell where you were meant to go, and one player saying it felt like holding the accelerator with no consequence, which they said made it not a fun game.
Every one of those is a defect that looks correct to the person who built it, because the builder reads the underlying state in their own head and sees the display agree with it. They surface only on contact with someone who has nothing but the display. No automated verification appears anywhere in the project.
That makes it a good worked example for the validation-responsibility material in ai-use-policies.qmd, and a concrete answer to "why bother instrumenting checks when the thing looks fine". It is more persuasive than an abstract warning because the author is candid, the project is genuinely impressive, and the defects are still there in public.
Notes for whoever writes it
- Style observed in
relative-advantages-ai-humans.qmd: semantic line breaks with roughly one clause per line, ::: notes divs for speaker notes, tables labelled {#tbl-...} with a : caption line, --- slide separators, and em dashes written as --- rather than the literal character.
- Open question: how should a Reddit post be cited?
references.bib carries academic entries and the fragment above cites [@lecun_world_models]. If there is no precedent for a web source, an inline link may be better than a bib entry -- your call. It should carry a date either way, since the whole thing is a snapshot of rapidly-moving practice and the README already sets that expectation.
- Items 1 and 4 look clearly worth doing; 2 is worth doing if the wai/ai-config split allows it; 3 needs a coverage check first.
Filed rather than sent as a PR because the placement decisions above are yours, and because item 1 is a rewording of existing prose rather than new content.
Unrelated, noticed while checking which owner to file this under: README.md's "Building locally" section still gives the clone URL as https://github.com/d-morrison/wai.git, and the published-site link as d-morrison.github.io/wai. gh repo view Morrison-Lab/wai --json nameWithOwner returns Morrison-Lab/wai, so the canonical owner has moved and the README is a rename behind. The GitHub API follows the rename redirect silently, so both the old clone URL and the old API path keep working -- which is exactly why this is easy to miss. Happy to send that as a one-line PR separately if you would like it fixed; not folding it into the content work above.
A public field report worth mining for these notes: a non-programmer describing four months of building a browser-based racing game with AI coding agents, posted to r/ClaudeCode on 2026-08-22 ("Vibe coded this game in four months",
ActionLittle4176), with the author answering process questions in the comments. It is unusually specific about cost, division of labour, and where the time went, and its comment thread doubles as a cautionary case about validation.I have checked the existing content before proposing anything, and most of this is a refinement of rather than an addition to what is already here. Details per item below.
1. The division-of-labour claim refines what
relative-advantages-ai-humans.qmdalready saysThat fragment closes with: for most tasks you will not need to manipulate code yourself, "However, you'll still need strong coding skills to: Supervise and validate AI-generated code / Handle edge cases that agents struggle with / Make creative decisions about architecture and design / Understand when agent suggestions are incorrect or suboptimal."
The field report is a datapoint that pushes against the phrase coding skills specifically, and it is interesting precisely because it agrees with the underlying point. The author says he has no coding experience at all, but does know the tech behind games, game design, and has spent a lot of time working with language models -- and that this let him plan properly and catch important decisions before they became problems. His own framing: if he could not code and did not know the rest either, he would have hit a wall after about two prompts. Elsewhere he says human decision-making was the biggest factor, that the engine underneath is just objects moving through space with no animation, that the polish on top is all human design, and that working out how to operate within the agent's limits is not something you can delegate.
So the requirement the fragment is really naming looks like enough domain judgement to supervise, of which coding skill is one route rather than the only one. That is a small rewording of the existing list plus a sentence of attribution, not a new section -- and it makes the list more true rather than less demanding, since it keeps the supervision requirement while dropping an unnecessary precondition.
2. Model tiering for cost, which has no general home yet
The author's stated main cost lever: plan with the strongest model, implement with cheaper ones. He also constrains scope deliberately -- his phrasing is to keep the vision to what you can realistically deliver, so the result is a working product rather than a promise, and to iterate from there. Total spend was roughly $200 over four months on subscriptions taken out specifically for the project, on top of a shared general-purpose subscription.
Existing coverage is vendor-specific:
gemini-spend-management.qmdis about one provider's API spend, andsmall-local-models-agentic.qmdis about running cheap models rather than about routing between tiers. There does not appear to be a general "plan expensive, implement cheap" section. That is a candidate for a short new fragment underai-tools/, or a few paragraphs added to one of those two.Worth noting the lab's machine-facing corpus (
Morrison-Lab/ai-config) already states this rule for agents. This would be the human-facing statement of the same idea, which seems like exactly the wai/ai-config split -- but if you would rather not restate it here, say so and I will drop this item.3. Where the time actually goes
Two commenters independently identified manual testing as the dominant cost. One, a former software project manager, said an application that used to take a year now takes a week and that manual testing is what consumes most of the time. Another put it as: to get something defect-free you need either deep experience in the domain or heavy testing.
This belongs with
agents-benefits-and-hazards.qmdoragents-best-practices.qmd. I have not read either closely enough to say whether it is already covered -- flagging rather than asserting a gap.4. The cautionary case, which is the most useful part
The author says most things worked first try. His own comment thread contradicts that, and the contradiction is the teaching point. Players reported a minimap announcing a turn in the wrong direction when the track turned the other way, speed boosts not visible from any distance, an orbit track where you could not tell where you were meant to go, and one player saying it felt like holding the accelerator with no consequence, which they said made it not a fun game.
Every one of those is a defect that looks correct to the person who built it, because the builder reads the underlying state in their own head and sees the display agree with it. They surface only on contact with someone who has nothing but the display. No automated verification appears anywhere in the project.
That makes it a good worked example for the validation-responsibility material in
ai-use-policies.qmd, and a concrete answer to "why bother instrumenting checks when the thing looks fine". It is more persuasive than an abstract warning because the author is candid, the project is genuinely impressive, and the defects are still there in public.Notes for whoever writes it
relative-advantages-ai-humans.qmd: semantic line breaks with roughly one clause per line,::: notesdivs for speaker notes, tables labelled{#tbl-...}with a: captionline,---slide separators, and em dashes written as---rather than the literal character.references.bibcarries academic entries and the fragment above cites[@lecun_world_models]. If there is no precedent for a web source, an inline link may be better than a bib entry -- your call. It should carry a date either way, since the whole thing is a snapshot of rapidly-moving practice and the README already sets that expectation.Filed rather than sent as a PR because the placement decisions above are yours, and because item 1 is a rewording of existing prose rather than new content.
Unrelated, noticed while checking which owner to file this under:
README.md's "Building locally" section still gives the clone URL ashttps://github.com/d-morrison/wai.git, and the published-site link asd-morrison.github.io/wai.gh repo view Morrison-Lab/wai --json nameWithOwnerreturnsMorrison-Lab/wai, so the canonical owner has moved and the README is a rename behind. The GitHub API follows the rename redirect silently, so both the old clone URL and the old API path keep working -- which is exactly why this is easy to miss. Happy to send that as a one-line PR separately if you would like it fixed; not folding it into the content work above.