El Craftsmanship en la era de la IA: por qué importa más que nunca
La IA acelera el desarrollo pero no garantiza que el sistema aguante producción. Por qué el Software Craftsmanship es más relevante en 2026, no menos — con ejemplos técnicos concretos.
En 2009, un grupo de ingenieros decidió que el Manifiesto Ágil había traicionado su promesa. El proceso se había comido al software.
Los sprints terminaban con código que "pasaba la demo" pero acumulaba comportamientos inesperados en producción. Nacía el Manifesto
for Software Craftsmanship: not just working software, but well-crafted software.
Quince años después, la IA genera código más rápido de lo que cualquier engineer imaginó entonces. GitHub Copilot, Cursor, Claude. Un
engineer con las herramientas correctas produce en dos horas lo que antes tardaba dos semanas.
Y sin embargo. Los sistemas críticos siguen fallando en producción a tasas que no han mejorado proporcionalmente a la velocidad de
desarrollo. Los race conditions siguen apareciendo durante picos de tráfico. Los sistemas de pago siguen teniendo incidentes en Black
Friday.
La pregunta que me hacen los CTOs con más frecuencia en 2026: ¿el craftsmanship sigue importando cuando la IA escribe el código?
La respuesta es la misma que en 2009. Las razones son diferentes.
¿Qué prometió el Craftsmanship — y qué prometió la IA?
El Manifesto for Software Craftsmanship formuló cuatro valores que iban "más allá" del Manifiesto Ágil:
- Well-crafted software — no solo software funcional
- Steadily adding value — no solo responder al cambio
- A community of professionals — no solo colaboración individual
- Productive partnerships — no solo colaboración con el cliente
La crítica implícita era precisa: el código que se entregaba al final del sprint "funcionaba" en demo pero acumulaba deuda técnica que el siguiente equipo heredaba sin contexto, sin tests, sin documentación real de las invariantes del sistema.
La IA, en 2026, promete algo distinto: velocidad de implementación sin precedentes. El tiempo de ir de idea a código funcional ha
caído entre un 60% y un 80% para tasks bien definidas. Un LLM genera un endpoint REST con validación, un schema de base de datos con
migraciones, y un suite de tests con casos de borde, en minutos.
Pero hay una confusión que cuesta cara. La velocidad de generación de código no es lo mismo que la velocidad de entrega de valor en
producción. La IA resuelve la primera parte. La segunda sigue siendo un problema de ingeniería.
¿Por qué el código generado por IA falla donde importa?
La IA aprende de código existente en repositorios públicos. Genera implementaciones que "parecen correctas" basándose en patrones
estadísticos de millones de proyectos. Para la mayoría de los problemas funciona bien: un CRUD, un parser JSON, un cliente HTTP, una
query SQL estándar.
El problema emerge cuando el dominio requiere razonar sobre estados concurrentes, invariantes de consistencia distribuida, o
comportamientos que solo aparecen bajo carga real.
Un ejemplo que revisé hace unas semanas. Un equipo pidió a Cursor la lógica de reserva de inventario para un eCommerce:
async function reserveInventory(productId: string, qty: number): Promise<boolean> {
const item = await db.inventory.findOne({ productId });
if (item.available >= qty) {
await db.inventory.update(
{ productId },
{ $inc: { available: -qty } }
);
return true;
}
return false;
}
El código compilaba. Los tests pasaban. En desarrollo con una sola instancia, funcionaba perfectamente.
En producción, con 800 requests simultáneos durante Black Friday, generó overselling. El pattern de read-modify-write sin control de
concurrencia es un race condition clásico: dos requests leen el mismo item.available, ambos ven stock suficiente, ambos actualizan.
El inventario cae a negativo. Los pedidos quedan pendientes sin stock físico.
La IA no cometió este error por ser incapaz. Lo cometió porque el código en el que fue entrenada no incluía pruebas de carga
concurrente para este patrón. El código es estadísticamente correcto para el 99% de los proyectos que procesó. El 1% restante es producción en pico.
Este es el gap que el craftsmanship resuelve.
Cómo trabaja un craftsman en la era de la IA
El engineer con craftsmanship en 2026 no escribe menos código que sus compañeros. Trabaja de forma diferente en tres áreas.
Test-first como especificación
La práctica TDD del Software Craftsmanship siempre fue sobre diseño, no sobre testing. Escribes el test primero porque te obliga a
pensar en la interfaz, en las invariantes, en los casos de borde, antes de escribir la implementación.
Con IA, esta práctica se vuelve más poderosa. El test actúa como especificación formal que el LLM interpreta y ejecuta.
Para el ejemplo anterior, el test correcto expone la condición de fallo:
it('previene overselling con requests concurrentes', async () => {
await db.inventory.set({ productId: 'P001', available: 1 });
const results = await Promise.all(
Array(50).fill(null).map(() => reserveInventory('P001', 1))
);
const successes = results.filter(Boolean);
expect(successes).toHaveLength(1);
const final = await db.inventory.findOne({ productId: 'P001' });
expect(final.available).toBeGreaterThanOrEqual(0);
});
Este test, dado como contexto al LLM, provoca una implementación completamente diferente. El modelo genera SELECT FOR UPDATE,
transacciones con optimistic locking, o un mutex distribuido con Redis. No porque "sepa" que el primer pattern tiene un race condition
— sino porque ese test falla con la implementación naive, y el LLM ajusta.
El craftsman define las invariantes. La IA encuentra la implementación que las cumple.
Code review como primer filtro real
Cuando el compilador era el primer feedback, la revisión de código era el segundo filtro. Cuando la IA genera código que compila en el primer intento, la revisión se convierte en el único filtro real antes de producción.
El problema: revisar código generado por IA requiere el mismo rigor que revisar código de un engineer que escribe muy rápido sin
explicar su razonamiento. El código es sintácticamente correcto, los patrones son reconocibles, los tests pasan. Pero las asunciones
implícitas sobre el estado del sistema pueden ser incorrectas de formas que solo emergen bajo carga.
Los anti-patterns que aparecen con más frecuencia en auditorías de equipos que han adoptado IA masivamente:
- Concurrencia implícita: funciones async sin control de paralelismo que parecen secuenciales pero no lo son
- Errores silenciados:
try-catchque captura excepciones sin log, sin retry, sin propagación - Idempotencia inconsistente: algunas funciones son idempotentes, otras no, sin criterio explícito ni documentación
- Timeouts ausentes: llamadas a servicios externos sin timeout configurado — lo que convierte un servicio lento en un bloqueo del
sistema entero
Ninguno de estos falla en tests unitarios. Todos aparecen en producción bajo condiciones específicas de carga o error de red.
Arquitectura diseñada, no emergente
Cuando la IA genera componente tras componente iterativamente, el sistema resultante puede ser funcionalmente correcto pero
arquitectónicamente incoherente. Las abstracciones emergen del proceso de generación en lugar de ser diseñadas.
El resultado en sistemas reales: acoplamiento implícito entre módulos que deberían ser independientes, inconsistencias en el manejo de errores entre capas, fronteras de dominio borrosas que hacen imposible razonar sobre el sistema cuando algo falla a las 3AM.
El craftsman hace algo que la IA no puede: detiene el avance para refactorizar hacia la coherencia. No "cuando tengamos tiempo". De
forma continua, como parte del proceso. La IA genera deuda técnica más rápido que el ritmo de desarrollo anterior. El refactoring
continuo es lo que mantiene esa deuda bajo control.
La paradoja de la velocidad
Aquí está la tensión que nadie menciona en los comparativos de herramientas de IA.
La IA multiplica la productividad individual de forma medible. Un engineer senior con Cursor produce a una velocidad que hace dos años requería un equipo de tres. Esto es real, con números, sin matices.
Pero los sistemas de software no son la suma de productividades individuales. Son sistemas distribuidos con estado compartido,
dependencias entre componentes, y comportamientos emergentes que nadie diseñó explícitamente.
Lo que vemos en auditorías: equipos que usaron IA para acelerar el desarrollo llegaron más rápido a un sistema que "funciona". Y luego
pasaron el triple de tiempo depurando comportamientos que el sistema exhibía en producción pero no en desarrollo. El time-to-market
inicial fue mejor. El time-to-stability fue significativamente peor.
El craftsmanship produce sistemas que el equipo puede razonar cuando las cosas fallan. Un sistema generado por IA sin disciplina de
artesanía es un sistema que solo quien lo generó entiende parcialmente — y solo en el momento en que fue generado.
Cuando ese engineer sale del equipo, o cuando el sistema falla a las 3AM, el conocimiento implícito desaparece con él.
Cuándo el craftsmanship es imprescindible — y cuándo no lo es
Esto importa decirlo.
Para prototipos, scripts de un solo uso, o herramientas internas con un único usuario y sin requisitos de disponibilidad — la IA sin
disciplina adicional es perfectamente razonable. El trade-off entre velocidad y calidad se resuelve rápido: genera, usa, descarta si
no funciona.
El craftsmanship se vuelve imprescindible cuando:
El sistema tiene estado compartido entre múltiples procesos. Cualquier concurrencia no trivial requiere razonar sobre invariantes
que la IA no puede verificar por inspección del código generado. Sin tests de concurrencia, sin revisión explícita de los patterns de
acceso a estado compartido, los race conditions son prácticamente inevitables a escala.
El coste del fallo en producción supera el coste del desarrollo. En FinTech, HealthTech, Logistics en pico — un incidente puede
costar entre €100K y €6M según el sistema. Una semana adicional de revisión y tests de concurrencia tiene un ROI que no hace falta
calcular.
El sistema crece y vive durante años. El código generado por IA sin refactoring continuo acumula deuda técnica más rápido que el
código diseñado con artesanía. A 18 meses, la diferencia en coste de mantenimiento es sustancial.
El equipo necesita operar el sistema en producción. Los sistemas que nadie entiende completamente generan los incidentes más
difíciles de resolver — no porque sean más complejos, sino porque el equipo no tiene el modelo mental correcto de cómo funcionan bajo
condiciones de fallo.
Retorno a la artesanía
El Manifesto for Software Craftsmanship no anticipó la IA. Pero anticipó exactamente la presión que la IA ahora hace máxima: generar
más, más rápido, con menos cuestionamiento sobre si lo que se genera aguantará producción.
Lo que ha cambiado es la forma en que se ejerce el oficio, no su relevancia.
El craftsman en 2026 escribe tests que exponen los casos que la IA no ve. Revisa código generado con el contexto del dominio y la
experiencia de producción. Diseña para la observabilidad — porque cuando el sistema falla, necesitas saber por qué. Refactoriza hacia
la coherencia arquitectónica antes de que el sistema acumule complejidad que nadie puede razonar.
La artesanía no es un freno a la IA. Es el filtro que convierte código generado en sistemas que aguantan producción.
¿Tu equipo usa IA para acelerar el desarrollo? La pregunta no es cuánto código genera — es qué pasa con ese código cuando el Black Friday llega y el sistema procesa 50x el tráfico habitual con 200 requests concurrentes apuntando al mismo registro de inventario.