How I AI: Mental Models, Failure Modes, Long Horizon Workflows

transcript

Yeah. So this will be um basically how to how you can get a almost a man years amount of uh work done in in a night or a day which is very much technically possible. Just have to do some things. And in fact uh this whole presentation uh is largely written from notes I've collected over the past year but um the first time I gave it was internally um yeah uh I work at uh at Nvidia as senior firmware engineer um electronics and compilers and all that of that's what I have been working with now even more schematics um hardware and silicon photonics um and I worked here uh at Oticon and I in two rounds and I've also done some biometric stuff um yeah uh I focus on the concepts not the technology the technologies will come and go they expired kind of rapidly Don't focus on that.

The concepts you you learn them deeply, they will persist. Yes. Uh let me start out by showcasing some things that I've done over the past year. Uh only the public stuff which is a small fraction of These are uh pretty much I think all of them are uh on GitHub. So these links can you can see it down there. Then then you can actually jump to them uh but uh uh for instance you can have uh some packages that you can communicate between computers um which I think is also Nyx is also being used here.

I I hear that uh there's some uh something from a master thesis which could be relevant tool to in fact uh you could argue that uh CUDA is very much for uh homogeneous large parallel things uh like GPUs. Um but if you have heterogeneous uh constellations of different chips and accelerators then you actually kind of want to use this and the reason I can publish this is because it's basically I have taken my old master thesis and reimplemented uh in rust with a lot more breadth and depth and one of the cases is actually a hearing aid uh if you have some C code you can also now formally verify it that is called C lift um that as uh that is possible because you can take the workflow that was pioneered by a research group uh in America uh for the SEAL4 uh kernel uh but did it in uh in Isabel a language for that called Isabel but it doesn't have um and that works you can already do that in Isabel but that will require you to write the proofs of your code in Isabel and AI is not uh there's not a lot of training material for Isabel but there is a lot for lean because there's math lip so there are lots of code for formal verification in lean and This is the same methodology that is ported to lead.

It is their methodology which is ported to lead. Now you can formally verify. Uh you can also implement uh SSH the SSH protocol. And by default, if you download kind of a if you do a survey, you can find something that takes about 70 kilobytes for implementing uh protocol can be done in 4 kilobytes for hearing aid. Uh if you use uh if you use Nyx, you could have Nyx has a language interpreter which is too incomplete. So you can uh you could uh run an emulate risk 5 assembly in just in the Nyx language.

And when you have that then you could of course have a C compiler. So you could simply evaluate and execute C code in Nyx without a compiler without any binaries. Mini forth is uh I think it's it's very very small. It's like uh less than 100 lines. Uh if you want a u something that is is turn complete that you can execute as a small bite code VM. Also if you want to have like a bite code VM on a hearing aid.

This is extremely small and it has a C compiler. So you can actually take arbitrary C code and you can have them interpret and run on something that you can fit uh 100 lines of code. Uh then there's something with the Sally logic which also going to spend a lot of time on. Uh I know because I worked a lot with it. Um and also at uh at Nvidia it is also used and I still dislike it. Um so uh the entire protocol is re reverse engineered here.

Grab it. uh Philips baby monitor camera uh hit. Uh it would be cool if I could do breathing rate analysis on the frames, but uh you know then I need to get the stream so I can reverse engineer it. Um uh it turns out that uh it's Chinese. for those that have kids, you can go here and then you can get a native Rust implementation of the Outland client. This I posted actually on LinkedIn and I measured uh how long it took.

It it this was done in in in for for a working draft 16 hours. two hours of like spec and upfront work and design and logging in the immediate uh and then cla goes bur over 16 and that was five or six months ago. So there's a library and there's a CLI and if you want the pictures you can mark them as a file system. those are clients for LinkedIn. Um, Microsoft Teams can also be reverse engineered. I I took a an audio call.

Yeah, this video does not work here in Rust. and next it will work us time. Uh namely the grocery delivery was done in a in a kind of boring meeting 40 minutes. Uh reading schematics uh video presentation skills which I will actually I can show you the next slide I think. You can do some fancy pants stuff with AI where you can fuse two models together and get better eval score than their themselves individually. If you have uh have gitlab then they you can visualize your pipeline across time that is the gitlab cis.

If you also have gitlab then you can also run it locally. You could simply ostracize out the Ruby part that implements the actual pipeline scheduling logic and run it locally. Uh my blog is written in in its own kind of uh lang uh framework niche can geollocate from Wi-Fi and you can have some category theory to uh domain modeling. It's not a UML diagram. It is complimementaryary. Uh UML will speak of the states and so on. What's like what connects where and so on.

But uh ontology logs will define what a thing is. It's good for onboarding. So that is some green field projects meaning uh I started them from scratch. Um and this is the the last 12 months. Then there's some brownfield examples and of course there are some brownfield a lot of stuff and also green field or that I cannot show work but uh um I can I can show I can demo two things at once. audio will work here. Probably not. Anyway, um this is narrated um uh this is uh solving and explaining um a uh kind of memory fragmentation error in the Linux kernel that I had on my one of my routers.

Um that was solved in in a day and when I say a day it's like uh unattended uh and this video presentation thing here uh it takes 3 minutes to prompt and then there's a skill I've made a skill for making such videos and then it go it it takes about an hour uh mostly to actually uh take each frame. That's the main but to make such a video takes in wall clock time about an hour. Then there are something that CERN has make made which is Ganesha.

