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).
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".
Tribuna de opinión de **Olivier Rafal** (Director de Consultoría en Estrategia en **WeNvision**) publicada el **23 de febrero de 2024** en **CIO-Online** (sección *Tribune*), que defiende una tesis entonces todavía contraintuitiva: **la IA generativa es más una cuestión de producto tecnológico que un proyecto de IA/ciencia de datos**. **Argumento 1 — la ciencia de datos no es el problema central**: construir un *foundation model* desde cero requiere *«varios meses, millones de euros y acceso a cantidades enormes de datos»* — algo reservado a actores con conjuntos de datos específicos y monetizables (por ejemplo, **Bloomberg** y su **BloombergGPT** para las finanzas). Para casi todas las empresas, el reflejo correcto no es, por tanto, contratar científicos de datos. **Argumento 2 — desajuste de competencias**: lo que se necesita principalmente son **ingenieros de desarrollo e integración** (back/front), **sólidas competencias cloud** y **DevOps**. Cita de un cliente: *«No hace falta necesariamente ser científico de datos, pero sí entender los conceptos básicos, tener competencias de desarrollo back-office y sólidas competencias cloud.»* **Argumento 3 — arquitectura de plataforma (orquestadores + API)**: construir una **plateforme d'IA générative** empresarial mediante orquestadores y API permite *«trabajar con los mejores LLM del mercado y cambiar entre ellos a medida que evolucionan sus respectivas capacidades, sin tener que rehacer las aplicaciones»* (anti vendor lock-in). **Argumento 4 — del proyecto al producto**: *«La plataforma […] debe considerarse como un producto de pleno derecho»*; en lugar de una inversión puntual, hay que prever un **flujo de financiación mensual** (iteración continua, innovación permanente). **Argumento 5 — gobernanza y shadow AI**: la democratización sin precedentes de la IA generativa genera *«tanta shadow AI como fuertes expectativas hacia el CIO»* → gobernanza para captar las necesidades de negocio, **priorizar los productos por valor** y supervisar su correcto funcionamiento. **Cambio de paradigma** anunciado: *«se pasa de la programación algorítmica clásica a agents Langchain que gestionan parte de las decisiones»*. **Relevancia para la veille**: un **texto fundacional (con 2 años de anticipación)** de la doctrina de WeNvision (producto > proyecto, plataforma/API, financiación en flujo, gobernanza, shadow AI), ampliado más tarde por [[wenvision-ai-agents-enterprise-deployment-2025-10-01]], [[habert-ia-agentique-production-2025-10-29]] y rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04 (FinOps/token, financiación en flujo → gobernanza financiera). También prefigura el *harness/plataforma en torno al modelo* (Dropbox/Okumura: *systems around the model*) y la **independencia de modelo** lograda mediante una capa de orquestación.
#IA generativa#producto tecnológico#producto vs proyecto
**Olivier Rafal** · *Consulting Director Strategy* chez **WeNvision** (cabinet de conseil FR). Tribune publiée dans la rubrique *Tribune* de **CIO-Online**. Auteur déjà présent dans la veille (cf. fiches WeNvision/Atlas/Tokenomics). Publié le **23 février 2024**.