Reflexiones sobre ingenieria de software, liderazgo tecnico y como construir sistemas que realmente importan.
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.
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.
Unete a otros ingenieros que reciben reflexiones sobre carrera, liderazgo y tecnologia cada semana.
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.
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.
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.
Mi manifiesto personal sobre el futuro de la ingeniería de software. No es un análisis. Es una dirección.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
"En mi máquina funcionaba". El ownership es la diferencia entre ser un desarrollador más y alguien que construye producto.
¿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.