Testing Claude Code's Ultracode Mode: Generating a SQLite SPARQL Extension in 12 Hours

Simon Willison's recent experiment showcased the remarkable output of an AI coding agent in "Ultracode" mode—and also exposed an awkward reality: we may be producing code we cannot understand.

Experiment Background: When "Delete Rows" Becomes a "SPARQL Engine"

In Claude Code's "Ultracode" mode, Simon Willison entered a prompt that contained a typo from mobile input: he asked for a SQLite extension written in Rust, embedding SPARQL and "hitting delete rows directly" for high-speed execution. His intent was "hit the rows directly," but "delete" was an accident.

This small input error, combined with Ultracode mode's aggressive use of dynamic workflows, kept Claude Code for web running continuously for over 12 hours. It generated a large number of Rust crates and automatically coordinated a network of sub-agents to decompose the complex problem.

According to Simon's later notes, when he checked progress the next day, he only appended one prompt: requiring every crate directory to have a README, along with tutorial.md and example data scripts. In the end, he got a "complete SPARQL 1.1 implementation" written in Rust, running inside SQLite.

SQLite extensions are a plugin mechanism provided by SQLite that allows developers to compile dynamic libraries in C/C++ or languages that support the C ABI (such as Rust) and load them at runtime, thereby adding new functions, virtual tables, or query capabilities to SQLite. Since SQLite itself is an embedded database, the extension mechanism gives it extensibility while remaining lightweight. Rust provides safe wrappers around the SQLite C API through crates such as rusqlite, so "writing a SQLite extension in Rust" means the generated crate must properly handle FFI boundaries, memory safety, and error propagation. SPARQL is the RDF graph data query language defined by the W3C; its 1.1 version includes complex features such as graph pattern matching, aggregation, property paths, and federated queries (SERVICE). Implementing SPARQL as a SQLite extension is essentially building a graph query engine on top of relational storage, requiring handling the mapping of RDF triples to relational tables, query parsing, and algebraic execution—so the workload involved is far greater than that of an ordinary script.

Ultracode Mode: How Dynamic Workflows Work

According to the Claude Code documentation, Ultracode mode "aggressively uses dynamic workflows"—it generates JavaScript code to define and coordinate a set of sub-agents, enabling them to collaboratively solve complex problems. This is no longer simple single-shot code completion, but a multi-agent orchestration system.

The advantage of this mode lies in handling long-cycle, multi-module tasks. A SQLite extension involves multiple layers such as a parser, query optimizer, and storage engine interface, while SPARQL 1.1 also includes complex graph pattern matching and federated query features. A single prompt can hardly cover all of this, but dynamic workflows can break it down into manageable subtasks.

Simon's experiment shows that this orchestration can last more than 12 hours, automatically creating multiple Rust crates and maintaining code structure. He only needed to check in at key points and append instructions.

Sub-agents refer to independent AI instances dynamically spawned by a main agent to handle specific subtasks, usually with their own context windows and tool permissions. The main agent orchestrates these sub-agents by generating code or structured instructions—for example, assigning one sub-agent to the parser and another to test cases—and aggregates their outputs. Dynamic workflows emphasize that the orchestration logic itself is not hard-coded in advance but generated by the model at runtime (the Claude Code documentation mentions generating JavaScript to define workflows). This approach suits scenarios with fuzzy task boundaries that require exploration, but it also brings reduced predictability: developers cannot know in advance which modules the agent will create or how it will coordinate them, and reviewers must understand both the generated code and the logic of the workflow itself.

Results and Confusion: Code That Cannot Be Reviewed

The project was named sparqlite and hosted in Simon's research repository. On the surface, it is a fully functional SPARQL 1.1 implementation that can run directly inside SQLite. SPARQL is a query language for RDF data and holds an important place in the semantic web and knowledge graph domains. Combining it with SQLite could theoretically allow an embedded database to query RDF data directly without an additional graph database.

But Simon's confusion is equally real: "This feels like the next level of vibe coding—reviewing the code produced here is fundamentally infeasible, and even following the documentation is a significant investment of effort."

He admits: "I appear to now have a complete SPARQL implementation inside SQLite, written in Rust, but if I created it on a whim and can't (or won't) invest the necessary time to understand what it can do, how much value does it have?"

This touches the core contradiction of AI-assisted programming: generation speed far exceeds comprehension speed. When the code reaches thousands of lines and involves multiple crates and complex algorithms, the cost of manual review may exceed that of writing from scratch.

Vibe coding is a term coined by Andrej Karpathy in 2025, referring to developers mainly relying on natural language prompts to have AI generate code, with themselves more "feeling" the result than reviewing it line by line. Simon calls this experiment "the next level of vibe coding" because the task scale and autonomy have both increased significantly: no longer generating one function at a time, but having an agent work continuously for hours and produce multiple crates. This concept is directly related to code review cost—traditional review assumes the code volume is manageable and the author can explain the design intent; when the generator is an AI and there is no design documentation produced in sync, reviewers must reverse-engineer the intent, and the cost rises sharply. This also explains why Simon emphasizes that "even following the documentation is a significant investment of effort": maintainability depends not only on code correctness but also on whether humans can build a mental model.

Implications for Developers: Balancing Efficiency and Understanding

This experiment offers several reference points for everyday developers.

First, AI agents can already handle modular tasks that would require multiple days of human work. Twelve hours of autonomous operation and automatic coordination of sub-agents mean that some types of projects can greatly compress early-stage development time.

Second, prompt precision is still critical, but fault tolerance is increasing. An accidental "delete" did not cause the project to fail; instead, the AI rationalized it and continued execution. This shows the model's robustness while also reminding us that results may deviate from the original intent.

Third, code review and knowledge transfer have become new bottlenecks. Simon's predicament is not an isolated case: when AI generates large amounts of code, how can teams ensure maintainability? Perhaps future workflows will require AI to simultaneously generate explanatory documentation, test cases, and architecture diagrams, not just code.

Whether the sparqlite project itself will be widely adopted is still unknown, but as a landmark case, it documents the shift of AI coding agents from "assisted completion" to "autonomous construction." For developers following the evolution of AI coding tools, this repository is worth tracking.