Está tu equipo de ingeniería preparado para la velocidad de la IA?


Una frase de Max Kanat-Alexander en un podcast que escuché recientemente se me quedó grabada:

La IA es un amplificador.

Amplifica todo lo bueno que existe en tu proceso de desarrollo. Y también todo lo malo.

Si tu equipo tiene buenos tests, CI/CD confiable, código bien estructurado y procesos eficientes, los agentes pueden trabajar mucho más rápido dentro de ese sistema.

Pero imagina lo contrario:

  • Los tests son flaky.
  • El pipeline tarda 40 minutos y falla con frecuencia.
  • El código es difícil de entender.
  • El proceso de code review ya es un cuello de botella.

Ahora introduce una herramienta capaz de generar tres veces más código en ese sistema. Probablemente no te volviste tres veces más productivo. Solo pusiste tres veces más presión sobre los cuellos de botella que ya existían.

Max menciona un dato interesante: incluso antes de la IA, los desarrolladores dedicaban apenas alrededor del 14% de su jornada a escribir código. Aunque la IA hiciera que esa parte fuera instantánea, todo el resto del ciclo seguiría existiendo.

De hecho, algunos problemas podrían empeorar. Si puedes generar código mucho más rápido, los tests deficientes se vuelven más peligrosos. El code review se sobrecarga. Los problemas de arquitectura pueden propagarse más rápido.

Esto ayuda a explicar por qué dos empresas pueden comprar exactamente las mismas herramientas de IA y obtener resultados completamente diferentes.

Tal vez la pregunta para un CTO no debería ser solamente:

“Cómo aumentar la adopción de IA en mi equipo?”

Sino también:

“Nuestro entorno de ingeniería está preparado para un equipo capaz de producir mucho más rápido?”

Porque tal vez la mejor inversión para aumentar la productividad con IA no sea una nueva herramienta de IA. Puede ser arreglar aquello que ya dificultaba el trabajo de tus desarrolladores antes de ella.

Y existe una consecuencia todavía más peligrosa cuando esto no sucede: la IA puede empezar a deteriorar el propio entorno en el que trabaja.

Ese será el tema del próximo texto.

Fuente: Engineering Enablement Podcast: conversación con Max Kanat-Alexander, Executive Distinguished Engineer en Capital One.

Leo Andreucci - CTO Mentor

Ex-VP Engineering @ Creditas ($4.8B). 20+ years building and scaling tech teams. Today, I help CTOs make better decisions.

Read more from Leo Andreucci - CTO Mentor

Uma frase do Max Kanat-Alexander em um podcast que ouvi recentemente confirma o que muita gente vem falando: IA é um amplificador. Ela amplifica tudo que existe de bom no seu processo de desenvolvimento. E tudo que existe de ruim também. Se seu time tem bons testes, CI/CD confiável, código bem estruturado e processos eficientes, agentes conseguem trabalhar muito mais rápido dentro desse sistema. Mas imagine o contrário: Os testes são flaky. O pipeline demora 40 minutos e quebra com...

Imagina la siguiente situación: eres responsable de algunos equipos de desarrollo. Esos equipos tienen stakeholders. El CEO de la empresa se acerca a uno de ellos y le pregunta por qué una determinada iniciativa está retrasada o por qué no se alcanzó algún resultado. Escenario A: el stakeholder se queja del equipo de tecnología. Dice que el equipo no entrega, que es lento, que no entiende lo que realmente necesita. Escenario B: el stakeholder dice que hubo algunos obstáculos, pero que está...

Imagine a seguinte situação: você é responsável por alguns times de desenvolvimento. Esses times tem stakeholders. O CEO da empresa chega para um dos stakeholders e pergunta por que uma determinada iniciativa está atrasada ou algum resultado não foi entregue. Cenário A: o stakeholder reclama do time de tecnologia. Diz que o pessoal não entrega, que é lento, que não entendem o que ele realmente precisa. Cenário B: o stakeholder diz que houve alguns obstáculos, mas que ele está trabalhando bem...