El futuro de la computación es delegación, no clicks — y todavía no estamos preparados para vivir ahí

El click como unidad de trabajo

Toda la arquitectura del software empresarial moderno está organizada alrededor de una unidad de trabajo: el click. Hay un botón para guardar, un menú para navegar, un formulario para completar. El diseño UX — una industria entera, con sus propias conferencias, sus propios libros, sus propios principios — existe para hacer esa secuencia de clicks lo más eficiente e intuitiva posible para un humano.

Esta arquitectura tiene décadas. Nació con las interfaces gráficas de los 80, se consolidó con la web de los 90 y 2000, y se perfeccionó con el SaaS de los 2010. Salesforce, HubSpot, Shopify, Notion, Jira, Figma — todos comparten la misma filosofía de base: el software como espacio navegable por humanos que saben dónde hacer clic.

Lo que está cambiando ahora no es cosmético. Es estructural. El agente de IA no navega interfaces. Llama funciones. No necesita un botón: necesita un endpoint, una herramienta, un contrato explícito. Y cuando el software no tiene ese contrato, el agente improvisa — con resultados que van de aceptables a desastrosos.

La convergencia de 2024-2025: MCP, Operator, y la carrera por la interfaz de agentes

En noviembre de 2024, Anthropic publicó la especificación del Model Context Protocol. No fue el primer intento de estandarizar cómo los LLMs interactúan con herramientas externas — OpenAI ya tenía plugins, y antes de eso había docenas de frameworks propietarios. Pero MCP fue el primero en ganar tracción real como estándar abierto.

La razón es simple: la especificación es limpia, el ecosistema de clientes compatibles creció rápido (Claude Desktop, Claude Code, Cursor, Cline, y decenas más), y el modelo de servidor MCP es suficientemente simple para que cualquier equipo de ingeniería lo implemente en días. Hoy hay cientos de servidores MCP públicos — para bases de datos, para APIs de terceros, para herramientas de desarrollo, para plataformas de negocio.

Casi simultáneamente, OpenAI lanzó Operator: un agente que opera browsers de forma autónoma, diseñado para completar tareas en interfaces web que no tienen API. Google anunció Agent Builder dentro de su plataforma Vertex. El mensaje del mercado fue coherente: los próximos dos años van a redefinir quién (o qué) es el usuario principal del software.

En el mundo del desarrollo, la señal fue igual de clara. Devin, de Cognition Labs, demostró que un agente puede operar un entorno de desarrollo completo — leer código, escribir tests, hacer commits, abrir pull requests — con supervisión mínima. Cursor evolucionó de ser un editor con autocompletado inteligente a tener un modo agente que puede ejecutar plans de múltiples pasos. Claude Code opera terminales, edita archivos, corre tests. Cline, de código abierto, hace lo mismo con cualquier modelo compatible.

Todos estos sistemas comparten una característica: funcionan mejor cuando el entorno fue diseñado para ser operado por agentes. Y funcionan peor — a veces mucho peor — cuando tienen que improvisar sobre interfaces diseñadas para humanos.

Computer-use: el puente que todos usan y nadie quiere

Frente al gap entre lo que los agentes necesitan (APIs tipadas, contratos explícitos) y lo que el software empresarial tiene (interfaces web optimizadas para humanos), la solución provisional es computer-use.

Computer-use es la capacidad de un modelo de ver screenshots de una pantalla y emitir comandos de mouse y teclado. Claude tiene esta capacidad. GPT-4o también. La industria la llama de distintas formas — "GUI agent", "browser automation con LLM", "visual agent" — pero el principio es el mismo: el modelo mira la pantalla como un humano y actúa como un humano.

El atractivo es obvio. Si el agente puede operar cualquier interfaz visual, no importa que el software no tenga API. El agente puede llenar el formulario de configuración del impuesto, navegar el wizard de setup del gateway de pagos, ajustar los sliders de la campaña de ads. Sin cambios en el software subyacente.

El costo también es obvio para quien lo usa en producción. Cada ciclo de percepción-decisión-acción requiere procesar una imagen. En modelos de frontera, una imagen cuesta entre 5 y 20 veces más tokens que el texto equivalente. Una tarea que via API tipada costaría centavos puede costar dólares via computer-use. Para una operación aislada está bien. Para un agente que opera continuamente un negocio, el costo escala rápido.

La fragilidad es el otro límite. Un agente que navega una interfaz web tiene un modelo mental de esa interfaz construido en su contexto. Cuando la interfaz cambia — y todas cambian, con actualizaciones frecuentes — el agente puede fallar silenciosamente, haciendo clic en lo que ya no está donde estaba, o interpretando mal un nuevo elemento de UI. Las herramientas tipadas tienen versionado explícito; las interfaces visuales, no.

