Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition

In 2021, Jonathan Kelley spent his final undergraduate summer starting Dioxus, a cross-platform application framework written in Rust. The proposition was appealingly direct: build web, desktop, and mobile interfaces with Rust, HTML, and CSS instead of moving among platform-specific languages, IDEs, and build systems. Rust would produce native applications without a virtual machine, JavaScript runtime, or inter-process bridge, while familiar web markup and React-inspired reactivity would preserve access to web concepts and tooling. 0:22

The easy-sounding abstraction concealed an enormous implementation burden. In the ecosystem available at the time, Dioxus could not simply assemble ready-made pieces for reactivity, font rendering, hot reloading, and bundling. The team had to build much of the application stack itself. “Building a web browser” became one of the necessary intermediate steps rather than an adjacent research project. 1:53

Five years later, Dioxus supported the major capabilities in that original plan: shared full-stack and native code, cross-platform rendering, hot reload, and bundle splitting. Kelley reported nearly 37,000 GitHub stars, millions of downloads, and an estimated cumulative audience above 200 million across applications including AI assistants, voting software, data-science tools, and satellite collision-avoidance systems. The end-user figure is an estimate presented in the recording, not a measured deployment census. 2:29

The developer experience was deliberately compressed around a conventional Rust project: fewer files, unified tooling, optimized assets, little platform-specific code, and a main.rs entry point. That simplicity mattered because the product was not only its visible output. Developers had to understand the project structure, compile it across platforms, and build businesses against its APIs.

Two projects show how far the team pushed the stack. Blitz is a lightweight HTML and CSS renderer built from a browser-grade CSS engine extracted from Firefox, a custom HTML/DOM implementation, and a hybrid GPU pipeline. Kelley reported Blitz applications below five megabytes and below 50 megabytes of runtime memory. Subsecond watches Rust, C, or C++ source files, recompiles only the changed portions, and patches the running native application in place in roughly 100 milliseconds; the same approach extends to Rust compiled to WebAssembly. 3:59

Those systems established the quality culture that shaped the later agent experiment. A small team had spent years reading every contribution, maintaining an ambitious release cadence, and writing essentially all of Dioxus by hand. Generated code would be judged against that existing standard, not merely against whether it compiled or demonstrated a feature.

The team had been skeptical that agentic coding and high-quality systems work belonged together. That changed when coding agents became markedly better at Rust. The team responded by exhausting its coding-agent subscriptions and generating tens of thousands of lines for long-desired features, integrations, and bug fixes. Almost none of that output cleared the question that mattered: should this be merged? 5:37

The code remained in drafts because implementation volume had outrun reviewable quality. Kelley calls this failure mode becoming a “slop cannon”: an agent can rapidly produce plausible changes, but every unmerged change still consumes attention, creates uncertainty, and competes with real maintenance work. The observable result was not a faster product. It was a much larger queue of code that the maintainers did not trust.

The postmortem produced a surprising reversal. Dioxus had spent years making Rust easier for people through readable code, good tools, and helpful errors. Agents were less sensitive to that ergonomic work. Instead, they handled Rust’s mechanical burden directly: following edge cases, satisfying the type system, and repeatedly negotiating with the borrow checker. The learning curve the team had tried to flatten for humans became useful because an agent could absorb it while preserving Rust’s compile-time constraints. 7:00

The lessons apply most strongly to foundational software, where users build on the code itself. Research prototypes can prioritize discovery, and an application may hide its internals behind a polished interface. Dioxus has to keep working, remain fixable when it fails, preserve APIs across patch releases, and maintain accurate examples, documentation, tests, and benchmarks. A shortcut in the framework becomes somebody else’s broken build or stalled business. 8:00

Velocity therefore compounds through the existing architecture. New work lands on a “substrate” made of module boundaries, APIs, tests, and maintenance conventions. A sound substrate makes later features easier to add and repair. A poor one turns every additional feature into another dependency on an unstable base. Dioxus still has dozens of desired features, but shipping them faster cannot justify breaking APIs relied on by millions of users.

The first strong use case was not indiscriminate feature generation. It was knowledge-heavy engineering. A three-person core team cannot retain every detail of every operating system, build system, runtime, language, API, binary format, and implementation quirk. Coding agents can patiently search documentation, inspect bespoke interfaces, examine binaries, and compare unfamiliar implementations without becoming tired of the investigation. 9:56

A concrete example was adding deeply integrated Kotlin and Swift plugins to Dioxus’s build system. Comparable native-module infrastructure had taken years of handwritten development elsewhere. With agents, Dioxus shipped its version in roughly two to three weeks. Kelley recalls that the initial implementation may have arrived in about a day; the remaining time—roughly two weeks—went into designing test cases and exercising the integration on real devices. Generation accelerated the first draft, but verification still dominated the path to a shippable feature. 10:56

