The work

Problem and design decision: Classic games without source code cannot be maintained or studied directly; I paired a specification-based Python simulation with a separate binary-analysis prototype that decoded the original level files and data tables.

A 1995 god game by Creative Edge Software, rebuilt without its source code. All 100 original levels load and draw in the Windows desktop build from an owned copy. A version with generated levels and new art runs on the front page, and you can change its rules while it plays. On the desktop build, all 100 levels load with 0 errors and 9,000 random inputs caused 0 exceptions.

Grass world, the first of the remake's five worlds: grass, ice, circus, sand and hell. Generated level, project-made art.

Case study 100-level check 9,000-input fuzz Play it

Problem and design decision: Agent summaries and instructions quietly go stale when upstream documents change, and passive prose guides alone did not beat an ordinary workflow across 37 real repository tasks (48.8%/49.0% vs 53.8%); the engine binds extracted claims, 5-project Document Atlas spans (883,486 files censused, 699 keepers, 8,013/8,013 span hashes), and AST-mapped code bricks to source revisions and executable pytest oracles.

In the October 18, 2026 study on ApprovalBench (61 AST units in a single package), source-blind rebuilds from verified code bricks passed in 3 of 3 runs, while mechanical self-maintenance flagged 15/15 behaviour-changing edits with 0/12 cosmetic false-stale alerts. One Baldies prototype also used the engine to carry disassembled values like the house-capacity table into code, and a public synthetic fixture runs with plain Python. Council, BigBoss and SEED remain separate supporting projects.

How the brief frames the work: keep the source, record the task use, and check it. Council, BigBoss and SEED stay separate.

Project overview & Oct 24 metrics Research brief Oct 24 research note The consumption problem Reducing research sprawl Run the example

Problem and design decision: Published Voynich studies often fit a cipher or generator to a few global statistics or differ in how they filter lines and spaces; I built an interactive Evidence Atlas with the team (the AI agents I direct) that pairs Beinecke MS 408 folio images with nine source-linked evidence stories, corrections and downloadable records.

Explore plants, pools and star diagrams, then follow the selected evidence stories to their sources, scope limits and a clearly labeled working interpretation. The manuscript remains undeciphered; earlier research accounts remain available below.

Beinecke MS 408, Folio 75r (Currier B, Hand 2, public domain via Yale University Library): physical lines act as compositional units.

Explore the Evidence Atlas Sources and downloads Full research record (GitHub) Earlier case study Findings & protocol index Research note Beinecke MS 408 notice

Problem and design decision: Coding agents lose structural coherence when they start in an empty folder or rely on one long chat transcript; the fluid CLI (1,264 lines across 6 Python 3.11+ standard-library files) separates module hierarchy (parent), semantic contracts (depends_on) and dispatch gates (build_after), materializes native MODULE.md contracts, renders three-tier bounded context packets, and tracks SHA-256 delivery receipts.

In a matched October 23, 2026 comparison building a four-document Research Navigator, both fresh builders (Foundation-assisted and ordinary control) satisfied 13/13 protocol rows on unchanged first-delivery bytes with 0 product repairs after adjudicating two defects in the frozen evaluation harness. Because frame authoring was untimed prior to dispatch on an n = 1 pair, it demonstrates workflow feasibility and oracle accountability rather than a net speed multiplier.

How FluidSoftware frames a build: explicit module contracts, three-tier context, and SHA-256 receipts.

Case study Code (v0.1.1 / 6fdee0d) Matched comparison Run the checks

Problem and design decision: People who move to music often stop when they meet the instrument or the software. MusicLab starts with a band that is already playing, so a press joins the music instead of starting from silence.

Inspired by Banjo-Kazooie's adaptive music, the band changes style around the notes a person contributes while those notes stay theirs. The full build spans 78 musical arrangements with a scored continuous Ska, Rocksteady and Reggae arc, eight-key scale play, a live read meter and picture answer receipts so you can see what the band hears, 24-bar unbroken history capture across rests and restarts, a leave warning before unkept Jam notes can be lost on reload, dealt Adjust idea cards, whole-song timeline scrubbing, live note dragging and MusicXML 4.0 sheet notation (804 JavaScript and 130 Python tests, 303 to 351 ms quiet first sound across 12 package runs, and a 78-of-78 style sweep at commit d0a8d7a). It runs locally in the browser with no account and does not generate audio with AI; I built it by directing AI coding agents.

Cutaway of the genre circle, multi-part band timeline (Beat, Bass, Chords, and Your notes), and eight scale keys.

Case study Interactive sketch Code (7e2a9a3) How it works Limits

Problem and design decision: Coding agents can execute destructive shell or file actions before a person notices; BigBoss hashes the exact proposed action, workspace and policy version into a persisted SQLite approval gate.

An approval gate for coding agents. Each decision is tied to one hashed action and saved in SQLite. Release v0.1.0 passed 399 tests with no skips in four jobs: Ubuntu and Windows, Python 3.12 and 3.13.

Release v0.1.0 of bigboss-approval-plane on GitHub, with notes on what exists at that tag.

Case study Code 399 tests (v0.1.0)

Problem and design decision: Peer models often agree on a plausible-sounding numerical mistake; The Council separates open-ended critique from explicit claim extraction and re-derivation.

An app that gets answers from several model providers, has them critique each other, checks the claims, and combines the result. A recorded live run shows a claim check catching an error the critique missed.

Recorded live run on the Council case study: claim checking catches a step peer critique missed.

Case study Code Recorded run

Problem and design decision: Broad self-play learners struggled to retain gains across opponents; isolating a targeted matchup rule change and testing it across 8,400 games showed where it helped and where it stayed flat.

Learning parts and a matchup counter for the card game. The counter builds on makthanithin's Apache-2.0 community_1084 policy. Each opponent faced 600 games against the baseline and 600 against the counter. Against two tested Alakazam implementations, the counter gained 20.42 and 18.75 percentage points. Against the other five tested opponents it averaged -0.47.

8,400 games, 600 per arm per opponent; bars show approximate 95% intervals.

Case study Code 8,400-game CSV Evidence map

Problem and design decision: Inspector-heavy 3D game engines are opaque to coding agents; expressing scenes, procedural meshes and simulation rules as plain-text Godot scripts makes 3D games inspectable and testable from the command line.

Methods and checks for building Godot games with an AI coding assistant, based on a read-only study of a shipped Godot game, plus The Argon One-Shot, a 3D city simulator in Godot 4.7 whose code is private, with a simplified browser sketch.

Public godot-ai-methodology repository: principles, phased workflow and skills suite.

The Argon One-Shot case study Methodology code

Hands-on lessons on how AI tools work. Fetch a dog photo with a real request, or find your place on Vector Planet. No account or key. The Dog lesson has a teacher guide and worksheet.

Dog API lesson: the photo returned by the live dog.ceo request.

Lessons Teacher guide