Computer-use es el puente mientras el software aprende a hablar con agentes. Pero construir sobre ese puente como si fuera infraestructura permanente es un error.

Lo que todavía no funciona bien

Con toda la cobertura entusiasta de 2025 y 2026, vale la pena ser honesto sobre los límites actuales de los agentes en producción.

La confiabilidad en tareas largas sigue siendo el problema principal. Un agente que completa el 95% de una tarea de 20 pasos tiene un error esperado en cada ejecución. Para tareas cortas y bien definidas, los agentes actuales son notablemente confiables. Para flujos complejos de múltiples horas — auditar una campaña de ads, migrar configuración entre plataformas, gestionar un lanzamiento de producto de punta a punta — la tasa de error acumulada sigue siendo demasiado alta para dejarlos operar sin supervisión humana.

La gestión de credenciales y permisos es un problema no resuelto. Un agente que opera herramientas necesita acceso a APIs, tokens, secrets. El modelo de seguridad para eso está en construcción — hay propuestas, hay implementaciones parciales, pero no hay un estándar ampliamente adoptado. Esto genera tensión entre "el agente necesita acceso para operar" y "darle acceso al agente es un riesgo de seguridad".

El debugging de lo que hizo el agente es difícil. Cuando un humano hace algo mal en un dashboard, podés ver el historial de clics, los logs de la aplicación, el estado antes y después. Cuando un agente falla a mitad de un flujo complejo, reconstruir qué pasó requiere logs estructurados que muchos frameworks de agentes todavía no ofrecen de forma nativa.

Nada de esto invalida la dirección. Son problemas de ingeniería con soluciones en progreso, no límites fundamentales. Pero vale nombrarlos porque el ciclo de hype actual tiende a ocultarlos.

El factor LATAM: cuando el costo del tiempo es diferente

Hay una dimensión de esta transición que la cobertura anglosajona suele pasar por alto: el cálculo costo-beneficio de adoptar software operado por agentes es completamente diferente en Buenos Aires, Bogotá o Santiago que en San Francisco.

En Silicon Valley, el costo de un ingeniero de software senior es de $200,000-$300,000 dólares anuales. En ese contexto, si un agente cuesta $500/mes en tokens pero elimina la necesidad de alguien configurando dashboards manualmente, el ROI es inmediato e inobjetable.

En Argentina, con salarios tech de $2,000-$5,000 dólares mensuales (incluso en las startups mejor pagadas), el cálculo es diferente. No porque el tiempo valga menos — vale lo mismo, y en muchos casos hay menos gente para distribuir ese tiempo — sino porque el margen de error económico es más ajustado. Una startup en Palermo que gasta $300/mes en tokens de agentes tiene que justificar eso contra lo que podría hacer con esos $300.

La respuesta, en muchos casos, es que sí tiene sentido — precisamente porque en LATAM el problema no es el costo del tiempo técnico sino la escasez de ese tiempo. Una persona sola que maneja producto, operaciones y marketing de una tienda online no tiene las horas para aprender y operar cuatro plataformas distintas. Un agente que opera esas plataformas por ella — a $30-$100/mes en costos de API, que es el rango real para uso moderado — libera tiempo que vale mucho más.

El punto es que el análisis correcto para LATAM no es "copiar el caso de uso de San Francisco" sino entender la estructura local del problema. Y en esa estructura, la delegación a agentes puede ser más transformadora que en mercados donde el tiempo técnico es más abundante.

El trabajador tech en la era de la delegación

La pregunta que le preocupa a mucha gente — y con razón — es qué pasa con el trabajo humano cuando los agentes empiezan a operar el software de negocios.

La respuesta honesta es que algunas categorías de trabajo van a cambiar profundamente. El analista que pasaba el 60% de su tiempo extrayendo datos de dashboards y el 40% interpretándolos va a pasar el 10% extrayendo datos (con herramientas de agente) y el 90% interpretando. El desarrollador que configuraba integraciones manualmente va a supervisar agentes que hacen esa configuración. El community manager que publicaba contenido en cinco plataformas va a definir la estrategia y aprobar lo que los agentes ejecutan.

Lo que es menos claro — y donde el optimismo de Silicon Valley choca con la realidad de mercados laborales más complejos — es qué pasa con los trabajadores cuya habilidad principal era precisamente operar el software. El asistente administrativo que sabe Salesforce mejor que nadie. El especialista en operaciones que domina el dashboard de WooCommerce. Esas habilidades van a depreciarse, y más rápido de lo que muchos anticipan.

