I have artificial superintelligence for coding, and all I got were these lousy Rust ports.

We finally built machines that can write software, and our first idea was to make them rewrite software we already have. But memory-safe. Every CEO gets a browser. Every browser gets a launch thread. Every launch thread announces that software engineering has changed forever.

Apparently, the future is the past rewritten in Rust. Who is behind the Coding Agent-Rustacean alliance?

The list is getting long:

• FastRender, a browser rendering engine written from scratch in Rust by Cursor agents
• one-agent-one-browser, another browser engine in Rust, this time built by one human and one agent
• Claude’s C Compiler, a C compiler written in Rust by parallel Claude agents
• JSSE, a JavaScript engine written in Rust by an agent
• VibeSQL, a SQL database written in Rust by agents
• beads_rust, an actual Rust port of Steve Yegge’s Beads
• Bun’s Zig-to-Rust rewrite, completed by a swarm of agents
• Cursor’s SQLite experiment, which rebuilt SQLite from its documentation, in Rust of course

These are not all literal ports. They are the same genre: take a known system, a mature specification, or an existing test suite, and dump enough tokens on it until a giant Rust repository falls out.

My fellow CEOs were impressed. Cursor CEO Michael Truell showed off FastRender, more than three million lines of agent-written Rust that “kind of works.” Stripe CEO Patrick Collison called it the coolest AI breakthrough since GPT-4.

Three million lines that “kind of work”? Add agents, and it becomes a moon landing.

Don’t get me wrong. A browser is hard. A compiler is hard. A database is hard. Recreating one is an excellent agent benchmark. But where is all the novel software? Were we out of ideas? I’ll even take novel software in Rust.

Vibe Coding vs Agentic Engineering#

There is still shame attached to saying, “an agent built this, not me.” Vibe Code. Slop. A Claude logo in the GitHub contributors list is a scarlet letter hanging around your repository’s neck. Maintainers put the disclosure in a warning box. Critics treat it as an admission that the project is fake. Some developers hide the provenance entirely. No shame here, my friends.

In March, I tried to draw a line between Vibe Code and Trad Code. A new, more respectable term of art has replaced “vibe code”: agentic engineering, coined by Simon Willison. Agentic engineering is production vibe code. Vibe code without the vibes. Vibe code with one of those IBM ties from the 80s. The human still decides what to build, writes the specification, gives the agent tools, and verifies the result. The agent writes most or all of the implementation. Tests, builds, benchmarks, screenshots, and actual behavior become the control surface.

Is agentic engineering better than vibe coding? Or when you disclose that agents wrote the implementation, does the project get moved from “software” to “slop”? Who cares? I want more novel software!

But this shame helps explain why the future keeps looking like the past. If agents rebuild a browser, a compiler, or SQLite, the existing specification launders the agent provenance. The product is already respectable. The test suite already exists. The hard questions have known answers. All that remains is to marvel at how quickly the agents typed them into Rust.

A novel agent-engineered project takes two risks at once. The idea might be wrong and the code was not typed by a human. If it fails, nobody learns anything. It was just vibe-coded slop polluting your already slop-filled social media feeds. If the Rust browser fails, at least it was a benchmark.

So, where are all the novel agent-engineered projects? Are they hiding in plain sight? This article is my attempt to highlight novel agent-engineered projects.

Steve Yegge Dragged DoltHub Into the Future#

I did not arrive at this opinion on my own. Steve Yegge dragged us into the future before most of us were ready.

Beads gave coding agents durable, queryable work memory. Agents are great at solving a task and terrible at remembering the project. Beads turns tasks and dependencies into a graph that survives context windows and agent sessions. Steve said Beads was entirely vibe coded and that he had never read its source. As an acknowledgment of Beads’ forward thinking, Anthropic made Tasks a first-class citizen in Claude Code and credited Beads as inspiration.

Gas Town took the next step. Instead of making one agent better, Gas Town organizes many agents into roles. The Mayor assigns work, Polecats implement it, and the Refinery lands it. Beads tracks the work. Gas Town is not really a coding tool. It is an organization chart for synthetic engineers. And gawd do I miss my Mayor sometimes.

When Steve adopted Dolt as Beads’ storage layer, we had a massive incentive to dogfood his approach. Does Gas Town work? Does Dolt help? If it works, is that good for Dolt?

So we started building stuff with Gas Town. But we didn’t want was a Rust port of Dolt. We wanted to build something real, something novel. As I wrote in A Week In Gas Town:

I also wanted a project that could end up being useful. I didn’t want a toy problem. I wanted to fully commit.

