El vibe coding ha invadido las conversaciones tech en 2025. El término, popularizado por Andrej Karpathy, describe una forma de trabajar simple sobre el papel: describes lo que quieres a una herramienta IA (Cursor, Claude Code, Windsurf), aceptas el código generado y evitas preguntarte demasiado cómo funciona por debajo. Fundadores de startups construyen así prototipos enteros en pocos días. Las redes sociales rebosan de demostraciones impresionantes. Y en las empresas que externalizan su desarrollo, surge una pregunta práctica: ¿cambia el vibe coding la ecuación offshore?
- 🚀 El vibe coding acelera la producción de código, pero el valor de un desarrollador experimentado se desplaza hacia la arquitectura y la supervisión, no hacia la salida.
- ⚠️ Sin supervisión técnica, el vibe coding produce aplicaciones frágiles: seguridad ausente, deuda técnica incontrolable y mantenimiento casi imposible.
- 💡 Los equipos offshore que dominan las herramientas IA duplican o triplican su rendimiento sin sacrificar la calidad estructural del producto.
- ✅ La combinación spec-driven development y ejecución offshore asistida por IA ofrece los resultados más sólidos en proyectos B2B serios.
Qué es realmente el vibe coding (y qué no es)
Empecemos por desmontar algunas ideas preconcebidas. El vibe coding no es una técnica que transforma a cualquiera en desarrollador competente. Es una forma de delegar la escritura del código a un LLM manteniendo, en teoría, el control sobre lo que se construye. En la práctica, ese control depende por completo de la persona que lleva las riendas.
Fireship planteó bien la distinción en un vídeo de marzo de 2025: codear y programar no son lo mismo. Codear es traducir una lógica en instrucciones de máquina. Programar es concebir, arbitrar y resolver problemas que no tienen una respuesta evidente. Los LLMs son excelentes codeando. Son mucho menos buenos programando en el sentido amplio: no tienen visión de producto, no gestionan la arquitectura a 18 meses y no saben que una decisión técnica tomada hoy va a crear un infierno de mantenimiento en seis meses.
En concreto, un fundador sin formación técnica puede prototipar una interfaz funcional en pocas horas con las herramientas adecuadas. Es real e impresionante. Pero cuando intenta añadir un sistema de pago seguro, gestionar permisos por rol o escalar su aplicación más allá de 500 usuarios simultáneos, las carencias aparecen rápido. La IA generó código que funciona en el caso nominal. No anticipó los casos límite, los errores de red, los intentos de inyección SQL ni la forma en que los datos se van a corromper progresivamente si la lógica de negocio no es coherente.
Qué produce el vibe coding sin supervisión en la vida real
Kai Lentit publicó una entrevista satírica de un "vibe coder" construyendo un simulador en tiempo real. El vídeo es divertido porque es preciso. El desarrollador no sabe qué base de datos utiliza su aplicación. Dejó una clave privada en duro en un repositorio GitHub público. No tiene ni idea de cómo desactivar una funcionalidad que causa problemas. Cuando le preguntan si probó su aplicación, responde que la publicó en TikTok.
No es un caso inventado para exagerar. Los patrones recurrentes documentados en los informes de campo son consistentes: acumulación de parches que vuelven el código progresivamente inmanejable, regresión sistemática de las funcionalidades existentes con cada nueva feature e imposibilidad de depurar porque nadie entiende realmente lo que hace el código.
Tom, socio en Y Combinator, lo describe bien en su sesión sobre vibe coding: si te encuentras copiando y pegando mensajes de error en bucle sin avanzar, es la señal de que algo salió mal mucho antes. Su consejo concreto: hacer un git reset --hard y partir de una base limpia en lugar de acumular parches sobre parches. La deuda técnica en un proyecto vibe-codeado sin rigor no se acumula linealmente. Explota a partir de cierto umbral, y ese umbral se alcanza mucho antes de lo que uno piensa.
IBM Technology presenta una alternativa más estructurada en su vídeo sobre spec-driven development. La idea: redactar primero una especificación formal del comportamiento esperado (endpoints, parámetros, códigos de retorno, casos de error, reglas de negocio), y luego dejar que la IA genere el código a partir de esa spec. Es sentido común de desarrollador senior transformado en workflow IA: defines lo que el sistema debe hacer antes de pedirle que lo haga. La ambigüedad es el enemigo de los LLMs, y una spec clara reduce drásticamente las alucinaciones y las implementaciones sorprendentes.
Qué cambia para los desarrolladores offshore
La pregunta que vuelve en las conversaciones B2B es directa: si una herramienta IA puede generar una aplicación en pocos días, ¿por qué financiar un equipo de desarrolladores offshore?
La respuesta cabe en una línea: la IA genera código, no mantiene un sistema en producción. La diferencia entre un prototipo que funciona en demo y una aplicación que atiende a 10 000 usuarios reales siete días a la semana es precisamente todo lo que el vibe coding puro no cubre. La seguridad de los datos. El rendimiento bajo carga. El monitoreo y las alertas. Las migraciones de base de datos sin pérdida de datos. La gestión de errores imprevistos. La coherencia del modelo de datos a lo largo de 18 meses de desarrollo incremental.
Lo que muestran los transcripts es que los equipos offshore que adoptaron herramientas IA ven su productividad aumentar de forma sustancial. Un desarrollador que producía entre 200 y 300 líneas de código funcional al día puede producir dos o tres veces más con las herramientas adecuadas y un método riguroso. El valor no desaparece, se redistribuye: menos tiempo escribiendo código repetitivo, más tiempo concibiendo la arquitectura, revisando lo que genera la IA y tomando las decisiones que la herramienta no puede tomar sola.
Para las empresas que externalizan, es una buena noticia estructural. El coste de un equipo offshore sigue siendo competitivo frente a las tarifas locales, y la productividad de ese equipo ha mejorado. No es una cuestión de reemplazo, es una cuestión de especialización. Los desarrolladores offshore que dominan estas herramientas se convierten en perfiles híbridos, capaces de dirigir la generación de código IA garantizando al mismo tiempo el rigor técnico que una herramienta sola no puede asegurar. Detallamos este cambio en nuestro artículo sobre los desarrolladores offshore e IA.
Las prácticas que marcan la diferencia en la práctica
Los comentarios de los fundadores YC y de los desarrolladores experimentados convergen en algunos puntos que no sorprenderán a los equipos técnicos curtidos.
El plan antes del código es la primera práctica innegociable. Tom recomienda crear un archivo markdown con la arquitectura y las funcionalidades previstas antes de escribir la primera línea de código. Este plan sirve de referencia a lo largo de todo el proyecto, funcionalidad por funcionalidad. Se le dice a la IA: "hacemos la sección 2 ahora, y solo la sección 2". Se valida que funciona, se prueba, se hace commit y se pasa a lo siguiente. Los LLMs no generan de golpe un producto completo de calidad. Trabajan bien por bloques, y esos bloques deben estar definidos claramente de antemano.
El control de versiones riguroso es la segunda práctica. Git no es opcional cuando se trabaja con herramientas IA. Cada funcionalidad validada merece un commit limpio sobre una base sana. Si la IA toma una dirección incorrecta, poder volver a un estado estable en pocos segundos cambia completamente la relación con el riesgo. Tom es explícito al respecto: no confía en las funciones "revert" integradas en los IDE IA. Usa Git, punto.
Los tests de integración son la tercera palanca. Varios fundadores YC mencionan que primero redactan los tests que describen el comportamiento esperado y luego dejan que la IA genere el código que los haga pasar. Es el spec-driven development aplicado en la práctica. Cuando los tests pasan, la funcionalidad queda validada. Cuando la IA toca código adyacente y rompe algo, los tests lo detectan de inmediato, antes de que el problema llegue a producción.
Por último, la elección del stack importa más de lo que se piensa. Los LLMs rinden significativamente mejor con frameworks populares y documentados (React, Node.js, Rails) que con tecnologías recientes o poco extendidas. Para un equipo offshore que trabaja en proyectos SaaS B2B, es un argumento más a favor de los stacks probados. Nuestro artículo sobre React y TypeScript en proyectos SaaS desarrolla este punto en detalle.
| Enfoque | Puntos fuertes | Riesgos principales |
|---|---|---|
| Vibe coding puro | Rapidez de prototipado | Seguridad ausente, deuda técnica |
| Spec-driven development | Coherencia, mantenibilidad | Setup más largo antes de codear |
| Equipo offshore + herramientas IA supervisadas | Productividad + expertise de negocio | Depende de la calidad de las specs de entrada |
Lo que hay que retener de verdad
El vibe coding no es una amenaza para los equipos offshore competentes. Es un acelerador para los que tienen el rigor técnico para encuadrarlo correctamente. Las empresas que piensan reemplazar a sus desarrolladores con vibe coding sin supervisión van a descubrir los mismos problemas que el personaje satírico de Kai Lentit: una clave API expuesta en GitHub, una arquitectura que nadie entiende y ningún medio para corregir lo que falla cuando llegan los primeros usuarios reales.
Lo que sí cambia es el perfil que se espera de un buen desarrollador offshore en 2026. Menos código escrito a mano, más capacidad para encuadrar el trabajo de la IA, validar su salida y tomar las decisiones de arquitectura que la herramienta no puede tomar sola. Es precisamente lo que los equipos estructurados ya ofrecen.
