Una segunda opinión que ayuda

Una revisión comienza con el cambio que quieres evaluar y con el comportamiento esperado. Informa entrada, resultado deseado, archivos involucrados y verificaciones ya hechas. El revisor necesita saber qué puede considerarse correcto, no solo recibir un directorio enorme.

Una segunda IA, como Codex, puede ofrecer otro análisis, pero no se vuelve automáticamente más confiable. Trata sus sugerencias como hipótesis que deben apuntar a un escenario concreto. El valor aparece cuando la revisión encuentra algo que puede demostrarse.

En un proyecto Git, el diff muestra lo que cambió. Antes de revisar, revisa la carpeta actual y el estado del repositorio. Separa archivos propios del cambio y materiales que no deben publicarse. Una revisión de cambios no versionados puede incluir archivos nuevos.

Con la CLI Codex instalada y autenticada, consulta la ayuda local y usa una revisión compatible con la versión disponible. El ejemplo de abajo muestra la revisión de cambios no confirmados. No sustituye la prueba de la aplicación.

Solicita que cada hallazgo describa disparador, efecto, ubicación y forma de reproducir. Prefiere “dos clics envían el mismo pedido dos veces” a “mejora la robustez”. La primera enunciación permite construir una prueba; la segunda no define un comportamiento.

Diferencia error funcional, mantenimiento y preferencia de estilo. Todos pueden importar, pero no deben recibir la misma prioridad. Una exportación que incluye registros de otro cliente exige una respuesta distinta a un nombre de variable poco claro.

Muchos errores aparecen en la segunda ejecución. Si un pedido se reenvía después de una falla de conexión, la operación necesita saber si ya fue procesada. Una clave de idempotencia identifica la misma intención para evitar crear dos resultados.

Otro escenario es la interrupción a mitad de una actualización. Registrar la mitad de una operación puede dejar los datos inconsistentes. En ejercicios, simula la falla entre pasos y observa el estado final. No concluyas que un flujo es correcto solo porque funcione una vez.

Cuando una corrección falla repetidamente, registre lo que ya se intentó y el resultado de cada intento. Reduzca el problema hasta una entrada pequeña que todavía falle. Entregue ese caso a una nueva revisión.

Cambiar de modelo sin organizar las evidencias puede solo reiniciar el mismo ciclo. El cambio más importante es proporcionar un experimento más pequeño, una hipótesis a la vez y una condición clara de parada. Conserve el caso que fallaba después de la corrección.

Imagine un formulario ficticio que agrega pedidos a una lista. El mismo identificador puede llegar dos veces. Describa cómo reproducir la duplicación y proponga una regla que conserve solo un efecto para el mismo pedido.

No basta con ocultar la segunda línea en la pantalla. La regla debe actuar sobre el registro de la operación. Explique también qué hacer cuando el identificador es igual, pero el contenido cambió: esto exige tratar un conflicto, y no descartar en silencio la información.