Durante quince años la respuesta a “quiero montar esto” fue siempre la misma: aprende a programar, o paga a alguien que sepa. Esa frase ya no es cierta.
Lo digo desde el otro lado. Soy estudiante de ingenieria informática y administrador de sistemas, me dedico a infraestructura y seguridad, y llevo años escribiendo el código y el YAML que ahora un modelo genera en treinta segundos. No me molesta. Me parece la mejor noticia de la década para cualquiera que tenga un problema de negocio y ninguna forma de resolverlo.
Pero hay una versión de este discurso que me pone de los nervios: la de que “ya no hace falta saber nada”. Eso es mentira, y es una mentira cara. La barrera no ha desaparecido. Se ha movido, y se ha movido a un sitio donde casi nadie está mirando.
Lo que realmente ha caído: el coste de la primera versión
Conviene ser preciso sobre qué es lo que ha cambiado, porque el hype lo mezcla todo.
Lo que ha colapsado es el coste de llegar de cero a una primera versión que funciona. Antes ese tramo eran semanas: entorno, dependencias, boilerplate, autenticación, un CRUD, un deploy. Hoy son horas, y en muchos casos ni siquiera hace falta escribir código.
Esto no es una intuición mía. Microsoft integró Copilot en Power Apps, Power Automate y Power Virtual Agents con el objetivo explícito de que la gente construya soluciones describiéndolas en lenguaje natural (Microsoft News). ServiceNow lleva años usando el término “desarrollador ciudadano” para describir a la persona de negocio que se construye sus propias aplicaciones sin pasar por IT (ServiceNow). Y el efecto agregado es el que describe MyNextDeveloper: una explosión en la cantidad y variedad de aplicaciones que se crean, porque el cuello de botella dejó de ser la escritura de código.
La palabra que se usa para esto es “democratización” y, aunque suene a folleto, describe bien lo que pasa. El acceso se ha abierto.
Mi propia evidencia
No hablo de esto en abstracto. Buena parte de lo que uso a diario lo he construido así:
- Mi sistema de finanzas personales clasifica miles de movimientos bancarios con un modelo barato y los escribe en Notion. El “programa” son unos cientos de líneas de Python que en su mayor parte no escribí a mano. Lo conté entero en cómo automaticé mis finanzas con Notion e IA.
- En WhiteLabs monto automatizaciones B2B en n8n. Flujos que hace cinco años habrían sido un microservicio con su repo, su pipeline y su on-call, hoy son un lienzo con nodos y una llamada a un modelo en medio.
- Este blog es Astro sobre Cloudflare Pages. El contenido lo escribo yo; el andamiaje lo generó en gran parte un agente corriendo en local contra el repositorio.
Nada de esto es una demo. Está en producción, lo uso, y si se rompe me molesta a mí.
Así que sí: si tienes un negocio y una idea concreta de qué quieres que haga el software, hoy puedes construirlo. Esa parte del discurso es real.
Dónde se rompe el cuento
Ahora la parte que nadie pone en el thread de LinkedIn.
Todo lo que he descrito arriba tiene una característica común: son sistemas pequeños, de un solo usuario o de un equipo, sobre datos que no son críticos para terceros. En cuanto sales de ese perímetro, empiezan a aparecer las facturas.
El día 2 no lo genera nadie
La IA te da el día 1. El día 2 —el día en que eso lleva ocho meses corriendo, se ha llenado de datos, y falla un martes a las tres de la mañana— sigue siendo tuyo.
El modo de fallo que más me he encontrado en automatizaciones no es especialmente glorioso: un flujo de n8n sincroniza datos entre dos sistemas cada hora, funciona durante semanas, y un día el endpoint de origen empieza a devolver un 200 OK con el cuerpo vacío en lugar de un error. El flujo no falla: procesa cero registros y sigue tan contento. No hay alerta de “cero es sospechoso”, porque nadie escribe esa alerta cuando el objetivo es que funcione. Te enteras días después, mirando otra cosa.
Ningún generador de código te avisa de eso. La lógica del camino feliz es lo que un modelo hace brillantemente. La pregunta “¿qué pasa si esto se degrada en silencio?” no está en el prompt de nadie.
Lo mismo con las copias de seguridad. Yo tengo un NAS con backups cifrados hacia Hetzner con Restic, y aprendí por las malas la única lección que importa aquí: un backup que no has restaurado nunca no es un backup, es una carpeta. La primera vez que hice un restic restore de prueba en serio, descubrí que uno de los repositorios llevaba semanas sin recibir snapshots nuevos porque el cron se ejecutaba en un contexto sin las credenciales cargadas. Silencioso, otra vez.
Vendor lock-in: la factura que llega tarde
El análisis más honesto que he leído sobre esto lo tiene Unico Connect, que reconoce sin rodeos tres límites: escalabilidad, lock-in y la dificultad de migrar. Y el segundo es el que más gente subestima.
Cuando construyes sobre una plataforma no-code, la lógica de tu negocio no vive en un fichero que puedas leer. Vive en la representación interna de esa plataforma. No hay git diff. No hay code review. No hay “me llevo esto a otro sitio” sin reescribirlo entero.
Esto no es un problema teórico de arquitectura: es un problema de poder. El día que suban el precio, cambien el modelo de licencia o cierren el producto, tu capacidad de negociación es cero, porque el coste de irte es reconstruir. Es exactamente la misma dinámica que me llevó a montarme un NAS y sacar mis datos de la nube de terceros: no es paranoia, es no querer que una decisión de otro me deje sin operación.
La mitigación no es “no uses no-code”. Es: mantén la lógica que te da ventaja competitiva en un sitio del que puedas salir, y usa la plataforma para el pegamento.
Seguridad: la superficie que no ves
Esta es la parte que más me preocupa, por deformación profesional.
Cuando montas una aplicación con una herramienta visual y un asistente, la superficie de ataque no desaparece: se vuelve invisible. Sigue habiendo un webhook público. Sigue habiendo un token de un tercero guardado en algún sitio. Sigue habiendo permisos OAuth concedidos a integraciones que instalaste una tarde y no volviste a mirar.
La diferencia es que ahora no hay nadie en el flujo que sepa mirar eso. El paper de la Universidad de Aalborg sobre low/no-code y IA generativa lo señala en su apartado de limitaciones: estas plataformas aceleran, pero arrastran problemas heredados de gobernanza y control.
Y no es un riesgo hipotético. Ya escribí sobre el hackeo de Vercel y la cadena de suministro vía OAuth: el vector no fue un fallo de código, fue un token de integración con más permisos de los necesarios. En un stack no-code tienes más integraciones, no menos. Multiplicas ese vector y le quitas al único que sabía auditarlo.
El mínimo que yo aplicaría, y que no requiere ser ingeniero:
- Ningún secreto en el cuerpo de un nodo, un prompt o un mensaje de chat. Nunca.
- Un inventario escrito de qué integraciones tienen acceso a qué. Una hoja de cálculo sirve.
- Revisión trimestral de tokens OAuth y revocación de todo lo que no reconozcas.
- Datos personales o de clientes: pregúntate dónde acaban físicamente antes de conectar nada, no después.
El techo de control
Hay un cuarto límite, más sutil. AppBuilder lo describe bien: las funciones asistidas por IA tienden a encerrarte en las sugerencias que el sistema genera, y quitarte el control fino sobre el resultado. Tú describes la intención, la herramienta decide la implementación, y cuando necesitas que haga exactamente otra cosa, no hay palanca.
Ashish Rangnekar lo plantea como una redefinición del debate no-code vs low-code vs desarrollo a medida: no-code no queda obsoleto, lo que cambia es dónde está la frontera de la decisión. Y coincido: el error no es elegir no-code, el error es no saber que estás eligiendo.
La nueva barrera se llama criterio
Aquí está mi tesis, y es lo único que me interesa que te lleves.
La barrera nunca fue la sintaxis. La sintaxis era la parte enseñable, la parte que se automatiza. La barrera real siempre fue saber qué construir, cómo tiene que comportarse cuando algo va mal, y qué pasa el día que crezca. Eso no lo ha automatizado nadie, y no está cerca de estarlo.
Un modelo escribe cualquier función que le pidas. Lo que no hace es decirte que la función que estás pidiendo es la equivocada.
Por eso el trabajo se ha desplazado hacia arriba: de escribir código a especificar comportamiento. Es exactamente el flujo que describí en Spec Driven Development: antes de pedir implementación, defines reglas, caminos felices y —sobre todo— caminos tristes. La IA implementa; el criterio lo pones tú.
Y esto es una buena noticia para el no programador, no una mala. Porque el criterio de negocio ya lo tienes. Sabes qué es una devolución válida, qué cliente es rentable, qué proceso te está costando dinero. Eso, que era el input más difícil de transmitir a un desarrollador externo, ahora es el input principal.
Lo que te falta no es programar. Es saber hacerle a un sistema las preguntas incómodas.
Cómo lo decido yo: tres preguntas antes de elegir herramienta
No tengo una regla ideológica. Tengo tres preguntas, y las respuestas mandan.
1. ¿Qué pasa si esto desaparece mañana?
Si la respuesta es “pierdo una tarde”, constrúyelo con lo que sea más rápido. Si es “se para la facturación”, no lo construyas sobre algo que no puedas exportar.
2. ¿Quién lo va a operar dentro de seis meses?
No quién lo construye: quién lo arregla. Si la respuesta es “yo, que no sé programar”, entonces necesitas una herramienta que falle de forma ruidosa y visible, aunque sea menos potente. La observabilidad importa más que la elegancia.
3. ¿Este trozo es mi ventaja competitiva o es fontanería?
La fontanería —notificaciones, sincronizaciones, formularios, informes— a no-code sin remordimientos. Lo que te diferencia, en código que puedas versionar.
Esto acaba siendo, en la práctica, una arquitectura híbrida. Es justo la conclusión a la que llega uCertify comparando IA no-code con desarrollo tradicional: el debate no es cuál es mejor, es cuál encaja en cada caso, y el enfoque mixto es el que equilibra velocidad, coste y control.
En mi caso el reparto queda así:
Fontanería (n8n, plataformas gestionadas)
- sincronizaciones entre SaaS
- notificaciones y alertas
- informes periódicos
Núcleo (código en Git, Docker, mi infraestructura)
- lógica de negocio propia
- tratamiento de datos personales
- todo lo que tenga que sobrevivir a un cambio de proveedorY un requisito transversal, aplique quien aplique: si un proceso corre solo, tiene que avisarme cuando no hace nada. El silencio es el modo de fallo por defecto de todo sistema automatizado.
# La alerta que casi nadie escribe y que ahorra semanas de datos corruptos
# Regla: si el flujo procesó 0 registros en una ejecución que debería tener datos, es un incidente.
if [ "$PROCESSED" -eq 0 ]; then
notify "sync: 0 registros procesados — revisar origen"
exit 1
fiQué significa esto para los negocios a medida
La consecuencia interesante no es que más gente vaya a programar. Es que se vuelve rentable construir software para problemas que antes no daban el número.
Piensa en el taller, la clínica, la asesoría, el pequeño distribuidor. Todos tienen un proceso raro y propio que ningún SaaS cubre bien, y todos han vivido con la misma disyuntiva: o te adaptas a la herramienta genérica, o pagas un desarrollo a medida que no se amortiza. Ese hueco —problemas reales demasiado pequeños para justificar un proyecto— es donde la IA cambia la economía de verdad.
Ahí es donde veo la oportunidad, y no está en “hacer apps”. Está en ser la persona que entiende un sector lo suficiente como para especificar bien el problema, y que además sabe operar lo que construye. Esa combinación era carísima. Ahora está al alcance de una persona sola.
Lo que no ha cambiado es que el software hay que mantenerlo. Quien venda lo contrario está vendiendo el día 1 y cobrando por el día 2.
Conclusión
Programar ya no es la barrera. Lo firmo.
Pero la conclusión honesta no es “cualquiera puede hacer software”. Es: cualquiera puede hacer la primera versión, y casi nadie está preparado para la segunda. Entre las dos hay backups que restaurar, tokens que revocar, fallos silenciosos que detectar y decisiones de dónde vive tu lógica que te van a condicionar durante años.
Si eres no programador y estás empezando: adelante, en serio. Constrúyelo. Pero no confundas la ausencia de código con la ausencia de sistema. Empieza por definir cómo tiene que comportarse cuando falle, no cuando funcione.
Y si eres desarrollador y esto te suena a amenaza, mi lectura es la contraria. Lo que se ha devaluado es teclear. Lo que se ha revalorizado es exactamente lo que hacemos cuando nadie nos mira: pensar en el fallo antes de que ocurra.
Nos vemos en la red.