That's how they pump out all the LHC data. They basically pump that through something called Ganesha which is really a multiplexer for storage and that's good if if uh if Nvidia has some slow links or if has some slow NFS then you can actually you can think of it as an engine X but for storage but [laughter] renode is very nice Um especially now with AI Noda is a uh type checking kernel for formal verification. Um I could speed that up.

This is the fastest typeing kernel for uh formal verification. Um 12% latency improvement. Yeah. Okay. So that was just a showcase um like let's say half of what you can do in a in a um and this will also not make sense without sound. Let me see I I it doesn't matter. It doesn't matter. Um this guy is nice because he uh he speaks funny. Um and he says functions are important and they control the world and that is correct. Um and uh uh so basically this is very important right you have uh f composed with g um this is very important um this is how you manage complexity this is basically Unix philosophy in in uh in math uh you have two functions g and f and they have each their own domain and then you bubble them together you don't let them know about each other you don't have inheritance You have composition.

You do composition. This is how you get scalable things. Um neural networks are so general by design um that they are you you can think of them as universal function approximators, right? Um they they can fit a banana. They can learn anything. Um and when you exert enough pressure you can show that what happens in the middle uh if you give them tokens like speech and text or at the input and the output then what is in the middle? Well it it turns out that if the network is large enough then it forms kind of a this latent space where um it forms concepts of things.

This was shown very early on for image generation where the networks would simply automatically from the data set of all the images would simply just detect sunglasses. And so you would have one parameter, one weight or a few weights that would control sunglasses nests and you could simply slide that up and down to give people more or less sunglasses. And so that's a concept, right? because it's a recurring theme and they are very good at what we can see here at at the basically they they learn the composition because it's more economic.

Um when you have a lot of training data um you basically uh uh the the training itself is the discovery of patterns. Like you give a lot of uh data but you you force it to uh be squished down into a much smaller set of data, right? uh and in doing so there's really some forces at play that uh want to have things economical. You are exerting the the the the pressure through training and the training loss. Um and you could say that this is a kind of compression because if you have a good compression algorithm then it probably identify it's good at identifying the patterns in your data.

uh this is just a a bit more fussy. It is not it is a lossy function. But then what actually happens to to be encoded in these weights? Um you can think of as u first you have a few layers that need to parse your sentence that is like your syntax. Uh English has syntax words and vocabulary. uh but then they in context of each other mean something like in semantics and intent. Intent is probably what you from your one sentence which may be ambiguous given the broader context of what you have said before may change the meaning right and in the end you have basically domain knowledge that well he is talking about this thing here he's not talking about all the other possible interpretations and uh when you squish all of these things down You should really think of it like almost like a quantum many worlds thing because you're literally talking with a condensate of all of humanity's output squashed down, right?

It's humanity.exe. Uh so you need to be careful, right? Uh you can ask about Harry Potter, you can ask about uh coding, uh baking recipes, um genetics, whatever, right? Um if there are some similarities cross discipline, AI might probably have detected some patterns in between that because it would be just more economical for to store it. Yeah, this means also you should think of them these large language models as schizophrenic in a in a a sense it's the ultimate schizophrenic because uh um they have extreme versatility and the data set is not really I mean [clears throat] it would make sense that you do an agent specifically for coding and people also do that um uh but if you have the general models then you should actually be kind of specific about what you in in terms of role and context and and your goal.

Uh yeah. Um so if if you have the earth um you know you have some pressure gravity uh and uh you know you can mix soap and water and and oil and water and um you can you can shake these things and they will maybe uh chemically uh in a greedy fashion segregate in in layers naturally. Um and I would argue that uh nature does this. Nature has a very nice abstraction level called atoms and then it has something called molecules and then you have blah blah blah and you have genes and cells and so there tends to be some discrete if fussy boundaries between these levels of abstraction.

And uh you can you can you can show that the same thing happens when you do uh an analysis of the latent space in a in a network uh which is of course way way way uh too high dimensional like they have hundreds or millions of dimensions. So you need to kind of um either do it for very small models or you need some projection. Here it's the Uh so um so you can you can show that this is uh simply natural.

There's nothing uh uh special about that. If if you have a negative feedback loop and you minimize a thing or optimize a thing, you will get these patterns. And then uh every time you uh that the network works it it predicts it actually gives you a distribution of tokens and you sample from that with a temperature. Um this can go many ways right you can either pick token A or token B from the given context and then you adopt this and then you go on right so uh every single session you have if you simply repeat it with a non-zero temperature uh it will drift in some way you will not get the same upper uh but when I'm speaking um I am also kind of forced to say one word at a I have a a mental picture of what I want to articulate and I constantly kind of re-evaluate if I've said my if I've articulated my point but the precise words that I'm going to say I don't know what is going to come out exactly.

Um but I I have hindsight in what I have said and what I may lack yet and if you ask me a second time I will probably articulate it in a slightly different way. And uh that's not so different from what uh networks do, right? Um but what if it actually says something that is kind of complete bogus? Um then it's it's there. It's stuck. It cannot retract it. It cannot retract a token. Um uh and that's where chain of thought comes in because it basically gives the network it is not the network thinking that you cannot see and the network cannot introspect on how what data flows through the network.

