The Software Factory: Don't Review the Code, Verify It

Producer: Welcome back to AI Radicals. Most engineering teams still read every line of code their AI writes. Today's guests think that's the bottleneck. Justin McCarthy is the founder of Diffusion, where he's been building what he calls a software factory, a system of loops that turns unreliable model outputs into reliable software without a human ever reading the code.

James Cham is a partner at Bloomberg Beta, and by Satyen's account, the idea's biggest hype man. Satyen, Justin, and James get into why verification should cost 100 times more than generation, why legacy systems are a better fit for automation than you'd expect, and why capping developer token spend is exactly the wrong move.

They also get honest about the human side, the AI haze, a workday made up entirely of hard decisions, and the engineers who'd rather go open a bakery. If you're still reviewing pull requests line by line, this one's for you.

Sponsor message.

Producer: This episode is brought to you by Alation. If your data teams are still spending weeks packaging data for AI and analytics, there's a better way. Alation's data products marketplace lets you build certified, governed, AI-ready data products, no code required. Get the guide at alation.com/data-products.

What is a software factory?

Justin McCarthy, founder of Diffusion, defines a software factory as a looping system that produces reliable software from unreliable model output, a pattern related to agentic workflows.

Satyen Sangani (host, CEO of Alation): Justin, James, welcome to AI Radicals.

Justin McCarthy (founder, Diffusion): Happy to be here.

James Cham (partner, Bloomberg Beta): This will be fun.

Sangani: So I'm gonna jump right into it. You guys are at the forefront of this idea, and you in particular, Justin, are at the forefront of this idea, although I think James is really your key hype man around this concept of the software factories. So what is a software factory?

McCarthy: So first, it would be totally reasonable for anyone to claim that a software factory doesn't exist. I think that's a fine position. And it's reasonable to question why the factory metaphor might even be useful. But I will say I think it's useful for at least a few things. It's useful when you're trying to call upon the recollection of an industrial process that has reliable outputs. And I think that's something when we consider what the models are known for, reliable outputs is not among the top of the list. And so when you aspire to create a software factory, one thing you're doing is you're putting yourself in the mindset of high reliability and low variance.

What you can find when you begin using the key structure, which is an L word, which I'm gonna say in a second, a four-letter word. When you use those structures, you can actually stabilize the outputs of that process. So you can take these unreliable inputs, and you can produce reliable outputs. And then the interesting thing, of course, the generative capacity of these models, is you can produce it at a scale that maybe wasn't possible when we were all typing things in by hand.

So that's at least one part of it. And then the four-letter word that's really the key, the internal engine of the thing, is just loop. And I'll say it's not much more than any kind of feedback loop, and it doesn't just have to be about software, but it is a looping system that produces reliable outputs that gets you closer and closer to your intentions and ultimately unites you with your ambitions.

Why take the human out of the loop?

James Cham, partner at Bloomberg Beta, argues that the goal of an automated loop is to remove the human from it entirely, which forces teams to be more rigorous.

Cham: And there's a critical nuance, though, around that where when people usually talk about loops, so much of the emphasis is around where does the human sit? What's the human in the loop? And I think the radical thing that Justin suggested to me a year and a half ago was the actual goal for anything that we build should be to take the human out of the loop. That actually, the moment you did that, the moment you actually automated an entire loop, you can suddenly get a level of productivity and reliability that, to be honest, we in software development just don't really think about.

There's a way in which we've all become lazy, and our expectations have gone down, in part because we think we can put a person in here, and they'll watch out and they'll make sure this whole thing works. But the moment you adopt the mindset of pulling people out of that process, suddenly you're forced to be rigorous in a way that I think we just haven't had to for a long time.

A software factory does not decide what users want

Justin McCarthy of Diffusion explains that a software factory only works on problems a team already understands, and that discovering what customers want requires a separate process.

Sangani: So the factory is producing software, I guess, right? And you're saying... But I'm gonna stupidly say back to you what I heard, and I wanna maybe just delve a little bit into each of the statements, right or wrong. So you're producing software. The problem with producing software is that it's full of bugs. But also some of the challenges with producing software are that we don't fully understand what the user really wants. And another problem with producing software is it's somewhat reliant upon the skills of the people who have both gathered the requirements, but also the people who are interpreting the requirements and turning them into software. And so if I'm building this factory to produce this software, I'm trying to solve, at least for those things, probably many other things that I haven't figured out. First of all, did I get that right? That maybe I'll just start there. Did I get that right? And what did I miss?

McCarthy: So I was in a discussion yesterday on part of the definition of a software factory. And actually, one thing that I think is reasonable, this isn't chiseled in stone yet, but I think one reasonable distinction is that you should put into the factory that which you understand, and so you understand what you want already. And there's actually a separate loop and a separate learning process and a separate process of achieving clarity that you're doing essentially prior to the industrialization.

And so I'll just note that this doesn't solve what the user wants. It doesn't solve the faster horse problem directly. It doesn't solve what the customer's gonna pay for it. You need other mechanisms other than the pure software factory to get that. Maybe it can increase your shots on goal. Maybe it can help you industrialize experimentation. So maybe that's an aspect of how the factory can amplify your discovery process. But really, for at least if we're gonna use the factory metaphor, it should be something that theoretically can be a reliable output. So I would say it's a precondition that you kinda know what you want before you turn the factory on.

How big should a software factory loop be?

James Cham of Bloomberg Beta says autonomous loops must be scoped differently, and host Satyen Sangani frames the question as hill climbing in optimization.

Cham: And then that's part of that nuance, though, around how you talk about the loop. That when we talk about totally autonomous loops, that also means you scope the loop differently than how we usually think about it, right? Because now, in some ways, you're trying to say, "What's the biggest thing that I could automate entirely? But also, what is a tight thing that I'm actually automating entirely?" And that mindset actually forces a very different kind of thinking than we're used to.

