Pure Code-Generated Animation: Long-Horizon Autonomous Coding Test and Engineering Breakdown

1. What the phenomenon signals: from generating content to generating programs

In early test reports shared by developers, a flagship-level coding agent that had not yet been officially released completed a notable task: it did not call any image-generation, video-generation, or audio-generation capability. Instead, over roughly 2 hours and 40 minutes, it autonomously wrote, ran, and modified code, eventually producing a 66-second animated short. According to the publisher, the output was 1920×804 at 24fps, and the scene included a fox, paper birds, clouds, text, and lighting changes. The background music and sound effects were also synthesized by code written by the model. No external images, asset libraries, audio samples, or font files were used. The final result was packaged as a self-contained web page that could be opened directly in a browser.

These reports come from developer accounts and community discussion. No formal vendor confirmation has been published, so the appropriate reading is to treat this as evidence of a capability direction rather than a reproducible benchmark.

The technically important point is not whether the visuals are attractive, but that the output format has changed. The traditional AI media generation path is “content generation”: the model outputs pixels or waveforms, and humans edit, color-grade, and mix. Here, the model produces a “program”: the deliverable is an executable rendering project, and the media file is a deterministic output of that project. This shift has three direct consequences:

• Reproducibility: With the same code and random seed, the output should in principle be bit-for-bit identical, rather than requiring another random sampling run.
• Editability: Changing one parameter—such as cloud density, bird paths, or timbre envelope—allows re-rendering without regenerating the entire media asset.
• Deliverable as engineering assets: The deliverable is source code rather than a binary, so it can be placed under version control, code review, and continuous integration.

2. Engineering breakdown I: a deterministic frame-by-frame rendering pipeline

The first principle of procedural animation is a pure-function relationship between time and the visual: given time t, the full state of the frame must be uniquely determined. In practice, this is often organized as follows:

# Illustrative pseudocode: frame-clock-driven rendering
TOTAL_FRAMES = round(66 * 24)        # 66 seconds x 24fps = 1584 frames
for f in range(TOTAL_FRAMES):
    t = f / 24.0                      # seconds
    clear_canvas()
    draw_sky(t)                       # gradient + procedural clouds
    draw_fox(fox_position(t))         # character driven by parameterized path
    draw_birds(flock(t))              # flocking rules (separation/alignment/cohesion)
    draw_text_overlay(text_timeline(t))
    draw_lighting(t)
    encode_frame(f)                   # feed into encoder

Several easily overlooked details determine whether the pipeline succeeds:

1. Randomness must be controlled. Anything that appears random—cloud noise, bird jitter, particles—should come from a pseudo-random number generator with a fixed seed. In addition, the seed for each element should be derived from its identity, not from call order. Otherwise, changing draw order or enabling parallel rendering can introduce unexplained jumps.

# Illustrative pseudocode: derive seeds by identity, independent of call order
def rng_for(scene, entity_id):
    return seeded_prng(hash(scene) ^ (entity_id * 2654435761))

1. Wall-clock time must not be used. Date.now(), adaptive frame-rate step sizes, or tweening based on real elapsed time will cause the same code to produce different results on different machines. All animation quantities must be derived from f / fps.

2. Floating-point and font differences across platforms. Font metrics vary slightly across systems, causing differences in text wrapping, letter spacing, and even baseline position. With zero external assets, glyph outlines are usually provided by code-generated paths or bitmap glyph tables. This is a substantial workload and one of the major time consumers in this type of task.

3. Resolution and encoding constraints. 1920×804 is approximately 2.39:1, a widescreen cinematic aspect ratio. A total of 1584 frames means manual frame-by-frame inspection is impractical; quality must be backed by automated metrics.

3. Engineering breakdown II: asset-free procedural audio synthesis

Music and sound effects synthesized entirely by code are essentially building a small synthesizer inside software. The core technical elements align with widely accepted synthesis patterns:

• Waveforms and timbre: Sine, square, sawtooth, triangle, and noise sources. Timbre is determined by harmonic structure and filter cutoff frequency.
• Envelopes: Attack-decay-sustain-release (ADSR) shapes the volume contour of a single note and is key to making it sound like an instrument rather than a beep.
• Filtering: Low-pass and high-pass filtering shape brightness; formant filtering can simulate vowel sounds.
• Reverb and spatial perception: Implemented through multi-tap delay, all-pass filtering, or convolution; this determines whether the sound feels close-up or in a large hall.
• Audio-visual synchronization: This is the most fragile part of a pure-code approach. Audio and visuals must share the same timeline rather than advancing independently.

