Verificar el código de la IA es el nuevo cuello de botella

Del 28 al 30 de junio de 2026, Thoughtworks y Martin Fowler encerraron en Engelberg (Suiza) a un grupo de CTOs, arquitectos, consultores y programadores senior durante tres días. Cuarenta sesiones en formato unconference: sin ponencias, sin agenda cerrada, propuestas por los propios asistentes y, según reconoce el informe, a veces directamente discusiones.

De ahí no salió un consenso, sino un inventario honesto de por dónde se está rompiendo nuestro oficio.

Las tres jornadas caben en una frase. Generar código ya no es el cuello de botella, confiar en él sí.

TL;DR — Los 5 titulares del retiro:

🔍 La verificación es el cuello de botella — Los agentes producen código, specs, tests e infraestructura más rápido de lo que ningún equipo puede llegar a confiar en ellos. Gana quien construye verificación barata, rápida y legible por humanos.

🔧 El “harness engineering” nace como disciplina propia — El andamiaje alrededor del agente pesa más que el modelo o el prompt. Es donde vivirá la diferencia competitiva cuando los modelos se conviertan en commodity.

🎓 Hay una crisis de aprendizaje — Si los seniors emparejan en exclusiva con agentes, los juniors pierden el camino práctico hacia el criterio. La cohorte de 7 a 10 años de experiencia es la que está peor.

📉 La brecha ejecutivo/ingeniero es más peligrosa que cualquier límite técnico — La estimación realista contando el ciclo completo es 2-3x, no 10x. Y hay una ventana de 12 a 18 meses antes de que las expectativas se reajusten.

🏛️ La modernización de legacy es el filón más defendible — Un compilador de COBOL que pasa la suite de tests del NIST, construido en tres días por unos 5.000 dólares en tokens.

– Lee el original en inglés y PDF: The Future of Software Engineering — June 2026, Engelberg

Este es el segundo retiro. El primero fue en febrero, en Utah, y de él salió el análisis del futuro de los programadores cuando la IA escribe el código. No hace falta que lo hayas leído: aquí no hay dependencias. Pero sí conviene saber que Engelberg no es un resumen de Utah. Es una revisión de cuatro meses después, con cosas que se confirman, cosas que se dan la vuelta y cosas que ni estaban sobre la mesa en febrero.

Vamos a desgranarlo.

¿Por qué la verificación se ha convertido en el cuello de botella? ¶

Porque la capacidad de generar se ha desacoplado de la capacidad de confiar. Fue la observación más repetida de todo el retiro, y apareció en sesiones que hablaban de cosas distintas: testing, modernización de legacy, revisión de código y diseño de equipos. En todas se llegaba a lo mismo.

Un participante lo formuló así: la ingeniería se ha destilado hasta quedarse en dos preguntas. Cómo describo el objetivo y cómo verifico que lo he alcanzado.

No se quedó en abstracción. Salieron cuatro cosas concretas.

Está apareciendo un vocabulario nuevo de testing. Los constraint tests son tests de una sola entrada y una sola salida cuya misión no es cubrir casos, sino acotar lo que el agente tiene permitido generar. Los scenario tests describen recorridos completos. Y los good/bad logs se derivan de incidentes reales de producción: le das al agente el log de algo que salió bien y el de algo que reventó, y tienes un criterio de aceptación que no se puede discutir.

Un constraint test tiene esta pinta. Nada sofisticado:

# Constraint: el descuento nunca puede superar el precio del pedido.
# Este test no cubre casos, acota lo que el agente puede escribir.
def test_discount_never_exceeds_order_total():
    order = Order(total=40.00)
    user = User(tier="vip", loyalty_years=25)
    assert calculate_discount(user, order) <= 40.00

def test_discount_is_never_negative():
    order = Order(total=40.00)
    user = User(tier="none")
    assert calculate_discount(user, order) >= 0.00

