Ensayo de **Donn Felker** publicado el **14 de septiembre de 2026** en su Substack (~4.400 palabras, subtítulo *"Your identity was built on a bottleneck"*). El autor, responsable de plataforma IA en **Polygon** y antiguo empleado de **Tinder**, especialista en Android durante más de diez años, data su cambio en **julio de 2025** a partir de tres hechos: una SaaS construida sin escribir una sola línea, una migración de una librería de threading en Tinder reducida de **6-8 horas** a **10 minutos** mediante un prompt de **2.000 palabras**, y personas no técnicas (un CFO, un gestor de gimnasio) lanzando productos completos. **(A)** A partir de esto propone un marco psicológico —*occupational categorization*, *professional identity centrality*— para explicar la ansiedad de los ingenieros: *"It was never about coding, it's about the ability to execute"*. **(B)** Propone una imagen de **péndulo de apalancamiento** entre producto e ingeniería: la IA desplaza el apalancamiento inicial hacia producto, la complejidad y la escala lo devuelven hacia ingeniería, y cada oscilación se amortigua a medida que se codifican los guardrails y la arquitectura. **(C)** Describe un rol híbrido, el **agentic builder**, y una trayectoria en dos pasos (codificar el propio conocimiento en skills, pasar de un pensamiento de especialista a un pensamiento sistémico) con un horizonte declarado de **seis meses**. Extiende el cambio hacia la *agentic engineering* descrita en [[karpathy-vibe-coding-agentic-engineering-software-3-0-2026-04-29]] y el colapso de las fronteras entre profesiones de [[sfeir-ia-frontieres-metiers-skill-based-organisation-2026-08-01]].
Informe de experiencia publicado en **LinkedIn Pulse** el **12 de agosto de 2026** por **Guillaume Dumortier**, en su newsletter *Growth Marketing Fit*, subtitulado *« Cuatro capas, mucha reconstrucción y los modos de fallo de los que nadie te advierte »*, ~2.500 palabras. El tema: un sistema de IA interno construido **en Claude** para un equipo de marketing de unas sesenta personas — alrededor de treinta **skills** de contenido y ventas, una decena de **módulos de fuente de verdad**, **siete agentes, seis de los cuales existen únicamente para verificar el trabajo en lugar de producirlo**, un **plugin** para quienes viven en una terminal, una **aplicación de navegador** que porta el mismo conocimiento para el resto, y una orquestación que encadena tres o cuatro activos en un *campaign bundle*. La tesis se plantea desde el principio: la calidad de una salida de IA no se determina en el momento de la generación, sino por lo que el sistema sabe antes de empezar y por lo que ocurre con el borrador después — *« El paso de generación en el medio es la parte fácil. También es la única parte que la mayoría de los equipos han construido. »* De ahí cuatro capas: **Verdad** (casi nadie la construye), **Producción** (todo el mundo), **Verificación** (casi nadie), **Distribución interna** (*« donde los buenos sistemas mueren por negligencia »*). Dos mecanismos de fallo sostienen el artículo. **(A) El « pass » desnudo de mundo cerrado del verificador**: un fact-checker respaldado por documentación de producto recibe un borrador que contiene una afirmación sobre otro producto, uno que sus fuentes no cubrían — devuelve un *« pass »*, no porque la afirmación fuera cierta sino porque nada la contradecía. *« No solo pasó por alto el error, lo certificó. »* Solución: prohibir un veredicto desnudo y exigir que cada informe declare su **propia cobertura** — cuántas afirmaciones se verificaron, cuántas se relacionaron con fuentes, cuáles quedaron fuera de su jurisdicción, cuáles no pertenecían a ninguna fuente. *« "No puedo verificar esto" se convirtió en un resultado de primera clase. »* **(B) La contradicción entre activos**: dos activos pueden ser individualmente correctos, cada uno trazable a una fuente real, y aun así contradecirse entre sí — el comunicado de prensa indica una fecha, la entrada de blog otra, ambos pasan, el bundle no puede publicarse. *« La verificación por activo individual no puede detectar eso, por construcción. »* Cláusula de cierre del artículo: *« La generación es gratis. La confianza es el producto. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
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