Um it will simply do the sampling. All the sampling is still happening. It is simply a delimitation on uh how um it's a it's a scratch path. You can have the AI do a rehearsal of what it wants to output and see if it kind of makes sense before it will commit to output. That is chain of thought. It is essentially a hack uh for for AI but it does increase the eval scores quite a bit. Uh that's also why fusion works.

In Fusion, you have this uh thing where uh you can run uh different models, but you can certainly also run the same model uh twice for the same context and you give a new prompt and you simply run it in duplicate and because the sampling temperatures or the seeds are different, you will get different outputs. Okay. Now, what then you have a a judge or a selector that will that can uh cut and paste snippets of what they may agree on or what uh they may not um and and synthesize a a union of those.

And if you do that as uh this is an article from um open router they showed that you can beat the frontier with this if you had at that time they had fable five uh at the frontier and it it turns out that if you took 4.8 eight, which is kind of a step below fable. If you took two of those, they would exceed Fable. Uh, yep. Uh, I have a package for that, by the way. Then there are some things with AI that doesn't work.

There there are hallucinations, overconfidence, context poisoning and and distraction. And we'll get into into those things. U but um essentially um this the main problem is open loop. Um, if you just prompt something and you do some complicated work, you know, that relies on all the prior facts, if any of those prior facts turn out to be slightly wrong, then your, you know, your vector angle is is wrong and it's it's going to compound. um these dominoes will fall if nothing else is kind of pushing them back up or exerting some negative feedback loop.

You should not use AI for anything that requires 100% guaranteed. You shouldn't also rely on humans for anything that is 100%. uh uh in in fact you can think of AI as a mini represent representative human right the same pitfalls basically apply humans will cheat and lie and and be confidently wrong also if pressured on time or something um if you want determinism you should use deterministic programs and luckily AI is quite good at writing deterministic programs so you can falsify and it can also run the same thing and you can give it to another person and they can also run it and that's much better than you, you know, prompt a goddamn AI and pay tokens for it.

Why why do that? Um so so you you use all the soft squishy parts and you combine them with a hard deterministic. Um yeah uh this is what most people will do. Uh this is this is VIP coding. This is VIP. The first thing is VIP coding. That's where you take a non-expert and you say ah you can do anything in the world blah blah blah. Uh just go knock yourself out. Get this glorious uh textbox prompt. Just type in whatever you want and it'll do something.

It will do something. It may work the first time round. It may work for a few iterations but eventually if you add enough complexity it's going to break down either because the context window will grow and there are many many pitfalls but um the problem is um there's a lack of process this is very lax right there's no discipline here this is not engineering um in engineering you have a version control system you have tasks you have sort of a plan you you kind of know where you want to go you need to actually have documentation for the things that it interacts with.

You also need to document the things that you have done uh such that when other people come in or new AI agents, new hires, they can onboard. That is engineering I would say. And if you can add a lot of good testing, then they can kind of self-reover. So open loop, closed loop, negative feedback. Good. You know, you you set the direction, you set the vector, and you have uh reachable fine grained tasks on the path to that. Uh you shall not blindly trust AI.

You can also not trust everything you read on the internet written by humans. Uh again there's no like at what point is the difference um uh but um AI has this thing where if you have a very long context window so this grows as you progress in your session then you can at various uh points in your session you could have something like a needle remember the small detail you just casually place it in there uh something could it could be very important detail um and then at the end of that context window.

So you have to think of it like you go uh to you only have this part here and then you ask at that point what is the needle and that's going to have a success rate because these are probabilistic. You should always think of them as probabilistic. They are probabilistic. You cannot expect 100% from something that is stochastic. So um uh so you're going to get a failure rate and that failure rate is actually kind of dependent on where in the context or when and where in the context window you you set that thing.

Um that is uh kind of a yeah this this is a thing lost in the middle. Um and the recall is actually kind of good for the start and not so much for the end. And uh that is in part probably due to reinforcement um because you have pre-training and then you have reinforcement after you have multiple stages of training. Yes, I'm also going to repeat myself a few times in this because that works for humans as well as AI. So, uh, if you repeat the needle, the plot is going to be different.

The heat map is going to look different. Um, yes. Sorry, quick question. Can you can you give an example of this uh needle because I'm not sure I understood the concept. It could be um pay attention to how you build this uh uh code base. There is a minor quirk in when we do this blah blah blah. Uh you know that is not very uh common place. U it could be uh when you do an end to end test you need to be aware that the USB hub is power cycled before right.

Um, and if your session has not really done that, uh, because it's not in the context, so it's not, uh, well remembered in the context window, it's not biased into the context window, then um, if you then ask about it or uh, if you wish for that action to happen later, then you're going to get the poor results. um it may not uh restart the USB up. It may forget to do so. Uh then there are some uh funny things on the internet where people say h we're we're not at AGI uh level yet.

And uh my uh experience tells me absolutely that these models are superhuman at current state. They're superhuman at anything I've seen. I cannot vouch for biology or anything like that, but for coding um reverse engineering anything of complexity, they are superhuman. Um so when when something when people say look look at this funny haha it's it's not so clever. If you look at it, uh if you think of the AI as a kind of autistic person, uh that person would would answer the same way.

Uh the car wash is 50 m away. Should I walk or take the car? Well, where is the car there? There's a failure of spec. It is big. It is very human. Uh and they can't mind read. And yet probably Elon Musk is working with that. Um but um this is a spec failure. Um you should anticipate this. Um you cannot expect a a good probabilistic uh like a good success. There's a distribution of the answers. It's not you will not get the same answer every time.

