Es asombroso cómo los no desarrolladores han sido recientemente empoderados para crear sus propias aplicaciones que incluso pueden generar ingresos. Hemos visto recientemente avances en el campo del desarrollo de IA, desde el éxito de la IA en el "código greenfield" (aplicaciones construidas desde cero) hasta el "código brownfield" (aplicaciones existentes a gran escala). Los modelos más recientes han mejorado mucho en el uso de herramientas y han tenido un éxito tremendo en la implementación de características dentro de aplicaciones más grandes, hasta el punto de que los desarrolladores apenas se detienen a revisar el código. En su lugar, centran su tiempo más en la definición de requisitos y las pruebas funcionales, lo que les permite lanzar más productos.
Al mismo tiempo, desarrollar nuevas funcionalidades tan rápido conlleva el riesgo de aumentar la deuda técnica hasta un punto en el que sea prácticamente imposible avanzar. Sin supervisión, los equipos pueden acabar con montones de código espagueti, por lo que los estándares de calidad del código deben ser una prioridad antes de que el problema se descontrole.
Mantener altos estándares de calidad del código es más fácil de decir que de hacer. La revisión humana no puede seguir el ritmo, y pedir a Claude o Cursor que revisen tu código es como pedirle a alguien que revise una tesis doctoral sin ningún contexto de la disciplina o los estándares que deben seguirse.
¿Qué hacen los equipos cuando el código de IA se acumula?
El coste de omitir las revisiones, especialmente en los cambios arquitectónicos, aparece más tarde, generalmente unos meses después. Los cambios generados por IA se apilan sobre otros cambios generados por IA, y cada capa asume que la que está debajo es sólida. Cuando no lo es, el modelo tiene una base débil sobre la que construir, y también los desarrolladores que lo utilizan. Los errores aparecen en lugares extraños e incluso pequeños cambios comienzan a producir efectos secundarios que tardan un tiempo en depurarse.
En algún momento, la velocidad que era alta en el primer mes comienza a revertirse. El equipo lanza más lento porque cada PR ahora siente el peso de todo lo que vino antes.
Luego, cuando los equipos intentan hacer una limpieza, es una tarea importante. Las organizaciones incluso están tratando de resolver el problema con especialistas en limpieza de código "vibe coding". Puedes encontrar a las personas con este rol en LinkedIn ahora mismo.
Parece contradictorio beneficiarse de la IA y luego requerir más personas para solucionar los problemas que la IA hizo posibles. Por lo tanto, los equipos deben tomar medidas para revisar el código de manera temprana y eficiente.
Cómo mantener baja la deuda de código
Las mejores opciones que se han encontrado hasta ahora para reducir la deuda de código generalmente se dividen en una de estas dos categorías:
- Una herramienta para verificar la calidad del código en las pull requests y detectar la deuda de código a tiempo
- Una herramienta para verificar la calidad del código en los repositorios
Los equipos las utilizan para:
- Desde una perspectiva de gestión, verificar qué equipos podrían necesitar más desarrolladores sénior, o ver qué equipos necesitan que se eleve el listón de calidad del código.
- Realizar un seguimiento de los hallazgos individuales. Por ejemplo, incluso cuando tienes algún repositorio heredado que no tocas porque "simplemente funciona", revisar los hallazgos de errores lógicos sigue siendo interesante para entender si podría haber efectos secundarios inesperados con un impacto oculto.
Ambos casos de uso funcionan solo si las comprobaciones que se ejecutan debajo son precisas, y la precisión depende de cuán estrictamente se defina el alcance de cada comprobación. Pedir a un LLM que revise un repositorio completo de una sola pasada presenta el mismo problema que un prompt poco específico para Cursor, con demasiada información para centrarse en algo concreto.
Por eso la función Code Quality de Aikido lanza llamadas a LLM por cada regla. Esto ayuda enormemente al LLM a centrarse en una pregunta específica a la vez. Además, es posible ajustar esas reglas con contexto adicional para asegurar que los hallazgos coincidan con el estilo del código. Si no existe una regla que apunte a un requisito específico, también se pueden añadir reglas personalizadas. Esa capa de control ayuda a optimizar todo el proceso en el equipo.
Además, esta capa de control se aplica tanto a las comprobaciones de PR como al escaneo de repositorios a la vez, para asegurar que los datos estadísticos del escaneo de repositorios se alineen con la retroalimentación de las pull requests.
Prompts de calidad de código con benchmarking
Una segunda ventaja de usar un sistema dedicado de calidad de código es que los LLM reciben prompts ajustados que han sido sometidos a benchmarking (algo que también hacemos con AutoTriage). El proceso es simple. Recopilamos muestras de código para una regla determinada y las etiquetamos manualmente indicando si deben ser marcadas o no, con una puntuación de confianza.
Algunas reglas de calidad de código se encuentran en una zona gris, lo que hace que no esté claro si deben ser marcadas o no. Por ejemplo, notamos grandes diferencias en la rigurosidad con la que los equipos trataban la regla de "no duplicación obvia". El propio estilo de código de Aikido es no aplicar esta regla de forma muy estricta. A menudo se prefiere la legibilidad a la ventaja de mantenibilidad de la deduplicación. Los nuevos empleados a veces querrían que fuera más 'DRY' y harían todo lo posible para añadir abstracciones que lo hicieran posible. Aquí no hay bien ni mal, es solo un matiz diferente de gris. En tales casos, una etiqueta de confianza define cuántas personas esperamos que marquen algo o no.
Sin embargo, necesitamos tomar una decisión de blanco o negro al marcar algo en una PR. Entonces, ¿cómo navegamos por la zona gris al aplicar etiquetas de confianza? Primero, simplemente buscamos no marcar muestras de la zona gris; es más probable que frustremos a los desarrolladores con demasiados hallazgos que asombrarlos con hallazgos precisos. También lo integramos en nuestro sistema de ingeniería de prompts. Después de etiquetar las muestras, ajustamos los prompts de una manera que maximice la satisfacción del cliente.
Desafortunadamente, los LLM no son perfectos y los errores siguen ocurriendo, por lo que necesitamos elegir nuestras batallas. Tener muestras de la zona gris nos ayuda a elegir las batallas correctas. Cuando tomamos una decisión incorrecta sobre una muestra de la zona gris, se penaliza menos en comparación con una decisión incorrecta sobre una muestra obvia. El resultado es que los hallazgos están bastante cerca de la verdad, significativamente más cerca de lo que se obtiene con el prompting "vainilla".
Centrarse en la calidad del código en lugar de buscar errores
Una fuente interesante de confusión entre un sistema de calidad de código y otros sistemas de revisión de PR es que la mayoría de los sistemas tienden a centrarse en la búsqueda de errores. Esto es, por supuesto, un aspecto importante, pero tiene un propósito diferente. La forma más conveniente de progresar es iterar rápidamente sobre el estilo del código, y esos sistemas deben funcionar rápido. El sistema de calidad de código de Aikido suele finalizar en menos de 1 minuto después de subir el commit, manteniendo el ciclo de retroalimentación corto. Esto incluye tanto la calidad del código como las comprobaciones de seguridad.
En un futuro próximo, también será posible solicitar una comprobación rigurosa en un commit. Esta comprobación buscaría errores lógicos y problemas de autorización con mayor profundidad. Se comporta de forma agéntica y, por lo tanto, es más lento y costoso, pero es una comprobación final ideal en una PR antes del despliegue.
Conclusión
Una instrucción genérica a Claude o Cursor comprueba el código según lo que el modelo priorice ese día, no la cultura de codificación específica de una base de código. Un sistema de calidad de código dedicado soluciona esto porque ejecuta las mismas reglas ajustadas en las solicitudes de extracción (pull requests) y en repositorios completos, de modo que un equipo obtiene una respuesta consistente en lugar de dos diferentes según dónde se ejecute la comprobación. El siguiente paso hace que esa respuesta sea más profunda: una comprobación agéntica diseñada para rastrear errores lógicos y problemas de autorización, lo suficientemente estable y segura como para ejecutarse justo antes del despliegue en lugar de en cada commit.
