Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition

Hello. My name is Jonathan Kelley, and today we're going to talk about what it means to build ambitious software in the age of AI.

Five years ago, I made the first commit ever to a project called Dioxus. I used the last summer I had as an undergraduate, and instead of getting an internship at Google or doing research in AI like many of my friends at the time, I spent it exploring an idea I had for a cross-platform app framework written in the Rust programming language.

In 2021, Rust was still pretty niche, but the ecosystem was growing, the tooling was improving, and the pitch of native performance, a solid type system, and simple cross compilation really sold me. It's extremely nerdy.

The idea for Dioxus was straightforward: what if we had an actually good cross-platform app framework? Instead of wading through dozens of toolchains, programming languages, and IDEs, what if we simply wrote all of our apps in Rust using HTML and CSS as the markup language?

This was back in the day, 2021, where React Native was janky, Flutter was too slow, and neither performed well with native APIs. On the flip, with Rust, we could build native apps directly, with no VM, no IPC, no JavaScript, and if we used a little bit of HTML and CSS for the UI and took some inspiration from React for the reactivity, we could reuse vast amounts of web components and web tooling.

The goal was an extremely powerful app framework that was still quite familiar to the average developer.

Sounds easy,right? Well, as they say, we choose to build an app framework from scratch, not because it's easy, but because we thought it would be easy. In reality, trying to challenge React Native and Flutter is extremely ambitious. In 2021, there were very few off-the-shelf components you could use to build Dioxus.

Everything from reactivity to font rendering to hot reloading and application bundling had to be built from scratch. There was nothing we could use. For us, tasks like building a web browser were just necessary steps along the way.

Now, today, in 2026, Dioxus has achieved and far surpassed its original mission. We support all the features we originally set out to build, from cross-platform support to native rendering to Rust hot reload and bundle splitting. We've basically reinvented and improved the entire app development stack.

Users can ship a powerful full-stack web application in the exact same codebase, sharing components as their iOS and Android apps. The Dioxus project now has nearly 37,000 stars on GitHub with millions of downloads. Apps built in Dioxus are rolled out across the globe with a cumulative estimate of over 200 million end users.

Users have built things like AI assistants, software for voting, data science tools, and even collision avoidance systems for satellites in space. We've put a ton of effort into making Dioxus as user-friendly as possible. Fewer files, unified build tooling, hot reloading, asset optimization, everything you need to easily ship across all platforms.

Because Dioxus apps are written in Rust, they are structurally very simple. You rarely need to drop into platform-specific code. Because all Rust projects are alike, it's very easy for developers to dive into a new project. You can completely skip annoying build system setup.

All you need is a main.rs to get started.

One of the most ambitious goals we had for Dioxus was to ship our own lightweight but fully featured HTML and CSS rendering engine called Blitz. We extracted the browser-grade CSS engine out of Firefox, built our own HTML, DOM, and developed a hybrid GPU rendering pipeline.

Compared to Electron apps, which are RAM and storage hogs, Blitz apps are lightweight, coming in at less than 5 megabytes bundle sizes, and consume less than 50 megabytes of RAM at runtime. And they're pretty cool. You can write your own custom components, spinning cubes, you can customize the browser however you want.

It's a very cool project. We also worked on a tool called Subsecond, which is our generic hot reload engine for Rust, C, and C++. Subsecond watches your code for edits, recompiles parts of the code that changed, and patches the running app in place, all in 100 milliseconds.

This was an incredibly difficult technical challenge, and it's the only hot reload engine for native compiled code to have such wide language and runtime support. It works on every major operating system and even the web, where Rust is compiled into WebAssembly.

No one has done this before.

I'm talking about these because these projects we've worked on along the way over the past five years are incredibly ambitious and are the result of a tiny but capable team of craft engineers. We've labored over quality, read every line of code with our own two eyes, and maintained a frequent but ambitious release cadence.

The most amazing thing, every line of code in Dioxus, until very recently, has been painstakingly written by hand.

Why do I say recently? Well, if you aren't aware, software engineering and development has taken a massive turn in the past six months. AI coding agents got really, really good, and specifically, they got really good at Rust. Our team, a bunch of cracked Rust engineers, has been quite skeptical of AI for a long time.

We had not felt the AGI, so to speak, and we definitely weren't using AI in our day-to-day work. We thought the two things were incompatible: shipping high-quality code and using agentic coding tools. Seeing them get really good at Rust was a huge surprise to us, so we were finally excited.

