El día de hoy llegué en la mañana a una serie de artículos en Medium sobre agentes de inteligencia artificial. La idea es que acaben reemplazando a desarrolladores humanos.
Veo una serie de problemas grandes además de lo de conectividad:
Primero, que no pueden hacer nada ante vidas humanas o el riesgo de éstas. Inclusive el efecto de trámites mal hechos.
Segundo, tomar decisiones serias que impliquen pérdida de miles de litros o kilos de producto.
No resuelven problemas reales relativamente simples, porque:
- El ser humano no es simple
- El ser humano no es lógico
- Lo que muchas personas buscan es control o reducción de costos, no eficiencia
Y la mayor parte de las selecciones se basa en CONDICIONES IDEALES. No es mi caso, pero es buen pretexto para ahorrar costos y correr personas. Pero no arreglan los problemas.
Vamos a explicar algo antes:
Una cosa son los chats tipo ChatGPT, Claude, Copilot, Llama, Mistral, DeepSeek, Grok y Kimi. Son útiles y pueden sobrevivir aunque a veces alucinen. Son modelos LLM.
La idea de los AGENTES depende de hacer scripts, como los antiguos «robots de código» en C o Pascal que se enfrentaban en un campo de batalla virtual. Idealizados. Pero para que funcionen requieren demasiadas condiciones de control y hay demasiados puntos de falla.
Uno de ellos, no el único, es el ejemplo que he comentado de querer usar React para una pantalla con 800 combos de entrada. Si te imponen eso, el agente tratará de hacerlo pero es basura.
El segundo es que hay complicaciones extraordinarias que ve como naturales. Pongo ejemplos más abajo.
Estuve tratando con Gemini 3, DeepSeek y Claude sobre cómo aplicar AGENTES a ciertos problemas. Claude dijo, a su manera cortés, que era económicamente inviable y el costo era excesivo.
Tres ejemplos reales, simplificados:
1. Fábrica de comida que se vende en central de abastos. Mandan carga de camiones hecha a mano por WhatsApp, se captura y luego las ventas de diez choferes. El costo real es la capturista y el servidor. La solución propuesta por presupuestos de LLM era: tensores de reconocimiento óptico de caracteres, modelo de negocio por técnica silo, ajustes por precios, y el costo era de 270 mil de implementación el primer año más alguien que revisara la captura a 400 pesos por hora, dos horas diarias. Con eso «se limita error humano del capturista». (Mi opinión: la mala fe de los choferes no se computa y es un proceso de evitar faltas de probidad, y reconocimiento óptico de 12 letras manuscritas con un costo de 35,000 MXN o 2000 USD por única ocasión es ridículo. Extra al entrar choferes nuevos. Tres agentes necesarios).
2. Tres problemas en cliente de los monolitos (luego doy detalles): uno era sobre firma electrónica, otro sobre puertos cerrados y RHEL sin acceso a root con PHP 7.x. El tercero era sobre resolver al vuelo problemas de un video de YouTube para cuadrar contra una hoja de Excel cerrada para escritura, y la solución de cada uno era de 270 mil pesos ANUALES POR CADA UNO. Lo peor del caso es que el sueldo que me pagaban era un poco mayor a eso (mas de 300 pero menos de 400), no lo pagaban en realidad y literalmente a veces pasaba por ocho pasos de servidores diferentes por puertos cerrados y necesidades de la burocracia.
3. Dato muy bonito. Oye, hay que verificar este documento y juzgarlo, son siete documentos por persona pero el primero tiene cincuenta datos con tres columnas y a ojo se decide sí o no. Solución de Gemini y Copilot era capturar los 150 campos de 35 formatos diferentes posibles para evitar el factor humano y reducir costos, ya que el análisis daba al final uno de 45 resultados posibles por solicitante. Para simplificar el paso final, la solución era que lo hiciera la misma analista como la dama Margarita, y que eso pasaba el costo a cero del proceso final de firmas porque ya el paso dos lo hacía un humano (la simplificación se hacía metiendo la analista150 datos por expediente que antes no hacía), pero seguíamos con el mismo problema en el paso 20 del proceso. Y el costo del servidor final e implementación según Copilot era cercano a cero porque el servidor se usaba para otras cosas. ¿? Gemini dijo cero sin que le preguntara. Así que era tecnología mágica que cuesta cero el servidor, el mantenimiento y el desarrollo del paso 20 porque te ahorraste usar IA en el paso 2 porque ahora la capturista metía 150 datos que antes no necesitaba.
Solo que ahora con un costo de 270 mil por cada una de las tres funciones que decía yo hacía (de unas 25 reales), con más problemas de control, y creando problemas donde no los había. Para coordinar eso ahora necesitaban un analista senior, o sea yo, que dedicara cuatro horas cada vez del tercer proceso para revisar los resultados de la IA (de tres a seis agentes por proceso) en lugar de las cinco horas que yo hacía a mano y que mis antecesores hacían en dos semanas.
Y me fui por falta de pago, actualmente dos procesos no lo hacen y el otro regresaron a Excel. Corolario : Las empresas mexicanas que no pagan a programadores experimentados no entienden los costos, y menos lo que cuesta AWS y lo que implican los agentes IA en dependencia. No pueden costear agentes de IA para problemas que un programador experimentado resuelve manualmente a menor costo y con mayor flexibilidad.
Las respuestas para las finanzas en México son como decirle a alguien sin casa que se compre un departamento con seguridad privada en Polanco. Es absolutamente irreal.
En resumen, que aprendí:
- Cuando la entrada de datos no se puede automatizar con fiabilidad (por la falta de uniformidad, calidad o el requisito legal/procedimental del original), la inversión en Agentes de IA que procesan esos datos se vuelve inviable o absurda.
- (Tiempo) 4 horas/mes para asegurar la continuidad del Actuador (FTP/XML-RPC) y actualizar el RAG si cambia algún dictamen crítico en lugar de las cinco horas de la persona actual en hacer el proceso es estúpido.
- Es irresponsable y falso afirmar que el costo de un Agente o microservicio de IA, incluyendo hardware y mantenimiento, es cero.
- La IA y los agentes se basan en el deseo y error retórico para adaptarse a un presupuesto institucional que no existe, pero violó el principio fundamental de la ingeniería de software: todo componente tiene un costo, y la IA no es mágica.
- La ingeniería de software dicta que la calidad de entrada condiciona la calidad de salida. Sin estandarización, la IA solo amplifica errores.
- La herramienta debe ser proporcional al problema. Si quieres usar un martillo para tomar la temperatura o un microondas para enfriar tu comida, no es lo mejor aunque tus jefes digan que sí.
- Si el costo de la solución excede el costo del error humano que pretende evitar, la solución es inviable.
- Muchos discursos de IA ignoran que la responsabilidad legal y técnica recae en quien implementa. No basta con decir «la nube es segura».
Principio de auditoría: todo flujo que involucra datos sensibles debe cumplir con:
- Control de acceso (quién puede ver/editar)
- Trazabilidad (qué se procesó, cuándo y por quién)
- Cifrado en tránsito y reposo
- Cumplimiento normativo (en México: Ley Federal de Protección de Datos Personales)
En resumen, por razones largas de explicar aquí, veo que los agentes de IA necesitan una inversión que incluso el gobierno no puede hacer, para rangos de retorno (ROI) bajísimos y hacer el proceso más vulnerable.
Sí creo que funcionen LLM y equipos aislados, pero los puros costos de nube, sin contar el desarrollo, hacen que usar Agentes de inteligencia artificial sea ineficiente y casi imposible. No solo por la complejidad de las acciones humanas, sino porque si la entrada no está absolutamente automatizada, no existe la oficina sin papeles.
Solo que dar acceso a correos, hojas de cálculo o repositorios de código fuente a los LLM y agentes no es buena idea. Tampoco usarlos, como decimos, en producción. Con un buen prompt puedes capturar los casos edge que te acuerdas, pero los que hayan tratado con herramientas CASE como el infame GeneXus o sistemas expertos, saben que el script de datos parece un lenguaje en sí y es propietario. Ahora no dependes de una persona sino de una corporación que deprecia funcionalidades o cambia estándares.
La situación es muy parecida al boom en los 90s-2000 de Active Documents y Java Beans, el de jQuery en 2010 y después Angular (1, 2… 19 casi siempre incompatibles entre sí, incluso peor que Laravel). Un poco como usar JavaEE y Amazon AWS en México para una papelería con 20 sucursales. Le veo más sentido a Javelin o Quarkus. Me explico:
Todas estas tecnologías llegaron con la promesa de revolucionar el desarrollo, bajar costos y «democratizar» la programación. ¿Te acuerdas?
- Los Active Documents de Microsoft iban a eliminar la necesidad de programadores.
- Los Java Beans prometían componentes universales y reutilizables.
- jQuery simplificaría todo el desarrollo web.
- Angular cambió su API radicalmente entre versiones (de la 1 a la 2, y luego hasta la 19 con breaking changes), obligando a reescribir aplicaciones completas.
- Laravel hace lo mismo cada vez que sube de versión mayor.
El patrón es el mismo: adoptas la tecnología de moda, inviertes tiempo y dinero, y en 3–5 años está obsoleta o toca migrar con costos altos.
Ahora, los agentes de código que hacen commits a Git tienen exactamente el mismo problema… pero peor. Generan código según los patrones y convenciones del agente o LLM específico. Si ese agente cambia su forma de generar código, deprecia funcionalidades, o la empresa detrás cambia su modelo de negocio, tu código queda amarrado a esa versión y a ese momento. Es como lo que pasaba con GeneXus: generabas miles de líneas que solo el sistema entendía, y si pedías un requisito nuevo, tenías que empezar de cero y perder tus ajustes manuales. En vez de depender de un programador que podías contratar o capacitar, ahora dependes de una corporación de IA que controla el estándar.
- Nota: Las herramientas CASE como GeneXus son el antecesor inmediato y es especialmente preciso: «si pedías un requisito nuevo, tenías que empezar de cero y perder tus ajustes manuales» – eso es exactamente lo que pasa con código generado por agentes cuando cambian de versión, cambian tus requisitos, los del cliente, el hardware, o las reglas de negocio. Lo que para un programador experimentado son 30 minutos en su código, son horas o días donde hay tiempo muerto, la empresa no factura o hay pérdidas directas.
Los agentes solo procesan la entrada que tú les des y lo que les digas que miren. No detectan:
- a) Cambios en el hardware buenos o malos … o en sus costos !!
- b) Si el contador se murió
- c) Si google.com resuelve en DNS
- d) Si hay respaldos
- e) Si hay faltas de probidad
- f) Si el disco duro va a tronar
Suficientes razones cada una de ellas para no usar agentes de IA.
Y cuando esos agentes fallen o generen bugs sutiles en producción, ¿qué pasa? Vas a necesitar programadores senior. Pero no programadores comunes: gente que entienda tanto el código generado como el contexto del negocio para corregirlo. Eso cuesta más, porque ahora tienen que descifrar qué hizo el agente. O sea, no reduces costos, y encima agregas más puntos de falla.
Resumen ejecutivo:
-
Tesis: Los Agentes de IA son inviables para problemas reales no idealizados.
-
Motivo (Humano): El factor humano/gerencial (costo, control, no lógica) es el verdadero problema.
-
Evidencia (Costo Real): Los ejemplos demuestran que las soluciones IA son más caras que el problema que intentan resolver, y se requiere más supervisión humana (Analista Senior).
-
Principio (Técnico): Los agentes amplifican errores si la calidad de la entrada es baja (no hay «oficina sin papeles»).
-
Analogía (Histórica): Es una moda pasajera con el mismo fallo de las tecnologías propietarias del pasado (dependencia corporativa, altos costos de migración).
Lo que realmente importa:
- Los LLM sí pueden funcionar como asistentes web o aislados / isolated.
- Los agentes de IA que escriben directamente en repositorios o leen tu correo o tus hojas de cálculo son, honestamente, una llamada al desastre y una moda pasajera.