AI Reviews AI – Cerrando el Ciclo en el Desarrollo Agente

OK, gracias por invitarme. En la próxima charla sobre cerrar el ciclo en el desarrollo de agentes, primero quiero presentarme. Mi nombre es Daniel, soy de Alemania, trabajo como consultor para una empresa llamada Thinktexture, y también soy el MVP para tecnologías web y de desarrollo, ya que hablo mucho sobre tecnología de Microsoft para mis clientes.

Mi enfoque siempre ha sido cómo hacer que mis colegas y equipos de desarrollo sean más productivos. Y así, por supuesto, con el auge de la IA, también estoy hablando sobre este tipo de tema. Y primero que nada, creo que todos podemos decir que cada vez más código es escrito por IA. Creo que no necesitamos discutir eso. Así que es solo un número más de la encuesta de Sonar, por ejemplo, que el 42% del código que estamos enviando actualmente es generado por IA. Personalmente, cuando trabajo con clientes, diría que ya es más como el 90%. Pero sí, esos son los números que puedes encontrar en línea.

Y lo que también podemos ver es que estamos fusionando más y más código en producción. Tal vez este sea también uno de esos problemas que GitHub tiene actualmente, como que están constantemente caídos porque se envía más y más código a sus plataformas. Así que estamos enviando más código más rápido. ¿Es bueno o es malo? Esta es la pregunta principal. Y quiero darte algunas de mis experiencias y perspectivas, cómo puedes resolver esos problemas que tenemos. Así que ahora podemos enviar más código, y no tenemos tiempo para revisarlo. Creo que este es el mayor cuello de botella actual. Y cuando buscas en Google, encontrarás muchos estudios y números.

Así que este es solo un ejemplo de una empresa llamada Pharoes AI. Así que también deberíamos tomar esos números con cautela porque todas esas empresas con esos números también están tratando de venderte algunos productos. Pero aún quiero volver a esos números porque creo que son reales cuando miro a los clientes con los que trabajo.

Así que podemos ver que, OK, estamos enviando más código a producción, pero con un precio. Así que en este caso, en esos números, podemos ver que, por ejemplo, el tiempo para las revisiones de pull request está aumentando vertiginosamente. Son tremendamente atractivas. También podemos ver que el 31% del código ahora se fusiona sin una revisión.

Porque, por ejemplo, uno de mis clientes cambió completamente al desarrollo agentic. Así que puedes pensar si es bueno o malo. Pero cuando hablo con los desarrolladores, me dijeron que, OK, no podemos revisar el código. Así que intentamos crear pull requests más pequeños. Y cuando los pull requests son pequeños y el CI está en verde, entonces lo fusionamos de todos modos. Porque la calidad del código ya no importa. La pipeline está en verde, así que podemos enviarlo.

Pero también podemos ver, por ejemplo, que la incidencia por pull request también está aumentando. Este es un problema realmente, realmente grande. Así que hay un número, un término llamado code churn. Code churn significa que estás creando un pull request, estás fusionando algo, y directamente después de fusionar, necesitas tocar el código que fusionaste antes. Así que estás agregando código a tu base de código que tal vez funcione, pero luego te das cuenta, OK, no está funcionando. O el código no era bueno, así que necesitamos tocarlo. Y necesitamos cambiar la línea de código o corregir un error.

Este es un problema realmente, realmente grande. Por ejemplo, también puedes echar un vistazo al último informe Dora de Google. Así que también están publicando este informe una vez al año. Y también puedes ver que grandes empresas como Google también están luchando con este problema. Por ejemplo, en el último informe, el número de incidentes aumentó un 5% o 6%. Así que ahora están enviando más características, pero la estabilidad de los productos, los productos internos que estamos usando como clientes, están disminuyendo, bajando un 5% o 6%.

