Nadie sabe nada: el coste oculto del código IA

El debate que ya nadie puede esquivar en ingeniería

El ensayo del ingeniero Simon Späti lo plantea en una frase incómoda: "El problema no es el código que escribe la IA, sino que ya nadie sabe nada". No es una queja aislada. La encuesta State of AI-assisted Software Development 2025 del equipo DORA (Google Cloud), basada en 5.000 desarrolladores, encontró que el 90% de los equipos ya usan herramientas de IA para programar, frente al 76% del año anterior, según reportó TechTarget. Es la adopción más rápida de una herramienta de desarrollo en la historia reciente — y, al mismo tiempo, el momento en que más dudas se acumulan sobre quién entiende realmente lo que se está enviando a producción.

Qué dice la fuente original sobre la nueva fábrica de código

Späti parte de una observación concreta: si tu base de código estaba por debajo de la media, la IA puede llevarla hasta la media sin demasiado esfuerzo. El problema aparece cuando todo el equipo se vuelve un intermediario entre un prompt y un repositorio. Cita un caso real de un ingeniero (alias Voxium) que llevaba medio mes en una empresa grande y describía su día así: "Las specs, el código, los tests, los tickets, las resoluciones, los reportes… todo lo hace Claude Code. Nadie lee nada. La gente trabaja 12 o 13 horas al día solo para pulsar Enter".

Späti añade un matiz que muchos fundadores obvian: los ingenieros de datos crecidos antes de la IA tenían que conocer el negocio a fondo para hacer su trabajo. Hoy, esa necesidad se evapora. Quien empieza hoy en un dominio nuevo, haciendo prompts, aprende a ejecutar tareas sin construir el modelo mental del sistema que las sostiene.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Por qué la IA amplifica lo que ya está mal (no lo arregla)

La advertencia de Späti conecta con un hallazgo central del informe DORA 2025 recogido por Diginomica: "La IA funciona principalmente como un amplificador. Magnifica las fortalezas de las organizaciones que ya rinden bien y las disfunciones de las que rinden mal". Esto es, la IA no convierte un equipo mediocre en uno excelente: lo hace más rápido en lo que ya era.

Vivek Ahuja, VP de Technology en rSTAR, lo describe en Forbes (agosto 2026) como "AI architecture debt" — deuda de arquitectura IA — y la separa del technical debt clásico: la deuda técnica se acumula por atajos en el código, la deuda de arquitectura IA se acumula por decisiones arquitectónicas que hacen cada nueva iniciativa más cara y difícil de gobernar. Según su experiencia en proyectos enterprise, los patrones problemáticos son siempre los mismos:

Knowledge debt: cada aplicación IA construye su propia copia del conocimiento de la empresa en lugar de compartir una fuente única gobernada.
Prompt debt: los prompts quedan embebidos en mil aplicaciones y nadie puede versionarlos ni mejorarlos.
Integration debt: cada solución crea conexiones punto a punto en lugar de servicios reutilizables.
Governance debt: equipos distintos aplican flujos de aprobación y políticas de seguridad incompatibles.
Evaluation debt: cada proyecto mide la calidad de la IA con métricas diferentes (o no la mide).

Los números que preocupan a founders y CTOs

La paradoja central del informe DORA 2025, según TechTarget, es que la velocidad de entrega mejoró con la IA, pero la inestabilidad del software sigue subiendo. El 70% de los desarrolladores confía "algo", "mucho" o "muchísimo" en los outputs de la IA en 2025, frente al 87,9% de 2024 — la confianza cayó casi 18 puntos mientras la adopción subía 14 puntos. Un 30% de los encuestados dice confiar "poco" o "nada" en lo que genera el modelo.

Para un founder, esto se traduce en una pregunta incómoda: si tu CTO te dice que el equipo ahora entrega el doble de features, pero la confianza en esas features bajó, ¿estás construyendo producto o acumulando pasivo oculto?

El “jefe final” del que habla Späti: el mantenimiento

Späti insiste en que "escribir código a mano puede estar muerto, pero certainly ayuda", y que el jefe final siempre ha sido — y será — la mantenibilidad. Cuanto más fácil es generar un pipeline, una app o un dashboard de BI con un prompt, más superficie de mantenimiento acumulas. Si nadie en el equipo entiende la arquitectura, el coste de cambiar esa app en seis meses puede ser mayor que el beneficio de haberla lanzado en dos semanas.

El informe DORA 2025, reportado por Diginomica, detecta exactamente el mismo síntoma en su "paradoja del tamaño de lote": los equipos que rompen su trabajo en lotes muy pequeños (commits diarios, feature flags, slices de valor) logran mejor rendimiento de producto, pero reportan menor sensación de eficacia individual — porque la fricción de revisar contexto nuevo con cada lote pequeño es alta. La conclusión operativa: la velocidad percibida no es lo mismo que la velocidad real del sistema, y la IA empeora esa disonancia si no hay procesos explícitos que la frenen.

Qué significa esto para tu startup

Si diriges un equipo técnico, el riesgo no es que la IA "escriba mal código" — Späti y DORA coinciden en que la calidad promedio de lo que genera es aceptable. El riesgo es construir una organización donde nadie sabe por qué el sistema es como es. Cuando llegue el momento de pivotar, migrar, contratar a un senior o responder a un incidente, no tendrás mapa mental del producto, solo un repositorio.

Acciones concretas para implementar esta semana:

Audita quién sabe qué. Haz una ronda de 15 minutos con cada ingeniero del equipo y pídele que dibuje en una pizarra la arquitectura del producto. Si menos del 60% puede hacerlo sin consultar código, tienes un problema de "knowledge debt" del que la IA no te va a sacar.
Bloquea “prompt debt” desde el día uno. Cualquier prompt que se use en producción debe estar versionado en el repositorio, con autor, fecha y motivo del cambio. Si tu equipo trata los prompts como mensajes de chat, vas a perder la trazabilidad en cuanto alguien rote de proyecto.
Mide mantenibilidad, no solo velocidad. Trackea tres métricas durante un trimestre: tiempo medio de recuperación (MTTR), ratio de cambios revertidos y horas-hombre necesarias para una feature equivalente a la que ya tienes. Si suben mientras la velocidad de entrega sube, estás canjeando estabilidad por throughput y la factura llegará.
Conserva la contratación junior. Späti menciona un punto clave: muchos equipos senior ya no entrenan juniors porque la IA "los reemplaza". El efecto colateral es que en dos años no habrá quien entienda los sistemas que se están construyendo hoy.