Por qué fracasan las fábricas de software: la ingeniería de harness por sí sola no basta

 (github.com/humanlayer)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Una fábrica de software sin supervisión humana (lights-off), donde las personas no leen ni escriben código, aumenta la velocidad de generación, pero también elimina a los humanos que juzgan la mantenibilidad a largo plazo, por lo que es difícil que funcione en codebases de producción complejas
  • El aprendizaje por refuerzo de los modelos de coding optimiza recompensas rápidas y claras, como pasar pruebas, y no puede penalizar el costo de un mal diseño que aparece meses después
  • La familia SWE-bench evalúa la corrección de bugs y la preservación de pruebas existentes, pero no filtra cambios que degradan gradualmente la calidad del código, como try/catch indiscriminados, casts de tipos o shotgun surgery
  • Por ahora, los humanos deben encargarse de la revisión de código y revisar requisitos de producto, arquitectura del sistema, diseño del programa y slices verticales antes de la implementación para reducir retrabajo y revisiones masivas de código generado por IA
  • Si se reconocen las limitaciones de los modelos, en lugar de perseguir una automatización forzada de 10 a 100 veces, se puede desarrollar 2 a 3 veces más rápido manteniendo una calidad cercana a la humana; el juicio clave y la lectura de código aún no pueden tercerizarse

La promesa y la realidad de las fábricas de software centradas en loops

  • En la carrera por adoptar AI coding en producción, se ha extendido la idea de que basta con aumentar los harnesses y los loops de agentes
  • Este enfoque parte de la premisa de que las personas son el cuello de botella, que los modelos ya son suficientemente buenos y que, como el costo de generar código es prácticamente bajo, basta con lanzar más
  • El objetivo es lograr al mismo tiempo 10 a 100 veces más velocidad, alta calidad y eliminar la revisión humana de código
    • Se asume que, si se configuran más linters y se instruye a los bots de revisión de PR para hacer una revisión adversarial, el software puede volverse seguro por sí mismo
  • En la práctica, ya aparecen casos donde errores de agentes de coding causan incidentes y las codebases se deterioran rápidamente
  • El informe de Faros AI observó los siguientes cambios tras adoptar herramientas de AI coding
    • Aumentaron la cantidad y la longitud de los comentarios de revisión, pero también crecieron los PR que se mergean sin revisión
    • Aumentaron los incidentes y los bugs por desarrollador
    • Aun así, se trata más de una señal de correlación que de una causalidad verificada
  • Es difícil encontrar datos concluyentes que muestren los resultados de StrongDM, y también han sido poco frecuentes las actualizaciones públicas entre febrero y junio

Una codebase compleja es un problema distinto al vibe coding

  • Un proyecto paralelo usado por pocas personas y un equipo que mantiene un sistema enterprise de 10 años comparten muy pocas restricciones
  • El tema no es el vibe coding en sí, sino los problemas difíciles de las codebases complejas y el mantenimiento en producción
  • Antes, brownfield solía referirse a sistemas Java antiguos, entre otros, pero una codebase creada por agentes también puede volverse difícil de modificar después de unos 3 a 6 meses debido a la velocidad de desarrollo
  • Cuando el resultado es malo, se suele aconsejar que faltan tokens o tecnología, pero el problema central está más en la forma de entrenamiento del modelo que en el harness

