WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=H7vFrcNWXzs

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/H7vFrcNWXzs.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.719 --> 00:00:22.160
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.

s3
00:00:22.640 --> 00:00:27.599
5 years ago, I made the first commit ever to a project called Diosis.

s4
00:00:27.599 --> 00:00:39.600
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 crossplatform

s5
00:00:39.600 --> 00:00:44.160
app framework written in the Rust programming language.

s6
00:00:44.160 --> 00:00:55.920
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

s7
00:00:55.920 --> 00:00:57.039
really sold me.

s8
00:00:57.039 --> 00:00:59.760
It's extremely nerdy.

s9
00:01:00.239 --> 00:01:03.120
The idea for Diosis was straightforward.

s10
00:01:03.120 --> 00:01:07.119
What if we had an crossplatform app framework?

s11
00:01:07.119 --> 00:01:19.360
Instead 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?

s12
00:01:19.360 --> 00:01:27.920
This was back in the day 2021 where React Native was janky, Flutter was too slow, and neither performed well with native APIs.

s13
00:01:27.920 --> 00:01:36.079
On the flip, with Rust, we could build native abstractly with no VM, no IPC, no JavaScript.

s14
00:01:36.079 --> 00:01:47.119
And 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.

s15
00:01:47.119 --> 00:01:53.200
The goal was an extremely powerful app framework that was still quite familiar to the average developer.

s16
00:01:53.600 --> 00:01:55.520
Sounds easy, right?

s17
00:01:55.520 --> 00:02:03.360
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.

s18
00:02:03.360 --> 00:02:07.600
In reality, trying to challenge React Native and Flutter is extremely ambitious.

s19
00:02:07.600 --> 00:02:12.879
In 2021, there were very few off-the-shelf components you could use to build Dioxis.

s20
00:02:12.879 --> 00:02:20.400
Everything from reactivity to font rendering to hot reloading and application bundling had to be built from scratch.

s21
00:02:20.400 --> 00:02:22.319
There's nothing we could use.

s22
00:02:22.319 --> 00:02:29.360
For us, tasks like building a web browser were just necessary steps along the way.

s23
00:02:29.920 --> 00:02:36.239
Now today in 2026, Diosis has achieved and far surpassed its original mission.

s24
00:02:36.239 --> 00:02:45.120
We support all the features we originally set out to build from crossplatform support to native rendering to Rust hot reload and bundle splitting.

s25
00:02:45.120 --> 00:02:50.879
We've basically reinvented and improved the entire app development stack.

s26
00:02:50.879 --> 00:03:00.959
Users can ship a powerful full stack web application in the exact same codebase sharing components as their iOS and Android apps.

s27
00:03:00.959 --> 00:03:07.040
The Daxis project now has nearly 37,000 stars on GitHub with millions of downloads.

s28
00:03:07.040 --> 00:03:14.239
Apps built in Dioxis are rolled across the globe with a cumulative estimate of over 200 million end users.

s29
00:03:14.239 --> 00:03:25.440
Users have built things like AI assistance, software for voting, data science tools, and even collision avoidance system for satellites in space.

s30
00:03:25.760 --> 00:03:30.319
We've put a ton of effort into making Dioxis as userfriendly as possible.

s31
00:03:30.319 --> 00:03:38.480
Fewer files, build tooling, hot reloading, asset optimization, everything you need to easily ship across all platforms.

s32
00:03:38.480 --> 00:03:43.040
Because Dioxis apps are written in Rust, they are structurally very simple.

s33
00:03:43.040 --> 00:03:48.879
You rarely need to drop into platform specific code because all rest projects are alike.

s34
00:03:48.879 --> 00:03:51.760
It's very easy for developers to dive into a new project.

s35
00:03:51.760 --> 00:03:55.040
You can completely skip annoying build system setup.

s36
00:03:55.040 --> 00:03:59.040
All you need is a main.rs to get started.

s37
00:03:59.840 --> 00:04:08.319
One of the most ambitious goals we had for ship lightweight but fully featured HTML and CSS rendering engine called Blitz.

s38
00:04:08.319 --> 00:04:17.759
We extracted the browser grade CSS engine out of Firefox, built our own HTML DOM, and developed a hybrid GPU rendering pipeline.

s39
00:04:17.759 --> 00:04:28.479
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.

s40
00:04:28.479 --> 00:04:29.280
And they're pretty cool.

s41
00:04:29.280 --> 00:04:33.199
You can write your own custom components, spinning cubes, you can customize the browser however you want.

s42
00:04:33.199 --> 00:04:35.440
It's a very cool project.

s43
00:04:35.440 --> 00:04:42.560
We also worked on a tool called Subsecond uh which is our generic hot reload engine for Rust, C and C++.