Para el trabajador tech en LATAM, la estrategia más robusta en este contexto es la misma que siempre fue útil en transiciones tecnológicas: subir en la cadena de abstracción. Entender qué quieren los agentes (contratos explícitos, APIs bien definidas, herramientas tipadas) es una habilidad que vale en 2026 y va a seguir valiendo. Saber evaluar cuándo un agente está fallando y por qué es una habilidad que los equipos técnicos necesitan ahora mismo. Diseñar los flujos que los agentes van a ejecutar — qué herramientas exponer, cómo estructurar los datos, dónde poner los puntos de aprobación humana — es trabajo de alto valor que no se delega fácilmente.

Las plataformas que van a sobrevivir la transición

Hay una pregunta de estrategia empresarial implícita en todo esto: ¿qué SaaS va a ser relevante en cinco años?

La hipótesis que vale considerar: las plataformas que van a mantener su posición son las que traten a los agentes como ciudadanos de primera clase, no como integraciones de terceros. Eso no significa necesariamente reescribir todo desde cero — significa exponer suficiente funcionalidad via contratos bien diseñados para que un agente pueda operar la parte que importa sin recurrir a computer-use.

Salesforce ya está en este camino con Einstein Copilot y herramientas de agente nativas. Notion tiene una API relativamente completa. Linear, el tracker de issues favorito de los equipos técnicos modernos, tiene una API GraphQL que es suficientemente expresiva para que los agentes la usen bien. HubSpot ha expandido sus capacidades de API en los últimos 18 meses en parte por esta presión.

En el ecommerce, algunas plataformas nacidas en este contexto — Wafle es un ejemplo regional — están construyendo la capa de agente como la interfaz primaria desde el principio, lo que les da una ventaja arquitectónica que las plataformas maduras van a tardar años en replicar.

La pregunta para cualquier equipo evaluando herramientas en 2026 debería incluir: ¿qué porcentaje de las operaciones que necesito hacer están disponibles via API tipada? ¿Hay un MCP server? Si hay un MCP server, ¿cubre el 30% o el 90% de los flujos? ¿Qué pasa cuando el agente llega al borde de lo que el servidor soporta?

Lo que todavía no sabemos

Hay partes de esta transición que no están escritas todavía, y que cualquier predicción honesta tiene que reconocer como inciertas.

No sabemos qué modelo de precios va a dominar el software operado por agentes. ¿Por seat, como el SaaS actual? ¿Por operación ejecutada? ¿Por resultado de negocio? La economía del software va a necesitar reinventarse cuando el "usuario" es un agente que ejecuta mil operaciones por hora en lugar de un humano que ejecuta veinte por día.

No sabemos cómo van a evolucionar los marcos regulatorios. Los agentes que operan sistemas fiscales, de pagos, o de salud tienen implicaciones legales que los reguladores apenas están empezando a procesar. En Argentina, por ejemplo, la interacción entre un agente autónomo y el sistema de facturación AFIP abre preguntas sobre responsabilidad que no tienen respuesta clara hoy.

No sabemos si la confiabilidad de los agentes va a escalar lo suficientemente rápido para que la supervisión humana pueda reducirse al ritmo que los optimistas predicen. Los modelos mejoran, pero los flujos de negocios también se vuelven más complejos a medida que más se delega.

La pregunta correcta

Hay una tendencia a enmarcar esta transición como "los agentes van a reemplazar a los humanos en X". Ese framing es impreciso y lleva a debates improductivos.

La pregunta más útil es diferente: ¿nuestras herramientas van a estar listas cuando los agentes lleguen a usarlas?

Porque los agentes ya llegaron. Claude Code existe. Cursor en modo agente existe. Los workflows automáticos de n8n con LLM nodes existen. Las empresas que están adoptando estas herramientas no están esperando a que "la IA madure": están usando lo que hay ahora, con sus limitaciones actuales, y obteniendo ventajas reales sobre las que no lo hacen.

La brecha no es entre "los que usan IA" y "los que no". Es entre las organizaciones cuyo software tiene contratos explícitos para agentes y las que no. Entre los equipos que saben cómo supervisar un agente cuando falla y los que no tienen esa habilidad. Entre las plataformas que fueron diseñadas para ser operadas por agentes y las que tienen un MCP server pegado como afterthought.

Esa brecha se va a ensanchar en los próximos dos o tres años. Y la geografía no protege de ella — ni para bien ni para mal. Un emprendedor en Montevideo que adopta estas herramientas ahora tiene acceso a las mismas capacidades que uno en Nueva York. La cancha se nivela para los que se mueven rápido, sin importar el código postal.

El futuro de la computación es delegación. Todavía no estamos del todo preparados para vivir ahí. Pero la distancia entre "no preparados" y "preparados" se cierra mes a mes, y la dirección ya no está en duda.