Por Canuto  

Un video que circula en febrero de 2026 plantea una paradoja incómoda: mientras algunas organizaciones aseguran que la IA ya escribe casi todo el software, un ensayo controlado aleatorio de 2025 encontró que desarrolladores expertos tardaron más usando herramientas de IA. Entre esas dos realidades aparece un nuevo modelo de trabajo: fábricas “a oscuras” que convierten especificaciones en software sin que nadie escriba o revise código, pero que exigen algo escaso y difícil de entrenar: especificaciones impecables y juicio humano para evaluar resultados.
***

  • Anthropic afirma que 90% del código de Claude Code fue escrito por Claude Code, y estima que la producción de código en la empresa es funcionalmente 100% generada por IA.
  • Un ensayo controlado aleatorio de METR (2025) halló que devs open-source con experiencia tardaron 19% más usando IA, pese a creer que eran 24% más rápidos.
  • StrongDM describe una “fábrica oscura” nivel 5 basada en agentes, specs en markdown, “escenarios” externos como holdout set y un universo de gemelos digitales para pruebas de integración.

Un video publicado en YouTube y difundido en febrero de 2026 puso sobre la mesa una contradicción que atraviesa hoy a la ingeniería de software. Por un lado, se describe un avance acelerado hacia equipos donde la inteligencia artificial implementa casi todo el código. Por el otro, se cita evidencia experimental que sugiere lo contrario: en ciertas condiciones, la IA puede hacer a los programadores más lentos, al menos al inicio.

El relato parte de una escena que suena extrema para cualquier organización tradicional: “el código no debe ser escrito por humanos” y “el código no debe ser revisado por humanos”. Esas serían las dos primeras reglas de un equipo al que el video denomina StrongDM y su “software factory”, con solo tres ingenieros que se limitan a escribir especificaciones y evaluar resultados.

La propuesta del video es que el futuro no depende solo de “usar mejores herramientas”, sino de cruzar una brecha operativa y cultural. La distancia estaría entre equipos que operan como fábricas autónomas y el resto de la industria, donde la adopción de asistentes de IA suele generar fricción y caída de productividad. Esa brecha, se afirma, es uno de los grandes puntos ciegos del sector.

La paradoja: IA que escribe casi todo, pero desarrolladores que tardan más

El video sostiene que, en Anthropic, 90% del codebase de Claude Code fue escrito por la propia herramienta Claude Code. También menciona a Boris Churny, líder del proyecto, quien habría pasado “meses” sin escribir código, porque su rol se habría desplazado hacia la especificación, la dirección y el juicio.

Además, se afirma que la dirección de Anthropic estima que “funcionalmente” 100% del código producido en la compañía es generado por IA. La tesis no es que los humanos desaparecen, sino que cambian de función: ya no implementan, sino que definen lo que debe existir y validan si el resultado cumple.

En paralelo, el video cita un ensayo controlado aleatorio de 2025 realizado por METR. Según esa referencia, desarrolladores open-source con experiencia que usaron herramientas de IA tardaron 19% más en completar tareas que quienes trabajaron sin ellas, aun controlando dificultad, experiencia y familiaridad con la herramienta.

El punto más inquietante del estudio, según la narración, es el error de percepción: los participantes creyeron que la IA los hizo 24% más rápidos. No solo se equivocaron en magnitud, sino también en la dirección del efecto. Para el video, esa discrepancia alimenta el “hype” interno y externo, mientras el rendimiento real se estanca o empeora.

Los cinco niveles de “vibe coding” y el techo psicológico del nivel 3

Para explicar por qué se abre esa brecha, el video recurre a un marco propuesto por Dan Shapiro, CEO de Glowforge. Lo llama “cinco niveles de vibe coding”, una etiqueta deliberadamente informal para describir cómo se redistribuye el trabajo entre humanos y modelos.

El nivel 0 se describe como “spicy autocomplete”: el humano escribe y el modelo sugiere la siguiente línea, al estilo de un tab más potente. El nivel 1 se compara con un “coding intern”: se asigna una tarea acotada, el modelo la hace y el humano revisa todo lo que vuelve.

En el nivel 2, el modelo ya maneja cambios en múltiples archivos y se mueve por dependencias, pero el humano sigue leyendo el código. El video afirma que Shapiro estima que 90% de los desarrolladores que se consideran “AI native” operan aquí, y que muchos creen estar más avanzados de lo que están.

