Programar con IA: el fin de entender tu propio código

El día que no entendí mi propio software

Hace unos meses le pedí a un agente de IA que construyera el módulo de despacho de TimberID, mi sistema de trazabilidad para la industria maderera. En una tarde tenía pantallas, validaciones y reportes funcionando. Una semana después, un cliente reportó que dos guías de remisión descontaban el mismo lote. Abrí el código para corregirlo y me di cuenta de algo incómodo: no sabía cómo funcionaba mi propio sistema.

No era falta de experiencia. Llevo más de 20 años ordenando procesos en planta. Era algo nuevo: había construido algo que yo mismo no había escrito.

Si estás aprendiendo a programar con inteligencia artificial, esto te va a pasar, si no te está pasando ya. La buena noticia es que tiene solución, y la encontré en una charla de James Cowling, cofundador y CTO de Convex, ingeniero que lideró en Dropbox la migración de exabytes de datos fuera de Amazon S3. Su propuesta cabe en una frase: en la era de la IA, la habilidad que más vale no es escribir código, sino diseñar buenas abstracciones.

En este artículo te explico qué significa eso, por qué importa ahora y cómo aplicarlo aunque no seas programador profesional.

1972: la primera vez que el software nos superó

Esto ya pasó antes. A inicios de los años 70 la industria habló abiertamente de una crisis del software. Edsger Dijkstra, uno de los padres de la computación moderna, lo resumió en 1972: cuando las computadoras eran débiles, programar era un problema pequeño; con computadoras gigantes, programar se volvió un problema igual de gigante.

El límite no era el hardware. Era el cerebro humano. Para mantener un sistema había que entender cada pieza y cómo se relacionaba con todas las demás. Como dice Cowling, se había llenado la “ventana de contexto” de nuestra mente.

La salida vino de investigadoras como Barbara Liskov, ganadora del Premio Turing, con una idea que hoy parece obvia: separar qué hace algo de cómo está construido. Eso es una abstracción. Cuando guardas un archivo en la nube no piensas en millones de discos duros; usas dos acciones simples: guardar y leer.

Sin abstracciones, un sistema es una red enmarañada donde todo toca todo. Con buenas abstracciones, se parece a un árbol ordenado: usas cada rama sin conocer su interior.

Las dos brechas de programar con inteligencia artificial

Hoy generar código es casi gratis. Un chico de 12 años puede lanzar una app web en un fin de semana. Pero generar código no es lo mismo que construir software de calidad. Cowling identifica dos brechas que explican la diferencia.

1. La brecha de comprensión

Si usas un agente de IA, el código se te escapa. Aunque lo leas línea por línea, no lo entiendes como si lo hubieras escrito tú. Y no hay marcha atrás: nadie volverá a escribir todo a mano.

El resultado es incómodo. Muchos emprendedores tienen hoy productos cuya lógica interna no conocen. Eso es un riesgo para la seguridad, para el mantenimiento y para la capacidad de innovar.

2. La brecha de interés

La segunda brecha es más profunda: a mucha gente simplemente ya no le importa el código. Cowling cuenta que una aplicación viral de agentes personales, construida sobre Convex, provocó de pronto un pico enorme de carga en sus bases de datos. Cuando le sugirió al creador reescribir unas consultas, la respuesta fue directa: no había escrito ese código, no lo había leído y no pensaba cambiarlo.

Cowling no lo cuenta como crítica. Lo cuenta como una ventana al futuro. Su conclusión fue dejar de educar a los usuarios y empezar a diseñar para un mundo donde nadie entiende todo.

No entender no es el problema (casi nunca)

Aquí viene el giro contraintuitivo: no entenderlo todo es la base del progreso. No somos biológicamente más inteligentes que nuestros abuelos. Simplemente vivimos rodeados de abstracciones que funcionan.

Cuando prendes la luz en Pucallpa no piensas en la central térmica, ni en el voltaje, ni en las líneas de transmisión. Aprietas un interruptor. Lo mismo pasa cuando usas la API de un modelo de IA sin saber cómo funciona la inferencia, o cuando instalas un paquete de npm.

Lo nuevo, y lo peligroso, es otra cosa: ahora puedes no entender tu propio producto. Antes, lo que no entendías era de otros y estaba probado. Hoy lo que no entiendes es tuyo y nadie lo probó.

La regla de Cowling es clara: si produjiste algo que no sabes cómo funciona por dentro, más te vale que sea una buena abstracción. Es decir, que al menos entiendas perfectamente cómo se usa y qué garantiza.

Las 5 propiedades de una buena abstracción

Una abstracción toma algo complejo, le quita el detalle y te deja una interfaz simple. Cowling propone cinco pruebas para saber si es buena. Las traduzco con ejemplos de trazabilidad maderera, que es el mundo que conozco.

La más importante y la más rara es la componibilidad. Según Cowling, cuando un producto de software se vuelve lento de evolucionar, casi siempre es por falta de ella. Lo he vivido: un cambio en cómo registras las trozas termina afectando inventario, reportes y facturación.

Y hay una señal de éxito curiosa: una buena abstracción se vuelve invisible. La gente la usa y piensa “¿no es así como siempre se hizo?”. Eso pasó con la nube: hace 15 años nadie confiaba en ella; hoy es el suelo sobre el que todos construimos.

La forma sigue a la función

