人間は今、何をするのか？ AIエージェント時代のソフトウェアエンジニアリングを再考する

Hello and welcome to the Data Engineering Podcast, the show about modern data management. Your host is Tobias Macy, and today I'm interviewing Jonathan Ellis about how to make the best use of human time when agents are building the software. So, Jonathan, can you start by introducing yourself? Absolutely. I'm Jonathan Ellis. I started DataStax 15 years ago to commercialize Apache Cassandra, spent a long time in the space of distributed databases and the JVM, and now I'm running a small AI startup called Brock AI, where I'm doing either of those things and writing native code in Rust through agents. And do you remember how you first got started working in the ML and AI space? basically uh well so i guess to back way way up i've always been attracted to the idea that

as engineers we should be comfortable building our own tools and automating our own jobs and making ourselves more productive which is a philosophy that goes all the way back to you know richard stallman and emacs and the people before him so one of the coolest things for me is that is how AI unlocks that. Whereas five years ago, I would have said, oh man, like I'm spending my time in IntelliJ and it's, what is it, five million lines of code? Like it's a ridiculously large project, very intimidating to make contributions to. And now I can say, hey, I really wish this feature existed in IntelliJ. Go and code dive it, figure it out, come back. Usually, I think, and this comes back to our topic today, I don't think the right approach is to say just go build this, but rather come back to me and give me the top three options and let's discuss the pros and cons and go from there.

But any tool that I use day to day now, I can enhance and extend using AI in a way that wouldn't have made sense from a time investment perspective before the advent of Gen.AI. And so Brock is basically an extension of that where I said, hey, there's a bunch of tools that I think should exist and nobody's building them, so I'm going to go build them. Yeah, it's definitely pretty remarkable the unlock that has happened because of the speed at which you can go from idea to delivery or at least prototype. and the ways that that manifests in terms of an organizational context where you're working in a professional engineering team can have a lot of knock-on effects in terms of what people are doing and how they spend their time, particularly if the engineering team predates the past two years. So people who have built up a certain set of workflows and expectations largely around code review,

which is part of what we're here to talk about. And so because of the fact that writing the code itself is no longer the bottleneck that shifts the bottlenecks everywhere else, and I'm wondering how you're seeing that impact the ways that engineering teams think about their job and the work that they do. Yeah, and I think this is a place where collectively as an industry, we have more questions than answers. And, you know, I certainly have opinions, and I think we're starting to stumble towards some of those answers. But really, I think what happened and how we got here is, at first, AI was accelerating the act of creating code, you know, incrementally more and more with every new model released. But everyone was still just kind of slotting that into the existing teams and processes. is, and it's like, oh, great, Jonathan's faster at writing code than he used to be. That's great, and we don't need to change anything else except maybe he tackles, he

goes through the backlog faster. But now we're starting to see, as we've gone from, oh, it makes code 50% faster, or it makes it 100% faster, or 200% faster, now it really is 10x faster now, and it's still getting even faster still because as the new models come out now, the number of tokens per second they're generating hasn't gotten faster for the most part. There's some exceptions. But the task size that I can give it, that's what's changed. So I can have 12 tasks going now with Fable, and they're each taking multiple hours, sometimes multiple days. And that's what accelerates the pace of code generation now is being able to parallelize that with less oversight, not zero oversight, but with less oversight. And so that's what's just completely broken that old paradigm of we're just going to keep using these human oriented tools and human oriented processes. And so what comes after that? What comes now that

code is 10 times faster than it was, how do we fit the rest of the software development lifecycle around that new reality? And we can kick it off or we can set more stage if you want, but one of the first things to go, I believe, is the concept of humans spending time reading through diffs and doing code review the way we did three years ago, even one year ago, because that's just not a good use of time. And I can flesh out my thesis a little bit more, or you can jump in first. Yeah. So just as a quick reference for listeners, you wrote this blog post about the fact that it's time to stop performing code review. I'll add a link in the show notes. And I think that one of the other interesting elements of this point in time is that particularly for people who have been in the industry for more than two or three years, they have developed a certain amount

of their identity and ego around the code that they write and the way that they approach code and their various competing camps of what constitutes best practice or idiomatic practices for different languages or frameworks or ecosystems. And so one of the points of contention that I've seen in my own experience is people saying, well, the code that the AI is writing isn't the way that I would have written it, so therefore it's not good. Or it's ignoring this idiom that I have spent a lot of time perfecting, where maybe instead of using a bunch of if-then blocks, I put it into a dictionary so that it's more of a direct access, or maybe I prefer a more functional style versus imperative style. And so there's a lot of these details that at the end of the day really don't matter, except for the case where maybe they have a performance impact. and so that I think is another piece where the human element of engineering is coming under fire

by the AI because you have to just let go of that fact of okay well maybe I didn't even read the code as long as the code does what I want it to do that's the thing I care about the most and you know there's the trope that nobody's paying for the software they're paying for what the software does. And so why do we as engineers spend so much of our time bike shedding or yak shaving about the way that you write your for loop versus does it do the thing that the customer actually wants? I think that's an excellent point. And it highlights one of the gaps or the differences in approaches that I've seen in the talented engineers that I've worked with when it comes to AI because I think it's much easier to come to terms with the things that you're talking about for people who have managed or led a team of human engineers because it's to some degree, like there's differences for sure. And I'm definitely not saying that managing a team of