Dos tests de tres líneas. Ninguno describe la lógica de negocio. Los dos juntos hacen imposible que el agente te cuele un descuento de 120 euros sobre un pedido de 40.

Los montajes de approval testing hechos a medida están funcionando mejor que los frameworks BDD genéricos. Y no por purismo: porque mantienen la superficie que un humano tiene que revisar pequeña y difícil de engañar para un agente. El informe recomienda presupuestar horas, no semanas, para montar uno de estos: en el retiro se enseñaron ejemplos construidos en una sola sesión de trabajo con alguien con experiencia.

Para migraciones de alto riesgo ya hay un stack de verificación de tres capas. Primero characterization tests que capturan el comportamiento real del sistema antiguo. Después ejecución simbólica, con fundamento matemático y sin IA de por medio. Y al final back tests contra flujos de datos reales de producción como última puerta. Es la metodología más rigurosa que salió del retiro.

Y la evaluación mixta resuelve el problema del LLM-como-juez. Un equipo combinó linters y pattern matching deterministas con un “consejo de jueces” de tres modelos. La aceptación de merges a la primera pasó de rondar el 60% a rondar el 80%.

¿Los tests importan más que la especificación? ¶

Según Engelberg, sí. Y esta es la frase del retiro que más va a escocer a quien lleve meses metido en Spec Driven Development:

🔑 “Los tests de conformidad importan mucho más que la spec. Si los tests de conformidad difieren de la spec, ¿adivinas cuál gana?”

En Utah, en febrero, la conclusión era que la especificación se convertía en el artefacto con mayor capacidad de impacto: una mala spec produce mal código a escala. Engelberg no lo desmiente, lo ordena. La spec sigue siendo la entrada del proceso, pero el test es el único artefacto ejecutable. Cuando los dos se contradicen, lo que está en verde manda sobre lo que está escrito en prosa.

Esto tiene una consecuencia práctica y poco cómoda: si escribes specs preciosas y no las cierras con tests de conformidad, has escrito documentación. Documentación buena, pero documentación.

Lo que no significa es que la spec sobre. Significa que el ciclo no termina donde muchos lo estamos terminando. Si estás empezando con esto, los errores más comunes al hacer Spec-Driven Development cubren justo el tramo donde la gente se queda a medias.

Curso gratis · paso a paso

Ve el ciclo entero de SDD antes de discutir si la spec o el test

Ocho lecciones sobre un proyecto real: proposal, spec, diseño, tareas, aplicar y archivar. Lo ves funcionar completo en modo asistido y luego haces tu primer ciclo a mano.

Entra en el curso gratis →

¿Y si el code review manual nunca hizo lo que creíamos? ¶

Aquí es donde el retiro se puso incómodo. Varios participantes señalaron lo mismo: nadie en la sala podía citar un solo dato sobre cuántos defectos detecta de verdad la revisión manual de código.

El informe lo llama “ilusión de statu quo”. Una práctica que damos por garantía de calidad sin haberla medido nunca.

En febrero la preocupación era otra. Era que perder el code review nos dejaba sin canal de aprendizaje y de comprensión compartida del sistema. Esa parte sigue en pie. Lo que Engelberg añade es la pregunta previa: ¿y si además tampoco pillaba tantos bugs?

La recomendación no es cargarse la revisión. Es dejar de tratarla como una garantía por defecto y medirla. Si tu organización no puede producir datos sobre defectos detectados en review, eso es un hueco real, no una formalidad.

Y para código que no conoces o que ha generado un agente, el informe propone una secuencia de tres pasos en este orden:

1. Cobertura primero. Sin esto no hay conversación posible.
2. Sondeo adversarial con IA. Le pides a un modelo que intente romper el código sin romper los tests. Si lo consigue, tu suite miente.
3. Mutation testing, pero solo si el paso anterior no encontró nada.

