Por Canuto  

Simon Willison, una de las voces más influyentes en torno al uso de IA para programar, describió cómo los agentes de código están cambiando el trabajo de los desarrolladores a una velocidad inédita. Su mensaje combina entusiasmo por la productividad con una advertencia clara: sin pruebas, sandboxing y disciplina, la nueva era del desarrollo puede convertirse en un problema de seguridad y mantenimiento.
***

  • Simon Willison asegura que los agentes de código ya escriben más software que él y, en algunos casos, ni siquiera hace falta leer cada línea.
  • El experto defiende pruebas automatizadas, desarrollo guiado por tests y verificación manual con herramientas como curl para confiar en el resultado.
  • También advierte sobre prompt injection, el “lethal trifecta” y la necesidad de ejecutar estos sistemas en entornos aislados.

 

Simon Willison, cocreador de Django y referente del software de código abierto, ofreció una radiografía muy concreta de cómo están evolucionando los agentes de IA para programación. En una conversación publicada bajo el título Simon Willison: Engineering practices that make coding agents work – The Pragmatic Summit, del canal The Pragmatic Engineer, el desarrollador explicó que su flujo de trabajo ya cambió de forma radical.

Su tesis central es simple, pero incómoda para buena parte de la industria. Los agentes de código ya no son asistentes menores que completan fragmentos. Ahora pueden resolver tareas completas, escribir más código que el propio desarrollador y, en escenarios bien delimitados, producir resultados suficientemente confiables como para no revisar cada línea.

Willison sostuvo que ese salto no se produjo de forma gradual, sino mediante varios puntos de inflexión. Entre ellos destacó la madurez de los agentes de código en el último año y, de forma particular, una mejora reciente en modelos como Claude Opus 4.6 y Codex 5.3, que según su experiencia elevaron mucho la fiabilidad de las ejecuciones de una sola instrucción.

Para una audiencia más amplia, el debate es relevante porque anticipa un cambio estructural en el desarrollo de software. Igual que la automatización modificó la operación de mercados financieros o la gestión de infraestructura digital, los agentes de código están redefiniendo quién programa, cómo se valida el trabajo y qué controles hacen falta cuando una máquina toma decisiones dentro de un sistema real.

Del copiloto al agente que resuelve tareas completas

Willison describió varias etapas en la adopción de IA por parte de los programadores. La primera fue el uso de interfaces conversacionales para hacer preguntas puntuales o solicitar ayuda con errores. Luego vino el uso de herramientas capaces de escribir fragmentos de código más largos. El cambio decisivo, en su opinión, ocurre cuando el agente empieza a producir más código que la persona.

Según explicó, ese momento le llegó hace apenas unos meses. También identificó noviembre como una fecha importante, porque fue cuando ciertos modelos empezaron a entregar soluciones buenas en vez de versiones “janky”, es decir, funcionales pero torpes y llenas de remiendos. A partir de ahí, se volvió mucho más fácil delegar tareas enteras.

El desarrollador incluso afirmó que hoy escribe más código en su teléfono que en su laptop. Como ejemplo, relató que acababa de publicar una nueva función en su blog desde el móvil. En otro momento reciente, pidió a un modelo que ejecutara un benchmark y buscara la mejor forma de optimizar un motor WebAssembly escrito en Python. El resultado, dijo, fue una mejora cercana al 45% y luego al 49% en Fibonacci.

Esa combinación de velocidad y ubicuidad cambia la naturaleza del trabajo técnico. Ya no se trata solo de abrir un editor y escribir. Se trata de dirigir agentes, formular instrucciones breves, verificar que ejecuten pruebas y cambiar de contexto entre varios proyectos a la vez.

La confianza en la IA no nace de la fe, sino de las pruebas

Willison dejó claro que no recomienda una confianza ciega. De hecho, su respuesta a la pregunta sobre cómo convertir una sala llena de desarrolladores en personas que ya no necesiten leer toda la salida del modelo fue directa: pruebas, y más específicamente desarrollo guiado por pruebas.

