Want this content delivered right to your inbox?

Subscribe to the Newsletter

A conversation with Bryon Jacob, technology advisor and AI strategist

“Low tech debt and high efficiency with AI are two sides of the same coin. You have to have one to get the other.” – Bryon Jacob

In this episode of the New Friction podcast, host Douglas Ferguson interviews Bryon Jacob, a technology advisor and AI strategist who previously co-founded data.world as CTO and spent a decade at HomeAway. Jacob argues that the teams succeeding with AI-assisted software development share one thing in common: rigorous governance — including near-100% automated test coverage, strictly enforced architectural standards, and code bases deliberately organized for agentic development. He explains why zero tech debt has shifted from aspirational to economically necessary, since AI amplifies good patterns and railroads bad ones, making clean, well-documented, thoroughly tested code the prerequisite for real productivity gains. The conversation examines how leaders are rethinking code review, prototyping, and the entire software development lifecycle, including why a CEO drafting a pull request in Claude Code is a fundamentally better spec than any design brief. Jacob closes by drawing the arc from assembly language to compilers to natural language programming, framing today’s moment as the natural next step in a decades-long evolution — and a preview of the governance-driven transformation already coming for legal and every other structured profession.

Listen on Apple Podcasts
Listen on Spotify
Watch on Youtube

This episode is part of the Facilitation Lab Podcast. See all episodes

Show Highlights

[00:00:00] Introduction and the New Friction Premise
[00:02:15] How AI Is Already Reshaping Engineering
[00:07:30] Governance as the True Differentiator
[00:14:00] Scaling Code Review Beyond Human Limits
[00:21:00] CEO Pull Requests and Prototyping Culture
[00:28:00] Code Base Shape and the AI Readiness Gap
[00:35:00] Zero Tech Debt as New Engineering Mandate
[00:43:00] Greenfield First to Win Over Skeptics
[00:56:00] Software Engineering as Canary in the Coal Mine

Bryon Jacob on LinkedIn
Voltage Control

About the Guest

Bryon Jacob is an independent technology advisor and AI strategist based in Austin, Texas, working with early-stage startups on technology strategy, AI implementation, and fundraising. He previously served as Chief Technology Officer at data.world, a collaborative data platform he co-founded in 2016 and led through its acquisition by ServiceNow, and before that spent a decade at HomeAway (now VRBO), joining shortly after founding and staying through the company’s IPO and its acquisition by Expedia. His interest in AI dates to graduate school at Case Western Reserve University, where he studied symbolic AI and machine learning, and he has authored widely cited research on how knowledge graphs can improve large language models’ accuracy over structured data. He is a founding board member of the Texas AI Alliance.

Transcript

Douglas Ferguson: Welcome to New Friction. I’m Douglas Ferguson. AI just made execution almost free, so why are organizations still stuck? Because the friction didn’t disappear, it moved and it multiplied. It’s no longer in the building, it’s in deciding what to build, how to align, and how to move forward when the path isn’t clear. That friction, the human side of change, is what this series is about. Each episode, I sit down with leaders who are living it, navigating the real challenges of AI transformation, not the tools, the people. The task that took two weeks now takes two minutes. The work isn’t the bottleneck anymore. The conversation before the work is. That’s the work this show is about. Today, I’m with Bryon Jacob, a technology advisor and AI strategist based in Austin, Texas. He previously co-founded data.world as its CTO, leading the company through a successful acquisition and has over two decades of experience in tech, including leadership roles at Amazon and HomeAway, now Vrbo. Welcome to the show, Bryon.

Bryon Jacob: Thanks, Doug. Great to be here.

Douglas Ferguson: Looking forward to chatting. And as you know, we’re here to talk about how AI is reshaping roles, especially in the engineering and product. And I think that’s a great place to dive into. I know you have a lot of thoughts there and you’ve been helping a lot of organizations think about what that means. And what have you been noticing as far as the biggest shifts that have happened so far?

Bryon Jacob: Yeah, I mean, I think software engineering is one of the first things to massively transform. And I think a lot of it has to do with the fact that obviously technologists are probably paying more attention to AI, maybe want to be on the earlier edge. But I think a lot of it too comes down to really using AI responsibly to do any job, using it effectively and responsibly to do any job ultimately comes down to what kind of governance do you put on it? And software engineering and the software development lifecycle is essentially a governance regime for how we do software. And it’s one that’s pretty well understood. It’s got a million different flavors and permutations, and technology leaders could talk forever about their preferred variance of SDLC, but everyone doing software for real is executing some kind of governed SDLC. And SDLC is something that usually in software engineering, we have a ton of tooling. Engineers are great at automating everything that can be automated. Forget automating with AI, deterministic automation of things like your CI/CD pipelines, things like that. I think that’s one of the things that’s basically enabled this to be one of the first jobs that can really meaningfully be transformed with AI, because the things it takes to actually govern it, which is what you have to do to get good utility out of it and do it in a safe and responsible way, they already exist. And so most of what we’re doing is really just automating things we already knew how to automate, and then just automating them at a much bigger scale.

Douglas Ferguson: Yeah, I mean that’s a valid point. The other thing is after years and years of automating things, we understand the boundaries where our existing automations were limited.

Bryon Jacob: Yep.

Douglas Ferguson: And so we see these tools and we immediately go, “Oh, I can now add some inference here and get past something where it was difficult to do before.”