AI agents is the same as managing a human team because it's not. But it is similar in this one respect, which is that if you have a team of human engineers and your code reviews take the form of saying, you know, I disagree with how you wrote this switch statement instead of putting it in a dictionary and matching on that, like that's not productive use of code review time. And it just isn't. And so I think that people who have been in the position of running those teams have gone through that adjustment of coming to terms with whether the code is functionally correct is more important than whether it follows the idioms that are my preferred weapons of choice. the other way that I've seen this framed a lot in various blog posts and conversations in the community is that people are no longer just individual contributors everybody has to become

a manager but instead of managing people they're managing agents and so you really need to bring your level of abstraction up to the point of the product or the feature and not the lines of code or the modules. And I think that one way that I've seen this play out is that teams who do have a strong culture of doing RFCs and architecture decision records as the initial step along the path of actually getting to that feature delivery are better situated to take advantage of the current landscape that we're in. Because once you have that RFC or the ADR or the spec that details this is the thing that we actually want to build, then the implementation becomes automatic because the agent has that shared agreed upon context. And I think that the point of review just needs to shift earlier in the process where you need to get more people involved in that design and debate of what is the thing that we're actually trying to build and why

versus how. And so as long as the code that lands can be tied back to and validated against the original design document, then the human review on the code doesn't need to happen as you just need to be able to have a way of doing that validation to show that it aligns with the stated goals? Two thoughts about that. So first on the general direction, we're all product managers now, right? We're all, or I think that we're being pushed in the direction where the value we add as humans is less on how do we implement this decision versus what decisions should we make? What is important to implement next? And so I think that developers who worked in an organization where there was a very stark line between those two groups and the engineers just implemented what another team was handing down as the decisions,

I think that's going to be – the time where that's a useful use of human time is drawing to a close. It's not completely gone, but it's limited. And there's a line of sight to where it's like, yeah, you leave that to the agents. That's just what you do. So I think that teams that already had more of a porous boundary between engineer and product manager and, you know, the product managers are now implementing proof of concepts with their own agents, and the engineers are participating in design discussions, I think that's a much healthier place, and they're going to adapt a lot better. So spending a bit more time on the review, validation, and delivery phase of the software lifecycle, there has been a lot of stake put in the role of the human in that where,

oh, you need to have a human looking at the code before it can go to production, because the humans are the ones that know whether it's going to work or not or have that broader context, which even before AI increased the volume of code wasn't always true, because if you have somebody do a code review who hasn't worked in that code base before, that's not going to be very helpful unless the purpose is purely for educating them on what that code is doing and how. But even if you have somebody who is expert in that particular code base, they're liable to miss things, or if they are the expert in the code base, they're likely already busy with their own implementation and don't want to have to spend those extra cycles on the code review. But there's still the element of some sort of validation and guardrails need to happen so that we can have confidence in the code as it is written before we put it into production because we don't want to be dealing with constant firefighting due to buggy and broken code. And so I'm curious how you're seeing teams address that angle of what are those checks and guardrails that we need to put in place so that we can confidently remove humans from that phase of the life cycle.

so this is where that article that i wrote that you mentioned was becomes controversial because for reasons that i don't completely understand when i say like i did just now uh you know a year from now or two years from now humans just won't be writing code by hand anymore most people look at the curve that we've been riding for the last two years and say, yeah, I can see how if I draw that line out a little bit more, that's probably what's going to happen. But then when I say, and you shouldn't be reviewing it either, and then they're like, oh, like just heads exploding. People feel very, very strongly that, like you said, code should not be pushed to production without a human reading at first. And part of the research that I did for that article was looking at, like, if you actually study this and measure it, how many defects does human code

review find? And the answer is typically about 30% of the defects. And, you know, if it's a more complicated problem domain, like security, it's more like 20%. So humans aren't really good at doing code review from a standpoint of, is this, am I finding the defaults, the defects? And so I think the reason why people have that reaction of, oh, I couldn't even dream of pushing this without a human review, is that we all have memories of the times where we did find a defect. And so this is part of like, you know, our human ape brains are not evolved to be statistically literate. They're really good at remembering exciting things that happened once or twice, but really bad at estimating, like, was this a good use of time to find those defects given all

the other times that I did review and didn't find defects? So my standpoint is not that code review doesn't add value. I'm not saying that because like I said, I can remember times I found bugs as much as anyone can. But my standpoint is that the time invested to find those defects is no longer worth it and should be spent. There are higher value ways to spend that time now. Even if I'm saying I need to spend 30% of my time or 50% or 80% of my time doing quality assurance or in the literal sense of the word that I'm assuring the quality of the code, that it does what it's supposed to do, whatever number of time you think you should be spending on that class of problem, there better options than reading the code by hand Yeah just anecdotally I call out that I actually got at least one production system It not customer facing but it is team facing that I written entirely by AI and haven

