Agentes de IA en el código: menos magia, más control

Pediste una pantalla nueva en el sistema, el proveedor dijo "la IA lo hace en una tarde" y tres semanas después nadie puede explicar por qué el informe de ventas dejó de cuadrar. Esta historia se está volviendo rutina. Los agentes de IA escriben código a una velocidad absurda. El problema casi nunca es la velocidad. Es lo que pasa cuando nadie sujeta el volante.

Hace unos días apareció en Hacker News un proyecto llamado Huzzah. Su autor lo presenta como una nueva forma de programar con IA. No voy a resumir la herramienta aquí, entre otras cosas porque es para desarrolladores. Lo que me llamó la atención fue la pregunta que hay detrás, y le interesa mucho a quien paga la cuenta de un software: ¿quién manda en el trabajo, la persona o el agente?

Qué son los agentes de IA en el desarrollo de software

Un chatbot responde preguntas. Un agente actúa. Abre archivos, escribe código, ejecuta pruebas, corrige el error y vuelve a intentarlo. Todo solo, en secuencia.

En la práctica, el desarrollador escribe algo como "crea un registro de clientes con búsqueda por número fiscal" y el agente se pone a trabajar. En 20 minutos hay una pantalla funcionando. Parece magia. Y ahí está el peligro.

Porque el agente no conoce tu negocio. No sabe que tu área financiera necesita el número fiscal con puntos y guiones para el ERP antiguo. No sabe que un cliente inactivo no puede aparecer en la búsqueda del equipo comercial. Llena esos huecos con suposiciones razonables. Y una suposición razonable, en el software de una empresa, es un bug con buena apariencia.

Por qué el modelo "pedir y rezar" sale mal

La forma más común de usar IA para programar hoy es lo que yo llamo pedir y rezar. Describes lo que quieres en un texto largo, el agente genera un montón de código y tú cruzas los dedos para que esté bien.

Funciona bien en proyectos pequeños. Una landing page, un script que ordena una hoja de cálculo, un prototipo para mostrarle al socio. En esos casos, si sale mal, lo tiras y pides de nuevo.

En un sistema que sostiene la operación, la cuenta cambia. Un ejemplo que vi de cerca: una empresa pidió una automatización para generar facturas de cobro a partir de pedidos aprobados. El agente entregó rápido. Solo que interpretó "pedido aprobado" como cualquier pedido con estado distinto de "cancelado". Resultado: cobros emitidos para pedidos que todavía estaban en análisis de crédito. Fueron unos 40 cobros erróneos antes de que alguien lo notara. El código estaba limpio. La regla estaba mal.

La IA no se equivoca por falta de capacidad. Se equivoca por falta de contexto.

Qué cambia cuando la persona mantiene el control

La idea que exploran proyectos como Huzzah, y que yo defiendo hace tiempo, es simple: en lugar de entregarle la tarea entera al agente, divides el trabajo en decisiones pequeñas y revisas cada una.

Parece más lento. No lo es. Compara dos caminos para la misma funcionalidad:

• Pedir y rezar: 1 hora generando, 6 horas descubriendo qué quedó mal, 4 horas corrigiendo sin romper el resto.
• Paso a paso con revisión: 3 horas construyendo en etapas cortas, 1 hora de ajuste fino.

Los números varían de un proyecto a otro, claro. Pero el patrón se repite. El tiempo que "ahorras" dejando suelto al agente vuelve cobrado con intereses en la fase de corrección.

En el paso a paso, el flujo queda más o menos así:

1. La persona define la regla de negocio en lenguaje claro, antes de cualquier código.
2. El agente propone un plan corto. La persona lo aprueba o lo corrige.
3. El agente implementa una parte pequeña.
4. La persona revisa, prueba con un caso real y solo entonces libera la siguiente parte.

Es la misma forma en que un buen gerente trabaja con un empleado nuevo, muy capaz y sin ningún contexto de la empresa. No le entregas la llave de la caja fuerte el primer día. Le das tareas, revisas, ajustas y vas soltando las riendas a medida que crece la confianza.

Cómo saber si tu proveedor usa la IA de la forma correcta