Bryon Jacob: Yeah, absolutely. I mean, I think people are trying to use AI to build software. You can find people who are saying, “This doesn’t work at all. All it does is create more tech debt. This is just creating more problems.” Senior engineers are complaining, because all they do is get PRs from junior engineers that they vibe coded with no understanding and shipped without even reading them. Those stories are real, that’s definitely happening. But then you also hear the stories of teams who are getting 5X, 10X of throughput. They’re running 95, 99% of their code with AI and shipping better than ever, that’s also real. Both things are really happening in the real world. And the delta is… And it’s not tools and models, I mean, I mean tools and models are great, Fable is amazing and now everyone loves the latest codex models and it’s all fine, but you’ve been able to do almost fully automated software development where AI is writing 98 plus percent of your code on most problems since at least call it Sonnet 3.5 or wherever you want to draw the bar. The models keep getting incrementally better, but that’s not the fundamental shift. The fundamental shift is how you use them. And is your code base organized in a way that AI can make sense of it? AI is just going to go in there and start copying patterns. If you have good patterns, it copies good patterns. If you have bad patterns, it railbends tech debt into your app. And the ROI has flipped. The return on having clean, perfect or well architected code that’s really well documented and has amazing testing and super high quality bar, is if you have code like that, AI can write that code, AI can work in that code base, AI can add features to it. And the investment side has gone way down, because who’s really great at going and writing a thousand unit tests to characterize your code? That same AI. So it’s like if you get into this cycle of reinvesting the dividends, basically take some of this newfound engineering capacity and use it to basically say, “We’re going to operate in a world where we don’t have tech debt,” low tech debt and high efficiency with AI are two sides of the same coin.

Douglas Ferguson: Yeah.

Bryon Jacob: You have to have one to get the other and you can’t do either one without the other. Yeah.

Douglas Ferguson: The other thing that came to mind too is your point around the junior engineer vibe coding stuff that they don’t understand, I would argue comes back to, if that’s one of the things that delineates the organizations where it’s not working, that also comes back to the fact that they don’t have good governance. Because I would argue that part of your software development governance should be that anyone committing code or any of PR getting approved, that whoever’s submitting it needs to be able to understand and explain the code that they’re submitting. If they can’t, kick it back until they can explain it, because it’s okay “to vibe code something,” but you need to study it, understand it, critique it and decide what needs to be changed.

Bryon Jacob: Yeah, I agree with that. Although, I agree with a caveat, and I wonder how much we agree on this, because this is another interesting scene that always is like… Definitely, I mean 100%, if you’re submitting code for a pull request, you’re responsible for it. The only thing that can take responsibility for a code change is a human, period. Maybe that changes in the future too, but at this point there has to be a governance system and you have to say there’s a person who’s accountable for that change. So I would agree with everything you said that the nuance is, I think we’re evolving quickly to a world where the bar can’t be a human thoroughly reviews every line of code. So not only do I not write almost any of the code that I’m responsible for anymore, I also don’t read every line of the code. Again, it’s automating more and more of this governance structure. So I’m directing AI on what needs to be written. I’m making sure that it’s writing it into a system where it’s going to make good choices and it almost can’t help but to make good choices, and then I’m reviewing it with more AI agents who I know embody the ideals that I would want to see and have an attention to detail and an inability to get bored and miss something that is actually an improvement over me. Mostly, what I’m doing, is I’m reviewing the review.

Douglas Ferguson: Yeah.

Bryon Jacob: Mostly, I’m putting everything through a system of automated review, reviewing that review, and again, still thoroughly and diligently, but with much higher efficiency and much higher bandwidth. And I would say, the majority of the pull requests I review, I approve, go through with me having looked at only a small amount of the actual code. That’s controversial. A lot of people hate that idea.

Douglas Ferguson: Yeah, well, I would argue that the folks that scoff at that, I also kick back to them and say, if you’re being truly honest out of all the code, especially if you’re in a leadership position where there’s a lot of stuff flowing past your desk, do you scrutinize every character on every line when you’re doing these code reads? And the answer’s probably no. And it almost feels safer when I’ve got something written by Sonnet that then Astra’s doing a pass on, Opus is doing a pass on. I’ve got multiple perspectives with different instruction sets. One might be looking for security vulnerabilities, one might be looking for something else. I just see it as a sophisticated instrumentation to help me find issues.

Bryon Jacob: Yeah, I mean 100%. I mean it’s both the only thing that’s going to scale, because I mean at the end of the day, you put a pretty hard ceiling on how much throughput. If you’re saying, “I’m going to allow AI to produce code, but I must thoroughly review every character, every line,” there’s a hard ceiling on how much throughput can go through. And that frankly, leaves human engineers with a job most of them don’t want, which is all they’ve become is peer review machines. But then exactly what you said, you can actually get a much higher degree of trust. And there is a mental leap that people have to make here, which is there’s a notion in there that, well, okay, but what if that reviewer is adversarial? What if the reviewer intentionally is trying to sneak one by you? I’m like, yep. I mean that is a thing that could theoretically happen. However, I think we have enough understanding of the models that we’re using and how you can build blind adversarial reviewer bots, and particularly if you’re going across multiple models, multiple techniques, you can engineer a lot of that out. And then there’s a notion of, well, what if the AI misses something? It’s like, well, the notion of what if the reviewer misses something was always ever present, right?

Douglas Ferguson: Yeah.

Bryon Jacob: Has it never occurred in your entire career that a human reviewer missed something? Well, no, of course it has. You’ve had work done by a great engineer, reviewed by a great engineer, and they still made a mistake. The bar isn’t zero mistakes ever. The bar for can we use AI to write software isn’t does it never write bugs? Bugs are an inherent part of software and they will continue to be forever. The bar is, are we doing as well or better than we would’ve with all human work? And are we putting the right levels of… And again, all these things are matters of degree. Are there portions of your code base that should only pass with a specific review by a specific named human who is directed to only pass it if they’ve actually looked at every line of code? Yeah. There’s probably a 2% of your code base that’s managing how do we manage our encryption keys and make sure that our network perimeter is secure? Yeah, there’s definitely some things that you can’t trust anything but the most senior person whose actual accountability’s on the line to own that decision, but that’s not 98% of your code base.

Douglas Ferguson: Yeah, I think that’s an important thing. It’s like, let’s not have blanket rules that apply across the board. And I would argue that’s true of governance writ large. We don’t necessarily need to write guidelines that apply to legal and every other part of the organization, and we don’t need all the guidelines to apply to every piece of code, because different things are going to have different business impacts. And also I would argue, how reversible is this damage? Because if something ships with an issue, what’s the cost of that issue? And then how easily can we reverse it if something goes bad?