# Illustrative pseudocode: note synthesis and shared audio-visual timeline
SR = 48000                                  # sample rate
def render_note(freq, start_sec, dur_sec, env):
    n0, n1 = int(start_sec*SR), int((start_sec+dur_sec)*SR)
    phase = 0.0
    for i in range(n0, n1):
        t_local = (i - n0) / SR
        phase += 2*pi*freq/SR
        amp = env(t_local, dur_sec)          # ADSR envelope
        buffer[i] += amp * (sin(phase) + 0.3*sin(2*phase))
# Key: the animation event table drives both visuals and sound
EVENTS = [ (0.0, "bird_takeoff", 660),      # seconds, event, pitch
           (12.5, "fox_jump", 220), ... ]

Two engineering disciplines are essential: first, avoid clipping; after multiple tracks are mixed, normalization or soft limiting should be applied, otherwise the final output will show obvious distortion. Second, maintain loudness consistency; the target loudness of the final output should align with normalization standards commonly used by streaming platforms to avoid volume levels fluctuating noticeably.

4. The real difficulty: self-verification loops in long-horizon autonomous coding

The 2 hours and 40 minutes are more informative than the animation itself. Distributed over 1584 frames, this averages roughly 6 seconds of wall-clock time per frame, far beyond what pure rendering requires. This indicates that most of the time was spent on iteration: writing, running, observing results, locating problems, modifying, and running again. It exposes the core challenge of long-horizon agent tasks:

1. State must be externalized. The context window cannot hold the output of thousands of frames. The mature approach is to write state into the project files themselves—scene descriptions, parameter tables, event timelines, rendering logs—and read only the necessary fragments on each iteration, letting the file system act as external memory.

2. Objective acceptance signals must exist. Visual results are hard to judge automatically, but many proxy signals can be evaluated automatically: whether it compiles, whether exceptions are thrown, whether the frame count matches expectations, whether the pixel difference between the first and last frames is zero, whether audio peak amplitude exceeds limits, and whether the single-file size is within bounds. Without such signals, a model can only rely on self-satisfaction.

# Illustrative verifier skeleton
checks = {
  "Frame count matches":   frame_count(clip) == 66*24,
  "Resolution":            (clip.width, clip.height) == (1920, 804),
  "No flicker":            max_luma_delta(consecutive_frames) < THRESHOLD,
  "No clipping":           peak_amplitude(wav) <= 0.99,
  "A/V sync":              abs(detect_onset(wav) - expected_onset) < 40ms,
  "Self-contained":        external_requests(html) == 0,
}

1. Failures must support local rollback. In long tasks, a single large rewrite almost inevitably introduces regressions. A workable structure is staged commits: scaffold → background → character → particles → text → audio → mux. Run the verifier after each stage, proceed only after it passes, and save checkpoints.

2. Budget constraints must be modeled explicitly. Time budgets, call-count budgets, and retry budgets should be capped at the orchestration layer. Otherwise, agents can become trapped indefinitely on a visual detail.

5. Engineering implementation: turning the pattern into a production capability

Watching a single demo has limited value. The real benefit comes from integrating this pattern into an existing pipeline.

5.1 Task definitions must be measurable

Do not request “make a good-looking animation.” Request a task with acceptance criteria: duration, resolution, frame rate, aspect ratio, encoding bitrate range, target loudness, maximum audio-visual synchronization error, maximum deliverable size, and zero external dependencies. Measurability is a prerequisite for automation. Vague acceptance criteria turn long tasks into black holes that do not converge.

5.2 Two-layer time model: AI iteration time versus deterministic rendering time

Two kinds of time must be distinguished. Agent iteration time is development cost; rendering time is compute cost. Production environments should aim for a one-time investment in the former and long-term amortization of the latter: once parameters are fixed, subsequent thousands of re-renders do not consume any model calls. This is also the most concrete economic advantage of the pure-code route over a route that regenerates pixels each time—the marginal rendering cost approaches zero.

5.3 Sandboxing and resource isolation

Running autonomously generated code means executing untrusted output, so isolation is mandatory:

• No external network access, to avoid implicit asset fetching and data leakage;
• A file-system allowlist, allowing writes only to designated working directories;
• CPU, memory, and process-count quotas with timeout circuit breakers to prevent infinite loops from dragging down nodes;
• Dependencies restricted to a predefined local package set, with arbitrary runtime installation prohibited;
• Structured logs and call-chain tracing throughout the process to support post-mortem analysis of where things began to go wrong.

