- Caso experimental de un producto interno beta construido con la restricción fija de 0 líneas de código escritas manualmente, donde Codex escribió la lógica de la aplicación, pruebas, configuración de CI, documentación, observabilidad e incluso herramientas internas
- La base de código, que empezó desde un repositorio git vacío, llegó a cerca de 1 millón de líneas unos 5 meses después, con throughput de PR en el que tres ingenieros ejecutaron Codex para abrir y fusionar alrededor de 1,500 PR
- El trabajo principal de los ingenieros dejó de ser escribir código y pasó a diseñar el entorno, especificar la intención y construir bucles de retroalimentación para que los agentes trabajen de forma confiable
- El conocimiento del repositorio se gestiona con un
AGENTS.mdcorto,docs/estructurado, planes de ejecución, linters y CI; además, UI, logs, métricas y trazas se transformaron en legibilidad de la aplicación que Codex puede leer y verificar directamente - Con el aumento del throughput, minimizar las merge gates y corregir mediante ejecuciones posteriores se volvió una elección práctica, pero la consistencia arquitectónica a largo plazo y la codificación del juicio humano siguen siendo temas de aprendizaje
Beta interna creada con 0 líneas de código escritas manualmente
- Durante los últimos 5 meses se realizó un experimento para construir y lanzar un producto de software beta interno con 0 líneas de código escritas manualmente
- El producto tiene usuarios internos diarios y testers alfa externos, y ya ha pasado realmente por flujos de lanzamiento, despliegue, incidentes y correcciones
- Codex escribió cada línea de código, desde la lógica de la aplicación, las pruebas, la configuración de CI, la documentación, la observabilidad y las herramientas internas, y se estima que se construyó en aproximadamente 1/10 del tiempo que tomaría escribirlo a mano
- Los humanos dirigen, los agentes ejecutan
- Había que lanzar en pocas semanas un resultado que finalmente terminó con una escala de 1 millón de líneas, y para lograrlo el trabajo principal del equipo de ingeniería pasó de escribir código a diseñar entornos, especificar intención y construir bucles de retroalimentación
Empezando desde un repositorio git vacío
- El primer commit del repositorio vacío ocurrió a finales de agosto de 2025
- La estructura inicial del repositorio, configuración de CI, reglas de formateo, configuración del package manager y framework de la aplicación fueron generados por Codex CLI usando GPT-5, guiado por partes de plantillas existentes
- El archivo inicial
AGENTS.md, que guía cómo los agentes trabajan dentro del repositorio, también fue escrito por Codex - No existía código previo escrito por humanos que sostuviera el sistema; el repositorio se formó desde el principio por agentes
- Cinco meses después, el repositorio alcanzó alrededor de 1 millón de líneas entre lógica de aplicación, infraestructura, herramientas, documentación y utilidades internas para desarrolladores
- Tres ingenieros ejecutaron Codex para abrir y fusionar alrededor de 1,500 PR, lo que equivale a un throughput promedio de 3.5 PR por día por ingeniero
- Incluso después de que el equipo creciera a siete ingenieros, el throughput siguió aumentando
- El resultado no es output por el simple hecho de producir output; el producto es usado por cientos de usuarios internos, incluidos power users internos
- A lo largo de todo el proceso de desarrollo, los humanos no contribuyeron código directamente, y ningún código escrito manualmente fue una filosofía central del equipo
Redefinir el rol del ingeniero
- La restricción de que los humanos no codifiquen directamente introduce un tipo distinto de trabajo de ingeniería enfocado en sistemas, scaffolding y leverage
- El progreso inicial fue más lento de lo esperado, no por falta de capacidad de Codex, sino porque el entorno no estaba lo suficientemente especificado
- Los agentes carecían de herramientas, abstracciones y estructura interna necesarias para avanzar hacia objetivos de alto nivel
- El trabajo principal del equipo de ingeniería era hacer posible que los agentes hicieran trabajo útil
- El trabajo real seguía un enfoque depth-first: dividir grandes objetivos en bloques más pequeños como diseño, código, revisión y pruebas, dar prompts para que el agente construyera esos bloques y usarlos como base para tareas más complejas
- Cuando había fallas, la solución no era “intentar más fuerte”, sino encontrar qué capacidad faltaba para que Codex pudiera hacer el trabajo y convertirla en algo que el agente pudiera leer y seguir
- Los humanos interactúan principalmente con el sistema mediante prompts, en un flujo donde el ingeniero describe la tarea, ejecuta al agente y hace que abra un PR
- Durante la finalización del PR, Codex revisa localmente sus propios cambios, solicita revisiones adicionales de agentes tanto en local como en la nube, responde a feedback humano o de agentes y repite hasta que todos los reviewers agentes quedan satisfechos, en un proceso cercano al Ralph Wiggum Loop
- Codex usa directamente herramientas estándar de desarrollo como
gh, scripts locales y skills integradas al repositorio para recopilar contexto sin copy-paste humano - Los humanos pueden revisar PR, pero no es obligatorio, y con el tiempo casi todo el trabajo de revisión pasó a resolverse entre agentes
Aumentar la legibilidad de la aplicación
- A medida que aumentó el throughput de código, el cuello de botella pasó a la capacidad de QA humana
- Como la restricción fija era el tiempo y la atención humana, se amplió la capacidad de los agentes haciendo que la UI de la aplicación, los logs y las métricas de la app pudieran ser leídas directamente por Codex
- La aplicación se configuró para poder arrancar por cada git worktree, de modo que Codex pueda ejecutar y manipular una instancia por cada cambio
- Se conectó el Chrome DevTools Protocol al runtime del agente y se crearon skills para snapshots del DOM, screenshots y tareas de navegación
- Con esto, Codex puede reproducir bugs, validar correcciones y razonar directamente sobre el comportamiento de la UI
- Los logs, métricas y trazas se exponen a Codex mediante un stack local de observabilidad que existe temporalmente para un worktree específico
- Codex trabaja sobre una versión completamente aislada de la app, incluyendo logs y métricas, y cuando termina esa tarea también se eliminan los logs y métricas asociados
- El agente consulta logs con LogQL y métricas con PromQL
- Prompts como “garantiza que el arranque del servicio termine en menos de 800 ms” o “garantiza que ningún span de los cuatro recorridos clave de usuario supere los 2 segundos” se convierten en tareas ejecutables
- Es frecuente que una sola ejecución de Codex trabaje más de 6 horas en una tarea, muchas veces mientras el humano duerme
Convertir el conocimiento del repositorio en el sistema de registro
- Uno de los retos clave para hacer efectivos a los agentes en tareas grandes y complejas es la gestión del contexto
- Codex no necesita un manual de 1,000 páginas, sino un mapa
- El contexto es un recurso escaso, y los archivos gigantes de instrucciones desplazan la tarea, el código y los documentos relevantes, haciendo que el agente pierda restricciones clave u optimice restricciones equivocadas
- Demasiada guía deja de ser guía; cuando todo es importante, nada lo es, y el resultado es que el agente se queda en pattern matching local en vez de explorar con intención
- Un único manual gigantesco se vuelve obsoleto de inmediato y corre el riesgo de convertirse en un cementerio de reglas viejas y una distracción atractiva que nadie mantiene
- Un solo archivo monolítico dificulta la verificación mecánica de cobertura, vigencia, ownership y cross-links, por lo que el drift se vuelve inevitable
AGENTS.mdse trata no como una enciclopedia, sino como una tabla de contenidos- La base de conocimiento del repositorio está en un directorio
docs/estructurado que se trata como sistema de registro - Un
AGENTS.mdcorto de unas 100 líneas se inyecta al contexto y sirve como mapa que apunta a fuentes de verdad más profundas - Los documentos de diseño se catalogan e indexan junto con un conjunto central de creencias que define el estado de validación y los principios operativos agent-first
- El documento de arquitectura ofrece el mapa de alto nivel del dominio y las capas de paquetes
- Los documentos de calidad califican cada dominio de producto y capa arquitectónica, y rastrean brechas a lo largo del tiempo
- Los planes se tratan como artefactos de primera clase; para cambios pequeños se usan planes ligeros y temporales, mientras que las tareas complejas se guardan en el repositorio y se commitean como planes de ejecución con progreso y registro de decisiones
- Los planes activos, planes completados y deuda técnica conocida están todos versionados y co-ubicados, para que el agente pueda trabajar sin depender de contexto externo
- Esta estructura permite divulgación progresiva: el agente empieza desde un punto de entrada pequeño y estable, en lugar de quedar abrumado desde el inicio, y aprende dónde mirar después
- Linters dedicados y jobs de CI verifican la vigencia, cross-links y exactitud estructural de la base de conocimiento
- Agentes repetitivos de mantenimiento documental detectan documentos viejos u obsoletos que ya no reflejan el comportamiento real del código y generan PR de corrección
La legibilidad para agentes como objetivo
- Como toda la base de código es producto de agentes, el objetivo principal de optimización es la legibilidad para Codex
- Así como se busca que un nuevo ingeniero pueda navegar fácilmente el código, la meta de los ingenieros humanos es hacer que el agente razone sobre todo el dominio del negocio directamente desde el repositorio
- Desde la perspectiva del agente, lo que no es accesible dentro del contexto de ejecución prácticamente no existe
- El conocimiento en Google Docs, hilos de chat o en la cabeza de alguien no está al alcance del sistema; solo código, markdown, schemas y planes de ejecución versionados localmente en el repositorio son visibles para el agente
- Aunque el equipo acuerde un patrón arquitectónico en Slack, si el agente no puede descubrirlo, entonces está en el mismo estado que conocimiento no comunicado a una persona nueva que se unió tres meses después
- Darle más contexto a Codex no significa volcarle instrucciones arbitrarias, sino organizar y exponer la información correcta para que el agente pueda razonar
- Igual que se hace onboarding a una nueva persona con principios de producto, normas de ingeniería, cultura del equipo e incluso preferencias de emojis, darle esa información al agente lleva a resultados más alineados
- Se prefieren dependencias y abstracciones que estén completamente internalizadas dentro del repositorio y puedan ser razonadas ahí mismo
- Tecnologías a menudo consideradas “aburridas” tienden a ser más fáciles de modelar por los agentes gracias a su composabilidad, estabilidad de API y representación en los datos de entrenamiento
- En algunos casos, resulta más barato que el agente reimplemente parte de una funcionalidad que tratar de rodear el comportamiento opaco de alto nivel de una librería pública
- En lugar de traer un paquete genérico estilo
p-limit, se implementó un helper propio de map-with-concurrency, estrechamente integrado con la instrumentación de OpenTelemetry, con 100% de cobertura de pruebas y un comportamiento que coincide exactamente con las expectativas del runtime - Cuanto más se logre meter el sistema en una forma que el agente pueda inspeccionar, validar y corregir directamente, mayor será el leverage no solo para Codex sino también para otros agentes como Aardvark que trabajen sobre la misma base de código
Forzar arquitectura y preferencias
- La documentación por sí sola no basta para mantener coherencia en una base de código completamente generada por agentes
- En lugar de microgestionar la implementación, se crea una estructura que permite lanzar rápido sin que el agente debilite la base, forzando invariantes
- A Codex se le exige parsear la forma de los datos en los límites, pero no se prescribe exactamente cómo hacerlo
- Los agentes funcionan mejor en entornos con límites estrictos y estructura predecible, por lo que la aplicación se organiza alrededor de un modelo arquitectónico sólido
- Cada dominio de negocio se divide en un conjunto fijo de capas, y la dirección de dependencias y conexiones permitidas se verifica estrictamente
- Esa restricción se hace cumplir mecánicamente con linters personalizados y pruebas estructurales generadas por Codex
- Dentro de cada dominio de negocio, el código solo puede depender hacia adelante siguiendo la capa fija
Types → Config → Repo → Service → Runtime → UI - Las preocupaciones transversales como autenticación, conectores, telemetría y feature flags solo pueden entrar por una interfaz explícita única llamada
Providers - No se permite ninguna otra dependencia, y se bloquea mecánicamente
- Este tipo de arquitectura normalmente se posterga hasta que haya cientos de ingenieros, pero en un entorno con agentes de coding es un prerrequisito temprano para mantener velocidad mientras se evita corrupción y drift arquitectónico
- En la operación real, las reglas se hacen cumplir con linters personalizados, pruebas estructurales y un pequeño conjunto de “invariantes de preferencia”
- Logging estructurado, convenciones de nombres para schemas y tipos, límites de tamaño de archivos y requisitos de confiabilidad por plataforma se fuerzan estáticamente con lint personalizado
- Los mensajes de error del lint personalizado están redactados para inyectar instrucciones de corrección dentro del contexto del agente
- En un workflow human-first estas reglas podrían parecer demasiado detallistas o restrictivas, pero en un entorno con agentes, una regla codificada una vez se convierte en un multiplicador que se aplica a todo simultáneamente
- En el centro se controlan con fuerza los límites, la exactitud y la reproducibilidad, y dentro de eso el equipo o el agente conserva amplia libertad en cómo expresar la solución
- El código resultante no siempre coincide con las preferencias de estilo de los humanos, pero si es correcto, mantenible y legible para futuras ejecuciones de agentes, cumple el estándar
- Las preferencias humanas siguen retroalimentándose mediante comentarios de review, PR de refactorización y bugs visibles al usuario, actualizando documentación o herramientas
- Cuando la documentación no basta, la regla se eleva a código
El throughput cambió la filosofía de merge
- A medida que el throughput de Codex aumentó, varias normas tradicionales de ingeniería empezaron a volverse contraproducentes
- El repositorio opera con el mínimo posible de merge gates bloqueantes
- Los PR se mantienen cortos
- Las flakes de pruebas a menudo se manejan con ejecuciones posteriores en lugar de bloquear el avance indefinidamente
- En un sistema donde el throughput del agente supera ampliamente la atención humana, el costo de corregir es bajo y el costo de esperar es alto
- Es un enfoque que podría ser irresponsable en un entorno de bajo throughput, pero aquí a menudo es el tradeoff correcto
El alcance real de “generado por agentes”
- Decir que la base de código fue generada por agentes Codex significa literalmente todo dentro de la base de código
- Cosas que el agente produce
- Código de producto y pruebas
- Configuración de CI y herramientas de release
- Herramientas internas para desarrolladores
- Documentación e historial de diseño
- Harnesses de evaluación
- Comentarios de review y respuestas
- Scripts que administran el propio repositorio
- Archivos de definición de dashboards de producción
- Los humanos siempre siguen dentro del loop, pero trabajan en una capa de abstracción más alta que antes
- Los humanos priorizan tareas, traducen feedback de usuarios en criterios de aceptación y validan resultados
- Cuando el agente tiene dificultades, eso se interpreta como una señal de que falta una herramienta, guardrail o documento, y esa corrección también se devuelve al repositorio para que Codex la escriba
- Los agentes usan directamente herramientas estándar de desarrollo, traen feedback de review, responden inline, empujan actualizaciones y con frecuencia hasta hacen squash y merge de sus propios PR
Subir el nivel de autonomía
- A medida que más pruebas, validación, review, manejo de feedback y recuperación quedan codificados dentro del sistema, recientemente se cruzó el umbral en el que Codex puede impulsar nuevas funciones de principio a fin
- Tareas que el agente puede realizar a partir de un solo prompt
- Verificar el estado actual de la base de código
- Reproducir un bug reportado
- Grabar un video que muestre la falla
- Implementar la corrección
- Validar la corrección manipulando directamente la aplicación
- Grabar un segundo video que muestre la solución
- Abrir un PR
- Responder a feedback de agentes y humanos
- Detectar y corregir fallas de build
- Escalar a un humano solo cuando se requiera juicio
- Fusionar el cambio
- Este comportamiento depende fuertemente de la estructura y herramientas específicas de ese repositorio, y no debería asumirse como algo generalizable sin inversiones similares
Entropía y recolección de basura
- La autonomía total de agentes también introduce problemas nuevos
- Codex replica patrones que ya existen en el repositorio, incluso si esos patrones son desparejos o no óptimos
- Con el tiempo, esa repetición lleva a drift
- Al principio, los humanos lo manejaban manualmente y el equipo usaba cada viernes, es decir 20% de la semana, para limpiar “AI slop”
- Como eso no escalaba, se codificaron directamente en el repositorio “principios dorados” y se construyó un proceso repetitivo de limpieza
- Los principios dorados son reglas mecánicas y con opinión fuerte para mantener la base de código legible y consistente para futuras ejecuciones de agentes
- Un ejemplo de principio es preferir paquetes utilitarios compartidos sobre helpers hechos a mano, para centralizar invariantes
- Otro ejemplo es validar límites o depender de SDK tipados en lugar de explorar datos “a lo YOLO”, evitando que el agente construya accidentalmente sobre formas de datos adivinadas
- De forma periódica, trabajos de fondo con Codex escanean desviaciones, actualizan calificaciones de calidad y generan PR de refactorización dirigidos
- La mayoría de esos PR de refactorización se pueden revisar en menos de 1 minuto y auto-mergear
- Este proceso funciona como garbage collection
- La deuda técnica es como un préstamo con intereses altos: casi siempre conviene pagarla continuamente en pequeñas partes, en lugar de dejarla acumularse y resolverla dolorosamente de una sola vez
- Las preferencias humanas, una vez capturadas, se hacen cumplir de manera continua sobre cada línea de código
- Los malos patrones pueden detectarse y resolverse a diario antes de que se propaguen por la base de código durante días o semanas
Todavía están aprendiendo
- Hasta ahora, esta estrategia ha funcionado bien para lanzamientos internos y etapas de adopción dentro de OpenAI
- Construir productos reales para usuarios reales ayuda a mantener la inversión anclada en la realidad y orientada hacia la mantenibilidad de largo plazo
- Sigue siendo desconocido cómo evolucionará durante años la consistencia arquitectónica en un sistema completamente generado por agentes
- También siguen aprendiendo dónde el juicio humano agrega mayor leverage y cómo codificar ese juicio para producir efectos acumulativos
- Todavía no se sabe cómo evolucionará este sistema a medida que los modelos se vuelvan más capaces con el tiempo
- Lo que sí quedó claro es que construir software sigue requiriendo disciplina, pero esa disciplina se manifiesta más en el scaffolding que en el código
- La importancia de las herramientas, abstracciones y bucles de retroalimentación para mantener la consistencia de la base de código sigue aumentando
- Hoy, el reto más difícil es diseñar entornos, bucles de retroalimentación y sistemas de control que ayuden a los agentes a crear y mantener software complejo y confiable a gran escala
- Cuanto más agentes como Codex asuman una mayor parte del ciclo de vida del software, más importantes se vuelven estas preguntas
- Los aprendizajes iniciales ayudan a juzgar dónde conviene invertir esfuerzo para simplemente poder construir algo
1 comentarios
Comentarios de Hacker News
La capacidad de procesamiento está en un nivel ridículo. Me pregunto cuál debería ser la línea base. Antes de la codificación con agentes, ¿cuántos PR normalmente se esperaba que subiera un ingeniero? ¿Algo como 2 a 10 por día?
También me pregunto si en los últimos 6 meses realmente se siente que el software haya mejorado. Si la cantidad de ingenieros es parecida, el ciclo de iteración de las aplicaciones de software importantes debería haberse acelerado unas 5 veces, pero no parece que haya pasado. Las apps de IA cambian muy rápido, pero como es un campo tan nuevo eso era esperable, y fuera de eso no se siente mucho
Aquí se habla de 1,500 PR para 1 millón de líneas, así que el aumento neto es de unas 650 líneas por PR. Eso no significa que cada PR tenga 650 líneas en total, sino que el aumento neto, restando eliminaciones a adiciones, es de +650 líneas
Hay varias preguntas para el lector detallista. ¿Cómo se vería dentro de 10 años un proyecto que aumenta cada año en tantas líneas como todo el codebase de Firefox? ¿Qué dice la cantidad de líneas sobre la verbosidad de las herramientas, y qué dice sobre el resultado el hecho de que el propósito del proyecto no se haya explicado públicamente con claridad? ¿Habrá alguna razón para seguir preocupándose por la cantidad de líneas en un mundo donde las personas ya no escriben código directamente? Si el codebase crece muchísimo, ¿qué pasará con el uso de tokens? Si se confirma que usar LLM hace explotar la cantidad de líneas, ¿qué significará eso para un codebase que, tras usarlos durante unos meses, quiera volver a la codificación manual por motivos de costo?
Curiosamente, la mayoría de los usos de los “agentes” terminan siendo para construir otro producto de IA. Son tortugas hasta el infinito. Tal vez eso diga más sobre el campo de Harness que sobre el poder de los “agentes”
Si miras MS Office, últimamente se notan muchos cambios pequeños y la mayoría son irritantes. Cosas como que al etiquetar con @ a un colega en un comentario de Word se pierda el foco, o que en Outlook haya que hacer doble clic para escribir en la barra de búsqueda, o que el selector de fechas de Outlook móvil parezca haber perdido la función de mostrar mi disponibilidad y la de los asistentes
Así que sí, parece haber mucho volumen, pero lamentablemente están rompiendo funciones que antes funcionaban bien. O están gastando tiempo en cosas poco importantes, como que la barra de estado de búsqueda de OneDrive dé vueltas alrededor del cuadro de entrada
La mayor parte del código que se escriba quiero controlarla yo, sentado al volante, mientras uso la IA para reforzar el estado de flujo y quitarme bloqueos. Quiero que la herramienta haga la mínima generación real de código posible
Durante los últimos 5 meses hemos estado haciendo el mismo experimento en tsz[1], y llegamos a conclusiones muy parecidas. Hace falta mucho harness para forzar una buena separación de arquitectura, y también hacen falta muchas pruebas y mucho CI
El objetivo de construir tsz es aprender a hacer proyectos muy grandes con IA. Al final, el mismo flujo de trabajo y la misma actitud también pueden aplicarse para crear apps de producto para clientes con UI. Parece que OpenAI está usando hasta pruebas automatizadas en navegador y video como parte del flujo de trabajo. A medida que los modelos mejoren, esta dirección en la construcción de software probablemente terminará teniendo sentido, pero todavía no estamos ahí. Aun así, a diferencia de las afirmaciones vagas de OpenAI, al menos aquí se comparte el resultado para poder verlo directamente
Las soluciones que ofrecen un nivel muy alto de automatización, como Lovable, son un poco demasiado optimistas y no están acopladas estrechamente con muchas pruebas automatizadas
[1] https://github.com/tsz-org/tsz
Coincide exactamente con la forma en que lo he estado haciendo. Claude/Codex te da medios para verificar su propio trabajo. Cosas como navegador, smoke tests, pruebas end-to-end y entornos locales de alta fidelidad
Guardo todo el contexto —seguimiento de issues, documentación, ideas, planes y registro de trabajo— dentro del repositorio (https://github.com/shepherdjerred/monorepo/tree/main/package...)
También le doy a Claude/Codex acceso a herramientas de observabilidad como Grafana, Prometheus, Tempo y PagerDuty, y hago que siga buenas guías de ingeniería como fallar rápido, seguridad de tipos y parsing en los bordes
Pero en mi homelab todavía no he llegado a una autonomía total por el costo y la carga del CI
Hace poco vi un video de trabajadores de una fábrica de vapeadores. Tomaban un paquete de vapeadores de una cinta transportadora, se ponían uno en la boca, daban una calada fuerte durante unos 5 segundos y luego probaban el siguiente paquete. Que una persona revise cientos de líneas cambiadas en un PR escrito por IA no es tan distinto
En los PR no es así. Un solo PR malo puede ser fatal para el negocio, mientras que un vapeador malo normalmente no lo será
Además, si un ingeniero de software muestrea salidas de IA, verá que hoy por hoy la calidad no cumple de manera consistente el estándar deseado para un producto. Por eso hay que revisar todos los PR y corregir una parte importante
Un enfoque por muestreo podría funcionar si se logra limitar el alcance del impacto de los cambios y si la salida se vuelve, en general, lo bastante aceptable como para no requerir supervisión, de modo que en la práctica solo haya que hacer una doble verificación de que no hubo regresiones en producción
Soy una de las tres personas ingenieras que escribió esto. Puedo responder preguntas si las hay
No soy escéptico de la IA, pero me parece dudosa la intención de este artículo. Hace grandes afirmaciones sobre la ingeniería agent-first basándose en un producto real, usuarios reales y un equipo real en crecimiento, y hace que parezca un caso real, pero ni dice ni muestra qué construyeron. Es igual que todos los demás artículos inflados sobre IA
Esto solo puede funcionar si tienes recursos de cómputo infinitos y tokens infinitos
Habiendo usado el plan de $20, este tipo de enfoque puramente basado en agentes no es posible. Pegas con el límite muy rápido y obtienes menos resultados
Lo que me ha funcionado muy bien es dar código escrito por humanos como referencia y pedir que lo extiendan. Defino la estructura general, diseño la arquitectura y escribo algunas piezas de código de muestra como controladores, servicios, modelos, componentes, esquema de base de datos y método de autenticación, para que el LLM tenga un punto de apoyo desde el cual enfocar su atención
Normalmente escribo stubs que detallan bastante cómo implementar algo. Es como pseudocódigo a un nivel de abstracción más alto. Luego le pido al LLM que haga la implementación
Si falla, muchas veces es mejor revertir todo el cambio, ajustar el stub para que capture el fallo anterior y volver a intentarlo
O hacer commit del cambio y luego dejar que maneje solo lo que salió mal en un contexto nuevo
Si intento abordarlo de forma agentic desde el principio, siempre termino decepcionado tanto por el resultado como por los límites. A veces topo con el límite antes de que pase una hora
Si subes a $200 al mes puedes usarlo más, pero incluso para alguien que le da uso intensivo como yo, el cupo siempre se queda corto
Todavía envidio a la gente que recibió 200 veces más uso solo por haber confirmado asistencia a una fiesta de OpenAI
Otro texto de ventas agitado. Es como vender picos a los mineros, pero ¿dónde está el oro? ¿Dónde está el producto increíble que realmente crearon estos chatbots hablándose entre sí sobre Git y produciendo montones de líneas de código? No se ve por ningún lado
Ojalá estas entradas emocionadas de blog fueran un poco más educativas
Por ejemplo, me gustaría que mostraran paso a paso cómo se configura realmente ese workflow que dicen que es tan potente, y que lo demostraran con algo concreto
No soy escéptico de la IA. Al contrario, si de verdad hay superpoderes reales, no quiero perdérmelos
Para funciones nuevas escribo especificaciones de features en Gherkin; para mejoras las actualizo; para refactors no las toco. Etiqueto los PR con esos sustantivos
Ejecuto type checks, linting, pruebas unitarias y otras verificaciones rápidas y automatizables con un hook pre-push
Creo un subsitio de VitePress dentro del repositorio y hago que el agente lo mantenga. Ahí documento principios importantes, arquitectura y demás
Hago un comando CLI que enumera todas las páginas y las descripciones del frontmatter YAML, para que el agente pueda elegir qué leer sin reventar la ventana de contexto
Uso diseño guiado por el dominio y monorepo. Escribo la lógica en capas headless y luego compongo esas capas en apps. Los agentes navegan muy bien por las capas
Uso zod, o la herramienta equivalente en ese lenguaje, y desarrollo de API contract-first. Personalmente esta parte es la que más me gusta, y uso orpc
Solo hice una skill única llamada “code” y describí el ciclo de vida. Abrir worktrees, configurar
.envpara no chocar con otros agentes, elegir puertos no usados, donde Docker ayuda mucho. Escribir o actualizar el archivo de features, afinar la especificación ahí, luego implementar, validar con algo como playwright mcp, ejecutar las verificaciones pre-push, esperar la revisión después del push, limpiar y hacer fast-forward merge a maintestcontainers sirve mucho para garantizar que varios agentes puedan ejecutar pruebas sin conflictos
En serio, solo hay una skill. Todo lo demás está en la documentación. Se siente muy productivo, no en el sentido de cantidad de líneas de código, sino en el de “hacer buen software”
Para hacerlo, cada vez que el agente se topaba con un problema, le preguntaba cómo resolverlo usando herramientas o scripts de validación. Durante el proceso de auditoría también le hice programar esas herramientas. Como resultado, ahora hay más de 30 reglas para validación de commits[2], y funcionan bastante bien
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (“modo demo” si lo dejas hasta que termine el temporizador)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Al principio intentamos esto. Antes de escribir código, usamos ChatGPT como “gerente de proyecto” para que configurara todo el arnés. Una semana después, habían salido más de 140 documentos de reglas, arquitectura y framework, y la cantidad de líneas de código era 0
Más tarde hicimos que otra herramienta lo revisara y el veredicto fue: “una bóveda vacía perfectamente segura”. El arnés era impecable, pero no había nada dentro
El arnés es importante, pero si no avanza en paralelo con el lanzamiento del código, no es más que escribir ficción