read possibly any of the code. And it's been very useful and helpful. So it's actually a project that manages the team memories and task and project graphs for coding agents so that it's a shared flat graph that everybody can access and read and write to for being able to break down the context into chunks so that you don't have to have one session that runs for three days because you don't want to lose all the stuff that you put in at the beginning and also be able to have the memory be compatible across different agent harnesses rather than just a random markdown file somewhere on your disk that you hope doesn't disappear sometime. And I've also bypassed a lot of the human review element of it as well because it works. I use it. I make changes. I make sure that the changes do what I want them to do, and then I ship it. Exactly. Yeah. And I think that's kind of like the easy case, right? And I don't mean that disparagingly, but in the sense that if I'm building an internal tool for a small audience where, you know, the world doesn't end if there's a bug, then, yeah, just ship it and use it and fix problems when you find them.

And then the more interesting question is, how do you do that in a situation where the world doesn't when you ship a bug? Or there's potentially very bad consequences if you ship buggy code. And then how do we do that now? and I think that a healthy way to start that discussion is from what I just said that actually you weren't catching all of the bugs by reading the code before anyway and therefore what does that imply for what we should be doing with that time that we're no longer spending reading the code and I think that one of the ways that we can spend that time is by getting the agent to help with building those quality gates and validation loops so that you can catch those errors early and often, preferably even before it gets to a PR, where I think maybe that ties us

into some of the work that you're doing, where I know that the Bifrost tool is a linter and MCP server that gives a more comprehensive view of the code structure so the agent can have that insight rather than having to rely on a thousand grep calls to find a particular symbol. And so be interested in hearing some of what you're investing time in on that angle and also some of the other ways that you're seeing teams use the accelerated pace of delivery to put more of that work into the CI systems and guardrails and validation cycles that we should have been building all along, but deprioritized because it took too much time off of the actual product that we were trying to ship. Yeah. So as you said, I'm building a tool called Bifrost that is the way I think of it is it's basically Coverity, which is a static analysis tool that's been around since, man, I want to say like 1996.

Like it's pretty old, but it's also it's really powerful and it's really slow and it's really difficult to extend. But what it can do is find things like a use-after-free, or it can find certain classes of concurrency deadlocks by analyzing the flow of data through your program. And so I want to bring that caliber of deterministic analysis into agent harnesses, where it's not like, let's push this and let CI crank on it for a couple hours and see what it comes back with, but rather the agent makes a tool call that says, you know, run the use after free checks, and it gets back an answer in milliseconds instead of minutes or hours. And so to do that, to make Bifrost itself, so we're tackling 13 languages at once. And I think there's other tools out there, but I think we're probably the first one to try to do so many languages all at once.

And obviously, AI makes that possible with the word parallelization that I mentioned. But guaranteeing correctness is actually still really hard. There's so many corner cases when you have so many languages that you're dealing with. And so the big technique or like the big idea that I orient my thinking around is I gave a talk not long ago where I talked about you should be trying to build an oracle for your agents. And you should use agents to build that oracle. And, of course, an oracle is a term from AI engineering where we're talking about something that knows the right answer for a certain class of problem. And it's usually because we've constructed the problem in such a way that we know the answer up front or we can derive the answer much more easily than we can in the fully general problem space. And so categories of tools that the QA engineering space knows about include things like fuzz testing, includes things like property checkers.

And so we've built for Bifrost all of those things, and we use that to let the agents triage the bugs they find. So that's the other thing that agents unlock, by the way, is that a lot of these techniques, like fuzz testing isn't new. And, you know, mutation testing isn't new. And like all of these techniques that we use, none of these are new. I'm not that creative. But what's new is that, you know, before AI, if you had a sonar cube or a find bugs or a co-verity or like any of these static analysis checking reports, like they generate tons of false positives. And that's just the nature of the problem space. And so most teams didn't bother unless they were in an extremely sensitive space where releasing bugs is just catastrophic, in which case the investment of time to use these tools would pay off.

But for most tools, and even at my last company, even at DataStacks where we're building Apache Cassandra used by companies like Apple and Netflix and, you know, all of these other companies to store data that they cared very deeply about. Even there, we only made minimal use of this kind of static analysis because, like I said, there's just so much false positives. But now you can just tell Opus or Sol or, you know, your model of choice, go through this report and throw out the false positives and create tickets for the ones that we need to fix. Like that unlocks so many of these things that software engineering researchers have come up with over the last 20 years and nobody could use because we didn't have the time to implement them or the effort didn't pay off. But now code isn't the only thing that's free anymore or very close to free. Reviewing the outputs of these tools is also free now.

And so now that so much of the work can be automated, there's always the problem of running around with a hammer and trying to hit everything that might be a nail. And so I'm wondering what are some of the ways that you are seeing the best return on investment for human time spent and what are some of the useful heuristics around what are the places that AI is going to be most useful and most effective versus the time where I need to use my own human judgment and reasoning, which also potentially segues us into the conversation of how do we help people build up that knowledge and reasoning if they're early in their career. career and haven't gone through all of the painful learning paths of people who have been in the industry prior to AI. Those are two very different topics, but both of them interesting. So on the first one, how do you decide where to spend your time? I think, so for me, the best use

