1. Experiment Background: Handing the Wheel Entirely to AI

1.1 What Is Black-Box Software Development

Mainstream AI-assisted programming still follows a human-led, AI-supported division of labor: humans break down requirements, review approaches, and control code quality, while AI handles completion and generation. This experiment deliberately went to the opposite extreme: black-box development.

• Humans only issued requirements or commands, without participating in code review, unit testing, or debugging.
• All intermediate artifacts, including design documents, code implementation, log analysis, and regression testing, were produced independently by AI.
• The goal was to verify whether AI could autonomously complete the full loop of design, coding, debugging, and end-to-end testing with zero manual code inspection, and reliably deliver runnable services.

By analogy, AI-assisted programming is like a human sitting in the driver’s seat and taking over at any time. Black-box development is more like handing the car to autonomous driving, with humans only setting the destination and acceptance criteria. An additional goal was to produce a reusable AI coding SOP and an efficient automated testing strategy.

1.2 Experiment Boundaries

To keep the results measurable, the experiment set four hard boundaries:

1. Task scope: Focus on backend and algorithm logic, excluding frontend interfaces. The core outputs were runnable services and supporting scripts.
2. Delivery threshold: All end-to-end test scripts passing was defined as success. Code readability, comments, and elegance were not included in the evaluation. This was intentional: the first objective was to understand the ceiling of pure functional delivery capability.
3. Resource model: The experiment continuously consumed resources at the highest allowance available under one coding subscription, totaling about 3 billion tokens over 30 days. Another model used as a comparison exhausted its weekly allowance completely for four consecutive weeks.
4. Unattended constraint: Humans were allowed to observe the process but not intervene. All corrective instructions were automatically initiated by the scheduling system after test failures.

From a resource perspective alone, 3 billion tokens spread across 30 days is roughly 100 million tokens per day. If a full agent loop — reading the codebase, writing a plan, coding, running tests, analyzing logs, and fixing issues — consumes several million tokens, this translates to dozens of autonomous iterations per day. This also shows that token allowance durability is itself the lifeline of this type of experiment, which will be discussed later as a dedicated evaluation dimension.

2. System Architecture: Task Scheduling Bus + Containerized Workers

The first question black-box development must answer is: without a human supervisor, who supervises? The answer is the architecture itself.

2.1 The Bus + Worker Two-Layer Structure

Human requirements (natural language + acceptance criteria)
        │
        ▼
┌────────────────────┐     Task dispatch    ┌──────────────────────┐
│  Task scheduling   │ ──────────────────▶ │ Containerized Worker × N │
│  bus (AI overseer) │ ◀────────────────── │ Independent coding / running / testing │
└────────────────────┘     Status report   └──────────────────────┘
        │
        ▼
End-to-end test scripts ──pass──▶ Delivery
        │
       fail ──▶ Automatic attribution → fix → retest (loop)

• Task scheduling bus: Operated by a resident overseer agent, it is responsible for decomposing human requirements into subtasks with acceptance criteria, dispatching them to workers, collecting results, and deciding whether to retry, rework, or mark a task as failed.
• Containerized workers: Each worker runs in an isolated container with an independent code copy and runtime environment. A single task crash does not affect the bus or other tasks, and the setup naturally supports an atomic fail-and-rebuild approach. This environment can be built with local containers or run on general-purpose cloud container services. The key is ensuring isolation and reproducibility.
• Acceptance loop: Each subtask must include an executable acceptance script. A worker reporting completion does not count; passing tests is the only credible progress signal in black-box mode.

2.2 Minimal Task Description Specification

Whether the scheduling bus can operate reliably depends heavily on whether task descriptions are machine-verifiable. In practice, a minimal usable specification looked like this:

task:
  id: notify-order-delay
  goal: Trigger delayed notification when an order is not shipped on time
  acceptance:
    - tests/e2e/test_order_delay_notify.py all cases pass
  retry_budget: 5         # Retry budget to prevent unlimited token burning
  context_isolation: true # Isolated container, rebuild on failure

retry_budget and context_isolation are two easily overlooked but critical fields, corresponding to the fifth dimension, token durability, and overall stability.

3. Evaluation Framework: Five Dimensions

Simply asking whether the system can run is not enough to characterize AI development capability. The experiment divided evaluation into five dimensions:

Dimension	Sub-dimension	Evaluation Basis
A	Solution design and code structure	Consistency between directory, file, and path naming and the initial design
B	Coding correctness	Compilation/startup success rate, frequency of runtime crashes
C	Defect localization and repair	Whether a single conversation can produce root cause and minimal change; detection of deep design flaws
D	Autonomous end-to-end test closure	Whether the log analysis → modification → retest loop can converge unattended
E	Token/allowance durability	Whether resource consumption can sustain prolonged trial and error

Dimensions A and B measure the ability to get things right on the first attempt. Dimensions C and D measure the ability to recover from mistakes independently. Dimension E measures the endurance to afford that recovery. Together they form the necessary and sufficient conditions for autonomous delivery.

4. Key Findings

4.1 Design and Coding: High Consistency, but Noticeable Redundancy

For dimensions A and B, models that performed well generally understood the structure and conventions of the existing codebase correctly and produced structured design documents that clearly listed new and modified file paths. Quantitatively, the ratio of directory structures consistent with the expected design exceeded 80%, meaning the engineering skeleton produced by AI was broadly reliable. A lightweight human involvement model of reviewing the plan rather than the code appears feasible.

However, two problems appeared repeatedly:

