Robert Ta and Jonathan discuss self-healing codebases: automated systems that monitor production logs, generate and deploy fixes without human intervention, and directly improve user retention and revenue. They frame it as a 24/7 staff engineer that keeps code quality high enough to matter to the bottom line.
Everybody's talking about like, you know, how can we get our agents to be closed loop? And the self-healing version of that is the, is your coding agent is closed loop to a code base. So it's, it's kind of like aspirational. Like this is what we want all of our agents to be when they grow up someday.
Yeah, totally. And when we say self-healing, the way that I'm understanding it, I wanna hear from you, is that there is some target outcome of a quality bar for the code base that meets the real world in terms of economic value, AKA, do users come back, use it more, are they retained, do they engage with it more, do they pay more and ultimately keep using it, refer other people. Those are some of what I mean by business outcomes or economic value. And then there's tied to that, obviously, if your quality is really bad, you're going to have lower economic value out of your codebase. If the codebase is a software asset that your company sells, then you got to make sure the quality bar is high. In my head, I'm like, just think of this as a staff engineer running at 24/7. So what would they do? Bug comes in, they triage, and hopefully they get a fix out fast, right? To maintain the quality bar. So self-healing to me kind of means that, making sure the business is still making money, making more money tied to the health of the codebase, the quality of the codebase. Is that how you think about it, Jonathan, for self-healing codebases?
Well, I think there's some specific, like, here's a codebase, it needs to be healed, as in it has an error somewhere. And you're gonna see that in your production logs, you know, like the code being expressed in the real-time runtime environment. You're going to see that in terms of bug reports from your users. To me, that's what self-healing means is like, it can take those errors and you could just like have a background agent running with Cursor that automatically promotes a fix, a PR, deploys it to production, and then checks the logs to see if like it actually did fix that bug. I think it's, it's like pretty concrete if you just think about like, where, what are the error sources and what needs to be healed? And that's what this SDK does is like, you know, right now you can use Cursor in your IDE, you can use it in your CLI. This SDK makes it so you can just take it and put it and run it like in the background on the server, and it can be monitoring your logs and fixing things without, you know, necessarily even human intervention. That's really next level.
Yeah, that's the panacea for sure.