Sangani: You've touched on it both times, James, on this idea of complete and total automation. And Justin, you're saying, "Look, I need to have a pretty good idea as to what I'm building." But in some ways a lot of software is some combination of global and local optimization. The way I think about this is that in this metaphor of optimization you've got hill climbing, and sometimes your start point dictates you're climbing a hill that's not a very worthwhile hill. And you're basically saying, "Look, I need to know what hill I'm trying to climb," I think. Is that another way of saying what you're saying? Am I making sense?

McCarthy: I think so, yeah. I think so. Yes.

How does a software factory handle bug fixes and new features?

Justin McCarthy of Diffusion describes how loops can pursue faster, more secure, and cheaper software, and how bug fixes and feature extensions within a product's existing promise can be looped.

Sangani: But then once you've decided that, there's still a whole bunch of stuff to do in software, which is to perfect the product. Maybe not the big loop, but you're in all these small loops where users are using stuff, they're giving you bugs, they're giving you enhancements. How does that work? Let's assume that I've actually figured out what I want to go build. How does this work in a software factory metaphor?

McCarthy: There are loops. They're both loops within loops, and then there are parallel loops running. But there are at least a few things you can say about most things that we've historically called software. I've never loved software being slow. I've never loved it when software was insecure. So you can at least say regarding the promise of functionality that we've made, what if it was always faster than it was yesterday? What if it was always more secure? What if it was cheaper? So better, faster, cheaper, that sounds like something that we don't have to really debate anymore. We can just ask that of the loops, right?

When it comes to, for example, a bug fix, that's within some existing promise that you've made. Like we said this was going to be photo editing software, it should probably be able to edit photos. Now, if you ask the photo editing software to also be able to compose some music, I think that's a big expansion, right? But if you ask it to be able to use a vector mask to highlight some pixels or something like that, maybe you could make a decision that that kind of a feature extension is within the envelope of what we've already promised, and that itself can be, let's say, reasonably looped.

And maybe there's a little bit of design input that someone needs to contribute to consider nine interaction styles for defining that path, and then maybe they have to anoint three of them available and then see which one the users use most. So you can have experimental tournaments around the key ideas of a new feature, but if it's a feature within the envelope, I don't know, see how far you can get with a loop.

How many more tokens should you spend verifying AI code?

Justin McCarthy of Diffusion says teams should spend at least 10 times, and preferably 100 times, more tokens validating code than generating it, and James Cham of Bloomberg Beta agrees that verification should be 100 times more automated work.

Cham: But there's one thing that you should probably chime in on, Justin, which is, I've actually often talked to people who talk about building software factories in which they say, "Oh, you know what? I gave it a spec. It generated a bunch of code. I read through all the code. I had my traditional QA process, and I had 40 people testing it. It was such a pain, and eventually some software came out." And when you talk about a software factory, you scoff at those people, and why is that?

McCarthy: I don't know that I scoff at anyone. This is a time of change. We're getting used to a new way of thinking. I will say that, and this is a famous way of thinking from open source, with enough eyes, all bugs are shallow. And we're just at a moment where with enough tokens, all bugs become shallow. So before you spend a [unclear] tokens on anything, before a human sees anything, you have to be spending at least one order of magnitude, preferably two orders of magnitude more tokens on validating something compared to the time you spent generating it. So Claude runs for a minute to write a function. I want 100 minutes of analyzing that, not just from Claude, but from all the other models as well. So this valid...

Cham: And not by humans.

McCarthy: But not humans. Of course, not by humans. The generation to validation ratio and the amount of tokens, and we're talking giga-tokens here, right? So you spend one mega token making something, please spend a giga-token validating it before you wake up Satyen and Justin and say, "Hey boss, I think it's done." And that's something that the harnesses on their own will not do.

Cham: Right. I was going to say exactly that, that actually the harnesses don't do this, the IDEs don't like to think this way. In fact, in some ways, I feel like the entire software development infrastructure is designed not to think this way right now, and yet it is clearly the best lever for taking advantage of LLMs, right? This sort of thinking, because everyone else is interested in efficiency or decrease in cost, but those are all local efficiencies. And the moment you genuinely adopt this idea that verification should be 100X more work, 100X more automated work, then suddenly the sort of things that you can do and the reliability you get is fundamentally different.

Who decides how AI-generated software gets verified?

Host Satyen Sangani asks who determines the evals, or evaluations, behind AI-generated software, and Justin McCarthy of Diffusion answers with layers of validation. Related reading: AI agent evaluations.

Sangani: Okay. So I've heard two things, one of which is you, instead of describing a specific set of enhancements, you described these adverbs, better, cheaper, faster, which effectively are in some ways vectors of improvement that can run forever, right? There's no limit on what better, cheaper, faster can mean in theory. I mean, obviously they're probably asymptotes for any given process, but they're all directions. But the other thing you said was verification. And that to me sounds like evals. In some ways, there's test-driven development. In other ways there's concepts like, if it was an LLM and obviously all the AI, we've got this construct of evals. Who determines these evals? And I guess... Or am I hearing the wrong thing?

McCarthy: You are hearing the right thing. Maybe the one thing that's missing, and sorry to call on so many metaphors, but when you think about the levels of cache that are present in the CPU or the distance of memory from the register where you've got memory and then you've got storage and so on, and those order of magnitude concentric rings of performance, we have a similar thing in validation where you need the inner, inner validation that can run very fast, that the agents can use as they're producing. So they can run a unit test in a few milliseconds or a few seconds and get a sense that they're making progress and they're not backtracking.

Now, you should be extremely skeptical of that because the agents wrote it. So you need something outside of that that satisfies your definition of done, your definition of correct in a parlance that is very close to the user's experience of your software and that anyone in your company can look at and it's immediately like, "Yeah, that's how the tax calculation should work." That jurisdiction is important, and that jurisdiction calculates it differently, and we all get that. So you really want a language of essentially a functionality bounding box around the process that is in just a language that you can all share.