If you repeat the same question a 100 times in different clean contexts, you will get many different answers. they will group and like consolidate in different clusters but uh the success rate is not going to be good. the strawberry thing. I've probably have also seen that uh that was an issue of tokenization because the networks simply do not see or read. They cannot see the actual characters. That's a property of the tokenization. Uh at the very first step, those uh uh letters are dissolved into 100,000 dimensional embedding vectors.

There are there are no words or characters in in that. They operate at like the basic unit of a token is a semantic vector of at least 100,000 dimensions. That's why you need a lot of RAM in the GPUs because when you have say a million context window and you need that many vectors, you need that much RAM. So a single word will literally take up like almost 100 kilobytes. You can stuff a whole picture. That's why pictures are actually kind of token efficient.

Yes. Uh this is because humans don't understand how the models are at current constructed. you know we will see different architectures in time context engineering. So uh you have a session uh it has some context it has a s it is born with a system prompt typically um uh but but it it's really and then you you prompt stuff and stuff gets put into it and it's all appended. Um, if you say if you say if it makes a mistake and you say don't do that or something like that, you want to course correct it going forward.

Uh, that's wrong because now you've added more garbage. It had some garbage and you course corrected it. So now you have garbage plus the course correction. What you want to do is you you want to actually step back in the context window which in CL it depends on the harness but in cloud code say you double escape and you can actually just rewind the context window because you can it's literally a a linear buffer so you can just reset it to that point and then you need to rearticulate or make your statement more precise.

If you do all of a lot of these course corrections, they are just noise that the network has to then source out because well it did something but then it needs to remember again with a catastrophic thing forgetting um then it needs to remember that ah that was not the way to do it and so on. It it's just much better to have less confusion and you can reset uh rewind the concept. So this is clean context. It's it's a soup uh here.

Um and here you have a lot of noise. You have blah blah blah. All sorts of things. Irrelevant noise. Not no not good. Yeah. Um we will get into the distillation and exploration but the recall degrades. The quality of your your output will depend on of course how well you precisely articulate your prompt, the model itself, how the model fits with the harness and the tools that it has available and the the workflow that you adopt in the harness. The harness is just a a an excuse for the model to be able to call tools.

The harness exposes tools to the model and the feedback uh which matters a lot. Uh but you can then choose how to use in a workflow that and the tools that you come with. Um some tools have higher friction than others. you can decrease tool friction and very good. Um yeah, so um every time you start a new context window, the AI uh is is onboarded fresh. It doesn't know. It's just it's born with its biases from the labs. Uh it hasn't seen your code.

It is completely freshly graduated. Uh it is a professor but it it had it's day one for the for the new tire. Um yeah um it doesn't have memory. The thing with the with the what I see with the current harnesses is that they try to have memory systems. I would be very careful with those memory systems because they if they spend a bit of time um trying and then succeeding um they will oh that's that's very important. And I need to remember this in the memory MD.

But uh if if if that memory is at some point going to go stale or if it is just a workaround that it achieved because it should have done something else now it's now persisted only for you. So it's not reproducible for others. You cannot distribute because the memory file is local. Not ideal. Um, so I would honestly uh not not use that. Um um yeah uh if you have um conventions in your codebase, they should be codified uh ideally as deterministic things if you can uh or or as as documentation.

Um what is best practice for humans is good for AI. good engineering. Um and um um you have you can think of that uh and now we get into what what I do basically but you can think of that you have long-term and short-term documentation. You have something that is that doesn't really change very often like you have your requirements or what you want to achieve. What is the vision in your uh uh project? What is what is it about u uh your architecture documentation?

Those don't change often. And then you have uh short-term things, individual tasks. Um and of course the the uh short-term tasks to be able to do the short-term task it needs to understand what is what world are we in what are the long-term things but then when a task is done you don't need to the point is you don't need to remember it anymore then you can just go um so you can think of it like your context window is your RAM it doesn't have memory Hopefully, uh, when you boot up your agent, it should load these long-term docs and then do the short-term work and then you're done.

Ideally, you do not extend the window longer. Um, then there are uh many code bases and companies debate endlessly on coding guidelines and in the age of AI, this is simply a moot point. It doesn't make sense. just stop. Uh don't think of don't do that. Uh if you want coding adherence to coding guidelines, use llinters or deterministic tools for that and just do that on the back burner after don't bother the AI with it because it is just slowing it down just like humans would be slowed down by it.

Um do it after. You can always limp or pretty print your code. Um it is better to let the AI work without many uh paper cuts or things in mind. Let it work naturally because um it will work generally well and then if you have particular opinions you can come with them after. Um you if you write some code um when you uh there are many aspects you should be aware of. You should be aware of security. You need to uh update the docs, read the docs and write new orend them.

You need maybe perhaps to be aware of performance. Then there's all these low-level coding style things. uh testing and lint and architecture and performance and memory. Um if you overload an agent or a person with all these at in one go, you your head will just explode. You will typically implement something first that works and then you will maybe profile and blah blah blah and test deeper and so on and then you can think of documentation or uh coding style or whatever.

Um it is much more valuable to to do to really specify what is good and bad architecture. uh the semantic and meaning the intentional thing the the actual um meat you want you want to uh you actually want the agent to be bothered with those things like don't block the main loop thread. Okay, good good point because if if it doesn't if it does u then recovering all that work could be a pain. Yeah. Uh the more you overload AI or humans with instructions that may be in conflict with each other, uh the less kind of cognitive overload you get wear different hats at different times.