With this newfound excitement, we started building. Our team maxed out our Claude code subscriptions, turned out tens of thousands of lines of Rust, and built all sorts of features we had long wished to have. Unfortunately, very little of the code cleared our quality bar of, should we merge this in?

Thousands of lines of new features, bug fixes, and integrations we had wanted for years sat there in draft and continued to sit there in draft. We definitely did not know how to properly wield these tools, and it was way too easy to become what we call a slop cannon.

So we reflected a bit and studied what worked and what didn't.

One thing we realized over all these years, we had put a ton of effort into making Dioxus extremely developer-friendly. Easy to read, easy to write, good tools, good error messages. The coding agents generally don't care about this. We tried to make Rust easy for humans, and in fact, it didn't really matter.

Coding agents excel with Dioxus, still, fortunately, because Rust is harder to write. The coding agents deal with the development burden for you, they handle the edge cases, and they fight the borrow checker, saving you from the cognitive burden of writing Rust apps.

The learning curve, which we fought to reduce, is now a feature. So throughout the process of adopting the coding tools to work on Dioxus, we learned a wide array of lessons. Many of the things the coding agents do really well today, and many things they just aren't there yet.

So the next couple slides, I want to talk about some of the things we learned and what it means to build ambitious software projects in the age of agentic coding.

It's important to talk about first what it means to build an ambitious software project. There's many different types of software out there. It depends on what you ship every day. You might be doing research, and the quality of your code isn't the most important thing.

You might be doing prototyping code, and iterating fast and moving quickly is important. You might be building applications, which people don't see the code internally. They just see what it looks like on the outside. But for us and for Dioxus, we care about a few different things.

Primarily, of course, we care that our code works all the time, and that if it breaks, we can easily fix it. I think this is something people don't think about enough these days, that you need to continue to build easily maintainable code, and the velocity that you ship lays down on this substrate that you've built, and if the substrate isn't good, nothing you build on top is going to be good.

Secondarily, we care about shipping new features. Our roadmap is really long. It extends into the far future. There's dozens of features we still have yet to build for Dioxus, and we want to ship these quickly to keep up with the times, but we also want to maintain quality.

When building a large, ambitious project like Dioxus, there's a constant tension of shipping fast, adding new features, and then also making sure you don't break things, and that in a patch release, you're not breaking APIs that millions of people rely on.

For a project that people build their businesses on, there's also a high bar for releases. We need to maintain high quality of our documentation, of our examples, of our tests, of our benchmarks. If anything is out of place, people figure it out pretty quickly.

So we really do like coding agents as a form of an excellent assistant for very hard technical problems. Coding agents bring a level of patience and massive knowledge that is very hard to muster as an individual working on a very large software project.

Many problems in Dioxus are knowledge problems. Our team can't feasibly know every detail about every build system, every runtime, every operating system, every programming language, every API, every quirk. Fortunately, this is exactly where the coding agents excel. They can quickly sift through thousands of pages of documentation, read all the bespoke APIs, dig into binaries, reverse engineer APIs.

They have so much more patience than an individual developer does. We were able to implement things like Kotlin and Swift plugins for Dioxus, deeply integrated into our build system, which is a really hard feature. If you know React Native, Turbo Modules, these things took many years of development to getright by people writing them by hand.

We were able to ship this in two to three weeks with coding agents, and we probably could have gone faster. I think the implementation was done on the first day, and we spent two weeks building test cases and testing on real devices.

And in Blitz, the thing on theright, our custom web engine, web agents have accelerated debugging hard CSS styling and layout issues for us. The agents know the CSS spec exceptionally well. You might be writing a line of code that's trying to resolve some sort of painting or layout issue, and the agents can instantly recall exactly how Google Chrome and Safari do it, can tell you theright way of handling it for your problem, and you don't have to go open the web kit source code that's nested deep somewhere in Apple's Git repositories.

We're able to invest time in doing things theright way, not the hacky way, which, interestingly, is a turn compared to how we used to do it. We would always gauge a project based on its complexity and tend to take shortcuts as humans to ship things faster, but not at a high-quality bar.

So coding agents give us the ability to maintain quality and do things theright way, which is very interesting.

A less sexy application of coding agents for ambitious projects is actually doing the extremely mundane tasks. Our team is very small. We have three core engineers working on Dioxus. Any time that we spend verifying the tarball extracts into theright directory structure is time wasted from us thinking about the architecture and the hard problems of our software.

