De usuarios a creadores: la nueva democratización del software
Durante décadas, la relación de la mayoría de las personas con el software fue esencialmente asimétrica. Un grupo relativamente pequeño de profesionales lo diseñaba, programaba y distribuía, mientras que el resto aprendía a utilizarlo. Las empresas y los usuarios podían elegir entre diferentes productos, configurarlos dentro de ciertos límites o combinar varias herramientas para resolver una necesidad concreta, pero la posibilidad de modificar radicalmente su funcionamiento —o construir una alternativa— permanecía, en buena medida, reservada a quienes contaban con conocimientos técnicos. Si una aplicación no hacía exactamente lo que una persona necesitaba, las opciones eran previsibles: adaptar el proceso a las limitaciones del software, buscar otro producto, solicitar una modificación al departamento de tecnología, contratar a un desarrollador o aprender a programar.
La inteligencia artificial generativa está comenzando a modificar esa relación. No porque haya eliminado la necesidad de comprender la programación, ni porque construir software confiable se haya convertido repentinamente en una actividad trivial, sino porque está reduciendo una distancia que durante buena parte de la historia de la informática fue considerable: la distancia entre identificar un problema y construir una herramienta digital capaz de resolverlo. Una persona puede hoy describir un flujo de trabajo en lenguaje natural, solicitar una interfaz, generar una función, conectar servicios, transformar datos, construir una automatización o producir el primer prototipo funcional de una aplicación sin dominar necesariamente los lenguajes de programación que operan debajo de esas capas.
La diferencia es importante. Democratizar la programación no significa convertir a toda la población en ingenieros de software profesionales. Significa ampliar el número de personas capaces de utilizar el software no solamente como un producto terminado, sino también como un material modificable. La consecuencia potencial es un cambio en la propia condición del usuario: de consumidor de herramientas diseñadas por otros a creador de herramientas construidas alrededor de sus propias necesidades.
Una democratización que comenzó antes de la inteligencia artificial
La idea de permitir que personas no especializadas construyan programas no nació con los grandes modelos de lenguaje. Las hojas de cálculo, las macros, los sistemas de gestión de contenidos, las herramientas de automatización y, más recientemente, las plataformas low-code y no-code han aumentado progresivamente el nivel de abstracción mediante el cual las personas pueden interactuar con las computadoras. La investigación sobre end-user programming —programación realizada por personas cuyo trabajo principal no consiste en desarrollar software— existe desde mucho antes de la actual generación de inteligencia artificial. Un estudio presentado en CHI 2016, por ejemplo, analizó más de 200,000 automatizaciones públicas creadas mediante IFTTT y encontró un ecosistema considerable de usuarios construyendo pequeños programas basados en reglas del tipo “si ocurre esto, entonces ejecuta aquello”, muchas veces para añadir funciones que las aplicaciones originales no ofrecían.
Lo que cambia con la inteligencia artificial es la interfaz y, potencialmente, la escala de participación. Una revisión sistemática publicada en 2026 en Management Review Quarterly, de Springer Nature, basada en el análisis de 383 definiciones procedentes de 306 publicaciones, describe precisamente esta evolución de las plataformas low-code y no-code. Los autores identifican una transición desde modelos centrados principalmente en instrucciones y componentes predefinidos hacia sistemas cada vez más orientados a la intención del usuario, en los que el lenguaje natural y los agentes de inteligencia artificial pueden participar en la generación de interfaces y lógica de negocio. El estudio se refiere a esta evolución como Programming by Natural Language: los usuarios describen mediante texto o voz lo que desean construir y el sistema traduce esa intención en una implementación inicial que después puede refinarse de manera iterativa.
Desde una perspectiva histórica, la inteligencia artificial generativa puede entenderse entonces como una nueva capa dentro de un proceso mucho más largo de abstracción. Los programadores dejaron hace décadas de introducir instrucciones binarias directamente; los lenguajes de alto nivel ocultaron buena parte de esa complejidad; las bibliotecas y los frameworks encapsularon posteriormente operaciones cada vez más sofisticadas; las interfaces gráficas permitieron construir determinadas aplicaciones sin especificar manualmente cada instrucción; y ahora el lenguaje natural comienza a funcionar como otra capa intermedia entre la intención humana y el sistema que finalmente la ejecuta. El código no desaparece debajo de esta abstracción, de la misma manera que Internet Protocol no desaparece porque alguien utilice un navegador. Simplemente, una proporción cada vez mayor de su complejidad deja de estar presente en la interacción inmediata del usuario.
Del software para millones al software para una sola persona
Esta reducción de las barreras de creación puede tener una consecuencia económica particularmente interesante. Tradicionalmente, desarrollar software era suficientemente costoso como para que, fuera de determinados proyectos internos, resultara más razonable construir productos capaces de atender a muchos usuarios. Una empresa identifica un problema relativamente común, desarrolla una solución general y distribuye el costo de esa construcción entre cientos, miles o millones de clientes. Esta lógica explica buena parte de la economía del software comercial: un procesador de texto, un CRM, una plataforma de gestión de proyectos o una aplicación de productividad deben ofrecer suficiente flexibilidad para servir a usuarios cuyos procesos nunca son exactamente iguales.
La reducción de los costos de desarrollo introduce otra posibilidad: software cuya audiencia legítima puede estar compuesta por una sola persona. Un abogado puede necesitar un sistema que clasifique ciertos documentos de acuerdo con criterios específicos de su práctica; un investigador puede querer una herramienta que transforme información dispersa en una estructura adaptada a una metodología particular; un diseñador puede automatizar la preparación de archivos repetitivos; un administrador puede crear una interfaz que consolide información procedente de varios servicios; o un estudiante puede construir un sistema que organice materiales, fechas y notas siguiendo una lógica completamente personal. Ninguna de estas herramientas necesita convertirse en una empresa, atraer inversión o conseguir miles de usuarios para tener valor. Su justificación económica puede ser simplemente ahorrar varias horas a una sola persona cada semana.
Esto permite imaginar una categoría de software personal mucho más amplia que la que hemos conocido hasta ahora. La idea va más allá de personalizar una aplicación existente mediante algunas opciones de configuración. En su lugar, las personas podrían construir pequeñas capacidades digitales alrededor de la forma particular en que trabajan. Algunos de estos sistemas podrían existir durante años; otros podrían crearse para un proyecto de un mes y desaparecer después. Bajo el modelo tradicional, dedicar varios días de ingeniería a una herramienta destinada a resolver una necesidad temporal podía resultar económicamente irracional. Si una parte importante de esa herramienta puede construirse conversacionalmente en mucho menos tiempo, la ecuación cambia.
La comparación con otros procesos de democratización tecnológica resulta útil. Las cámaras digitales y, posteriormente, los teléfonos inteligentes equipados con cámaras cada vez más capaces no convirtieron a todas las personas en fotógrafos profesionales, pero sí redujeron radicalmente el costo de producir una imagen y provocaron una expansión extraordinaria del número de fotografías creadas. Los sistemas de gestión de contenidos hicieron algo similar con la publicación web: no eliminaron el desarrollo profesional, pero permitieron que millones de organizaciones y personas publicaran en Internet sin construir un sitio desde cero. El desarrollo asistido por inteligencia artificial puede producir un fenómeno comparable: no necesariamente menos desarrolladores, sino muchísimo más software.
La posible era del microsoftware
A partir de esta lógica puede plantearse el concepto de microsoftware: pequeñas aplicaciones, automatizaciones, scripts, agentes o interfaces diseñados para resolver una necesidad extremadamente específica y cuya existencia no requiere convertirse en un producto comercial independiente. El término resulta útil aquí como marco analítico más que como una categoría técnica formal. Una pieza de microsoftware puede existir únicamente para recibir determinados archivos, extraer cinco variables, comparar los resultados con una base de datos y generar un reporte; otra puede reorganizar notas después de una reunión; una tercera puede preparar un resumen semanal; y una cuarta puede conectar dos sistemas que nunca fueron diseñados para trabajar juntos.
Lo importante no es cada herramienta de manera aislada, sino el entorno que puede surgir cuando construirlas resulte suficientemente barato. Una persona podría terminar trabajando junto a decenas de pequeños sistemas personales diseñados para eliminar fricciones concretas de su vida cotidiana. En lugar de depender exclusivamente de grandes aplicaciones de propósito general, su entorno digital podría estar formado por una combinación de plataformas comerciales, APIs, modelos de inteligencia artificial y capas de automatización construidas alrededor de sus necesidades individuales. La pregunta cotidiana podría dejar de ser únicamente “¿qué aplicación existe para hacer esto?” y convertirse también en “¿por qué sigo haciendo esto manualmente?” o “¿puedo crear algo que haga exactamente lo que necesito?”.
Este cambio puede ser especialmente relevante para pequeñas empresas y equipos que históricamente han quedado atrapados entre dos opciones imperfectas: utilizar software genérico que no se adapta completamente a su operación o asumir el costo de desarrollar sistemas personalizados. La inteligencia artificial no elimina esa tensión —particularmente cuando entran en juego la seguridad, la disponibilidad, la escalabilidad o el cumplimiento normativo—, pero puede ampliar considerablemente el espacio intermedio en el que soluciones más pequeñas pueden ser construidas y mantenidas localmente.
El lenguaje natural como interfaz de programación
Uno de los cambios más visibles de esta nueva etapa es que describir una intención puede comenzar a formar parte del propio proceso de programación. Durante décadas, convertir una idea en software exigía varias capas de traducción: comprender el problema, diseñar una solución lógica y expresar después esa solución mediante una sintaxis suficientemente precisa para que una computadora pudiera ejecutarla. Los modelos generativos introducen una nueva capa capaz de participar en esa última traducción. De forma simplificada, el proceso puede representarse como: intención humana → lenguaje natural → representación técnica → código y ejecución.
La importancia de esta capa no debe confundirse con la idea de que el lenguaje natural posee la precisión de un lenguaje de programación formal. Decir “organiza mis documentos importantes” sigue siendo extraordinariamente ambiguo frente a una especificación técnica. ¿Qué significa “importantes”? ¿Qué ocurre cuando un archivo está duplicado? ¿Dónde debe almacenarse la información? ¿Quién debe tener acceso? ¿Qué ocurre si falla la clasificación? ¿Qué debe conservarse y qué puede eliminarse de forma segura? La inteligencia artificial puede reducir el trabajo necesario para producir una implementación, pero alguien sigue teniendo que tomar o supervisar esas decisiones. Por ello, la programación mediante lenguaje natural no elimina la ingeniería: traslada una parte del esfuerzo desde la escritura de sintaxis hacia la especificación de la intención y la evaluación del resultado.
La evidencia procedente de grandes organizaciones tecnológicas también muestra hasta qué punto la inteligencia artificial ya se ha integrado en distintas partes del trabajo de ingeniería de software. Google Research informó en 2024 que sus herramientas internas de completado de código basadas en inteligencia artificial alcanzaban una tasa de aceptación del 37% entre sus ingenieros y participaban en la producción de aproximadamente la mitad de los caracteres escritos en código dentro de los contextos analizados. Al mismo tiempo, Google subrayó la importancia de medir la efectividad real y distinguir entre una demostración técnicamente impresionante y una herramienta que mejora materialmente el flujo de trabajo de un desarrollador.
Productividad: una historia más compleja de lo que parece
La reducción de barreras para crear software no debe interpretarse automáticamente como un aumento de productividad. La evidencia disponible ofrece resultados distintos dependiendo del tipo de usuario, la naturaleza de la tarea, el entorno de trabajo y la forma en que se mide la productividad. Un experimento controlado realizado por investigadores de GitHub y Microsoft encontró que los programadores que utilizaban GitHub Copilot completaron una tarea concreta de construcción de un servidor HTTP en JavaScript un 55.8% más rápido que los participantes que no tenían acceso a la herramienta. Los investigadores también sugirieron que estos efectos podían ser especialmente relevantes para personas que aún se encontraban desarrollando experiencia en programación.
Sin embargo, sería engañoso extrapolar ese experimento y concluir que la inteligencia artificial hace a cualquier desarrollador 55% más productivo. Un ensayo controlado aleatorizado publicado por METR en 2025 examinó prácticamente el escenario opuesto: 16 desarrolladores experimentados trabajando en 246 tareas reales dentro de grandes repositorios de código abierto que conocían desde hacía años. Antes del estudio, los participantes creían que la IA reduciría aproximadamente 24% su tiempo de trabajo. Incluso después de utilizar las herramientas, estimaban que la IA los había hecho alrededor de 20% más rápidos. El resultado medido fue el contrario: en ese entorno específico, el acceso a herramientas de IA incrementó aproximadamente 19% el tiempo necesario para completar las tareas. METR fue explícito al señalar que el resultado no debe generalizarse a todo el desarrollo de software, pero el experimento es valioso precisamente porque demuestra que el efecto de la IA depende profundamente del contexto en el que se utiliza.
La encuesta de desarrolladores de Stack Overflow de 2025 muestra una tensión similar entre adopción y confianza. El 84% de los encuestados afirmó utilizar o tener previsto utilizar herramientas de IA dentro del proceso de desarrollo, frente al 76% del año anterior, mientras que el 51% de los desarrolladores profesionales señaló utilizarlas diariamente. Al mismo tiempo, el 46% indicó desconfiar de la precisión de los resultados generados por IA, frente a un 33% que afirmó confiar en ellos. Entre las principales frustraciones aparecieron recibir soluciones “casi correctas” y tener que dedicar tiempo adicional a depurar código producido por inteligencia artificial.
La conclusión razonable, por tanto, no es que la IA “funcione” o “no funcione” para programar. Más bien, su valor cambia según la tarea. Construir desde cero una aplicación relativamente delimitada, explorar un lenguaje desconocido, generar código repetitivo o preparar un prototipo puede beneficiarse significativamente de herramientas generativas. Comprender una arquitectura madura, modificar sistemas con numerosos efectos secundarios, mantener garantías de compatibilidad o tomar decisiones que requieren años de conocimiento contextual pertenece a otra categoría de problema. La investigación DORA de Google Cloud de 2025 refleja precisamente esta distinción al describir la adopción exitosa de IA en el desarrollo de software como una cuestión de sistemas y capacidades organizacionales, y no simplemente como la adquisición de una nueva herramienta.
Cuando escribir código deja de ser la única habilidad escasa
Si producir determinados tipos de código se vuelve progresivamente más barato, el conocimiento técnico no desaparece; cambia la distribución de su valor. Memorizar determinada sintaxis puede resultar relativamente menos diferenciador en algunos contextos, mientras aumentan de importancia otras capacidades: identificar correctamente un problema, delimitarlo, dividirlo en componentes, diseñar restricciones, comprender los datos, evaluar resultados, detectar excepciones, verificar comportamientos y reconocer cuándo una solución aparentemente funcional es incorrecta.
En este entorno, una persona sin formación tradicional en ingeniería puede ser capaz de construir herramientas sorprendentemente útiles si posee un conocimiento profundo de su campo y sabe describir con claridad sus procesos. La experiencia de un médico, un abogado, un investigador, un contador, un diseñador o un especialista en operaciones puede combinarse con sistemas capaces de traducir parte de ese conocimiento a software. Sin embargo, esta misma posibilidad explica por qué los desarrolladores profesionales continúan siendo esenciales. Cuando una herramienta deja de ser un experimento personal y comienza a manejar dinero, identidades, información confidencial, decisiones importantes, miles de usuarios o infraestructura crítica, comprender lo que ocurre debajo de las capas de abstracción se vuelve todavía más importante.
Por ello, resulta más preciso describir el cambio como una redistribución de habilidades y no como su desaparición. Los desarrolladores profesionales pueden concentrarse cada vez más en arquitectura, seguridad, infraestructura, observabilidad, integración, aseguramiento de calidad, diseño de plataformas y problemas que exigen comprensión sistémica, mientras que otros usuarios construyen sobre las capas que esos profesionales proporcionan. Paradójicamente, cuanto más fácil resulte generar software, más importante puede volverse la capacidad de distinguir entre una demostración que funciona y un sistema que puede mantenerse de forma confiable.
Democratizar el software también democratiza sus errores
Existe una consecuencia inevitable al ampliar el número de personas capaces de construir aplicaciones: también aumenta el número de personas capaces de construir aplicaciones inseguras, frágiles o incorrectas. Una interfaz puede parecer completamente funcional y, aun así, almacenar credenciales de manera inadecuada, exponer datos personales, confiar en entradas manipulables, utilizar dependencias vulnerables, carecer de controles de autorización apropiados o producir resultados incorrectos en escenarios que su creador nunca anticipó.
Esta preocupación no es hipotética. El Center for Security and Emerging Technology de Georgetown University ha identificado tres grandes categorías de riesgo asociadas con los sistemas de generación de código mediante inteligencia artificial: la generación de código inseguro, las vulnerabilidades presentes en los propios sistemas generativos y los efectos posteriores sobre la seguridad de la cadena de suministro de software. El centro también advierte que estos riesgos no se distribuirán de manera uniforme. Las organizaciones con mayores recursos pueden implementar revisiones de seguridad, procedimientos de prueba y mecanismos de gobernanza que posiblemente no estén disponibles para usuarios individuales o empresas más pequeñas.
NIST aborda un problema relacionado en su perfil del Secure Software Development Framework para sistemas de inteligencia artificial generativa. El organismo señala que los sistemas basados en IA heredan riesgos tradicionales del software mientras incorporan otros relacionados con modelos, datos, entradas en lenguaje natural y nuevas superficies susceptibles de manipulación. Su recomendación fundamental continúa siendo válida independientemente de si el código fue escrito manualmente o generado por inteligencia artificial: el desarrollo seguro requiere procesos de protección, revisión, validación y respuesta ante vulnerabilidades a lo largo de todo el ciclo de vida del sistema.
Esto conduce a una distinción fundamental en cualquier discusión sobre democratización: crear software funcional y crear software confiable no son la misma actividad. La inteligencia artificial puede reducir drásticamente la barrera para la primera. La segunda sigue dependiendo de disciplina de ingeniería, pruebas, seguridad, mantenimiento, conocimiento del dominio y responsabilidad.
Del Shadow IT al Shadow Software
Dentro de las organizaciones, esta nueva capacidad también genera un problema de gobernanza. Durante años, las empresas han utilizado el término Shadow IT para describir tecnologías, aplicaciones o servicios adoptados por empleados y departamentos sin el conocimiento o supervisión de la función formal de tecnología. Las plataformas low-code y no-code ya habían ampliado este fenómeno; la generación de aplicaciones mediante lenguaje natural puede llevarlo considerablemente más lejos.
Imaginemos a un empleado que necesita automatizar una tarea recurrente y, en lugar de esperar la aprobación de un nuevo sistema corporativo, crea en unas cuantas horas una pequeña aplicación que conecta una hoja de cálculo, una API externa, documentos internos y un modelo de inteligencia artificial. Desde la perspectiva del empleado, ha eliminado una ineficiencia. Desde la perspectiva de la organización surgen inmediatamente otras preguntas: ¿qué información está procesando?, ¿dónde se almacena?, ¿qué permisos posee la aplicación?, ¿quién la mantiene si el empleado abandona la empresa o cambia de puesto?, ¿qué ocurre si una API modifica su comportamiento?, ¿existe una copia de seguridad?, ¿el sistema cumple con las políticas internas y la regulación externa?
La revisión de Springer sobre democratización del desarrollo de software identifica explícitamente el Shadow IT y la deuda técnica entre los riesgos que deben considerarse conforme las plataformas low-code y no-code avanzan hacia la hiperautomatización y el desarrollo impulsado por intención. El resultado probable es la aparición de una nueva forma de Shadow Software: cientos o incluso miles de pequeñas herramientas, automatizaciones y agentes construidos dentro de una organización porque su costo individual es suficientemente bajo como para que los empleados puedan resolver problemas localmente, pero cuyo efecto acumulado produce una infraestructura que nadie comprende ni gobierna por completo.
La respuesta organizacional difícilmente puede consistir únicamente en prohibir estas herramientas. Si realmente resuelven necesidades que los sistemas tecnológicos centralizados no pueden atender con suficiente rapidez, el incentivo para utilizarlas continuará existiendo. El desafío será construir modelos de gobernanza capaces de preservar la velocidad del desarrollo distribuido sin renunciar al control sobre datos, permisos, identidad, seguridad, trazabilidad y mantenimiento.
La nueva brecha digital
Hablar de democratización puede crear la impresión de que la desigualdad tecnológica desaparecerá. Es más probable que simplemente cambie de lugar. Cuando utilizar una computadora requería conocer sistemas de línea de comandos, quienes dominaban esos entornos poseían una ventaja considerable. Las interfaces gráficas redujeron esa barrera, pero generaron otras. Internet disminuyó radicalmente el costo de publicar información, pero no convirtió automáticamente a todos sus usuarios en productores capaces de construir influencia o alcanzar una audiencia.
Algo semejante puede ocurrir con el desarrollo de software asistido por inteligencia artificial. La nueva separación quizá ya no exista únicamente entre quienes saben programar y quienes no, sino entre quienes saben convertir la inteligencia artificial en capacidad productiva y quienes se limitan a consumir sus resultados. Una persona capaz de comprender su propio trabajo como un conjunto de procesos, identificar tareas repetitivas, diseñar automatizaciones, estructurar información, evaluar correctamente una solución y combinar distintos servicios tendrá una ventaja significativa incluso si nunca memoriza la sintaxis completa de un lenguaje de programación.
La alfabetización tecnológica, por tanto, puede necesitar ampliar su significado. Tal vez ya no sea suficiente saber utilizar un procesador de texto, una hoja de cálculo o una plataforma específica. Será cada vez más importante comprender qué procesos pueden automatizarse, qué información debe o no delegarse a un modelo, cuándo es necesario verificar un resultado, qué permisos se están concediendo y qué consecuencias tiene conectar diferentes sistemas. La capacidad de construir estará más distribuida, pero también lo estará la responsabilidad sobre aquello que se construye.
Más software, no necesariamente menos desarrolladores
Buena parte de la discusión pública en torno a la inteligencia artificial y la programación se formula como una pregunta laboral: si una máquina puede escribir código, ¿cuántos programadores seguirán siendo necesarios? La pregunta es razonable, pero puede estar asumiendo implícitamente que la demanda de software de la sociedad permanecerá constante. La historia de otras tecnologías sugiere algo diferente: cuando el costo de producir algo cae de forma drástica, normalmente comenzamos a producir mucho más.
Si el costo de convertir una pequeña necesidad en una herramienta digital funcional disminuye lo suficiente, proyectos que anteriormente nunca habrían recibido presupuesto se vuelven viables. Una pequeña empresa que jamás habría contratado a un equipo de desarrollo para construir diez sistemas internos puede terminar operando decenas de automatizaciones. Una persona que nunca habría encargado una aplicación personalizada puede crear varias. Los equipos profesionales pueden experimentar con muchas más ideas antes de decidir cuáles merecen convertirse en productos robustos. El costo por unidad de software disminuye mientras se expande el universo de problemas considerados económicamente razonables de resolver mediante software.
El papel del desarrollador profesional casi con seguridad cambiará como consecuencia de este proceso. Determinadas tareas pueden automatizarse parcialmente y algunas formas de trabajo pueden perder valor relativo mientras otras adquieren mayor importancia. Pero reducir toda la transformación a una competencia entre “IA” y “programadores” deja fuera una consecuencia mucho más profunda: la frontera que define quién puede producir software se está desplazando.
De usuarios a creadores
La revolución más importante de la inteligencia artificial aplicada a la programación quizá no sea que un modelo pueda generar una función de Python, construir una página web o corregir un error de programación. Esas capacidades son técnicamente significativas, pero pertenecen a un fenómeno mayor: la reducción del costo necesario para convertir una intención en una capacidad digital.
Durante décadas aprendimos a vivir dentro de sistemas diseñados por otras personas. Modificamos nuestros procesos para adaptarlos a sus menús, columnas, formularios, flujos de trabajo y limitaciones. La siguiente etapa puede invertir parcialmente esa relación. En lugar de buscar constantemente una aplicación que se acerque lo suficiente a lo que necesitamos, tendremos cada vez más posibilidades de construir capas de software alrededor del propio problema.
Esto no elimina el desarrollo profesional de software, la ingeniería ni la necesidad de conocimiento técnico. De hecho, puede hacer que estas capacidades resulten todavía más importantes allí donde las consecuencias del error son mayores. Tampoco significa que cualquier persona pueda construir de forma segura cualquier sistema simplemente describiéndolo. La evidencia disponible sobre productividad, confiabilidad, confianza y seguridad exige una interpretación considerablemente más prudente.
Aun con estas limitaciones, el cambio continúa siendo profundo. Las plataformas low-code redujeron la cantidad de código necesaria para construir software; las plataformas no-code permitieron desarrollar ciertos sistemas sin interactuar directamente con el código; y los modelos generativos están comenzando a reducir también la distancia entre la intención y la implementación. La programación se convierte así, en determinados contextos, en algo menos exclusivamente parecido a una conversación entre un programador y una máquina y cada vez más en una conversación entre una persona, un sistema de inteligencia artificial y la infraestructura capaz de ejecutar aquello que ambos definen.
El resultado puede ser una época en la que crear pequeñas herramientas digitales deje de ser una actividad extraordinaria. Una época en la que una aplicación pueda tener un solo usuario, existir durante una semana y seguir siendo económicamente razonable. Una época en la que automatizar trabajo repetitivo deje de ser únicamente una decisión reservada a un departamento de tecnología y se convierta también en una capacidad individual.
Durante décadas, el usuario tuvo que adaptarse al software. La nueva democratización del desarrollo plantea la posibilidad contraria: que cada vez más software pueda adaptarse al usuario.
Referencias
Abendroth et al. The democratization of software engineering: evolution, definition, and the future of low-code and no-code platforms. Management Review Quarterly, Springer Nature, 2026. Ver publicación.
Stack Overflow. 2025 Developer Survey — AI. Datos sobre adopción de IA, confianza, productividad percibida y preocupaciones entre desarrolladores. Ver encuesta.
Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Ver estudio.
Becker, J., Rush, J., Barnes, B., & Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 2025. Ver estudio.
Chandra, S., & Tabachnyk, M. AI in Software Engineering at Google: Progress and the Path Ahead. Google Research, 2024. Ver publicación.
Google Cloud / DORA. 2025 State of AI-Assisted Software Development. Ver reporte.
National Institute of Standards and Technology. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models — NIST SP 800-218A. 2024. Ver publicación de NIST.
Ji, S., Jun, M., Wu, H., & Gelles, R. Cybersecurity Risks of AI-Generated Code. Center for Security and Emerging Technology, Georgetown University, 2024. Ver reporte.
Ur, B. et al. Trigger-Action Programming in the Wild: An Analysis of 200,000 IFTTT Recipes. CHI 2016. Ver publicación.
