Revisión y pruebas de código
Los agentes de programación pueden generar mucho código, lo que también implica que pueden generar deuda técnica. Avanzar rápido es genial, pero debes mantener un alto nivel de calidad. Los estándares para fusionar código deben ser los mismos, independientemente de si lo escribió una persona o un agente.
El código generado por IA puede parecer correcto, pero contener errores sutiles. Puede seguir patrones existentes, compilar y superar las pruebas que escribiste, pero aun así no contemplar casos límite, tener vulnerabilidades de seguridad o duplicar lógica presente en otra parte de tu base de código.
Por eso la revisión de código es tan importante. Debes establecer los procesos adecuados para garantizar una base de código de alta calidad y detectar problemas antes de que lleguen a producción. Como ingeniero, es tu responsabilidad invertir en que la revisión de código sea eficaz.
Revisión propia
Debes revisar tu código antes de pedir a otros que lo revisen.
Supervisa el trabajo del agente. La vista de diferencias muestra los cambios a medida que se producen. Si ves que el agente va por mal camino, haz clic en Detener o presiona Cmd Shift BackspaceCtrl Shift Backspace para cancelarlo y redirigirlo. No tienes que esperar a que termine. Para cambios de rumbo más importantes, revierte los cambios y ajusta tu plan antes de ejecutarlo de nuevo, como vimos en desarrollo de funciones.
Pídele al agente que revise todos los cambios de una vez. Etiqueta @Branch en tu instrucción para proporcionarle al agente la diferencia completa de tu rama actual. Di algo como "revisa los cambios de esta rama" o "¿en qué estoy trabajando ahora mismo?" para proporcionarle suficiente contexto y detectar problemas en distintos archivos.
Por ejemplo, puedes pedirle al agente que revise su propio trabajo:
Prepararse para la revisión por pares
Los agentes pueden generar muchos cambios de código a la vez. Esto puede dar lugar a un único commit grande con cientos de líneas modificadas. Revisarlo es difícil para cualquiera.
Recomendamos usar commits pequeños y semánticos con descripciones claras. Cada commit representa un cambio lógico. Un revisor humano puede recorrer el historial de commits en lugar de analizar una masa de cambios de código.
Este tipo de organización de commits es tediosa si se hace a mano, pero los agentes la gestionan bien. Por ejemplo:
- Crea la funcionalidad libremente. No te preocupes por la higiene de los commits mientras iteras.
- Cuando todo funcione, pide al agente que reorganice el historial de commits en partes fáciles de revisar.
- El agente vuelve a
main, revisa todos los cambios y planifica una secuencia lógica para crear commits limpios con mensajes descriptivos. - Valida que el diff final coincida con el original para que no se pierda ninguno de tus cambios.
Usa esta instrucción para crear una skill para que cualquier persona de tu equipo pueda ejecutar /rework-commits después de terminar una funcionalidad:
Create a skill file at .cursor/skills/rework-commits/SKILL.md with this content: # Split branch into reviewable commits Rework a branch into a sequence of small, semantic commits for review. ## Important - Prepend `GIT_EDITOR=true` to all git commands you run, especially ones looking at diffs, so you avoid getting blocked ## Instructions 1. **Check for uncommitted changes**: Abort if there are any. 2. **Check rebase status**: Verify the branch is rebased on top of `main`. Abort if not. 3. **Save recovery point**: Tell the user the current commit hash in case we need to `git reset --hard` to it later. 4. **Save the original diff**: Save the full git diff to `/tmp/original-diff.patch` before making changes. 5. **Reset to main**: Run `git reset main` to unstage all changes. 6. **Plan the commits**: Read through ALL changes carefully. Plan a logical breakdown into small, sequential, semantic commits. Write a TODO for each in `/tmp/split-todos.md`. Order: database/schema changes first, backend second, frontend last. 7. **Create the commits**: Work through the TODOs one by one. Write excellent commit descriptions for human reviewers. 8. **Validate**: Compare the current diff against `/tmp/original-diff.patch` to ensure no changes were lost or altered. 9. **Cleanup**: Delete temporary files once validation passes. ## Notes - If validation fails, tell the user and provide the original commit hash for recovery - Each commit should be self-contained and represent a logical unit of work - Commit messages should explain the "why" behind the changes
Try in Cherri CodeAgent Review
Cuando el agente termine una tarea, haz clic en Review y luego en Find Issues para ejecutar una revisión de código específica. El agente analiza las modificaciones propuestas línea por línea y señala posibles problemas.
Para revisar todos los cambios locales, abre la pestaña Source Control y ejecuta Agent Review para compararlos con tu rama main. Así detectarás problemas en todo el conjunto de cambios.
Es similar a pedirle manualmente al agente que revise tus cambios. Hemos diseñado cuidadosamente una instrucción para que sea efectiva.
Bugbot para pull requests
Bugbot se integra con tu proveedor de control de versiones para revisar pull requests automáticamente. Es una de las cada vez más numerosas herramientas que ofrecen comentarios directamente en la PR.
Bugbot revisa las PR cuando haces push. Lee todo el contexto de tu cambio, incluida la relación entre el código modificado y el resto de tu base de código, y busca errores que podrían llegar a producción. A diferencia de los linters, que detectan problemas de formato, Bugbot encuentra errores de lógica como excepciones de puntero nulo, condiciones de carrera, falta de manejo de errores y vulnerabilidades de seguridad.
Cuando Bugbot encuentra un problema, también puede proponer una solución. Con autofix activado, puedes confirmar la solución directamente desde un comentario en el pull request.
También puedes personalizar Bugbot proporcionando reglas adicionales, de las que hablaremos con más detalle en la siguiente sección sobre personalizar agentes.
Objetivos verificables
Para ayudar a garantizar que tu código sea correcto, proporciona al agente señales claras para que valide su propio trabajo:
- Las pruebas detectan regresiones de comportamiento
- La comprobación de tipos detecta errores estructurales
- El linting detecta infracciones de estilo y patrones
Cuantas más comprobaciones de este tipo tengas implementadas, con más confianza podrás delegar trabajo a los agentes. Recomendamos usar lenguajes tipados con cobertura de pruebas y reglas de linting junto con tu agente.
¿Qué combinación ofrece la mayor protección para el código generado por IA?
Deja que los agentes escriban tus pruebas
Antes, lograr una cobertura de pruebas exhaustiva requería un esfuerzo considerable. La mayoría de los equipos solo añadían pruebas cuando algo fallaba o seguían procesos rigurosos para garantizar un determinado porcentaje de cobertura.
Los agentes hacen que escribir pruebas sea mucho más accesible. Puedes pedirle al agente que escriba pruebas y luego verificar que sean correctas. El agente también puede realizar pruebas manuales por ti mediante el navegador, comprobando estados o flujos de la UI que, de otro modo, verificarías a mano.
Esto es importante porque unas pruebas de alta calidad te dan más confianza para dejar que el agente trabaje de forma autónoma y haga cambios sin introducir regresiones.
Buenas instrucciones para generar pruebas:
- "Planifica cómo lograr cobertura e2e para nuestro flujo de pago. ¿Qué escenarios deberíamos probar?"
- "Configura pruebas de integración para la API de pagos. Usa nuestra infraestructura de pruebas existente en
src/__tests__/." - "¿Qué casos límite no cubren nuestras pruebas actuales de la funcionalidad de descuentos?"
- "Escribe pruebas de regresión para el error que solucionamos en
PaymentService.ts."
El agente también puede ayudarte a configurar la infraestructura de pruebas desde cero. Si no tienes Playwright configurado para una aplicación web, puedes pedirle al agente que configure el proyecto, escriba la configuración y cree tu primera prueba.
Agentes en la nube
Hasta ahora, has trabajado con agentes que se ejecutan localmente en tu Editor. Los agentes en la nube se ejecutan en entornos aislados remotos, por lo que puedes cerrar tu laptop y consultar los resultados más tarde.
Así es como funcionan:
- Describe la tarea y proporciona el contexto relevante
- El agente clona tu repo y crea una rama
- Trabaja de forma autónoma y abre una pull request al terminar
- Recibes una notificación cuando termina (por Slack, correo electrónico o la interfaz web)
- Revisa los cambios y fusiónalos cuando estén listos
Los agentes en la nube son ideales para tareas que, de otro modo, añadirías a una lista de pendientes: correcciones de errores que surgieron mientras trabajabas en otra cosa, cobertura de pruebas para código existente, actualizaciones de documentación o refactorizaciones.
Pruebas a escala con agentes en la nube
Un patrón muy útil consiste en usar agentes en la nube para probar muchas variantes en paralelo. Puedes iniciar varios agentes en la nube para probar distintos casos límite, condiciones de error y combinaciones de entradas en toda tu aplicación.
Por ejemplo, supongamos que añadiste una nueva función de códigos de descuento. Podrías iniciar agentes en la nube para probar todos los tipos de descuento, probar entradas no válidas, combinaciones como el apilamiento de descuentos y verificar el comportamiento en valores límite.
Cada agente en la nube crea una rama con sus casos de prueba y resultados. Después, puedes agrupar los fallos en casos de prueba locales reproducibles y corregirlos antes de fusionarlos.
Acelera tus ciclos de retroalimentación
A medida que empiezas a trabajar con más agentes de programación, el cuello de botella pasa a ser la parte más lenta de tu sistema. A menudo, se trata de esperar a que termine tu suite de pruebas, ejecutar comprobaciones de tipos y linting en toda tu base de código u otros pasos de tu pipeline de CI.
Cada conversación con un agente de programación conlleva estos costes. Si tus pruebas tardan 10 minutos en ejecutarse e inicias 10 agentes de programación en paralelo, son casi dos horas de espera. Haz que tus pruebas sean un 50 % más rápidas y ahorrarás casi una hora cada vez.
Estas mejoras se amortizan una y otra vez en cada sesión, cada rama y cada agente de programación. Estos son algunos ejemplos de cambios de gran impacto:
- Acelerar tu suite de pruebas
- Simplificar tu árbol de dependencias
- Optimizar tu pipeline de CI
- Acelerar tus comprobaciones de tipos
- Reducir los tiempos de creación
Son el tipo de tareas que los equipos pueden relegar, pero cuando los agentes de programación ejecutan estos comandos decenas de veces al día, el ahorro se acumula. Invertir una hora en acelerar las pruebas puede ahorrar cientos de horas con el tiempo.
Lo mejor es que los agentes de programación pueden hacer este trabajo por ti. Puedes pedirle a un agente de programación que analice el rendimiento de tus pruebas y encuentre las más lentas para solucionarlas. También puedes pedirle que audite tus dependencias y elimine las que no se usan. Son tareas bien delimitadas, con una salida clara y verificable, justo el tipo de trabajo que mejor hacen los agentes de programación.
Patrón de fallo común
Que las pruebas pasen no garantiza que el código funcione correctamente. Es posible que estén comprobando el comportamiento equivocado. El agente de programación podría haber escrito código que funciona en los casos habituales, pero que no contempla todos los casos límite.
Es importante que entiendas los cambios en el código. Si el cambio es demasiado grande como para revisarlo con comodidad, considera dividirlo en partes más pequeñas y fáciles de revisar, tanto para ti como para los agentes de programación.
Qué sigue
Ahora sabes cómo lanzar nuevas funciones, depurar cuando algo sale mal y revisar código para garantizar su calidad. Lo último es acelerar tu flujo de trabajo personalizando agentes para que trabajen con tu base de código específica.