And then outside of that, there's yet another loop which is actually QA-ing our cool ideas that we've put into it and saying, "You missed another jurisdiction. You guys didn't even think of this." So it is expanding the boundary further and doing a version of exploratory testing where it's using the software and it's evaluating the corpus of cases that we all agreed to, and it's expanding and maintaining and curating that corpus. And then that compiles down further to the fast tests.

So it really is all of these. Otherwise, if you don't have all of those, you're gonna miss in some way. You're gonna be biased in some way. You're gonna lose wall time because there's only one wall time, even if you parallelize. You can't lose wall time. So you need this thing to be fast. You need it to be efficient. You need it to explore a lot of the space. You need it to keep track. But then you also do need continuous pruning and augmentation of the corpus of correct for the system.

How do you stop AI models from cheating on tests?

James Cham of Bloomberg Beta and Justin McCarthy of Diffusion explain that models try to win the task, for example to declare victory in reinforcement learning from human feedback (RLHF), so verification environments must be designed carefully.

Cham: If you're trying to imagine those sorts of tests, so on the one hand, it's everything from evals that are static questions that you're asking to static data that you're putting in and out, to synthetic data that you've generated, to simulations of other systems to see whether or not they actually work or not, to tools to do a better job of measuring the simulations. So in some ways, the amount of sophistication in that verification step is the undiscovered frontier, and I think that's part of what Justin is pushing so much.

McCarthy: Yeah. And it's an extremely creative endeavor, right? You have an adversarial entity here in the models that are trying to cheat, right? They're trying to just win the task, right? So they can declare victory on their RLHF, right? And so you have to create an environment where the easiest way out for the model as it's bouncing around is the correct answer. And then if they can find a trapdoor and cheat their way out, they will, right?

And so the design of that environment, there's just no textbook you can read on how to design that environment. And so that's what requires so much creativity. And in every business domain, some domains are extremely quantitative. There's columns and rows and all the numbers add up. Some are just all video, right? And so you're dealing with video the whole time. Some are other kinds of signal processing. There's just very, very different domains that require different instrumentation for defining that token environment that the models can't escape from without doing the job correctly.

How do you start building a software factory?

Host Satyen Sangani asks Justin McCarthy of Diffusion how a chief technology officer (CTO) should begin, and McCarthy proposes a one-month experiment in which a small team does not read the code.

Sangani: Yeah. And so this is, as you said, a totally new way of thinking about developing software, and a lot of it is getting people to unlearn this construct of "I've got this job to be done, and then I'm gonna break it up into sub-jobs, and then I'm gonna have agents build the sub-services because I'm gonna define the services, and then all of a sudden we're gonna end up with this testable process and on we go." You're basically saying, "No, there's a meta process to be described, and then we're gonna figure out what all the verification steps are, and the ultimate output is gonna also be verified, and we're gonna change that ultimate process at all times." And so that all makes some sense. How do I get started with such a construct? What do I do first? I'm like Joe Coder, CTO walking along.

McCarthy: I do think that there are a couple of very practical exercises, but I think at least one is to start finding ways to tie your hands behind your back. So tie your hands regarding reading the code is a great one. So you have to simultaneously believe, "Oh gosh, we're not gonna be able to read the code," and "Oh gosh, we need to fulfill our promises." And you have to take that spiritually seriously. And you have to sign your three compatriots on the team and say, "Hey, can we agree the next month we're gonna be extremely paranoid. We're gonna want this thing to be correct, but we're not gonna look at code even once?" And just try it for a month.

Is it safe to ship code no human has read?

Justin McCarthy of Diffusion argues that models already write code faster than humans can read it, and host Satyen Sangani raises the point that compilers are largely deterministic.

Cham: I'm sorry, Justin, are you literally... That must be a metaphor. You can't be serious. How would that even... Who does that?

McCarthy: No, I think if you had to have exploratory surgery every time someone was trying to diagnose whether you might have a fracture, then our medical bills would be crazy, right? You can't open up the patient and look inside every time. You can't open up the lines of code when they're being generated at dozens of lines of code, hundreds of lines of code per second. And just plot the future. These models are gonna be generating... They're already generating at superhuman speed. It's gonna be an order of magnitude faster next year. So whether it's now or next year, you have to get accustomed to the fact that just like you don't read your compiler outputs and debate whether the move instruction should go in front of the jump instruction, you can't read the code. It is generated by a machine process that goes faster than you.

Sangani: Yeah, but compilers are largely deterministic, right? So there's a little bit more of a leap of faith required in this move, right?

McCarthy: Yeah. The individual bolts in a bridge are also non-deterministic, right? So the stress and strain that will cause a particular bolt to shear, we don't know each bolt. We know error bars around them. And then we compose them together with redundancy, and that's how we drive over the Golden Gate Bridge with confidence.

Sangani: That metaphor is great because tolerances and variances is a very well-understood construct in all engineering, so...

McCarthy: In every other engineering.

Sangani: Yes.

Cham: In every other engineering. Right. That's right.

How should an engineering team pilot a software factory?

James Cham of Bloomberg Beta recommends that an organization carve off three to five people to work this way. Teams weighing how to organize around the shift can read about an enterprise AI operating model.

Cham: And then my suggestion is that I'm sure there are problems. There's a way in which at an organizational level it's actually easier to think about than at the Joe developer level. Because at an organizational level what you can say is carve off three to five people and then have them think that way and see what they can get done, right? And I think for individual developers it's a different kind of risk, but at an organization I'm pretty sure that this way of thinking is gonna be the future of almost all software development.

And I can also attest that for the organizations that start on that road, it is a little bit like getting infected. They do get radicalized suddenly when a small enough group is suddenly able to work not just two times better, not just 10 times, but 100 to 1,000 times better on certain classes of problems. And so on the one hand we sound unreasonable and we sound radical, but I'm also here to say that it actually works, that we're still surprised right now by the things that are doable if you think this way.

Sangani: Yeah. And I think the key point, just to drive that home, is you're saying that thinking this way is having agents entirely develop all of the code that's being written without humans actually doing any of the typing of code, right?

Cham: Or reading.

Sangani: Or reading.

