La carrera por los agentes autónomos —esas IAs que no solo “responden”, sino que navegan, programan, orquestan tareas y “usan” el ordenador sin supervisión— sumó un nuevo episodio: Anthropic presentó Claude Sonnet 4.5 y aseguró que el modelo trabajó 30 horas seguidas para construir una app tipo Slack/Teams, generando unas 11.000 líneas de código y deteniéndose solo al “completar la tarea”. Es un salto notable respecto a mayo, cuando su modelo Opus 4 fue noticia por operar siete horas de forma continua. La compañía lo promociona sin matices: “el mejor modelo del mundo para agentes reales, programación y uso de ordenadores”.
La promesa es ambiciosa y estratégica. OpenAI, Google y Anthropic compiten por licencias empresariales que moverán miles de millones: quien convenza a los equipos técnicos de que su agente programa y automatiza con fiabilidad ganará contratos, datos y una posición dominante. Pero, como casi siempre en IA, la letra grande convive con asteriscos. Desarrolladores que han probado el modelo describen una realidad más matizada: código impecablemente estructurado… que no compila o no corre sin intervención humana intensiva.
Lo que dice Anthropic (y por qué importa)
En declaraciones a The Verge, Scott White, responsable de producto de Claude.ai, elevó el listón de expectativas: el modelo opera a “nivel jefe de gabinete”—coordina agendas entre varias personas, mira un panel de datos y redacta un informe con insights, prepara status updates a partir de one-on-ones. Y llegó con infraestructura “para construir agentes”: máquinas virtuales, memoria, gestión de contexto y soporte multiagente, los bloques con los que funciona Claude Code y que la empresa quiere poner en manos de terceros.
Dianne Penn, head of product management, contó que Claude Sonnet 4.5 es “más de tres veces” mejor en uso del ordenador que la versión de octubre (navegar, abrir apps, copiar/pegar, automatizar clicks). Dice usarlo para cribar perfiles en LinkedIn y generar hojas de cálculo con candidatos; Canva, beta-tester, aseguró que ayuda con tareas complejas de largo contexto, desde engineering en su repositorio a features en producto e investigación. El objetivo es claro: paquetizar la capacidad de “usar un PC” y programar durante horas sin supervisión.
…y lo que ven los programadores
En paralelo, la comunidad técnica describió un patrón familiar. Miguel Ángel Durán (@midudev) lo sintetizó con ironía: “Claude Sonnet 4.5 refactorizó todo mi proyecto en un prompt. 20 minutos pensando. 14 archivos nuevos. 1.500 líneas modificadas. Arquitectura limpia. Nada funcionaba. Pero qué bonito fue”. Otros desarrolladores reportan lo mismo: miles de líneas de código con estructura profesional, nombres perfectos, capas y tests… que fallan al compilar o colapsan en ejecución por errores sutiles, dependencias mal resueltas o contratos incoherentes entre módulos.
Esa brecha—“código bonito” vs “software que funciona”—no es nueva. Desde 2023, los modelos han mejorado al parecer programadores: redactan README exhaustivos, imitan patrones y estilos de equipo, cuentan historias elegantes en commits. Pero entregar un Slack operativo sin ingeniero de cierre sigue siendo otra liga: faltan detalles de integración, configuraciones y pruebas que separan un repositorio bonito de un producto usables.
Más aún: Anthropic no ha mostrado públicamente la aplicación corriendo end-to-end, ni ha publicado el código para verificación independiente. Ed Zitron (consultor y analista crítico con el hype) lo resume: una cosa es comunicar “lo ha construido” y otra demostrar “esto funciona”. Hasta que no se ve demo verificable (o un repo reproducible), la afirmación se queda a medias.
¿Por qué cuesta tanto pasar del “parece” al “funciona”?
1) Fricción invisible. Un Slack no es solo UI y mensajes. Es autenticación, permisos, sincronía, eventos, persistencia, cacheo, APIs que se comportan, estados que no se corrompen, migraciones y observabilidad. Los LLM pueden escribir piezas, pero el ajuste fino —ese 20 % que lleva 80 % del tiempo— sigue necesitando criterio humano.
2) Entorno y dependencias. Herramientas, versiones, runtimes, package managers, build systems, linters. Los agentes no dominan aún la disciplina de entorno para reproducir el mismo resultado en frío, sin sorpresas.
3) Pruebas de verdad (e2e). Generar tests no es lo mismo que pasar tests significativos. Muchos conjuntos generados repiten el happy path; cuando aparece la realidad, el castillo se cae.
4) Planificación. Un agente que escribe mientras “piensa” tiende a sobre-arquitecturar (capas para todo) y a sobrerrefactorizar, lo que introduce inconsistencias. A veces la solución de 500 líneas “feas” funciona, y la de 5.000 “perfectas” no.
¿Entonces, es puro humo? No del todo
Las mejoras existen y cuentan. Que un agente pueda mantener contexto durante horas, volver sobre archivos escritos por él mismo, modificar su propio diseño y crear scripts de build y deploy acerca un objetivo real: reducir trabajo mecánico y elevar al humano a arquitecto/validador. Y la infra que Anthropic pone alrededor —VMs, memoria/“notes” persistentes, gestión de contexto, multiagente— reconoce el problema de base: el modelo por sí solo no basta; hacen falta bloques de sistema que le permitan recordar, planificar, reintentar y coordinar tareas.
El “mejor del mundo en uso del ordenador” es una hipérbole de marketing, pero es cierto que Computer Use (clics, formularios, navegación) ha mejorado mucho en los últimos 12 meses, y eso habilita automatizaciones útiles (sourcing en LinkedIn, capturas de datos, hojas de cálculo) que ya devuelven valor —aunque estén lejos de “construye un Slack y me voy a dormir”.
Cómo probar la utilidad (y no caer en el hype)
Para equipos de software
- Acota el problema: pide tareas cerradas (generar migrations, componer API de un CRUD, escribir un parser robusto, añadir telemetry básica) y evalúa con diffs y tests reales.
- Exige reproducibilidad: el agente debe dejar scripts (Makefile/NPX/Poetry), versiones fijas y un README con pasos exactos para build/run.
- Integra linters y CI: si los jobs no pasan en CI, el “parece pro” no vale.
- Mide tiempo ahorrado: lead time por issue, bugs por cambio, tiempo a PR aprobado.
Para negocio
- Selecciona casos de “sudor digital”: slides, dashboards, briefings, resúmenes de reuniones, búsqueda y clasificación de información.
- Pon un “humano en el bucle” (HITL): el agente propone; alguien aprueba.
- Cuantifica: horas ahorradas por semana, tiempo de respuesta a peticiones ad-hoc, calidad percibida por usuarios internos.
Tendencia de fondo: los agentes necesitan “sistema operativo”
La industria converge: OpenAI (con herramientas/“computer control” y Pulse orientado a rutinas), Google (Gemini + App/Device Control/Workbench) y Anthropic (Claude + VMs/memory/context/multi-agent) reconocen que un modelo no es un agente. Hace falta una pila: memoria a largo plazo, planificador, herramientas externas (terminal, navegador, editor), control de errores/reintentos y seguridad (permisos, sandboxes, límites). El debate ya no es “¿quién tiene el modelo más grande?”, sino “quién tiene el mejor runtime de agente” para que la IA no se pierda a los 20 minutos.
Marketing vs. realidad técnica: ¿cuándo llega la “IA que entrega”?
La pregunta clave sigue en el aire: ¿cuándo veremos una IA que genere software funcional por sí sola, sin un ingeniero cerrando los flecos? No hay fecha, pero hay señales a observar:
- Repos reproducibles: repos con scripts (infra as code), Dockerfiles, seed data y pipelines que cualquiera puede levantar.
- Benchmarks de “entrega”: más allá de evaluar estilo o tests sintéticos, medir tiempo-to-green (de prompt a build verde) y MTBF (cuánto aguanta en producción sin caerse).
- Menos toy apps, más integraciones: webhooks, OAuth, filas (Kafka/Rabbit), DB reales (Postgres/Redis) y observabilidad (OpenTelemetry) integradas por el agente.
- Economía unitaria: que el coste de cómputo del agente no supere el valor del trabajo automatizado.
Hasta que eso ocurra, lo prudente es tratar a Claude Sonnet 4.5 (y a sus pares) como aceleradores capaces de quitar trabajo mecánico, generar borradores sólidos y automatizar tareas de bajo/medio riesgo, no como reemplazos de equipos que entregan productos en producción.
Conclusión
La demostración de Anthropic —“30 horas, 11.000 líneas, un Slack”— golpea donde duele: demostrar agencia real. Pero el salto de “parece software” a “es producto” aún exige ingeniería humana. La buena noticia es que la pila de agente (VMs, memoria, contexto, multiagente) mejora y que las automatizaciones útiles ya están disponibles. La menos buena es que, con o sin Claude 4.5, sigue siendo fácil escribir bonito y difícil entregar.
Para equipos de IA y software, la consigna es doble: pilotar con casos acotados y medibles y exigir pruebas verificables antes de comerse titulares. El resto es (buen) marketing.
Preguntas frecuentes
¿De verdad Claude Sonnet 4.5 programó un “Slack” en 30 horas?
Anthropic afirma que el modelo corrió 30 horas, generó ~11.000 líneas y detuvo la ejecución al “completar la tarea”. No ha publicado código ni una demo operativa verificable. La comunidad pide pruebas reproducibles.
¿En qué mejora 4.5 frente a versiones anteriores?
Según Anthropic, es 3× mejor en uso de ordenador que la versión de octubre y llega con infra de agente: VMs, memoria, gestión de contexto y multiagente. Beta-testers (p. ej., Canva) reportan ayuda en tareas de largo contexto.
¿Por qué muchos dicen que el código “no funciona”?
Los LLM imitan estructura y estilo, pero fallan en integración, entornos y detalles (e2e). Es habitual ver refactors masivos y arquitecturas “limpias” que no compilan o rompen en ejecución sin cierre humano.
¿Cómo sacar provecho hoy sin comerse el humo?
Acota tareas (CRUD, migrations, parsers), exige reproducibilidad (scripts, versiones), integra CI y tests reales, y mide €/resultado (tiempo ahorrado, lead time, bugs evitados). Trata al agente como copiloto ejecutor, no como equipo completo.
Más referencias: Xataka
