Después de 6 meses de trabajar en una herramienta de desarrollo CodeGen (piloto GPT), esto es lo que aprendí

Durante los últimos 6 meses, he estado trabajando en GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ) para comprender cuánto podemos automatizar realmente la codificación con IA, así que quería compartir nuestros aprendizajes. hasta ahora y hasta dónde es capaz de llegar.

Cuando comencé a construir GPT Pilot, escribí esta publicación de blog sobre cómo se concibe. Ahora quiero compartir mi pensamiento revisado y analizar lo que funcionó y lo que no funcionó.

Finalmente, verá ejemplos de aplicaciones creadas con GPT Pilot y cómo puede crear una aplicación con un programador de pares de IA real .

¿Cuál es la idea detrás de GPT Pilot?

GPT Pilot está concebido como un desarrollador de IA real, no un autocompletado ni un chatbot . Más bien, es un desarrollador quien crea un plan sobre cómo se debe construir su aplicación o función y comienza a codificar. Quiere hacer la mayor parte de la codificación por sí mismo, pero cuando se atasca, necesita una aclaración sobre los requisitos dados o requiere una revisión del código, le pide ayuda.

¿Es la IA como un desarrollador junior? O…

A menudo veo herramientas basadas en CodeGen GPT-4 que dicen que están creando un desarrollador junior de IA.

De alguna manera, siempre he tenido un problema con eso porque cuando uso ChatGPT para codificar, me da respuestas e ideas que solo una persona con un nivel muy alto podría darme, algo que ningún desarrollador junior sería capaz de comprender. Aún así, ningún LLM puede crear una aplicación tan bien como lo puede hacer un desarrollador senior, pero el conocimiento que tiene GPT-4 sobre codificación va mucho más allá de cualquier desarrollador junior.

Yo diría que GPT-4 tiene tanto conocimiento sobre cada parte del desarrollo de software como si fuera el desarrollador más veterano del mundo pero con la memoria de un pez dorado. Lo imagino como un robot sobrehumano que simplemente se encuentra en medio de una habitación y sólo puede realizar una pequeña acción a la vez, pero no puede combinar muchas acciones y trabajar de forma repetitiva. Debe decirle exactamente qué debe hacer a continuación.

Esto es lo que buscamos con GPT Pilot: queremos crear un marco de pensamiento para el LLM que haga que ese robot sobrehumano trabaje continuamente revisando sus acciones anteriores, tenga un ciclo de retroalimentación y determine qué debe hacer a continuación en orden. para lograr el objetivo final, que es crear una aplicación lista para producción.

En la publicación del blog que mencioné anteriormente , describí los pilares principales sobre los que se construyó GPT Pilot. Pero estos han cambiado un poco según lo aprendido por nuestro equipo, por lo que aquí están los pilares revisados:

1. Se necesita un ser humano para supervisar la IA no sólo porque la IA no es lo suficientemente buena, sino también porque es posible que desees cambiar la forma en que funciona o se ve algo después de su implementación. Es común que un desarrollador o gerente de producto, una vez que ve cómo se ve una implementación, decida cambiarla.

   
   

2. O se da cuenta de que hay más casos extremos de los que anticipó inicialmente y cree que es más fácil refactorizar su implementación actual que solucionar todos los problemas. El problema es cuando terminas toda la aplicación y luego intentas refactorizarla; aquí es cuando se vuelve mucho más difícil porque cada cambio afectará todas las demás funciones.

   
   

   Por otro lado, si realiza la refactorización antes de confirmar los cambios, podrá continuar con las siguientes funciones además de un código bien escrito. Por eso es crucial que un desarrollador de IA tenga un ser humano informado cada vez que se implementa una tarea .

   
   

   De esta manera, el humano puede revisar la implementación de cada tarea (como una revisión de código antes de fusionar un PR) antes de que GPT Pilot continúe con la siguiente tarea. Si un humano le dice a GPT Pilot qué está mal, será mucho más fácil solucionar los problemas dentro de la tarea misma. Al mismo tiempo, el LLM tiene el contexto de lo que se debe hacer en la tarea y lo que se ha hecho hasta ahora.

   
   

3. La IA puede repetir sus propios errores. Tengo la sensación de que mucha gente juzga la capacidad de ChatGPT para escribir código por lo bien que funciona la primera vez que le pides que codifique algo. Si no produce código que funcione, muchos pensarán que no es impresionante. En realidad, los humanos casi nunca escriben código funcional en el primer intento . En su lugar, escribe código, lo ejecuta, ve los errores y lo itera. Esto es exactamente lo que GPT Pilot le permite hacer a GPT-4: después de escribir el código, GPT Pilot puede ejecutar el código, tomar el resultado y preguntarle al LLM si el resultado es correcto, si se debe arreglar algo y, de ser así, cómo. .

   
   

