Programar con IA en 2026: ¿construir o solo aparentar?

¿Construiste un sistema enorme y no lo entiendes? Eso es exactamente lo que se discute en 2026

Mark Seemann, programador danés con más de treinta años en el oficio, publicó el 16 de septiembre de 2026 en su blog Ploeh una carta abierta titulada "On learning programming in an age of LLMs". Responde a la consulta de un lector anónimo que resume algo que muchos founders y builders de 2026 reconocerán al instante.

El lector no viene del mundo CS. Con LLMs, había levantado en aproximadamente un año un sistema grande en TypeScript y JavaScript con APIs, PostgreSQL, pipelines LLM, automatización de research y workflows multi-modelo. "Sentí que la IA colapsaba la distancia entre tener una idea y poder construirla", cuenta. Y añade la frase incómoda: "Tras meses de refactorizar, me di cuenta de algo: puede que haya construido un sistema por encima de mi propio nivel de entendimiento. Cuando todo funciona, la brecha es invisible. Cuando algo falla, se vuelve muy real".

Ese episodio es la puerta de entrada a una pregunta más incómoda: en la era de los LLMs, ¿qué significa realmente aprender a programar?

🤖 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

¿Está creciendo la deuda técnica más rápido que la productividad que la IA promete?

Los datos independientes publicados en los últimos meses cuadran con la intuición del lector. Según la encuesta DORA 2025 de Google, el 90% de los profesionales tech ya usan IA para programar, y el propio reporte asoció mayor adopción de IA con mayor inestabilidad en las entregas, según recogió Forbes en septiembre de 2026.

La advertencia se vuelve más específica en cifras posteriores:

Sonar (encuesta 2026): el 96% de los desarrolladores dice no confiar del todo en código generado por IA, pero menos de la mitad lo revisa siempre antes de hacer commit, según reportó Forbes.
GitClear (análisis de enero de 2026): los peores resultados de calidad de código son nueve veces más probables entre los usuarios más intensos de IA.
CloudBees (2026 State of Code Abundance): el 81% de los líderes técnicos empresariales reportó más issues en producción atribuibles a código IA, pese a que el 92% se sentía "confiado" al despachar ese código, según recogió TechTarget.
Secure Code Warrior + RMIT (AI Trust Index): sobre 1.760 codebases analizadas en 16 modelos, un promedio de 15 vulnerabilidades por codebase, sobre todo fallos de logging, inyección y control de acceso roto.

Joshua Copeland, profesor en Tulane y director de ciberseguridad en Crescendo AI, resumió el patrón a TechTarget: "El código se ejecuta bien, pero resuelve un problema distinto del que la organización quería. Esos defectos son más peligrosos que los fallos visibles porque pueden sobrevivir indetectados en producción".

¿Qué dice un programador con 30 años de oficio sobre aprender con IA?

La respuesta de Seemann no es anti-IA. Es explícita al respecto: usa LLMs, experimenta con ellos, reconoce que le impresionan. Pero muestra su postura sin ambigüedad: "Me inclino a disgustarle, aún sabiendo que quizá sea imparable". Y revela una economía personal: es senior, con una carrera construida, y puede absorber una hipotética interrupción. Lo que le preocupa no es él. Es la sociedad del conocimiento: "Como economista, no puedo imaginar que un desempleo masivo del 30% al 40% no tenga un impacto significativo en la economía".

La regla técnica que rescata de tres décadas es modesta y útil: "Entiende la capa de abstracción directamente debajo de la tuya, así como la de arriba. Eso te permite resolver la mayoría de problemas". Su crítica al vibe coding (programar dejando que el modelo produzca y enviándolo sin entender) es que construye sistemas cuyo dueño real no existe.

El argumento más afilado aparece al responder si la IA acelera el desarrollo más rápido de lo que el humano puede aprender. Su respuesta apunta al cuello de botella real: "Dudo que sea posible acelerar significativamente el aprendizaje humano. El cuello de botella casi nunca son los profesores ni los materiales, sino lo rápido que un cerebro humano puede absorber conocimiento nuevo".

¿Por qué Seemann dice que "los LLMs mienten con descaro"?

Hay una frase del ensayo que merece repetirse entera porque resume su método. Seemann escribe: "Notarás que no uso mucho los LLMs para aprender. Los LLMs no alucinan; mienten con descaro (they bullshit), y desconfío profundamente de cualquier cosa que me digan".

Lo que sí hace es preguntarles cosas falsificables: "¿Puedo hacer esta expresión de Haskell más concisa?". La respuesta se verifica: el código compila o no compila, queda más corto o no. Nunca pregunta "¿qué debería aprender a continuación?", porque la respuesta no es falsificable: el modelo devolverá un plan de estudios bonito y sin base. La regla que destila de esa experiencia: "Prefiero hacer a los LLMs preguntas que se puedan falsear".

¿Cuánto cuesta ya esta trampa en dinero real?

Tres ejemplos recientes publicados en prensa técnica ilustran el lado material:

Amazon (marzo de 2026): dos caídas del sitio retail en una semana se atribuyeron parcialmente a cambios asistidos por IA. Una dejó unos 120.000 pedidos perdidos y 1,6 millones de errores en el sitio; la otra cerca de 6,3 millones de pedidos perdidos, según documentos internos reportados por Business Insider y recogidos por TechTarget.
Lovable (CVE-2025-48757): el investigador Matt Palmer reveló ó una falla en la plataforma de vibe coding que expuso más de 170 aplicaciones a acceso a base de datos sin autenticación.
IBM (encuesta a ejecutivos): el 81% dice que la deuda técnica ya está limitando el éxito de sus proyectos de IA, con estimaciones de entre el 15% y el 22% extra en plazos, según recogió Forbes.

Para una startup, eso se traduce en un sencillo cálculo: si la deuda técnica añade un 20% a tus cronogramas y dispara incidentes, la productividad que creías comprar con IA se la come la operación.

¿Qué significa esto para tu startup?

Más allá del debate existencial, hay decisiones concretas que cualquier founder puede tomar este mes.

Asume un dueño humano por cada merge generado por IA. El equipo de Commvault, según TechTarget, mantiene la política de que los ingenieros son responsables de cada línea, IA incluida: sin nombre propio en el commit, no entra a producción. La métrica que Nick Shevelyov (ex CISO de Silicon Valley Bank) recomienda trackear es el porcentaje de merges con un humano nombrado como accountable. Cuando ese número baja, "la deuda se está acumulando en silencio".
Reserva tiempo explícito sin IA. Joshua Copeland recomienda ejercicios periódicos "AI-free": pair programming, code walkthroughs, lecturas de módulos en los que el ingeniero debe explicar qué hace cada parte. Sudheer Mareddi (Sutherland) advierte que el razonamiento de diagnóstico es la primera habilidad que se atrofia cuando el código siempre lo escribe otra cosa.
Haz solo preguntas falsificables al modelo. Política de equipo: las preguntas abiertas ("¿qué arquitectura me conviene?", "¿qué stack debería usar?") se resuelven en sesiones humanas. Las preguntas aptas para LLM son las de verificación inmediata: "¿compila esto?", "¿este snippet tiene una SQL injection?", "¿este regex cubre los casos X, Y, Z?".

Si una sola persona en tu equipo tiene la única comprensión real de un módulo crítico, esa persona no es un activo: es un riesgo de continuidad. Seemann lo dijo sin nombrar startups: un sistema cuyo dueño real no existe es, en el fondo, una hipoteca que tu negocio le está pagando al futuro.