El paso 2 es el que más información da. Un agente que consigue introducir un fallo real sin que se ponga ni un test en rojo te está diciendo exactamente dónde está el agujero de tu suite. Si quieres profundizar en el proceso completo, tienes más en cómo hacer testing con IA según los expertos.

¿Qué es el harness engineering y por qué pesa más que el modelo? ¶

El harness es todo lo que rodea al agente y no es el agente: gestión de contexto, guardarraíles deterministas, skills, bucles de mejora automática, herramientas acotadas. En Engelberg, varias sesiones llegaron por caminos distintos a la misma conclusión. Cuando los modelos se conviertan en commodity, la diferencia competitiva vivirá ahí.

A diferencia de otras conversaciones del retiro, esta viene con números medidos:

Fíjate en las dos filas del linter, porque son la misma herramienta. La diferencia entera está en el formato del mensaje. Decirle al agente “esta función es demasiado larga” produce resultados mediocres. Decirle “aquí tienes cómo refactorizar una función larga, paso 1, paso 2, paso 3” casi dobla la tasa de resolución. El informe lo señala como la mejora de harness más barata y de mayor palanca documentada en todo el retiro.

La segunda idea es todavía mejor. Los equipos que mejor rinden no escriben su harness a mano. Dejan fallar al agente, ejecutan una skill de “aprender” que reflexiona sobre la sesión y propone ediciones al propio harness, y reservan el trabajo humano para podar y simplificar cada cierto tiempo. El humano no es el autor, es el jardinero.

Si quieres el concepto desarrollado con ejemplos, lo tienes en qué es el AI harness y el harness engineering.

⚠️ Y aquí llega el aviso que nadie quiere oír si ha montado una biblioteca de skills: las skills y los artefactos de contexto compartidos se degradan igual que un framework sin dueño. Necesitan propiedad explícita y una poda periódica conforme mejoran los modelos, con un proceso ligero de evaluación con skill y sin skill para ver cuáles ya no aportan nada.

El retiro no resolvió quién debe ser ese dueño. Centralizarlo todo en un “equipo de harness” reproduce el viejo antipatrón del equipo de operaciones aislado. Dejarlo sin dueño garantiza la deriva. No hubo consenso, y el informe lo admite.

Tu IA puede mentirte

La IA miente: cómo revisar y verificar lo que programan los agentes

El retiro dice que la verificación es el cuello de botella. Esta masterclass es el cómo: ciclo anticaos, pruebas con Playwright, casos Gherkin, evaluación de skills y adversarial review entre modelos.

Ver la masterclass →

Masterclass premium · suscripción Web Reactiva · 15€/mes

¿Por qué el throughput se dispara y el cycle time no mejora? ¶

Este es el diagnóstico más afilado que salió de Engelberg y se llama el problema de los dos relojes.

Los equipos están midiendo dos tiempos por separado. El reloj de producir código y el reloj de esperar una decisión. Lo que están encontrando es que el primero se ha desplomado mientras el segundo sigue igual. El throughput del developer ha explotado y el cycle time global no ha mejorado, porque la restricción se ha mudado a la toma de decisiones y a la claridad de la especificación.

La conclusión práctica es directa: si tu throughput sube y tu cycle time no, arregla el proceso de decisión, no el pipeline. Estás optimizando el tramo que ya no es el problema.

De ahí sale una segunda observación sobre la forma de los equipos. Las conversaciones de topología convergieron en algo parecido en al menos cinco sesiones: equipos “núcleo” más pequeños, muchas veces parejas o tríos, supervisando flotas grandes de agentes, pero manteniendo un suelo social de unas diez personas por cordura organizativa.

Hubo además un caso de estudio que se repitió casi con las mismas palabras en varias sesiones. Un equipo donde el product manager y el diseñador se convirtieron en “superpoderes” que sacaban funcionalidades por su cuenta con agentes, mientras el ingeniero quedaba relegado a limpiar detrás. Frente a otro equipo que emparejaba en specs, tests e intención de diseño mientras una flota de agentes convergía hacia la solución.