La evolución de la fábrica de software

  • Desde 1968 hasta antes de la adopción de la IA

    • El término “fábrica de software” se remonta a la conferencia de la OTAN de 1968, donde apareció la expresión “ingeniería de software”
    • Una fábrica típica alrededor de 2022 tenía el siguiente ciclo
      • Una persona decide qué construir y lo registra en un tracker como Linear o Jira
      • La persona responsable implementa y prueba
      • Pasa por chequeos automáticos y revisión humana de código; si hay problemas, vuelve a la implementación
      • Tras desplegar a producción, se monitorea, y los incidentes y el feedback de usuarios vuelven al tracker
    • Como la implementación y la revisión pueden tomar horas o días cada una, los equipos colocan por adelantado planificación, propuestas de arquitectura y sprint planning para generar consenso primero
    • El consenso antes de implementar reduce el retrabajo, y un PR de alta calidad que se acerca a la dirección acordada se puede revisar rápido incluso leyendo todas las líneas

  • Fábricas agentic

    • Ramp, Stripe, WorkOS, Brex y otras empresas afirman que sus fábricas con agentes envían alrededor del 75% del código
    • En la fábrica tradicional, la etapa que implementaba una persona se reemplaza por un agente, combinando orquestación, harnesses, sandboxes, modelos y uso de computadoras
    • El tiempo de implementación baja de horas o días a minutos u horas, pero la lectura de código y las pruebas humanas se mantienen, por lo que la revisión se vuelve el cuello de botella
    • Para reducir este cuello de botella se agregan varios loops
      • Revisión de código con agentes para estilo, bugs y seguridad
      • Pruebas de regresión que verifican el comportamiento externo mediante navegador y uso de computadora
      • Flujos que conectan automáticamente incidentes con PR para que la persona responsable reciba candidatos de corrección
      • Flujos que conectan el feedback de usuarios directamente con la cola de tareas
    • Al final, el problema operativo se reduce a cuántas tareas se pueden meter en la cola y qué tan rápido se pueden revisar y probar los resultados

  • Fábricas sin supervisión humana

    • La fábrica sin supervisión humana, nombrada por Dan Shapiro, elimina la etapa en la que los humanos leen cada cambio
    • En lugar de revisión de código, se invierte en las siguientes áreas
      • Pruebas propias del agente
      • Sandboxes y orquestación
      • Revisión automática y monitoreo
      • Lanzamientos graduales y recolección de señales de feedback de usuarios
    • Si se elimina el juicio humano, lo único que queda es cuántas tareas se pueden pedir al agente, pero este enfoque no funciona en codebases de producción complejas

El fracaso de aplicar directamente el enfoque sin supervisión humana

  • Desde julio de 2025, se aplicó un enfoque completamente sin supervisión humana en el que agentes en segundo plano se encargaban de tareas pequeñas y medianas leyendo solo especificaciones y tickets
  • Tras unos meses, surgieron problemas complejos que no se resolvían ni con prompts avanzados ni con workflows
    • Se recopiló el contexto necesario y se le entregó al modelo
    • El agente intentó reproducir el problema de unas 10 formas
    • Al final, un humano tuvo que entrar directamente a una codebase que no había leído en 3 meses para encontrar la causa
  • Mientras tanto, el sitio se cayó, los usuarios sufrieron molestias y los humanos tuvieron que leer el código de baja calidad acumulado
  • En el primer fracaso se consideró que valía la pena asumir el riesgo por velocidad, pero en noviembre, cuando apareció aproximadamente el tercer problema, era más fácil reescribir desde cero
    • Un cofundador reimplementó manualmente el patrón durante 2 semanas en VS Code

Por qué los modelos degradan la calidad de la codebase

  • Los modelos actuales no pueden mantener ni mejorar la calidad de una codebase a largo plazo sin una dirección humana considerable
  • Aquí, mantenibilidad significa la capacidad de evitar un estado de shotgun surgery, donde cambiar una parte rompe otra y el mismo cambio debe aplicarse en varios lugares
  • Los modelos han avanzado mucho en resolver problemas puntuales o crear nuevos sitios de marketing, pero no parece haber una mejora clara en su capacidad de mejorar la calidad del código con el tiempo
  • Como no hay buenos benchmarks para medir la capacidad de mantenimiento, también es difícil demostrar o refutar esta diferencia
  • Incluso si un modelo como GPT-5.5 xhigh realiza una excelente refactorización, si un humano debe entender la codebase e indicar de forma concreta qué hace falta, el problema de la fábrica sin supervisión humana no se resuelve

Claude Code y el aprendizaje por refuerzo dentro del harness

  • Antes de Claude Code ya existían agentes CLI como aider, cline y codebuff, que ofrecían herramientas de lectura, escritura, edición, búsqueda, shell e ingeniería de contexto
  • A veces, los agentes existentes carecían de estabilidad en el uso de herramientas, por ejemplo al fallar repitiendo la misma edición
  • El paper de SWE-Agent analiza que incluso pequeñas diferencias de diseño de herramientas, como incluir números de línea en el resultado de ReadFile o cambiar Edit de buscar/reemplazar a edición por rangos de líneas, afectan el rendimiento
  • Se señala como una razón clave del rápido crecimiento de Claude Code que Anthropic entrenó por refuerzo el modelo dentro del harness que efectivamente iba a lanzar
    • Ajustó los pesos para que el modelo llamara al conjunto exacto de herramientas dentro del loop del agente
    • A diferencia de desarrolladores externos que adaptan definiciones de herramientas y evaluaciones a las preferencias del modelo, el dueño del modelo puede modificar el propio modelo para ajustarlo a las herramientas
  • Un equipo que tiene tanto el harness como los pesos del modelo tiene ventaja sobre uno que solo puede construir el harness y no ajustar los pesos

