Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition

0:01 [music] Hello, my name is Jonathan Kelly and today we're going to talk about what it means to build ambitious software in the age of AI.

0:22 5 years ago, I made the first commit ever to a project called Diosis. I used the last summer I had as an undergraduate and instead of getting an internship at Google or doing research

0:33 in AI like many of my friends at the time, I spent it exploring an idea I had for a crossplatform app framework written in the Rust programming language.

0:44 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

0:56 me. It's extremely nerdy. The idea for Diosis was straightforward. What if we had an crossplatform app framework? Instead of waiting through dozens of tool chains, programming

1:09 languages, and idees, what if we simply wrote our 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

1:24 slow, and neither performed well with native APIs. On the flip, with Rust, we could build native abstractly with no VM, no IPC, no JavaScript. And if we used a little bit of HTML and CSS for

1:39 the UI and take 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

1:50 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.

2:03 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 Dioxis. Everything from

2:13 reactivity to font rendering to hot reloading and application bundling had to be built from scratch. There's nothing we could use. For us, tasks like building a web browser were just

2:25 necessary steps along the way. Now today in 2026, Diosis has achieved and far surpassed its original mission. We support all the features we originally set out to build from

2:39 crossplatform support to native rendering to Rust hot reload and bundle splitting. We've basically reinvented and improved the entire app development stack.

2:50 Users can ship a powerful full stack web application in the exact same codebase sharing components as their iOS and Android apps. The Daxis project now has nearly 37,000

3:04 stars on GitHub with millions of downloads. Apps built in Dioxis are rolled across the globe with a cumulative estimate of over 200 million end users. Users have built things like

3:15 AI assistance, software for voting, data science tools, and even collision avoidance system for satellites in space. We've put a ton of effort into making

3:27 Dioxis as userfriendly as possible. Fewer files, build tooling, hot reloading, asset optimization, everything you need to easily ship across all platforms.

3:38 Because Dioxis apps are written in Rust, they are structurally very simple. You rarely need to drop into platform specific code because all rest projects are alike. It's very easy for developers

3:50 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

4:01 for ship 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

4:15 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

4:25 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.

4:35 We also worked on a tool called Subsecond uh which is our generic hot reload engine for Rust, C and C++. Subsecond watches your code for edits, recompiles parts of the code that

4:46 changed and patches the running app in place all in 100 100 milliseconds. This was an incredibly difficult technical challenge and is the only hot reload engine for native compiled code to have

4:58 such wide language and runtime support. It works on every major system and even the web is compiled into web assembly. No one has done this before because these projects we've worked on

5:11 along the way over the past 5 years are incredibly ambitious and are the result of a tiny but over every line of code by with our own two eyes and maintain a frequent but

5:25 ambitious release cadence. The most amazing thing, every line of code in Dioxis until very recently has been painstakingly written by hand. Why do I say recently? Well, if you

5:40 aren't aware, software engineering and development has taken a massive turn in the past 6 months. AI coding agents got really, really good. And specifically, they got really good at Rust. Our team,

5:53 a bunch of cracked rest 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

6:05 the two things were incompatible, shipping high quality code tools. Seeing them get really good at Rust was a huge surprise to us. So, we were finally excited.

6:18 With this newfound excitement, we started building our team. maxed out our cloud code subscriptions, turned out tens of thousands of lines of Rust, and built all sorts of features we had long

6:27 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

6:40 for years sat there and draft and continue to sit there and 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

6:52 cannon. Um, so we reflected a bit and studied what worked and what didn't. to read, easy to write, good tools, good error messages. The coding agents

7:12 generally don't care about this. We tried to make Rust easel with Dioxis still because Rust is harder to write. The coding agents deal with the development

7:26 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

7:38 feature. So throughout the process of adopting the coding tools to work on Dioxis, we learned a wide array of lessons. Many of the thing the coding agents do

7:50 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 to build ambitious software

8:00 projects in the age of agent coding. Um, it's important to talk about first what it means to build an ambitious software project. Um, there's many different types of software out there.

8:14 Depends on what you ship every day. Um, you might be doing research and the quality of your code isn't the most important thing. You might be doing prototyping code and and iterating fast,

8:25 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 Diosis,

8:37 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

8:48 about enough these days that you need to continue to build easily maintainable code and like the velocity that you ship lays down on this substrate that you've built and if the substrate isn't good,

9:00 nothing you build on top is going to be good. Secondarily, we care about shipping new features. Our road map is really long. It extends

9:10 into the far future. There's dozens of features we still have yet to build for Dioxis. And we want to ship these quickly to keep up with the times, but we also want to maintain quality. When

9:23 building a large ambitious project like Deiosis, 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,

9:33 you're not like 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 uh

9:44 high quality of our documentation, of our examples, of our tests, of our benchmarks. If it if anything is out of place, people figure it out pretty quickly.

9:56 So, we really do like coding agents as a 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

10:10 muster as an individual working on a very large software project. Many problems in Dioxis are knowledge problems. Our team can't feasibly know every detail about every build system,

