A personal experiment published on GitHub says the combination of model and harness can materially affect the quality of AI-generated frontend code. On the event date, September 8, 2026, the author of the Hangar Harness / Model Tests page said they had been testing the same prompt across different model and harness setups to see which combination produced the best result.
The prompt itself was narrow and visual: build a single-page Three.js sci-fi hangar with hovering drones, warning lights, emissive runway strips and fog planes, then add a drone-formation toggle and a cinematic camera path. The output had to be a self-contained HTML file with inline JavaScript. The setup is useful because it constrains the task while still leaving enough room for the model to make design and implementation choices.
The page says the author compared ten model/harness combinations. The test matrix includes GLM runs labeled GLM 5.3 Flash Max, and the page explains that the reported token counts and reasoning counts vary depending on how each harness exposes its telemetry. It also notes that some harnesses do not report separate reasoning counts and that some durations combine two turns while excluding the pause between them. Those details matter because they make the comparison less like a clean lab benchmark and more like the kind of messy real-world experimentation developers actually do.
The broader takeaway is that harness behavior is not just bookkeeping. If one setup exposes reasoning separately, another folds it into output tokens, and a third reports tool errors differently, the apparent performance of a model can shift depending on what you measure. That means comparisons between model runs can be misleading if the harness itself is not understood.
The author also records tool errors as failed events, which is another reminder that coding-agent evaluation is not just about the final HTML file. A model may fail because it cannot reason about the task, because the harness interrupts it, or because the tool chain introduces friction. In practice, developers care about the whole pipeline, not only the code emitted at the end.
The experiment does not claim to settle which model is best. Instead it reads as a practical note from someone trying to answer a narrower question: what actually changes when the same prompt is run through different orchestration layers? That question is becoming more important as AI coding tools multiply. The result of a prompt is no longer just a function of the model; it also depends on the surrounding scaffolding, telemetry and retry behavior.
For anyone building with agentic coding tools, the lesson is straightforward. If the output quality varies from one harness to another, then benchmark results and day-to-day developer experience may diverge in ways that are easy to miss. A model that looks weak in one environment may appear stronger when the control flow, error handling or logging changes. Likewise, a prompt that seems reliable in a polished UI may break down in a bare-bones setup.
The page is small, but it points to a larger trend in AI development: orchestration is becoming part of the product. The model is only one component. The harness decides how much feedback the model gets, how failures are recorded and how much visible reasoning survives the trip to the user. If you are evaluating coding agents seriously, those layers are no longer optional detail; they are part of the result.
