Tus Revisiones de Código AI Están Perdiendo el Punto (Y Cómo Solucionarlo)

Hola a todos, mi nombre es Ishai. Soy el CTO en LearnrB. Y hoy voy a hablar sobre las revisiones de código de AI. Tal vez las tengas, tal vez no. Voy a hablar sobre por qué probablemente no están haciendo todo lo que pueden por ti y cómo solucionar esto.

Así que, voy a cubrir una introducción sobre las revisiones de código de AI y por qué creemos que este es el primer paso que AI realmente da en el SDLC. Mostraré algunos anti-patrones que hacen que las revisiones de código de AI pierdan el punto. Y luego me centraré en cómo mejorarlas.

Lo que realmente importa en tu sistema de revisión de código de AI y cómo pasar de resultados mediocres a grandes resultados que realmente transformen cómo trabajas. Así que, las revisiones de código de AI, esa es una historia de éxito creciente para AI dentro del espacio de trabajo de codificación. Y en contraste con cómo AI típicamente ayuda a los desarrolladores en el IDE o en CLI ayudándoles a codificar, las revisiones de código en realidad comienzan el viaje de AI en el proceso mismo porque ahora dejan el ámbito de un solo desarrollador y realmente son un lugar donde AI se convierte o aumenta el proceso. Si miramos las diferentes formas en que AI ayuda a los desarrolladores y ayuda a los equipos de ingeniería a entregar valor a través de cambios en una base de código, tenemos tres modos principales.

Y en esta diapositiva, voy a describir los modos, pero también su modelo de madurez y cómo avanzan con el tiempo. Así que, la primera fila son los asistentes de codificación. Estos son los famosos cursores, cloud code, copilotos de cliente y así sucesivamente, típicamente viviendo dentro de mi IDE o en mi laptop. En un CLI, tal vez tenga un enjambre de agentes, pero están en el ámbito de ayudarme a escribir código. Así que, soy el desarrollador. Yo soy dueño de lo que estoy haciendo. Estos agentes me ayudan a escribir más código, me ayudan a escribirlo más rápido, tal vez me ayuden a escribirlo de extremo a extremo. Cuando está listo, enviaré el código como una pull request o como una merge request, y pasará por el resto del SDLC.

Este modo obviamente explotó, comenzó la experimentación en 2024, y el año pasado básicamente fue el año en que este modo maduró. Así que, las grandes organizaciones ya despliegan agentes y ayudantes en este modo, y en madurez, estoy hablando de RFPs, de integrar esto en los presupuestos, de tener mediciones sobre cómo me está ayudando, de tener programas de capacitación, convirtiéndose en parte incluso de currículums y cómo evaluamos a los candidatos. Todas estas cosas han sucedido, y ahora esto básicamente se ha convertido en otra herramienta madura en manos de los desarrolladores. No ha terminado en términos de evolución, pero ha pasado por un rápido ciclo de madurez para convertirse en algo que todos necesitan.

El segundo modo, los agentes asistentes, son típicamente aquellos que son un poco más autónomos. Ya no están dentro de mi espacio privado o mi laptop como desarrollador, y típicamente reaccionan al nuevo código. Así que, estos podrían ser obviamente agentes de revisión de código de AI, pero también agentes que me ayudan a actualizar mis documentos, describir mi pull request. Están respondiendo a algunos cambios o a pasos en el SDLC. No están tomando el trabajo de extremo a extremo, y ahora están pasando por una experimentación tardía y comenzando a madurar.

Con las revisiones de código de AI siendo, diría yo, la vanguardia de la madurez, muchas organizaciones, incluidas las grandes, ahora están mirando y desplegando y haciendo bake-offs con revisiones de código de AI y flujos similares que ayudan al proceso del desarrollador aumentando algunos pasos, y particularmente reaccionando al nuevo código.

Finalmente, la tercera fila son los agentes más autónomos, como los devins, los agentes de codificación co-pilot, y otros, que están diseñados para llevar a cabo una tarea de extremo a extremo. Estos típicamente se ejecutan en algún bucle en la nube o en mi pipeline. Miran un ticket de JIRA o una descripción similar de lo que se necesita hacer, tal vez tomen algo del backlog, tal vez encuentren un error. Crean una solución o crean una nueva característica. Presentarán el pull request o la change request, y son mucho más autónomos por naturaleza. Estos todavía están pasando por experimentación. Estos todavía son tempranos. Las organizaciones están probándolos, entendiendo los desafíos que traen, como la propiedad del código y así sucesivamente.