Cham: Or reading. To be honest, the or reading part is the radical part, right? That everyone generates lots of... I generate lots of random code. But the or reading part for actual production-grade software, that idea that it would not be hand-read still is, depending on the audience, an incredibly crazy idea to a mildly radical one.

Why pull requests should show the P&L, not the code

Justin McCarthy of Diffusion argues that the pull request (PR) interface in GitHub or GitLab biases reviewers toward code diffs, when it should show changes to profit and loss (P&L) and Net Promoter Score (NPS).

McCarthy: The notion of PRs, we still talk in terms of PRs. So a PR is being merged into something. But the interface itself in GitHub or GitLab, it biases you away from where your mind should be, which is, "Prove to me that this is correct," because it's offering you a diff of code, right? It should be offering you a diff of the P&L. It should be offering you a diff of NPS score, right? Not lines of code. That's closer to what we want.

Sangani: Where the P&L and the customer score are the outputs of the software process that you're trying to develop.

McCarthy: Yes.

Sangani: The fundamental end evils that you're trying to engineer against.

McCarthy: Yes.

What kinds of problems can a software factory handle?

Justin McCarthy of Diffusion says brownfield systems, meaning existing software already in operation, are often the best fit for a software factory, while product-market-fit work stays open loop.

Sangani: Okay. You start on this process. You say, "I'm not gonna read any more code. I'm not gonna write any more code." And I guess one of the things that you said, James, that I thought was super interesting is in which scenarios this works, the types of problems. So what are the types of problems where this works, and what are the types of problems where this categorically doesn't work, and where are we in the world today in terms of what we know it does, what we know it doesn't, what kinds of problems we know it doesn't work on, and what's the messy middle?

McCarthy: I have a little bit of a hunch on this. Anything where you have brownfield, I know counterintuitively that may seem like the riskiest kind. That's the most specified kind of problem you have. And so if you have any process that's working, you have the instrumentation you need to replicate that system with different performance characteristics and different operational characteristics. So anything brownfield, pretty good chance that you're gonna be able to loop it with high confidence.

Anything where you really are trying to find that product-market fit, you're trying to match signal, demand to supply, that's much more open loop, right? And so you are much more in the loop there rather than on the loop. Even high-performance, high-criticality applications. We can talk about the performance requirements. We can talk about the availability requirements. Those are all pretty climbable, so I'm pretty satisfied with all of those. I will say that I haven't seen an operating system kernel that I would be excited about making in this way. So I think using Linux is still probably pretty okay down at the lower substrate of the world.

Should AI-built software reuse code like Postgres and Redis?

Justin McCarthy of Diffusion explains why teams should rely on proven software such as Postgres and Redis, with more precedent needed the lower they work in the stack.

Sangani: I know somebody who actually built a search engine natively, and a big part of how he was able to get performance gains out of the search engine was basically by giving it Linux, giving it the Linux source code and basically saying, "Make operating system level modifications in order to make my search engine run faster," and was able to do so. Apparently, he was able to get almost, on some processes, an order of magnitude...

McCarthy: Yes. We do see a lot of using paragons of a particular concept, and a lot of these paragons come from the lower-level substrate software that we care about and love. So, for example, Postgres or Redis. In that software there's wisdom, and the reason this particular function is written in this way is not an accident, right? And so clipping those into your software is pretty reasonable, or just using it directly. I think all of those are so much better than reinventing those wheels. And you can think of it in terms of the pace layers or the depth of the stack. The further you go down in the stack, the higher concentration of precedent you want to rely on. Going higher in the stack, you have more freedom, right?

Sangani: Yeah. Or there's more that can go wrong the lower you go. And you probably haven't thought of all the test cases.

McCarthy: Yeah, you haven't had 20 years of experience encoded into it yet.

Where does a software factory fail?

Justin McCarthy of Diffusion says a software factory falls short wherever people must react to the product, such as measuring a person's emotional response, because that work takes real time.

Sangani: Yeah, yeah, yeah. So that's where it does work. And I wanna come back to the brownfield question, but before we do, let's do where it doesn't work. Where doesn't it work?

McCarthy: Yeah, so where it doesn't work, I would say this is very much where you necessarily need someone reacting to know whether you're going the right direction. You need humans to react, and you need their... I don't tend to use the T word, taste. I don't tend to use the J word, judgment, because there's a lot of discourse that suggests that only Satyen and Justin have taste and judgment. The models obviously do have taste and judgment, it's just on a different spectrum, and maybe it's spotty, maybe it's ragged. But they have some taste, they have some judgment.

But right now, as long as humans are procuring and as long as they're deciding to use our software and our products, then we need to measure the emotional state of that person as they're experiencing it, right? So the AirPods case, how do I like the hinge? How am I feeling as I actuate the hinge, right? So recording my telemetry, right, of my brain and my hinge movements, that's what you need. That takes wall time. So you're not gonna loop that in simulation and digital twin that and run 1,000 years of simulation overnight, right? So that's where don't expect a factory to be your panacea. Actually allow your factory to free you up so you can get out of the building, so that instead of 10% of your time with customer prospects, you can spend 90% of your time with customer prospects.

Free engineers to spend more time with customers

Justin McCarthy, founder of Diffusion, says engineers moving to a software factory go through a grieving period, and that discovering something new now requires more outbound activity.

Sangani: So the entire premise is if you are spending a lot of time plumbing versus deciding the architecture of the building that you're trying to build, then you're probably wasting time, and what you really need to be doing is the thing that makes you uniquely aware and understanding of the process that you're trying to... the customer you're trying to satisfy or the process that you're trying to basically optimize or build against. But not the craftsman work that we think of as software engineers. That is the work that you should be doing with the software factory.

McCarthy: Yeah, and I will just acknowledge that as folks go through this transition, there is an inevitable and necessary grieving period that they have to go through because it could be that the reason you were in DevOps was because you didn't want to be a product manager, right? The activity of being a product designer and a product manager or a sales engineer or a seller wasn't attractive to you. Your personality type or your interests just don't flow in that direction, and you enjoy instead appreciating the laminar flow of a deployment system or something like that.

