Talk by Jonathan Kelley, founder of Dioxus Labs, about building ambitious software and how AI coding agents changed the Dioxus Rust project. Covers the project's history and scale (cross-platform Rust app framework, ~37,000 GitHub stars, rendering engine with a CSS engine from Firefox, ~100 ms hot reload), the failure mode of mass agent-generated code that never merged, how Rust's steep learning curve became an advantage once agents handled the borrow checker, and where agents help (build plugins, release checklists, documentation, fuzzing) versus fall short (writing the right tests). Kelley's takeaway: code is cheap now, quality is not, and architecture is where time goes. # Video Identity Observations: "Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition" ## Speaker & Context - The presenter identifies himself directly: **"Hello, my name is Jonathan Kelly"**, founder of the Dioxus project. - This is a **conference-style talk** format (explicit slide references: *"the next couple slides I want to talk about"*), closing with a hiring pitch. ## Explicit Self-Description Evidence - **Creator affiliation**: Speaker describes himself as part of *"the Dioxus team"* who *"joined Cognition"* — positioning Dioxus Labs/Cognition as the organizational identity. - **Explicit recruitment claim**: *"if you would like to work on the tools of the next generation of software, Cognition, the people who have acquired Dioxis, are hiring."* ## Claimed Scope of the Presentation - Stated topic: **"what it means to build ambitious software in the age of AI."** - The talk spans: - A five-year origin/history narrative of Dioxus (first commit *"5 years ago"*; Rust cross-platform app framework). - Project impact claims: *"nearly 37,000 stars on GitHub with millions of downloads"* and *"over 200 million end users."* - Lessons learned adopting **AI coding agents** in a production open-source project. ## Intended Audience - **Software engineers, particularly Rust developers and open-source maintainers** — demonstrated by: - Technical depth: borrow checker, hot reload engines, CSS spec conformance, fuzzing, bundling. - Framing references to developer ecosystems: React Native, Flutter, Electron, WebKit, Zed editor. - Direct address to peers: *"one thing we do for Daxis, which maybe you guys still do, maybe you don't, is we review every PR line by line."* ## Observable Presentation Patterns - **Positioning as domain authority**: speaker makes strong "first/only" claims, e.g., Subsecond is *"the only hot reload engine for native compiled code to have such wide language and runtime support"* and *"No one has done this before."* - **Balanced, experience-based framing on AI**: skeptical-to-adopted narrative — *"We had not felt the AGI, so to speak"* followed by *"thousands of lines of new features... sat there in draft."* Includes candid failures: agents *"have a tendency to write kind of sloppy tests."* - **Quality-focused ethos as a stated value**: *"the code is the product"*; *"code is now cheap, but quality is not."* - **Named team scale**: *"three core engineers working on Diosis"* — small team, high ambition contrast is a recurring theme. ## Claims vs. Demonstrated Behavior - **Creator claims**: adoption figures, star counts, feature completeness, team size, acquisition by Cognition — unverifiable from the material, presented as fact. - **Demonstrated patterns**: deep first-hand engineering detail (e.g., describing Blitz's rendering pipeline, *"extracted the browser grade CSS engine out of Firefox"*) lends internal consistency to expertise claims, but the talk itself is the only source. ## Metadata Note - No curated metadata was supplied; identity observations rest solely on the title and transcript. # Delivery Observations — Jonathan Kelley, "Building ambitious software" ## Overall Tone & Register - **Conversational, informal talk style**: casual asides like "Sounds easy, right?" and self-aware humor — "It's extremely nerdy." - Delivered as a **personal narrative arc**: origin story → current state → lessons learned, framed by the opening "today we're going to talk about what it means to build ambitious software in the age of AI." ## Recurring Phrases & Vocabulary - **"Dioxis / Diosis / Dioxis"** — the project name is pronounced inconsistently throughout (e.g., "Diosis" at [24], "Dioxis" at [118], "Daxis" at [176]); also "rest engineers" for "Rust engineers" [348]. Suggests imperfect transcription or variable articulation. - Repeated pairing of **quality vs. speed**: "we want to ship these quickly... but we also want to maintain quality" [555–567]; closing thesis: "code is now cheap, but quality is not" [1090]. - Recurrent framing of coding agents' strengths as **patience and knowledge**: "They have so much more patience than an individual developer does" [644]; "a level of patience and massive knowledge" [601]. - Colloquial coinages: **"slop cannon"** [412], **"a bunch of cracked Rust engineers"** [358]. ## Speech Habits - Frequent **fillers and restarts**: "Um," appears heavily in the latter half ([475], [487], [500], [735], [867], [966], [1022]). - **Doubled words from self-correction**: "all in 100 100 milliseconds" [288]; "quickly quickly sift" [634]; "is is" constructions ("It's it's been about architecting" [1101]). - Self-interrupting clarifications: "Why do I say recently?" [337]; "The thing on the right" [667]. ## Teaching / Explanatory Patterns - **Contrastive explanation**: repeatedly explains concepts by comparing to familiar alternatives — Electron ("RAM and storage hogs" [255]), React Native, Flutter, "If you know React Native turbo modules" [656]. - **Concrete numbers as evidence**: "less than 5 megabytes bundle sizes," "less than 50 megabytes of RAM" [255–265]; "nearly 37,000 stars" [176]; "two to three weeks" [656]. - **Anecdote → lesson structure**: each section opens with a project experience, then generalizes ("So throughout the process of adopting the coding tools... we learned a wide array of lessons" [463]). - Audience-inclusive hedges: "maybe you guys still do, maybe you don't" [1022]; "one thing I'm not 100% convinced yet" [857] — models calibrated uncertainty explicitly. ## Stable vs. Isolated - **Stable**: quality-vs-velocity tension, agent-as-assistant framing, concrete metric citations, informal register. - **Isolated**: humor peaks early ("we thought it would be easy" [118]) and appears less in the denser technical middle; the hiring plug at the close is a one-off shift to promotional mode. *Uncertainty note: exact quotes are taken from the transcript as supplied; apparent mispronunciations/variants (Diosis/Dioxis/Daxis) may reflect transcription artifacts rather than the speaker's delivery.* # Position Record: "Building ambitious software" — Jonathan Kelley, Dioxus Labs & Cognition ## Speaker - All positions below are attributed to **Jonathan Kelley**, the sole speaker in the transcript (self-identified in the opening). --- ## Background & Project Origin (Dioxus) - **Motivation (2021):** Kelley skipped a Google internship or AI research during his last undergraduate summer to build a cross-platform app framework in Rust. Rust's appeal: native performance, solid type system, simple cross-compilation. - **Core idea:** Write all apps in Rust, using HTML and CSS as markup, with React-inspired reactivity — no VM, no IPC, no JavaScript. - **Stated market gap:** In 2021, "React Native was janky, Flutter was too slow, and neither performed well with native APIs." - **Self-aware humor:** "We choose to build an app framework from scratch, not because it's easy, but because we thought it would be easy." ## Current State (as claimed) - Dioxus supports cross-platform, native rendering, Rust hot reload, bundle splitting; full-stack web apps share a codebase with iOS/Android apps. - ~37,000 GitHub stars, millions of downloads, estimated 200M+ cumulative end users. - **Blitz:** lightweight HTML/CSS rendering engine — Firefox-derived CSS engine, custom DOM, hybrid GPU pipeline. Claimed <5MB bundles, <50MB RAM at runtime, contrasted with Electron. - **Subsecond:** hot-reload engine for Rust, C, C++; patches running apps in ~100ms; claimed to be the only such engine with wide language/runtime support, including WebAssembly. ## Position on AI Coding Agents ### Initial skepticism - Kelley's team of expert Rust engineers was "quite skeptical of AI for a long time," "had not felt the AGI," and avoided AI in daily work, believing AI incompatible with shipping high-quality code tools. - Agents becoming "really good at Rust" was a **surprise** that changed their stance. ### Early failure mode - After adopting agents ("maxed out our cloud code subscriptions"), tens of thousands of lines were generated — but **very little met their merge-quality bar**. Features sat in draft indefinitely. "It was way too easy to become what we call a slop cannon." - Post-mortem framing: *they* didn't know how to wield the tools — not solely a tool failure. ### Rust's difficulty as an advantage - Rust is harder to write, but agents absorb that burden ("they fight the borrow checker"). The learning curve Dioxus fought to reduce "is now a feature" — a notable reversal of prior positioning. ## Where Agents Excel (per Kelley) - **Hard technical problems requiring knowledge/patience:** agents sift documentation, reverse-engineer APIs, dig into binaries. - Example: Kotlin and Swift plugins deeply integrated into the build system, shipped in "two to three weeks" (implementation in "the first day"; rest spent on tests and real-device testing) — contrasted with React Native turbo modules taking years of hand-written work. - **CSS/layout debugging in Blitz:** agents "know the CSS spec exceptionally well" and can recall how Chrome/Safari handle layout/painting issues. - **Quality inversion:** previously the team took shortcuts to ship fast; agents let them "do things the right way, not the hacky way." - **Mundane automation:** release checklists, backporting fixes, doc verification, testing that extensions (e.g., Zed editor) still work — freeing three core engineers from tedium. - **Release cadence:** more patch releases than ever, weekly or multiple times per week, where they were previously "scared" to release. - **Test harnesses / fuzzing:** agents are "excellent at building these harnesses" for adversarial/malformed inputs. ## Where Agents Fall Short (per Kelley) - **Writing the *right* tests:** agents write "sloppy tests" (e.g., testing a constructor trivially); the team still enumerates test conditions and crafts test APIs manually, though agents serve as a "sounding board" for test ideas. - **Architecture remains a human art:** agents aren't afraid of huge refactors; they "typically just ship." "Just like human engineers can write spaghetti code, so can the agents, but now just faster." Most development time is now spent on architecture and future design. - **Intent communication:** agents "can't read our minds"; contributors using agents are "quite bad at communicating their intent," producing solutions "glued in place." - **Prompt engineering is "quite real":** implementation quality depends heavily on prompt quality — though Kelley frames this as nothing fundamentally new. ## Process Values & Practices - **Code as the product:** users download, read, and build on the code; quality failures translate directly into business harm for users. - **Human review retained:** every PR is still reviewed line by line, though AI review pre-spots bugs. - **Maintainability over velocity:** velocity depends on the quality of the "substrate" already built. ## Closing Thesis > "Code is now cheap, but quality is not." - The software engineer's job was never about putting lines on screen — it's architecting elegant solutions, thinking ten steps ahead, retaining flexibility. "These facts have not changed and the bar for software engineering is higher than ever." - Ends with a hiring note for Cognition, which he states acquired Dioxus. # Speaker Attribution Record ## Video - **Title:** Building ambitious software — Jonathan Kelley, Dioxus Labs & Cognition - **Video ID:** `01a15ca7-68e0-7bb5-8ee7-7d7481e3590d` ## Speakers - **Jonathan Kelley** — **creator / sole speaker**. Self-identified in the opening line: "Hello, my name is Jonathan Kelly." Speaks throughout as a first-person project lead of Dioxus ("we," "our team"), presenting a talk about building the Dioxus framework and adopting AI coding agents. - No **guests**, **narrators**, or other identified speakers appear in the transcript. A brief closing **[music]** cue is noted, unattributed. ## Referenced Sources & Third-Party Claims Claims are made by the speaker; none independently verified in-transcript: - **Dioxus** (rendered variously "Diosis"/"Dioxis"/"Daxis"/"Daxis" in the transcript) — the speaker's project; claimed ~37,000 GitHub stars, millions of downloads, ~200 million cumulative end users. - **Blitz** — described as Dioxus's HTML/CSS rendering engine; speaker claims CSS engine extracted from **Firefox**. - **Subsecond** — described as a hot-reload engine for Rust, C, C++; claimed to be the only such engine with wide language/runtime support. - Third-party technologies referenced: **React Native**, **Flutter**, **Electron**, **Google Chrome**, **Safari/WebKit**, **Apple Git repositories**, **Kotlin and Swift plugins**, **Zed editor**, **WebAssembly**. - Speaker claims Dioxus was **acquired by Cognition** and that the Dioxus team joined Cognition. ## Promotional Segments - **Closing promotional segment (flagged):** Hiring pitch for **Cognition** — "Cognition, the people who have acquired Dioxis, are hiring… hopefully you will too." - Throughout, the speaker describes his own projects (Dioxus, Blitz, Subsecond) favorably with performance and adoption figures; these are **self-reported creator claims**, not neutral third-party evaluations. ## Availability & Provenance Limits - **No curated metadata was supplied** — no comment availability, publication details, or external corroboration. - Transcript contains apparent **speech-to-text spelling variants** of the project name (Diosis/Dioxis/Daxis/Dioxus) and a mid-sentence gap ("…a tiny but over every line of code by with our own two eyes…"). - No timestamps, external citations, or links provided in the source. 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. 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 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. 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 Diosis was straightforward. What if we had an crossplatform app framework? 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? 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 abstractly with no VM, no IPC, no JavaScript. 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. 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 Dioxis. Everything from 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 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 crossplatform 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 Daxis project now has nearly 37,000 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 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 Dioxis as userfriendly as possible. Fewer files, build tooling, hot reloading, asset optimization, everything you need to easily ship across all platforms. 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 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 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 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 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 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 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 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 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 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, 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 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. 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 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 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 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 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 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 Dioxis, we learned a wide array of lessons. Many of the thing 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 to build ambitious software 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. 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, 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, 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 like 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 road map is really long. It extends 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 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 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 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. 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 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, 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 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 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 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. 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, 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 the right way of handling it for your 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 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 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. 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 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 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 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 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 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 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 uh tasks like verifying release checklists, backporting bug fixes onto stable releases, and ensuring our docs and documents are of extremely high quality. 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 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 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, 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. 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 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 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 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 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 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 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 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 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. 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, 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. 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 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 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. 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 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. 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 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 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 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. 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 team joined Cognition to be part of the future and hopefully you will too. Thank you. \>\> \[music\]