Bryon Jacob: Yeah, 100%. And the reality is, this is another place where your SDLC can protect you. And you start down this path of how do we streamline and improve these processes? And I think the first order thing that I see a lot of organizations do, is how do we just get more efficient at the kind of things we already know how to do? And that’s the right place to start. How do we take those things and turn them up? But then you start to develop whole new ways of working that are really just different ways of applying the same tools. Related to when you talk about the stakes, it used to be that it was pretty expensive, took a lot of time, took a lot of human effort, dollars to pay salaries to go really build out a feature to the point where you could actually really kick the tires on it and try it. It’s no longer the case. And a couple of companies that I’m pretty close with who I’ve seen who are really trying to be on the cutting edge of this have moved to a model where everyone in the company is encouraged to contribute their ideas, their features to the code base in the form of pull requests. Now, that’s not to say that we don’t need software engineers and that organization is not one… The company that I’m thinking of here would not… They have actually a lot of guardrails in place around this. The idea is when the CEO has an idea that he wants to implement, he is totally empowered to open up Claude Code, have a conversation with Claude, work through to the point of having something that works and works well enough in the actual company’s code base where you can start it up, click on it, actually execute the feature, even deploy it off to a shared environment if you want. And by the way, there were cultural bumps here, there was definitely some. “This person has no business and this PR is going to…” the same kind of complaints we had earlier about the PR. But if you reframe your thinking to the idea isn’t this is a pull request ready to be accepted, merged and go to production. The idea is this is fundamentally better in every way than a vague idea that then has to go through a design sprint and a designer designing an interaction and an engineer thinking about how it might get built before we can even talk about does this thing work? You’ve short circuited from the idea that’s in the senior leader’s brain that he wants to get into the world, to something that provably works and sits inside of the application. And now we can take that and do anything we want with it. Now we can go put it through those other steps, like, “Okay, now let’s have a proper UX person think through a better interaction pattern. Let’s go actually make it look the way that fits in our design system. Let’s go actually re-engineer the bits.” But there’s no better spec than a PR that literally works inside of our piece of software and can work. And you can throw the whole thing away and retain none of the code, it’s still a valuable mode of thinking and working.

Douglas Ferguson: Yeah, it’s essentially taking the prototyping culture way further than we’ve ever gone in the past. I’ve also seen organizations creating test harnesses and prototyping harnesses that are idiosyncratic to their environment.

Bryon Jacob: Yeah.

Douglas Ferguson: I’m thinking of one organization right now that is building out a fairly complex new feature that allows you to, I would say, customize and extend the capabilities of their product. And so it’s one of those things that sometimes you really need those use cases for that sort of thing to come alive and to imagine how much capability should they build into that sandbox, because they don’t want to just build an entire dev kit to build anything, right?

Bryon Jacob: Yeah.

Douglas Ferguson: They’ve got to have really good primitives and they got to think about how is it connected to other data sources and that sort of thing.

Bryon Jacob: Yeah.

Douglas Ferguson: And so being able to dream up use cases and see how that actually functions in the real world is really important. So they actually built a prototyping harness that allows you to simulate very, very quickly the environment. So you’re not actually building a PR necessarily, but it’s super close to that, because all of the Chrome and all the pieces where this thing would live, that environment’s supported and really easy to dream up your ideas. And I think we’re going to see more and more of these kind of custom tools that would’ve been cost prohibitive to build, but now we can generate them quickly, and maybe even throw them away after that season’s over.

Bryon Jacob: Yeah, no, totally. And that’s exactly that. It’s like however you do this, I mean, I think that’s a perfectly great pattern, and I think it’s honestly essentially the exact same thing as the company I was talking about. The only difference is that company’s invested so much in their test environment for their developers that it was like, “We already have a perfectly good prototyping.”

Douglas Ferguson: Yeah.

Bryon Jacob: It’s the product itself, but same exact idea. You had to get over this stigma of, “It’s a PR. We can either keep it, we can completely rewrite it, or we can throw the whole thing away and say that was an abandoned idea. And at the end of the day, what did we spend? A few tokens.” Right?

Douglas Ferguson: Yeah.

Bryon Jacob: It’s faster to throw stuff at the wall and try than it ever has been before. It just changes the economics of certain equations. It’s like, “Should we do this way A, B, or C?” Honestly, it’s faster to build A, B, and C and actually click on it than it is to pontificate about which one would be better, right? Yeah.

Douglas Ferguson: Yeah. And I want to talk a little bit more about governance, and one of the things that you said as we were leading into some of that was how important it is to consider the shape of your code base. You mentioned if you’ve got a lot of good patterns in there, there’s a lot for it to rely on or copy, and if there’s a lot of bad patterns or lack of consistency, it’s going to maybe go do things however it might feel it wants to in the moment. And I think also there’s other implications to the shape. It’s almost like Conway’s Law rearing its head again in new ways, right?

Bryon Jacob: Yeah.

Douglas Ferguson: And one of the examples I think about is legacy software that might be monolithic, it might be sprawling and complex, unnecessarily complex, because they never decomposed it properly and it just got built on and built on and built on, and now the surface area is just way too wide for it to do justice by the context window. And so I’m curious, are there other things or does anything come to mind as you think about the implications of the shape of the code base or how we even prepare it to be more agentic friendly?