Un principio clave: la abstracción debe tener la forma del problema que resuelve, no la forma de cómo fue construida. Cowling pone un ejemplo: cuando Amazon S3 nació, podías guardar un archivo y al leerlo inmediatamente no estaba. Técnicamente tenía sentido, pero en la práctica obligaba a los usuarios a montar un segundo sistema solo para saber si su dato se había guardado. Hoy S3 garantiza lo que el usuario espera: lo guardas y está ahí.

En tu SaaS pasa lo mismo. Si tu cliente necesita entender tu base de datos para usar tu sistema, tu abstracción está filtrando detalles de implementación.

Los agentes de IA trabajan mejor con buenas abstracciones

Quizás pienses: “si la IA escribe todo, ¿para qué me preocupo del diseño?”. Cowling responde con dos argumentos.

Primero, el software no es gratis: los tokens cuestan, y cada vez que un agente reescribe algo mal diseñado, pagas. Segundo, hay cosas en las que los agentes todavía fallan:

• Diseño de interfaces: no son buenos definiendo cómo debería usarse algo.
• Simplicidad: tienden a añadir capas en lugar de quitar.
• Razonamiento no local: les cuesta prever cómo un cambio aquí afecta algo allá.

Lo interesante es que no hay que elegir entre calidad y productividad. Un agente con una buena abstracción:

1. Necesita menos contexto, y se concentra en lo que diferencia tu producto.
2. No puede expresar estados inválidos, porque tu diseño no los permite.
3. Razona localmente, sin romper módulos que no tocó.

Un ejemplo concreto son las transacciones en bases de datos: garantizan que dos operaciones simultáneas no se pisen. En TimberID, eso significa que dos despachos al mismo tiempo nunca pueden descontar el mismo lote. Exactamente el error que tuve al inicio.

Por eso trabajo con plataformas como Supabase: me entregan autenticación, base de datos y permisos como piezas simples. El agente no reinventa esas piezas; se enfoca en la lógica de trazabilidad, que es donde está el valor.

La lección de negocio: vende la tranquilidad de no preocuparse

Esta es, para mí, la idea más valiosa de la charla, y Cowling la menciona casi de pasada. A menudo algún joven le dice que en el futuro cada uno construirá su propia base de datos con IA. Su respuesta es una analogía: si tienes un carrito de helados, no fabricas el caucho de tus llantas. Le pagas a quien sabe hacer llantas.

Las cadenas de suministro existen porque concentran conocimiento. Y Cowling lo dice sin rodeos: lo que él vende no es una base de datos, es la oportunidad de que el problema deje de ser tuyo. Por eso su propia empresa guarda archivos en S3, aunque sabe construir sistemas de almacenamiento: prefiere pagar para que otro cargue con ese problema.

Esto cambia cómo pienso mis productos:

Si la IA hace que cualquiera pueda “construir su propia versión”, tu ventaja no está en el código. Está en asumir la responsabilidad por un resultado y hacerlo con confianza. Y esa confianza exige que entiendas tus abstracciones, aunque no entiendas cada línea.

Ahora eres el jefe técnico de tus agentes

Cowling cierra con una imagen que cualquier supervisor de planta reconoce. Cuando lideras un equipo por primera vez, controlas cada detalle. Luego el equipo crece y tu cabeza ya no alcanza. La respuesta equivocada es desentenderte. La correcta es construir estructuras que te permitan confiar sin revisar cada tarea.

Hoy todos somos jefes técnicos de un equipo de agentes. Estas son las cuatro prácticas que aplico, inspiradas en la charla y en lo que aprendí con Lean Manufacturing:

1. Define la interfaz antes que el código. Antes de pedirle nada al agente, escribe en una página qué entra, qué sale y qué nunca debe pasar. Es tu trabajo estándar.
2. Haz imposibles los errores (poka-yoke). Usa restricciones en la base de datos, transacciones y validaciones para que los estados inválidos no puedan existir, los genere quien los genere.
3. Divide en módulos con contratos claros. Producción, inventario y despacho se hablan por reglas definidas, no por atajos. Así el agente cambia uno sin romper los otros.
4. Verifica comportamiento, no líneas. No necesitas leer cada línea; necesitas pruebas que confirmen que el sistema hace lo que promete: el lote entra, se transforma y sale con el volumen correcto.

Nada de esto requiere ser programador senior. Requiere dos cosas que Cowling considera esenciales: fundamentos para saber qué es posible pedirle a la máquina, y pensamiento de diseño para ponerte en el lugar de quien usará tu sistema.

Conclusión: la ingeniería no se volvió más fácil, cambió de lugar

La opinión más provocadora de Cowling es que construir software no se va a volver más fácil. Si las herramientas simplifican el trabajo, alguien más lo hará mejor y la vara volverá a subir. El reto no desaparece; se mueve.

Antes el reto era escribir código. Hoy es diseñar bloques simples, sólidos y componibles sobre los que la IA pueda construir sin que pierdas el control. Programar con inteligencia artificial no te libera de pensar. Te obliga a pensar a otro nivel: como diseñador y como líder.

En mi caso, aquel error de los lotes duplicados en TimberID no se resolvió leyendo más código. Se resolvió rediseñando la abstracción: una sola regla, protegida por una transacción, que hace imposible descontar dos veces el mismo lote.

¿Quieres profundizar? En el próximo episodio del podcast Nación Emprende converso sobre estas ideas con ejemplos prácticos para emprendedores que construyen con IA. Escúchalo en Spotify y cuéntame: ¿ya te pasó no entender algo que tú mismo construiste?

Este artículo se basa en la charla “The End of Understanding: Why Good Abstractions Matter” de James Cowling, CTO de Convex, en la conferencia Abstract.