4. El desarrollo de software se puede orquestar . Hay muchas rutinas repetitivas por las que pasan todos los desarrolladores al crear una aplicación. Una de las rutinas puede ser: escribir código, ejecutarlo, leer los errores, cambiar el código, volver a ejecutarlo, etc. Otra de nivel superior puede ser: tomar una tarea, implementarla, probar la implementación (repetir hasta que pasen todas las pruebas). , envíelo para revisión, solucione los problemas (repita hasta que el revisor lo apruebe) e impleméntelo. Muchas de estas rutinas se pueden orquestar si contamos con una persona inteligente que toma decisiones (como un LLM).

   
   

5. El proceso de codificación no es una línea recta . Cuando creamos la primera versión de GPT Pilot, pensamos que sería necesario iterar sobre tareas, implementar código, arreglarlo y seguir adelante. En realidad, no progresas continuamente al codificar una aplicación: reescribes tu código todo el tiempo.

   
   

   A veces, refactorizas el código base porque, después de la implementación inicial, te das cuenta de que hay una mejor manera de implementar algo. Otras veces lo haces por un cambio de requisitos. Como mencioné en el punto 1, después de ver que una solución no funciona, a veces es necesario revertir una serie de cambios, pensar en una solución alternativa al problema e intentar resolverlo de esa manera.

   
   

   Para que GPT Pilot, o cualquier otro desarrollador de IA, funcione a escala, necesita tener un mecanismo que le permita retroceder, elegir una ruta alternativa y volver a implementar una tarea.

¿Qué aprendimos?

Los LLM, en general, son una nueva tecnología que todo el mundo intenta comprender: cómo funciona, qué se puede hacer mejor, cómo realizar una ingeniería rápida adecuada, etc. Nuestro enfoque es centrarnos en construir la capa de aplicación en lugar de trabajar en conseguirla. LLM para obtener mejores resultados .

El razonamiento es que los LLM mejorarán y, si pasamos semanas optimizando un mensaje, es posible que se resuelva por completo con la nueva versión de GPT.

En cambio, nos centramos en cómo debería ser la experiencia del usuario y qué mecanismos se necesitan para controlar el LLM para permitirle funcionar continuamente, acercándonos cada vez más a la solución final. Entonces, aquí están nuestros aprendizajes hasta ahora:

1. La descripción inicial de la app es mucho más importante de lo que pensábamos . Nuestra idea original era que, con la aportación humana, GPT Pilot podría navegar en la dirección correcta y acercarse cada vez más a la solución funcional, incluso si la descripción inicial era vaga.

   
   

   Sin embargo, el pensamiento de GPT Pilot se ramifica a lo largo de las indicaciones, comenzando con la descripción inicial. Y con eso, si algo es engañoso en el mensaje inicial, toda la demás información que tiene GPT Pilot conducirá en la dirección equivocada. Entonces, cuando lo corrijas en el futuro, estará tan profundamente en esta forma incorrecta que será casi imposible llevarlo al camino correcto.

   
   

   Ahora, mientras escribo esto, parece muy obvio, pero eso es algo que necesitábamos aprender: centrarnos mucho más en la descripción inicial. Por eso, creamos un nuevo agente llamado "Spec Writer", que trabaja con usted para desglosar los requisitos del proyecto antes de comenzar a codificar.

   
   

2. La codificación no es una línea recta . Como mencioné anteriormente en la sección de pilares, la refactorización ocurre todo el tiempo y GPT Pilot también debe hacerlo. Aún no hemos implementado una solución para esto, pero probablemente funcionará agregando la capacidad de GPT Pilot de crear marcadores alrededor de su árbol de decisiones para que, cuando algo no funcione, pueda revisar los marcadores y pensar dónde podría haberlo hecho. hice un mal giro.

   
   

3. Los agentes pueden revisarse ellos mismos . Mi pensamiento fue que si un agente revisa lo que hizo el otro agente, sería redundante porque es el mismo LLM reprocesando la misma información. Pero resulta que cuando un agente revisa el trabajo de otro agente, funciona sorprendentemente bien. Contamos con 2 agentes "Revisores" diferentes que revisan cómo se implementó el código.

   
   

   Uno lo hace en un nivel alto, como cómo se implementó toda la tarea, y otro revisa cada cambio antes de realizarlo en un archivo (como hacer git add -p).

   
   

