<?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</link>
    <description>Reflexiones sobre ingeniería de software, liderazgo técnico y desarrollo profesional</description>
    <language>es</language>
    <lastBuildDate>Sun, 10 May 2026 11:58:33 GMT</lastBuildDate>
    <atom:link href="https://emiliocarrion.com/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</link>
    </image>

    <item>
      <title>Las siete leyes no escritas que la IA cobra más caro</title>
      <link>https://emiliocarrion.com/blog/siete-leyes-no-escritas-ingenieria-ia</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/siete-leyes-no-escritas-ingenieria-ia</guid>
      <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
      <description>Esta semana vi a un compañero subir nueve PRs en un día. Trabajo bien hecho, asistido por IA. La velocidad es lo que celebramos, pero las reglas no escritas de la ingeniería, esas que se aprenden a base de romperlas, ahora se cobran antes y más caro. Las siete leyes, y cómo la IA cambia el cálculo de todas.</description>
      <content:encoded><![CDATA[
        
        <p>Llevo unas semanas con una sensación rara en el cuerpo, y creo que no soy el único.

Esta semana, revisando lo que estaba haciendo un compañero de equipo, vi que había subido nueve pull requests en un día. Nueve. Cada una asociada a una versión de despliegue, porque tenemos despliegue continuo. Y no era una mañana caótica de hotfixes. Era trabajo normal, bien hecho, asistido por IA.</p>
        <p><a href="https://emiliocarrion.com/blog/siete-leyes-no-escritas-ingenieria-ia" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>ingeniería</category>
      <category>operaciones</category>
      <category>calidad de software</category>
    </item>
    <item>
      <title>El ADN del software no era un concepto. Era 24 archivos.</title>
      <link>https://emiliocarrion.com/blog/adn-software-24-archivos</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/adn-software-24-archivos</guid>
      <pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate>
      <description>Hace tres semanas defendí que el código se iba a volver desechable y lo importante sería el ADN del software. Me encerré a comprobar si esa idea era escribible de verdad. Lo que sale: 24 archivos, dos regeneraciones por menos de un euro cada una, un repo público, y bastante claridad sobre lo que el harness engineering aún no resuelve.</description>
      <content:encoded><![CDATA[
        
        <p>Hace tres semanas saqué la bola de cristal e intenté adivinar el futuro 🔮: cuando los LLMs generen miles de tokens por segundo, regenerar código será más barato que mantenerlo (y más rápido incluso que leerlo!). Y entonces la pregunta deja de ser &quot;¿cómo escribo bien código?&quot; y pasa a ser &quot;¿qué información permite regenerar este sistema sin perder su identidad?&quot;. A esa información la llamé ADN.</p>
        <p><a href="https://emiliocarrion.com/blog/adn-software-24-archivos" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>arquitectura</category>
      <category>software regenerativo</category>
      <category>agentes</category>
      <category>producto</category>
    </item>
    <item>
      <title>Tu LLM aprueba el benchmark y suspende en producción</title>
      <link>https://emiliocarrion.com/blog/llm-aprueba-benchmark-suspende-produccion</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/llm-aprueba-benchmark-suspende-produccion</guid>
      <pubDate>Tue, 21 Apr 2026 00:00:00 GMT</pubDate>
      <description>Las métricas genéricas te dicen si tu LLM se equivoca, no si se equivoca para tu negocio. Por qué evaluar LLMs es un problema de dominio y cómo abordarlo con LLM-as-a-Judge.</description>
      <content:encoded><![CDATA[
        
        <p>Esta semana habrás visto el chatbot de soporte de McDonald&apos;s escribiendo código Python para invertir una linked list. El usuario le pide ayuda con un script, el bot se lo resuelve con complejidad O(n), y luego le pregunta si quiere unos McNuggets. La broma se ha hecho viral: &quot;deja de pagar por Claude Code, el soporte de McDonald&apos;s es gratis&quot;.

&lt;Tweet id=&quot;2045780439638347793&quot; /Es fácil reírse.</p>
        <p><a href="https://emiliocarrion.com/blog/llm-aprueba-benchmark-suspende-produccion" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>ingeniería</category>
      <category>verificación</category>
      <category>llm</category>
      <category>evaluación</category>
    </item>
    <item>
      <title>Cuando los LLMs generen miles de tokens por segundo, lo que importa no será el código</title>
      <link>https://emiliocarrion.com/blog/codigo-desechable-adn-software</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/codigo-desechable-adn-software</guid>
      <pubDate>Tue, 14 Apr 2026 00:00:00 GMT</pubDate>
      <description>Si regenerar es más barato que mantener, la estrategia racional no es cuidar el código. Es hacer que sea desechable por diseño e invertir en lo que no es desechable. El futuro del ingeniero es escribir ADN, no código.</description>
      <content:encoded><![CDATA[
        
        <p>La semana pasada hice un experimento. Cogí un microservicio de logística que lleva muchos años en producción, un servicio que nadie quiere tocar porque el ingeniero que lo diseñó ya no está y la documentación es, siendo generosos, incompleta. Le pedí a un agente que lo regenerara desde cero usando solo los tests existentes y la especificación de contratos.

El agente generó código.</p>
        <p><a href="https://emiliocarrion.com/blog/codigo-desechable-adn-software" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>arquitectura</category>
      <category>verificación</category>
      <category>software regenerativo</category>
    </item>
    <item>
      <title>Cuando el cuello de botella ya no es ingeniería</title>
      <link>https://emiliocarrion.com/blog/cuello-botella-no-es-ingenieria</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/cuello-botella-no-es-ingenieria</guid>
      <pubDate>Tue, 07 Apr 2026 00:00:00 GMT</pubDate>
      <description>Los agentes de IA están expandiendo la capacidad de implementar software más rápido de lo que las organizaciones pueden generar y validar ideas. El cuello de botella se mueve de ingeniería a ideación y validación. La respuesta no es frenar ni acelerar a lo loco, sino redirigir la capacidad sobrante hacia donde genera valor.</description>
      <content:encoded><![CDATA[
        
        <p>Hace unas semanas uno de los equipos que apoyo terminó un desarrollo en tres días que habíamos estimado para un sprint entero. Usaron Claude Code, tiraron de agentes para la parte más mecánica, y el resultado era correcto. Tests pasando, funcionalidad completa, listo para review.

Lo siguiente que escuché fue una conversación entre dos ingenieros del equipo: &quot;¿Y ahora qué hacemos?&quot;.</p>
        <p><a href="https://emiliocarrion.com/blog/cuello-botella-no-es-ingenieria" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>agentes-ia</category>
      <category>producto</category>
      <category>ingeniería</category>
      <category>wip</category>
      <category>kanban</category>
      <category>validación</category>
    </item>
    <item>
      <title>Construir el camino, no correr la maratón</title>
      <link>https://emiliocarrion.com/blog/construir-camino-no-correr-maraton</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/construir-camino-no-correr-maraton</guid>
      <pubDate>Tue, 31 Mar 2026 00:00:00 GMT</pubDate>
      <description>Mi manifiesto personal sobre el futuro de la ingeniería de software. No es un análisis. Es una dirección.</description>
      <content:encoded><![CDATA[
        
        <p>Llevo semanas intentando escribir este artículo. Lo he empezado tres veces y las tres lo he borrado porque sonaba a algo que ya había dicho.

Y tiene sentido. Llevo meses escribiendo sobre cómo la IA está cambiando la ingeniería de software. Sobre el código opaco que ya está en producción. Sobre las heurísticas que los seniors no saben explicar.</p>
        <p><a href="https://emiliocarrion.com/blog/construir-camino-no-correr-maraton" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ingeniería de software</category>
      <category>futuro</category>
      <category>ia</category>
      <category>manifiesto</category>
    </item>
    <item>
      <title>La disciplina no escala. La verificación necesita infraestructura.</title>
      <link>https://emiliocarrion.com/blog/verificacion-necesita-infraestructura</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/verificacion-necesita-infraestructura</guid>
      <pubDate>Mon, 30 Mar 2026 00:00:00 GMT</pubDate>
      <description>La disciplina individual como sistema de calidad es un diseño frágil. Los tests escalaron porque se convirtieron en infraestructura. La verificación necesita hacer lo mismo.</description>
      <content:encoded><![CDATA[
        
        <p>La semana pasada, un perfil no técnico de mi entorno creó una herramienta funcional usando IA. No un prototipo ni una demo, algo que hacía lo que tenía que hacer, con tests pasando y una interfaz limpia.

Le eché un vistazo y mi primera reacción fue &quot;esto está sorprendentemente bien.&quot; La segunda fue &quot;no tengo ni idea de si esto debería llegar a producción.</p>
        <p><a href="https://emiliocarrion.com/blog/verificacion-necesita-infraestructura" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>ingeniería</category>
      <category>verificación</category>
      <category>liderazgo</category>
      <category>arquitectura</category>
    </item>
    <item>
      <title>Generar es fácil. Verificar es el trabajo.</title>
      <link>https://emiliocarrion.com/blog/generar-facil-verificar-trabajo</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/generar-facil-verificar-trabajo</guid>
      <pubDate>Sun, 29 Mar 2026 00:00:00 GMT</pubDate>
      <description>Anthropic separó al agente que genera del que evalúa y la calidad se disparó. Ese patrón describe el futuro de la ingeniería de software: la generación es commodity. La verificación es craft.</description>
      <content:encoded><![CDATA[
        
        <p>Un estudio de METR puso a 16 developers experimentados a completar tareas reales en sus propios repositorios, aleatorizando si podían usar IA o no. Muestra pequeña, pero diseño experimental riguroso: tareas reales, repositorios propios, asignación aleatoria. Los que usaron IA tardaron un 19% más. Pero lo interesante es que, antes de empezar, estimaron que la IA les haría un 24% más rápidos.</p>
        <p><a href="https://emiliocarrion.com/blog/generar-facil-verificar-trabajo" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>ingeniería</category>
      <category>arquitectura</category>
      <category>liderazgo</category>
      <category>verificación</category>
    </item>
    <item>
      <title>IA y deuda cognitiva: lo que he aprendido usándola a diario</title>
      <link>https://emiliocarrion.com/blog/ia-deuda-cognitiva</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/ia-deuda-cognitiva</guid>
      <pubDate>Thu, 26 Mar 2026 00:00:00 GMT</pubDate>
      <description>La IA multiplica tu capacidad de análisis, pero puede atrofiar tu pensamiento si no la usas con intención. Tres estudios científicos y experiencia real de un Staff Engineer que la usa a diario.</description>
      <content:encoded><![CDATA[
        <p><em>Colaboración con Alejandro Capdevila Tárrega.</em></p>
        <p>Nos guste más o menos, la IA ha irrumpido en nuestro entorno laboral trastocando el status quo que manteníamos desde hace años. Actualmente trabajo como Staff Engineer con siete equipos bajo mi paraguas, y uso IA todos los días: análisis transversales, spikes donde pruebo enfoques distintos antes de comprometerme con uno, decisiones arquitectónicas que impactan a varios equipos, y un largo...</p>
        <p><a href="https://emiliocarrion.com/blog/ia-deuda-cognitiva" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Alejandro Capdevila Tárrega)</author>
      <category>ia</category>
      <category>carrera</category>
      <category>ingeniería</category>
    </item>
    <item>
      <title>Cómo construí un gemelo digital de València (y por qué no sé si es arte o ingeniería)</title>
      <link>https://emiliocarrion.com/blog/gemelo-digital-valencia-respira</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/gemelo-digital-valencia-respira</guid>
      <pubDate>Wed, 25 Mar 2026 00:00:00 GMT</pubDate>
      <description>Durante las Fallas construí València Respira: una instalación visual en tiempo real con once capas de datos vivos. Este artículo cuenta las decisiones técnicas y de diseño detrás de la pieza, y lo que aprendí construyendo algo que no encaja en ninguna categoría.</description>
      <content:encoded><![CDATA[
        
        <p>Llevo días queriendo escribir esto y no encontraba el ángulo. Porque no es un artículo sobre arquitectura de software. Ni sobre datos abiertos. Ni sobre arte digital. Es sobre las tres cosas a la vez, y no sé muy bien en qué orden ponerlas.

Voy a intentarlo de la forma más honesta que pueda: contando las decisiones que tomé y por qué.</p>
        <p><a href="https://emiliocarrion.com/blog/gemelo-digital-valencia-respira" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>arquitectura</category>
      <category>diseño de software</category>
      <category>carrera</category>
    </item>
    <item>
      <title>Tu agente de IA no necesita pensar mejor. Necesita saber cuándo la ha cagado.</title>
      <link>https://emiliocarrion.com/blog/agente-ia-necesita-verificacion</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/agente-ia-necesita-verificacion</guid>
      <pubDate>Mon, 16 Mar 2026 00:00:00 GMT</pubDate>
      <description>Los equipos que sacan valor real de agentes no tienen modelos mágicos. Tienen verification loops que detectan fallos rápido y fuerzan corrección con señales externas.</description>
      <content:encoded><![CDATA[
        
        <p>Esta semana Karpathy publicó autoresearch. Dejó un agente corriendo solo en una GPU toda la noche. 126 experimentos. Descartó 102 cambios que no mejoraban nada, se quedó con 23 que sí. Por la mañana, el modelo había mejorado más de lo que un investigador habría sacado en semanas de ajuste manual.

Y lo primero que pensé fue: esto no va de que el agente sea más listo.</p>
        <p><a href="https://emiliocarrion.com/blog/agente-ia-necesita-verificacion" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>testing</category>
      <category>calidad de software</category>
    </item>
    <item>
      <title>El Senior Egoísta</title>
      <link>https://emiliocarrion.com/blog/senior-egoista</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/senior-egoista</guid>
      <pubDate>Sun, 15 Mar 2026 00:00:00 GMT</pubDate>
      <description>Cuando un senior acumula conocimiento en su cabeza, el equipo se queda sin red. Con la IA acelerando la creación de código, compartir contexto deja de ser una buena práctica y pasa a ser una responsabilidad crítica.</description>
      <content:encoded><![CDATA[
        
        <p>La semana pasada subí al escenario de T3chFest a contar algo que me daba vergüenza. Esto es la versión extendida de esa charla, con las referencias y el contexto que no caben en 50 minutos.

Cuando mandé la propuesta de esta charla en noviembre, pensaba que iba a hablar de mentoring. De cómo los seniors deberían compartir más. Un tema importante, pero tranquilo.

Desde entonces han pasado cosas.</p>
        <p><a href="https://emiliocarrion.com/blog/senior-egoista" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>carrera</category>
      <category>liderazgo</category>
      <category>ia</category>
    </item>
    <item>
      <title>La IA no va a eliminar al ingeniero de software. Va a eliminar al que solo escribía código.</title>
      <link>https://emiliocarrion.com/blog/ia-no-elimina-ingeniero-software</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/ia-no-elimina-ingeniero-software</guid>
      <pubDate>Fri, 06 Mar 2026 00:00:00 GMT</pubDate>
      <description>Dario Amodei dice que la IA reemplazará a los ingenieros en 6-12 meses. Jensen Huang dice que no deberíamos aprender a programar. Llevo meses dándole vueltas a esto. No tengo todas las respuestas, pero sí tengo una postura.</description>
      <content:encoded><![CDATA[
        
        <p>Llevo meses con esto en la cabeza.

En enero, Dario Amodei subió al escenario de Davos y dijo que estamos a 6-12 meses de que la IA haga &quot;la mayoría, quizá todo&quot; lo que hace un ingeniero de software. Jensen Huang lleva desde 2024 repitiendo que los niños no deberían aprender a programar. Zuckerberg predice que la IA escribirá la mayor parte del código de Meta antes de que acabe el año.</p>
        <p><a href="https://emiliocarrion.com/blog/ia-no-elimina-ingeniero-software" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>liderazgo</category>
      <category>carrera</category>
    </item>
    <item>
      <title>Las heurísticas invisibles: lo que los seniors saben y no saben explicar</title>
      <link>https://emiliocarrion.com/blog/heuristicas-invisibles-seniors</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/heuristicas-invisibles-seniors</guid>
      <pubDate>Mon, 02 Mar 2026 00:00:00 GMT</pubDate>
      <description>Los ingenieros seniors resuelven incidentes más rápido, pero no pueden explicar cómo lo hacen. Gary Klein descubrió lo mismo con bomberos en 1984: el conocimiento tácito se adquiere con experiencia y no se puede articular fácilmente. Esto importa ahora más que nunca.</description>
      <content:encoded><![CDATA[
        
        <p>En 1984, un psicólogo llamado Gary Klein se sentó frente a un grupo de comandantes de bomberos veteranos con una pregunta simple: ¿cómo tomáis decisiones cuando un edificio se está quemando?

Todos le dijeron lo mismo: &quot;No tomamos decisiones. Simplemente seguimos el procedimiento.&quot;

Klein no se lo creyó. Les pidió que describieran su último incendio complicado.</p>
        <p><a href="https://emiliocarrion.com/blog/heuristicas-invisibles-seniors" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>liderazgo</category>
      <category>calidad de software</category>
    </item>
    <item>
      <title>El código que nadie entiende ya está en producción</title>
      <link>https://emiliocarrion.com/blog/codigo-opaco-ia-operacion</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/codigo-opaco-ia-operacion</guid>
      <pubDate>Thu, 19 Feb 2026 00:00:00 GMT</pubDate>
      <description>La IA escribe código más rápido que nunca. Pero hay un trade-off del que casi nadie habla: estamos intercambiando velocidad de desarrollo por opacidad operacional. Y ese intercambio no es gratis.</description>
      <content:encoded><![CDATA[
        
        <p>Hace poco me contó un colega una historia que no me puedo quitar de la cabeza.

Alerta a las 2 AM. Latencia disparada en un servicio crítico de e-commerce. El ingeniero de guardia abre el código, mira los logs, revisa las métricas. Todo parece correcto pero el sistema se está muriendo.

Tres horas después, descubren el problema.</p>
        <p><a href="https://emiliocarrion.com/blog/codigo-opaco-ia-operacion" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>deuda técnica</category>
      <category>calidad de software</category>
    </item>
    <item>
      <title>El Senior Engineer está muerto. Larga vida al Experto Generalista</title>
      <link>https://emiliocarrion.com/blog/experto-generalista-senior-engineer</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/experto-generalista-senior-engineer</guid>
      <pubDate>Mon, 16 Feb 2026 00:00:00 GMT</pubDate>
      <description>El senior engineer clásico (profundidad extrema en un stack, foco en implementación) se está quedando obsoleto. La evolución natural es convertirte en experto generalista: profundidad técnica real con amplitud de criterio para conectar tecnología con negocio.</description>
      <content:encoded><![CDATA[
        
        <p>Hace unos meses tuvimos una caída en producción que afectaba a la preparación de pedidos en tiendas. El sistema de stock no actualizaba correctamente y los preparadores estaban trabajando con datos desactualizados. Cada minuto contaba (hablamos de tiendas físicas, gente real esperando producto en el lineal).

Teníamos a dos ingenieros disponibles para atacar el problema.</p>
        <p><a href="https://emiliocarrion.com/blog/experto-generalista-senior-engineer" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>carrera</category>
      <category>liderazgo</category>
      <category>ia</category>
    </item>
    <item>
      <title>La factura que nadie vio venir: business case y tokens para que tu feature de IA escale sin arruinarte</title>
      <link>https://emiliocarrion.com/blog/feature-ia-business-case-tokens</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/feature-ia-business-case-tokens</guid>
      <pubDate>Fri, 13 Feb 2026 00:00:00 GMT</pubDate>
      <description>Integrar IA sin un business case riguroso puede convertir una gran feature en un problema de costes. Así puedes estimar mejor y optimizar tokens sin perder calidad.</description>
      <content:encoded><![CDATA[
        
        <p>Lunes, 9:07 de la mañana. Mensaje en Slack: &quot;Oye, ¿podemos revisar el coste de la feature de IA?&quot;. Ese mensaje llegó solo una semana después del despliegue, y nos pilló con la euforia todavía encima. En el piloto todo había ido bien: pocos usuarios, consumo contenido y feedback muy positivo. Parecía una de esas historias donde todo encaja a la primera.</p>
        <p><a href="https://emiliocarrion.com/blog/feature-ia-business-case-tokens" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>producto</category>
      <category>negocio</category>
    </item>
    <item>
      <title>El 96% no confía en el código de la IA. Solo el 48% lo verifica. Houston, tenemos un problema.</title>
      <link>https://emiliocarrion.com/blog/verification-bottleneck-ia</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/verification-bottleneck-ia</guid>
      <pubDate>Wed, 11 Feb 2026 00:00:00 GMT</pubDate>
      <description>Casi todos usamos IA para programar, pero muy pocos verifican siempre el código que generan las herramientas. Así nace una deuda de verificación que puede salir carísima.</description>
      <content:encoded><![CDATA[
        
        <p>Déjame contarte algo que me pasó hace cosa de un año. Estaba en una de esas etapas Erasmus que hago como Staff Engineer, integrado dentro de un equipo que trabaja en dashboards para la preparación en tiendas. Yo, emocionado con la potencia de las herramientas de IA, decidí usarla para generar tests y parte de la implementación. Todo pintaba bien. Subí la PR y me fui tan contento.</p>
        <p><a href="https://emiliocarrion.com/blog/verification-bottleneck-ia" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>ia</category>
      <category>deuda técnica</category>
      <category>calidad de software</category>
    </item>
    <item>
      <title>El código bonito no paga facturas (pero el pragmatismo sí)</title>
      <link>https://emiliocarrion.com/blog/codigo-bonito-no-paga-facturas</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/codigo-bonito-no-paga-facturas</guid>
      <pubDate>Tue, 03 Feb 2026 00:00:00 GMT</pubDate>
      <description>El purismo técnico no paga facturas. Aprende a decidir cuándo priorizar velocidad, cuándo invertir en arquitectura y cómo usar la deuda técnica con cabeza.</description>
      <content:encoded><![CDATA[
        
        <p>Esta semana he estado reflexionando sobre un malentendido que he visto repetirse en mi carrera una y otra vez: confundir código bonito con profesionalidad. Y es que la realidad es algo más complicada.

&lt;Callout type=&quot;important&quot;En 60 segundos: Escribir código perfecto no te hace un gran profesional.
  El purismo técnico puede ser tu peor enemigo cuando tu startup necesita
  velocidad.</p>
        <p><a href="https://emiliocarrion.com/blog/codigo-bonito-no-paga-facturas" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>arquitectura</category>
      <category>deuda técnica</category>
      <category>producto</category>
    </item>
    <item>
      <title>La falsa promesa del catálogo único</title>
      <link>https://emiliocarrion.com/blog/la-falsa-promesa-catalogo-unico</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/la-falsa-promesa-catalogo-unico</guid>
      <pubDate>Tue, 27 Jan 2026 00:00:00 GMT</pubDate>
      <description>Hay una frase que aparece con una regularidad inquietante en empresas multinacionales: “Vendemos los mismos productos en varios países. Deberíamos tener un único catálogo.”</description>
      <content:encoded><![CDATA[
        <p><em>Colaboración con Sergio Pérez Andrés.</em></p>
        <p>Hay una frase que aparece con una regularidad inquietante en empresas multinacionales:
“Vendemos los mismos productos en varios países. Deberíamos tener un único catálogo.”

Suele decirse con convicción. Como si fuera una verdad técnica evidente, no una decisión organizativa.
Y casi siempre llega acompañada de la promesa implícita de orden, eficiencia y control.</p>
        <p><a href="https://emiliocarrion.com/blog/la-falsa-promesa-catalogo-unico" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Sergio Pérez Andrés)</author>
      <category>liderazgo</category>
      <category>cultura</category>
      <category>negocio</category>
    </item>
    <item>
      <title>440 millones en 45 minutos: 7 señales de que tu servicio va a fallar</title>
      <link>https://emiliocarrion.com/blog/senales-servicio-fallar</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/senales-servicio-fallar</guid>
      <pubDate>Sat, 22 Nov 2025 00:00:00 GMT</pubDate>
      <description>La historia de Knight Capital y las 7 señales inconfundibles (como el Factor Bus o el despliegue de los viernes) de que tu servicio está a punto de colapsar.</description>
      <content:encoded><![CDATA[
        
        <p>Antes de entrar en materia, déjame contarte la historia de terror favorita de todo SRE.

440 millones perdidos en 45 minutos

Ocurrió la mañana del 1 de agosto de 2012. Knight Capital Group, una de las mayores firmas de trading de Wall Street, desplegaba una actualización de su software.

Tenían 8 servidores. El equipo de operaciones actualizó el software en 7 de ellos... pero se olvidó de uno.</p>
        <p><a href="https://emiliocarrion.com/blog/senales-servicio-fallar" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>postmortem</category>
      <category>sre</category>
      <category>cultura</category>
    </item>
    <item>
      <title>¿Para qué escribimos tests? (El CTO que no entendía nada)</title>
      <link>https://emiliocarrion.com/blog/testing-valor-negocio</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/testing-valor-negocio</guid>
      <pubDate>Sun, 09 Nov 2025 00:00:00 GMT</pubDate>
      <description>El software que no resuelve el problema para el que fue creado no vale nada. Descubre por qué los tests son la única garantía de valor.</description>
      <content:encoded><![CDATA[
        
        <p>Muchas veces debatimos sobre arquitecturas, sobre patrones de diseño, sobre creación de sistemas... Y son temas súper importantes, pero no son la parte importante del software.

Porque, ¿para qué creamos software en primer lugar? ¿Para qué nos pagan?

Pues la respuesta es sencilla: para resolver problemas. Con software creamos valor resolviendo diferentes problemas dentro de un negocio.</p>
        <p><a href="https://emiliocarrion.com/blog/testing-valor-negocio" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>testing</category>
      <category>calidad de software</category>
      <category>negocio</category>
    </item>
    <item>
      <title>Ownership: El superpoder invisible</title>
      <link>https://emiliocarrion.com/blog/ownership-superpoder</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/ownership-superpoder</guid>
      <pubDate>Fri, 31 Oct 2025 00:00:00 GMT</pubDate>
      <description>&quot;En mi máquina funcionaba&quot;. El ownership es la diferencia entre ser un desarrollador más y alguien que construye producto.</description>
      <content:encoded><![CDATA[
        
        <p>¿Sabes qué? Esta semana he estado pensando mucho en esas frases que todos hemos escuchado (o peor, dicho) alguna vez:
&quot;En mi máquina funcionaba&quot;
&quot;Yo solo hice lo que decía el ticket&quot;
&quot;Ese no es mi problema&quot;

Y me he dado cuenta de que todas tienen algo en común: reflejan una falta de ownership.</p>
        <p><a href="https://emiliocarrion.com/blog/ownership-superpoder" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>carrera</category>
      <category>soft skills</category>
      <category>liderazgo</category>
    </item>
    <item>
      <title>La deuda técnica y la metáfora de los suegros</title>
      <link>https://emiliocarrion.com/blog/deuda-tecnica-suegros</link>
      <guid isPermaLink="true">https://emiliocarrion.com/blog/deuda-tecnica-suegros</guid>
      <pubDate>Mon, 27 Oct 2025 00:00:00 GMT</pubDate>
      <description>¿La deuda técnica es mala? Spoiler: No. Pero tiene truco. Descubre cómo gestionarla usando la metáfora de la cocina y los suegros.</description>
      <content:encoded><![CDATA[
        
        <p>Esta semana hablamos de uno de esos temas que divide opiniones en todos los equipos de desarrollo: la deuda técnica. Y empiezo con la pregunta que siempre hago en mis formaciones:

¿La deuda técnica es mala?

Spoiler: No. Pero tiene truco.

El mito de la deuda técnica

La deuda técnica no es mala per se.</p>
        <p><a href="https://emiliocarrion.com/blog/deuda-tecnica-suegros" style="color: #10b981; font-weight: bold; text-decoration: none;">Continúa leyendo el artículo completo →</a></p>
      ]]></content:encoded>
      <author>hola@emiliocarrion.com (Emilio Carrión)</author>
      <category>deuda técnica</category>
      <category>liderazgo</category>
      <category>calidad de software</category>
    </item>
  </channel>
</rss>