En enero de 2026, un fundador lanzó Moltbook, una red social construida enteramente con agentes de inteligencia artificial. Él mismo lo contó con orgullo: no había escrito una sola línea de código. Todo el producto emergió de conversaciones con agentes que ejecutaron, archivo por archivo, lo que se les pidió. Setenta y dos horas después del lanzamiento, la aplicación había expuesto 1,5 millones de tokens de autenticación y 35.000 direcciones de correo. Investigadores de la firma Wiz encontraron la llave de la base de datos visible en el código del navegador, con las protecciones de acceso a los datos desactivadas.

Lo notable no es la vulnerabilidad. Cualquier ingeniero, en una revisión de rutina, la habría detectado en minutos. Lo notable es que nadie decidió exponer esos datos. Simplemente nadie decidió lo contrario, y la configuración quedó donde el sistema la dejaba por defecto. La catástrofe no fue una mala decisión. Fue una no-decisión, ocupada por un default.

La no-decisión también decide

Moltbook no es una anécdota aislada. En mayo de 2026, la firma de ciberseguridad RedAccess escaneó unas 380.000 aplicaciones construidas en plataformas de desarrollo con agentes y encontró cerca de 5.000 filtrando datos sensibles al público: registros médicos, finanzas internas de un banco, documentos de estrategia corporativa, información de ensayos clínicos de una empresa de salud. La prensa leyó estos casos como un problema de ciberseguridad. La lectura profunda es más incómoda, y más general.

El patrón que une todos estos incidentes es que el agente hizo todo lo que se le pidió, y nada de lo que no se le pidió. Un agente genera código que satisface el requerimiento declarado, sin los supuestos no declarados que un profesional experimentado aplica automáticamente, porque los lleva incorporados como oficio. Y cuando el criterio falta, el agente no se detiene a preguntar como lo haría un empleado nuevo prudente: resuelve la ambigüedad con lo genérico, con lo que estadísticamente aparece más en todo lo que ha visto. De ahí la regla que estos incidentes vienen a enseñar: el vacío de criterio nunca queda vacío. Se llena solo, con el promedio.

Lo que explota en silencio

La seguridad es apenas el lugar donde ese mecanismo explota primero y con titulares, porque los datos filtrados dejan evidencia. Pero el mismo mecanismo opera sobre una dimensión que no genera noticias: el producto. Un agente sin criterio no construye un mal producto deliberadamente. Construye el producto promedio, el que resultaría de mezclar todos los productos parecidos que existen. Que es exactamente el producto que no diferencia a nadie, no sirve a ningún usuario específico y no mueve ningún indicador del negocio.

Los números de la industria ya muestran esa brecha. Una investigación de académicos del MIT y Wharton, publicada en mayo de 2026, encontró que los agentes de código aumentaron la producción de código en 180%, mientras el software efectivamente entregado creció apenas 30%. Y Gartner proyecta que más del 40% de los proyectos de IA agéntica serán cancelados antes de escalar. La capacidad de ejecución se multiplicó; el resultado apenas se movió. La distancia entre esos dos números es la distancia entre ejecutar y juzgar.

product-sense.md, el archivo que salvaba el día en Moltbook

La industria ya instaló una respuesta parcial, bajo el nombre de ingeniería de contexto. Los repositorios de código serios incluyen hoy archivos versionados, como el estándar AGENTS.md, que le dicen al agente cómo trabajar en ese proyecto: comandos, convenciones, estructura, formas de verificar. Es, en la práctica, el onboarding permanente de la fuerza de trabajo digital. Pero ese archivo codifica el cómo trabajar. No dice una palabra sobre qué es bueno…

Lo que casi ninguna organización ha escrito es el segundo archivo. Llamémoslo product-sense.md: el archivo del criterio. Quién es el usuario y qué le duele. Qué significa “bueno” en este producto. Qué no construir aunque parezca obvio. Cómo desempatar cuando la especificación calla. Cada sesión de trabajo con agentes contiene decenas de bifurcaciones que ningún requerimiento anticipó, y cada una se resuelve en silencio hacia el promedio, salvo que exista criterio escrito que la resuelva hacia el negocio.

# product-sense.md — Moltbook

## Qué es este producto
Una red social. Nuestro activo no son las features:
es la confianza de gente que nos entrega su identidad,
sus contactos y sus conversaciones.

## Qué es "bueno" aquí
- Bueno = el usuario controla quién ve lo suyo.
- Cualquier dato de un usuario es privado hasta que él
  decida lo contrario. Nunca al revés.

## Qué NO hacer aunque acelere el lanzamiento
- No lanzar ninguna feature que toque datos de usuarios
  sin responder antes: ¿quién más puede ver esto?
- No aceptar defaults de plataforma en nada que involucre
  datos personales. Los defaults optimizan la demo,
  no la confianza.

## Cómo desempatar cuando nadie especificó
Ante cualquier ambigüedad entre "que funcione ya"
y "que proteja al usuario": proteger al usuario.
El costo de un día de retraso es recuperable.
El costo de una filtración, no.

Hay un matiz decisivo, medido por investigadores de ETH Zurich: los archivos de contexto generados automáticamente por los propios modelos empeoran el desempeño de los agentes y encarecen su operación, mientras que solo los escritos por humanos que conocen de verdad el proyecto agregan valor. Dicho de otro modo: no se puede delegar en la máquina la escritura de su propio criterio. Esa es, quizás, la definición más precisa del trabajo directivo en la era de los agentes.

Empezar por una página

Las organizaciones llevan décadas conociendo la diferencia entre darle a un gerente nuevo el reglamento y darle la cultura de decisión de la casa. El reglamento evita el escándalo; la cultura produce las decisiones que el fundador habría tomado. Con los agentes la lección es la misma, con una diferencia brutal: el nuevo integrante del equipo no absorbe cultura por ósmosis en el pasillo. Solo lee archivos.

La salida no es un manual. Es una página. Reunir a las dos o tres personas que hoy cargan el criterio del producto en la cabeza y hacerles cuatro preguntas: para quién es esto, qué es bueno aquí, qué no construimos, cómo se desempata cuando nadie está mirando. De hecho, prácticas ampliamente reconocidas como Lean Inception de Paulo Caroli tienen un ejercicio llamado “Es / No Es, Hace / No Hace”, que justamente aborda este tipo de temática. Lo mínimo: volcar ese conocimiento en este archivo de alguna manera.

Escribir las respuestas donde los agentes, y también los humanos, puedan leerlas. Versionarlas como se versiona el código, porque el criterio también evoluciona. Y volver a ellas cada vez que un agente entregue algo técnicamente correcto que se sienta equivocado: ahí hay, casi siempre, una regla implícita esperando ser escrita.

La pregunta que queda

En Itera venimos acompañando a organizaciones que están incorporando agentes a sus procesos de desarrollo y de negocio, y el patrón se repite: la tecnología casi nunca es el cuello de botella; el criterio no escrito, casi siempre. La pregunta con la que vale la pena quedarse es simple. El criterio de producto de su organización, ¿está escrito donde sus agentes puedan leerlo, o vive en la cabeza de tres personas que no estarán en la sala cuando la próxima no-decisión se tome sola?