Vibe coding: por qué los desarrolladores senior deberían liderar esta revolución, no combatirla

La inteligencia artificial está cambiando la forma en que desarrollamos software.

Y, como ocurre con prácticamente cada cambio importante dentro de la industria tecnológica, también está generando resistencia.

Uno de los conceptos que más discusión provoca actualmente es el vibe coding: utilizar modelos de inteligencia artificial para generar una parte significativa del código a partir de instrucciones, contexto e iteraciones en lenguaje natural.

Para algunos desarrolladores, especialmente aquellos con muchos años de experiencia, este enfoque puede parecer peligroso.

Y, en cierta medida, tienen razón.

Pero esa no es toda la historia.

El verdadero problema no es el vibe coding

Hay una diferencia enorme entre una persona sin conocimientos técnicos pidiendo:

“Construye un sistema de facturación.”

y un arquitecto o desarrollador senior explicando:

“Necesito este servicio bajo esta arquitectura, utilizando estos patrones, respetando estas políticas de autenticación, con pruebas unitarias, manejo de excepciones, observabilidad y estos criterios de seguridad.”

Ambas personas están utilizando inteligencia artificial.

Pero no están haciendo lo mismo.

El conocimiento técnico sigue siendo fundamental porque la IA puede producir código sintácticamente correcto que, desde una perspectiva de arquitectura, seguridad o mantenibilidad, sea una mala decisión.

Y los propios desarrolladores lo reconocen.

La encuesta 2025 de Stack Overflow, con más de 49,000 participantes, mostró que 84% utiliza o planea utilizar herramientas de IA en su proceso de desarrollo. Entre desarrolladores profesionales, alrededor del 51% ya las utilizaba diariamente.

Sin embargo, la confianza no crece al mismo ritmo. El 46% señaló que no confía en la precisión de las respuestas de estas herramientas, y 45% identificó como una frustración que depurar código generado por IA puede consumir tiempo.

Para mí, esos datos no demuestran que la IA haya fracasado.

Demuestran exactamente lo contrario: necesitamos experiencia humana encima de la IA.

¿Realmente desarrolla más rápido la IA?

La respuesta responsable es: depende.

Y eso es importante decirlo porque abundan las afirmaciones exageradas.

Un experimento controlado publicado por Microsoft Research estudió desarrolladores que debían implementar un servidor HTTP en JavaScript. Los participantes que tuvieron acceso a GitHub Copilot terminaron la tarea 55.8% más rápido que el grupo sin el asistente.

Es un resultado impresionante.

Pero existe evidencia en sentido contrario.

METR realizó un experimento con 16 desarrolladores experimentados trabajando sobre 246 tareas reales en repositorios maduros que conocían desde hacía años.

El resultado fue sorprendente: con las herramientas de IA disponibles a principios de 2025, tardaron 19% más.

La propia METR actualmente advierte que ese estudio representa una fotografía de principios de 2025 y que ya no considera que necesariamente refleje las capacidades actuales de las herramientas.

Entonces: ¿la IA hace a un desarrollador 55% más rápido o 19% más lento?

Las dos cosas pueden ser ciertas.

Porque desarrollar software no es una actividad uniforme.

Crear boilerplate, pruebas, una API sencilla, documentación o determinados componentes repetitivos no presenta el mismo problema que modificar una plataforma de un millón de líneas de código con diez años de decisiones arquitectónicas detrás.

Ahí está justamente una de las grandes equivocaciones de la discusión sobre vibe coding.

No todo vibe coding es igual

Pensemos en dos escenarios.

Escenario 1

Una persona describe superficialmente una aplicación. La IA genera cientos o miles de líneas de código. Funciona. Se publica.

Nadie revisa realmente:

• arquitectura,
• seguridad,
• dependencias,
• patrones,
• escalabilidad,
• observabilidad,
• calidad,
• pruebas,
• deuda técnica.

Este tipo de vibe coding efectivamente puede ser peligroso.

Escenario 2

Un desarrollador senior o arquitecto diseña primero la solución.

Define arquitectura, tecnologías, estándares, restricciones, criterios de seguridad y formas de integración.

Después utiliza IA para acelerar la implementación.

Y finalmente somete el código a pruebas y revisiones adicionales.

Eso también es vibe coding. Pero es una disciplina completamente diferente.

En este escenario, la IA escribe más código, pero el humano conserva la responsabilidad de ingeniería.

De prompts a Skills y de Skills a agentes

Aquí está, para mí, el cambio realmente interesante.

El futuro del desarrollo asistido por IA probablemente no consistirá únicamente en escribir mejores prompts.

Será construir sistemas de contexto, Skills y agentes especializados.

Una Skill puede enseñarle al entorno de IA cómo queremos ejecutar determinada actividad:

• cómo estructuramos un proyecto,
• qué patrones permitimos,
• cómo construimos una API,
• qué estándares seguimos,
• cómo documentamos,
• cómo realizamos pruebas,
• qué controles deben ejecutarse antes de aceptar código.

Y alrededor de estas instrucciones podemos incorporar agentes especializados. Por ejemplo:

• Agente de arquitectura: revisa si la implementación respeta las decisiones arquitectónicas del proyecto.
• Agente de seguridad: busca problemas relacionados con autenticación, autorización, manejo de secretos, validación de inputs y vulnerabilidades comunes.
• Agente de calidad: evalúa complejidad, duplicación, mantenibilidad y consistencia.
• Agente de testing: genera y ejecuta pruebas unitarias, de integración y casos límite.
• Agente de documentación: mantiene README, documentación técnica, APIs y decisiones relevantes sincronizadas con el código.

