Anthropic ha encendido el debate sobre la programación autónoma al presentar Claude Sonnet 4.5 con un ejemplo tan simple de entender como difícil de replicar: un agente que estuvo 30 horas seguidas generando unas 11.000 líneas de código para “clonar” una aplicación tipo Slack/Teams y que detuvo su ejecución al “completar” la tarea. El hito multiplica por más de cuatro las 7 horas que, en mayo, se atribuyeron a Opus 4. Para la compañía, el mensaje es claro: Sonnet 4.5 sería “el mejor modelo del mundo para agentes reales, programación y uso de ordenadores”.
El anuncio llega en medio de una batalla de fondo entre Anthropic, OpenAI y Google por ganar el mercado empresarial de agentes autónomos: asistentes que navegan, operan un PC, orquestan herramientas y escriben código durante horas sin supervisión. El premio es enorme —licencias, servicios y datos—, y la carrera se libra a base de demos públicas y, cada vez más, de infraestructura alrededor de los modelos.
Lo que trae Claude Sonnet 4.5 (más allá del titular)
Anthropic no solo actualiza el modelo: intenta entregar una pila para agentes. Junto al lanzamiento, habilita máquinas virtuales, memoria, gestión de contexto y soporte multiagente. En palabras de la empresa, son los “bloques” que usan internamente en Claude Code y que ahora empaqueta para que desarrolladores creen sus propios agentes “de última generación”. La apuesta sigue la misma dirección que están tomando OpenAI (herramientas, computer control, integraciones) y Google (Gemini + control de apps/dispositivo, workbenches), con una conclusión compartida: un modelo por sí solo no es un agente.
En The Verge, Scott White (product lead) describió a Sonnet 4.5 como un asistente capaz de operar a “nivel jefe de gabinete”: coordinar calendarios, mirar paneles de datos, extraer insights y redactar actualizaciones de estado. Dianne Penn (product management) insistió en que es “más de tres veces” mejor en uso de ordenador que la versión de octubre: navegar, escribir formularios, copiar/pegar, automatizar flujos. Canva, como beta-tester, aseguró que ha ayudado con tareas complejas de largo contexto, desde ingeniería en su repositorio a features de producto e investigación.
…y lo que ven los programadores en el día a día
En paralelo a los anuncios, muchos desarrolladores experimentan una realidad más prosaica. Como sintetizó Miguel Ángel Durán (@midudev): “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”. Varias pruebas apuntan al mismo patrón: estructuras impecables, nomenclatura de manual, capas bien separadas… y fallos a la hora de compilar, testear o poner en marcha el sistema sin intervención humana.
No es un capricho: entregar software exige más que generar archivos. Hace falta cerrar la integración (autenticación, permisos, estados, persistencia, webhooks), gestionar dependencias y entornos (runtimes, package managers, build systems), y pasar pruebas end-to-end (no solo happy paths). Los modelos actuales escriben cada vez mejor, pero fallan con demasiada frecuencia al entregar un conjunto coherente que funcione de verdad y sin tocar.
Por qué persiste la brecha “código bonito vs software que funciona”
- Complejidad invisible. Un Slack no es solo una UI: hay eventos, synch, permiso granular, cachés, migraciones, observabilidad… El agente tiende a sobre-arquitecturar y subestimar detalles de integración.
- Entornos y reproducciones. Falta disciplina de entorno: versiones exactas, scripts de build/run, seed data, configuración de CI, Dockerfiles robustos.
- Tests significativos. Generar tests no es lo mismo que pasar tests que merezcan la pena. Los happy paths abundan; los casos límite no tanto.
- Planificación y coherencia. Sin una estrategia de paquetes y contratos entre módulos, un refactor masivo deja inconsistencias sutiles que rompen el producto.
Lo que sí es un paso adelante
Aun así, hay progresos reales. Que un agente pueda mantener contexto durante horas, volver a sus propios archivos y revisar decisiones previas, automatizar tareas de “sudor digital” (recopilar perfiles en LinkedIn, preparar hojas de cálculo, redactar briefings) y operar un navegador con fiabilidad mejora la productividad. Y la pila añadida —VMs, memoria persistente, gestión de contexto, multiagente— reconoce explícitamente el talón de Aquiles: el modelo puro no basta; hacen falta mecanismos de estado, herramientas y control para simular algo parecido a un “sistema operativo” de agentes.
Cómo evaluar utilidad sin comerse el hype
Para equipos de ingeniería
- Acotar tareas: pedir piezas cerradas (CRUDs, migrations, parsers, telemetry básica) y evaluar con tests reales en CI.
- Reproducibilidad obligatoria: scripts (Makefile/NPX/Poetry), versiones fijas y README con pasos exactos para build/run.
- Métricas de entrega: tiempo a build verde, bugs por diff, tiempo a PR aprobado.
- Entorno controlado: containers y linters para frenar el “refactor por deporte”.
Para producto/negocio
- Casos con retorno: slides, dashboards, resúmenes de reuniones, informes, clasificaciones.
- Humano en el bucle (HITL): el agente propone, alguien valida.
- Horas ahorradas: cuantificar semanalmente tiempo y calidad percibida.
El contexto de industria: “runtime de agente” vs “tamaño de modelo”
La carrera no es solo por el modelo más grande. OpenAI, Google y Anthropic se están moviendo hacia entornos de ejecución que proporcionen memoria de trabajo, planificación, herramientas (navegador, terminal, editor), reintentos y seguridad (permisos y sandboxes). El ganador no será quien recite mejor, sino quien entregue flujos reproducibles y útiles sin pedirle a un humano que reconstruya todo al final.
Un checklist de señales “serias” para seguir el progreso
- Repos reproducibles: infra as code, Dockerfiles, seed data, CI público.
- Benchmarks de entrega: medir tiempo-to-green y MTBF (mean time between failures) tras el primer despliegue.
- Integraciones reales: OAuth, webhooks, colas (Kafka/Rabbit), Postgres/Redis, observabilidad (OpenTelemetry).
- Economía unitaria: que el coste de cómputo del agente no supere el valor del trabajo automatizado.
¿Cuándo veremos agentes que “programan solos” de verdad?
No hay fecha. Es probable que el camino pase por modelos menos monolíticos y más compuestos (modelos medianos + RAG + tools), silicio ajustado al trabajo (GPU + NPUs/ASICs) y, sobre todo, runtimes de agente que abran menos frentes de incertidumbre. Mientras tanto, la manera realista de extraer valor de Claude Sonnet 4.5 (o de sus rivales) es tratarlo como acelerador: quitar trabajo repetitivo, sembrar código y documentación con calidad aceptable, y automatizar tareas con bajo riesgo. La “IA que entrega sola” —sin un ingeniero cerrando— aún no está aquí.
Conclusión
El experimento de 30 horas y 11.000 líneas coloca a Claude Sonnet 4.5 donde Anthropic quería: en el centro del debate sobre agentes autónomos. Al mismo tiempo, la experiencia de los equipos recuerda que escribir código bonito y entregar software siguen siendo dos oficios distintos. Lo positivo es que el oficio de agente —memoria, herramientas, contexto, multiagent— mejora. Lo prudente es aterrizar promesas en pruebas medibles, con reproducibilidad y benchmarks de entrega. Hasta entonces, más que programadores que se van de vacaciones mientras el agente “clona” un Slack, tendremos parejas de trabajo: IA que prepara y humanos que encienden.
Preguntas frecuentes
¿Claude Sonnet 4.5 puede construir aplicaciones complejas sin ayuda?
Puede generar grandes bases de código y mantener contexto durante horas. En la práctica, entregar una app compleja suele requerir un ingeniero para cerrar integraciones, entornos y pruebas.
¿Qué diferencias reales aporta respecto a versiones anteriores?
Según Anthropic, es 3× mejor en uso del ordenador y llega con pila de agente (VMs, memoria, gestión de contexto, multiagente) para tareas de largo contexto. Beta-testers (p. ej., Canva) reportan mejoras en automatizaciones complejas.
¿Por qué el código “de libro” a veces no compila ni corre?
Los LLM imitan estructura y estilo, pero fallan en contratos entre módulos, dependencias, entornos y tests significativos. Sin reproducibilidad y CI, el salto de parecer a funcionar es frágil.
¿Cómo aprovecharlo hoy sin riesgo?
Acota tareas (CRUD, migrations, parsers), exige scripts y versiones fijadas, integra CI con tests reales y mide €/resultado (tiempo ahorrado, lead time, bugs evitados). Usa el agente como copiloto ejecutor, no como equipo completo.