s44
00:04:42.560 --> 00:04:51.680
Subsecond watches your code for edits, recompiles parts of the code that changed and patches the running app in place all in 100 100 milliseconds.

s45
00:04:51.680 --> 00:05:00.240
This 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.

s46
00:05:00.240 --> 00:05:05.120
It works on every major system and even the web is compiled into web assembly.

s47
00:05:05.120 --> 00:05:17.919
No 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

s48
00:05:20.560 --> 00:05:28.080
over every line of code by with our own two eyes and maintain a frequent but ambitious release cadence.

s49
00:05:28.080 --> 00:05:36.880
The most amazing thing, every line of code in Dioxis until very recently has been painstakingly written by hand.

s50
00:05:37.280 --> 00:05:39.120
Why do I say recently?

s51
00:05:39.120 --> 00:05:46.479
Well, if you aren't aware, software engineering and development has taken a massive turn in the past 6 months.

s52
00:05:46.479 --> 00:05:49.600
AI coding agents got really, really good.

s53
00:05:49.600 --> 00:05:52.320
And specifically, they got really good at Rust.

s54
00:05:52.320 --> 00:05:59.280
Our team, a bunch of cracked rest engineers, has been quite skeptical of AI for a long time.

s55
00:05:59.280 --> 00:06:02.240
We had not felt the AGI, so to speak.

s56
00:06:02.240 --> 00:06:05.520
And we definitely weren't using AI in our day-to-day work.

s57
00:06:05.520 --> 00:06:11.520
We thought the two things were incompatible, shipping high quality code tools.

s58
00:06:11.520 --> 00:06:14.880
Seeing them get really good at Rust was a huge surprise to us.

s59
00:06:14.880 --> 00:06:17.759
So, we were finally excited.

s60
00:06:18.479 --> 00:06:21.919
With this newfound excitement, we started building our team.

s61
00:06:21.919 --> 00:06:29.199
maxed 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.

s62
00:06:29.199 --> 00:06:35.440
Unfortunately, very little of the code cleared our quality bar of should we merge this in.

s63
00:06:35.440 --> 00:06:45.360
Thousands 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.

s64
00:06:45.360 --> 00:06:54.639
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.

s65
00:06:54.639 --> 00:07:00.319
Um, so we reflected a bit and studied what worked and what didn't.

s66
00:07:07.759 --> 00:07:11.680
to read, easy to write, good tools, good error messages.

s67
00:07:11.680 --> 00:07:14.400
The coding agents generally don't care about this.

s68
00:07:14.400 --> 00:07:24.720
We tried to make Rust easel with Dioxis still because Rust is harder to write.

s69
00:07:24.720 --> 00:07:27.440
The coding agents deal with the development burden for you.

s70
00:07:27.440 --> 00:07:34.639
They handle the edge cases and they fight the borrow checker, saving you from the cognitive burden of writing Rust apps.

s71
00:07:34.639 --> 00:07:40.080
The learning curve which we fought to reduce is now a feature.

s72
00:07:40.240 --> 00:07:48.560
So throughout the process of adopting the coding tools to work on Dioxis, we learned a wide array of lessons.

s73
00:07:48.560 --> 00:07:54.720
Many of the thing the coding agents do really well today and many things they just aren't there yet.

s74
00:07:54.720 --> 00:08:04.960
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 projects in the age of agent coding.

s75
00:08:05.039 --> 00:08:11.520
Um, it's important to talk about first what it means to build an ambitious software project.

s76
00:08:11.520 --> 00:08:14.720
Um, there's many different types of software out there.

s77
00:08:14.720 --> 00:08:16.800
Depends on what you ship every day.

s78
00:08:16.800 --> 00:08:22.400
Um, you might be doing research and the quality of your code isn't the most important thing.

s79
00:08:22.400 --> 00:08:27.199
You might be doing prototyping code and and iterating fast, moving quickly is important.

s80
00:08:27.199 --> 00:08:30.879
You might be building applications which people don't see the code internally.

s81
00:08:30.879 --> 00:08:34.000
They just see what it looks like on the outside.

s82
00:08:34.000 --> 00:08:40.560
But for us and for Diosis, we care about a few different things.

s83
00:08:40.560 --> 00:08:47.040
Primarily, of course, we care that our code works all the time and that if it breaks, we can easily fix it.

s84
00:08:47.040 --> 00:08:57.360
I 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

s85
00:08:57.360 --> 00:09:03.839
this substrate that you've built and if the substrate isn't good, nothing you build on top is going to be good.

s86
00:09:03.839 --> 00:09:07.680
Secondarily, we care about shipping new features.

s87
00:09:07.680 --> 00:09:09.600
Our road map is really long.

s88
00:09:09.600 --> 00:09:12.000
It extends into the far future.

s89
00:09:12.000 --> 00:09:16.320
There's dozens of features we still have yet to build for Dioxis.