Obviamente están sucediendo. Están agregando valor, pero aún no están en la fase madura. En esta charla, me voy a centrar en las revisiones de código de AI, que están en la segunda fila y ahora están comenzando a moverse de la experimentación a la madurez. Gran parte de lo que hablaremos es lo que se requiere, si se quiere, para convertirse en una solución madura. En Leonard B., hablamos con muchas organizaciones de ingeniería, y realizamos una encuesta para entender dónde la gente está viendo que AI se involucra en el SDLC.

No voy a recorrer todas las áreas aquí, pero puedes ver que el área que está bajo la categoría de codificación tiene muchos modos mixtos y AI donde AI está haciendo más trabajo y AI más humanos está tomando el control. Así que eso podría ser escribir el código. Eso podría ser crear un pull request y así sucesivamente. Si miras la revisión y el lanzamiento, el cuadro que destaqué, estas son como un par de las áreas más pequeñas. Específicamente, si estoy mirando quién revisó el PR, aquí es donde ves mucho modo mixto y ves alguna actividad agradable de AI.

Así que las revisiones de código de AI están comenzando a ayudar a las organizaciones con la revisión de las sugerencias de código. Pero si miramos quién tomó la decisión de fusionar, quién realmente aprobó el pull request y fusionó el código, eso sigue siendo muy, muy humano. Esa es la barra más pequeña de toda la tabla con respecto a la participación de AI. Así que vemos que las organizaciones están inclinándose hacia las revisiones de código de AI, pero no tanto, al menos en este punto, inclinándose hacia AI para tomar una decisión sobre aceptar el código. Recuerda eso. Vamos a volver a eso más tarde.

Así que uno de los desafíos clave que surgen al usar AI para ayudarme a escribir mi código es que crea nuevos tipos de cuellos de botella. Ahora tenemos formas mucho más rápidas de codificar y desarrolladores que han aprendido a usar las herramientas de AI y realmente se están inclinando hacia tener agentes como Cloud Code en su laptop, ejecutando algunos de ellos en paralelo, desarrollo impulsado por especificaciones. Hay un montón de nuevas prácticas que resultan en mucho código nuevo. Así que hay mucho más código nuevo. AI está feliz de crear mucho código, muy verboso. Pero, ¿quién va a revisar todo ese código?

Si el proceso de revisión, y ya lo has visto, el proceso de decisión sigue siendo manual, ahora tenemos un nuevo cuello de botella sobre cómo manejamos todo esto, ya sabes, 10 veces la cantidad de código, si nuestra línea de entrega, las revisiones, aceptaciones, decisiones son todavía humanas. Además, tener mucho más código y el aumento adicional de la velocidad en la creación de código significa que los problemas de calidad ahora se están volviendo más costosos. Tengo 10 veces más código, habrá 10 veces más problemas de calidad, incluso si mantengo los mismos estándares de calidad, lo que significa que necesitaré responder a los problemas de calidad a una tasa mucho más alta.

Así que tener más códigos en realidad significa que tenemos que aumentar nuestras tasas de calidad y tener incluso menos densidad de errores que o menor densidad de errores que antes. Así que solo para alinear a todos sobre las revisiones de código de AI, si aún no las tienes en tu organización, estas son revisiones de código que ocurren en los pull requests, muy similar a lo que esperarías de un revisor humano, donde hay un montón de comentarios en el pull request, y en algunos casos, hay una sugerencia destacando una línea específica de código o área en el código donde hay un problema y una sugerencia sobre cómo solucionarlo. En algunas de las interfaces de usuario de los proveedores de Git, puedes comprometer directamente tales sugerencias.