Así que este es un problema realmente, realmente grande. No solo lo tengo con mis clientes más pequeños, sino también con grandes empresas como Google. Entonces, ¿cómo podemos lidiar con estos problemas? Así que el problema principal a menudo es que el código parece plausible. Así que parece que el código está funcionando. Como, OK, tenemos un CI, tenemos pruebas, las pruebas están en verde, la construcción está en verde, el linter está en verde. Entonces, ¿por qué deberíamos revisar el código? Está funcionando. Cuando estamos haciendo clic a través de la UI, tal vez también esté funcionando. Pero el problema son esos problemas ocultos. Nuevamente, un ejemplo de mis clientes. Tal vez conozcas esta herramienta llamada Sonar. Así que también te mostré algunos números de ellos llamados Sonar Cube o Sonar Cloud. Es un software que puedes usar para análisis de código estático para analizar, por ejemplo, si estás introduciendo líneas de código duplicadas.

Así que también trabajé con un cliente. Querían introducir la codificación asistida por IA en su equipo. Así que tenían como 50 desarrolladores. Y luego pusimos en marcha Sonar Cloud, y la base de código existente ya tenía un 35% de líneas de código duplicadas. Así que es un problema realmente grande. Ahora piensa en agregar más código generado por IA a una base de código ya relacionada. Así que es un problema realmente, realmente grande. Y tienen muchas pruebas unitarias, como si estuviera alrededor del 80% de cobertura. Pero cuando miras su backlog, estaba realmente lleno de errores. Así que un problema realmente, realmente grande.

Así que necesitamos o todavía necesitamos puertas de calidad. Este es el mayor problema que puedo ver cuando hablo con desarrolladores que, diría que saben cómo usar cloud code o cualquier otro harness. Realmente no importa. Pero la mayoría de esos desarrolladores no están pensando en puertas de calidad. Así que quiero darte algunos ejemplos de cómo resolver esos problemas. Primero, hay formas deterministas de resolver estos problemas y formas probabilísticas de hacerlo. En primer lugar, siempre debes comenzar con soluciones deterministas. Así que pruebas, linters, comprobaciones de tipo, hooks y más. Volveré a eso después. Y por otro lado, todavía podemos usar, o en algunos casos, IA para revisar nuestro código con la ayuda de diferentes modelos o herramientas.

Así que la capa de defensa es realmente pequeña. Así que cuando los desarrolladores me hablan, y porque hablo mucho en conferencias sobre codificación asistida por IA, siempre piensan que mi configuración podría ser realmente complicada. Debería usar muchos sub-agentes y diferentes tipos de herramientas y harnesses. No, mi configuración en sí es realmente, realmente simple. Así que primero en el lado izquierdo, porque también hablo mucho sobre el desarrollo Spectrum, es que yo como desarrollador todavía estoy escribiendo la especificación. Ya no estoy escribiendo el código, pero estoy escribiendo la especificación. Así que este es, por supuesto, mi primer desafío. Luego entrego la especificación a cualquier tipo de harness. En primer lugar, cuando comienzo mis propios proyectos personales o cuando me uno a equipos de desarrolladores, primero configuro algunas puertas deterministas. Puedes asumir, diría que soy desarrollador ahora desde hace 10 años, y he trabajado con, no sé, 100, 200 clientes, y había, no sé, diría que el 5% de mis clientes usaban linters y formatters correctamente en su base de código.

Así que para mí personalmente, cuando comencé a desarrollar con Angular y TypeScript, hace 10 años, entonces había, por ejemplo, el modo estricto introducido. No sé cuándo fue, pero muchos de mis clientes todavía no usan el modo estricto, por ejemplo. Así que primero lo primero, antes de iniciar cualquier harness, completa tus fundamentos, define el linter, define el formateador de código, inicia el modo estricto, lo que sea. Este es el primer paso. Esto es realmente importante. Después de eso, entonces intento o comienzo a añadir sub-agentes de IA en mi ciclo. Más sobre eso también más tarde. Así que esta es la segunda etapa.

Y luego la tercera etapa, también quiero hablar de ello más tarde, son algunos servicios de revisión de pull requests. Así que hay algunas herramientas que puedes usar. Y después de eso, todavía se necesita una revisión humana. En algunos casos, tal vez no. Pero al final de este ciclo puedes ver que comienza con mi aporte personal y también termina con mi aporte personal. Así que este es mi ciclo preferido personal.

