<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Code-Review on @zhisme :: signal over noise</title><link>https://zhisme.com/tags/code-review/</link><description>Recent content in Code-Review on @zhisme :: signal over noise</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 25 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://zhisme.com/tags/code-review/index.xml" rel="self" type="application/rss+xml"/><item><title>Why code review needs an AI triage layer</title><link>https://zhisme.com/articles/why-code-review-needs-ai-triage-layer/</link><pubDate>Sun, 25 Oct 2026 00:00:00 +0000</pubDate><guid>https://zhisme.com/articles/why-code-review-needs-ai-triage-layer/</guid><description>&lt;h2 id="machinery-review"&gt;Machinery Review&lt;/h2&gt;&#10;&lt;p&gt;Compilers/linters/formatters are cool tools. For decades we have been using them alongside us; our pipelines were built on top of the input of linters, tests and compilers. If all pipelines were green, we trusted them. The static and deterministic analysis of such tools was easy to understand.&lt;/p&gt;&#10;&lt;p&gt;Green tests mean the logic is OK: we didn&amp;rsquo;t violate our product logic regarding WHAT our code does (we may argue about this point, but most of the time that is the most valuable factor to us). Green linters mean we didn&amp;rsquo;t violate our company rules regarding HOW we write code.&lt;/p&gt;</description></item></channel></rss>