Así que lo que esperas de un humano al revisar tu código, deberías esperarlo de los bots de revisión de código de AI al mirar tu código, observar los cambios que has hecho, entender su significado, buscar problemas y darte un resultado. Las verdaderas razones por las que esto ayuda a impulsar la productividad es, ante todo, un ciclo de retroalimentación corto. Si normalmente tengo que esperar horas o tal vez un día, tal vez dos, tal vez dos semanas para que alguien revise mi código, cuando es un bot, cuando es AI, obtienes retroalimentación en minutos. Así que todavía estoy en la zona, todavía estoy pensando mucho en el código que acabo de cambiar. Obtener retroalimentación temprana significa que no tengo que cambiar de contexto, no tengo que recordar lo que hice aquí. Puedo rápidamente corregir o abordar la retroalimentación y mejorar mi código. Cuando esto realmente llega a un revisor humano, tal vez después de que corrija las cosas que AI encontró para mí, el revisor humano recibe un pull request mucho mejor. Ya está corregido de todos los problemas más fáciles de encontrar. Ahora tengo un código de mucho mejor calidad para revisar y puedo enfocar mi capacidad mental humana en las cosas difíciles y perder menos tiempo lidiando con cosas simples o simplemente cosas que AI encontró antes de que tuviera que hacerlo. Y el tercer punto aquí es importante. Es una oportunidad para agregar otro paso de automatización. Así que acabamos de hablar sobre este nuevo tipo de cuello de botella y el hecho de que las organizaciones todavía necesitan una decisión humana para decidir aceptar el código. Cuando tengo una buena revisión de código de AI, puedo empezar a pensar en, tal vez puedo fusionar automáticamente el código si pasa la revisión de código. Al menos en algunos casos, tal vez algunos PRs en algunas partes del código, bajo algunas reglas, si pasan, todo está limpio, AI ha inspeccionado el código, ha determinado que no hay errores, tal vez puedo hacer una fusión, tal vez puedo omitir completamente a un humano. Y ahí es donde se gana una gran productividad porque los humanos probablemente siempre serán el cuello de botella. Entonces, ¿por qué la revisión de código de AI tiene tanto sentido? ¿Por qué es un gran caso de uso para AI? En primer lugar, es un proceso humano existente con mucha fricción. Tengo que esperar a que otros me proporcionen retroalimentación. Tienen que cambiar de contexto de lo que están haciendo. Hay mucho ida y vuelta entre humanos. Así que hay mucha fricción en un proceso existente que es un objetivo principal para que AI lo optimice. Es una tarea bien definida. Las entradas y salidas están bien definidas. Aquí está mi diff al código y la salida es una lista de comentarios y sugerencias para corregir el código. Así que está muy bien definido, otra cosa que AI adora. La revisión de código de AI típicamente puede trabajar con un contexto limitado. No necesito saber todo sobre todo para proporcionar una revisión de código sólida. Puedo mirar el código, pero no necesito ponerlo todo en mi memoria a la vez. Al igual que un humano conoce parte del código, sabe cómo buscar más información si necesita entender algo que no ha aprendido antes. Hay un contexto bien definido que puedo mirar y no tiene que ser enorme. Y esto sigue la ola de usar AI para ayudar con el código.

Todos hemos visto que AI es realmente buena. Los LLMs son realmente buenos para leer, entender y escribir nuevo código. Eso ya ha sido demostrado por la primera ola de asistencia de codificación de AI. Así que es natural extender eso para hacer revisión de código además de la generación de código.

Ahora voy a hablar sobre por qué AI está perdiendo el punto en muchos casos al hacer revisiones de código. Y voy a resaltar algunos anti-patrones que hemos visto con organizaciones que están comenzando a experimentar o implementar revisiones de código de AI y hablar sobre por qué estos son básicamente bloqueadores para obtener el mayor valor de la revisión de código de AI.

Y finalmente, voy a hablar sobre cómo mejorarlo. Así que el primer patrón es la adopción ad hoc. Solo gasta $29 o $20 al mes, compra una herramienta, proporciona a tu equipo acceso, tal vez implementarla en algunos repos. Ahora tienes bolsillos de uso aleatorios. Tal vez no está revisando todo el código. Tal vez no está revisando todo el código todo el tiempo. Tal vez está revisando solo la primera versión de un pull request pero no lo revisa de nuevo después de que se hacen cambios.

Tal vez está siendo ignorado. Sabemos de muchas herramientas que están funcionando en PRs, generando resultados, pero realmente no se están utilizando. Nadie las está mirando realmente. Nadie está confiando en ellas como parte del proceso. Así que simplemente poner una herramienta ahí no es suficiente. Típicamente, estás ciego como organización. ¿Quién está usando? ¿Qué está encontrando de ti? ¿Realmente está encontrando errores? ¿Qué tipo de errores? ¿Dónde están ocurriendo los errores? ¿Cuál es la densidad? Toda esta información, típicamente, al menos en un despliegue ingenuo de revisión de código de AI, no está ahí, y estás volando a ciegas. Y si hay algún aprendizaje aquí, va a ser por suerte.

