Reflexiones sobre el futuro del desarrollo de software

• Los modelos de lenguaje a gran escala (LLMs) han causado un gran impacto en los campos creativos al permitir generar imágenes, texto y código
• Al principio hubo muchos resultados graciosos, como dibujos con manos humanas mal hechas o afirmaciones incorrectas, pero poco a poco han ido mejorando
• Antes de que aparecieran estos modelos, el principal argumento en contra de la automatización era que las máquinas no podían pensar de forma creativa, pero ahora esa afirmación se está debilitando cada vez más
• ¿Hacia dónde deberíamos ir ahora?

Framework: niveles de capacidad en el desarrollo de software

• El desarrollo de software es mucho más que simplemente escribir código
• La imagen típica del programador es la de alguien en una habitación oscura mirando la computadora y tecleando código intensamente, pero en realidad dedica más tiempo a otras tareas que a escribir código
  • Recopilar requisitos de los usuarios de negocio
  • Refinar esos requisitos para poder modelarlos en código
  • Visualizar soluciones y hacer planes con compañeros de equipo como diseñadores y gerentes de producto
  • Diseñar y refinar aspectos técnicos con otros desarrolladores
  • Configuración de infraestructura, ajustes, boilerplate, etc.
  • Escritura del código propiamente dicho
  • Depuración, comprensión del código de otros, documentación, etc.
  • Despliegue a producción
  • Respuesta a incidentes en producción
  • Y muchas otras tareas
• Decir que "la IA va a reemplazar a los desarrolladores" significa que la IA tendría que ser competente en todas las tareas anteriores
• Pero, viendo la lista anterior, algunas de estas tareas podrían automatizarse en el futuro, mientras que otras todavía parecen difíciles de automatizar

Clasificación de niveles de automatización en autos autónomos

• El sector de los autos autónomos desarrolló una forma de clasificar los niveles de automatización
• Esta clasificación explica con claridad lo que la tecnología actual puede hacer y evita una visión de blanco o negro
• Si aplicamos una clasificación así al desarrollo de software basado en IA
  • El nivel más bajo sería lo que teníamos antes: una etapa en la que la IA no participa en el trabajo. Claro, ya existían otros tipos de automatización, como compiladores y procesos de build, pero eso no era IA, sino automatización determinista escrita por personas
  • El siguiente nivel es lo que tenemos hoy
    • Desarrolladores que reciben apoyo usando ChatGPT o GitHub Copilot
    • Los desarrolladores lo usan para escribir pruebas, código repetitivo, refactorización y para entender código/errores
    • Uno puede conversar con ello como si hablara con otro desarrollador, hacer preguntas y recibir ayuda, pero como no tiene acceso a la computadora, no puede crear archivos, ejecutar comandos de build ni desplegar en producción
  • El nivel más alto sería delegar parte o la totalidad de un proyecto a un "AI coder"
    • Un AI coder recibiría requisitos, escribiría el código, corregiría errores y luego desplegaría el producto final en producción
    • Antes pensaba que aún faltaban algunos meses para que esto ocurriera, pero la demo de Devin mostró que, aunque por ahora solo puede realizar tareas de desarrollo sencillas, existe la posibilidad de que mejore en el futuro Devin, el primer ingeniero de software con IA
• Además de la capacidad de los modelos de IA, también hay que pensar en qué tan correcta es la solución
  • Estos modelos tienden a ser vulnerables a las alucinaciones o a requerir que se les haga prompt de cierta forma para obtener lo deseado
  • Eso genera fricción en la adopción y hace que la mayoría de las personas abandonen a los asistentes de IA en esta etapa
  • Pero esto también está mejorando, y en los modelos más recientes ya no se necesita ese nivel de prompt engineering
• Además, los modelos deberían poder navegar por la web para "aprender", en lugar de depender solo de los datos con los que fueron entrenados
  • Esto es importante a medida que aparecen nuevas versiones de librerías y lenguajes de programación

Framework: desarrollo de software tercerizado

• Ahora que ya construimos un marco de capacidades, ¿qué impacto tendría eso en la estructura de los equipos o de la organización? Las empresas desarrollan software de distintas maneras:
  • Completamente in-house
  • Mayormente in-house con unos pocos vendors
  • Poco in-house con muchos vendors
  • Completamente a cargo de vendors
• Podemos pensar en un AI coder como si fuera un vendor o consultor externo de desarrollo de software
• Es importante que un equipo interno de la empresa supervise el trabajo del vendor
  • Esto podría resolverse por contrato, pero los contratos normalmente solo aplican a un proveedor o proyecto específico, y con ese método no se pueden imponer objetivos de largo plazo
  • Es recomendable tener aunque sea un pequeño equipo interno capaz de guiar al vendor
  • Del mismo modo, incluso si fuera posible rentar AI coders como si fueran instancias EC2, seguiría siendo ventajoso que un equipo interno de desarrolladores supervise ese trabajo

Framework: el desarrollo de software es modelado de complejidad

