AMPECO no se volvió AI-native de la noche a la mañana. El cambio empezó con una pregunta sencilla pero ambiciosa: ¿y si la IA pudiera hacer algo más que ayudar a los desarrolladores? ¿Y si pudiera escribir código listo para producción mientras los ingenieros se centraban en la arquitectura, la validación y la dirección en lugar de en tareas repetitivas de implementación?
Esa idea pronto se convirtió en un debate interno muy serio. A medida que el ritmo de la innovación aumentaba y las expectativas de velocidad seguían creciendo, quedó claro que el verdadero cuello de botella eran los flujos de desarrollo tradicionales. No el talento ni la ambición, sino el propio motor.
En verano de 2025 ya habíamos reconstruido todo nuestro flujo de desarrollo en torno a agentes de IA, inspirados en parte por la investigación sobre arquitecturas de agentes de larga duración que mantienen el estado y el contexto a lo largo de varias sesiones.
Este cambio nos obligó a replantear desde la base cómo se crea el software. En lugar de elegir entre velocidad y seguridad, nos preguntamos si era posible eliminar ese dilema por completo. La respuesta no estaba en mejores herramientas sueltas, sino en integrar la IA a fondo en el núcleo de cómo AMPECO diseña, construye y hace evolucionar su plataforma.
Para los operadores de puntos de recarga (CPO), esta transformación tiene consecuencias directas. Esto es lo que la mayoría de los CPO no ven: el motor de desarrollo que hay bajo su plataforma es un límite oculto a su velocidad competitiva. Cada vez que ha esperado meses una integración crítica, o ha aplazado una funcionalidad o una oportunidad de mercado porque «no está en la hoja de ruta», ha sentido ese límite.
Simplemente no sabía que tenía solución.
La paradoja velocidad-seguridad
En una infraestructura crítica, la inclinación del sector por la prudencia era racional. Los ciclos de lanzamiento largos, las revisiones manuales exhaustivas y una gestión de cambios conservadora eran la forma más segura de operar cuando el mercado de la recarga de vehículos eléctricos (VE) era joven y había pocas alternativas.
El perfil de riesgo ha cambiado.
El mercado de la recarga de VE madura a gran velocidad. La competencia se intensifica, las expectativas de los clientes aumentan, los requisitos normativos evolucionan más deprisa y los modelos de negocio se diversifican.
Los CPO siguen necesitando lo mismo de siempre: desplegar funcionalidades con rapidez para seguir siendo competitivos, mantener una alta disponibilidad, integrarse con nuevo hardware y nuevos sistemas energéticos, y adaptarse a la evolución del mercado.
Lo que ha cambiado es la presión. La velocidad no puede ir en detrimento de la estabilidad, y la estabilidad no debería frenar la innovación. Los CPO necesitan ambas a la vez.
El efecto iceberg
Al evaluar plataformas, la mayoría de los CPO se fijan en lo visible: funcionalidades, precios y calidad del soporte. Pero lo que se ve es solo la punta del iceberg. Igual de importante es algo menos visible: cómo desarrolla y entrega software realmente su proveedor.
El motor de desarrollo que hay debajo determina todo lo que importa a largo plazo. Determina lo rápido que llegan las nuevas capacidades cuando las necesita. Si la velocidad se paga con estabilidad o si ambas mejoran a la vez. Lo flexible que puede ser su plataforma a medida que evoluciona su negocio.
Esto nos llevó a plantearnos una pregunta de fondo: ¿qué haría falta para eliminar por completo el dilema entre velocidad y seguridad? No solo mejorarlo, sino resolverlo.
Nos dimos cuenta de que el límite no era nuestro talento: tenemos ingenieros excepcionales. Tampoco era nuestro compromiso: nuestro equipo siempre ha trabajado duro. El límite era el propio motor de desarrollo.
Esto reforzó nuestra convicción de que la forma más eficaz de llevar la IA a la plataforma de AMPECO era integrarla en nuestro propio núcleo. Así que hicimos algo radical. Reconstruimos todo nuestro proceso de desarrollo para que fuera AI-native: no asistido por IA, no mejorado con IA, sino AI-native desde la base.
Cómo rehicimos desde cero nuestro motor de desarrollo y nos volvimos AI-native
Conviene aclarar qué entendemos por «AI-native», porque es un término que se usa mucho y a la ligera.
Hoy muchos productos incorporan funciones de IA, como chatbots, motores de recomendación o informes automatizados. Son funciones de IA: visibles para los usuarios, presentes en los materiales de marketing y lo que todo el mundo corre a lanzar.
Ser AI-native es algo completamente distinto. Es una IA integrada en la forma de crear el software, no en lo que el software hace. Sus clientes no la ven, pero cambia por completo todo lo que usted puede ofrecerles.
La diferencia importa. Añadir funciones de IA a un producto construido de la forma tradicional es como poner un motor más potente en un coche con cambio manual: algo mejora, pero el sistema de base sigue limitándole. Rehacer con IA la forma de crear software es como pasar a un sistema de propulsión totalmente distinto. Los límites cambian de raíz.
Cuando propusimos esta transformación, nuestros ingenieros se mostraron muy escépticos, y con razón. Siempre hemos priorizado soluciones estables y predecibles. Y cuando la mayoría de los desarrolladores oyen «programar con IA», piensan en el «vibe coding»: pedirle cosas a una IA hasta que el resultado parece correcto, publicarlo y cruzar los dedos.
Ese enfoque no funciona en una infraestructura crítica.
El vibe coding sirve para prototipos y pruebas de concepto. Pero el software que gestiona infraestructura de recarga necesita un proceso sistemático en el que la calidad se garantice en cada paso, no algo que se espera conseguir al final.
Teníamos que averiguar cuál era ese enfoque. ¿Cómo es, en la práctica, un desarrollo con IA sistemático y listo para producción?
Así que empezamos por los principios básicos.
Cómo creamos el CoOperator Dev Agent
La pregunta clave no era «¿puede la IA escribir código?», sino «¿dónde aportan valor realmente las personas en el desarrollo de software?».
Partimos de un principio sencillo: las personas destacan en la conceptualización y el criterio; la IA, en la ejecución. Entender qué hay que construir, diseñar cómo debe funcionar y validar que funciona correctamente es criterio humano. Convertir esas decisiones en código, ejecutar las pruebas y desplegar los cambios es ejecución.
Codificamos todo nuestro flujo de trabajo en torno a este principio. El resultado es el CoOperator Dev Agent: un sistema de gestión del flujo de trabajo en el que la IA se encarga de la ejecución mientras los ingenieros dirigen la arquitectura y validan la calidad. Si quiere conocer el plano técnico de cómo construimos el Cooperator Dev Agent, consulte el análisis en profundidad de nuestro CTO, Alexander Alexiev, en Cómo construimos un sistema de ingeniería AI-native.
Con más de 20.000 pruebas unitarias automatizadas, cada cambio se valida antes de llegar a producción. No se trata de esperar que la IA haya acertado, sino de un aseguramiento de la calidad sistemático.
Cambio de mentalidad
Crear el CoOperator Dev Agent fue la parte fácil. La transformación más difícil fue el cambio de mentalidad que debía producirse en todo nuestro departamento de ingeniería.
Pedíamos a los ingenieros que dejaran de hacer lo que habían tardado años en dominar. Que dejaran de escribir código línea a línea. Que empezaran, en cambio, a diseñar la arquitectura de los sistemas y a dirigir la ejecución de la IA.
El cambio no afecta solo a lo que hacen los ingenieros, sino a su nivel de abstracción. Antes traducían requisitos humanos a código. Ahora traducen requisitos a instrucciones para la IA y después validan los resultados. Es un nivel de pensamiento más alto, que exige el mismo conocimiento técnico profundo, pero aplicado de otra manera.
Los ingenieros han pasado de ser «albañiles» que escriben sintaxis a «arquitectos» que orquestan la lógica. Ya no escriben código línea a línea. Su nivel de abstracción ha vuelto al lenguaje humano, pero a un lenguaje humano que leerá un agente de IA.
Nuestro antiguo cuello de botella era tener demasiadas cosas que construir y pocos ingenieros. ¿El nuevo? Contar con requisitos verificados y bien justificados. Cuando el código deja de ser el límite, saber exactamente qué construir pasa a serlo.
Por eso estamos acercando a todos los ingenieros a la visión de producto. En lugar de que un puñado de product managers alimente el trabajo de decenas de ingenieros, avanzamos hacia un modelo en el que los ingenieros exploran, investigan, expresan la intención y toman las decisiones que dan forma a un gran producto. CoOperator se encarga de la implementación.
Como resume Alexander: «Escribir código a mano se ha quedado obsoleto. Ahora la experiencia se dedica a mejorar la automatización, no a tareas de programación repetitivas». Detalla toda la arquitectura técnica y el flujo de trabajo en Cómo construimos un sistema de ingeniería AI-native.
Resultados: velocidad y calidad a la vez
El impacto ha sido enorme.
Las historias de usuario que antes llevaban dos días ahora se completan en horas. Hemos pasado de sprints semanales a lanzamientos diarios. Entregamos el doble de funcionalidades con la mitad de errores.
Esto último sorprende. Pero los datos son claros: nuestra tasa de errores ha bajado mes a mes desde que empezamos. ¿Por qué? Porque la IA no se cansa, no toma atajos y no se salta pruebas. Y esto no ha hecho más que empezar.
Infraestructura sin demoras: qué supone para los CPO
En el desarrollo de software siempre hay demoras. Entre detectar una necesidad y planificarla. Entre planificarla y empezar a desarrollarla. Entre el desarrollo y las pruebas. Entre las pruebas y el despliegue.
Estas demoras se acumulan. Una funcionalidad que se construye en días puede tardar meses en entregarse.
Cuando el proveedor de su plataforma de recarga de VE se vuelve AI-native, estas demoras se desploman. No hasta cero, porque siempre hay algún límite, pero sí hasta un punto radicalmente distinto.
Es una infraestructura sin demoras, en la que sus necesidades se convierten en capacidades de la plataforma sin los retrasos tradicionales que limitan su negocio.
Esto es lo que supone en la práctica:
1. Incidencias resueltas antes y mejor
Nuestra velocidad de desarrollo ha cambiado de raíz. Las historias de usuario que antes llevaban dos días ahora se completan en horas y, con lanzamientos diarios, las mejoras llegan a producción de forma continua en lugar de esperar a las ventanas semanales
Igual de importante: un 50 % menos de errores por historia de usuario significa, para empezar, menos incidencias que alteren sus operaciones. Y cuando surgen, se resuelven de 3 a 4 veces más rápido que antes.
Esta velocidad no va en detrimento de la calidad, ya que nuestras pruebas sistemáticas nos permiten publicar correcciones de forma continua sin aumentar el riesgo.
2. Funcionalidades e integraciones más rápidas
Una mayor velocidad de desarrollo se traduce directamente en un menor tiempo hasta obtener valor. Tanto si necesita integrar un nuevo procesador de pagos como una funcionalidad de informes a medida o una actualización por cumplimiento normativo, los plazos se han reducido de forma drástica.
Con ciclos de desarrollo hasta 4 veces más rápidos, las integraciones y los lanzamientos de funcionalidades que antes llevaban trimestres ahora pueden entregarse en semanas. Los plazos reales siguen dependiendo de la complejidad y las prioridades, pero el punto de partida ha cambiado de raíz: responder a las necesidades del mercado y del negocio ahora se mide en semanas, no en trimestres.
3. Fiabilidad de plataforma que crece con el tiempo
Menos incidentes en producción que alteren las operaciones, menos tiempo dedicado a escalados y un comportamiento de la plataforma más predecible. La mejora de la estabilidad procede del mismo sistema que genera la velocidad: controles de calidad automatizados y pruebas exhaustivas integradas en cada cambio.
Pero esto es lo que lo diferencia del desarrollo tradicional: el CoOperator Dev Agent aprende y gana eficiencia en cada ciclo, y esa ventaja se acumula. Cuando se detecta un problema, no nos limitamos a corregir ese error concreto: mejoramos las instrucciones y el contexto del sistema de IA, lo que eleva el nivel de calidad de todo el desarrollo futuro.
4. La flexibilidad estratégica, una realidad
Hemos construido una plataforma que se adapta a la evolución de su modelo de negocio, y no al revés. Como el límite del desarrollo de la plataforma pasa de «a qué velocidad podemos construir» a «qué deberíamos construir», podemos responder a las nuevas necesidades del negocio, ya sean nuevos modelos de precios, nuevos servicios o nuevos segmentos de mercado, sin los cuellos de botella del desarrollo tradicional. Así, nuestra plataforma no dicta su estrategia: la hace posible.
A medida que hemos ganado velocidad de desarrollo, hemos ido trasladando los límites hacia delante. Ahora estamos automatizando las traducciones, la documentación y los procesos de lanzamiento, y agilizando todo lo que genera demoras entre «funcionalidad terminada» y «valor entregado al cliente».
Por qué importa más allá de AMPECO
El motor de desarrollo que hay bajo su plataforma determina todo lo que se acumula con el tiempo: lo rápido que llegan las nuevas capacidades, si se ve obligado a elegir entre velocidad y estabilidad, y lo adaptable que es su infraestructura a medida que evoluciona su negocio.
Lo que hay bajo el agua importa más que la punta del iceberg.
La ingeniería AI-native no es fácil. Exige una transformación profunda: rediseñar los procesos de desarrollo, invertir masivamente en pruebas automatizadas, un cambio cultural en los equipos de ingeniería y la mejora continua de los propios sistemas de IA.
Pero eleva el listón de lo que los CPO deberían esperar de cualquier proveedor de plataforma. Ser «AI-native» debería convertirse en el nuevo estándar. La falsa elección entre velocidad y seguridad se ha acabado. El desarrollo AI-native, en el que una infraestructura sin demoras ofrece ambas cosas, es posible hoy, no en un futuro lejano.
