Radar de Thoughtworks: qué puede adoptar ya tu equipo con agentes

Son las seis y media de la tarde. Alguien de tu equipo tiene una funcionalidad entera bien especificada y podría dejársela a un agente de código hasta mañana. No lo hace, porque a las nueve de la mañana nadie sabría decir si lo que ha hecho el agente se puede integrar.

El Technology Radar 35 de Thoughtworks, publicado este mes, pone esa noche en el anillo Trial y, a su alrededor, la lista de lo que hace falta para fiarse del resultado. Casi nada de esa lista es una herramienta nueva.

Hemos leído el volumen entero, las 117 entradas, y nos hemos quedado con lo que está en Adopt y en Trial y afecta a un equipo que desarrolla con agentes. Lo hemos ordenado por las preguntas que se hace ese equipo.

Cómo se lee el Radar

El Radar lo elabora el Technology Advisory Board de Thoughtworks, 18 tecnólogos sénior que se reúnen dos veces al año; esta edición sale de su encuentro de septiembre de 2026 en Recife (Brasil). Cada entrada, que ellos llaman blip, cae en uno de cuatro anillos:

• Adopt: creen que el sector debería adoptarlo y lo usan en sus proyectos cuando encaja.
• Trial: vale la pena; las empresas pueden probarlo en un proyecto que aguante el riesgo.
• Assess: conviene explorarlo para entender cómo te afecta.
• Caution: hay que ir con cuidado, porque tiene problemas serios.

Según nuestro recuento, en este volumen Adopt tiene 11 entradas y Trial, 49. Y de lo que hay dentro: de las seis técnicas en Adopt, cinco las justifica el propio Radar por la llegada de los agentes o de la IA generativa (aislar al agente, el mutation testing, mapear el camino a producción, dar el contexto por partes y el modelado de amenazas); la sexta es la criptografía poscuántica. Entre las herramientas, OpenAI Codex pasa a Adopt y, según el texto, se suma a Claude Code y OpenCode como agentes de terminal que sus equipos usan a diario.

Con tres agentes de código citados como herramienta de uso diario, elegir agente ya no distingue a un equipo de otro. Lo que el Radar sube de anillo es lo que rodea al agente, y le dedica uno de sus cuatro temas, harness engineering at scale: el harness es todo lo que se construye alrededor del agente, de la memoria y el contexto a los bucles de corrección y los límites, y el Radar lo describe como «un activo vivo» que necesita dueño y mantenimiento.

Antes de que el agente escriba: especificar sin enterrarlo en Markdown

OpenSpec, un marco ligero de Spec-Driven Development (SDD, desarrollo guiado por especificaciones) que funciona con cualquier agente, pasa de Assess a Trial. Según el Radar, varios equipos de Thoughtworks lo han usado con éxito, también sobre código existente, y cuentan que el agente produce resultados más previsibles y menos cambios no pedidos que cuando se le da solo un prompt. Lo que destacan es que cada cambio se escribe como una diferencia sobre una especificación persistente, que sigue siendo la referencia actual del sistema.

En el mismo anillo hay dos técnicas para la conversación previa. Con el grilling, el agente te entrevista sobre el plan antes de actuar, para no adivinar donde tu intención no está clara; el Radar añade que te obliga a revisar tus propias suposiciones y deja decisiones que se pueden registrar. Con los planes visuales interactivos, el agente prepara un plan en HTML con diagramas y bocetos de pantallas que el equipo recorre antes de implementar; sus equipos avisan de no convertirlo en un gran diseño previo y de trabajar en pasos pequeños y comprobables.

El contrapeso está en Caution: AI-driven documentation sprawl, la documentación que los agentes generan en grandes cantidades y que nadie poda. El Radar cita Spec Kit y BMAD como herramientas con las que pasa, habla de una «gran bola de barro de documentación» y avisa de que las especificaciones obsoletas o contradictorias consumen contexto y desvían al agente. Su recomendación es tratar el Markdown como un artefacto de primera clase y dedicar esfuerzo humano deliberado a podarlo.

Nuestra lectura es que el Radar separa las dos entradas por el mantenimiento: una especificación que nadie actualiza acaba siendo ruido que el agente lee como si fuera cierto. Al propio OpenSpec el Radar le pide disciplina para mantener la especificación persistente.