El primero era muy productivo. El liderazgo lo describió como “un desastre en construcción”, porque erosionaba la cultura de pairing y la cohesión de la organización.

💡 De ahí sale la recomendación más contraintuitiva del informe: preserva de forma deliberada el pairing sobre specs y sobre intención de diseño, aunque el pairing sobre implementación desaparezca. Una flota de agentes genera desde una sola instrucción mucho más código del que una pareja humana podía revisar línea a línea.

Dos apuntes más de esta parte. Los equipos de plataforma necesitan una actualización de credibilidad: los tradicionales, centrados en infraestructura, muchas veces no tienen el nivel de programación para hacerse cargo del harness, y la propuesta repetida fue que usen las mismas herramientas agénticas que exigen a los equipos de producto y pasen de ofrecer un “menú de opciones” a un camino asfaltado con opinión.

Y el domain-driven design está siendo reevaluado como la disciplina existente más relevante para esta etapa. No porque produzca un gran diseño maestro, sino porque es la única práctica establecida para negociar y nombrar límites de forma continua en una organización grande.

¿Se está rompiendo la escalera que convierte juniors en seniors? ¶

Sí, y esta es la parte donde el retiro cambia de tono.

En al menos seis sesiones independientes apareció el mismo miedo, planteado por gente distinta que estaba resolviendo problemas distintos: si los juniors nunca llegan a pelearse con código real, incidentes reales de producción y decisiones de diseño reales, porque los agentes (o los seniors que emparejan en exclusiva con agentes) absorben ese trabajo, la industria pierde el mecanismo que fabrica seniors con criterio y con gusto.

Ojo al matiz, porque es exactamente lo que hace el problema difícil. El retiro estuvo de acuerdo, igual que en Utah, en que para trabajar así hay que saber qué aspecto tiene lo bueno. Por eso los seniors rinden tanto con agentes. Y por eso mismo el problema de la escalera es más grave: la habilidad que hace falta para usar bien estas herramientas es justo la que se adquiría haciendo el trabajo que las herramientas ahora hacen.

En febrero la conclusión era que los juniors son más valiosos que nunca. Sigue siendo verdad. Lo que Engelberg añade es que la maquinaria de convertirlos en seniors se está rompiendo por otro lado.

Las contramedidas que ya se están pilotando:

• Quórum de diseño o mob programming deliberado. Un senior lidera la conversación de diseño en tiempo real mientras los juniors hacen los prompts. El junior mantiene las manos en el teclado y la exposición a las decisiones difíciles.
• Puntos de control de aprendizaje sin IA. Momentos explícitos del onboarding donde la persona trabaja sin asistencia y tiene que explicar su razonamiento. Con rendición de cuentas pública, no como sugerencia.
• Currículos nuevos que enseñan orquestación y supervisión de agentes como competencia de inicio de carrera, no como algo que se aprende después.

Luego está el grupo que peor lo está pasando, y no es el que esperarías. La cohorte de 7 a 10 años de experiencia fue identificada como la de mayor tensión: han invertido una década dominando habilidades que los modelos ahora igualan o superan, y el impacto emocional y de identidad es real. El informe recomienda vigilar a ese grupo de forma específica buscando señales de desconexión, porque suelen ser los responsables de entrega con más experiencia del equipo y su pericia se está devaluando rápido y sin hacer ruido.

Como refuerzo, el retiro citó una investigación con estudiantes universitarios que escribieron ensayos con asistencia intensiva de LLM: mostraron una degradación medible de su capacidad de pensamiento crítico a lo largo de tres meses, incluso comparados con su propia línea base sin asistencia.

Si esto te toca de cerca y estás pensando en cómo posicionarte, en cómo encontrar trabajo de programador en tiempos de IA hay estrategias concretas para el tramo de entrada.

¿Es la modernización de legacy el filón más claro a corto plazo? ¶

