AI ate the easy bugs. Undo’s CTO isn’t worried
Mark Williamson has spent more than a decade helping engineers untangle code no human understands — and now he’s teaching AI agents to do the same
Most bugs are shallow. Annoying, but survivable.
The ones that cost millions, buried in code written 30 years ago by engineers nobody can track down, are Undo’s business.
Founded in Cambridge in 2005, Undo makes time travel debugging tools that record a program’s execution so engineers can replay exactly what happened. That gave CTO Mark Williamson, who himself is a product of the Cambridge startup scene, a front-row seat as enterprise customers adopted AI coding agents “faster than I’ve ever seen an enterprise move.”
But that speed only works for some organizations. And all are now facing a crossroads as rampant spending gives way to questions about return on investment.
“The return on each token you spend is the thing you really want to look at,” Williamson says.
Over coffee, Williamson, discusses why runtime context matters more than bigger models, how companies should shift from maxing out token budgets to measuring ROI, why technical debt is more mortgage than payday loan — and the first thing he ever vibe-coded: a Facebook for dogs.
How have things changed at Undo since AI?
For 12 years, our core value has been helping people understand code that no one can understand. Most bugs out there are shallow — annoying, but people get through it. Our niche has always been mission-critical software, where a bug in production can cost millions of dollars and a very high reputational cost. These are companies with massive codebases, where code written 20 or 30 years ago works fine until you change something you thought was safe, and it explodes. Often no human left understands it, or you can’t even find who wrote it. Now those companies are moving to AI coding tools and agents faster than I’ve ever seen an enterprise move. Normally it’s six to 12 months of deliberation, but this time they threw caution aside. What we’ve found is AI is genuinely smart now, but not magic. It can only scale as far as the information it’s given lets it. That’s kind of always been our reality. Until the middle of last year we weren’t worried about coding agents; then customers adopted them uncharacteristically fast. Our research showed that runtime context — what actually happened while the software was running — is exactly what makes AI smarter at handling problems in enterprise codebases. That’s turned some things on their head. The shallow bugs we used to handle are now being eaten up by AI agents. But our core value hasn’t changed — everyone wants AI in their workflow, often exclusively. What happened around the middle of last year was that some of the more recent frontier models crossed a threshold where they got really good at this stuff. Google released Gemini [2.5], and you could see it had gone from “this is an interesting form” to “this can actually write code.” I think, generally, in the industry, toward the start of that year, it felt like people were sleeping on it a bit. They were saying, “Oh, we’ve got AI engineers, we want it,” but hadn’t decided whether it was going to stick around or whether it was actually brilliant. So generally, businesses could have done with moving a bit faster on it then, if they could have seen it clearly. By the middle of last year, they started moving faster — that was okay. And then, largely, they all made the decision that things were moving so fast that the only reasonable thing to do was try to maximize spend — make people hit token targets, make people invest in new agents, and not worry about how much it costs. I actually think that’s fine if you’ve got an organization of, say, 100,000 people, and you’re trying to change that culture; you can’t sit down and have a breezy debate with everybody about the pros and cons. Sometimes you just have to say: you’ve all got to do this now, and we’ll figure out the consequences later. But I think a lot of businesses, as a result, haven’t made the transition from “we’ve got to get things moving, let’s just spend” to “let’s think about the return on investment.” The return on each token you spend is the thing you really want to look at. Companies don’t want to minimize spending and lose value, but they also don’t want to maximize spend just for the sake of it — and it makes CFOs cry anyway, so we don’t want that. I think a lot of them haven’t figured out how they’re going to transition from “everybody max out tokens” to “everybody’s really efficient and cares about ROI.” That transition could be a lot smoother and a lot more thought through. What’s a good use case for an agent? And for the things that are good use cases, what kind of sources of information do we need to feed the agent so it’s giving us sensible, reasoned answers instead of frantically guessing in a really convincing way? Yes, to be honest. And not all of that’s bad. When things are changing, business leaders need to place some big bets, and some of them will pay off and some will make them look really stupid in retrospect. That comes with the territory. But in some cases, it’s generated a lot more heat than light. There’s been a lot of talk about how clever and impressive the next model is going to be, and how much better things would be if only everyone had access to it. And I think that’s driving some confused behavior. It’s causing a lot of uncertainty. People aren’t necessarily investing in things they would have done before, things they know will work, because they don’t know what’s coming around the corner. Basically, if a company invents a wizard in a box, everybody wants enough money to buy that wizard. But if it turns out to be a substantial improvement on existing models while fundamentally having the same constraints — that you can’t get something useful out unless you have the right information to feed it — then it’s kind of silly to drop everything else for it. I think a lot of it comes down to boring, sensible engineering practices, in some ways. If you’ve got technical debt, debt isn’t automatically bad. It’s like a mortgage on my house: I wouldn’t have bought the house without it, so that’s good debt as long as I can pay it down. If I’d taken out a load of payday loans, that would probably be bad debt. People shouldn’t be scared of technical debt, as long as they’re managing it. But what you can’t do is have AI generate huge amounts of code, faster than a human could, without a plan for how you’re going to pay that down later, or cope with the comprehension debt — engineers not understanding how the software works anymore. There has to be a way, later, that either the AI or a human will be able to understand it. And the other thing is, people need to get on with really understanding the ROI on their AI use. It’s obviously not right to just tell people to spend as much as possible because more is better. That creates a weird incentive. But there’s also a risk of overcorrecting — rationing AI, saying don’t use the most intelligent models, use the cheapest model you possibly can and only use it when absolutely necessary. My advice would be: come up with a strategy where you’re actually controlling this. That means selecting the right models for the job, and the right sources of information to get the best results. Paying for the best model when you don’t need it is a waste. And the cheapest model, when it can’t cope with the scope of your problem, is also a waste. It’s about right-sizing: matching AI ability to the problems you’re solving and the information you have. As CTO, I’d have to spend a lot of time trying to figure out if [an idea] was worth pursuing. We’d have to have lots of meetings about who could work on it, who could spend time on it — sure, it might only take a couple of days in theory, but it would probably take a week or two in practice, and I’d have to weigh that against other priorities. So you had to load up a lot of justification before something was even worth thinking about trying. To get to a prototype or a [minimum] viable product, I find it now often takes much less time for a coding agent to just build it than it does to decide whether to even try — for things like slightly speculative new features, or new front ends to the product. They’re ideal for that. The first thing I vibe-coded [for work] was an alternative, more agent-oriented front end to our debugger, because I was trying to figure out what a workflow might look like in our new world. When I vibe-code, I try to take it seriously in the sense that I commit to not looking at any of the code. I give no advice to the agent on how to code or what it should do. I try not to use any of my normal expertise. I just communicate in terms of what the product should look like, what should come out and how we test it to make sure it works. It’s also enabled me to ship things in TypeScript, which I’ve never learned. I think the very first thing I vibe-coded was actually a Facebook for dogs. The models back then were just about good enough to do it, and their sense of humor was often on point too. It’s a really interesting time to be in all of this. A decade ago, everybody would have said a startup building developer tools was a very weird choice. In the past couple of years, they’ve become these $10 billion companies competing in the space. It’s a scary ride, because things change constantly now, whereas a couple of years ago, we knew exactly what we were. But it’s also exciting. In many ways, the traction we’re getting with customers now, even with all the disruption, is the best we’ve ever had. It’s almost like this AI stuff was missing for us and we never even knew it. So scary in both good and bad ways, but overall, a really interesting ride right now. I’m taking it however it’s going, to be fair. What I like is my Bialetti Brikka, which makes extra-extra strong and creamy coffee.You
said it wasn’t until the middle of last year that you became concerned about agent coding. If you could go back to that time and advise everyone on how to approach it, what would you say?
Has there been a misconception over what AI can do and where businesses should be using it?
What would your advice be for anyone currently facing that point? Where they’ve got to figure out where they’ll get the return on investment, or where they’re dealing with technical debt?
Have
you vibe-coded anything?
What about in your personal life?
How do you take your coffee?