Bryon Jacob: Well, yeah, you basically set out my soapbox here, because this is the thing that I think I am the most opinionated about of anything right now and the thing I care the most about right now, is I think this is the unlock. Ultimately, I think this is how you do it. Every version of every team I see effectively working AI into their software process ends up leaning to some version of this. So you talk about the legacy, monolithic applications, the things, there’s a couple of dimensions to that, but the key thing is, like we were saying earlier, I think zero tech debt has to be the new mantra. We can’t afford tech debt. Tech debt was a very useful tool for decades. We all built software with lots of tech debt. Why do you take out debt? Same reason you take out a mortgage to buy a… I can go buy a house that I can’t afford today and pay it off later. And that’s essential if you’re operating a financed software startup, because you’ve got to go chase that next top line feature. And so you’re like, “Well, it’s the quickest way to build this, get a feature out, turn it into revenue so I can go chase the next hill. We’ll pay tech debt down in the future when we have lots of money and we can slow down,” which translates to never. And we all did that, we did it for years and you manage the tech debt. Well, now it’s that ROI equation I talked about earlier. You can afford to pay down your tech debt because you have machines that can help you with it and you can’t afford not to. And so then it becomes how do you actually do it? Because that doesn’t magically solve the problem. You cannot go into a messy monolithic code base and just say, “Claude, solve all my problems, make this a perfect pristine code base.” What perfect to pristine means is it’s absolutely dependent on the application to some degree. There’s great patterns, but there’s not one great true pattern that rules everything, it’s just like, here’s the magic. This is why the job of software engineering isn’t going away, but it’s going to change substantially. The job isn’t turning somebody else’s ideas into code. The job is understand how software is architected and apply that thinking and bring that to the table. So you mentioned legacy code. My favorite book for the AI coding era, and it was written I think 25 years ago, so way before any of this was happening, but it’s the most relevant thinking. This is the most practically applicable book I think most software leaders should read if you’re trying to figure out, “How do I take this code base that’s been around before AI and make AI work with it?” It’s called Working Effectively with Legacy Code by Michael Feathers. And the first thing he does, which I love in this book, is he defines legacy code as code without text. He’s like, “We can all talk forever about what good code and bad code look like, and so you could say it’s legacy because it’s bad, but that’s somewhat a matter of taste. We could talk about monolithic versus broke, but there’s pros and cons to every angle of that. It’s always about taste. We could talk about whether it was old, but honestly, code could be reasonably well done and produced last week, and I would still call it legacy, because it’s legacy if you don’t have test cases that force it to hold its shape because you don’t understand what it actually does in a formal way that you can check, and you therefore aren’t able to change it safely.” And we all know that general principle. So the principles in this book, the high-level principles are things we all know. The details are actually pretty great. And he goes into something that he calls characterization testing. And it’s like a lot of teams look at a large untested code base and they say, “Well, I don’t want to go add a bunch of tests to it. What if I just write tests that codify the wrong things? What if I just go enshrine a bunch of defects in my test cases?” And Feathers addresses this. He’s like, “Actually, that’s fine.” He’s like, “The purpose of going and writing a thousand unit tests on a legacy code base isn’t to weed out all the bugs. You’ll probably find some bugs and fix them on the way.” But the point is you don’t actually know what the code is supposed to do, because there’s probably not a written spec and there’s certainly not enough tests. So you go characterize the code with a bunch of tests and say, “Well, this is what it does.” You formally write down, “I have a formal check of what it does.” And the whole point is now as you go forward and change, you don’t know whether everything you’ve written down is correct behavior or not, because you have no formal definition of correct. What you do know is whether it changed or not. So now you can go start to rip it up and replace it. And so that’s where you get into then you break down the monoliths, you clean up the legacy architecture. I think the playbook for teams, I mean, this is the thing, every company I’m advising and coaching, the high-level playbook is easy, the details are what is hard to actually figure out on a project-by-project basis. But I mean the playbook is one, the new bar for automated test coverage is 98%, right?

Douglas Ferguson: Mm-hmm.

Bryon Jacob: It used to be the gold standard is you get to 70, 80 and you’re like, it’s diminishing returns. No, because there’s no reason not to go for as close to 100% as you can get. And yeah, there’s 2% of config code that’s hard to measure, that’s fine. But I want fast unit tests at the lowest level possible mocking everything outside of a dependency chain that give me 98% test codes. Why? Because that tells me I can change anything and didn’t break it. And then I go through like, okay, now what is the architecture of this system? And if it doesn’t have a clean, consistent architecture, it needs to have one. You need to write one down. You need to say, “Well, this is my target architecture that I want the app to have. Where am I violating that?” That’s a refactoring opportunity. And so then what are the chess moves I can make that go one step closer to, I have everything in a clean, modular, decoupled architecture? Sorry, I’m rambling for a long time. You hit a nerve here. Just to say, I think those are the key things you do. You have to put that scaffolding up in terms of tests to be able to make these changes. You have to go ahead and invest in these. And then the last thing I’ll say, is the culture on teams is I think a very common culture, and I saw it on essentially every team I’ve led. I don’t think this was some unusual toxic culture, I think it was the normal culture that we actually have to change, was we got a bunch of smart people and so we’re going to agree on a few basic principles of things and our basic rules of the road. And then mostly it’s going to be, “Well, we’re all smart. We’re going to trust each other in there and write good code.” And what that means, is when you go in and look at a module, you’re like, “Well, Bob wrote this code, so it kind of looks like Bob code. And then Dave came along and wrote this code, it kind of looks like B code. It’s all pretty good. It all basically works and it follows our high-level contracts.” I think that era is dead. I think you have to get much more opinionated as a team. I think the code base, each code base has to know what is your architecture and it has to be consistent. The whole team needs to put their head together and decide what we’re going to do, and everyone gets a voice. But once that’s been decided, it’s decided and it’s not you’re allowed to check in. There is no more opinion on a PR-by-PR basis about how we’re going to write our code. It is, “We’re going to write it in this architecture. It’s going to be clean. It’s going to follow all these rules, and the code base is going to enforce it. If we don’t like these rules in the future, we can change them, but we can’t ever break them.”

Douglas Ferguson: I think part of that was driven by the fact that it was so onerous to sit down and try to document it and come to a consensus on what it should be. And then also, it’s onerous and laborious to enforce it.

Bryon Jacob: Yeah.

Douglas Ferguson: And those two things have changed dramatically.

Bryon Jacob: Yeah, exactly.

Douglas Ferguson: The ability to feed in some general… The vague contracts that we already agreed upon, let’s feed it in and have it generate a document of high specificity that we’re going to follow, and then have everyone review that and decide if there’s anything we want to change or tweak.

Bryon Jacob: Yeah.

Douglas Ferguson: I mean, the fact that we can draft that specification document on how we’re going to shape our code is also accelerated and so fast, it allows us to get into critique mode versus generation mode, and that really opens up… We’re so much better critiquers than we are generators.