of time has been, as I mentioned, building more oracles and building the harnesses to drive those. And, like I said, I'm not a super creative guy. So I just go to, you know, ChatGPT or Claude, and I say, you know, the way I would start with a new project is I would say, hey, what are some of the most interesting research approaches from the last 20 years of software development or software engineering research that I could apply to this project and order them by your expected cost benefit and then start figuring out how to build them from there. The other thing that's a good use of time is building better tools. So all of those things that I'm talking about, we have custom harnesses for Bifrost to drive those. It's not just like type into codex, hey, do some differential analysis for me, but rather we're going to build a system that can do that as a nightly job

and then give me a report and feed that through the agent that's going to triage it for actual defects and so forth. And that can be at the micro level where, you know, since Bifrost is a tool for agents to use, a lot of what we do involves looking through the traces of a model that's trying to use the Bifrost tools and then, you know, figuring out where the tools were less helpful than expected. So one of the very low-level things we built is something to parse codexes' trajectories for the Bifrost tool calls and pull out the appropriate context so that Astra doesn't have to reinvent that wheel every time it's tackling one of these jobs. and at a higher level it could include things like Neonir where I've created kind of a meta harness or a harness harness so that I can use my codex and my Anthropic and my Kimmy and my GLM

subscriptions all in a single pane of glass and keep track of what the different agents are doing. the other thing that you mentioned was was about how do you upskill as a junior engineer so if you want to take the conversation in that direction we could do that yeah i think that that is an interesting angle as well because everybody's asking the question various people have attempts at an answer but i haven't seen a i haven't seen any sort of standard developed as far as what are the actual ways that we do that. Not that we did a great job of it prior to AI, but now there are potentially fewer opportunities or depending how you look at it, more opportunity because the junior engineer can get more done, but they're also holding a bigger foot gun. So there's potentially a larger blast radius of poor understanding of the problem. And I think that one of the ways that humans can spend their time and tying back to what you were saying about mining the agent traces for

how the how it's issuing the tool calls for bifrost or any other tool is that in order to prevent a lot of wasted compute and tokens on retreading the same ground over 50 different agent sessions as well as giving junior engineers a place to look to understand what are the best practices or how do we tackle these types of problems is through the introduction of different skills documents that helps the agent do the work, but also acts as an artifact that people can look at to understand what is the approach for doing this and why did we do it this way? So that acts as a shared repository of knowledge if you take the time to actually look at it. And that's actually another area that I and my team have been spending time is every time I have to keep doing something a certain way, I say, okay, great, let's go ahead and read back through all the sessions where I did this

particular workflow, codify that into a skill so that I can just trigger it when I want to do that thing again. So one example of that is actually for code review, because I'll open a pull request from my agent, I'll get a different agent to do reviews on that. Lately, it's been co-pilot, but whatever other agent. And then I have a skill that says address PR feedback that will just go through, find all the comments and pull them in, perform the necessary, evaluate, perform the necessary changes, and then close those responses. And so that gives me a way to go back and forth on create the code, get some feedback on it, address some of the problems without having to involve a human until after that's already been done. If I say this actually is a large enough change that I want to have somebody else look to make sure that my general approach and design is correct before I actually merge and ship this. Yeah, someone, so for a couple years there, and I think we've broadly moved past this point, but for a couple years, people were saying, well,

the AI is like an intern, and, you know, it's reasonably smart, but it makes a lot of mistakes, and it kind of doesn't know what it doesn't know, so you've got to supervise it closely, And that was their mental model of the AI agent. And now the agents are smarter and better at writing code, but they still don't have the big picture. So someone said, and I don't remember who, that a better model now, it's not an intern so much as it's a great new hire. And every time you talk to him, it's his first day at the company. And so what that pushes us towards is some of the things that you're talking about that were kind of best practices already in human-oriented teams, at least teams that hired new people regularly, that you need to have this knowledge base and a set of runbooks and things that let those new hires orient themselves to what's going on.

And so what are the decisions we've made that we don't need to relitigate every day? And, you know, what are you know, what's our big hairy goal? Right. What are we trying to build here and and why and what problems are we solving and and so forth? And so the difference is, of course, that. Maintaining that was always super, super difficult in the before times. And so most teams didn't do as good a job as they could have. And now I can just say, okay, Fable, document what we did and the dead ends we ran into and put that in our set of plan documents so that we don't have to re-derive that next time. And we can talk about how I don't think text files. I come from a database background. So I think there's better solutions than a directory full of markdown files.

But that's kind of where we are right now is the markdown file level. And it works pretty well. Eventually you do outgrow it, but it does work pretty well, surprisingly well even, for what it is. And then as a very tactical piece one of the things that works really well for us is OpenAI wrote an article almost a year ago now I think it was in November of 25 but it was late 25 And they wrote an article about using something called exec plans to drive agents for longer tasks. And the framing of the article was, here's a structure for how to create plan documents and have your agent create the plan documents. that it can follow that will keep it on task over a task that takes hours or days. And remember, this is back, you know, like Codex 5.1, I think, was state-of-the-art,

