En febrero de 2025, Andrej Karpathy acuñó el término «vibe coding». La idea era simple: en lugar de escribir código línea a línea, le describes al modelo lo que quieres y él lo construye. Tú supervisas, corriges el rumbo, apruebas. El modelo programa.
Dieciocho meses después, esa idea ha dejado de ser una curiosidad de Twitter para convertirse en el modo por defecto de trabajo en una franja creciente de la industria. Y como casi todo en IA, la realidad es más complicada —y más interesante— que el titular.
Lo que está ocurriendo de verdad
No estoy hablando de autocompletado glorificado. Estoy hablando de herramientas como Cursor, Claude Code o GitHub Copilot Workspace que en 2026 son capaces de:
- Leer tu codebase completa y entender su arquitectura
- Proponer refactors de componentes enteros con contexto real
- Escribir tests unitarios e integración desde cero
- Debuggear errores a partir del stack trace y el contexto circundante
- Ejecutar comandos de terminal, leer resultados y ajustar su trabajo
¿El resultado? Una encuesta de Stack Overflow de principios de 2026 indica que el 62% de los desarrolladores profesionales usa alguna de estas herramientas a diario. No como complemento. Como pilar central de su flujo de trabajo.
Y en startups de menos de diez personas, la proporción se dispara. He hablado con tres fundadores técnicos en los últimos dos meses. Los tres me dijeron lo mismo: «lanzamos el MVP con un solo ingeniero». Lo que antes necesitaba un equipo de cuatro ahora lo hace uno con paciencia suficiente para escribir buenos prompts.
La parte que nadie cuenta en la demo
El discurso oficial es inspirador. La realidad de producción tiene sus bordes ásperos.
El código generado funciona. La mantenibilidad es otra historia.
Cuando un modelo escribe código, lo hace para resolver el problema que tú le describiste, en ese momento, con ese contexto. No tiene opiniones sobre consistencia de patrones a largo plazo. No va a avisarte de que en el módulo de autenticación ya existe una función que hace lo mismo que la que acaba de crear. No tiene memoria de lo que generó la semana pasada.
El resultado es código que pasa los tests y falla en revisión. Duplicaciones. Abstracciones incoherentes. Nombres de variable que cambian de convención cada tres archivos. Funciona. Pero en seis meses, cuando el equipo crezca o el proyecto evolucione, alguien va a tener que limpiar ese desastre.
| Dimensión | Código humano | Código generado (2026) | |---|---|---| | Velocidad inicial | Lenta | Muy rápida | | Consistencia de patrones | Alta | Variable | | Cobertura de tests | Opcional | Automática | | Deuda técnica acumulada | Controlable | Impredecible | | Comprensión del dominio | Profunda | Superficial |
No es que el código generado sea malo. Es que es optimizado para la tarea inmediata, no para el sistema a largo plazo.
El programador de mantenimiento tiene los días contados
Hay un perfil concreto que está desapareciendo más rápido que nadie: el programador junior de mantenimiento. El que heredaba proyectos legacy, corregía bugs menores, añadía features simples a sistemas existentes.
Ese trabajo, en 2026, lo hace un agente. No perfectamente, pero suficientemente bien y a una fracción del coste.
Lo que no desaparece —al menos no todavía— es el criterio. La capacidad de leer código generado y decir «esto funciona pero va a explotar en tres meses». La habilidad de diseñar sistemas a alto nivel antes de que el modelo empiece a rellenarlos. El ojo clínico para distinguir deuda técnica asumible de deuda técnica suicida.
El perfil que sobrevive no es el que escribe mejor código. Es el que dirige mejor a los modelos que lo escriben.
Un caso concreto: elfalsoprofeta
Este blog usa Claude Code en su pipeline editorial. Los agentes escriben MDX desde un brief, el editor revisa el tono, el SEO valida los metadatos. Yo apruebo o descarto.
Pero la infraestructura —el Next.js, el sistema de posts, el CSS— también pasó por Claude Code. No un 20%. Un 70%.
¿Funciona? Sí. ¿Es el código más elegante que he visto? No. Hay partes donde el modelo eligió una solución que yo no habría elegido. Partes que haré refactor cuando tenga tiempo. Pero está en producción, responde bien y costó una décima parte del tiempo que me habría llevado escribirlo manualmente.
Eso es el trade-off real: velocidad de llegada a producción a cambio de deuda técnica futura. No es gratis. Pero en un mercado donde llegar primero importa, muchos están dispuestos a pagarlo.
La pregunta incómoda
Si el código lo genera la máquina, ¿qué queda para el programador?
La respuesta honesta es: criterio, contexto y responsabilidad.
El modelo no sabe que tu base de datos tiene un límite de conexiones que se satura bajo carga. No sabe que tu cliente más importante usa un navegador antiguo con un bug específico. No sabe que aquel módulo de pagos tiene una deuda técnica de 2019 que nadie ha tocado porque todos le tienen miedo.
Ese conocimiento contextual es irreemplazable. Por ahora.
Lo que sí está desapareciendo es la ilusión de que programar bien consiste en teclear rápido, recordar la sintaxis y conocer los patrones de diseño de memoria. Eso lo hace el modelo mejor que tú. La pregunta es qué haces con el tiempo que te libera.
¿Usas herramientas de generación de código en producción? ¿Cómo estás gestionando la deuda técnica que generan? Este debate me interesa más que cualquier benchmark. Escríbeme.