Qué es un agente de código (coding agent) como Claude Code

El problema real detrás del término

Toda empresa que no es de software acumula una lista de tareas que nadie quiere hacer y nadie ha resuelto: cruzar dos reportes que no comparten formato, migrar datos de un sistema viejo al nuevo sin perder historial, generar el mismo documento veinte veces por semana cambiando solo tres datos, avisar por correo cuando un inventario cruza un umbral. Cada una de esas tareas, sola, no justifica un proyecto de software. Juntas, se comen horas de gente capacitada que debería estar haciendo otra cosa.

El problema no es solo el costo de contratar. Es que ese tipo de trabajo vive en una zona incómoda: demasiado específico para un software genérico que ya tengas licenciado, demasiado técnico para resolverlo con una hoja de cálculo o una automatización sin código, y demasiado pequeño para justificar la atención de un desarrollador interno o de una consultora externa. El resultado, en la práctica, es que se sigue haciendo a mano, con el riesgo de error humano de siempre, o simplemente no se hace.

Ahí es donde entra una categoría de herramienta que hasta hace poco no existía como opción real para una empresa fuera del rubro tecnológico: un sistema que no solo redacta código cuando se lo pides, sino que puede meterse a un repositorio, escribir el script, correrlo, revisar si el resultado es el esperado, y corregir si no lo es. Antes de llegar a la definición vale la pena entender que esto no es una mejora del corrector ortográfico del programador. Es un salto de nivel en la autonomía que se delega.

Qué es un agente de código, en criterio de negocio

Para el negocio, lo que importa no es la etiqueta técnica sino el nivel de autonomía que el sistema tiene sobre tu operación. Hay una escala clara detrás de la palabra agente de código, y confundir los escalones es lo que lleva a delegarle de más, o de menos, a una herramienta.

En criterio de negocio, un agente de código no es «una IA que programa». Es más parecido a contratar a alguien extremadamente literal y siempre disponible, darle acceso a una carpeta específica y a una terminal, decirle qué objetivo cumplir, y pedirle que muestre evidencia de que funcionó antes de que tú apruebes el resultado. La diferencia con lo anterior no es la calidad del código que escribe: es que ahora puede ejecutarlo, ver si falla, y volver a intentarlo sin que tengas que estar mirando cada línea.

Eso es lo que separa a esta categoría de un simple generador de texto que parece código: la capacidad de actuar sobre archivos reales y de verificar su propio trabajo, no solo de sugerirlo.

La escala que importa: de sugerir una línea a ejecutar un objetivo

La escala que importa para decidir cuánto delegar tiene tres escalones, y cada uno implica un nivel distinto de riesgo y de supervisión.

Autocompletado: sugiere una línea

Es el nivel más básico: el sistema predice la siguiente línea o el siguiente bloque mientras alguien escribe. No toca nada por su cuenta, no corre nada, no decide nada. El riesgo que asume la empresa es prácticamente nulo porque la persona sigue escribiendo y aprobando cada carácter.

Copiloto: te acompaña en el editor

Un paso más: responde preguntas sobre el código existente, propone bloques más largos, explica qué hace una función. Sigue dentro del editor, sigue esperando que una persona copie, pegue y decida. Ahorra tiempo de redacción, pero el criterio de qué se integra y qué no sigue siendo cien por ciento humano en cada paso (este nivel se desarrolla con más detalle en la entrada sobre qué es un copiloto de IA).

Agente de código: recibe un objetivo, toca varios archivos, corre pruebas e itera

Acá cambia la naturaleza del trabajo. Ya no se pide una línea ni una función: se da un objetivo, por ejemplo «hazme que este reporte cruce estos dos archivos y avise si hay diferencia mayor a la esperada», y el sistema explora el repositorio, escribe en varios archivos si hace falta, ejecuta lo que escribió, revisa si el resultado cumple el objetivo, y corrige si no. La persona deja de mirar cada línea y pasa a revisar el resultado final y el camino que tomó para llegar ahí.

• El copiloto espera que copies y pegues; el agente ejecuta directamente sobre el repositorio.
• El copiloto responde una pregunta a la vez; el agente sostiene un objetivo a lo largo de varios pasos.
• El copiloto no verifica su propio resultado; el agente corre pruebas o comandos para comprobar si lo que hizo funciona.
• El copiloto no decide qué archivo tocar; el agente explora el repositorio y elige dónde intervenir.
• El nivel de revisión humana necesario sube en cada escalón, no baja.

Qué cambia para un negocio que no es de software

El cambio real no es técnico, es económico. Antes, para que una empresa que no vive del software construyera una herramienta interna, el costo de conseguir a alguien que la escribiera, la probara y la mantuviera tenía que justificarse contra el valor de esa herramienta. La mayoría de las necesidades internas de una empresa mediana no cruzan ese umbral: son útiles, pero no valen un contrato de desarrollo. Con un agente de código, ese umbral baja, porque quien antes tenía que escribir y probar la herramienta ahora puede supervisarla en lugar de escribirla línea por línea.

Eso abre una puerta concreta: la herramienta interna que antes no valía contratar ahora sí vale construirse, si alguien dentro de la empresa entiende el proceso que quiere automatizar y sabe revisar el resultado.

