Abrí LinkedIn el martes en la noche y encontré algo que creí chiste hasta que revisé los perfiles. Un título de puesto que resultó ser literal.

“Vibe Coding Cleanup Specialist” como descripción profesional. No en una cuenta paródica, no en un post irónico. En perfiles reales, con foto, con seguidores, con historial.

Jonathan Lin, desde Kuala Lumpur, lo lista como “Overengineering & Vibe Coding Cleanup Specialist”. Hamza Gulraiz, en Lahore, combina “Vibe coding cleanup specialist” con React Native Developer. Nishant Gohel, desde Bangalore, tiene 22 mil seguidores y usa ese mismo título. Wilmer Mauricio Herrera Rentería, en Quito, firma como “Vibe Coding Fixer | Software Architect | MSc in AI”. Victor Istrati, desde Chișinău, Moldavia, se presenta como “Senior Web Engineer | Vibe Coding Cleanup Specialist”.

No es regional. No es una cohorte de pasantes buscando gracia. Son ingenieros con experiencia, distribuidos en cuatro continentes, que decidieron que este segmento de mercado es lo bastante grande para ponerlo como headline.

Pascal Bornet lo puso en portada hace menos de 24 horas. La frase del post que más se replicó no es la irónica. Es la operacional: vibe coding no mató al desarrollador, lo movió al layer de limpieza. Y algo tuvo que pasar esta misma semana para que cinco ingenieros al azar en cinco países eligieran ese título a la vez. Lo que pasó tiene nombre, vector y número de reporte.

Lovable filtró todo. Por eso apareció el puesto.

El lunes 20 de abril, Alex Turnbull — fundador de Groove — publicó en LinkedIn una guía de triage sobre Lovable, la plataforma de desarrollo por prompt. El título: “Lovable is experiencing a mass data leak.” Si tu equipo construyó algo en Lovable antes de noviembre de 2025, cualquier persona con una cuenta gratuita puede leer tu código fuente, tus credenciales de base de datos y tu historial de chat con la IA.

El mecanismo se llama BOLA (Broken Object Level Authorization). Dvir Arad, Tech Lead en Lumana AI, lo resumió en los comentarios: es la vulnerabilidad más común de cualquier sistema multi-tenant y no es un problema exclusivo de IA. La API de Lovable valida el token de autenticación — sabe quién eres — pero no valida si eres el dueño del proyecto que estás pidiendo. Token válido + ID de proyecto ajeno = 200 OK y te devuelve todo.

