La IA ya puede escribir código.
Pronto, eso podría ser una de las partes menos diferenciadas de construir software.
El lanzamiento de Catalyst 3.0 por Zoho es una señal importante de hacia dónde se mueve la industria del software. Catalyst se posiciona como una plataforma cloud full-stack preparada para agentes que conecta agentes de codificación con IA con la infraestructura necesaria para construir y operar aplicaciones. Zoho permite ahora a los agentes aprovisionar bases de datos, configurar autenticación, crear almacenamiento, desplegar funciones, trabajar con servicios de plataforma e interactuar con la infraestructura mediante MCP y agent skills legibles por máquina. (Catalyst)
La importancia va mucho más allá de Zoho.
Apunta a un cambio estructural mucho mayor en el desarrollo de software.
En la primera fase de la IA generativa en ingeniería de software, la industria se concentró intensamente en una pregunta:
¿Cuánto código puede escribir la IA?
La siguiente pregunta es considerablemente más importante:
¿Cuánto de la creación de software puede convertirse de ensamblaje humano en un sistema gobernado y automatizado?
Esa distinción podría tener consecuencias importantes para las empresas de software, los equipos de ingeniería y, en particular, la industria de servicios TI de la India.
La generación de código se convierte rápidamente en una commodity
Claude, Codex, Cursor, GitHub Copilot, Gemini y otros sistemas de codificación ya pueden producir cantidades sustanciales de software funcional.
La calidad varía. La fiabilidad varía. La supervisión humana requerida varía.
Pero la dirección ya no es especialmente controvertida.
El coste marginal de producir otro componente, ruta API, consulta SQL o caso de prueba cae con rapidez.
Zoho parece reconocer la implicación. Catalyst 3.0 no intenta simplemente convertirse en otro asistente de codificación. Proporciona a los agentes de IA acceso estructurado a la plataforma cloud circundante.
Zoho describe Catalyst como una cloud full-stack preparada para agentes que cubre frontend, backend, datos, infraestructura, IA y DevOps. Su integración MCP permite a los agentes de codificación crear tablas, configurar autenticación y desplegar servicios directamente contra la plataforma. También proporciona agent skills que enseñan a los modelos compatibles cómo debe usarse Catalyst. (Catalyst)
Eso es un desarrollo importante porque escribir código de aplicación nunca ha sido todo el problema del software.
El software de producción también requiere arquitectura, autenticación, permisos, bases de datos, infraestructura, observabilidad, despliegue, escalado, gestión de releases, controles de seguridad y mantenimiento.
A medida que la generación de código se facilita, estas disciplinas circundantes se vuelven relativamente más valiosas.
Pero hay otra capa antes de todas ellas.
La oportunidad mayor es el ensamblaje de software
En Volt X, nuestra visión es que la industria avanza más allá de la automatización de la generación de código hacia la automatización del ensamblaje de software.
No son lo mismo.
Un asistente de codificación puede crear un componente React.
El ensamblaje de software determina:
- si ese componente debería existir
- qué patrón de producto implementa
- qué módulo lo posee
- qué objeto de datos representa
- qué roles pueden acceder a él
- qué estados de workflow aplican
- cómo se comporta en el resto de la aplicación
- cómo los cambios se propagan a interfaces relacionadas
- cómo se validan sus datos
- cómo se integra con el sistema más amplio
- cómo se prueba
- cómo permanece coherente seis meses y 200 solicitudes de cambio después
Aquí es donde los grandes productos de software se vuelven difíciles.
El reto no es simplemente producir código. El reto es mantener un producto y un sistema de ingeniería coherentes mientras se acumulan miles de decisiones de implementación individuales.
Ese es el problema que Blaze fue creado para abordar.
Blaze adopta un camino distinto al de la codificación agéntica
Blaze no está diseñado en torno a la suposición de que un agente de IA deba inventar continuamente la aplicación.
La arquitectura central está impulsada por contratos.
Una aplicación Blaze puede comenzar con una definición canónica de aplicación que represente elementos como:
- módulos
- entidades
- campos
- relaciones
- workflows
- comandos
- consultas
- roles
- estructuras RBAC
- permisos
- estados operativos
- dashboards
- informes
- navegación
- patrones de página
- reglas de interfaz
Estas estructuras se convierten en la definición persistente del producto.
El software se ensambla entonces contra patrones de producto gobernados, esquemas tipados, estructuras UX reutilizables y reglas de ingeniería deterministas.
La IA puede asistir donde la interpretación o el razonamiento aportan valor.
Pero dondequiera que el comportamiento pueda representarse de forma determinista, Blaze está diseñado para que los contratos y las reglas de software posean ese comportamiento en lugar de pedir repetidamente a un modelo de lenguaje que lo recree.
La distinción puede expresarse de forma sencilla.
Un sistema de codificación agéntica pide a la IA que tome mejores decisiones de software.
Un sistema de creación de software impulsado por contratos intenta eliminar por completo las decisiones de software innecesarias de la IA.
Esa diferencia se vuelve cada vez más importante a medida que crecen las aplicaciones.
Zoho Catalyst y Blaze abordan partes adyacentes de la misma transición
Catalyst 3.0 es especialmente interesante porque valida la dirección más amplia.
Zoho está diciendo, en efecto, que dar a un agente de codificación con IA una ventana de prompt es insuficiente.
El agente también necesita conocimiento estructurado de la plataforma, capacidades legibles por máquina, acceso a infraestructura, permisos y controles de producción.
Sus Agent Skills y la implementación MCP proporcionan ese contexto. Zoho informa de una finalización de tareas materialmente superior cuando los modelos usan Catalyst Skills y MCP que cuando intentan las mismas tareas sin ellos. (Catalyst)
Blaze aborda el problema en otra capa.
Una simplificación útil es:
Asistente de codificación con IA
escribe o modifica código
Blaze
gobierna y automatiza la estructura de aplicación y el ensamblaje de software
Plataformas cloud como Catalyst
proporcionan infraestructura de producción y servicios operativos
Estas capas pueden solaparse, pero no son idénticas.
Catalyst se ocupa principalmente de dar a los agentes un mejor camino del código a la infraestructura.
Blaze se ocupa de hacer que la aplicación en sí esté estructurada antes, durante y después de la generación de código.
Esta distinción importa porque la preparación para producción comienza antes del despliegue.
La arquitectura comienza antes que la infraestructura.
La mantenibilidad comienza antes de que un repositorio se vuelva grande.
La coherencia comienza antes de construir la centésima pantalla.
La compatibilidad de seguridad comienza con la forma y comprensibilidad del codebase.
Y la gestión fiable de cambios comienza con si la aplicación tiene una definición estructural persistente.
Por qué esto importa enormemente para la industria de servicios TI de la India
La India construyó una de las industrias tecnológicas más exitosas del mundo en torno a la industrialización de la entrega de software.
La escala es sustancial.
NASSCOM estimó los ingresos de la industria tecnológica india en aproximadamente US$283 billion in FY25, incluyendo alrededor de US$224 billion in exports. Estimaciones industriales más recientes sitúan el sector por encima de US$300 billion, con millones de personas empleadas en desarrollo de software, servicios de procesos de negocio, ingeniería, consultoría y funciones tecnológicas relacionadas. (NASSCOM Community)
Este éxito se construyó sobre varias ventajas potentes:
grandes reservas de talento técnico cualificado, capacidad de entrega global, gestión madura de procesos, dominio del inglés, eficiencia de costes y la capacidad de movilizar organizaciones de ingeniería sustanciales.
Durante décadas, la escala en sí fue una ventaja.
Una empresa global que necesitaba un programa de software importante podía contratar a una organización de servicios india capaz de reunir cientos o miles de personas en análisis, UX, ingeniería frontend, ingeniería backend, QA, DevOps, arquitectura y soporte.
El modelo comercial a menudo seguía la misma unidad subyacente:
people × time × billing rate.
La automatización del software desafía esa unidad.
¿Qué ocurre cuando un equipo pequeño puede producir el output de uno mucho mayor?
Supongamos que una aplicación empresarial sustancial requiere tradicionalmente:
20 desarrolladores frontend,
15 desarrolladores backend,
8 ingenieros QA,
5 analistas de negocio,
4 diseñadores,
varios arquitectos,
ingenieros DevOps,
gestión de proyectos,
y múltiples capas de coordinación.
Los números exactos no importan.
La suposición subyacente sí.
Los modelos de entrega tradicionales requieren una cantidad significativa de trabajo humano porque el software debe ensamblarse manualmente a través de miles de decisiones y artefactos interconectados.
Si las estructuras de producto se vuelven reutilizables, los modelos de datos se impulsan por contratos, las interfaces se vuelven deterministas, los workflows comunes se convierten en patrones, las pruebas se generan cada vez más, la producción de código se automatiza y el despliegue se vuelve operable por máquina, la relación entre output y headcount cambia.
Un equipo de diez puede eventualmente entregar trabajo que antes requería cincuenta.
Un equipo de cinco puede gestionar productos que previamente requerían veinte.
Eso no simplemente aumenta la productividad.
Cambia la economía de la industria.
El modelo basado en headcount resulta cada vez más difícil de sostener
Para las empresas tradicionales de servicios TI, la automatización crea un problema económico inusual.
Si los ingresos de una empresa están estrechamente correlacionados con el número de personas facturables desplegadas en un cliente, una tecnología que reduce drásticamente el headcount requerido puede simultáneamente mejorar la productividad de entrega y socavar el modelo comercial existente.
Una empresa de servicios de software puede automatizar el 70 per cent de una implementación.
Pero si continúa cobrando puramente por meses de desarrollador, acaba de automatizar parte de su propia base de ingresos.
Esto crea una tensión estratégica.
Las empresas más capaces de construir una potente automatización de entrega pueden ser también las que más tienen que disrumpir dentro de sus organizaciones existentes.
Por eso la transición puede no ser simplemente:
servicios TI tradicionales + IA = la misma industria, ligeramente más rápida.
Puede convertirse en:
un modelo de entrega de software completamente distinto.
La unidad de valor puede pasar de las personas al output de software
La pregunta tradicional en outsourcing a menudo ha sido:
¿Cuántas personas necesitamos?
La pregunta emergente puede convertirse en:
¿Cuánto software fiable puede producir este sistema de entrega?
Eso es un cambio profundo.
Los modelos comerciales podrían moverse cada vez más hacia:
- resultados de producto
- entrega de capacidad fija
- uso de plataforma
- módulos de software
- economía por transacción
- operaciones de producto gestionadas
- servicios respaldados por propiedad intelectual
- precios basados en valor
en lugar de una multiplicación directa de headcount.
Esto es central en el modelo de Volt X.
No creemos que una mayor capacidad de software deba requerir automáticamente equipos de entrega proporcionalmente más grandes.
La oportunidad económica en la automatización del software es precisamente la contraria.
La tecnología debería permitir producir software cada vez más capaz con equipos más pequeños, más experimentados y más multidisciplinares.
Esto no significa que los ingenieros de software desaparezcan
La conclusión de que la automatización del software elimina por completo a los ingenieros es tanto simplista como improbable.
Lo que cambia es dónde reside el valor de la ingeniería.
A medida que la implementación repetitiva se abarata, aumenta el valor relativo del trabajo de orden superior.
Los equipos seguirán necesitando personas que comprendan:
- arquitectura empresarial
- modelos de dominio
- sistemas distribuidos
- arquitectura de datos
- ciberseguridad
- diseño de integración
- estrategia de producto
- ingeniería de workflows
- rendimiento
- restricciones regulatorias
- comportamiento del usuario
- resiliencia operativa
- entornos legacy complejos
Pero menos personas altamente capaces pueden entregar sustancialmente más.
El ingeniero de software se vuelve menos valioso como unidad humana de producción de código y más valioso como tomador de decisiones técnicas.
Lo mismo ocurre con diseñadores, analistas y profesionales QA.
La producción rutinaria de artefactos se facilita.
El juicio se vuelve más valioso.
La industria TI india ha afrontado cambios tecnológicos antes, pero este es estructuralmente distinto
La industria tecnológica de la India se ha adaptado repetidamente.
El trabajo en mainframe dio paso a sistemas cliente-servidor.
Cliente-servidor dio paso al desarrollo web.
La infraestructura migró hacia la cloud.
El QA manual evolucionó hacia la automatización.
Waterfall dio paso a la entrega ágil.
El mantenimiento de aplicaciones se expandió hacia transformación digital, modernización cloud, ingeniería de datos y desarrollo de producto.
La IA creará otro mercado amplio para las empresas tecnológicas indias.
Eso no está en duda.
Pero la automatización del ensamblaje de software crea un reto más fundamental porque llega directamente a la relación entre trabajo y ingresos.
Las oleadas tecnológicas anteriores crearon con frecuencia nuevas categorías de trabajo de implementación.
Esta oleada puede automatizar partes cada vez mayores del propio trabajo de implementación.
Eso no necesariamente hace más pequeña la industria TI india.
Sí significa que las empresas más fuertes pueden necesitar derivar más ingresos del apalancamiento intelectual y menos del apalancamiento laboral.
La próxima ventaja competitiva puede ser la inteligencia de entrega codificada
Las organizaciones de servicios de software poseen un activo enorme que a menudo permanece sorprendentemente no estructurado.
Han acumulado décadas de conocimiento sobre:
sistemas bancarios, telecomunicaciones, sanidad, manufactura, ERP, cadenas de suministro, seguros, comercio, operaciones, compliance, diseño de workflows, estructuras de datos e integración empresarial.
Mucho de ese conocimiento sigue viviendo dentro de personas, documentos de proyecto, repositorios, PowerPoints e implementaciones anteriores.
La próxima oportunidad es convertir esa experiencia en inteligencia ejecutable.
Patrones.
Esquemas.
Contratos.
Arquitecturas de referencia.
Modelos de workflow.
Sistemas de producto reutilizables.
Frameworks de prueba.
Automatización específica de dominio.
Eso es considerablemente más defendible que simplemente dar a cada desarrollador acceso al mismo modelo de IA de frontera.
Toda empresa importante de servicios puede acceder a Claude.
Toda empresa importante de servicios puede acceder a Codex.
Toda empresa importante de servicios puede acceder a Gemini.
El diferenciador se convierte en qué sistema propietario rodea esos modelos.
Esta es la importancia más profunda de Zoho Catalyst 3.0
Zoho está demostrando un principio importante.
La capacidad genérica de IA no basta.
Para operar eficazmente dentro de un entorno tecnológico real, el modelo necesita conocimiento estructurado, herramientas explícitas, permisos gobernados e interfaces legibles por máquina.
Catalyst Agent Skills proporcionan conocimiento específico de plataforma. MCP expone acciones controladas. Los permisos restringen el comportamiento del agente. Las audit trails hacen observables esas acciones. (Catalyst)
En otras palabras, Zoho está añadiendo estructura alrededor de la inteligencia.
Ese principio se extiende mucho más allá de la infraestructura.
Lo mismo debe ocurrir con la aplicación misma.
La estructura del producto debe ser legible por máquina.
Los roles deben ser explícitos.
Las relaciones deben estar tipadas.
Los workflows deben estar gobernados.
Las reglas de UI deben persistir.
Los cambios deben tener dependencias trazables.
Los builds deben ser reproducibles.
Las pruebas deben ser sistemáticas.
La arquitectura no debería necesitar redescubrirse cada vez que alguien introduce otro prompt.
Esa es la dirección que perseguimos con Blaze.
De la automatización del desarrollo de software a la manufactura de software
La palabra "manufactura" ha sido históricamente incómoda en software porque el software no es un producto físico repetitivo.
Cada organización tiene workflows, usuarios, datos, políticas, integraciones y realidades operativas distintas.
Eso sigue siendo cierto.
Pero la personalización no significa que cada estructura subyacente deba inventarse de nuevo.
La mayoría de las aplicaciones empresariales contienen grandes cantidades de inteligencia de software repetible:
sistemas de registros, listas, grids, jerarquías, filtros, dashboards, estados de workflow, aprobaciones, permisos, historiales de auditoría, notificaciones, configuraciones, informes, formularios, búsqueda, gestión de roles.
La oportunidad no es eliminar el software a medida.
Es industrializar las partes repetibles preservando el control determinista sobre las partes que hacen distinto a cada negocio.
Esa es una interpretación mucho más útil de la automatización del software.
El modelo ganador puede combinar humanos, sistemas deterministas e IA
Hay una tentación de enmarcar el futuro como humanos versus IA.
Esa es probablemente la abstracción equivocada.
Un sistema de entrega de software más sólido combina tres capacidades distintas.
El juicio humano determina qué importa.
Los sistemas de software deterministas gobiernan lo que no debe variar.
La IA gestiona interpretación y razonamiento donde la variabilidad es útil.
El problema del vibe coding puro es que demasiada responsabilidad se delega a la capa probabilística.
El problema de la entrega tradicional es que demasiado trabajo repetible sigue delegado a las personas.
La oportunidad está entre ambos.
Usar personas para el juicio.
Usar software para el determinismo.
Usar IA para inteligencia donde la inteligencia realmente aporta valor.
Esa es la arquitectura de automatización del software que creemos que puede escalar.
¿Qué ocurre con el modelo de servicios de miles de millones?
La industria de servicios TI de la India no desaparecerá.
Pero su modelo operativo puede cambiar drásticamente.
La parte más expuesta de la industria probablemente sea el trabajo que es:
altamente repetible, impulsado por especificaciones, intensivo en mano de obra, coordinado manualmente y diferenciado principalmente mediante headcount eficiente en costes.
Las oportunidades más fuertes probablemente se muevan hacia trabajo que combine:
experiencia de dominio, sistemas de entrega propietarios, platform engineering, integración compleja, arquitectura, IA y automatización, datos, seguridad, product ownership y propiedad intelectual reutilizable.
Esto podría hacer que las empresas tecnológicas indias sean considerablemente más valiosas, no menos.
Una empresa que puede generar el doble de output de software con la mitad de personas no tiene inherentemente un negocio más pequeño.
Tiene una estructura de costes fundamentalmente distinta.
La pregunta es si continúa vendiendo horas o aprende a vender el valor producido por ese apalancamiento.
Las empresas de software competirán cada vez más en el sistema que construye el software
Durante los últimos veinte años, la industria del software compitió intensamente en talento de ingeniería.
Durante la próxima década, otra dimensión puede volverse igual de importante:
el sistema interno mediante el cual ese talento crea software.
Dos empresas pueden emplear ingenieros igualmente capaces y usar exactamente el mismo LLM.
Pero una puede tener:
un modelo de producto canónico, miles de patrones codificados, contratos tipados, pruebas automatizadas, ensamblaje de aplicación determinista, automatización de despliegue, inteligencia específica de dominio y conocimiento acumulado de build.
La otra puede simplemente proporcionar a los desarrolladores un asistente de codificación con IA.
Esas no son capacidades equivalentes.
Por eso creemos que la tecnología de build propietaria puede convertirse en una ventaja competitiva importante para las empresas de desarrollo de software.
La pregunta ya no es si la IA puede escribir código
Esa pregunta ha sido respondida en gran medida.
Las preguntas más consecuentes son ahora:
- ¿Puede codificarse la estructura del software?
- ¿Puede el ensamblaje de aplicaciones volverse determinista?
- ¿Puede la inteligencia de producto volverse reutilizable?
- ¿Pueden los cambios propagarse sin deriva arquitectónica?
- ¿Pueden equipos más pequeños producir de forma fiable sistemas mucho mayores?
- ¿Pueden las empresas de software desacoplar output de headcount?
- ¿Pueden décadas de experiencia de entrega convertirse en propiedad intelectual ejecutable?
Zoho Catalyst 3.0 es una indicación más de que la industria avanza más allá del asistente de codificación.
En Volt X, creemos que la próxima frontera va aún más lejos.
No se trata meramente de automatizar la codificación.
Se trata de automatizar partes cada vez mayores del ensamblaje de software en sí preservando el juicio de producto, la disciplina de ingeniería y los controles empresariales que el software de producción requiere.
Si esa transición continúa, cambiará más que la productividad del desarrollador.
Podría cambiar la economía de una industria entera.
Y para una economía de servicios tecnológicos tan grande e importante como la de la India, eso convierte la automatización del ensamblaje de software en un desarrollo que merece tomarse muy en serio.
Acerca de Blaze
Blaze es la tecnología propietaria de creación de software de Volt X para construir y extender aplicaciones empresariales mediante definiciones estructuradas de producto, inteligencia de producto reutilizable, patrones UX gobernados y contratos de ingeniería deterministas.
Está diseñada para ayudar a los equipos a crear software a medida sustancial con mayor velocidad, coherencia y control sin convertir la IA generativa en la fuente de verdad arquitectónica.