So it's true that we're all attracted to different things, but it's also true in this moment that to discover something new, it is more of that outbound activity that's required. And because we have dramatic amplification of capability on the inside topics that previously we needed large-scale teams to handle, many of the tasks in those do compress in this moment.

Sponsor message.

Producer: We're brought to you by Alation. Healthcare organizations are sitting on some of the most valuable and most fragmented data in the world. How are leading innovators getting that data ready for AI to better serve patients? Alation partnered with teams at Children's Hospital of Philadelphia and Rady Children's Health to document how leading health systems are actually doing this, building trusted data foundations, creating usable data products, and deploying AI that clinicians will actually act on. If you're working at the intersection of data and health care, this guide is worth your time. Grab it free at alation.com/ai-healthcare.

How do engineering leaders react to the idea of never reading code?

James Cham of Bloomberg Beta describes how engineering leaders respond when told a team will not read its code: some dismiss the idea, and others feel relief.

Sangani: James, you've obviously been... as you know, I described you as a hype man. You sort of run around and you said, over the last weekend when we started, you were literally evangelizing this to... Justin came up in 10 different conversations, I think, or something like that is what you said. One, I guess, why are you so hyped about this? And two, what is the response that you get from people most commonly? Or give us the range.

Cham: I think there's a way in which we all now use the same buzzwords to say everything, right? And so there's a way in which you kind of have to spend between 5 to 15 minutes to get to the slightly ridiculous statement, which is, at least to me, this idea that people don't hand-read code. And then the moment that we get to that, then I think there's either... for most people, there's just, "That's obviously dumb," for whatever corner case, or it just does feel so inaccessible to people.

And then for others, there's that sense of relief because for a host of the folks right now who are sitting underneath this interim software development process we're in the middle of, where it's just generating too much code, and they're not sure what to do about it, and they understand there's gotta be something wrong about the way they're building their software. And then for those people, there's actually a palpable sense of relief where they say, "Oh, you know what? Actually, of course, it totally makes sense that if I'm relying on the models to generate this much code, I should be relying on the models to verify it." And the moment I tell them it should be 100x more tokens to verify, there's also this palpable sense of relief because, unfortunately, while we're in this uneasy transition period, there's a lot of stupid conversation around trying to save money.

Why jagged models and CFO cost pressure leave no easy answers

James Cham of Bloomberg Beta says chief financial officer (CFO) cost pressure and methods from Q3 2025 are the main risks, and that AI models are jagged, so no easy frameworks exist yet.

Cham: We're trying to save money at exactly the time we should be trying to figure things out, right? And so there's a way in which the cycle times of this last year and a half have been so fast that suddenly the CFOs have gotten a little too involved, where they're starting to demand the wrong kind of results, just as teams are starting to almost get to this point where they can actually take advantage of the technology. And so that feeling for a number of people I talked to, where they said, "Oh, you know what? Actually, this is obviously right. This is exactly the way I should be doing this, but I just made some promises to my CFO that we'll keep developer tokens per developer below a certain number," which is exactly the wrong way to think about it, right?

And so that's another set of reactions. And then I think for another set of folks, you do have to talk more about what verification looks like. And the fact that verification is the creative process and having the tooling, which just doesn't exist in most places, to actually understand what automated verification looks like. Because it's not like we're talking about formal methods, although sometimes we are. Sometimes it's around different ways of doing screen capture, right? So that entire range of creativity is where the fun is right now.

And then I think the last thing is just as a reminder, these tools are jagged in the sense that they're very good at some things and then very bad at things that seem very similar to the thing that they're very good at, right? And so that feeling and that nuance, there's things that can only be understood if people spend a bunch of time playing with it. And so the desire for easy answers or for frameworks or whatever, I just keep on trying to tell people, "No, no, no, there aren't easy answers yet." The only easy answer is to just keep on playing with it, which I have to admit sometimes goes against, I think, the current zeitgeist for most of corporate America, where they're trying very hard to tame it and to make it seem like it makes sense. But the way they want it to make sense is thinking from Q3 of 2025. And to me, that's the biggest danger. And if I imagine a way that all this would go badly, it is if we were stuck in software development methodologies from Q3 of 2025, which I have to admit many organizations are stuck at.

Should you cap AI token spending per developer?

James Cham of Bloomberg Beta argues against controlling every developer to the median token usage, and expects some developers to use 1,000 to 10,000 times more tokens than others.

Sangani: Yeah, I think people have a hard time thinking in nonlinear terms. And software is linear, generally, or at least it always has historically been: I do this, then I do this. It's linear and deterministic. I guess maybe, but rewinding, the cost thing is really interesting because I guess there's two reasons why costs are going up. One, people are using more tokens, but two, people are also paying for expensive tokens. I assume you're talking really about the people who are using more tokens and not necessarily that you shouldn't save money on tokens or at least use models that are cheaper.

Cham: Yeah. And also there's a little bit of a theory of change that's going on right now, where if you had a 1,000-person developer team, the current thought is that what I really should do is make sure I understand the median cost, right? And then control everyone so they're all stuck at the median usage of tokens, to be fair. And I think that's exactly the wrong way to think about it right now. But actually, I think there are gonna be individual developers who are gonna use not five times more, not 10 times, not 100, like 1,000 to 10,000 times more tokens than the other developer. And to be honest, I think that's okay. And creating the org structure to support that sort of thing is something that we're in the middle of.

Why electrical engineers and chip designers already think this way

James Cham of Bloomberg Beta and Justin McCarthy of Diffusion explain why electrical engineers, who use oscilloscopes, and silicon designers, who track yield, grasp software factories quickly.

Cham: And then going back to your point on software development, which I totally understand because, I have to admit, I was computer science mostly because I just hated electrical engineering too, right? But it is almost no accident that the people who are electrical engineers or have electrical engineering or physics backgrounds understand this new world better than a guy like me, who, to be honest, just kind of wanted to get this algorithm to work, right? And I think there's a systems way of thinking that I think many software developers are not used to, but electrical engineers are actually quite used to.

