Todo responsable de ingeniería que desarrolla infraestructura crítica ha trabajado con una premisa básica: se puede tener velocidad o fiabilidad, pero conseguir ambas a la vez se consideraba imposible.
No es un problema de procesos ni de equipo. Durante años, el sector lo aceptó como una limitación inherente a la forma de desarrollar software. La fiabilidad exige ciclos de lanzamiento lentos y metódicos. Las pruebas exhaustivas llevan tiempo. Las revisiones de código crean cuellos de botella. Cada capa de seguridad añade semanas a los plazos de entrega.
En las plataformas de recarga de vehículos eléctricos (VE), hay más en juego que en el software habitual. No puede permitirse caídas del servicio, porque cada minuto sin disponibilidad supone pérdida de ingresos. Pero tampoco puede permitirse una entrega lenta de funcionalidades, ya que los operadores de puntos de recarga (CPO) necesitan adaptarse a medida que evoluciona el mercado.
Nos negamos a aceptar que la lentitud sea el precio de la seguridad.
Vimos que la IA había alcanzado un grado de madurez que por fin podía resolver este dilema. La cuestión no era si usar la IA, sino cómo diseñar un sistema de ingeniería en el que la velocidad y la calidad se refuercen mutuamente en lugar de competir, un cambio que describimos en Cómo AMPECO se convirtió en una empresa AI-native.
Así que reconstruimos todo el proceso de desarrollo de software de AMPECO en torno a agentes de IA, no para elegir un lado del dilema, sino para romperlo por completo. Automatizamos el ciclo de desarrollo completo: planificación, programación, pruebas y despliegue. La IA se encarga de la ejecución y los ingenieros dirigen la arquitectura y validan la calidad. El resultado: historias de 2 días reducidas a horas, la tasa de errores reducida a la mitad y el paso de sprints semanales a lanzamientos diarios.
Le contamos cómo lo hicimos.
Así creamos el CoOperator Dev Agent
Llevábamos casi dos años experimentando con herramientas de programación con IA: GitHub Copilot para el autocompletado, el asistente de revisión de código CodeRabbit y el editor con IA Windsurf. Todas eran prometedoras, pero dieron resultados desiguales. Cada herramienta aportaba mejoras graduales, pero ninguna cambiaba las reglas del juego.
El gran avance llegó con Claude Code de Anthropic. Las herramientas anteriores exigían supervisión constante: los desarrolladores tenían que leer los resultados intermedios y escribir «continue» para que el proceso siguiera avanzando. Claude Code cambió esta dinámica: podía trabajar en una tarea sin interrupciones y, cuando indicaba que había terminado, el trabajo estaba realmente acabado. Además, y esto era clave, se podía programar mediante un SDK, lo que nos permitió integrarlo como un paso fiable en nuestros flujos de trabajo automatizados.
Tomamos nuestro proceso existente, que ya funcionaba bien, y lo dividimos en pasos pequeños e individuales. Este enfoque detallado era esencial para no superar las limitaciones de contexto de los modelos de IA actuales.
Para cada paso redactamos instrucciones concretas, las que daríamos a un desarrollador humano, que definían exactamente cómo completar la tarea y qué significa «terminado». Guardamos estas instrucciones como prompts ejecutables.
Después, organizamos estos pasos en un flujo de trabajo que reproduce exactamente el proceso que sigue nuestro equipo de ingeniería humano. Descubrimos que no había ningún paso fundamental que la IA no pudiera hacer, desde escribir código hasta el control de calidad, siempre que el alcance se gestionara correctamente.
El resultado es lo que llamamos CoOperator Dev Agent (CODA). Funciona como un gestor de flujos de trabajo que orquesta la ejecución de estas instrucciones y lleva el proceso de principio a fin. Una fase de arquitectura crea un plan detallado, una fase de desarrollo escribe las pruebas e implementa las funcionalidades, y una fase de revisión de código realiza una revisión interna por pares que valida rigurosamente el trabajo frente a los estándares de programación, los patrones de arquitectura y los requisitos de la historia. Cuando se detectan problemas, el flujo vuelve atrás para corregirlos y se repite hasta que el trabajo está terminado.
El motor de IA: eliminar sistemáticamente las interrupciones humanas
Nos dimos cuenta de que, en un sistema AI-native, el principal límite a la velocidad no es el tiempo de generación de la IA, sino el tiempo de ciclo humano. Esperar a que una persona revise un plan o apruebe un paso crea «tiempos muertos» que destruyen la velocidad.
Nuestro enfoque no consiste en gestionar «bucles» de interacción entre personas e IA. Consiste en establecer puntos de control y después eliminarlos sistemáticamente a medida que ganamos confianza en la autonomía del agente.
De la supervisión a la autonomía
Al principio, nuestro proceso estaba muy vigilado. Un Product Manager aprobaba la historia y, a continuación, los agentes de IA (Architect y QA) generaban un plan técnico. Un desarrollador humano tenía que detenerse, revisar y aprobar ese plan antes de que pudiera empezar la implementación. Solo entonces los agentes de ejecución (Developer, Code-review y AcceptanceTest) llevaban la tarea hasta el final, seguidos de otra revisión de código humana más.
A medida que los agentes demostraban su capacidad, vimos que el punto de control de «revisión del plan» era un cuello de botella. La IA era capaz de planificar correctamente sin que nadie la llevara de la mano. Así que eliminamos esa interrupción humana.
Cómo trabajamos hoy
Hoy, en cuanto el Product Owner y el ingeniero marcan una historia como «Listo para desarrollo», los agentes toman el control por completo. Se encargan de forma autónoma de la planificación de la arquitectura, la planificación de las pruebas, la implementación y la autocorrección. El sistema itera internamente (escribe código, ejecuta pruebas, corrige errores) hasta alcanzar un estado «listo para producción».
El desarrollador humano solo vuelve a intervenir al final, para una revisión definitiva. En esta fase puede aprobar el trabajo o dar su opinión. Si el agente se atasca o necesita corregir el rumbo, el desarrollador puede actualizar manualmente las instrucciones del agente o el contexto del proyecto y reiniciar todo el proceso para asegurarse de que el cambio resuelve el problema.
Hacia la intervención cero
El objetivo es seguir eliminando estos puntos de control humanos. Esperamos que en los próximos meses alcancemos un nivel de confianza en el que ya no haga falta una revisión de código humana para cada tarea. Al eliminar estas interrupciones, permitimos que la IA trabaje a su máxima velocidad teórica y convierta días de espera en minutos de ejecución.
Red de seguridad: 25.000+ pruebas
Para alcanzar este grado de automatización con IA, primero hay que tener las redes de seguridad en su sitio. Pero no son redes de seguridad nuevas que inventáramos para la IA.
Nuestro sistema se apoya por completo en la disciplina de las pruebas unitarias y funcionales obligatorias, la integración continua y la gobernanza de seguridad automatizada, prácticas que dominamos hace años para que nuestros equipos humanos avanzaran rápido. Simplemente descubrimos que estas mismas prácticas ayudan a nuestros agentes de IA tanto como a nuestros ingenieros.
En nuestro caso, esa base es un enorme conjunto de más de 25.000 pruebas automatizadas. Un agente no puede dar una tarea por «completada» hasta que genera las pruebas que demuestran que el código funciona. Esto proporciona a la IA una respuesta inmediata y programática. No necesita «adivinar» si la lógica es correcta: el conjunto de pruebas se lo dice al instante. Si una prueba falla, el agente se corrige y vuelve a intentarlo hasta que todo está en verde.
Esta densidad de pruebas, generadas a una velocidad que ninguna persona podría igualar, es lo que nos permite desplegar a diario sin caos. Detecta las regresiones al instante y garantiza que las nuevas funcionalidades no rompan las existentes. Sin este marco riguroso, un agente de IA simplemente produciría código con errores más rápido de lo que las personas podrían corregirlo.
Aunque las pruebas son la principal salvaguarda, las reforzamos con otras herramientas automatizadas de análisis estático de código. Igual que estas herramientas impedían a las personas fusionar código desordenado o inseguro, ahora bloquean a los agentes de IA. Si la IA genera código que funciona correctamente pero incumple los estándares de arquitectura, estas herramientas detienen el proceso.
En definitiva, no construimos la IA sobre promesas vacías, sino sobre una disciplina de ingeniería consolidada.
Los controles humanos se mantienen
No hemos eliminado a las personas del proceso: hemos elevado su papel al de «responsables» de sus compañeros de IA. Hay dos puntos de control humanos esenciales que enmarcan el flujo de trabajo autónomo:
1. La sesión de alineación (antes del trabajo) Antes de escribir una sola línea de código, el Product Owner y el ingeniero responsable se reúnen (en remoto) para iterar sobre la historia. El objetivo no es dictar detalles técnicos de implementación, sino ponerse de acuerdo en el «qué» y el «porqué». Afinan los requisitos hasta que ambas partes quedan satisfechas. Solo cuando el ingeniero marca explícitamente la historia como «Listo para desarrollo», el agente toma el relevo.
2. La revisión de responsable (después del trabajo) Cuando el agente ha terminado la planificación, la programación y las pruebas, presenta el trabajo para su revisión antes de producción. El ingeniero valida el resultado igual que un buen responsable revisaría el trabajo de alguien de su equipo:
- Inspecciona el código final y la funcionalidad.
- Revisa la prueba del trabajo: los registros de planificación, los resultados de las pruebas y los caminos lógicos que siguió el agente.
- Da su opinión mediante la revisión de código.
Si el ingeniero detecta un problema o un enfoque mejor, deja sus comentarios. El agente los utiliza para corregir el código en cuestión y, lo que es más importante, genera una historia de automejora para actualizar sus propias instrucciones, de modo que no haga falta el mismo comentario la próxima vez.
Esta responsabilidad concentrada permite ganar velocidad sin perder calidad. La responsabilidad no se diluye entre varios equipos: recae en un único ingeniero que valida el trabajo en su conjunto.
Adiós al proceso antiguo
Nuestro CEO, Orlin Radev, lo explica sin rodeos: «No nos limitamos a añadir herramientas de IA en los márgenes. Destruimos y reconstruimos nuestro proceso de desarrollo con la IA en el centro».
Lea la visión completa de Orlin sobre lo que esto significa para los CPO en Cómo AMPECO se convirtió en una empresa AI-native.
Cancelamos las sesiones de refinamiento tradicionales, en las que un equipo de ingeniería y el Product Manager repasaban todas las historias de una iteración. En su lugar, celebramos sesiones de alineación concretas en las que las personas (un ingeniero y un Product Owner) definen la intención y la IA se ocupa del análisis técnico. Suprimimos las demos de iteración porque, con lanzamientos diarios, las presentaciones quincenales quedaron obsoletas. Pasamos de sprints semanales a lanzamientos diarios continuos.
Y los resultados demuestran que valió la pena: una velocidad 4 veces mayor con un 50 % menos de errores por historia. No sacrificamos la calidad por la velocidad, sino que construimos un sistema en el que ambas mejoran a la vez. Lo logramos aplicando MÁS controles de calidad, no menos. La cobertura de pruebas aumentó mientras la entrega se aceleraba.
El cambio estratégico: la velocidad como ventaja competitiva
Para un CTO, el dilema entre velocidad y fiabilidad suele ser el mayor lastre de la organización. Cuando los ciclos de desarrollo son lentos, la deuda técnica se acumula porque los equipos no pueden permitirse refactorizar y cumplir a la vez los plazos de entrega. Cuando la fiabilidad es baja, el «impuesto de mantenimiento» (gestionar incidencias en producción y errores) se come la hoja de ruta.
Al pasar a un sistema AI-native, hemos llevado a la organización de una postura defensiva a una ofensiva.
Cuando la tasa de errores baja un 50 % gracias a los controles automatizados, el equipo de ingeniería deja de ser un centro de costes dedicado a corregir fallos y se convierte en una fábrica de innovación. Unos ciclos de desarrollo 4 veces más rápidos no solo significan «más funcionalidades»: significan que el coste de experimentar se ha desplomado. Ahora podemos integrar en horas actualizaciones normativas complejas o requisitos de informes a medida, y responder a presiones del mercado que habrían paralizado durante semanas a un equipo tradicional.
Un motor que mejora solo
Este sistema genera una ventaja acumulativa que los procesos tradicionales no pueden igualar. En una organización de ingeniería convencional, el conocimiento queda aislado. Cuando un desarrollador sénior aprende una lección, puede que se quede en su cabeza o, en el mejor de los casos, acabe en una wiki.
En un sistema AI-native, cada lección queda codificada. Cada vez que un agente genera una historia de automejora a partir de los comentarios de una persona, ese conocimiento se incorpora de forma permanente a la infraestructura. La calidad de base de todo el departamento sube con cada tarea.
Como dice Orlin: «Si hubiéramos empezado creando funciones de IA para los clientes, habríamos resuelto el problema de hoy. Al reconstruir el núcleo, hemos resuelto el problema de mañana».
De dentro hacia fuera
No creamos agentes de IA para seguir una moda. Los creamos porque nuestro propio proceso de ingeniería era el cuello de botella de nuestra misión: escalar la infraestructura de recarga de VE.
Como nuestros agentes se han puesto a prueba con nuestro propio código de producción crítico, tenemos una hoja de ruta clara para llevar las capacidades de IA a otras áreas: éxito del cliente, operaciones y automatización de producto. No serán funcionalidades especulativas, sino extensiones de una arquitectura que ya impulsa nuestro núcleo.
Hace seis meses nos propusimos demostrar que la velocidad y la fiabilidad podían reforzarse mutuamente. Los datos demuestran que es posible. La brecha entre la ingeniería AI-native y el desarrollo tradicional no ha hecho más que empezar a abrirse, pero definirá quién liderará la próxima década del software.
