<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gears Within Gears</title><link>https://brianguthrie.com/categories/architecture/</link><description>Gears Within Gears</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 16 Jul 2026 14:30:12 +0000</lastBuildDate><atom:link href="https://brianguthrie.com/categories/architecture/" rel="self" type="application/rss+xml"/><item><title>Software architecture after AI</title><link>https://brianguthrie.com/p/software-architecture-after-ai/</link><pubDate>Tue, 21 Apr 2026 06:00:00 -0500</pubDate><guid>https://brianguthrie.com/p/software-architecture-after-ai/</guid><description>&lt;p&gt;One of the more useful definitions of software architecture comes from &lt;a href="https://evolutionaryarchitecture.com/"&gt;Building Evolutionary Architectures&lt;/a&gt;: architecture is definitionally the stuff that&amp;rsquo;s hard to change.&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt; I&amp;rsquo;ve always found this definition to be the most honest framing available, to say nothing of the simplest. It doesn&amp;rsquo;t pretend architecture is about beauty or correctness or your resident architect&amp;rsquo;s favorite stalking-horse. It acknowledges that what makes a decision &amp;ldquo;architectural&amp;rdquo; is not its conceptual weight but its &lt;em&gt;cost to reverse&lt;/em&gt; and its &lt;em&gt;business impact&lt;/em&gt;. And &amp;ldquo;hard to change&amp;rdquo; has always been, at root, about wall-clock time: coordination cost, incident mitigation, cognitive load, handoff friction. Software architecture has always been a labor problem dressed up as a design problem.&lt;/p&gt;</description></item></channel></rss>