¿Por qué forzar herramientas de IA en tus ingenieros es la receta perfecta para el desastre?

Los managers están presionando a sus equipos de desarrollo para adoptar IA sin considerar las consecuencias reales

La presión en la industria tecnológica es abrumadora. Cada pocos días aparece un nuevo artículo sobre cómo los ingenieros son X% más productivos gracias a la IA, y cómo la empresa Y despidió a cientos de desarrolladores porque «ya no son necesarios».

Los CEOs y ejecutivos leen esto y piensan: «¿Por qué no vemos más funcionalidades lanzadas en nuestra empresa? Nuestros ingenieros están obsoletos y no adoptan las herramientas de IA lo suficientemente rápido. ¡Vamos a convertirnos en una empresa AI-first!»

Aunque no sea exactamente este el flujo de pensamiento, el resultado es que los ingenieros en todas partes están presionados para enviar código más rápido, adoptar las últimas herramientas y volverse «AI first». Y tus ingenieros necesitan que su manager los ayude en esta batalla.

El modelo mental inverso: cómo garantizar un desastre

Para entender mejor el problema, utilicemos la inversión como modelo mental. Si quisiera asegurarme de que la adopción de herramientas de IA termine en desastre, ¿qué haría?

1. Forzarlo todo

Cursor es lo más popular ahora mismo. Prohibiría a todos los ingenieros usar IntelliJ/PyCharm.

Además, cada nueva herramienta interna tendría que construirse con Bolt o Lovable.

¡Ah, y DEBEMOS tener agents! No más llamadas simples a APIs. ¿Necesitamos datos del clima? Creemos un ‘Weather agent’ que nos consiga la información.

La obsesión con los «agents» es particularmente molesta. Si alguien usa la palabra «agent» de forma vaga en una conversación, inmediatamente dejo de escucharlos. No llames «agent» a un switch statement con llamadas a APIs. No hay nada malo en decir simplemente ‘código’.

2. Crear calificaciones de adopción de IA

Empezaría a elogiar a las personas que adoptan más herramientas y las usan más. Podríamos crear una tabla de clasificación, ¡basada en tokens utilizados! Y vinculemos las promociones a esto: si no usaste 10M tokens en un mes, ¡no puedes ser promovido!

Finalmente, ¡tenemos una métrica medible para la próxima revisión de rendimiento!

¿Crees que estoy bromeando? He visto cosas así en LinkedIn, sobre cómo los ‘mejores’ empleados están agotando el presupuesto de herramientas. Esto es una locura. ¿Por qué volvemos a elogiar el uso y no los resultados? ¡Midamos líneas de código otra vez! La ley de Goodhart en su máxima expresión.

3. Matar la forma ‘antigua’ de escribir código

Los ingenieros que escriben código línea por línea deberían ser ridiculizados. Todos deberían desarrollar el hábito de pedirle a la IA que haga las cosas. Si atrapas a alguien actualizando un mensaje de log manualmente, repréndelo frente a todos.

La IA debería escribir tus pruebas. Debería depurar los incidentes de producción. Debería diseñar tus pantallas. ¡No más trabajo manual en nuestra empresa!

¿No estás exagerando?

El resultado de estos tres enfoques será, como espero que estés de acuerdo conmigo, un completo desastre.

Pensemos en esto: ¿cuál es tu objetivo?

• «¿Convertirse en una empresa AI-Native?»
• «¿Adoptar las mejores herramientas?»
• «¿Lanzar más rápido?»
• «¿Mostrar a los inversores que te estás adaptando a la IA para subir el precio de las acciones?»

Si es lo último, no puedo hacer nada al respecto. Pero si es una de las primeras tres, esperemos que el objetivo real detrás sea servir mejor a tus clientes y hacer crecer tu negocio.

¿Por qué entonces te enfocarías en herramientas y no en resultados? Si optimizas para la adopción de herramientas, no te sorprendas si terminas con un ritmo más lento y un completo desastre en un año.

Tu aplicación probablemente ya está en la fase de enshitification, ¿tal vez deberías enfocarte en eso primero?

Qué deberían hacer realmente los engineering managers

