Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition

AI Engineer · 19 min · 181 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:01[music]
  2. 00:12Hello, 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.
  3. 00:225 years ago, I made the first commit ever to a project called Diosis.
  4. 00:27I 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 crossplatform
  5. 00:39app framework written in the Rust programming language.
  6. 00:44In 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
  7. 00:55really sold me.
  8. 00:57It's extremely nerdy.
  9. 01:00The idea for Diosis was straightforward.
  10. 01:03What if we had an crossplatform app framework?
  11. 01:07Instead of waiting through dozens of tool chains, programming languages, and idees, what if we simply wrote our all of our apps in Rust using HTML and CSS as the markup language?
  12. 01:19This was back in the day 2021 where React Native was janky, Flutter was too slow, and neither performed well with native APIs.
  13. 01:27On the flip, with Rust, we could build native abstractly with no VM, no IPC, no JavaScript.
  14. 01:36And if we used a little bit of HTML and CSS for the UI and take some inspiration from React for the reactivity, we could reuse vast amounts of web components and web tooling.
  15. 01:47The goal was an extremely powerful app framework that was still quite familiar to the average developer.
  16. 01:53Sounds easy, right?
  17. 01:55Well, 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.
  18. 02:03In reality, trying to challenge React Native and Flutter is extremely ambitious.
  19. 02:07In 2021, there were very few off-the-shelf components you could use to build Dioxis.
  20. 02:12Everything from reactivity to font rendering to hot reloading and application bundling had to be built from scratch.
  21. 02:20There's nothing we could use.
  22. 02:22For us, tasks like building a web browser were just necessary steps along the way.
  23. 02:29Now today in 2026, Diosis has achieved and far surpassed its original mission.
  24. 02:36We support all the features we originally set out to build from crossplatform support to native rendering to Rust hot reload and bundle splitting.
  25. 02:45We've basically reinvented and improved the entire app development stack.
  26. 02:50Users can ship a powerful full stack web application in the exact same codebase sharing components as their iOS and Android apps.
  27. 03:00The Daxis project now has nearly 37,000 stars on GitHub with millions of downloads.
  28. 03:07Apps built in Dioxis are rolled across the globe with a cumulative estimate of over 200 million end users.
  29. 03:14Users have built things like AI assistance, software for voting, data science tools, and even collision avoidance system for satellites in space.
  30. 03:25We've put a ton of effort into making Dioxis as userfriendly as possible.
  31. 03:30Fewer files, build tooling, hot reloading, asset optimization, everything you need to easily ship across all platforms.
  32. 03:38Because Dioxis apps are written in Rust, they are structurally very simple.
  33. 03:43You rarely need to drop into platform specific code because all rest projects are alike.
  34. 03:48It's very easy for developers to dive into a new project.
  35. 03:51You can completely skip annoying build system setup.
  36. 03:55All you need is a main.rs to get started.
  37. 03:59One of the most ambitious goals we had for ship lightweight but fully featured HTML and CSS rendering engine called Blitz.
  38. 04:08We extracted the browser grade CSS engine out of Firefox, built our own HTML DOM, and developed a hybrid GPU rendering pipeline.
  39. 04:17Compared 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.
  40. 04:28And they're pretty cool.
  41. 04:29You can write your own custom components, spinning cubes, you can customize the browser however you want.
  42. 04:33It's a very cool project.
  43. 04:35We also worked on a tool called Subsecond uh which is our generic hot reload engine for Rust, C and C++.
  44. 04:42Subsecond watches your code for edits, recompiles parts of the code that changed and patches the running app in place all in 100 100 milliseconds.
  45. 04:51This was an incredibly difficult technical challenge and is the only hot reload engine for native compiled code to have such wide language and runtime support.
  46. 05:00It works on every major system and even the web is compiled into web assembly.
  47. 05:05No one has done this before because these projects we've worked on along the way over the past 5 years are incredibly ambitious and are the result of a tiny but
  48. 05:20over every line of code by with our own two eyes and maintain a frequent but ambitious release cadence.
  49. 05:28The most amazing thing, every line of code in Dioxis until very recently has been painstakingly written by hand.
  50. 05:37Why do I say recently?
  51. 05:39Well, if you aren't aware, software engineering and development has taken a massive turn in the past 6 months.
  52. 05:46AI coding agents got really, really good.
  53. 05:49And specifically, they got really good at Rust.
  54. 05:52Our team, a bunch of cracked rest engineers, has been quite skeptical of AI for a long time.
  55. 05:59We had not felt the AGI, so to speak.
  56. 06:02And we definitely weren't using AI in our day-to-day work.
  57. 06:05We thought the two things were incompatible, shipping high quality code tools.
  58. 06:11Seeing them get really good at Rust was a huge surprise to us.
  59. 06:14So, we were finally excited.
  60. 06:18With this newfound excitement, we started building our team.
  61. 06:21maxed out our cloud code subscriptions, turned out tens of thousands of lines of Rust, and built all sorts of features we had long wished to have.
  62. 06:29Unfortunately, very little of the code cleared our quality bar of should we merge this in.
  63. 06:35Thousands of lines of new features, bug fixes, and integrations we had wanted for years sat there and draft and continue to sit there and draft.
  64. 06:45We definitely did not know how to properly wield these tools and it was way too easy to become what we call a slop cannon.
  65. 06:54Um, so we reflected a bit and studied what worked and what didn't.
  66. 07:07to read, easy to write, good tools, good error messages.
  67. 07:11The coding agents generally don't care about this.
  68. 07:14We tried to make Rust easel with Dioxis still because Rust is harder to write.
  69. 07:24The coding agents deal with the development burden for you.
  70. 07:27They handle the edge cases and they fight the borrow checker, saving you from the cognitive burden of writing Rust apps.
  71. 07:34The learning curve which we fought to reduce is now a feature.
  72. 07:40So throughout the process of adopting the coding tools to work on Dioxis, we learned a wide array of lessons.
  73. 07:48Many of the thing the coding agents do really well today and many things they just aren't there yet.
  74. 07:54So the next couple slides I want to talk about some of the things we learned and what it means to to build ambitious software projects in the age of agent coding.
  75. 08:05Um, it's important to talk about first what it means to build an ambitious software project.
  76. 08:11Um, there's many different types of software out there.
  77. 08:14Depends on what you ship every day.
  78. 08:16Um, you might be doing research and the quality of your code isn't the most important thing.
  79. 08:22You might be doing prototyping code and and iterating fast, moving quickly is important.
  80. 08:27You might be building applications which people don't see the code internally.
  81. 08:30They just see what it looks like on the outside.
  82. 08:34But for us and for Diosis, we care about a few different things.
  83. 08:40Primarily, of course, we care that our code works all the time and that if it breaks, we can easily fix it.
  84. 08:47I think this is something people don't think about enough these days that you need to continue to build easily maintainable code and like the velocity that you ship lays down on
  85. 08:57this substrate that you've built and if the substrate isn't good, nothing you build on top is going to be good.
  86. 09:03Secondarily, we care about shipping new features.
  87. 09:07Our road map is really long.
  88. 09:09It extends into the far future.
  89. 09:12There's dozens of features we still have yet to build for Dioxis.
  90. 09:16And we want to ship these quickly to keep up with the times, but we also want to maintain quality.
  91. 09:22When 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, you're not
  92. 09:34like breaking APIs that millions of people rely on.
  93. 09:38For a project that people build their businesses on, there's also a high bar for releases.
  94. 09:43We need to maintain uh high quality of our documentation, of our examples, of our tests, of our benchmarks.
  95. 09:50If it if anything is out of place, people figure it out pretty quickly.
  96. 09:56So, we really do like coding agents as a a form of an excellent assistant for very hard technical problems.
  97. 10:05Coding 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.
  98. 10:14Many problems in Dioxis are knowledge problems.
  99. 10:18Our team can't feasibly know every detail about every build system, every runtime, every operating system, every programming language, every API, every quirk.
  100. 10:28Fortunately, this is exactly where the coding agents excel.
  101. 10:32They can quickly quickly sift through thousands of pages of documentation, read all the bespoke APIs, dig into binaries, reverse engineer APIs.
  102. 10:42They have so much more patience than an individual developer does.
  103. 10:46We were able to implement things like cotlin and swift plugins for dioxysis deeply integrated into our build system which is a really hard feature.
  104. 10:56If you know react native turbo modules these things took many years of development to get right by people writing them by hand.
  105. 11:03We were able to ship this in like two to three weeks with coding agents and we probably could have gone faster.
  106. 11:08I think implementation was done in like the first day and we spent two weeks building test cases and testing on real devices.
  107. 11:15And in Blitz, the thing on the right, our custom web engine, web agents have accelerated debugging hard CSS, styling, and layout issues for us.
  108. 11:25The agents know the CSS spec exceptionally well.
  109. 11:28You might be writing a line of code that's trying to resolve some sort of painting or layout issue.
  110. 11:33And the agents can instantly recall exactly how Google Chrome and Safari do it.
  111. 11:37Can tell you the right way of handling it for your problem.
  112. 11:40and you don't have to go open the the WebKit source code that's nested deep somewhere in Apple's Git repositories.
  113. 11:49We're able to invest time in doing things the right way, not the hacky way, which interestingly is a turn and compared to how we used to do it.
  114. 11:59We 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.
  115. 12:07So coding agents give us the ability to maintain quality and do things the right way which is very interesting.
  116. 12:15Um a less sexy application of coding agents for ambitious projects is actually doing the extremely mundane tasks.
  117. 12:23Uh our team is very small.
  118. 12:24We have three core engineers working on Diosis.
  119. 12:27uh 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 of our software.
  120. 12:38Um Dioxis is a large project and it's been a challenge to maintain a high quality bar across the entire codebase across every release.
  121. 12:46In one release we might add an extension for a new editor like zed.
  122. 12:50We might not be able to test that editor every time we do a patch release.
  123. 12:54And it might be easy to break that.
  124. 12:56Applying agents to the problem actually lets us automate many of these like hard tedious tasks that would have taken like countless hours before.
  125. 13:04And then for us like the code is the product.
  126. 13:07People download the code, they build on the code, users interact with our APIs, they read our docs, and they build on our architecture.
  127. 13:14So any laziness in the 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.
  128. 13:29So coding agents have been 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.
  129. 13:41We 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.
  130. 13:49Everything has an example and everything actually is documenting the thing that it says in the way that it says.
  131. 13:55Um, as humans, you know, you'll go edit the code, but you won't edit the comment.
  132. 13:59So, a lot of your comments will actually be out of date over time and things get very confusing.
  133. 14:04Um, 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.
  134. 14:10So, 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.
  135. 14:21Um, 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.
  136. 14:33Um, one place we've struggled with Diosis is testing.
  137. 14:36It can be very hard to test foundational software, especially like end to end for complex systems.
  138. 14:42It's hard to test that your extension installs into zed and works the way you want it to do with literally opening zed and like using the extension.
  139. 14:50Um, the coding agents struggle here too to an extent.
  140. 14:55Uh, they also are, you know, have a tendency to write kind of sloppy tests.
  141. 15:00you'll give it a constructor and then it will go test the constructor and that's not a very interesting test.
  142. 15:04Um they can easily write tests for any given API but much like humans they fail to write the right tests.
  143. 15:12So 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 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
  144. 15:31um but one place that we have actually really enjoyed using coding agents to do testing is building test harnesses.
  145. 15:36So fuzzing is a critical part of building like production grade software which means taking your application and putting it under millions of different inputs and quite often adversarial inputs basically like malformed inputs or
  146. 15:52uh ways of using the software that users should not be using the software but they they can use the software and coding agents are excellent at building these harnesses.
  147. 16:03Um, one thing we've found that code extra code architecture is still an art.
  148. 16:08Um, coding agents enable you to ship at an exceptionally high velocity.
  149. 16:14I mentioned this earlier.
  150. 16:15If the substrate on which your coding agents code lands is bad, their contributions will be bad as well.
  151. 16:22Unlike 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.
  152. 16:30They'll typically just ship.
  153. 16:32Most 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.
  154. 16:40Just like human engineers can write spaghetti code, so can the agents, but now just faster.
  155. 16:46However, 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.
  156. 16:59Actual code writing, not so much.
  157. 17:02Um, 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.
  158. 17:11Um, we definitely use AI review to spot bugs ahead of time, but we still do like to read the code that we ship.
  159. 17:18We receive lots and lots of PRs from strangers.
  160. 17:21Actually, uh, Daxis is big open source project.
  161. 17:24Uh, and not every PR is made the same.
  162. 17:27Uh we find that users can be quite bad at communicating their intent to the models.
  163. 17:31Contributors don't usually think deeply about how the codebase should evolve over time.
  164. 17:34They just want their bug fix or their feature in.
  165. 17:37Uh and many solutions are glued in place.
  166. 17:40So we're we're not quite at the point where the coding agents can read our minds.
  167. 17:44Uh and thus we're still limited by the medium of text.
  168. 17:47And as ridiculous as it sounds, prompt engineering is quite real.
  169. 17:50The quality of an implementation can be very much dependent on the the prompt that you give the model.
  170. 17:56But in a sense, nothing really has changed.
  171. 17:59Reading code has always been more important than writing code.
  172. 18:02Um maybe not in the beginning, but eventually as the project evolves, uh it does.
  173. 18:07So my closing thoughts on on using coding agents to build ambitious software is that code is now cheap, but quality is not.
  174. 18:16Um the the job of a software engineer has never really been about putting lines of code on the screen.
  175. 18:22It's 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.
  176. 18:34These facts have not changed and the bar for software engineering is higher than ever.
  177. 18:41Uh if you would like to work on the tools of the next generation of software, Cognition, the people who have acquired Dioxis are hiring.
  178. 18:48Uh the Daxis team joined Cognition to be part of the future and hopefully you will too.
  179. 18:53Thank you.
  180. 18:55[applause]
  181. 19:10[music]