DoltLite is SQLite with its B-tree storage engine replaced by Dolt’s content-addressed Prolly Trees, something customers have been asking for pretty much since Dolt was launched in 2019. “I want a local-first Dolt.” It is an embedded SQL database with branch, merge, diff, push, pull, and clone. I built its first version during A Week In Gas Town. It turned into a real database with well over 2,000 pull requests, multiple language bindings, a frozen storage format, and a truly silly amount of testing. I still spend 6 to 8 hours a day on it, mostly evenings.

My success with DoltLite was infectious. Neil hates SQL and always wanted a non-SQL Dolt option. Enter Dumbo: MongoDB plus Git, built on Dolt’s storage engine. Neil built its first version during Two Weeks in Gas Town. I think you see a pattern. Point a Gas Town at an ambitious database idea and see what comes out. We’re still iterating on Dumbo. It’s Neil’s full-time project as evidenced by his weekly articles about it.

Anyway, thanks Steve.

Beads, Gas Town, DoltLite, and Dumbo are not in the ranking below. They are why I went looking. Who else is building cool shit and not hiding the agents that built it?

Selection Criteria#

I scored projects on five dimensions:

1. Agent authorship. Agents wrote essentially all of the implementation, not just a few functions or a prototype.
2. Technical ambition. The project solves a hard systems or infrastructure problem. A thin chat wrapper does not make the cut.
3. Novelty. The project introduces a useful abstraction or is designed around agent-native constraints. Rust points are available in this category.
4. Proof. The maintainers provide tests, benchmarks, real usage, or a concrete artifact that lets us evaluate more than a demo video.
5. Open source utility. The code has a real open source license and is useful as a project, a reference implementation, or a research artifact.

There is also an informal conflict-of-interest tax. If your open source project doubles as a product demo, the Apache license only gets you so far.

No project maxes out every dimension. VibeTensor resembles an existing framework. Symphony is intentionally minimal. Loom is early. Ghidra Headless MCP builds on Ghidra. The rankings are also based on maintainer disclosures, not forensic audits of every commit. This is my list, compiled in two days of research. If I missed your project, just email me. I’m happy to make a revised list in a month. The whole point is to shine a light on novel, new, open-source software built by agents.

The Top Five#

5. VibeTensor#

Tagline

A deep learning system fully generated by AI agents

Creator

NVIDIA Research and collaborators

GitHub

https://github.com/NVlabs/vibetensor

License

Apache-2.0

Agent Provenance

Implementation changes are agent-generated and validated without per-change manual review

VibeTensor is a PyTorch-inspired eager deep learning runtime with a fresh C++20 core, Python and Node.js interfaces, reverse-mode automatic differentiation, its own CUDA allocator and runtime, GPU kernels, plugin interfaces, and experimental multi-GPU support.

At publication, it contains about 60,000 non-blank lines of C++ and CUDA implementation plus another 50,000 lines of tests across C++, Python, and JavaScript. The team ran end-to-end computer vision and language-model training workloads on the generated stack. This is not a toy tensor class that can add two arrays.

Humans gave high-level architectural direction. Agents produced the diffs. Instead of manual reviews of every change, correctness was enforced by builds, tests, and differential checks. The maintainers also published the failure they call the “Frankenstein Effect”: individually correct components can compose into a globally bad design. VibeTensor is correct-first, not competitive with PyTorch, and explicitly not for production.

VibeTensor earns its spot because NVIDIA published the code, tests, methodology, and failure modes. It lands at number five because NVIDIA also makes a tremendous amount of money selling the hardware and software beneath the AI boom. An open-source artifact that says “AI can build deep learning systems” is not exactly adverse to NVIDIA’s interests.

Still, this is how you wash away some of the stink attached to using your tools: do something real with them, release it, and let everyone kick it. VibeTensor is real enough to inspect and imperfect enough to believe.

4. Symphony#

Tagline

Turn project work into autonomous implementation runs

Creator

OpenAI

GitHub

https://github.com/openai/symphony

License

Apache-2.0

Agent Provenance

Codex generated the Elixir reference implementation from the specification

Symphony turns an issue tracker into a control plane for coding agents. Every eligible ticket gets an isolated workspace and an agent. The service watches task state, manages bounded concurrency, retries failures, and keeps an agent working until the ticket reaches a handoff state.

The best part is the distribution format. Symphony is primarily a language-independent SPEC.md. OpenAI pointed Codex at the specification and it generated the Elixir reference implementation in one shot. The team also used generated implementations in TypeScript, Go, Rust, Java, and Python to find ambiguity in the spec. Code became a test fixture for the specification.