Entonces, revisión de código de AI, ¿aprende? ¿Mejora a partir de los comentarios que recibe de los usuarios? ¿Entiende la forma en que queremos ver el código y los cambios de código que ocurren en nuestra base de código, las diferencias entre equipos y todo eso? Así que si solo estás aplicando una herramienta, estos son los muros y los límites que vas a encontrar.

El segundo patrón es la dependencia excesiva. Entonces, oh, hay una revisión de código. AI ha revisado mi código. No tengo que revisar mi código. Puedo escribir un código descuidado y esperar que AI lo detecte. Así que ese es un patrón donde, al tener una herramienta con alguna etiqueta de calidad alrededor, algunos equipos, algunos desarrolladores dependerán en exceso y simplemente dirán, está bien, hay alguien más que va a encontrar los problemas. Y luego también hay un caso donde tienes, ya sabes, algunas personas usan básicamente el mismo modelo, como cursor y luego bug bot, el mismo modelo para escribir el código y luego para revisarlo. Eso en sí mismo podría ser un problema. Quieres al menos mirar una variedad de modelos entre escribir código, revisarlo. Así tienes más posibilidades de encontrar cosas y más ángulos aquí.

Y luego el tercer patrón que estamos viendo es aferrarse al mismo proceso rígido de siempre, ¿verdad? Tenemos un paso, que es la revisión de código. Podemos aumentar eso, aumentar al humano solo en ese punto, tal vez ahorrar algo de tiempo para obtener la primera revisión y retroalimentación temprana. Eso es mucho valor. Pero no estamos cambiando el proceso. Todavía habrá una revisión y una decisión humana. Y es el mismo proceso único para todos, para todas las pull requests en todo momento.

Esto es lo que vemos sucediendo en como el 95% de la industria. Todos tienen que pasar por una aprobación humana y el proceso es extremadamente rígido. Lo insinué antes. Ignorar la oportunidad de hacer algunos cambios en el proceso para inculcar algo de flexibilidad y automatización es como un techo de cristal sobre lo que puedes obtener de las revisiones de código de AI. Si puedes de alguna manera aprovecharlas para tomar decisiones automáticas sobre la fusión, eso se convierte en un cambio de juego.

Así que ten eso en cuenta mientras hablamos sobre cómo hacer las cosas realmente, realmente mejor. Entonces, ¿qué es lo que realmente importa? Voy a empezar a hablar sobre, como, primero que todo, cómo pensar en evaluar un despliegue o solución de revisión de código. Así que esto se trata de las herramientas que estás eligiendo, también sobre cómo las estás usando. Y va a haber una progresión aquí. Voy a empezar con lo básico y subir la escalera con cada peldaño, agregando más requisitos y más valor que realmente hace que las soluciones de revisión de código de AI brillen.

Entonces, la primera parte, tiene que ser, ya sabes, sin ruido. No debe enviarme spam, no debe proporcionarme comentarios incorrectos o con mucho ruido. Si me proporciona ruido, será ignorado. El segundo peldaño, tiene que encontrar problemas y errores. Si está en silencio o si falta muchas de las cosas que necesitaba encontrar, nuevamente, no estoy obteniendo mucho valor, así que estoy buscando algo de completitud. Necesito poder confiar en esto para encontrar problemas.

El tercer peldaño es tener múltiples tipos de hallazgos. No todo es un error. Algunas cosas son problemas de seguridad. Algunas cosas están relacionadas con la mantenibilidad o la legibilidad del código fuente. Algunas cosas serían problemas de rendimiento. Así que tener, como, revisiones de código multifacéticas, que puedan resaltar diferentes tipos de hallazgos y, con suerte, categorizarlos para que quede claro lo que está encontrando. Ese será el siguiente nivel. No quieres solo una revisión de código de una sola vía o de una sola mentalidad que solo busque errores lógicos, porque el problema real no es solo la lógica. Porque el problema real nunca es solo una cosa.

