Publicación en X de **Andrew Ng** del **14 de agosto de 2026** (16:29 UTC), que retoma la carta «Dear friends» de ***The Batch* #366** (DeepLearning.AI, misma fecha), ~900 palabras. Ng presenta **The AI Engineering Skills Map** y publica **cuatro habilidades** consideradas las más importantes. **(1) Construir y desplegar aplicaciones de IA** — se nombra la especificidad: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, de ahí el énfasis en los *evals* y los bucles de análisis de errores. **(2) Fundamentos de ingeniería de software**, porque *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — el desarrollador inexperto fracasa *« because they don't know what context to give their coding agent »*, de ahí el objetivo de *« steering coding agents using the precise language of software engineering »*. **(3) Uso de agentes de codificación**, en una formulación operativa: *« help the agent autonomously close loops by providing verifiers or evals »*, y *« knowing how much to intervene and how much to leave them alone »*. **(4) *Shaping the build***: *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, junto con *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Una **nota terminológica** aporta la mayor parte del enfoque: Ng habla de **habilidades** en ingeniería de IA y **no del rol** "AI Engineer", con una analogía explícita — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* El conjunto se apoya en *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, de la cual **no se publica ningún resultado numérico**: Ng describe su proceso como *« informally… akin to running clustering »* y anuncia un mapa detallado en futuras publicaciones. Declara el interés en la penúltima frase: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#mapa de habilidades#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
Página de referencia publicada en **eventuallycoding.com** el **28 de julio de 2026** por **Hugo Lassiège** (Lyon, desarrollador convertido en emprendedor, autor de Bloggrify, Hakanai y Writizzy). El autor la presenta así: *«Esto será más una página de referencia que un artículo»*, pensada para su propia página de recursos. **Tema**: una descripción exhaustiva y detallada de una **fábrica de software en solitario** donde *«el código producido es ahora casi 100% generado»*, en varios monorepos políglotas (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **despliegue continuo a producción**. **Distinción planteada de entrada**: esto no es **vibe coding** en el sentido de Karpathy (experimentación, dejarse llevar) sino context engineering — *«dar todo el contexto necesario, en el momento adecuado, para que el software se ajuste a una intención y esté sistemáticamente controlado»*, con la frase que fundamenta la responsabilidad: *«Aunque no escriba el código, soy responsable de él y debo mantener el control sobre él»*. **Todo el conjunto de herramientas responde a tres preguntas**, y esta es la grilla de lectura más reutilizable del texto: *«¿Qué sabe el agente?»* (contexto, memoria, grafo de código) — *«¿Qué sabe hacer de forma determinista, sin improvisar?»* (skills, procedimientos) — *«¿Qué lo detiene cuando se equivoca?»* (hooks, tests de arquitectura, quality gates). **Seis capas detalladas**: (1) **contexto** — `CLAUDE.md` raíz + `.claude/rules/*.md` temáticos cargados condicionalmente vía `paths:` + `.agents/*.md` para asuntos no técnicos (personas, posicionamiento, tono); (2) **skills** — una treintena, criterio de existencia *«si explico lo mismo una tercera vez»*; (3) **herramientas** — MCP del IDE de JetBrains, **GitNexus** (grafo de código: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper de filtrado RTK, Sentry, base de datos de solo lectura; (4) **guardrails ejecutables** — hooks del harness, **tests de arquitectura**, linting de patrones (**ast-grep** para decisiones de arquitectura, no solo ESLint); (5) **fábrica** — quality gate bloqueante con `needs:` sobre el job de calidad, cinco etapas de pruebas; (6) **proceso de producto** — specs numeradas con una skill de redacción **y una skill de cierre**, diseño en Claude Design, entrega escalonada tras feature flags, distinción entre **feature flipping** (Unleash) y **gating** (contrato con el cliente). **La regla que lo resume todo**: *«Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayoría de las veces'… Un hook o un test se sigue siempre»*. **Una rareza para el género**: una sección «Por mejorar» que expone cuatro limitaciones vividas — la **imposibilidad de medir la obsolescencia de una regla** (*«no tengo forma de saber si una regla antigua se ha vuelto obsoleta»*), el **rabbit hole** creado por una regla boyscout, la **falta de empaquetado** de las skills entre proyectos, y sobre todo la admisión de tensión: *«cada vez soy menos útil durante las fases de implementación»*, *«dividido entre la satisfacción de tener una fábrica cada vez más eficiente y el riesgo de perder conocimiento»*.
#fábrica de software#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
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".
Digesto de vigilancia tecnológica de fuentes primarias sobre la posición de **Gregor Hohpe** (autor de *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; antiguo AWS & Google Cloud Enterprise Strategist, antiguo Chief Architect en Allianz) respecto al papel del arquitecto en la era de la IA generativa. Tesis: la IA **no devalúa** al arquitecto, **desplaza su valor** del código hacia lo que la IA no hace — **tomar y asumir decisiones, arbitrar compromisos, "vender opciones", comunicarse con humanos, producir abstracciones sólidas**. Fórmula clave (Craft Conference 2026): "*Los desarrolladores interactúan principalmente con máquinas… GenAI. Los arquitectos, en cambio, se comunican con humanos*". Su tesis distintiva (el arquitecto no debe ser la persona más inteligente de la sala, debe **hacer que todos los demás sean más inteligentes**) se refuerza a medida que el código se vuelve abundante: la ventaja proviene de la **disciplina en la toma de decisiones** y de **sacar a la luz los compromisos ocultos**, no del volumen. El digesto también desglosa sus posiciones por rol (arquitecto empresarial: de **cartógrafo a explorador**; arquitecto de software: **depurar** decisiones en lugar de escribir código; arquitecto de plataforma: **abstracciones, no ilusiones**), su metáfora de las **opciones reales** (valor que aumenta con la volatilidad tecnológica, analogía con Black-Scholes), y sus advertencias ("*Un SDLC impulsado por IA castiga los malos hábitos mucho más rápido*"; los ganadores de la IA se definirán por la rapidez con la que pasen de la experimentación a la **producción gobernada**). ⚠️ La fórmula ampliamente difundida "los arquitectos que usan IA reemplazarán a los que no lo hacen" **no es de Hohpe**. Dominio: arquitectura de software, el papel del arquitecto, toma de decisiones, opciones reales, plataformas, GenAI en el SDLC.
#Gregor Hohpe#Architect Elevator#papel del arquitecto
Gregor Hohpe (sources primaires) — digest de veille
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.
Guía del medio **Every** (every.to/guides) publicada el **2 de junio de 2026**, firmada conjuntamente por **Mike Taylor, Laura Entis y Claude**, que propone una **escala de madurez de 8 niveles para la adopción de IA**. **Tesis central**: la adopción de la IA **no es una carrera hacia la máxima sofisticación** — ***« un nivel más alto no es necesariamente mejor »*** ; hay que identificar el nivel que **se ajusta al propio flujo de trabajo y nivel de confianza**, y luego reevaluar regularmente si subir un escalón aporta **valor real**. ***« La mejor manera de encontrar valor en la IA es usarla de una forma que encaje con tu trabajo. »*** **Eje estructurante**: en cada nivel, *« delegas más de tu trabajo en la IA, y depositas más confianza en ella »* (delegación + confianza crecientes). **Los 8 niveles**: **(1) Chatbot** — interfaz conversacional sin contexto integrado (ChatGPT, Claude, Gemini); **(2) Copilot** — IA integrada en el espacio de trabajo con acceso al archivo actual (Cursor, Claude en Excel, Gemini en Docs); **(3) Agent** — sistema reactivo que ejecuta paso a paso solicitando aprobación (Cowork, Codex); **(4) Autopilot** — se describe el **resultado** y el agente ejecuta de forma autónoma, revisión únicamente del **resultado final** (Lovable, Codex, Claude Code; vinculado al *vibe coding*); **(5) Workflows** — ingenieros que construyen **harnesses** en torno a los agentes (planificación, revisión, verificaciones de confianza, salvaguardas; Compound engineering, Claude Workflows, Copilot AI Studio; paso del vibe coding puntual → **agentic engineering**); **(6) Assistant** — agentes **proactivos y siempre activos** que monitorizan un dominio y presentan información sin que se les solicite (OpenClaw, Hermes Agent, Claude Managed Agents; p. ej. `heartbeat.md` cada 30 minutos); **(7) Multi-agent** — gestión simultánea de **varios agentes de larga duración** con roles distintos (Claude Managed Agents, OpenClaw, Codex Goals; *« firmemente en el terreno de la ingeniería senior »*); **(8) Orchestrator** — un **gestor de agentes** dirige un equipo de subagentes (planificación, delegación, monitorización, consolidación; Gas Town, Paperclip, Symphony/OpenAI; *« altamente experimental »* — incluso los propios ingenieros de vanguardia ocupan este rol). **Puntos óptimos por rol**: los **trabajadores del conocimiento** suelen operar entre los niveles **1-4**, los **ingenieros** entre **5-8**. **Paralelismo canónico con la incorporación de un becario**: *« Espera invertir un esfuerzo similar con tus agentes antes de poder confiar en ellos… en el siguiente nivel de autonomía »* ; y la frase marcadora ***« No presumirías de tener ocho becarios trabajando toda la noche en un proyecto clave sin haber revisado su trabajo. »*** El nivel adecuado depende de **4 criterios**: calidad del resultado, coste, fiabilidad (confianza), riesgo en caso de fallo; y la **capacidad del modelo** desplaza progresivamente el nivel de autonomía "seguro". Un marco directamente utilizable para estructurar una **doctrina de adopción** en el ámbito de la consultoría. Convergencia con *los sistemas alrededor del modelo* (Dropbox/Okumura), la *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines), y la doctrina del *agent manager* (BFM/Girard).
#adopción de IA#escala de madurez#ocho niveles
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Continuous Delivery como base innegociable del desarrollo asistido por IA — Dave Farley, en su canal *Modern Software Engineering*, sostiene que sin CD la IA no es un acelerador sino una trampa (teoría de las restricciones y paradoja de Jevons aplicadas al código generado, ATDD/BDD como salvaguarda, pipeline de despliegue como árbitro de calidad).
#Continuous Delivery#IA generativa en el SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)
Podcast de Greg Isenberg × Meng To (diseñador, fundador de Design+Code, creador de los productos Aura / New Form / Dream Cut) sobre **`design.md`** — la convención de código abierto de Google, equivalente a `agents.md` / `skills.md` / `soul.md` pero **para el sistema de diseño** (tipografía, colores, espaciado, animaciones WebGL/Three.js, reglas de revelado). Idea central: transportar el "**alma del diseño**" en un archivo markdown que se entrega a un agente (Claude Code, Codex, OpenClaude, Gemini, Stitch, Aura, V0, Lovable, Cursor) para preservar la **coherencia entre medios** (web, móvil, Replit slides, motion design con Hyperframes/Remotion). Tríada enseñada: **HTML = plato terminado, design.md = receta, skills = ingredientes** (tipografía, láseres, skeuomorphic, skills 3D — 63 en New Form). Diagnóstico principal: **design drift** en los flujos one-shot (`v0`, Lovable, Framer) que empiezan fuerte y luego derivan hacia una salida genérica. Metamensaje: el *gusto* (taste) es el único **moat** que queda — *"si algo se parece a otra cosa, su valor cae de 10× a 100×"*. Flujo de trabajo: **Reference → Design.md → Generate → Inspect → Systemize → Iterate (hasta más de 1000 prompts) → Remix → Expand → Export**. Crítica de los **gradientes morados** ("you just run") como la base genérica post-vibe coding. Meng To afirma haber gastado ~500.000 $ en tokens, haber ejecutado entre 1.000 y 10.000 iteraciones por producto, y haber gestionado 4 productos en paralelo en solitario.
#design.md#Google#sistema de diseño
Greg Isenberg (host — podcast Late Checkout / The Greg Isenberg Show, 12 mai 2026 livestream workshop ideabrowser.com) ; **Meng To** (guest — designer, fondateur Design+Code 2014, créateur Aura / New Form / Dream Cut, autodidacte parti à 18 ans, dropout, francophone d'origine canadienne)
Whitepaper de Google (la entrega "Day 1" de una serie, de Addy Osmani, Shubham Saboo y Sokratis Kartakis) que traza la transformación del ciclo de vida del desarrollo de software (SDLC) en la era de los agentes de codificación. Tesis: el cambio fundamental no es un nuevo lenguaje, sino el paso de escribir código a **expresar intención**. El documento plantea un espectro que va del *vibe coding* (proponer y aceptar) a la *agentic engineering* (la IA implementa bajo restricciones, pruebas y bucles de retroalimentación diseñados por humanos), con la **context engineering** como habilidad central, el modelo de **software factory** (el entregable del desarrollador = el sistema que produce el código), la **harness engineering** (Agente = Modelo + Harness), y un análisis económico CapEx/OpEx del coste total de propiedad.
Entrevista con Andrej Karpathy (cofundador de OpenAI, ex Tesla Autopilot) sobre el paso de *vibe coding* a *agentic engineering*: December 2025 transition como punto de inflexión ("nunca se sintió más rezagado como programador"), la taxonomía Software 1.0/2.0/3.0, el ejemplo openclaw (script bash → texto para copiar y pegar en el agente) y MenuGen vuelto obsoleto por Nanobanana de Gemini, la teoría de la *verifiability* que explica por qué los LLM son *jagged* (picos en matemáticas/código, fallo al "caminar a un lavadero de coches a 50 m"), la distinción entre *vibe coding* (elevar el piso) y *agentic engineering* (preservar el estándar de calidad), la metáfora "animales vs fantasmas", la refundación de la contratación mediante proyectos agente contra agente, y la fórmula clave: ***"Puedes externalizar tu pensamiento pero no puedes externalizar tu comprensión."***
#Andrej Karpathy#vibe coding#agentic engineering
Andrej Karpathy (co-fondateur OpenAI, ex-Tesla Autopilot, créateur du terme "vibe coding")
Renovación del proceso de contratación de ingeniería en Sierra en la era de los agentes de codificación: entrevista presencial nativa en IA (Plan/Build/Review), eliminación de la prueba de codificación algorítmica, sustitución de la entrevista telefónica por una entrevista de diseño de sistemas, prueba piloto de una entrevista de depuración sobre una base de código existente.
#contratación de ingeniería#entrevista técnica#agentes de codificación
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)
Planificación vs Vibe Coding - Compounding Engineering - Three Fidelities - Agentes de IA - Cora Email Bankruptcy - Plans Teach Systems - Every Source Code
Evolución del rol del desarrollador con la IA generativa, transformación de los roles TI, ingeniería de sistemas, orchestration agentique - Yves Caseau - Michelin - LinkedIn
#desarrollador#IA generativa#generación de código
Yves Caseau (Group Chief Digital & Information Officer chez Michelin)
Deep Research - Revolución AI4* - 6 pilares de la producción de software - Transición de Copilots a Agentes - Paradoja Vibe vs Check - Crisis de FinOps for AI - Gobernanza como ruta crítica - GenAI Landing Zone