4. Los LLM funcionan mejor cuando pueden centrarse en un problema en comparación con varios problemas en una sola indicación. Por ejemplo, si le dice a GPT Pilot que realice 2 cambios diferentes en una sola descripción, tendrá dificultades para concentrarse en ambos. Entonces, dividimos cada entrada humana en varias partes en caso de que la entrada contenga varias solicitudes diferentes.

   
   

5. Los registros detallados ayudan . Esto es muy obvio ahora, pero inicialmente no le dijimos a GPT-4 que agregara ningún registro alrededor del código. Ahora, crea código con registro detallado, de modo que cuando ejecute la aplicación y encuentre un error, a GPT-4 le resultará mucho más fácil depurar cuando vea qué registros se han escrito y dónde están esos registros en el código.

   
   

6. Dividir el código base en archivos más pequeños ayuda mucho . Ésta también es una conclusión obvia, pero teníamos que aprenderla. Es mucho más fácil para GPT-4 implementar funciones y corregir errores si el código se divide en muchos archivos en lugar de en unos pocos grandes. Tal como pensamos los humanos: es mucho más fácil procesar fragmentos de código más pequeños que grandes. Lo hacemos creando niveles de abstracción: funciones, clases, etc.

   
   

   Una de las formas más sencillas de lograr que el LLM cree una abstracción más manejable es simplemente decirle que cree más código modular y lo divida en más archivos. Funciona increíblemente bien y el resultado final también es mejor para nosotros, los desarrolladores.

   
   

7. Para que un humano pueda corregir el código, se le debe mostrar claramente lo que estaba escrito en la tarea y la idea detrás de ella . El objetivo de GPT Pilot es realizar el 90% de todas las tareas de codificación y dejar el otro 10% a un humano. Este 10% generalmente comprende correcciones o pequeños cambios que al LLM le cuesta notar, pero para el ser humano, podría ser un cambio simple.

   
   

   Sin embargo, el problema es que no es fácil decirle al humano qué no funciona y qué código debe mirar. Si GPT Pilot escribe 3000 líneas de código, el desarrollador humano, si quiere ayudar a GPT Pilot, debe comprender todo el código base antes de sumergirse en el código real.

   
   

   En versiones futuras de GPT Pilot, el desarrollador humano tendrá una explicación detallada de qué código se ha agregado a la tarea actual y el razonamiento detrás de ello. De esta manera podrás ayudar a GPT Pilot.

   
   

8. Los humanos somos vagos . Es mejor que los LLM hagan preguntas a los humanos en lugar de dejar que los humanos piensen en todos los errores posibles. Nuevamente, es muy obvio mirando hacia atrás, pero una de las cosas que notamos fue que las personas estaban mucho más dispuestas a responder las preguntas que les hacía GPT Pilot en lugar de tener un campo de entrada abierto donde podían escribir comentarios sin restricciones.

   
   

9. Es difícil lograr que un LLM piense fuera de lo común . Este fue uno de los mayores aprendizajes para mí. Pensé que podrías avisar a GPT-4 dándole un par de soluciones que ya había utilizado para solucionar un problema y decirle que pensara en otra solución. Sin embargo, esto no es tan fácil como parece.

   
   

   Lo que terminamos haciendo fue pedirle al LLM que enumerara todas las posibles soluciones que se le ocurrieron y las guardara en la memoria. Cuando necesitábamos probar algo más, buscábamos soluciones alternativas y le decíamos que probara una solución diferente, pero específica.

Aplicaciones creadas con GPT Pilot

Actualmente, puedes crear aplicaciones simples pero no triviales con GPT Pilot. También hemos visto a personas crear aplicaciones con GPT Pilot que son muy impresionantes, como una aplicación que puede ajustar un modelo ResNet para contar palmeras y luego, cuando cargas una imagen, contar los árboles que contiene. Aquí hay un par de aplicaciones que creamos, junto con el código, las estadísticas y las demostraciones:

Laboratorio rápido ( DEMO )

Piense en esto como OpenAI Playground con esteroides: le permite cargar una conversación desde una matriz JSON o ingresarla manualmente, ejecutar la conversación con el LLM X varias veces, guardar la conversación en la base de datos y volver a cargarla. De hecho, usamos esta aplicación cuando diseñamos un mensaje y queremos ver cómo se comporta.

Playground no es lo suficientemente bueno porque lleva mucho tiempo volver a ejecutar un solo mensaje repetidamente. Con Prompt Lab, puede elegir cuántas veces ejecutarlo y dejar que la aplicación ejecute el mensaje repetidamente.