Es el más defendible, según el informe, y con diferencia. Varias sesiones describieron enfoques de modernización de mainframe asistida por IA que no eran especulación: eran pilotos avanzados o cosas ya en producción.

La disciplina de migración que se repitió entre sesiones se resume en tres reglas:

1. “No añadas nada, no cambies nada, borra todo lo que puedas” durante el port.
2. Cambia una cosa cada vez. Primero fidelidad de comportamiento, después arquitectura. Nunca las dos a la vez.
3. Preserva los bugs conocidos a propósito, como decisión aprobada por el cliente, en lugar de dejar que la IA “arregle” con buena intención algo de lo que depende un sistema aguas abajo.

Esa tercera regla es la que separa a quien ha hecho una migración de verdad de quien la ha leído.

Los resultados técnicos que se enseñaron dan bastante vértigo. Un compilador completo a medida de TypeScript a .NET CLR construido con IA en cuatro días. Un compilador de COBOL que pasa la suite de tests del NIST, construido en tres días por unos 5.000 dólares en tokens. Y la ingeniería inversa de un formato binario de mainframe de 1994, sin documentar y cifrado, haciendo que un modelo detectara patrones a nivel de byte.

Problemas que antes no salían a cuenta resolver desde cero (compiladores a medida, transliteradores, verificación formal) están ahora al alcance de un equipo normal.

Y hay un encuadre que funciona en consejos de administración: conectar la inversión en IA directamente con el presupuesto de mantenimiento y modernización, que en grandes empresas suele ser entre el 30% y el 50% del gasto total de TI. Un caso real convirtió una petición vaga de 100 millones de dólares en una propuesta acotada de 8 millones sobre el 20% de los sistemas, con valor medible atado.

¿Por qué tu CEO cree que la IA es 10x y tú ves 2-3x? ¶

Porque su experiencia práctica con la IA no es programando. Es escribiendo informes.

La queja fue casi universal en el retiro: los consejos y los CEOs creen que “un product manager suelta un PRD en la máquina mágica y sale software funcionando”. Y esa creencia tiene una explicación concreta y poco culpable. Las herramientas de IA para redactar y resumir funcionan de maravilla, y son un proxy pésimo para la ingeniería de software.

Los números que se pusieron encima de la mesa:

• Una estimación realista, contando el ciclo de vida completo y no solo la generación de código, sitúa las ganancias a corto plazo en 2-3x, no 10x.
• La distancia entre el bombo y esa realidad podría “reventar la burbuja” en una ventana de 12 a 18 meses.
• En una organización, los incidentes internos de seguridad reportados subieron unas 20 veces en seis meses.
• Los presupuestos anuales de tokens se están agotando en tres meses en lugar de en doce.

Ese último dato es el que está consiguiendo atención de los consejos más rápido que cualquier promesa de productividad. El shock de presupuesto convence antes que la métrica.

🔑 La brecha no se cierra con modelos mejores. Se cierra contando historias concretas atadas al balance de la empresa, verificando contra benchmarks reales los “10x” que promete cada proveedor, y montando ejercicios donde los directivos intenten construir algo ellos mismos y choquen contra los límites de verdad.

¿Cuánto te cuesta de verdad tu agente? ¶

Depende muchísimo menos del modelo que eliges y muchísimo más de cómo has diseñado el acceso a los datos. El informe da una cifra que parece una errata y no lo es: la eficiencia de coste varía hasta 1.400 veces según cómo esté arquitecturado ese acceso.

El generador de coste más infravalorado tiene nombre: el round-tripping ineficiente vía MCP entre el modelo y los sistemas de la empresa. Cada ida y vuelta innecesaria se paga en tokens. Y hay una tensión real ahí, porque la optimización de coste empuja a acercar los datos al modelo y la seguridad empuja justo en dirección contraria.

