¿Por qué la localización se está moviendo hacia el inicio del ciclo de desarrollo?

La localización se está moviendo hacia el inicio del ciclo porque la premisa central del pipeline antiguo se rompió: que el código cambia lo bastante despacio como para exportar un catálogo de cadenas estable, traducirlo en otro sitio e importar los resultados antes de la siguiente versión. Los agentes de codificación con IA acabaron con esa premisa. globalize.now es infraestructura de localización impulsada por IA construida para la nueva posición: localización que se ejecuta dentro del ciclo de desarrollo y se entrega como pull request. Este ensayo trata de por qué lo que cambió es la posición, no la calidad de la traducción.

¿Qué significa mover la localización hacia el inicio del ciclo?

Significa que la unidad de trabajo de localización deja de ser un catálogo de cadenas y pasa a ser un commit. En el modelo antiguo, la localización empieza cuando el código ya está terminado. En el modelo adelantado, ocurre donde vive el código, en el momento en que el código cambia, y su resultado es código: un PR localizado que revisas con diff, evalúas y fusionas.

Los dos pipelines se ven así.

Traditional:   build → internationalize → export → translate → review → import → ship

Upstream:      code → push → localized PR → merge → ship

El primer pipeline tiene siete etapas y sale del repositorio dos veces. El segundo tiene cinco, y ninguna sale del repo. Esa diferencia estructural, no ninguna función concreta, es de lo que trata este ensayo.

¿Cómo funciona el pipeline de localización tradicional?

Funciona como un ida y vuelta, y cada flecha en él es una cola. Construyes la funcionalidad. La internacionalizas, extrayendo cadenas a claves, suponiendo que tu equipo o tu agente de IA produjeron código estructurado desde el principio. Exportas el catálogo a una plataforma de traducción. Traductores o traducción automática lo procesan. Alguien revisa. Importas los resultados, resuelves los conflictos que se acumularon mientras el catálogo estaba fuera, y despliegas.

Cada traspaso existe porque el trabajo ocurre en un lugar distinto, a cargo de personas distintas, con un reloj distinto. Era un diseño razonable cuando los lanzamientos eran trimestrales y las cadenas cambiaban por lotes. La dependencia oculta del pipeline es la estabilidad: el catálogo tiene que quedarse quieto el tiempo suficiente para completar el ida y vuelta.

Ya no se queda quieto. En el informe DORA 2025 sobre el estado del desarrollo de software asistido por IA, el 90 % de los profesionales de software declaró usar herramientas de IA en el trabajo, y el estudio de impacto del cuarto trimestre de 2025 de DX midió que el código escrito por IA representaba el 22 % del código fusionado en la empresa mediana estudiada. Código que antes cambiaba semanalmente ahora cambia entre la comida y el standup.

¿Cómo es la localización dentro del ciclo de desarrollo?

Como cualquier otra comprobación automatizada que se ejecuta en cada push. Conviertes el codebase una sola vez: cadenas extraídas, claves generadas, archivos de traducción creados, conexión al runtime lista. A partir de ahí, la sincronización se ejecuta en cada push. Cuando un commit introduce cadenas nuevas, las traducciones vuelven como un pull request sobre tu rama, en tu repositorio, estructurado de la misma forma que el resto de la app.

Esto no es un rendimiento hipotético. En una ejecución que registramos en agosto de 2026 sobre un repo de demostración, un commit enviado con push volvió como un PR localizado que cubría 30 unidades de traducción en alemán, francés y español en 49 segundos. En menos de un minuto, del commit al PR listo para revisar, sin ninguna persona en el bucle hasta la revisión. Compáralo con cualquier pipeline que incluya la palabra «exportar».

La conversión inicial, para que quede claro, no es instantánea. En apps reales tarda unos 30 minutos, porque reestructura código: extrae cadenas, genera claves, conecta un runtime. Esa es la puerta de entrada. El bucle que se repite en cada push a partir de ahí es el producto.

La propiedad importante de ese bucle no es la velocidad. Es que nada salió del repo. No hay ningún catálogo esperando en una plataforma externa que se va desviando poco a poco de main. La ejecución en monorepo que publicamos antes mostró la conversión inicial a gran escala; el bucle es lo que mantiene vivo el resultado después. Fusionar o cerrar, los mismos dos verbos que rigen cualquier otro cambio. Si ya trabajas de esta forma, la documentación para desarrolladores muestra la configuración.

¿Por qué los agentes de codificación con IA obligan a este cambio?

Porque desplazaron el cuello de botella. La limitación en localización solía ser la capacidad de traducción: la rapidez con la que un proveedor o un motor podía procesar un catálogo bien estructurado. Los agentes generan muy por encima de esa limitación y crearon una nueva, más arriba en el proceso. El recurso escaso ahora es la sensatez arquitectónica después de la generación: mantener las claves consistentes, los archivos de traducción completos y la estructura intacta mientras un agente añade interfaz al codebase a diario.

Un agente al que se le pide una página de pago produce una página de pago funcional con las cadenas codificadas directamente en el JSX. Escribimos sobre la anatomía de esto en el código generado por IA rompió la localización: un proyecto React analizado tenía 1284 cadenas de interfaz repartidas en 312 archivos sin ninguna estructura de i18n. El catálogo que el pipeline tradicional quiere exportar no existe en ese codebase. Y el codebase volverá a verse distinto mañana, porque el agente sigue desplegando.

Un pipeline posterior se enfrenta a esa realidad permanentemente por detrás. Lo que exportó ya está desactualizado para cuando llega el momento de importar. La única posición desde la que la localización puede seguirle el ritmo al código generado es dentro del propio bucle que lo genera, y eso vale igual si el código viene de Cursor, Claude Code o Lovable.

¿No es lo mismo la traducción con IA?

No, y aquí es donde la conversación del mercado se equivoca. Lokalise se describe a sí misma como una plataforma de localización con IA; Phrase ofrece Language AI para traducción automática a gran escala. Ambas son capacidades reales. Ambas hacen más rápida una sola flecha del pipeline antiguo: el paso de traducir. El catálogo se sigue exportando, sigue viviendo en una plataforma externa, sigue volviendo a través de una importación.

Una flecha más rápida en un ida y vuelta de siete etapas es una optimización. Eliminar el ida y vuelta es un producto distinto. Esa es la distinción de capa real: las plataformas construidas en torno a flujos de trabajo de traductores ocupan la capa de gestión, y globalize.now ocupa la capa de infraestructura debajo de ella, generando las claves y los archivos de traducción a partir del propio código, en el repo. «Impulsado por IA» describe a ambas. No distingue a ninguna. La posición sí.

¿Qué sigue perteneciendo a la parte final del proceso?

El criterio humano en textos de alto riesgo. Textos legales, afirmaciones reguladas, la voz de marca en un mercado que te importa de verdad: eso merece un traductor profesional y una pasada de revisión, y los equipos con esa necesidad seguirán usando herramientas construidas en torno a flujos de trabajo de traductores. Nada en la localización adelantada impide eso; el PR localizado es una superficie revisable, y una persona puede exigirle cualquier estándar antes de fusionarlo.

Lo que termina es la era en la que cada equipo tenía que adoptar una plataforma de workflow para traductores solo para lanzar un segundo idioma. Un desarrollador solo con un producto construido con IA no tiene traductores que gestionar. Tiene commits. Las herramientas deberían encontrarlo ahí.

El loop es el producto

Si tu código se lanza mediante pull requests, tus traducciones también deberían. globalize.now convierte el codebase una vez y a partir de ahí lo mantiene localizado en cada push, PR entrante, PR fusionada, lanzada.