Y primero que nada, una de esas características al trabajar con harnesses son los hooks. Los hooks son tan simples. Son realmente simples. Pero de nuevo, cuando hablo con mis clientes, no sé, ninguno de ellos los está usando. Lo genial de los hooks en cualquier tipo de harness, en este caso es Cloud Code pero realmente no importa, es que son deterministas. Así que no tiene sentido, por ejemplo, uno de mis ejemplos favoritos es que alguien está escribiendo algo como en su Agents MD, por favor después de cada tarea ejecuta las pruebas unitarias o por favor haz una revisión de código. Esto es un completo sinsentido. Es no determinista.

No deberías escribir algo como esto en tu Agents MD o por favor no hagas ningún tipo de commits, por favor no elimines ninguna línea de código. Esto realmente no funciona. Necesitas una manera determinista de manejar estos casos. Y los hooks son la manera más simple. Hay diferentes tipos de hooks. Este es un ejemplo. Este es, por ejemplo, el hook de post tool.

Así que este hook siempre se llama, en este caso, nuevamente por Cloud Code, cuando Cloud Code llama a una herramienta y luego puedes escribir una medida. Por ejemplo, en este caso estoy filtrando la herramienta de edición y escritura. Así que cada vez que Cloud Code toca un archivo y edita el archivo, el hook se ejecutará y luego puedes ejecutar cualquier tipo de scripts. Así que en este caso, para que quepa en la pantalla aquí, estoy ejecutando ESLint, por ejemplo.

Y una cosa genial aquí es que el hook puede entonces devolver el resultado al agente nuevamente como un prompt. Como, está bien, la función que añadiste está introduciendo algunos problemas de lint o algunos problemas de tipado o la aplicación no está compilando o algunas pruebas unitarias no están corriendo. Esto le da al agente retroalimentación directa. Así que el agente no espera hasta que la tarea esté completada y luego intenta arreglar algo, sino que mientras escribe código, arregla algo por ti. Así que es realmente simple.

Los hooks son increíbles. Hay más hooks como, por ejemplo, hay un ejemplo del stop hook. En este caso, estoy ejecutando un compilador de TypeScript, pero también puedes iniciar sub-agentes como un hook. Así que puedes, al final, definir un stop hook y un stop hook es entonces, por ejemplo, iniciar tu agente de revisión de código que definiste. Y luego automáticamente no necesitas solicitar algo, no necesitas esperar que tu harness esté llamando al sub-agente. El agente siempre se ejecutará. Realmente, realmente simple. Así que deberías comenzar a añadir hooks.

También, una cosa a tener en cuenta. También hay un hook, por ejemplo, el pre-tool use hook. Puedes usarlo para asegurarte de que tu agente en el modo automático o modo YOLO no esté eliminando algo por ti. Así que definitivamente deberías probarlo. Realmente importante. También, parte de la capa uno es el desarrollo dirigido por pruebas y por comportamiento. También hay, por ejemplo, cuando estoy en LinkedIn, hay tantas publicaciones sobre, oh, uso cloud code para crear una tasa de cobertura del 99% generando pruebas unitarias para mi base de código existente. Sí, felicitaciones.

Esto es un completo disparate. Esto no tiene ningún sentido porque el problema es que tienes una función con un error. Le pides a cloud code, por favor escribe una prueba unitaria. Y luego la prueba unitaria solo confirma el código existente. Y luego tienes una prueba unitaria que siempre está en verde y no te ayuda a encontrar un error o a corregir errores. Así que no uses la IA de esta manera. No era un gran fanático del desarrollo dirigido por pruebas cuando comencé a desarrollar software, pero siempre fui un gran fanático del desarrollo dirigido por comportamiento porque lo bueno del desarrollo dirigido por comportamiento es que, por ejemplo, esos criterios de aceptación en esos archivos pueden ser escritos también por personas no técnicas en tu equipo.

Así que estamos moviéndonos de ingenieros de software más hacia quizás desarrolladores de productos. Así que escribir código es menos importante. Así que también más personas de tu equipo de desarrolladores de software se unen a esta cadena de desarrollo de software, generando código sin este conocimiento profundo. Así que tiene más sentido usar el desarrollo dirigido por comportamiento para definir esos archivos. Así que cualquiera puede leer esos archivos.