How how do I practically practically you can define sub agents for these things. Um there's a slide for it but um uh I in particular have a a sub agent that embody my principles. I have a mini me u my ethos of architect architecture and then I have another agent that can um do testing that can uh do uh mutation based testing or whatever kinds of testing. Um and those are two different sub aents. One has opinion and the other doesn't have so much opinion.

It just needs to run the uh the thing. Uh but you can have all those things. Uh I don't have a particular agent for security. Uh but that might be a concern you know for for some people. Um but uh um when you when you you have your main context can start the sub agents they start fresh. They are actually prompted by the main orchestrator. So there is some uh transfer of knowledge uh from the main to the uh uh sub aents.

But the neat thing is that these are actually they will by default more or less run in parallel and then they will work. Um they may uh need to discover a bit more of the codebase. In fact they will also you do pay a tax because you uh they also in fact need to uh learn and get their bearings on the codebase. What is this codebase about? For instance, the architect would need to know that test tester persona probably not so much.

But then they would fold in and return and give back their feedback or the conclusion to the to the main orchestrator. So do they are they allowed to make the code or do they only return the idea to the main orchestrator? That is a very good point because uh uh when you see people uh uh say I'm starting a 100 agent swarm thing. Yeah. Uh that's expensive, right? Uh if they all modify the codebase, that's not so good. um if they review read only fine not uh but if you have something with multiple writers so you really need to just be careful in that sense uh we will see in one of the next few slides I only have one that I implement in se in in sequence um I specifically uh ensure if there are writers that they work and operate on distinctly different things so they don't tread on each other's toes.

Um the the 100 uh uh agent thing that is working on the same go is is it's chaotic. Um I've seen Peter Steinburgger do that for the Nemo claw and it's a mess. It's a complete mess just and he pays network his bill he showed his token their bill is about $1.3 million a month and it's not so good right uh Nemo or the open yeah and so say I have uh I want to uh design, implement and document a piece of code.

Um, I could ask one agent to do that or I could ask three agents to design, implement, document a go. Yeah. Uh, I guess I would get very different results based on who is the leading uh agent on that power order. So do you have any yes ideas of what the AI is best at like writing code and implicitly get the design right and then experts design production that or better at designing and then so I I will ask kind of a a funny um what would you do in a company you would implement the code first probably that's or read some background documentation how you but you would get Yeah, you would refine and iterate on it, right?

But probably you want to get the code right first. It doesn't make sense to jump to documentation first because you don't have the code. Um, you want to see that you have something working and you would iterate on it and then you would write the documentation and also do some you know testing before documentation. Um um what I would do is um uh I will show a task management system which is fully open source which is very very nice. um um it's called backlog and I would simply define the work in backlog and uh backlog has support for just like J you can think of it like Jira just that it it resides locally so you have much faster thing uh latency um also then the neat thing is that um there's no race condition um and you can let the agents iterate on that faster uh um so I would define basically an umbrella task if it's a complicated thing and then subdivide it basically implement that thing uh make sure we have tested it end to end could also be part of the acceptance criteria of the implementation task in fact that would make sense because uh that much more load it doesn't really uh if you split it up into way too fine grained there are pros and cons for those Um but uh you backlog has support for these acceptance criteria and it makes sense to have an agent do one logical unit if it has implemented it and it works and it's tested um then uh you know it may make sense to let it document also.

Um it's just because sometimes it's difficult for me to figure out how much logic uh is applied by the AI or if it if you want to keep things separate then is it better for me to not uh put in context by asking you to design it first like to write it in words what it will do or is it better just to let it implement and then deduct the design from that later. Yeah, why not? er if it is if it is uh something that is challenging I think it would even make sense to do a a small focused proof of concept kind of falsify the the basis of it these are free now a a p used to take time you had to make it yourself now it's free it will be done in 20 minutes um it if there are some learnings that can be gotten from that puck then it you don't you didn't need to have it fully integrated into the big system yet.

Uh only to discover after one hour of firmware compilation that it uh doesn't work. But but this is uh back to the workflow in the quality equation that is exactly the workflow component and uh your quality will depend uh a lot on how and what workflow you use but I will get into the particular workflows that I I do. Okay. the workflow. Uh yeah. Um this is a bit the same. Uh you have something longived and something short-lived. You have the uh product or project requirements design.

Um you specify you you should actually articulate what the point is a vision. uh if you uh plot [clears throat] the AI with too many details, it will not be able to see the forest uh for the uh trees um too many details can obscure what what is good or bad. So some high level thing and this is true of most brownfield projects they this is all tacet implicit knowledge in distributed across your heads. Um but what is the what should the firmware do boot up or should it boot fast or what what is the metrics what what is good or bad?

um um that's basically the PRD um vision and goals. Um uh if you have a design spec uh very nice, you need to make sure that AI can act access it and it knows and understands the vocabulary. um uh if there's a lot of specs and architecture and all that stuff then uh those should be skills I would say um but skills compose very well uh you have you have basically MCP and you have skills and you have agents uh MCP is when you connect to a tool that is kind of remote typically I would not advocate ever for MCPs they don't scale very well actually it is much better to have a command line with a skill that vastly outperforms in context efficiency and um a kind of a range or breadth what you can otherwise do with an MCP.

An MCP uh is very context expensive because it actually teaches the AI it blasts it with the entire API all at once and that's the API. It's not composable. It cannot put a pipe in it. You cannot pipe it through Gret. You cannot strap a for loop over it, but you can with a command line. Um, and command line tools can have d-help, and that's what the agents will probe. So, they will kind of self-discover. Um, but they will not understand or know that that tool exists in the first place unless you have a skill that kind of explains that the business.

So if you have design specs uh which are big um maybe you need a tool in front of it or maybe they can just be skills in your workspace. uh plan. This could be either JVA or it could be backlog. Um, but I will show you that backlog has a long-term advantage because you get the uh you actually preserve the the meaning or the intent behind code changes in your codebase which is otherwise delegated to some third party thing called Jira where you could see the motivation but now in Jira you have the intent or the wish what was actually desired and your codebase holds what was implemented and sometimes the mapping between those two is kind of lossy.

Uh that's not so good. Uh what if you couldn't I mean it's just text god damn it. I mean just put it in in git. It's not that difficult. So um uh and then if you run git blame or if you have a reviewer you know uh if you have a backlog task then the reviewer can probably read the what what was the problem in the first place instead of just being blasted with a diff that you had to decode and then when you run git blame six months later you can actually see the backlog task for the motivation behind why was this done this way what was the thing we That's why backlog and there is a backlog to durize somebody that and Mark if you um I can see that you have 49 slides and we have 30 minutes so I'm not sure how you want to distribute that.

Yeah. Yeah. Uh I will take up all the time. Yes, that's correct. That's intended. Uh let me move on. Um this is uh delegation. You have the explorer. It can pollute a lot of stuff. It will put a it will basically run GP but that GP will be polluted with a lot of false matches. So you should isolate that and most harnesses will do that already. Issue the explorer and then you only get the conclusion. This mitigates context pollution which is a good thing.

They do this uh by themselves. Um for join that's what that's basically how they do it. you have your parent context and it can delegate out to the sub agent and this makes sense uh that um uh it can do a lot of stuff and then you get the conclusion back. So you only in the parent agent it cost you more or less 100 tokens instead of 50k being put permanently in terms of confusion in bulk on the parent. Uh yeah, this is pretty easy.

This is what I do. I have an orchestrator uh something implements mainly my small mini me and then I uh in parallel have a review and test and a fix um and they will iterate and that's a task. If there are any learnings or uh conclusions or new discoveries um they are simply filed as new tasks in backlog and then it uh it goes to the next task and runs the backlog tool the orchestrator. So the orchestrator is pretty done it just needs to run the backlog tool and see what is the next task.

It's basically the pro product manager and uh uh it just okay and what should we do? We should usually do this thing. Okay. and it will need to ramp up because you need to have a new agent on board exactly to the same point of knowledge every time. That should be that's just what it will do. Um and uh and then you you feed forward the learnings and every so often every half a day or a day then um the backlog uh you can look at the backlog you can you can also run the code um and look at it and uh as a human and then you provide your own feedback also in terms of backlog tasks that's what I And uh this is simply uh context engineering.

Uh you need to be precise. Uh I would happily spend two hours um designing and thinking of what I want before letting it loose at all. And uh uh it should I for those green field projects um it it really takes two hours uh of my time to start it. Um and I need I have some I I I speak a lot of things and I write a lot of things and then uh uh they that may have ambiguities. So I ask AI to produce this as part of the phase one.

We will see that later as a skill. um to basically expand it to make it more articulate and I read that and I look for inconsistencies or misalignment and I call and I cross correct it there and I do that a few rounds. So I read and reread five pages over and over until I'm very satisfied that this is purely a spec. Now just echo execute. Um and uh feedback is very important. Uh good feedback loop. Um and you can get unreasonable amount of feedback uh uh deterministic tools because you can ask for fussing.

um mutation testing where you let AI up your codebase intentionally and run the unit tests and your unit test should then fail. If not, you have poor unit tests. Uh or you can even uh in these times you can ask for formal verification which is easy for rust. Um, if you find something goes wrong, if you repeat yourself or if you see something go repeatedly wrong in your workflow, you need to take a step back and think of how you fix it uh going permanently.

Um, uh, simple things, paper cuts, uh, people not finding a package or your packages are not locked, you need to fix that immediately. Um and then uh um you can delegate different sub agent personas for different uh things. Uh an architect for you know aspirational things, a software pragmatic gardener that doesn't have an opinion but needs to still see how it fits into the brownfield project. uh and tester and these are are dividing concrete. Um you want to have your brown field codebase uh convert to the same uh point as a green field.

Basically a a task management system. The brownfield project you should have documentation. it will probably take lots of time to build that documentation because it has to be done incremental. But if you see the agent assuming something wrong, that's because it couldn't really see that it was not onboarded correctly. So you go and fix it in the documentation. So it can onboard correctly the next time. And this can scale because you have if you have that in git, it will be distributed to your peers.

Um yeah, that's uh more the same. This is a Ralph loop. Um a Ralph loop is where you run basically the same thing over and over and over. Uh but the thing that changes are the tasks and uh the state is in your workspace. Um and this can go uh this will produce a lot of work, but it will only work if you have good uh negative feedback. Um how you test is uh crucial. If you don't have good tests, it will not work.

