Me despidieron por la IA. Y esa misma tarde decidí construir con ella.

El 11 de marzo de 2026, beBee, la empresa donde llevaba ocho años y medio trabajando — primero como desarrollador, después como CTO — cerró su oficina de Miranda de Ebro y despidió a nueve programadores. La prensa lo recogió dos meses después, el pasado 8 de mayo. Yo era uno de ellos.

Esta no es una historia de resentimiento. Es el relato de cómo viví desde dentro un cambio de paradigma que primero transformó nuestra forma de trabajar, después hizo desaparecer nuestro equipo y, finalmente, me empujó a construir algo nuevo.

Antes del despido: cómo trabajábamos

beBee no era una empresa técnicamente atrasada. La arquitectura era moderna — cloud, despliegues automatizados, bases de datos no relacionales — y la aplicación principal era un producto rentable, maduro y estable. Procesaba volúmenes muy serios de información, integraciones con terceros, envíos masivos de correo, cruces de datos. La parte invisible pesaba más que la interfaz, aunque desde dirección lo que se veía en pantalla solía pesar más que lo que ocurría por debajo.

Yo, como CTO, era quien aterrizaba las peticiones de dirección. Las hablaba con el equipo, las repartía entre las personas adecuadas, tomaba las decisiones de arquitectura y aseguraba que las piezas encajasen antes de llegar a producción. Las decisiones de producto no se tomaban de forma unilateral: nos reuníamos con dirección para entender qué querían conseguir, madurábamos la idea, la analizábamos con el equipo, y volvíamos a poner en común lo que habíamos descubierto. Si aparecían limitaciones, riesgos o detalles no previstos, se volvían a discutir y se elegía la mejor solución. Eso no era lentitud: era construir con criterio.

Desde Miranda vivíamos cada día el trabajo de integrar piezas, validar que no se pisaban unas con otras, comprobar regresiones, revisar que el código siguiera funcionando cuando entraba en contacto con el resto del producto. Desde Madrid, donde estaba la dirección, muchas veces solo se percibía que las cosas tardaban más de lo deseado.

La IA cambió la escala de lo que podíamos hacer

La IA llegó al equipo primero como asistente: Perplexity, ChatGPT, Cursor. Ayudaba en tareas cotidianas, aceleraba búsquedas, desbloqueaba dudas. El cambio cualitativo llegó con Claude — pero con un matiz importante. La dirección la adoptó muy pronto y empezó a experimentar por su cuenta, sin dar acceso ni licencias al equipo hasta bastante tiempo después. Cuando las recibimos a mediados de enero, comprobamos por nosotros mismos que ya no era un copiloto para una persona: estaba alterando la escala de lo que un equipo entero podía abordar.

Tareas que durante años habían sido costosas o poco agradecidas empezaron a desbloquearse: traducciones con contexto, auditorías SEO, revisión global de código, automatizaciones, optimización de costes, análisis de URLs, propuestas de mejora que antes habrían exigido perfiles muy distintos o mucho más tiempo. Empezamos a sacar adelante funcionalidades complejas en una fracción del tiempo. Muchas seguían necesitando supervisión humana, criterio técnico y revisión final, pero la velocidad era otra. Tan distinta que en la propia oficina lo comentábamos abiertamente: si el ritmo seguía, tarde o temprano iba a sobrar gente.

Dos visiones de la IA

Ahí apareció la fractura real. Mientras el equipo seguía entendiendo la IA como una herramienta potentísima que había que integrar en un flujo serio, la dirección empezó a moverse hacia otro modelo: menos proceso, menos validación intermedia, mayor tolerancia al error si eso permitía desplegar antes.

Nosotros trabajábamos con un flujo bastante estándar: desarrollo en local, integración, paso por preproducción, pruebas, supervisión, producción. La alternativa que dirección empezó a construir con IA tenía otra lógica: si el producto no es «un banco», se pueden asumir pequeños fallos a cambio de moverse mucho más rápido. Ese cambio de filosofía lo altera todo. Cuando se acepta que algunos caminos pueden romperse porque se prioriza velocidad, ya no se está optimizando el mismo tipo de producto.

