Hace unos días cerramos una entrega con 47 commits en 24 horas, repartidos entre backend y frontend. Los hizo una sola persona trabajando con un agente de códigoAgente de códigoUn agente de IA que escribe, modifica y prueba código por su cuenta dentro de un proyecto. Es una cifra que llama la atención, y por eso conviene decir enseguida que no es la importante.
Lo importante es por qué fue posible, y qué habría pasado si la misma herramienta hubiera estado en otras manos.
Escribir código ya no es el cuello de botella
Un agente de código escribe rápido, no se cansa y encadena decenas de cambios en una jornada. Eso no elimina el problema: lo desplaza. Antes, lo lento era producir el código. Ahora lo lento es saber qué código hace falta y comprobar que el que se ha escrito hace lo que debe.
Dicho de otro modo: el agente pone la velocidad. La dirección la pone la persona.
Lo que se multiplica
Un agente amplifica a quien lo dirige, en los dos sentidos.
Si conoces bien el sistema, sabes en qué orden hay que hacer las cosas y reconoces un error cuando lo ves, el agente convierte ese conocimiento en trabajo terminado a un ritmo que antes no existía.
Si no lo conoces, el agente convierte tus lagunas en código con la misma rapidez. Y lo hace con buen aspecto, que es justo lo que lo vuelve peligroso.
Un ejemplo, inventado pero muy reconocible. Una tienda online decide dejar de guardar los precios con decimales y pasar a céntimos enteros, para acabar con los descuadres de redondeo. El agente recibe la orden, localiza los veintitantos archivos afectados y los cambia todos en una tarde. Los tests pasan. El código se lee bien. Dos semanas después, los descuentos por porcentaje empiezan a dar un céntimo de menos en algunos carritos. En uno solo de aquellos archivos el agente redondeó antes de multiplicar en vez de después. Nadie lo vio porque los datos de prueba eran cantidades redondas y porque el cambio tenía exactamente el mismo aspecto que los otros veinte.
Quien conocía ese cálculo habría pedido una prueba con 19,99 € y un 15 % antes de aceptar nada. Quien no, aceptó un cambio correcto en veinte sitios y equivocado en uno, con la misma confianza en los veintiuno.
Por eso la frase funciona en las dos direcciones: el agente multiplica lo que ya sabes, y también lo que no sabes.
Tres cosas que debe dominar quien dirige un agente
1. Qué pedir. Hay que conocer el sistema lo bastante para dividir el trabajo en pasos acotados, darlos en el orden correcto y saber cuándo el resultado no es el que se pidió. Un agente responde a la pregunta que le haces, no a la que deberías haber hecho.
2. Qué puede tocar. Los permisos de un agente deben ser mínimos y explícitos: qué repositorios, qué ramas, qué credenciales, y si tiene o no acceso a producción. Dar acceso total «para ir más rápido» es la forma más corta de convertir un error pequeño en uno grande.
3. Hasta dónde llega. No todas las acciones pesan igual. Un cambio en una rama se revierte; un borrado de datos o un despliegue mal hecho, no siempre. Las acciones irreversibles las revisa una persona antes de que ocurran, sin excepciones.
Cómo lo hacemos nosotros
No es teoría. Nuestro día a día con agentes tiene cuatro reglas que no se negocian:
- El agente trabaja libremente en local y en ramas de trabajo. Producción no la toca sin que una persona diga que sí, paso a paso.
- Antes de desplegar, copia de seguridad de lo que se va a sustituir y un procedimiento de vuelta atrás ya escrito. Si algo falla, se restaura en un minuto, no se improvisa.
- Las pruebas se ejecutan antes de tocar nada y se vuelven a ejecutar en el servidor después. Si una falla, el despliegue no sale, por mucha prisa que haya.
- Cuando el agente dice «hecho», alguien comprueba que es verdad. La afirmación no es la evidencia.
Son reglas aburridas. Precisamente por eso funcionan.
Esto no va solo de código
Todo lo anterior vale igual, o más, para los agentes que empiezan a entrar en las empresas sin escribir una línea de código: el que responde a clientes por WhatsApp, el que registra gastos, el que mueve una cita, el que envía un correo en nombre de alguien. Son acciones sobre datos y personas reales, y algunas no se deshacen.
La misma pregunta sirve para todos: qué puede hacer solo, qué necesita aprobación y quién la da. En NAiOS un agente puede proponer un cobro, un envío o un cambio en una ficha, pero la acción la confirma una persona. Es lo que llamamos una empresa HITL, con la persona dentro del circuito. No porque el agente sea torpe, sino porque la responsabilidad no se delega.
Con varios agentes, más todavía
Cuando una persona coordina varios agentes a la vez, lo anterior deja de ser una buena práctica y pasa a ser una condición. Un error ya no ocurre en un solo sitio ni en un solo momento. Los permisos y los límites de cada agente son lo que separa un equipo que avanza en paralelo de un problema que se propaga en paralelo.
La conclusión
Los agentes no sustituyen el criterio; lo hacen más valioso. La persona que sabe muy bien lo que hace consigue en un día lo que antes llevaba semanas. La que no lo sabe consigue lo mismo, pero con sus errores.
La pregunta para cualquier empresa que esté adoptando agentes no es cuánto más rápido puede ir. Es quién va a dirigirlos, con qué permisos y con qué límites. Es, de hecho, lo que el Reglamento Europeo de IAAI Act (Reglamento Europeo de IA)Reglamento (UE) 2024/1689: la primera ley integral sobre inteligencia artificial, con obligaciones por nivel de riesgo llama supervisión humana, y lo que pide a las empresas que sus equipos sepan hacer desde el artículo 4. Nosotros empezamos por ahí.
