Hace un par de años, cuando hablabas con un desarrollador, casi todo giraba en torno a tres cosas: frontend, backend y base de datos. Hoy la lista es mucho más larga: agentes, MCPs, CLIs, bases de datos vectoriales y varios modelos de IA entre los que elegir. Y hay un tipo de desarrollador que no quiere aprender nada de esto. Ese miedo a quedarse sin trabajo es real, y muchos me lo escriben. Este artículo es mi perspectiva de cómo veo el desarrollo de software hoy, con lo que uso a diario y con algunos datos para que no tengas que fiarte solo de mi opinión.

Cómo era el desarrollo: frontend, backend y base de datos

Hace unos años, hacer una aplicación consistía básicamente en esas tres partes. Eran tan fundamentales que ahí estaba casi todo el trabajo. Por eso existían desarrolladores de frontend que consumían un backend, backends especializados y hasta profesionales que solo se dedicaban a la base de datos. Cada pieza era un mundo, y cada una necesitaba a alguien que escribiera, validara y actualizara el código.

Incluso hoy hay empresas grandes que necesitan cada área por separado. Pero seamos honestos: para la mayoría de aplicaciones, desde empresas pequeñas o medianas hasta herramientas internas, todo eso ya se puede lograr con vibe coding.

Hoy casi todo se puede hacer con vibe coding

Y no es una suposición. A diario trato con personas que no son técnicas y ya están generando aplicaciones para clientes: pagan una herramienta, siguen una idea y la construyen. El vibe coding es real y está generando trabajo y mucho más software que antes.

El único problema es que lo que ves en pantalla no es todo lo que hay detrás. Una aplicación puede parecer terminada y ser bastante más compleja por dentro.

Modelos frontera frente a modelos open source

Hoy un modelo puede generar casi cualquier aplicación, y lo digo porque lo uso todos los días. Hablo sobre todo de los modelos frontera, y en mi caso del que más uso, Claude. Eso podría cambiar con el tiempo; la generación de código con IA va a mejorar y a ser más accesible.

Pero para trabajo real, esos modelos suelen exigir suscripciones de 100 o 200 dólares al mes, porque consumen muchos tokens. Sé que hay planes de 20 dólares, pero para clientes de verdad, con actualizaciones constantes, yo me apoyo en los modelos frontera. Los modelos open source son el futuro del acceso gratuito, y si no tienes empleo o estás estudiando, empezar con ellos tiene todo el sentido para entender cómo funcionan.

Un matiz importante sobre lo que conté en el video: depende del modelo. Qwen 3.8 en su versión de 27 mil millones de parámetros pasa de unos 55 GB a unos 31 GB con cuantización FP8 (los datos son de Hugging Face), y una tarjeta como la RTX 5090 trae 32 GB de memoria. O sea, cabe en una sola GPU, aunque con poco margen para el contexto. Otra cosa es DeepSeek V4: incluso su versión Flash pesa cientos de gigabytes, así que no es algo que instales en casa. Cuantizar significa guardar los pesos con menos precisión para gastar menos memoria, y eso tiene un costo en calidad.

¿El software ha muerto?

Con todo esto, la pregunta es inevitable: si un modelo puede generar casi cualquier aplicación, ¿murió el software? No. Un usuario puede generar su proyecto con IA, pero en algún punto va a necesitar a alguien que revise ese código, porque el modelo te lo genera y tú vas a ciegas. Y no quiero que se entienda que el vibe coding no funciona: sí funciona, y hay personas ganando dinero con aplicaciones hechas así.

Por qué sigue haciendo falta un profesional

Dos razones principales. La primera es la experiencia: alguien con criterio te deja un diseño base sobre el cual luego puedes seguir pidiendo cosas a la IA. La segunda es la responsabilidad. Si tu IA elimina registros de la base de datos, alguien tuvo que pedirlo. No vas a culpar a la empresa del modelo: de hecho, el propio Claude Code te avisa del riesgo al abrir una carpeta nueva.

Aquí va otro matiz. Según la documentación de seguridad de Claude Code, el aviso es un diálogo de confianza que sale cuando lo abres en una carpeta que no has marcado como confiable, y la revisión de lo que se ejecuta es responsabilidad tuya. El aviso no sale siempre. La idea de fondo se mantiene: la herramienta no responde por ti. Lo que hace falta no es solo quien escriba el código, sino quien responda por él.

Cuando el proyecto crece, el vibe coding se queda corto

Mientras más complejo es el proyecto, más pesa el conocimiento. En un backend ya no solo pides una API: entran WebSockets, GraphQL, gRPC, SOAP. Alguien tiene que tomar decisiones, y puedes delegarlas todas a la IA, pero ir a ciegas suele terminar en reescribir.

Por eso digo que el vibe coding sirve como base de una aplicación, pero cuando el proyecto crece necesitas entender lo que hay por detrás. Estos días estoy creando sistemas que tienen que comunicarse con software antiguo: software cerrado, a veces con protocolos propios y sin API, donde toca hacer scraping o programar tareas que consulten constantemente. Y piensa en una aplicación con muchos usuarios que se satura de datos, tiene consultas mal optimizadas o necesita migrar de nube. La IA te ayuda, pero alguien debe saber qué está pidiendo.

De programador a administrador de agentes

Hace un par de años yo hacía de project manager: generaba el proyecto, definía tareas y se las delegaba a desarrolladores. Hoy es parecido, solo que en lugar de personas delegas en agentes. Un agente puede generar código, leer correos, hacer testing o abrir el navegador, y trabaja todo el tiempo, por mucho menos que una persona. Un proyecto que antes me tomaba unos tres meses ahora lo termino en semanas.

¿Significa eso que ya no se necesitan desarrolladores? No. Cuando un sistema se vuelve complejo, aun con agentes tienes que administrarlos, y eso requiere conocimiento técnico: saber escalar una base de datos, desplegar, probar o elegir el stack correcto. Ya casi no hace falta quien escriba código, pero sí quien administre un proyecto, y no solo en planificación, también técnicamente.

El proyecto que copia Photoshop, Word y más con IA

En las últimas semanas se ha hecho muy popular un proyecto de código abierto con aplicaciones que imitan a Photoshop, Premiere, Word, AutoCAD y más, hechas con IA. Se llama ArtCraft y su código está en la organización storytold de GitHub. Son apps escritas en Rust que se presentan como reimplementaciones «clean-room». Su app tipo Photoshop, PhotoCraft, supera las 68.000 estrellas (dato del 19 de octubre de 2026).

Un par de matices sobre lo que conté. Mencioné FL Studio, pero la app de audio del proyecto, SoundCraft, imita a Pro Tools. «Slides» sería en realidad PowerPoint (su app se llama DeckCraft). Y «toda la suite de Adobe» exagera un poco: son siete aplicaciones, y el README de PhotoCraft lo describe como una alpha temprana, todavía no como un reemplazo de Photoshop para el trabajo profesional diario.

Lo interesante es lo que confirma mi punto: en solo 19 días, PhotoCraft acumula más de 1.600 issues abiertos y más de 1.100 pull requests. Generar la aplicación es la parte rápida; atender usuarios, bugs y mejoras es el trabajo que nunca termina. Y un proyecto open source, además de código, necesita ingresos o patrocinio para sostenerse.

¿Ya está todo el software resuelto?

Cualquiera puede pedirle a ChatGPT o a Claude que genere una aplicación y lo hará. Pero eso no significa que todo el software esté resuelto. Hay problemas mucho más complejos que una interfaz conectada a una base de datos: un sistema de facturación, una cola para procesar videos, un sistema de notificaciones. No son aplicaciones llamativas, pero requieren que alguien las diseñe y entienda lo que ocurre dentro, sobre todo si quieres mejorarlas con el tiempo. Yo trabajo con ejecutivos que pagan suscripciones caras de IA y podrían generar sus propias aplicaciones, y aun así no lo hacen: no tienen el tiempo ni quieren delegar con clientes reales de por medio.