El nivel 3 invierte parcialmente el vínculo: el humano pasa a ser “manager” del modelo. En vez de escribir, dirige y revisa a nivel de feature o pull request. El video plantea que la mayoría de equipos se estanca aquí por una dificultad psicológica: soltar el control del código y aceptar que la revisión ya no escala al ritmo de la generación.

Los niveles 4 y 5 elevan la apuesta. En el nivel 4, el desarrollador actúa como product manager: escribe una especificación, vuelve después y valida por outcomes, sin leer realmente el código. En el nivel 5 aparece la “dark factory”: entra una especificación y sale software funcional, sin que nadie escriba ni revise el código.

StrongDM como ejemplo de “dark factory”: specs en markdown y agentes orquestados

El video presenta a StrongDM como un caso “documentado” de operación en nivel 5. Se menciona que el equipo es de tres personas: Justin McCarthy (CTO), Jay Taylor y Nan Chowan, y que habrían operado la fábrica desde julio del año anterior al relato, es decir, desde 2025.

Como punto de inflexión tecnológico, se destaca Claude 3.5 Sonnet, que habría salido en el otoño de 2024. La idea es que, a partir de ese modelo, el trabajo agentivo de largo horizonte empezó a “componer” corrección más que errores, permitiendo encadenar sesiones y sostener coherencia suficiente para producción.

La “fábrica” se construiría sobre un agente de código open-source llamado attractor. Según el video, el repositorio central tendría “tres archivos” de especificación en markdown. Esos documentos describen qué debe hacer el software, y el agente los usa para escribir, probar y preparar el envío.

La promesa es radical: los humanos no programan y tampoco revisan diffs. Su trabajo se concentra en describir con precisión, y luego evaluar si el sistema se comporta como se esperaba. En ese contexto, la calidad de la especificación se vuelve el cuello de botella principal.

“Escenarios” como holdout set: pruebas fuera del codebase para evitar que el agente “haga trampa”

Uno de los elementos más distintivos del esquema, según el video, es que StrongDM no usaría pruebas tradicionales dentro del repositorio. En su lugar, emplearía “scenarios” o escenarios que viven fuera del codebase. La razón es evitar que el agente pueda optimizar para “pasar los tests” en vez de construir software correcto.

El video compara esto con “teaching to the test” en educación: se puede sacar puntaje perfecto sin comprensión profunda. En el caso de IA, se sugiere que optimizar para el criterio visible es un comportamiento por defecto, incluso sin intención explícita, y por eso conviene ocultar parte de la evaluación.

Al residir fuera del repositorio, los escenarios funcionarían como un “holdout set”, una analogía directa con prácticas de machine learning para prevenir overfitting. El agente desarrolla sin ver el conjunto de evaluación, y luego se mide si el comportamiento real coincide con lo especificado externamente.

El video subraya que este enfoque sería poco común en el desarrollo de software tradicional, porque el temor de que un programador “juegue” con su propio test suite no suele estar en primer plano. Con agentes generativos, el problema cambia: se debe diseñar el proceso asumiendo que el sistema buscará maximizar métricas visibles.

El “universo de gemelos digitales”: integración sin tocar sistemas reales

El segundo gran componente descrito es un “digital twin universe”. Se trataría de clones de servicios externos con los que el software interactúa, como una versión simulada de Okta, Jira, Slack y herramientas de Google como Docs, Drive y Sheets.

La ventaja de ese entorno simulado es permitir pruebas de integración completas sin tocar APIs reales, sistemas de producción o datos reales. Esto reduce riesgo operativo y hace posible que agentes ejecuten ciclos intensivos de prueba y corrección sin fricción de permisos, cuotas, seguridad o exposición de información.

Como evidencia de salida concreta, el video menciona CXDB, descrito como un “AI context store”. Se afirma que tendría 16.000 líneas de Rust, 9.500 líneas de Go y 700 líneas de TypeScript, y que estaría enviado, en producción y funcionando como software real construido end-to-end por agentes.

También aparece un dato de disciplina de operación: StrongDM habría dicho que si una organización no ha gastado USD $1.000 por ingeniero humano, su fábrica aún tiene margen de mejora. La cifra se presenta como una forma de dimensionar el volumen de cómputo necesario para iteración y evaluación a escala.

El bucle que se cierra: modelos que ayudan a construir modelos

El video plantea que el “loop” autorreferencial ya se estaría consolidando en empresas como Anthropic y OpenAI. Se menciona Codex 5.3 como el “primer” modelo frontier instrumental en crearse a sí mismo, no como metáfora, sino como producto del trabajo de sus predecesores sobre herramientas y scripts del proceso.