OpenAI says Symphony increased landed pull requests by 500% on some teams. That is a vendor claim, so season to taste. The more important change is the abstraction. Humans stop supervising sessions and start managing work. The repository’s WORKFLOW.md captures the operational knowledge that used to live in a senior engineer’s head.

OpenAI has an even more obvious conflict of interest than NVIDIA. It sells the models and coding agent Symphony exists to showcase. Symphony is a product demo with an Apache license.

But again, this is how you wash away the shame. Build something real with your own tool, publish it, and let people judge the artifact. Do OpenAI and NVIDIA know exactly what they are doing? Is this a coordinated campaign to wash away the shame of using their tools, much like the unholy Coding Agent-Rustacean alliance? This Rust situation has me going full Tucker over here.

3. Loom#

Tagline

A capability-secure, manifest-driven agent runtime

Creator

Mikayla Maki

GitHub

https://github.com/mikayla-maki/loom

License

CC0-1.0

Agent Provenance

Entirely vibe coded

Loom is a package and runtime manager for building agents out of reusable parts. An agent.toml manifest declares the model harness, session layers, tools, secrets, and capabilities. loom audit resolves the whole thing so an operator can see what the agent is allowed to do before running it.

The interesting idea is that a tool’s capabilities are also its security boundary. A shell tool can get one directory and no network. A calendar tool can get one executable and network access. Skills can request capabilities, but the manifest sets a ceiling they cannot exceed.

That is agent-native software: software for agents, built by agents. Steve Yegge kind of pioneered this category with Beads, and Loom pushes the idea into runtime security. Humans are not going to manually supervise every tool call made by thousands of micro-agents. We need systems where authority is composable, visible, and machine-checked. Loom is early, and its own README says not to trust it with production data yet. But YOLO.

2. Ghidra Headless MCP#

Tagline

Deep reverse engineering tools for AI agents

Creator

mrphrazer

GitHub

https://github.com/mrphrazer/ghidra-headless-mcp

License

GPL-2.0

Agent Provenance

Code, tests, and documentation are 100% vibe coded

Ghidra is the National Security Agency’s (NSA) open-source reverse-engineering suite. Ghidra Headless MCP gives agents a headless interface: disassembly, decompilation, types, cross-references, patching, scripting, transactions, and undo/redo. The US government’s software powering a “built cool shit” list? What a time to be alive.

This is not a five-tool demo. The project exposes 212 tools across 34 feature groups. It includes a real pyghidra backend, a fake backend for Continuous Integration (CI), an agent-oriented command line interface, and a feature fuzzer. Programs open read-only by default; mutations require explicit transaction and save workflows.

The project earns a spot because it turns a deep, specialized human tool into an environment an agent can operate over time. It is software for agents, built by agents. I’m sensing a theme.

1. CXDB#

Tagline

An AI context store

Creator

StrongDM Software Factory

GitHub

https://github.com/strongdm/cxdb

License

Apache-2.0

Agent Provenance

Built under a factory charter where humans neither write nor review code

Context is the stack trace of an agent. We store source code, build logs, and application telemetry in purpose-built systems, then shove agent conversations into JSONL files and hope for the best.

CXDB gives context a real data model. Turns are immutable nodes in a directed acyclic graph. Payloads live in a content-addressed blob store, something we kind of adore here at DoltHub. A conversation can branch from any turn in constant time without copying its history. Identical tool output is deduplicated. A type registry projects compact MessagePack payloads into typed JSON for user interfaces. Git for context, an idea we’ve been curious about.

This is not architecture fanfiction. CXDB ships a pre-built Docker image, a working React UI, first-party capture wrappers for Codex and Claude, and a test suite.

It is also a product of StrongDM’s Software Factory, whose charter is unusually strict: humans do not write code and humans do not review code. Builds, tests, specifications, and product behavior have to carry the load.

Yes, the storage server is written in Rust. No, that doesn’t disqualify the project. CXDB is a new storage primitive shaped around the branching, append-heavy, enormous-context workloads agents actually create. Novel Rust, not a port. For agents, by agents.

More Than a Rust Rewrite Button#

Agents can reproduce existing software. Burn enough tokens and eventually a Rust repository falls out. We know.

Instead, let’s use this newfound software goldmine to make cool new things. Don’t be ashamed. Be proud of what you built. Imagine how long it would have taken a year ago. Build things you always wished for but thought “too hard”. Look for inspiration in the “For agents, by agents” category like the leaders on this list.

DoltLite would have taken at least 3 years of human effort. It existed in 3 months. That’s cool, not lame.

If I missed a worthy project, come yell at me on Discord or email me. Bonus points if it is not written in Rust, and automatic disqualification if the README says “blazingly fast” - the “open sesame” to the Rustacean clubhouse.