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)
Análisis de SFEIR (voz de consultora, "la lectura de un ingeniero") que articula dos marcos demasiado a menudo confundidos: el **SDLC** (Software Development Life Cycle — *construir el software correcta y fiablemente*) y el **PDLC** (Product Development Life Cycle — *construir el producto correcto y triunfar en el mercado*). Tesis central: los dos ciclos no son competidores sino **anidados** — el SDLC es el subconjunto del PDLC **alojado bajo su fase de desarrollo**; cuando un equipo de producto llega a la etapa de "construcción", un ciclo SDLC completo (diseño → construcción → pruebas → revisión → despliegue) se ejecuta dentro de él. El SDLC está estandarizado (**ISO/IEC/IEEE 12207**, ediciones 2017 y 2026), con su linaje de modelos (Waterfall 1970, modelo en V, iterativo/espiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) y sus métricas **DORA** (throughput, estabilidad, MTTR, tasa de fallos de cambio). El PDLC, al ser el ciclo paraguas, se extiende desde la **ideación/discovery** hasta la **retirada del mercado** (no confundir con el **PLC** de marketing de Theodore Levitt, 1965, que describe una *curva comercial*, no un *trabajo organizado*: "el PLC observa una curva; el PDLC organiza el trabajo"). **Punto de inflexión**: el SDLC aborda nativamente **solo uno de cada cuatro riesgos** — vía el marco de **Marty Cagan «Four Big Risks»** (Valor → PM, Usabilidad → Diseñador, Viabilidad técnica → Lead Engineer, Viabilidad de negocio → PM) — una organización excelente en SDLC pero ciega al PDLC produce "software que nadie quiere" — la **"feature factory"** de John Cutler (el éxito medido por el output, no por el outcome). **Por qué la IA lo cambia todo**: la IA generativa **comprime el SDLC** (datos de Google/JetBrains, mayo de 2026: **~85% de los desarrolladores** usan regularmente agentes de codificación, **~41% del código nuevo** es generado por IA; la implementación pasa de semanas a horas), por lo que el **cuello de botella se desplaza aguas arriba** — decidir *qué* construir (Marty Cagan, abril de 2026: "cuando el coste de la entrega se desploma, el cuello de botella se traslada al discovery"). Consecuencias: DORA 2025 (~5.000 profesionales, 90% de adopción de IA) muestra una **correlación positiva con el throughput pero negativa con la estabilidad** (más funcionalidades no validadas implica inestabilidad y retrabajo); Andrew Ng (AI Startup School, julio de 2025) informa de equipos que **invierten la proporción "1 PM por 4 ingenieros" a "2 PM por 1 ingeniero"**; y con el **spec-driven development**, la frontera PDLC/SDLC se vuelve **porosa** (la especificación de producto se vuelve directamente ejecutable por agentes). **Lo que un CIO debe retener**: un SDLC aumentado se convierte en un **estándar de mercado, no en un diferenciador** — hay que instrumentar la unión con el producto, exigir **especificaciones ejecutables** como entrada, cruzar las métricas técnicas con las métricas de outcome, y **rechazar** el rol de "proveedor de funcionalidades". Para un CPO: el desplazamiento del cuello de botella hacia el discovery es a la vez una **promoción** (el juicio de producto vuelve a ser escaso) y un **aviso para actuar** (industrializar el discovery para alcanzar la paridad con el SDLC). El marco propio de SFEIR ("Diseñar y construir en la era agéntica" — **ciclo de 11 fases** + **Software Factory 10x**) se posiciona como la respuesta del lado de la ingeniería, con la **articulación de los dos ciclos** como la siguiente palanca. Conclusión: "a medida que el código se convierte en un commodity, el margen se desplaza hacia el juicio de producto y la gobernanza".
Artículo de opinión en profundidad (punto de vista) publicado en **sfeir.com** el 24 de junio de 2026, por **Didier Girard** (Director General, SFEIR). **Tesis central**: en 2024 todos apostaban por **AI4Business** (IA en los procesos de negocio) como el gran yacimiento de valor; en 2026 el panorama se ha **invertido** — es **AI4IT** (IA para producir el sistema de información: código, SDLC, fábrica de software) la que genera valor **medible**. El artículo *fundamenta* esta tesis en la vigilancia tecnológica de la firma: decepción de AI4Business (el estudio del MIT «95% de pilotos sin ROI», cuestionado pero revelador; un bloqueo **organizativo** / el problema hayekiano de Mollick) frente a la evidencia cuantificada de AI4IT (Salesforce, Intercom, Raiffeisen, AWS/Bedrock, Atlassian, DORA). Explicación mecanicista: **el código se verifica a sí mismo** (compilación, pruebas, CI) mientras que los procesos de negocio no tienen ni compilador ni bucle de retroalimentación inmediato. **Consecuencia presupuestaria 2027**: un desplazamiento **CapEx→OpEx**, la dinámica de precios de los tokens (pico al alza — Fable 5 a 2× Opus — frente a una inferencia ÷280 y presión a la baja de los pesos abiertos/inferencia de escritorio), y un **AI FinOps** guiado por el **coste por resultado**. Cierra con **4 recomendaciones para el COMEX**.
#AI4IT#AI4Business#inversión
**Didier Girard** — Managing Director (CTO / DG) de **SFEIR** · ESN française (~1 000 personnes, France · Belgique · Luxembourg · Suisse). Auteur de l'article ; voix éditoriale du cabinet sur la transformation IA des DSI.
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.
Chris Williams (@voodootikigod) abre su serie ADLC argumentando que ejecutar el SDLC humano sobre modelos es un error de categoría: el ciclo clásico fue diseñado para contrarrestar los modos de fallo humanos (ego, fatiga, olvido) que están ausentes en los LLM. Cataloga ocho modos de fallo estructurales (F1-F8) y cinco propiedades explotables (E1-E5), y expone el principio fundacional: cada fase de un ciclo agéntico debe remontarse a un modo de fallo contra el que se defiende o a una propiedad que explota.
Un artículo de arXiv (cs.SE) de Martin Monperrus que defiende una tesis radical para el SDLC: los agentes de codificación han superado un umbral de capacidad tal que **la revisión de código humana ya no es un componente necesario** de un pipeline de calidad. Dos afirmaciones: (1) los sistemas autónomos basados en LLM alcanzan todos los objetivos de la revisión (detección de defectos, calidad, cumplimiento) con menor coste y mayor rendimiento; (2) el modelo híbrido "el agente escribe, el humano revisa" es insostenible — no garantiza una calidad real y no escala al ritmo de la velocidad de la IA, generando una "falsa sensación de seguridad". Monperrus contrasta la inspection de Fagan (1976) con un **pipeline de verificación adversarial multi-agente** (agente generador + agentes revisores independientes + tests/métodos formales + consenso basado en voto). El humano se reenfoca en la especificación, las decisiones arquitectónicas, la aprobación de dominios críticos y los casos límite. Recomendaciones: pilotar primero en componentes de bajo riesgo, medir agente frente a humano, hacer explícitas las decisiones de rechazo.
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
Tribuna de opinión de **Olivier Rafal** (Director de Consultoría Estrategia, **WeNvision** — grupo **SFEIR**; exredactor jefe de *Le Monde Informatique*) publicada el **1 de junio de 2026** en **CIO-Online**, estructurada en torno a una **paradoja**: en la era de la IA, la ingeniería de software **lo cambia todo… y no cambia nada**. **Lo que cambia es el modelo operativo.** Los roles se redefinen: el **Product Owner** pasa de la descomposición del backlog a **generar contexto utilizable por la IA**; el **desarrollador** pasa de escribir código a **enmarcar, dirigir y revisar** la ejecución de los agentes; el **QA** adquiere la capacidad de definir de antemano la **prueba esperada**. La estructura de los equipos pasa de los *"double pizza teams"* (cadenas de traspaso de ~8 personas) a los ***"sandwich teams"***: un **binomio estrecho formado por un experto de negocio y un tech lead, ambos potenciados por IA**, con otras competencias en apoyo. Cifra interna de **Sfeir**: *"este binomio impulsa ahora aproximadamente el 80% de la cadena de producción"*, quedando el ~20% restante (arquitectura, gobernanza de datos, seguridad) centralizado. Cita pivote: ***"El problema no es un problema de herramientas, es un problema de modelo operativo."*** **Lo que no cambia es la disciplina del ciclo.** Las fases del **SDLC** (definir → construir → verificar → desplegar → mantener) permanecen idénticas y no negociables; la IA no elimina ninguna, las **intensifica**: ***"todo el margen que el ritmo humano solía absorber, aunque fuera de forma imperfecta, se convierte, a la velocidad de la IA, en defectos de nivel industrial"*** (una metáfora del deporte amateur frente al profesional). De ahí **tres *gates* inviolables** (control humano): **especificación, planificación, revisión de entrega**; validación **por prueba** (no por las propias afirmaciones de la IA); **capitalización sistemática** (cada ciclo alimenta al siguiente) → resultado medido: **−30% de iteraciones de corrección tras ~10 ciclos**. Principio: ***"cuanto más rápida la ejecución, más estricto debe ser el marco."*** Conceptos invocados: el **harness** (reglas agénticas adaptadas al contexto), el **vibe-coding** calificado de **insostenible en la empresa**. **Tercer pilar = gobernanza, FinOps y gestión orientada al valor**: costes de IA **variables y recurrentes** (~**10 €/hora** por rol potenciado), paso de la licencia a tarifa plana a la facturación por uso (un paralelismo con la nube de la década de 2010); el **FinOps** no busca recortar costes sino *"optimizar la eficiencia de las herramientas"* (coste en relación con el valor); alineación previa de las **métricas de negocio** (time-to-market, funcionalidades, rendimiento, ecodiseño). **Conclusión**: la aceleración hace que los fundamentos sean **no negociables**; el reto es **organizativo y cultural**, no tecnológico — sin asegurar la relación con el negocio y la disciplina colectiva, un SDLC potenciado por IA no hace más que **amplificar los problemas** (chocar contra el muro más rápido). Prolonga la doctrina de WeNvision de [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] y [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; converge con *los sistemas alrededor del modelo* dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28, la *harness engineering* osmani-agent-harness-engineering-2026-04-19, el Salesforce agéntico, y el debate sobre el *agent manager* (BFM/Girard, SFEIR).
#ingeniería de software#IA#todo cambia nada cambia
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (groupe **SFEIR**). Ancien **rédacteur en chef du *Monde Informatique*** · et auparavant consultant analyste du marché IT (~10 ans). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Publié le **1er juin 2026**.
Manual de referencia de compound engineering: bucle agéntico de 7 pasos (Ideate→Brainstorm→Plan→Work→Review→Polish→Compound), plugin de 40+ agentes, escala de adopción de 5 niveles, regla 50/50 — Kieran Klaassen (Cora / Every) - Every Source Code
#compound engineering#filosofía nativa de IA#bucle de 7 pasos
Kieran Klaassen (avec Claude & GPT crédités co-auteurs du guide complet)
Every Marketplace - Compounding Engineering Plugin - Claude Code - GitHub - Flujo de Trabajo de Desarrollo con IA - Calidad del Código - Reducción de Deuda Técnica
#Compounding Engineering#Claude Code#Desarrollo con IA
EveryInc (Organization) · Contributors from Every.to engineering community
8 estrategias de planificación con IA - Agentes de investigación en paralelo - Anclaje en el código base - Historial de git - Prototipado vibe - Agentes de estilo - Compounding engineering - Every Source Code - Kieran Klaassen
#estrategias de planificación#agentes de investigación#operaciones en paralelo
Planificación vs Vibe Coding - Compounding Engineering - Three Fidelities - Agentes de IA - Cora Email Bankruptcy - Plans Teach Systems - Every Source Code