Era principios de 2025.
La función estándar de autocompletado de código en GitHub Copilot ya estaba bien consolidada. ChatGPT estaba sustituyendo a la búsqueda de Google para consultar referencias de código —e incluso ofrecía sugerencias de bloques de código bastante útiles—, pero la programación asistida por IA nos hacía más bien gracia porque o bien era demasiado simplista, carecía de un contexto de código claro o estaba ridículamente sobrecomplicada.
Todo esto cambió en la primavera de 2025, cuando las importantes mejoras introducidas en los modelos base hicieron que herramientas de programación con IA como Cursor, GitHub Copilot Agent, Windsurf, Claude Code y Cline resultaran mucho más viables. Nuestras críticas ya no parecían tener sentido, y si no nos sumábamos al plan, nos íbamos a quedar en ridículo.
En Bitly Engineering, nos dimos cuenta de que o nos lanzábamos de cabeza o nos quedaríamos atrás.
En mayo de 2025, pusimos en marcha una iniciativa de formación en ingeniería de Bitly. El objetivo: que nuestros 60 ingenieros pasen de usar la función de autocompletado de GitHub Copilot a prácticas de programación asistidas por un agente de IA lo antes posible.
Sabíamos que no podíamos detener el mundo y mandar a todo el mundo a formarse, y de hecho, la formación reglada ni siquiera existía todavía, así que decidimos crear la nuestra propia.
Nuestro enfoque consistió en desarrollar un programa de «IA en ingeniería» que combinara estructura, educación informal, experimentación y evaluaciones, partiendo de la idea de que iríamos ajustándolo sobre la marcha. Tendríamos que asfaltar la carretera mientras circulamos por ella.
Esta es nuestra historia: lo que nos ha salido bien, lo que no y lo que hemos ido aprendiendo por el camino.
Elegir herramientas de IA
Los criterios para elegir nuestras herramientas de IA eran muy sencillos: Pon a disposición de los ingenieros herramientas de última generación. Con las mejores herramientas, pudimos explorar nuevas posibilidades, aprender juntos y avanzar rápidamente. Elegimos herramientas que combinaran madurez y facilidad de uso y que tuvieran el menor impacto posible en nuestro ciclo de desarrollo. La lista de finalistas incluía:
- Cursor (Nivel empresarial con modo de privacidad activado)
- ChatGPT (Plan de equipo para un chat de IA de uso general)
- Claude Code (se añadió a mitad del programa porque se reveló como una opción de programación muy válida)
La privacidad era innegociable. Nos mantuvimos firmes en nuestros principios de privacidad, incluyendo el cumplimiento de la norma SOC2 como requisito imprescindible, la activación del modo de privacidad en Cursor para garantizar que no se guardaran datos, y nos aseguramos de que los datos de las respuestas no se utilizaran para entrenar modelos.
El lanzamiento
Empezamos en mayo de 2025 y nos marcamos los siguientes objetivos:
- Fomenta el dominio de la IA en todo el equipo: todos deberían saber cómo aprovechar las herramientas de programación de IA en sus flujos de trabajo
- Compartir experiencias y recopilar buenas prácticas
- Evalúa el impacto de forma continua
- Crea una cultura de aprendizaje y experimentación
Uno de sus puntos fuertes desde el principio: Sesiones «por encima del hombro»
Una de nuestras tácticas más eficaces fue organizar sesiones «Over the Shoulder» (OTS), es decir, sesiones de trabajo en las que los ingenieros compartían sus pantallas y mostraban flujos de trabajo de programación de IA en tiempo real y en situaciones reales.
Les pedimos a los voluntarios que ya usan agentes de IA que compartieran su trabajo, desde la configuración de las herramientas, las instrucciones y las reglas hasta cómo perfeccionaban los resultados cuando las cosas salían mal. Durante las dos primeras semanas, organizamos sesiones diarias en diferentes zonas horarias, tanto a nivel mundial como regional. A medida que fue aumentando la participación, pasamos a sesiones semanales y luego mensuales.
Fueron auténticas sesiones de trabajo en proyectos reales, como el desarrollo de funciones, la refactorización, las pruebas y la depuración, no simples demostraciones pulidas. Intentamos fomentar un ambiente de franqueza y sinceridad en estas sesiones haciendo que los primeros talleres los impartieran ingenieros con más experiencia que, a su vez, también eran nuevos en el uso de las herramientas de programación de IA. Eso ayudó a crear un espacio seguro donde la gente pudiera lidiar con la incertidumbre en público. Esto me hizo darme cuenta de algo muy importante: aquí todavía no hay expertos, solo gente que está aprendiendo.
We tried to encourage a sense of openness and vulnerability in these sessions by having more senior engineers who were also new to the AI coding tools run the early sessions.”
– Michael Richman, VP, Engineering at Bitly
Lo que hemos aprendido: Lo bueno
Las herramientas ganadoras:
- Cursor se hizo popular por su perfecta integración con el IDE, el contexto completo del código y la función de chat directamente dentro del entorno de desarrollo.
- ChatGPT se convirtió en la herramienta de referencia para debates sobre arquitectura, documentación y redacción técnica, y como alternativa cuando otras herramientas se «atascaban».
- GitHub Copilot resultó muy útil para revisar las solicitudes de incorporación de cambios, ya que detectó pequeños errores que a los revisores humanos se les podrían haber pasado por alto. A medida que el programa fue evolucionando, Copilot incorporó las «Tareas de agente» y modelos más avanzados, lo que demostró su potencia y relevancia continuas.
- Claude Code acabó convirtiéndose en una opción de primer nivel para quienes lo adoptaron, destacando por su capacidad para razonar ante problemas complejos.
También probamos ChatGPT Codex y nos entusiasmó su potencial, pero la falta de imágenes personalizadas lo hacía inutilizable para nuestras necesidades. OpenAI, estamos deseando que llegue…
En qué destacó la IA:
- Tareas repetitivas y operaciones de buscar y reemplazar en bases de código extensas
- Generar cobertura de pruebas para el código existente
- Trabajar con partes del código que no conozco
- Documentación y redacción técnica
- Sesiones de lluvia de ideas y debates sobre arquitectura
- Pruebas unitarias del backend siguiendo los patrones establecidos
Un ingeniero logró refactorizar 275 archivos en un solo proyecto de hackweek. Otros dos utilizaron la IA para crear el borrador de todo un panel de control administrativo interno en una semana. No se trataba de pequeñas mejoras en la productividad. En algunos casos, estaban resultando transformadoras.
Dicho esto, la experiencia también puso de manifiesto algunos retos.
These weren’t minor productivity gains. They were proving transformative in some cases.”
– Michael Richman, VP, Engineering at Bitly
Lo que hemos aprendido: Lo malo
No todo salió a la perfección, pero los obstáculos nos enseñaron tanto como los éxitos.
Los problemas de calidad se hicieron evidentes desde el principio. La IA podía generar código rápidamente, pero gran parte de él necesitaba una profunda refactorización para cumplir con nuestros estándares. Los ingenieros solían dedicar tanto tiempo a revisar y corregir el código como el que habrían empleado en escribirlo ellos mismos.
Se necesita revisión humana. El código generado por IA no debería enviarse para su revisión sin que el «autor» humano lo revise primero.
Las restricciones de contexto eran un rollo. Las herramientas solían perder el hilo de las conversaciones largas, lo que obligaba a volver a empezar o a repetir las explicaciones, lo cual suponía un verdadero obstáculo para los cambios complejos.
El trabajo en el frontend fue más complicado. La IA solía complicar demasiado las soluciones, repetir código y no respetar los estándares de la interfaz de usuario, mientras que las tareas de backend funcionaban mejor.
Lo que hemos aprendido: Lo incierto
Más allá de los problemas técnicos, nos encontramos con fricciones culturales.
Algunas personas se sentían presionadas a usar la IA y les preocupaba que las sustituyeran. Otros interpretaron el programa como una adopción «forzada» en lugar de una exploración. A algunos ingenieros les preocupaba perder el contacto con su oficio, sobre todo a los más jóvenes que aún están adquiriendo las habilidades básicas.
Para quienes no son desarrolladores, sobre todo para los ingenieros y analistas de control de calidad, las instrucciones no estaban claras. ¿Cómo debería usar un ingeniero de control de calidad las herramientas de programación basadas en IA? ¿Y los analistas de datos? Compartir conocimientos resultó más difícil de lo que pensaba. Incluso hoy en día, el flujo de indicaciones y buenas prácticas todavía no está como nos gustaría.
Pero encontramos una metáfora que nos ayudó: Piensa en la IA como un ingeniero competente que está empezando su carrera. Rápido, a veces erróneo, siempre hay que revisarlo. Eso se quedó grabado. Estableció unas expectativas realistas y cambió el enfoque de la conversación, pasando de la «sustitución» a la «colaboración».
El reto de medir el éxito
Es difícil medir el impacto de las herramientas de programación basadas en IA. ¿Se basa en comparaciones de «antes y después» del número de líneas de código escritas? ¿Cuántas solicitudes de incorporación de cambios hay? ¿Cuántas modificaciones? ¿La velocidad del equipo?
Sabemos que hay un impacto, pero no estamos seguros de cuál es su magnitud. Decir que «el 30 % de nuestro código lo escribe ahora la IA» da una falsa sensación de certeza. Para la evaluación, usamos un enfoque mixto, combinando valoraciones subjetivas y objetivas.
De forma subjetiva, preguntamos a los ingenieros sobre la precisión, la rapidez, la confianza en código desconocido, la carga cognitiva y la satisfacción general. Preguntamos sobre la opinión respecto a la IA antes y después del programa.
Objetivamente, estamos analizando todos los factores mencionados anteriormente, tanto antes como después de la adopción de la IA, aunque reconocemos que se trata de una orientación más que de una conclusión definitiva.
Medir el aumento de la productividad es complicado: hay demasiadas variables y no hay suficientes datos fiables. Por ahora, las tendencias de mercado y el estado de ánimo del equipo son nuestros mejores indicadores.
Ya han pasado seis meses…
La carrera de las herramientas
Han pasado seis meses y todavía no hay un claro ganador en la carrera por las herramientas. Cada herramienta destaca en una tarea concreta, y muchos ingenieros usan más de una. Personalmente, prefiero Claude Code para trabajos de programación intensivos y Cursor cuando necesito que evalúe el código y me ofrezca un resultado bien formateado.
También han surgido nuevas herramientas. Se ha lanzado Codex, se han lanzado las tareas de GitHub Copilot Agent y el panorama sigue cambiando ante nuestros ojos. Hasta ahora, seguimos sin atrevernos a firmar contratos anuales para herramientas de programación con IA, por miedo a que surja otra que se imponga claramente.
Conjuntos de reglas
Estamos trabajando en los conjuntos de reglas, que son archivos de configuración que enseñan a la IA cuáles son nuestros estándares de programación, patrones de arquitectura y errores habituales. Estamos desarrollando conjuntos de reglas tanto para las normas de codificación internas como para tareas específicas, como evaluar tickets de Jira o hacer lo que vendría a ser un «control de calidad manual» basado en los cambios en el código.
Establecer expectativas
Además, estamos siendo más claros con respecto a las expectativas. Aunque al principio se fomentaba el uso de la IA, pero no era obligatorio, estamos evolucionando como organización hasta el punto de exigir que todos los ingenieros —y todos los empleados— dominen esta tecnología.
Adaptación continua
Para agosto de 2025, las herramientas de IA pasaron discretamente de ser un «proyecto especial» a formar parte simplemente de nuestra forma de trabajar, sobre todo gracias al valor inmediato que aportaban una vez que la gente se acostumbró a usarlas.
Un buen indicador era que, cuando a alguien se le acababan las solicitudes Premium en una herramienta de programación, de repente sentía que ya no podía hacer su trabajo con la misma eficacia. Claro, aún no hemos conseguido que todo el mundo las use, pero ahora casi el 95 % de los ingenieros de Bitly utilizan herramientas de programación basadas en IA de forma habitual.
We haven’t achieved universal adoption, but there is now close to 95% utilization of AI coding tools by Bitly engineers on a regular basis.”
– Michael Richman, VP, Engineering at Bitly
Dejamos de considerar las herramientas de programación basadas en IA como algo experimental y empezamos a integrarlas en los flujos de trabajo diarios de ingeniería: planificación, programación, refactorización, introspección, documentación y revisión de código. El objetivo ahora no es «completar la implantación» de las herramientas de programación basadas en IA, sino seguir evolucionando junto con ellas. Ahora lo que hay que hacer es adaptarse constantemente.
¿Y ahora qué?
Optamos por el enfoque de «aprender sobre la marcha» y, en ese sentido, seguimos aprendiendo.
Tenemos que lidiar con cuestiones de costes. Somos un equipo de ingeniería relativamente pequeño, pero pagar por tres herramientas que se solapan bastante no es una buena estrategia a largo plazo. Creemos que pronto vamos a reducir el personal.
Ahora nos vamos a centrar en profundizar en nuestras habilidades y en consolidar lo que hemos aprendido. Eso significa desarrollar programas de formación estructurados para quienes buscan una orientación más práctica, perfeccionar los conjuntos de normas para codificar los estándares y mejorar la forma en que medimos el impacto.
Eso también implica ir más allá en cuanto a la mejora de la productividad:
- ¿Cuál es la mejor forma de gestionar varias sesiones de agentes a la vez?
- ¿Cómo conseguimos equilibrar el código generado por los agentes de IA con la facilidad de revisión?
- ¿Cómo podemos combinar varios agentes para coordinar tareas en paralelo?
- ¿Cuánta autonomía podemos dar a nuestros agentes de programación de IA?
Antes me burlaba de los resultados de las herramientas de programación con IA. Ahora suelo quedarme alucinado (y solo a veces me burlo).
Para bien o para mal, esta es la nueva realidad de la ingeniería de software, y las herramientas no harán más que mejorar a partir de ahora. Para mí, la cuestión no es si adoptar herramientas de programación basadas en IA, sino cómo seguir evolucionando con ellas y sacarles el máximo partido.