No era que el equipo estuviese en contra de la IA, ni que no supiéramos usarla. De hecho, cuando empezamos a trabajar de verdad con Claude comprobamos por nosotros mismos que estábamos ante una revolución. Lo que había era una asimetría de experiencia: la dirección había empezado antes a experimentar por su cuenta y hablaba desde un bagaje que el equipo todavía no tenía. Desde fuera podía parecer resistencia. Desde dentro era curva de aprendizaje.

Desde diciembre empezamos a notar algo extraño: la dirección dejó de prestar atención al trabajo cotidiano de la oficina. Seguía habiendo reuniones, pero ya no existía el mismo seguimiento ni la misma conversación continua sobre prioridades reales del equipo. La explicación llegó después. Mientras nosotros aprendíamos a apoyarnos en la IA para multiplicar nuestra productividad, ellos ya iban por otro camino: estaban intentando levantar una versión alternativa del producto, construida con Claude, para desplegarla directamente a producción, sin pasos intermedios de revisión. Como ese experimento les funcionaba lo suficiente y además veían que reduciría la factura de infraestructura, la oficina fue quedando en un segundo plano.

El día que cerraron la oficina

No vimos venir el golpe en toda su magnitud. Intuíamos que, con el ritmo nuevo, podía sobrar parte del equipo. No imaginábamos que la decisión sería cerrar la oficina entera.

Un lunes nos dijeron que el miércoles habría una reunión. Esa frase, dicha así, sin contexto, no permite anticipar nada concreto, pero deja un peso particular en las cuarenta y ocho horas siguientes. El miércoles nos sentaron a todos juntos y nos comunicaron que cerraban la oficina y que la aplicación sería sustituida por otra desarrollada con IA. Después vino el proceso laboral, que terminó resolviéndose en conciliación: despidos formalizados inicialmente como disciplinarios, reconducidos a improcedentes mediante acuerdo.

En ese momento decidí escribir este mensaje en el grupo de Whatsapp de mis amigos: Aquí uno que se ha quedado ya sin curro por la IA. Me pido primer 😖

Mi compañero David de la Fuente, ingeniero del equipo, lo resumió bien después en una entrevista: «Nos quedamos un poco en shock… la inteligencia artificial puede reducir muchísimo el trabajo, pero sigue necesitando supervisión humana.» Comparto la lectura. Lo de «shock» no es retórica: cuando llevas casi una década construyendo un producto y te informan en una reunión que esa relación se acaba esa misma semana, hay un silencio en la sala difícil de describir. ¡Y ahora qué!

Lo que dijo el CEO, y por qué creo que se equivoca

La primera nota de prensa que salió, en BurgosConecta, ya recogía la explicación de la dirección. Y fue precisamente esa nota la que se difundió por redes sociales y llegó a Menéame, con cientos de meneos y un debate amplio en los comentarios. Javier Cámara-Rica, consejero delegado de beBee, declaraba:

«No necesitamos programadores, necesitamos ingenieros de IA. Los programadores no tienen esa capacidad o esa visión porque son perfiles muy ejecutores.»

Y unas líneas más abajo:

«Hay perfiles que directamente en seis u ocho meses van a desaparecer totalmente.»

Sobre esto sí tengo una posición clara, y es una de las razones por las que escribo este post.

La afirmación de que los programadores son «ejecutores» sin capacidad para guiar a una IA no encaja con lo que hacemos cada día. Un buen programador descompone problemas complejos, traduce necesidades ambiguas a instrucciones precisas, evalúa resultados, detecta errores y decide cuándo una solución es válida y cuándo no. Eso es exactamente lo que pide trabajar bien con un modelo de lenguaje. La IA no elimina ese rol; lo vuelve todavía más importante, porque el coste del error se mueve del «esto no compila» al «esto compila pero está mal». Y detectar lo segundo es lo difícil.

Que el CEO de una empresa diga públicamente que su propio equipo técnico no servía para esta transición tiene un coste real: nos quita visibilidad para encontrar trabajo a quienes salimos de allí, y deja en el imaginario público una idea equivocada sobre qué hace un programador. Por eso escribo y por eso firmo este post. La mejor refutación que se me ocurre no es una réplica en prensa: es construir.

Lo que viene, y por qué construyo Forjia