Sobre el interés creciente en auto-hospedar modelos, el retiro fue claro en que la motivación ha cambiado. Ya no es el coste. Es soberanía y control: miedo al alcance legal estadounidense sobre los datos, miedo a que un proveedor suba precios de forma unilateral o limite el acceso, y no querer perder la capacidad de aprender y cambiar por haberla externalizado entera.

El aviso realista es que el auto-hospedaje a gran escala es una disciplina escasa y especializada, con ingeniería de rendimiento que llega hasta la topología física del rack, y que los hyperscalers y las neoclouds están absorbiendo. El camino intermedio que se propuso para cargas de trabajo de programación: hardware de inferencia dedicado más pequeño o proveedores especializados en alojar modelos de código.

Y la recomendación de fondo para quien gestiona: varias organizaciones reportaron que su gasto en tokens se multiplicó por diez en meses, sin presupuestar y sin detectar hasta que fue una crisis. Eso no es un problema de finanzas, es un fallo de gobernanza. Necesita responsables con nombre, cadencia de revisión y política basada en patrones de uso, igual que se hizo en su día con el gasto en cloud. Por el lado del día a día, las formas de inflar tokens y las de usarlos con criterio siguen siendo la palanca más rápida.

¿Qué incidentes de seguridad están pasando ya? ¶

Los tres que se contaron en el retiro son reales y ninguno requiere un atacante sofisticado:

• La aplicación que un contable construyó con Copilot expuso datos de clientes a internet abierto a través de un túnel de Cloudflare que le sugirió la propia IA.
• El asistente de IA de un equipo de marketing recibió acceso amplio a GSuite mediante scopes de OAuth en cascada que la empresa no era capaz ni de enumerar cuando intentó cortarlo.
• Un agente que se quedó sin espacio en disco borró los backups para hacer sitio. Y quedó encantado consigo mismo por haber resuelto el problema.

A eso se suma un vector de cadena de suministro que da miedo por lo elegante que es: un atacante puede predecir qué librerías inexistentes es probable que un LLM alucine por nombre, y publicar paquetes maliciosos reales con esos nombres exactos. El sandboxing por sí solo no lo resuelve, porque la dependencia puede llegar igualmente a producción.

Las mitigaciones parciales que ya se están extendiendo:

En gobernanza salió un patrón que merece la pena copiar: un modelo de niveles verde, ámbar y rojo (uso personal, uso de equipo con formación obligatoria, uso en toda la empresa con validación de ingenieros profesionales), acompañado de detección por encima de prevención. Escaneo continuo de los logs de conversación de los agentes buscando patrones peligrosos, en lugar de confiar solo en la formación previa, que no puede seguir el ritmo de lanzamientos semanales de modelos.

El error de gestión que el informe señala con más insistencia es aplicar una política uniforme. “Vamos rápido en todo” y “bloqueamos todo” fallan igual sobre un portfolio con perfiles de riesgo muy distintos. La autonomía se calibra por criticidad del sistema, madurez del equipo y exposición regulatoria.

¿Qué es eso de ser “conspicuously human”? ¶

Es la contranarrativa de valores que atravesó todo el retiro por debajo del optimismo técnico, y significa algo así como ser humano de forma visible y deliberada.

El razonamiento es este: si verificar, prototipar y hasta testear el mercado se vuelven casi gratis y están al alcance de cualquiera, lo único que queda para diferenciarse es el juicio, el gusto y el cuidado humanos. Y eso hay que protegerlo a propósito, porque la presión de márgenes tiende a optimizarlo hasta hacerlo desaparecer.

Las analogías que se usaron para que no suene a nostalgia:

• El impresionismo surgió justo porque la cámara podía replicar la realidad a la perfección, y el valor humano se desplazó a la interpretación.
• Los bateristas se volvieron más sofisticados, no obsoletos, cuando llegaron las cajas de ritmos.
• El mejor “jugador” de ajedrez del mundo desde 1997 ha sido, discutiblemente, un equipo de humano más motor. No el motor solo.