Los endpoints afectados son concretos: /projects/{id}/*, /git/files, /git/file y /documents. Un investigador con handle weezerOSINT creó una cuenta gratuita y sacó el árbol de fuentes completo de un panel de administración construido para Connected Women in AI, una ONG danesa real. 3.703 ediciones en el año, la última hace diez días. Dentro del código fuente: SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY y SUPABASE_SERVICE_ROLE_KEY hardcodeadas. Ponentes reales de Accenture Dinamarca y Copenhagen Business School expuestos con nombre, empresa y perfil de LinkedIn.

El reporte al programa de HackerOne de Lovable entró el 3 de marzo, con número #3583821. Lovable desplegó un fix, pero solo para proyectos nuevos. Un proyecto creado en abril de 2026 responde 403 Forbidden. Uno creado en octubre de 2025 sigue respondiendo 200 OK. Lovable llama a eso “intentional behavior” y recomienda marcar el proyecto como privado — feature de pago. 48 días después del reporte, el ticket sigue abierto.

Es el segundo incidente mayor de seguridad de Lovable en 12 meses. Según Turnbull, entre las cuentas expuestas hay empleados de Nvidia, Microsoft, Uber y Spotify.

La service_role key es el eslabón que rompe todo

La frase de toda esta historia que más debe importarte es ésta: SUPABASE_SERVICE_ROLE_KEY.

Supabase tiene un modelo de seguridad de dos capas. La que normalmente proteges con Row Level Security (RLS) aplica reglas del tipo “este usuario solo ve sus propios datos”. La anon key y la publishable key están sujetas a RLS. La service_role key no — bypassea toda la política de seguridad del proyecto. Es la llave maestra.

Esa llave existe para que tu backend haga operaciones administrativas que el usuario final no debería poder hacer. Está diseñada para vivir en el servidor, nunca en el cliente, nunca en un repositorio, nunca en un chat. En el mundo de vibe coding el flujo es otro. Le pides a Lovable que agregue autenticación o cree un dashboard de admin, Lovable genera el código con la service_role key hardcoded directo en el repo del proyecto, y ese proyecto termina expuesto por BOLA.

Mikhail Filatchev lo escribió en los comentarios del hilo de Turnbull con una claridad incómoda: el problema de la service_role key hardcoded es un tema aparte, no es un bug de Lovable, es una falla de higiene de credenciales que el flujo de vibe coding fomenta activamente. Pega tus keys en un chat de IA para debuggear y ese contexto queda almacenado en algún sitio que tú no controlas.

La falla estructural no es solo que la llave se filtró. Es que la llave estaba en el código de frontend para empezar, porque así fue como el agente decidió construirlo y nadie lo revisó. Si tu empresa construyó algo sobre Lovable antes de noviembre de 2025, la service_role key de ese proyecto debe tratarse como pública desde hace 48 días como mínimo. Y ese es el escenario optimista.

Cuarto incidente del trimestre, mismo patrón

Si ves solo el caso Lovable, es drama de fin de semana. Si miras el trimestre, es el cuarto punto de la misma línea.

En marzo, TeamPCP envenenó LiteLLM en PyPI comprometiendo primero Trivy, el escáner de seguridad de Aqua Security. 97 millones de descargas mensuales. La herramienta que debía proteger fue el vector de entrada.

El 1 de abril, Mercor dejó expuestos 4 TB de datos biométricos de 600 mil personas que aplicaron a entrevistas con Anthropic, OpenAI, xAI y Meta. Datos que, por definición, no se pueden rotar.

El 19 de abril, Vercel fue comprometido vía OAuth de Context.ai, un agente de IA de terceros con acceso al Google Workspace de un empleado. El ataque no fue al modelo, fue al ambiente.

Y ahora, 20 de abril, Lovable vía BOLA. Cuatro vectores distintos en un trimestre: supply chain de paquetes, dataset biométrico sin rotación, OAuth de IA de terceros, autorización rota en una plataforma no-code. El común denominador no es la IA. Es la velocidad con la que estas plataformas pasaron de prototipo a producción sin la disciplina que cualquier SaaS de 2015 tuvo que adquirir a los golpes.

El mismo Dvir Arad que mencioné antes lo describe así: trabajando microservicios en producción, el supuesto por defecto era que cualquier ID de objeto en una URL está controlado por un atacante. Ese mindset es lo que falta en buena parte del stack nuevo.

Por qué ese título apareció esta semana

Pascal Bornet lo nombró primero en LinkedIn: vibe coding no mató al desarrollador, lo convirtió en el layer de limpieza de decisiones ajenas.

Guy Pistone, CEO de Valere, respondió en el mismo hilo con una línea que vale repetir: vibe coding movió la complejidad aguas abajo. Más cerca de producción, más lejos de quien escribió el prompt. Eso no es eliminación de trabajo. Es accountability tercerizado.

La generación de código con IA hace lo que la calculadora hizo con la aritmética — baja el costo de la operación trivial. Lo que no hace es sustituir el criterio sobre qué es seguro poner en producción. Auditar un BOLA, rotar credenciales, limpiar una service_role key filtrada, reconstruir el modelo de autorización desde cero, todo eso sigue siendo trabajo de ingeniería sénior. Solo que ahora el trabajo llega envuelto en un repo que alguien más prompteó y declaró listo.

El Vibe Coding Cleanup Specialist existe porque apareció demanda. La demanda no nace de curiosidad. Nace de empresas que escalaron de 3 a 30 proyectos en vibe coding sin gobernanza y descubrieron, un lunes a las 3 de la mañana, que esos proyectos tenían la service_role key en el frontend. El título de LinkedIn es la señal pública de que el mercado ya existe.

La economía cambió y todavía no te la cobraron

La promesa original del vibe coding era construye cualquier cosa en una tarde. La promesa era verdadera mientras la alternativa fuera no construir nada. Hoy la alternativa es distinta: construye en una tarde y paga el triple después para limpiar.

Haz el cálculo con un ejemplo concreto. Un dashboard de administración con autenticación, construido en Lovable en un fin de semana, sale gratis en tiempo de ingeniero. El mismo dashboard, con la service_role key filtrada y la auditoría post-hoc para determinar si alguien exfiltró datos en los últimos 48 días, sale entre cinco y quince mil dólares por proyecto. Rotar credenciales, verificar logs de Supabase, reemitir notificaciones a usuarios afectados, actualizar política de privacidad, reescribir el backend de admin con autorización real. Todo eso es trabajo cobrado a tarifa de especialista.

El moat (ventaja competitiva) que importa en 2026 ya no es qué tan rápido puedes construir. Es si puedes construir sin que en seis meses alguien tenga que limpiar detrás de ti. Dos empresas lanzando un MVP en Lovable el mismo mes tienen la misma velocidad de salida. La que escribe el dashboard con arquitectura real desde el primer commit no paga el impuesto de limpieza en el mes ocho.

El error de cálculo común es tratar la velocidad como si fuera gratis. No lo es. La velocidad de construir por prompt viene con un pasivo diferido, invisible en el balance hasta que una API devuelve 200 OK a un desconocido.

Si usas Lovable o equivalente, tres cosas esta semana

Si tu empresa construyó cualquier proyecto en Lovable antes de noviembre de 2025, el trabajo de esta semana es mecánico y no se pospone.

Rota la SUPABASE_SERVICE_ROLE_KEY primero. Esa es la llave maestra y la prioridad absoluta. Después rota cualquier otra credencial que haya vivido en ese proyecto: connection strings, anon keys, publishable keys, y cualquier API key de terceros (Stripe, SendGrid, OpenAI, providers de auth) que haya estado pegada alguna vez en un chat con el agente de Lovable. Cualquier credencial que haya tocado un chat de IA debe considerarse expuesta — no hay forma de saber dónde terminó esa conversación almacenada.

Audita los logs de Supabase de los últimos 48 días buscando lecturas anómalas sobre tablas de usuarios, facturación o administración. Si ves consultas desde IPs o session tokens que no reconoces, estás frente a exfiltración y la notificación regulatoria pasa de opcional a obligatoria según jurisdicción. En Costa Rica la Ley 8968 obliga reporte a PRODHAB dentro de cinco días. En la UE, GDPR exige 72 horas.

Confirma si tu proyecto está afectado. Abre la URL del proyecto de Lovable en un navegador anónimo o con una cuenta gratuita distinta. Si puedes ver el código o el historial del chat, cualquier extraño también puede. Proyectos creados después de noviembre de 2025 devuelven 403 Forbidden. Proyectos anteriores devuelven 200 OK y te sirven el repositorio completo.

Si después de esta auditoría confirmas exposición, la pregunta siguiente es si vale la pena mantener ese proyecto en Lovable. Esa decisión depende del volumen de datos comprometidos y del apetito de tu empresa para seguir operando sobre un vendor con un ticket de HackerOne abierto por 48 días. Para la parte técnica de verificación continua después de rotar, puedes usar nuestro Escáner de Seguridad de API, que identifica problemas de autorización y exposición de credenciales en endpoints públicos.

El mercado del especialista en limpieza ya existe

El mercado del Vibe Coding Cleanup Specialist es real, tiene perfiles públicos y va a crecer mientras las plataformas no-code sigan enviando proyectos a producción con la service_role key expuesta en el frontend. Los ingenieros que se están posicionando ahí están haciendo un cálculo correcto sobre dónde hay demanda.

IQ Source opera en el otro lado del problema. Nuestra posición no es limpiar después del prompt. Es construir el proyecto una sola vez, con autorización real desde el primer commit, y que seis meses después no haya nada que limpiar. Es la parte menos llamativa del trabajo y es la única que no genera tickets de HackerOne abiertos por 48 días.

El martes a las once de la noche, un desconocido con cuenta gratuita en Lovable bajó el código fuente de una ONG danesa sin tocar una sola línea de exploit. El miércoles los cinco ingenieros que vi en LinkedIn tuvieron más trabajo del que pueden tomar. Ambas cosas son consecuencia del mismo cálculo que mucha gente todavía no ha hecho.