1. Redundancy and over-engineering: AI tended to introduce unnecessary abstraction layers and modules that might be useful in the future. One counterintuitive observation was that overly templated specification constraints actually aggravated this problem: AI would mechanically pile up defensive structures according to the template. After relaxing the constraints to only interface contracts and directory conventions, without restricting implementation details, redundant code decreased significantly. This suggests that specification constraints should serve as anchors rather than cages.
2. Low-level implementation errors: Surface errors such as variable typos, boundary conditions, and asynchronous timing issues were unavoidable and required multiple rounds of local repair. At this level, different models did not differ much and could be placed at the same capability tier. In other words, being able to write code is now a common capability. The real gap lies elsewhere.

4.2 Defect Diagnosis: Attribution Depth Determines Interaction Cost

Dimension C was where different models diverged most clearly. The experiment observed two typical behavior patterns:

Indicator	Deep-attribution behavior	Surface-patching behavior
Localization depth	Tends to provide design-level root cause in one pass	Mostly stays at surface-level code errors
Interaction rounds	Usually converges in about 1.x rounds	Often requires 3–5 rounds of guidance
Solution completeness	Presents multiple options for confirmation first	Tends to modify code directly and requires mid-course interception
Probability of wrong patches	Low	High, easily triggering new problems in a chain reaction

The engineering cost difference between the two patterns is significant. The typical loop of a surface patcher is: change one line, run tests, another assertion fails, change another line. It looks diligent, but it is essentially whack-a-mole without understanding the design intent, and it can easily spread local problems into cascading failures. A deep attribution pattern first answers why the error occurred, then answers what the minimal change should be.

The resulting SOP insight is: for models that tend to act directly, a mandatory protocol of attribution before action must be enforced. Before making changes, the model should be required to output a root cause hypothesis, impact analysis, and a minimal change plan. Only after confirmation by the bus can changes be applied. This interception mechanism compresses 3–5 rounds of inefficient guidance into 1–2 rounds.

4.3 Autonomous End-to-End Test Closure: Convergence Depends on Log Quality

Dimension D validates the capability closest to unattended operation: after a test failure, can AI rely solely on logs to complete the analysis → modification → retest loop? The findings are threefold:

1. Structured logs are the lifeline of closed-loop operation. Unstructured stack traces significantly reduced attribution accuracy. Structured output with context, expected assertion values, and failed step numbers allowed most failures to be repaired autonomously within 1–2 rounds. A minimal usable autonomous repair loop looks like this:

def autonomous_fix_loop(task, max_rounds=5):
    for _ in range(max_rounds):
        result = run_e2e_tests(task)
        if result.passed:
            return deliver(task)
        diagnosis = agent.analyze(result.structured_logs)
        patch = agent.propose_minimal_change(diagnosis)
        apply_patch(task.workdir, patch)
    return escalate(task)   # Exceeded retry budget, escalate

1. A retry budget is essential. An autonomous loop without an upper bound has two negative consequences: unlimited token burning and error fixes stacking on top of error fixes, polluting an originally clean workspace to the point where rollback becomes impossible. In this experiment, all tasks had a five-round limit. Beyond that, the workspace was frozen and left for manual review.
2. Failures can be classified, and strategies can be tiered. Assertion failures, missing environment dependencies, and race conditions should be handled differently. The first two are suitable for autonomous AI repair. Race conditions and timeout issues have a low autonomous repair success rate and tend to oscillate, so they should be escalated earlier.

4.4 Token Durability: The Hidden Threshold for Long-Cycle Trial and Error

Dimension E is often overlooked, but it directly determines whether the experiment is feasible. Three observed patterns:

• Context expansion is the largest consumption source. As the codebase grows, the context cost carried by each session rises linearly. The countermeasure is task-level context isolation: each subtask only carries code slices relevant to it, rather than the entire repository.
• Failed loops burn the most resources. A failed iteration includes reading code, writing code, running tests, and analyzing logs. Its cost can be several times that of a successful iteration. Reducing the failure rate in dimensions C and D is itself the best cost optimization.
• Allowance consumption should be smooth rather than pulsed. Using up the entire allowance in bursts causes complete stagnation in the later phase and artificially fragments the autonomous loop. A stable consumption rhythm is friendlier to long-cycle projects.

5. The Resulting AI Coding SOP

Based on 30 days of observation, a reusable black-box AI development SOP can be summarized into six rules:

1. Specifications first, but lightweight: Have AI produce a design document first, covering directory structure, file paths, and interface contracts. Humans review only the design, not the code. Constrain directory and contract conventions, not implementation details. The fact that directory consistency exceeded 80% shows this step has the highest return on effort.
2. Atomic tasks: Each subtask must include an executable acceptance script and a retry budget. Self-reported completion is never accepted.
3. Mandatory attribution protocol: Require the model to output a root cause hypothesis and a minimal change plan before making modifications, to intercept the tendency to act directly.
4. Structured logs: Design log formats for AI rather than humans, making failure information machine-readable.
5. Environment isolation: Execute in containers with fail-and-rebuild semantics to prevent dirty state from spreading across tasks.
6. Retry budget plus escalation mechanism: Set an upper bound for autonomous loops. Beyond that, freeze the workspace to protect token allowances and workspace cleanliness.

6. Conclusion and Outlook

The core answer from this experiment is: under appropriate architecture and protocol constraints, AI can already complete the design → coding → debugging → end-to-end testing loop unattended and reliably deliver runnable backend services. The output of 30 days, 3 billion tokens, and 110,000 lines of code validates the feasibility of this path while also exposing a clear sequence of weaknesses: a tendency toward surface patching, an impulse toward over-engineering, and high failed-iteration costs.

The next improvement directions are therefore clear: compensate for attribution depth through interaction protocols, reduce redundant design through appropriate specification anchors, and lower token costs through task-level context management. For engineering teams, the most valuable action right now is not waiting for more powerful models, but building this evaluation framework and SOP first. Regardless of how model capabilities evolve, this pipeline of bus + workers + acceptance loop will continue to benefit.