Durante años, confesó, no le gustó el enfoque clásico de red-green test-driven development. Le parecía tedioso y lento. Sin embargo, cuando quien ejecuta ese proceso es un agente, el costo cambia. Si la IA “pierde tiempo” escribiendo una prueba que falla antes de generar la implementación mínima para hacerla pasar, eso ya no representa una carga significativa para el humano.

Su práctica actual consiste en iniciar casi todas las sesiones de programación indicando al agente cómo correr los tests, por ejemplo con comandos como uv run pytest, y luego pedirle explícitamente que use red-green TDD. A su juicio, esa instrucción mínima eleva mucho la probabilidad de obtener código correcto, porque impide que el sistema escriba más de lo necesario.

Fue enfático en este punto. Dijo que ve a personas usando agentes de código sin escribir pruebas, y calificó esa práctica como una mala idea. Si antes los tests podían omitirse por el trabajo adicional que suponían, ahora ese argumento pierde fuerza porque, en su experiencia, la IA hace que resulten “efectivamente gratis”.

Pero las pruebas unitarias no bastan. Willison añadió otra capa: pedir al agente que arranque el servidor en segundo plano y luego ejercite la API con curl. Ese paso simula una validación manual, aunque esté automatizada, y permite detectar fallos que la suite formal no cubre.

También mencionó una herramienta reciente creada por él llamada Showboat. Según explicó, Showboat construye un documento en Markdown con la evidencia de la prueba manual que ejecutó el agente, incluyendo comandos y salidas. La idea es que el desarrollador no solo sepa que el sistema dijo haber probado algo, sino que cuente con un registro estructurado de lo que ocurrió.

Buenas bases producen mejor código, también con agentes

Otro punto clave de la charla fue el contexto que recibe el modelo. Willison afirmó que los agentes son muy consistentes al seguir patrones existentes dentro de un repositorio. Si el código base está bien organizado, con pruebas en el estilo preferido, integración continua y una estructura clara, el agente tiende a extender ese mismo patrón.

Para eso utiliza plantillas con herramientas como Cookiecutter. Con ellas crea esqueletos de proyectos o plugins que ya incluyen disposición de archivos, framework de testing, README y configuración de integración continua. Luego suelta al agente sobre esa base. El resultado, aseguró, es mucho mejor que empezar desde cero en un entorno desordenado.

La idea recuerda una regla antigua del desarrollo en equipo: el primer ejemplo termina convertido en plantilla informal para quienes vienen después. En opinión de Willison, eso no cambió con la IA. Lo que cambió es la velocidad con la que un patrón bueno o malo se replica a gran escala.

Sobre la calidad del código, su postura fue matizada. Para herramientas pequeñas, de una sola página y vida corta, dijo que no le preocupa si el resultado es un “spaghetti” de 800 líneas, siempre que funcione. En software que se mantendrá por más tiempo, la calidad sí importa. Pero subrayó que aceptar código malo del agente es, en última instancia, una decisión humana.

Incluso fue más allá. Aseguró que, cuando decide refinar una implementación y pedir refactorizaciones, suele terminar con código mejor del que él habría escrito a mano. La razón no es que la IA tenga mejor criterio en todos los casos, sino que él mismo reconoce una tendencia a dejar para después ciertos arreglos que el agente puede ejecutar mientras él hace otra cosa.

Prompt injection, “lethal trifecta” y el problema de seguridad

La parte más delicada de su intervención estuvo en seguridad. Willison recordó que lleva años alertando sobre prompt injection, una clase de ataque contra sistemas construidos sobre modelos de lenguaje. El riesgo aparece cuando el sistema mezcla instrucciones confiables con contenido externo que puede incluir órdenes maliciosas.

Su ejemplo fue claro. Si un agente recibe la orden de leer una documentación y alguien inserta al final un texto diseñado para manipularlo, el modelo podría ejecutar acciones no deseadas. Aunque un caso extremo como borrar todos los archivos quizá no funcione tal cual en herramientas actuales, la idea sigue siendo válida si se ofusca o se adapta a capacidades reales del agente.

Willison reconoció además que el término “prompt injection” no fue la mejor etiqueta posible, porque muchas personas asumen otra definición al oírlo. Por eso propuso una formulación alternativa: el “lethal trifecta”. Este aparece cuando el modelo tiene acceso a datos privados, está expuesto a instrucciones maliciosas y además dispone de una vía para exfiltrar información.

