Gonzalo Hernández Araujo · Notas e investigaciones
La barrera no era programar. Era saber cuándo ya tenías un sistema.
En los últimos meses he construido varias cosas con ayuda de inteligencia artificial. Una aplicación móvil para registrar gastos. Una herramienta pequeña para añadir una lectura breve a textos editoriales. Esta web, que empezó como un conjunto de archivos HTML y terminó con una rutina para revisar enlaces, fechas y publicaciones.
Los tres proyectos comenzaron de una forma parecida. Describí lo que quería, el modelo propuso código y, después de algunos ajustes, apareció una primera versión que funcionaba.
La primera versión siempre produce una sensación engañosa. Parece que el problema era escribir el código y que ya quedó resuelto.
No quedó resuelto. Apenas se volvió visible.
1. El primer prototipo te hace una promesa que no puede cumplir
Cuando una herramienta abre, guarda un dato o responde a un clic, demuestra una cosa concreta: alguien pudo construir ese recorrido.
No demuestra que el recorrido sea el correcto. Tampoco que los datos tengan un significado claro, que la siguiente persona pueda mantenerlo o que el sistema sepa qué hacer cuando algo salga mal.
Durante mucho tiempo, escribir software exigía conocer una sintaxis, una biblioteca, un entorno y una cantidad suficiente de detalles como para poder corregir lo que uno mismo había escrito. La inteligencia artificial redujo mucho el costo de llegar a una primera versión. También permite que alguien que no se considera programador vea una pantalla funcional en una tarde.
Eso es útil. El problema aparece cuando confundimos la velocidad del primer prototipo con la madurez del sistema.
Ya había escrito que los programadores no están enojados con la IA porque su trabajo nunca fue sólo escribir código. La experiencia reciente me obliga a completar esa frase: resolver problemas tampoco significa producir una pantalla que responde. Significa decidir qué debe responder, con qué datos, bajo qué condiciones y qué pasa cuando la respuesta no llega.
La IA abarató el primer camino. No decidió a dónde debía llevar.
2. Una aplicación no empieza cuando abre
En una aplicación móvil sencilla, registrar un gasto parece suficiente. Escribes una cantidad, eliges una categoría y la pantalla confirma que guardó el dato.
Después llegan las preguntas que no caben en la demostración:
- ¿El dato se guardó sólo en el teléfono o también en otro lugar?
- ¿Qué copia cuenta como la correcta si las dos cambian?
- ¿Qué ocurre si se pierde la conexión justo después de pulsar Guardar?
- ¿Cómo se evita que un reintento duplique el gasto?
- ¿Qué puede ver otra cuenta?
- ¿Cómo se recupera la información si una sincronización falla a la mitad?
La aplicación que construí tenía que resolver esas preguntas antes de poder considerarse algo más que un prototipo. No bastaba con añadir un inicio de sesión. Iniciar sesión no es sincronizar. No bastaba con enviar los datos a un servidor. Había que decidir cuándo se enviaban, qué se conservaba localmente, qué podía borrarse y cómo se podía volver atrás.
También había que separar las pruebas. Una cosa era comprobar las reglas de datos en un entorno controlado. Otra, abrir la aplicación en un navegador. Otra, recuperar el mismo registro en un segundo dispositivo. Otra, comprobar qué pasa después de una sesión vencida o de una petición interrumpida.
El primer resultado verde podía significar que una parte funcionaba. No que el producto estuviera listo.
Esa distinción parece obvia cuando se escribe. Se vuelve menos obvia cuando tienes una pantalla delante, el flujo principal funciona y el modelo te dice que la implementación está completa.
Un sistema empieza a ser confiable cuando sus límites están escritos. Qué conserva. Qué no hace. Qué ocurre cuando falla. Qué evidencia permite decir que una parte está terminada y cuál sigue pendiente.
3. Una función pequeña también puede tener consecuencias grandes
El segundo proyecto parecía mucho más pequeño. La idea era añadir una lectura breve al inicio de un texto editorial para que alguien pudiera entender lo esencial antes de decidir si quería leerlo completo.
La primera versión visual podía resolverse rápido. Un bloque, un botón, unos estilos y una animación.
Pero había que responder otras preguntas:
- ¿Quién escribe el resumen?
- ¿Qué pasa si el campo está vacío?
- ¿Debe aparecer en una lista de artículos o sólo dentro del texto completo?
- ¿Qué debe ver una persona si no tiene JavaScript?
- ¿La animación respeta a quien prefiere reducir el movimiento?
- ¿El resumen puede terminar por accidente en una descripción para redes sociales?
- ¿Qué ocurre si se pulsa varias veces o si el guardado falla?
La dificultad no estaba en hacer aparecer el bloque. Estaba en decidir cuándo tenía derecho a aparecer.
El proyecto terminó necesitando una secuencia que, vista desde fuera, parece excesiva para una función tan pequeña: probar varias versiones de la interfaz, elegir una, describir sus estados, empaquetarla, revisar su comportamiento sin JavaScript, comprobar el teclado, revisar el contenido que se guarda y distinguir lo que se verificó en un archivo de prueba de lo que todavía debía comprobarse en el sitio real.
El resultado fue menos espectacular que una demostración generada en segundos. También fue más útil. La herramienta no generaba texto por su cuenta, no dependía de un servicio externo y no modificaba el contenido principal. Tenía un alcance claro.
Eso es parte del trabajo de desarrollo que no se ve en una captura de pantalla. Una función no está terminada porque aparece. Está terminada cuando se puede decir dónde aparece, dónde no, qué datos usa y qué hace cuando una de sus condiciones no se cumple.
Cuando el software cambia las reglas sin avisar, parece que apareció un bug. A veces sí es un bug. Otras veces el problema es que nadie había escrito el contrato que permitía distinguir un cambio correcto de un comportamiento inesperado.
4. Una web no se publica cuando el archivo se genera
Esta web empezó de una forma deliberadamente sencilla: archivos Markdown para escribir, HTML para publicar y una carpeta que contiene la salida visible.
Incluso ahí la parte difícil dejó de ser producir la página.
Una publicación necesita conservar la fecha, el título y el texto. Necesita enlaces que funcionen, metadatos coherentes, una entrada en el archivo, un sitemap y un RSS que no contradigan lo que aparece en la portada. También necesita una forma de revisar que un cambio en una pieza no arrastre por accidente otros archivos del proyecto.
Un script puede comprobar varias de esas cosas. No puede decidir si el artículo merece publicarse. Tampoco puede saber si una afirmación está bien interpretada o si un enlace es técnicamente válido pero editorialmente forzado.
La automatización reduce el trabajo mecánico y deja más expuesto el trabajo de criterio. Por eso no me interesa pensar en la web como un conjunto de páginas generadas, sino como una pequeña cadena de decisiones: una fuente, una salida, una revisión y una publicación.
La misma lógica aparece en otros contextos. Tus archivos siguen en tu computadora, pero el agente ya no muestra lo que pasa cuando una herramienta cambia el lugar donde ocurre el trabajo. El problema no es sólo aprender la nueva interfaz. Es saber qué parte del sistema sigue bajo tu control y qué parte depende de una decisión que tomó alguien más.
5. Programar con IA cambia lo que tienes que saber
La tentación es describir este cambio como la desaparición de la programación. No es eso. Es un cambio en la distribución de la dificultad.
La IA puede convertir una intención en una primera implementación. Puede sugerir una estructura de datos, escribir una consulta, proponer una prueba o encontrar una contradicción entre varios archivos. También puede equivocarse con seguridad, asumir una relación que no existe o resolver la parte visible de un problema mientras deja intacto el riesgo importante.
La investigación sobre la frontera dentada de la IA describe precisamente esa irregularidad: los modelos pueden rendir muy bien en tareas que parecen difíciles y fallar en otras que parecen sencillas. La capacidad de producir código no garantiza que hayan entendido el significado del sistema que están construyendo.
Por eso el trabajo se desplaza hacia cuatro preguntas:
- ¿Qué existe y cómo se relaciona?
- ¿Qué debe ocurrir en cada estado, incluido el vacío, el error y la recuperación?
- ¿Qué prueba permite afirmar que el resultado es correcto?
- ¿Qué queda escrito para que otra persona pueda continuar?
En mis propios proyectos, la secuencia que mejor funciona empieza por describir los datos y sus reglas. Después detalla la experiencia completa, no sólo la pantalla bonita. Luego implementa una parte pequeña y la prueba antes de seguir. Si la interfaz cambia, la descripción también debe cambiar. Si una decisión sigue abierta, no se disfraza de requisito.
Suena menos emocionante que pedirle a un modelo que construya una aplicación completa. Es más cercano a lo que hace falta cuando la aplicación tiene que durar más que la conversación en la que nació. También obliga a asignar un responsable para mantener las reglas y revisar las excepciones, el mismo problema que aparece cuando la IA se atora sin un dueño del proceso.
La idea de que una persona debe describir lo que quiere y no cada paso para conseguirlo tampoco nació con los modelos de lenguaje. Bret Victor la exploró en The Future of Programming, una charla de 2013. Lo nuevo no es sólo que esa aspiración esté más cerca. Es que ahora mucha más gente puede producir el primer resultado sin haber construido todavía el criterio para juzgarlo.
Ahí está la parte incómoda. Es posible construir algo antes de comprenderlo.
6. ¿Qué convierte un prototipo en un sistema?
No es la cantidad de código. Tampoco el número de funciones.
Un prototipo responde: «¿podemos hacer que esto ocurra?»
Un sistema tiene que responder además:
- ¿Quién puede usarlo y qué puede hacer?
- ¿Qué información conserva y cuál descarta?
- ¿Cómo se comporta cuando la entrada es incompleta?
- ¿Cómo se detecta una respuesta equivocada?
- ¿Qué pasa si la red, el proveedor o la persona responsable no están disponibles?
- ¿Puede otra persona actualizarlo sin pedir una explicación oral de una hora?
- ¿Qué evidencia falta antes de llamarlo listo?
La velocidad del código generado vuelve más importante contestar esas preguntas. Antes, el tiempo necesario para llegar a una primera versión podía esconder la falta de definición. Ahora la primera versión llega tan pronto que el vacío aparece de inmediato.
La deuda no es solamente técnica. También es una deuda de comprensión. Si nadie sabe por qué existe una regla, si una decisión sólo quedó en una conversación o si la única persona que entiende el sistema es quien lo construyó con ayuda de un modelo, la herramienta no eliminó la dependencia. La trasladó.
Por eso un chat largo no es memoria institucional. La memoria de un proyecto aparece cuando otra persona puede encontrar el propósito, las reglas, los límites, las decisiones y las pruebas sin tener que reconstruir la historia desde la ventana de contexto de alguien más.
La barrera se movió
La inteligencia artificial hizo mucho más barato escribir el primer programa. Eso cambia quién puede empezar y qué tipo de experimentos vale la pena intentar.
También cambia la pregunta que conviene hacer después de que el programa funciona.
No es «¿puede la IA construirlo?»
Es «¿qué tendría que ser verdad para que esto siga funcionando cuando cambie el dato, falle la conexión, llegue otra persona o yo ya no recuerde cómo lo hicimos?»
La barrera no era programar. Era saber cuándo ya tenías un sistema.
Notas y fuentes
- Fabrizio Dell’Acqua, Edward McFowland III, Ethan Mollick et al., Navigating the Jagged Technological Frontier, Organization Science, 2026. La investigación documenta que el rendimiento de la IA no sigue una escala simple de dificultad y que puede mejorar unas tareas mientras empeora otras.
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework, marco para pensar en validez, confiabilidad, seguridad, transparencia y responsabilidad durante el diseño y uso de sistemas de IA.
- Bret Victor, The Future of Programming, charla presentada en 2013 sobre expresar intenciones de alto nivel y no sólo instrucciones paso a paso.