El siguiente peldaño es que tiene que saber por qué. Tiene que ser consciente, al menos con cierta conciencia, de por qué estoy tratando de hacer este cambio. ¿Por qué estoy construyendo? Por ejemplo, ¿puede mirar el ticket, el ticket de JIRA, o el problema en el que estás trabajando y comparar la implementación con lo que realmente son los requisitos del producto? Tal vez sea una gran implementación de la cosa equivocada. Así que tener la capacidad de hablar sobre el alcance, sobre si realmente implementaste lo que se necesitaba. Ese es el siguiente nivel. Va más allá de solo mirar el código. También es entender por qué estamos haciendo esto. Subiendo la escalera hacia las partes más altas de las soluciones de revisión de código AI.

No todos los equipos trabajan de la misma manera. No todas las bases de código son iguales. Una herramienta de revisión de código AI tiene que saber cómo trabaja el equipo, tiene que ser capaz de aprender y conformarse con cuáles son las mejores prácticas para esa organización, para ese equipo, por lo que usar archivos de directrices, habilidades, otros insumos que básicamente lo ajusten y personalicen para convertirse en un jugador del equipo y no solo en algo genérico que mira el código. Tiene que entender que así es como revisamos y aceptamos código en esta base de código en este equipo. Tiene que tener alguna capacidad de aprendizaje y volverse más inteligente, mejorar, así que mejorar basándose en la retroalimentación que recibe de los usuarios, aprovechando el conocimiento existente, mirando solicitudes de extracción y comentarios anteriores.

Hay muchos insumos que puedes usar aquí. Pero la pregunta es, ¿tengo un lugar en mi SDLC para algo que sea estático y no mejore? El siguiente nivel es, ¿puedo realmente hablar sobre si me está haciendo más productivo? Así que hablamos de todo el valor que me está dando, pero ¿tengo una manera de medir esto? ¿Tengo una forma medible incorporada en la solución que me permita entender que esto realmente me está ayudando a moverme más rápido? ¿Esto está encontrando más cosas, mejorando la calidad, reduciendo el tiempo de ciclo, ayudándonos a movernos más rápido? ¿Y puedo probarlo? ¿Puedo mostrarlo? Porque hay una sensación instintiva y luego están los datos. Y finalmente, ¿puedo usarlo para transformar cómo trabajamos? ¿Puedo usarlo para cambiar el proceso, para automatizar algunas cosas, omitir humanos donde sea posible? Es un gran bloque de construcción para eso.

Pero, ¿soy capaz, tengo el soporte circundante y las herramientas que me permiten aprovechar los hallazgos y el hecho de que tengo la Revisión de Código AI para realmente transformar la forma en que trabajamos, la forma en que aceptamos código? Eso sería la cima de la escalera. Así que al mirar todo esto, esto también insinúa lo que hace una gran solución de Revisión de Código AI y su implementación. Tiene que tocar todos estos aspectos. Y voy a dar algunos ejemplos o mostrar un poco cómo abordamos esto con las herramientas de Linux B. Pero nuevamente, puedes aplicar esta escalera de evaluación a cualquier solución que quieras implementar allá afuera y ver dónde tienes buenas coincidencias para cada una de las etapas. Y tal vez una pregunta que deberías tener en mente y mirar cada vez que estés implementando la solución, ¿tienes una manera de probar el valor que estás obteniendo?

Esta será la primera pregunta. ¿Puedo demostrar el valor que estoy obteniendo de esa herramienta? Así que mirando algunos ejemplos, este es un ejemplo de un ticker que muestra los hallazgos reales, los PRs reales que LinDB ha escaneado. Esto es dog food. Este es nuestro propio código. Puedes ver los números y los tipos. Tenemos bugs, rendimiento, mantenibilidad, diferentes hallazgos, diferentes tipos. Y me da de un vistazo una comprensión de la acción. ¿Qué está sucediendo realmente con la Revisión de Código AI en mis equipos?

Hablamos de poder medir y entender. Así que aquí hay algunos ejemplos de cómo hablar sobre mediciones. Me voy a centrar en solo dos o tres de estos. Puedo mirar la cobertura. Entonces, ¿cuánto de mis nuevos PRs están realmente siendo revisados por AI? Esto depende de la forma en que lo implementé y si está habilitado en todas partes. Puedes ver que la cobertura no siempre es del 100%. Y esto es tal vez porque comencé a implementarlo teniendo solo la mitad de mi base de código, tal vez parte de mis repos, y luego quiero impulsar esto para que AI revise todo mi código y ver que esto llegue al 100%.