Una vez terminado, puedes analizar los resultados. Esto podría resultar útil para las personas que están creando una aplicación de IA y necesitan optimizar sus indicaciones.

• ⏳ Tiempo empleado: ~2 días
• 💾 Repositorio de Github

Herramienta de análisis de bases de datos SQLite ( DEMO )

Esta también es una aplicación que usamos internamente para analizar una base de datos SQLite local. Extrae los datos de la base de datos en un formato que es muy específico de la estructura de la base de datos de GPT Pilot, pero se puede modificar fácilmente para adaptarse a otras estructuras.

Lee y carga su base de datos SQLite, divide las filas por un campo específico, descomprime las filas en valores, carga los datos de la conversación LLM en un formulario y le permite simplemente cambiar uno de los mensajes y enviar la solicitud LLM a GPT-4. para ver cómo se verán los resultados.

De esta manera, puede analizar las conversaciones que los agentes de GPT Pilot tienen con el LLM y explorar fácilmente qué pasaría si las indicaciones fueran diferentes.

• ⏳ Tiempo empleado: ~2 días
• 💾 Repositorio de Github

Susurrador de códigos ( DEMO )

Code Whisper es un proyecto divertido que creamos como ejemplo para mostrar. La idea es que puedas usarlo para hacer preguntas al LLM sobre tu código base. Pegas el enlace a un repositorio público de Github.

Luego, clona el repositorio, envía los archivos relevantes al LLM para su análisis, que crea una descripción para cada archivo sobre lo que hace el código y guarda esas descripciones en la base de datos.

Después de eso, puede hacerle preguntas a la aplicación sobre el código base, y el código base le mostrará la respuesta. En esta demostración, utilizamos GPT-3.5.

• ⏳ Tiempo empleado: 7 horas
• 💾 Repositorio de Github

Historia de las estrellas ( DEMO )

He estado lanzando proyectos de código abierto durante años y siempre quise ver qué tan rápido está creciendo mi repositorio de Github en comparación con otros repositorios exitosos en https://star-history.com/ . El problema es que en Star History no puedo hacer zoom en el gráfico, por lo que un nuevo repositorio que tiene 1000 estrellas no se puede comparar con un repositorio grande que tiene 50 000 porque no se puede ver cómo le va al repositorio más grande al principio. .

Entonces, le pedí a GPT Pilot que creara esta funcionalidad. Extrae repositorios de Github para observadores de estrellas, los guarda en la base de datos, los traza en un gráfico y permite acercar y alejar el gráfico.

• ⏳ Tiempo empleado: 6 horas
• 💾 Repositorio de Github

Conclusión

Espero que haya obtenido una idea del estado actual, los problemas y los hallazgos que abordamos en GPT Pilot.

Entonces, para resumir:

Creemos que una verdadera herramienta de desarrollo de IA debería basarse en los siguientes pilares:

• Se necesita un humano para supervisar la IA.

  
  

• Deberíamos permitir que la IA repita sus propios errores.

  
  

• El desarrollo de software se puede orquestar , lo que debe implementarse en una capa superior a los LLM.

  
  

• El desarrollador de IA debería poder refactorizar el código base porque, en realidad, el proceso de codificación no es una línea recta.

Hasta ahora hemos aprendido que:

1. La descripción inicial de la aplicación es mucho más importante de lo que pensábamos

2. La codificación no es una línea recta, los agentes pueden revisarse ellos mismos

3. Los LLM funcionan mejor cuando se centran en un problema en comparación con varios problemas en un solo mensaje

4. Los registros detallados hacen milagros

5. Dividir el código base en archivos más pequeños ayuda mucho

6. Para que un humano pueda arreglar el código

7. Se les debe mostrar claramente lo que se ha escrito y la idea detrás de ello.

8. los humanos son vagos

9. Es difícil lograr que el LLM piense fuera de la caja

   
   

¿Qué opinas? ¿Ha notado alguno de estos comportamientos en sus interacciones con los LLM o tiene una opinión diferente sobre alguno de ellos?

Me encantaría saber de usted, así que deje un comentario a continuación o envíeme un correo electrónico a [email protected] .

Puedes intentar crear una aplicación con IA con GPT Pilot aquí:

• Repositorio de código abierto de GPT Pilot
• Extensión del código GPT Pilot VS

Si te gustó esta publicación, significaría mucho que destacaras el repositorio GPT Pilot Github y, si lo pruebas, cuéntanos lo que piensas. Sus comentarios son realmente importantes para todo el equipo piloto de GPT.

También publicado aquí