- Para volverse hábil en el uso de agentes de IA, es importante tener buenas habilidades de revisión de código
- Los modelos de lenguaje grandes son buenos para la generación de código, pero les falta capacidad de juicio profunda, por lo que a menudo desperdician tiempo en direcciones equivocadas
- Las revisiones triviales que solo señalan detalles de sintaxis o las revisiones de sello de aprobación que aprueban sin criterio no ayudan a aprovechar la IA
- Una buena revisión de código incluye una perspectiva estructural, evalúa si existe una mejor manera de hacer las cosas y ayuda a evitar diseños complejos
- Al final, programar con IA es un modelo que combina el juicio humano con la productividad de la máquina, como en el "ajedrez centauro", y la capacidad de revisar código se traduce directamente en la capacidad de aprovechar la IA
La relación entre los agentes de IA y la revisión de código
- Usar correctamente a los agentes de IA es, en esencia, parte del proceso de revisión de código
- Quienes hacen bien la revisión de código también aprovechan de forma efectiva las herramientas de código con IA como Claude Code, Codex y Copilot
Por qué importa la habilidad de revisar código
- Los modelos de lenguaje grandes destacan en la generación masiva de código, pero todavía les falta el criterio de un ingeniero de software experimentado
- Por eso, si se les deja sin supervisión, tienden a desperdiciar muchos recursos en diseños innecesarios o deficientes
Límites de los agentes de IA y errores de diseño
- Como ejemplo, durante el desarrollo del proyecto VicFlora Offline, Codex dedicó mucho esfuerzo a hacer ingeniería inversa del código frontend
- En realidad existía un enfoque de acceso a datos mucho más simple
- Al usar agentes de IA, aproximadamente una vez por hora se detecta que realizan alguna tarea sospechosa
- Cuando se detecta este tipo de problema y se corrige la dirección de forma directa, se pueden ahorrar varias horas de trabajo
- En otra experiencia de desarrollo de una app, la IA propuso construir demasiada infraestructura en segundo plano incluso para una tarea simple de procesamiento en paralelo
- Bastaba con manejarlo desde el frontend de forma no bloqueante, pero aun así intentaba introducir una arquitectura compleja
- Es importante seguir controlando a la IA para mantener la simplicidad
- Cuando una persona no experta desarrolla confiando solo en la IA, la complejidad y la ineficiencia de la base de código se acumulan, y paradójicamente su capacidad de resolver problemas cae de forma drástica
La esencia y los efectos de la revisión de código
- Colaborar con la IA se parece a trabajar con un desarrollador junior entusiasta pero con poca experiencia
- La IA no mejora su criterio con el paso del tiempo, por lo que requiere observación continua
- El mayor error en la revisión de código es mirar solo el código escrito y no pensar si existe una alternativa mejor
- La revisión de código óptima integra el contexto de todo el sistema desde una perspectiva estructural
- Antes que crear un sistema nuevo e innecesario, conviene priorizar la reutilización de sistemas existentes
- Los revisores 'nitpicky' que se obsesionan solo con detalles minuciosos del estilo de código pueden perder la verdadera oportunidad de aprovechar las herramientas de IA
- Si se actúa como un revisor de tipo 'rubber-stamp' y se deja pasar todo sin crítica, resulta difícil colaborar de manera efectiva con la IA o con desarrolladores junior
Reflexiones sobre la habilidad para usar herramientas de IA
- Las herramientas tradicionales como git tienen una estructura y una forma de operación claras, pero la estructura subyacente de la IA es opaca
- La IA puede realizar casi cualquier tipo de operación
- Algunas personas consideran que la habilidad para usar IA consiste en aprovechar las herramientas de IA en todos los frentes
- En la práctica, los usuarios experimentados pueden extraer muchas más posibilidades
- Por ahora, los agentes de código con IA pueden ayudar en tareas diversas, pero requieren supervisión cercana
- Como en el modelo de "ajedrez centauro", cuando se combina la dirección de un humano experto con las propuestas de la IA, es posible alcanzar una productividad óptima
- En última instancia, la habilidad para aprovechar la IA depende de la capacidad de revisión de código y del criterio crítico de diseño
- Cuanto mejores sean las habilidades de revisión de código, mayor será el efecto al usar herramientas de agentic AI
Reflexión final y perspectiva
- Los agentes de IA pueden dar la impresión de que, con el tiempo, van creciendo hasta parecerse cada vez más a ingenieros experimentados
- En los próximos años, la experiencia de colaborar con IA podría evolucionar hasta acercarse al nivel de trabajar con un ingeniero de nivel intermedio
- Por ahora, lo recomendable es experimentar usando diversas herramientas de IA (Codex, Claude Code, Copilot, etc.), y la capacidad de supervisión crítica es el factor diferenciador más importante
Opiniones adicionales
- En Hacker News y otros espacios ha habido discusiones sobre “hasta qué punto son útiles los agentes de IA”
- El autor no cree que solo con revisión de código la IA pueda contribuir a nivel del kernel de Linux
- Algunas personas también opinan que métodos de revisión de código como el estilo y la elección de nombres son importantes
- Existe una mirada crítica sobre hacer discusiones de diseño dentro de la revisión de código, pero el autor no lo ve de forma negativa
1 comentarios
Opiniones en Hacker News
La idea de que incluso con un mal proceso se pueden obtener buenos resultados si el control de calidad es bueno me parece bastante dudosa; es como decir: "aunque siga escupiendo porquerías, con que alguien lo revise está bien", y en la realidad nunca he visto que eso funcione bien. La industria automotriz de EE. UU. intentó algo así, pero no se me ocurre ningún caso exitoso. Si me imagino que, siendo yo líder de equipo, mi jefe me dijera: "en vez de cinco personas competentes, te voy a poner 25 principiantes totales y voy a esperar que por suerte salga algo que encaje; tú revísalo todo", eso sería absurdo. Y sin embargo, cuando entra la IA en este escenario, a mucha gente le parece que "mmm, ¿tal vez sí podría funcionar?", y eso es lo sorprendente.
Revisar código de gente con poca experiencia o poca motivación también es agotador; consume una enorme cantidad de energía mental y emocional. Cuando revisas la misma funcionalidad cuatro veces, te cansas y terminas rindiéndote en un punto donde la calidad ya no puede subir más.
Esto va totalmente en contra del modelo de control de calidad que Deming (Edward Deming) desarrolló en Japón y difundió en Occidente. La calidad no viene de las personas, sino del proceso. Si eliges un proceso con muchos defectos y esperas que un humano atrape los errores, eso no es en absoluto una buena estrategia si tu objetivo es la calidad. Los LLM se pueden usar de muchas formas, pero solo algunas ofrecen ventajas. La gerencia está atrapada en la fantasía de que la IA puede resolverlo todo, y parece que no entienden bien las fortalezas y limitaciones de la IA o que olvidaron las lecciones de Deming.
La evolución misma funciona con mutación aleatoria y selección, y toda la existencia de la vida compleja es un ejemplo de eso. No es mi método preferido, pero existe una tendencia a entusiasmarse con la palabra de moda del momento e intentar usarla a la fuerza donde no encaja. En la producción de ciertas piezas plásticas de utensilios de cocina todavía existen procesos donde se fabrica con mala calidad y luego trabajadores temporales lo corrigen manualmente con un cuchillo antes de empacarlo; yo mismo hice ese tipo de trabajo temporal. El chip binning y la gestión de rendimiento en semiconductores también pueden verse como casos con una tasa de fallas altísima. Basta con mirar la realidad para ver que los procesos dudosos no son algo raro, sino más bien lo cotidiano.
Cuando uno empieza a verse a sí mismo como alguien que "sabe usar bien la IA", cae en la ilusión de que "el rango de problemas que puedo resolver se volvió enorme". Este fenómeno aparece con toda tecnología de propósito general. Ya pasó algo parecido en la época del auge de los algoritmos genéticos. Todo el mundo encuentra una herramienta "general" y luego se convence de que puede hacerlo todo con ella. En realidad intentan optimizar sin ningún contexto. La IA es un ejemplo todavía más extremo de este fenómeno.
Por más bueno que sea el proceso, así no se aprende a construir sistemas que realmente funcionen. El patrón que se repite es que el equipo da vueltas durante mucho tiempo y al final el ingeniero que sí sabe cómo resolver el problema termina interviniendo y marcando la dirección correcta.
Es realmente difícil lograr que la IA respete los parámetros solicitados; siempre se desvía aleatoriamente hacia alguna dirección absurda. Al trabajar en el resaltado de nftables, hay 230 tokens, 2,500 estados y más de 50 mil transiciones de estado. Incluso dándole a la IA estas cinco reglas claras, se termina desviando en puntos aleatorios. No solo falla en los resultados de código, tampoco puede hacer bien un Vimscript muy simple. Al final solo la uso para documentación. Aun así, se le da bastante bien explicar cosas por partes como
rule,chain_block stmtomap_stmt_expr. Yo solo copio y pego los patrones de sintaxis que quiero.La generación de código con IA es bastante útil en etapas tempranas de un proyecto, pero en proyectos maduros hay cosas preocupantes. Recientemente se hizo merge de un parser de Postgres de más de 280 mil LOC en Multigres sin revisión pública. En el ecosistema open source eso debería preocuparnos. Mucha gente depende de estos proyectos para aprender y como referencia; si entra código generado con IA sin revisión adecuada, se debilitan tanto el valor educativo como la confianza en esa dependencia. El code review no solo atrapa bugs: también es clave para que los colaboradores aprendan, entiendan por qué se tomaron ciertas decisiones de diseño y acumulen conocimiento colectivo. El problema no es la velocidad, sino el proceso de transferencia de conocimiento. Sobre el tiempo que tardó en hacerse público el PR, ver enlace
Mi proceso es más o menos así:
A veces voy tomando snapshots intermedios para poder volver atrás.
Así no obtengo algo excelente, pero sí al menos un resultado que me sirve como línea base para mi propia implementación.
La desventaja es que consume muchísimo tiempo y, en el 80% de los casos, siento que habría sido más rápido hacerlo todo yo solo desde el principio.
Se ve más lento que hacerlo solo. Programar con IA se siente como revisar algo que un desarrollador de nivel medio improvisó durante toda la noche del fin de semana siguiendo más o menos tus notas mientras se tomaba una cerveza, y luego te pregunta: "¿qué tal?". Le dices una sola vez "NO, no me gusta", y aun así, si la dirección general más o menos era correcta, da la sensación de que arrancar desde ahí el lunes por la mañana refactorizando es un poco más rápido que empezar desde cero.
Cada vez que veo estas guías por pasos, al final siento que solo agregan una enorme cantidad de fricción, y que desaparece por completo la eficiencia que en teoría la IA iba a aportar. En mi experiencia, eso es casi siempre cierto. Claro que hay momentos en que la IA ayuda, pero creo que una habilidad importante es saber cuándo y dónde sirve realmente.
Yo trabajo en capas más bajas y normalmente hago esto:
En general, cuando le das de golpe un objetivo demasiado amplio o largo, muchas veces el agente juzga mal cuándo realmente terminó el trabajo.
Uso un proceso parecido pero más simple. Incluso le doy un PRD, le explico la arquitectura general y le pido que implemente cada componente de la forma que quiero. Sigue tomando mucho tiempo y seguramente sería más rápido hacerlo directamente, pero ahora me da flojera ir escribiendo todo línea por línea, así que estoy pensando en pedirle al LLM que lo haga función por función.
Si hubiera usado la IA solo para que me orientara sobre el enfoque general, las librerías o características del lenguaje, habría sido mucho más rápido hacer el trabajo principal yo mismo.
Si eres bueno haciendo code review, quizá sea mejor no usar agentes de IA en absoluto.
Después de revisar código y corregir bugs de compañeros que se enamoraron de agentes como Claude Code, mi impresión es que el código a menudo resulta tan extraño como si hubiera sido escrito en estado de alucinación, y muchas veces quien lo produjo ni siquiera puede explicarlo. Aun así, supongo que sí habrá personas capaces de producir código realmente bueno de esa manera, pero todo lo que yo he visto ha sido decepcionante. Por suerte, algunos se dieron cuenta por sí solos y retomaron una forma de trabajo más sensata. Si uno mira críticamente los resultados que salen de los workflows basados en agentes hoy en día, la respuesta me parece evidente. Quien sabe revisar código bien va a llegar a esa conclusión mucho más rápido.
Si yo fuera bueno haciendo code review, querría seguir mejorando todavía más.
El code review también es parte del trabajo, pero es la parte menos disfrutable. Los desarrolladores obtienen satisfacción al escribir código ellos mismos, y aunque las herramientas de IA ayudan, como son impredecibles pero al mismo tiempo suenan convincentes, obligan a revisar con más cuidado y al final aumentan la carga. ¿Por qué creamos herramientas que nos quitan la parte divertida y nos dejan más de la parte aburrida? Me pregunto dónde está el agente dedicado a hacer "code review".
En realidad, escribir código en sí no me resulta tan divertido. Lo que me parece más interesante es resolver problemas, crear cosas nuevas, descomponer sistemas y recombinarlos en estructuras mejores. Programar con LLM me da la sensación de acelerar mucho el paso de una idea a un resultado tangible con el que se puede interactuar. El código existente también gana más estabilidad de tipos, mejor documentación y refactors complejos más fáciles. No espero que el LLM resuelva problemas por mí; espero que ayude a reunir contexto, reaplicar patrones y automatizar código repetitivo. Sobre todo, cuando hay código repartido en muchos archivos, que la IA lo genere automáticamente en lugar de escribirlo a mano uno por uno es comodísimo porque solo tengo que revisar cada cambio.
OpenAI Codex Cloud añadió funciones de code review, y el nuevo modelo GPT-5-Codex fue entrenado específicamente para code review [Presentación de las mejoras de Codex]. Gemini y Claude también ya tienen funciones de code review integradas con GitHub Actions y Claude con integración en GitHub. GitHub también lanzó su propia función de Copilot Code Review. También hay muchas startups especializadas, como CodeRabbit, Greptile y Qodo Merge.
El momento que de verdad me emociona es cuando, mientras implemento algo, descubro una estructura elegantísima escondida debajo y eso termina cambiando mi forma de programar o incluso de vivir (aunque eso pasa muy rara vez).
Cuanto más junior es el desarrollador, más suele gustarle escribir código directamente; los seniors, en cambio, aman reducir código. En lo personal, el code review es la parte más divertida de mi trabajo (cuando no estoy presionado por deadlines). No estoy de acuerdo con la idea de que el code review sea aburrido.
Al inicio se dijo que "a la mayoría de los desarrolladores les gusta crear cosas nuevas", pero en realidad también hay mucha gente que prefiere entender patrones y estructuras en codebases hechas por otros y mejorarlas. También hay quienes encuentran más difícil el proceso de construir algo completamente nuevo (diseño inicial - iteración infinita). Sobre la pregunta de si "nos quitaron la diversión y solo nos dejaron lo aburrido", probablemente se deba a que se enfocaron en las áreas donde el aumento de productividad se siente más fuerte. Para IA de revisión ya existen opciones como CodeRabbit o GitLab Duo, y tampoco sería difícil darle un Git diff a algo como RooCode para que haga el code review.
El título de este artículo me parece demasiado simplista. El code review y el design review son cosas distintas, y lo que se intenta hacer con IA no se limita solo a esas dos. Para aprovechar la IA hace falta conocimiento especializado del área, e incluso si hablamos solo de programación, la capacidad de revisar no basta; se necesita poder validar el trabajo que se le delega a la IA, sea del área que sea. De hecho, la IA es más útil cuando me enfrento a lenguajes o frameworks que no conozco bien, pero en ese caso tampoco puedo hacer un code review profundo. También es curioso que la palabra "coding" se haya puesto de moda otra vez en la era de la IA/LLM. Hoy en día parece que las empresas prefieren ingenieros capaces de hacer no solo código, sino también arquitectura, análisis de requisitos, desarrollo full-stack y operaciones.
Mi cargo oficial es "Software Engineer", pero en los últimos cinco años:
Me gusta mucho la idea de que al revisar código con compañeros mejoran el conocimiento compartido y los estándares comunes. Pero solo de pensar en revisar código de una IA terca y poco colaborativa siento que me podría dar burnout.
A veces pienso que si me vuelvo muy bueno en la parte más aburrida de mi trabajo, voy a terminar haciendo solo eso para siempre. Sinceramente no quiero. Y, como dice el texto, siempre es mejor que los bugs no entren desde el principio; atraparlos después siempre implica más riesgo.