|
He probado con un cliente una IA específicamente enfocada al desarrollo de software. Esta IA se llama Aider, es para hacer pair programming usando una IA desde el terminal. En realidad no es una IA, sino una herramienta que se comunica con una IA. En su web dicen que funciona mejor con GPT-4o & Claude 3.5 Básicamente, extiende funcionalidad de una IA. Puede analizar pull request desde los ángulos que le digas, sugerirte mejoras, incluso aplicarlas, modificando código en vivo, haciendo commits y push en el pull request actual o crear uno nuevo con las mejoras sugeridas. Es ir un paso más allá de GitHub copilot. Mi cliente me enseño un análisis que hizo Aider de un pull request que había realizado yo. Me quedé muy sorprendido con el análisis. Ver en palabras de la IA un estilo de desarrollar que tengo tan interiorizado al programar es alucinante. Ahora lo entenderás. En el análisis aparecían frases como: - Clara separación entre lógica de UI y lógica de negocio
- Reduce duplicación de código a través de componentes reutilizables
- Uso apropiado del patrón view model
Y también proponía mejoras: - Considera añadir test unitarios para los nuevos componentes de UI usando Compose.
- La documentación para los nuevos componentes puede ser mejorada.
- Estas funciones del activity X pueden ser optimizadas.
Partimos de este punto y le dijimos que creara un pull request nuevo para cada una de las mejoras. Teniendo el editor de código abierto fue increíble ver como iba escribiendo código solo en el propio proyecto. Analizando los 3 pull request por separado, solo aprobamos el de la documentación. Te explico. En el de añadir los test unitarios, no entendió el sistema nuevo de Android de añadir dependencias y las añadió de la forma antigua harcodeando la versión de cada la librería. Además, añadió dependencias que ya existían. En el de las funciones a optimizar, le recomendé al cliente no aprobarlo. El contexto es importante y el propietario de esta aplicación es otra empresa. La aplicación es open source, mi cliente tiene un fork y yo hago personalizaciones para mi cliente. El código que la IA quería optimizar no era código escrito por mí, sino código escrito por la empresa propietaria. Cada nueva versión que sacan, tengo que traerme los cambios y resolver conflictos. Es un trabajo tedioso, a veces según los cambios que añadan. Si aprobábamos ese pull request en el repositorio de mi cliente, era un conflicto seguro a resolver en el futuro por un código que no necesitaba ser personalizado para mi cliente. Algo que sí podríamos hacer es crear un pull request en el repositorio original, no en el fork. Al acabar la reunión mi cliente me dijo que le había servido de mucho. Había entendido perfectamente que pese a tener esta herramienta de IA un potencial increíble, está mejor en mis manos que en las suyas. Él no tiene todo contexto, ni conocimiento sobre el código para poder decidir si lo que le indica la IA es bueno, definitivo o hay que descartarlo. Como digo siempre, es más importante que nunca formarse. Quien mejor va a sacar todo el potencial a la IA es quien realmente sabe sobre lo que pide. Es necesario tener criterio sobre lo que devuelve la IA para iterar o descartar. La IA es una bomba en los dos sentidos. En las manos adecuadas puedes hacer cosas muy buenas y muy rápido. En las manos equivocadas puedes hacer cosas muy mal y muy rápido también. Por cierto, voy a sacar un nuevo formato de curso que he llamado master class. Pero de eso ya te hablo la semana que viene. Ya sabes que, de momento, he dejado las ediciones en directo de la formación Clean Architecture. Estoy recibiendo peticiones para hacer una edición en abierto. Si hay la suficiente gente apuntada a la lista de espera, es posible que haga una edición próximamente. Lista de Espera Pd: Si te gustan mis emails, habla bien y comparte xurxodev.com para que otros lo disfruten. Pd2: Si no te gustan mis emails, habla mal y comparte xurxodev.com para evitar que otros lo sufran.
|