• Cuando hablamos de resolver problemas de negocio, podemos tomar Excel como ejemplo.
• Excel tiene una barrera de entrada muy baja, así que con él se pueden organizar datos, hacer análisis de datos o automatizar algunos procesos
• Pero no es adecuado para flujos de trabajo de negocio complejos, porque carece de funciones como control de acceso granular, capacidades de integración con sistemas no compatibles, posibilidad de pruebas, reutilización y dependencia de proveedor
• Lo mismo ocurre con soluciones de "low-code" como Power Automate
• "¿Podrían los usuarios de negocio crear estos flujos de trabajo complejos usando un AI coder sin ayuda de desarrolladores de software?"
• Si lo pensamos, Excel y las herramientas low-code existen desde hace décadas, entonces ¿por qué la profesión de desarrollo de software sigue existiendo?
• Es porque se piensa en el desarrollo de software como si fuera solamente escribir código
• Los problemas complejos requieren personas que puedan gestionar esa complejidad de manera efectiva y convertir problemas de negocio del dominio real en modelos digitales
• Dicho de otra manera, que puedas construir un cobertizo de madera viendo tutoriales de YouTube sin ayuda de un ingeniero civil no significa que también puedas, o debas, construir un edificio de 10 pisos de la misma manera
  • Si aprendes gradualmente cómo hacer bien ese trabajo, poco a poco podrías convertirte en ingeniero civil
  • Al final, solo es una cuestión de si vas a invertir tiempo en aprenderlo bien o si vas a contratar a un ingeniero experimentado
• Por eso, ya sea que uses Excel o el AI coder más moderno, si estás modelando lógica compleja, yo diría que sigues siendo desarrollador de software
• Lo que cambia es la herramienta con la que expresas los requisitos del negocio: fórmulas de hoja de cálculo, código, prompts, etc.

Framework: el tamaño del pastel

• La mayor parte de la ansiedad alrededor de este tema parte del supuesto de que el tamaño del mercado del desarrollo de software se mantendrá igual; es decir, que los AI coders irán quitándoles gradualmente "cuota de mercado" a los humanos
• Como el mercado de "resolver problemas de negocio" es mucho más grande que el de desarrollo de software, el desarrollo de software no va a desaparecer pronto

Framework: definición formal de la lógica de negocio

• La lógica de negocio siempre debe definirse en una forma clara y formal
• Por eso los lenguajes de programación, aunque usen palabras en inglés como if o switch, definen de manera muy estricta el significado de esas palabras, y si usas una palabra equivocada no funcionan. Si lo piensas, lo mismo pasa con las fórmulas de Excel o los flujos low-code
• Incluso si en el futuro los AI coders pudieran crear productos de software a partir de instrucciones dadas en inglés conversacional, creo que seguirá existiendo una definición formal subyacente de la lógica de negocio que se genera en el backend
• Puede verse muy diferente de los lenguajes o frameworks que usamos hoy, pero la definición formal de la lógica de negocio sigue sonando muy parecida al "código"
• Hasta que un AI coder pueda generar esa lógica de negocio de forma determinista a partir de inglés conversacional, seguirá haciendo falta alguien que pueda entender el código generado en el backend y modificarlo cuando sea necesario. Ese alguien es el desarrollador de software

Conclusión

• La naturaleza del trabajo va a cambiar y las herramientas que usemos serán muy distintas a las actuales, pero creo que en el futuro cercano seguirá existiendo un mercado para los desarrolladores de software

[xguru]

Devin, el primer ingeniero de software con IA
OpenDevin - implementación de código abierto de Devin, el ingeniero de software con IA

[dhlee0305]

Incluso antes de que OpenAI se hiciera tan conocido, al ver cómo la IA expande su alcance desde las artes —que se consideraban uno de los campos donde su adopción sería la más tardía o incluso imposible—, de pronto pensé que las cosas que hoy creemos que solo los "humanos" pueden hacer quizá no sean tan "seguras".

[edunga1]

Como en el texto principal y en la publicación https://es.news.hada.io/topic?id=13557,
está claro que la porción del trabajo para los desarrolladores va a reducirse ahora, y eso se acelerará aún más, ¿no?

[ahwjdekf]

A medida que la importancia de los prompts de IA se vuelve cada vez más evidente, probablemente más usuarios tomarán conciencia de que definir especificaciones y organizar requisitos con mayor claridad es indispensable, y eso al final podría jugar a favor de los desarrolladores en la forma en que trabajen en el futuro.

[colus001]

Creo que el código es para las personas, y que si las máquinas escriben código, eso significa que las personas siguen siendo necesarias, así que no me parece que esa sea la dirección del desarrollo en un futuro lejano. Pienso que evolucionará hacia una forma en la que lancemos la consulta que queremos a una especie de caja negra, como el backend-GPT que se experimentó al principio (https://github.com/RootbeerComputer/backend-GPT), esta acceda a la base de datos y procese los datos, mientras que en la experiencia antes y después de eso las personas intervengan parcialmente.

[kaistj]

Parece que, entre las muchas cosas que se comentan sobre ChatGPT y Copilot, se menciona bastante la ingeniería de prompts. También creo que un factor importante es cómo transmitirnos y comunicarnos de forma eficiente con un codificador de IA en esos procesos que solemos hacer para programar: reunirnos, comunicarnos rápidamente con palabras, organizar ideas y luego confirmarlas ^^.

[vbmania]

> “La IA reemplazará a los desarrolladores” significa que la IA tendría que ser competente en todas las tareas mencionadas arriba.

-> Creo que podrían ser procedimientos necesarios porque los hace una persona y que, al final, cuando se pasan por todos esos pasos, el resultado en forma de código puede tener ciertos patrones. Es como en el baduk, donde se pensaba que hacían falta cosas como las aperturas o las jugadas estándar, pero al final se demostró que eso no era más que un método inevitable para procesar información dentro del ámbito cognitivo humano.