5.4 Long-task orchestration: resumability and idempotency

For tasks lasting more than two hours, mid-run failure is the norm rather than the exception. The orchestration layer should provide checkpoints, idempotent steps, failure retries, and a human intervention channel:

# Illustrative orchestration logic
STAGES = ["scaffold", "background", "character",
          "particles", "text", "audio", "mux"]
for stage in STAGES:
    ckpt = load_checkpoint(stage)
    if ckpt and validate(ckpt):
        continue
    for attempt in range(MAX_RETRY):
        artifact = agent.run(stage, context=external_memory(stage))
        report = verifier.check(artifact)
        if report.passed:
            save_checkpoint(stage, artifact); break
        external_memory(stage).append(report.failures)
    else:
        escalate_to_human(stage, report)

5.5 Observability and infrastructure

Long-horizon tasks impose infrastructure requirements quite different from ordinary inference calls: long-lived session persistence, disk storage for large intermediate artifacts, fine-grained log retention, and metrics-based alerting. In concrete deployments, a common combination is container platforms for rendering workloads, object storage for intermediate frames and final outputs, logging services for runtime traces, and monitoring alerts for failure rates and duration distributions. Whether deployed on a public cloud environment or on Baidu AI Cloud, these general capabilities have the same responsibility boundaries and integration patterns; differences are mostly in quotas, billing, and operational details.

6. Acceptance checklist: from “it runs” to “it can be delivered”

Dimension	Check	Typical failure mode
Timing	Frame count, frame rate, and total duration match	Missing frames, frozen final frame
Visual	Adjacent-frame luminance delta, banding, aliasing, flicker	Clouds jump from frame to frame
Motion	Continuity of speed and acceleration, loop seams	Character teleports, frame jumps at loop points
Audio	Peak level, target loudness, sample rate, pops	Clipping when multiple tracks overlap
Synchronization	A/V deviation at key events	Sound effects lag behind actions
Delivery	External requests equal 0, size within limit	Hidden dependencies on fonts or images
Reproducibility	Bit-for-bit identity across two renders	Random seed not fixed
Maintainability	Parameters externalized, scenes decoupled	Thousands of hard-coded lines in a single file

7. Boundaries and risks

A rational view of this capability requires understanding what it is not good at:

• Complex physics remains a weakness. Hair, fluids, cloth, and large-scale particle simulations are not at the same level as professional offline rendering pipelines when produced through general graphics programming. Forcing procedural generation often costs more than it is worth.
• Goal drift exists in long tasks. Once context is crowded by intermediate artifacts, a model may optimize local details while drifting from the overall narrative. Periodic mechanisms for restating task goals are therefore necessary.
• Visual quality lacks reliable automated scoring. Current proxy metrics can catch flicker, clipping, and frame-count errors, but they cannot catch “it looks bad.” Manual spot checks cannot be omitted.
• Compliance and asset provenance. Zero external assets are clean from a copyright perspective, but whether generated glyphs or melodies resemble existing works still requires separate evaluation.
• Energy and cost. Several hours of continuous inference consume substantial compute. It is suitable for scenarios with “one-time development and long-term reuse,” not for high-frequency one-off production.

8. Conclusion and practical recommendations

The value of this test is not how well a fox was drawn, but that it validates a path: when an agent is given a closed loop of writing code, running it, observing results, and correcting errors, it can turn media assets into deterministic, reproducible software engineering artifacts. The barrier to this path lies not in the upper limit of model capability but in supporting engineering:

1. Write acceptance criteria as executable verifiers, not as prompt text;
2. Externalize state into project files so long tasks are not constrained by context length;
3. Use checkpoints, idempotent steps, and budget caps to turn “might not finish” into “recoverable”;
4. Use sandboxing to isolate untrusted code, and logs and metrics to support post-mortem analysis;
5. Distinguish AI iteration cost from rendering compute cost, and invest only in scenarios with one-time development and long-term reuse.

If your team is evaluating this capability, start with a small verifier with clear boundaries: given a duration, resolution, frame rate, and an event timeline, have an agent autonomously produce a bit-for-bit reproducible video in an isolated sandbox, while recording the iteration trace throughout. A minimal closed loop like this is more convincing than any demo video about whether it is worth entering your production pipeline.