KI kann jetzt Code schreiben.
Das könnte bald einer der am wenigsten differenzierten Teile der Softwareentwicklung sein.
Zohos Launch von Catalyst 3.0 ist ein wichtiges Signal dafür, wohin sich die Softwareindustrie bewegt. Catalyst wird als agent-ready, full-stack Cloud-Plattform positioniert, die KI-Coding-Agenten mit der Infrastruktur verbindet, die zum Erstellen und Betreiben von Anwendungen erforderlich ist. Zoho erlaubt Agenten nun, Datenbanken bereitzustellen, Authentifizierung zu konfigurieren, Storage anzulegen, Functions zu deployen, mit Plattformdiensten zu arbeiten und über MCP sowie maschinenlesbare Agent Skills mit der Infrastruktur zu interagieren. (Catalyst)
Die Bedeutung geht weit über Zoho hinaus.
Sie weist auf einen viel größeren strukturellen Wandel in der Softwareentwicklung hin.
In der ersten Phase generativer KI in der Softwareentwicklung konzentrierte sich die Industrie stark auf eine Frage:
Wie viel Code kann KI schreiben?
Die nächste Frage ist erheblich wichtiger:
Wie viel der Softwareerstellung kann von menschlicher Montage in ein governiertes, automatisiertes System überführt werden?
Diese Unterscheidung könnte erhebliche Folgen für Softwareunternehmen, Engineering-Teams und insbesondere die indische IT-Services-Branche haben.
Code-Generierung wird schnell zur Commodity
Claude, Codex, Cursor, GitHub Copilot, Gemini und andere Coding-Systeme können bereits erhebliche Mengen funktionierender Software produzieren.
Die Qualität variiert. Die Zuverlässigkeit variiert. Der erforderliche menschliche Aufsichtsaufwand variiert.
Aber die Richtung ist nicht mehr besonders umstritten.
Die Grenzkosten für die Produktion einer weiteren Komponente, API-Route, SQL-Abfrage oder Testfall sinken rapide.
Zoho scheint die Implikation zu erkennen. Catalyst 3.0 versucht nicht einfach, ein weiterer Coding-Assistent zu werden. Es bietet KI-Agenten strukturierten Zugang zur umgebenden Cloud-Plattform.
Zoho beschreibt Catalyst als agent-ready full-stack Cloud mit Frontend, Backend, Data, Infrastruktur, KI und DevOps. Die MCP-Integration ermöglicht Coding-Agenten, Tabellen zu erstellen, Authentifizierung zu konfigurieren und Services direkt gegen die Plattform zu deployen. Es stellt auch Agent Skills bereit, die unterstützten Modellen beibringen, wie Catalyst selbst genutzt werden soll. (Catalyst)
Das ist eine wichtige Entwicklung, weil das Schreiben von Anwendungscode nie das gesamte Softwareproblem war.
Produktionssoftware erfordert auch Architektur, Authentifizierung, Berechtigungen, Datenbanken, Infrastruktur, Observability, Deployment, Skalierung, Release-Management, Sicherheitskontrollen und Wartung.
Wenn Code-Generierung einfacher wird, werden diese umgebenden Disziplinen relativ wertvoller.
Aber es gibt eine weitere Schicht vor all diesen.
Die größere Chance ist Software Assembly
Bei Volt X ist unsere Einschätzung, dass die Industrie über Code-Generierungs-Automatisierung hinaus zu Software-Assembly-Automatisierung übergeht.
Das ist nicht dasselbe.
Ein Coding-Assistent kann eine React-Komponente erstellen.
Software Assembly bestimmt:
- ob diese Komponente existieren sollte
- welches Produktmuster sie implementiert
- welches Modul sie besitzt
- welches Datenobjekt sie repräsentiert
- welche Rollen darauf zugreifen können
- welche Workflow-States gelten
- wie sie sich im Rest der Anwendung verhält
- wie Änderungen auf verwandte Interfaces propagieren
- wie ihre Daten validiert werden
- wie sie in das breitere System integriert wird
- wie sie getestet wird
- wie sie sechs Monate und 200 Change Requests später konsistent bleibt
Hier werden große Softwareprodukte schwierig.
Die Herausforderung ist nicht nur, Code zu produzieren. Die Herausforderung ist, ein kohärentes Produkt- und Engineering-System aufrechtzuerhalten, während sich Tausende individueller Implementierungsentscheidungen ansammeln.
Das ist das Problem, für das Blaze entwickelt wurde.
Blaze geht einen anderen Weg als agentisches Coding
Blaze ist nicht darauf ausgelegt, dass ein KI-Agent die Anwendung kontinuierlich neu erfinden soll.
Die Kernarchitektur ist contract-driven.
Eine Blaze-Anwendung kann mit einer kanonischen Anwendungsdefinition beginnen, die Elemente wie diese repräsentiert:
- Module
- Entitäten
- Felder
- Beziehungen
- Workflows
- Commands
- Queries
- Rollen
- RBAC-Strukturen
- Berechtigungen
- operative States
- Dashboards
- Reports
- Navigation
- Page Patterns
- Interface Rules
Diese Strukturen werden zur persistenten Definition des Produkts.
Die Software wird dann gegen governierte Produktmuster, typisierte Schemas, wiederverwendbare UX-Strukturen und deterministische Engineering-Regeln zusammengesetzt.
KI kann dort unterstützen, wo Interpretation oder Reasoning wertvoll ist.
Aber wo immer Verhalten deterministisch dargestellt werden kann, ist Blaze so konzipiert, dass Contracts und Software-Regeln dieses Verhalten besitzen — statt wiederholt ein Language Model zu bitten, es neu zu erzeugen.
Die Unterscheidung lässt sich einfach ausdrücken.
Ein agentisches Coding-System bittet KI, bessere Softwareentscheidungen zu treffen.
Ein contract-driven Software-Creation-System versucht, unnötige Softwareentscheidungen ganz aus der KI herauszunehmen.
Dieser Unterschied wird wichtiger, je größer Anwendungen werden.
Zoho Catalyst und Blaze adressieren benachbarte Teile derselben Transition
Catalyst 3.0 ist besonders interessant, weil es die breitere Richtung bestätigt.
Zoho sagt im Grunde, dass es nicht ausreicht, einem KI-Coding-Agenten ein Prompt-Fenster zu geben.
Der Agent braucht auch strukturiertes Plattformwissen, maschinenlesbare Fähigkeiten, Infrastrukturzugang, Berechtigungen und Produktionskontrollen.
Agent Skills und die MCP-Implementierung liefern diesen Kontext. Zoho berichtet materiell höhere Task-Completion, wenn Modelle Catalyst Skills und MCP nutzen, als wenn sie dieselben Aufgaben ohne sie versuchen. (Catalyst)
Blaze geht das Problem auf einer anderen Schicht an.
Eine nützliche Vereinfachung ist:
KI-Coding-Assistent
schreibt oder modifiziert Code
Blaze
governt und automatisiert Anwendungsstruktur und Software Assembly
Cloud-Plattformen wie Catalyst
stellen Produktionsinfrastruktur und operative Services bereit
Diese Schichten können sich überlappen, sind aber nicht identisch.
Catalyst konzentriert sich vor allem darauf, Agenten einen besseren Pfad vom Code zur Infrastruktur zu geben.
Blaze konzentriert sich darauf, die Anwendung selbst vor, während und nach der Code-Generierung zu strukturieren.
Diese Unterscheidung ist wichtig, weil Production Readiness vor dem Deployment beginnt.
Architektur beginnt vor Infrastruktur.
Wartbarkeit beginnt, bevor ein Repository groß wird.
Konsistenz beginnt, bevor der hundertste Screen gebaut wird.
Sicherheitskompatibilität beginnt mit Form und Verständlichkeit der Codebase.
Und zuverlässiges Change Management beginnt damit, ob die Anwendung eine persistente strukturelle Definition hat.
Warum das für die indische IT-Services-Branche enorm wichtig ist
Indien hat eine der erfolgreichsten Technologieindustrien der Welt um die Industrialisierung der Software-Lieferung aufgebaut.
Der Maßstab ist erheblich.
NASSCOM schätzte den Umsatz der indischen Technologieindustrie auf etwa US$283 billion in FY25, einschließlich rund US$224 billion in exports. Neuere Branchenschätzungen setzen den Sektor über US$300 billion an, mit Millionen Beschäftigten in Softwareentwicklung, Business-Process-Services, Engineering, Consulting und verwandten Technologiefunktionen. (NASSCOM Community)
Dieser Erfolg basierte auf mehreren starken Vorteilen:
große Pools qualifizierter technischer Talente, globale Delivery-Fähigkeit, reife Prozessführung, Englischkenntnisse, Kosteneffizienz und die Fähigkeit, erhebliche Engineering-Organisationen zu mobilisieren.
Jahrzehntelang war Skalierung selbst ein Vorteil.
Ein globales Unternehmen, das ein großes Softwareprogramm benötigte, konnte eine indische Services-Organisation engagieren, die Hunderte oder Tausende Menschen in Analyse, UX, Frontend Engineering, Backend Engineering, QA, DevOps, Architektur und Support zusammenbringen konnte.
Das Geschäftsmodell folgte oft derselben Grundeinheit:
people × time × billing rate.
Software-Automatisierung stellt diese Einheit in Frage.
Was passiert, wenn ein kleines Team den Output eines viel größeren produzieren kann?
Angenommen, eine substanzielle Enterprise-Anwendung erfordert traditionell:
20 Frontend-Entwickler,
15 Backend-Entwickler,
8 QA Engineers,
5 Business Analysts,
4 Designer,
mehrere Architekten,
DevOps Engineers,
Project Management,
und mehrere Koordinationsschichten.
Die genauen Zahlen sind nicht wichtig.
Die zugrunde liegende Annahme schon.
Traditionelle Delivery-Modelle erfordern erheblichen menschlichen Aufwand, weil Software manuell über Tausende verknüpfte Entscheidungen und Artefakte zusammengesetzt werden muss.
Wenn Produktstrukturen wiederverwendbar werden, Datenmodelle contract-driven werden, Interfaces deterministisch werden, gemeinsame Workflows zu Patterns werden, Testing zunehmend generiert wird, Code-Produktion automatisiert wird und Deployment maschinenoperierbar wird, ändert sich das Verhältnis zwischen Output und Headcount.
Ein Team von zehn kann eventuell Arbeit liefern, die einst fünfzig erforderte.
Ein Team von fünf kann Produkte verwalten, die zuvor zwanzig erforderten.
Das steigert nicht einfach nur Produktivität.
Es verändert die Ökonomie der Branche.
Das Headcount-Modell wird zunehmend schwer zu verteidigen
Für traditionelle IT-Services-Unternehmen schafft Automatisierung ein ungewöhnliches wirtschaftliches Problem.
Wenn der Umsatz eines Unternehmens eng mit der Anzahl abrechenbarer Personen korreliert, die beim Kunden eingesetzt werden, kann eine Technologie, die den erforderlichen Headcount drastisch reduziert, gleichzeitig die Delivery-Produktivität verbessern und das bestehende Geschäftsmodell untergraben.
Ein Software-Services-Unternehmen kann 70 per cent einer Implementierung automatisieren.
Aber wenn es weiterhin rein nach Developer Months abrechnet, hat es gerade einen Teil seiner eigenen Umsatzbasis automatisiert.
Das erzeugt eine strategische Spannung.
Die Unternehmen, die am besten in der Lage sind, leistungsstarke Delivery-Automatisierung aufzubauen, haben möglicherweise auch am meisten zu disruptieren in ihren bestehenden Organisationen.
Deshalb ist die Transition möglicherweise nicht einfach:
traditionelle IT Services + KI = dieselbe Branche, etwas schneller.
Sie kann werden:
ein völlig anderes Software-Delivery-Modell.
Die Werteinheit kann von Menschen zu Software-Output wechseln
Die traditionelle Frage im Outsourcing war oft:
Wie viele Menschen brauchen wir?
Die aufkommende Frage könnte stattdessen werden:
Wie viel zuverlässige Software kann dieses Delivery-System produzieren?
Das ist ein tiefgreifender Wandel.
Geschäftsmodelle könnten zunehmend in Richtung gehen:
- Produkt-Outcomes
- feste Capability Delivery
- Plattformnutzung
- Software-Module
- Transaktionsökonomie
- Managed Product Operations
- IP-gestützte Services
- Value-based Pricing
statt einfacher Headcount-Multiplikation.
Das ist zentral für das Volt-X-Modell.
Wir glauben nicht, dass größere Software-Fähigkeit automatisch proportional größere Delivery-Teams erfordern sollte.
Die wirtschaftliche Chance in Software-Automatisierung ist genau das Gegenteil.
Technologie sollte ermöglichen, zunehmend leistungsfähige Software mit kleineren, erfahreneren, multidisziplinäreren Teams zu produzieren.
Das bedeutet nicht, dass Software Engineers verschwinden
Die Schlussfolgerung, Software-Automatisierung eliminiere Engineers vollständig, ist sowohl vereinfachend als auch unwahrscheinlich.
Was sich ändert, ist, wo Engineering-Wert liegt.
Wenn repetitive Implementierung billiger wird, steigt der relative Wert höherwertiger Arbeit.
Teams werden weiterhin Menschen brauchen, die verstehen:
- Enterprise Architecture
- Domain Models
- Distributed Systems
- Data Architecture
- Cybersecurity
- Integration Design
- Product Strategy
- Workflow Engineering
- Performance
- regulatorische Constraints
- User Behaviour
- Operational Resilience
- komplexe Legacy-Umgebungen
Aber weniger hochqualifizierte Menschen können substanziell mehr liefern.
Der Software Engineer wird weniger wertvoll als menschliche Code-Produktionseinheit und wertvoller als technischer Entscheidungsträger.
Dasselbe gilt für Designer, Analysts und QA Professionals.
Routinemäßige Artefakt-Produktion wird einfacher.
Urteilsvermögen wird wertvoller.
Die indische IT-Branche hat Technologiewechsel schon erlebt — dieser ist strukturell anders
Indiens Technologieindustrie hat sich wiederholt angepasst.
Mainframe-Arbeit wich Client-Server-Systemen.
Client-Server wich Webentwicklung.
Infrastruktur bewegte sich zur Cloud.
Manuelles QA bewegte sich zur Automatisierung.
Waterfall wich agiler Delivery.
Application Maintenance expandierte zu Digital Transformation, Cloud Modernisation, Data Engineering und Product Development.
KI wird einen weiteren großen Markt für indische Technologieunternehmen schaffen.
Daran besteht kein Zweifel.
Aber Software-Assembly-Automatisierung schafft eine fundamentalere Herausforderung, weil sie direkt in die Beziehung zwischen Arbeit und Umsatz greift.
Frühere Technologiewellen schufen häufig neue Kategorien von Implementierungsarbeit.
Diese Welle kann zunehmend große Teile der Implementierungsarbeit selbst automatisieren.
Das macht die indische IT-Branche nicht notwendigerweise kleiner.
Es bedeutet, dass die stärksten Unternehmen möglicherweise mehr Umsatz aus intellectual leverage und weniger aus labour leverage ableiten müssen.
Der nächste Wettbewerbsvorteil könnte codified delivery intelligence sein
Software-Services-Organisationen besitzen ein enormes Asset, das oft überraschend unstrukturiert bleibt.
Sie haben Jahrzehnte Wissen angesammelt über:
Banking Systems, Telekommunikation, Healthcare, Manufacturing, ERP, Supply Chains, Insurance, Commerce, Operations, Compliance, Workflow Design, Data Structures und Enterprise Integration.
Viel dieses Wissens lebt noch in Menschen, Projektdokumenten, Repositories, PowerPoints und früheren Implementierungen.
Die nächste Chance ist, diese Erfahrung in executable intelligence zu verwandeln.
Patterns.
Schemas.
Contracts.
Reference Architectures.
Workflow Models.
wiederverwendbare Produkt-Systeme.
Testing Frameworks.
domänenspezifische Automatisierung.
Das ist erheblich verteidigungsfähiger, als jedem Developer Zugang zum selben Frontier-KI-Modell zu geben.
Jedes große Services-Unternehmen kann auf Claude zugreifen.
Jedes große Services-Unternehmen kann auf Codex zugreifen.
Jedes große Services-Unternehmen kann auf Gemini zugreifen.
Der Differentiator wird, welches proprietäre System diese Modelle umgibt.
Das ist die tiefere Bedeutung von Zoho Catalyst 3.0
Zoho demonstriert ein wichtiges Prinzip.
Generische KI-Fähigkeit reicht nicht aus.
Um in einer echten Technologieumgebung effektiv zu operieren, braucht das Modell strukturiertes Wissen, explizite Tools, governierte Berechtigungen und maschinenlesbare Interfaces.
Catalyst Agent Skills liefern plattformspezifisches Wissen. MCP exponiert kontrollierte Aktionen. Berechtigungen begrenzen Agent-Verhalten. Audit Trails machen diese Aktionen beobachtbar. (Catalyst)
Mit anderen Worten: Zoho fügt Struktur um die Intelligenz herum hinzu.
Dieses Prinzip reicht weit über Infrastruktur hinaus.
Dasselbe muss mit der Anwendung selbst geschehen.
Produktstruktur sollte maschinenlesbar sein.
Rollen sollten explizit sein.
Beziehungen sollten typisiert sein.
Workflows sollten governiert sein.
UI Rules sollten persistieren.
Änderungen sollten nachverfolgbare Abhängigkeiten haben.
Builds sollten reproduzierbar sein.
Tests sollten systematisch sein.
Architektur sollte nicht jedes Mal neu entdeckt werden müssen, wenn jemand einen weiteren Prompt eingibt.
Das ist die Richtung, die wir mit Blaze verfolgen.
Von Software-Development-Automatisierung zu Software Manufacturing
Das Wort "Manufacturing" war in Software historisch unbequem, weil Software kein repetitives physisches Produkt ist.
Jede Organisation hat unterschiedliche Workflows, User, Data, Policies, Integrationen und operative Realitäten.
Das bleibt wahr.
Aber Customisation bedeutet nicht, dass jede zugrunde liegende Struktur neu erfunden werden muss.
Die meisten Enterprise-Anwendungen enthalten große Mengen wiederholbarer Software Intelligence:
Record Systems, Lists, Grids, Hierarchies, Filters, Dashboards, Workflow States, Approvals, Permissions, Audit Histories, Notifications, Settings, Reports, Forms, Search, Role Management.
Die Chance ist nicht, Custom Software zu eliminieren.
Es geht darum, die wiederholbaren Teile zu industrialisieren und gleichzeitig deterministische Kontrolle über die Teile zu bewahren, die jedes Business anders machen.
Das ist eine viel nützlichere Interpretation von Software-Automatisierung.
Das Gewinnmodell könnte Menschen, deterministische Systeme und KI kombinieren
Es besteht die Versuchung, die Zukunft als Menschen versus KI zu rahmen.
Das ist wahrscheinlich die falsche Abstraktion.
Ein stärkeres Software-Delivery-System kombiniert drei verschiedene Fähigkeiten.
Menschliches Urteilsvermögen bestimmt, was zählt.
Deterministische Software-Systeme governen, was nicht variieren sollte.
KI übernimmt Interpretation und Reasoning, wo Variabilität nützlich ist.
Das Problem mit purem Vibe Coding ist, dass zu viel Verantwortung an die probabilistische Schicht delegiert wird.
Das Problem mit traditioneller Delivery ist, dass zu viel wiederholbare Arbeit weiterhin an Menschen delegiert bleibt.
Die Chance liegt dazwischen.
Menschen für Urteilsvermögen nutzen.
Software für Determinismus nutzen.
KI für Intelligenz nutzen, wo Intelligenz tatsächlich Mehrwert liefert.
Das ist die Architektur der Software-Automatisierung, die unserer Einschätzung nach skalieren kann.
Was passiert mit dem Milliarden-Services-Modell?
Die indische IT-Services-Branche wird nicht verschwinden.
Aber ihr Operating Model kann sich dramatisch ändern.
Der am stärksten exponierte Teil der Branche ist wahrscheinlich Arbeit, die:
hochgradig wiederholbar, spezifikationsgetrieben, arbeitsintensiv, manuell koordiniert und primär durch kosteneffizienten Headcount differenziert ist.
Die stärksten Chancen dürften sich zu Arbeit bewegen, die kombiniert:
Domain Expertise, proprietäre Delivery-Systeme, Platform Engineering, komplexe Integration, Architektur, KI und Automatisierung, Data, Security, Product Ownership und wiederverwendbares Intellectual Property.
Das könnte indische Technologieunternehmen letztlich erheblich wertvoller machen, nicht weniger.
Ein Unternehmen, das doppelt so viel Software-Output mit der Hälfte der Menschen erzeugen kann, hat nicht von Natur aus ein kleineres Business.
Es hat eine fundamental andere Kostenstruktur.
Die Frage ist, ob es weiterhin Stunden verkauft oder lernt, den durch diesen Leverage erzeugten Wert zu verkaufen.
Software-Unternehmen werden zunehmend am System konkurrieren, das die Software baut
In den letzten zwanzig Jahren konkurrierte die Softwareindustrie stark um Engineering-Talent.
Für das nächste Jahrzehnt könnte eine weitere Dimension gleich wichtig werden:
das interne System, durch das dieses Talent Software erstellt.
Zwei Unternehmen können ähnlich fähige Engineers beschäftigen und exakt dasselbe LLM nutzen.
Aber eines kann haben:
ein kanonisches Produktmodell, Tausende codifizierter Patterns, typisierte Contracts, automatisiertes Testing, deterministische Application Assembly, Deployment-Automatisierung, domänenspezifische Intelligence und angesammeltes Build-Wissen.
Das andere stellt Developers einfach einen KI-Coding-Assistenten bereit.
Das sind keine gleichwertigen Fähigkeiten.
Deshalb glauben wir, dass proprietäre Build-Technologie ein wichtiger Wettbewerbsvorteil für Software-Development-Unternehmen werden kann.
Die Frage ist nicht mehr, ob KI Code schreiben kann
Diese Frage ist weitgehend beantwortet.
Die folgenreicheren Fragen sind jetzt:
- Kann Software-Struktur codifiziert werden?
- Kann Application Assembly deterministisch werden?
- Kann Produkt-Intelligence wiederverwendbar werden?
- Können Änderungen ohne architektonischen Drift propagieren?
- Können kleinere Teams zuverlässig viel größere Systeme produzieren?
- Können Software-Unternehmen Output von Headcount entkoppeln?
- Können Jahrzehnte Delivery-Erfahrung in executable Intellectual Property umgewandelt werden?
Zoho Catalyst 3.0 ist ein weiterer Hinweis, dass die Industrie über den Coding-Assistenten hinausgeht.
Bei Volt X glauben wir, dass die nächste Frontier noch weiter geht.
Es geht nicht nur darum, Coding zu automatisieren.
Es geht darum, zunehmend große Teile der Software Assembly selbst zu automatisieren und dabei Product Judgement, Engineering Discipline und Enterprise Controls zu bewahren, die Produktionssoftware erfordert.
Wenn diese Transition anhält, verändert sie mehr als Developer Productivity.
Sie könnte die Ökonomie einer ganzen Branche verändern.
Und für eine so große und wichtige Technology-Services-Wirtschaft wie Indiens macht Software-Assembly-Automatisierung eine Entwicklung, die sehr ernst genommen werden sollte.
Über Blaze
Blaze ist Volt X's proprietäre Software-Creation-Technology zum Erstellen und Erweitern von Enterprise-Anwendungen durch strukturierte Produktdefinitionen, wiederverwendbare Produkt-Intelligence, governierte UX-Patterns und deterministische Engineering-Contracts.
Sie ist darauf ausgelegt, Teams zu helfen, substanzielle Custom Software mit größerer Geschwindigkeit, Konsistenz und Kontrolle zu erstellen — ohne generative KI zur architektonischen Source of Truth zu machen.