Dos citas del retiro que resumen la postura mejor que cualquier resumen:

🔑 “Lo único que no quiero externalizar son los criterios de aceptación. Todo lo demás estoy dispuesto a externalizarlo.”

🔑 “Todas las mejores piezas de software jamás construidas se hicieron despacio. Eran las cosas a las que dedicamos más tiempo y más cuidado. Creo que el pensamiento lento es bueno.”

Esto no es sentimiento antitecnológico. Convive con el entusiasmo general del retiro por las herramientas agénticas. La formulación más clara fue mantener el bucle donde se inyecta el juicio de forma deliberada y visiblemente humana, aunque el bucle donde se construyen las cosas se automatice al máximo.

¿Qué ha cambiado entre febrero y junio? ¶

Si leíste el análisis del retiro de Utah, esta tabla te ahorra la comparación. Y si no lo leíste, te sirve igual como mapa de por dónde se está moviendo el consenso.

Lo que no cambia entre los dos retiros es el fondo. El trabajo de ingeniería no se está evaporando, se está desplazando. Lo que cambia es la velocidad a la que hay que reaccionar.

Y hay una advertencia estratégica que no estaba en febrero: no esperes una meseta. El informe considera más probable que los ciclos de bombo se compriman y que el ritmo de cambio siga acelerando, así que la única inversión sensata es en capacidades que aguanten donde sea que caiga el ciclo. Harness, verificación y gobernanza aguantan. Apostar la estrategia a que las promesas más extremas de hoy se cumplan, no.

¿Qué puedes hacer tú el lunes? ¶

El informe dedica dos secciones enteras a recomendaciones. Estas son las que puedes aplicar sin pedir permiso a nadie:

1. Mide tu code review. Aunque sea a mano y aunque salga mal. Cuenta cuántos defectos reales han salido de las revisiones del último trimestre. Si el número es cero o no lo sabes, ya tienes tu primera conversación pendiente.
2. Escribe dos constraint tests para la parte del código que más miedo te da que toque un agente. Entrada única, salida única, y que acoten lo que se puede generar.
3. Traduce tus reglas de linter a instrucciones paso a paso en el contexto del agente. Es la mejora de mayor palanca y menor coste que documentó el retiro.
4. Ejecuta el sondeo adversarial sobre un módulo que no conozcas: pide a un modelo que rompa el código sin romper los tests.
5. Mide tus dos relojes durante dos semanas. Tiempo produciendo código y tiempo esperando decisiones. Si el segundo domina, el problema no está en tus herramientas.
6. Pon dueño a tus skills compartidas y agenda una poda. Si nadie las mantiene, están decayendo ahora mismo.
7. Acota las herramientas de tus agentes que tocan infraestructura. Interfaces con esquema definido y auditables en lugar de acceso al CLI de tu proveedor cloud. Nada de comandos crudos de AWS o gcloud.
8. Si eres senior, monta un quórum de diseño. Tú llevas la conversación, el junior escribe los prompts. Cuesta una hora a la semana y es lo único que impide que la escalera se rompa en tu equipo.

Preguntas frecuentes ¶

¿Qué es el retiro Future of Software Engineering de Thoughtworks?
Un encuentro en formato unconference convocado por Thoughtworks y Martin Fowler que reúne a líderes técnicos, CTOs, arquitectos y consultores para discutir el estado de la ingeniería de software. El primero fue en febrero de 2026 en Utah y el segundo del 28 al 30 de junio de 2026 en Engelberg (Suiza), con 40 sesiones propuestas por los propios participantes.

¿Qué significa que la verificación es el cuello de botella?
Que los agentes de IA generan código, tests, specs e infraestructura mucho más rápido de lo que cualquier equipo puede establecer confianza en esa salida. El límite ya no está en producir, está en poder afirmar que lo producido es correcto. La disciplina que gana es la que construye verificación barata, rápida y legible por humanos.

¿Qué es un constraint test?
Un test de una sola entrada y una sola salida cuyo objetivo no es cubrir casos de uso sino acotar lo que un agente tiene permitido generar. Funciona como una barrera: en lugar de describir el comportamiento correcto, define los límites que el código no puede cruzar bajo ninguna implementación.

¿Qué es el harness engineering?
La disciplina de construir y mantener el andamiaje que rodea a un agente de IA: gestión del contexto, guardarraíles deterministas, skills, herramientas acotadas y bucles de mejora automática. En el retiro se describió de forma repetida como más determinante que el modelo o el prompt, y como el lugar donde vivirá la diferencia competitiva cuando los modelos se conviertan en commodity.

¿Los tests importan más que la especificación en Spec Driven Development?
Según el retiro de Engelberg, sí en caso de conflicto: si los tests de conformidad difieren de la spec, ganan los tests, porque son el único artefacto ejecutable. La spec sigue siendo la entrada del proceso, pero un ciclo que termina en la spec y no llega al test de conformidad deja el contrato sin cerrar.

¿Cuál es la mejora más barata que puedo hacer en mi harness?
Convertir las señales pasivas de tu linter o análisis estático en instrucciones deterministas paso a paso para el agente. En el experimento que se presentó, un linter en crudo resolvía menos del 50% de los code smells y el mismo linter traducido a instrucciones concretas llegaba al 90%.

¿Cuánta productividad real dan los agentes de IA?
Una estimación presentada en el retiro, contando el ciclo de vida completo del software y no solo la generación de código, sitúa las ganancias realistas a corto plazo en torno a 2-3x, frente a los 10x que prometen muchos proveedores. Los participantes anticipan una ventana de 12 a 18 meses antes de que las expectativas se reajusten.

¿Qué es la crisis de aprendizaje de la que habla el informe?
El riesgo de que los programadores junior pierdan el camino práctico hacia el criterio profesional, porque los agentes (o los seniors que emparejan en exclusiva con agentes) absorben el trabajo con el que se aprendía. Apareció de forma independiente en al menos seis sesiones distintas del retiro.

¿Qué grupo de developers está bajo más presión según el retiro?
La cohorte de 7 a 10 años de experiencia. Han invertido una década dominando habilidades que los modelos ahora igualan o superan, y el informe señala un impacto real de identidad, además de recomendar vigilancia específica sobre ese grupo por ser a menudo los responsables de entrega con más experiencia.

¿Por qué se dispara el gasto en tokens y cómo se controla?
Porque la eficiencia de coste varía hasta 1.400 veces según cómo esté diseñado el acceso a los datos, con el round-tripping vía MCP como generador de coste más infravalorado. El informe lo trata como un problema de gobernanza y no de finanzas: responsables con nombre, cadencia de revisión y políticas basadas en patrones de uso reales.

Fuentes ¶

• The Future of Software Engineering — Retreat Findings, June 28-30 2026, Engelberg (Thoughtworks, PDF)
• The future of software engineering — February 2026, Utah (Thoughtworks, PDF)

Qué me llevo de Engelberg ¶

Tres cosas.

La primera es que el trabajo pendiente no está en aprender a pedirle código a un agente. Eso ya lo sabes hacer. Está en montar el sistema que te dice si lo que te ha dado sirve, y ese sistema se construye con tests raros y baratos, no con más herramientas.

La segunda es que el harness es el sitio donde de verdad se acumula ventaja. Y como es aburrido de construir y no luce en una demo, la mayoría no lo va a construir.

La tercera me preocupa más que las otras dos juntas. Si eres senior y trabajas solo con tu agente, estás siendo productivo y estás rompiendo la escalera por la que subiste. La contramedida cuesta una hora a la semana y consiste en dejar que otro escriba los prompts mientras tú explicas por qué.

Esa hora es la que va a decidir cómo es tu equipo dentro de tres años.

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter