La historia del desarrollo de software consiste en un proceso continuo de reducci\u00f3n de barreras. Cada avance tecnol\u00f3gico relevante ha facilitado que un n\u00famero mayor de personas pueda utilizar ordenadores para crear nuevas herramientas. Pero reducir la dificultad necesaria para crear aplicaciones y servicios no implica eliminar la necesidad de comprender c\u00f3mo se construye un proyecto software.<\/p>\n
Durante las primeras d\u00e9cadas de la inform\u00e1tica, crear software estaba restringido a organizaciones capaces de acceder a ordenadores muy costosos y a profesionales con una formaci\u00f3n muy especializada. La aparici\u00f3n del ordenador personal modific\u00f3 esta situaci\u00f3n. Una persona pod\u00eda adquirir para su casa una m\u00e1quina programable de prop\u00f3sito general por un precio relativamente asequible.<\/p>\n
La barrera de entrada pas\u00f3 entonces a estar formada principalmente por tres elementos: disponer de un ordenador personal, acceder a las herramientas necesarias para desarrollar programas y adquirir los conocimientos t\u00e9cnicos para utilizarlas. Un ordenador personal, un compilador y suficiente documentaci\u00f3n pod\u00edan constituir un entorno de desarrollo completo. El hardware se hab\u00eda democratizado, pero el conocimiento segu\u00eda siendo una barrera considerable.<\/p>\n
La popularizaci\u00f3n de Internet produjo una nueva transformaci\u00f3n. El ordenador personal hab\u00eda democratizado el acceso a la capacidad de computaci\u00f3n, Internet comenz\u00f3 a democratizar el acceso al conocimiento necesario para utilizarla.<\/p>\n
La documentaci\u00f3n t\u00e9cnica, que anteriormente pod\u00eda encontrarse principalmente en libros, manuales, revistas especializadas, universidades y entornos profesionales, empez\u00f3 a estar disponible en l\u00ednea. Posteriormente aparecieron foros, comunidades de desarrolladores, proyectos de c\u00f3digo abierto, cursos, tutoriales, blogs t\u00e9cnicos y plataformas especializadas en preguntas y respuestas.<\/p>\n
Aprender a programar continuaba requiriendo un esfuerzo considerable, pero el coste econ\u00f3mico y la dificultad de encontrar informaci\u00f3n se hab\u00edan reducido dr\u00e1sticamente. Un desarrollador que encontraba un problema pod\u00eda buscar su mensaje de error, consultar la documentaci\u00f3n de una biblioteca o estudiar c\u00f3mo otras personas hab\u00edan resuelto situaciones similares.<\/p>\n
Internet facilit\u00f3 el aprendizaje de lenguajes de programaci\u00f3n y ayud\u00f3 a la difusi\u00f3n de conocimientos sobre arquitectura de software, patrones de dise\u00f1o, seguridad, pruebas, bases de datos, sistemas distribuidos y metodolog\u00edas de desarrollo.<\/p>\n
La barrera del conocimiento no desapareci\u00f3, pero acceder a \u00e9l se hizo progresivamente m\u00e1s sencillo.<\/p>\n
La aparici\u00f3n de los asistentes conversacionales basados en inteligencia artificial introdujo un cambio cualitativamente diferente. El problema dej\u00f3 de ser \u00fanicamente encontrar informaci\u00f3n para convertirse tambi\u00e9n en poder interrogarla mediante lenguaje natural.<\/p>\n
Ante una cuesti\u00f3n t\u00e9cnica, ya no era imprescindible formular correctamente una b\u00fasqueda, localizar varias fuentes, interpretarlas y construir una respuesta a partir de ellas. Un chatBot con conocimientos de ingenier\u00eda del software pod\u00eda realizar parte de ese proceso y proporcionar directamente una explicaci\u00f3n adaptada al contexto presentado por el usuario.<\/p>\n
Conceptos que requer\u00edan consultar diferentes libros, art\u00edculos o discusiones t\u00e9cnicas pueden explorarse mediante una conversaci\u00f3n en un chat. Con este avance era posible describir un problema, solicitar alternativas, preguntar por sus ventajas e inconvenientes y profundizar sucesivamente en determinados aspectos del problema.<\/p>\n
La inteligencia artificial comenz\u00f3 as\u00ed a actuar como una nueva capa de abstracci\u00f3n sobre el conocimiento t\u00e9cnico disponible.<\/p>\n
Pero facilitar el acceso a una respuesta no equivale a comprender la soluci\u00f3n que se ha obtenido. Una respuesta t\u00e9cnicamente plausible puede contener errores, asumir condiciones inexistentes o ser adecuada para un contexto diferente. La capacidad para evaluar la respuesta contin\u00faa dependiendo del conocimiento de la persona que la recibe.<\/p>\n
La reciente evoluci\u00f3n de la IA introduce un cambio todav\u00eda m\u00e1s profundo. Este cambio consiste en que las herramientas de inteligencia artificial han dejado de limitarse a explicar c\u00f3mo escribir software y han comenzado a participar directamente en su construcci\u00f3n.<\/p>\n
Los modelos actuales pueden generar c\u00f3digo, modificar proyectos existentes, ejecutar herramientas, interpretar errores, crear pruebas y realizar sucesivas modificaciones hasta obtener aparentemente el resultado solicitado. La aparici\u00f3n de agentes de programaci\u00f3n ampl\u00eda todav\u00eda m\u00e1s esta capacidad al permitir que determinados procesos se ejecuten con un grado creciente de autonom\u00eda.<\/p>\n
En este contexto se ha popularizado el concepto de vibeCoding<\/strong>, una forma de creaci\u00f3n de software en la que el usuario describe mediante lenguaje natural aquello que desea delegando \u00a0parte de las decisiones de implementaci\u00f3n en la inteligencia artificial.<\/p>\n Esta capacidad est\u00e1 produciendo dos interpretaciones aparentemente contradictorias. Hay personas sin conocimientos avanzados de programaci\u00f3n que ya pueden construir prototipos y aplicaciones que anteriormente habr\u00edan requerido la intervenci\u00f3n de un desarrollador. Por otra parte, los profesionales del software pueden utilizar estas mismas herramientas para aumentar considerablemente su productividad.<\/p>\n La consecuencia es una nueva reducci\u00f3n de la barrera de entrada a la creaci\u00f3n de software.<\/p>\n Esta democratizaci\u00f3n presenta un problema fundamental que consiste en que generar software que aparentemente funciona es considerablemente m\u00e1s sencillo que generar buen software.<\/p>\n Cuando una persona solicita a una inteligencia artificial que construya una aplicaci\u00f3n, el sistema intenta materializar la descripci\u00f3n recibida. Si la especificaci\u00f3n es incompleta, ambigua o t\u00e9cnicamente inconsistente, el modelo debe trabajar con esa incertidumbre. Puede realizar suposiciones razonables y producir un resultado visualmente convincente, pero eso no significa que haya construido exactamente aquello que el usuario necesitaba.<\/p>\n Una caracter\u00edstica especialmente problem\u00e1tica del vibeCoding es que tiene una facilidad para producir una sensaci\u00f3n prematura de \u00e9xito.<\/p>\n Una interfaz puede mostrarse correctamente. Un bot\u00f3n puede ejecutar la acci\u00f3n esperada. Los datos pueden almacenarse y recuperarse. Desde el punto de vista del usuario, el software parece terminado.<\/p>\n Sin embargo, gran parte de la calidad del software no resulta inmediatamente visible.<\/p>\n La arquitectura puede ser inadecuada para futuras ampliaciones. El modelo de datos puede contener decisiones que dificulten su evoluci\u00f3n. Pueden existir problemas de concurrencia, seguridad o rendimiento. El tratamiento de errores puede ser insuficiente. Las pruebas pueden cubrir \u00fanicamente los escenarios m\u00e1s evidentes. Las dependencias pueden haber sido elegidas sin considerar sus consecuencias a largo plazo.<\/p>\n El problema no consiste necesariamente en que la inteligencia artificial haya ejecutado incorrectamente la tarea. Puede haber construido de manera razonable aquello que se le solicit\u00f3. El problema puede encontrarse en en la incapacidad del usuario para describir con suficiente precisi\u00f3n aquello que realmente necesitaba.<\/p>\n El desarrollo profesional de software nunca ha consistido exclusivamente en escribir c\u00f3digo. Una parte importante del trabajo consiste en transformar necesidades ambiguas en requisitos concretos, identificar restricciones, anticipar situaciones excepcionales y decidir qu\u00e9 compromisos son aceptables.<\/p>\n Cuando se delega la implementaci\u00f3n en un agente de inteligencia artificial, estas actividades no desaparecen, m\u00e1s bien adquieren una importancia mayor.<\/p>\n Una especificaci\u00f3n insuficiente produce un n\u00famero de soluciones demasiado amplio. El sistema debe completar la informaci\u00f3n que falta mediante inferencias. Cuantas m\u00e1s decisiones se deleguen, mayor ser\u00e1 la probabilidad de que el resultado se aleje de las necesidades reales.<\/p>\n En este sentido, los modelos generativos pueden reducir dr\u00e1sticamente el coste de escribir c\u00f3digo sin reducir en la misma proporci\u00f3n la dificultad de especificar correctamente un sistema.<\/p>\n La programaci\u00f3n puede hacerse m\u00e1s accesible mientras que la ingenier\u00eda de software contin\u00faa siendo dif\u00edcil.<\/p>\n El problema aparece despu\u00e9s de que el programa funcione<\/p>\n Existe adem\u00e1s una dimensi\u00f3n temporal que puede pasar inadvertida durante la generaci\u00f3n inicial. El coste de un producto de software no termina cuando se obtiene su primera versi\u00f3n funcional.<\/p>\n El software necesita ser corregido, actualizado, ampliado, auditado y adaptado a nuevos requisitos. En sistemas con una vida \u00fatil suficientemente larga, una parte considerable del esfuerzo se dedica precisamente a comprender y modificar c\u00f3digo existente.<\/p>\n El c\u00f3digo generado autom\u00e1ticamente no est\u00e1 exento de esta realidad.<\/p>\n Una sucesi\u00f3n de instrucciones destinadas \u00fanicamente a conseguir que el sistema vuelva a funcionar puede introducir duplicaciones, dependencias innecesarias, soluciones locales incompatibles con la arquitectura general o abstracciones dif\u00edciles de comprender. Cada modificaci\u00f3n puede resolver el problema inmediato y, al mismo tiempo, aumentar la dificultad de implementar la siguiente versi\u00f3n del producto.<\/p>\n El riesgo no es s\u00f3lo producir c\u00f3digo incorrecto. Tambi\u00e9n existe el riesgo de producir c\u00f3digo que nadie comprende suficientemente bien como para sustituir el trabajo de la IA por c\u00f3digo mantenible, escalable y actualizable.<\/p>\n La mantenibilidad del proyecto se convierte en una cuesti\u00f3n central. Si la persona que dirige el desarrollo no comprende la arquitectura creada por la IA, evaluar una modificaci\u00f3n propuesta por otro agente de IA resulta dif\u00edcil. La capacidad de generar cambios puede crecer m\u00e1s r\u00e1pidamente que la capacidad para evaluar sus consecuencias.<\/p>\n El incremento de productividad asociado a estas herramientas tambi\u00e9n est\u00e1 modificando la percepci\u00f3n sobre la organizaci\u00f3n de los equipos de desarrollo. Un profesional experimentado asistido por inteligencia artificial puede realizar determinadas tareas que anteriormente requer\u00edan muchas m\u00e1s horas de trabajo. Esto puede generar la impresi\u00f3n de que algunas funciones, especialmente las posiciones junior, han dejado de ser necesarias o de que equipos completos pueden ser sustituidos por un desarrollador experimentado acompa\u00f1ado de varios agentes.<\/p>\n Esta conclusi\u00f3n confunde capacidad de producci\u00f3n con capacidad organizativa.<\/p>\n Un equipo de software no est\u00e1 \u00fanicamente para producir l\u00edneas de c\u00f3digo. Tambi\u00e9n est\u00e1 para distribuir conocimiento, revisar decisiones, detectar errores, cuestionar hip\u00f3tesis e ideas y permitir que diferentes personas desarrollen experiencia sobre el sistema. De la misma forma un desarrollador junior no es simplemente una versi\u00f3n menos productiva de un desarrollador senior.<\/p>\n Las posiciones junior forman parte del mecanismo para formar los profesionales experimentados del futuro.<\/p>\n Si las organizaciones eliminan sistem\u00e1ticamente esas posiciones porque la inteligencia artificial permite que los profesionales actuales produzcan m\u00e1s software, pueden obtener una mejora de productividad inmediata mientras debilitan simult\u00e1neamente su capacidad para formar nuevas generaciones de especialistas.<\/p>\n La cuesti\u00f3n no es cu\u00e1ntas personas son necesarias para producir una determinada cantidad de software, sino qu\u00e9 conocimientos deben existir dentro de una organizaci\u00f3n para comprender, mantener y evolucionar ese software durante a\u00f1os.<\/p>\n La democratizaci\u00f3n de la creaci\u00f3n de software mediante inteligencia artificial ofrece una oportunidad que puede ser m\u00e1s importante que la generaci\u00f3n autom\u00e1tica de c\u00f3digo.<\/p>\n Las mismas herramientas que permiten solicitar crea esta aplicaci\u00f3n<\/em> permiten adoptar un enfoque diferente como pedir ens\u00e9\u00f1ame a construir esta aplicaci\u00f3n<\/em>.<\/p>\n La diferencia entre ambas formas es sustancial.<\/p>\n En el primer caso, en el que la persona pide la creaci\u00f3n, el objetivo principal es obtener un resultado. En el segundo caso, el resultado se convierte tambi\u00e9n en un mecanismo de aprendizaje. La inteligencia artificial puede explicar las decisiones arquitect\u00f3nicas, presentar alternativas, justificar la elecci\u00f3n de determinadas estructuras de datos, generar ejemplos progresivos, analizar errores y ayudar al usuario a comprender las consecuencias de cada modificaci\u00f3n.<\/p>\n De esta forma, la inteligencia artificial puede utilizarse como sustituto parcial de determinadas tareas de programaci\u00f3n, y como un instrumento para acelerar la adquisici\u00f3n de conocimientos. La misma tecnolog\u00eda que permite programar sin comprender puede convertirse en una de las herramientas m\u00e1s eficaces para aprender a comprender.<\/p>\n Puede ser cada vez m\u00e1s sencillo conseguir que un ordenador produzca una aplicaci\u00f3n. Pero sigue \u00a0siendo dif\u00edcil determinar qu\u00e9 aplicaci\u00f3n debe construirse, c\u00f3mo debe comportarse en situaciones no previstas, qu\u00e9 arquitectura permitir\u00e1 mantenerla, qu\u00e9 riesgos introduce y c\u00f3mo deber\u00e1 evolucionar cuando cambien sus requisitos.<\/p>\n La democratizaci\u00f3n de la creaci\u00f3n de software no deber\u00eda entenderse como el final de la necesidad de aprender ingenier\u00eda de software. Mas bien puede ser lo contrario.<\/p>\n Cuando producir c\u00f3digo deja de ser el principal cuello de botella, comprender qu\u00e9 c\u00f3digo merece la pena producir, evaluar el que ha sido generado y ser capaz de mantenerlo adquiere m\u00e1s importancia.<\/p>\n El futuro de la creaci\u00f3n de software no estar\u00e1 en elegir entre programar manualmente o delegar la programaci\u00f3n en una inteligencia artificial. M\u00e1s bien estar\u00e1 en utilizar la inteligencia artificial para elevar progresivamente el nivel de abstracci\u00f3n al que trabajan las personas sin renunciar al conocimiento necesario para comprender aquello que est\u00e1n construyendo.<\/p>\n La herramienta puede escribir cada vez m\u00e1s c\u00f3digo pero la responsabilidad de entender el sistema contin\u00faa siendo humana.<\/p>\n","protected":false},"excerpt":{"rendered":" La historia del desarrollo de software consiste en un proceso continuo de reducci\u00f3n de barreras. Cada avance tecnol\u00f3gico relevante ha facilitado que un n\u00famero mayor de personas pueda utilizar ordenadores para crear nuevas herramientas. Pero reducir la dificultad necesaria para crear aplicaciones y servicios no implica eliminar la necesidad de comprender c\u00f3mo se construye un … <\/p>\nLa falsa sensaci\u00f3n de \u00e9xito<\/h2>\n
Especificar tambi\u00e9n es ingenier\u00eda<\/h2>\n
La productividad y la desaparici\u00f3n del equipo<\/h2>\n
De pedir resultados a pedir conocimiento<\/h2>\n
Una nueva etapa de la democratizaci\u00f3n<\/h2>\n