En noviembre de 2025 el diccionario Collins eligió «vibe coding» como palabra del año y lo definió como usar IA, con instrucciones en lenguaje natural, para ayudar a escribir código. La expresión cuajó porque la experiencia es real. Se describe una aplicación, se acepta lo que escribe el modelo y el domingo por la tarde hay una pantalla que funciona. Un fundador ya puede enseñar una demo a clientes antes de contratar a un ingeniero.
Lo que no se abarató es la parte que hace fiable al software. En la Stack Overflow Developer Survey de 2025, el 66% de los desarrolladores señaló «soluciones de IA que están casi bien, pero no del todo» como su principal frustración con las herramientas de IA, y el 45% dijo que depurar código generado por IA lleva más tiempo. Un prototipo es el lugar donde casi bien es suficiente. Producción es el lugar donde no lo es.
Esta nota enumera lo que producción añade a un prototipo, da un reparto aproximado del esfuerzo y sugiere cómo debería tratar la demo que acaba de ver quien gestiona el presupuesto.
La aceleración es real, y sigue sin medirse
La medición más cuidadosa de la velocidad de programación con IA viene de METR, una organización de investigación sin ánimo de lucro. Su ensayo aleatorizado de 2025 encontró que desarrolladores open source con experiencia tardaban un 19% más en las tareas cuando se permitía la IA, con un intervalo de confianza de +2% a +39%.
El 24 de febrero de 2026 METR publicó un seguimiento: 57 desarrolladores, 143 repositorios, más de 800 tareas, realizado desde agosto de 2025. En la misma escala de cambio de tiempo en la que el resultado de 2025 fue +19%, las nuevas estimaciones puntuales son -18% para los desarrolladores que volvían del primer estudio (intervalo de -38% a +9%) y -4% para los recién reclutados (intervalo de -15% a +9%). Ambas estimaciones puntuales se inclinan ahora hacia un ahorro de tiempo con IA. Ambos intervalos incluyen el cero.
El propio METR califica los nuevos datos como una señal poco fiable. Entre el 30% y el 50% de los desarrolladores dijeron que habían decidido no enviar algunas tareas porque no querían hacerlas sin IA. Por tanto, las tareas donde la IA más ayuda faltan en la muestra, y METR cree que la aceleración real probablemente es mayor que su estimación.
Para un comprador, la conclusión es acotada. La IA hace más rápida parte de la programación, en una cantidad que investigadores cuidadosos no han conseguido precisar. No cambia lo que un sistema necesita antes de que la gente pueda depender de él.
Qué demuestra un prototipo, y qué no
Un prototipo de fin de semana demuestra tres cosas útiles: la idea funciona con las entradas que alguien probó, la interfaz tiene sentido para quienes la vieron, y alguien la quiere.
No demuestra que el sistema funcione con entradas que nadie probó, que funcione para doscientas personas a la vez, que muestre a cada persona solo lo que tiene permitido ver, que cueste al mes lo que usted cree, ni que alguien pueda arreglarlo cuando se rompa de noche. Esas son las preguntas que responde producción.
Hay una segunda diferencia fácil de pasar por alto. Un prototipo lo juzga la persona que lo construyó, el día en que lo construyó, con entradas que eligió ella. Un sistema de producción lo juzgan personas que nunca vieron la demo, meses después, con datos que no existían cuando se escribió el código. La mayor parte del trabajo de la tabla siguiente existe para que ese segundo juicio salga bien.
Qué añade producción
Las proporciones siguientes son un reparto ilustrativo para una herramienta LLM interna, como un copiloto de búsqueda de documentos, que pasa de un prototipo funcional a unos cientos de usuarios diarios. Son opiniones de planificación, no mediciones. Cambie los pesos para su caso; lo importante es la forma.
| Tarea | Qué significa | Sin ella | Proporción ilustrativa |
|---|---|---|---|
| Lógica central | Lo que el prototipo ya muestra | No hay producto | 20% |
| Contratos de datos y pipelines | Comprobación de esquema en cada fuente de entrada; cargas programadas e idempotentes | Cambia una exportación de origen y las respuestas empeoran sin ningún error | 15% |
| Conjunto de evaluación y quality gates | Preguntas reales con respuestas esperadas, ejecutadas en cada cambio de prompt o de modelo | Nadie sabe si un cambio mejoró o empeoró las cosas | 12% |
| Autenticación y permisos | Single sign-on; reglas de acceso aplicadas en el momento de la recuperación | El personal ve documentos que no debería | 8% |
| Validación de entradas y gestión de errores | Límites de tamaño y formato; tratamiento de texto hostil en archivos subidos y documentos recuperados | Un archivo raro tumba el servicio o manipula al modelo | 8% |
| Monitorización y alertas | Latencia, tasa de errores, coste por petición, tasa de recuperaciones vacías, feedback de usuarios | Los problemas los reportan los usuarios, días después | 8% |
| Revisión de seguridad y correcciones | Secretos, dependencias, datos enviados a APIs de terceros | Una clave filtrada o una brecha en el tratamiento de datos | 8% |
| Guardias y runbooks | Un responsable con nombre y pasos escritos para los fallos habituales | La única persona que lo sabe está de vacaciones | 7% |
| Rollback y proceso de release | Prompts, modelos e índices versionados; un interruptor para volver a la última versión buena | Un release defectuoso sigue en producción mientras alguien lo depura | 5% |
| Documentación y traspaso | Cómo funciona, cómo cambiarlo, cómo operarlo | El sistema no puede sobrevivir a su autor | 5% |
| Límites de coste | Cuotas por usuario, topes de tokens, un cortacircuitos de gasto | Un bucle o un usuario intensivo produce una factura inesperada | 4% |
La primera fila es el prototipo. En este reparto es una quinta parte del trabajo. Las otras cuatro quintas partes son invisibles en una demo, y por eso una demo es tan mala guía para un presupuesto.
Para ingenieros: a dónde va el tiempo
Algunas filas merecen más detalle, porque es donde las estimaciones suelen fallar.
Los permisos van en la recuperación, no en la respuesta. En un sistema con generación aumentada por recuperación, la comprobación de acceso tiene que filtrar los documentos antes de que lleguen al modelo. Filtrar después de la generación no funciona: el modelo ya ha leído el texto restringido y puede parafrasearlo. Eso significa que el índice lleva metadatos de acceso, se mantiene sincronizado con el sistema de origen y alguien lo prueba con cuentas que tienen distintos permisos.
El conjunto de evaluación es la especificación en forma ejecutable. Es un archivo versionado de entradas reales con salidas esperadas o reglas de calificación, ejecutado en CI en cada cambio de prompts, modelos, chunking o parámetros de recuperación. Construirlo significa sentarse con las personas que usarán el sistema y escribir qué es una respuesta correcta. Es lento, y ningún asistente puede hacerlo por usted, porque el conocimiento lo tienen los usuarios.
La validación de entradas ahora incluye texto que ataca al modelo. Un documento del índice puede contener instrucciones. Los archivos subidos pueden ser enormes, estar vacíos, ser imágenes escaneadas o tener la codificación equivocada. Cada caso necesita un comportamiento definido y un test.
El rollback necesita todo versionado en conjunto. Un release es un prompt, una versión de modelo, una construcción del índice y código. Si solo el código está en git, revertir el código no revierte el comportamiento.
Los límites de coste son una funcionalidad de producción. Un prototipo tiene un usuario. Un sistema de producción tiene unos cientos, más scripts y reintentos. Las cuotas por usuario, los máximos de tokens y una alerta sobre el gasto diario son baratos de construir y evitan la sorpresa desagradable más común.
Cómo tratar un prototipo si gestiona el presupuesto
Trátelo como una especificación. Un prototipo funcional es la descripción más clara de lo que se quiere que la mayoría de los proyectos llega a tener. Entrégueselo a los ingenieros junto con la lista de entradas con las que se probó y los casos en los que falló.
No lo trate como el 80% del producto. Si un presupuesto es pequeño porque el prototipo existe, pregunte qué filas de la tabla anterior cubre. Si la respuesta es solo la primera fila, el presupuesto es para un segundo prototipo.
Úselo para comprobar la demanda antes de financiar producción. Póngalo delante de los usuarios previstos durante dos semanas. Si no vuelven a usarlo, se ha ahorrado el presupuesto de producción, que es lo más útil que puede hacer un prototipo.
Cuándo tirar el prototipo
Reescriba en lugar de ampliar cuando se cumpla una o más de estas condiciones:
- hay secretos en el código o en el historial del repositorio;
- se accede a los datos a través de la cuenta personal o la API key personal de alguien;
- la interfaz, la lógica y el acceso a datos están mezclados, de modo que los permisos no se pueden aplicar en un solo sitio;
- nadie puede explicar cómo se produjo una respuesta concreta;
- funciona sobre un constructor alojado que no se puede desplegar dentro de su entorno ni cumplir sus reglas de datos;
- la lógica es larga y no tiene tests.
Consérvelo cuando la lógica central sea corta, legible y separable, ya existan algunos tests y el flujo de datos se parezca al de producción.
Tirar código cuesta menos de lo que parece. El prototipo ya ha hecho su trabajo: las decisiones están tomadas, los ejemplos están recogidos, la interfaz se ha probado. Los prompts, las entradas de ejemplo y las capturas de pantalla suelen sobrevivir a una reescritura aunque el código no lo haga.
Cómo se ve la diferencia en dinero
Nuestras propias franjas de precio publicadas muestran la misma proporción. Una prueba de concepto cuesta 14k–38k € en 4–7 semanas. Un desarrollo de producción cuesta 45k–120k € en 10–20 semanas. En ambos extremos del rango, producción es unas tres veces la prueba de concepto: 45 / 14 ≈ 3,2 y 120 / 38 ≈ 3,2. Ese múltiplo es el coste de las filas de arriba que no son la primera. Entregamos monitorización y rollback antes del traspaso por la misma razón: son lo que permite a un cliente operar el sistema sin nosotros.
Si ya tiene un prototipo y quiere saber qué filas cubre, el teardown gratuito es una primera comprobación en seis preguntas, y un discovery corto de pago lo responde por completo. La misma lista se aplica a los copilotos de documentos internos, donde los permisos y el conjunto de evaluación suelen llevar más tiempo.
Fuentes
- CNN, 'Vibe coding' named Collins Dictionary's Word of the Year, noviembre de 2025 — https://www.cnn.com/2025/11/06/tech/vibe-coding-collins-word-year-scli-intl
- Stack Overflow, 2025 Developer Survey: AI, julio de 2025 — https://survey.stackoverflow.co/2025/ai
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, julio de 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, We are Changing our Developer Productivity Experiment Design, febrero de 2026 — https://metr.org/blog/2026-02-24-uplift-update/