Dioxus is a large project, and it's been a challenge to maintain a high-quality bar across the entire codebase, across every release. In one release, we might add an extension for a new editor like Zed. We might not be able to test that editor every time we do a patch release, and it might be easy to break that.

Applying agents to the problem actually lets us automate many of these hard, tedious tasks that would have taken countless hours before. And then for us, the code is the product. People download the code, they build on the code, users interact with their APIs, they read our docs, and they build on our architecture.

So any laziness in the quality of the code, the SDKs that we ship to users, translates directly into a worse developer experience and people either getting upset, their businesses being stalled, or them turning off the product. So coding agents have been excellent at maintaining tasks like verifying release checklists, backporting bug fixes onto stable releases, and ensuring our docs and doc comments are of extremely high quality.

We still do write a lot of doc comments ourselves, but it's very easy to give the agents a task of making sure everything is documented properly, everything has an example, and everything actually is documenting the thing that it says in the way that it says.

As humans, you'll go edit the code, but you won't edit the comment, so a lot of your comments will actually be out of date over time, and things get very confusing. And if you just look at the numbers, we've shipped more patch releases in our most recent Dioxus version than we ever had before.

So we've been able to maintain weekly or multiple times a week release cadence for a large, ambitious piece of software in a way that we would be scared to do a release earlier.

One thing I'm not 100% convinced yet we have found varying levels of success is using AI to write tests, or at least blindly writing tests. One place we've struggled with Dioxus is testing. It can be very hard to test foundational software, especially end-to-end for complex systems.

It's hard to test that your extension installs into Zed and works the way you want it to do without literally opening Zed and using the extension. The coding agents struggle here too, to an extent. They also have a tendency to write kind of sloppy tests.

You'll give it a constructor, and then it will go test the constructor, and that's not a very interesting test. They can easily write tests for any given API, but much like humans, they fail to write theright tests. So we still find ourselves enumerating test conditions manually, crafting test APIs ourselves, and handwriting test runners.

But it is sometimes a great sounding board to come up with the test ideas for a particular thing you're trying to make sure has coverage, and then enumerating the edge conditions. But one place that we've actually really enjoyed using coding agents to do testing is building test harnesses.

So fuzzing is a critical part of building production-grade software, which means taking your application and putting it under millions of different inputs and quite often adversarial inputs, basically malformed inputs or ways of using the software that users should not be using the software, but they can use the software.

And coding agents are excellent at building these harnesses.

One thing we've found that code architecture is still an art.

Coding agents enable you to ship at an exceptionally high velocity. I mentioned this earlier. If the substrate on which your agent's code lands is bad, their contributions will be bad as well. Unlike a human engineer, coding agents aren't typically afraid to voluntarily go on a huge refactor of a system or redesign the architecture when a feature doesn't quite fit.

They'll typically just ship. Most of our development time is actually now spent thinking about software architecture, about what features we'll want in the future and how the system will evolve. Just like human engineers can write spaghetti code, so can the agents, but now just faster.

However, I will say with Fable-level tools, the actual code quality itself is so high, provided you properly communicate your intent, that proper software architecture will probably take the vast majority of time in the future. Actual code writing, not so much.

One thing we do for Dioxus, which maybe you guys still do, maybe you don't, is we review every PR line by line. We definitely use AI review to spot bugs ahead of time, but we still do like to read the code that we ship.

We receive lots and lots of PRs from strangers, actually. Dioxus is a big open-source project, and not every PR is made the same. We find that users can be quite bad at communicating their intent to the models. Contributors don't usually think deeply about how the codebase should evolve over time.

They just want their bug fix or their feature in, and many solutions are glued in place. So we're not quite at the point where the coding agents can read our minds, and thus we're still limited by the medium of text.

And as ridiculous as it sounds, prompt engineering is quite real. The quality of an implementation can be very much dependent on the prompt that you give the model. But in a sense, nothing really has changed. Reading code has always been more important than writing code, maybe not in the beginning, but eventually as the project evolves, it does.

So my closing thoughts on using coding agents to build ambitious software is that code is now cheap, but quality is not. The job of a software engineer has never really been about putting lines of code on the screen.

It's been about architecting elegant solutions to complex problems, to thinking 10 steps ahead about how a system will evolve, about retaining flexibility in the face of changing requirements. These facts have not changed, and the bar for software engineering is higher than ever.

If you would like to work on the tools of the next generation of software, Cognition, the people who have acquired Dioxus, are hiring. The Dioxus team joined Cognition to be part of the future, and hopefully you will too.

Thank you.