Saltar al contenido

root / tags / dora-2025

#DORA 2025

4 fiches

Calidad y Seguridad Traducción verificada automáticamente

Code review dans le SDLC augmenté : l'anneau de contraintes autour des agents

Episodio «Fase 5 · Review» de la serie de SFEIR sobre el SDLC aumentado, publicado **el mismo día** que la publicación de Addy Osmani en LinkedIn que traduce en una especificación de fase. Tesis: **la calidad ha cambiado de dirección** — ya no se lee en el código (los agentes producen más código del que nadie puede revisar) sino en **el anillo de restricciones que rodea al agente**. El anillo de Osmani (siete dimensiones — corrección, seguridad, rendimiento, accesibilidad, mantenibilidad, **eficiencia económica**, **comprensibilidad** — enlazadas por la regla de **back-pressure**: «un bucle solo recibe la autonomía que puede verificarse de forma barata y fiable, ni un ápice más») se redibuja, se traduce y se adjunta a la fase 5 del ciclo de 11 fases de SFEIR. El corolario estructurante: **el cuello de botella nunca ha sido la generación, es la verificación** — «la generación es una boca ancha, la verificación un cuello estrecho; acelerar la boca engrosa la pila en el cuello». **La decisión de diseño más interesante es una elección de arquitectura del ciclo**: Review queda deliberadamente **fuera de las tres puertas humanas** (Define, Plan, Ship), porque convertir Review en la puerta pondría la atención humana — un recurso finito — como el punto de control de una capacidad de generación que a su vez escala: «habrías construido un pipeline cuyo rendimiento máximo es el número de diffs que un senior puede leer antes de que acabe el día». De ahí la separación: **Review instrumenta, Ship decide** — Review entrega un *cuerpo de evidencia oponible*, Ship decide sobre la evidencia, no sobre el diff completo. Una postura enfrentada a Monperrus (de quien SFEIR conserva el diagnóstico — la inspección humana de cada diff no puede resistir la velocidad agéntica — pero rechaza la conclusión: la aceptación no puede delegarse). La trampa señalada es la **validación circular** (el agente que escribe el código escribe los tests que lo validan: «has construido un espejo, no un anillo»), con cinco contramedidas extraídas de Anthropic (puertas independientes en ventanas de contexto separadas, determinista + agéntico que nunca se sustituyen entre sí, modo sombra, categorización por riesgo, registro en el SIEM) y la advertencia de Compare the Market (**grafo AST ~70% frente a RAG vectorial ~58%**, con el RAG rindiendo *peor que sin contexto alguno*). La extensión propia de la firma es **el trinquete**: «cada fuga se convierte en una restricción» — un defecto que ha cruzado el anillo se cierra *dentro del anillo* (test, regla de lint, rúbrica de revisión, guardrail del harness) en Compound-1, «el único activo de la cadena que se revaloriza mientras los modelos se deprecian» (una medición interna no auditada: **−30% de iteraciones de corrección tras diez ciclos**). Cierra reformulando la pregunta: «¿es bueno este código?» se ha vuelto una pregunta sin respuesta; lo que queda es **«¿qué se niega a dejar pasar mi sistema?»**

#anillo de restricciones#restricciones alrededor de los agentes#fase Review

SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market

Calidad y Seguridad Traducción verificada automáticamente

Anthropic sécurise un SDLC où l'IA écrit 80 % du code : le cycle redevient le socle

