Cuando el software crece más rápido que nuestra comprensión
La IA está cambiando el costo de construir software. A medida que asume más de la implementación, ¿cómo seguimos siendo los autores de lo que construimos?
Le das una tarea a un agente de programación. Un rato después, la función ya funciona y las pruebas pasan. Los cambios abarcan decenas de archivos, introducen nuevas estructuras y resuelven algunas cosas que nunca le pediste de forma explícita.
El resultado parece bueno. Tras probarlo unas cuantas veces sin encontrar problemas evidentes, pasas a la siguiente tarea.
Pero algunas preguntas siguen sin respuesta. ¿Por qué esta implementación? ¿Qué comportamientos se derivan de tus requisitos y cuáles reflejan decisiones del agente? Cuando vuelvas a cambiar esta parte del sistema, ¿qué debe conservarse?
El software ha avanzado. Tu comprensión sigue en el punto de partida.
1. Mantener nuestra comprensión mientras el software cambia
El software existe como código y procesos en ejecución, pero también en la comprensión de las personas que le dan forma. ¿Para qué sirve? ¿Por qué funciona así? ¿Qué decisiones deben seguir vigentes y cuáles pueden cambiar? Esa comprensión es lo que nos permite seguir dando forma a nuestro software a lo largo del tiempo.
No hace falta que abarque todos los detalles de la implementación. Puedes desconocer funciones concretas y aun así saber en qué debería convertirse el software, juzgar si un cambio responde a tu intención e intervenir cuando no lo hace.
En el desarrollo convencional, la complejidad y los cambios en el equipo pueden separar la comprensión de la implementación. Sin embargo, diseñar, programar, depurar y revisar también nos dan oportunidades constantes de construir y corregir nuestra comprensión mientras trabajamos.
Los agentes de programación cambian el ritmo. Pueden saltarse muchos de los pasos que antes exigían nuestra participación directa y producir por su cuenta implementaciones considerables. El software sigue cambiando. Nuestra comprensión quizá no cambie con él.
La función llega primero; comprenderla se convierte en una tarea posterior. Leer los cambios. Preguntar por qué. Averiguar qué más afectan. Estas tareas ocupan parte del tiempo ahorrado al programar. El agente puede seguir generando, y las cosas que tenemos pendientes de comprender pueden seguir acumulándose.
También hay un ajuste más difícil: el software puede avanzar exactamente como pediste y, al mismo tiempo, resultarte cada vez menos familiar. Pasas el día asignando tareas, respondiendo preguntas y comprobando resultados. Todos los agentes avanzan, pero todavía tienes que averiguar cómo encajan esos cambios. La perspectiva que desarrollas al construir algo por tu cuenta —saber en qué punto está y cómo cambiarlo después— no aparece automáticamente cuando las tareas terminan.
Tu propia obra se va volviendo desconocida. Recuerdas lo que pediste, pero te cuesta más explicar por qué el resultado es como es, si las decisiones anteriores siguen vigentes o qué afectará el próximo cambio. La continuidad de saber qué has construido, por qué funciona así y cómo cambiarlo empieza a romperse. Seguir dándole forma se vuelve más difícil.
2. Una IA mejor no elimina el derecho a decidir
Una respuesta natural es hacer que los modelos sean más fiables: mejor código, mejor detección de errores y verificaciones más exhaustivas. Si un modelo llega a ser lo bastante bueno, ¿las personas siguen necesitando comprender y decidir en qué debería convertirse su obra?
Nuestro derecho a dirigir nuestro propio trabajo no depende de que la IA siga cometiendo errores.
«La IA puede escribir el código, pero las personas seguirán teniendo que diseñar la arquitectura». Esta respuesta vincula nuestro papel a una capacidad en la que hoy tenemos ventaja. ¿Y si los modelos también se convierten en excelentes arquitectos? Refugiarse en la verificación o en la comprensión del sistema lleva a la misma pregunta: cuando un modelo también sea bueno en eso, ¿perderemos nuestra razón para participar?
Llevemos el argumento hasta el límite. Supongamos que la IA alcanza una inteligencia general. Comprende sistemas complejos, toma excelentes decisiones técnicas y comprueba las implementaciones con más rigor que nosotros. ¿Deberíamos entonces cederle todas las decisiones sobre lo que creamos?
Mientras alguien quiera crear según su propia intención y elegir el rumbo de su obra, esa pregunta seguirá vigente.
La capacidad de tomar una mejor decisión no otorga, por sí sola, el derecho a decidir por otra persona.
Puedes elegir delegar muchos juicios en la IA y reservarte una decisión concreta. Puedes aceptar consejos, cambiar de opinión o reconocer que una elección anterior fue equivocada. Lo que importa es que decidas con conocimiento de causa, en lugar de descubrir después que el software ya ha cambiado.
El derecho a dirigir tu propio trabajo no depende de que seas más capaz que la IA. Tampoco depende de cuántas personas sigan queriendo ejercerlo. Aunque casi todo el mundo esté dispuesto a delegarlo todo, quien no lo esté sigue teniendo el derecho a decidir en qué debería convertirse su software.
Mientras una sola persona quiera seguir siendo autora de su obra, necesitaremos responder cómo puede mantenerse vigente su intención.
3. Qué hace falta para seguir dando forma a tu software
La autoría continúa después de que la primera idea se convierte en software funcional. Necesitas poder comprender las decisiones importantes, cambiar de rumbo, rechazar resultados que contradigan tu intención y seguir revisando la obra. El derecho a dirigirla debe traducirse en capacidades prácticas.
Si lo único que puedes hacer es pulsar «Aceptar» cuando el agente termina, sin saber qué decisiones importantes contiene el resultado, tu control es limitado. Lo mismo ocurre si puedes rechazar un resultado pero no encuentras la forma de cambiarlo, o si un requisito que expresaste claramente ayer deja de cumplirse en silencio en la implementación de hoy. Puedes seguir aprobando el trabajo y, al mismo tiempo, perder la capacidad de darle forma según tu intención.
Conservar esa capacidad significa poder responder algunas preguntas concretas:
- ¿Sigue estando claro en qué debe convertirse el software?
- ¿Puedes ver cómo responde la implementación actual a tus requisitos?
- ¿Puedes distinguir tus decisiones importantes de las que tomó el agente?
- Al cambiar de rumbo, ¿puedes comprender las posibles consecuencias e intervenir?
- Tras el siguiente cambio en la implementación, ¿seguirán vigentes las decisiones que tomaste de forma explícita?
Piensa en una herramienta personal de escritura con un requisito explícito: mantener su contenido en el dispositivo local. Dejas al agente la organización de los archivos, la implementación del almacenamiento y muchos detalles internos. Más adelante, para facilitar el uso de la herramienta en varios dispositivos, el agente propone sincronizarla con la nube.
Que el contenido pueda salir del dispositivo afecta a una decisión que ya has tomado. Esa elección debe ser visible, y debes comprender qué cambia antes de aceptarla o rechazarla. Un resultado puede ser más cómodo y más fiable y, aun así, apartarse del requisito original.
Las pruebas pueden ayudar a demostrar que el software se comporta de una manera determinada. Aun así, necesitas juzgar si ese comportamiento es aceptable y si respeta las decisiones que quieres mantener.
El agente puede implementar la sincronización, comprobar que los datos se transfieren correctamente y corregir errores. Pero si el contenido debe salir del dispositivo, qué evidencia basta para aceptar ese cambio y quién responde si algo sale mal son cuestiones que necesitan respuestas explícitas más allá de la propia implementación. Tu criterio debe determinar hacia dónde va el trabajo y cuándo se detiene, en lugar de servir solo como firma cuando todo está terminado.
4. ¿Puede la lectura de todo el código preservar la autoría?
La revisión de código ofrece una respuesta directa. El agente escribe el código; una persona lo lee y comprueba qué hace.
El código puede contener comportamientos que el informe del modelo nunca menciona, estructuras que afectan al mantenimiento y problemas que solo puedes juzgar examinando la implementación en detalle.
Pero, a medida que la generación se acelera, ¿puede seguir siendo sostenible leer cada cambio para mantener el control?
Incluso sin leer línea por línea, tu jornada puede seguir llena: aclarar requisitos ambiguos, detectar dónde se ha desviado un resultado, decidir qué evidencia demostraría que es correcto y guiar de nuevo al agente. Cada paso exige experiencia y concentración. Leer muy poco código y trabajar intensamente pueden ser dos realidades simultáneas.
Leer código también es una oportunidad para desarrollar la comprensión. Revisar los cambios de un colega ayuda al equipo a aprender qué hace ahora el sistema, por qué se diseñó así y qué conviene vigilar en cambios futuros. Si leemos menos código, necesitamos otras formas de desarrollar esa comprensión.
Sin embargo, cuando los cambios se acumulan y las personas solo pueden leerlos por encima antes de aprobarlos, mantener el proceso de revisión no preserva necesariamente la comprensión. Nuestra atención limitada debe llegar a los lugares que requieren criterio: decisiones de diseño con consecuencias importantes, cambios de gran alcance y resultados que siguen siendo inciertos.
¿Qué decisiones necesitamos seguir comprendiendo a lo largo del tiempo? ¿Qué detalles de implementación podemos investigar cuando haga falta? ¿Cómo evitamos dedicar toda nuestra atención a los detalles y pasar por alto las decisiones que realmente nos necesitan?
5. ¿Y si sustituimos el código por especificaciones extensas?
Otra respuesta es trasladar nuestro trabajo al lenguaje natural. Describir cómo debe comportarse el software y después pedir a un agente que implemente la especificación. O pedirle que explique el código, convirtiendo el sistema en una documentación más fácil de leer.
Los requisitos claros reducen los malentendidos. La documentación conserva el contexto. Una buena explicación hace más accesible el código desconocido. Pero el lenguaje natural no hace desaparecer el costo de leer.
Si el software contiene muchos comportamientos y decisiones con ventajas e inconvenientes, un documento que los describa todos puede crecer junto con la implementación. Podemos pasar de tener demasiado código que leer a tener demasiado texto que leer. Aunque cada frase sea más fácil de comprender que el código correspondiente, el conjunto puede seguir superando nuestro tiempo y nuestra atención.
Y si el agente sigue ampliando la especificación mientras nosotros nos limitamos a aprobarla, llamarla un documento aprobado por una persona no demuestra que esa persona haya comprendido todas las decisiones que contiene.
Lo que hace el software, lo que el agente dice que hace y lo que realmente comprendemos y elegimos respaldar son tres cosas distintas.
Incluso con un registro completo y una explicación exhaustiva podemos seguir sin saber cómo continuar dando forma al software. Necesitamos poder encontrar lo que importa, comprender cómo se cumple en la implementación actual y ver qué opciones tendremos cuando vuelva a cambiar.
Mantener la autoría en manos humanas
A medida que implementar cuesta menos, más personas pueden convertir sus ideas en software. También deberían poder comprender y seguir dando forma a lo que crean.
Esta libertad va más allá del software. En cualquier trabajo creativo, quien lo crea debería poder elegir qué delega en la IA y qué decide por su cuenta.
La misión de Finite Ground es ayudar a las personas a crear según su propia intención y a seguir dando forma a su obra mientras la IA amplía lo que es posible.
Noema lleva esa misión al software, manteniendo vigente la intención de las personas mientras la implementación sigue cambiando.
Si llega un día en que la inteligencia artificial general (AGI) toma el control de todos los aspectos de la vida humana y todo el mundo renuncia a su autonomía, esta pregunta dejará de tener sentido. Finite Ground dejará de tener una razón para existir.
Mientras una sola persona no esté dispuesta a renunciar a esa autonomía, habrá una razón para seguir adelante.
La IA puede traer más ideas al mundo. El derecho a decidir en qué se convierten esas ideas sigue perteneciendo a quienes eligen conservarlo.