Entonces el flujo cambia.

Antes: diseñar → programar → probar → documentar → revisar.

Ahora podemos evolucionar hacia: diseñar → delegar → generar → probar automáticamente → revisar con agentes → validar humanamente → desplegar.

La IA deja de ser simplemente un generador de código. Se convierte en una capa de ejecución dentro del proceso de ingeniería.

El seniority no pierde importancia: cambia dónde aporta valor

Durante años asociamos parte del seniority con la capacidad de escribir código rápidamente.

Pero escribir código nunca fue el verdadero valor diferencial de un desarrollador senior.

Su valor está en saber qué construir, cómo construirlo, qué no construir y qué consecuencias tendrá cada decisión.

Un desarrollador senior entiende por qué determinada arquitectura puede generar problemas dentro de tres años. Sabe dónde introducir abstracciones y dónde evitarlas. Reconoce riesgos de seguridad. Entiende performance. Puede evaluar deuda técnica. Puede anticipar problemas de operación.

Y tiene algo particularmente difícil de proporcionar a un modelo de inteligencia artificial: contexto.

Por eso me parece un error que algunos profesionales experimentados vean la IA únicamente como una amenaza.

Precisamente ellos tienen una ventaja extraordinaria para utilizarla.

El nuevo desarrollador senior puede convertirse en un orquestador

Anthropic analizó 500,000 interacciones relacionadas con programación y encontró que, dentro de Claude Code, 79% de las conversaciones estaban clasificadas como automatización, frente a 21% como colaboración o aumento de capacidades.

Esto apunta hacia un cambio interesante. Cada vez habrá más tareas que podamos delegar completamente a agentes.

Pero automatizar una tarea no equivale a automatizar la responsabilidad sobre un sistema.

Alguien necesita establecer los límites. Alguien necesita revisar. Alguien necesita decidir si una implementación tiene sentido.

Ahí es donde creo que evolucionará el trabajo del desarrollador senior. De “yo escribo cada línea del sistema” hacia “yo diseño cómo debe funcionar el sistema, establezco las reglas, delego partes de la implementación y verifico sus resultados”.

Eso no reduce su importancia. La incrementa.

No deberíamos medir solamente cuánto código genera la IA

Existe además otro riesgo.

Podemos generar diez veces más código y no ser diez veces más productivos. Incluso podríamos terminar siendo menos productivos si aumentamos bugs, retrabajo, vulnerabilidades, deuda técnica, complejidad y costos de mantenimiento.

Por eso las organizaciones deberían medir resultados de ingeniería y no solamente líneas generadas. Algunas métricas mucho más interesantes serían:

• Lead time: cuánto tiempo pasa desde una necesidad hasta producción.
• Cycle time: cuánto tarda realmente el equipo en implementar un cambio.
• Deployment frequency: cuántas veces podemos desplegar de manera segura.
• Change failure rate: cuántos cambios generan incidentes o rollback.
• Tiempo de code review: cuánto esfuerzo humano sigue necesitando el código generado.
• Defectos posteriores al despliegue: si estamos desarrollando más rápido pero también introduciendo más errores.

Aquí probablemente encontraremos el verdadero ROI del desarrollo asistido por IA.

Entonces, ¿vibe coding sí o no?

Mi respuesta es: sí, pero profesionalizado.

No creo en reemplazar ingeniería con prompts. Creo en aplicar ingeniería a los prompts, al contexto, a las Skills y a los agentes.

No creo que sea buena idea aceptar cualquier código porque “lo hizo la IA”. Creo que la revisión humana será incluso más importante conforme generemos código más rápidamente.

Y tampoco creo que los desarrolladores senior deban combatir esta transformación. Creo que deberían liderarla.

Porque alguien que entiende arquitectura, seguridad, cloud, DevOps, patrones, APIs y operación tiene una capacidad enorme cuando además puede delegar parte del trabajo mecánico a agentes de inteligencia artificial.

La ecuación entonces deja de ser IA vs. desarrollador y se convierte en:

Experiencia + IA + Skills + Agentes + Automatización + Revisión humana.

La IA no necesariamente elimina al desarrollador. Amplifica al buen desarrollador.

Probablemente veremos equipos capaces de entregar proyectos en semanas que anteriormente necesitaban meses. Eso no significa eliminar controles de calidad para entregar antes. Significa utilizar la IA para reducir el tiempo empleado en tareas mecánicas y dedicar más capacidad humana a las decisiones que realmente importan: arquitectura, seguridad, experiencia del usuario, operación, innovación y negocio.

El código siempre fue un medio para construir esas soluciones. Nunca fue el objetivo.

Por eso, en lugar de preguntarnos si el vibe coding va a reemplazar a los desarrolladores, quizá deberíamos hacernos otra pregunta:

¿Qué tan productivo puede llegar a ser un gran desarrollador cuando aprende a trabajar realmente bien con inteligencia artificial?

Creo que apenas estamos empezando a descubrir la respuesta.

Referencias

• Microsoft Research: The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Experimento controlado que observó una mejora del 55.8% en tiempo para una tarea específica.
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Encontró un incremento del 19% en el tiempo en su escenario experimental; METR ya publicó resultados más recientes, de inicios de 2026.
• Stack Overflow 2025 Developer Survey: AI. Más de 49,000 respuestas y datos sobre adopción, confianza y agentes de IA.
• Anthropic Economic Index: AI's Impact on Software Development. Análisis de 500,000 interacciones relacionadas con desarrollo.