Sparqlite：12 小時的 Ultracode 智能體編排揭示 Vibe Coding 的侷限

Simon Willison pointed Claude Code at a single prompt and walked away. Twelve hours later, he had a full SPARQL 1.1 implementation in Rust that runs inside SQLite, complete with multiple crates, READMEs, and a tutorial. He also had a problem: the code works, but he cannot feasibly review it, and he's not sure what to do with it.

This is the sharp edge of agent orchestration at scale. When dynamic workflows spawn subagents that partition work across modules, the human who commissioned the project loses the ability to audit, understand, or maintain the output. The code runs. The tests pass. The documentation exists. But the human is no longer in the loop.

How Ultracode Orchestration Works

Claude Code's Ultracode mode uses dynamic workflows to coordinate subagents. Instead of a single agent grinding through a task linearly, the orchestrator generates JavaScript that defines a network of subagents, each responsible for a slice of the problem.

In Willison's case, the initial prompt was:

Write a SQLite extension in Rust that implants SPARQL and runs really fast because it can hit the delete rows directly

The typo ("delete" instead of "direct") didn't stop the agent. It proceeded to:

• Partition the SPARQL implementation into multiple Rust crates
• Build a cost-based query planner
• Implement integer-encoded terms and covering indexes
• Write batched join logic
• Generate a direct SQLite B-tree reader for performance
• Pass 636 of 639 W3C SPARQL evaluation tests

The orchestrator decided when to spawn new subagents versus continuing in a single thread. The folder structure reveals the partitioning strategy: a crates/ directory with each crate handling a distinct layer (parsing, planning, execution, storage).

Willison's follow-up prompt requested documentation:

Every folder in the crates/ directory needs a README. Include a tutorial.md teaching users how to install the extension and how to run it in the SQLite CLI and then teaching them SPARQL in addition to how to use the SQLite extension. Include a script with the tutorial for populating a SQLite database with useful and realistic example data for that tutorial.

The agent complied. The documentation exists. But documentation generated by the same subagent network that wrote the code does not substitute for human code review.

The Folder Structure and Dependency Graph

The crates/ directory structure shows how subagents partitioned work:

• Parser crate: SPARQL 1.1 syntax to AST
• Planner crate: Cost-based query optimization
• Executor crate: Batched join execution and result streaming
• Storage crate: Integer encoding, B-tree access, quad indexing
• FFI crate: SQLite extension interface and registration

Each crate has its own Cargo.toml, README, and test suite. Dependencies flow from FFI down through executor and planner to storage. The subagents respected Rust's module boundaries and built a clean dependency graph.

This is impressive. It's also unauditable. A human reviewing this code would need to:

• Understand SPARQL 1.1 semantics
• Verify the cost model in the planner
• Audit the B-tree reader for correctness and safety
• Check the FFI layer for memory leaks and SQLite API compliance
• Trace execution paths through batched joins

The agent ran for 12 hours. A human review would take weeks.

What Observability Would Close the Gap

Agent-generated code at this scale needs observability that doesn't exist yet. Here's what would help:

None of these exist in Claude Code's Ultracode mode today. The agent produces code and documentation. It does not produce a review trail.

When Vibe Coding Breaks Down

Willison describes this as "next-level vibe coding." He created a full implementation "on a whim" but can't invest the time to understand it. This is the failure mode:

• The agent succeeded at the task.
• The human succeeded at delegating the task.
• The human failed to retain stewardship of the output.

Vibe coding works when the output is small enough to review or when the human doesn't care about correctness. It breaks down when the output is large, complex, and mission-critical.

The SPARQL extension is not mission-critical for Willison. He can walk away. But if this were a production system, the lack of human understanding would be a security and maintenance liability.

Architecture of the Generated Extension

The extension uses a quad-store model with integer encoding:

// Simplified representation of the storage layer
struct QuadStore {
    // Integer-encoded terms (URIs, literals, blank nodes)
    term_dict: HashMap<String, u32>,
    reverse_dict: HashMap<u32, String>,

    // Quads stored as (subject, predicate, object, graph) tuples
    quads: Vec<(u32, u32, u32, u32)>,

    // Covering indexes for common access patterns
    spo_index: BTreeMap<(u32, u32, u32), Vec<u32>>,
    pos_index: BTreeMap<(u32, u32, u32), Vec<u32>>,
    osp_index: BTreeMap<(u32, u32, u32), Vec<u32>>,
}

The planner selects indexes based on query shape. The executor uses batched joins to minimize SQLite API calls. The B-tree reader bypasses SQLite's SQL layer and reads pages directly.

This is a reasonable architecture. It's also one that a human would need to audit for correctness, especially the B-tree reader, which operates outside SQLite's safety guarantees.

Failure Modes

Here are the likely failure modes for agent-generated code at this scale:

1. Semantic drift: The agent misinterprets the spec and implements a subtly wrong version of SPARQL. The tests pass because the agent wrote the tests.
2. Memory unsafety: The Rust code uses unsafe blocks to access SQLite's B-tree. The agent doesn't have a mental model of SQLite's invariants.
3. Performance cliffs: The cost model in the planner is wrong for certain query shapes. The benchmarks don't cover those shapes.
4. Dependency rot: The generated code depends on specific versions of Rust crates. Those crates break in six months. No human knows how to fix it.
5. Undocumented assumptions: The agent made assumptions about SQLite's internal layout. Those assumptions break in a future SQLite release.

All of these are standard software engineering risks. The difference is that the human who commissioned the code doesn't have enough context to mitigate them.

Technical Verdict

Use Ultracode orchestration when:

• You need a prototype fast and don't care about long-term maintenance.
• The output is small enough to review (under 1,000 lines).
• You have domain expertise to audit the generated code.
• The task is well-specified and has a clear correctness criterion (like passing a test suite).

Avoid it when:

• The output will run in production.
• You lack the expertise to review the generated code.
• The task is ambiguous or requires judgment calls.
• You need to maintain the code over time.

Willison's experiment exposes the gap between "the agent built it" and "I can use it." Until orchestration systems produce observability trails that let humans audit subagent decisions, large-scale agent-generated code will remain a curiosity, not a tool.

Source Links

• sparqlite: SPARQL 1.1 inside SQLite, written in Rust (Simon Willison)