Carta «Dear friends» de Andrew Ng en *The Batch* (DeepLearning.AI, número 359) sobre **loop engineering** aplicado al desarrollo de producto **0-to-1**. Ng comparte sus **3 bucles clave** — bucle de codificación agéntica (~minutos), bucle de feedback del desarrollador (~horas), bucle de feedback externo (~días) — anidados por escala temporal creciente, conectando *agente de codificación → especificación de producto/evals → visión del desarrollador → feedback externo*. Tesis central: los humanos conservan una **ventaja de contexto** (más que un «gusto») que hace indispensable el human-in-the-loop; los ingenieros asumen un rol parcial de gestión de producto. Ámbito: agentes de codificación, ingeniería de producto, metodología agéntica.
#Loop engineering#desarrollo de producto#bucle de codificación agéntica
Ensayo extenso de **Shubham Saboo** (X/Twitter) que plantea una tesis sobre el rol del Product Manager en la era de los agentes: la próxima competencia clave no es la **ingeniería de prompts** sino **Loop Engineering** — diseñar un *sistema que mejora con cada ejecución* en lugar de escribir el prompt perfecto cada vez. Un **loop** es un ciclo repetido: cambiar lo que moldea el comportamiento del agente → ejecutarlo → evaluar el resultado → conservar el cambio si la calidad sube, revertirlo en caso contrario → **acumular el aprendizaje** para que la siguiente versión parta con ventaja. Para un PM, el punto de entrada no es el código sino los **artefactos duraderos** que codifican su criterio: skill de revisión de PRD, *summarizer* de llamadas con clientes, rúbrica de evaluación, checklist de lanzamiento, flujo de investigación, `CLAUDE.md`, plantilla de prompt, marco de priorización. Como se reutilizan, estos artefactos **se acumulan en ambas direcciones** — y **derivan** (drift) silenciosamente (un CLAUDE.md que no deja de crecer, un checklist que se ignora…): el modelo no ha empeorado, son los artefactos los que han derivado sin supervisión. Un loop tiene **5 partes**: disparador, acción, **prueba**, memoria, **condición de parada** (la más crítica). Las **evals** se convierten en trabajo del PM (poner a prueba el artefacto con ejemplos conocidos: 3 PRD buenos / 3 malos, 5 llamadas ya comprendidas, 2 lanzamientos pasados). La **memoria** vive en **GitHub** (el repositorio se convierte en "memoria de producto": commits, diffs, resultados de evals, registro de decisiones, rollback). Primer loop recomendado: un **loop semanal de señal de producto** (cada viernes). El criterio (taste) sigue siendo central — pero ahora necesita **prueba**. Cita a Boris (creador de Claude Code): "ya no escribe prompts, escribe loops."
#Loop Engineering#gestión de producto#PM aumentado
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**.