Blitz supplied another good fit. CSS painting and layout bugs often require reading specifications and checking how established browser engines handle obscure cases. An agent can retrieve the relevant rule and compare Chrome, Safari, or WebKit behavior while the engineer stays focused on the local rendering problem. That reduces the pressure to insert a quick workaround simply because investigating the correct behavior would otherwise take too long.

These examples share a useful boundary: the system already has an architectural destination, while the agent supplies patient research and implementation labor. The agent makes doing the careful version cheaper. It does not decide whether the integration belongs in the product or how the surrounding system should evolve.

The less glamorous use case may be more valuable: agents can repeatedly perform work that a small team cannot afford to do by hand. Checking that a release tarball extracts into the correct directory or confirming that examples and documentation still match the code consumes time that could otherwise go into architectural work. Editor extensions illustrate the harder edge of this problem: a team may struggle to retest an extension after every patch, but verifying that it installs in Zed and works during actual use is difficult for agents too. Automating release chores does not by itself solve that end-to-end check. 12:15

Three recurring mechanisms paid off:

• Release verification: Agents can walk release checklists and inspect packaging details consistently.
• Maintenance across branches: They can backport bug fixes onto stable releases, reducing the manual cost of supporting shipped versions.
• Documentation audits: They can find missing examples and stale comments, including comments that still describe behavior changed by a human code edit.

Kelley links this automation to a concrete operational change: the latest Dioxus version had received more patch releases than any previous one, with releases arriving weekly or multiple times per week. The talk does not isolate which automation contributed how much, but the team became willing to release at a cadence it previously considered too risky.

Testing exposed the boundary of this success. An agent can write a test for nearly any API, but that does not mean it has chosen a consequential behavior. Given a constructor, it may simply test that constructor. Foundational end-to-end behavior requires product knowledge, an appropriate test interface, and a runner capable of reproducing the environment. Humans still enumerate the important conditions and build much of that testing structure. 14:21

Agents remain useful as a sounding board for candidate conditions and edge cases, and they excel at constructing fuzzing harnesses. A fuzzing harness repeatedly drives software with millions of ordinary, malformed, or adversarial inputs to expose crashes and assumptions that hand-written examples miss. Here the target behavior is already clear—feed varied inputs into a defined interface and report failures—so the agent can handle the repetitive harness construction without being asked to decide what product behavior matters most.

Once implementation becomes cheap, architecture consumes more of the schedule. Agent contributions inherit the quality of the system they enter: a poor foundation still produces poor contributions, even when code arrives at exceptional speed. When a feature does not fit, an agent may readily undertake a huge refactor or redesign the architecture rather than hesitate over the scope of the change. Humans and agents can both write spaghetti code; agents can now write it faster. Dioxus consequently spends much of its development time deciding which future features the architecture must accommodate and how today’s interfaces should leave room for them. Kelley expects architecture to take an even larger share of engineering time as implementation improves, provided developers communicate their intent clearly. 16:03

What separates generated code from shipped software? The diagram synthesizes the practices described here: architectural intent shapes implementation, tests and real-device checks examine behavior, and maintainers read the code they ship. Its arrows show relationships rather than a fixed release order. In the Kotlin and Swift integration, an initial implementation arrived in about a day, while test cases and real-device testing took roughly two weeks. That contrast makes the remaining work visible: producing code quickly still leaves substantial work to decide whether it belongs in the product.

Dioxus still reviews every pull request line by line, using AI review as another bug-finding input rather than a replacement for maintainers reading what they ship. Open-source contributions make this especially important: contributors often want one bug fixed or one feature accepted, while maintainers have to consider the codebase’s long-term shape. A locally successful patch can still be glued into the wrong abstraction.

Intent must also travel through text. Agents cannot infer the maintainers’ unwritten model of how Dioxus should evolve, and contributors may not communicate that model clearly. Prompt quality therefore affects implementation quality in a practical sense: a better description carries more architectural decisions, constraints, and acceptance criteria into the agent’s work. It is not mind reading, and it does not remove the need to inspect the result.

The technical conclusion is deliberately old-fashioned: reading code eventually matters more than writing it. Coding agents make lines of code cheap, but they do not make quality cheap. Engineering value remains in choosing an elegant shape for a complex system, anticipating how it will change, preserving flexibility, and taking responsibility for what ships. Faster implementation raises that bar because weak decisions can now propagate much faster. 18:03

Kelley closes by connecting that work to Cognition: Cognition acquired Dioxus, and the Dioxus team joined the company. He also notes that Cognition is hiring people to work on the next generation of software-development tools. 18:41