No necesitas entender de código para hacer buenas preguntas. Y hoy prácticamente todo desarrollador usa IA de alguna forma. Lo que importa es cómo.

Algunas preguntas que separan a quien la usa bien de quien solo aprieta el botón:

• "¿Quién revisa el código que genera la IA?" Si la respuesta es "la propia IA", enciende la luz amarilla.
• "¿Cómo validan las reglas de mi negocio?" Espera oír hablar de casos de prueba con ejemplos reales de tu operación.
• "Si hay un problema dentro de seis meses, ¿alguien va a entender este código?" Código que nadie leyó es código que nadie sabe arreglar.
• "¿Las entregas son grandes o por partes?" Entregar en partes pequeñas es señal de control. Un paquetazo a fin de mes es señal de rezo.

Mi opinión, sin rodeos: el proveedor que vende "la IA lo hace todo, por eso es barato" te está vendiendo una deuda con cuotas que van a vencer después. El ahorro real de la IA está en quitar el trabajo pesado del camino, no en quitar el juicio humano del proceso.

Dónde brillan de verdad los agentes de IA

No quiero que salgas de aquí pensando que los agentes de IA son un fraude. Al contrario. Los uso todos los días, y la ganancia es enorme cuando el trabajo está bien dividido.

Son excelentes en:

• Tareas repetitivas: crear diez pantallas de registro parecidas, migrar datos de un formato a otro.
• Primer borrador: sacar una idea del papel en horas para que la veas, hagas clic y opines.
• Lectura de sistemas antiguos: explicar qué hace un código de 2015, algo que antes costaba días de alguien sufriendo.
• Pruebas: generar casos de prueba que un humano cansado olvidaría.

Y son débiles en todo lo que depende de saber cómo funciona tu empresa de verdad. Esa excepción que solo conoce la gente del almacén. El cliente grande que tiene un plazo de pago distinto. El parche del sistema fiscal que nadie documentó, pero que todo el mundo respeta.

Eso no sale de ningún modelo. Sale de conversar. Por eso la parte más valiosa de un proyecto con IA sigue siendo la más humana: sentarse, entender el proceso y escribir las reglas antes de ponerse a generar código. Si el agente fuera un becario, sería el becario más rápido del mundo. Pero seguiría siendo un becario.

Qué llevarte de esto para tu empresa

Si estás pensando en usar IA para construir o mejorar algún sistema, quédate con tres ideas:

Velocidad de generación no es velocidad de entrega. Lo que cuenta es cuánto tiempo pasa hasta que la cosa funciona bien, en producción, con tus datos.

Control es trabajar en partes pequeñas. Cuanto más grande sea el trozo que le entregas al agente de una vez, mayor es la probabilidad de que una suposición errónea se esconda ahí dentro.

El contexto es tu activo. El conocimiento sobre cómo opera tu negocio vale más que cualquier herramienta. La IA amplifica ese conocimiento. Sin él, amplifica la adivinanza.

El debate que Huzzah abrió entre desarrolladores es el mismo que todo dueño de negocio debería tener con quien se encarga de su tecnología. No se trata de usar o no usar IA. Se trata de quién decide.

Así trabajo en mis proyectos de automatización e IA: la máquina acelera, yo decido y tú acompañas cada etapa. Si quieres entender mejor esta forma de trabajar, conoce un poco más sobre mí.

El proveedor dijo "la IA lo hace en una tarde". Tres semanas después, nadie sabía explicar por qué el informe de ventas dejó de cuadrar.

Ya vi a un agente de IA emitir 40 facturas de cobro erróneas con un código impecable. El código estaba limpio. La regla de negocio era lo que estaba mal.

La IA no se equivoca por falta de capacidad. Se equivoca porque no conoce tu negocio.

Pedir todo de una vez y cruzar los dedos parece rápido, pero la cuenta llega a la hora de corregir. Lo que funciona es dividir en partes pequeñas, revisar cada una y liberar la siguiente solo después de probar.

La máquina acelera. Quien decide sigue siendo una persona.

Si quieres usar IA en tus sistemas sin volverte rehén de ella, vale la pena conversar.

#InteligenciaArtificial #AgentesDeIA #DesarrolloDeSoftware #Automatizacion #Tecnologia