Definitivamente NO estoy diciendo que deberíamos ignorar estas herramientas. SÍ hay ingenieros que son anticuados y resisten sin darle una oportunidad real. Tienes la responsabilidad de ayudar a tu equipo a adaptarse al nuevo mundo (y ES un nuevo mundo).

Pero hay muchas mejores maneras de hacerlo:

Dar tiempo para explorar

No hay adopción de ‘costo cero’ en empresas existentes. No estás construyendo un SaaS de lista de tareas donde puedes crear una solución completa en 30 minutos usando Cursor.

Adaptar cualquier herramienta de IA a una base de código existente (y grande) es difícil y toma tiempo. Necesitas experimentar con ella durante el trabajo real, evaluar qué funciona mejor y ajustar constantemente el flujo.

Esto dolerá a corto plazo, pero verás un aumento de velocidad a largo plazo, asumiendo que dejas que las personas elijan las herramientas correctas y los casos de uso correctos.

Toma un par de ingenieros entusiastas y deja que lideren este esfuerzo. Reduce su carga de trabajo en un 20% y pídeles que jueguen con los juguetes más recientes durante su trabajo.

O toma una semana/mes completo fuera del roadmap para explorar.

Compartir qué funcionó en TU organización

No hables de cosas de otras empresas: en el 90% de los casos no será relevante para ti. En su lugar, entiende qué funcionó genial en TU empresa y compártelo con todos.

Te prometo que la mayoría de los ingenieros no son resistentes solo por serlo, ni por seguridad laboral. Es porque realmente no puedes decirle a Claude ‘mejora el rendimiento de nuestra webapp’ y esperar algo útil.

Sí, puedes y debes usarlo para ayudarte a depurar, analizar, planificar, hacer brainstorming. Y SÍ está mejorando escribiendo código en bases de datos complejas.

Pero todavía son los primeros días.

¿Honestamente crees que TODOS tus ingenieros son peores que los de las empresas sobre las que lees en las noticias? Espero que no, y que sepas que tienes algunos ingenieros excelentes.

Cuando tus ingenieros vean algo que funciona, lo adoptarán por sí mismos. Confía en su juicio.

Dar tiempo a las personas para adoptarlo a su manera

El mundo no se está acabando. No es ‘IA o muerte’.

En mi opinión, en lugar de enfocarte en qué herramientas usan tus ingenieros, deberías preocuparte por qué trabajo entregan.

Entonces, si tienes 6 ingenieros, 3 que usan herramientas de IA y 3 que no, y los primeros 3 están haciendo un trabajo mucho mejor (más rápido, mayor calidad, lo que quieras medir), entiende por qué, y si encuentran una gran manera de usar IA que funciona, ¡genial! Compártelo con los otros tres.
Si crees que algo así es inviable en una organización grande, observa el ejemplo de Monday, una empresa cotizada de 15 000 millones de dólares que se permitió cinco semanas para explorar. Durante ese tiempo puso en marcha un programa con tres pilares:

• Charlas semanales impartidas por personas campeonas internas de IA, centradas en casos de uso y flujos que ya funcionaban.
• Talleres prácticos entre pares, donde cada equipo llevaba su propio problema y lo abordaba con las nuevas herramientas.
• Demostraciones semanales con 127 envíos en total; una regla simple: mostrar lo que está en producción, lo que falló y lo que se aprendió.

No fue perfecto —por ejemplo, insistieron en que “no supone un trade-off con la hoja de ruta”, algo discutible—, pero claramente apunta en la dirección adecuada.

Palabras finales

Conviene añadir algunos matices. Existe presión para que las personas ingenieras eleven su nivel —el autor lo trató en The software engineering «squeeze» (24 de junio)— y es previsible que las herramientas sigan mejorando. Por ello, dedicar tiempo a experimentarlas y adoptar solo lo que realmente funcione resulta una estrategia sensata.

Cuando se parte de una base de código nueva o de un prototipo, los beneficios pueden ser enormes. En repositorios simples y bien definidos se puede avanzar en dos meses lo que antes costaba casi un año, justo el escenario ideal para la IA.

Estas ideas pueden parecer contradictorias, pero el mensaje esencial es claro: no existen recetas universales. Explora, mide resultados y conserva únicamente aquello que impulse de verdad al equipo.