El mismo día del despido tuve una intuición clara: si esto estaba ocurriendo en un equipo tecnológico maduro, iba a acabar afectando a muchísima más gente. Fuimos de los primeros en estar fuera, pero el resto va a caer detrás como un castillo de naipes. La IA no solo acelera tareas; reordena sectores enteros, redefine qué trabajo hace falta y obliga a reconsiderar dónde está el valor humano. Y no creo que se limite al software. La siguiente ola va a ser la robótica: durante mucho tiempo el cuello de botella de un sistema físico no fueron los motores ni los ejes, sino la inteligencia necesaria para coordinar todas las articulaciones y adaptarse al entorno en tiempo real. Esa parte ya está. Cuando se acople a hardware estable, el reordenamiento será mucho mayor.

La pregunta personal no era si tenía experiencia para seguir trabajando en desarrollo. La tenía: ocho años y medio en beBee, y antes proyectos grandes en sectores exigentes — incluida una central nuclear y un sistema completo de gestión empresarial (contabilidad, remesas bancarias, almacén y facturación) construido desde cero por mí solo. La pregunta era otra: ¿tenía sentido buscar el mismo tipo de trabajo en un mercado que ya estaba cambiando delante de mis ojos? Decidí que no. Si la IA iba a alterar tan profundamente la manera de construir software, lo razonable era situarme en el lugar desde donde aprovechar ese cambio, no esperar a que me alcanzara otra vez.

Empecé esa misma tarde. Había un contexto que me parecía clarísimo: la llegada de VeriFactu y TicketBAI iba a empujar a muchos autónomos y pequeñas empresas a revisar cómo facturan. Ahí había una necesidad real, un conocimiento que ya traía de proyectos anteriores, y una oportunidad para construir algo útil. Elegí autónomos porque es el segmento que más fricción tiene con la AEAT y menos herramientas IA decentes: Quipu, Holded, Anfix y compañía resuelven contabilidad para empresas con gestor; el autónomo que factura solo desde el móvil, le manda el ticket al gestor por WhatsApp y nunca abre un panel web está mal atendido.

Así nació Forjia. La idea es simple en superficie:

• Le mandas un audio: «factura 250 € a Juan Pérez por la reforma del baño». Llega el PDF listo para enviar.
• Le mandas la foto del ticket de la gasolinera. Queda contabilizado al 50 % por el artículo 95.3 del IVA.
• Le preguntas: «¿cómo va el trimestre?». Te contesta con el borrador del 303.

Sin menús, sin campos, sin paneles. WhatsApp. El nombre viene de «forjar tu negocio con IA», y empecé a construirlo apoyándome en Claude, en mi experiencia como desarrollador y en mis conocimientos de gestión contable y administrativa. No partía de una intuición vacía: ese bagaje ya estaba ahí esperando.

Tiene una premisa muy clara, y aquí es donde mi experiencia en beBee marca el diseño: la IA puede acelerar, proponer, redactar, clasificar y asistir; pero la parte crítica, determinista y segura — la numeración de facturas sin huecos, la firma TicketBAI inmutable, los cálculos fiscales — vive en código de servidor y en reglas bien definidas. Un modelo no siempre interpreta igual y no siempre responde igual. Por eso hace falta una capa de control que mantenga la confianza del usuario. La diferencia entre «construir con IA bien» y «construir con IA rápido» es esa frontera. Lo vi de cerca durante meses.

Lo que quiero demostrar

Hay algo casi simbólico en todo esto. La misma historia que se usó en prensa para ilustrar que la IA puede sustituir a un equipo de programadores es, en mi caso, la que demuestra que un programador con experiencia, criterio y conocimiento profundo de un sector puede reinventarse con esa misma IA — y construir algo nuevo con mucho menos capital del que habría hecho falta hace unos años.

La IA está cambiando el mercado laboral y probablemente va a destruir muchos puestos tal y como los conocíamos. Pero también está abriendo la posibilidad de que personas con experiencia y criterio construyan herramientas muy valiosas de una forma antes impensable.

Mi conclusión es sencilla. No, los programadores no somos malos «ingenieros de IA». Al menos no por definición. Cuando se entiende cómo resolver problemas, cómo estructurar sistemas y cómo validar resultados, lo que cambia no es la capacidad de aportar valor, sino el medio con el que se construye.

Y en mi caso, ese medio ahora se llama Forjia.