The worker proposes. The checks decide.
Model tested on 10 September 2026: Qwen3-Coder-30B-A3B-Instruct, using the Q3_K_M quantization and running locally through llama.cpp. The saved repair transcript identifies this model in the isolated AEOS fixture tests described below.
The local model’s job is to propose code. It has zero acceptance authority: a convincing explanation is not a passing result, and the author of a change does not get to approve it.
In this experiment, deterministic tooling handled the candidate files and ran acceptance checks in a separate test environment. The model could not read the hidden tests, directly write the repository, or approve its own output.
What the task shape changed.
The trials on 10 September 2026 showed how much the surrounding tooling mattered. These are bounded test results, not a reliability score for arbitrary coding work.
| Task shape | Reported outcome |
|---|---|
| Single-function trial | Passed after the harness’s output-capture problem was corrected. |
| Multi-file trial | Passed after deterministic tooling handled the file output and repository operations. |
| Two-file runner and gate fixture | Required several targeted repairs before its saved hidden-test suite passed. This was an isolated fixture, not production AEOS acceptance. |
The useful pattern is narrower than “an autonomous engineer”: keep the task bounded, let tooling handle the mechanical parts, and make the next repair small enough to check.
Two calls, measured.
The final two focused repair calls reported these figures. Speed is generated tokens per second, not prompt processing speed; memory and swap are the service-level figures printed in the run log.
| Measurement | Runner repair | Gate repair |
|---|---|---|
| Generation speed | 8.7 tokens/sec | 8.2 tokens/sec |
| Service memory peak, as logged | 6.9G | 6.4G |
| Service swap, as logged | 0B | 0B |
These readings do not establish the computer’s total memory requirement or show that the whole computer used no swap. They describe these two calls under this test setup.
The frozen candidate then passed the saved hidden-test suite. Passing that suite demonstrates the tested cases; it does not prove that the suite covered every possible failure.
11 October: give the worker a smaller job.
The next experiments moved from getting a reply to checking a small code change. My retained progress record reports an authenticated local model service, a tool roundtrip limited to the test project, and isolation checks on an unprivileged container.
A corrected tag-normalization function passed all six functional tests. Earlier attempts had failed: one returned empty source, and another produced no tool call. The later result covers that bounded function; the earlier failures stay in the record.
OpenCode was checked separately inside the restricted container. A temporary authenticated bridge then returned a model response, with the model API key kept outside the container. The temporary bridge was cleaned up after the check.
At that stage, a complete OpenCode-to-model edit-and-test loop was still missing. Model registration and a permanent connection had not been established by those individual checks. The later pilot checkpoint below records the next result.
14 October: a supervised end-to-end run.
My 14 October checkpoint reports a completed supervised end-to-end smoke test. It also records 17 generated-function cases passing independent verification. Those are functional cases, separate from the cancellation checks.
The same checkpoint reports the cancellation-hardening work complete, cleanup successful, the test resources gone and the job lock released. Stopping a job needs its own checks, alongside checking the code it produces.
These results cover small supervised jobs in disposable pilot workspaces. They do not establish unattended operation, changes to live projects, or recovery from every possible crash. I still review the generated work.
20 October: a conversation with supplied context.
My command-line results report a supervised Goose/Qwen conversation with three replies. The same approved context was applied on each turn, conversation history was preserved, and the audit reported successful cleanup.
The replies correctly described the limits of that setup: no direct view of the computer, no ability to run or delegate jobs, and no access to files. The useful result was a conversation grounded in the context I supplied, with those boundaries intact.
A separate offline MCP probe also passed its bounded check. That does not establish a working live Goose/model tool connection, accepted broker permissions, arbitrary file access, writes, or unattended execution. The everyday launcher was still the earlier version at this checkpoint.
Next: a separate window for Qwen.
The next proposed step is a separate, private Qwen Gateway. It would let approved assistants ask questions, analyze code I supply, or summarize logs I choose to send. The proposal gives it no shell commands, filesystem browsing, or control of the server.
This gateway remains a separate design handoff. The Goose conversation above does not establish that gateway’s implementation. Its contract, authentication, privacy controls and refusal checks still need implementation and testing.
A useful worker does not need the final say.
The aim is a small, useful contributor inside a system that can reject its work. Faster proposals are welcome. Acceptance still has to be earned.
The September results are based on my saved test history and the 10 September run transcript. The October updates use retained recaps of my reported command-line results, including the 14 October pilot and 20 October Goose/Qwen conversation checkpoints. The original full receipts, offline probe files and current running system were not independently inspected or rerun for this update. The Qwen Gateway remains a proposed handoff. This is a write-up of my own experiments, not an independent benchmark. Private system identifiers are omitted.