Ideas
La IA y la bala de plata: ¿qué nos falta todavía?
Desarrollar software es difícil. Podemos tener los mejores desarrolladores del mundo, los mejores procesos de desarrollo, las mejores herramientas de programación, un aseguramiento de calidad riguroso y sofisticados pipelines de CI/CD, y seguirá siendo difícil.
Esto es así por la naturaleza del software, por su esencia. Necesitamos entender qué debe hacer el software, cómo deben funcionar sus muchas partes junto con los procesos de negocio y cómo encajará en el mundo y la cultura que lo rodean. También necesitamos definir cómo se pondrá en producción, cómo se adoptará y cómo se usará para lograr los resultados esperados.
La IA está haciendo partes de este trabajo notablemente más fáciles. Después de construir aplicaciones con ella yo mismo, las posibilidades me entusiasman. Sin embargo, la experiencia me lleva una y otra vez a una pregunta que exploré en 2011: ¿encontramos por fin la bala de plata del desarrollo de software?
Llevamos mucho tiempo eliminando obstáculos
Fred Brooks examinó esta pregunta en “No Silver Bullet—Essence and Accidents of Software Engineering”, publicado en Computer en 1987, después de su primera aparición en 1986.¹ La metáfora era memorable: un proyecto de software aparentemente sencillo podía convertirse en un hombre lobo de plazos incumplidos, costos crecientes y resultados decepcionantes. La industria seguía buscando una bala de plata: un avance capaz de producir mejoras extraordinarias en productividad, confiabilidad y simplicidad.
Brooks distinguía entre las dificultades accidentales, asociadas a cómo producimos el software, y las dificultades esenciales, inherentes a lo que intentamos construir. Mejores herramientas podían eliminar una cantidad considerable de trabajo accidental sin eliminar la complejidad del problema esencial de fondo.¹
En mi artículo de 2011, me pregunté si la plataforma como servicio (PaaS) podría ser ese avance. PaaS y otras plataformas en la nube simplificaron la gestión de la infraestructura y la puesta en producción. Las herramientas de desarrollo visual ofrecían otra posibilidad prometedora: acercar a quien entendía la necesidad del negocio a la construcción de la aplicación. Estos avances eliminaron obstáculos importantes. Aun así, nos dejaron con preguntas fundamentales sobre qué debía lograr la aplicación y cómo debía funcionar.
Hoy, la IA ha hecho que esa conexión entre entender una necesidad y construir una solución sea mucho más tangible para mí, ¡y mucho más crítica de resolver!
¿Qué pasa con la complejidad esencial?
Brooks identificó cuatro características detrás de las dificultades esenciales del software: complejidad, conformidad, mutabilidad e invisibilidad. Ofrecen una forma útil de examinar qué nos ayuda a resolver la IA y qué sigue pendiente.
La complejidad proviene de las muchas partes que interactúan en un sistema y de sus posibles comportamientos. En mi trabajo reciente, la IA me ha ayudado a navegar código que no habría podido escribir tan rápido por mi cuenta, a examinar dependencias y a razonar sobre la arquitectura. Esa ayuda hace más abordables los sistemas complejos. Sus interacciones todavía requieren un diseño y una verificación cuidadosos, pero los modelos son cada vez mejores conectando todos los puntos.
La conformidad se refiere a la necesidad de encajar en un mundo fuera de la aplicación: otros sistemas, reglas de negocio, prácticas organizacionales y restricciones. La IA puede ayudar a implementar una interfaz. Entender lo que esa interfaz debe significar para el negocio requiere un contexto que una descripción técnica por sí sola quizá no capture. Lo que entendemos de otros sistemas y procesos, y que podemos darle como insumo a nuestro modelo, tiene un límite.
La mutabilidad refleja cómo el software debe evolucionar a medida que cambian las necesidades y las circunstancias. Una implementación más rápida nos ayuda a responder. Aún necesitamos entender qué cambios importan, qué afectan y si mejoran el resultado.
La invisibilidad se refiere a la dificultad de ver la estructura completa del software. Las explicaciones, los diagramas y los prototipos nos ayudan a examinarla, pero ninguna vista captura todo. La IA nos da formas adicionales de explorar un sistema, aunque sigue siendo nuestra responsabilidad cuestionar y validar esas representaciones.
Estas dificultades se traslapan. Entender los requisitos, por ejemplo, implica tanto cómo encaja la aplicación en su entorno como la forma en que ese entorno cambia.
Mi experiencia sugiere que la IA nos da nuevas y poderosas formas de trabajar en estos desafíos. No los hace desaparecer.
La aplicación fue más fácil que las preguntas a su alrededor
Recientemente he construido aplicaciones que van desde pequeñas experiencias de aprendizaje para mi hijo hasta un sistema para la consultoría de mi padre en cultura y cambio organizacional.
Este último recopila retroalimentación de ejecutivos que forman parte de un mismo equipo directivo. Incluye múltiples usuarios, bases de datos y una puesta en producción en AWS. La velocidad con que pude construir y conectar estos componentes fue notable. ¡Mi padre no podía creer lo rápido que lo construí, y yo tampoco!
Sin embargo, las conversaciones más exigentes giraron en torno a cómo se usaría la aplicación en la práctica.
¿En qué momento de una consultoría la presentaría mi padre? ¿Cómo entenderían el ejercicio los participantes? ¿Cuándo se recopilarían las respuestas? ¿Cómo se compartirían los resultados con las personas que reciben la retroalimentación? ¿Qué conversación debería venir después?
Cada respuesta le da forma al software.
Un mecanismo que funcione para recopilar respuestas solo es útil si apoya el proceso de consultoría. Entender ese proceso determina qué información se necesita, cómo debe desarrollarse la experiencia y qué deben hacer posible los resultados. Todo esto es la complejidad esencial.
Aun así, la IA me ayudó a aligerar la carga. Pude construir una primera versión, obtener retroalimentación, iterar, probar más alternativas, validar… así que, aunque no podía reemplazar el conocimiento que mi padre tiene de su trabajo, pude incorporar sus aportes al software que estaba construyendo de forma muy efectiva.
Saber qué construir es más difícil que construir
Hace poco tuve una conversación muy reveladora con un ex-CTO a quien admiro mucho. Me dio una perspectiva aguda, que se me quedó grabada, sobre las discusiones acerca de que la IA se quede con los trabajos de los desarrolladores: un desarrollador que sabe darle instrucciones a una herramienta de IA no sería suficiente. Él mismo le daría las instrucciones a la IA y contrataría a las personas que entienden a fondo el problema de negocio que hay que resolver. Ese es el elemento crítico que hará que una nueva solución se distinga del resto.
Estoy totalmente de acuerdo.
¿Qué problema merece atención? ¿Qué debe lograr el proceso de negocio? ¿Cómo se vería un mejor resultado? ¿Cómo sabremos si la aplicación ayuda?
La capacidad de convertir esas respuestas en software es cada vez más accesible. La capacidad de descubrir, cuestionar y refinar esas respuestas sigue siendo enormemente valiosa.
El criterio técnico sigue siendo esencial. Un desarrollo más rápido amplía las oportunidades para quienes pueden combinar ese criterio con el entendimiento del negocio y trabajar de forma efectiva con quienes conocen el proceso de primera mano.
Además, construir es solo el comienzo
El desafío tiene otra capa: una vez en producción, una herramienta todavía tiene que adoptarse y usarse para generar valor. La puesta en producción técnica solo hace que la aplicación esté disponible. La adopción organizacional es lo que cambia los procesos de negocio, moldea la cultura y produce beneficios.
Las personas necesitan entender el propósito de la nueva herramienta, confiar en la experiencia e incorporarla a sus responsabilidades. En la aplicación de mi padre, recopilar retroalimentación es un paso. Que él use esa retroalimentación para apoyar conversaciones productivas y cambios significativos es el objetivo mayor.
Cualquiera que haya liderado una transformación de negocio reconocerá esta distinción. Entregar la herramienta crea una oportunidad. Aprovechar su valor requiere más trabajo.
¿Estamos más cerca de la bala de plata?
Construir con IA me ha entusiasmado aún más con lo que podemos lograr. Ideas que antes requerían mucho más esfuerzo o ayuda ahora están a nuestro alcance, y podemos probarlas mucho antes. También ha reforzado algo que he encontrado a lo largo de mi carrera: entender el problema de negocio y guiar el cambio organizacional son fundamentales para que la tecnología sea útil.
Quizás nos estemos acercando a la bala de plata. Pero las preguntas esenciales siguen ahí: ¿qué deberíamos construir, cómo debería funcionar y qué tiene que cambiar para que marque una diferencia? Seguiré buscándola.
Referencias
- ¹ Brooks, F. P., Jr. (1987). “No Silver Bullet—Essence and Accidents of Software Engineering.” Computer, abril de 1987. Leer el ensayo.