Bryon Jacob: Exactly.

Douglas Ferguson: And so if the team can critique and get to some consensus there, then the onerous part of enforcing it we can hand off to the agents too, because now we’ve got this really well specified process and shape that it’s just looking for and measuring for.

Bryon Jacob: Totally. One other cheat code I love, is just pick your favorite named architecture that matches your ideology as closely as possible. And again, if you’d asked me two years ago, I would have said I’m not that opinionated, there’s a lot of great patterns to follow, and the one that I use the most now is, if you’re familiar with the concept of hexagonal architecture, which is domain-driven design. And again, I think the two things that I think are great about hexagonal architecture in this area, one, it’s extremely prescriptive. Not a lot of teams adopted it, because it forces you to overly anal retentively put interfaces and separation of concerns around everything. And the common complaint was, “Yeah, I got to go write 30 lines of boilerplate code to add a method to this adapter to this third party system, whereas I could just go add a method, and I’m probably never going to switch courses, so being coupled to this one external integration is fine.” But because it’s so prescriptive, it actually forces you down this path on everything. And then the second thing about it is it’s really widely written about. The people who write about it have written a lot about it, which means every foundation model has read 30 different angles on hexagonal architecture and understands what it means really well. And so it’s like a token compression on a really, really aggressive opinionated architecture. You can go into almost any project and basically say, “This is kind of a mess with stuff that seems overly coupled. I’d really like to reorganize this into a strict hexagonal architecture with all the domains clearly delineated. Could you help me do that?” And I almost just gave you the prompt you need to go into a project to basically send an AI off to go do the whole research project for you. It doesn’t take a whole lot more than that to then go come up with a catalog of here’s the 10 bounded contexts that should probably exist and how we might architect it. You probably need to… That’s not enough for it to go do the work, but that’s certainly enough for you to send Claude off to go do your librarian and archeology work to tell you where the bodies are buried, and it helps kick off that session.

Douglas Ferguson: Yeah. And I think that’s the thing that so many folks miss, because they see all of these single shot builder tools like Lovable, et cetera.

Bryon Jacob: Yeah.

Douglas Ferguson: But spending a good chunk of time, to your point, writing test cases for existing code, doing archeology on it, coming up with a plan for how we might shift things over. And if we don’t attend to that stuff, then it’s going to be a lot more difficult to add onto new things to it, because if we’ve got a shaky foundation and we’re adding more stuff, it’s hard to blame the AI for that. We were going to have a hard time as well.

Bryon Jacob: And that’s it. I mean, honestly, it’s like almost universally, the things that you do to make your code better able to be worked with AI are the exact same things that make it easier to work with for humans. I mean, at least I haven’t hit diminishing returns yet. This has been mostly the only thing I think about professionally for two and a half years, and I haven’t hit diminishing returns yet on… Almost always the way I improve something about how using AI for software development is more rigorous application of something I’ve known about for 30 years that we could just never afford to do, and now you can afford to do it. That’s an almost bottomless well at this point. There’s very few things that I would say that I’ve done that are AI… Even some things that felt AI specific, ultimately that’s just how humans read too. Really, this is a little bit in the weeds detail, but it’s an interesting note. Even as some of the other models have started to outperform it as a model, one reason I still love working with Claude, is that its harness makes a really smart decision of the way it handles its Claude MD context, where it’s strictly hierarchical. As you read a file anywhere in the tree, it reads all the Claude MD files down. That gives you an architecture, where you can load a lot of context into those Claude MD files. You can have hundreds of those files in a large repo. Each one is relatively small, a hundred lines of text at most. And then when I’m reading down a deep path, I can see the rules of the overall repo from the top, and then the rules of the sub-project and this monorepo there, the rules of this sub-module, the rules of this specific package. I’m reading four or five Claude MDs which add up to a really great system prompt that’s going to give me super fantastic context, but I’m reading a few thousand words as opposed to the hundred thousand words that exist in the whole repo. And that was one of the things I’m like, “Oh, well, this is one of those things that’s kind of unique to the AI era,” but not really, you could easily imagine that organizing your ReadMes that way for human developers five years ago was just as important. And again, you couldn’t afford to do it, now you can afford to take all that context, spread it out like that, and then you could put an automated librarian task that just runs on CI/CD continuously. And is like, “Hey, every once in a while, let me just go audit all these pieces of documentation and make sure that they’re accurate with the code.” Don’t let the docs drift from the code too much without scooping up and fixing it.

Douglas Ferguson: That’s a good point. I’m a big fan of creating routines that are basically drift alerts for all sorts of things, right?

Bryon Jacob: Yeah.

Douglas Ferguson: I have tons of monitors running just to detect if a routine has gone sideways or maybe my RAG system embeddings have gotten a little bit degraded in some way.

Bryon Jacob: Yeah.

Douglas Ferguson: And that’s another thing I don’t see enough folks doing. I see folks putting evals in place if it’s a feature inside your product that’s leveraging AI, to make sure that we’re getting the accuracy we want so that we don’t impact our customers in a negative way.

Bryon Jacob: Yeah.

Douglas Ferguson: I think that there’s a lot of room for more eval when it comes to our process and how we’re operating and the results we’re getting from building with AI. And then if we have eval suites and we set up things like that, we can run those in an automated way to make sure those things aren’t drifting or getting out of sync. And you talking about scanning the Claude MD files is a great example of that.

Bryon Jacob: Yeah, no, I totally agree. I mean, anything that’s there to basically improve the performance of an activity that has a heavy inference is something that’s subject to an eval, I mean 100%. I mean that’s just application of governance going back to the theme of this, that’s just how do you govern the things that are basically steering inference heavy tasks and make sure that they’re continuing to perform within bounds?