Límites de recompensa en el aprendizaje por refuerzo de agentes de coding

  • El aprendizaje por refuerzo de modelos de coding suele repetir millones de veces el siguiente procedimiento
    1. Genera un trace de ejecución del agente para resolver un problema, como corregir una prueba
    2. Evalúa el trace de ejecución con un verificador
    3. Actualiza los pesos del modelo para aumentar la probabilidad de los buenos traces de ejecución y reducir la de los malos
  • El problema es que la puntuación de evaluación puede ser demasiado unidimensional

  • Caso de SWE-bench Multilingual

    • SWE-bench Multilingual usa tareas de unos 15 minutos tomadas de repositorios open source como Redis, jq y Django
    • La recompensa es 0 o 1 y verifica dos condiciones
      • FAIL_TO_PASS: si corrigió el problema solicitado
      • PASS_TO_PASS: si no rompió el comportamiento existente
    • La tarea fastlane__fastlane-19304 es un bug en el que, cuando faltan los parámetros opcionales include y exclude, se llama .empty? sobre nil y falla
    • La corrección humana real fue un cambio de dos líneas que establecía nil por defecto como un arreglo vacío
    • El modelo recibe solo el commit base justo antes de la corrección y el reporte del bug; no ve el patch de la solución ni el patch de pruebas usado para calificar
    • La evaluación avanza en este orden
      1. Conserva el patch creado por el modelo
      2. Elimina los cambios que el modelo haya hecho en archivos de prueba
      3. Aplica el patch de pruebas privado del benchmark
      4. Ejecuta las pruebas existentes y las nuevas juntas
    • La razón para descartar cambios en pruebas es que algunos modelos hacen pasar todo comentando pruebas fallidas o agregando mocks sin sentido
    • El benchmark y el verificador de aprendizaje por refuerzo no son lo mismo y deberían estar separados, pero ambos muestran una limitación estructural al juzgar la calidad de los traces de ejecución de coding

  • No hay penalización por degradar el diseño

    • Si las pruebas pasan, el proceso seguido para llegar a la solución y la calidad estructural no se reflejan en la puntuación
    • También pueden considerarse respuestas correctas envolver todo con try/catch o casts de tipos laxos que destruyen las ventajas del sistema de tipos
    • El daño a la mantenibilidad no recibe penalización mientras pasen las pruebas existentes y nuevas

Verificar calidad es más difícil que pasar pruebas

  • Las pruebas ofrecen éxito o fracaso claros en segundos, por lo que el aprendizaje por refuerzo puede repetirse millones de veces
  • El costo de una mala arquitectura aparece semanas, meses o años después, cuando un pequeño cambio debe aplicarse en varios lugares
  • Los benchmarks actuales no pueden evaluar ese costo de diseño a largo plazo
  • El aprendizaje por refuerzo y los benchmarks no son lo mismo, pero si la mantenibilidad se hubiera resuelto con aprendizaje por refuerzo, es probable que esa capacidad también apareciera en el diseño de benchmarks
  • Por lo tanto, no se puede tomar la mejora en puntajes de benchmarks existentes como evidencia de que el modelo ya no ensucia la codebase

Nuevos intentos de evaluar la mantenibilidad

  • La frontera de calidad de los modelos está mejorando, pero las expectativas y el marketing van por delante de la disciplina técnica
  • Algunos casos que intentan evaluar algo más cercano a la mantenibilidad son
    • SWE-Marathon: usa tareas de unas 400 horas, como replicar todas las funciones de Excel, y canales de recompensa compuestos en lugar de un único éxito/fracaso
    • DeepSWE: reduce la contaminación de datos de entrenamiento usando grandes tareas open source que no fueron implementadas en la realidad, pero no resuelve el problema de calidad en sí
    • Frontier Code: evalúa tareas que abarcan varios PR y penaliza escribir pruebas que no fallan incluso en el código previo al patch
      • Verifica la validez de las pruebas de forma determinista con un método similar a mutation testing
      • También ejecuta un modelo juez que revisa el diff según reglas de calidad de código
  • Existe una limitación: si un modelo juez puede distinguir la calidad de forma estable, entonces quizá también podría haber generado buen código desde el principio
  • El aprendizaje por refuerzo necesita un oráculo rápido y confiable, pero la mantenibilidad no tiene un oráculo así
  • Los agentes de revisión y los tokens adicionales pueden detectar errores evidentes y elevar el piso de calidad, pero no elevan el techo de calidad más allá de lo que el modelo aprendió mediante aprendizaje por refuerzo
  • SWE-Marathon, DeepSWE y Frontier Code son intentos iniciales de evaluar la mantenibilidad más allá de una decisión de éxito/fracaso, pero aún no están al nivel de confiarles una codebase completa

