This disclosure covers the development tools used in the contract and the discipline that governs them. It applies to the whole project, and the weekly reports refer to it rather than repeat it. AI-assisted coding tools are part of the workflow. They are instruments under a verification regime, not autonomous code generators. The sections below explain what that means and why it can be checked rather than taken on faith.
Tools used
CLion is the primary C++ environment, where I read, debug, and inspect the running engine, and its in-IDE AI assistant is held to the same review discipline as the others. Claude Code is the command-line assistant that writes code from the specifications I author and returns it with the results of the checks it passed. Ollama runs small local models on-device for session logging.
Division of labor
The division of labor is fixed. The architecture and signal-flow design are mine, drawn from hardware modular practice rather than any tool. So is the specification of every change, with its acceptance criteria. So is every perceptual decision about how the instrument should sound, which no automated check can judge. I read every diff before it enters the codebase and decide whether to accept it. The tool's job, under that specification, is to write code that satisfies it and return it with the results of the gates it passed. Nothing enters the project until I have read the diff and the verification record and accepted it.
Verification and enforcement
What makes this more than good intentions is that the workflow leaves a committed record and runs under automated enforcement. Each unit of work begins as a written specification I author before any code exists. Every change must then pass a fixed set of mechanical checks before it can be committed. They are formatting, the test suite, a build, and, for an audio project, a determinism check that confirms the same input yields the same output before and after the change. They run in a pre-commit gate the project's rules forbid bypassing. Each AI-assisted change is recorded in an applied log committed alongside the code. The entry records what was specified, what came back, which gates passed, and what I decided, so the git history and these logs form an auditable record of how every line arrived. All commits are authored by me. Beneath all this, the environment enforces safety rules independent of any single tool. Dangerous filesystem operations and access to secret files are blocked before they run, and a session that has changed compiled code is flagged to verify the build and tests before it closes. These checks fire on their own, not on my memory.
Reading this academically
The honest summary is that AI tools accelerate the implementation of designs I author and verify. They do not replace the architectural, perceptual, and verification work that is the real learning in this contract. Writing C++ for real-time audio, understanding the JUCE lifecycle and threading model, designing the signal processing, and judging the result by ear are all work I do and answer for. The method is itself part of what the contract demonstrates. Specification, mechanical gates, and logged, reviewed changes are a disciplined way to use these tools in a complex, quality-gated codebase without surrendering authorship or understanding. The commit history, the logs, and the gate configuration are all in the repository, open to review at any time.