Construir con Agentes de IA: el experto sigue al volante, pero el viaje cambió para siempre

Hace un par de años, cuando alguien me preguntaba cuánto tardaba en construir una herramienta interna —un dashboard, un script de automatización, un microservicio para resolver un dolor puntual del equipo— mi respuesta tenía siempre la misma forma: "depende, pero calcula entre dos y cuatro semanas si lo hacemos bien".

Hoy esa misma conversación termina distinto. Calcula entre dos y cuatro días. A veces, dos y cuatro horas.

No es magia. Y sobre todo, no es que el experto haya dejado de importar. Lo que cambió es quién hace qué, y en qué momento del proceso aparece cada uno. Esa es la conversación que quiero tener hoy.

Antes: el desarrollador como traductor

Durante mucho tiempo, construir software fue un ejercicio de traducción. Un experto entendía un problema —un proceso de negocio, un cuello de botella operativo, una necesidad del cliente— y se sentaba a traducirlo a código línea por línea.

Buena parte del tiempo no se iba en pensar la solución, sino en escribirla: el boilerplate del endpoint, la configuración del proyecto, el test que valida el caso borde, la documentación que nadie quiere escribir pero todos necesitan leer.

El experto cargaba con todo: el qué, el cómo, el cuándo y el escribirlo. Era lento porque tenía que serlo.

Ahora: el experto como director de orquesta

Cuando trabajamos con agentes de IA bien orquestados, el reparto cambia. El experto sigue definiendo el qué (qué problema resolvemos, qué éxito significa, qué restricciones existen) y el cómo a alto nivel (qué arquitectura, qué patrones, qué decisiones de diseño no son negociables).

Pero el agente puede asumir grandes pedazos del cómo a bajo nivel: andamiar el proyecto, escribir la primera versión funcional, generar los tests, mantener la documentación al día, refactorizar cuando algo huele mal.

Lo interesante no es que el agente "programe por ti". Es que te libera del trabajo mecánico para que puedas dedicar más tiempo al trabajo que sí requiere criterio. Y resulta que el trabajo que requiere criterio es, casualmente, el que diferencia una herramienta mediocre de una buena.

La velocidad real (y la trampa de medirla mal)

Cuando hablamos de productividad con agentes, hay una tentación de medirla en líneas de código por hora o en tickets cerrados por sprint. Es una mala métrica.

Lo que realmente cambia es otra cosa:

El tiempo entre "se me ocurre una idea" y "tengo un prototipo funcionando que puedo enseñar" se desploma. Lo que antes era una conversación de "déjame estimarlo y la próxima semana te digo si vale la pena" hoy es "dame veinte minutos y te muestro algo navegable".

Eso no solo acelera la entrega, cambia la forma en que decidimos qué construir, porque experimentar deja de ser caro.

El costo de tirar a la basura una versión también baja. Cuando reescribir un módulo cuesta una tarde en lugar de una semana, dejas de aferrarte a decisiones tempranas que ya no sirven. La calidad sube no porque escribamos mejor a la primera, sino porque iteramos más veces sobre la misma idea.

Y el mantenimiento —ese trabajo invisible que se come la mitad del presupuesto de cualquier herramienta seria— se vuelve manejable. Un agente puede ayudarte a entender un código que escribiste hace seis meses, a actualizar dependencias sin romper nada, a documentar lo que ya existe. Cosas que sabíamos que teníamos que hacer y que nunca priorizábamos.

El nuevo rol: del que escribe al que decide y valida

Si tuviera que resumir en una frase cómo cambió el rol del desarrollador, diría: pasamos de escribir a dirigir, revisar y validar. Y aunque suena a degradación, en la práctica es lo contrario: es un trabajo más exigente intelectualmente, no menos.

Dirigir significa saber qué pedirle al agente. Eso requiere tener clara la arquitectura, el dominio del problema, las restricciones del negocio. Un agente sin contexto produce código que parece correcto pero resuelve el problema equivocado. Quien dirige bien al agente necesita entender mejor el problema que quien lo programaba a mano, porque ahora tiene que articularlo con precisión en vez de descubrirlo escribiendo.

Revisar significa leer crítica y rápidamente. El agente produce mucho código en poco tiempo, y aceptarlo sin más es la receta para acumular deuda técnica a velocidad récord. Revisar implica tener criterio sobre qué es legible, qué es mantenible, qué patrón encaja con el resto del sistema y cuál no.

Validar es la parte que ningún agente puede asumir por ti: ¿esto resuelve realmente el problema del usuario? ¿es seguro? ¿se comporta bien bajo carga? ¿no rompe nada río abajo? Esas preguntas requieren contexto del mundo real, conversaciones con personas, intuición construida con años de errores propios.

La responsabilidad no se delega

Acá quiero ser muy claro, porque es donde he visto a más equipos meterse en problemas: la responsabilidad técnica sigue siendo enteramente del experto humano.

Si una herramienta filtra datos, si un script borra lo que no debía, si una decisión de diseño te lleva a un callejón sin salida en seis meses —el responsable es la persona que aprobó ese código, no el agente que lo escribió.

Esto no es un detalle legal ni una formalidad. Es lo que hace que el trabajo siga teniendo sentido. Un agente puede generar diez soluciones razonables a un problema; alguien tiene que decidir cuál es la correcta para este contexto, este equipo, este usuario. Esa decisión se apoya en experiencia que no se delega.

Lo que cambia es dónde gastas tu atención. Antes, buena parte se iba en producir el código. Hoy se va en evaluarlo, integrarlo y responsabilizarte de que haga lo que prometiste. Es menos teclado y más juicio, pero no es menos trabajo.

Lo que estamos aprendiendo en HechoX

Los proyectos donde el combo experto + agente está funcionando mejor tienen tres cosas en común:

1. Hay una persona claramente responsable de cada pieza, con autoridad y contexto para revisar lo que el agente produce 2. El agente recibe contexto rico al inicio —no solo "haz X", sino "estas son nuestras convenciones, este es el resto del sistema, estos son los casos que importan" 3. Existe un ciclo de revisión real, donde el código generado se lee, se prueba y se cuestiona antes de mezclarse con el resto

Los proyectos que han tenido problemas suelen fallar en lo mismo: se trató al agente como un junior al que se le delega y ya, sin revisar a fondo. El resultado es código que funciona en la demo y se desmorona en producción.

Hacia dónde vamos

Mi convicción a estas alturas es esta: las herramientas internas, los prototipos y buena parte del software de uso específico están entrando en una era donde se construyen en horas, no en semanas, y eso va a redefinir qué problemas vale la pena resolver con software a la medida.

Muchos dolores que antes no justificaban el costo, ahora sí.

Pero quien siga creyendo que esto significa "menos expertos" se va a estrellar. Significa expertos haciendo más, con más alcance, decidiendo sobre más cosas. Significa que la diferencia entre un equipo que aprovecha esto y uno que no, no va a estar en quién tiene acceso a los agentes —eso ya lo tiene todo el mundo— sino en quién tiene la disciplina, el criterio y el dominio para dirigirlos bien.

El experto sigue al volante. Lo que cambió es el motor.

---

¿Ya estás construyendo con agentes? Cuéntame qué aprendes en el camino.