Dune Architecture and Enforcement Layers

Meet Dune

(40:43) >> Cool. And then um yeah, also quick question on like CI. So again, you don't have to go into like uh the screen share of like your CI does, but just generally would you describe what the CI kind of looks like uh or how strict it is? >> Uh yeah, so uh well specifically for Grockbot. So Dune is the is the sort of cheeky code code name for the architecture that we've built for Grockbot.

Conventions enforced by CI

(41:11) Um the CI looks pretty annoying because there's checks for everything. So like literally I have um uh well if you've written any React for example you know you know that one of the biggest foot guns in React is use effect. Uh so in uh Dune and in graphbot we've banned use effect. So Dune is just you can the the mental model of what Dune is uh you can kind of think of it as like Nex.

(41:37) js JS for uh electron apps and it's designed for agents to write uh and it's like custom for you know our agent powered applications. Um so the CI checks are very like specific to that like you know don't use use effect it's it's it's banned like CI will fail uh and yell at you. We have like some of the more interesting ones that people might raise eyebrows is like I actually ban code comments as well.

(42:04) Uh which is very interesting. Uh but I've noticed that 99% of the time agents just write code comments that kind of describe some historical thing that is actually totally irrelevant to the code. Um like it will often say like you know oh Lauren said you should never do this and it's now in in a code comment.

I'm like what? like why what that was I didn't say that as like a durable you know global rule I just meant like your this PR sucks and you should change that part but agents don't really understand us that well surprisingly uh and or they (42:39) kind of assume too much and they kind of do things in like very stupid ways so like yeah we just ban everything everything you can imagine like the agents are bad at we ban uh so one example that we actually suffer for a lot in the agents window is we have uh you know you if you've used the agents window you've definitely seen performance issues and you know we're constantly trying to fix them.

(43:04) Uh but it's like a it's a never- ending struggle because there's so many pull requests that get merged every any one of them could just regress performance or stability or reliability. Uh you know the agents window doesn't have this architecture yet. I plan to do bring this learning back there and kind of refactor everything there.

Separate processes and protect frames

(43:26) Uh but uh it just regresses super often uh because uh there's just one example is like we have very poor um isolation between processes. So like on you know on on Electron you have a renderer thread that renders your UI but you also have like a main thread that you can run other code that you know doesn't need to block the renderer.

(43:47) Um, but we do a poor job of separating those things. And so oftentimes you just accidentally have code that gets pulled into running on the renderer thread and then all of a sudden you're competing with the the renderer that you know that has a very if you want like 60 fps you have to every frame that gets drawn has to be done in 16 milliseconds.

(44:09) So very very small you know deadline per frame uh if you want you know a very smooth product. Uh and when you start building bringing in accidentally bringing in you know things that are like very computationally heavy or they have a lot of IO uh then you just get into like a lot of jank right your your FPS really drops you start uh you know losing frames you get long tasks that take more than 16 milliseconds and you just get this really choppy experience.

Check dependency boundaries

(44:37) So all of those patterns that we've learned basically building electron apps we've encoded into this framework and it becomes like a hard failure. So I literally in in grabbot we literally have a directory called electron main electron renderer and we have uh import uh CI guess where we actually check the dependency graph to make sure you're not accidentally importing code from one directory to another.

(45:05) Uh so that's enforced by CI um as well as bug bots uh which is our which cursors um like code review tool that runs on CI uh you know in our agents MD it's everywhere like so I I I um I have this thing here where I I talk about like um you know like there are multiple layers I think for building a good codebase.

Keep feature code together

(45:30) Uh obviously the codebase is one where uh if you have an architecture like this where it's extremely strict uh you know the the the way to build features is very conventional that's like the strongest strongest level of enforcement because agents just love to copy existing patterns. So uh one example of this in rockbot is like we have this these concepts called like a feature and we have entry points and transcript cards like oh you know the cards that you see in the chat these are all like like nouns I guess in in the framework and so (46:04) there's a very conventional way of creating them and so like a feature is all in in a single directory as an example and so all of the code that contributes to that feature lives in one directory so it's all collocated in one place.

Makes it super easy. You know, agents don't have to like uh grap around and try to figure out like where all the things are. (46:26) It just looks at the feature and like, oh, okay, I'm working on the onboarding feature in Grockbot. Uh I'm just going to work in this directory. And for 80% of the work, it's mostly just very encapsulated there.

But, uh like it's like very it's like designed again for you know like the dumbest agent like you don't have to think, right? the the the one of the key principles I have for this framework is like the shortest the shortest path is the best path. (46:55) So uh because that plays exactly to how agents love to write code is like they like to take shortcuts really you know they they'll find the quickest way to solve the problem.

So why not make that the best way to solve the problem? Uh so I I I probably won't get into all the specific details. (47:16) Um and uh the the this framework is really more of a collection of ideas and principles rather than something that will open source. Uh you can you can you know screenshot this I guess if you want and uh tell your agent to uh do some build build something like this for you too.

Um yeah, but it's really all about the layers uh you know like the the codebase is one part with features uh and directories and you know import or blocking import dependencies uh that shouldn't be imported.

Layer hard and soft constraints

(47:47) Uh but and and it all enforces that and static analysis. So like uh there's CI checks, we have a lot of lints for bad patterns that we observe. uh compiler diagnostics uh there's also rules and bugbot which are um I think like three four five are more soft right these two actually make make CI red right so that you know there's a hard constraint where the agent can't just write crappy code for rules and skills and buggbot your agents can still forget right you can still or it may not always consistently apply them.

So, I like to layer them, (48:30) but I don't I don't like to rely on them as the only source of enforcement because it's very very soft, right? And if you if you only have rules and bug ball and skills and a style guide for your code, you will it's only a matter of time before your code base looks like complete trash.

(48:48) I'm sorry to say that, but uh I definitely recommend yeah like you know investing in you know things that can be hard and forced, right? Okay. And this is why you know maybe uh the choice of text stack that you use is also very important. Um like I think for example Rust is sort of making you know it's like getting super popular again.

(49:08) Uh because the compiler is so strict right the compiler enforces so many different things. you know, there's a borrow checker that you have to appease and if as long as you make sure your agents don't write unsafe code blocks, uh you can more or less feel somewhat confident that if the code compiles, it probably works and it's good.

Architecture and conventions
                 │
                 ▼
Static analysis, lint, compiler
                 │
                 ▼
CI enforces hard failures
                 │
                 ▼
Rules, skills, and review reinforce

Turn repeated review into enforcement

(49:28) Uh but you see it gives you that level of trust and confidence that you as a human engineer no longer need to go and check it yourself. you know, you you rely on code and static analysis to actually make that uh a lot smoother. Um, and I I guess the worst part, the worst place to be in is if you are stuck in code review land where you actually enforce all of the constraints, the invariance in your codebase by literally the human person saying, you know, reading the code and like, okay, you should not do this, right?

Every time you have to do that, you (50:07) should consider that as a code smell like a anti- pattern and you should say, "Okay, instead of me commenting on the PR, how do I turn this into a hard rule?" Right? How do I turn this into a lint rule? How do I turn this into a CI failure? Or how do I even categorically eliminate this problem uh entirely?

Uh I I can talk about another migration I've done, but I'll probably pause here. (50:32) >> Sure. >> Yeah. I feel like that's that's where I am to be honest is is what you're describing right now which is that like I don't have all of these rules. So I have some things to go do after this session in terms of being able to scale my agents.

I'm I'm definitely on like the uh you know maybe a couple of parallel ones locally stage like two to three locally and I'm sure most people here are on the same. (50:55) So uh yeah I know we only have a couple minutes left. Lauren, was there anything else that you wanted to to highlight? I obviously there's lots of questions so I can grab more but I want to give you a few minutes if there's anything else you want to talk about.

>> Well, I think I've been yapping for quite a lot so maybe let's just do questions.