GitHub Copilot, an AI-powered coding assistant, is rapidly transforming software development. Studies show Copilot can significantly boost developer productivity with features like predictive text leading to 55% faster task completion. Copilot can also improve code quality in areas like readability and maintainability. This frees developers from repetitive tasks, boosts morale and allows them to focus on the creative and strategic aspects of software development.
Sin embargo, medir el verdadero impacto de Copilot requiere un enfoque integral que considere no solo la velocidad y la calidad, sino también la adopción por parte de los desarrolladores, la dinámica del equipo y los posibles sesgos dentro del modelo de IA.
Después de practicar con GitHub Copilot durante varios meses, identificamos algunas trampas al codificar y cómo superarlas. La herramienta proporciona un ritmo mucho más rápido, pero no es mágica. Su naturaleza no determinista, en la que genera varias sugerencias para una solicitud dada, puede ser una característica inesperada y potencialmente distraída.
Aunque GitHub Copilot ofrece una funcionalidad notable, es esencial recordar que "con un gran poder viene una gran responsabilidad". O, citando a Michael Feathers, "cuando usamos IA para la generación de código, la garantía de calidad se vuelve mucho más importante". Recomendamos ejercer cautela al usarlo para mitigar la ocurrencia de código generado por el asistente de IA que puede no cumplir con las expectativas, como la contaminación de contexto, el sesgo de automatización, la falacia del costo hundido, el efecto de anclaje y la autocompletación en esteroides. Llamamos a estos comportamientos incorrectos 'olores' de IA.
En lugar de relajarte pensando que GitHub Copilot codificará por ti, debes estar especialmente enfocado en las decisiones de implementación. De lo contrario, podrías perder requisitos relevantes de tu código, ya que te distraen las recomendaciones aleatorias. Recuerda: tú sigues estando al mando.
Nuestra exploración reveló que el desarrollo guiado por pruebas (TDD) y la programación en pareja pueden mitigar eficazmente la ocurrencia de 'olores' de IA. En este blog, profundizaremos en por qué creemos que esto es así.
GitHub Copilot, tu pato de goma de IA
Copilot es una herramienta asistida por IA para programadores. Permite a los usuarios interactuar con Copilot en un formato de lenguaje natural o emitir comandos específicos y esperar a que se complete el código. Los desarrolladores pueden describir su funcionalidad deseada a través de solicitudes o pedir completaciones para líneas de código específicas. Copilot luego analiza la base de código existente y los elementos contextuales para generar sugerencias relevantes, que van desde completaciones de código hasta fragmentos completos, adaptados a la intención del programador.
Aunque el lema "GitHub Copilot, tu par de programación de IA" puede captar inicialmente la atención, puede llevar a algunos malentendidos. Es importante reconocer que no captura completamente la verdadera naturaleza de lo que realmente es la programación en pareja.
Una frase más precisa y descriptiva sería: "GitHub Copilot: tu pato de goma de IA", reflejando adecuadamente su capacidad para facilitar un proceso de auto-explicación e introspección. El rol de GitHub Copilot radica en ayudar a los desarrolladores a articular sus pensamientos y entender el problema en cuestión.
Además, redactar comentarios claros y concisos antes de buscar recomendaciones de código puede mejorar significativamente el proceso de auto-reflexión y comprensión. En esencia, GitHub Copilot actúa como un catalizador para el diálogo interno, incitando a los desarrolladores a articular sus ideas y comenzar la discusión consigo mismos.
Programación en pareja y desarrollo guiado por pruebas
¿Por qué es importante la programación en pareja?
La programación en pareja es una técnica en el desarrollo de software donde dos programadores trabajan juntos en una sola computadora o de manera remota, turnándose para ser el conductor y el navegador. El conductor es responsable de escribir el código, mientras que el navegador se encarga de guiar la implementación, dar retroalimentación y sugerir mejoras. La programación en pareja fomenta una cultura de colaboración, reducción de errores y mejora del código.
GitHub Copilot carece de la capacidad de cuestionar o desafiar tus suposiciones, por lo que no puede ofrecerte perspectivas alternativas como lo haría un ser humano al programar en pareja.
Test-driven development (TDD)
TDD nos obliga a pensar en el problema de manera estructurada, desglosándolo en unidades más pequeñas y testeables, también evitando violaciones del principio YAGNI. TDD no solo mejora la calidad del código a través de pruebas, sino que también promueve un código bien diseñado. TDD también enfatiza la modularidad y la separación de preocupaciones, principios de diseño que hacen que el código sea más flexible y adaptable a cambios futuros, más fácil de entender, mantener y modificar. TDD también nos ayuda a identificar y abordar problemas potenciales desde el principio, reduciendo la probabilidad de introducir 'olores' de IA más adelante en el proceso de desarrollo. GitHub Copilot es extraordinariamente efectivo al sugerir grandes fragmentos de código y patrones repetitivos, pero siempre existe el riesgo de caer en algunos 'olores' de IA; TDD puede mitigarlos.
Con TDD, los desarrolladores escriben código en el último momento responsable, por lo que siempre están en control de la implementación, no GitHub Copilot. Vale la pena recordar que hay una tarea antes del ciclo Rojo/Verde/Refactorizar: Pensar. Esto te mantiene enfocado y evita algunas de las trampas de autocompletado en esteroides.
'Olores' de IA — y cómo prevenirlos
La naturaleza predictiva de GitHub Copilot hace que sea desafiante involucrarse en un diálogo verdaderamente bidireccional. Aunque el asistente de IA puede hacernos pensar y reflexionar, es importante no convertirnos en receptores pasivos de sus sugerencias, lo que puede llevar a trampas como la adopción de código mal elaborado o incluso perjudicial.
Curiosamente, los 'olores' de IA pueden surgir no solo de depender únicamente de GitHub Copilot sino también de la codificación en solitario. Esto se debe a que nuestros cerebros tienen una tendencia natural hacia la pereza y se inclinan hacia tareas familiares y repetitivas, ya que requieren menos esfuerzo cognitivo. Esta tendencia puede llevarnos a tomar atajos y pasar por alto consideraciones importantes.
Los 'olores' de IA descritos en las siguientes secciones han sido identificados en otros lugares. Junto con la exploración de los posibles 'olores' de IA, proporcionamos consejos útiles para abordarlos.
Contaminación de contexto
La contaminación de contexto ocurre cuando seguimos buenas prácticas y solicitamos a Copilot que haga lo mismo, pero aún así continúa sugiriendo implementaciones obsoletas o patrones deficientes.
TDD no solo es una forma de cubrir tu código con pruebas para favorecer el proceso de refactorización, sino también una forma de pensar sobre la arquitectura y la mejor y mínima implementación para la funcionalidad. Por lo tanto, la contaminación de contexto puede mitigarse en gran medida utilizando TDD y programación en pareja. Algo a tener en cuenta es que GitHub Copilot puede generar fácilmente más código del necesario para hacer pasar la siguiente prueba. Se requiere algo de disciplina y diálogo para no aceptar demasiado código de una vez y evitar el siguiente olor de IA, la autocompletación en esteroides.
Consejo #1. Reflexión: TDD y la programación en pareja nos obligan a discutir enfoques y soluciones. Decir y explicar las cosas en voz alta nos impulsa a reflexionar si realmente tenemos el nivel adecuado de comprensión o si realmente tenemos la mejor solución.
Autocompletado en esteroides
Esto se refiere a la desafortunada tendencia a desconectar el cerebro y aceptar todo, en un bucle infinito de Tab/Enter.
Esto puede ocurrir cuando usamos GitHub Copilot, ya que la comunicación es unidireccional; hace que sea demasiado fácil desconectarse y simplemente aceptar sus sugerencias. Aceptar cada recomendación proporcionada por el asistente de IA requiere menos esfuerzo cognitivo.
Consejo #2. Pensamiento crítico: La programación en pareja nos anima a involucrar activamente nuestras propias habilidades de pensamiento crítico a través de la discusión. Debe obligarnos a evaluar cuidadosamente las sugerencias ofrecidas y considerar su relevancia, mantenibilidad y si cumplen con las buenas prácticas.
Sesgo de automatización
Este es el error de preferir aceptar las sugerencias automatizadas de GitHub Copilot sobre la entrada de código manual que proviene de nosotros. Surge de la suposición de que una salida generada a través de la computación es ‘mejor’ o más precisa que algo hecho por un humano.
En realidad, GitHub Copilot a menudo proporciona fragmentos de código que no son los más apropiados. A veces esto es porque la solicitud no es lo suficientemente precisa; es posible que necesitemos reformularla o proporcionar más información o contexto.
Consejo #3. Mantén el enfoque: La programación en pareja te mantiene enfocado al requerir que comuniques tu progreso y decisiones a tu pareja. Previene que te distraigas y te vayas por caminos sin salida. Cuando dos pares de ojos están mirando el código, podemos identificar mejor problemas potenciales que podrían pasarse por alto por un solo desarrollador.
Falacia del costo hundido
La falacia del costo hundido en este contexto es cuando dudamos en rechazar o modificar el código sugerido por GitHub Copilot debido al tiempo o esfuerzo ya invertido en él.
Consejo #4. Revisión constante: TDD te obliga a revisar y refactorizar el código regularmente. Esta práctica ayuda a evitar la falacia del costo hundido al mantener una mentalidad abierta y centrada en mejorar el código, no solo en aceptar el que ya ha sido escrito.
Efecto de anclaje
Esto ocurre cuando nos resulta más difícil desarrollar implementaciones de código alternativas una vez que hemos visto una sugerencia de Copilot.
La programación en pareja puede ser útil una vez más para abordar esto: puede fomentar la reflexión y la discusión, lo que puede llevar a una comprensión más profunda del problema, del código y de otras posibles soluciones.
Consejo #5. Dos modos de pensar combinados: La programación en pareja permite tener diferentes perspectivas sobre el código, proporcionando alternativas más estratégicas para el diseño genera
Consejo final. Pausas regulares: dale a tu cerebro la oportunidad de descansar y recargarse tomando pausas regulares durante tus sesiones de codificación. Alejarse de la computadora puede ayudarte a regresar con una perspectiva renovada y más objetiva.
Conclusión
El futuro es impredecible: mientras las nuevas herramientas continúen encontrando su camino en el conjunto de herramientas del desarrollador, lo que realmente importa es sacar lo mejor de ellas. En Thoughtworks, TDD y la programación en pareja son parte de nuestros estándares sensatos. GitHub Copilot (y herramientas similares) pueden mejorar la calidad del software producido, pero solo si el proceso de desarrollo fomenta la comunicación y si la implementación se centra en producir código limpio y eficiente de manera iterativa.
GitHub Copilot pretende transformar a las personas en desarrolladores 10x. Esto podría derivarse de la creencia errónea de que la aparente fluidez en la generación de código implica comprensión de los conceptos subyacentes. Es momento de dar un paso atrás y reflexionar, no solo sobre la velocidad, sino sobre la efectividad al usar GitHub Copilot de manera inteligente. Por lo tanto, recomendamos encarecidamente GitHub Copilot como el compañero perfecto para la programación en pareja y TDD, y los desarrolladores que los utilicen están en el camino correcto.
Gracias a Birgitta Boeckeler y al grupo “Ensembling with Copilot” alrededor de Paul Sobocinski en Thoughtworks Canadá por sus memorandos perspicaces que ayudan a entender mejor lo que llamamos "olores de IA de GitHub Copilot."
Gracias también a Bruno Belarte, Javier Molina, Javier López, Chris Ford y Paul Sobocinski por sus comentarios en la revisión.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.