McCarthy: One note on the electrical engineer observation, they already built oscilloscopes because they realize they can't intuit voltages at a gigahertz. You can't feel what voltage this is at one gigahertz. So they work in time domains and with the speed of light, and so they already know that every process they deal with is a superhuman process, and their whole training has been that. And for the first time, we're experiencing that in software, where it's moving close to the speed of light, right?

Sangani: Yeah. We're so far from the machine. Compilers are compilers, but you still have an intuitive understanding of what they can and can't do as a software engineer, and I know that Java's an abstraction, and I know that I'm able to use it, and it does. But I still have a sense for what's going on.

McCarthy: Exactly. The other helpful one that comes up periodically is the word yield. So you go to someone that works in silicon and you say yield, and you're like, "Yes, my fab has this yield." We've never had yield in a software team before, but we do have a concept of yield and waste and scrap in a software factory, right? And it's totally fine to have a lot of scrap as long as it doesn't make it to the customer.

How do you tell productive token spend from wasteful spend?

Host Satyen Sangani asks how to separate productive from unproductive token spend, and James Cham of Bloomberg Beta answers that a company should make five people 1,000 times better to show the rest of the organization what is possible.

Sangani: Yeah. So James, I agree with you on the point that there are some people spending lots of money in tokens that is tremendously useful. But there are equally some people who are spending lots of money in tokens who are frankly not all that productive. It's not necessarily correlated. I can give a model a lot of dumb things to do. I could also give a model a lot of smart things to do. But talk a little bit about that, because how do you start? I guess you assess the outputs, but...

Cham: Okay, so you assess the outputs, that's the job of a manager in some ways. But also, there's a little bit of a theory of change here, which is, I think right now, more often than not, most big organizations feel like what we really should do is make everyone on the development team 10 percent better, and if we do that, everything will work. And I think that's actually wrong. I think what needs to happen is you need to make five people a thousand times better and then show the rest of the organization that something like this is possible. And this partly goes to... Justin's the one who convinced me of this, right? And so I think that's what you're seeing in practice, Justin.

Why do some engineers thrive with AI while others quit?

Justin McCarthy of Diffusion describes how one proficient person or loop inspires other teams, and why some engineers decide the pace is not for them and open a bakery instead.

McCarthy: This is a pretty common observation that for whatever reason, there are people that take to this moment and seem to be able to wield these models with a level of proficiency that you maybe didn't expect, maybe you did expect it, maybe you didn't. But when it happens, it really shows up. And there's a risk in indulging that observation because maybe in the past, earlier this year, it led to a token maxing sort of a goal, which is not correct. But there is some reality that there are folks, how they've prepared, what they want every day leads to a situation where they have a virtuous obsession with getting this right and a stamina for not tolerating mistakes in the overall loop, and they see it through.

And then once you have an example of that, it seems that other teams and individuals, not every team, not every individual, but it seems like once you have at least one loop and one proficient wielder, other folks can look and can begin questioning, "I have an existence proof that I can see in our domain, in our company. I want to be like that." And by the way, I know this is tough to admit and understand, but there are folks that say, "You know what? There's just too much productivity here. I'm gonna start a bakery." And the right thing to do in that case, if you don't want to work at this speed, is just open a bakery.

And so there are folks that ask to get off the bus when faced with the reality that you really do need to work differently, and your level of intensity, the models do demand a higher level of intensity. You still have to get eight hours of sleep. You have to restore your decision-making budget every night. You have to take care of yourself. You can't be in AI psychosis. You can't be in a mania phase. But once you get through that phase, every minute of your day matters.

Will today's 10x engineers be the ones who thrive with AI?

Host Satyen Sangani asks whether the traditional 10x engineer is the person most likely to adopt AI, and Justin McCarthy of Diffusion says he does not have enough data to say.

Sangani: I want to get back to that, because I've talked to a lot of engineers who have this AI haze. One of my engineers talked about AI haze, and they're just like, "Ah, I just don't even know where, what space-time place I am in this entire world." And I want to get back to that. So we've always in software engineering and development talked about the 10x engineer. In your experience, since you've seen this actually happen, and I know you probably don't have very much data about it, is the 10x engineer the person that's most likely to be the AI-pilled token maxer, or are those unrelated constructs? Is it just as likely that somebody who was a 10x engineer won't get it in the new world? Talk to me about those constructs.

McCarthy: Yeah. This is interesting. I can't claim to have a high enough N to declaratively say what definitely is. There's some interesting Venn diagram that a year from now will be obvious. I will say that there are folks that you are surprised by that you would not have guessed that all of a sudden have taken to it tremendously. And many of those folks weren't even on the product and engineering team at all, or maybe they were a product manager. And their contribution of their intent, the strength of their vector of desire, is so strong that the rest of the system adapts to that. And it might be that they generate a lot of slop, but it's such useful slop that you find other team members jumping in and saying, "This is a great slop stream. We are gonna purify it." And then you end up with these cascades of strong desire and purifiers that ultimately create the totality.

I have just anecdata on folks that are right at the beginning of their career, and they're amazing, and folks that are right at the beginning of their career, and they realize they're in the wrong career, and then folks that are very deep into their career and open a bakery very deep into their career and realize they're a god and can produce everything now. And so I think we're seeing all of these trajectories. The great news, I would say, is that within any organization, if you have more than a couple people, the probability that you have at least one of these X engineers is non-zero. And if you have a few, you can do a lot.

Can you predict who will become a 1,000x AI engineer?

Justin McCarthy of Diffusion says no reliable predictor exists, but that people who never fell in love with the career may struggle to sustain the intensity this work requires.

Sangani: Okay. But no texture-based prediction algorithm as to who's the baker or the future baker or who's the future totally pilled 1000xer?

