Escribir código más rápido solo significa entregar antes si el proceso que viene después es capaz de seguir ese ritmo.
En Codemotion hablamos a menudo con desarrolladores sobre herramientas de IA, pero hay una pregunta a la que deberíamos prestar más atención: ¿qué pasa después de escribir el código? Datadog tiene una propuesta bastante concreta para responder a esta cuestión, basada en la experiencia de equipos reales. Te contamos en qué consiste y cómo encaja su solución.
Hay una idea que se repite mucho cuando hablamos de programar con IA: si los desarrolladores escriben código más rápido, el software también llegará antes a producción. Parece lógico, pero no es del todo cierto.
Escribir código es solo el primer paso de un proceso bastante más largo. Después vienen la pull request, la compilación (build), las pruebas, la revisión, la integración y el despliegue. Si aceleras muchísimo el primer paso, no significa que todo el proceso vaya a ir más rápido. Lo que haces es acumular más trabajo justo en el siguiente punto donde el proceso se atasca. Y, en muchos equipos, ese cuello de botella es CI (integración continua).
Más código significa más trabajo para todos
Los asistentes y agentes de IA no solo ayudan a escribir código. También hacen que probar nuevas ideas sea mucho más fácil y barato. Algo que antes podía llevarte toda una tarde para tener un primer prototipo, ahora puede resolverse con un prompt y un café.
Como resultado, los desarrolladores crean más pull requests, suben más commits y prueban cambios con mucha más frecuencia.
Y cada uno de esos cambios pone en marcha una pipeline. Más pull requests significan más compilaciones (builds); más builds, más ejecuciones de pruebas; y más pruebas, más consumo de recursos, más tiempos de espera y más posibilidades de que algo falle sin que nadie sepa muy bien por qué.
El problema es que los fallos de CI que antes podías tolerar no se mantienen igual cuando aumenta el volumen de trabajo: se multiplican. Una pipeline que resultaba simplemente molesta con diez pull requests al día puede convertirse en un problema diario cuando llegas a cincuenta.
Y una prueba que fallaba de vez en cuando, por ejemplo, una de cada cien ejecuciones, puede pasar de ser una pequeña molestia a convertirse en algo casi habitual. Siempre hay alguien con una compilación fallida sin motivo aparente.
La solución que parece más fácil: añadir más recursos
Cuando empiezan a acumularse los trabajos en cola, la primera reacción suele ser aumentar la capacidad: añadir más runners, contratar más recursos de computación y permitir que se ejecuten más tareas en paralelo.
Hasta cierto punto, funciona. Pero es como añadir carriles a una autopista cuando el verdadero problema es un accidente que está bloqueando uno de ellos.
Tener más capacidad permite procesar más trabajo, pero no soluciona los problemas de fondo: una tarea demasiado lenta que bloquea el resto del proceso, una batería de pruebas que vuelve a ejecutarse entera cada vez que cambias un solo archivo o una prueba inestable que obliga al desarrollador a pulsar otra vez el botón de «reintentar».
Al final, pagas más por ejecutar las mismas ineficiencias en paralelo.
La factura crece casi al mismo ritmo que el volumen de trabajo, pero los desarrolladores siguen esperando. Vamos, que acabas pagando más para seguir teniendo el mismo problema.
Cuatro ideas para escalar sin depender de más máquinas
Si añadir más máquinas no es suficiente, ¿qué podemos hacer? Si nos fijamos en cómo trabajan los equipos que consiguen mantener sus procesos de CI bajo control, encontramos cuatro prácticas. Ninguna es especialmente complicada. Lo difícil es aplicarlas de forma constante, y para eso hace falta tener visibilidad de lo que está pasando.
1. Identificar dónde está realmente el problema.
Decimos que las pipelines son lentas, pero ese tiempo de espera no suele repartirse por igual. Lo habitual es que unos pocos trabajos o fases concentren la mayor parte de las demoras.
Hasta que no sabes dónde se está yendo realmente el tiempo, optimizas un poco a ciegas. Y normalmente acabas intentando solucionar lo que más te molestó la semana pasada, no necesariamente lo que más impacto tiene.
2. Dejar de tratar las pruebas inestables como una simple molestia.
Una prueba que falla de forma aleatoria no solo hace perder tiempo. También provoca que los desarrolladores dejen de confiar en los resultados.
Cuando te acostumbras a repetir una prueba esperando que esta vez funcione, empiezas a asumir que un error no significa necesariamente que algo esté roto. Y cuando aparece un problema real, puede acabar recibiendo la misma atención que un falso positivo.
Por eso, estas pruebas deben evitarse siempre que sea posible y, cuando no lo sea, hay que tenerlas controladas: aislarlas, asignar a alguien responsable de ellas y hacer seguimiento hasta que se solucionen.
3. Ejecutar solo las pruebas que tienen sentido para cada cambio.
La mayoría de los cambios no afectan a todo el código. Sin embargo, muchas pipelines ejecutan toda la batería de pruebas cada vez que se modifica algo, simplemente porque es la opción más segura.
La selección inteligente de pruebas propone hacer justo lo contrario: utilizar la información sobre los cambios realizados y el historial de las pruebas para ejecutar únicamente aquellas que podrían verse afectadas.
Menos trabajo, el mismo nivel de confianza y resultados más rápidos.
4. Repartir mejor el trabajo que queda.
Una vez eliminado el trabajo innecesario, toca distribuir el resto de forma equilibrada.
Ejecutar pruebas en paralelo solo ayuda si los distintos grupos de tareas (shards) terminan más o menos al mismo tiempo. Si uno de ellos acumula demasiado trabajo, todos tendrán que esperar a que termine el último, mientras el resto de máquinas se quedan prácticamente sin hacer nada.
Fíjate en que las cuatro ideas tienen algo en común: no hablan de añadir capacidad, sino de gestionar mejor el trabajo. Hacer menos tareas innecesarias, conseguir que las pruebas sean más fiables y repartir mejor lo que queda.
Una vez hecho eso, ya tiene sentido invertir en más capacidad si sigue haciendo falta.
Un ejemplo real: Betterment
El caso de Betterment es un buen ejemplo porque parte de una situación bastante habitual.
A medida que crecía su base de código, las pruebas empezaron a fallar de forma aleatoria, las pipelines de CI llegaron a tardar casi 40 minutos y menos de la mitad de las compilaciones terminaban correctamente.
Pero el problema más importante iba más allá de las cifras: los desarrolladores habían dejado de confiar en el proceso. Cuando la mayoría de las compilaciones fallan por motivos que no tienen nada que ver con tus cambios, acabas dejando de prestar atención a los errores.
La solución no pasó por rehacerlo todo desde cero. El equipo utilizó CI Visibility y Test Optimization de Datadog para identificar qué pruebas estaban dando problemas, asignar responsables y utilizar Workflow Automation para detectar posibles regresiones sin depender de que alguien se diera cuenta manualmente.
Los resultados hablan por sí solos:
- El porcentaje de compilaciones correctas superó el 95 %.
- El tiempo de compilación bajó de los 10 minutos.
- Los costes de computación de CI se redujeron en más de un 50 %.
Este último dato es especialmente interesante. Conseguir que algo sea más rápido, más fiable y, además, más barato no suele ser lo habitual.
En este caso, el ahorro llegó al eliminar trabajo innecesario: ejecuciones repetidas, tareas redundantes y compilaciones fallidas. No se trataba de hacer lo mismo más rápido, sino de dejar de perder tiempo y recursos.
Y, como consecuencia, los desarrolladores pudieron dedicar menos tiempo a repetir compilaciones y más a desarrollar las funcionalidades para las que fueron contratados.
Lo que hay detrás de estos resultados
Es fácil leer un caso como este y pensar que todo se reduce a utilizar una herramienta concreta. Pero hay algo más interesante: el ciclo de feedback.
En esencia, CI es un sistema de retroalimentación. Haces un cambio y la pipeline te dice si es seguro o si hay algún problema.
El valor de esa respuesta depende de dos cosas: que llegue rápido y que sea fiable.
Si tarda demasiado, interrumpe el ritmo de trabajo. Si no puedes confiar en ella, dejas de prestarle atención. Y el desarrollo asistido por IA pone a prueba ambas cosas porque multiplica el número de veces que necesitas esa respuesta.
Por eso, tener visibilidad de lo que ocurre es más importante de lo que parece.
Los datos de las pipelines (qué tareas tardan más, dónde se acumulan las esperas) y los datos de las pruebas (cuáles fallan de forma aleatoria, cuáles suelen fallar juntas y quién es responsable de cada una) suelen estar repartidos en distintas herramientas.
Unificarlos permite responder a preguntas que realmente ayudan a tomar decisiones:
- ¿Esta tarea tarda demasiado por el propio trabajo, por una prueba o porque está esperando en cola?
- ¿Este fallo es nuevo o llevamos un mes ignorando el mismo problema?
Precisamente, esa conexión entre los datos de las pipelines y los resultados de las pruebas es uno de los puntos en los que se centra CI/CD Optimization de Datadog. Y ahí es donde entra su propuesta.
¿Qué aporta Datadog?
La solución CI/CD Optimization de Datadog sigue precisamente este enfoque: reunir los datos de las pipelines y las pruebas en un mismo sitio para que esas cuatro prácticas se basen en información real y no en intuiciones.
Estas son sus principales funcionalidades:
- Detectar los cuellos de botella: CI Visibility ofrece información sobre las pipelines y cada uno de sus trabajos, lo que permite identificar dónde se concentra el tiempo de espera y dónde se producen los fallos.
- Controlar las pruebas inestables: Test Optimization permite hacer seguimiento de las pruebas que fallan de forma aleatoria, identificarlas, aislarlas y asignar responsables para solucionarlas. Es una de las funcionalidades que utilizó Betterment.
- Ejecutar menos pruebas: la selección inteligente permite ejecutar solo las pruebas relacionadas con los cambios realizados, en lugar de lanzar toda la batería cada vez.
- Repartir mejor el trabajo: la ejecución de pruebas en paralelo distribuye las tareas restantes para que los distintos grupos terminen en tiempos similares.
- Automatizar el seguimiento: Workflow Automation permite automatizar la monitorización y detectar posibles regresiones en cuanto aparecen, sin depender de que alguien esté pendiente.
Lo interesante es cómo se combinan todas estas funcionalidades. Cada una de estas prácticas existe por separado y muchos equipos desarrollan sus propias soluciones con scripts y hojas de cálculo.
El problema de hacerlo así es que alguien tiene que conectar todos esos datos y mantener el sistema funcionando. Tener las pipelines, las pruebas y los responsables en un mismo lugar facilita que estas prácticas se mantengan en el tiempo, en lugar de quedarse en una optimización puntual.
Eso sí, hay algo que conviene tener claro: una herramienta puede ayudarte a detectar un problema, pero alguien tiene que solucionarlo. En el caso de Betterment, los resultados llegaron tanto por tener información clara como por asignar responsables a las pruebas que daban problemas.
Si quieres ver cómo funciona este enfoque y preguntar directamente al equipo, Datadog estará en Codemotion Milan 2026.
¿Con qué nos quedamos?
Si tu equipo ya está utilizando herramientas de IA para programar, o está pensando en incorporarlas, hay algunas preguntas que merece la pena hacerse antes de que empiecen a acumularse las pull requests:
- ¿Sabes qué tres tareas o fases de tu pipeline concentran la mayor parte del tiempo de espera?
- ¿Podrías identificar tus diez pruebas más inestables y quién es responsable de cada una?
- Si alguien modifica un solo archivo, ¿tu pipeline necesita ejecutar todas las pruebas?
- Cuando ejecutas tareas en paralelo, ¿todos los grupos terminan más o menos al mismo tiempo?
Si no tienes claras las respuestas, añadir más runners no va a solucionar el problema. Solo hará que sea más caro.
La IA está cambiando la velocidad a la que escribimos código. Pero que eso se traduzca en entregas más rápidas depende de todo lo que viene después.
Los equipos que más partido saquen a estas herramientas no serán necesariamente los que generen más código, sino los que consigan tener un proceso de feedback lo suficientemente rápido y fiable como para seguirles el ritmo.