• Una cadena retail en Perú que necesitaba cruzar el inventario de su punto de venta con el de su proveedor logístico, sin conector nativo entre ambos sistemas.
• Una constructora en Colombia que generaba a mano el mismo reporte de avance de obra cada semana, copiando datos de tres archivos distintos.
• Un despacho contable en México que revisaba manualmente si las facturas emitidas calzaban con lo declarado, tarea repetitiva y propensa a error humano.
• Una empresa de servicios en Chile que quería una alerta automática cuando un cliente cruzaba cierto nivel de consumo, sin pagar por un módulo de un sistema que no usaba el resto de funciones.
• Una operación de manufactura que necesitaba migrar años de historial de un sistema descontinuado a uno nuevo sin perder trazabilidad.

Qué exige antes de encenderlo

Nada de esto funciona si se le da a un agente de código acceso irrestricto porque ahorra tiempo. Lo que baja el riesgo de catastrófico a manejable es la disciplina alrededor de la herramienta, no la herramienta misma.

• Control de versiones real: todo cambio que el agente propone queda registrado, se puede revisar y se puede revertir. Sin esto no hay forma de saber qué tocó ni de deshacerlo.
• Revisión humana antes de integrar cualquier cambio a lo que la empresa realmente usa. El agente propone, una persona con criterio del proceso aprueba.
• Un entorno aislado para que trabaje: una copia de los datos, no la base de producción; un ambiente de prueba, no el sistema en vivo con clientes reales adentro.
• Cero permisos sobre producción por defecto. Si el agente necesita tocar algo que sí importa, ese acceso se otorga puntual y temporalmente, nunca como configuración permanente.
• Alguien responsable de definir qué significa «terminado» para esa tarea, antes de lanzar al agente a resolverla. Sin ese criterio, el agente puede darse por satisfecho con algo que no sirve.

Esto no es paranoia, es la misma lógica que se aplica a cualquier persona nueva con acceso a sistemas de la empresa: se le da lo que necesita para hacer el trabajo, no todo lo que existe.

Cómo se supervisa en la práctica

En el día a día, supervisar un agente de código se parece más a revisar el trabajo de alguien junior con mucha velocidad y cero contexto de negocio, que a programar. La pregunta no es si escribió código correcto, es si resolvió el problema que había, de la forma esperada, sin tocar nada que no debía.

En la práctica, eso significa revisar la diferencia entre lo que había antes y lo que el agente dejó, correr las pruebas que confirman que el resultado funciona antes de aceptar el cambio, y tener claro de antemano qué límites no se negocian: qué carpetas puede tocar, qué comandos puede correr, qué credenciales jamás va a ver.

Esto conecta con varias ideas que conviene tener claras antes de meter un agente de código a una operación real: qué tan lejos llega su autonomía sin supervisión humana, que es el tema de la entrada sobre qué es un agente autónomo; qué tanto contexto del negocio necesita para no equivocarse de objetivo, que se explica en la entrada sobre ingeniería de contexto; y en qué se diferencia de simplemente aceptar sugerencias de código sin revisarlas, el riesgo detrás de lo que se conoce como vibe coding. Correr cualquiera de estos niveles sin un entorno de prueba separado es el error que cubre, aparte, la entrada sobre sandbox de IA.

Mi criterio

Cuándo sí conviene y cuándo no

No toda empresa necesita esto hoy, y meterlo sin las condiciones mínimas genera más problema del que resuelve. Hay señales concretas para saber en qué lado estás.

Señales de que sí conviene probar un agente de código

• Tienes una lista de tareas repetitivas y bien definidas que nadie ha automatizado porque el ticket es demasiado chico para contratar a alguien.
• Cuentas con control de versiones y con alguien que sabe revisar un cambio antes de aprobarlo, aunque no sea programador de profesión.
• Puedes darle al agente un entorno de prueba separado de tu operación real, con datos que no comprometen a un cliente si algo sale mal.
• El objetivo que le darías se puede describir de forma concreta y verificable, qué archivo, qué condición, qué resultado esperado, no como una idea vaga.
• Ya identificaste el proceso que quieres resolver y sabes que el problema es de ejecución, no de que el proceso mismo está mal diseñado.

Señales de que no es el momento

• Nadie en el equipo puede revisar lo que el agente entrega; la aprobación sería un trámite, no una revisión real.
• No existe entorno aislado y la única opción realista es dejarlo tocar sistemas en producción desde el primer día.
• El proceso que quieres automatizar todavía no está claro ni siquiera para las personas que lo hacen a mano.
• La expectativa interna es que esto reemplace a un desarrollador, no que libere tiempo de alguien que ya sabe revisar código.
• No hay forma de deshacer un cambio si algo sale mal, porque no hay control de versiones ni respaldo del estado anterior.

El orden correcto, aplicado a este término

El orden nunca cambia, tampoco acá: primero el dolor real, la tarea que nadie quiere hacer y que cuesta más de lo que parece; después el proceso, entender exactamente qué pasos sigue esa tarea y por qué; después el dato, qué información entra y sale, y en qué formato; y solo al final la herramienta. Un agente de código es una herramienta poderosa para ese último paso. No arregla ninguno de los tres anteriores, y si se lo pide antes de tenerlos resueltos, lo único que consigue es automatizar el desorden más rápido.

La pregunta que de verdad importa no es si tu empresa «ya tiene» un agente de código. Es si tu empresa tiene el proceso claro, el dato ordenado, y a alguien con criterio para revisar lo que la herramienta entrega. Eso no lo vende ningún proveedor: se construye antes, y es lo único que hace que la autonomía de la herramienta valga la pena en lugar de dar miedo.