McCarthy: I think if someone convinced you when you were 19 to get into this occupation because it was a good career path and you never really fell in love, I think it's probably pretty hard to maintain your desire at the intensity that is required.

How do you get past AI haze and decide where your attention goes?

Justin McCarthy of Diffusion explains how to graduate from the AI haze, where agents absorb your attention, to a workflow in which models escalate only the hard decisions.

Sangani: Yeah. So talk a little bit about this intensity haze thing. Give us a sense for why it's so intense and what's happening to drive intensity. I definitely see lots of people who are so AI-pilled that they can't get away from the clients. They just have to be there. Always.

McCarthy: I refer to that as a stage that you have to go through. They will suck all of your attention into those windows of text. I am here to say in October of '26, you can actually graduate beyond that phase. And in fact, you must. You must graduate to the phase where you are allocating your attention, they're not allocating it for you. But that requires a hierarchy of escalation, where the models, as I'm sitting here on the podcast, the models are purifying my decisions so that by the time the decision gets to me, it's only the hard cases. It's 51/49 Supreme Court cases. But 51/49 Supreme Court cases are the ones where you have to do the most thinking. So the unfortunate part is that when you get the system right, you get out of that text haze and terminal haze, and you get into, "Oh, this is a hard decision," and then your day becomes hard decisions.

Sangani: Are these phases a function of a factory or a function of you as a human?

McCarthy: It's both. It's both. It's a function of the sophistication of your pipelines and realizing that just making stuff is not the same as making stuff that's gonna succeed. Just making stuff is not the same as quality. And just getting back to... it's intent and purifying and densifying that intent, and then scheduling that out in experiments where your intent will encounter the real world and give you the data you need to make the next steering input.

Sangani: For any given problem, you have to have a texture for what it feels like and what the limits of it are and where, to your point, the 51/49 exists.

How many teams are running software factories today?

James Cham of Bloomberg Beta estimates that fewer than 1,000 teams in the world have adopted this approach, and compares the moment to the early shift to agile software development.

Sangani: So James, you've been following and really partnering with Justin on this journey for a bit. What's the thinking arc in terms of people's responses as this journey has evolved? How many teams have been totally pilled in this way? And what are you seeing in the wild?

Cham: I mean, it's less than a thousand. Is it less than... In the world right now. It used to be less than a hundred, but now I kind of feel like we are in this place where there are people who are successful here. And also, to be honest, learning the practical boundaries, and there are gonna be new techniques and ways to talk about this. I remember that transition to agile software, and I remember that feeling of just confusion for a while, and then people came up with good words. And so we're still in the middle of coming up with the good words that everyone understands. And so right now we're still in metaphors and trying out things and trying to push. And so we're still in that interim stage.

But I think the thing that everyone who listens to this chat to just remember is that there is a way in which there's great, great value in just understanding what's possible right before everyone else does. Because suddenly you'll be in this position where other people are doing things at a pace where you just don't understand, or there are competitors who will be building or thinking about their businesses fundamentally differently because they assume that their software will be high quality and it'll be very, very quick to produce, and suddenly they'll be iterating and moving faster than you will be. And I think that sense that there are people like that now is no longer a theoretical question, but now it's empirical because people can see this. They can see what's happening in different organizations. And so that feeling is happening right now.

What are the different ways to verify AI-built software?

Justin McCarthy of Diffusion lists verification types, including computer-use agents that click through an app as new and advanced users. Alation Agents apply a related principle by gating agents on evaluations before production.

Sangani: I want to talk about verification, and I want to talk about this idea of brownfield, because I think they're related. But let's first talk about verification. What are the different kinds of verification that exist? How does one think about the verification problem? Because I think ultimately you're designing a system, you're thinking about what are the characteristics of this system, and I think verification is probably the best way of thinking outside in, to your point around oscilloscope. How should I think about the verification problem, and are there structural ways of thinking about that?

McCarthy: You should recognize that there are going to be many, many types, and those types are going to be shaped toward your business. But just to give a few examples. I think James said earlier, just screenshotting in different ways is a great example. So computer use has recently achieved a threshold where, let's say in a mobile app or in some sort of web browser or even a regular traditional desktop app, using it in a high-fidelity, confident way where the model isn't getting confused, that's now possible. So for any given piece of software, you can send the agent in to use it, click around, try things, try things as a new user, try things as an advanced user, try things with a world state that is sophisticated, an evolved installation or tenant, try things with a brand-new, empty tenant.

All of those are possible, and that exploratory activity, when you then reflect on it, can generate common... and essentially do clustering on the exploration and say, "This is something we want to make sure that always works." And then that process itself of exploring and then clustering and then compacting, that whole thing can be a loop. So if I just throw a piece of software, I make a cool new calculator app, I throw it into one of these systems, I come back a day later, and I should have really fast tests, really long-running tests, tests in different languages, tests with different number values, big numbers, small numbers. All of that should just essentially materialize that can bound the intent of my system.

And so that should exist for everything. I think we have a lot of voice applications now. We also have voice synthesis. That means instead of you speaking into your voice-responding application, you should have voice synthesis speaking into your voice-responding application, right? And you're closing loops in those ways.

When should you use formal methods to verify software?

Justin McCarthy of Diffusion explains where formal methods fit, such as an e-commerce package routing algorithm, and why verification demands large amounts of traditional compute. For how agents can help check data, see agentic data quality management.

McCarthy: And so really it is everything. We said formal methods a moment ago. Formal methods also fit in. They're not for your shopping cart application in your e-commerce. They are for your e-commerce package routing algorithm that's gonna figure out which warehouse to send it from and which inputs should be going into that warehouse, and so on. So you should glue together in the totality of your system these extremely rigorous verifications with much more open-ended verifications that are moving around the system in generative ways. All of that leads you to the conviction that in the past 200 years of simulated activity, we've never seen a customer refunded more money than they paid us, right?