En ese escenario, un asistente digital con acceso al correo electrónico, por ejemplo, podría reenviar mensajes sensibles si un atacante logra convencer al modelo. Para Willison, la única solución garantizada es eliminar una de las tres patas del problema. Si no puede comunicarse hacia fuera, el daño potencial disminuye de forma drástica.

Su recomendación práctica principal es el sandboxing. Los agentes deberían ejecutarse en entornos aislados, como contenedores o máquinas virtuales temporales, de modo que un fallo grave no comprometa el equipo local ni otros secretos del desarrollador. Destacó en particular entornos remotos administrados por proveedores, donde el peor escenario sea perder una máquina efímera.

Aun así, admitió una contradicción personal. Dijo que muchas veces ejecuta Claude en su propia Mac con permisos peligrosamente amplios, pese a ser una de las voces que más ha insistido en no hacerlo. La razón, reconoció, es la comodidad. Ese comentario resume bien la tensión actual del sector entre seguridad ideal y productividad inmediata.

Un trabajo más ambicioso, pero también más agotador

Cuando se le preguntó por el futuro de la profesión, Willison evitó hacer predicciones a largo plazo. Dijo que ya ni siquiera intenta anticipar más de una semana, porque el ritmo de mejora es demasiado acelerado. Prefiere enfocarse en una pregunta más concreta: qué pueden hacer los modelos disponibles hoy que aún no hemos descubierto.

Su diagnóstico sobre el presente, no obstante, fue contundente. Programar con varios agentes a la vez es mentalmente agotador. Aseguró que suele trabajar en tres proyectos simultáneos para aprovechar tiempos muertos, pero que después de unas dos horas de ese ritmo queda exhausto. En su visión, no se trata de que la IA vuelva perezosos a los desarrolladores, sino de que exige operar a máxima intensidad.

Eso podría tener una consecuencia paradójica. Aunque un solo ingeniero pueda multiplicar su producción, no necesariamente podrá escalarla sin límite, porque la coordinación, revisión y gestión cognitiva siguen pesando. Para Willison, quizá ese agotamiento sea uno de los factores que moderen el impacto laboral más extremo de estas herramientas.

Al mismo tiempo, cree que los desarrolladores deberían ser más ambiciosos ahora mismo. Sugirió explorar nuevos lenguajes sin esperar una curva de aprendizaje tradicional. Como ejemplo, dijo haber publicado tres proyectos en Go en las dos semanas previas, pese a no considerarse un programador fluido en ese lenguaje. La clave es poder leer lo suficiente, apoyarse en TDD y mantener proyectos pequeños y controlables.

Código abierto bajo presión en la era de la generación automática

La charla cerró con una reflexión importante sobre software libre. Willison recordó que el propio Django nació en 2003 para permitir construir aplicaciones web con rapidez, en un contexto periodístico donde las noticias no podían esperar semanas de desarrollo. Hoy, señaló, una aplicación para una historia específica puede levantarse en horas con ayuda de un agente, sin que la estética interna del código sea la prioridad inicial.

Esa realidad cambia la ecuación para ciertos componentes reutilizables. Se preguntó, por ejemplo, por qué alguien usaría una librería genérica de selector de fecha si un modelo puede generar un date picker a medida, adaptado a móviles y accesibilidad. A su juicio, esto ya está afectando incluso a modelos de negocio asentados sobre bibliotecas de componentes premium.

Sin embargo, no concluyó que el código abierto vaya a desaparecer. Recordó que los agentes dependen profundamente del ecosistema abierto para recomendar librerías, unir piezas y producir resultados útiles. En ese sentido, la productividad de la nueva generación de herramientas descansa precisamente sobre décadas de trabajo comunitario.

Lo que sí observa es una presión creciente sobre los mecanismos tradicionales de colaboración. Comentó que muchos proyectos están siendo inundados por contribuciones basura generadas con IA, hasta el punto de que algunos mantenedores quieren que plataformas como GitHub permitan desactivar pull requests. Si eso se consolida, el ecosistema abierto enfrentará no solo una crisis de incentivos, sino también una de gobernanza y control de calidad.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados