Llevo más de dos décadas construyendo para la web. He pasado por la era de jQuery, por el cansancio de los frameworks, por modas que prometían reescribirlo todo y por más titulares sobre la muerte de Ruby on Rails de los que merece la pena contar.
Y aun así lo tengo bastante claro: si estás pensando en entrar en el desarrollo web, o si ya estás dentro y te preguntas hacia dónde va el oficio, este es el momento.
No porque las herramientas sean más brillantes. No porque haya una tecnología nueva que debas aprender esta semana. Sino porque el trabajo ha cambiado de una forma profunda, y ha cambiado a nuestro favor.
Nunca fue solo escribir código
Tardé años en interiorizarlo: el desarrollo web nunca iba realmente de escribir código. Iba de resolver problemas para personas. El código era el medio.
Nadie te contrata porque escribas Ruby elegante o TypeScript impecable. Te contratan porque sus usuarios necesitan algo: un flujo de trabajo que no sea frustrante, una forma más rápida de cobrar, un panel que explique qué está pasando, una herramienta que reduzca errores o tiempo perdido.
El trabajo consiste en entender qué hace falta y convertirlo en algo real.
Durante mucho tiempo, la segunda parte consumía casi toda la energía. Podías pasar tres días peleándote con CSS Grid, depurando una condición de carrera o montando una pantalla administrativa que era necesaria pero poco interesante. Cuando por fin llegaba a producción, a veces ya se había perdido de vista el problema que se quería resolver.
Esa proporción se ha invertido.
La IA escribe mucho; tú sigues pensando
Los asistentes de código ya escriben una parte enorme del trabajo repetitivo. Y lo hacen razonablemente bien. No son perfectos: todavía hace falta revisar, refactorizar, decidir arquitectura, entender el dominio y detectar cuándo una solución es demasiado frágil. Pero la época de perder una tarde entera montando una interfaz CRUD desde cero está terminando.
Eso cambia el valor del tiempo de un desarrollador.
Ahora hay más espacio para validar requisitos antes de escribir una línea. Para preguntarse si la solución propuesta es realmente la adecuada. Para pensar en casos límite, accesibilidad, rendimiento, seguridad, permisos, datos expuestos y mantenimiento.
Es decir: en todo lo que separa una funcionalidad que existe de una funcionalidad buena.
La IA no ha sustituido a los desarrolladores. Ha quitado parte del trabajo mecánico que impedía a muchos desarrolladores hacer su trabajo de verdad.
Iterar rápido es una ventaja enorme
Aquí es donde el cambio se vuelve especialmente interesante. Cuando generar código lleva minutos en lugar de días, puedes construir varias soluciones para el mismo problema.
No como ejercicio teórico. De verdad.
Puedes preparar dos enfoques, enseñárselos a usuarios reales, instrumentarlos y dejar que los datos ayuden a decidir. Antes, un test A/B era algo reservado a empresas con equipos de crecimiento, analítica, diseño e ingeniería dedicados. Hoy, un solo desarrollador puede montar variantes, medir resultados y ajustar el producto a partir de lo que ocurre en producción.
Eso cambia la dinámica de producto.
Menos "creo que este enfoque es el correcto". Más "vamos a comprobarlo".
La IA no elimina la necesidad de criterio. Pero sí reduce el coste de probar alternativas razonables. Y cuando el coste de experimentar baja, tomar decisiones a ojo empieza a parecer una mala costumbre, no una necesidad.
La frontera entre backend y frontend se está estrechando
Hay otra consecuencia incómoda: la separación rígida entre "desarrollador backend" y "desarrollador frontend" está perdiendo fuerza.
Esas etiquetas tenían mucho sentido cuando cada capa requería tanta especialización solo para ser productivo que moverse fuera de tu zona era caro. La persona de frontend que no tocaba bases de datos y la persona de backend que no tocaba CSS podían encajar en equipos grandes, con mucha coordinación y una división clara de responsabilidades.
Pero las herramientas han cambiado.
Hoy puedes levantar una aplicación Rails en muy poco tiempo, escribir una funcionalidad completa, probarla, ajustar la interfaz y desplegarla durante la misma tarde. La IA ha bajado la barrera para trabajar en toda la pila, no porque convierta a cualquiera en experto en todo, sino porque elimina mucha fricción operativa.
El mercado se mueve hacia perfiles capaces de entender el sistema completo. Personas que pueden hacerse cargo de una funcionalidad de extremo a extremo. Que no necesitan esperar a que tres equipos distintos se alineen para poner algo en manos de usuarios.
O eres desarrollador web en el sentido amplio, o compites con alguien que sí lo es.
Ahora eres alguien que construye
El cambio de mentalidad más importante es este: ya no tiene sentido definirse solo como alguien que escribe código, cierra tickets o acumula pull requests.
Eres alguien que construye.
Y quien construye se mide por lo que consigue poner en producción.
¿Cuántas mejoras llegaron a usuarios este trimestre? ¿Qué funcionalidades redujeron trabajo manual? ¿Bajaron los tickets de soporte? ¿Subió la retención? ¿El negocio entiende mejor lo que está pasando? Esas son las preguntas importantes.
No estoy diciendo que la calidad del código no importe. Importa mucho. Pero importa como medio para un fin. El objetivo final es siempre el mismo: software funcionando en producción, resolviendo problemas reales, generando valor para usuarios y negocio.
El mejor código del mundo no vale demasiado si se queda en una rama que nunca se fusiona.
El mejor código es el que está en producción
Conviene ser directo con esto: el mejor código es el que está en producción y genera valor.
No el código más puro arquitectónicamente. No el que sigue todos los patrones del libro. No el que quedaría bien en una charla. El que se desplegó, funciona, lo usan personas reales y ayuda a la empresa a avanzar.
Esto no es una excusa para enviar basura. Es un recordatorio de que la perfección también puede ser una forma de no entregar. Una funcionalidad bien probada, razonablemente diseñada y ligeramente imperfecta, pero viva y generando valor, suele ganar a una funcionalidad impecable que lleva tres sprints "casi lista".
La IA hace que esta tensión sea todavía más visible. Si podemos producir más rápido, también necesitamos decidir mejor qué merece ser producido y cuándo está suficientemente bien para aprender de la realidad.
Tres criterios para la era de la IA
Si tuviera que resumir cómo evaluar una funcionalidad en esta etapa, usaría tres criterios. No son sofisticados, pero funcionan como OKR personales para cualquier desarrollador web.
Útil. ¿Resuelve un problema real? ¿Alguien lo necesita de verdad o lo estás construyendo porque resulta técnicamente interesante? Si los usuarios no lo necesitan, da igual lo bien hecho que esté.
Rápido. ¿Funciona con la velocidad suficiente para que el usuario no piense en ello? El rendimiento no es un extra bonito. Una funcionalidad lenta es una funcionalidad rota.
Seguro. ¿Protege bien los datos? ¿Has pensado en autorización, validación de entradas, exposición accidental de información y abuso? La seguridad no se añade al final. Forma parte de cada decisión desde el primer día.
Útil, rápido y seguro. Si una funcionalidad cumple esas tres condiciones, vas por buen camino. Si falla en alguna, lo demás importa menos.
La oportunidad está ahora
Estamos en uno de esos momentos raros en los que las herramientas, el mercado y la cultura se alinean a favor de quienes construyen para la web.
La IA se está encargando de buena parte del trabajo repetitivo. La industria valora cada vez más a perfiles full-stack, orientados a resultados y capaces de entregar. Las empresas empiezan a premiar menos el proceso por el proceso y más el software que llega a producción. Y la web, con todos sus defectos, sigue siendo la plataforma más abierta, accesible y universal que tenemos.
Si ya eres desarrollador web, toca subir de nivel. Aprende a pensar en toda la pila. Usa la IA como herramienta, no como amenaza. Céntrate en resultados, no en volumen de trabajo aparente.
Si estás pensando en convertirte en uno, deja de pensarlo durante demasiado tiempo y empieza a construir. La barrera de entrada nunca ha sido tan baja. El techo nunca ha estado tan alto.
Nunca ha habido mejor momento.