Es también lo que veo con los equipos con los que trabajamos. Siempre les explico que los alineamos con OpenSpec porque nuestra forma de trabajar ya sigue ese mismo enfoque, pero que herramientas como Spec Kit hoy no se ajustan a las necesidades de su proyecto, porque traen skills y plantillas demasiado genéricas.

El contexto: menos instrucciones, cargadas cuando hacen falta

Progressive context disclosure sube a Adopt porque, según el Radar, ya es casi universal en las aplicaciones serias: el agente arranca con lo esencial y carga el resto cuando lo necesita. En código, eso es un AGENTS.md corto con enlaces a documentación que el agente consulta si le hace falta, y skills y herramientas que no ocupan contexto hasta que se usan.

La entrada de Caution que lo acompaña es agent instruction bloat: las instrucciones crecen, cada regla parece útil por separado y con el tiempo el conjunto se alarga y se contradice. El Radar propone convertir en comprobaciones automáticas todo lo que se pueda y revisar las instrucciones con cada modelo nuevo para borrar las que ya no necesita. Como ejemplo, cuenta que Anthropic quitó más del 80 % del prompt de sistema de Claude Code para sus últimos modelos sin una pérdida medible. Qué conviene dejar en ese archivo lo hemos tratado aparte (CLAUDE.md y AGENTS.md: qué dejar en el archivo del agente).

Tres entradas de Trial van en la misma dirección. Los subagentes para gestionar el contexto hacen la exploración y los reintentos fuera de la sesión principal y le devuelven solo lo esencial; el Radar sugiere dos a cuatro a la vez y reconoce que su beneficio aún no se ha medido de forma sistemática. Las bases de conocimiento mantenidas por agentes guardan el conocimiento del equipo en archivos de texto enlazados que un agente mantiene al día, con el riesgo de que se alejen de la realidad si ninguna persona las revisa. Y anclar los agentes a una aplicación de referencia les permite consultar en el momento las convenciones vigentes de la plataforma, que cambian más deprisa que cualquier plantilla.

En Caution queda también agent skill cognitive surrender: importar bibliotecas enteras de skills de la comunidad sin entender qué hacen. El Radar pone en Trial una de esas bibliotecas, mattpocock/skills, precisamente porque son skills pequeñas y fáciles de adaptar, y pide leer cada skill antes de usarla y preferir las que el equipo escribe para su propio dominio.

La comprobación: dónde mira una persona y dónde mira una máquina

Con más agentes trabajando, el Radar ve el cuello de botella en la capacidad de revisión y en el camino a producción. Su respuesta en Trial es risk-tiered human oversight: los cambios más arriesgados o difíciles de deshacer los aplica una persona, los intermedios pasan por revisión humana y los de bajo riesgo los puede integrar el agente a través de la integración continua. Para clasificarlos propone dos vías, zonas del código que exigen más revisión y una clasificación del cambio con un modelo de lenguaje, que el Radar califica de falible, y menciona el proceso que ha publicado Meta.

La alternativa, revisarlo todo con la misma intensidad, el Radar la pone en Caution con nombre propio: human-in-the-loop theater, la persona que aprueba cambios que no puede evaluar de verdad y convierte la aprobación en un sitio donde nadie es responsable de la decisión. Para lo que no revise una persona, propone vigilar el sistema con comprobaciones: mutation testing, tests basados en propiedades, modelos formales y revisión semántica asistida por agentes.

El mutation testing está en Adopt por un motivo muy concreto: el agente genera muchos tests, la cobertura de código es fácil de inflar con tests superficiales y el mutation testing introduce pequeños fallos a propósito para ver si algún test los detecta. El Radar añade que el propio agente puede hacerlo dentro de su bucle, y aconseja limitarlo a los paquetes que importan o al código cambiado, porque tarda.

El otro Adopt de esta parte es path-to-production mapping, una práctica de siempre en Thoughtworks que, según el Radar, vuelve a ser relevante: si el agente escribe más código, los atascos aparecen en otro punto del camino. Es un taller con todas las personas que diseñan, desarrollan, despliegan y operan el software: primero se escriben en una pizarra los pasos, del puesto del desarrollador hasta producción, y en una segunda vuelta, los puntos de dolor.

