<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Emilio Carrión - Blog</title>
    <link>https://emiliocarrion.com/en</link>
    <description>Reflections on software engineering, technical leadership, and professional development</description>
    <language>en</language>
    <lastBuildDate>Sun, 10 May 2026 11:58:33 GMT</lastBuildDate>
    <atom:link href="https://emiliocarrion.com/en/feed.xml" rel="self" type="application/rss+xml" />
    <copyright>Copyright 2026 Emilio Carrión</copyright>
    <managingEditor>hola@emiliocarrion.com (Emilio Carrión)</managingEditor>
    <webMaster>hola@emiliocarrion.com (Emilio Carrión)</webMaster>
    <image>
      <url>https://emiliocarrion.com/og-blog.jpg</url>
      <title>Emilio Carrión - Blog</title>
      <link>https://emiliocarrion.com/en</link>
    </image>

    <item>
      <title>The seven unwritten engineering laws AI is making more expensive</title>
      <link>https://emiliocarrion.com/en/blog/seven-unwritten-engineering-laws-ai</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/seven-unwritten-engineering-laws-ai</guid>
      <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
      <description>This week I watched a teammate ship nine PRs in a single day. Solid work, AI-assisted. Speed is what we celebrate, but the unwritten rules of engineering, the ones you only learn by breaking them, now charge you sooner and bigger. The seven laws, and how AI changes the math on every one of them.</description>
      <content:encoded><![CDATA[
        
        <p>I&apos;ve had a weird feeling for a few weeks now, and I don&apos;t think I&apos;m the only one.

This week, looking at what a teammate was doing, I noticed they had shipped nine pull requests in one day. Nine. Each one tied to a deployment version, because we run continuous deployment. And it wasn&apos;t a chaotic morning of hotfixes. It was normal work, well done, AI-assisted.</p>
        <p><a href="https://emiliocarrion.com/en/blog/seven-unwritten-engineering-laws-ai" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>engineering</category>
      <category>operations</category>
      <category>software quality</category>
    </item>
    <item>
      <title>The DNA of software wasn&apos;t a concept. It was 24 files.</title>
      <link>https://emiliocarrion.com/en/blog/software-dna-24-files</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/software-dna-24-files</guid>
      <pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate>
      <description>Three weeks ago I argued that code was going to become disposable, and what would matter is the DNA of the software. I locked myself in to check whether that idea was actually writable. What came out: 24 files, two regenerations for less than a euro each, a public repo, and a lot of clarity about what harness engineering still doesn&apos;t solve.</description>
      <content:encoded><![CDATA[
        
        <p>Three weeks ago I pulled out the crystal ball and tried to guess the future 🔮: when LLMs generate thousands of tokens per second, regenerating code will be cheaper than maintaining it (and faster even than reading it!). And then the question stops being &quot;how do I write good code?&quot; and becomes &quot;what information lets me regenerate this system without losing its identity?&quot;.</p>
        <p><a href="https://emiliocarrion.com/en/blog/software-dna-24-files" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>architecture</category>
      <category>regenerative software</category>
      <category>agents</category>
      <category>product</category>
    </item>
    <item>
      <title>Your LLM passes the benchmark and fails in production</title>
      <link>https://emiliocarrion.com/en/blog/llm-passes-benchmark-fails-production</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/llm-passes-benchmark-fails-production</guid>
      <pubDate>Tue, 21 Apr 2026 00:00:00 GMT</pubDate>
      <description>Generic metrics tell you if your LLM is wrong, not if it&apos;s wrong for your business. Why evaluating LLMs is a domain problem and how to tackle it with LLM-as-a-Judge.</description>
      <content:encoded><![CDATA[
        
        <p>You&apos;ve probably seen it this week: the McDonald&apos;s support chatbot writing Python code to reverse a linked list. A user asks for help with a script, the bot solves it in O(n) complexity, and then asks if they&apos;d like some McNuggets. The joke went viral: &quot;stop paying for Claude Code, McDonald&apos;s support is free&quot;.

&lt;Tweet id=&quot;2045780439638347793&quot; /It&apos;s easy to laugh.</p>
        <p><a href="https://emiliocarrion.com/en/blog/llm-passes-benchmark-fails-production" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>engineering</category>
      <category>verification</category>
      <category>llm</category>
      <category>evaluation</category>
    </item>
    <item>
      <title>When LLMs Generate Thousands of Tokens per Second, What Matters Won&apos;t Be the Code</title>
      <link>https://emiliocarrion.com/en/blog/disposable-code-software-dna</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/disposable-code-software-dna</guid>
      <pubDate>Tue, 14 Apr 2026 00:00:00 GMT</pubDate>
      <description>If regenerating is cheaper than maintaining, the rational strategy isn&apos;t to care for the code. It&apos;s to make it disposable by design and invest in what isn&apos;t disposable. The future of the engineer is writing DNA, not code.</description>
      <content:encoded><![CDATA[
        
        <p>Last week I ran an experiment. I took a logistics microservice that&apos;s been in production for many years, a service nobody wants to touch because the engineer who designed it is gone and the documentation is, being generous, incomplete. I asked an agent to regenerate it from scratch using only the existing tests and the contract specification.

The agent generated code. Reasonable but with flaws.</p>
        <p><a href="https://emiliocarrion.com/en/blog/disposable-code-software-dna" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>architecture</category>
      <category>verification</category>
      <category>regenerative software</category>
    </item>
    <item>
      <title>When the bottleneck is no longer engineering</title>
      <link>https://emiliocarrion.com/en/blog/bottleneck-is-no-longer-engineering</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/bottleneck-is-no-longer-engineering</guid>
      <pubDate>Tue, 07 Apr 2026 00:00:00 GMT</pubDate>
      <description>AI agents are expanding the capacity to ship software faster than organizations can generate and validate ideas. The bottleneck is shifting from engineering to ideation and validation. The answer isn&apos;t to slow down or speed up recklessly — it&apos;s to redirect surplus capacity to where it creates value.</description>
      <content:encoded><![CDATA[
        
        <p>A few weeks ago, one of the teams I support finished a development in three days that we&apos;d estimated for a full sprint. They used Claude Code, leaned on agents for the more mechanical parts, and the result was solid. Tests passing, feature complete, ready for review.

The next thing I heard was a conversation between two engineers on the team: &quot;So... what do we do now?&quot;

It was a genuine question.</p>
        <p><a href="https://emiliocarrion.com/en/blog/bottleneck-is-no-longer-engineering" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai-agents</category>
      <category>product</category>
      <category>engineering</category>
      <category>wip</category>
      <category>kanban</category>
      <category>validation</category>
    </item>
    <item>
      <title>Build the road, don&apos;t run the marathon</title>
      <link>https://emiliocarrion.com/en/blog/build-the-road-not-run-the-marathon</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/build-the-road-not-run-the-marathon</guid>
      <pubDate>Tue, 31 Mar 2026 00:00:00 GMT</pubDate>
      <description>My personal manifesto on the future of software engineering. Not an analysis. A direction.</description>
      <content:encoded><![CDATA[
        
        <p>I&apos;ve spent weeks trying to write this post. I started it three times and deleted it each time because it sounded like something I&apos;d already said.

Which makes sense. I&apos;ve been writing for months about how AI is changing software engineering. About the opaque code already running in production. About the heuristics seniors can&apos;t explain. About why verification is the new core work.</p>
        <p><a href="https://emiliocarrion.com/en/blog/build-the-road-not-run-the-marathon" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>software engineering</category>
      <category>future</category>
      <category>ai</category>
      <category>manifesto</category>
    </item>
    <item>
      <title>Discipline Doesn&apos;t Scale. Verification Needs Infrastructure.</title>
      <link>https://emiliocarrion.com/en/blog/verification-needs-infrastructure</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/verification-needs-infrastructure</guid>
      <pubDate>Mon, 30 Mar 2026 00:00:00 GMT</pubDate>
      <description>Individual discipline as a quality system is a fragile design. Tests scaled because they became infrastructure. Verification needs to do the same.</description>
      <content:encoded><![CDATA[
        
        <p>Last week, a non-technical person in my circle built a working tool using AI. Not a prototype or a demo, something that did what it was supposed to do, with passing tests and a clean interface.

I took a look and my first reaction was &quot;this is surprisingly good.&quot; The second was &quot;I have no idea if this should go to production.&quot; Because &quot;it works&quot; and &quot;it&apos;s correct&quot; are not the same thing.</p>
        <p><a href="https://emiliocarrion.com/en/blog/verification-needs-infrastructure" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>engineering</category>
      <category>verification</category>
      <category>leadership</category>
      <category>architecture</category>
    </item>
    <item>
      <title>Generating Is Easy. Verifying Is the Work.</title>
      <link>https://emiliocarrion.com/en/blog/generating-easy-verifying-work</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/generating-easy-verifying-work</guid>
      <pubDate>Sun, 29 Mar 2026 00:00:00 GMT</pubDate>
      <description>Anthropic separated the agent that generates from the one that evaluates, and quality skyrocketed. That pattern describes the future of software engineering: generation is commodity. Verification is craft.</description>
      <content:encoded><![CDATA[
        
        <p>A study by METR had 16 experienced developers complete real tasks in their own repositories, randomizing whether they could use AI or not. Small sample, but rigorous experimental design: real tasks, their own repos, random assignment. Those who used AI took 19% longer. But the interesting part is that, before starting, they estimated AI would make them 24% faster.</p>
        <p><a href="https://emiliocarrion.com/en/blog/generating-easy-verifying-work" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>engineering</category>
      <category>architecture</category>
      <category>leadership</category>
      <category>verification</category>
    </item>
    <item>
      <title>AI and Cognitive Debt: What I&apos;ve Learned Using It Daily</title>
      <link>https://emiliocarrion.com/en/blog/ai-cognitive-debt</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/ai-cognitive-debt</guid>
      <pubDate>Thu, 26 Mar 2026 00:00:00 GMT</pubDate>
      <description>AI multiplies your analytical capacity, but it can atrophy your thinking if you don&apos;t use it with intention. Three scientific studies and real-world experience from a Staff Engineer who uses it every day.</description>
      <content:encoded><![CDATA[
        <p><em>Collaboration with Alejandro Capdevila Tárrega.</em></p>
        <p>Whether we like it or not, AI has burst into our work environment and disrupted the status quo we&apos;d maintained for years. I currently work as a Staff Engineer with seven teams under my umbrella, and I use AI every day: cross-cutting analyses, spikes where I try different approaches before committing to one, architectural decisions that impact multiple teams, and a long list of other things.</p>
        <p><a href="https://emiliocarrion.com/en/blog/ai-cognitive-debt" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Alejandro Capdevila Tárrega)</author>
      <category>ai</category>
      <category>career</category>
      <category>engineering</category>
    </item>
    <item>
      <title>How I Built a Digital Twin of València (and Why I Don&apos;t Know If It&apos;s Art or Engineering)</title>
      <link>https://emiliocarrion.com/en/blog/digital-twin-valencia-breathes</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/digital-twin-valencia-breathes</guid>
      <pubDate>Wed, 25 Mar 2026 00:00:00 GMT</pubDate>
      <description>During Fallas I built València Respira: a real-time visual installation with eleven layers of live data. This article covers the technical and design decisions behind the piece, and what I learned building something that doesn&apos;t fit into any category.</description>
      <content:encoded><![CDATA[
        
        <p>I&apos;ve been wanting to write this for days and couldn&apos;t find the angle. Because this isn&apos;t an article about software architecture. Or open data. Or digital art. It&apos;s about all three at once, and I&apos;m not sure in what order to put them.

I&apos;ll try in the most honest way I can: by recounting the decisions I made and why.

It All Started with a Fallas Dashboard

Nit del Foc 2026.</p>
        <p><a href="https://emiliocarrion.com/en/blog/digital-twin-valencia-breathes" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>architecture</category>
      <category>software design</category>
      <category>career</category>
    </item>
    <item>
      <title>Your AI Agent Doesn&apos;t Need to Think Better. It Needs to Know When It Screwed Up.</title>
      <link>https://emiliocarrion.com/en/blog/ai-agent-needs-verification</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/ai-agent-needs-verification</guid>
      <pubDate>Mon, 16 Mar 2026 00:00:00 GMT</pubDate>
      <description>Teams getting real value from agents don&apos;t have magical models. They have verification loops that catch failures fast and force correction with external signals.</description>
      <content:encoded><![CDATA[
        
        <p>This week Karpathy published autoresearch. He left an agent running solo on a GPU overnight. 126 experiments. It discarded 102 changes that improved nothing, kept 23 that did. By morning, the model had improved more than a researcher would have achieved in weeks of manual tuning.

And the first thing I thought was: this isn&apos;t about the agent being smarter.</p>
        <p><a href="https://emiliocarrion.com/en/blog/ai-agent-needs-verification" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>testing</category>
      <category>software quality</category>
    </item>
    <item>
      <title>The Selfish Senior</title>
      <link>https://emiliocarrion.com/en/blog/selfish-senior</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/selfish-senior</guid>
      <pubDate>Sun, 15 Mar 2026 00:00:00 GMT</pubDate>
      <description>When a senior hoards knowledge in their head, the team is left without a safety net. With AI accelerating code creation, sharing context is no longer a nice-to-have -- it&apos;s a critical responsibility.</description>
      <content:encoded><![CDATA[
        
        <p>Last week I got on stage at T3chFest to talk about something I was embarrassed about. This is the extended version of that talk, with the references and context that don&apos;t fit in 50 minutes.

When I submitted the proposal back in November, I thought I&apos;d be talking about mentoring. About how seniors should share more. An important but calm topic.

Since then, things have happened.</p>
        <p><a href="https://emiliocarrion.com/en/blog/selfish-senior" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>career</category>
      <category>leadership</category>
      <category>ai</category>
    </item>
    <item>
      <title>AI Won&apos;t Replace the Software Engineer. It Will Replace the One Who Only Wrote Code.</title>
      <link>https://emiliocarrion.com/en/blog/ai-wont-replace-software-engineer</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/ai-wont-replace-software-engineer</guid>
      <pubDate>Fri, 06 Mar 2026 00:00:00 GMT</pubDate>
      <description>Dario Amodei says AI will replace engineers in 6-12 months. Jensen Huang says we shouldn&apos;t learn to code. I&apos;ve been thinking about this for months. I don&apos;t have all the answers, but I do have a stance.</description>
      <content:encoded><![CDATA[
        
        <p>I&apos;ve had this on my mind for months.

In January, Dario Amodei took the stage at Davos and said we&apos;re 6-12 months away from AI doing &quot;most, maybe all&quot; of what a software engineer does. Jensen Huang has been saying since 2024 that kids shouldn&apos;t learn to code. Zuckerberg predicts that AI will write most of Meta&apos;s code before the year is out.</p>
        <p><a href="https://emiliocarrion.com/en/blog/ai-wont-replace-software-engineer" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>leadership</category>
      <category>career</category>
    </item>
    <item>
      <title>Invisible Heuristics: What Seniors Know but Can&apos;t Explain</title>
      <link>https://emiliocarrion.com/en/blog/invisible-heuristics-seniors</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/invisible-heuristics-seniors</guid>
      <pubDate>Mon, 02 Mar 2026 00:00:00 GMT</pubDate>
      <description>Senior engineers resolve incidents faster, but they can&apos;t explain how they do it. Gary Klein discovered the same thing with firefighters in 1984: tacit knowledge is built through experience and can&apos;t be easily articulated. This matters now more than ever.</description>
      <content:encoded><![CDATA[
        
        <p>In 1984, a psychologist named Gary Klein sat down with a group of veteran fire commanders with a simple question: how do you make decisions when a building is burning?

They all told him the same thing: &quot;We don&apos;t make decisions. We just follow the procedure.&quot;

Klein didn&apos;t buy it. He asked them to describe their last complicated fire.</p>
        <p><a href="https://emiliocarrion.com/en/blog/invisible-heuristics-seniors" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>leadership</category>
      <category>software quality</category>
    </item>
    <item>
      <title>The Code Nobody Understands Is Already in Production</title>
      <link>https://emiliocarrion.com/en/blog/opaque-code-ai-operation</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/opaque-code-ai-operation</guid>
      <pubDate>Thu, 19 Feb 2026 00:00:00 GMT</pubDate>
      <description>AI writes code faster than ever. But there&apos;s a trade-off almost nobody talks about: we&apos;re exchanging development speed for operational opacity. And that exchange isn&apos;t free.</description>
      <content:encoded><![CDATA[
        
        <p>A colleague recently told me a story I can&apos;t get out of my head.

Alert at 2 AM. Latency spiking on a critical e-commerce service. The on-call engineer opens the code, checks the logs, reviews the metrics. Everything looks fine but the system is dying.

Three hours later, they find the problem. A piece of the service had been generated almost entirely with Copilot months earlier.</p>
        <p><a href="https://emiliocarrion.com/en/blog/opaque-code-ai-operation" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>technical debt</category>
      <category>software quality</category>
    </item>
    <item>
      <title>The Senior Engineer Is Dead. Long Live the Expert Generalist</title>
      <link>https://emiliocarrion.com/en/blog/expert-generalist-senior-engineer</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/expert-generalist-senior-engineer</guid>
      <pubDate>Mon, 16 Feb 2026 00:00:00 GMT</pubDate>
      <description>The classic senior engineer -- extreme depth in one stack, focused on implementation -- is becoming obsolete. The natural evolution is becoming an expert generalist: real technical depth with the breadth of judgment to connect technology with business.</description>
      <content:encoded><![CDATA[
        
        <p>A few months ago we had a production outage affecting order preparation in stores. The stock system wasn&apos;t updating correctly and pickers were working with stale data. Every minute counted (we&apos;re talking about physical stores, real people waiting for products on the shelf).

We had two engineers available to tackle the problem. One was an absolute wizard with the framework we used.</p>
        <p><a href="https://emiliocarrion.com/en/blog/expert-generalist-senior-engineer" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>career</category>
      <category>leadership</category>
      <category>ai</category>
    </item>
    <item>
      <title>The Bill Nobody Saw Coming: Business Case and Tokens to Scale Your AI Feature Without Going Broke</title>
      <link>https://emiliocarrion.com/en/blog/ai-feature-business-case-tokens</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/ai-feature-business-case-tokens</guid>
      <pubDate>Fri, 13 Feb 2026 00:00:00 GMT</pubDate>
      <description>Integrating AI without a rigorous business case can turn a great feature into a cost nightmare. Here&apos;s how to estimate better and optimize tokens without sacrificing quality.</description>
      <content:encoded><![CDATA[
        
        <p>Monday, 9:07 AM. Slack message: &quot;Hey, can we review the cost of the AI feature?&quot; That message landed just one week after deployment, and it caught us still riding the high. During the pilot everything had gone smoothly: few users, contained consumption, and very positive feedback. It looked like one of those stories where everything clicks on the first try.</p>
        <p><a href="https://emiliocarrion.com/en/blog/ai-feature-business-case-tokens" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>product</category>
      <category>business</category>
    </item>
    <item>
      <title>96% don&apos;t trust AI-generated code. Only 48% verify it. Houston, we have a problem.</title>
      <link>https://emiliocarrion.com/en/blog/verification-bottleneck-ai</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/verification-bottleneck-ai</guid>
      <pubDate>Wed, 11 Feb 2026 00:00:00 GMT</pubDate>
      <description>Almost everyone uses AI to code, but very few always verify the code these tools generate. This creates a verification debt that could get very expensive.</description>
      <content:encoded><![CDATA[
        
        <p>Let me tell you something that happened to me about a year ago. I was in one of those Erasmus-style rotations I do as a Staff Engineer, embedded within a team working on dashboards for store fulfillment. Excited by the power of AI tools, I decided to use them to generate tests and part of the implementation. Everything looked good. I pushed the PR and went on my merry way.</p>
        <p><a href="https://emiliocarrion.com/en/blog/verification-bottleneck-ai" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ai</category>
      <category>technical debt</category>
      <category>software quality</category>
    </item>
    <item>
      <title>Pretty Code Doesn&apos;t Pay the Bills (But Pragmatism Does)</title>
      <link>https://emiliocarrion.com/en/blog/pretty-code-doesnt-pay-bills</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/pretty-code-doesnt-pay-bills</guid>
      <pubDate>Tue, 03 Feb 2026 00:00:00 GMT</pubDate>
      <description>Technical purism doesn&apos;t pay the bills. Learn when to prioritize speed, when to invest in architecture, and how to use technical debt strategically.</description>
      <content:encoded><![CDATA[
        
        <p>This week I&apos;ve been reflecting on a misunderstanding I&apos;ve seen repeat itself throughout my career over and over: confusing pretty code with professionalism. The reality is a bit more complicated than that.

&lt;Callout type=&quot;important&quot;In 60 seconds: Writing perfect code doesn&apos;t make you a great professional.
  Technical purism can be your worst enemy when your startup needs
  speed.</p>
        <p><a href="https://emiliocarrion.com/en/blog/pretty-code-doesnt-pay-bills" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>architecture</category>
      <category>technical debt</category>
      <category>product</category>
    </item>
    <item>
      <title>The False Promise of the Single Catalog</title>
      <link>https://emiliocarrion.com/en/blog/false-promise-single-catalog</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/false-promise-single-catalog</guid>
      <pubDate>Tue, 27 Jan 2026 00:00:00 GMT</pubDate>
      <description>There&apos;s a phrase that appears with unsettling regularity in multinational companies: &quot;We sell the same products in multiple countries. We should have a single catalog.&quot;</description>
      <content:encoded><![CDATA[
        <p><em>Collaboration with Sergio Pérez Andrés.</em></p>
        <p>There&apos;s a phrase that appears with unsettling regularity in multinational companies:
&quot;We sell the same products in multiple countries. We should have a single catalog.&quot;

It&apos;s usually said with conviction. As if it were a self-evident technical truth, not an organizational decision.
And it almost always comes with the implicit promise of order, efficiency, and control.</p>
        <p><a href="https://emiliocarrion.com/en/blog/false-promise-single-catalog" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Sergio Pérez Andrés)</author>
      <category>leadership</category>
      <category>culture</category>
      <category>business</category>
    </item>
    <item>
      <title>440 million in 45 minutes: 7 signs your service is about to fail</title>
      <link>https://emiliocarrion.com/en/blog/signs-service-about-to-fail</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/signs-service-about-to-fail</guid>
      <pubDate>Sat, 22 Nov 2025 00:00:00 GMT</pubDate>
      <description>The Knight Capital story and the 7 unmistakable signs (like the Bus Factor or Friday deployments) that your service is on the verge of collapse.</description>
      <content:encoded><![CDATA[
        
        <p>Before we dive in, let me tell you every SRE&apos;s favorite horror story.

440 million lost in 45 minutes

It happened on the morning of August 1, 2012. Knight Capital Group, one of Wall Street&apos;s largest trading firms, was deploying a software update.

They had 8 servers. The operations team updated the software on 7 of them... but forgot one.

The problem?</p>
        <p><a href="https://emiliocarrion.com/en/blog/signs-service-about-to-fail" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>postmortem</category>
      <category>sre</category>
      <category>culture</category>
    </item>
    <item>
      <title>Why do we write tests? (The CTO who didn&apos;t get it)</title>
      <link>https://emiliocarrion.com/en/blog/testing-business-value</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/testing-business-value</guid>
      <pubDate>Sun, 09 Nov 2025 00:00:00 GMT</pubDate>
      <description>Software that doesn&apos;t solve the problem it was created for is worthless. Discover why tests are the only guarantee of value.</description>
      <content:encoded><![CDATA[
        
        <p>We often debate about architectures, design patterns, system design... And those are incredibly important topics, but they&apos;re not the important part of software.

Because why do we create software in the first place? What do we get paid for?

The answer is simple: to solve problems. With software we create value by solving different problems within a business.</p>
        <p><a href="https://emiliocarrion.com/en/blog/testing-business-value" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>testing</category>
      <category>software quality</category>
      <category>business</category>
    </item>
    <item>
      <title>Ownership: The Invisible Superpower</title>
      <link>https://emiliocarrion.com/en/blog/ownership-superpower</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/ownership-superpower</guid>
      <pubDate>Fri, 31 Oct 2025 00:00:00 GMT</pubDate>
      <description>&quot;It worked on my machine.&quot; Ownership is what separates just another developer from someone who actually builds product.</description>
      <content:encoded><![CDATA[
        
        <p>You know what? This week I&apos;ve been thinking a lot about those phrases we&apos;ve all heard (or worse, said) at some point:
&quot;It worked on my machine&quot;
&quot;I just did what the ticket said&quot;
&quot;That&apos;s not my problem&quot;

And I&apos;ve realized they all have something in common: they reflect a lack of ownership.</p>
        <p><a href="https://emiliocarrion.com/en/blog/ownership-superpower" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>career</category>
      <category>soft skills</category>
      <category>leadership</category>
    </item>
    <item>
      <title>Technical Debt and the In-Laws Metaphor</title>
      <link>https://emiliocarrion.com/en/blog/technical-debt-explained-to-inlaws</link>
      <guid isPermaLink="true">https://emiliocarrion.com/en/blog/technical-debt-explained-to-inlaws</guid>
      <pubDate>Mon, 27 Oct 2025 00:00:00 GMT</pubDate>
      <description>Is technical debt bad? Spoiler: No. But there&apos;s a catch. Learn how to manage it using the kitchen and in-laws metaphor.</description>
      <content:encoded><![CDATA[
        
        <p>This week we&apos;re talking about one of those topics that divides opinions in every development team: technical debt. And I&apos;ll start with the question I always ask in my trainings:

Is technical debt bad?

Spoiler: No. But there&apos;s a catch.

The Myth of Technical Debt

Technical debt isn&apos;t bad per se. It&apos;s a strategic tool we can use to deliver value sooner and learn from it.</p>
        <p><a href="https://emiliocarrion.com/en/blog/technical-debt-explained-to-inlaws" style="color: #10b981; font-weight: bold; text-decoration: none;">Continue reading the full article →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>technical debt</category>
      <category>leadership</category>
      <category>software quality</category>
    </item>
  </channel>
</rss>