because 5.2 came out in December, and this was definitely before that. And the Opus was around 4.5, I think. And both of these models, you know, were the start of the new agentic age that we're in now. But they both got distracted really easily, and they both were a little bit lazy where if you gave them a big task, they'd do the first part and then stop. And if you just said, well, slash goal, do the big task, then they'd go all over the place and compaction wasn't as good and so forth. So OpenAI said, hey, use this exec plan idea to keep them on track across compactions in this longer-running task and so forth. And we mostly don't need plan documents for that purpose anymore. Or rather, doing a slash plan in the harness is sufficient. But we're still doing exec plan documents because of this category of problem where two weeks later or two months later, why did we do things this way?

And the exec plan captures that in a way that seems to fit how the agents want to work a lot better than trying to put it into a comment in the code. Because for a bunch of reasons, the grep and set approach to going through code means that they have holes in their knowledge and they'll easily miss that kind of comment. But if you have a document that says, here's where all of our plans live and go look at them if you need to understand why we did something, that works a lot better. Yeah. And similarly for architecture decision records, this is the design and why we chose to do it this way that the humans can also look at. And that's something that predates AI workflows as well of humans who are joining the company afresh and they're working in that thorny corner of the code and think, I know exactly how to solve this. And then there's definitely seen tropes of people saying, OK, every time you think you're going to solve this, increment this counter of how many times people have tried to do that before going back to whatever it was before.

And on that point, on that point of databases being a better structure for some of this style of data, that's also why I built the tool that I'm using for my shared agent task and memory context. It's actually using a storage layer called OmniGraph and the backing store that uses Lance as the storage format, but builds a graph on top of that. So you can actually have the connectivity between projects and tasks and memories and have the way to be able to go from one to the other and also being able to have memories that get superseded so that as you find out more things, you can have the most recent, but you still have the way to backtrack to see what did we think we do at this point in time. And so that's an interesting angle as well. And so you should you should check this out. A couple of friends of mine started a company called Vectorize and their their flagship product is called Hindsight. And it's basically graph and embeddings based memory for agents.

So, yeah, it is it is on GitHub. Yeah, I think I think you should probably check it out and see at least at least. there's probably some interesting ideas that might be useful cross-pollination and it might even be where you're like oh i don't need to maintain my own anymore i can i can use someone else's who does this full time yeah i'll definitely take a look at that as well and there's that's the other interesting aspect of the time that we're in is there is a massive proliferation of people who are solving adjacent problems or maybe even the same problem in slightly tangential ways where we're having an explosion of what are the different concepts and primitives that we actually need for software engineering agents or agents for particular workflows. And so it's the let a thousand flowers bloom mentality. And so it'll be interesting to see where we are two years from now once the market starts to coalesce around some of the primitives that we all agree are useful.

And these are the two or three different right ways to do it and how that collapses some of the tools and products that are being launched right now. Yeah, I think that's true. And I think that's also something that we collectively need to be a little bit intentional about. Because for me, and I think for a lot of engineers, there's whenever I see somebody selling something where I'm like, oh, like I understand how to build that. It's a very, it's not a large step to go from I understand how to build that to I should build that. Especially if it means that I don't have to pay someone for something that I could do myself. But the good part about AI code is that building my own is easier than it's ever been. But I think that that means that there's a trap of not seeing, like, the rest of the iceberg under the surface.

That, you know, building the prototype, yeah, that's a weekend. But maintaining it and, you know, handling feature requests from my team, that's a serious time sink over the next six months, even if AI is doing most of the actual code authoring. And so I think that, and I certainly do this myself, and I hope I haven't fallen into that trap with Mjolnir, that building your own is seductive, but not always the right call. it's the age of the content management system or static site generator where everybody says oh that's an easy problem i can build my own and then they get 80 of the way there and say oh i'm almost done now i'll spend the rest of my time trying to build that other 20 and so yeah that's a really good analogy yeah and that's definitely another interesting aspect of have i built a static site Yes, I have.

And so that's another interesting aspect of where we are in terms of how do you decide what are the appropriate ways and places to spend your limited human attention? Because, as you said, it is very seductive to say, oh, I know how to build that. I'll go build it for myself. But now more of my time is getting sunk into this offshoot toy project that is maybe helpful, but is distracting from what are the actual concrete broader goals that I'm getting paid to achieve. I mean, if you're doing it for fun in your hobby time, sure. But again, you can only have so many hobbies before they take over an increasing amount of your life. And I think another aspect of this problem going beyond just agentic software engineering into the broader agent ecosystem is what is the role of humans when agents can do more and more of the daily tasks of dealing with my emails or managing the data ingest workflows as data continues to break or building and iterating on the product.

