Stanford HAI - AI Index - Informe anual - Tendencias del sector - Métricas de investigación - Desarrollo global de la IA
Stanford Human-Centered AI Institute (HAI)
Google AI Mode - Transformación de la búsqueda - Sitios personalizados - Búsqueda generativa - Web generativa
Robby Stein (Google)
AEO (Answer Engine Optimization) - SEO - Motores de respuesta de IA - Graphite
Graphite.io Team
Personal Software - AI-Customized Applications - Future of Software - Lee Robinson
Lee Robinson
Artículo del blog de Sierra (10 de diciembre de 2024, Elliot Greenwald) que expone el **texto fundacional del *outcome-based pricing*** para agentes de IA. **Tesis pivote**: los agentes de IA que ejecutan procesos de forma autónoma hacen posible un **modelo de precios completamente nuevo** — ***"solo pagas cuando el software logra resultados específicos y valiosos: outcome-based pricing."*** El artículo traza una **genealogía en cuatro eras de los precios del software**: (1) **software en caja precintada** (años 80-90, la caja de disquete/CD-ROM en Fry's Electronics — *"Lo hayas usado o no, lo pagabas"*) → (2) **SaaS / precios por asiento** (pionero por **Salesforce**, seguido por Google/Microsoft/Adobe — Internet hace posible vender el software *como servicio*) → (3) **precios por consumo** (**Amazon/AWS** y **Snowflake** — *"se cobraba solo por lo que se usaba"*) → (4) **precios por resultado** (agentes de IA). **Definición canónica**: ***"el outcome-based pricing está vinculado a impactos empresariales tangibles — como una conversación de soporte resuelta, una cancelación evitada, un upsell, un cross-sell, o cualquier número de resultados valiosos. Si la conversación queda sin resolver, en la mayoría de los casos, no hay cargo."*** **Principio de incentivos alineados**: ***"Con el outcome-based pricing, Sierra solo cobra cuando completamos una tarea para ti. Nuestros incentivos están alineados."*** **Crítica del precio por asiento y el concepto de *shelfware***: *"Los asientos no utilizados permanecen ociosos en un proverbial estante de tienda, de ahí el apodo despectivo 'shelfware'"* — se pagan miles de dólares al año por licencia, se use o no. **Conflicto estructural para los Fournisseurs CX legacy**: sus ingresos dependen del precio por asiento, y sin embargo *"cuanto más eficaz se vuelve su IA, menos asientos de centro de contacto necesitan sus clientes — socavando el propio modelo de ingresos del proveedor"* — un agente de IA eficaz **canibaliza** el modelo de ingresos de un proveedor cuyos precios se basan en asientos. **Granularidad del resultado**: una distinción entre **resoluciones simples** (responder una pregunta) y **resoluciones complejas** (gestionar un caso que requiere una llamada L2 de 20 minutos); las **escaladas por lo general no generan cargo**; es posible un **precio combinado (blended)** (por ejemplo, por consumo para interacciones de enrutamiento/saludo). **Compromiso de optimización continua** por parte del proveedor: *"seguimos desplegando optimizaciones concertadas y dirigidas para refinar el rendimiento del agente con el tiempo"* — el proveedor permanece alineado para mejorar el rendimiento ya que solo se le paga por el resultado. Relevancia: planteado a **finales de 2024**, este artículo **precede y fundamenta** todo el debate de 2026 sobre la economía agéntica — aporta el **vocabulario de la unidad de facturación** (el *resultado* completado en lugar del asiento, el uso o el token) que más tarde retomarán Gupta (*coste de un resultado completado*, *atribución token-a-resultado*), Bain (*el outcome-based pricing desplaza los ingresos de asientos fijos hacia la economía de mano de obra/operaciones*), Ng (*poder de fijación de precios anclado en el salario del empleado sustituido*). Con Sierra como el **ejemplo de referencia** citado por Bain (*resolución autónoma de incidencias de clientes*), este texto ofrece la **visión desde el lado del proveedor** de la mecánica que otros analizan desde el lado del comprador. Directamente relevante para el posicionamiento de la firma en **entrega agéntica / precios basados en valor** y para el bloque de **Cost Optimization** (la contraparte del lado proveedor del *coste por resultado*).
**Elliot Greenwald** — Sierra (entreprise fondée par Bret Taylor & Clay Bavor, plateforme d'agents IA conversationnels pour l'expérience client). Billet publié sur le blog Sierra le **10 décembre 2024**. Sierra est l'**exemple-référence** cité par Bain (*The $100-Billion SaaS Opportunity*) pour l'*autonomous customer issue resolution* · et fait l'objet de plusieurs fiches du dossier (recrutement AI-native, interview Plan/Build/Review).
Kent Beck - Vibe Coding - TDD - Desarrollo asistido por IA - Artesanía del software - LinkedIn - Metodología ágil
Kent Beck
LightRAG - RAG Simple y Rápido - Grafos de Conocimiento - Recuperación de Doble Nivel - EMNLP2025 - GitHub
Zirui Guo · Lianghao Xia · Yanhua Yu · Tu Ao · Chao Huang (HKUDS - Hong Kong University Data Science)
Planificación estratégica para los futuros imposibles de la IA y la AGI - One Useful Thing - Ethan Mollick
Ethan Mollick · Professeur à la Wharton School · University of Pennsylvania
NuExtract NuMind - modelo fundacional para extracción estructurada en JSON, formato compacto
Alexandre Constantin · Liam Cripwell · Etienne Bernard
Estudio de caso oficial de OpenAI sobre el despliegue de ChatGPT Enterprise en Moderna: 750 GPTs en 2 meses, 100% de adopción en el departamento legal, el GPT Dose ID para ensayos clínicos, la cita de Stéphane Bancel sobre "100.000 empleados", un marco de transformación organizativa (mChat, Generative AI Champions, un foro interno con 2.000 participantes).
OpenAI (étude de cas officielle, citations Stéphane Bancel, Brad Miller, Brice Challamel, Shannon Klinger, Kate Cronin, Meklit Workneh)
Ethan Mollick - Adopción de IA - Cambio organizacional - One Useful Thing - Wharton - Investigación académica - Gestión
Ethan Mollick (Wharton School)
Sebastian Raschka - Aprendizaje Automático - Libro - Educativo - Deep Learning - PyTorch - Práctico
Sebastian Raschka
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.
**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**.
Weave (workweave.dev) - Startup de Y Combinator - Medición del trabajo de ingeniería impulsada por IA - Weave Hour - Atribución de código de IA - Directorio YC
Y Combinator
METR - Seguridad de la IA - Replicación autónoma - Agentes de IA - Evaluación de riesgos - Riesgo existencial - Alineación
METR (formerly ARC Evals)
Crisis de sentido en el trabajo - Botón "Help me write" - Prender fuego al tiempo - Señales de esfuerzo - Cartas de recomendación de IA - Ethan Mollick - One Useful Thing
Ethan Mollick
**Mathieu Eveillard** publica en su blog personal el **7 de diciembre de 2022** (última actualización el 17 de marzo de 2025) una **contraargumentación punto por punto** al célebre ensayo de **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Artículo categorizado **craft / best-of**, una postura de **artesano del software** que defiende el **Test-Driven Development** sin dogmatismo. **Distinción crucial** que a DHH se le escapa según Eveillard: ***"Test-first"*** (escribir todos los tests antes de cualquier código) frente a ***"Test-Driven Development"*** (los tests me **guían** en la escritura del código, de modo que cada vez escribo un fragmento de código *"en reacción"* a un nuevo test). DHH en realidad critica el *Test-first* llamándolo TDD — una confusión que **oculta una forma de programar completamente distinta**. **Respuestas punto por punto**: (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concede el punto deontológico pero redefine el *"buen código"*: no solo la ausencia de bugs sino **tests unitarios de grano fino** que documentan el comportamiento en el nivel más bajo, ubicados junto al código, una **red de seguridad**; (2) *"Rebalance from unit to system"* — TDD **no dice nada** sobre los tests de sistema y **no dice** que no haya nada fuera de TDD; los tests de sistema **no sustituyen** a los tests unitarios (una declaración de la renta probada de extremo a extremo no tiene sentido); **pirámide de tests** — cada tipo aporta su parte, los tests unitarios para un feedback de **milisegundos** + detección temprana de bugs; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard responde que **no observa estos efectos en programación funcional**, por lo que el efecto probablemente se deba a la **POO**, no al TDD; pero concede que una inyección de dependencias excesiva puede acoplar test e implementación. **Conclusión equilibrada**: *"TDD is not a religion, it's a tool"*. TDD es especialmente adecuado para el **código de dominio** (el núcleo funcional de un *bounded context*, el *core del hexágono*) — motores de cálculo, reglas de negocio de grano fino, casos límite por doquier — ***"30% del código base como máximo"***. Menciona la **Law of the Instrument** (si la herramienta no ayuda, es porque has caído en ella). **Relevancia para el corpus**: un **artículo de craft ajeno al corpus de IA** pero que vale la pena archivar para situar los debates actuales sobre agentes de codificación (*Augmented Coding Beyond Vibes* de Beck, 2025-06-25, Vibe Coding vs TDD, la *atrofia del músculo de la escritura* de Frizzo) dentro del linaje histórico de los debates de craft en torno al TDD. Para usar como **base de biblioteca** para sesiones de formación.
**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).
Keynote de **Gregor Hohpe** (Enterprise Strategist en AWS, autor de *The Software Architect Elevator* y del próximo libro *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) en **PlatformCon 2022** sobre **la magia de las plataformas** — por qué las plataformas triunfan, qué las distingue de la mera *IT Service Management*, y **las decisiones de arquitectura no triviales** que hay que tomar al construir una. **Tesis pivote**: *"los estándares no reducen la creatividad, pueden multiplicarla"* — análoga al incendio de Baltimore de 1904 (bombas incompatibles), el tornillo métrico ISO, HTTP, el papel A4. **Cita canónica tomada de Peter / Thoughtworks**: ***"las plataformas centralizan la experiencia pero no la innovación"*** — la rueda no se reinventa, pero la innovación queda en manos de los equipos más cercanos al cliente. **Analogía pivote**: la industria automotriz (Volkswagen Group construye el Audi A4 y el Bentley Bentayga sobre la misma plataforma), *"undifferentiated heavy lifting"* (vocabulario de AWS) bajo el capó, diferenciación visible del lado del cliente. **Tres propiedades de una verdadera plataforma**: (1) **baja fricción** — la adopción no puede forzarse, los equipos buscarán atajos; (2) **transparencia** (no una *caja negra*) — los usuarios deben poder diagnosticar si el fallo es suyo o de la plataforma; (3) **responsabilidad compartida** (referencia directa al *AWS Shared Responsibility Model*) — la plataforma no corrige una aplicación mal diseñada. **Antipatrón explícito**: *"una capa común puede ser muchas cosas — no es necesariamente una plataforma"*; el IT Service Management tradicional tiene la misma imagen (una capa común debajo de todos) pero la **interfaz es la opuesta** (alta fricción, formularios, cuello de botella). **Dos caminos de construcción**: (a) anticipar cada necesidad (Hohpe: *"no me siento lo bastante inteligente"*); (b) **evolución** a partir de piezas útiles, observando el uso. **Decisiones que hay que explicitar**: objetivos (carga cognitiva ↓, más seguro / menos errores, más rápido vía samples/blueprints/self-service, compliance), forma de la curva de aprendizaje (acantilado, palo de hockey, cambio de marcha). **Concepto canónico #1 — Floating platforms vs Sinking platforms**: cuando la *base platform* (típicamente la nube) gana nuevas capacidades, **dos estrategias opuestas**: **sinking platform** (estática, duplicando lo que la base ya ofrece, hundiéndose a medida que sube el nivel del agua) vs ***floating platform*** (descarta las piezas que se han vuelto redundantes, **se eleva por encima del nuevo nivel**, innova más arriba). Metáfora del *"submarino y el barco"*. Fuerte implicación contractual: **advertir explícitamente a los stakeholders** de que los componentes se eliminarán en cuanto la base los absorba. **Concepto canónico #2 — Fruit salad vs Fruit basket**: una plataforma no es una colección de capacidades yuxtapuestas (una cesta) sino un ensamblaje **proporcionado, en trozos pequeños** donde las piezas interactúan — *"el precio por kilo de la macedonia de frutas es más alto que el de la cesta de frutas"*. El título deriva de la frase *the magic of platforms* — el efecto contraintuitivo por el cual **estandarizar libera la innovación en lugar de ahogarla**, siempre que la interfaz, la evolución y la integración entre componentes se manejen con cuidado. Relevante para: arquitectos de plataformas, **equipos de Platform Engineering / IDP 2026** (una referencia fundacional, anterior al auge de las *Internal Developer Platforms* pero que estructura su vocabulario), CIOs que evalúan build-vs-stagnate frente a las capacidades nativas de la nube, comités ejecutivos de producto. Converge con **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — la plataforma como pilar sistémico).
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).
Técnicas de comunicación oral, presentación académica, heurísticas de expresión oral eficaz
Patrick Winston
Artículo enciclopédico (Wikipedia, en inglés) sobre la **ley de Goodhart**: enunciada por el economista británico Charles Goodhart en 1975 a propósito de la política monetaria — "cualquier regularidad estadística observada tiende a colapsar en cuanto se ejerce presión sobre ella con fines de control" — y luego generalizada por la antropóloga Marilyn Strathern (1997) en el aforismo canónico "cuando una medida se convierte en un objetivo, deja de ser una buena medida". El tema conecta la economía, la teoría de los incentivos, la evaluación de políticas públicas y, por extensión, la optimización de métricas en los sistemas de IA.
Wikipedia contributors (concept : Charles Goodhart ; généralisation : Marilyn Strathern)