4 pasos para volver a poner a los humanos en el loop

  • Por ahora, el evaluador de calidad confiable es el humano, así que hay que restaurar la revisión de código
  • Se aplica la planificación previa usada desde antes de la IA para reducir revisiones largas y la probabilidad de retrabajo
  • El leverage de la IA se aprovecha en cuatro etapas: requisitos de producto, arquitectura del sistema, diseño del programa y slice vertical

  • 1. Revisión de producto

    • Convierte una frase corta o una nota de voz larga en un documento semiestructurado que fija qué se construye y por qué
    • Primero define el problema a resolver en el lenguaje del usuario y establece criterios para juzgar el éxito después del lanzamiento
      • Reducir el tiempo de ejecución de un workflow
      • Alcanzar antes hitos de onboarding
      • Mejorar la tasa de errores o la latencia
      • Reducir tickets de soporte específicos
    • Se enfoca en la experiencia de usuario más que en detalles técnicos; si una decisión técnica bloquea una decisión de producto, se guarda el documento actual y se pasa a una revisión de arquitectura o a un prototipo de factibilidad
    • Para el comportamiento de pantallas, un mockup HTML aproximado suele ser más efectivo para lograr consenso que una explicación larga
    • Este proceso no se aplica a cambios de texto, scripts de una sola vez ni bugs con pasos de reproducción claros; se delegan directamente al agente
    • Solo se someten a revisión de producto los cambios cuyo costo sea alto si el agente malinterpreta la intención
    • Se hace que quien revise el PR revise también por adelantado las especificaciones de producto y técnicas; se pueden usar comentarios asincrónicos en documentos, GitHub o Notion

  • 2. Arquitectura del sistema

    • Se acuerda cómo se comunican servicios, endpoints, esquemas, colas y almacenes, sin bajar hasta la implementación interna del programa
    • Para aumentar el ancho de banda de comunicación entre humanos y agentes, se usan estas representaciones
      • Diagramas de secuencia entre UI, API, servicios y almacenes
      • Contratos de API que muestran request y response
      • Modelos de datos que representan nuevas tablas y formas de queries
    • Mermaid es útil, pero si se usa en exceso puede dar una falsa seguridad de que realmente hubo consenso
    • La revisión de arquitectura es efectiva para frenar temprano malos hábitos del modelo, pero no basta para garantizar código de alta calidad

  • 3. Diseño del programa

    • Antes de implementar, se decide la forma del código, un nivel por debajo de la arquitectura
      • Tipos
      • Firmas de métodos
      • Distribución del programa
      • Call stack
    • Una visualización ligera en pseudocódigo es más fácil de leer que Mermaid complejo
    • Para cambios de orquestación o flujo de control se usa un árbol de call stack, y si lo que cambia es importante se aplica sintaxis de diff
    • Con un diff del árbol de archivos se revisa la ubicación y el rol de archivos nuevos y modificados
    • Definir por adelantado los tipos y firmas de métodos de funciones clave reduce la probabilidad de que el agente elija mal el diseño interno
    • El modelo puede crear el borrador y el humano ajustarlo; es una forma de adelantar a un momento más barato decisiones que de otro modo se tomarían implícitamente durante la revisión de código

  • 4. Slice vertical

    • Los modelos prefieren un plan horizontal, construyendo en orden migración de base de datos → capa de servicios → API → frontend
    • Con un plan horizontal, durante el trabajo es difícil tocar y validar la solución real con el navegador o con curl
    • Antes de la IA, los desarrolladores expandían desde el centro hacia afuera y verificaban continuamente, en lugar de escribir 500 o 2.000 líneas de una sola vez
      1. Crear el contrato de API y datos mock, y probar con curl
      2. Consumir los datos mock desde el frontend y pulir en el navegador
      3. Conectar la API con la capa de servicios
      4. Agregar la migración de base de datos y la conexión al almacén
      5. Agregar la lógica de negocio
      6. Agregar manejo de errores
    • Los slices verticales o tracer bullets permiten probar y mejorar el comportamiento real en cada etapa
    • En áreas donde la calidad es especialmente importante, revisar 100 a 200 líneas en cada etapa y corregir el rumbo resulta más barato que arreglar tarde más de 2.000 líneas
    • Incluso los modelos más recientes tienen dificultades para planificar así sin dirección humana, y también les cuesta generalizar según la codebase y la tarea, por lo que el humano debe seguir en el loop