Descifrado de SFEIR (voz de la firma) del informe de Jason Clinton (Deputy CISO, Anthropic) publicado cinco días antes — ya documentado en [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **El valor añadido no reside en los hechos sino en la tesis que los relee**: si los controles de Anthropic se sostienen, es porque **existe un ciclo con etapas nombradas del que colgarlos** — "el SDLC es el fundamento, no una formalidad". La demostración avanza releyendo el mapeo (**PSR en Plan, CLAUDE.md + egress allowlist en Code, agentes de revisión en Test, DAST continuo en Deploy, triage + enrutamiento SIEM en Monitor**), y después mediante una **anáfora en cuatro partes**: (1) *sin un SDLC, las ganancias de productividad no se materializan* — Clinton cita la **ley de Amdahl**: multiplicar por 8 el volumen de código no multiplica nada si la revisión sigue siendo secuencial y humana, y Anthropic ganó no distribuyendo agentes sino **identificando la etapa bloqueante (Test) y reconstruyéndola** — "no se optimiza un cuello de botella que no se ha mapeado" (haciendo eco del **efecto espejo** de DORA 2025); (2) *sin un SDLC, la seguridad no tiene punto de anclaje* — un **gate es por definición un control situado entre dos etapas**, y las tres amenazas de Clinton se abordan en momentos distintos; (3) *sin un SDLC, no puede formularse ninguna política de **FinOps de tokens*** — el escaneo agéntico se factura por consumo y crece con el volumen de código, así que **el tiering basado en riesgo ES la política de FinOps** (decide dónde se pagan tres pasadas de agente y dónde basta un SAST), de lo contrario "el gasto en tokens no se pilota, se descubre a fin de mes"; (4) *sin un SDLC, no hay nada que medir* — los indicadores (16% → 54% de PR comentados, un tercio de los incidentes pasados interceptados) existen solo porque hay etapas donde puede colocarse un contador; sin eso, solo se producen **cifras de uso** (licencias, tokens) que nada dicen sobre calidad o riesgo. Dos puntos fuertes más allá de la tesis: la lectura del **incident agent-à-agent** ("un perímetro de seguridad que descansa sobre una instrucción en un prompt no es un perímetro"; **el acceso de un agente a otros agentes forma parte de su superficie de ataque**) y una **advertencia metodológica explícita** — cifras de Anthropic sobre Anthropic, no auditadas, publicadas por el proveedor del modelo descrito, en el contexto de una base de código joven sin mainframe: **lo que se transpone es el método, no las cifras**.

#SDLC#SDLC nativo en IA#ciclo de desarrollo

SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)

Arquitectura y Construcción Traducción verificada automáticamente

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Artículo de SFEIR (en francés) que formaliza un SDLC impulsado por IA en 11 fases (0 a 10) y sostiene que el sector converge hacia él. Observación de partida: en 2025, las organizaciones añadieron herramientas de IA sin transformar su modelo operativo, produciendo una paradoja de «todo cambia… y nada cambia» (la velocidad de ejecución se multiplica sin una ganancia proporcional). La verdadera respuesta no es la elección de herramientas, sino el rediseño del ciclo para la ejecución por máquinas. El ciclo de SFEIR se apoya en tres puertas humanas inamovibles (Define, Plan, Ship), fases automáticas entre ellas, y dos momentos de capitalización (Compound-1 antes del despliegue, Compound-2 en producción) que convierten las lecciones en reglas reutilizables. Tres principios: la IA ejecuta (artefactos completos + prueba de ejecución, sin confiar nunca en las afirmaciones del propio agente), el humano conserva el control de la intención, el sistema aprende de forma acumulativa. Resultados medidos (rediseño de 6 meses a 1 día, −30 % de iteraciones tras diez ciclos) y convergencia declarada con ADLC, Google y DORA 2025.

#SDLC#ciclo de desarrollo#IA

SFEIR

Arquitectura y Construcción Traducción verificada automáticamente

How AI Changes the SDLC: A Six-Stage Guide

Guía de Augment Code (Paula Hingel) que describe cómo los agentes de IA están reestructurando el ciclo de vida del desarrollo de software (SDLC), etapa por etapa. Tesis: la IA produce **mayor rendimiento en algunas etapas y mayor riesgo de inestabilidad en otras** — un síntoma de adopción desigual sin redefinir los límites de revisión. Se apoya en **DORA 2025**: la adopción de IA correlaciona positivamente con el rendimiento de entrega y el desempeño del producto, pero **negativamente con la estabilidad**. Seis etapas revisadas (Requisitos, Diseño/Arquitectura, Implementación, Pruebas/QA, Despliegue, Mantenimiento), tres riesgos principales (erosión del pipeline junior, **validación circular** de pruebas generadas por IA, brechas de gobernanza a escala) y tres roles emergentes (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Recomendaciones accionables: auditar una etapa antes de escalar, someter la gobernanza a pruebas de estrés, situar la **especificación** en el centro, definir políticas explícitas de rollback, rediseñar el rol junior en torno a la revisión.

#SDLC#ciclo de vida del desarrollo de software#agentes de codificación

Paula Hingel (Augment Code)