You need tests. Um that is a problem if you are dealing with hardware because you then you will literally walk into the bottleneck of like scarcity of hardware available. But you can ask for unreasonable things. So you can make uh you can get uh models simulators and if you have the code for your hardware you can model it and that is literally a language translation from say RTL to a behavioral model. Now you can get hardware at scale. The all of these things is now centered around you or one development scaling the efforts and having controlling several agent moving up an abstraction layer where you are more expecting and and verify testing but if you work in a team then I'm just asking if all people are doing this then maybe some of your personal experience because what I remember from also working with developers is that the most engaging part is the creating part.

The more pain for a developer is to sit and value things that others have done. So it kind of like that scaling. Yes. Yes. Yes. I understand. I uh the uh the the thing is you shouldn't let AI solve the problem for you. If you know how to solve it, you should definitely articulate it. Um you can outsource it but that's pretty bad for future. Um uh it it is simply the execution. Uh uh often you will know how to solve a problem and you are bottlenecked by uh your finger typing speed.

Um if and if it's a tricky bug then you need a lot of iterations. Then it's not so much about thinking but then it's about hypothesis checking. Um so uh so AI is the execution and it can also you can have it as a sparring partner for for thinking but if you know how to solve a thing tell it and put it in a backdrop task so it's visible across time. If it up, then you can just have that agent um resume that task or implement different candidates and you could benchmark or make a tournament for the different uh what you uh are increasingly about uh concerned about is testing and um um the workflow.

Workflow extremely important. if you get 5% in increase of your workflow. But but here we're talking about, you know, potentially orders. Um, and it's also the biggest untapped potential that I see. The models are very good, the harnesses are very good, but workflow is very scattered. There's no consensus on how you do workflow. It's also subjective to Um yeah um there all sorts of things because there's bias. Don't say what you don't want. That will give bias that uh uh make make it such that errors are a non-issue.

If it deletes your workspace, you don't care. Uh isolate it in Docker or VM and put it in Git and make sure that it pushes Um, you really need to be concerned about supply chain attacks. Uh, because AI will happily fetch a lot of software. They are not always benign. Uh, it can be sold via it infrastructure and and white lists. Uh, you should think of batching stuff. If you are sitting and prompting and you're not fully autonomous, then think in batches.

Uh, I rarely just type a single prompt. Um, if if there are multiple things like reviewing this presentation, I simply note it down or talk it into my text editor and I give it uh in bulk and it will uh happily do that and then I review more and it will sit in the background and be done with that before I have progressed further. Um if you do that uh at a like if it's not pipelined if it's single roundtrip then you will just sit and wait for the AI but if you batch it then AI is much faster than you and uh so you mitigate some overhead.

Use Rust. There are good transpilers now for C to to Z. Rust has very good negative feedback. Um, you can think of your own prior sessions as a as a data source. You can mine it. Look for your own pitfalls or claude even has that as a built-in tool. It's called slash insights. Uh, you should use good tooling and these slides are in map. So, it's just text. I can easily diff it. I can show it to colleague. They can comment.

AI can edit. It's not PowerPoint. It doesn't need my attention or gooey. These are my skills. Uh I have uh for the green field thing. Uh the phase one is where I spend two hours. Then I spend maybe five minutes in the phase two where I actually populate an entire backlog. So this is you could think of it as many months of work that is just being spawned in fine grain detail in the phase two and phase three is the execution which will take some days.

Um these are skills they are public you can see them there on uh on GitHub. Um the way these were made was that I did this manually um many times and then I okay I'm seeming to fall in into a pattern let AI data mine all my prior sessions and constitute these uh uh have my input architect QA and something that can uh take a more user centric values uh opinion on priority. Uh there are many tiers of AI usage. Many people they just log into a web page chat to see.

Then you could have an editor with assistance. You could have cloud code where you actually delegate have true agentic things. Then you can have backlog the Ralph loop where you get quite fast cadence or you can have a thing where uh uh it just improves itself. uh which is Gasilla, not open source yet, but uh the majority of the time I simply uh review merge requests from AI that works at night on our code bases. Uh the problem with normal AI or uh not the route loop but um is that when you have a mature codebase then you AI basically is bottlenecked by the human waiting to prompt figure something out.

But who addresses technical debt? AI will not address technical debt unless you prompt it to. Why not have basically a service that tackles technical debt? So that happens every night across our code bases. Uh so I define perpetual tasks. It could be lint documentation accuracy if it is drifted according to the code. And this simply happens at a weekly cadence. Each task at a week's notice there's a chron. And then it will uh do that and it will test and it will put on on CI.

If the CI passes then it is human assigned. Uh this is backlog. I highly encourage this backlog thing. Um it's a simple tool from your command line but you can also get browser. It has a command line and a tui but you can also ask it to spin up a web browser if you want the ja deal. It's a canban board. It's not big or complicated. It is meant to be simple. Uh but these uh if you drag and drop a card here from one or the other and you can click and edit if you want to use the web interface um it will reflect on your file system uh immediately because it's spawned by a ser when you run as a cas and it has to use your runners or it uses some kind of resource to test.

Do you have and I'm do you have that much excessive runner resources available to run this? Uh essentially I set up the runners uh I have set up the runners but there's a one particular runner that it will always run on name the one that is locked down. It doesn't really have internet. That's because you can't trust AI. Don't trust AI. Don't trust it. It will do stuff. You know about our conduct where we have different runners down in the basement.