Si estoy mirando los problemas resueltos, entonces una buena solución de revisión AI rastrea los cambios que se realizan después de los comentarios para entender si los comentarios y los problemas planteados fueron realmente solucionados por el desarrollador. ¿Hicieron un commit o empujaron otro commit que solucionó esos problemas? Así que puedes ver el número de problemas potenciales identificados y luego el número de problemas resueltos. Puedo entender si los comentarios y los problemas que se encuentran realmente se abordan. Y luego están los commits directos de las sugerencias de AI. Así que si la revisión de código AI realmente me dio un fragmento para solucionar el problema y alguien lo comprometió directamente desde ese fragmento, también podemos rastrear eso. Y esto es como una gran señal que me dice que este comentario fue aceptado directamente. AI realmente ha contribuido líneas de código aquí a través de la revisión. Esa es una gran señal de éxito.

Otro ejemplo interesante es observar los problemas de alcance. Así que recuerda cuando mencioné que AI debe ser capaz de entender lo que estás tratando de construir. Así que aquí hay un análisis detallado de PRs específicos a través de diferentes repos donde la revisión de código AI encontró una desviación entre la implementación y el ticket. Así que esto realmente me ayuda a entender cómo puedo profundizar y entender no solo los números generales, sino entrar en ejemplos específicos. Profundizar hasta una pull request para entender exactamente dónde y cómo AI me ha ayudado. Y con el tiempo, puedes ver que está encontrando alrededor de 22 o 23 problemas de alcance cada semana para el equipo.

Así que siempre hay valor entrando. Este es otro ejemplo de cómo se ve el hallazgo de alcance. Y habla específicamente sobre el manejo de usuarios en nuestra base de datos, contribuyentes, y así sucesivamente. La implementación es diferente de los requisitos. Y esto es algo que el desarrollador tendrá que arreglar antes.

Esto realmente puede proporcionar lo que se requería. Voy a finalizar hablando de las revisiones de código AI como una señal o como un sensor para entender la calidad del código. Si AI está revisando el código entrante, ahora es capaz de decirme cuál es la densidad de problemas de diferentes tipos como bugs, seguridad, y así sucesivamente presentes en PRs que son creados por diferentes flujos. Así que puedo comparar el código que se escribe manualmente con el código que es generado por, ya sabes, Cloud o Copilot, o puedo comparar dos herramientas diferentes que están siendo utilizadas por el equipo. Todos sabemos que AI a veces puede proporcionar código que parece estar bien pero tiene problemas. Tener esa revisión de código AI como el primer paso ahora se convierte en un sensor de calidad.

Puedo mirar y decir, ¿estoy obteniendo buena calidad de mis herramientas de AI? O tal vez tengo desarrolladores junior que están creando código que no está a la altura y la revisión de código AI me lo está diciendo. Así que hay otro ángulo muy interesante de usar la revisión de código AI, no solo para corregir el PR sino también para ayudarme a medir la calidad del código entrante en general y de manera multidimensional. Voy a omitir un par de estos. Hablé sobre demostrar el valor y demostrar el impacto.

Aquí hay un ejemplo donde miramos varias métricas de productividad de ingeniería como el tiempo de revisión, cuánto tiempo me lleva fusionar una pieza de código, o el tamaño de la pull request y otros. Y puedo comenzar a comparar, comparar el comportamiento o las métricas de cuando se aplicó la revisión de código de agencia a otros lugares donde no se aplicó o aún no se implementó. Ahora puedo entender, ¿me está ayudando a hacer mi tiempo de ciclo más corto? ¿Me está ayudando con la calidad eventual del código? ¿Me está ayudando a moverme más rápido como equipo, básicamente.

Así que recuerda que la pregunta siempre es, ¿puedo probar, puedo mostrar que esta nueva solución que implementé, esta nueva práctica, realmente me ayuda a entregar más. Y tener esas comparaciones es un gran paso en esa dirección. Así que para resumir, la revisión de código es una gran oportunidad para AI. Es casi como una tarea que es perfecta para AI. Pero hay un montón de desafíos entre tú y lograr que la revisión de código AI realmente, realmente te ayude a moverte más rápido.