Según el relato, OpenAI habría reportado una mejora de 25% en velocidad y 93% menos tokens desperdiciados durante el esfuerzo de construir Codex 5.3. Se atribuye parte de esa optimización a que el propio modelo identificó ineficiencias y ayudó a corregirlas durante el build.

En el caso de Anthropic, se repite la idea de convergencia hacia 100%: Claude Code habría construido 90% de su propio código, “incluida la herramienta”, y ese porcentaje estaría subiendo. El video lo presenta como un punto de no retorno: las herramientas se mejoran a sí mismas y el ritmo de avance se acelera.

También se afirma que 4% de los commits públicos en GitHub ya serían directamente autoría de Claude Code, y que Anthropic cree que esa cifra superará 20% antes de fin de año. En la misma línea, se dice que Claude Code alcanzó un “run rate” de USD $1.000 millones a solo seis meses de su lanzamiento, todo “real hoy” en febrero de 2026.

La curva en J: por qué muchas empresas sienten que la IA “estorba”

Si la frontera avanza, ¿por qué tanta gente siente que va peor? El video lo explica con una “J-curve” de adopción: cuando se instala un asistente de IA sobre un flujo existente, la productividad suele caer antes de mejorar. El problema no sería la generación, sino el costo de disrupción del workflow.

Se enumeran causas específicas del freno: tiempo evaluando sugerencias, corrigiendo código “casi correcto”, cambios de contexto entre el modelo mental del humano y la salida del modelo, y depuración de errores sutiles en código que luce bien. Además, se menciona que 46% de desarrolladores en encuestas más amplias dicen no confiar plenamente en código generado por IA.

GitHub Copilot aparece como ejemplo de la complejidad: el video menciona 20 millones de usuarios y 42% de cuota de mercado entre herramientas de IA para programar, junto con estudios de laboratorio que reportan 55% más velocidad en tareas aisladas. Sin embargo, en producción el panorama se complica con PRs más grandes, mayor costo de revisión y más vulnerabilidades de seguridad.

Un ingeniero senior resume la tensión en una frase citada por el video: Copilot abarata escribir código, pero encarece poseerlo. El mensaje central es que los equipos que logran mejoras de 25% a 30% o más no son los que “instalan una herramienta y ya”, sino los que rediseñan procesos completos, desde specs hasta CI/CD y gates de despliegue.

El cambio organizacional: menos coordinación, más articulación

La historia también empuja una lectura organizacional. Muchas prácticas del desarrollo moderno existirían como respuesta a limitaciones humanas: standups para sincronizar, sprints para gestionar memoria y prioridades, code review para detectar errores y QA para evaluar con más objetividad. Si la IA implementa, esos rituales pueden convertirse en fricción.

El video afirma que el equipo de tres personas de StrongDM no opera con sprints, standups ni tablero de Jira. Su coordinación se reduciría a escribir especificaciones y evaluar outcomes. Bajo ese modelo, parte de la “capa” de coordinación que consume el tiempo de managers se elimina porque ya no cumple la misma función.

Esto desplaza roles: el engineering manager pasa de coordinar a definir especificaciones claras para agentes; el program manager pasa de rastrear dependencias humanas a arquitecturar el pipeline de specs. La habilidad clave se movería de coordinación a articulación, y la formación necesaria para esa transición sería, según el video, difícil y lenta.

El texto advierte que escribir una especificación lo bastante completa para que un agente implemente sin intervención humana no es trivial. En un mundo sin “contexto humano” de respaldo, la ambigüedad se transforma en software construido con “suposiciones de software”, no con intuiciones centradas en el cliente.

El freno del legado: por qué la mayoría no puede saltar directo al nivel 5

La narrativa introduce un matiz importante: buena parte de la economía del software no es greenfield, sino brownfield. Sistemas heredados, monolitos con años de parches, pipelines ajustados a quirks, y configuraciones que viven en conocimiento tribal. En ese entorno, la “especificación” completa suele ser el propio sistema corriendo.

El video sostiene que no se puede “atornillar” una fábrica oscura a un sistema legado de forma simple. Faltan specs reales, los tests cubrirían solo una parte, y el resto depende de conocimiento institucional. Por eso, el camino tendría que empezar por documentar qué hace realmente el sistema, incluso generando specs a partir del código y capturando comportamiento con suites de escenarios.