s90
00:09:16.320 --> 00:09:22.800
And we want to ship these quickly to keep up with the times, but we also want to maintain quality.

s91
00:09:22.800 --> 00:09:34.640
When 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

s92
00:09:34.640 --> 00:09:38.560
like breaking APIs that millions of people rely on.

s93
00:09:38.560 --> 00:09:43.200
For a project that people build their businesses on, there's also a high bar for releases.

s94
00:09:43.200 --> 00:09:50.320
We need to maintain uh high quality of our documentation, of our examples, of our tests, of our benchmarks.

s95
00:09:50.320 --> 00:09:55.760
If it if anything is out of place, people figure it out pretty quickly.

s96
00:09:56.640 --> 00:10:05.120
So, we really do like coding agents as a a form of an excellent assistant for very hard technical problems.

s97
00:10:05.120 --> 00:10:14.560
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.

s98
00:10:14.560 --> 00:10:18.079
Many problems in Dioxis are knowledge problems.

s99
00:10:18.079 --> 00:10:28.560
Our team can't feasibly know every detail about every build system, every runtime, every operating system, every programming language, every API, every quirk.

s100
00:10:28.560 --> 00:10:32.160
Fortunately, this is exactly where the coding agents excel.

s101
00:10:32.160 --> 00:10:42.240
They can quickly quickly sift through thousands of pages of documentation, read all the bespoke APIs, dig into binaries, reverse engineer APIs.

s102
00:10:42.240 --> 00:10:46.959
They have so much more patience than an individual developer does.

s103
00:10:46.959 --> 00:10:56.000
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.

s104
00:10:56.000 --> 00:11:03.680
If you know react native turbo modules these things took many years of development to get right by people writing them by hand.

s105
00:11:03.680 --> 00:11:08.399
We were able to ship this in like two to three weeks with coding agents and we probably could have gone faster.

s106
00:11:08.399 --> 00:11:15.519
I think implementation was done in like the first day and we spent two weeks building test cases and testing on real devices.

s107
00:11:15.519 --> 00:11:25.279
And in Blitz, the thing on the right, our custom web engine, web agents have accelerated debugging hard CSS, styling, and layout issues for us.

s108
00:11:25.279 --> 00:11:28.320
The agents know the CSS spec exceptionally well.

s109
00:11:28.320 --> 00:11:33.120
You might be writing a line of code that's trying to resolve some sort of painting or layout issue.

s110
00:11:33.120 --> 00:11:37.440
And the agents can instantly recall exactly how Google Chrome and Safari do it.

s111
00:11:37.440 --> 00:11:40.240
Can tell you the right way of handling it for your problem.

s112
00:11:40.240 --> 00:11:49.120
and you don't have to go open the the WebKit source code that's nested deep somewhere in Apple's Git repositories.

s113
00:11:49.120 --> 00:11:59.120
We'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.

s114
00:11:59.120 --> 00:12:07.760
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.

s115
00:12:07.760 --> 00:12:15.120
So coding agents give us the ability to maintain quality and do things the right way which is very interesting.

s116
00:12:15.279 --> 00:12:23.519
Um a less sexy application of coding agents for ambitious projects is actually doing the extremely mundane tasks.

s117
00:12:23.519 --> 00:12:24.800
Uh our team is very small.

s118
00:12:24.800 --> 00:12:27.440
We have three core engineers working on Diosis.

s119
00:12:27.440 --> 00:12:38.560
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 of our software.

s120
00:12:38.560 --> 00:12:46.720
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.

s121
00:12:46.720 --> 00:12:50.880
In one release we might add an extension for a new editor like zed.

s122
00:12:50.880 --> 00:12:54.240
We might not be able to test that editor every time we do a patch release.

s123
00:12:54.240 --> 00:12:56.560
And it might be easy to break that.

s124
00:12:56.560 --> 00:13:04.320
Applying agents to the problem actually lets us automate many of these like hard tedious tasks that would have taken like countless hours before.

s125
00:13:04.320 --> 00:13:07.680
And then for us like the code is the product.

s126
00:13:07.680 --> 00:13:14.399
People download the code, they build on the code, users interact with our APIs, they read our docs, and they build on our architecture.

s127
00:13:14.399 --> 00:13:29.120
So 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.

s128
00:13:29.120 --> 00:13:41.600
So 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.

s129
00:13:41.600 --> 00:13:49.200
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.

s130
00:13:49.200 --> 00:13:55.600
Everything has an example and everything actually is documenting the thing that it says in the way that it says.

s131
00:13:55.600 --> 00:13:59.440
Um, as humans, you know, you'll go edit the code, but you won't edit the comment.

s132
00:13:59.440 --> 00:14:04.240
So, a lot of your comments will actually be out of date over time and things get very confusing.

