Todos somos programadores (y eso debería preocuparnos un poco)
Las herramientas de IA permiten construir un sistema sin saber programar. Eso es poderoso, y abre riesgos que solo se ven cuando ya es tarde.
Felipe UribeCTO · 
El panel de Excel que funcionó demasiado bien
Alguien en tu empresa (o quizás tú mismo) abre Claude un martes por la tarde, describe lo que necesita, y dos horas después tiene un panel web que lee archivos Excel, cruza datos y muestra un resumen en pantalla. Sin haber escrito una línea de código antes. Sin haber contratado a nadie.
Eso es real. No es hype. Y es, en muchos sentidos, algo extraordinario.
El problema no es que funcione. El problema es lo que pasa después, cuando ese panel empieza a usarse todos los días, cuando alguien sube un archivo con un formato distinto, cuando dos personas lo usan al mismo tiempo, cuando los datos que procesa empiezan a alimentar decisiones de negocio reales. Ahí aparece una brecha que nadie vio venir, porque nadie tenía el mapa para verla.
La paradoja de la democratización técnica
Hay un patrón que se repite en este momento: los que menos saben, más seguros están. Los que más saben, más conscientes son de lo que no entienden.
No es un juicio moral. Es casi una consecuencia matemática de cómo funciona el conocimiento.
Cuando no sabes lo que hay detrás de un sistema (autenticación, manejo de errores, concurrencia, persistencia de datos, seguridad), tampoco sabes qué preguntas hacerte. El panel funciona, el MVP corre, el cliente paga. ¿Qué podría salir mal?
Mientras tanto, un desarrollador senior que lleva quince años construyendo sistemas mira la misma demo de Claude Code y piensa: ¿pero cómo maneja los estados de error? ¿Qué pasa si la sesión expira a mitad del proceso? ¿Dónde están guardados esos datos y quién tiene acceso? No porque sea pesimista, sino porque ha visto exactamente lo que pasa cuando esas preguntas no tienen respuesta.
Este fenómeno tiene nombre: el efecto Dunning-Kruger. En términos simples, las personas con poco conocimiento sobre un tema tienden a sobreestimar su competencia, mientras que los expertos tienden a subestimar la suya porque son más conscientes de la complejidad real. Aplicado al código generado con IA, el efecto se amplifica: la herramienta es tan buena que el resultado parece profesional aunque los cimientos no lo sean.
Qué sabe la IA y qué no sabe
Claude, GPT-4, Gemini: todos son extraordinariamente buenos generando código que parece correcto. Y muchas veces lo es, para el caso feliz: el input esperado, el flujo normal, el usuario que hace exactamente lo que se supone que debe hacer.
Donde el código generado empieza a fallar es en los bordes:
- ¿Qué pasa si el archivo Excel tiene 200.000 filas en vez de 500?
- ¿Qué pasa si dos usuarios suben archivos al mismo tiempo?
- ¿Qué pasa si alguien sube un archivo malicioso?
- ¿Dónde quedan guardados los datos procesados y por cuánto tiempo?
- ¿Quién puede ver qué?
La IA no omite estas cosas por descuido: las omite porque nadie las pidió. Y quien no sabe que esas preguntas existen, no las va a pedir.
Esto no es un argumento contra usar IA para construir sistemas. Es un argumento para entender qué estás construyendo realmente.
El espectro real de lo que se está construyendo
No todo sistema tiene el mismo riesgo. Vale la pena ubicarse en este espectro antes de decidir cuánta informalidad es aceptable:
Bajo riesgo: automatización interna desechable Un script que consolida reportes para uso propio. Si falla, lo vuelves a correr. Los datos no son sensibles. Nadie más depende de él. Aquí el vibe coding es perfectamente razonable.
Riesgo medio: herramienta interna que usan varias personas El panel de Excel que empezó siendo tuyo y ahora lo usa el equipo de finanzas. Ya hay dependencia operacional. Un error puede generar decisiones incorrectas. Aquí conviene al menos revisar qué hace el código y tener un respaldo.
Alto riesgo: producto que toca clientes o datos sensibles Un MVP que procesa pagos, almacena información de usuarios, o alimenta un proceso crítico del negocio. Aquí la informalidad tiene consecuencias reales: legales, reputacionales, operacionales. El hecho de que funcione en producción no significa que esté bien construido, y antes de seguir conviene comparar las cuatro opciones reales para resolverlo.
La trampa es que los sistemas no nacen en la categoría de alto riesgo: llegan ahí después de que alguien decidió que "por ahora está bien así".
Lo que los expertos están viendo
Hay algo llamativo en las conversaciones técnicas de este momento: los desarrolladores más experimentados son los que expresan más incertidumbre sobre hacia dónde va esto, no menos.
No es nostalgia ni resistencia al cambio. Es que entienden, mejor que nadie, la distancia entre "esto genera código" y "esto entiende sistemas". La IA puede escribir una función de autenticación correcta. No puede decirte si tu arquitectura va a sostener diez mil usuarios concurrentes, ni si el modelo de datos que elegiste va a ser un problema en seis meses cuando necesites agregar una nueva entidad.
Esa brecha, entre generar código y diseñar sistemas que sobrevivan, es exactamente la que se vuelve costosa cuando el sistema empieza a tener más usuarios y más datos.
Qué hacer ahora
Si estás construyendo algo con herramientas de IA, o evaluando hacerlo, hay tres preguntas concretas que conviene responderte antes de seguir:
1. ¿Cuál es el costo real si esto falla? No el costo de reescribirlo, sino el costo operacional, reputacional o legal de que falle en producción. Si la respuesta es "bajo", sigue adelante. Si la respuesta te genera incomodidad, eso es información.
2. ¿Alguien con experiencia técnica revisó lo que se construyó? No necesariamente para reescribirlo, sino para identificar los puntos ciegos. Una revisión de una hora por alguien que sabe lo que busca puede evitar problemas que tardan semanas en resolverse.
3. ¿Tienes un plan para cuando esto se quede corto? La mayoría de los sistemas vibe-codeados no fallan el día uno. Fallan cuando tienen que aguantar más volumen, cuando cambian los requisitos, cuando alguien que no los construyó tiene que mantenerlos. Si no hay nadie que pueda sostener eso, el riesgo es terminar con un sistema que nadie puede mantener, y vale la pena nombrarlo ahora.
La democratización del desarrollo es genuinamente buena. Que más personas puedan construir cosas que antes requerían años de formación es un avance real. Pero la conciencia de lo que se está construyendo no se democratizó al mismo ritmo, y esa brecha es la que vale la pena cerrar.