I went to see that every other night. Yeah. It would consume a massive amount of separation of concerns. The uh the you want to separate AI running it will do a change. It may not work but that change is then subject to regression tests. Two different things. something that proposes changes checks your documentation for instance and something that runs I'm more concerned about the the time that the rundown and tests equipment that's we don't have that kind of we don't have that capacity we don't either but that's why we make renode models uh so you can take uh for instance uh all our some IC's there were 28 IC's half a year ago um I can make re I've made reode models of them in parallel um in 9 days.

Um and now we have that and that's a gate and that's faster than real time. That is faster and you can spin up as many as you want. Yeah. Uh backlog very nice I recommend open source. The real benefit of backlog is this dumbledore. um you know you have a thing you have you're thinking of something uh but actually the AI agent has the better context knowledge right at this point so um uh so you can ask the AI agent to basically do a review say of your codebase and it can find a lot of stuff and what you get presented with is just the summary right it's actually much deeper in its context window in itself you just get to see the outcome but with backlog it is very Easy.

Then you could just ask, okay, file these as new backlog tasks, right? It has better grasp of what has just happened, what it has seen than what you were, what it presented you with. If you had to go and manually type stuff, super inefficient and you would get loss, manual transcription errors, it will be much higher fidelity with a backlog. And they are very nice. like Jira by comparison you barely get a headline you know if if people bother or body like there's no body in a G it's just a headline typically what the hell does that mean and that's the task you're supposed to evaluate your your sprint planning on the hell is that what what we do in in our team is actually we use the context to the jur contemplated whether or not this is how loying is is a format So what I've done at some point is actually I spawn both a juro task and a whip branch that the AI gets to generate in order to not lose any of the implementation detail that it sometimes lose.

Yeah. But backlog is a higher resolution back end. Yes, it is. And the neat thing with backlog is that you can always dot on a new subtask. And then just synchronize your Yeah. And it's get and in in the review when it's marked done you can see okay this was either born here or it's old or and you can add implementation details to it and it can your agents when it spawns from one sub agent to the next it can pass on learnings between the sub tasks or the task yeah the history of the backlog items are easily reviewable.

Yes, like uh good um AI uses a lot of the current technology uses a lot of thinking hacks and crutches. I expect this to be better over time. Like this chain of thought is basically a hack. Rag is also kind of it's good but it's mainly good for unstructured data. If you have structured data, I would recommend a skill. Um tool use um yeah, use deterministic tool. um blah blah blah takeaways uh what leaves us then humans are basically now uh you know in dog slays in Canada you have dog slays uh dogs and uh those are your agents right they're very eager they will run you need to put them in a harness and you need to steer them in the right direction so you need to be the human at the end of this uh as this dog flip.

Um so we are shepherds basically and they are fallible. You shouldn't trust them. That's why you need very good testing. Um you also need to put in the time. If AI does not work, it can be brought to work. Just fix it. Make sure that your your common pitfall is then fixed. Um and uh yeah return on investment is is quite high I would say but you need to pay both in to tokens but also your own uh experience. You don't learn to play the guitar by watching others.

Uh there are some skills that you need. Uh you need to know what is possible. You need to envision what can be made possible because the cost has now dropped many orders of magnitude. You do need expertise. In fact, you probably need it a lot more now because the pace is increasing. So, you need to be able to falsify and also decide what should be done. If you can do that and you don't just ask for a vague thing um then you will be much better off.

It will also be easier to review if you know what you want. You can review for that instead of something vague that you have not specified. Then you don't know what to look for. Um you need marketing. This is now the attention economy. Uh yeah. Uh you can self-reflect on ambiguity before you prompt it. Um it makes sense to actually speak things twice or say things uh in repetition not not the same thing but articulate it slightly different. Um try this backlog tool.

Uh we actually also use Gila but that's for epics and we aim to close an epic per week and so we subdivide an epic into backdrop classes. Yeah, this whole presentation is consolidated uh from some notes that I've collected. So this is basically one product and all the figures are also made by AI in 12 minutes in parallel. Yeah. to talk and actually these end points you have here at least for myself in these days I'm quite lucky to have just meaning I've been in the field for a long time you have some recommendations for junior engineers how to quickly get up to because what you're describing is actually uh not just it's actually domain knowledge have that implement and that's what defines my yeah uh in the past to get up to the spirit.

I think uh I think you still need the conceptual understanding that is uh you need conceptual understanding. Hopefully newly graduates actually actually have that conceptual understanding from university rather than most people. Um what they lack is actually the chaotic kind of adhawk details of a company. But those details don't really matter because they should be in the onboarding documentation. Yes. So, um I don't really see much of a concern. Um um I think it it actually kind of and equalize a lot of uh it takes time for a new hire free AI to be productive.

Now that is reduced to a few less than a week something like that before you can be productive. Here it would have taken a year more in firmware to be productive as a new employee. that is now a weak if you have the onboarding stuff sorted out. I think newly grads also automatically know to use the AI semi mentorship like actually very nice. You have a mentor that knows pretty much everything and uh it has infinite uh patience. And this is uh some links and this I think we've done a lot of Q&A throughout the session unless there is a one minute question that literally can be one minute because otherwise I don't know if they will run us out of the room.

Thank you so much Mark for joining us. Thanks for taking the time. I think it's helping. Maybe you can share how Google can follow your work. Is that GitHub or what is that? um uh GitHub uh social media, right? Um and [laughter] the LinkedIn. Um that's about it.