<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Shift-Left on Revelara</title><link>https://revelara.ai/tags/shift-left/</link><description>Recent content in Shift-Left 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/tags/shift-left/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></channel></rss>