# Harness Engineering is not Enough: Why Software Factories Fail — Dex Horthy — session 2026-06-30T23:30:00.000Z → 2026-06-30T23:50:00.000Z

_67 transcript lines · 0 slides · source: full recording_

## Transcript

Ladies and gentlemen, please put your hands together and welcome back our MC, member of the technical staff at Keycard, Ali Howe. Welcome back to our afternoon keynotes. I hope you all had an amazing day so far. I know I certainly have. I've enjoyed exploring the different talks across all of our different 18 different tracks. I've enjoyed exploring the expo session. And I've enjoyed talking and networking with all of you. AI Engineer is a really special place where we can all come together in one space and have really interesting conversations that push the boundaries of what's next. It's a really powerful thing to get AI security engineers and AI engineers into the same room and And how we can unblock, shipping because of security issues, ship faster, and increase our engineering velocity. It's also really exciting to get the same people that are building the models in the same room with the people that are using them so we can understand what actually works and help us define what's next. I'm super excited for the rest of our content today, but I wanna take a moment to thank our amazing sponsors that make all of this possible. Let's take a round of applause for our presenting sponsor, Microsoft. I also wanna recognize our Lab and Platinum sponsors. Also, our gold sponsors. Round of applause for them as well. And last but not least, I wanna thank our silver and bronze sponsors, which there are Amount of those as well. It certainly takes a lot of people to put on this event. And so super thankful to all of our different sponsors. Thankful for all of the people that are here that make this community possible. I know we've heard a lot about software factories today, and they're super interesting. We're all, like, very By the promise of what the productivity and unlock that they can deliver. But in practice, they could be more difficult than in theory, and I'm really excited because our next round of speakers are going to help us understand the best practices for loop engineering and help us understand how we can create software factories that actually work and don't produce slob. I'm super excited to introduce our very first speaker of the afternoon keynote sessions. This speaker is A seasoned AIE speaker, he just told me this is his fourth time he's spoken at AI Engineer, which is incredible. This speaker is known for raging the war on slop. He is known for coining the the term context engineering, and he is known for creating the research plan implement framework that we know and love. It's my honor to introduce, Jack Swarthees, cofounder and CEO of Humor and Layer, to talk about harness engineering is not enough, why software factories fail. Please welcome to the stage, Dex. 'Sup, everybody. How we doing? Guys, give it up for all the great speakers today so far. All right, this is, harness. Engineering is not enough and why software factories fail. And we're gonna click maybe. Oh, that's way too many slides. Hold on, guys. Okay. So we're all racing to put AI coding into production, and there's been lots been said about loop engineering, and we should probably write more loops. And, yeah, I don't know. I guess we're doing loops now. Strong VM built a light soft software factory where nobody even reads the code and the prevailing Is we should just spend more tokens. You are the bottleneck. The models are good enough. Code is free. Just ship more stuff. But at the same time, we are starting to see the cracks. Our friend, Mario at AI Engineer Europe begged us to slow down because companies that should not be having outages because of coding agents are having outages due to coding agent mishaps. Code based Are falling apart faster than they ever have before. And our friends at Pharos AI actually even did a report since we all picked up all these AI coding tools in January, maybe February. Pull request code review quality is way down. We're having more comments, longer comments, and tons of PRs being merged without any review at all. Incidents are way up. Bugs per developer are way up. And, many people will tell you that you're holding it wrong. That's the only reason you're not. Well, maybe you are, but that's not the point. I've spoken a lot. About how to hold it better when it comes to working with AI, probably a million views on YouTube at this point across a bunch of different talks. And the basic thing is, like, as engineers, we've been told that if token maxing isn't working, then it's a skill issue. You just need to spend more tokens, let go of reading the code, that with enough harness engineering, if we maybe sprinkle some magic words, adversarial review on enough of Our PR bots that we can get the best of both worlds. 10 to a 100 x faster, high quality, and nobody has to do that thing we all hate called code review. I'm here to convince you today that this is in fact not a skill issue, that no amount of harness engineering or loops maxing can solve what is fundamentally a model training issue. That's why we say the harness is not enough. And to understand this, we kind of have to grapple and dig into how coding models are trained. I'm gonna talk about what I think the shortcomings are with some of the current benchmarks and what better ones Look like and we'll talk about how to move faster safely in the meantime. It's gonna sound like a rant, but there is hope here. I'm gonna talk about our journey and a bunch of the landmines we've hit building in this world, a bunch of exciting new techniques that we've been working with a lot of our users and customers to develop and I think how we all as a community get to the next chapter of agentic engineering after whatever this thing that we're in. So we use a lot of words here. I'm A little bit. I wanna give you kind of like a brief history of the software factory. And it's actually I don't I just learned this last week. The term software factory was defined at a NATO conference in 1968. We're gonna start around 2022, right before AI started coming around. And basically in a typical 2022 software factory, you will have some people building stuff. You'll have engineers, you'll have PMs, maybe you have some sort of leadership team that is driving the vision here, and they all decide that stuff needs to get done. And so you put it In a tracker, a linear, a JIRA, a beads, some sort of state machine that tracks what needs to be done. And then someone goes and grabs something off of there and they build the thing. And there may be some automated testing in that process, maybe some manual testing in that process. At a certain point, we make this pull request thing says, okay, cool. We gotta run a bunch of checks, automated stuff. A human's gonna review the change and review the code, and perhaps we might even have, a human pull it down and test it somehow. And if anything goes wrong here, we loop back to someone builds the thing. And eventually we're ready for prod. And so we ship it to production. And once it's in prod, it makes contact with our users and users do a thing that we all love. Users love to complain. I love our users. But yeah, they're gonna ask for things, they're gonna find bugs, they're gonna file feature requests, and that goes back to your team. You might also add monitoring. And so, you know, what do we want more than anything else? We wanna wake up engineers at three in the morning when something breaks so they can get dragged out of bud to track. They go fix it, and we go on and on in this loop, and we ship a bunch of code. And one thing that we noticed here is that, teams figured this out decades ago is that this someone builds the thing step is usually going to take hours or days in most cases, and the review part will also take hours or days for large things. And so teams started doing this upfront planning architecture proposals, sprint planning, and they would collaborate this on on these things as a team, with the hopes that we might decrease the percent chance that something would need to be reworked, that we would be able to reduce the time Spend in reviewing every line of code because we aligned on everything ahead of time. This brings us to the agentic software factory. Every company and their mother is talking about how they built a coding agent factory that shifts 75% of their code now. Literally everybody. And so if we look at the software factory from 2022, we just replace someone builds the thing with an agent builds the thing. We have an orchestration and a harness and a sandbox and a model and computer use, and I'm not gonna get into, like, the details of that. You can watch a 100 talks about that this week, I'm sure. But now the building part takes minutes or hours, but this human part still takes hours or days if you're gonna review the code and you're gonna test the changes. And And so we bring in agentic code review, and we bring in agentic regression testing, and it makes this part faster, but it's probably still the bottleneck. But we can do more loops here. Why not? Let's do some more loops. So we can route all incidents straight into the factory. Why does someone need to get woken up, and try to fix it when they could just wake up to a pull request and, maybe that fixes the issue. For you. You can take all the user feedback and just stick it straight into the factory so that, people ask for stuff and it gets built. And now your only job is how much things can you stuff into the queue of stuff to do and how fast can you review and test the changes, which brings us, of course, to, I'm sure you know, the lights off software factory where basically Dan Shapiro coined this is we no longer read the code. We say, you know what? This is going great. That code For your thing? No, thanks. We're just not gonna do that anymore. And we invest into all these other parts of the system. Your your testing, your monitoring, your rollout, everything else. We just write more code and build those systems better, and now our job really is just how how much stuff can we ask the agent to build? I am going to posit that this does not work, and this is why software factories fail. As as an aside, what I'm going to say has nothing to do with Vibe Coding. So Adi had this, great post. I'm gonna just go literally take his quote verbatim. A developer Vibe Coding side project a dozen people will ever run. And a team keeping a ten year old enterprise system alive for another quarter share almost no constraints worth naming. And most of what you hear on the Internet is one of these groups of people telling the other group of people how to live their lives. So if you love Vibe Coding, please go on. At HumanLayer, what we hear about is how do we help people solve hard problems in complex code bases. We use the word Brownfield a lot, which historic Has meant, like, some ten year old Java thing. I actually think agents really start to struggle after maybe three to six months, especially with the pace at which we can ship now. You can ask me how I know this, and I will tell you that it is because in July 2025, we tried this. We went full lights off. And, if you have tried this seriously for a number of months, you probably found at least one issue that the agent couldn't solve. Even with your most advanced prompting, you do research, you do reproductions, you just, you have to go and dig into that code base that you stopped reading three months ago to try to figure out what's broken. In the meantime, your site was down. Your users were pissed. And you were if you were like me, you were probably miserable reading all this slop code that you let slip into your system. And what I wanna get to is basically models have a shortcoming. They can't maintain and improve code base quality over time, not without a decent amount of human steering. And when I say maintainability, I'm basically talking about issues like it becomes really, really hard to make a change in one part of the code base. Without breaking other parts of the code base. This is Martin Fowler's shotgun surgery textbook code smell. I'm not gonna say much more about maintainability. There's a bunch of books that you can go read about it. In fact, John Osterhoot is actually here speaking this week, so you can go ask him in person about the philosophy of software design if you want to. But it brings us to this question of like why can't models do software maintainability? And you may also be saying, but Dex, you know, surely the models have gotten much better since then. They've gotten better in some ways, but they're still about the same at others. If you want to solve. One off problems or Vibe code a new marketing site. Yes. They got way better since 2025 and 2024. But as far as improving code base quality, I think, they have not gotten much better. Now I cannot prove this because there are no good benchmarks for a model's ability to maintain code base quality, and I'll get into, like, where we're going with that. But if you've worked with coding agents for a while, a lot of people are posting about this. It's just like you probably have this vibe that they generally make things worse over time and make the code base harder to work in. And to figure out why this happens, I'm gonna zoom out to the first great coding agent. Why did Cloud Code go from nothing to 4,000,000,000? And I think now they're at 9,000,000,000 in revenue in under a year because there were great CLI agents before Cloud Code. You had Adder. You had CodeBuff. There was a bunch of tools in this category. They had all the same tools, read, write, edit, graph, bash. So what was the difference? The difference was was that this was the first time that a model lab trained a model against The harness that they were gonna distribute it to users in. And it got really, really good. This is just some of the tools, but it got really, really good at calling these sorts of tools in an agentic loop. In fact, the OpenAI team did a talk in November about basically if you are a harness builder and you don't own the model weights and you can't r l the model in your harness, you will always be at a disadvantage compared to somebody who owns both the model and the harness. And I'm gonna cite a couple slides from my buddy Calvin French Owen, who was a MTS on codecs during the initial launch. Looking predictors, this is a slide from over a year ago where basically as you're doing your agentic loop, context window goes in, next step comes out. And, we're gonna try to do this. I haven't actually timed this, but we're gonna see if we can do coding agent reinforcement learning in sixty seconds. So what we're gonna do is we wanna train a model to get better at tool calling, better at solving software problems. We're gonna generate a bunch of we're gonna give it a problem, and we're gonna generate a bunch of traces, try to solve the problem a bunch of different times. But LMS are just next We're gonna score them all on correct. This and did the test pass and all this stuff, and then we're gonna reinforce. We're gonna make the bad behavior less likely, and we're gonna update the weights to make the good behavior more likely. This is one of the classic ones here is Swee bench multilingual. They're about fifteen minute tasks. They're from open source repos like Redis, JQ, and Django and all this stuff, and they have binary one or zero rewards on did you fix the problem you were trying to fix and did you do it without breaking anything else? And we look at actually a real problem from one of these benchmarks. This is Fastlane, which is a Ruby project. Basically, there was some issue where we weren't checking for nil and we have a stack trace blow up because you have a null pointer exception. And in this, in this benchmark, you have a base commit that we're gonna check out before the issue was solved by a human in the past. We're gonna give it a test patch that says here's what the behavior should be afterwards. We have a golden patch. Both these are hidden from the model, and so we have the agent go try to solve the problem. We store its patch. We undo all the changes it made to any test files because I'm sure you've seen models comment out test just to get things work. Thing, and then, we're going to apply our golden test batch, and then we're gonna run the test, old test and did the new test pass, and if they both pass, then, then we get the reward. Otherwise, we don't. And so models are trying to get a test to pass. There's no way in this system that we can penalize it for poor program design or for eroding the maintainability of our systems. That's why we get things like this, try catches around things that probably don't need a try catch or things like this. I think by Bob gave us this example earlier of casting things to other things just so the model can just just just wants to get the test to pass. And so if you can't verify the The, maintainability of the code, it gets way harder to train on this stuff. So you remember this picture, verifying code quality and maintainability is orders of magnitude harder than the code runs and the test pass because the cost function of bad architecture is measured in months and years. If you have a coding episode and then you only find out months later that like, oh, somebody vibed this a little bit too hard, it's really hard to propagate that reward signal. Back across the gap. And now the frontier is getting better slowly. And since I know someone's gonna be in the YouTube comments about this, yes, I know benchmarks and verifiers are different and they actually have to be separate data sets, but they're shaped the same and the structure of these benchmarks is directionally correct. So we're gonna look at these as like like what is the future of evaluating code maintainability. There's a really cool one called Sweet marathon from abundant AI where they do like four hundred hour tasks of like clone all of Microsoft Excel every single feature and they have some sophisticated reward channel stuff. Deep Suite. From Datacurb is also like large tasks on OSS repos that are not actually in the training set because they were never actually built in the real world. And then you have Frontier code from Cognition, which is multi PR tasks. They do interesting things like, hey, if the model writes tests that don't fail on the pre patch code, then it gets penalized. And we have a judge model that says, okay, did this follow all of our code quality rules? So we're getting better, but I think models judging quality can only go so far, because if the new model, if the model knew what good code looks like. It would probably write it in the first place, and review agents and throwing more tokens at the problem. It can raise the floor, but we're still constrained by what we can teach during RL. And so I will I will posit that for now we're stuck reading the code, but we can still move pretty fast. And of course, there's a world where this is solved, in the future. And if you want to just keep YOLO ing prompts until you get to GPT seven, you don't have to think about this by all means, please. But bitter lesson be damned. We've got some problems to solve, so let's engineer our way out of this. So turning the lights back on, we're gonna put the code review back. We're gonna embrace this approach of like, how do we plan up front to reduce the chance that we have a long or difficult review process? We're gonna find leverage. We're gonna use AI to help with this. The first thing we're gonna do is we're gonna do some sort of product review, understanding what problem we're solving. What's the desired behavior? Maybe looking at mock ups. Here's a product review I was working on yesterday with a mock up of a new feature. Once we have our product review, we're gonna, by the way, we don't small stuff still just go straight to the agent. But once we have the product review, we're gonna also do architecture system architecture. Contracts, data models, constraints. This is an example of a doc that we build to understand how these systems are gonna fit together and what's, like, the high level picture of it. From there, we do something, that I think is really underemphasized in, agent decoding these days, which is program design. I think people assume that once you get the architecture right, the model can just cook. But we're all I we often look into the types and the method signatures, the program. A lot of people have been doing this for a while. Layout and the call stacks. And so here's some examples. I don't think you'll be able to read this one, but this is like the level of abstraction we're at is how we actually lay this stuff out and how these systems gonna interact. Dylan Mulroy from CloudFlare talks a lot about how he's using these call graphs as part of his planning process. I think this is is exactly right.

## Slides