- Recientemente ha surgido en la industria de TI una nueva categoría de servicios llamada "limpieza de vibe coding":
Vibe Coding Cleanup as a Service
- A medida que se hace evidente la realidad de que la mayor parte del código generado por IA no es apto para producción, está apareciendo un nuevo mercado de servicios para ordenarlo y corregirlo
- Desde que Andrej Karpathy definió "Vibe Coding" a inicios de 2025, el 92% de los desarrolladores usa herramientas de IA, pero también han quedado en evidencia serios problemas de degradación de la calidad del código y vulnerabilidades de seguridad
- En la práctica, ya hay desarrolladores que se dedican profesionalmente a resolver inconsistencias, duplicaciones y lógica irracional creadas por la IA, y se están expandiendo marketplaces y servicios de consultoría especializados
- La IA es excelente para tareas pequeñas, pero al no considerar el contexto del sistema produce deuda estructural y problemas de seguridad, lo que a su vez da origen a una nueva oportunidad industrial: la "economía de la limpieza"
- Para que una empresa aproveche con éxito la programación con IA, puede dejar los prototipos en manos de la IA, pero debe invertir en personal especializado para arquitectura, seguridad y procesos de prueba y limpieza
La aparición y expansión del vibe coding
- A inicios de 2025, Andrej Karpathy usó el término "vibe coding", con lo que el concepto quedó establecido
- Una forma de generar funciones completas mediante conversaciones en lenguaje natural
- Se difundió rápidamente junto con la expectativa de que podría multiplicar por 10 la productividad
- Según GitHub, el 92% de los desarrolladores usa herramientas de programación con IA
- Copilot genera miles de millones de líneas de código cada mes
- Sin embargo, según análisis de GitClear, al usar código de IA aparece una tasa de cambio de código 41% más alta
- Aumentó de forma importante el código que se revierte o reescribe en menos de dos semanas
- En una investigación de Stanford, los desarrolladores que usan asistencia de IA escriben más código inseguro y al mismo tiempo tienden a creer que es más seguro
- Las herramientas de IA provocan que se amplifiquen varios antipatrones, debido a la falta de validación de entradas, uso de dependencias obsoletas y decisiones de diseño ambiguas
La realidad de la economía de la limpieza
- Recientemente, en la industria de TI ha comenzado a aparecer discretamente una nueva área de servicios llamada limpieza de vibe coding
- Al principio empezó casi como una broma sobre "arreglar el código desastroso hecho por IA", pero ahora se está consolidando como una oportunidad de negocio real
- Según una investigación de 404 Media, algunos desarrolladores ya están construyendo su carrera solo con limpieza de código de IA
- El trabajo consiste en desarmar inconsistencias, duplicaciones y lógicas absurdas, lo que algunos llaman "AI spaghetti"
- Ulam Labs promociona Vibe Coding Cleanup como un servicio principal
- También apareció un marketplace especializado llamado VibeCodeFixers.com
- En solo unas semanas se registraron más de 300 expertos y se emparejaron decenas de proyectos
- Cliente típico: "una startup que gastó miles de dólares en créditos de OpenAI y tiene un prototipo que funciona a medias"
Por qué falla el código de IA
- El problema no es que la IA escriba mal código por sí misma, sino que no entiende el contexto del sistema y escribe código optimizado de forma local
- Como resultado, se acumulan patrones inconsistentes, lógica duplicada y huecos de seguridad, generando deuda técnica
- Según una investigación de Georgetown University, al menos el 48% del código generado por IA incluye vulnerabilidades de seguridad
- Exposición de secretos, uso de librerías antiguas y condiciones de carrera bajo carga, entre otros
- Lo más grave es que los propios desarrolladores muchas veces no entienden suficientemente el código generado por IA y por eso no detectan bien los problemas
- Thoughtworks define esto como "deuda de capacidad"
- Un fenómeno en el que el equipo pierde la capacidad de mantener el código y cae en dependencia de la IA
Oportunidad de mercado
- El mercado de limpieza está creciendo rápidamente, aunque es difícil medir cifras concretas
- Gartner proyecta que para 2028 el 75% de los desarrolladores empresariales usará asistencia de IA para programar
- Se espera que en la mayoría de los proyectos surja la necesidad de limpieza
- Incluso si solo una parte de ellos necesitara limpieza, por escala se convertiría en un mercado nuevo bastante grande
- También resulta atractivo en términos económicos
- Las startups crean rápido un MVP con IA, pero luego invierten una cantidad similar de tiempo y dinero en ordenarlo
- Aun así, sigue siendo más rápido que el desarrollo tradicional
- Los especialistas en limpieza cobran entre 200 y 400 dólares por hora
- También se están expandiendo servicios empaquetados como tarifas fijas, auditorías de código de IA y pipelines tipo "Vibe-to-Production"
- Según Thoughtworks, en proyectos que usan IA disminuye la proporción de refactorización, aumenta aún más el cambio de código y se vuelve indispensable un proceso de limpieza a gran escala antes de pasar a producción
- Varias consultoras ya comenzaron a contratar talento dedicado a funciones de limpieza o remediación de código de IA
- En conclusión, el mercado de limpieza es real, está creciendo con rapidez y todavía tiene muchas áreas sin explotar
Impacto en la ingeniería
- Está en marcha un cambio fundamental en la metodología de desarrollo de software
- El proceso de desarrollo se está reconfigurando como un esquema de división del trabajo donde la IA implementa y las personas se encargan de arquitectura, pruebas y limpieza
- Gergely Orosz compara las herramientas de IA con "un desarrollador junior muy entusiasta", enfatizando que escriben código rápido pero siempre necesitan supervisión
- Pero como la IA siempre se queda al nivel de un desarrollador junior y no evoluciona a senior, el rol del especialista en limpieza siempre será necesario
- También se están abriendo nuevas rutas de carrera
- Un desarrollador junior que aprenda habilidades de limpieza puede alcanzar un salario de nivel senior en dos años
- Los perfiles senior que entienden las fortalezas y límites de la IA generan alto valor
- Las empresas exitosas no son las que más usan IA, sino las que construyen procesos de limpieza de forma sistemática
- Las organizaciones que establezcan procesos de limpieza sólidos podrán obtener ventaja competitiva en el mercado
La postura de Donado Labs
- Donado Labs, con base en numerosas experiencias limpiando vibe code, enfatiza que la IA es útil para acelerar, pero que siempre hace falta un proceso de limpieza a cargo de expertos
- La IA se usa para prototipado y tareas repetitivas, mientras que la arquitectura central, la seguridad y las pruebas quedan en manos humanas
- Con su servicio "Vibe to Production", ponen en condiciones empresariales los prototipos hechos con IA
- Incluye pruebas, refuerzo de seguridad y documentación
- Las empresas que usan con éxito la programación con IA no son las que más la usan, sino las que la usan inteligentemente e invierten en limpieza
- La clave es hacer la limpieza en paralelo antes de que se acumule la deuda técnica
- Frente a la afirmación de que la IA reemplazará a los programadores, la pregunta "¿y quién va a limpiar ese código?" representa la verdadera oportunidad de negocio
4 comentarios
Al principio de GPT había gente que, al encargar trabajo de programación, decía que había hecho un prototipo con IA y que solo faltaba terminar un poquito, para regatear fuerte el precio.
> Los expertos en organización cobran entre 200 y 400 dólares por hora
Pero, sinceramente, ¿de verdad habrá gente que haga esto?
Antes de la llegada del vibe coding, ya había pensado que estaría bien que existiera un servicio que ordenara código hecho un desastre, y parece que alguien realmente lo está creando. Aun así, no creo que llegue a adoptarse en nuestra empresa :(
Antes era común contratar a gente para corregir los dedos en ilustraciones hechas con IA... pero ahora ya ni eso se hace.
Parece que la limpieza con IA también va a seguir ese mismo camino.
Opinión de Hacker News
Llevo bastante tiempo aceptando proyectos de “reestructuración” a través de mi negocio
Antes, el código que apenas funcionaba solía venir de agencias externas, pero últimamente parece que la fuente se está moviendo hacia los LLM
Al final, parece que se repiten los mismos problemas
Lo único que cambió fue la forma de recortar costos
Está claro por qué alguien elegiría el atajo, pero el verdadero problema aparece cuando no se entiende a fondo que eso también puede salir caro
Da igual si viene de managers, empleados o gente tercerizada: el resultado suele ser parecido
Todavía no he publicitado por separado un servicio de mejora estructural para plataformas hechas con vibe coding, pero quizá ya va siendo hora de intentarlo
El mercado de software en Australia es pequeño, así que no se escucha mucho sobre los resultados de ese tipo de experimentos
Creo que la diferencia entre el vibe coding y el desarrollo tercerizado está en el volumen de código que se produce
Una vez hice un script helper sencillo con vibe coding, y si lo hubiera escrito yo mismo habría sido como un tercio del tamaño actual, y probablemente ni habría cubierto la mayoría de los casos límite (había manejo de excepciones inútil, pero también cosas realmente útiles)
Lo único que hice fue revisar el código y quitar una línea que borraba archivos temporales porque, por error, podía terminar borrando el directorio home
Pero más tarde, al hacer trabajo de datos más profundo, me di cuenta de que algunos archivos temporales habían desaparecido y que había otras dos partes con código de borrado
La verdad es que hay tanto código que no es realista revisarlo todo a mano
Aun así, en velocidad sí es una eficiencia brutal
En adelante, planeo menos leer código con lupa y más ejecutar pruebas con IA dentro de un sandbox
Hay una diferencia importante, sobre todo con herramientas como Claude Code que tienen “modo plan”
Últimamente uso mucho Claude Code en el trabajo, y siempre empiezo en modo plan, preguntando en formato conversacional “cómo lo implementarías”, y con varias rondas de conversación voy afinando un buen diseño y un plan detallado
Después, la IA me dice exactamente qué código va a generar (junto con el diff del código), y solo tras mi aprobación final genera el código real
En contraste, cuando antes revisaba código hecho por equipos externos, era un desastre absoluto de spaghetti code imposible de entender
Creo que es buena idea poner aunque sea términos relacionados con vibe-coding en el sitio por SEO
Yo pensé algo parecido
Pero si un proyecto fue vibe-coded y terminó siendo un montón de código lleno de bugs, ¿basta con que yo llegue, arregle los bugs y ordene la estructura?
Me pregunto cómo una empresa que ni siquiera tenía la experiencia necesaria para configurarlo desde el principio puede continuar luego con el mantenimiento
Creo que tanto la subcontratación como el desarrollo basado en LLM terminan requiriendo capacidades muy parecidas
Es decir, siguen haciendo falta bases sólidas de ingeniería: levantar requisitos, comunicarse, manejar stakeholders, definir especificaciones, probar y documentar
Se me hace raro que el concepto de "vibe coding" de Karpathy se haya popularizado de esta manera
Supongo que quizá solo pasa entre gente con poca experiencia real desarrollando
Si mal no recuerdo, vibe coding era más bien una especie de estado de flujo donde “simplemente hablas con la IA y sigues adelante confiando en el resultado, sin ni siquiera revisar el código que genera”
Es una forma terrible de trabajar si la calidad del software que estás construyendo importa aunque sea un poco
Tal vez sirve para memes de Twitter, experimentos para satisfacción personal o scripts pequeños para usar en casa, pero me parece absurdo para desarrollar un producto serio
Que esto se haya vuelto tan sonado se debe al buen nombre que le puso alguien famoso como Karpathy; si lo hubiera dicho otra persona, seguramente habría pasado desapercibido
Incluso antes de la IA, desarrolladores junior o con poca experiencia ya programaban así
Copiaban y pegaban cosas de cualquier lado, comprobaban que “más o menos corrieran”, y si aparecía un bug raro o un core dump, cambiaban el orden del código hasta que dejara de pasar
Ese estilo en una empresa como mínimo te gana una advertencia, te mete en un plan de mejora de desempeño o, en el peor caso, te deja fuera
Muchas veces la gente no técnica no lograba obtener buenos resultados al comunicarse con ingenieros de software
La aparición del vibe coding me parece una reflexión sobre el tipo de software que hemos estado entregando todo este tiempo
De hecho, la calidad del software de las startups vibe-coded que conozco es pésima, pero si hace lo que ellas quieren, en esta etapa la calidad no les importa
Mientras la calidad del software no cause un "golpe real" al negocio, no van a querer asumir el riesgo de contratar desarrolladores y ver cómo su idea se distorsiona
Al final, aunque sea una basura, poder usar ya mismo lo que quieren es mejor para ellos que un software perfecto que no querían
Te guste o no, el vibe coding no va a desaparecer
A mí tampoco me entusiasma mucho el concepto, pero dentro de la organización a veces les digo a mis colegas “esto lo hice vibe coded”
Para nosotros significa algo así como “la mayor parte del código fue autogenerada por IA”
Pero jamás subiría ese código a producción sin revisión
Es más bien para experimentos ligeros, tipo “armé una app simpática de prueba con vibe coding”
Creo que Karpathy lo planteaba como un “experimento posible” que vale la pena probar para ver hasta dónde puede llegar y divertirse un poco
No creo que estuviera recomendando hacer productos reales en una empresa solo con vibe coding
La gente interpretó la expresión totalmente fuera de contexto
De hecho, Karpathy explicó en un video de YouTube lo que quiso decir
Artículo relacionado
YouTube de Karpathy: Software Is Changing (Again)
Creo que el malentendido creció porque la gente quiere creer que ahora podrá hacer fácil lo que antes era difícil
Yo sigo pensando que el tweet original era más una broma o una forma de expresar la libertad del “YOLO coding” que una recomendación real de proceso de trabajo
Solo estaba describiendo de forma simpática esa sensación de liberación que tenía en ese momento
En este momento, vibe coding se está usando prácticamente como un término para despreciar o burlarse de cualquier ayuda de codificación con IA
Cualquier herramienta se puede usar bien o mal, pero ahora el meme de “miren qué estúpido es el vibe coding” consigue votos muy rápido en internet
Ya hasta cansa
El punto central del artículo es la idea de que “si una startup logra sacar un MVP semanas antes gracias al vibe coding, entonces aunque después tenga que gastar un tiempo y costo parecido limpiándolo, igual sigue siendo más rápido que el desarrollo tradicional”
Me pregunto si de verdad es así
Por lo que he visto, si un desarrollador lo construye directamente usando ayuda de IA, la diferencia de velocidad podría no ser tan grande
Sobre todo si ya sabes que ese MVP o prototipo va a terminar entrando a producción, da la impresión de que conviene más plantear bien la arquitectura desde el principio
Pero la mayoría de producto y de dirección ve ese tiempo como un desperdicio
La verdadera ventaja del vibe coding es que el equipo de producto puede probar directamente lo que quiere sin tener que explicárselo a los desarrolladores
Quizá haya mercado para herramientas de producto basadas en vibe coding que sirvan más para clarificar especificaciones y prototipos que para producir código en sí
Ese tipo de herramientas podría darles mejores specs a los desarrolladores y al mismo tiempo darle más aporte e iniciativa al lado de negocio
En startups, salir al mercado es tan importante que, incluso si al final cuesta más tiempo y dinero en total, sigue siendo completamente razonable aceptar deuda técnica a cambio de lanzar más rápido
Por eso la gente acumula deuda técnica
Twitter también empezó como una webapp en Ruby on Rails, y cuando Justin Bieber tuiteaba se caían los servidores y aparecía el fail-whale
Pero a medida que creció, terminó contratando expertos y rehaciendo bien todo con una estructura más sólida y escalable
Quizá sirva más para un prototipo que para un MVP,
pero si no existe la disciplina organizacional y personal de no subir prototipos a prod, creo que lo correcto es evitar el vibe coding
Todos saben lo difícil que es convencer a la dirección de una empresa de que “ese código tan bonito que estamos usando ahora mismo por dentro es un desastre y hay que reemplazarlo por completo”
En estos casos, las herramientas no-code son bastante más seguras
La realidad es que la mayoría de los MVP o prototipos terminan muy pronto en producción
Recuerdo que alguien dijo una vez: “si el código del MVP no te da náuseas de lo sucio que está, entonces estás gastando demasiado tiempo en calidad de código”
Al final, esos parches temporales se convierten en la columna vertebral de la empresa
Un servicio dedicado solo a hacer ese tipo de reestructuración podría llamarse “C-Suite cleanup as a Service”, pero si se anunciara así, probablemente nadie lo contrataría
Apenas leí el texto, me quedó clarísimo que estaba escrito por Claude incluso sin usar em dash
Seguro que el OP le dio como prompt sus ideas y materiales, pero había frases y matices de redacción tan típicos que salen en los LLM que se sentía forzado leerlo
Me pregunto si este estilo de escritura va a volverse anticuado con la etiqueta de “prosa de LLM” en el futuro
Parece que ahora se viene la moda del vibe-writing cleanup as a service
Llevo mucho tiempo usando mucho el em dash, pero ya siento que llegó la época en la que tendré que bajarle, aunque sea a la fuerza
Microsoft Word cambia automáticamente los guiones por em dash
Creo que el vibe coding se parece al trabajo de plomería DIY
Lo intentas tú mismo y, cuando el baño se inunda, terminas llamando a un plomero de emergencia y pagándole caro
En el proceso, la próxima vez aprendes un poco más
Se puede ver de forma parecida, pero un plomero profesional también usa bien herramientas que ayudan al DIY
La diferencia es que los expertos saben bien cuándo y hasta dónde usarlas
Yo diría que es aún peor
En plomería al menos ves con tus propios ojos lo que estás haciendo, pero con vibe code un día de repente algo deja de funcionar y no tienes idea de por qué
En YouTube también se ve a muchos plomeros DIY que trabajan con más cuidado que algunos profesionales
Creo que dependerá de si quien hace vibe coding realmente aprende algo de esa experiencia
Habrá que verlo con el tiempo
De verdad siento que esta analogía encaja muy bien
Así como un agente inmobiliario presionado podría hacer un trabajo de plomería a las carreras para vender una casa, un fundador de startup también puede improvisar algo rápido para mostrárselo a inversionistas o clientes y luego llamar a un experto de verdad para que lo limpie
Con suerte, evitará un desastre grande antes de que eso pase
Me sorprendió pensar si el término Janitor Engineer ya existía en la industria
Además, después de "Why AI code fails at scale", todos los links del artículo estaban rotos, y eso me llamó aún más la atención porque era un texto reciente
Ojalá nadie lo tome a mal
Desde que se puso de moda el vibe coding, yo también he tenido medio en broma un plan de retiro como consultor de “all-organic-code”, dedicado a deshacer y ordenar el montón de código que generan las IA
Lo verdaderamente raro suele ser más bien un proyecto greenfield
El vibe coding está debilitando muy rápido la documentación y la claridad de la arquitectura
Las empresas solo consideran importantes métricas como la cantidad de tokens de código generados y la velocidad del prototipado, e ignoran los costos ocultos de mantenimiento y limpieza
Ahora la habilidad real ya no es generar, sino limpiar
La verdadera habilidad está en guiar bien desde el principio para obtener software correcto
Hay gente que cree que Claude Code “es la nueva tecnología”, pero para hacerlo bien hace falta muchísima más participación
En realidad no es tan distinto de la ingeniería de siempre
La clave es minimizar costos y cumplir requerimientos
Si no exiges explícitamente mantenibilidad, obtienes exactamente el resultado que pediste
No entiendo por qué sería la muerte de la documentación
También existe la forma de escribir la documentación desde el principio y luego desarrollar comprobando que el código coincida con ella
O hacer que la documentación se genere a partir del código y revisar personalmente si queda bien
Nuestra empresa lleva décadas encargándose de recuperaciones urgentes para sistemas críticos de clientes (fallas que provocan pérdidas económicas graves y que ellos no pueden resolver por sí mismos)
En los últimos años, este tipo de casos ha ido aumentando bastante rápido
El vibe code se parece al legacy code en muchos sentidos
Da miedo tocarlo porque no confías en el código, y tanto la calidad interna como la externa son bajas
Pero también hay diferencias
Tiene poco código para la edad que tiene, una presión de calendario enorme y expectativas infladas
Lo más costo-efectivo es mover la mayor cantidad posible de errores hacia antes del runtime, idealmente a la etapa de diseño o de compilación
El problema es que, con la IA, todo el mundo está corriendo demasiado rápido hasta llegar al runtime
Por cierto, vale la pena leer “Vibe code is legacy code (val.town)”
Post relacionado en HN
Que sea legacy code no significa siempre que sea malo
Suele ser complejo o estar poco documentado, y muchas veces acumula parches operativos grandes y pequeños durante mucho tiempo
También puede incorporar muchos problemas reales de operación (como requisitos nuevos) y seguir funcionando bien en producción
El problema aparece cuando desaparece la gente que conocía esa base de código, o incluso ya no queda nadie que domine el lenguaje o las herramientas con las que se hizo
Me pregunto si el vibe coding se puede aplicar también a lenguajes fuertemente tipados
Estoy de acuerdo en que el código hecho con vibe puede tratarse como legacy code
Pero me da curiosidad si la gente también tiende de verdad a no querer tocar el vibe code
Me da la impresión de que la generación de código con LLM podría incluso desaparecer en el futuro
El artículo asume siempre que se generará código con LLM y que siempre habrá que limpiarlo, pero si el costo del LLM más el costo de limpieza termina siendo siempre más alto que el salario de un desarrollador, ¿no habrá que volver a que los humanos escriban el código directamente?
Generar código con LLM y revisarlo antes de usarlo no es lo mismo que vibe coding
En vibe coding, el código terminado se usa tal cual, sin revisión
No parece que ninguna de las dos formas vaya a desaparecer
El vibe coding basado en IA de hoy en día está perdiendo popularidad poco a poco
Porque pronto aparecerá una IA todavía mejor
Si te pasas todo el día haciendo solo vibe coding, quizá termines con una estructura de costos imposible de sostener
Puede que el entusiasmo de todos haya sido una ilusión provocada por demasiada ayuda y asistencia, y que más adelante llegue el golpe de realidad
Lo que sí no va a desaparecer es la tendencia a tener herramientas de ayuda con autocompletado predictivo y generación automática entrenadas con muchísimos casos de código
Es como antes, cuando se programaba sin syntax highlighting, pero hoy nadie querría volver a eso
Teclear DFS por octogésima vez no hace que me sienta más programador