Cómo aplicarlo según el tamaño de la tarea

  • 30 minutos de planificación previa pueden reducir horas de revisión después de implementar
  • Para mantener una calidad cercana a la humana, los humanos deben participar en diseño de producto, arquitectura del sistema, diseño del programa y slices verticales
  • No se aplica todo el proceso a todas las tareas
    • Aproximadamente el 40% se genera de una sola vez o se completa con 1 o 2 rondas de feedback ligero
    • En tareas medianas, se combinan diseño de producto y de sistema en un único documento de planificación y no se divide la implementación en etapas
    • En tareas grandes se pasan las cuatro etapas, pero si la revisión de producto no corresponde, como en una refactorización grande, se omite esa etapa
  • Normalmente se encarga al modelo 1 a 3 slices a la vez y se revisa el código en progreso
  • Es más fácil corregir estructura interna o funcionalidad al inicio que generar en masa y luego buscar qué salió mal

El cuello de botella no es la cantidad de PR, sino su calidad

  • El cuello de botella no es que haya demasiados PR, sino que hay demasiados PR malos
  • Un PR limpio que sigue el diseño decidido y las convenciones del equipo se puede revisar rápido aunque se lean todos los archivos
  • Si solo el 20% de los PR requiere retrabajo, se genera carga cognitiva y emocional tanto para quien lo envía como para quien lo revisa
  • Los PR generados de una sola vez por IA muchas veces tienen una tasa de retrabajo cercana al 50%
  • Aunque quien envíe sea una IA, alguien debe iniciar el trabajo, pulir el resultado o hacerse responsable, así que el costo de retrabajo no desaparece

