“The fundamental problem with alerts is that you need to know what the problem is before you can set an alert for it… I swapped models today and one of the models doesn't support images… There is no way on earth I would have set an alert for, you know, if user puts image, alert me.”
devtools.fm: Developer Tools, Open Source, Software Development · Hands-On Engineering Podcasts · October 2026
Boris Tane, founder of Polylane, explaining why it continuously scans an app's telemetry rather than waiting for alerts. He argued the hard part of production problems is now knowing about them, since once you do, a coding agent can write the fix.
Transcript
…days when it's doing some work. Whereas the ground truth, it loads it kind of every single time because, you know, you run Vercell, it's true, right? It also gets updated continuously, but not discarded. Like the first type, they actually get discarded and replaced by kind of newer information.
…that makes sense. I'm curious just to like walk through like what the traditional flow of the product would be. So let's say, you know, you have an issue in production, like where does Polylane come in? And then all the way to like, we want to ship effects. Like, what does that flow look like?
Yes. Before I talk about that flow, actually, there is something, it's an experiment that we did about a month ago. And it's starting to become the most used feature on Polylane, very surprisingly. The problem is trying to solve is how do I know that this pull request is not breaking my app, right? Like I took a screenshot from a support ticket, pasted it in Codex, asked Codex, fix it. It worked for 30 minutes and submitted the pull request. Okay, that's cool. But if I press that merge button, I become responsible for the health of the app based on code I barely saw, I barely read. So what we do is we take that pull request and we run it through what we call trajectories. What are the possible implications of this pull request in production, right? We come up with five, ten trajectories, go and investigate them deeply and figure out which ones of those trajectories may potentially have a negative impact on production. It may increase error rates, it may increase latencies, it may toast the app completely. And then we post a comment on the pull request saying, hey…
So you mentioned a lot of particular scenarios where an agent can step in and make a PR. So like this one you just discussed is like CI
fails. So Polylane is like acting on a signal and creating a PR. I was looking on your, just on the marketing page, and there are like, you know, a few like general cases that you cover that you would expect like a tool like this to cover. So like you have this impact analysis or like some signal…
Yeah. Yeah. So when I started in March, The very first prototype I built actually did not submit the pull request. It was working only on Cloudflare and Vercel, and it will deploy to prod, right? It will find the problem, fix it, deploy to production because those platforms you can deploy via API.…
More from devtools.fm: Developer Tools, Open Source, Software Development
