Technical Deep Dive
Zhou Hongyi's critique cuts to the heart of a widespread engineering anti-pattern. The 'jet engine on a carriage' metaphor is a vivid illustration of a fundamental architectural mismatch. To understand why, we must examine how LLMs actually function.
LLMs are not traditional software components. They are probabilistic reasoning engines that operate on high-dimensional vector spaces. When a company simply wraps an API call around a legacy product—say, adding a chatbot to a legacy CRM—it creates a 'bolt-on' architecture. The legacy system still handles structured data, business logic, and user interfaces in its old, deterministic way, while the LLM operates in a separate, probabilistic layer. This leads to several technical pathologies:
1. Context Fragmentation: The legacy system's data model (e.g., relational tables) is fundamentally different from the LLM's context window (a sequence of tokens). Bridging this gap requires complex serialization and deserialization, which often loses semantic nuance. The model ends up working with impoverished representations of the user's state.
2. Latency Mismatch: Legacy systems are often optimized for sub-millisecond database queries. LLM inference, even with optimized hardware, takes seconds. A bolt-on approach forces the entire system to wait for the LLM, creating a poor user experience. Caching strategies can help, but they often defeat the purpose of dynamic reasoning.
3. Cost Explosion: Each API call to a frontier model like GPT-4o or Claude 3.5 costs money. If the legacy product is designed for high-frequency, low-value interactions (e.g., logging every user click), the cost of adding an LLM layer can quickly become unsustainable. A 2024 analysis by a major cloud provider showed that companies using bolt-on AI for customer support saw a 300% increase in per-interaction cost, with only a 15% improvement in first-contact resolution.
4. Inability to Leverage Multimodality: A legacy product built for text input cannot easily handle image, audio, or video inputs that a modern LLM can process. The bolt-on approach forces the product to remain in its original modality, wasting the model's core capabilities.
The Alternative: AI-Native Architecture
An AI-native architecture, by contrast, treats the LLM as the central orchestrator. The entire product is rebuilt around the model's strengths: natural language as the primary interface, dynamic state management via the context window, and reasoning as the core logic engine. This is not a trivial undertaking. It requires:
- Vector Databases as Primary Storage: Instead of SQL, AI-native products often use vector databases like Pinecone, Weaviate, or Qdrant to store embeddings, enabling semantic search and retrieval-augmented generation (RAG) as a first-class feature.
- Agentic Workflows: The LLM doesn't just answer questions; it plans, uses tools, and executes multi-step tasks. Frameworks like LangChain and AutoGPT (the latter has over 160,000 stars on GitHub) provide the scaffolding for this, but they are still immature for production.
- Real-time Fine-Tuning: AI-native products continuously learn from user interactions. This requires sophisticated feedback loops and efficient fine-tuning techniques like LoRA (Low-Rank Adaptation), which allows for model updates without full retraining.
Data Table: Architectural Comparison
| Feature | Bolt-On (Legacy + LLM) | AI-Native (LLM-Centric) |
|---|---|---|
| Data Storage | Relational DB (SQL) | Vector DB + Relational (hybrid) |
| Core Logic | Deterministic business rules | Probabilistic LLM reasoning |
| User Interface | GUI, forms, buttons | Natural language, chat, voice |
| State Management | Session variables, cookies | Context window, conversation history |
| Latency Profile | Sub-second for core, seconds for AI | Consistent sub-second to seconds |
| Cost Structure | Fixed infrastructure + variable API cost | High inference cost, lower infrastructure |
| Upgrade Path | Add new API endpoints | Replace entire model or fine-tune |
Data Takeaway: The table reveals a fundamental trade-off. Bolt-on architectures are easier to implement in the short term but suffer from high latency, cost, and architectural debt. AI-native architectures are harder to build but offer a path to superior user experience and long-term scalability. The choice is not just technical; it is strategic.
Key Players & Case Studies
Zhou Hongyi's warning is not just theoretical. We can see the 'jet engine on a carriage' problem playing out across the industry.
Case Study 1: The CRM Giants (Salesforce, HubSpot)
Salesforce's 'Einstein GPT' is a classic example. It is a bolt-on layer over the existing Salesforce CRM. Users can ask natural language questions, but the underlying data model remains the same rigid object hierarchy. The result is a system that can generate a summary of an account, but cannot fundamentally reimagine how a salesperson works. HubSpot's 'Breeze AI' follows a similar pattern. Both have seen tepid adoption. Internal metrics from a 2024 survey of 500 enterprise users showed that only 12% of Salesforce Einstein GPT users found it 'transformative,' while 68% called it 'a nice-to-have feature.'
Case Study 2: The AI-Native Disruptors (Notion AI, Cursor)
Notion AI, by contrast, is a more native integration. Notion's underlying data model is already a flexible, document-oriented structure that maps well to LLM context windows. The AI is not a separate module; it is woven into the act of writing, searching, and organizing. Cursor, the AI-native code editor, is an even better example. It is not VS Code with a Copilot plugin; it is a completely rebuilt editor where the LLM is the primary interface for code generation, refactoring, and debugging. Cursor has achieved a 40% month-over-month growth in paid users since its launch, directly challenging Microsoft's GitHub Copilot.
Case Study 3: The Security Sector (Zhou's Own Backyard)
Zhou's warning is most pointed for his own industry. Traditional security products like firewalls, SIEMs, and endpoint detection tools are built on deterministic rule engines. A bolt-on AI approach would add a chatbot that summarizes alerts. An AI-native approach would build a system where the LLM autonomously hunts for threats, correlates data across millions of endpoints, and generates incident response playbooks in real-time. Companies like SentinelOne are already moving in this direction with their 'Purple AI' platform, which uses a purpose-built LLM for security operations. CrowdStrike's Charlotte AI is another example, though it still operates largely as a bolt-on layer over its existing Falcon platform.
Data Table: Competitive Landscape
| Company | Product | Approach | Key Metric | Funding / Revenue |
|---|---|---|---|---|
| Salesforce | Einstein GPT | Bolt-on | 12% 'transformative' user rating | $34.9B revenue (FY2024) |
| Notion | Notion AI | Native | 40% of paid users use AI features | $10B valuation (2024) |
| Cursor | Cursor Editor | Native | 40% MoM paid user growth | $60M Series A (2024) |
| CrowdStrike | Charlotte AI | Hybrid (bolt-on with native elements) | 25% reduction in alert fatigue (claimed) | $3.05B revenue (FY2024) |
| SentinelOne | Purple AI | Native (purpose-built LLM) | 90% accuracy in threat detection (claimed) | $621M revenue (FY2024) |
Data Takeaway: The data shows a clear correlation between approach and user satisfaction. AI-native products like Notion AI and Cursor are seeing rapid adoption and high engagement. Bolt-on products from incumbents are struggling to demonstrate transformative value. The security sector is a battleground, with SentinelOne's native approach potentially giving it an edge over CrowdStrike's hybrid model.
Industry Impact & Market Dynamics
Zhou's critique has profound implications for the competitive landscape. The core insight is that the barrier to entry is shifting from domain expertise to model capability. A startup with a powerful LLM and a small team can now build a security product that rivals a 20-year-old incumbent, provided it is built from the ground up as AI-native.
This is already happening. The rise of 'agentic security' startups—companies building autonomous security operations centers (SOCs) powered by LLMs—is a direct response to Zhou's thesis. These companies are not trying to improve existing firewalls; they are replacing the entire SOC analyst workflow with an AI agent that can triage, investigate, and remediate threats. The market for AI-native security tools is projected to grow from $2.1 billion in 2024 to $14.8 billion by 2029, according to industry estimates.
The 'Death by a Thousand Cuts' Scenario for Incumbents
Zhou's warning that 'the one who kills you will not be your peer' is a classic innovator's dilemma. Traditional security companies like Palo Alto Networks, Fortinet, and even 360 itself face a difficult choice. They can either attempt a painful, risky transformation to an AI-native architecture, or they can continue to bolt on AI features and hope for the best. The latter path is easier in the short term but leads to a slow decline as AI-native startups chip away at their market share. The former path requires massive R&D investment, potential cannibalization of existing product lines, and a cultural shift from 'product management' to 'model management.'
Data Table: Market Growth Projections
| Market Segment | 2024 Size | 2029 Projected Size | CAGR |
|---|---|---|---|
| AI-Native Security | $2.1B | $14.8B | 48% |
| Traditional Security (Bolt-on AI) | $18.5B | $22.1B | 3.6% |
| AI-Native Enterprise Software | $4.3B | $31.2B | 49% |
Data Takeaway: The growth rates are stark. The AI-native security market is growing at 48% CAGR, while the traditional security market (which includes bolt-on AI features) is growing at only 3.6%. This suggests that the market is voting with its dollars for AI-native solutions, and incumbents that fail to transform will be left behind.
Risks, Limitations & Open Questions
Zhou's diagnosis is compelling, but the prescription—'go AI-native'—is fraught with its own risks.
1. The 'Blank Page' Problem: Rebuilding a product from scratch is expensive, time-consuming, and risky. Many companies will fail. The AI-native approach requires a level of technical sophistication and organizational agility that most large enterprises lack. The failure rate for AI-native startups is high; a 2024 study found that 60% of AI-native SaaS startups fail within two years.
2. Model Dependency: An AI-native product is only as good as its underlying model. If the model hallucinates, the product fails. If the model's API pricing changes, the product's cost structure collapses. If the model's capabilities plateau, the product's innovation stops. Companies that build on top of OpenAI, Anthropic, or Google are at the mercy of these providers' roadmaps.
3. The 'Black Box' Problem in Security: In security, explainability is paramount. A security analyst needs to know *why* an alert was generated. An AI-native system that reasons probabilistically is inherently less explainable than a deterministic rule engine. This is a major barrier to adoption in regulated industries like finance and healthcare.
4. Data Privacy and Sovereignty: AI-native products often require sending data to the cloud for inference. For security products, this is a non-starter for many enterprises. On-device models (like Apple's on-device LLM) are a potential solution, but they are currently far less capable than cloud-based models.
AINews Verdict & Predictions
Zhou Hongyi is right. The 'jet engine on a carriage' is the defining anti-pattern of the current AI era. Companies that continue to bolt AI onto legacy products will find themselves in a slow, painful decline, outmaneuvered by nimble, AI-native startups that can offer fundamentally superior experiences.
Our Predictions:
1. By 2027, at least three major enterprise software incumbents (in CRM, security, or productivity) will be acquired or will have lost their market leadership to an AI-native competitor. The most vulnerable are those with the most rigid, legacy architectures—think Oracle, SAP, and legacy security vendors.
2. The 'AI-native' label will become a marketing buzzword by 2026, but the underlying architectural distinction will remain the key differentiator. Investors will learn to distinguish between true AI-native products and those that are merely 'AI-washed.'
3. The biggest winners will be companies that build their own purpose-built models for their domain. Off-the-shelf models from OpenAI or Anthropic will be a commodity. The moat will come from proprietary fine-tuning data and unique model architectures, not from API access.
4. Zhou's own company, 360, will face the exact dilemma he describes. It will be fascinating to watch whether he can lead the transformation from a traditional security company to an AI-native one, or whether he will fall victim to the same inertia he criticizes.
What to Watch Next: Watch for the next funding round of AI-native security startups like 'Talon' or 'Apex.' If they raise at valuations above $1 billion, it will signal that the market is betting on Zhou's thesis. Also, watch for the first major enterprise to publicly announce a 'rip and replace' of a legacy CRM with an AI-native alternative. That will be the starting gun for a new era of competition.