based on what are the requests that I'm getting from my users. And that brings back that question of human judgment that open source maintainers have had to deal with for years now. Just because somebody can request a feature doesn't mean that it's a feature that I want to own. No, that's 100% true. And again, I don't remember who said this first and possibly lots of people, but the most important job of an open source maintainer is saying no. And that was true five years ago, but it's significantly more true now. And to the point that, by the way, I definitely appreciate everyone whose libraries I'm using on GitHub who have PRs open. And just yesterday, I upstreamed PRs to two different libraries that Brock is using, and they were both accepted, or rather the sets of PRs were both accepted.

So I appreciate being able to contribute like that. But at the same time, I don't think that that's scalable as the barrier towards, oh, I have a problem. Let me throw up a PR. Because a lot of people do throw up PRs without actually doing a whole lot of the kind of review that we're talking about. And so it's very easy for those open source maintainers to get snowed under by trying to give feedback on those PRs that were written by agents with very little human oversight and sometimes by people who aren't professional developers. So on the one hand, I'm not here to gatekeep, but I think it's great that AIs are opening up, creating tools to make lives better in digital worlds for people who aren't professional developers. I think that's great. But at the same time, when the number of people who can open a PR to your product is literally everyone in the world and not just the professionals, it does mean that maybe there needs to be another barrier to reduce that maintainer burnout.

And so what we're doing with Bifrost, we haven't done this with any of our other repos, but with our flagship Bifrost repo, we have turned off PRs. And so, you know, the issues are open. If you have a problem or a feature you want to request, open an issue. But it's just faster for me to drive that in the right direction with my own agents, with my own harness, with my own QA system than it is to try to do a dance of, hey, can you fix this? That can potentially take several days with contributors. So I think that's unfortunate because I think that that open source ecosystem and community building and training the next generation and all of that were good outcomes from the way we used to do it. But there is historical precedent, which is that back in the 80s when Richard Stallman started the Free Software Foundation, it was not a GitHub style, hey, everyone bring your contributions and let's build this together.

He believed very strongly and still believes very strongly in the importance of having the source available so that you can make changes and have the freedom to do so. But the FSF in the 80s did not accept patches from external contributors. It was much more of a shared source is what we'd call it today than open source. And I kind of think that's the direction we're heading in. yeah I've definitely heard about a number of other open source projects that have followed that same model of you can open an issue and then I will send that issue to my agent to do the code change because of the fact that as you said the PR itself requires a lot more time investment and communication overhead. And so, yeah, I think that one way that as an industry, we should be thinking about the ways that we develop our workflows

around AI being the primary actor is to codify and enforce more of that human judgment requirement where rather than giving the agent an objective and say, hey, go build this thing, force it to ask you why or what is the actual thing that we're trying to achieve, which that's a human problem as well, where I can go and tell one of my employees, go build this thing and they'll happily go off and build the thing that I said because I'm perceived as the expert. But maybe I don't actually know what I'm talking about in this regard. And so having more of that pushback and requiring the human to be more involved in the end to end delivery of what are we building? Why are we building it? What are the things that we need to think about before we put this thing out into the world? And then also maybe to your point of there are 50 different versions of problem X, agentic memory, coding harnesses. Those are some of the ones for this era. Go and do some research to see, do any of those solve 90% of the problem that I think I'm solving?

And maybe I should just use those instead of building another one. yeah and yeah i do want to come back to to what you said earlier about upskilling the the next generation we talked a little bit about onboarding the agents uh kind of in the context of onboarding new humans but that's a that's a bit of a different problem than how do you go from a new college graduate to being able to do what you do in terms of being able to supervise agents effectively. And I don't really have a good solution to that. And I'm kind of hoping that you do because, or that at least collectively, we can come up with ways to do that. The best that I've found so far, or the best that I've been able to come up with so far is, so my 18-year-old right now is studying computer science and he wants to, wants to be an engineer. And, you know,

the rule of thumb with him is, you know, you can use agents to do anything that's routine that you understand how to do, but don't, don't use it for anything. Don't, don't throw an open problem that you don't understand it, Claude and say, solve this for me, because then you're just cheating your future self of, of that understanding. And there's been, you know, I think we have a little bit of, you know, historical precedent there where, you know, we've taught kids to do arithmetic in their heads or on paper, even though calculators have existed for, you know, lots of years. and slide rules were a thing even before that. So there's some value and we've created some patterns for here's how you do something by hand and here's why it's valuable to do something by hand, even though we've already figured out how to automate it. But this pushes that a lot farther down. Like it's like even deep into graduate school,

you'll still be doing things by hand that we already can automate with agents, which is, at the very least, it's a mental shift for our educational system. And maybe one way to think about this in the context of software engineering teams, particularly for people who are earlier in their career or who are working in an unfamiliar area and trying to upskill is the idea of training wheels where the harness and the agent will do the work, but maybe it will only execute on it after you've been able to provide a satisfactory description of the problem space and what you've thought through. And maybe as you get more adept at a particular area, it adapts and says, OK, well, you have already proven your expertise in this area. So I'm going to go ahead and do what you asked me to do because you've demonstrated ability similar to the way that we demonstrate ability in our work and get promotions in that regard. And so having the harness push back more and not just blindly accept every instruction that is thrown at it.

