Artículo de **Ethan Mollick** publicado el **31 de agosto de 2026** en *One Useful Thing* (~2200 palabras). Parte de un incidente de seguridad para plantear una cuestión organizativa: ¿cuándo debe una IA pedir ayuda a un humano?
#agencia#agencia#agentes autónomos
Ethan Mollick — professeur à la Wharton School (University of Pennsylvania) · auteur du blog *One Useful Thing* sur Substack.
Ensayo de **Bill Staples**, CEO de **GitLab**, publicado el **24 de agosto de 2026** en el blog about.gitlab.com: una lectura anunciada de **31 minutos**, unos **39.000 caracteres**, presentado como la continuación de un memorando escrito al consejo de administración en enero de 2026 y publicado parcialmente en mayo bajo el título *GitLab Act 2*. El texto se presenta como una respuesta al playbook de SDLC nativo en IA de **Anthropic**, publicado tres días antes, del que toma prestada la frase de apertura —"Code is no longer the bottleneck"— para plantear la pregunta que lo articula: qué se vuelve escaso cuando el código se vuelve abundante. (A) El diagnóstico económico: la unidad útil no es el costo por línea sino el **costo por cambio aceptado**, que agrega generación, entorno, contexto, verificación, revisión, remediación y gobernanza; la IA colapsa únicamente el término de generación, lo que hace que los demás pesen proporcionalmente más — una organización diez veces más rápida generando "simplemente desplazará la cola". (B) La respuesta arquitectónica: cuatro capacidades —plataforma de agentes, ejecución a escala de máquina, contexto duradero, gobernanza— que forman una capa empresarial que sobrevive al modelo, "The model should be replaceable. The agent should belong to the customer." (1) Tres modos coexisten de forma duradera, desde el legado dirigido por humanos hasta el desarrollo autónomo, en contra de la idea de una curva de madurez única. (2) El pipeline de CI/CD se convierte en el lugar donde se ejecuta el bucle interno, en lugar de ser una puerta de control al final de la cadena. Las cifras citadas son las de Stripe, Spotify y Amplitude; GitLab produce una sola, sobre su propio control de fuente. El corpus ya contiene [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la fuente a la que este texto responde, y [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sobre la articulación SDLC/PDLC que Staples adopta como propia.
#abundancia de código#costo por cambio aceptado#teoría de las restricciones
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Guía extensa de **Anthropic** firmada por **Louis Claxton** (equipo Applied AI), publicada el **21 de agosto de 2026** en el blog de claude.com: una lectura estimada en **40 minutos**, de unos **64.000 caracteres**, presentada como una colección de *plays* extraídos del trabajo del equipo con sus clientes. (A) El diagnóstico: al dejar de ser el código el cuello de botella, este se desplaza hacia las etapas situadas a ambos lados de la construcción (planificación, revisión/pruebas, despliegue), los controles línea por línea dejan de sostenerse en cuanto el agente escribe la mayor parte del diff, y el coste de la gobernanza aumenta porque las excepciones siguen pasando por comités periódicos. (B) La respuesta: seis etapas (Plan, Design, Build, Test, Deploy, Maintain) organizadas como un **loop** en lugar de una cadena, cada una terminando en un **artefacto versionado** que la siguiente etapa lee — `intent.md`, `spec.md`, `plan.md`, el diff y sus pruebas, la PR y sus hallazgos, el registro del incidente. (1) El conocimiento institucional se convierte en archivos versionados: `CLAUDE.md`, skills, `REVIEW.md`, `bands.yaml`. (2) La gobernanza se divide en dos capas, con la skill situada como control consultivo y el hook como capa determinista detrás de ella. La separación de funciones se fija como invariante — el agente que escribe el código no puede aprobarlo — y la pieza se cierra con *"El loop sigue corriendo. El juicio humano permanece por encima de él."* El corpus ya cuenta con [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sobre la vertiente de seguridad del mismo ciclo, y con [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sobre el mismo desglose en seis etapas visto por un competidor.
#SDLC nativo de IA#ciclo de vida de desarrollo de software#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Guía firmada por **Michael Segner**, publicada el **20 de agosto de 2026** en el blog claude.com, categoría *Claude Code*: una lectura de **5 minutos** anunciada para aproximadamente **31.500 caracteres** de cuerpo del texto, ofrecida también en PDF. Material declarado: entrevistas con **más de una docena** de startups, quince nombradas — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Cinco reglas operativas: *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, cada una cerrada con consejos de producto y reunidas en una checklist final. (B) Un cuerpo compuesto de citas atribuidas, cada regla ilustrada por directivos nombrados en lugar de una métrica agregada. Las cuatro cifras destacadas son las de las empresas entrevistadas: **+30%** más funcionalidades entregadas (ClickHouse), **de 2 a 3×** productividad de ingeniería (Omni), **100%** del triaje de bugs automatizado (Clay), **más de 6.000 PR por semana** (Artemis Security). Dos pasajes se apartan del registro testimonial: el bucle de autocorrección de **Cainex** sobre la codificación médica, descrito paso a paso, y el uso interno de **Claude Tag** en **Anthropic** como primer respondiente para las guardias de CI/CD. La pregunta planteada al inicio — *"what would it look like if an organization built their product development lifecycle with Claude Code from the ground up?"* — conecta con [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], publicado al día siguiente por el mismo editor, y prolonga [[cherny-wu-reflecting-year-claude-code-2026-07-17]].
#Claude Code#startups#everyone ships
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
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).
Artículo de noticias analizado, publicado en **VentureBeat** el **11 de agosto de 2026** por **Michael Nuñez**, basado en una **entrevista exclusiva con Timothée Lacroix**, cofundador y CTO de **Mistral AI**, realizada antes del anuncio, ~2.000 palabras. Mistral amplía su oferta de infraestructura en tres partes: **Mistral Regional Endpoints** en disponibilidad general (fijando la inferencia y su procesamiento asociado en Europa o Estados Unidos), un **Priority Tier** en vista previa pública (niveles de servicio comprometidos, cuotas personalizadas, SLA de disponibilidad), y una **coalición de empresas europeas** cuyos compromisos plurianuales están destinados a financiar **200 MW para finales de 2027** y **1 GW para finales de 2030**. El vehículo se denomina **European Compute Unit (ECU)**: un derecho sobre capacidad construida por Mistral, fungible entre inferencia, entrenamiento, adaptación de modelos o Kubernetes gestionado, con un horizonte objetivo de cinco años. Lacroix describe el mecanismo sin rodeos — *"Todo el sentido de las unidades de cómputo es tener compromiso"* — y, sobre la salida anticipada: *"No hay salida posible."* El artículo pone en perspectiva la ambición: Mistral declara operar *"menos de 200 MW"* y detalla tres emplazamientos que suman **77 MW** (44 MW cerca de París, 23 MW en Suecia con EcoDataCenter, 10 MW en Les Ulis); **Epoch AI** cifra el capex inicial de un centro de datos de IA de un gigavatio en **~38.000 millones de dólares**, y **Goldman Sachs Research** cifra las instalaciones de nueva generación en **15-20 millones de dólares/MW sin chips**, frente a los **~4.000 millones de dólares** que Mistral ha recaudado en total (PitchBook). A esto se suma una decisión que *"probablemente levantará algunas cejas entre los puristas de la soberanía"*: Mistral empieza a **alojar modelos abiertos de terceros**, comenzando por **GLM-5.2** de **Z.ai**, un laboratorio chino — *"Es un modelo excelente. A todo el mundo le encanta. Tiene pesos abiertos, así que no había ninguna buena razón para no hacerlo."* El artículo examina la letra pequeña de la documentación de Mistral, que menciona *"transferencias limitadas y controladas"* a subcontratistas fuera de la región; presionado para dar detalles, Lacroix señala las **llamadas a herramientas**, en particular la búsqueda web, y afirma que **la restricción de acceso es la funcionalidad, no el fallo**. El enfoque del autor: *"el control regional total está disponible, pero en el momento en que un agente de IA accede a la web abierta, la soberanía se convierte en una decisión de configuración, no en un valor por defecto."* Quedan dos dependencias: las **GPU** provienen de Nvidia, y **Microsoft** — cliente ancla de los centros de datos europeos de Mistral desde julio — se presenta como lo que reduce el riesgo de la expansión.
#Mistral AI#soberanía digital#soberanía de la IA
**Michael Nuñez** — journaliste **VentureBeat** · couvre l'IA et l'infrastructure ; déjà présent au corpus. L'article est bâti sur un **entretien exclusif avec Timothée Lacroix** · cofondateur et CTO de Mistral AI · conduit **avant l'annonce** · et fait suite à un entretien de juin avec le même interlocuteur. Publié le **11 août 2026**.
Artículo extenso publicado en **X** el **11 de agosto de 2026** por **Jesse Zhang**, CEO de **Decagon** (agentes de IA para atención al cliente), bajo un título en forma de dilema —*« To FDE, or not to FDE? »*— dedicado al **Forward Deployed Engineer**, convertido en *« the answer to almost every hard question in AI go-to-market »*. Observación inicial: Anthropic y OpenAI han construido brazos de despliegue empresarial explícitamente calcados de Palantir, *« every seed-stage company »* anuncia una oferta de FDE, y las ofertas de empleo con ese título habrían aumentado varios cientos por ciento en un año. **(A) La genealogía Palantir** aporta el marco: la fórmula de **Shyam Sankar** (CTO), *« FDEs eat pain and excrete product »*, y el recordatorio de **Joe Lonsdale** de que Palantir pasó cerca de dos décadas siendo tildada de *« glorified consultancy »* sobre la base de una observación certera. Los despliegues a medida de **Gotham** (CIA, NSA, inteligencia militar) se codificaron en primitivas de plataforma —ontología, modelos de objetos, permisos, motores de flujo de trabajo, trazabilidad de procedencia— que dieron lugar a **Foundry**, luego Apollo y AIP; la estandarización llevó el margen bruto a la franja del 80% y Palantir pasó de un modelo de FDE a una venta basada en cuentas, con muchos FDE migrando hacia la ingeniería central. *« The pain was the input to the product, not a cost of sale. »* **(B) El criterio propuesto** no es renunciar a los FDE sino saber cuándo detenerse: desplegarlos pronto y luego preguntarse si aún se está en fase de **descubrimiento** —*« The trap is not starting. It's not stopping. »* **(C) Una distinción que pocos hacen: FDE ≠ implementación.** *« Building that integration into their ticketing system »* es trabajo real, pero se trata de ejecutar una especificación conocida, no de descubrir una desconocida; confundir ambas cosas *« is how a company convinces itself that a growing services org is a product investment »*. Frase de cierre: *« If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business. »* Se presentan dos cifras sobre Decagon —*« two-thirds of deployment work is now done autonomously via Duet »* y *« a few days on average to launch the first AOP, even for large banks, airlines, telcos »*— sin que se defina el denominador de «deployment work» ni se explicite el acrónimo AOP.
#Forward Deployed Engineer#FDE#ingeniero embebido con el cliente
**Jesse Zhang** — cofondateur et **CEO de Decagon** (agents IA de service client, San Francisco) · 85 000 abonnés sur X · site personnel `jessezhang.org`. Il cite son cofondateur **Ashwin Sreenivas** · **ex-Palantir** · d'où la profondeur du récit Palantir. Publié le **11 août 2026**.
Manifiesto doctrinal publicado en **meta.com** el **10 de agosto de 2026**, firmado solo con un nombre de pila (*"– Mark"*) por **Mark Zuckerberg**, bajo el título *"The Future is for Everyone: The Path to a Positive AI Future"*, ~6500 palabras. Se anuncian tres principios desde el inicio: el empoderamiento individual como fuente de prosperidad, la invención como propósito primordial de la superinteligencia, el equilibrio de poder como fundamento de la seguridad. **(A) El argumento central es un argumento político**, formulado como una breve cadena de razonamiento: *"Humanity is not a monoculture"* — los valores de las personas codifican compromisos opuestos entre sí, ninguna solución técnica puede alinearse simultáneamente con intereses contrapuestos, de modo que cualquier superinteligencia singular tendría que priorizar ciertos valores sobre otros y, por ello, sería incapaz de ser benevolente con todos. De ahí la fórmula: *"There is no such thing as a singular benevolent superintelligence."* La seguridad se replantea como un problema de distribución del poder, ilustrado mediante un experimento mental repetido tres veces (un único abogado superinteligente frente a que todos dispongan de uno; lo mismo para la ciberseguridad, y luego para los negocios). **(B) Una redefinición del alineamiento**: *"Solving alignment is necessary for billions of people to adopt personal superintelligence agents. But it also implies that if we reach a state where billions of people are using and scrutinizing personal superintelligence agents, then we will have solved alignment with their interests."* El corolario apunta al resto de la industria sin nombrarla: *"the most dangerous scenario would be leading labs training powerful models and keeping them for themselves."* **(C) Compromisos con fecha**: un modo **totalmente privado** en el que *"even Meta"* no puede ver ni conceder acceso (una analogía con WhatsApp); versiones **gratuitas** para miles de millones de personas junto con un **mecanismo de puja dinámica** para el cómputo de pago; la **reanudación** anunciada de las publicaciones open source — *"we will soon resume releasing some open source models"*; y una estructura que otorga a la **junta independiente** la facultad de aprobar los criterios de seguridad de los lanzamientos y verificar el cumplimiento de cada uno, reconociendo el autor que Meta es una empresa controlada por su fundador. **(D) Dos propuestas de política pública**, repetidas tres veces: que los laboratorios compartan con el gobierno **puntos de control intermedios del entrenamiento** e ingenieros, en lugar de una revisión de fin de ciclo, y que se regule la **producción física** de materiales peligrosos en lugar de la difusión del conocimiento. Las fuentes del texto son prácticamente inexistentes.
#Mark Zuckerberg#Meta#Meta Superintelligence Labs
**Mark Zuckerberg** — fondateur et PDG de **Meta**. Texte signé du seul prénom (*« – Mark »*) · publié le **10 août 2026** sur un domaine dédié de meta.com. La signature n'est pas « Meta » · et l'alternance des pronoms est régulière : **« we » pour les engagements de l'entreprise** (*« we will offer free versions »*, *« Meta is implementing a governance structure »*) · **« I » pour les affirmations normatives ou contestables** (*« I think this view of alignment is fundamentally flawed »*, *« I propose that companies developing frontier AI should… »*, *« My honest guess, and it is a guess »*). Les engagements produits et de gouvernance sont au « nous » · les propositions de politique publique au « je ».
Artículo de opinión en profundidad publicado en **sfeir.com** el 1 de agosto de 2026, escrito por **SFEIR** (la voz editorial de la firma). Reúne **dos publicaciones de julio de 2026** con metodologías opuestas — el experimento de campo preregistrado **"The Cybernetic Teammate"** en **Procter & Gamble** (Dell'Acqua, Ayoubi, Lifshitz, Sadun, **Ethan Mollick** et al., *Organization Science* 37(4), 2026) y el primer informe de la serie **"Work at the Frontier"** de **OpenAI Economic Research** (27 de julio de 2026, >800.000 mensajes de usuarios estadounidenses de ChatGPT) — en una única tesis: *"la IA generativa no solo acelera el trabajo existente, redistribuye quién hace qué"*. La arquitectura se despliega en cuatro etapas: **el mecanismo** (P&G: la IA actúa como un dispositivo *boundary-spanning*, borrando los silos funcionales — un individuo + IA alcanza el nivel de una pareja sin IA, **+0,37 σ**), **la escala** (OpenAI: **43,5%** de los mensajes específicos de una profesión caen fuera de la propia profesión del usuario), **la agenda** (Mollick: los muros se están adelgazando, la división del trabajo debe repensarse, y una recomposición bien orquestada "rinde generosamente"), luego **la respuesta de la firma** — **Skill Based Organisation (SBO)**, adoptada en SFEIR bajo el impulso de **Rosalie Zandona** (VP People & Culture): la **competencia realmente operativa** reemplaza la descripción de puesto como unidad de organización (**hasta 13 competencias identificadas por rol**), pasando de una **identidad basada en el estatus** ("soy manager") a una **identidad operativa** ("sé diseñar arquitecturas complejas"). El movimiento retórico es una prueba por el ejemplo interno: *"hicimos el cambio internamente antes de recomendarlo"*. **Se señalan tres reservas**: el cambio hacia el SBO se remonta a **febrero de 2026**, por lo tanto *precede* al diagnóstico que se supone debe resolver (el orden argumentativo invierte el orden cronológico); **nada en los datos demuestra** que una organización basada en competencias absorba mejor el cruce de tareas que una basada en roles (una hipótesis de diseño no probada); el resultado de P&G circula **desde marzo de 2025** (NBER w33641) — el "unas semanas antes" se aplica a la publicación revisada por pares, no al resultado en sí.
#Skill Based Organisation#SBO#organización basada en competencias
**SFEIR** — ESN française « AI Only » (~850 ingénieurs, 8 agences France & Benelux). Voix éditoriale du cabinet (byline « SFEIR »).
Episodio «Fase 5 · Review» de la serie de SFEIR sobre el SDLC aumentado, publicado **el mismo día** que la publicación de Addy Osmani en LinkedIn que traduce en una especificación de fase. Tesis: **la calidad ha cambiado de dirección** — ya no se lee en el código (los agentes producen más código del que nadie puede revisar) sino en **el anillo de restricciones que rodea al agente**. El anillo de Osmani (siete dimensiones — corrección, seguridad, rendimiento, accesibilidad, mantenibilidad, **eficiencia económica**, **comprensibilidad** — enlazadas por la regla de **back-pressure**: «un bucle solo recibe la autonomía que puede verificarse de forma barata y fiable, ni un ápice más») se redibuja, se traduce y se adjunta a la fase 5 del ciclo de 11 fases de SFEIR. El corolario estructurante: **el cuello de botella nunca ha sido la generación, es la verificación** — «la generación es una boca ancha, la verificación un cuello estrecho; acelerar la boca engrosa la pila en el cuello». **La decisión de diseño más interesante es una elección de arquitectura del ciclo**: Review queda deliberadamente **fuera de las tres puertas humanas** (Define, Plan, Ship), porque convertir Review en la puerta pondría la atención humana — un recurso finito — como el punto de control de una capacidad de generación que a su vez escala: «habrías construido un pipeline cuyo rendimiento máximo es el número de diffs que un senior puede leer antes de que acabe el día». De ahí la separación: **Review instrumenta, Ship decide** — Review entrega un *cuerpo de evidencia oponible*, Ship decide sobre la evidencia, no sobre el diff completo. Una postura enfrentada a Monperrus (de quien SFEIR conserva el diagnóstico — la inspección humana de cada diff no puede resistir la velocidad agéntica — pero rechaza la conclusión: la aceptación no puede delegarse). La trampa señalada es la **validación circular** (el agente que escribe el código escribe los tests que lo validan: «has construido un espejo, no un anillo»), con cinco contramedidas extraídas de Anthropic (puertas independientes en ventanas de contexto separadas, determinista + agéntico que nunca se sustituyen entre sí, modo sombra, categorización por riesgo, registro en el SIEM) y la advertencia de Compare the Market (**grafo AST ~70% frente a RAG vectorial ~58%**, con el RAG rindiendo *peor que sin contexto alguno*). La extensión propia de la firma es **el trinquete**: «cada fuga se convierte en una restricción» — un defecto que ha cruzado el anillo se cierra *dentro del anillo* (test, regla de lint, rúbrica de revisión, guardrail del harness) en Compound-1, «el único activo de la cadena que se revaloriza mientras los modelos se deprecian» (una medición interna no auditada: **−30% de iteraciones de corrección tras diez ciclos**). Cierra reformulando la pregunta: «¿es bueno este código?» se ha vuelto una pregunta sin respuesta; lo que queda es **«¿qué se niega a dejar pasar mi sistema?»**
#anillo de restricciones#restricciones alrededor de los agentes#fase Review
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market
Descifrado de SFEIR (voz de la firma) del informe de Jason Clinton (Deputy CISO, Anthropic) publicado cinco días antes — ya documentado en [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **El valor añadido no reside en los hechos sino en la tesis que los relee**: si los controles de Anthropic se sostienen, es porque **existe un ciclo con etapas nombradas del que colgarlos** — "el SDLC es el fundamento, no una formalidad". La demostración avanza releyendo el mapeo (**PSR en Plan, CLAUDE.md + egress allowlist en Code, agentes de revisión en Test, DAST continuo en Deploy, triage + enrutamiento SIEM en Monitor**), y después mediante una **anáfora en cuatro partes**: (1) *sin un SDLC, las ganancias de productividad no se materializan* — Clinton cita la **ley de Amdahl**: multiplicar por 8 el volumen de código no multiplica nada si la revisión sigue siendo secuencial y humana, y Anthropic ganó no distribuyendo agentes sino **identificando la etapa bloqueante (Test) y reconstruyéndola** — "no se optimiza un cuello de botella que no se ha mapeado" (haciendo eco del **efecto espejo** de DORA 2025); (2) *sin un SDLC, la seguridad no tiene punto de anclaje* — un **gate es por definición un control situado entre dos etapas**, y las tres amenazas de Clinton se abordan en momentos distintos; (3) *sin un SDLC, no puede formularse ninguna política de **FinOps de tokens*** — el escaneo agéntico se factura por consumo y crece con el volumen de código, así que **el tiering basado en riesgo ES la política de FinOps** (decide dónde se pagan tres pasadas de agente y dónde basta un SAST), de lo contrario "el gasto en tokens no se pilota, se descubre a fin de mes"; (4) *sin un SDLC, no hay nada que medir* — los indicadores (16% → 54% de PR comentados, un tercio de los incidentes pasados interceptados) existen solo porque hay etapas donde puede colocarse un contador; sin eso, solo se producen **cifras de uso** (licencias, tokens) que nada dicen sobre calidad o riesgo. Dos puntos fuertes más allá de la tesis: la lectura del **incident agent-à-agent** ("un perímetro de seguridad que descansa sobre una instrucción en un prompt no es un perímetro"; **el acceso de un agente a otros agentes forma parte de su superficie de ataque**) y una **advertencia metodológica explícita** — cifras de Anthropic sobre Anthropic, no auditadas, publicadas por el proveedor del modelo descrito, en el contexto de una base de código joven sin mainframe: **lo que se transpone es el método, no las cifras**.
#SDLC#SDLC nativo en IA#ciclo de desarrollo
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
**Informe de investigación interno de SFEIR** (documento de preparación editorial, basado en deep research — ~70 referencias) sobre la **AI Kill Switch Act** estadounidense, enmarcado en torno a la **soberanía europea** y el **«so what» para las empresas**. Es la **base factual** de un futuro artículo de blog — expone dónde la tesis del «umbral muy bajo» **se sostiene** y dónde necesita **matices**. **Aporte clave frente a la cobertura de prensa** (incluida [[arstechnica-ai-kill-switch-act-2026-07-23]]): (1) una lectura **del propio texto de la ley** (nueva **sección 2220F**, «Shutdown-Capability Standard and Graduated Deployment-Corrections Framework», presentada el 23 de julio de 2026, 119.º Congreso) — la autoridad recae en el **Secretario del DHS a través de la CISA** (el «Director»), en consulta con Commerce + DNI; (2) **dos umbrales ACUMULATIVOS** — ≥ **500 M$** en ingresos de IA (incluidas filiales) **Y** cómputo de entrenamiento > **100 M$** — lo que implica que **hoy son pocos los laboratorios cubiertos**, lo cual **contradice estrictamente** la tesis del «umbral bajo»; (3) pero un **alcance real muy amplio** a través del **mecanismo de expansión** (actualizaciones anuales de los umbrales por el DHS, cláusula de «filiales», cómputo indexado al precio del cloud, crecimiento de ingresos) y sobre todo a través del **efecto dominó** sobre los clientes; (4) **sanciones graduadas**: hasta **2 M$/día** (infracción general), **20 M$/día** (infracción de la autoridad de emergencia); (5) **matiz crítico**: dado que el incidente **OpenAI/Hugging Face** ocurrió durante **red-teaming/evaluación interna**, **NO activaría** la autoridad de emergencia tal como está redactada actualmente (el texto excluye el red-teaming). El ángulo de **soberanía** se apoya en el **precedente de Anthropic** (corte de Fable 5 / Mythos 5 durante **19 días** en junio de 2026) como **prueba operativa** de un «kill switch de facto», y desemboca en **recomendaciones para el CTO** (arquitectura multimodelo probada, cláusulas de continuidad, mapeo de exposición, opciones soberanas).
#AI Kill Switch Act#sección 2220F#Shutdown-Capability Standard
**SFEIR** (recherche interne / deep research). Document non signé nominativement — préparation éditoriale pour le blog SFEIR · dans la ligne souveraineté/adoption du cabinet (cf. [[sfeir-mistral-microsoft-souverainete-strategie-industrielle-2026-07-22]]). Base factuelle équilibrée (arguments **et** contre-arguments) · références numérotées.
Análisis de SFEIR (voz de la firma, «una lectura de ingenieros») del acuerdo anunciado el **21 de julio de 2026** entre **Mistral** y **Microsoft**: una **alianza industrial valorada en varios miles de millones de dólares**, estructurada en tres partes — (1) **cómputo en Europa** (capacidad Azure reservada en el continente, centros de datos en Francia, sistemas **NVIDIA Vera Rubin** de última generación, para «cerrar el déficit europeo de cómputo»); (2) **los modelos de Mistral en las herramientas de Microsoft** (**Mistral Medium 3.5** y **Mistral OCR 4** en **Microsoft Foundry**, accesibles en **Copilot Studio** para construir agentes empresariales); (3) sobre todo **Azure Local hasta el modo desconectado** (nube pública, nube conectada supervisada, y **air-gapped**, totalmente fuera de la red externa — para el secreto de defensa, la sanidad, la banca crítica). **Dato notable, confirmado por Brad Smith: ninguna nueva participación de capital** de Microsoft en el capital de Mistral — una alianza masiva **sin vínculo de capital**. SFEIR — socio de Anthropic y Google Cloud, «sin interés en sobrevender al campeón francés» — considera a Mistral **«la mejor apuesta europea en la capa de modelo»** y propone una lectura en tres partes. **Lo que el acuerdo aporta a un CIO**: un modelo europeo de vanguardia, ejecutable en un entorno desconectado y controlado por el cliente (cifrado en memoria, claves gestionadas localmente), marca casillas que pocas ofertas marcan. **La tensión**: esta soberanía se despliega **sobre la infraestructura de un hyperscaler estadounidense**; hay que distinguir cuatro soberanías — **modelo, ejecución, infraestructura, relación comercial** — de las cuales se puede «obtener tres de cuatro, pero aun así hay que saber cuál falta». El único elemento que hace que la soberanía sea **verdaderamente portable** es la naturaleza **open-weights** de los pesos de Mistral (la misma lógica de reversibilidad que para **Kimi K3**). La ausencia de participación de capital no es un detalle: preserva la gobernanza de Mistral **y** minimiza el riesgo de un examen antitrust (FTC, Comisión Europea) — **arbitraje regulatorio asumido**, no solo una elección técnica. **El verdadero punto ciego**: la **legibilidad de la estrategia industrial de Mistral**, presente simultáneamente en casi todos los frentes (B2C con Le Chat, B2B vía distribución Azure, modelo open-weights **y** ambición frontier, infraestructura muy intensiva en capital — 200 MW asegurados, un tope de 1 GW para 2030 —, alianzas con un puñado de grandes cuentas, verticalización Robostral/OCR, servicio a sectores regulados): full-stack soberano (lectura optimista) o dispersión de una empresa de tres años, valorada en ~20.000 millones de euros, entre negocios con modelos económicos divergentes (lectura prudente). Para el liderazgo técnico: **separar el modelo del canal**, **diseñar para poder salir** (Design to Exit — el open-weights hace creíble la puerta de salida), **enrutar en lugar de apostar** (arquitectura soberana multi-LLM, RAISE). Conclusión: **la soberanía es una propiedad arquitectónica, no una etiqueta** — se cualifica dependencia por dependencia; la legibilidad industrial faltante sigue siendo la verdadera pregunta abierta, que no zanjarán los comunicados de prensa sino «los compromisos de los próximos doce meses».
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".
Análisis de Janakiram MSV (The New Stack, 20 de julio de 2026) sobre la **convergencia arquitectónica** de las plataformas de agentes empresariales de los tres hyperscalers: en nueve meses, **Amazon Bedrock AgentCore**, **Microsoft Foundry** y **Gemini Enterprise Agent Platform** han convergido en las **mismas seis primitivas** — runtime, memoria, tool gateway, identidad, observabilidad, gobernanza — bajo nombres de marca distintos. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una **capa de plataforma** diferenciada. La tesis: esta convergencia repite la **inflexión PaaS de 2011-2016**, en la que **Cloud Foundry** y **Heroku** unificaron VMs, balanceadores de carga, colas y almacenes de secretos en torno a un **contrato de aplicación** portable — salvo que aquí **todavía no existe un contrato equivalente**, y **ningún proyecto de código abierto lo ha reclamado**. Consecuencia: una empresa no puede **mover un agente de una nube a otra** (el estado de sesión, las trazas y la identidad terminan todos en manos de un único proveedor; migrar implica reconstruirlo todo). El autor propone un **mapeo línea por línea** del contrato de Cloud Foundry sobre los agentes, plantea tres principios de diseño (empaquetar el agente como **una única unidad desplegable**, **adjuntar** capacidades en lugar de incrustar proveedores, integrar la capa **operativa** en la abstracción), señala lo que los protocolos abiertos (MCP, A2A, OpenTelemetry) dejan fuera de alcance — el **ciclo de vida** — y plantea tres preguntas de due diligence: **gobernanza** (fundación neutral frente a proveedor), **empaquetado** (el mismo artefacto en dos nubes sin reescribirlo), **estado** (memoria exportable). Veredicto: quien termine poseyendo el **plano de control del agente** definirá *qué es un agente*.
#Plataformas de agentes empresariales#convergencia arquitectónica#portabilidad
**Boris Cherny** (Creator & Head of Claude Code @Anthropic) publica una tabla-marco en LinkedIn, **« Steps of AI Adoption »**, que mapea la adopción de IA agéntica de un equipo de ingeniería a lo largo de **5 etapas (0→4)**, cada una caracterizada por un **orden de magnitud de agentes gestionados** y una **transformación del rol del ingeniero**: **0 Gated** (0 agentes, acceso restringido), **1 Assisted** (~1 agente — "tú + un agente", programación en pareja supervisada), **2 Parallel** (~10 agentes — **orquestador**), **3 Supervised autonomy** (~100 agentes — **manager of managers**, un árbol organizativo), **4 AI-native** (~1.000+ agentes — **VP que dirige por intención**). La tabla cruza cinco columnas: número de agentes, *qué aspecto tiene*, *el cuello de botella*, *los productos que ayudan*, *las salvaguardas*. **Tesis central**: consumir más tokens no te hace subir de nivel — avanzar a la siguiente etapa requiere **identificar y romper el siguiente cuello de botella** Y **construir el siguiente conjunto de salvaguardas**. En concreto: dar a Claude un **bucle de autoverificación** fiable (tests + build + lint + e2e en un entorno real), habilitar **Auto mode** (evitando los prompts de permiso bloqueantes), hacer que la **revisión de código y la revisión de seguridad sean el estándar por defecto**, adoptar interfaces multiagente (Agent view CLI, Desktop, apps iOS/Android, Tag), luego `/loop`, `/batch`, `/goal`, **flujos de trabajo dinámicos** y **worktree isolation** para subagentes. Sobre el pilotaje: el uso (dashboard) mide **actividad, no retorno**; la pregunta correcta es *"¿de todos modos habríamos dedicado esfuerzo de ingeniería a esto? si es así, ¿cuántas horas-ingeniero manuales habría costado?"* — ese es el ROI. La verdadera recompensa llega cuando **la corrección y el mantenimiento ocurren en segundo plano** y los equipos se centran en *construir*. Anthropic se sitúa en la **etapa 3, rumbo a la 4**; Boris Cherny afirma haber alcanzado personalmente el **nivel 4**.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
Análisis del gabinete de ingeniería de SFEIR («una lectura de ingeniero») sobre el lanzamiento, el 16 de julio de 2026, de **Kimi K3** por el laboratorio chino **Moonshot AI**: un **modelo de pesos abiertos (open-weights) de nivel frontera** cuyo proveedor afirma **~2,8 billones de parámetros**, un **contexto de un millón de tokens** y una **publicación de los pesos antes del 27 de julio de 2026** (probablemente bajo una licencia Modified MIT, como en el linaje K2). Tesis: una capacidad que antes se creía reservada a los grandes propietarios (Anthropic, OpenAI, Google) está pasando a estar disponible **en pesos abiertos, a precio de descuento, desde un laboratorio chino**. SFEIR —pese a ser **partner de Anthropic y de Google Cloud**, y por tanto «sin ningún interés en sobrevender un modelo chino»— adopta una **advertencia metodológica** cardinal: el día del lanzamiento **no existe ninguna tabla de benchmarks oficial y completa**; las especificaciones (2,8 billones, Kimi Delta Attention, +25 % de eficiencia de entrenamiento) y las puntuaciones son **declaradas por el proveedor** o proceden de **arenas comunitarias**, «que deben tratarse como afirmaciones, no como hechos medidos». La nueva arquitectura (**Kimi Delta Attention**, atención lineal híbrida; decodificación que se afirma hasta **6,3 veces más rápida** a 1M de tokens) rompe con la cadencia de K2 (K2 jul. 2025 → K2.7 Code jun. 2026, un modelo insignia cada dos meses); dos variantes acompañan el lanzamiento (**K3 Max**, **K3 Swarm Max**), con el retiro forzado de la serie kimi-k2.5/moonshot-v1 el **31 de agosto de 2026**. **La verdadera arma es el precio** (~3 $/M de entrada, 0,30 $ en caché, 15 $ de salida según fuentes secundarias): un modelo frontera de pesos abiertos a este nivel **arrastra hacia abajo toda la curva de precio-rendimiento** — la comoditización de la capa de modelo, acelerada por el open source. Pero la singularidad decisiva no es una puntuación: es la **reversibilidad**. Un modelo frontera de pesos abiertos convierte una API consumida (dependencia del proveedor) en una **opción** (autoalojamiento, portabilidad, salida del lock-in), al precio de una infraestructura pesada para alojar 2,8 billones de parámetros. La postura de SFEIR: **el open-weights cambia la pregunta, no solo la respuesta** — ya no «¿qué modelo es mejor/más barato?», sino «¿qué parte de mi sistema estoy dispuesto a hacer depender de un proveedor que no controlo?». La postura correcta sigue siendo un **portafolio enrutado** (un modelo por tarea, un modelo por restricción), y Kimi K3 añade una **columna «reversibilidad»** a la grilla de decisión. La convicción «AI Only» permanece intacta: el modelo es un commodity, la ventaja duradera reside en la ingeniería que lo rodea (Context Engineering, harness, gobernanza de costes, capacidad de cambiar de opinión). Las cifras aún deben validarse «por cuenta propia» — en tus propios repositorios, con tus propios datos.
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
Nota de análisis de SFEIR que revisa el papel del arquitecto de software en la era de la IA generativa a través del marco de **Gregor Hohpe** (*The Software Architect Elevator*). Tesis central: el arquitecto « **Oráculo** » — el guardián supremo del conocimiento que dicta reglas desde una torre de marfil — está obsoleto, ya que la IA genera código y propuestas bajo demanda; el arquitecto moderno se convierte en un **amplificador de inteligencia (IQ Amplifier)** que provee a los equipos los modelos mentales, el contexto de negocio y las herramientas de decisión para aprovechar la IA garantizando al mismo tiempo la coherencia del sistema. El documento desglosa el impacto **piso por piso del "Architect Elevator"** (arquitecto de Empresa / Solución / Plataforma / Software) y defiende el **Domain-Driven Design (DDD)** como salvaguarda indispensable: el **lenguaje ubicuo** sustenta los *system prompts* (un diccionario de dominio inyectado vía `.clinerules`/plantillas, que reduce las alucinaciones y las malinterpretaciones de negocio), y los **bounded contexts** restringen el alcance confiado a la IA para maximizar la fiabilidad de la generación. Conclusión: la IA no es una amenaza sino un catalizador que libera al arquitecto de las tareas técnicas de entrada para poner en primer plano la síntesis, la visión estratégica, el modelado y el vínculo humano entre la tecnología y el negocio. Dominio: arquitectura de software, papel del arquitecto, DDD, prompting estructurado, gobernanza de IA empresarial.
#Arquitecto de software#papel del arquitecto#IA generativa
Tercera entrega de la serie de Ashish Singh «New Engineering Disciplines for the AI Era», dedicada al **KDLC — Knowledge Development Life Cycle**: un ciclo de vida de **8 etapas** que convierte el conocimiento empresarial en un **activo de ingeniería**, al mismo nivel que el código o los datos. Tesis: las iniciativas de IA fracasan no por falta de elegir el LLM adecuado o de desplegar un sistema RAG, sino porque **no abordan la estructura subyacente del conocimiento** — «la IA es solo tan eficaz como el conocimiento que puede descubrir, comprender, recuperar y en el que puede confiar». El KDLC encadena Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Contrapone el **RAG tradicional** (documentos aislados, palabras clave) con el **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search), en el que los agentes comprenden «relaciones, contexto y significado de negocio». Frase emblemática: «Los modelos aportan razonamiento. La memoria aporta continuidad. El conocimiento aporta comprensión.» Tres ejemplos (finanzas/cumplimiento normativo, ingeniería de software, sanidad) ilustran el impacto.
#KDLC#Knowledge Development Life Cycle#ciclo de vida del conocimiento
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
Informe interno de desmontaje técnico sobre el lanzamiento de código abierto **`xai-org/x-algorithm`** (15 de mayo de 2026) — el algoritmo del **feed For You** de **X (antes Twitter)** en 2026, con cuatro líneas de recomendaciones de crecimiento adaptadas a la audiencia (personal/fundador, marca/empresa, marco generalizado, entregable de consultoría/cliente). **Tesis central**: ***« La famosa tabla de pesos de 2023 —las respuestas cuentan más que los me gusta por un gran multiplicador— describe un sistema que ya no existe en esa forma. »*** El algoritmo de 2026 es un **transformer (Phoenix, derivado de Grok-1)** que aprende pesos a partir del historial de interacción de cada usuario, evaluado frente a una **superficie multiacción de 19 dimensiones**, filtrado por un servicio offline de comprensión de contenido (**Grox**). **La forma de la puntuación importa ahora mucho más que las cifras — y las cifras en sí no están en el lanzamiento público**. **Arquitectura de 4 componentes**: (1) **Home Mixer** (Rust, orquestador en tiempo de solicitud, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, almacén en memoria alimentado por Kafka con publicaciones recientes, búsquedas de sub-milisegundo para candidatos in-network); (3) **Phoenix** (ML en JAX, recuperación two-tower + transformer de ranking, ~derivado de Grok-1); (4) **Grox** (offline, clasificadores de spam/seguridad/PTOS/banger + embedder multimodal v5). **Las 19 acciones predichas por Phoenix** (cambio clave respecto a 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualización de calidad de video condicionada por duración mínima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Puntuación final** = `Σ (weight × P(action))` modificada por **3 multiplicadores estructurales**: (a) **OON_WEIGHT_FACTOR < 1** (penalización por fuera de red), (b) **decaimiento de diversidad de autor** `(1-floor) × decay_factor^position + floor` (atenuación exponencial de publicaciones repetidas del mismo autor dentro de un mismo render), (c) **umbral de duración de video** (vqv solo contribuye si `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Advertencia clave**: **ningún valor numérico de peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) está en el lanzamiento — todo es `crate::params::*`, gestionado por un servicio interno de feature-switch de X para pruebas A/B. ***« Cualquiera que diga que 'las respuestas valen N,N× más que los me gusta en 2026' está inventando una cifra que no se puede derivar del lanzamiento OSS. »*** **Diferencias clave frente a 2023**: (1) eliminación de todas las características diseñadas manualmente (*« Hemos eliminado cada una de las características diseñadas manualmente y la mayoría de las heurísticas del sistema »*); (2) un único modelo que predice 19 acciones frente a múltiples modelos de una sola acción; (3) Grox separa la comprensión de contenido del ranking; (4) nuevas señales de primer nivel (dwell continuo, vqv condicionado, follow_author, 3 variantes de share); (5) recuperación OON two-tower (frente a SimClusters+heurísticas) con embeddings multimodales de texto+imagen+video-ASR. **Tres capas de alcance** (marco generalizado): Elegibilidad (binaria, Grox+filtros) → Recuperación (probabilística, ANN two-tower) → Ranking (continuo, suma ponderada + multiplicadores). **Dos leyes del crecimiento mecánico**: (1) La red interna (in-network) es multiplicativa, la externa (OON) es aditiva; (2) La función del modelo es predecirte, no recompensarte. **Límite deliberado de honestidad**: el checkpoint de Phoenix publicado = versión mini (2 capas, 4 cabezas, 256 dimensiones, corpus de 537K publicaciones deportivas), no el modelo de producción; las integraciones Thrift están simuladas (`panic!("Not implemented")` en `candidate_features.rs`); las listas de brand-safety, los mapeos de ID de temas, las penalizaciones por idioma y las reglas de mezcla de anuncios están ausentes del lanzamiento público.
#algoritmo de X 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
Nota de análisis de **Mitch Ashley**, VP y Practice Lead de *CIO & Technology Buyers* y *Software Lifecycle Engineering* en **The Futurum Group**, publicada el **29 de abril de 2026** en la sección *Market Coverage News*: formato corto, aproximadamente **9.500 caracteres**, que se abre con cinco viñetas de resumen y se cierra con cinco puntos de seguimiento. Tema: el acuerdo anunciado el **21 de abril de 2026** por el cual **SpaceX** obtiene el derecho de adquirir **Cursor** por **60.000 millones de dólares** en el plazo de un año, o de pagar **10.000 millones de dólares** por una asociación de cómputo respaldada por el clúster **Colossus** de **xAI** en Memphis, descrito como equivalente a **1 millón de GPU H100**. (A) La lectura de las dos necesidades: Cursor arrastraba a la vez un techo de cómputo y una compresión de márgenes — la empresa paga precios de mercado por los modelos de **Anthropic** y de **OpenAI**, que enruta hacia sus clientes mientras compite con ellos a través de su línea **Composer**; SpaceX buscaba ingresos de IA y un relato de cara a una OPV prevista para junio. (B) La lectura de la estructura: un mínimo de 10.000 millones de dólares y una opción de compra de 60.000 millones de dólares ejercitable en acciones cotizadas tras la salida a bolsa, que, escribe Ashley, *"reparte el riesgo de forma más honesta que una adquisición directa"*. (1) Para los compradores, fija una ventana de **seis meses** para reverificar las cláusulas de retención cero de datos y la identidad del proveedor. (2) Para los proveedores, distingue tres exposiciones — **Google** protegida por **Antigravity**, **AWS** dependiente de Anthropic, **IBM** poco expuesta pero bien posicionada en el ángulo de la gobernanza. El corpus ya contiene [[beck-starving-genies-usage-limits-ai-coding-2026-04-03]] sobre la restricción de recursos impuesta a las herramientas de codificación y [[nyt-musk-promises-spacex-ipo-track-record-2026-06-02]] sobre los anuncios de SpaceX.
#SpaceX#Cursor#Anysphere
Mitch Ashley · VP et responsable des pratiques CIO & Technology Buyers et Software Lifecycle Engineering chez The Futurum Group · ancien CIO et CTO.
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
IA générative marco estratégico - 4 cuadrantes de despliegue - Paradoja del acceso - Datos como foso - Diferenciación estratégica - Harvard Business Review - Bharat N. Anand - Andy Wu
#estrategia de IA générative#ventaja competitiva#marco de cuatro cuadrantes
Bharat N. Anand (NYU Stern School of Business Dean) · Andy Wu (Harvard Business School)
Flujo de trabajo de IA para generar Wardley Maps, capacidades de prompts LLM, grafo de Obsidian, clustering con NetworkX, arranque estratégico - Tutorial en vídeo
#automatización de Wardley Mapping#prompts LLM#descomposición de capacidades