With AI becoming an integral part of every stage of the development cycle, the role of the developer is evolving rapidly. Automation, new trade-offs, a shift towards design skills rather than execution… the landscape is changing. To understand what is really changing in the day-to-day work of tech teams, we spoke to Karim Bourass, Lead Software Engineer at Berexia, who is observing this transformation from the inside and is already seeing its operational impacts.
En tu opinión, ¿cuál es el impacto real de la IA en la profesión de desarrollador hoy en día?
«Todo lo que es código repetitivo, andamiaje, conversión de formatos, pruebas repetitivas… sí, se ha acelerado en gran medida.
Pero ¿entender una necesidad empresarial difusa, arbitrar entre restricciones contradictorias, diseñar una arquitectura que resista el paso del tiempo? Eso sigue siendo 100 % humano.
El verdadero impacto es este: quien rechaza la IA pierde una ventaja competitiva real. Pero quien lo delega todo sin espíritu crítico genera deuda técnica a una velocidad nunca vista.»
¿Qué tareas te ayuda realmente a acelerar la IA en tu día a día como Tech Lead, y cuáles te niegas a delegar?
«En concreto, la IA me ayuda enormemente en:
- El scaffolding de módulos backend/frontend (guards, interceptors, DTOs, estructura básica, pruebas).
- Las consultas SQL complejas, sobre todo cuando trabajas con varios esquemas con agregaciones pesadas.
- La redacción de documentación técnica.
- El debugging exploratorio cuando te topas con un sistema legacy que no conoces
¿Qué es lo que me niego a delegar? Las decisiones de arquitectura. El diseño de API entre servicios. Y la revisión final del código (PR). La IA no entiende tu contexto organizativo, las limitaciones del cliente ni los compromisos que aceptas a sabiendas.»
¿Puedes compartir un ejemplo concreto en el que la IA haya mejorado una entrega o desbloqueado una situación técnica?
- «En un proyecto de puntuación con ML, había que extraer características de cinco esquemas diferentes de la base de datos. Uniones complejas, agregaciones temporales, mucho ir y venir. Normalmente son dos o tres días de SQL puro. En este caso, yo describía la lógica de negocio, la IA generaba el SQL, yo lo validaba y lo ajustaba. Terminado en medio día.
- Otro caso: integrar un conector a una API de CRM que no conocía en detalle. La IA aceleró toda la fase de exploración, lo que me permitió centrarme en la robustez y la gestión de errores en lugar de pasar horas leyendo documentación.»
¿Cómo acompañas a los desarrolladores (seniors y juniors) para que utilicen la IA sin volverse dependientes de ella?
«Un junior que copia y pega código generado por la IA sin intentar comprender lo que hace no progresa, acumula ignorancia técnica sin darse cuenta. La IA es un acelerador, no un profesor. En las revisiones de código, siempre hago la misma pregunta: explícame qué hace tu código. Si no eres capaz de defenderlo, no tiene nada que hacer en el código base. Da igual quién lo haya escrito.
En el caso de los seniors, la trampa es diferente, pero igual de peligrosa: es la pereza intelectual. Cuando empiezas a dejar que la IA piense por ti sobre la arquitectura o los casos extremos, estás retrocediendo. Y es engañoso porque el resultado parece limpio.
Al final, el principio es el mismo para todos: la IA genera, tú validas y asumes la responsabilidad.»
¿Cambia la IA tu forma de hacer la revisión de código o de transmitir las buenas prácticas?
«Claramente sí. Antes, gran parte de la revisión se centraba en errores de nomenclatura, estructura o patrones que faltaban. La IA ha reducido ese ruido. Hoy en día, la revisión se centra en los temas importantes: coherencia con el código base, implicaciones de seguridad, mantenibilidad a largo plazo. Pero hay una trampa. El código generado por la IA suele ser «correcto pero genérico». Se compila, pasa las pruebas básicas, pero no respeta necesariamente tus convenciones internas o tus restricciones de rendimiento. Hay que estar aún más atento.»
¿Qué riesgos observas cuando un equipo utiliza la IA sin un marco claro (calidad, seguridad, deuda técnica)?
«Lo primero que hay que evitar es el «vibe coding» puro: lanzar un prompt, obtener una feature de una sola vez y deployarla sin pensar. Funciona una vez, pero a escala de proyecto es una bomba de relojería. Sin un marco claro, te encuentras con tres problemas: deuda técnica invisible porque el código de IA parece limpio pero es verboso, e inconsistente con tu código base existente. Fugas de datos porque los desarrolladores pegan código de negocio, credenciales o esquemas de base en las peticiones sin plantearse preguntas. Y una erosión de las competencias: un equipo que ya no sabe escribir SQL, depurar a mano o entender lo que hace el ORM bajo el capó es un equipo que solo se mantiene en pie mientras la IA cubra su caso. El día que no sea así, no habrá nadie para tomar el relevo.»
En tu opinión, ¿qué habilidades interpersonales seguirán siendo imprescindibles para un desarrollador en un entorno en el que la IA está omnipresente?
«Para mí, la competencia que tendrá más valor en el futuro no es escribir código, sino comprender una necesidad empresarial —a menudo difusa— y traducirla en una arquitectura técnica limpia que se pueda implementar utilizando herramientas de IA. La etapa del código 100 % puro ya la hemos superado. Hoy en día, utilizar herramientas de IA ya no es un lujo, es una obligación. Quien no las adopte se quedará atrás por su propia cuenta.»