Yeah And then another analogy that gives me a little bit of hope here is the chess space where it it literally been 30 years since a human was the best chess player in the world deep blue beat gary kasparov in 1997 and that was a rematch he beat he beat the first deep blue in 96 if i remember correctly but then they went back and revised their algorithms and and expanded their hardware and then they won the rematch. And, you know, today, of course, you don't need a big RS6000 supercomputer powering it. My watch could be all of the best humans at chess. But, and yet, even with that, chess streamers are one of the most popular forms of entertainment on Twitch. And they're getting more popular. So there's space for, even though machines are better at this than humans, it's still useful and still interesting for humans to compete and try to improve in that problem space.

And, of course, in a less intellectual domain, we've had machines that are better at any kind of physical exertion than humans for 200 years. And we still go to the gym to get more athletic. So I'm not in the camp of, well, AIs are better than humans at everything, so we might as well give up. I think that there is some value to doing things as a human, even if the machine is better at it than I am. But, yeah, the world is not going to be the same. It's not going to go back to being the same. So it's going to be exciting. And also, there is always a role for the human to play, because despite all of the terminology that we use and all of the hype that has grown up around the ecosystem, these large language models or these various deep learning models do not have any agency of their own. They are a tool that we point in a direction. And so you still need to have that

human judgment of what is the direction I want this thing to go in and understand, one, what are the capabilities and why am I going in this direction, but also have the sufficient knowledge to understand whether or not you have achieved the stated goal. See, that's something that I'm not sure about. That's certainly true today, and it's certainly true next year. Is it true in 10 years? Do we never get to a point where I can tell Claude 14, you know, just write a loop that figures out the next thing to build. Here's my goal. Here's what I'm trying to build. Now just build the next thing that gets me closer to that goal in a loop. Do we never get there? I'm less sure about that. But even in that example, you're still the one stating the goal. The AI isn't going to be the one to tell you your goal. I mean, maybe sometimes it does, but you as a human still have agency that the model itself lacks. Okay, that's fair.

But that is saying that either the CEO is the only one who's not replaceable, or we're all mini-CEOs of our own agents. yeah I don't know I don't know I would say that that's a fair approximation of the world as it is right now where you have people who large companies where you have a CEO and there are people who are happy to work under them in their particular role and then you have people who chafe at being told what to do by anyone and they go and run their own small businesses focused on whatever it is that they want to do in the world. That's a good analogy. Yes. All right. Now that we've played that out, I guess, circling back around to what you're building, I'm curious, what are some of the most interesting or innovative or unexpected ways that you've seen the tool chain that you're currently focused on applied? So Bifrost, Mjolnir, and I think you're also building something called Anvil. Yeah, so Anvil is, we de-emphasize Anvil, so Anvil, so Mjolnir is, like I said, it's a

meta-harness, and what that means in this context is we're driving Codex and Cloud Code and Kimi Code and GrokBuild and MuseCode, we're driving those directly from that text interface that Mjolnir shows the user. And we're driving those over a protocol called ACP. And ACP was created so that you could put cloud code into your IntelliJ or into your VS code and so forth. But it's still cloud code under the hood. It's not a separate harness. And so Anvil was something where we said, well, we've got these interesting ideas for the harness itself. So we'll have our own ACP server, which is what the harness's role is. But as the models have gotten more sophisticated and they're doing things like, you know, cloud code will invalidate individual chunks of the inference server's key value cache

based on what's going on in your session. And I'm like, well, that's a level of integration that I don't think that I can outcompete the big labs at. So Anvil has been de-emphasized where I do think we are adding value with Mjolnir over the codex and the cloud code and so forth layer. And to give an example of what you asked about was something that's surprising or that I'm proud of. We just added a feature to Mjolnir where it will. So Mjolnir has a concept of workspaces and sessions belong to a workspace and you can navigate between the sessions and see what's going on. But we added a virtual workspace for subagents. And so you can have your codex subagents and click on the six subagents label and it opens up a virtual workspace and you can see what's going on in there. And those sub-agents don't have to be from the same heart.

So you can have Fable driving a Luna sub-agent, which is a very economical way to use Fable because Luna is really, really inexpensive. Or Deep Seek Flash. I had Fable driving six DeepSea Clash sub-agents yesterday working on a problem because it's part of the subscription optimization game where my Fable quota is much more valuable than the other half of the subscription that only lets me use Opus and Sonnet in Anthropics' case. So on the meta-harness side, that's what I'm excited about is kind of unlocking the value of my different subscriptions playing together. And then in the Bifrost side, this is going to get really deep into the technical weeds, but we've built the Bifrost database on top of Git, basically.

The primary key in Bifrost database is the Git blob ID, so the hash of the contents that's in the Git index. And so what that does, what that unlocks is that if I have 12 agents working in 12 work trees and making changes simultaneously, I only have to re-index changes that are new that have never existed in any work tree, and I don't have to re-index anything that has ever existed anywhere else. So creating a new work tree and indexing that in Bifrost is instant because all of those blobs have already existed. And then what that unlocks now is that's what unlocks the speed difference of, I can ask Bifrost during the coding session, you know, have I committed any concurrency crimes that the Bifrost policy engine catches rather than, you know, an hours-long CI session because I just have to re-index those pieces that have actively had edits since the last time it got indexed.