Dos herramientas en Trial sirven para que el agente reciba sus propios errores antes que una persona: Act, que ejecuta en local los flujos de GitHub Actions para que el agente pruebe la integración continua antes de subir, y ast-grep, cuyas reglas estructurales un equipo de Thoughtworks usa para comprobar el código del agente y devolverle el resultado. En Caution, el Radar vuelve a advertir contra medir la productividad por el porcentaje de código generado por IA o por los tokens consumidos, y recomienda las métricas DORA y los resultados de negocio.

El harness se mantiene, igual que cualquier otro sistema

El feedback flywheel pasa a Trial porque, según el Radar, editar el harness ya es rutina. La práctica añade una pregunta al final de cada sesión (¿hay que cambiar algo en un artefacto compartido?) y un punto en la retrospectiva donde el equipo decide qué actualizar. El Radar insiste en que la rueda también tiene que quitar: las reglas que solo se acumulan acaban en el exceso de instrucciones de antes. Un equipo puede empezar apuntando cada corrección que le hace al agente (lo que enseñan las correcciones de tu equipo).

Manel Marcos, nuestro CTO, lo resuelve con una persona: en el equipo al que acompañamos dejamos un rol de context engineer, y le enseñamos a velar por el harness y por el contexto y a mejorarlos de forma continua.

El paso siguiente, también en Trial, es el self-improving harness: agentes que analizan las trazas de ejecución y los resultados de las evaluaciones y proponen o aplican mejoras al propio harness. El Radar recomienda hacerlo con experimentos acotados y pruebas de regresión, con personas que fijan los objetivos y los límites de lo que se puede modificar.

Cuando varios equipos de una empresa usan agentes, aparece el problema de repartir lo que funciona. El Radar pone en Trial el agent plugin marketplace, un repositorio Git documentado desde el que se publican skills, instrucciones, servidores MCP y subagentes, y Agent Package Manager, que los gestiona como dependencias con versión y procedencia registradas, y busca Unicode oculto que podría secuestrar al agente. El nivel siguiente, el enterprise harness común a toda la organización, se queda en Assess, con el consejo de mantenerlo fino y federado mientras no haya consenso sobre cómo hacerlo bien.

Seguridad: el agente, aislado y con el mínimo acceso

Agent sandboxing llega a Adopt como opción por defecto para todos los agentes, también los que actúan en sistemas de negocio: entornos aislados con privilegios y acceso a sistemas externos restringidos, con un enfoque por riesgo que salga del modelado de amenazas. El threat modeling, en Adopt, debería ser una parte habitual del ciclo de desarrollo, dirigida por personas y apoyada por agentes, y terminar con decisiones explícitas: dónde es aceptable que el modelo se comporte de forma no determinista y dónde hacen falta límites deterministas.

En Trial, el toxic flow analysis for AI busca los caminos peligrosos de los datos en un sistema con agentes. El Radar parte de la combinación que llama «trifecta letal»: acceso a datos privados, exposición a contenido no fiable y capacidad de comunicarse hacia fuera. Y avisa de que el riesgo también llega por skills que parecen útiles y esconden instrucciones para sacar datos. El managed agents runtime, ejecutar los agentes en una plataforma que gestiona su ejecución, fuera del portátil del desarrollador, también está en Trial, con la recomendación de tratarlo como infraestructura de producción.

Si construyes agentes que no programan

Una entrada de Trial interesa a quien lleva agentes a procesos de negocio: el coding harness for general-purpose agents. Cada vez más equipos montan el bucle de sus agentes sobre el motor de un agente de código maduro (el Claude Agent SDK, el SDK de Codex, el servidor de OpenCode o Pi), que ya resuelve la compactación del contexto en tareas largas y las sesiones persistentes. El precio es menos control, y el Radar pide revisar sus instrucciones por defecto, pensadas para escribir código, y vigilar el consumo de tokens.

