Cada vez es más fácil escribir código.
Hoy alguien puede abrir un editor, describir lo que quiere en lenguaje natural, y obtener una aplicación funcional en minutos. Herramientas de IA, frameworks más amigables, plantillas, tutoriales infinitos. Entrar a programar nunca había sido tan accesible.
Y eso parece una buena noticia.
Pero esa facilidad trae una pregunta incómoda: si entrar es tan fácil, ¿la base de quienes entran también se vuelve más débil?
Hablo de fundamentos.
Mucha gente hoy aprende a programar logrando resultados antes de construir comprensión. Una API funciona, una página carga, una feature sale. Pero detrás de eso muchas veces faltan cosas más profundas: entender por qué falla algo, qué hace realmente una abstracción, qué implica una decisión de diseño, por qué cierto código escala mal o por qué se rompe en producción.
El conocimiento efímero de la asistencia con IA
Hay una diferencia importante entre entender algo en el momento y realmente aprenderlo.
Cuando trabajas con una herramienta de IA, muchas veces ocurre esto:
- lees una solución
- la reconoces
- incluso puedes explicarla superficialmente
Y eso da la sensación de comprensión.
Pero esa sensación puede ser engañosa.
Porque no pasaste por el proceso que normalmente consolida el conocimiento: equivocarte, explorar alternativas, construir la solución paso a paso. En lugar de eso, recibiste una versión ya resuelta.
El resultado es un tipo de conocimiento frágil.
Sabes seguirlo, pero no sabes reconstruirlo.
Y esa diferencia se nota más adelante.
Cuando vuelves a enfrentarte a un problema similar, muchas veces aparece el mismo bloqueo. No porque no lo hayas visto antes, sino porque no lo internalizaste.
Sin esfuerzo cognitivo real —sin tener que recordar, fallar, ajustar— el cerebro no consolida bien la información. Lo que obtienes es reconocimiento, no dominio.
Puedes avanzar muy rápido… pero con una base que no necesariamente te sostiene cuando el problema cambia.
Vibecoding, “slop” y la ilusión de calidad
Con herramientas como el vibecoding, producir código funcional es extremadamente fácil con los suficientes tokens.
El problema es que “funcional” no es un buen indicador de calidad.
Hoy un agente puede generarte algo que:
- corre
- pasa un caso básico
- cumple con lo que pediste
Pero eso no significa que sea buen código.
Puede ser:
- difícil de mantener
- inconsistente
- ineficiente
- frágil ante cambios
- lleno de decisiones que nadie entiende
En otras palabras, puede ser slop… que funciona.
Y si no tienes criterio —lo que muchos llaman taste— o estándares claros, ese tipo de código no solo pasa, sino que se acumula.
Ahí es donde sí aparece una degradación real.
No porque la herramienta sea mala, sino porque elimina fricción sin reemplazarla por juicio.
Antes, llegar a una solución requería suficiente esfuerzo como para cuestionar partes del proceso. Hoy puedes saltarte ese proceso por completo.
El resultado es claro:
la barrera para producir código bajó… pero la barrera para producir buen código no.
Y cuando ambas se separan, lo que crece más rápido no es la calidad, es el volumen.
Entonces… ¿necesitamos gatekeeping?
No creo que la solución sea hacer la entrada más difícil.
Hacer más dura la entrada no garantiza mejores programadores. Solo garantiza menos acceso. Históricamente, mucha gente brillante entró precisamente porque el camino estaba abierto, no porque pasó un filtro elitista.
El problema es otro.
Nunca había sido tan fácil parecer productivo sin entender realmente lo que estás haciendo.
Y ahí es donde entra algo interesante.
Tal vez no estamos eliminando el gatekeeping. Tal vez solo lo estamos moviendo.
Antes, el filtro estaba al principio. Muchos no podían ni entrar.
Ahora, casi cualquiera puede empezar. Casi cualquiera puede construir algo que funcione. Pero el verdadero filtro aparece después, cuando el proyecto crece, cuando el comportamiento no es obvio, cuando el error no tiene una respuesta copiable, cuando hay que depurar, mantener, diseñar, decidir.
En ese momento, una base débil empieza a notarse.
Entonces quizá el nuevo gatekeeping no está en el acceso. Está en la profundidad.
No te filtra el editor. No te filtra el lenguaje. No te filtra la sintaxis.
Te filtra la realidad.
Cierre
La industria no tiene un problema de acceso. Tiene un problema de profundidad.
Algunas ideas las obtuve de este video por gonz:
Estamos optimizando para que más gente escriba código, pero no necesariamente para que más gente entienda sistemas.
Y esas dos cosas no son lo mismo.
El problema no es que ahora cualquiera pueda escribir código.
Es que ahora cualquiera puede crear código que nadie debería haber escrito.
Y quizá lo más peligroso no es eso.
Quizá lo más peligroso es que, al principio… funciona.