Ten programmers ask their AI agents to implement features, run tests, and fix failures. Every agent reports success. The integrated game still breaks.
This article examines ten human programmers, each using AI on the same game—not one person replacing ten developers or running ten agents. Other disciplines may participate; their staffing is unspecified.
The answer is conditional: a shared harness can help, but ten independent agent loops do not automatically become a team. Explicit tasks and broader goals allocate responsibility differently; they are not stages on a ladder toward full autonomy.
This is a design analysis, not a measured rollout. It adapts a Japanese article with an October 15, 2026 evidence cutoff. Staffing, instructions, and workflows are proposals, not repository-tested commands or production results. Engine capabilities refer to the linked documentation; check the versions used by your project.
What a ten-person team needs from AI
A harness provides the environment; a loop controls continuation
In Anthropic's evaluation guide, the harness is the system around a model that handles inputs, coordinates tool calls, and returns results. The useful evaluation unit is the agent system, not the model in isolation.
For a game team, that means more than an instruction file: current specifications, change permissions, build commands, test environments, devices, logs, and evidence.
“Do not break old saves” becomes verifiable when the harness can load representative saves and expose the result. People should be able to use that same check.
Addy Osmani describes loop engineering as designing the mechanism that directs agents instead of issuing every instruction yourself. LangChain describes several nested loops, including tool execution, verification, event-driven work, and harness improvement. The terminology is not completely uniform.
Here, a loop chooses what follows investigation or verification: continue, revise, stop, or request a human decision. Harnesses can contain loops; these are responsibilities, not exclusive product categories.
Two choices remain separate:
| What the agent receives | How execution proceeds |
|---|---|
| A narrow task | It may still iterate through implementation and testing. |
| A broader goal | It may produce a plan and wait for approval before editing anything. |
Instruction scope is not automation level. A short prompt may rely on context supplied by the environment. Without that context, it may simply invite guesses.
The evidence is promising, but it does not prove the team case
OpenAI's February 2026 report describes an internal product built from an empty repository over roughly five months. The engineering team grew from three to seven. The report also describes substantial investment in structure, tools, and ways for agents to inspect the application.
That supports the possibility of shared agent-assisted development—not equivalent productivity for a ten-person game team, an existing codebase, or a team without that investment.
Luden.io's game-development report distinguishes useful applications—bug investigation, QA scenarios, and specification reviews—from unsuccessful attempts at gameplay implementation and autonomous playthroughs. It is one studio's experience, not a universal ceiling. “Your Game Is A Harness” argues for exposing state, reproducing situations, and testing changes. It is an architectural argument, not a comparison of two instruction styles in a ten-person team.
Anthropic's long-running agent work introduced setup, feature decomposition, and durable handoffs when a high-level goal alone was insufficient. Its later application-development report also reduced some scaffolding as model capabilities improved. Together, these examples suggest that neither “just give it a goal” nor “add more checks forever” is a complete strategy.
Productivity findings also need qualifications. In METR's 2025 experiment, 16 experienced open-source developers worked on 246 tasks; allowing AI increased completion time by 19%. That concerns those tools and tasks. A February 2026 update estimated effects in the direction of acceleration, but did not establish a clear speedup; selection effects made the effect size difficult to interpret.
A later survey of 349 technical workers was self-reported and used a convenience sample, with potentially substantial selection bias. Median answers to three work-value questions ranged from 1.4× to 2×; the median reported speedup was 3×. These are not measured causal effects, and speed is not the same outcome as value.
These sources do not directly compare task-based and goal-driven instructions in a ten-programmer game team. What follows is a proposal about conditions for collaboration.
Why ten people can make both the benefit and the risk larger
Shared asset-reference checks and reproducible builds can serve several developers and their agents. Repeated use creates an opportunity to recover infrastructure costs.
The relevant number is how often people reuse those facilities, not company headcount. Human-usable infrastructure retains value even when an AI workflow disappoints.
Individual success cannot simply be multiplied by ten. A solo developer can specify, implement, inspect, and approve a change. A team distributes those decisions.
Suppose UI removes a confirmation state that combat still relies on to block input. Better individual prompts cannot resolve a disagreement about shared behavior.
Generating changes faster can also overload review and integration. While a change waits, neighboring code moves and its assumptions become stale. The useful limit on concurrency is the team's capacity to accept changes, not the number of agents it can launch.
Ten is not a magic threshold: shared benefits matter, but an unlimited platform team is unrealistic. Games need observability because behavior can be hard to verify. That need does not make autonomous loops cheap or easy to deploy.
Share goals at three levels, not one slogan
Imagine every agent receives: “Make this tactical RPG feel faster.”
Combat removes animation time. UI removes confirmations. Progression combines reward screens. Each change reduces waiting. Together, they may remove the information players need to understand what happened.
The goal was shared. The priorities and constraints were not.
A more useful hierarchy is:
- Game intent: reduce waiting without obscuring the player's decisions and their consequences.
- Domain responsibility: combat commits the result once; presentation communicates that result.
- Current change: skipping presentation must preserve those responsibilities.
This is an example, not a required architecture. Higher-level intent guides trade-offs without prescribing every implementation detail.
Record behavioral contracts: who changes state, when events fire, whether they repeat, what consumers may read, and how interruption works. Matching data types is not enough.
Unresolved behavior can be explored, but label it provisional, name the human responsible for approving it, and record dependent implementations. Revalidate those implementations when the contract becomes final. Passing against a provisional agreement is not final approval.
Delegate to a person before delegating to their agent
Delegating “finish combat skipping” to a programmer is not equivalent to forwarding that sentence to an agent. The programmer may know decisions and hold authority the agent does not have.
The human owns the result and chooses the instruction scope. One may delegate a bounded goal; another may use narrow tasks while learning the codebase.
Standardize specifications, authority, acceptance criteria, and evidence—not prompting style. Put stable rules in shared infrastructure, the objective in the task, and new ambiguity in a decision request.
The case for a shared harness is stronger than the case for making every task autonomous. Both instruction styles can use it. The next question is how independent work becomes one working game.
Coordinating task instructions and goals
One programmer assigns AI a combat fix, another a UI goal, and a third an investigation. These workflows can contribute to one feature if they share its definition of completion.
Start with an agreed result, not ten assignments
Assume an approved design: combat commits its result once, independently of presentation, which displays it. Do not silently impose this architecture on a game that works differently.
Both playback modes must preserve the approved outcome, update the display, restore input, and permit required post-battle events. Check visual and audio continuity in the integrated build too.
One illustrative allocation has three combat developers, two UI, two maps/events, and one each for progression/saves, assets/tools, and build/validation. Only some need to work on skipping.
The build specialist does not inherit everybody else's quality responsibility. Domain owners must explain their changes and remaining uncertainty.
A narrow task can still give the agent room to think
A narrow task can specify the problem and boundaries while delegating investigation and implementation choices.
Goal: Fix stale HP displayed immediately after combat presentation is skipped.
Scope: The path that applies combat results to the UI. Investigate it first.
Preserve: Damage calculations, random-number consumption order, and save format.
Verify: Under matching initial state, inputs, and randomness, normal playback
and skipping both show the approved expected HP.
Stop: If the fix requires combat-flow or public-interface changes, report
the evidence and proposed change; do not widen the scope yourself.
Deliver: Diff, reproduction conditions, checks run, and checks not run.
This task includes a purpose and permits the answer: “The fix is outside the authorized boundary.”
By contrast, “Add a cache here” before investigating a loading delay may solve the wrong problem. Separate investigation from implementation rather than assuming the human's proposed solution is correct.
Check random-number consumption before comparing outcomes
A matching seed alone does not guarantee matching combat results. If presentation consumes the same random stream as combat, skipping an effect may change which random values combat receives.
Investigate those consumers and the differences introduced by skipping first. The agent must not silently split streams or redesign combat to make a comparison pass.
Match initial state, gameplay inputs, and relevant randomness; vary the presentation choice. If reproducibility is unresolved, stop before implementation and request a human decision.
Broader goals need authority and acceptance criteria
When the issue spans combat progression, completion notifications, and UI input recovery, a new instruction after every discovery may add unnecessary handoffs. A bounded goal delegates more:
Goal: Whether combat presentation plays or is skipped, preserve the approved
result and restore input for the next turn.
Scope: Combat progression, presentation-completion notifications, and combat UI.
Prerequisites: Human owners have agreed on this change boundary.
Reference the base commit, approved interface contract, and agreement.
Reproducibility and presentation's random-number use are already checked.
Invariants: Preserve damage formulas, combat randomness, and save format.
Preserve the specified count of result-commit events.
Acceptance: Normal playback and skipping must each match independent,
approved expected results for applicable ordinary-combat, defeat,
mutual-defeat, and consecutive-battle cases. Check HP, experience,
next turn, input availability, and event counts.
Evidence: Record the commit, environment, test output, and replay procedure.
Stop: On missing prerequisites, contradictory specifications, out-of-scope
changes, or unavailable validation, stop implementation and report
the evidence and the human decision needed.
Allow at most three repair-and-retest cycles. Do not relax acceptance
criteria to claim success.
Approval is a human workflow, not an agent action. The owner accepts or rejects the change after affected-owner review and integration verification. There is no automatic merge.
Three cycles is illustrative, not an optimum. Also limit time and spending. Include only applicable scenarios; omit mutual defeat if the rules prohibit it.
The benefit is potentially fewer human decisions about the next step—not a shorter initial prompt.
Goals leave implementation choices open, not trade-offs unapproved. The agent proposes more decomposition; the human checks dependencies and boundaries.
Keep local loops separate from integration
The combat owner can assign a task, the UI owner a goal, and the event owner an investigation. They need compatible changes, not identical prompts.
Local loops investigate, implement, test, and revise. Integration checks their combination. “One integration loop” means a common decision path, not one server or agent. Shared issues and human-mediated handoffs are a valid starting point.
Developer A may test against yesterday's UI while developer B tests against yesterday's combat code. Both can pass without anyone testing today's combination.
A clean Git merge is not enough either. Suppose combat now emits the result event once, while UI waits for its second occurrence. The files merge cleanly, but the behavior is broken.
Repeatedly “fixing the other side” can alternate between incompatible assumptions. Agree on the event contract instead of letting agents debate indefinitely.
Synchronize at boundaries, not on every edit
Not every edit needs ten approvals. Internal changes stay with their owner; shared events, data formats, save compatibility, and asset structures need affected-owner agreement.
Identify affected contracts, obtain agreement, plan compatibility, implement, then revalidate integration. Agents can propose changes, not invent missing consent.
Record who authorizes emergency exceptions, why, and which checks must follow.
Record the base commit, specification version, owner, and scope when work starts. If a shared contract changes, pause affected in-flight work and decide whether to resume or redo it. Updating a document does not prove a running agent has incorporated the update.
Label temporary contracts provisional and name a human approver. Record dependent implementations; revalidate when the contract becomes final.
Test the whole interaction—and stop honestly
Exercise battle start, skipping, results, next turn, and required post-battle events in the integrated build. Passing against a stub does not verify the real combination.
Return reproducible integration failures and violated contracts to change owners; do not let an integration agent independently rewrite every domain.
Track implemented, locally verified, integration verified, and approved separately. Also distinguish a failed check from one that could not run.
A second model is not independent proof: it may share the same faulty assumptions. Review the actual commit, approved behavior, and evidence. Normal and skipped playback can agree while both are wrong; check each against independent approved expectations.
Agents may propose corrections to faulty tests. Changing acceptance criteria requires separate approval; the author cannot redefine success and award it to itself.
Stop on success, exhausted budget, lack of progress, missing environment, or a required human decision. Preserve what was attempted, what was learned, what remains unknown, and the conditions for resuming.
Standardize contracts and handoffs, not prompt wording. Narrow tasks, bounded goals, and investigation can coexist in one coherent development process.
Building and measuring a shared harness
Fast coding followed by an integration backlog is not automatically progress. A shared harness must help changes reach a working game.
Start with the smallest complete validation path
Start with current specifications, named owners, distinct completion states, and a path through the target feature in an integrated build. Manual checks are acceptable; orchestration can wait.
Use least privilege and protect confidential information from the start. Resolve contention before sharing resources. Refine permissions, reservations, and performance-measurement paths as adoption expands.
Avoid dependence on one build specialist. Domain owners need verification and recovery procedures; shared infrastructure needs a backup owner. Maintenance is a cost, not free work by an enthusiast.
Make current specifications discoverable
Separate team rules, domain specifications, tasks, and historical decisions. Mark active versions, owners, and provisional/approved status. Update specifications alongside relevant code.
More context is not better when obsolete and current instructions look equally authoritative.
Different AI tools can share build paths, acceptance criteria, and evidence standards. Private chat history must not be the team's source of truth. Check how each tool reads shared rules; placing a file in the repository does not establish compliance.
Each change has a human owner who can explain its scope, evidence, and uncertainty without having typed every line.
Verify at several layers, without pretending they are interchangeable
Unity Test Framework provides Edit Mode, Play Mode, and target-platform testing. Unreal offers an Automation Test Framework and Gauntlet for running and validating game sessions. They provide verification paths, not proof of complete coverage.
| Layer | What it can help establish | What it does not establish alone |
|---|---|---|
| Logic and data | Calculations, state, references, formats | Actual controls or rendering |
| Engine execution | Lifecycle, transitions, event behavior | Target-device behavior |
| Target environment | Rendering, input, performance, built-game behavior | Whether the experience should be accepted |
| Human play evaluation | Clarity, pacing, intended experience | Untested conditions/devices or reproducibility |
Select layers by change risk and record checks not run. Not every edit needs every layer.
For example, Unity's -nographics option does not initialize a graphics device. Success there is not evidence of correct rendering. Batch mode and graphics-free execution are not synonyms.
Screenshots show layout, not timing. Input windows, camera recovery, and sound synchronization need evidence over time. Use video and state logs together: one can miss duplicate events, the other visual glitches. Record the commit, environment, and configuration.
Isolate workspaces, assets, and execution resources
A Git worktree provides another working tree for a repository. It does not prevent semantic conflicts, isolate permissions, or reserve a device.
Separate build outputs, test saves, and logs by execution ID; coordinate shared ports and devices. Unity also prohibits opening the same project in batch mode while it is open in the Editor. Workspace isolation does not solve engine concurrency. See Unity's command-line documentation.
Losing a Unity asset's .meta file can break references. Smart Merge helps merge Scenes and Prefabs; it does not prove correct behavior. Use suitable editor operations and validation; reserve shared assets when concurrent editing is unsafe.
A busy shared CPU or GPU can obscure performance changes. Reserve controlled measurement conditions rather than benchmarking inside every implementation loop.
“Do not publish” is not access control. Keep release credentials and unnecessary write permissions outside ordinary agent environments; require approval for protected operations. Worktrees are not security boundaries.
Review shared-rule changes separately: an unreviewed “improvement” can spread a bad rule to all ten developers. Test limited rollouts, keep a rollback path, and record ownership.
For creative work, finish with comparable candidates
“This battle feels good” is not equivalent to a passing test. Practical Loop Engineering likewise cautions against treating subjective design as automatically suitable for unattended loops.
A workable exit condition is “produce three comparable pacing candidates,” not “continue until the game is fun.” Replay the same battle under matching initial state, input sequence, and relevant randomness. First verify that the simulation and presentation actually support that comparison; matching seeds alone is insufficient.
Humans choose the candidate and next direction. Limit candidate count and variation; selection also costs time.
Shorter battles do not necessarily mean better pacing. Deleting feedback or weakening enemies can improve the metric while undermining the experience. Agree on trade-offs before optimizing.
Compare instruction styles on the same harness
Begin by recording where work goes: preparing requests, intervening in agent runs, reviewing, waiting for environments, integrating, and repairing regressions.
Compare human-decomposed tasks with bounded goals on the same harness. Keep quality requirements and change authority equivalent; do not let only the goal-driven group alter the specification.
Use comparable work and vary assignment/order where feasible. Repeating a task introduces learning. Changing the model, hardware, and instruction style together obscures what helped.
Small trials cannot establish precise causal effects. They can reveal useful work types, failed boundaries, and necessary human intervention.
Measure accepted work, including everybody's time
The endpoint is not “code generated.” It is a change that has passed the required checks, been integrated, and been approved.
Define the observation window before comparing approaches. For example, include rework until the accepted change has passed at least one subsequent integration check and one play evaluation. Track defects discovered after that window separately rather than including them in this particular comparison.
Count active time across requesters, affected developers, reviewers, and integrators. Track agent runtime and queues separately; waiting belongs in elapsed time to acceptance. Include AI charges, infrastructure, setup, and maintenance.
Compare features with similar acceptance conditions, not code volume. Check regressions, reopened/rejected work, and unverified behavior as quality constraints. Faster implementation may create more downstream work.
Pilot one domain, then separately evaluate all ten programmers. Device queues, review congestion, conflicting goals, and stale specifications may emerge only at full scale.
If integration queues grow, reduce work in progress, revisit boundaries, or increase verification capacity—not automatically the agent count. Count expert rescue time. Can another developer understand a stop reason and resume without that expert?
Keep the option to narrow the scope
Different work justifies different autonomy. A stable data validator is not a cross-domain redesign. A prototype and a release candidate need not accept the same change risk.
Return to smaller tasks when broader goals cause unauthorized edits or rework. Move repeated, well-understood human decisions into shared specifications and checks where feasible.
Success is not how long agents run. It is whether ten people move the same game toward completion without breaking one another's work. Harnesses and bounded loops are tools for that outcome, not proof of it.
Top comments (0)