- El equipo de IA de StrongDM plantea el concepto de una Software Factory que crea software de alta calidad sin mirar el código
- Con base en especificaciones/escenarios, los agentes escriben código, ejecutan el arnés de pruebas y convergen sin revisión humana, en un modo de desarrollo no conversacional
- El código no debe ser escrito ni revisado por personas, y para que la software factory funcione correctamente se debe gastar al menos más de 1,000 dólares diarios en tokens por ingeniero
- Desde la segunda revisión de Claude 3.5 (octubre de 2024), los flujos de trabajo de programación con agentes de larga duración comenzaron a acumular exactitud de forma compuesta en lugar de acumular errores, confirmando la viabilidad del desarrollo no conversacional
- Al ampliar el concepto tradicional de pruebas, se introducen escenarios (scenario) y satisfacción (satisfaction), construyendo un sistema en el que un LLM evalúa probabilísticamente la satisfacción del usuario
- A través de Digital Twin Universe (DTU), se clonan SaaS clave como Okta, Jira y Slack para realizar validación a gran escala, lo que permite verificar escenarios con volumen y velocidad superiores a los límites de producción
- La era de los agentes cambia de raíz la economía del software, y construir réplicas SaaS de alta fidelidad, antes económicamente imposible, ahora se vuelve una tarea cotidiana
Concepto de Software Factory
- Un sistema de desarrollo no conversacional en el que especificaciones (specs) y escenarios (scenarios) impulsan a los agentes para escribir y validar código
- Se prohíbe que las personas escriban y revisen código, y los agentes llevan a cabo todo el proceso de desarrollo
- La eficiencia se mide con una referencia de más de 1,000 dólares diarios en consumo de tokens por ingeniero
- Este enfoque busca construir un entorno autónomo de producción de software en el que el código se genera, valida y converge automáticamente sin intervención humana
El arranque del equipo de IA de StrongDM
- El 14 de julio de 2025 se formó el equipo de IA de StrongDM y comenzó los experimentos de desarrollo no conversacional
- Participantes: Jay Taylor, Navan Chauhan, Justin McCarthy (cofundador y CTO)
- Desde finales de 2024, tras Claude 3.5 (revisión de octubre), mejoró la precisión en la escritura de código a largo plazo, haciendo posible la exactitud acumulativa (compounding correctness) en lugar de la acumulación repetitiva de errores
- A través del modo YOLO de Cursor, la capacidad del modelo para escribir código a largo plazo se hizo evidente
- En modelos anteriores, al aplicar repetidamente LLMs a tareas de programación, se acumulaban todo tipo de errores —malentendidos, alucinaciones, errores de sintaxis, violaciones DRY entre versiones, incompatibilidades de librerías— y la app “colapsaba”
- La combinación del modelo actualizado de Anthropic con el modo YOLO mostró la primera posibilidad real del desarrollo no conversacional o del software cultivado
Principio clave: no meter mano
- En la primera hora del primer día del equipo de IA se estableció una carta de principios, y el más importante fue: “las personas no deben escribir código directamente”
- Al inicio era una intuición simple y un experimento: ¿qué tan lejos se puede llegar sin escribir absolutamente nada de código a mano?
- Al principio toparon con límites, pero empezaron a avanzar después de agregar pruebas
- Los agentes se obsesionaban con la tarea inmediata y tomaban atajos: pruebas escritas de forma muy estrecha podían pasar con un simple return true, pero eso no se generalizaba al software que realmente se quería
- Las pruebas simples no bastan; hay que ampliarlas con pruebas de integración, regresión, end-to-end y de comportamiento
De las pruebas a los escenarios y la satisfacción
- Un tema recurrente en la era de los agentes: se necesita un nuevo lenguaje; la palabra “prueba” es insuficiente y ambigua
- Las pruebas guardadas en el codebase pueden reescribirse perezosamente para ajustarse al código, o el código puede reescribirse para pasar las pruebas de forma trivial
- Se redefine el término escenario: representa una historia de usuario end-to-end, se guarda fuera del codebase (similar a un conjunto de “holdout” en entrenamiento de modelos), y un LLM puede entenderla intuitivamente y validarla con flexibilidad
- Como el propio software que se está cultivando incluye componentes agentes, la evaluación del éxito deja de ser un booleano simple y pasa a una satisfacción (satisfaction) probabilística y empírica
- Satisfacción: cuantifica la proporción de trayectorias observadas que pasaron todos los escenarios y que probablemente satisfarían al usuario
Validación de escenarios mediante Digital Twin Universe
- En el esquema anterior, se decidía si “¿funciona?” mediante pruebas de integración, regresión y automatización de UI
- Se encontraron dos límites en técnicas antes confiables:
- Las pruebas son demasiado rígidas: al programar con agentes y construir bucles de LLM y agentes como primitivas de diseño, con frecuencia se necesita un LLM-as-judge para evaluar el éxito
- Las pruebas son vulnerables al reward hacking: se necesita una validación menos susceptible al engaño del modelo
- Digital Twin Universe (DTU) es la respuesta: clones conductuales de los servicios de terceros de los que depende el software
- Se construyeron twins de Okta, Jira, Slack, Google Docs, Google Drive y Google Sheets, replicando APIs, casos límite y comportamiento observable
- Con DTU, es posible validar con un volumen y una velocidad muy por encima de los límites de producción
- También permite probar modos de falla que serían riesgosos o imposibles sobre servicios en vivo
- Se pueden ejecutar miles de escenarios por hora sin alcanzar límites de tasa, activar detección de abuso ni acumular costos de API
Economía no tradicional
- El éxito con DTU muestra una de varias maneras en que el momento agentivo (Agentic Moment) cambia de raíz la economía del software
- Crear clones de alta fidelidad de aplicaciones SaaS importantes siempre fue posible, pero económicamente inviable
- Varias generaciones de ingenieros quisieron una réplica completa en memoria de un CRM de prueba, pero ni siquiera se lo proponían a sus gerentes porque esperaban un rechazo
- Quienes construyen una software factory deben practicar una ingenuidad deliberada (deliberate naivete): encontrar y eliminar hábitos, convenciones y restricciones de Software 1.0
- Con DTU, lo que hace seis meses era inimaginable ahora se vuelve una rutina de trabajo cotidiana
Lecturas recomendadas
- Principles : nuestras creencias sobre el desarrollo de software con agentes
- El software se cultiva con una estructura de seed → arnés de validación → bucle de retroalimentación, donde los tokens funcionan como combustible
- Todo software necesita una semilla inicial: antes podía ser un PRD o una especificación; hoy bastan unas cuantas frases, capturas de pantalla o un codebase existente
- El arnés de validación debe ser end-to-end y estar lo más cerca posible del entorno real (clientes, integraciones, economía)
- La retroalimentación de muestras de salida como entrada, en un bucle cerrado, permite que el sistema se autocorrija y acumule exactitud de forma compuesta
- La teoría de validación y retroalimentación es fácil de entender, pero en la práctica requiere ingeniería creativa y de punta: buscar cómo convertir todos los obstáculos en expresiones que el modelo pueda comprender
- Techniques : patrones recurrentes para aplicar estos principios
- Digital Twin Universe (DTU)
- Replica el comportamiento observable externo de dependencias críticas de terceros
- Valida con un volumen y velocidad muy superiores a los límites de producción
- Proporciona condiciones de prueba deterministas y reproducibles
- Gene Transfusion
- Ancla al agente en ejemplos concretos para transferir patrones de funcionamiento entre codebases
- Las soluciones emparejadas con buenas referencias pueden reproducirse en un nuevo contexto
- Filesystem
- El modelo puede explorar rápidamente el repositorio y ajustar su propio contexto leyendo y escribiendo archivos
- Directorios, índices y estado en disco funcionan como una base práctica de memoria
- Shift Work
- Separa el trabajo conversacional del trabajo completamente especificado
- Cuando la intención está completa (especificación, pruebas, app existente), el agente puede ejecutar end-to-end sin idas y vueltas
- Semport
- Portabilidad automatizada con conciencia semántica, en una sola vez o de forma continua
- Mueve código entre lenguajes o frameworks preservando la intención
- Pyramid Summaries
- Resúmenes reversibles en varios niveles de zoom
- Comprime el contexto sin perder la capacidad de expandirse otra vez a todo el detalle
- Products : herramientas que usamos todos los días y que creemos que también pueden ser útiles para otros
- CXDB es un almacén de contexto autohospedado para agentes de IA, con Turn DAG, deduplicación de blobs, tipos dinámicos y depuración visual
- StrongDM ID es un sistema de identidad para humanos, workloads y agentes de IA, con soporte para autenticación federada y uso compartido con alcance por ruta
- Attractor es un agente de programación no conversacional estructurado como un grafo de fases, para ejecución end-to-end cuando la tarea está completamente especificada
3 comentarios
Probé el desarrollo guiado por especificaciones usando múltiples agentes. Es cierto que reduce mucho el trabajo, pero por las limitaciones de rendimiento de los LLM no se pueden crear productos que satisfagan al cliente. No es posible un reemplazo al 100% y sigue siendo necesario cierto nivel de trabajo humano.
Es un texto bastante provocador, pero de alguna manera también se entiende hasta cierto punto... es un artículo que te deja con una sensación extraña.
Si lees el texto de abajo después de ver este, genera todavía más empatía.
Lloramos nuestro espíritu artesanal
Opiniones de Hacker News
Coincido con el concepto de Digital Twin Universe
Mi codebase también tiene muchas integraciones con servicios externos, así que si bloqueaba las llamadas externas durante las pruebas, casi no podía validar nada
Por eso hacía implementaciones falsas de cada API, como Okta, Jira, Slack y Google Docs, para probar
Eso sí, no replicaba la UI; solo imitaba el comportamiento de la API
Eso de que “si no gastas $1,000 al día en tokens por ingeniero, hay margen de mejora” suena demasiado irreal
Cuesta creer que lo digan en serio
Si haces las cuentas, da alrededor de $250k al año
Si la IA realmente produjera esa productividad, podría ser razonable
Siendo realistas, probablemente rinda como dos ingenieros junior
Al final, parece que los humanos quedarían en un rol de lead, ocupándose solo de planificar y validar
Es un optimismo exagerado, pero tampoco es una locura total
Yo solo uso suscripciones de $20 al mes de Claude y OpenAI
Cuando se me acaban los tokens, salgo a caminar o me pongo a leer
No soy un aceleracionista, pero igual trabajo lo suficiente
Soy parte del equipo de StrongDM
Gastar $1,000 al día en tokens es fácil; lo importante es que es difícil usarlos de forma productiva
Esto parece puro postureo
Como mandar la señal de “nosotros vamos más adelantados en IA que ustedes”
Me dio vergüenza ajena leer el artículo
Se siente como si hubieran empaquetado los mocks y las pruebas de simulación de siempre como si fueran una “innovación”
Aun así, les reconozco que hayan mostrado con franqueza su estructura de costos
En su sitio estaba buscando código o producto real
Lo único que encontré fue strongdm/attractor
Básicamente, “programar con una novia canadiense” ahora se volvió un modelo de negocio
Además encontré strongdm/cxdb, pero el historial de commits estaba ordenado
Sí hay código real en el repositorio de cxdb
No sé si esto es una locura o una muestra del futuro
En la página de Products también hay bases de datos y sistemas de identidad
Si varios agentes van a colaborar, hace falta sí o sí contexto compartido y un sistema de permisos
Escuché un webinar sobre BAML de BoundaryML
El spec-driven development es un enfoque para crear flujos de trabajo estructurados con humanos dentro del loop
Define con claridad el ciclo
/research → /plan → /implementy hace pasar cada etapa por validación humanaEs una filosofía completamente opuesta a la idea de StrongDM de que “los humanos no escriben ni leen código”
Se siente como otro post de blog vacío
No hay resultados concretos, y lo de los $1,000 al día en tokens parece más bien pensado para impresionar inversionistas
Si no resuelven el problema de validación, todo esto no pasa de ser postureo
Por más que pongas revisiones automáticas o guardrails, al final un humano tiene que comprobar la coincidencia entre la especificación y el resultado
En Speedscale estamos automatizando la validación con captura y reproducción de tráfico
En realidad, los desarrolladores humanos tampoco son perfectos
Ya existen varios procedimientos sistemáticos de validación, como code review, tests y QA
Lo importante no es si la IA es perfecta, sino si la calidad del sistema completo converge
En mi experiencia, con Opus 4.5 sí hay un pequeño beneficio neto
Yo también estoy casi de acuerdo
La clave es la validación más que la generación
Estoy construyendo una estructura en la que varios agentes independientes muestran sus desacuerdos y llegan a consenso
En pocas palabras, están trasladando la validación y las pruebas de seguridad al usuario final
Habría que usar más activamente lenguajes basados en especificaciones y verificación formal
Al final, la programación va a redefinirse como “el acto de concretar una especificación”
Con $1,000 al día en tokens, terminas gastando más en la IA que en un humano
Esto parece el punto de quiebre de la visión de la IA
Dicen que Simon Willison actualizó el artículo
$240k al año es nivel de ingeniero junior en FANG
Siendo honestos, hay muchos juniors peores que Claude
Al final, parece que todo se va a reorganizar como una estructura piramidal con pocos humanos en la cima
Si puedes terminar el mismo trabajo en 5 días, el costo frente a la velocidad podría ser razonable
Si el volumen de resultados crece proporcionalmente, la eficiencia costo-beneficio podría cerrar
Además, es posible que el precio de los tokens siga bajando
Las industrias legal y de seguros van a ser las que más sufran con este cambio
Los errores humanos se pueden modelar, pero los errores en cadena de loops autónomos son un problema totalmente distinto
Las decisiones de la IA al final se traducirán en responsabilidad humana
Eso probablemente termine siendo el freno de todo este cambio agentic
$1,000 al día en tokens es una métrica absurda
Si la calidad del código es mala, el consumo de tokens se dispara
Al final, un codebase desordenado es lo que encarece todo
Si un equipo quema mil dólares al día, casi seguro que su eficiencia es bajísima
(Referencia: este meme)
Es un problema de optimización de corto vs largo plazo
La decisión es si maximizas la eficiencia ahora o mejoras el sistema completo
Tal vez recién ahora la dirección entienda la importancia del refactoring
El equipo del patrón Dark Factory que mencioné antes eran ellos
Escribí este artículo relacionado, y este equipo es de los experimentadores más ambiciosos
Pero en la práctica casi no hay resultados
Si les dieras $10k a unos cuantos universitarios, probablemente harían algo mejor
Eso de $1,000 al día en tokens es algo que mi presupuesto de equipo ni puede soñar
En lo personal también me es imposible por costo de vida
Al final se siente como “si lo haces, pierdes; si no lo haces, también pierdes”
Si no hay resultados verificables, son solo palabras
Y ahora hasta las palabras salen mucho más baratas gracias a los LLM
Hace falta una divulgación ética
La terminología del sitio no pasa de ser un reempaque de conceptos ya existentes
“Digital Twin Universe” son mocks, “Gene Transfusion” es leer código de referencia, y “Semport” es transpiling
No hay datos ni benchmarks reales de ningún tipo
Es un caso de marketing de IA disfrazado de insight de ingeniería
En realidad, la mayor parte del código clave ya está en GitHub
La verdadera diferencia está en el diseño de mecanismos y en los valores
El futuro va a ir hacia la combinación de verificación formal (formal methods) e IA
Me parece interesante eso de “probar dejando escenarios como holdout set”
Es una idea que imita las pruebas agresivas de un equipo de QA
Separar al equipo que construye del equipo que detecta bugs para crear una estructura de competencia mutua me parece llamativo
Eso sí, $1,000 al día en tokens es desmoralizante para desarrolladores open source
Usando modelos locales se puede bajar el costo
Como en este hilo, la automatización de agentes locales también es perfectamente posible
Tal vez algún día lleguemos a ver agentes sobornándose entre sí
Yo sigo prefiriendo un enfoque con humanos dentro del loop
Quemar tokens sin criterio es un desperdicio
En el artículo “LLMs aren’t tools” exploré el marco mental para usar LLM
La “fábrica de software” es el punto de llegada actual, pero la siguiente etapa es ver al LLM como una aplicación
O sea, ya no solo automatizar workflows, sino construir un harness personalizado