Douglas Ferguson: You did mention this idea of a good place to start, and I want to revisit that a little bit maybe in a broader context. So say you’ve got an organization and they’ve been a little bit reticent to dive in. I see people using it, maybe different developers are using different tools and there’s not consistency there. They might be using an auto-complete insight cursor, but not any heavy agentic work. They might be using it as an augmentation of themselves to help with code review or help read through some production logs or whatever, but there’s really no systemic use and there’s certainly no solid governance. And that may be the limiting factor because no one’s set the governance, so people are afraid to just really lean in because they don’t know how and when and what’s safe. And so I’m curious, what are the killer first use cases that really can get people convinced that, “Oh, this is safe and this is something that’s going to have a meaningful impact on our development process?”

Bryon Jacob: Yeah, I mean it’s extremely hard for all the reasons we’ve talked about here, because you brought up the way it starts getting rolled out at a lot of organizations. A lot of organizations are like, “All right, well, let’s get our team the tools,” and you can buy them all the best tools and buy them tokens and do the thing. But the problem is that if you and I are working in the same code base and you have a dedication to a certain practice and a discipline and a way you’re going to govern it and the way you’re going to write code and I don’t, there’s a hard ceiling to how well you’re going to be able to work inside of a code base that isn’t actually governed to basically be something that AI can work into. And so you have to get to the point where it’s a top-down commitment from the leadership, from the people who own the quality architecture of the code to say, “We are going to operate this code base as an agentically developable code base,” which I think flash forward 24 months is just code base, because the notion that we’re going to go back to people writing most of the code is, to me, completely off the table and that future’s here, it’s just not evenly distributed yet. But then to really answer your question, I think the way you jumpstart a team, the best way I can see to jumpstart a team is do something greenfield, because all the things that make it really, really hard to get this up and running are basically dealing with legacy code. And so if you start by taking that off the table and if you have one small problem that you can just go in and greenfield, either a completely green repo or even just a green module inside of one place where you’re like, “This little garden is going to be… We’re going to commit to making this garden perfect. We’re going to architect this from day one, we’re never going to let it steer off the rails. 100% test coverage is the rule from day one,” you can win people… I’ve seen this happen plenty of times. You can take the biggest skeptics in the world and turn them into your advocates when you show them, “No, look, I can really go build something in a week that you would acknowledge would’ve taken six months, and the quality of the code is provably higher, better, easier to read, understand, work with than the code it would’ve taken you six months to handcraft.” That flips the skeptic. You can no longer argue this can’t be done once you’ve gotten that proof point inside your organization. Then the harder nut to crack is for sure, how do you go apply that same reasoning to an existing code base with millions of lines of code that was built by multiple generations of humans over a period of time? And that is a harder problem. It is now at least a tractable problem in a way that it wouldn’t have been without AI assistance.

Douglas Ferguson: Yeah. Well, I think what’s compelling about that and also makes that leap easier is that instead of just picking one component in the SDLC, you’re saying, “Let’s pick a project that has some nice boundaries to it and let’s do the whole thing soup to nuts.” And that way we’re not just saying, “All right, we’re going to get everyone writing a regression test or a unit test with AI.” You’re only focusing on one part of the SDLC and then trying to make that leap into the other areas of the SDLC is much more difficult. So I like this end-to-end approach on a more bounded project.

Bryon Jacob: Yeah. I think you almost have to do that. I mean, again, you want to keep the scope small enough that you can actually go in and prove your point in a week or so, but you have to go end-to-end with something because it really is all holistic. There’s no magic bullet. People are waiting for, “Just tell me how to AI-ify my thing.” It’s like, well, I mean, you can do that, but it involves a rethinking of… And it’s an uncomfortable thing too. I mean a lot of people are just uncomfortable with the idea that, “I’m not going to sit in front of my IDE and type Python or JavaScript into a text editor anymore.” I mean, one analogy that has helped a few people, there’s a couple of people who are on my teams who are… I guess you have to be at least my age. I’m about the youngest you can be for this analogy to work. One of the engineers on our team who’s a couple years older than me was like, “Guys, I’m just really uncomfortable with the idea that I’m not going to actually write the code anymore, that this code’s going to be… And well, isn’t it a bad thing that we’re going to lose that skill and isn’t that important?” I’m like, “Well, I don’t know. How’s your assembly?” He’s like, “What do you mean? I haven’t thought about writing assembly code for 25 years.” I was like, “Exactly.” But there was a time, if you were a self-respecting engineer in the late ’90s you wouldn’t have trusted a C compiler to write performance enough code for the most memory sensitive stuff. You would have to be able to drop down and write a little bit of assembly to do anything that was real if performance mattered. And what happened was for a while, people kept trying to make assembly a little bit better and make it easier to write. And eventually we just realized humans don’t think like that. We would be much better by having higher order structured languages and just invest more in making the compilers really, really good to the point where a C compiler is going to take well-written C and produce better machine code than the best human writing assembly on 99.9% of the problems. Do people still write assembly today? Yes, but it’s a very, very niche thing. You’ve got to be right down at the mettle doing the most device specific stuff. But all that same machine code is still there. Already, I mean, people write JavaScript, but really mostly people write other programming languages that we’ve invented on top of JavaScript that compiles down to the kind of JavaScript that actually runs in our browsers. This is just that same evolution. We’re mostly not going to write the actual compilable code, but that was never your value as a software engineer. If your value was just, “I could take someone else’s perfectly written spec and convert it to JavaScript that compiles,” I’m sorry, that job doesn’t exist for people anymore. It’s not economically feasible for that job to exist. But that was never your value as a software engineer. Your value was being able to understand this architecture and the systems side.

Douglas Ferguson: Yeah. When you said you’re the youngest to maybe understand that, I thought you might be going to the story I like to tell, which goes back even further, which is if you’re writing code using punch cards and you are super married to the punch card and didn’t believe keyboards were the way to go, that’s a similar situation, right? Are you really that married to the keyboard?

Bryon Jacob: Right.

Douglas Ferguson: Because at the end of the day, we’re still architecturing, we’re still designing the systems, it’s just how are we inputting the information?

Bryon Jacob: Yep, totally.