Cualquiera puede mantener esos archivos. Y también lo bueno es que, sí, tu agente de codificación no puede eludir esos requisitos. Así que tal vez el código aún pueda parecer basura, o tal vez no sea bueno desde la perspectiva de la arquitectura. Esto no importa, pero siempre puedes asegurarte de que, sí, el comportamiento de tu tarea en la que estás trabajando está funcionando.

Así que esto es realmente importante. Así que cuando piensas en esos números que te mostré antes, hay muchas más líneas de código añadidas a nuestra base de código, no hay tiempo para revisar esas líneas de código. Así que tal vez no tengas tiempo para asegurarte de que el código se vea bien, pero quieres asegurarte de que el código funcione y siga las especificaciones que definiste al principio.

Así que definitivamente deberías pensar en el desarrollo dirigido por comportamiento y el desarrollo basado en pruebas. Para los desarrolladores de front-end, por ejemplo, estoy usando PlayWrite todo el tiempo. Así que con PlayWrite, es realmente simple configurar tales flujos de trabajo. Hay múltiples bibliotecas disponibles. No importa si es PlayWrite, VTest, o algo así. Y lo que también es genial, puedes combinarlo entonces con plataformas como Jira, Atlassian, Tools, no importa.

Así que tu product owner, por ejemplo, define tus historias de usuario, criterios de aceptación, y luego tu agente, si deseas usar un agente para generar esos archivos, puede extraer los requisitos y generar tus pruebas a partir de ellos. Así que realmente simple. Y la capa dos es ahora el agente de revisión en el bucle. Así que puedes usar IA para revisar IA. Pero hay un problema. Esos agentes a menudo añaden demasiado ruido. Este es un problema. Y también muchos desarrolladores usan, por ejemplo, están en la misma sesión, así que están usando Cloud Code para generar código. Y en la misma sesión, están iniciando su agente de revisión. Así que en la misma ventana de contexto. Así que este es también un gran problema. Así que nunca deberías hacer eso. Así que cuando estés revisando tu código, asegúrate de siempre iniciar una nueva sesión con un contexto limpio. Así que esta es la primera parte. Es realmente importante. Y volveré a eso más tarde después de esta diapositiva.

Pero también puedes usar algunos servicios. Solo un ejemplo, GitHub Copilot, GrabTile, CodeRabbit. Hay tantas herramientas disponibles. Soy fan de esas herramientas porque son bastante económicas y funcionan realmente bien. Pero mi principal problema aún con esas herramientas es el ruido. Así que, por ejemplo, GrabTile añade muchos comentarios de código. Esto tal vez no sea un problema porque hay una razón por la que hay algunos comentarios. Pero, por ejemplo, a menudo tengo este problema.

Bien, hay una revisión. Cambio la línea de código, vuelvo a ejecutar la revisión, y luego el agente me dice la diferencia completa. Bien, ahora cambiaré el código de nuevo al anterior. Esto es un poco frustrante. Y hay un aprendizaje con eso. Entonces, ¿quién revisa al revisor? Es que no deberías usar el mismo modelo. Hay algunos estudios que también puedes encontrar y leer si te interesa. Y puedes ver que hay algo llamado rubber ducking.

Eso también está en la siguiente diapositiva. Se llama rubber ducking. Con rubber ducking... ¿Cuál es el problema? No hice nada. Bien, lo siento. Bien, ahora ha vuelto. Realmente simple. En lugar de usar SONET para revisar SONET, OPUS revisando SONET, estás usando SONET para generar código y luego usas cualquier modelo GPT como un ejemplo para juzgar y revisar el resultado. También puedes usarlo cuando generas un plan, por ejemplo. Puedes usarlo para la revisión de código. Realmente no importa.

