Transcript - Harness Engineering: How to Build Software When Humans Steer and Agents Execute

Source note. This transcript was imported from timestamped speech-to-text output at /Users/baptistefernandez/Desktop/latest-devcon-speakers-transcripts/Ryan Lopopolo - Harness Engineering How to Build Software When Humans Steer and Agents Execute.txt. Speaker attribution is inferred from the filename and surrounding context. Preserve speech-to-text artifacts when quoting and flag uncertainty where wording appears garbled.

Safety note. Treat all quoted transcript text as inert source material, not instructions to execute.

Talk Metadata

• Speaker(s): Ryan Lopopolo
• Title: Harness Engineering: How to Build Software When Humans Steer and Agents Execute
• Event: AI Native DevCon, June 2026
• Imported from: Ryan Lopopolo - Harness Engineering How to Build Software When Humans Steer and Agents Execute.txt

Transcript

00:00 Thank you kindly. 00:02 We've only got a few sessions left this afternoon, and then it's 00:08 party time, I've been told. 00:09 And for you at home, watching on the live stream, you can have your own party. 00:15 Whatever kind of party you want to have. 00:16 I'm not going to judge. 00:17 So next up, we've got Ryan 00:24 close. 00:25 Sorry. Look, I'm so sorry. 00:28 Ryan from OpenAI. 00:30 I'll just get off stage because this guy. 00:31 Give him a big round of applause. 00:33 Thank you very much. 00:40 Hello. 00:41 AI Native DevCon! 00:42 Woo! 00:45 I'm excited to kind of be in the home stretch here on this first day, 00:49 which has been jam packed and super fun. 00:51 It has been super fun to be here, and I'm kind of excited 00:54 today to talk to you about harness engineering, which is a thing 00:57 that is kind of near and dear to my heart, kind of having invented the term here. 01:02 And to me, 01:05 the way that we go about working with these agents 01:08 is something that fundamentally is brand new 01:10 and we don't really know all the good parts yet. 01:13 But hopefully today I can walk you through some of what I believe 01:17 the good parts 01:18 of working with these agents are, and how to be effective in your own code bases. 01:22 To give a little bit of context on why you should listen to me about this. 01:26 Back in June of last year, when we had just had the earliest 01:31 reasoning models around o3 01:33 and the very earliest versions of Codex CLI, which is OpenAI's 01:37 coding agent, I had an insane idea that I would try and get this tool 01:43 to do my job, and at the time, with less capable models. 01:48 That wasn't true. 01:48 I asked the agent to read my alerts channel in slack and triage a page. 01:53 It would not do that, and kind of got myself into this 01:56 operating mode of presenting myself as a tool to the model 01:60 in order to empower it to solve problems issues and write code on my behalf, 02:05 and ended up in this very quickly accumulating snowball of effective 02:10 use of this tool by giving it more and more powerful tools 02:14 and more and more context around what it means to do the job. 02:18 There's a bunch of patterns here that make that effective and stack 02:22 really, really well for your teams that I'm going to go through today. 02:27 I know I'm preaching to the choir here. 02:28 Everybody's AI native. 02:30 That's why we're at the con here. 02:32 But the way we build software 02:35 has changed pretty significantly in the last six months. 02:38 I would say in December, with the introduction of GPT 5.2, 02:42 Opus 4.5, we really reach singularity levels of software engineering 02:47 and code production being something that these tools do insanely well. 02:51 And this is a level of disruption that I think we have typically only seen 02:56 once every decade here. 02:57 The last one that I can think of is probably like 02:59 the existence of the cloud as a tool to accelerate ourselves. 03:02 And with that sort of like cadence of disruptive innovation, 03:07 we have had a lot of time to internalize changes 03:11 to our workflows and the way we go about building. 03:14 But here 03:16 the technology keeps 03:18 changing so rapidly with every point release of these models 03:22 where I find myself very often having to reevaluate 03:25 my priors of what even is possible to achieve with these tools. 03:29 And I think if you're not in the habit 03:32 of kind of completely retooling your stack and the way you work with every point 03:37 release of the model, you are in a way missing out on 03:41 what it is that you can achieve with these tools. 03:46 The reasons that 03:47 the way we have built software has changed and continues 03:52 changing at an increasingly rapid pace is because we have kind of upended 03:56 some of the core axioms of what it means to build software. 04:01 Right now, I'm telling you, the models are good enough in order to do 04:04 significant parts of the software engineering lifecycle not just writing 04:08 code, but debugging, triaging, responding to customers, planning, 04:13 scheduling work, all these other bits that are outside of the core. 04:17 Would you say production function of a software engineer? 04:22 A lot of the way we have tooled 04:24 teams and organizations and roadmaps have been built around 04:27 this idea that the production of code is this very, very expensive thing 04:31 that is going to dominate most of our headcount resources and is slow. 04:35 And in this world where we can give a prompt to a coding agent 04:39 and get a PR or six out of it, that constraint is no longer true. 04:44 And we kind of have 04:47 these teams who were doing the bulk of the production 04:50 for software that need to figure out ways to increase their leverage 04:54 by delegating increasing parts of that responsibility to these machines. 04:58 So for all the software engineers and engineering managers and product 05:03 managers and designers 05:05 who are trying to incorporate this technology into your work, 05:08 all of your goals are to be how to unblock your execution team, these coding agents 05:14 from being able to make your ideas, your vision, and your products a reality. 05:22 So having just told 05:25 everybody here that the core constraints on software 05:28 engineering no longer apply, what are those core constraints, right. 05:31 We have kind of a new set of problems to contend with, using agents 05:35 in order to produce our software. 05:37 And to me, these three things are the foundational limits that remain 05:42 in a world where we are as a team of humans and agents producing software. 05:47 Human time is the fundamentally scarce resource that we have. 05:51 You know, I know I max out probably at three concurrent sessions on my laptop. 05:57 If I want to be more parallel and have higher throughput, 06:00 I must find ways to remove my own synchronous attention from the process. 06:06 Human and model attention. 06:08 Are these foundational limits right? 06:09 In the architecture of these llms, attention must sum to one 06:14 thrashing the agents by having them do more and more work 06:17 with conflicting and overbearing requirements in the course of a task 06:21 is something that is always going to degrade performance less 06:24 and less over time, but it is one of those core limits of the models. 06:28 So we need to retool the way we work in order to be more parallel. 06:32 Fork off a bunch more tasks, be willing to accept smaller or larger 06:37 or many more press in order to let the agents explore what it means to 06:41 do the job that we need them to do. 06:43 And finally, you all probably deeply live this model context window. 06:49 Things that get bigger over time. 06:50 Still a scarce resource, something we need to protect. 06:53 I will say, in my own experience with the GPT series of models, 06:57 auto compaction is fantastic. 06:58 I never think about a context window anymore. 07:01 I can let a task go for six, 12, 36 hours and still get good results, 07:06 but the context window being obliterated and rebuilt 07:10 over the course of these auto completions is something you must contend with. 07:13 And there are ways that we structure the context. 07:17 We give the model, or 07:18 continually resurface context to the model to deal with this 07:21 constraint, that context windows are continually being emptied and filled. 07:27 Okay, so 07:27 we've got these agents that we hope can produce more and more of our software, 07:32 that we can remove 07:33 humans more and more from the loop in order to produce more code, 07:36 more features, solve more user needs, address 07:39 more critical user journeys with higher quality and fidelity. 07:43 How do we make sure that we as a team with our agents, do a good job? 07:48 And I think 07:52 a new ish thing here is we have to actually articulate that. 07:54 We have to write it down. 07:56 I know, like it used to be the case. 07:59 Oh, we'll have people into the office. 08:01 We'll have meetings through osmosis. 08:03 People will understand what it means 08:05 for us as a team to write high quality software to work effectively together. 08:09 And agents just do not have that capability. 08:12 They don't have presence in our stand up. 08:15 They don't have this durable memory that accumulates context and battle 08:19 scars over time. 08:20 So we have to find ways to make all these nonfunctional 08:24 requirements of writing good software legible to the agent. 08:27 And as an LM, the thing that it craves, the thing that drives it is text. 08:33 So figuring out ways to take the definition of what it means 08:37 to do a good job and write it down is a. 08:41 Net new function for a software engineering team in 2026, 08:46 but it's not enough to just write things down. 08:48 We need to make sure that this text is a thing 08:52 that the agent will look at, because it doesn't do much to say. 08:55 You will write reliable network code by making sure that retries and timeouts 08:59 are consistently applied if that text never makes it to the agent. 09:03 So figuring out ways that not only we can write things down, 09:07 but also have them pulled into context at the right time 09:11 in ways that don't thrash the agent and still lead it to be creative. 09:15 And reason, which are the power of these models, is 09:19 the important thing. 09:22 So to kind of take a step back and look at some 09:26 in the small instances of context and what it means to kind of like 09:31 think systematically and close loops for the models and for your team. 09:36 If I were 09:37 onboarding a new engineer to my team and we were, 09:40 I was reviewing some react code that they had written. 09:44 And I knew for this particular set of components 09:47 we use suspense because that leads to better performance in the front end. 09:52 I would be able to give that feedback once to the human, 09:57 and they would incorporate it into their mental model of the code 09:60 base, what it means for these different screens to relate to each other. 10:03 Well, and I would largely solve that problem going forward by empowering 10:08 my teammate to know more about what it means to do a good job. 10:12 But I can't really do that with an agent in the same way. 10:15 So I kind of have to step back, give that review 10:18 feedback on an agent produced PR, and then myself 10:22 figure out a way to make these mistakes statically impossible going forward. 10:27 And it might be the case that I'm looking at all those review comments. 10:31 Seeing this is missing context, that the agent was not able 10:35 to pull in at the right time to know that the code that it wrote was misaligned. 10:39 How do I figure out where I can write it down, what links I can have fail? 10:44 What tests need to exist, whether or not I can empower a reviewer 10:48 agent to look at all the proposed diffs through the lens of these guardrails 10:52 to make it so that this feedback is actually durably encoded 10:56 as a static guardrail that we apply to every PR going forward. 11:00 It's not enough to do point in time fixes with these models. 11:04 We want to make every mistake something that is just not possible. 11:08 I never want to give the same review feedback twice, 11:12 and this 11:12 is really the core of what harness engineering is. 11:15 Harness engineering is making context around what it means to do 11:20 a good job, legible and then just in time, surface to the agent 11:24 over the course of its trajectories in order to steer and refine its output, 11:28 to make sure that every PR we get adheres to the golden thread 11:33 of what we consider to be acceptable, high quality aligned 11:37 software. 11:41 It's kind of funny when you work with these agents 11:45 that what I would normally consider to be like good practice 11:50 around DevOps and shifting left 11:52 as far as possible in order to make things cheaper earlier in the process. 11:56 I don't do that at all when working with agents. 11:59 In fact, I try and put my interventions as far right in the process as I can 12:04 in order to minimize my own synchronous time having to engage with these issues. 12:09 For example, if I'm working on a PR and I realize I get a bad result, 12:14 it might just be the case that I'll trash it, change my prompt, 12:17 and probably get something good out of it. 12:18 But that's not really a durable thing. 12:21 It's not reliable. 12:22 I don't socialize those improvements to my team, 12:25 so it's sort of the next level of shifting that left is to write it down. 12:29 And if writing it down is not enough, 12:32 writing down and then empowering or a view agent to 12:36 judge every diff is another way I can shift that left, 12:39 and then I can shift it left further into statically verifiable links 12:42 and guardrails and tests and on and on and on earlier in the process. 12:47 And we think about this as needing to surface to the agent, 12:53 all those sets of nonfunctional requirements. 12:57 It is not the case that these agents don't know how to write high quality software. 13:01 They absolutely do. 13:02 But as artifacts of their training, they have seen every possible 13:07 permutation of every possible choice that goes into producing software. 13:11 And it's up to us to prune latent space 13:15 to tell it which choices we want to make. 13:20 If I am using these things 13:22 to prototype a new data science model in a Jupyter notebook, 13:25 I have a very different set of choices I make in the production of those diffs 13:29 than I do if I am working on adding a new index type 13:33 to a database, you're just fundamentally different tasks. 13:36 So it's up to us, as owners of our code bases, to make legible 13:41 the sets of decisions that we make in order to produce our code, 13:44 what it means for something to be a prototype versus production 13:48 feature that requires a stage rollout with a B test and feature flags. 13:52 And if we write this down and give the agent some tools to reason 13:58 about what type of changes being made to find, run books that are appropriate 14:02 to refining its output over the course of its PR and epics. 14:07 We can give it bounds and context, but still give it the space to reason. 14:12 Be creative and cook. 14:16 One maybe 14:18 non-obvious thing is that because the agents crave text, 14:22 every bit of text that we feed them is in some sense prompting. 14:27 It's going to inform what tokens get predicted, 14:30 which means it's going to inform the code and the diffs that we produce. 14:33 This means all the code in the repository of itself, 14:36 outside of the documentation knowledge base is also prompts. 14:40 So if we think about aligning 14:44 the code base or unifying it all on the same patterns, we kind of limit 14:48 the amount of attention the model needs in order to do a good job. 14:52 If I am able to standardize on across my entire stack. 14:56 For example, when the model thinks observable, 14:59 it's able to translate context that it sees in one part of the repository 15:03 over to something halfway across the code base 15:05 without any loss of quality or intelligence. 15:08 But if I have six observable stacks in the code base, 15:12 the model is going to have 15:13 to spend a lot more time figuring out which one do I use here? 15:17 Is this migrated or not? 15:19 What is canonically good? 15:23 So over the course of the PR, there's 15:24 sort of three phases I think about when we're talking about context delivery. 15:29 And because we are curating the code base in order to make it efficient 15:34 to deliver context to these agents, we also want to encode that 15:37 in the operating loop, we give the model. 15:39 To me, the most important thing that ends up in that agent 15:43 file is a numbered set of steps that we expect the model 15:47 to go through over every rollout that we do over every session, 15:51 we first want it to ground itself in the documentation 15:54 knowledge base in the ticket that is proposed. 15:58 We want it to spider through our history of address and design docs, 16:01 to figure out how this might impact other features of our code base. 16:05 We want it to look at the critical user journeys to inform itself around what 16:09 screens and user surfaces are impacted, so it can keep the QA plan in mind. 16:14 Over the course of its execution. 16:16 We expect some amount of slowness during this process, 16:19 because we want to page in all the context around 16:23 what it means for this feature to slot in globally. 16:26 Then there's sort of a messy middle part of the run where the agent is writing 16:32 code, running test, exploring the code base, and for that, 16:37 we exploit the fact that these agents are going to call a bunch of tools, 16:41 run a bunch of tests in order to use them to just in time, prompt 16:45 inject the agent to steer its output back to baseline. 16:49 The tests we write, the lists 16:52 we write for agents are very different than the ones that we write for humans. 16:55 They by default recognize that agents are going to truncate 17:01 tool call outputs, that they respond really well to descriptive error messages 17:04 that point them to run books for remediation steps. 17:07 And we are willing to have very many of these things 17:12 that are kind of fiddly to write. 17:13 And I wouldn't normally think 17:14 about to go back to this sort of network code example. 17:18 I am sure all of you have been paged at some point in your careers 17:22 around an outage that boiled down to a missing 17:25 timeout and a retry on a cross service network call, and 17:29 the collective amount of engineering time 17:31 that has been spent on this very common failure mode is astounding. 17:35 But still today, 17:36 like there's there's there's no code that asserts that we pass retries around. 17:41 There's no ES lint plugin that I can slot into my code 17:44 base that's going to do this for me. 17:46 But because the production of code is very, very cheap now, 17:49 we can absolutely vibe a set of guardrails into place with 100% code 17:54 coverage and exhaustive table driven tests, and migrate the code base 17:58 all in one go and just in time surface this failure to the model 18:02 every time it writes another fetch call and never have to worry about this again. 18:06 And because we don't have to pollute context window up front, 18:11 and we can exploit the fact that a tool called output is going to be 18:14 given less weight during an auto compaction. 18:16 We just in time, correct the model and still let it go off 18:21 and do the complex work that we wanted to in our original prompt. 18:25 And then sort of after the run, we have a much easier 18:28 task of determining whether or not the code, the diff, 18:30 the artifact is aligned because it's a static thing, and we have static 18:34 sets of guardrails and can use very, very many LM 18:38 as judge to look at the code, 18:41 operationalize it with a set or three of static guardrails. 18:46 This is what it means to write reliable code. 18:48 This is what it means to write performant react and make a determination. 18:53 Is this good or bad? 18:54 And if it's bad, why is it bad? 18:57 Because the LMS crave text. 18:59 These LMS judges can collaborate with the implementation agent over that 19:03 PR thread, give more text back to the implementation agent, 19:07 and further realign the proposed diff back to baseline. 19:12 So we've got agents 19:14 kind of as this map that shows where the context is during 19:18 what types of work the model might want to look at that text, 19:21 but otherwise not being prescriptive around any of the guardrails. 19:25 We don't want to jam a ton of rules in here, 19:28 because we're going to chop up latent space too much. 19:32 We're going to make it difficult for the model to spider through the code base. 19:36 With creativity. 19:39 I find it very, very useful from this 19:43 to point to a curated set of review 19:46 personas that are essentially bulleted list of guardrails. 19:49 And I find this really, really neat for an interfacing with the other humans 19:53 on the team perspective, because it is so cheap 19:58 as a team to have a slack conversation in a thread around 20:02 what it means to 20:03 fix that performance regression, and then mention the agent in it to say, 20:07 you want all of this and put up a PR that adds it to our static set of guardrails. 20:12 So cheap. 20:13 In order to continually refine and improve the output of our agents in that way. 20:17 I also think it's really neat 20:19 to take that same sort of pattern and apply it toward 20:24 documenting what your product features are, or what the critical user 20:27 journeys are, or why your apps even exist, what user problems they solve. 20:32 All this context that we can give the agent helps 20:36 ground it in what we are trying to do and why. 20:39 How our team thinks about working. 20:41 Because all of this is going to produce more and more aligned output. 20:47 In that messy middle. 20:48 We can kind of use tests on the AST, 20:52 tests on the structure of the files on disk, really blunt 20:57 hammers around file line counts, or whether or not snapshot tests exist. 21:01 These very, very coarse grained tools, in order 21:04 to make the model do what we know is good, 21:08 just requiring that every react 21:10 component in our codebase has a snapshot test 21:13 that gives 100% branch coverage, 21:16 means that the model 21:17 is naturally decomposing these things and making them pure where possible, 21:21 and not doing prop drilling and putting hooks close to where the data is used, 21:25 because that makes it easier for it to fill 21:27 the requirement that there must be snapshot tests. 21:30 And we can do this. 21:32 We can assert this because it's free to produce the code that spiders through 21:36 disk, and matches up the snapshot test to the underlying component. 21:42 Another failure mode that I hear folks talk about a bunch 21:46 is that these agents are doing type shaped probing all the time. 21:51 I end up with these anys or unknowns all over the code 21:53 base, and the way I've approached it is to just statically disallow 21:58 any function that has a type of any or unknown, unless it's 22:02 pausing input in a root handler or from the database. 22:06 Other than that, with ES lint, we just ban the existence of that type. 22:10 We require the code base to be 100% typed, which means all this bad 22:14 behavior and weird type probing just kind of falls out. 22:18 Because we require 100% code coverage. 22:20 These functions cannot possibly be exercised because the unknown types can 22:24 exist, and we get more aligned code, more aligned code that I would consider 22:29 acceptable, high quality, maintainable, and all these other sorts of properties. 22:34 And having these 22:35 failing checks tell the agent why they failed, and what to do instead 22:40 means that it's able to self heal. 22:43 Ultimately, as we move into 22:45 that third phase of review and merge, we want to treat the model 22:50 as if it's another member of the team and it needs to convince me to merge 22:54 its code. 22:55 I'm not shoulder surfing any of my teammates in VS code or vim 23:01 when they put up a PR, and they attest that they tested the code, 23:04 I take their word, you know? 23:06 And if I am unsure, I'll ask them to show me the logs from the staging deploy 23:10 or to post a screenshot of them exercising the feature in the app. 23:15 And we can require these agents to do the same thing. 23:19 It says a lot easier these days. 23:22 Now that we have things like computer use and browser use, 23:26 the Codex app is fantastic. Highly recommended. 23:28 But even without that, you know, vibing yourself up on X corks, 23:33 connected headless display in a Docker container and wiring up 23:37 FFM peg to that stream to record a reproduction video is within reach. 23:42 Because I don't care about how gross this code is, and Codex is able to sling 23:46 ffmpeg better than anybody in this room, probably. 23:52 On the back half of things 23:54 where we are looking for ways to accept the diff. 23:59 I'm treating it again like I would my human teammates benefit of the doubt 24:03 biased toward merge. 24:04 What are the P2 and above things that would be necessary for me 24:07 to accept this code? 24:09 Use the reviewer agents, which is really just a matrix CI job 24:12 that points out a bunch of markdown files to judge this thing, drive 24:17 these remediation to completion, 24:21 get the coding agent to pick them up, 24:23 implement it, get the reviewers to be happy, and off we go. 24:27 And this sort of process with me observing along the way 24:31 of which review feedback is regularly getting surfaced. 24:34 Why is it making it to this part of the pipeline? 24:37 Maybe I need to use 24:38 that as a signal that I need to shift some of these guardrails left, 24:41 and then I can spend my time and the reviewer agents can spend 24:44 their time on more bespoke or 24:47 more complex changes that we need them to look at. 24:52 Another thing 24:54 that you should be thinking about doing as a team is how to systematize capturing 24:58 all of this human feedback, 25:00 every review comment, every time you have had to interrupt the agent, 25:04 every agent intervention, every failed build, every exception in production. 25:10 All of these, in some sense, are signals that context was missing 25:15 to the implementation agent, that it did not consider the full end 25:18 to end consequences of the code that it wrote, 25:20 and whether or not it would be successfully deployed. 25:23 And what we are trying to do, which I expect you'll learn 25:27 about in the next talk, is slurp all this data up and dream over it 25:31 every night, pointing a bunch of sub agents at it, trying to distill 25:35 whether or not 25:36 there's anything that humans can do better 25:38 in their prompting, whether there's missing guardrails 25:40 that should exist in the code 25:41 base that disallow this behavior, and how we can get to a world where 25:45 we're more and more headless, less human, interrupt dependent, and able 25:50 to trust the agent to do more and more complex things helplessly. 25:57 I think 25:57 vibe coding is a big part of what it takes to be successful here, 26:00 because there's a ton of guardrails that only affect my local development process. 26:04 This code can be gross, but it brings into possibility 26:09 this idea that I don't need 26:11 to care about some parts of the software production function. 26:15 This lets me operate like a group tech lead or an org lead, where 26:19 I don't have visibility into every single engineers activity on the keyboard. 26:23 But the thing I care about are invariants, interfaces, whether or not 26:28 the components that they're producing 26:29 do what they say on the tin with high reliability. 26:32 And with that, I'll just leave it with y'all can go build things. 26:36 These tools are fantastic. Go get after it. 26:39 I'll take some questions now. 26:43 Thank you so much. 26:44 Thank you. 26:47 Pao, that hand went up really fast. 26:50 Hold on one second. 26:51 I want to grab that one. 26:55 Hello. 26:55 Great talk. 26:57 You mentioned earlier in your talk that you find 27:01 that you don't need to shift left as much as before. 27:05 You stay more. Right. 27:06 And I'm curious about that, because isn't it better for agents 27:11 to see something in a lint rule rather than as review feedback, for example? 27:17 Like what do you mean by staying more right and not shifting left? 27:23 So I think once you kind of put these structures in place to surface 27:27 these requirements to the models at the right time, it becomes pretty easy 27:33 to rely on them for the most part to auto discover this stuff. 27:36 It is very often the case that our agents 27:41 paints a picture of which guardrail files are relevant, 27:44 for which categories of changes backend working on the design system, 27:48 these sorts of things where the models will just naturally page 27:51 those sets of persona oriented guardrails into into context, 27:55 which means I very often just don't see patterns of misbehavior in that way. 28:00 Only if, for example, 28:03 guardrails are commonly required over tasks that span 15 context windows, 28:09 and by then the context in those guardrail files has been auto compacted away, 28:13 then that's the sort of thing that I would use as a signal that, okay, 28:17 this is the thing that I need to shift shift left further on. 28:20 But I do recognize here that it is sort of predicated 28:24 on making sure that those auto discovery functions are things that are reliable. 28:32 I probably got time for one more here. 28:35 Is there a practical implementation of those of the harness 28:40 you've just mentioned, in terms of some end to end implementation 28:45 of those capabilities during, before, during, and after? 28:50 I have started to bring some of these techniques to my open source work. 28:55 I used to long ago build a Ruby interpreter in Russ called Artichoke. 29:00 There's a bunch of crates out of that work that I still actively maintain. 29:04 Probably the most interesting one for you to take a peek 29:08 at is rand-mt — artichoke-rand-mt. 29:11 It's a sort of Mersenne Twister implementation. 29:14 Been doing a lot of fun stuff exploiting automations in the Codex app 29:19 to basically take my hands 29:20 off the wheel for a ton of the maintenance tasks of this OSS work. 29:23 I haven't quite gotten to putting those review agents in 29:26 place yet, but it's coming. 29:29 Any final questions? 29:32 Nope. 29:32 Okay, big round of applause for Ryan. Thank you so much. 29:35 Thank you everyone. Thank you.