And so that's it. It's everything. It does demand a lot of traditional compute, which is why CPUs, and it's another reason why memory is expensive right now, because you need to run traditional compute. Maybe some people interact with large databases and have data and ETL and data dictionary environments and so on. You need to run queries on large databases as a means of verification and make sure all the numbers add up. All that stuff is true. You need to do all of it, but the models can help you do it and can help you do it at a scale that you would not have planned to do previously.

What role does data play in verifying AI systems?

Host Satyen Sangani asks Justin McCarthy of Diffusion when something is a rule and when it is data. Alation Data Quality uses agents to propose quality rules from catalog metadata, lineage, and usage patterns.

Sangani: Okay. And then I guess what's the... You talked a little bit about brownfield, and that gets a little bit into this idea of data. What is the role of data in these systems? And how do you think about that? Because that example that you just gave, we've never refunded a customer more than they've paid us. I shouldn't have to burn a million tokens in a model to rediscover that rule every time. I can state that compactly. I don't need to waste a lot of money to do that. People are now talking about things like ontologies. When is something a rule? When is something data? To me, that's a lot of the system design decisioning that people have to figure out.

How do you test a data pipeline with synthetic data?

Justin McCarthy of Diffusion uses the database idea of pushing down a predicate to separate deterministic rules from generative checks, and describes fuzzing an extract, load, and transform (ELT) pipeline with synthetic data. Tracing data flows with Alation Lineage is relevant when verifying a rewrite of a brownfield system.

McCarthy: Let me use a phrase from data systems of pushing down a predicate. So if you have some high-level query language, and you recognize that you have a columnar database that's really good at executing certain types of queries, you should push down that part of the query to the columnar database, right? And you shouldn't ask the transactional database that question. You should route it, and then you should push down the predicates. There's a version of that for these kinds of verifications where there are certain rules that should never be broken, and you should be able to run those deterministically, and you should be able to make sure that they're the fastest possible test of those constraints.

But that doesn't prevent you from, for example, adding synthetic data to amplify use cases that are present in an ELT pipeline or something like that, right? So you've got your 1,000 records that are flowing through, and they each have some amount of variance in each of those fields. Well, amplify that by 1,000 and actually add even more variance, right? And sample from that distribution, but actually tweak the distribution and go even a little bit further to fuzz the pipeline, right? All of this is possible if it helps you increase your confidence that, let's say, a modification to a brownfield system or even a rewrite of a brownfield system contemplates the totality of what has existed and what could exist.

How will software factories change how companies compete?

James Cham, a partner at Bloomberg Beta who invests in developer tools, describes how software factories may reshape competition. Readers exploring how AI changes enterprise operations can learn about Alation AIOS.

Sangani: Makes sense. James, where does this go? You've spent a lot of time thinking about this outside in. Obviously, as an investor, you've looked at different companies in addition to, obviously, Justin, who you're clearly obviously fond of. Where are we going? Where does this end up?

Cham: Okay. So there's a way in which I've been very lucky with developer tools, and so I continue to invest in developer tools. But I will totally admit that developer tools, in some ways, don't really make sense until the methodology is clear and understood and well adopted. And right now, in some ways, the opportunities really sit with organizations that are able to use these tools to compete in fundamentally different ways. And we're just starting to see the outlines of what those companies look like. And it is everything from being able to come up with different algorithms to do things 10 to 100 times faster than they thought it would in the past, to fundamentally just changing the sales process, right?

And then in some ways, up and down the chain of an organization, there are processes to... not to be migrated to AI, but processes that should be fundamentally blown up and rethought. And that sort of opportunity is the exciting thing and, to be honest, the terrifying thing. And so I don't know what the post-AI, or post-software factory company looks like, but I feel like I'm starting to get sniffs of it. You're starting to get little whiffs of what's working or how people are doing things that are definitely different.

And I think these very data-rich organizations that are now able to do hill climbing in a way that they just... I think you talked about hill climbing earlier. It is very interesting to me that for the first time ever, I was on a flight with an MBA student who used the term hill climbing three months ago. And there is a way in which that understanding, that way of thinking, we're just starting to get to, right? And then that'll shift business in new and hopefully good and probably terrifying ways.

Sangani: Yeah. Totally. That's exactly the conversation I wanted to have. Thank you guys for taking the time. I'm sure we can go on for another episode. This has been awesome. Justin, James, thank you for the moment, and we'll definitely have you back on soon. Maybe in... a year feels like too long, but at some point to be able to figure out where the progress of all this goes.

McCarthy: Yeah. One token year from now, I think, is December 2nd, so...

Sangani: There, you heard it first. We've got token year. Now everything has come back to the space. All right. Well, thank you guys. Have you back soon.

Cham: Thanks so much.

McCarthy: Thank you.

Producer: Everyone's using AI to write code faster. Justin and James say that's the easy part. The models already write code faster than anyone can read it, and next year they'll be an order of magnitude faster. So the question isn't how to review more code, it's how to stop needing to. Justin's answer is a software factory, loops within loops that check the model's work at every level, from millisecond unit tests to agents clicking through the app like real users. His rule of thumb is to spend 100 times more tokens verifying than generating. Designing that verification is the creative work now and the real frontier. None of this replaces time with customers. If anything, it should free you up for more of it. And the way in isn't making every engineer 10% better, it's letting a handful of people get radically better, then showing everyone else what's possible. Thanks for tuning into AI Radicals. See you next time.

Sponsor message.

Producer: Today's episode was brought to you by Alation. If you're in data or AI leadership right now, you've probably got a graveyard of pilots that never made it to production. You're not alone. MIT research shows only 5% of enterprise AI pilots from 2025 delivered real ROI. The gap isn't capability, it's focus. Alation's agentic AI opportunity discovery guide is a strategic framework built to help you cut through the noise. It walks you through the six AI primitives, the friction meets value sweet spot for identifying the right processes, how to build your opportunity backlog, and how to use an impact effort framework to prioritize what to build first. There's even a five-step launch checklist to get your first pilot off the ground. The organizations winning AI right now aren't the ones with the biggest budgets. They're the ones asking the better questions. This guide helps you ask them. It's free at alation.com/ai-guide.