También hay otro beneficio. Cuando combinas dos modelos más económicos para juzgarse entre sí, también te acercas a los modelos más caros. También encontrarás algunos números y estudios por ahí. Así que también puedes usarlo no solo para asegurarte de que el código sea mejor o los requisitos estén mejor definidos, sino que también puedes usarlo para ahorrar algunos tokens porque los tokens son cada vez más caros. Pero al final, puedes ver que todavía estoy yo, como humano, revisando el código. Bien, llegando al final, los puntos clave. Bucles de autocorrección que aún controlas. Lo siento. Así que la revisión es un cuello de botella.

Pero cuando trabajo con mis clientes, la parte de revisión de código es actualmente el mayor cuello de botella. Y siempre deberías comenzar con herramientas y bucles deterministas. Y, por ejemplo, usando hooks. Esto es realmente importante. Y también, deberías pensar en cómo estás generando pruebas. Así que, por favor, no uses AI para generar pruebas de código existente. Esto es un completo sinsentido. Úsalo para escribir pruebas de desarrollo guiado por pruebas o pruebas de desarrollo guiado por comportamiento.

Y si te gusta usar AI para revisar AI, intenta combinarlo con diferentes modelos. Así que no uses el mismo modelo. Usa diferentes modelos. Y al final, aún deberías estar en el bucle. Quizás esto cambie en el futuro. Pero actualmente, todavía quiero entender qué está haciendo el código. Quizás no todos los detalles. Pero todavía quiero asegurarme de que si alguien me pregunta, qué está haciendo el código, todavía pueda explicarlo.

Eso es todo de mi parte. Aquí está el código QR. Puedes escanearlo para encontrar las diapositivas. También puedes seguirme en LinkedIn si lo deseas. Así que te doy unos segundos más para escanear el código QR. Así que siéntete libre de conectar. Y después, es tiempo para tus preguntas. Fantástico. Muchas gracias, Daniel. Un aplauso para Daniel. Increíble. Así que por favor sigue enviando tus preguntas en Slido. El código es, nuevamente, 0607. Te daré unos segundos más.

Uno, dos. ¿Está funcionando? Bien, genial. Así que también puedo cambiar. Fantástico. Muchas gracias de nuevo por eso, Daniel. Así que la primera pregunta aquí. Mencionaste que para las pruebas, uno debería usar procesos deterministas primero antes que LLMs. ¿Es esta la mentalidad que deberíamos aplicar a otras tareas o problemas? ¿Hay casos donde AI primero es más beneficioso? Sí, así que esta es mi preferencia personal y aprendizaje que siempre deberías comenzar o deberías usar formas deterministas para revisar. Sí, porque es barato. También es barato. Es rápido. Es confiable. Porque mi experiencia personal con muchos equipos de desarrolladores es que ahora están tratando de añadir AI a todo. Pero no creo que necesites AI para todo. Así que comienza con lo básico. Muchos equipos no tienen lo básico. También es algo bueno porque muchos niveles C están viniendo a mí y preguntando, bien, queremos implementar ahora AI en nuestro equipo. Y luego encontrarás todos esos problemas del pasado que necesitan solucionar. Así que también es bueno comenzar con las cosas antiguas primero. Eso es increíble. Asombroso.

Así que con hooks, otra pregunta. Ejecutamos el chequeo de tipo lintar después de cada archivo, lo cual parece mucho comparado con ejecutarlo una vez después de que algunos archivos han sido tocados. ¿La nube recibe también el feedback de los hooks? Sí, claro. Así que por supuesto, no deberías ejecutar tal vez todo en cada cambio y edición de archivo. Así que no quieres ejecutar, por ejemplo, la construcción o el compilador cada vez. Esto sería demasiado lento. ¿Y cuál es la segunda parte? ¿La nube recibe también el feedback de los hooks? Sí, esta es la buena cosa que puedes decir, bien, el hook se ejecutó sin encontrar un problema, entonces no estás reportando nada de vuelta. Pero si encuentras un error de compilación, error de lint, entonces estás enviando el feedback de vuelta al agente como un prompt de entrada, y luego el agente puede trabajar en esto. Bien.