10:21 every runtime, every operating system, every programming language, every API, every quirk. Fortunately, this is exactly where the coding agents excel. They can quickly quickly sift through

10:34 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.

10:46 We were able to implement things like cotlin and swift plugins for dioxysis deeply integrated into our build system which is a really hard feature. If you know react native turbo modules these

10:58 things took many years of development to get right by people writing them by hand. We were able to ship this in like two to three weeks with coding agents and we probably could have gone faster.

11:08 I think implementation was done in like the first day and we spent two weeks building test cases and testing on real devices. And in Blitz, the thing on the right,

11:17 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

11:29 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 the right way of handling it for your

11:39 problem. and you don't have to go open the the WebKit source code that's nested deep somewhere in Apple's Git repositories. We're able to invest time in doing

11:51 things the right way, not the hacky way, which interestingly is a turn and compared to how we used to do it. We would always gauge a project based on its complexity and tend to take

12:02 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 the right way which is very interesting.

12:15 Um a less sexy application of coding agents for ambitious projects is actually doing the extremely mundane tasks. Uh our team is very small. We have three core engineers working on

12:26 Diosis. uh any time that we spend like verifying the tarball extracts into the right directory structure is like time wasted from us thinking about the architecture and the the hard problems

12:37 of our software. Um Dioxis 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

12:48 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

12:58 many of these like hard tedious tasks that would have taken like countless hours before. And then for us like the code is the product. People download the code, they

13:08 build on the code, users interact with our APIs, they read our docs, and they build on our architecture. So any laziness in the the quality of the code, the SDKs that we ship to users

13:20 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

13:30 excellent at maintaining uh tasks like verifying release checklists, backporting bug fixes onto stable releases, and ensuring our docs and documents are of extremely high quality.

13:41 We still do write a lot of docu comments ourselves, but it's very easy to give the agent a task of making sure everything is documented properly. Everything has an example and everything

13:51 actually is documenting the thing that it says in the way that it says. Um, as humans, you know, you'll go edit the code, but you won't edit the comment. So, a lot of your comments will actually

14:01 be out of date over time and things get very confusing. Um, and if you just look at the numbers, we've shipped more patch releases in our most recent DAXis version than we ever had before. So,

14:10 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.

14:21 Um, one thing I'm not 100% convinced yet, uh, we have found varying levels of success is using AI to write tests or at least blindly writing tests. Um, one place we've struggled with Diosis is

14:36 testing. It can be very hard to test foundational software, especially like end to end for complex systems. It's hard to test that your extension installs into zed and works the way you

14:46 want it to do with literally opening zed and like using the extension. Um, the coding agents struggle here too to an extent. Uh, they also are, you know, have a tendency to write kind of sloppy

14:59 tests. you'll give it a constructor and then it will go test the constructor and that's not a very interesting test. Um they can easily write tests for any given API but much like humans they fail

15:09 to write the right tests. So we still find ourselves enumerating test conditions manually um crafting test APIs our ourselves and handling test runners um but it is sometimes a great

15:22 sounding board to come up with the test ideas for a particular thing you're trying to to make sure has coverage and then enumerating the the edge conditions um but one place that we have actually

15:32 really enjoyed using coding agents to do testing is building test harnesses. So fuzzing is a critical part of building like production grade software which means taking your application and

15:44 putting it under millions of different inputs and quite often adversarial inputs basically like malformed inputs or uh ways of using the software that users should not be using the software

15:56 but they they can use the software and coding agents are excellent at building these harnesses. Um, one thing we've found that code extra code architecture is still an art.

16:08 Um, coding agents enable you to ship at an exceptionally high velocity. I mentioned this earlier. If the substrate on which your coding agents code lands is bad,

16:19 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

16:29 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

16:38 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

16:50 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.

17:02 Um, one thing we do for Daxis, which maybe you guys still do, maybe you don't, uh, is we review every PR line by line. Um, we definitely use AI review to spot bugs ahead of time, but we still do

17:16 like to read the code that we ship. We receive lots and lots of PRs from strangers. Actually, uh, Daxis is big open source project. Uh, and not every PR is made the same. Uh we find that

17:28 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

17:36 in. Uh and many solutions are glued in place. So we're we're not quite at the point where the coding agents can read our minds. Uh and thus we're still limited by the medium of text. And as

17:48 ridiculous as it sounds, prompt engineering is quite real. The quality of an implementation can be very much dependent on the the prompt that you give the model.

17:56 But in a sense, nothing really has changed. Reading code has always been more important than writing code. Um maybe not in the beginning, but eventually as the project evolves, uh it

18:06 does. So my closing thoughts on on using coding agents to build ambitious software is that code is now cheap, but quality is not. Um the the job of a

18:18 software engineer has never really been about putting lines of code on the screen. It's it's been about architecting elegant solutions to complex problems to thinking 10 steps

18:28 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

18:39 ever. Uh if you would like to work on the tools of the next generation of software, Cognition, the people who have acquired Dioxis are hiring. Uh the Daxis

18:49 team joined Cognition to be part of the future and hopefully you will too. Thank you. [applause] >> [music]