Douglas Ferguson: So before we wrap up, I’m just curious, we talked a lot about governance. There’s a few things you mentioned, including near 100% code coverage, being opinionated and consistent so that the patterns are clear for the AI to replicate, or at least being clear and consistent in what we expect so it follows those rules. And then also this idea of the hexagonal domain-driven approaches. Curious what other governance or approaches, like a lightning round on what are the things that folks should be thinking about when they’re putting governance in place, the requirements? I mean, I’m sure it’s a lot of the same stuff we’ve been doing for years, but some of it’s shifting even slightly.

Bryon Jacob: Yeah, I mean again, that’s really the spine of it. I mean, your testing needs to be ludicrously more thorough than it ever was before. Your architecture needs to be opinionated, written down, strictly enforced. You need to have alignment on your team that you’re going to do that. You really need to beef up the CI/CD, the pipeline rules of what’s allowed to come in and out into your code base. You mentioned evals, and I think there’s evals and a slightly broader view of just continuous improvement on these agentic flows of which evals is a big part of it. I think that’s a huge thing. I think this isn’t exactly the answer to your question, but it’s related. One of the things that I started seeing with people who I know who are really on the cutting edge of this, really pushing the how much can we actually get AI to produce all the code? How much leverage can we really get on a per engineer basis? One thing that I’ve started noticing is we’re now getting to the point where I think this is a good thing, we’re starting to have to solve some new problems. And some of this is definitely my fault on companies I’ve given advice to and I’m helping them unwind it. Sometimes you have to cross the line to find the line, and we’ve definitely crossed the line to find the line in a few places where this very rigorous like, “okay, we’re going to have automated tests for everything, 100% coverage. We’re going to have this rigorous end-to-end test suite. We’re going to really…” As that has been very successful, we built all these automated checks in. And then because of that, we’ve increased velocity to the point where it’s like, well, now you’re getting 10 times the PR volume through. It’s like, well, actually, what was actually a reasonable set of CI/CD rules to run every PR when you had the kind of volume that unaided units can produce? That was totally normal. Now, if you have that same volume of PRs, the first thing that starts manifesting is like, “oh no, my GitHub Actions bill is now out of control and I’m literally spending as much money on GitHub Actions to run very expensive CI/CD checks continuously as I am on my tokens.” Or you get into a log jam where it’s like, “Okay, I can now produce more PRs in a day than my automated deterministic checks can run.” These are all super solvable problems. This is the sort of thing where these are easily solved problems. Okay, obviously I can’t run 30 minutes of tests on every single PR when I’m pushing four PRs an hour. The math just doesn’t math when you’re doing that. So you have to figure out how to pipeline things better and better optimize your tests, run them in different phases, collect up six PRs before you go run your full test suite, because you just don’t need to run the full test suite on every one. These are the class of problems I’m starting to see now. These are high class first world problems, all right? If you’re getting to the point where we’re producing so much code and it’s of generally such high quality that we want to accept all of these PRs and we’re moving features this fast, but we’re now pushing ourselves to all the automated checks we need to keep it safe or taking too much time, these are the fun problems that I’m seeing people trying to solve now.

Douglas Ferguson: Yeah, that makes me think of two things that I wanted to highlight for the listener. One, is this thing you’re describing is also applicable org-wide when you start applying AI to processes and systems.

Bryon Jacob: Yeah.

Douglas Ferguson: So basically, what you’re describing is there’s a human shaped process or a human scoped process that now we’re shoving agents through. And your other point around it’s easily solvable, the performance and throttling can be easily solved, and often the right approach is fairly easy. But sometimes the obvious solution, i.e. let’s fix the throughput in some way, like maybe running them in batches or whatever, might not be the right solution because stepping back and going, “Hey, wait a second, the agents sending stuff through this at a volume that we never expected because this was designed for humans, is causing issues. Let’s step back and rethink this. Now that the friction has exposed itself, let’s think about what this means for the future, not just fixing this problem that we’re noticing right in this moment.”

Bryon Jacob: Yeah, no, I totally agree. And I mean I think as a general class, not every solution to these problems is easy or straightforward. I think that specific one around your build bottlenecking, that’s one that happens at human teams at certain scale.

Douglas Ferguson: Yeah, yeah, fair enough.

Bryon Jacob: And so that’s one that has some patterns. But you’re totally right, I mean, the phenomenon is sometimes, and this goes back to one of the things I was saying earlier too, you’re hitting it on another front, which is that sometimes it seems like these things are just qualitative differences like, “Well, we’re doing the same thing, but we’re doing it faster and at more scale.” But when the scale gets magnified to a certain point, it’s like, well, that quantitative difference is really actually a qualitative difference at some point. It’s like this is the same thing a hundred times faster, which becomes actually a qualitatively different thing. A friend I’ve worked with, he was saying this phrase about a year and a half ago, people were asking him, “Well, how much faster are you at engineering tasks with AI?” And he’s like, “That’s not the metric.” He’s like, “The metric is the number of things I now do that would’ve never seen the light of day, because doing them would’ve cost too much before.” He’s like, “Yeah, on the things I was going to do anyways, I don’t know, five times as fast, 10 times as fast.” But he’s like, “My thing is now I have the giant backlog of the last 30 years of every fun project I ever wanted to do, and all the ideas I had where I’m like, well, I’d love to go build that, but it would take me a month of weekends and I only have so much time to give. Now I can take one of those ideas, put it in front of Claude and have the result in an hour to play with. I’m doing all of them. So it’s infinite. The speed up is infinite. A million things that I would’ve never even started, I finish five of them every weekend.” And that’s where you change this quantitative speed up just becomes a qualitatively different thread.

Douglas Ferguson: Yeah, there’s two things that come to mind there. One, is the opportunity cost equation, where it’s like, “Oh, where do I invest my time because it’s a limited resource?” So that’s a qualitative change, because now that equation shifts in a big way where it’s like, “Wait a second, I can pursue all these opportunities.” And then there’s also this aspect of, “What am I getting exposed to? What am I learning by doing these things that I would not have known before?” So it’s not about just pumping more volume through, it’s about connecting the dots in a way that really allows us to level up in a brand new way. And in fact, if you look at everyone sees technology gains as a way to… They look and like, “Oh, well, if we can speed things up, we only need five engineers instead of 50.” Humans never work that way, right?