s133
00:14:04.240 --> 00:14:10.720
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.

s134
00:14:10.720 --> 00:14:21.120
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.

s135
00:14:21.440 --> 00:14:33.519
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.

s136
00:14:33.519 --> 00:14:36.880
Um, one place we've struggled with Diosis is testing.

s137
00:14:36.880 --> 00:14:42.959
It can be very hard to test foundational software, especially like end to end for complex systems.

s138
00:14:42.959 --> 00:14:50.880
It'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.

s139
00:14:50.880 --> 00:14:55.519
Um, the coding agents struggle here too to an extent.

s140
00:14:55.519 --> 00:15:00.079
Uh, they also are, you know, have a tendency to write kind of sloppy tests.

s141
00:15:00.079 --> 00:15:04.480
you'll give it a constructor and then it will go test the constructor and that's not a very interesting test.

s142
00:15:04.480 --> 00:15:12.240
Um they can easily write tests for any given API but much like humans they fail to write the right tests.

s143
00:15:12.240 --> 00:15:31.199
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 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

s144
00:15:31.199 --> 00:15:36.880
um but one place that we have actually really enjoyed using coding agents to do testing is building test harnesses.

s145
00:15:36.880 --> 00:15:52.880
So 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

s146
00:15:52.880 --> 00:16:02.480
uh 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.

s147
00:16:03.279 --> 00:16:08.959
Um, one thing we've found that code extra code architecture is still an art.

s148
00:16:08.959 --> 00:16:14.320
Um, coding agents enable you to ship at an exceptionally high velocity.

s149
00:16:14.320 --> 00:16:15.519
I mentioned this earlier.

s150
00:16:15.519 --> 00:16:22.079
If the substrate on which your coding agents code lands is bad, their contributions will be bad as well.

s151
00:16:22.079 --> 00:16:30.720
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.

s152
00:16:30.720 --> 00:16:32.639
They'll typically just ship.

s153
00:16:32.639 --> 00:16:40.240
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.

s154
00:16:40.240 --> 00:16:46.320
Just like human engineers can write spaghetti code, so can the agents, but now just faster.

s155
00:16:46.320 --> 00:16:59.600
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.

s156
00:16:59.600 --> 00:17:02.880
Actual code writing, not so much.

s157
00:17:02.880 --> 00:17:11.199
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.

s158
00:17:11.199 --> 00:17:18.720
Um, we definitely use AI review to spot bugs ahead of time, but we still do like to read the code that we ship.

s159
00:17:18.720 --> 00:17:21.679
We receive lots and lots of PRs from strangers.

s160
00:17:21.679 --> 00:17:24.640
Actually, uh, Daxis is big open source project.

s161
00:17:24.640 --> 00:17:27.280
Uh, and not every PR is made the same.

s162
00:17:27.280 --> 00:17:31.520
Uh we find that users can be quite bad at communicating their intent to the models.

s163
00:17:31.520 --> 00:17:34.960
Contributors don't usually think deeply about how the codebase should evolve over time.

s164
00:17:34.960 --> 00:17:37.600
They just want their bug fix or their feature in.

s165
00:17:37.600 --> 00:17:40.000
Uh and many solutions are glued in place.

s166
00:17:40.000 --> 00:17:44.240
So we're we're not quite at the point where the coding agents can read our minds.

s167
00:17:44.240 --> 00:17:47.520
Uh and thus we're still limited by the medium of text.

s168
00:17:47.520 --> 00:17:50.559
And as ridiculous as it sounds, prompt engineering is quite real.

s169
00:17:50.559 --> 00:17:56.720
The quality of an implementation can be very much dependent on the the prompt that you give the model.

s170
00:17:56.720 --> 00:17:59.200
But in a sense, nothing really has changed.

s171
00:17:59.200 --> 00:18:02.080
Reading code has always been more important than writing code.

s172
00:18:02.080 --> 00:18:07.679
Um maybe not in the beginning, but eventually as the project evolves, uh it does.

s173
00:18:07.679 --> 00:18:16.480
So my closing thoughts on on using coding agents to build ambitious software is that code is now cheap, but quality is not.

s174
00:18:16.480 --> 00:18:22.960
Um the the job of a software engineer has never really been about putting lines of code on the screen.

s175
00:18:22.960 --> 00:18:34.960
It'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.

s176
00:18:34.960 --> 00:18:41.600
These facts have not changed and the bar for software engineering is higher than ever.

s177
00:18:41.679 --> 00:18:48.480
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.

s178
00:18:48.480 --> 00:18:53.120
Uh the Daxis team joined Cognition to be part of the future and hopefully you will too.

s179
00:18:53.120 --> 00:18:55.127
Thank you.

s180
00:18:55.127 --> 00:18:57.127
[applause]

s181
00:19:10.848 --> 00:19:12.848
[music]