¿Vale la pena ser desarrollador hoy?

Sí lo vale. Mi consejo: no hagas solo aplicaciones básicas, porque ahora cualquiera puede generar un frontend con backend y base de datos. Practica con sistemas más complejos, como streaming de datos, aplicaciones en tiempo real o multitenant, y atrévete con un proyecto open source para ver cómo otros te envían cambios, que también ha cambiado mucho.

Los bots ya reciben y procesan los bugs

Te doy un ejemplo con Herdr, un proyecto para administrar múltiples agentes en la terminal. Encontré un bug en Windows, abrí el issue #4725 y la primera respuesta llegó en menos de dos minutos, de una cuenta de bot. Al día siguiente quedó resuelto en la rama principal y el 13 de octubre salió en la versión 0.9.4. Hoy los reportes también los puede escribir una IA y los puede recibir otro bot. Ten en cuenta que no está documentado que esos bots usen IA; lo que sí se ve es la automatización.

Existen herramientas dedicadas a esto, como CodeRabbit, que hace revisión automática de pull requests con IA: deja un resumen del cambio, comentarios línea por línea y revisa cada commit nuevo. Cuando hace falta una mejora, un desarrollador puede decidir si el error vale la pena y repararlo.

Qué actualizar: MCPs, agentes y bases vectoriales

Si te dedicas al desarrollo, mi recomendación es que te actualices. El backend ya no se queda en la API: ahora hay MCPs, protocolos de agente a agente y gateways para modelos de IA. En la base de datos aparecen las bases vectoriales. En el frontend, el SEO pasa a ser también parte de los agentes: cuando alguien le pregunta a ChatGPT por un servicio, el bot hace scraping en la web y puede sugerir tu proyecto. Y el frontend ya no es solo web: también puedes producir aplicaciones de escritorio y móviles bastante rápido.

Si estás estudiando, probablemente te enseñen cosas básicas como consultas a bases de datos o diseño de proyectos. Es válido, aunque algún contenido pueda estar anticuado. Lo que se ha construido en 10 a 20 años de desarrollo sigue vigente; la diferencia es que ahora no se hace con personas, se hace con agentes. Si te enseñan test-driven development, cambia a la persona por un agente y el proceso es igual.

Mantente al día sin caer en el FOMO

Para quien trabaja y para quien estudia, mi consejo es el mismo: mantente actualizado y trata de entender de qué va cada cosa, en lugar de correr detrás del FOMO. Lo básico es que el modelo es lo que importa; encima se crean protocolos y herramientas, y no necesitas aprenderlas todas.

Los datos acompañan sin exagerar. En la encuesta de desarrolladores de Stack Overflow 2026, el 73 % de quienes usan asistentes o agentes de código los usan a diario, pero solo el 48 % dice confiar en la IA cuando puede validar fácilmente la respuesta. Y la Oficina de Estadísticas Laborales de EE. UU. proyecta que el empleo de desarrolladores, analistas de calidad y testers crecerá un 10 % entre 2025 y 2035; es una previsión para ese país, no una garantía.

Conclusión

Si quieres dedicarte al desarrollo de software, no te guíes solo por el vibe coding. Está bien para mucha gente que genera sus aplicaciones, y en mi opinión es el no-code de esta época, incluso mejor porque ahora cualquiera puede generar aplicaciones. Y no es malo: hay mucha más demanda de software. Yo recibo más solicitudes para revisar proyectos que para crearlos, y hace años tenía reuniones solo para corregir fragmentos de código que hoy resuelve una IA.

El software no murió: cambió, y en mi opinión se ha vuelto más fácil que antes, porque ahora tienes algo que te ayuda a acelerar todo el proceso. Si lo ves de otra forma, cuéntamelo en los comentarios. Y muy pronto voy a traer un curso más elaborado, parte por parte, de todo lo que podrías aprender.

¿Tú qué piensas: el vibe coding te asusta o te ayuda en tu trabajo?

Fuentes