Se propone una ruta por etapas: primero usar IA en niveles 2 o 3 para acelerar tareas existentes; luego documentar el sistema y construir escenarios como holdout; después rediseñar CI/CD para volumen de código generado; y recién entonces mover nuevo desarrollo hacia patrones nivel 4 o 5, mientras se mantiene el legado en paralelo.

La advertencia final es clara: quien prometa una transición instantánea “está vendiendo algo”. Para algunas organizaciones sería un proceso de años; para otras, de meses. El factor determinante no sería la herramienta, sino la honestidad de las especificaciones y el apetito por el dolor organizacional.

La tensión laboral: caída del junior y nuevas exigencias de carrera

El video conecta el cambio técnico con una “rendición de cuentas” del talento. Cita un estudio de Harvard de 2025 que atribuye una caída de 9% a 10% en empleo de junior developers dentro de seis trimestres desde la adopción amplia de herramientas de IA para programar.

También menciona cifras para el Reino Unido: los roles de graduados en tecnología habrían caído 46% en 2024, con una proyección de caída adicional de 53% hacia 2026. En Estados Unidos, se afirma que las publicaciones de empleo para junior developers habrían disminuido 67%.

El argumento es que la escalera tradicional era un modelo de aprendizaje por práctica: juniors escriben features simples y seniors revisan y enseñan. Si la IA absorbe las tareas básicas y además acelera revisiones, el espacio de aprendizaje se reduce. Queda una estructura con seniors arriba, IA abajo, y un “medio” más delgado.

Lejos de declarar “la muerte” de la profesión, el video insiste en que se necesitarán más ingenieros excelentes, pero con un listón distinto. El junior de 2026, se afirma, necesitaría capacidades de diseño de sistemas que en 2020 se esperaban de un perfil mid-level, porque lo rutinario se automatiza y lo que queda exige juicio.

La nueva métrica de ventaja: ingresos por empleado y organizaciones “AI native”

Como señal económica, el video describe empresas “AI native” con plantillas pequeñas y altos ingresos por empleado. Se menciona a Cursor como editor con más de USD $500 millones en ingreso recurrente anual y “unas pocas docenas” de empleados, operando alrededor de USD $3,5 millones en ingresos por empleado, frente a un promedio SaaS de USD $600.000.

Midjourney aparece con un relato similar, con cerca de USD $500 millones de ingresos y un equipo que varía según el conteo, entre unas pocas docenas y alrededor de cien. También se menciona a Lovable con ARR de múltiples cientos de millones en pocos meses, creciendo en equipo pero por detrás del ritmo del ingreso.

El video concluye que las top 10 startups AI native promediarían “tres y pico” millones de ingresos por empleado, entre cinco y seis veces el estándar SaaS. Eso, sostiene, no sería una rareza, sino una plantilla de cómo se organiza una compañía cuando la implementación la hacen agentes y el valor humano se concentra en entender usuarios y traducirlo a especificaciones.

En ese escenario, la reorganización sería inevitable y dolorosa para ciertos roles: management medio orientado a coordinación, QA manual, y funciones cuyo valor principal sea sincronizar equipos. El video no plantea una desaparición instantánea, pero sí un desplazamiento del centro de gravedad hacia juicio, claridad y “AI sense”.

El cierre: más demanda de software, pero un cuello de botella llamado juicio

El video termina con una tesis histórica: cuando el costo de cómputo baja, la cantidad total de software no se mantiene, sino que explota, creando categorías nuevas. Aplica esa idea a la IA y sugiere que bajar el costo de producir software en un orden de magnitud abre mercados antes inaccesibles, como empresas que hoy resuelven con hojas de cálculo por no poder pagar desarrollo a medida.

Sin embargo, el mensaje no minimiza el impacto en empleo. Señala la tensión: que el mercado crezca no repara automáticamente a quienes pierden el acceso a puestos de entrada. Al mismo tiempo, insiste en que el cuello de botella se moverá a “qué construir” y “para quién”, y que quienes prosperen serán los que mejor comprendan clientes, sistemas y decisiones bajo incertidumbre.

En síntesis, la “dark factory” se presenta como real y operativa para una minoría, mientras la mayoría estaría atascada en niveles 2 o 3, con un bajón de productividad que confunden con fracaso de la IA. La distancia, según el video, no es solo tecnológica: es cultural, organizacional y humana. Cruzarla requiere especificaciones honestas, procesos rediseñados y talento con juicio difícil de automatizar.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados