De la promesa a la realidad
En cada conferencia sobre el futuro del trabajo, pitch de inversores, newsletter de innovación, la imagen se repite:
“la inteligencia artificial está democratizando el desarrollo”,
“ya no hace falta saber programar”,
“cualquiera puede construir software, aunque no sepa lo que es una API”.
La promesa es tentadora. Un mundo donde el conocimiento técnico deja de ser un privilegio, donde los límites entre diseñadores, negocios y desarrollo se disuelven, donde construir deja de ser una prerrogativa de ingenieros.
Es el sueño de Silicon Valley, reciclado en clave inclusiva.
Pero la promesa no siempre compila. Y cuando lo hace, suele venir con más warnings de los que las buenas prácticas de ingeniería recomendarían.
Por cada historia celebrada de alguien que armó su startup sin escribir una línea de código, hay otra en la que un flujo no-code se volvió inmanejable. Por cada nuevo constructor empoderado, hay errores silenciosos, procesos que no escalan, vulnerabilidades de seguridad que nadie auditó, estructuras que nadie diseñó pero que igual gobiernan el sistema.
Lo que parecía accesible, a veces se vuelve opaco. No por falta de acceso a la herramienta, sino porque el problema no fue bien pensado: faltó diseñar el flujo, modelar los datos, prever los límites. La interfaz cambió, sí. Pero las decisiones estructurales siguen ahí, y la complejidad no se deja esconder.
¿Es cierto que cualquiera puede programar hoy, o simplemente desplazamos el gatekeeping hacia otro lugar?
La conversación no se cierra con una celebración, ni con una denuncia. Se abre. Porque la promesa dice mucho, pero oculta aún más.
¿Qué significa realmente programar?
Durante décadas, programar fue escribir líneas de código en un lenguaje formal, compilarlas, testear, iterar. Era una práctica con fronteras claras, visible en editores de texto, en IDEs, en terminales.
Pero esas fronteras se diluyen. Hoy, programar puede significar arrastrar bloques en una interfaz visual, construir una lógica en Notion o Airtable, dictarle intenciones a un copiloto. Ya no hay que escribir “if/else” para decidir. Basta con decir “cuando pase esto, hacé lo otro”.
La gramática cambió.
¿Y la lógica?
Porque aunque la sintaxis sea más amable, el acto de programar sigue implicando una forma de pensamiento: entender un sistema, abstraer sus partes, modelar relaciones, prever consecuencias. Automatizar sin comprender qué se está automatizando es construir sin planos.
Detrás de cada sistema funcional —aunque haya sido armado en Zapier o con un copiloto— hay decisiones que organizan el comportamiento, gestionan excepciones, modelan los datos, piensan en el tiempo y la escala. No siempre son visibles. Pero están.
Reducir la programación a escribir instrucciones, aunque sean en lenguaje natural, es olvidar que el núcleo de la práctica no está en las teclas, sino en la cabeza: en cómo se piensa, se modela, se diseña el sistema antes de escribir una línea de código.
El nuevo gatekeeping: cognitivo, no textual
Durante años, el acceso al desarrollo de software estuvo custodiado por la sintaxis: aprender a programar era aprender a escribir en un lenguaje extraño, dominar sus reglas, entender sus errores crípticos. El umbral era visible y alto.
Hoy, ese umbral parece haberse derrumbado. Las herramientas no-code eliminan la necesidad de escribir código. Los copilotos completan funciones enteras a partir de frases sueltas. Ya no hace falta saber cómo se declara una variable, ni cómo se importa una librería.
Pero algo persiste. Porque aunque la puerta de entrada sea más baja, la complejidad no desapareció: solo cambió de lugar.
Ya no se excluye por no conocer una palabra clave. Se excluye —sin querer o sin notarlo— por no saber cómo pensar un sistema: cómo se estructura una lógica, cómo se modela un flujo, cómo se diseñan excepciones. El gatekeeping ya no es textual. Es arquitectónico.
La barrera de hoy no está en la sintaxis, sino en la capacidad de imaginar una arquitectura antes de que exista código, de trazar un diseño antes de que haya sistema.
Brooks lo dijo con claridad en The Mythical Man-Month, hace medio siglo: el fracaso de muchos sistemas no está en la codificación, sino en la ausencia de un diseño conceptual unificado. Esa advertencia hoy vuelve con fuerza: una aplicación no fracasa por usar no-code, sino porque nadie pensó su coherencia interna. Porque las decisiones se acumularon sin visión de conjunto. Porque nadie supo decir “esto no escala”.
Y Engelbart, desde otro ángulo, ya advertía que aumentar las capacidades humanas no era solo cuestión de darles herramientas más rápidas, sino de diseñar sistemas completos de interacción: lenguaje, metodología, formación. Hoy podemos arrastrar bloques en una interfaz visual, pero si no entendemos la lógica subyacente, no estamos aumentando nuestra capacidad de pensar sistemas: solo estamos ejecutando sin comprender.
El lenguaje natural nos abrió la puerta. Pero el lenguaje del diseño —ese que exige no solo paciencia y visión, sino también conocimiento real de ingeniería de software— sigue siendo el que decide qué entra y qué se queda afuera.
Y sin embargo… algo está cambiando
Sería injusto, y quizás ciego, negar que algo profundo se está moviendo. Personas sin formación técnica están resolviendo problemas que antes requerían equipos completos. Herramientas como Zapier, Retool, Notion, Airtable o los propios copilotos de código permiten construir prototipos, automatizar flujos, conectar servicios.
Pequeñas operaciones que antes exigían levantar un servidor, escribir en dos lenguajes y entender múltiples capas, hoy se resuelven en un par de clics.
El acceso es real, y el empoderamiento, también.
En muchas organizaciones, esto está dando lugar a algo nuevo: equipos mixtos, donde diseñadores, analistas, expertos en negocio o incluso usuarios finales pueden construir sin pedir permiso. Se rompe la dependencia de los cuellos de botella tradicionales. Se crean MVPs sin esperar ciclos de desarrollo. Se itera más rápido.
Desde América Latina, esta apertura tiene un significado particular. En contextos donde el acceso a talento técnico especializado es limitado, o donde los presupuestos no alcanzan para equipos grandes, poder construir con menos recursos no es solo eficiencia: es posibilidad. Esa creatividad ante la restricción, esa capacidad de hacer más con menos que nos define como región, encuentra en estas herramientas una amplificación real. No se trata de competir con el Silicon Valley replicando sus estructuras, sino de aprovechar lo que siempre supimos hacer: resolver con ingenio donde otros necesitan abundancia.
Pero esas victorias no se dan porque el conocimiento técnico haya dejado de importar. Se dan porque alguien, en algún momento, entendió el modelo de datos, configuró el entorno, delimitó los bordes del sistema. Y más temprano que tarde, ese MVP va a necesitar a alguien que lo piense técnicamente: para escalar, mantenerse o integrarse a algo más grande. Cada equipo puede decidir cuándo lo hace. Pensar que nunca hará falta es el error que más caro se paga.
La promesa de democratización no es falsa. Pero tampoco es mágica. Lo que está emergiendo no es un mundo donde cualquiera lo puede todo, sino uno donde la colaboración entre formas de pensamiento se vuelve esencial. El futuro no es sin ingenieros. Pero tampoco es solo de ellos.
¿Qué hacer con esta tensión?
No hay que resolver la tensión. Hay que aprender a habitarla.
La promesa de que todos pueden construir no es falsa, pero tampoco es plena. El riesgo no está en intentarlo, sino en suponer que ya no hace falta entender lo que se construye. Ni todo puede ser resuelto sin ingenieros, ni todo debe ser delegado a ellos.
En lugar de ocultar la complejidad, deberíamos compartirla. Hacer del conocimiento técnico algo comprensible, sin volverlo trivial. Y reconocer que democratizar no es eliminar las diferencias, sino diseñar espacios donde esas diferencias puedan colaborar sin jerarquías invisibles.
No se trata de elegir entre programadores y no programadores. Se trata de diseñar equipos que piensen juntos, en una mesa redonda donde la mejor idea —no el rol— es la que guía.
Algunas ideas concretas para quienes lideran, enseñan, o diseñan productos:
Cultivar la curiosidad técnica, no solo la autonomía operativa. Fomentar el aprendizaje compartido, donde quien construye con no-code también se pregunta cómo funciona por debajo, qué límites tiene, qué pasaría si esto crece diez veces. La curiosidad genuina es el antídoto contra la ilusión de autonomía total: nos recuerda que siempre hay más por entender, y que eso no es una debilidad, sino una oportunidad.
Entrenar en pensamiento crítico y computacional, más que en técnicas de prompting. No basta con saber usar una herramienta: hay que saber cuándo usarla, cuándo no, y cuándo pedir ayuda. El pensamiento crítico permite evaluar si una solución es sostenible, si un atajo hoy será deuda técnica mañana, si una automatización realmente resuelve el problema o solo lo esconde. Y el pensamiento computacional —esa capacidad de modelar, abstraer, descomponer— es lo que separa construir de acumular parches.
Diseñar sistemas donde lo técnico se explicita y se comparte, en lugar de esconderse tras capas de complejidad. Hacer del conocimiento técnico algo comprensible, sin volverlo trivial. Que quien usa una herramienta no-code pueda ver —y entender— qué decisiones estructurales está tomando. Y que quien tiene conocimiento técnico profundo lo comparta sin convertirlo en un idioma secreto.
Fomentar la agencia, pero con responsabilidad. Que más personas puedan construir sin pedir permiso es poderoso. Pero la agencia sin conciencia de límites lleva al caos. La verdadera agencia no es solo poder hacer, sino saber cuándo lo que hicimos necesita evolucionar, cuándo pedir ayuda, cuándo reconocer que llegamos al borde de nuestra competencia. Construir con autonomía, pero con humildad técnica.
Y sobre todo: construir con la conciencia de que en lo técnico también opera un lenguaje. Diseñar no es opcional: incluso cuando creemos no estar tomando decisiones técnicas, las estamos tomando igual. Toda omisión es una decisión. Todo atajo configura una forma de operar. Y toda decisión —incluso las invisibles— tiene consecuencias en el comportamiento del sistema.
Quizás algún día la promesa sea realidad plena. Pero hoy, nos toca habitar la tensión: entre la libertad de construir y la responsabilidad de entender, entre la autonomía individual y la necesidad de colaboración, entre el acceso democratizado y la complejidad irreductible. No se resuelve eligiendo un bando. Se resuelve aprendiendo a pensar juntos.
Porque en el fondo, la pregunta no es si cualquiera puede programar. La pregunta es: ¿qué tipo de relación queremos construir con lo técnico? ¿Una donde lo ocultamos hasta que se rompe, o una donde lo compartimos para que todos podamos mejorarlo? ¿Una donde “saber programar” sigue siendo un privilegio, o una donde entender sistemas se vuelve parte de la alfabetización común?
¿Te encontraste alguna vez diseñando sin saber que estabas diseñando? ¿Te ilusionaste con la autonomía total de una herramienta no-code, hasta que algo falló y necesitaste ayuda técnica? ¿Formás parte de un equipo donde conviven distintas formas de pensar lo tecnológico? ¿Cómo hacen para que esa diversidad sea potencia, y no fricción?
Me interesa saber cómo lo vivís vos, desde tu lugar. Este texto no busca tener la última palabra, sino abrir un diálogo. Compartí tus experiencias, dudas, acuerdos o contrapuntos. Todo lo que nos ayude a pensar mejor, juntos.