<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Marcos Defendi — Writing</title>
    <link>https://defendi.dev/blog/</link>
    <description>Writing on architecture, AI delivery, developer experience, and technical communication.</description>
    <language>en</language>
    <atom:link href="https://defendi.dev/blog/rss.xml" rel="self" type="application/rss+xml" />

    <item>
      <title>The Architecture Rules a Linter Can't Check</title>
      <link>https://defendi.dev/blog/architecture-rules-a-linter-cant-check</link>
      <guid isPermaLink="true">https://defendi.dev/blog/architecture-rules-a-linter-cant-check</guid>
      <category>Architecture</category>
      <description>I checked Cal.com's own documented architecture rules against their code, then pointed the same tool at a problem no linter can see: code that means two different things.</description>
      <pubDate>Mon, 22 Jun 2026 00:00:00 GMT</pubDate>
    </item>

    <item>
      <title>Your PR Review Is Not an Architecture Review</title>
      <link>https://defendi.dev/blog/pr-review-is-not-an-architecture-review</link>
      <guid isPermaLink="true">https://defendi.dev/blog/pr-review-is-not-an-architecture-review</guid>
      <category>Architecture</category>
      <description>PR review is a code quality tool. Treating it as architecture enforcement isn't a discipline problem — it's a mismatch between what the tool can see and what enforcement actually requires.</description>
      <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
    </item>

    <item>
      <title>Bit Rot Is Not a Metaphor</title>
      <link>https://defendi.dev/blog/bit-rot-is-not-a-metaphor</link>
      <guid isPermaLink="true">https://defendi.dev/blog/bit-rot-is-not-a-metaphor</guid>
      <category>Architecture</category>
      <description>You can write a perfect ADR and in 18 months nobody follows it. The question is not how to document better. It is what you do with the documentation after it is written.</description>
      <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
    </item>

    <item>
      <title>The Coupling Rate Problem</title>
      <link>https://defendi.dev/blog/coupling-rate-problem</link>
      <guid isPermaLink="true">https://defendi.dev/blog/coupling-rate-problem</guid>
      <category>Architecture</category>
      <description>GitClear's data shows code cloning is up while refactoring is down. That matters because duplicated code creates coupling, and refactoring is the work that forces teams to reconcile it.</description>
      <pubDate>Wed, 15 Apr 2026 00:00:00 GMT</pubDate>
    </item>

    <item>
      <title>Implicit Coupling Is a Maintenance Problem, Not a Generation Problem</title>
      <link>https://defendi.dev/blog/implicit-coupling-llm-assisted-development</link>
      <guid isPermaLink="true">https://defendi.dev/blog/implicit-coupling-llm-assisted-development</guid>
      <category>AI &amp; Engineering</category>
      <description>I ran three experiments with Claude Code (Opus 4.6) and Codex (GPT-5.4 xhigh) — greenfield creation, extension, and brownfield detection. The conclusion: implicit coupling is a maintenance problem, not a generation problem.</description>
      <pubDate>Wed, 08 Apr 2026 00:00:00 GMT</pubDate>
    </item>
  </channel>
</rss>
