Security Shifted Left. Reliability Can Too.
8 min readSecurity moved from a late scan to a check where developers work, and it worked. The same shift is available for reliability, at authorship time, before commit.
For about a decade, security had the same shape as a punishment. You wrote your code, you opened your pull request, you felt good about your week, and then a scanner you didn’t run and couldn’t see filed a report against you. The findings landed after the fact, in a different tool, owned by a different team, and by the time they reached you the context that produced the code was gone. You were being asked to remember why you wrote a line you’d already forgotten writing.
That model produced a predictable behavior, and it wasn’t “developers care more about security.” It was developers routing around security, not out of malice but out of load. When the check lives at the far end of the pipeline, it’s someone else’s job, and the codebase fills up with the difference.
Then the industry did something that, in hindsight, looks obvious and, at the time, didn’t. The insight was never “make security a CI gate”; gates already existed, and everyone hated them. The insight was to take security out of the security team’s hands entirely and put it where the developer actually works: in the editor, in the CLI, in the pull request the developer was already looking at, framed as information you could act on before you shipped rather than a verdict. A vulnerability database became browsable pages, one per known problem, and the check that read your dependencies against it ran in seconds next to your cursor instead of hours later in a queue. The developer stopped being the defendant and became the person best positioned to fix the thing, at the only moment fixing it was cheap.
It worked because it respected a fact about complex systems that the late-scan model ignored: the cheapest place to fix a defect is the place it was written, while the person who wrote it still remembers why. Everything downstream of that moment is more expensive, and production is the most expensive of all.
Reliability has the exact same shape, and in a lot of ways, it’s still stuck in the pre-shift-left era.
Where reliability meets you now
Most teams meet their reliability risks the expensive way: at 2am, after the page, in an incident channel, while a retry storm you introduced three weeks ago is hammering a service that’s already down and can’t answer. The knowledge that would have prevented it existed. It just wasn’t anywhere near the developer when the developer told the agent what to write.
Think about the shape of the classic public outages, the ones that get written up and talked about at conferences. A retry with no backoff and no jitter, so the moment a dependency slows down, every client retries in lockstep and turns a blip into a synchronized flood. A cache that expires all at once and sends a thundering herd at the origin. A system that, somewhere deep in its own recovery path, depends on itself to come back up, so being down is the one condition under which it can’t get back up. None of these are exotic; they’re a handful of failure classes that have taken down large, well-staffed, well-monitored public platforms more than once, and every one of them is visible in the code, at the call site, before anything ships. Every system carries a flaw that creates or prolongs availability or performance issues somewhere; the trick is knowing where before it bites you.
None of the typical tools in the developer’s loop are looking for them. Your linter checks style. Your type checker checks types. Your test suite checks the behaviors you thought to write tests for, which by definition aren’t the ones that surprise you. Your AI reviewer checks whether the code is correct, and correct code causes outages all the time. When every component works, the interaction is what kills you, and the interaction is exactly what none of those checks are built to see.
So the reliability check, like the old security scan, has drifted to the far end of the pipeline. It runs in production, under an incident, owned by whoever’s on call. Which, at a growing number of mid-market teams, is a software engineer, because there’s no SRE.
Authorship time, not review time
The distinction that matters here is sharper than “should it be in CI or not.”
A reliability risk is a design time decision as much as a runtime application. The missing timeout, the retry with no backoff, the absent circuit breaker, the new call that quietly couples two service cells that were independent yesterday and were meant to remain so by design: these are choices, made at the moment the code takes shape. The cheapest time to change a design decision is while you’re still making it. Once the diff is written and the PR is open, the design is set, and everything after that is rework. The longer it goes, the more expensive it is to fix.
That’s why the coding agent matters. The agent is the 2026 inner loop, where the code is authored, and the natural home for a check that catches design decisions while they’re still decisions. A code-review bot, by construction, lives at the gate: it waits for the PR because that’s what it reviews, and review time is after the design is done. Reliability doesn’t want to be at the gate. It wants to be at authorship, in the agent, while you can still change your mind for free. You can still run it as a pre-commit or pre-push hook, or in CI as a backstop, and you probably should. The point is to catch the outage-shaped decision before it hardens.
This is the move shift-left security made, applied to the other class of problem: take the check off the far end of the pipeline and put it where the work happens.
Reliability at authorship time
The category we think should exist, and the one Revelara is built to occupy, is reliability at authorship time: not a dashboard you check or a scan that runs overnight, but a check that reads the change you’re about to make and tells you, before you commit, whether it introduces a reliability risk that has taken down real systems before, so you can fix it while you still remember why you wrote it.
The security analogy isn’t decoration, it’s the whole argument. The tools that won didn’t just tell you your dependency was “risky”; they told you which known vulnerability it matched, with a link. The specificity is what earned the trust.
Revelara’s version of that specificity is a corpus of thousands of real public production incidents. When it flags a pattern in your code, many of those findings can point at the class of real outage that pattern has caused elsewhere. The finding reads less like “this looks fragile” and more like “this is the retry shape that has taken down production systems, here’s the mechanism, here’s where it lives in your diff.” It runs in the local dev loop, inside the coding agent you already use, before the commit and before CI. A check that slows you down is a check you’ll disable. The analysis is a real read of a complex change, so results are non-deterministic, the way any honest read of a complex system is. The claim is that it’s grounded in real incidents, not that it catches every risk on every run.
Who this is for, and who it isn’t
If you’re a developer, this is the check you always wanted security to be and reliability never was: something that meets you at the keyboard, speaks in specifics, and doesn’t file a report against your past self.
If you lead the team, this is coverage for a risk you already own. A senior SRE is expensive, and on a lot of mid-market teams there isn’t one to delegate to. Reliability at authorship time is how you cover the gap. Where you do have SREs, this complements them and hands them cleaner code to work with. It doesn’t replace them. It covers the work that, on a team without an SRE, currently no one and everyone owns, whether they do it or not.
Security learned this lesson the expensive way first, across years of late scans and ignored reports, before it moved the check to where the code was written and the whole thing finally started working. Reliability doesn’t have to relearn it from scratch. The template already exists. We’re applying it to the other class of 2am problem, and I think the teams that pick it up early will have a quieter next quarter than the ones that wait.