Bryon Jacob: Yeah.

Douglas Ferguson: Once we speed things up and make new discoveries and the possibilities have now shifted, we level up in some whole new way. There’s so many examples of that. In fact, a friend was just telling me the story about Snow White when they originally animated that, how many animators it took. It was like, I don’t know, it was in the hundreds or whatever. And then you look at the latest X-Men or whatever with all of these sophisticated digital animation tools, and I don’t know, 95% of it’s completely animated. And you think, well, the computers can now do all that stuff, but it was 3,500 animators. So it’s actually requiring more people, because we just push the boundaries of what we expect and what we want to do. To your point, it’s not just a quantitative game.

Bryon Jacob: Yeah, no, I agree. A lot of people talk about Jevons Paradox now, which is the phenomenon you’re talking about, where we create new capabilities, and therefore you’ve dramatically reduced the cost of certain activities and increase the throughput, so now you can do more things. Yes, it would take fewer people to produce an animation that looked just like Snow White, but we don’t produce animation like that. We spend the overage on making better, better things. I don’t think there’s any reason to think that we’re at the ceiling of human capability on almost any axis where we couldn’t do more things better. I mean, I do think one thing we’ve talked a little bit about here, a theme is I think that software engineering is in some degrees the canary in the coal mine. It is one of the first things to fall and change dramatically with AI. I think superficially people think, “Well, of course software engineering can be automated more, because software engineering is computers, AI is computers.” That’s a superficial connection. The real connection to me, I think, is more about the automation tools around governance. That’s why this job in particular gets tackled first. I think that is the bigger driver than just it happens to be computer programmers are the kind of people who would care about AI. I do think that’s mostly a superficial connection. And why that’s important is, I think that over time, the same patterns we’re seeing here end up, basically, this ends up being the pattern by which almost any job that people do can become more and more automated by AI and start to become subject to these phenomenon of the exact question you’re asking is like, “Well, do I do the same amount of work with fewer people or are there fundamentally new ways of working when I can do that work a thousand times faster?” And we’ve already hinted in this conversation, software engineering is, I think, by far the most changed profession. Legal’s not far behind for a lot of the same reasons. It’s a very regimented information processing kind of thing. So it’s going to be a spectrum, but I think a lot of the things that we learn as we go through this change in the software engineering practice are going to trickle down and imply ways that a lot of the other work gets transformed.

Douglas Ferguson: Yeah, that’s interesting that you mentioned legal, because I was going to say there’s evidence for this hypothesis or this observation you have, because I’m noticing it in legal where they’re moving quite quickly on this stuff. And honestly, in some organizations where there’s resistance on the engineering side, I see legal adopting it more than engineering.

Bryon Jacob: Yeah.

Douglas Ferguson: And to your point, it’s structured, there’s governance in place, they have very explicit ways of doing things and guardrails around stuff. And also there’s a lot of documented process, right?

Bryon Jacob: Right.

Douglas Ferguson: They are upholding laws that are well documented and the language is very specific. It’s just a matter of time before more jobs are impacted. I don’t think anyone’s going to sit this out.

Bryon Jacob: Yeah, I agree.

Douglas Ferguson: So I want to invite you to leave our listeners with a final thought.

Bryon Jacob: Yeah. I mean, we’ve already talked about it a lot, so it’s a little bit of rehashing, but I mean, for me, I’m focusing so much, have been for the last couple years, on how do software engineering teams make this shift? We talked a little bit about this. This is an economic force. Actually, you can like it or not like it, this is definitely happening. I think the proof is clearly out there that we are going to produce most software code, if not all software code, with AI authoring. I think that is just a natural evolution. I don’t see it as a fundamental change, certainly not as an end to software engineering as a human pursuit, and I don’t see it really as much of a fundamental shift. As impactful as it is, I think it’s a natural curve. We talked about assembly language and compilers, and in a certain sense, this is really just moving up that stack. I mean, we’ve always talked about how the best programming language would be just natural language. Why do I as a human have to come down and talk at the level of a computer in order to get my thoughts across? Why can’t the computer come up and talk at my level? And it’s a little scary and intimidating, but also really fun and extremely exciting to be at the point in history where that’s actually possible to a much, much larger degree than it ever was. In fact, I would say, we are there. The computer is not as good as me or as good as any solid engineer at deciding the best architecture, making all the best judgment calls. It’s not a logical reasoning machine, at least not yet. It simulates one really well, close enough to fool people on a lot of dimensions, but there’s still a role, at least for now, for a smart engineer to be involved and help and make those decisions and steer. So I really think of it more as, I still program all the time. In fact, I program more than I have in my entire life, I just do it conversationally. I do it with English. I do it by typing instructions out. I do it when I go on a walk and turn on voice mode and have a 30-minute conversation where I fully spec out a feature and then I get back to my computer and copy it. Sometimes it’s more sophisticated than this, but often it’s still as unsophisticated as copy paste the output of that chat from one chatbot into the input of another and say, “Here’s a thing I spec’d out while I was on a chat with another chatbot. Please go build it according to the architectural principles in this project and work through that spec.” I think the thought that I want people to understand, is that future is already here. The teams who are saying, “This doesn’t really work for us and it’s making things worse,” they’re right, but I would argue they’re doing it wrong and they haven’t figured out what to do. The teams who are getting high effectiveness, that is real. I’ve seen it with my own eyes, it definitely works. And it really comes down to just rigorous application of the engineering practices we’ve always known we would do if we had infinite time and resources, and now we almost do.

Douglas Ferguson: All great points. Bryon, it’s been a pleasure chatting. I’m looking forward to chatting with you again sometime soon.

Bryon Jacob: That was a lot of fun. Thanks for having me on, Doug. I appreciate it.

Douglas Ferguson: Thanks for listening to New Friction. If you enjoyed this episode, share it with a leader who’s in the middle of this right now, they’ll thank you for it. And if you want to go deeper, we bring leaders together through executive dinners and virtual masterminds. To learn more about our work or to inquire about exclusive executive events, visit voltagecontrol.com. I’m Douglas Ferguson, see you next time.