Increíble. Muchas gracias. La siguiente pregunta que tenemos, sigan enviando sus preguntas, por cierto. También están transmitiendo en línea. La siguiente pregunta que tenemos es, en tu opinión, ¿qué modelos son mejores para revisar el código? Puedo darte una respuesta sobre cuál es tal vez el mejor modelo. Así que desde mi perspectiva, por supuesto, todos esos nuevos modelos son realmente buenos. Así que como te mostré o hablé sobre este seguimiento rápido, para mí, tiene más sentido usar diferentes modelos. Así que personalmente, uso mucho cloud code para generar código. Pero en mi pipeline de revisión de código, estoy usando los modelos GPT. Solo mi preferencia personal, podría ser al revés, realmente no importa desde mi perspectiva actualmente. Bien, eso tiene sentido. Asombroso. El siguiente, si estamos usando revisiones de AI en el momento del PR, si pudieras frotarlo, etcétera, mencionaste que esto era L3. ¿Qué ves en la siguiente etapa de la evolución, básicamente? Esa es una buena pregunta. Así que mi perspectiva personal es que podría haber un punto, tal vez en los próximos meses, no lo sé, que la calidad del código sea tan buena que no necesitemos revisarlo. Esto solo funciona cuando tu arquitectura está bien definida, así que tienes que pensar en tus habilidades y todo sobre eso. Y luego todavía necesitas pruebas. Por eso estoy forzando a mis clientes a comenzar finalmente a escribir pruebas de extremo a extremo y pruebas de integración para asegurarse de que nada se rompa, tu código está funcionando, tu estabilidad se mantiene alta, tu velocidad se mantiene alta en tu aplicación, así que entonces puedes enviar código sin mirar más de cerca porque todavía tienes estas herramientas de observabilidad para asegurarte de que todo sigue funcionando. Así que creo que esto es importante, pero aún no. Increíble. Así que la siguiente que tenemos es, ¿qué piensas sobre que el LLM encuentre y escriba pruebas unitarias faltantes con revisión humana como una forma de resaltar casos límite inesperados? Sí, creo que esto está bien. Pero entonces, por supuesto, todavía necesitas pensar en el código. Así que deberías echar un vistazo al código y luego puedes juzgar la prueba unitaria que el LLM quiere que escribas. Creo que esto está bien, pero no deberías usarlo a ciegas, solo generando pruebas para tener una tasa de cobertura más alta. Asombroso. Fantástico. Tenemos más preguntas llegando. Así que la siguiente es, ¿puedes explicar más sobre el desarrollo dirigido por comportamiento? Sí, es realmente simple. Así que, por ejemplo, podemos usar BDD. Tal vez pueda abrirlo.

Tengo un repositorio localmente, pero no estoy seguro si puedo mostrar algo de mis clientes. ¿Dónde está? Tal vez podamos encontrar algo como esto. Así que este es un comportamiento que puedes definir. Es legible por humanos. Así que tenemos una característica, luego tienes escenarios, y luego siempre tienes esta sintaxis dado-cuando-entonces. Y basado en este texto, se generan pruebas. Así que no la prueba completa, por supuesto, pero los inputs y los outputs que una prueba debería tener.

Así que la parte de preparación y la parte de afirmación se generan. Y lo bueno es que, como dije en mi charla, cualquiera puede leer este texto, tú como desarrollador, pero también tu product owner o alguien del soporte puede leer esos textos. Y este es el beneficio de ello. Y luego, por supuesto, la prueba aún necesita ser escrita por ti o por la AI más tarde. Pero sí, eso es todo.

Increíble. Fantástico. Así que este es uno muy interesante. Entonces, al final, ¿a quién culpar si la revisión de código significa un error, que causa una interrupción? ¿Es el desarrollador o tal vez alguien más? Yo diría que todavía el desarrollador, por supuesto. Hay algo llamado propiedad extrema, por ejemplo, así que deberías ser el dueño.

Por eso también digo que todavía quiero entender lo que estoy enviando. Así que tal vez no pueda explicar todo en detalle, pero todavía quiero poder explicar lo que el código está haciendo que estoy enviando. Quiero entender las APIs que estoy usando. Así que si algo se rompe, todavía es mi culpa, por supuesto, al final. Así que mi propiedad personal. Así que sí. Fantástico. Gracias. Siguiente pregunta sobre métricas. ¿Qué métricas aconsejarías usar para medir si el enfoque está funcionando? Buena pregunta, porque no es fácil qué KPIs podemos usar para medir. Así que tal vez deberías echar un vistazo a Dora, por ejemplo, o Space o DevX.

