AI can now write code.
That may soon be one of the least differentiated parts of building software.
Zoho’s launch of Catalyst 3.0 is an important signal of where the software industry is moving. Catalyst is being positioned as an agent-ready, full-stack cloud platform that connects AI coding agents with the infrastructure required to build and operate applications. Zoho now allows agents to provision databases, configure authentication, create storage, deploy functions, work with platform services and interact with infrastructure through MCP and machine-readable agent skills. (Catalyst)
The significance goes well beyond Zoho.
It points towards a much larger structural shift in software development.
For the first phase of generative AI in software engineering, the industry concentrated heavily on one question:
How much code can AI write?
The next question is considerably more important:
How much of software creation can be converted from human assembly into a governed, automated system?
That distinction could have major consequences for software companies, engineering teams and, particularly, the Indian IT services industry.
Code generation is rapidly becoming a commodity
Claude, Codex, Cursor, GitHub Copilot, Gemini and other coding systems can already produce substantial amounts of working software.
The quality varies. The reliability varies. The amount of human supervision required varies.
But the direction is no longer particularly controversial.
The marginal cost of producing another component, API route, SQL query or test case is falling rapidly.
Zoho appears to recognise the implication. Catalyst 3.0 is not simply trying to become another coding assistant. It is providing AI agents with structured access to the surrounding cloud platform.
Zoho describes Catalyst as an agent-ready full-stack cloud covering frontend, backend, data, infrastructure, AI and DevOps. Its MCP integration allows coding agents to create tables, configure authentication and deploy services directly against the platform. It also provides agent skills that teach supported models how Catalyst itself should be used. (Catalyst)
That is an important development because writing application code has never been the whole software problem.
Production software also requires architecture, authentication, permissions, databases, infrastructure, observability, deployment, scaling, release management, security controls and maintenance.
As code generation becomes easier, these surrounding disciplines become relatively more valuable.
But there is another layer before all of them.
The larger opportunity is software assembly
At Volt X, our view is that the industry is moving beyond code generation automation towards software assembly automation.
Those are not the same thing.
A coding assistant can create a React component.
Software assembly determines:
- whether that component should exist
- which product pattern it implements
- which module owns it
- which data object it represents
- which roles can access it
- which workflow states apply
- how it behaves across the rest of the application
- how changes propagate to related interfaces
- how its data is validated
- how it integrates with the wider system
- how it is tested
- how it remains consistent six months and 200 change requests later
This is where large software products become difficult.
The challenge is not merely producing code. The challenge is maintaining a coherent product and engineering system while thousands of individual implementation decisions accumulate.
That is the problem Blaze was created to address.
Blaze takes a different route from agentic coding
Blaze is not designed around the assumption that an AI agent should continuously invent the application.
The core architecture is contract driven.
A Blaze application can begin with a canonical application definition representing elements such as:
- modules
- entities
- fields
- relationships
- workflows
- commands
- queries
- roles
- RBAC structures
- permissions
- operational states
- dashboards
- reports
- navigation
- page patterns
- interface rules
These structures become the persistent definition of the product.
The software is then assembled against governed product patterns, typed schemas, reusable UX structures and deterministic engineering rules.
AI can assist where interpretation or reasoning is valuable.
But wherever behaviour can be represented deterministically, Blaze is designed to let contracts and software rules own that behaviour rather than repeatedly asking a language model to recreate it.
The distinction can be expressed simply.
An agentic coding system asks AI to make better software decisions.
A contract-driven software creation system tries to remove unnecessary software decisions from AI altogether.
That difference becomes increasingly important as applications grow.
Zoho Catalyst and Blaze are addressing adjacent parts of the same transition
Catalyst 3.0 is particularly interesting because it validates the broader direction.
Zoho is effectively saying that giving an AI coding agent a prompt window is insufficient.
The agent also needs structured knowledge of the platform, machine-readable capabilities, infrastructure access, permissions and production controls.
Its Agent Skills and MCP implementation provide that context. Zoho reports materially higher task completion when models use Catalyst Skills and MCP than when they attempt the same tasks without them. (Catalyst)
Blaze approaches the problem at another layer.
A useful simplification is:
AI coding assistant
writes or modifies code
Blaze
governs and automates application structure and software assembly
Cloud platforms such as Catalyst
provide production infrastructure and operational services
These layers can overlap, but they are not identical.
Catalyst is largely concerned with giving agents a better path from code into infrastructure.
Blaze is concerned with making the application itself structured before, during and after code generation.
This distinction matters because production readiness begins before deployment.
Architecture starts before infrastructure.
Maintainability starts before a repository becomes large.
Consistency starts before the hundredth screen is built.
Security compatibility starts with the shape and comprehensibility of the codebase.
And reliable change management starts with whether the application has a persistent structural definition.
Why this matters enormously for the Indian IT services industry
India built one of the world's most successful technology industries around the industrialisation of software delivery.
The scale is substantial.
NASSCOM estimated Indian technology industry revenue at approximately US$283 billion in FY25, including around US$224 billion in exports. More recent industry estimates place the sector above US$300 billion, with millions of people employed across software development, business-process services, engineering, consulting and related technology functions. (NASSCOM Community)
This success was built on several powerful advantages:
large pools of skilled technical talent, global delivery capability, mature process management, English-language capability, cost efficiency and the ability to mobilise substantial engineering organisations.
For decades, scale itself was an advantage.
A global enterprise requiring a major software programme could engage an Indian services organisation capable of assembling hundreds or thousands of people across analysis, UX, frontend engineering, backend engineering, QA, DevOps, architecture and support.
The commercial model often followed the same underlying unit:
people × time × billing rate.
Software automation challenges that unit.
What happens when one small team can produce the output of a much larger one?
Suppose a substantial enterprise application traditionally requires:
20 frontend developers,
15 backend developers,
8 QA engineers,
5 business analysts,
4 designers,
several architects,
DevOps engineers,
project management,
and multiple coordination layers.
The precise numbers are not important.
The underlying assumption is.
Traditional delivery models require a significant amount of human labour because software must be assembled manually across thousands of interconnected decisions and artefacts.
If product structures become reusable, data models become contract-driven, interfaces become deterministic, common workflows become patterns, testing becomes increasingly generated, code production becomes automated and deployment becomes machine-operable, the relationship between output and headcount changes.
A team of ten may eventually be able to deliver work that once required fifty.
A team of five may manage products that previously required twenty.
That does not simply increase productivity.
It changes the economics of the industry.
The headcount model becomes increasingly difficult to defend
For traditional IT services companies, automation creates an unusual economic problem.
If a company's revenue is closely correlated with the number of billable people deployed to a client, a technology that dramatically reduces the required headcount can simultaneously improve delivery productivity and undermine the existing commercial model.
A software services company can automate 70 per cent of an implementation.
But if it continues charging purely for developer months, it has just automated away part of its own revenue base.
This creates a strategic tension.
The firms most capable of building powerful delivery automation may also have the most to disrupt inside their existing organisations.
That is why the transition may not simply be:
traditional IT services + AI = same industry, slightly faster.
It may become:
a different software delivery model altogether.
The unit of value may shift from people to software output
The traditional question in outsourcing has often been:
How many people do we need?
The emerging question may instead become:
How much reliable software can this delivery system produce?
That is a profound change.
Commercial models could increasingly move towards:
- product outcomes
- fixed capability delivery
- platform usage
- software modules
- transaction economics
- managed product operations
- intellectual-property-backed services
- value-based pricing
rather than straightforward headcount multiplication.
This is central to the Volt X model.
We do not believe that greater software capability should automatically require proportionately larger delivery teams.
The economic opportunity in software automation is precisely the opposite.
Technology should allow increasingly capable software to be produced with smaller, more experienced, more multidisciplinary teams.
This does not mean software engineers disappear
The conclusion that software automation eliminates engineers entirely is both simplistic and unlikely.
What changes is where engineering value sits.
As repetitive implementation becomes cheaper, the relative value of higher-order work increases.
Teams will still need people who understand:
- enterprise architecture
- domain models
- distributed systems
- data architecture
- cybersecurity
- integration design
- product strategy
- workflow engineering
- performance
- regulatory constraints
- user behaviour
- operational resilience
- complex legacy environments
But fewer highly capable people may be able to deliver substantially more.
The software engineer becomes less valuable as a human code-production unit and more valuable as a technical decision maker.
The same is true for designers, analysts and QA professionals.
Routine artefact production becomes easier.
Judgement becomes more valuable.
The Indian IT industry has faced technology shifts before, but this one is structurally different
India's technology industry has repeatedly adapted.
Mainframe work gave way to client-server systems.
Client-server gave way to web development.
Infrastructure moved towards cloud.
Manual QA moved towards automation.
Waterfall gave way to agile delivery.
Application maintenance expanded into digital transformation, cloud modernisation, data engineering and product development.
AI will create another large market for Indian technology companies.
That is not in doubt.
But software assembly automation creates a more fundamental challenge because it reaches directly into the relationship between labour and revenue.
Previous technology waves frequently created new categories of implementation work.
This wave may automate increasingly large parts of the implementation work itself.
That does not necessarily make the Indian IT industry smaller.
It does mean that the strongest companies may need to derive more revenue from intellectual leverage and less from labour leverage.
The next competitive advantage may be codified delivery intelligence
Software services organisations possess an enormous asset that often remains surprisingly unstructured.
They have accumulated decades of knowledge about:
banking systems, telecommunications, healthcare, manufacturing, ERP, supply chains, insurance, commerce, operations, compliance, workflow design, data structures and enterprise integration.
Much of that knowledge still lives inside people, project documents, repositories, PowerPoints and previous implementations.
The next opportunity is to turn that experience into executable intelligence.
Patterns.
Schemas.
Contracts.
Reference architectures.
Workflow models.
Reusable product systems.
Testing frameworks.
Domain-specific automation.
That is considerably more defensible than simply giving every developer access to the same frontier AI model.
Every major services company can access Claude.
Every major services company can access Codex.
Every major services company can access Gemini.
The differentiator becomes what proprietary system surrounds those models.
This is the deeper significance of Zoho Catalyst 3.0
Zoho is demonstrating an important principle.
Generic AI capability is not enough.
To operate effectively inside a real technology environment, the model needs structured knowledge, explicit tools, governed permissions and machine-readable interfaces.
Catalyst Agent Skills provide platform-specific knowledge. MCP exposes controlled actions. Permissions constrain agent behaviour. Audit trails make those actions observable. (Catalyst)
In other words, Zoho is adding structure around the intelligence.
That principle extends far beyond infrastructure.
The same needs to happen to the application itself.
Product structure should be machine-readable.
Roles should be explicit.
Relationships should be typed.
Workflows should be governed.
UI rules should persist.
Changes should have traceable dependencies.
Builds should be reproducible.
Tests should be systematic.
Architecture should not need to be rediscovered every time someone enters another prompt.
That is the direction we are pursuing with Blaze.
From software development automation to software manufacturing
The word "manufacturing" has historically been uncomfortable in software because software is not a repetitive physical product.
Every organisation has different workflows, users, data, policies, integrations and operating realities.
That remains true.
But customisation does not mean every underlying structure has to be invented again.
Most enterprise applications contain large amounts of repeatable software intelligence:
record systems, lists, grids, hierarchies, filters, dashboards, workflow states, approvals, permissions, audit histories, notifications, settings, reports, forms, search, role management.
The opportunity is not to eliminate custom software.
It is to industrialise the repeatable parts while preserving deterministic control over the parts that make each business different.
That is a much more useful interpretation of software automation.
The winning model may combine humans, deterministic systems and AI
There is a temptation to frame the future as humans versus AI.
That is probably the wrong abstraction.
A stronger software delivery system combines three different capabilities.
Human judgement determines what matters.
Deterministic software systems govern what should not vary.
AI handles interpretation and reasoning where variability is useful.
The problem with pure vibe coding is that too much responsibility is delegated to the probabilistic layer.
The problem with traditional delivery is that too much repeatable work remains delegated to people.
The opportunity lies between them.
Use people for judgement.
Use software for determinism.
Use AI for intelligence where intelligence actually adds value.
That is the architecture of software automation we believe can scale.
What happens to the billion-dollar services model?
The Indian IT services industry will not disappear.
But its operating model can change dramatically.
The most exposed part of the industry is likely to be work that is:
highly repeatable, specification driven, labour intensive, manually coordinated, and differentiated primarily through cost-efficient headcount.
The strongest opportunities are likely to move towards work that combines:
domain expertise, proprietary delivery systems, platform engineering, complex integration, architecture, AI and automation, data, security, product ownership, and reusable intellectual property.
This could ultimately make Indian technology companies considerably more valuable, not less.
A company that can generate twice the software output with half the people does not inherently have a smaller business.
It has a fundamentally different cost structure.
The question is whether it continues selling hours or learns to sell the value produced by that leverage.
Software companies will increasingly compete on the system that builds the software
For the last twenty years, the software industry competed heavily on engineering talent.
For the next decade, another dimension may become equally important:
the internal system through which that talent creates software.
Two companies may employ similarly capable engineers and use exactly the same LLM.
But one may have:
a canonical product model, thousands of codified patterns, typed contracts, automated testing, deterministic application assembly, deployment automation, domain-specific intelligence, and accumulated build knowledge.
The other may simply provide developers with an AI coding assistant.
Those are not equivalent capabilities.
This is why we believe proprietary build technology can become an important competitive advantage for software development companies.
The question is no longer whether AI can write code
That question has largely been answered.
The more consequential questions are now:
- Can software structure be codified?
- Can application assembly become deterministic?
- Can product intelligence become reusable?
- Can changes propagate without architectural drift?
- Can smaller teams reliably produce much larger systems?
- Can software companies decouple output from headcount?
- Can decades of delivery experience be converted into executable intellectual property?
Zoho Catalyst 3.0 is one more indication that the industry is moving beyond the coding assistant.
At Volt X, we believe the next frontier goes further still.
It is not merely about automating coding.
It is about automating increasingly large parts of software assembly itself while preserving the product judgement, engineering discipline and enterprise controls that production software requires.
If that transition continues, it will change more than developer productivity.
It could change the economics of an entire industry.
And for a technology services economy as large and important as India's, that makes software assembly automation a development worth taking very seriously.
About Blaze
Blaze is Volt X's proprietary software creation technology for building and extending enterprise applications through structured product definitions, reusable product intelligence, governed UX patterns and deterministic engineering contracts.
It is designed to help teams create substantial custom software with greater speed, consistency and control without making generative AI the architectural source of truth.