Hace unos años, la idea de revisar de verdad 15 proyectos de software al mismo tiempo me habría parecido poco realista. No me refiero a abrir 15 repositorios y echarles un vistazo. Me refiero a revisar proyectos reales de forma recurrente para encontrar bugs, supuestos débiles, problemas de SEO, errores de traducción, inconsistencias de localización, tests ausentes, regresiones y código antiguo que ya no encaja con el resto del sistema.
El límite nunca fue la velocidad de escribir. Fue la atención. Cada proyecto tiene su historia, convenciones, edge cases y piezas de código que parecen incorrectas pero existen por una razón deliberada. Una revisión seria exige leer, buscar, comparar, ejecutar comprobaciones y solo después decidir qué merece cambiar.
Codex cambió para mí la economía de ese trabajo repetitivo. Puede hacer una primera pasada por un repositorio, seguir referencias, inspeccionar archivos relacionados, sacar a la luz patrones sospechosos, sugerir tests y ayudarme a investigar zonas que antes tendría que abrir manualmente una por una. Eso no automatiza la decisión final. Hace mucho más rápida la parte costosa que ocurre antes de decidir.
La regla más importante que he aprendido es sencilla: no uso Codex para sacarme del ciclo de revisión. Lo uso para ampliar ese ciclo.
El cuello de botella real es la repetición, no escribir código
Cuando mantienes un solo proyecto, puedes recordar una cantidad sorprendente de contexto. Con muchos proyectos, eso deja de escalar. Las mismas clases de trabajo aparecen una y otra vez:
- buscar bugs similares en componentes distintos;
- comprobar si un refactor dejó algún call site antiguo;
- revisar tests después de cambios de comportamiento;
- encontrar incoherencias en metadata, lógica de idiomas, headings o enlaces internos;
- comparar claves de localización y contenido traducido;
- buscar error handling ausente y edge cases;
- verificar si un cambio “pequeño” tocó más archivos de lo esperado;
- leer diffs que son simples por separado, pero consumen muchísimo tiempo juntos.
Nada de esto es glamuroso. Todo importa. Y cuando el mismo tipo de revisión se repite en muchas bases de código, su coste crece enormemente.
Ahí es donde un AI coding agent me resulta especialmente útil. Puede consumir la parte repetitiva del espacio de búsqueda para que yo reserve más atención para el juicio.
Empiezo por inspeccionar, no por darle permiso para reescribirlo todo
Una de las formas más sencillas de obtener malos resultados es pedir algo enorme como “revisa todo el proyecto y arregla todo”. Suena eficiente, pero mezcla discovery, priorización, arquitectura, implementación y validación en una sola tarea sin control.
Obtengo resultados mucho mejores cuando separo las etapas.
inspect → explain findings → prioritize → change → validate → review diffPrimero quiero que el agente entienda el área relevante y explique lo que encontró. Quiero rutas concretas de archivos, el código afectado, por qué algo parece sospechoso y cuál podría ser el impacto. Solo después quiero cambios.
Esto importa porque una IA puede equivocarse con enorme seguridad. Un fragmento puede parecer redundante y existir para un navegador antiguo, un edge case de pagos, una ruta de migración o una regla de negocio que no se entiende leyendo un solo archivo. Inspeccionar primero me permite detectar una mala suposición antes de que se convierta en un diff enorme.
Trato los hallazgos como pistas, no como veredictos
Una buena revisión de Codex no termina con “he encontrado 17 problemas”. El número por sí solo casi no significa nada. Me importa la evidencia.
Para que un hallazgo sea realmente accionable, quiero saber:
- dónde está el problema;
- por qué es un problema;
- qué comportamiento puede fallar;
- cuánta confianza merece la conclusión;
- qué comprobación puede confirmarla o descartarla;
- cuál sería el arreglo mínimo y seguro.
Esto es especialmente importante en security, SEO y lógica de negocio. Un agente puede señalar algo que merece investigación, pero una explicación con lenguaje de seguridad no convierte automáticamente el hallazgo en una vulnerabilidad real. Una advertencia SEO no es necesariamente un problema de ranking. Una condición extraña no es automáticamente dead code.
La IA reduce el coste de encontrar candidatos. La verificación sigue decidiendo qué es real.
El validation loop es lo que hace fiable el workflow
La generación de código es la parte visible del desarrollo asistido por IA, pero la validación es la que lo hace útil en producción.
Después de un cambio, quiero que el propio codebase responda. Según el proyecto, eso puede incluir:
- TypeScript u otro compiler/type checker;
- linting;
- tests unitarios e integrados;
- build checks;
- búsquedas dirigidas de nombres antiguos o call sites;
- revisión del diff final;
- verificación manual del comportamiento visible para el usuario.
Los comandos exactos importan menos que el ciclo. El agente hace una suposición, el repositorio devuelve evidencia y la siguiente decisión se toma con esa evidencia.
Por eso me gustan especialmente los proyectos con tipado fuerte para trabajo asistido por IA. Escribí aparte sobre por qué TypeScript funciona tan bien con Codex en software real: los tipos convierten muchas suposiciones incorrectas en feedback inmediato y legible por la máquina.
Algunos tipos de revisión encajan especialmente bien con IA
Bugs y regresiones
Un agente puede seguir un valor entre archivos, inspeccionar callers, comparar implementaciones parecidas y buscar ramas que no coinciden. Eso ayuda a acotar de dónde viene un síntoma. Aun así, reproduzco o verifico de otra forma el comportamiento antes de aceptar la conclusión.
Tests
La IA sirve para encontrar comportamiento que cambió sin cobertura de tests equivalente, proponer edge cases y explicar qué protege realmente un test existente. También puede señalar tests que validan detalles de implementación en vez de comportamiento real.
SEO
El SEO técnico contiene muchísimo trabajo de consistencia: metadata, alternates de idioma, reglas de indexabilidad, enlaces internos, plantillas, sitemap generation, redirects y convenciones por página. Un agente puede comparar esas reglas en una base de código grande mucho más rápido que yo abriendo manualmente cada route. Pero separo siempre la corrección técnica de la pregunta mucho más difícil de si el contenido merece posicionarse.
Localización y traducciones
Es una de las áreas más repetitivas de un producto multilingüe. La IA puede comparar claves, encontrar valores ausentes, detectar mezclas de idiomas, revisar placeholders y resaltar dónde un locale se ha desviado estructuralmente de otro. Es mucho más rápido que revisar grandes objetos de traducción a mano, aunque el copy importante sigue necesitando juicio humano.
Consistencia después de refactorizar
Los refactors grandes suelen fallar de maneras aburridas: queda un import antiguo, una route sigue usando el nombre anterior de un campo, un test fixture conserva la shape vieja. La búsqueda en todo el repositorio combinada con un agente que entiende la intención del cambio es muy útil aquí.
El trabajo en paralelo solo ayuda cuando las tareas son independientes
Es tentador lanzar muchos agentes y dejar que todos cambien cosas al mismo tiempo. Eso puede aumentar el throughput, pero también multiplicar conflictos y supuestos incompatibles.
Pienso en el paralelismo como un problema de coordinación. Las auditorías independientes son buenas candidatas: se puede revisar localización en un proyecto mientras otro se examina por tests, o inspeccionar repositorios diferentes a la vez. Dos agentes reescribiendo la misma arquitectura sin un plan compartido es otra historia.
Cuanto más paralela es la ejecución, más importan los límites: un proyecto claro, una tarea clara, una definición clara de terminado y un resultado que pueda revisarse de forma aislada.
El objetivo no es maximizar el número de agentes activos. Es maximizar el progreso útil y verificable.
Lo que no delego a ciegas
- Decisiones de arquitectura: el modelo puede proponer alternativas, pero los trade-offs a largo plazo dependen de contexto que quizá no esté en el repo.
- Conclusiones de seguridad: los hallazgos necesitan verificación, threat context y a menudo herramientas especializadas.
- Reglas de negocio: el código puede ser coherente internamente y aun así implementar el comportamiento de producto equivocado.
- Refactors destructivos grandes: un diff enorme es más difícil de razonar y más fácil de aprobar sin suficiente atención.
- Deploy a producción: pasar tests no elimina el riesgo operativo.
- Revisión final: quiero saber qué cambió antes de poner mi nombre en ello.
No porque la IA sea inútil en esas áreas, sino porque una respuesta plausible pero incorrecta puede ser especialmente costosa ahí.
La revisión con IA no sustituye al análisis estático
Tampoco veo Codex como sustituto de compilers, linters, tests, scanners o monitoring. Esas herramientas tienen una ventaja que la IA no tiene: son estrechas, deterministas y repetibles.
El workflow más fuerte las combina. Codex puede razonar sobre el contexto y sugerir dónde mirar. Las herramientas estáticas pueden aplicar reglas exactas. Los tests verifican comportamiento. Logs y monitoring muestran lo que ocurre en la realidad. Y la revisión humana conecta todas esas señales con la intención del producto.
Sin esos feedback systems confiaría menos en la IA, no más.
La mayor ganancia de productividad es asignar mejor la atención
Es fácil resumir todo esto como “Codex ahorra tiempo”, pero para mí se queda corto.
El recurso escaso en desarrollo no son las pulsaciones de teclado. Es la atención de alta calidad. Antes de los AI coding agents, una parte enorme de esa atención se consumía en discovery repetitivo: buscar los mismos patrones, leer archivos parecidos, seguir referencias, comprobar que un cambio se propagó a todos los sitios y repetir la misma auditoría en otro repositorio.
Ahora puedo delegar mucho más de esa primera pasada y reservar mi propia atención para lo difícil de automatizar: si el hallazgo importa, si el fix encaja con la arquitectura, si mejora la experiencia de usuario, si el riesgo es aceptable y si realmente quiero enviarlo a producción.
Por eso mantener y revisar muchos proyectos se siente distinto ahora. No reviso menos. En muchos casos puedo revisar más porque la parte mecánica ya no consume todo el presupuesto.
El workflow en el que confío
- Definir un objetivo de revisión estrecho. Bugs, tests, SEO, localización, un refactor u otra preocupación concreta.
- Dejar que el agente inspeccione antes de editar. Primero quiero evidencia y ubicaciones afectadas.
- Priorizar hallazgos. No todo problema teórico merece un cambio.
- Mantener los cambios acotados. Los diffs pequeños y coherentes son más fáciles de validar y revisar.
- Ejecutar checks automáticos. Typecheck, lint, tests, build, búsquedas o validación específica del proyecto.
- Leer el diff manualmente. Busco reescrituras innecesarias, supuestos falsos, edge cases ausentes y cambios fuera del scope.
- Verificar comportamiento importante. Especialmente usuarios, dinero, security, SEO e infraestructura de producción.
- Solo entonces pasar al siguiente proyecto. El paralelismo ayuda, pero la incertidumbre sin resolver no debería propagarse.
Quince proyectos ya no se sienten como quince veces el trabajo de revisión
Codex no convirtió 15 proyectos en algo sencillo ni eliminó mi responsabilidad. Cambió la relación entre escala y esfuerzo repetitivo.
Puedo pedir primeras pasadas más profundas, comprobaciones de consistencia más amplias, más ideas de tests y auditorías más sistemáticas sin gastar personalmente cada minuto buscando en cada archivo. Después puedo dedicar la atención ahorrada a las decisiones que todavía necesitan a un desarrollador.
Ese es el desarrollo asistido por IA que me parece valioso: no autopilot, no confianza ciega y no “genera código hasta que algo pase”. Es un ciclo más estrecho entre inspección a escala de máquina y juicio a escala humana.
Para mí, ese es el verdadero leverage de Codex. No elimina la revisión. Hace posible una revisión seria a una escala que antes era mucho más difícil mantener.