And as you have been working in this space and trying to discern what are the most effective ways for humans to be involved in this agent-owned software delivery lifecycle, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process? I guess I'm going to contradict my talking points a little bit, because one of the most frustrating and challenging parts is that, while I think everything we've said about how agents are so good at writing code now that we don't need to review their work is correct on average, average, there's always corner cases where, you know, our running joke on our Slack is, I guess I'm not obsolete yet. Because, you know, you constantly find these places where Fable decided that what I really needed was to clone. So Mjolnir is written in Rust. And so

it decided that what I really needed to do was to clone the entire conversation every time I appended a new message to that conversation. So it's like, well, why is my Mjolnir process spending all its time in memory remapping? Oh, it's because your allocations are through the It's like, well, should I really need to tell Fable in 2026 that this is not a good memory allocation pattern? Like, I feel like I shouldn't, and yet in this case I did. So, yeah, the edge is still jagged, but I do think that, you know, it is up and to the right over time. And at some point, and not today, at some point we won't have to think about that anymore. Yeah, the models are definitely very adept at being confidently wrong. Yes, that is still true, yes. And so as people are remapping their overall workflow and rethinking the role of humans in the production of software, what are some of the things you have planned for future looking tools or thought pieces or experiments to help us as an industry move in a beneficial direction for some definition of beneficial?

Well, I guess just at a really tactical level, one of the things that I'm frustrated about, again, is the state of model benchmarking. And I say again because in 2025, the state of the art for benchmarking coding models was Sweebench, the original Sweebench, which consists of 100% Python. and like 49% of it, I don't remember the exact number, is Django. So a high-sweepence code was basically just measuring how well, oh, and the problems they give the models were all based on GitHub tickets from like a 10-year time span. So a high-sweepence score was basically how well has your model memorized Django and a little bit scikit-learn and a little bit a couple other Python packages. And so I wrote something called Brockbench to do more realistic coding challenges.

And then at the beginning of this year, we kind of got a next generation of coding benchmarks, especially DeepSwee and CursorBench and FrontierSwee, I think, is another one. There's two or three that are reasonably good now. And so I said, okay, I don't have to do this anymore. But lately, with the last couple months of releases, DeepSwee is saturated. Like, everything's peaking at about 80%, and it's telling me things like Opus 5 is better than Fable 5.1. And I know that's not true. Like, that is just not true. Whatever you're measuring there is less useful than it was six months ago. And I don't know if it's because the agents or the labs are training on the benchmark or it's less useful. And so what I've been working on over the last couple weeks has been I'm taking live Bifrost tickets and I'm doing a bake-off between two or three models at a time.

And I'm having Fable and Astra judge the results. So I'm going to have basically a series of pair rankings across a couple hundred tasks for DeepSeek Flash, for GLM 5.3 and 5.3 Flash, for MuseSpark, for GrokBuild. Basically all the models that you might want to use when you're like, oh, help, I'm out of my Claude subscription tokens. What can I use now that's not going to break the bank and is still going to help me get things done? That's basically the question that I'm trying to answer. So I should have the first results by the end of this week, next week at the latest. And are there any other aspects of the work that you're doing at Brock AI and the various tool chains that you're investing in, or just this overall question of where and how best to spend our human attention in this world of AI generated everything that we didn't

discuss yet that you'd like to cover before we close out the show? Well, my goal with Brock AI is to get to that ideal point that you articulated earlier of we're spending our time as humans deciding what to build and less on checking, hey, did the model actually build what I told it to do? And that's what we're trying to build with Brock. All right. Well, for anybody who wants to get in touch with you and follow along with the work that you and your team are doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest gaps in the tooling, technology, or human training that's available for building AI systems today. Biggest gap? I think the biggest gap is agent-oriented collaboration tools. So we've got GitHub that's oriented towards humans. We've got Linear that's also oriented towards humans and maybe doing a faster job of adapting to agents than GitHub is.

But what I would like is a world where when I file a ticket, something in the system can say, oh, this is related to code that Agent 345 wrote last week. Let me revive that session on the appropriate harness and tell it, hey, you caused a regression. So it's got all the context there. It doesn't need to rediscover it. And just wire those pieces of the lifecycle together. if somebody had that, I would be a customer tomorrow. All right. Well, thank you very much for taking the time today to join me and share your thoughts and opinions and expertise on this fast-moving space of what do humans do now. So thank you for all the time and energy you're putting into that, and I hope you enjoy the rest of your day. Thanks, Tobias. It's been a pleasure. Thank you for listening, and don't forget to check out our other shows.

Podcast.net covers the Python language, its community, and the innovative ways it is being used. And the AI Engineering Podcast is your guide to the fast-moving world of building AI systems. Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts at dataengineeringpodcast.com with your story. and to help other people find the show please leave a review on Apple Podcasts and tell your friends and co-workers