Podcast: Superar el revuelo sobre las herramientas de desarrollo de IA

Ayudar al desarrollo con herramientas de inteligencia artificial puede ser un tema decisivo. Algunas personas piensan que reemplazarán completamente a los desarrolladores, otras piensan que no pueden producir código lo suficientemente bueno como para ser útil y muchas personas se quedan en algún punto intermedio. Dado el interés por este tipo de herramientas en los últimos años, en el último episodio de nuestro podcast hablamos con Phillip Carter, director de producto principal de Honeycomb, sobre su opinión sobre ellas. Él cree que, en general, estas herramientas pueden ser útiles, pero solo si puede limitar su uso, tener el nivel adecuado de experiencia para verificar el resultado y establecer expectativas realistas sobre lo que pueden hacer por usted. La siguiente es una versión abreviada de la conversación. SD Times: ¿Crees que estas herramientas de IA son buenas o malas para los equipos de desarrollo? Phillip Carter: Yo diría que me inclino hacia lo bueno y lo mejor a lo largo del tiempo. Depende de un par de factores diferentes. Creo que el primer factor es la antigüedad. Las herramientas que tenemos hoy son las peores versiones de estas herramientas que usaremos en la próxima década. Es algo así como cuando aparecieron los servicios en la nube en 2010, 2011, y su uso tenía claros beneficios. Pero en muchos casos de uso, estos servicios simplemente no resolvieron muchos de los problemas que tenía la gente. Y así, durante varios años, hubo muchos comentarios de «oye, esto podría ser realmente útil» y finalmente estuvieron a la altura de esas aspiraciones. Pero él no estaba allí en ese momento. Creo que para los desarrolladores de ayuda, estos modelos de IA se encuentran en ese punto en este momento, donde hay algunos casos de uso más específicos en los que funcionan bastante bien, y luego muchos otros casos de uso en los que no funcionan del todo bien, y puede ser activamente engañoso. Entonces, lo que hagas realmente depende del tipo de desarrollador que seas, ¿verdad? Si acabas de salir de la universidad o todavía estás aprendiendo a codificar y no eres un verdadero experto en desarrollo de software, la naturaleza engañosa de estas herramientas puede ser bastante dañina, porque realmente no tienes la imagen completa. Mucha experiencia y una especie de intuición sobre lo que está bien o mal con lo que compararlo. Mientras que si eres un ingeniero con más experiencia, puedes decir, bueno, ya he visto la forma del problema. Y este código que escupió parece ser mayoritariamente correcto. Y hay mucha utilidad, como crear algunas pruebas y asegurarse de que sean válidas, y en ese sentido ahorra tiempo. Pero si no tienes esa sensación de que está bien, así es como voy a verificar que en realidad sea correcto, así es como voy a comparar lo que veo con lo que he visto en el pasado, para que puede ser realmente difícil. Y hemos visto casos en los que algunos ingenieros jóvenes en particular han tenido dificultades para resolver problemas, porque lo intentan y no lo logran, lo intentan de nuevo y no lo logran del todo. Y pasan más tiempo haciendo eso que simplemente sentados y pensando en el problema. Uno de los ingenieros más jóvenes de nuestra empresa se apoyó en estas herramientas al principio y se dio cuenta de que eran un poco engañosas y se alejó para desarrollar algo de su propia experiencia. Y luego volvieron a usar algunas de esas herramientas, porque descubrieron que todavía eran útiles, y ahora que tenían más instinto para saber qué era bueno y qué era malo, podían usar algunas más. Es genial cuando sabes cómo usarlo y sabes compararlo con cosas que sabes que son buenas o malas. Pero si no lo hace, esencialmente habrá agregado más caos al sistema del que debería haber habido. SDT: ¿En qué momento de su carrera un desarrollador debería sentirse con la experiencia suficiente para utilizar estas herramientas de forma eficaz? PC: El ejemplo más obvio que me viene a la mente es escribir casos de prueba. Existe el entendimiento de que ese es un dominio al que puedes aplicarlo incluso cuando eres un poco más joven en tu carrera. Las cosas pasarán o fracasarán, y puedes mirarlas y pensar: ¿deberían haber pasado? ¿O debería haber fracasado? Es una señal muy clara. Mientras que si lo estás usando para editar código más sofisticado dentro de tu código base, es como, bueno, no estoy realmente seguro de si está haciendo lo correcto, especialmente si no tengo una buena prueba que valide que debería ser así. haciendo lo correcto. Y ahí es donde entra en juego la antigüedad y simplemente una mayor experiencia de vida en la creación de software, porque puedes tener esa sensación mientras lo estás creando, y no necesitas recurrir a un conjunto de pruebas sólido que realmente compruebe si lo estás haciendo. Lo correcto. La otra cosa que diré es que he visto a varios ingenieros jóvenes prosperar bastante con estas herramientas. Porque en realidad no se trata de ser junior, es solo que algunos ingenieros son mejores leyendo y comprendiendo el código que escribiéndolo. O tal vez sean buenos en ambas cosas, pero su superpoder es mirar el código, analizarlo y ver si hará el trabajo que se supone que debe hacer. Y eso realmente empuja el cuello de botella en esa dirección. Porque si te imaginas por un momento, digamos que eran perfectos generando código. Bueno, ahora el cuello de botella está enteramente en entender ese código, realmente no tiene nada que ver con escribir el código en sí. Y muchas más personas jóvenes en sus carreras pueden prosperar en ese entorno, si escribir código es un cuello de botella para ellos. Pero si son realmente buenos entendiendo cosas y leyéndolas, entonces pueden decir que esta cosa realmente hace las cosas más rápido. Y casi pueden usarlo para generar diferentes variaciones de cosas y leer el resultado y ver si realmente hace lo que se supone que debe hacer. Entonces, no sé si esto es necesariamente algo que sea universal para todos los ingenieros e ingenieros junior, pero si tienes esa mentalidad en la que eres realmente bueno leyendo y comprendiendo código, puedes usar estas herramientas para obtener una ventaja significativa hoy. y sospecho que mejorará con el tiempo. SDT: Entonces, incluso para los desarrolladores más experimentados (o desarrolladores junior que tienen una habilidad especial para leer y comprender el código), ¿hay formas en las que se podría abusar de estas herramientas de manera negativa? ¿Qué mejores prácticas deberían implementar los equipos para asegurarse de no depender demasiado de estas herramientas de IA? PC: Entonces, hay un par de cosas que pueden suceder. He hecho esto antes, otras personas en el equipo también lo han hecho, lo han usado y han hojeado las sugerencias y demás, y luego dicen, espera un minuto, sería Habría sido más rápido si lo hubiera escrito yo mismo. Esto sucede de vez en cuando, en realidad no sucede con tanta frecuencia, pero puede suceder. Y hay algunos casos en los que el código que tienes que escribir es, por alguna razón, demasiado complicado para el modelo. Puede que no sea necesariamente un código súper complicado conceptualmente, es solo que podría ser algo en lo que el modelo en este momento no es particularmente bueno. Entonces, si reconoces que está publicando algo que te preocupa y dices: «Realmente no estoy de acuerdo con esa sugerencia», generalmente es una buena señal de que no debes confiar demasiado en eso en este momento. tiempo. Existe el modelo ChatGPT en el que dices que quieres algo y se genera como un bloque completo de código, lo copias y pegas o haces algo. Este es un modelo. El otro patrón que creo que es más efectivo en el que la gente se apoya más y que, francamente, es más útil es el patrón de finalización en el que en realidad todavía estás escribiendo el código, pero como una sola línea por línea. da una sugerencia. A veces este consejo es una locura, pero normalmente es bastante bueno. Y todavía tienes un poco más de control y no estás simplemente copiando y pegando ciegamente grandes bloques de código sin siquiera leerlo. Y entonces creo que en términos de selección de herramientas, las que están profundamente arraigadas en la escritura del código conducirán a una comprensión mucho más efectiva de lo que está sucediendo, en comparación con las herramientas que simplemente producen grandes bloques de código que usted copia. y pegar. Y esperas que funcione. Creo que las organizaciones deberían centrarse en esto, en lugar de en herramientas de codificación de IA que apenas funcionan. Y tal vez mejore con el tiempo, pero definitivamente no es algo de lo que las organizaciones deban depender. Hay otro modelo de trabajo con estas herramientas que se está desarrollando ahora mismo, también desde GitHub, que creo que podría ser prometedor. Es a través de su producto llamado GitHub Copilot Workspace. Básicamente, se comienza con una tarea de lenguaje natural y luego se produce una interpretación de esa tarea de lenguaje natural. Y te pide que valides algo como: «Oye, ¿es esta la interpretación correcta de lo que debo hacer?». Y luego puedes agregar más pasos y más interpretaciones secundarias y modificarlo. Y luego da el siguiente paso y genera una especificación de trabajo. Y luego dices, está bien, ¿estoy de acuerdo con las especificaciones del trabajo o no? Y realmente no puedes continuar a menos que lo edites o digas «sí, eso se ve bien». Y luego dice: «Está bien, he analizado tu código base. Y estos son los archivos que quiero tocar. Entonces, ¿son estos los lugares correctos para buscar? ¿Me estoy perdiendo algo?». En cada paso del camino, usted interviene y tiene la oportunidad de apreciarlo, no estar de acuerdo y pedirle que genere algo nuevo. Y al final devuelve un bloque de código como diferencia. Entonces dirán: «Oye, esto es lo que creemos que deberían ser los cambios». Lo que me encanta de ese modelo, en teoría, y lo he usado en la práctica, es que funciona. En realidad, simplemente dice que el desarrollo de software no se trata solo de código, sino de comprender tareas. Se trata de interpretar las cosas. Se trata de revisar los planes. Se trata de crear una especificación formal de las cosas. A veces se trata de comprender dónde hay que trabajar. Porque si soy honesto, no creo que estos agentes automatizados vayan a ninguna parte en el corto plazo, porque el espacio en el que intentan operar es muy complicado y es posible que tengan un lugar para pequeñas tareas a las que hoy la gente recurre. como Upwork, pero, por ejemplo, reemplazar equipos de ingenieros que realmente resuelven problemas comerciales reales que son complicados y llenos de matices, simplemente no lo veo. Y entonces siento que concentrarme en eso es casi una distracción. Y las cosas impulsadas por IA pueden ser realmente útiles, pero deben centrarse en mantener al equipo de desarrollo involucrado todo el tiempo y permitirles usar su cerebro para impulsar estas cosas de manera efectiva. SDT: ¿Alguna idea final o conclusión de este episodio? PC: Yo diría que las herramientas no son mágicas, no creas en las exageraciones. El marketing es exagerado para lo que estas cosas pueden hacer. Pero cuando superas todo eso, y especialmente si limitas tus tareas a cosas pequeñas y muy concretas, estas herramientas pueden ser realmente maravillosas para ayudarte a ahorrar tiempo y, a veces, incluso considerar enfoques para cosas que tal vez no hayas considerado en el pasado. proyecto. pasado. Así que concéntrate en eso, elimina la exageración, simplemente piensa en ello como una buena herramienta. Y si no es una buena herramienta para ti, deséchala, porque no te será útil. Probablemente eso es lo que recomendaría a cualquiera, en cualquier capacidad, para enmarcar estas cosas.

About Francisco

Check Also

Factores de aprendizaje que impactan los costos de desarrollo de aplicaciones POS

Las aplicaciones POS han transformado en gran medida el comercio minorista al combinar conveniencia y …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *