For large, low-level, or new-language projects, first use a larger planning file to break out the next batch of work, then switch between code and debug modes and give the model explicit review and validation skills. This is a reusable workflow for long-running tasks.
Suitable tasks: Large backends, performance optimization, low-level languages, new languages, or projects that require long periods of continuous execution.
Unsuitable tasks: Repetitive mechanical changes (script them first), or production repositories without tests or version control.
Applicable model version: Ox Alpha; the original post provides no version snapshot.
Applicable clients, agents, or APIs: The comment mentions experiences with different clients, including Kilo, Antimatter, and OpenCode; it does not fix a single Harness.
Recommended reasoning levels and parameters: Not disclosed; fix and record the code/debug mode for each task, avoiding implicit changes within the same experiment.
The original post does not publish a complete prompt; the following is a reconstructed workflow, not the original prompt:
1. Fix the repository commit, build command, test command, and performance baseline.
2. Create a master planning file that records the goal, known constraints, module dependencies, risks, and current to-dos; break the next batch of work into separate smaller planning files.
3. First ask Ox Alpha to read only the planning files and relevant code, then return the “understood facts, assumptions to confirm, next steps, and validation commands”; do not immediately expand the scope to the entire repository.
4. Use code mode during implementation; when performance, type, security, or test issues arise, switch to debug mode and attach the original error and a minimal reproduction.
5. Install or enable skills that constrain the model: code review, planning, correctness validation, and debugger use. Skills describe behavioral requirements; they do not replace tests.
6. After each batch of changes, run the build, unit tests, integration tests, and necessary performance checks; update the facts and unresolved issues in the planning files.
7. Perform an independent review of the final diff, paying particular attention to undefined behavior, memory safety, performance regressions, and unrelated refactoring.The author says that they used Ox Alpha on a native D backend, with a main planning file of about 1050 lines, and split subsequent work into smaller files. After switching from code to debug, backend optimization results improved. Code review, planning, correctness validation, and debugger skills were also helpful. The author did not publish repository history, the complete planning files, or a baseline for the same task.
An overly large planning file may add context noise; separate “facts, decisions, and next steps.”
Performance code and unsafe/assembly code must be validated by the compiler, tests, and human review; do not rely only on the model’s explanation.
Prefer scripts for repetitive tasks; having the model repeatedly perform the same mechanical operation increases cost and the failure surface.
Ox Alpha