Con esas métricas, puedes, por ejemplo, medir la estabilidad de tu software. Porque números como pull requests, líneas de código, no tienen sentido. Tal vez puedas medir con qué frecuencia lanzas algo, pero tampoco soy un gran fan de esos números, pero me gusta medir el rendimiento de estabilidad de mi aplicación. Y también puedes medir, por ejemplo, la satisfacción del cliente o también del desarrollador para asegurarte de si están contentos con los resultados finales. Ese tipo de números tienen sentido para mí.

Increíble. Tenemos otra. Tenemos un par de preguntas más. Así que sigan enviándolas. Entonces, ¿encuentras que estamos siendo inundados con PLs generados por AI, como me gusta añadir, nuestros desarrolladores no siguen buenas prácticas? ¿Añadiendo pruebas exhaustivas para tus características? Necesito revisar tu trabajo antes de ponerlo en un PL. ¿Qué piensas?

Déjame pensarlo brevemente. Así que primero, a menudo esto es un problema para proyectos de open-source, así que ya no los mantengo. Pero a menudo todavía hay un problema de que muchos repositorios de open-source están cerrando pull requests porque nos vemos abrumados por esos pull requests. Así que, sí, de nuevo, entonces deberías definir algunos quality gates como equipo antes. Así que deberías definir tu definición de listo. ¿Cuándo está algo listo para revisión? Esos quality gates que deberían ser definidos por el equipo son realmente importantes. Así que alguien quiere enviar algo, pero entonces necesitas obligarlos a asegurarse de pensar antes de enviar algo así. Increíble. Muchas gracias.

La siguiente pregunta que tenemos es, ¿pueden las revisiones de AI identificar desviaciones de contratos? Sí, es una buena pregunta, porque a menudo esas herramientas de revisión de código solo miran tu código, pero no miran, por ejemplo, en tu ticket de G-Route, algo así. Por eso me gusta el desarrollo Spectrum. No soy fan de las herramientas para el desarrollo Spectrum, pero me gusta que tengas una única fuente de verdad. Y luego puedes combinarlo. Por ejemplo, puedes construir tu propio agente de revisión usando GitHub Copilot o lo que sea, realmente no importa. Y simplemente conectarlo usando una herramienta MCP a tus productos de Atlassian y también los requisitos en el proceso de revisión de código. Esto también es importante.

Pero de nuevo, volviendo al desarrollo dirigido por comportamiento, gracias a BDD, los requisitos del ticket también se traducen en pruebas. Así que puedes mirar tus pruebas en el desarrollo dirigido por comportamiento o en este archivo de características para asegurarte de que no haya desviaciones. Increíble. Suena bien. Tenemos dos minutos, así que vamos a tomar tal vez una pregunta.

Así que esta es interesante. ¿Existen frameworks que básicamente estructuren lo que has hablado hoy y pongan el proceso en conjunto? Porque soy un desarrollador front-end, trabajo mucho con, por ejemplo, para GitHooks estoy usando Lefthook en lugar de Husky. Así que Lefthook es una solución más ligera. ESLint, Prettier, Sonar, como dije. Sonar es realmente genial porque puedes alojarlo, así que no necesitas pagar por la solución en la nube. Puedes ejecutar tu propio contenedor Docker y luego también puedes instalar, por ejemplo, cuando todavía estás usando IDEs como Visual Studio Code, puedes sincronizar las reglas de Sonar desde el servidor con el plugin en tu IDE, así que tú como desarrollador ves directamente, okay, si me faltan algunas de las reglas que definimos como equipo, por ejemplo.

Así que nada espectacular, sin herramientas sofisticadas. Me gusta mantener mi configuración limpia. Así que ninguna herramienta para gobernarlas a todas. Sí, correcto. Increíble. Sí, estamos a tiempo. Muchas gracias, Daniel. Un aplauso para Daniel. Gracias.