<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Infrastructure on Andreas Nissen</title><link>https://andreasnissen.dev/tags/infrastructure/</link><description>Recent content in Infrastructure on Andreas Nissen</description><generator>Hugo</generator><language>en-us</language><copyright>© Andreas Nissen</copyright><lastBuildDate>Sat, 05 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://andreasnissen.dev/tags/infrastructure/index.xml" rel="self" type="application/rss+xml"/><item><title>When Coding Agents Change Infrastructure: What Evidence Is Enough to Ship?</title><link>https://andreasnissen.dev/writing/evidence-for-agent-infrastructure-changes/</link><pubDate>Sat, 05 Sep 2026 00:00:00 +0000</pubDate><guid>https://andreasnissen.dev/writing/evidence-for-agent-infrastructure-changes/</guid><description>&lt;p&gt;A coding agent changes a service&amp;rsquo;s liveness check from &lt;code&gt;/live&lt;/code&gt; to &lt;code&gt;/ready&lt;/code&gt;. Both endpoints return success during review. The configuration is valid and the deployment completes.&lt;/p&gt;&#10;&lt;p&gt;Later, the database slows down. In this hypothetical service, &lt;code&gt;/ready&lt;/code&gt; checks database connectivity. Enough failed liveness checks now cause the application container to restart, although restarting it cannot repair the database. The configuration change has coupled a dependency problem to application restarts.&lt;/p&gt;&#10;&lt;p&gt;My release rule is simple: &lt;strong&gt;before shipping an infrastructure change, identify the failure it could introduce, the observation that would reveal it, and the action that would restore service.&lt;/strong&gt; Match the evidence to those answers.&lt;/p&gt;</description></item></channel></rss>