- “No leer el código” significa depender de las especificaciones, las pruebas, el análisis estático y las señales de producción en lugar de hacer revisión línea por línea, con posibilidad de escalar a revisión de código en áreas de riesgo específicas
- Los casos de Harness Engineering de OpenAI y OpenClaw muestran un enfoque centrado en pruebas, observabilidad e infraestructura de validación automática en vez de centrarse en el código
- Como respuesta al escepticismo sobre cajas negras, seguridad y acumulación de errores, se subraya el patrón histórico de las capas de abstracción y la importancia de las herramientas de validación automatizada
- No se propone excluir por completo la lectura de código, sino una postura equilibrada: la revisión directa sigue siendo necesaria en decisiones de seguridad, protección y arquitectura
- El código se está convirtiendo cada vez más en un detalle de implementación, y conviene apostar por una trayectoria donde las especificaciones, la arquitectura y las capas de validación emergen como los entregables clave
Qué significa exactamente “no leer el código”
- La frase del texto anterior, “ya no leo código”, provocó más de 200 comentarios encendidos en Hacker News
- El sentido exacto es que, para la mayor parte del código de producto, la revisión línea por línea ya no se toma como mecanismo principal de verificación
- Aun así, se siguen revisando especificaciones y pruebas, una inspección selectiva de los diffs modificados y las señales de producción; además, es posible escalar a lectura de código en áreas de riesgo específicas
- La razón para no leer el código no es que el código importe menos, sino que, especialmente en entornos a gran escala, la lectura línea por línea no es el método más eficaz para garantizar corrección
Casos que sirven de base
-
Harness Engineering de OpenAI
- OpenAI explicó en su post del blog sobre Harness Engineering que el rol central de los equipos de ingeniería de software pasó de escribir código a diseñar entornos, especificar intenciones y construir ciclos de retroalimentación
- Tres ingenieros construyeron un producto usado por cientos de usuarios internos generando un millón de líneas de código solo con agentes Codex
- La inversión principal no fue en el código en sí, sino en el harness que lo rodea: documentación, reglas de dependencias, linters, infraestructura de pruebas y sistemas de observabilidad
- No se realizó una inversión aparte en revisión de código línea por línea
-
OpenClaw
- OpenClaw, creado por una sola persona sin equipo, se convirtió en uno de los proyectos open source de crecimiento más rápido de los últimos meses y consiguió más de 100 mil estrellas en GitHub
- Opera con una estructura de 5 a 10 agentes en paralelo, diseñada y operada por un ingeniero con experiencia, no por un principiante
- En una entrevista titulada “Despliego código que no leo”, menciona que invierte sobre todo en refactorización, arquitectura, pruebas y el harness alrededor de la programación con IA
-
De Coder a Orchestrator
- Un ingeniero experimentado que creó ESLint y escribió varios libros de O'Reilly señaló en un texto reciente que el futuro de la ingeniería de software estará centrado no en escribir código, sino en la orquestación de agentes de IA
- Las capacidades clave se están moviendo de la sintaxis y la implementación hacia el diseño de arquitectura, la redacción de especificaciones y el diseño de ciclos de retroalimentación
Respuesta al escepticismo
-
Crítica de la caja negra
- Frente a la crítica de si “alguien elegiría voluntariamente un enfoque de caja negra”, se enfatiza que el resultado del código no es el código mismo, sino el producto
- La analogía es menos “un fotógrafo que no mira sus fotos” y más bien no inspeccionar la estructura interna de la cámara que produce esas fotos
- Construir sistemas sobre capas de abstracción que no inspeccionamos directamente ya es una práctica común en múltiples áreas de la ingeniería, incluido el software
-
Preocupaciones de seguridad
- Ante la preocupación de que el código generado por IA pueda incluir puertas traseras, el problema no es “que un humano deba leer cada línea”, sino un problema de tooling y de sistema de validación
- El análisis estático, el escaneo de dependencias y los linters de seguridad existen también porque los humanos escriben código vulnerable; la solución apunta a sistemas de validación automatizada más sólidos, en la misma dirección que el enfoque centrado en harnesses
- Aun así, las áreas especialmente sensibles en seguridad siguen requiriendo revisión humana
-
El problema de la acumulación de bugs
- La crítica más frecuente es: “Si el código falla, desaparece el dinero de la gente, se detienen aviones y se averían autos. Lee el código”
- Según datos de CodeRabbit, el código generado por IA produce 1.7 veces más defectos en la calidad general del software
- Pero las formas de programar con IA son diversas, y el desarrollo centrado en harnesses con especificaciones, pruebas jerárquicas y restricciones arquitectónicas es fundamentalmente distinto del simple vibe coding
- Un enfoque propuesto en un comentario: apoyarse en especificaciones, pruebas y análisis estático; mantener más de 85% de cobertura de pruebas; construir testing ladders como pruebas de integración que amplían gradualmente el alcance; y exponer errores temprano con benchmarking y dogfooding intensivo
- La pregunta clave no es “¿el código de IA tiene más bugs en promedio?”, sino “¿dentro de un harness bien diseñado, desarrollando a la misma velocidad, produce más bugs que las alternativas?”
- Greg Brockman, cofundador de OpenAI, también sostiene que deben aplicarse los mismos estándares que al código escrito por humanos
Cómo está armado el sistema en la práctica
- Durante la mayor parte de su carrera ha escrito código, sobre todo herramientas internas, pero también sistemas de los que dependen usuarios reales
- Entiende la forma y la estructura del código, pero elige no leerlo directamente
-
Flujo de trabajo basado en especificaciones
- Antes de que el agente escriba código, primero redacta con la IA especificaciones muy concretas y detalladas a través de la conversación
- La estructura permite rastrear desde la especificación del producto hasta el plan de ejecución mediante IDs de requerimientos
- Todas las tareas del plan de ejecución incluyen criterios de aceptación con el método de validación indicado
- Las pruebas automáticas se marcan como (TEST)
- La verificación visual como (BROWSER:DOM)
- (MANUAL) solo se usa cuando no hay otra opción, e incluso en ese caso primero se intenta generar verificaciones automáticas con curl o bash
- Si una tarea no tiene metadatos de validación concretos, la habilidad de auditoría bloquea el inicio del trabajo
-
AI Coding Toolkit (harness)
- El toolkit compuesto por prompts, habilidades, hooks y scripts restringe cómo trabajan los agentes, e incluye más de 35 habilidades, instrucciones estructuradas para agentes e infraestructura de validación jerárquica
- Las instrucciones para agentes se gestionan como infraestructura
- AGENTS.md funciona como el reglamento principal: cambios conservadores, mantener interfaces existentes, seguir TDD, no adivinar, no reescribir el historial de git
- VISION.md define los límites estratégicos
- Se opera un sistema de validación jerárquico
- Tras cada etapa, una habilidad de checkpoint ejecuta compuertas multinivel que incluyen type checking, linting, pruebas, build, mutation testing y security scans
- Cuando la herramienta de navegador está disponible, se realiza verificación automática en el navegador
- El diff modificado se entrega a otro modelo de IA (Codex CLI) para una revisión de segunda opinión
- La validación cruzada entre modelos compensa puntos ciegos de un solo modelo
- A veces sí se lee código directamente, pero solo en situaciones excepcionales
- Cuando todas las pruebas pasan, pero el comportamiento del producto se siente extraño
- Cuando hay que tomar una decisión arquitectónica importante
- Cuando se depura una falla que varios agentes no pudieron resolver
- Incluso en esos casos, el objetivo no es analizar el código en sí, sino identificar qué vacío en el harness permitió el problema y evitar que se repita
Cuándo sí hay que leer el código
- En sistemas donde la seguridad está directamente en juego, servicios sensibles en términos de seguridad y decisiones arquitectónicas críticas, la ingeniería de software es ingeniería en el sentido pleno, y en una era de generación masiva de código su importancia es incluso mayor
- La analogía de “Children of the Magenta” en aviación describe el fenómeno de pilotos que pasan a depender en exceso de la ruta de vuelo magenta en la pantalla de navegación
- La lección no es “no uses piloto automático”, sino conserva la capacidad de intervenir cuando sea necesario
- Si algo falla, debes poder reducir el nivel de automatización y volver a lo básico, pero exigir que todos los vuelos se hagan siempre de forma manual sería ineficiente y más riesgoso
- La clave es equilibrar el uso de la automatización sin perder la capacidad de intervención
Apostar por la trayectoria
- Todas las capas de abstracción en la historia de la computación enfrentaron resistencia al surgir, y un caso representativo es la reescritura de Unix en C por Dennis Ritchie y Ken Thompson en 1973
- En ese momento hubo críticas de que sería más lento, se perdería control del hardware y la complejidad dificultaría el mantenimiento, pero la abstracción de C permitió expandir Unix como un sistema operativo con gran portabilidad e influencia
- El patrón que se repite es que quienes tienen experiencia en la capa que está siendo abstraída destacan la importancia de entenderla; eso es válido en algunos casos, pero la mayor parte del tiempo se termina pensando y diseñando en capas de abstracción más altas
- Elegir no leer código no es declarar que las herramientas son perfectas, sino juzgar que para muchos casos de uso ya son suficientemente válidas y están mejorando con rapidez
- El código no está desapareciendo, sino desplazándose cada vez más hacia un detalle de implementación, mientras que las especificaciones, la arquitectura y las capas de validación emergen como los entregables clave
3 comentarios
Parece que la programación con IA, más que abstracción o automatización, se acerca más a la externalización o subcontratación.
Y da la impresión de que el diseño y la verificación se introducen no tanto como elementos para una mayor sofisticación y precisión, sino como una especie de regulación que apenas mantiene unida a una sociedad de baja confianza.
Es un análisis preciso.
Parece importante el hecho de que la programación con IA sea fundamentalmente probabilística.
Estoy creando una librería con IA, y parece que también hay que usar IA para el refactor, mejorar la calidad del código y revisar defectos.