Alrededor hay varios componentes de producción en Trial: los stateful guardrails, que evalúan la conversación entera, turno a turno; Promptfoo, para evaluaciones y pruebas de ataque repetibles; Presidio, para detectar datos personales antes de enviarlos a un modelo, con el aviso de que no es infalible; Temporal y Restate, para procesos largos que esperan a una persona; y LibreChat, que el Radar presenta como una forma controlada de dar herramientas de IA a quien no es de ingeniería. En modelos, los de pesos abiertos y los pequeños pasan a Trial, y el uso del modelo más potente para todo, sin mirar coste ni latencia, se queda en Caution.

La prueba de esta noche

De todas las entradas, la que mejor sirve de diagnóstico es la de la noche. El Radar explica que «overnight» está en el nombre porque es difícil de fingir, y que un equipo que no deja a un agente trabajando solo de noche probablemente tampoco tiene trabajo autónomo durante el día. También dice que la práctica tiene requisitos de entrada y que buena parte de su valor está en obligar al equipo a cumplirlos. Convertidos en preguntas para tu equipo, más una que sale de la revisión por riesgo:

En nuestro producto propio, donde hemos llegado a un nivel de madurez alto, lo hacemos así: cuando una feature tiene todas sus preguntas abiertas resueltas, dejamos a los agentes desarrollando toda la noche un sprint de historias de usuario y por la mañana revisamos la auditoría del sprint.

Si alguna respuesta es «no», el Radar sugiere tratar la noche como un objetivo que justifica construir esa base. Es el trabajo de AI-Accelerated Development. Construimos con tu equipo dos cosas que se quedan en tu casa: el contexto en el que trabaja la IA y el proceso con el que trabajáis, de la idea a la documentación actualizada. Si quieres revisar con alguien de fuera qué os falta, el diagnóstico es gratuito.

Preguntas frecuentes

¿Qué es el Technology Radar de Thoughtworks?

Es la guía en la que Thoughtworks da su posición sobre técnicas, plataformas, herramientas y lenguajes. La elabora su Technology Advisory Board, un grupo de 18 tecnólogos sénior que se reúne dos veces al año, a partir de lo que ven en sus proyectos. El volumen 35, de noviembre de 2026, tiene 117 entradas.

¿Qué significan Adopt, Trial, Assess y Caution en el Radar?

Adopt quiere decir que Thoughtworks cree que el sector debería adoptarlo ya. Trial, que vale la pena probarlo en un proyecto que pueda asumir el riesgo. Assess, que conviene explorarlo para entender cómo te afecta. Caution, que hay que ir con cuidado porque tiene problemas importantes.

¿Qué es el harness de un agente de código?

Es todo lo que el equipo construye alrededor del agente para que trabaje bien: el contexto y las instrucciones, la memoria, las comprobaciones que le devuelven sus errores y los límites de lo que puede tocar. El Radar 35 lo trata como un activo vivo, con dueño y mantenimiento.

¿Se puede dejar un agente de código trabajando toda la noche?

El Radar 35 lo pone en Trial para equipos que ya tienen la base: el agente aislado en un entorno restringido, el trabajo especificado antes, comprobaciones que le permitan corregir sus propios errores y un harness probado que valide el resultado sin depender de leer cada línea.

¿Qué dice el Radar 35 sobre Spec-Driven Development?

Sube OpenSpec a Trial porque sus equipos lo usan con éxito, también en código existente, y pide que la especificación se mantenga como referencia viva. A la vez pone en Caution la documentación generada en masa que nadie poda, y cita Spec Kit y BMAD como herramientas con las que pasa.

¿Qué es human-in-the-loop theater?

Es mantener a una persona en el bucle de un agente como un paso de aprobación vacío: aprueba acciones o cambios que no puede evaluar de verdad. El Radar 35 lo pone en Caution y propone graduar la revisión según el riesgo de cada cambio.

Fuentes

• Thoughtworks, Technology Radar, vol. 35, noviembre de 2026 (PDF en inglés).
• Entradas citadas: Unattended overnight agentic builds, OpenSpec, AI-driven documentation sprawl, Progressive context disclosure, Agent instruction bloat, Risk-tiered human oversight, Human-in-the-loop theater, Mutation testing, Path-to-production mapping, Feedback flywheel, Agent sandboxing, Toxic flow analysis for AI y Coding harness for general-purpose agents.