Velocidad de desarrollo aceptando las restricciones

  • La restricción central actual es que hay cosas que los modelos hacen bien y otras que hacen mal, y que por un tiempo los humanos deberán seguir leyendo código
  • En lugar de perseguir 10 a 100 veces más velocidad asumiendo que la calidad del código no importa, si se optimiza el sistema dentro de las restricciones se puede obtener de forma segura una velocidad 2 a 3 veces mayor
  • Los principios prácticos son cuatro
    1. Trabajar lo suficiente con los modelos para desarrollar intuición sobre sus restricciones
    2. Optimizar el sistema de desarrollo dentro de esas restricciones
    3. Encontrar los puntos de alto leverage
    4. Leer el código real
  • Los harnesses y loops son herramientas para reducir errores evidentes, pero no reemplazan el juicio sobre mantenibilidad ni el pensamiento de diseño

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Comentarios en Hacker News

  • A esto lo llaman el problema de intención-implementación-calidad
    Las fábricas de software pueden implementar apps, funciones, correcciones de bugs, cambios de diseño y refactorizaciones a partir de un requisito de una sola línea, pero otra cuestión distinta es si pueden producir con precisión la intención humana detrás de ese requisito y la dirección de evolución del producto
    Las formas de implementarlo explotan de manera combinatoria, y la forma “correcta” de que sea consistente con el sistema, escalable, fácil de entender y capaz de soportar con seguridad a millones de usuarios es subjetiva según la persona y el problema. Las pruebas y la evidencia del trabajo pueden mejorar parte de la calidad, pero no existe un bucle de retroalimentación para validar y corregir esta calidad subjetiva

    • Aunque el cliente diga “quiero X”, puede que en realidad sí quiera X, que no necesite X, o que en realidad quiera Y pero no haya sabido expresarlo. Otros clientes pueden no querer X, o incluso sacudir a los desarrolladores sin una razón clara
    • Las fábricas de software encajan bien para software personal o de hobby con pocos usuarios e ingresos, donde un bug puede arreglarse con un solo prompt a Claude, o para startups antes del product-market fit
      También puede funcionar un equilibrio donde no se mira el código en absoluto y solo se usa como retroalimentación si el requisito tuvo éxito, pero fuera de eso, en otro tipo de software, los problemas de intención y calidad subjetiva aún no están resueltos
    • Partir de la premisa de que solo hay una manera de traducir requisitos a implementación ya no es cierto

  • El artículo tiene cosas buenas, pero es difícil generalizar un experimento de operación no supervisada de julio de 2025 como si fuera el límite actual de los agentes
    La utilidad de los modelos dio un gran salto alrededor del otoño de 2025 o la primavera de 2026, y desde entonces yo también pude empezar a delegar funcionalidades completas a los agentes. El artículo menciona la mejora de los modelos, pero en la práctica la ignora, y eso no coincide con mi experiencia

    • Tanto el artículo como el sitio del producto parecen haberse quedado en 2025. En particular, el texto que dice que “el contexto largo no es la respuesta” parece extrapolar el rendimiento pasado a los modelos actuales
      Los modelos posteriores a Opus 4.6 fueron lo bastante estables como para que fuera difícil notar una degradación de inteligencia incluso con 700 mil a 900 mil tokens; la eficiencia de costos es muy mala, pero funciona
    • La semana pasada escuché un pódcast con Dex Horthy, y su empresa Humanlayer sigue empujando los límites de los agentes y usándolos agresivamente
      Como conoce bien las capacidades de los modelos actuales, si hubiera concluido que hoy ya es posible una fábrica de software no supervisada, seguramente lo estaría intentando otra vez
    • Opus 4.5 sin duda fue un gran salto. La evaluación de alguien que no haya probado modelos posteriores vale menos, pero aunque los modelos no sean perfectos, siguen siendo muy útiles
    • En ese caso, habría sido más claro escribir “lo adoptamos por completo en 2025 y en 2026 no ha mejorado esencialmente”
      Creo que incluso los modelos frontier más recientes no manejan mejor la pérdida de contexto ni la cirugía con escopeta (shotgun surgery). Para rebatir eso, no basta con ignorarlo: hay que presentar evidencia concreta y una experiencia de uso distinta
    • Puede ser polémico, pero en ingeniería compleja sentí que Opus 4.1 era más inteligente que 4.5
      4.5 era más rápido y mejor para atraer rápidamente a usuarios nuevos con prompts simples y leyendo bien intenciones implícitas

  • He construido y operado mi fábrica de software durante 8 meses, y aunque todavía no tiene recolección automática de tareas ni envío de PR, después de definir los requisitos casi siempre avanza sola hasta el despliegue. Tras evaluar el sistema, dejé de revisar código en los últimos 4 meses
    En lugar de un prompt de una línea, primero resuelvo preguntas abiertas y ambigüedades mediante un proceso de entrevista, y uso como salvaguardas la revisión del plan, aseguramiento de calidad en navegador, revisión adversarial, pruebas unitarias, linter, verificador de tipos, hooks post-commit y seguimiento con métodos formales
    Cuando aparecen errores repetitivos, puedo detectar áreas degradadas incluso sin mirar el código. Si los requisitos crecen y se superponen variables de estado, lo refactorizo a un único tipo suma; si se complica, creo un modelo formal y trazas en Quint y las ejecuto con pruebas unitarias
    El codebase está compuesto por frontend y backend con más de un año de antigüedad. Los agentes tienden a copiar patrones existentes tal cual, así que los principios claros son importantes; al dividir nuevos límites del sistema, los modelos del nivel de Sonnet se equivocaban seguido y Opus funcionaba mejor

    • No es una fábrica completa, pero yo sentí algo parecido en varios proyectos maduros de vibe coding
      Casi siempre podía detectar la degradación de calidad, y todavía no me ha pasado abrir el código, encontrar el problema y que el agente no pudiera ordenarlo. Tampoco he visto a un ingeniero promedio en una situación donde ya no pudiera revertir la contaminación del codebase
    • Más que la fábrica de código en sí, me da curiosidad qué construyó. Hace falta un resultado que demuestre que también se pueden crear productos más allá de herramientas de coding con IA
    • Si publica una explicación larga o un repositorio con la configuración concreta y el flujo de trabajo, me gustaría verlo

  • O necesitas entender cómo funciona el codebase, o no necesitas entenderlo
    Claude puede escribir código por ti, pero no puede entenderlo por ti, y ese proceso sigue avanzando a velocidad humana. Hay casos en los que no hace falta entenderlo todo, pero hace falta una distinción más fina, y aunque Claude escriba código perfecto, ese hecho no cambia

    • Claude puede explorar un codebase espagueti muchísimo más rápido que un humano. El problema es justamente que, al tercerizar en Claude la comprensión del proyecto, uno puede seguir trabajando incluso después de que ya se volvió inutilizable para los humanos
    • En vez de verlo como una dicotomía entre entender o no entender, también puede verse como cuánta comprensión hace falta para trabajar eficazmente en un codebase concreto
      Incluso antes de los LLM, no había nadie que conociera por completo los codebases grandes, pero al menos la gente solía entender sus propios PR y el área de la que era responsable
    • Mi experiencia es la contraria. Hice que Claude entendiera mucho más profundamente que yo dos codebases grandes que en su mayoría escribí yo mismo y cuyos conceptos también diseñé, y ahora Claude me está explicando cosas que había olvidado hace mucho

  • Me da alivio porque se parece demasiado a mi experiencia. Me hace pensar en el gusto y criterio del que tanto se habla últimamente
    La calidad de la arquitectura, como la moda, puede no tener una respuesta objetiva correcta, y quizá después de entregar la razón y la racionalidad a las máquinas, los humanos tengamos que estudiar estética
    Sin el descanso que daba el proceso de implementación, uno termina agotado al tener que juzgar continuamente concesiones entre opciones casi equivalentes, y hasta con modelos del nivel de Fable o GPT-5.6 la revisión de código sigue siendo necesaria. Los defectos pequeños los guardo en mente y, cuando se acumulan suficientes problemas parecidos, los corrijo de una sola vez
    Con agentes también hay que elegir entre colaborar estrechamente con un pequeño grupo de gente sobresaliente o ejecutar una gran cantidad de subagentes y filtrar automáticamente lo valioso de lo inútil. Mi preferencia es un equipo pequeño y altamente sincronizado, pero el tiempo dirá si es lo correcto

    • Jake Nations, cuando trabajaba en Netflix, lo expresó así: “sé reconocer los malos patrones en cuanto los veo porque ya me tocó depurarlos a las 2 de la mañana”
      El gusto es una intuición ganada a punta de sufrimiento a partir de todos los antipatrones y minas terrestres que uno ha hecho explotar construyendo software
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • Esta persona ya había admitido antes que inventó cosas sin fundamento y causó daño al difundirlas, y esta vez tampoco hay ninguna evidencia de que su idea sea buena. Hace falta una razón para volver a confiar en él

    • Al final no es más que un anuncio largo para promocionar su producto, Humanlayer

  • El problema más evidente ahora mismo es la experiencia de usuario de revisión de PR
    Siempre he odiado la pantalla de PR de GitHub, así que descargaba la rama y revisaba las diferencias en $EDITOR, pero ya no hay razón para que siga siendo tan incómodo. Linear, que ni siquiera es una empresa de revisión de código, agrupa con un modelo pequeño los archivos modificados por tema y les añade explicación y orden de importancia, ofreciendo una función base mejor que GitHub
    Sin trabajo adicional del revisor ni del solicitante, la carga cognitiva baja muchísimo, y también serían totalmente posibles funciones posteriores como visualizaciones. Me pregunto si este enfoque está equivocado o si existe alguna alternativa ampliamente usada
    https://linear.app/docs/diffs#guides

    • Los mejores equipos no hacen revisión de PR. Discuten diseño y arquitectura mientras el cambio está en curso, automatizan verificaciones menores como linting y formato, y siguen con rigor reglas de no romper el build mediante muchas pruebas y validaciones
      Si además tienen procedimientos sólidos de rollback, la puerta de PR se vuelve un paso innecesario que no detecta problemas útiles, y los miembros del equipo pueden fusionar directamente entre sí
    • La política de usar la revisión de código como puerta de integración no tiene sentido. Mi agente responde por mí a las solicitudes de revisión y revisa por mí, e incluso puede saltarse políticas de empresa que exigen revisión humana
      Hay que revisar software que realmente funcione, y se necesita un sistema donde la propuesta de cambio pueda demostrarse de inmediato. El peso del código y de la especificación irá disminuyendo, y la producción de software del futuro será más parecida a Replit que a GitHub
    • La revisión de PR ya era difícil antes de los agentes, pero ahora que incluso aumentó la cantidad de PR por revisar, está mucho peor
    • Me da la impresión de que agrupar cambios de archivos por tema y explicarlos es algo que se supone que deben hacer los commits
    • No creo que los LLM sean tan buenos determinando importancia o resumiendo código
      Probé el enfoque basado en Tree-sitter de https://github.com/0x007BA7/codebook y me gustó. Aún no está al nivel para usarse en producción, pero hay espacio para convertir una aproximación similar en producto

  • Tengo sentimientos encontrados con la fábrica de software
    En productos centrales, la escala es tan grande que todo cambio necesita intervención humana, pero automatizar refactorizaciones ligeras, escritura de pruebas y cambios de UI sí funciona bien. En cambio, en experimentos pequeños, aunque el código resultante no fuera nada especial, sí se veía potencial de expansión a futuro, y creo que se pueden diseñar nuevas estrategias y arquitecturas suponiendo desde el inicio que serán escritas por agentes
    Documenté en https://relentless.works/ experimentos públicos donde no intervengo en absoluto en la dirección. También estoy observando un agente de trading sin intervenir; va con una pérdida de alrededor de 3%, pero no ha perdido todo el capital y hace poco incluso abrió una nueva posición
    La fábrica de software parece posible, pero hace falta nuevos conceptos, un cambio de mentalidad y paciencia para esperar a la IA

  • Hay un problema más fundamental: qué significa realmente hacer software
    Si solo asignas tickets de GitHub a un agente de IA y te pones a descansar, es muy probable que se sigan acumulando abstracciones y capas de indirección. Mientras uno programa, surgen perspectivas como “¿y si usamos Redis aquí?”, “¿la API ya entrega los datos que necesitamos?”, “saquemos del reporte a los clientes que no han tenido actividad en el último año”, y en algún momento un humano tiene que juzgar eso

    • Esto se conecta con la idea de programar es construir teoría, una perspectiva fácil de perder en la programación con agentes
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • Totalmente de acuerdo. Los flujos de trabajo y colecciones de técnicas de agentes de código más usados están diseñados para sacar a flote la intuición y el insight humano durante la planificación o la escritura de código
      El modo de planificación de Claude Code, mattpocock/skills, obra/superpowers y el flujo investigar-planear-implementar entran en esa categoría
    • Eso será cierto si eres un desarrollador del 1% superior, pero comparado con la mayoría de los desarrolladores que he conocido durante décadas, los modelos actuales son mejores que los humanos salvo los de élite
    • Las máquinas todavía construyen, tal como se les pide, incluso cosas que aún no existen. Más importante que la automatización total es la capacidad de pedir correctamente usando teoría de la información, teoría de la decisión y teoría de la creatividad
      La memoria de los modelos no se integra como en los humanos, que al dormir la graban en sus pesos; se parece más a pasarle notas a alguien que no recuerda el día de ayer. No sería sorprendente que un sistema de alta entropía añada entropía al proyecto con el paso del tiempo
    • El problema de “la API ya devuelve los datos que necesitamos” es especialmente grande. He visto varias veces a modelos de primer nivel resolver con cantidades enormes de código y tokens algo que en el cliente se arreglaba cambiando una sola línea con datos que ya estaban ahí, imitando el patrón cliente-servidor existente
      Los proyectos de vibe coding están llenos de este tipo de desperdicio, pero quien escribió el prompt puede no darse cuenta. Está bien que las herramientas nos ahorren tiempo todos los días, pero la sobreimplementación es grave

  • Es ridículo hablar de una fábrica de software sin intervención humana y medir la productividad por la cantidad de PR o commits. Si van en esa dirección, ya hasta habría que llamar a la unidad de código bos (bunch of shit)

    • Están repitiendo el viejo error de optimizar la utilización en vez del throughput total. Es un problema que Eli Goldratt viene tratando desde los años 70 y aun así no lo han aprendido
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • Si se quiere operar este concepto en serio, no se pueden permitir métricas de vanidad ni ignorancia sobre el código. Cuanta más automatización haya, el estándar no baja sino que sube, y hace falta muchísimas más matemáticas y esfuerzo
      Se parece más a un intercambio en el que, en vez de ahorrar capital como una startup extrema, se invierten años de vida