Es increíble cómo, últimamente, las personas que no son desarrolladores han adquirido la capacidad de crear sus propias aplicaciones, con las que incluso pueden generar ingresos. Recientemente hemos sido testigos de avances en el ámbito del desarrollo de la IA, que ha pasado de tener éxito en el «código greenfield» (aplicaciones creadas desde cero) al «código brownfield» (aplicaciones existentes a mayor escala). Los modelos más recientes han mejorado mucho en el uso de herramientas y han tenido un éxito tremendo a la hora de implementar funcionalidades en aplicaciones más grandes, hasta el punto de que los desarrolladores apenas se detienen a revisar el código. En su lugar, dedican más tiempo a definir los requisitos y a realizar pruebas funcionales, lo que les permite lanzar más productos al mercado.
Al mismo tiempo, desarrollar nuevas funcionalidades a este ritmo conlleva el riesgo de que la deuda técnica aumente hasta tal punto que resulte prácticamente imposible seguir avanzando. Sin una supervisión adecuada, los equipos pueden acabar con montones de código espagueti, por lo que hay que dar prioridad a los estándares de calidad del código antes de que el problema se salga de control.
Mantener unos altos estándares de calidad en el código es más fácil de decir que de hacer. La revisión humana no da abasto, y pedirle a Claude o a Cursor que revisen tu código es como pedirle a alguien que revise una tesis sin conocer el contexto de la disciplina ni los estándares que deben seguirse.
¿Qué hacen los equipos cuando se acumula el código de IA?
El coste de saltarse las revisiones, especialmente en los cambios arquitectónicos, se hace patente más adelante, normalmente al cabo de unos meses. Los cambios generados por la IA se superponen a otros cambios generados por la IA, y cada capa da por hecho que la que hay debajo es correcta. Cuando no lo es, el modelo tiene una base débil sobre la que construir, al igual que los desarrolladores que le dan instrucciones. Los errores surgen en lugares insospechados e incluso los cambios más pequeños empiezan a producir efectos secundarios que tardan un tiempo en depurarse.
En algún momento, el ritmo acelerado del primer mes empieza a frenarse. El equipo entrega con menos frecuencia porque cada solicitud de incorporación de cambios (PR) soporta ahora el peso de todo lo que la ha precedido.
Por eso, cuando los equipos intentan poner orden, se trata de una tarea titánica. Las organizaciones están incluso intentando resolver el problema contratando a especialistas en «vibe coding». Ya puedes encontrar a personas que desempeñan esta función en LinkedIn.
Parece contradictorio beneficiarse de la IA y, al mismo tiempo, necesitar a más personas para solucionar los problemas que la propia IA ha hecho posibles. Por eso, los equipos deberían tomar medidas para revisar el código de forma temprana y eficaz.
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 suelen encajar en una de estas dos categorías:
- Una herramienta para comprobar la calidad del código en las solicitudes de incorporación de cambios, con el fin de detectar a tiempo la deuda de código
- Una herramienta para comprobar la calidad del código en los repositorios
Los equipos los utilizan para:
- Desde el punto de vista de la gestión, comprueba qué equipos podrían necesitar desarrolladores con más experiencia o qué equipos necesitan elevar el nivel de calidad del código.
- Realiza un seguimiento de los hallazgos individuales. Por ejemplo, aunque tengas algún repositorio antiguo al que no tocas porque «simplemente funciona», sigue siendo interesante revisar los hallazgos de errores de lógica para comprender si podría haber efectos secundarios inesperados con repercusiones ocultas.
Ambos casos de uso solo funcionan si las comprobaciones que se ejecutan en segundo plano son precisas, y esa precisión depende de lo específico que sea el alcance de cada comprobación. Pedirle a un modelo de lenguaje grande (LLM) que revise todo un repositorio de una sola vez conlleva el mismo problema que una indicación poco concreta para Cursor: hay demasiada información ante él como para centrarse en algo específico.
Por eso, la función «Calidad del código» de Aikido realiza consultas al modelo de lenguaje grande (LLM) regla por regla. Esto ayuda enormemente al LLM a centrarse en una pregunta concreta cada vez. Además, es posible ajustar esas reglas añadiendo contexto para garantizar que los resultados se ajusten al estilo de código. Si no existe una regla que se ajuste a un requisito específico, también se pueden añadir reglas personalizadas. Esa capa de control ayuda a optimizar todo el proceso en todo el equipo.
Además, esta capa de control se aplica simultáneamente tanto a las comprobaciones de las solicitudes de incorporación de cambios como al análisis de los repositorios, con el fin de garantizar que las cifras estadísticas del análisis de los repositorios coincidan con los comentarios de las solicitudes de incorporación de cambios.
Pautas de referencia para la calidad del código
Una segunda ventaja de utilizar un sistema específico de control de calidad del código es que los modelos de lenguaje grande (LLM) reciben indicaciones ajustadas que han sido sometidas a pruebas comparativas (algo que también hacemos con AutoTriage). El proceso es sencillo. Recopilamos ejemplos de código para una regla concreta y etiquetamos manualmente si deben señalarse o no, asignándoles una puntuación de confianza.
Algunas reglas de calidad del código se encuentran en una zona gris, lo que hace que no quede claro si hay que señalarlas o no. Por ejemplo, hemos observado grandes diferencias en el grado de rigor con el que los equipos aplican la regla de «no duplicación evidente». El propio estilo de código de Aikido consiste en no aplicar esta regla de forma muy estricta. A menudo se da prioridad a la legibilidad frente a la ventaja que supone la deduplicación en cuanto a la facilidad de mantenimiento. Los nuevos empleados a veces prefieren un enfoque más«DRY»y hacen todo lo posible por añadir abstracciones para lograrlo. Aquí no hay nada correcto ni incorrecto, solo se trata de un matiz diferente de gris. En estos casos, una etiqueta de confianza define cuántas personas esperamos que señalen algo o no.
Sin embargo, debemos tomar una decisión clara y rotunda a la hora de señalar algo en una solicitud de incorporación de cambios. Entonces, ¿cómo abordamos la zona gris a la hora de aplicar etiquetas de confianza? En primer lugar, simplemente intentamos no señalar las muestras que se encuentran en la zona gris: es más probable que frustramos a los desarrolladores con demasiados hallazgos que los sorprendamos con hallazgos certeros. También lo integramos en nuestro sistema de ingeniería de indicaciones. Tras etiquetar las muestras, ajustamos las indicaciones de manera que se maximice la satisfacción del cliente.
Por desgracia, los modelos de lenguaje grande (LLM) no son perfectos y siguen cometiendo errores, por lo que debemos elegir bien nuestras batallas. Contar con ejemplos de «zona gris» nos ayuda a elegir bien esas batallas. Cuando tomamos una decisión errónea con respecto a un ejemplo de «zona gris», la penalización es menor que si se trata de un ejemplo claro. El resultado es que las conclusiones se acercan bastante a la verdad, mucho más de lo que se consigue con las indicaciones estándar.
Priorizar la calidad del código frente a la detección de errores
Un motivo interesante de confusión entre un sistema de calidad del código y otros sistemas de revisión de PR es que la mayoría de los sistemas tienden a centrarse en la detección de errores. Por supuesto, ese es un aspecto importante, pero tiene un objetivo diferente. La forma más eficaz de avanzar es realizar iteraciones rápidas sobre el estilo del código, y esos sistemas deben funcionar con rapidez. El sistema de calidad del código de Aikido suele completar su proceso en menos de un minuto tras enviar el commit, lo que mantiene breve el ciclo de retroalimentación. Esto incluye tanto las comprobaciones de calidad del código como las de seguridad.
En un futuro próximo, también será posible solicitar una comprobación rigurosa de una confirmación. Esta comprobación permitiría detectar errores lógicos y problemas de autorización con mayor profundidad. Funciona de forma autónoma y, por lo tanto, es más lenta y costosa, pero constituye una comprobación final ideal para una solicitud de incorporación de cambios antes de su implementación.
Conclusión
Una solicitud genérica a Claude o Cursor comprueba el código en función de lo que el modelo decida priorizar ese día, y no según la cultura de programación específica de un código fuente. Un sistema dedicado a la calidad del código soluciona esto, ya que aplica las mismas reglas optimizadas tanto a las solicitudes de incorporación de cambios como a los repositorios completos, de modo que el equipo obtiene una respuesta coherente en lugar de dos respuestas diferentes dependiendo de dónde se realice la comprobación. El siguiente paso permite profundizar aún más en esa respuesta: una comprobación autónoma diseñada para detectar errores lógicos y problemas de autorización, lo suficientemente estable y segura como para ejecutarse justo antes de la implementación, en lugar de en cada commit.
