<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Working Notes on Revelara</title><link>https://revelara.ai/blog/</link><description>Recent content in Working Notes on Revelara</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 16 Aug 2026 09:00:00 -0700</lastBuildDate><atom:link href="https://revelara.ai/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Fewer moving goal posts for more reliable commits</title><link>https://revelara.ai/blog/fewer-moving-goal-posts/</link><pubDate>Sun, 16 Aug 2026 09:00:00 -0700</pubDate><guid>https://revelara.ai/blog/fewer-moving-goal-posts/</guid><description>&lt;p&gt;The moment I understood what we had built was not during a benchmark or eval. It was during a commit that took three tries.&lt;/p&gt;
&lt;p&gt;I asked an agent to make a change. It finished, staged the work, and tried to commit. The
pre-commit hook ran a scan and blocked it on a reliability finding. The agent read the finding,
understood it, and fixed it. It tried to commit again, and this time its own fix had introduced a second blocking finding. It read that one, fixed it too, and ran again. This time it passed, and committed the whole change set.&lt;/p&gt;</description></item><item><title>Code Review Is a Memory Problem</title><link>https://revelara.ai/blog/code-review-is-a-memory-problem/</link><pubDate>Sun, 02 Aug 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/code-review-is-a-memory-problem/</guid><description>&lt;p&gt;I have been building Revelara for a while, and there&amp;rsquo;s one aspect I&amp;rsquo;ve had a hard time explaining to people. The easy version is &amp;ldquo;this is a reliability gate: it catches risky changes before they ship.&amp;rdquo; It&amp;rsquo;s easy for people to understand the value, but it&amp;rsquo;s too small for what it really does. The bigger version kept coming out vague, something about knowledge, memory, and the importance of having it in the developers coding context. Every time I said it out loud it sounded like a vague promise in the worst case, and unconvincing and easily dismissed in the best case. So I usually stick with the things that are easy for me to explain and for people to grok.&lt;/p&gt;</description></item><item><title>Security Shifted Left. Reliability Can Too.</title><link>https://revelara.ai/blog/security-shifted-left-reliability-can-too/</link><pubDate>Tue, 28 Jul 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/security-shifted-left-reliability-can-too/</guid><description>&lt;p&gt;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&amp;rsquo;t run and couldn&amp;rsquo;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&amp;rsquo;d already forgotten writing.&lt;/p&gt;</description></item><item><title>AI Writes More of Your Code Now. It Also Ships More Reliability Risk.</title><link>https://revelara.ai/blog/ai-code-ships-more-reliability-risk/</link><pubDate>Sun, 26 Jul 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/ai-code-ships-more-reliability-risk/</guid><description>&lt;p&gt;A 2025 study of 470 pull requests found that AI-generated code shipped roughly 1.7x more issues and about 1.4x more critical defects than human-written code. Nobody serious reads that as &amp;ldquo;AI code is bad,&amp;rdquo; and I&amp;rsquo;m not arguing it either; much of what an agent writes is clean, idiomatic, and correct. The trouble starts when you sit a real workflow on top of that number: volume times defect rate, pointed at the part of the system that hurts most when it breaks.&lt;/p&gt;</description></item><item><title>How to Scan a Codebase for Reliability Risks with rvl-cli</title><link>https://revelara.ai/blog/install-rvl-cli-first-risk-register/</link><pubDate>Sun, 19 Jul 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/install-rvl-cli-first-risk-register/</guid><description>&lt;p&gt;Clone a repo you&amp;rsquo;ve never scanned, install the Revelara CLI, run one scan, and read a ranked list of the reliability risks in that codebase. Budget about fifteen minutes end to end, and know that your hands-on part is a fraction of it. The scan does analysis, reading your code against a controls catalog with expert lenses, and real analysis takes longer than a grep. Kick it off, click through the permissions prompts, and load the risk register. This post is a walkthrough, using a public repo you can clone yourself.&lt;/p&gt;</description></item><item><title>The Counterfeit Test for AI Metrics</title><link>https://revelara.ai/blog/the-counterfeit-test-for-ai-metrics/</link><pubDate>Wed, 15 Jul 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/the-counterfeit-test-for-ai-metrics/</guid><description>&lt;p&gt;We had an AI quality metric that behaved exactly the way any good metric should. It was stable across model tiers. It improved when we refined the system. It separated weaker specialist lenses from stronger ones. And it measured something tied to proprietary knowledge the base model did not have.&lt;/p&gt;
&lt;p&gt;It measured &lt;strong&gt;grounding coverage&lt;/strong&gt;: the percentage of findings that cited a valid control from our reliability catalog. Every control in the catalog traces back to real incidents and known failure patterns.&lt;/p&gt;</description></item><item><title>GitHub's February 9 Incidents: What 'Mitigation' Leaves Out</title><link>https://revelara.ai/blog/mitigation-theater-github-february-9/</link><pubDate>Tue, 26 May 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/mitigation-theater-github-february-9/</guid><description>&lt;p&gt;GitHub&amp;rsquo;s availability report for February 2026 covers six incidents and there are two on February 9 worth reviewing. Two windows of degraded service an hour and fourteen minutes apart, and GitHub&amp;rsquo;s own investigation found they came from the same underlying cause. The first was declared mitigated before the second began. The mitigation GitHub applied was a correct response to what the team could see at the time. It also was not enough to prevent the second incident.&lt;/p&gt;</description></item><item><title>The Medium-Severity Paradox: Where Engineering Time Actually Goes</title><link>https://revelara.ai/blog/medium-severity-paradox-corpus-analysis/</link><pubDate>Sun, 10 May 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/medium-severity-paradox-corpus-analysis/</guid><description>&lt;p&gt;The average critical-severity incident in the Revelara corpus takes about 19 hours to resolve. The average medium-severity incident takes about 17 hours. On those two numbers alone, the natural conclusion is that critical incidents are roughly where engineering time goes, and that medium-severity work is the manageable middle. The conclusion is wrong by roughly an order of magnitude, and the data shows why.&lt;/p&gt;
&lt;h2 id="the-numbers-and-how-the-analysis-was-run"&gt;The numbers, and how the analysis was run&lt;/h2&gt;
&lt;p&gt;This analysis pulls from the Revelara public postmortem corpus, which currently spans nearly 3,000 published incidents and grows daily. Two severity-targeted comparisons were run. The &amp;ldquo;critical&amp;rdquo; set returned 272 incidents matching body language like SEV1, P0, total outage, and major. The &amp;ldquo;medium&amp;rdquo; set returned 284 incidents matching SEV3, P2, degraded, and partial.&lt;/p&gt;</description></item><item><title>What the DORA 2026 J-Curve Actually Says About Reliability and Vibe Coding</title><link>https://revelara.ai/blog/dora-2026-j-curve-reliability-vibe-coding/</link><pubDate>Mon, 04 May 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/dora-2026-j-curve-reliability-vibe-coding/</guid><description>&lt;p&gt;DORA shipped &lt;em&gt;The ROI of AI-Assisted Software Development&lt;/em&gt; recently. There&amp;rsquo;s an interesting number from that report that ties back to a Google Cloud 2025 report on the ROI of AI; 78% of executives from organizations with C-level AI sponsorship report seeing ROI now on at least one generative AI use case. The new report shares a number I have not seen quoted before, a 15% productivity drop used as the default in its sample ROI calculator. The report is explicit that the actual depth and duration of the dip are unpredictable; 15% is a placeholder input, not a measurement. On a 500-engineer organization at $176,000 fully loaded salary, that is $3.3 million in lost capacity over three months. The report calls this the &amp;ldquo;tuition cost&amp;rdquo; of AI adoption. It includes the line item in its example budget. Then it moves on.&lt;/p&gt;</description></item><item><title>The Observability System I Almost Shipped</title><link>https://revelara.ai/blog/the-observability-system-i-almost-shipped/</link><pubDate>Tue, 21 Apr 2026 08:00:00 -0700</pubDate><guid>https://revelara.ai/blog/the-observability-system-i-almost-shipped/</guid><description>&lt;p&gt;I finished a PRD on Sunday for the LLM observability and evaluation stack we&amp;rsquo;re adding to Revelara. Five layers, twenty-one user stories, async eval scoring, drift detection, the whole thing. I thought it looked great. I was happy with it. Before I started on the implementation, I ran it through our new STPA review tool (mostly because I didn&amp;rsquo;t trust how happy I was with it, so dogfooding seemed like the best test).&lt;/p&gt;</description></item></channel></rss>