|
La drástica reducción del coste de muchas tareas de desarrollo —escribir, probar, mantener y coordinar código— que ha supuesto la IA ha empujado a muchos profesionales a cuestionar o incluso ignorar las leyes elementales que hasta ahora guiaron la ingeniería del software.
Pero ¿realmente ha acabado la IA con los problemas que esas reglas nos ayudan a resolver o, simplemente, ha cambiado la forma de enfrentarnos a ellos?
¿Tiene sentido seguir los principios KISS (Keep It Simple, Stupid!) o DRY (Don't Repeat Yourself) cuando nos abstraemos por completo de la escritura del código?
¿Sigue extrapolándose del número de Dunbar el tamaño óptimo de equipos y departamentos ahora que interactuamos con agentes y no solo con personas? ¿Cambiará la concentración de bugs, que solemos asociar a la ley de Pareto, cuando el código no lo escribimos nosotros?
Para encontrar una respuesta, debamos distinguir qué problemas describen esas reglas. Algunas recogen las dinámicas de sistemas complejos. Otras, sin embargo, intentan delimitar nuestra capacidad para comprender, ejecutar y organizar trabajo.
Quizás debamos revisar cuidadosamente estas últimas, ahora que ha cambiado quién hace el trabajo y cuánto cuesta hacerlo.
Por ejemplo, la ley de Kernighan (el mismo Kernighan que escribió el primer Hello World) asegura que depurar un programa resulta el doble de difícil que escribirlo.
Ese «doble» no es una proporción exacta, sino una manera de plantear que, si escribimos código al límite de nuestra capacidad para comprenderlo, puede que no sepamos cómo arreglarlo en caso de que falle.
Sin embargo, con la IA podemos utilizar capacidades distintas para generar, analizar y corregir una solución. Un agente puede ayudarnos a localizar un fallo reproducible en código que nosotros no habríamos sabido escribir. Eso amplía lo que podemos abordar, aunque no garantice que cualquier error vaya a ser fácil de resolver.
La advertencia sigue siendo útil, pero necesitamos revisar cómo aplicarla. La IA puede reducir el coste de entender y corregir código complejo y cambiar cuánto esfuerzo compensa dedicar a evitar esa complejidad. Que algo siga siendo difícil no significa que siga siendo igual de costoso.
Algo parecido ocurre con la ley de Brooks, según la cual añadir personas a un proyecto retrasado lo retrasa todavía más. Su razonamiento incluye el tiempo necesario para seleccionar a alguien, formarlo, explicarle lo que debe hacer y coordinarlo con los que ya estaban trabajando.
¿Podríamos trasladarlo tal cual a un desarrollo agéntico? Un grupo de agentes necesita un contexto compartido y un entorno de ejecución y coordinación para solucionar potenciales conflictos, pero una vez creados, el coste de poner en marcha uno nuevo puede ser ridículo. Si podemos repartir tareas independientes entre varios, aumentar su número puede acelerar el proyecto.
La palabra clave es «independientes». Si todos necesitan modificar la misma pieza o existen cuellos de botella, multiplicar agentes también puede multiplicar conflictos.
Tenemos que repensar cuánto cuesta coordinar el trabajo y cuánto ganamos al repartirlo. Dar por sentado que será igual que con un equipo humano sería tan poco riguroso como asumir que no costará nada.
Pero quizás lo que más puede hacernos replantearnos nuestros sesgos e ideas preconcebidas sobre el trabajo sea la filosofía YAGNI (del inglés You Aren't Gonna Need It), que nos anima a implementar una funcionalidad solo cuando sea estrictamente necesaria, no porque creamos que alguna vez puede serlo.
Pero si añadirla apenas cuesta un par de palabras en un prompt, ¿por qué esperar?
Imaginemos que necesitamos exportar un listado a CSV. El agente nos propone añadir Excel y PDF. Aceptamos porque apenas supone trabajo adicional. Ahora tenemos más formatos que comprobar si cambian los datos, nuevas librerías que actualizar y un «contrato» con los usuarios que empiecen a utilizar esos formatos, que exigirán que cumplan sus expectativas.
La IA puede ayudarnos a mantener todo eso, pero cada funcionalidad debe seguir teniendo una utilidad que la justifique. El ahorro en la implementación modifica el cálculo, pero no garantiza que el resultado compense.
YAGNI nos plantea una disyuntiva interesante, porque si construir esa funcionalidad cuando alguien la necesite también será «barato», nuestro incentivo para anticiparnos disminuye. Podemos esperar a conocer mejor el problema y evitar, en la medida de lo posible, poner a prueba la ley de Kernighan… y también podemos crear prototipos desechables para aprender sin comprometernos a mantenerlos indefinidamente.
La IA amplía nuestras opciones, pero debemos seguir siendo nosotros los que determinemos cuál es la forma óptima de resolver una tarea determinada. Entender qué problemas intentan resolver estas reglas es una buena forma de empezar a hacerlo.
Descartarlas sin más no parece una buena idea. No tengo ni idea de las habilidades que se exigirán a los desarrolladores profesionales en un futuro, pero estoy seguro de que saber cuándo aplicarlas será una de ellas.
Porque la IA ha cambiado el umbral que justifica algunas prácticas, pero no necesariamente el problema que resuelven. Y nuestro trabajo nunca consistió solo en escribir código, sino en resolver problemas. El código solo es una de las herramientas que usamos para hacerlo.
Ignorar las nuevas posibilidades que nos da la IA para resolver esos problemas es tan estúpido como ignorar los conocimientos que adquirimos tras décadas resolviéndolo. ¿No creéis?
|
