<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on jpcercal.com</title><link>https://jpcercal.com/en/tags/architecture/</link><description>Recent content in Architecture on jpcercal.com</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 14 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jpcercal.com/en/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>What an AI Session Can Teach the Next One</title><link>https://jpcercal.com/en/what-an-ai-session-can-teach-the-next-one/</link><pubDate>Mon, 14 Sep 2026 00:00:00 +0000</pubDate><guid>https://jpcercal.com/en/what-an-ai-session-can-teach-the-next-one/</guid><description>&lt;p&gt;An AI assistant can help write code, explain an unfamiliar system, investigate a failure, or draft documentation. An AI agent can go a step further and take several actions on our behalf.&lt;/p&gt;&#10;&lt;p&gt;In both cases, it is easy to focus only on the immediate result. Did the code compile? Did the document look reasonable? Did the task move forward?&lt;/p&gt;&#10;&lt;p&gt;There is another result that is easy to lose: what the session taught us about the way our team works.&lt;/p&gt;</description></item><item><title>Working With AI Agents: Stay on the Loop</title><link>https://jpcercal.com/en/working-with-ai-agents-stay-on-the-loop/</link><pubDate>Sun, 13 Sep 2026 00:00:00 +0000</pubDate><guid>https://jpcercal.com/en/working-with-ai-agents-stay-on-the-loop/</guid><description>&lt;p&gt;I&amp;rsquo;ve been thinking recently about how our role as software engineers changes when AI agents become part of the development process.&lt;/p&gt;&#10;&lt;p&gt;There seems to be a tempting choice between two extremes.&lt;/p&gt;&#10;&lt;p&gt;Either we let the agent handle everything and trust the result, or we stay involved in every step, reviewing every piece of code it produces.&lt;/p&gt;&#10;&lt;p&gt;I don&amp;rsquo;t think either approach scales particularly well.&lt;/p&gt;&#10;&lt;h2 id="the-output-isnt-the-whole-process"&gt;The output isn&amp;rsquo;t the whole process&lt;/h2&gt;&#10;&lt;p&gt;When building software, we often focus heavily on the artifacts we produce: code, tests, technical designs, configuration, and documentation.&lt;/p&gt;</description></item><item><title>Understand the System Before Changing It</title><link>https://jpcercal.com/en/understand-the-system-before-changing-it/</link><pubDate>Thu, 10 Sep 2026 00:00:00 +0000</pubDate><guid>https://jpcercal.com/en/understand-the-system-before-changing-it/</guid><description>&lt;p&gt;One thing I&amp;rsquo;ve learned over the years is that good architecture often starts with understanding the system you already have.&lt;/p&gt;&#10;&lt;p&gt;Before changing something, I usually invest some time looking at how requests actually flow, where the dependencies are, what the failure points might be, and perhaps most importantly&amp;hellip; why things ended up the way they are.&lt;/p&gt;&#10;&lt;p&gt;Sometimes there&amp;rsquo;s a very good reason. Sometimes the reason is simply that the system evolved over time. Either way, understanding the context usually leads to better decisions than jumping straight to a solution.&lt;/p&gt;</description></item></channel></rss>