Your CLI Agent Is Your New Sysadmin

 

Why struggle through all this nonsense of command line errors, debugging package dependencies when you can command the power of a thousand suns and the sum total of human knowledge and say: "Get this working."

The Terminal Has Always Been Powerful (And Intimidating)

The command line is where real work gets done. Installing packages, managing dependencies, compiling code, debugging cryptic errors, setting up development environments—it's all terminal work. And it's always been a gauntlet for newcomers.

Take Python dependency management. We've had venv, then conda, and lately uv has taken the Python world by storm. Each tool is powerful. Each one is a puzzle to use if you're new. Version conflicts, environment mismatches, system-wide installations clashing with project-specific needs—it's a mess that's always required you to understand virtual environments, package registries, version resolution, and system paths.

And when something breaks? You're diving into Stack Overflow for your third search of the afternoon, parsing error messages, trying solutions, hitting new errors, searching again.

Let The Agent Operate Your Terminal

My son was setting up a CUDA development environment recently. Tutorials, code snippets, the usual learning process. At some point, he installed PyTorch—the CPU-only build from pip, not the CUDA-enabled version he needed. When he ran his script, it threw an error about CUDA.

The old approach: Google the error. Read Stack Overflow threads. Figure out you need the CUDA build. Uninstall the wrong version. Find the right installation command with proper CUDA toolkit flags. Reinstall. Hope you got it right. Try again.

What he actually did: pasted the error into his CLI coding agent and said "fix this." The agent uninstalled the CPU version, installed the CUDA build, and executed the script successfully.

He didn't touch his terminal. The agent operated it for him.

This Is The Pattern

CLI agents like Claude Code, Gemini CLI, and Qwen Code don't just write code - they run your terminal. They execute commands, see errors in real-time, fix what's broken, and iterate until it works.

Consider a usual scenario: version conflict. Your script needs an older version of a package, but you have the latest installed. You get an AttributeError because a method was deprecated.

Traditional flow: search the error, identify the version issue, check what you have installed, downgrade the package, update your requirements file, rerun.

With a CLI agent: paste the error. Watch it handle everything automatically.

Or compilation errors. Or missing system dependencies. Or path issues. Or permission problems. Whatever breaks in your terminal, the agent can see it, understand it, and fix it.

The Real Shift

Here's what makes this transformative: the agent isn't advising you on terminal commands. It's executing them.

You're not asking "how do I fix this?" You're saying "make this work" and delegating the entire workflow. The agent becomes your command-line operator—running commands, reading output, fixing problems, trying again.

It handles the execution loop: run → fail → read error → fix → run again. The same loop you'd do manually, but without the frustration, without the fatigue, without needing to understand every underlying system.

This isn't about replacing your knowledge. It's about removing friction from getting things done.

This isn't magic. The agent needs to see error messages to fix them, which means it needs to execute your code and commands. But that's the entire point. You give it access to operate your terminal, and it handles the tedious housekeeping—the dependency installations, the environment setup, the error-fix-retry cycles.

The agent reads the same error messages you would. It's just doing it at the speed of thought, with pattern-matching across thousands of similar cases, and without getting frustrated on the third failed attempt.

What This Means

The command line was always where real work happened. But it required you to be fluent in bash, understand package managers, know how to debug system errors, and have the patience to iterate through solutions.

Now? You need to know how to tell an agent what you want to accomplish.

The traditional tools and knowledge are still valuable and worth learning. But for everyday work—installing packages, fixing dependencies, setting up environments, handling the endless housekeeping of development—let the agent operate your terminal. It's better at it than most of us, and it never gets tired of circular dependencies.

First-time setup? You still need to install the CLI agent itself. But theoretically, it could handle everything else from there—even installing Python, setting up your entire development environment, whatever your system needs.

Stop fighting with cryptic error messages. Stop Googling for the right terminal commands. Just say: "Get this working."

And let your agent handle the terminal.

Self-Learning CLI Agents: A Practical Guide

 

Building Systems That Get Smarter Every Day

Introduction

After months of building and refining self-learning systems with CLI agents, I've discovered something that is quite obvious in retrospect: the secret to continuously improving AI assistance isn't in the model itself—it's in the knowledge capture infrastructure surrounding it.

Recent research quantifies what practitioners have been discovering: systems that accumulate and refine their own contextual knowledge can outperform traditional approaches by 10.6% on agent tasks and 8.6% on domain-specific reasoning, while reducing adaptation costs by up to 87%.

Since, I've been using this for a while, I though a a practical guide to building your own self-learning development system is in order. 

I've experimented with this approach in multiple domains, including AMP for email development and writing TradingView PineScript code, which is published at https://github.com/NakliTechie/PineScriptCoder.

Both are relatively obscure in the overall scheme of things. 

The system's adaptability across different development contexts demonstrates its versatility and value regardless of the specific technology or domain you're working with.

---

Why You Need This

The Problem You're Living With

Without systematic knowledge capture, you're experiencing:

• Repeated Mistakes: Solving the same problems across projects because insights weren't preserved
• Knowledge Loss: Valuable lessons disappear when team members move on or memories fade
• No Measurable Progress: Can't tell if your processes are actually improving
• Inconsistent Quality: Good patterns discovered but never systematically applied

The tragedy isn't making mistakes—it's making the same mistakes repeatedly because you have no institutional memory.

The Solution: Memory as Infrastructure

A self-learning system addresses these through three mechanisms:

1. Systematic Capture: Every significant learning is documented in a structured format
2. Organized Storage: Insights filed logically for easy retrieval
3. Active Utilization: Learnings automatically feed back into development workflows

This creates a compounding effect: better context → better performance → better learnings → better context.

The key insight from research: LLMs don't need brevity—they need comprehensive, detailed contexts. Unlike humans who benefit from concise summaries, language models perform better with long, detailed contexts and can autonomously extract relevant information.

---

The Research Foundation (In Plain English)

ACE Framework: Contexts as Evolving Playbooks

Stanford and SambaNova research introduced Agentic Context Engineering (ACE), which treats contexts not as static prompts but as "evolving playbooks" that accumulate and organize strategies over time.

Two problems ACE solves:

1. Brevity Bias: Traditional optimizers create concise, universal instructions while sacrificing domain-specific knowledge—the details that make systems work in production.

2. Context Collapse: Iterative rewriting degrades contexts into shorter, more ambiguous summaries over time, causing sharp performance declines.

ACE's solution: Structured, incremental updates that preserve detailed knowledge. Think of it like version control for context—you add and refine, you don't rewrite from scratch.

Training-Free GRPO: Learning Without Training

Tencent's research showed you can improve agent performance without any parameter updates—just by accumulating experiential knowledge as context.

With just a few dozen training samples, their approach outperformed fine-tuned models while avoiding overfitting and data scarcity issues.

The Implication

You don't need to fine-tune models. You don't need massive datasets. You need better memory management.

---

Implementation: Let Your Agent Build It

Here's the liberating truth: you don't need to manually create this infrastructure. Your CLI coding agent can build the entire learning system from broad guidelines.

This is meta-prompting in action—instead of manually writing templates and structures, you collaborate with your agent to design and implement the system itself.

Step 1: Bootstrap the System

Give your coding agent these requirements:

Create a comprehensive learning capture system for our development projects:

1. A directory structure separating different types of learnings
2. Templates that capture problems, solutions, and prevention strategies  
3. A consolidated quick-reference file for frequently-used knowledge
4. Integration with our development workflow
5. Clear documentation on usage

Make it practical, not bureaucratic. The system should make capturing 
knowledge easier, not harder.

Let the agent propose and implement. It will often produce something more comprehensive than you'd write manually.

Step 2: What the Agent Creates

Your agent will typically build:

/project/learning/
├── README.md                          # System overview
├── LESSONS_LEARNED_TEMPLATE.md        # Capture template
├── common_learnings.md                # Quick reference (KEY FILE)
└── categorized_learnings/
    ├── technical/                     # Technical solutions
    ├── process/                       # Workflow improvements
    ├── project_specific/              # Project insights
    └── framework_updates/             # System-wide changes

Critical component: The common_learnings.md file is your system's working memory. This is what the agent references during active development—not the detailed categorized files.

Step 3: The Capture Template

Your agent will design templates that capture:

For Technical Learnings:

• Problem description and context
• Root cause analysis
• Solution (with before/after code)
• Prevention strategies
• Integration recommendations

For Process Improvements:

• Current process description
• Issues identified
• Improved approach
• Implementation guide
• Measurable benefits

The template ensures completeness—when you capture knowledge, you capture it actionably.

Step 4: Agent Integration

Add this to your agent's system prompt:

## Learning Capture Protocol

After every significant development session:

1. IDENTIFY learnings worthy of capture
   - Non-trivial technical solutions
   - Process improvements discovered
   - Patterns benefiting future projects
   - Mistakes with clear prevention strategies

2. CATEGORIZE appropriately
   - Technical / Process / Project-specific / Framework

3. UPDATE common_learnings.md
   - Add broadly applicable insights
   - Ensure immediate accessibility
   - Maintain organized structure

4. FILE detailed learning
   - Use complete template
   - Store in appropriate category
   - Cross-reference with common learnings

5. IDENTIFY documentation updates
   - Mark guides/checklists needing revision
   - Create action items
   - Prioritize by impact

Learning capture is NOT optional—it's core workflow.

Step 5: Active Utilization

Ensure your agent uses what it learns:

## Using the Learning System

During development:
1. CONSULT common_learnings.md at task start
2. APPLY relevant patterns from past experience
3. DOCUMENT new patterns discovered during work
4. UPDATE common learnings with applicable insights
5. FILE detailed learnings in categories

When solving problems:
- Reference past solutions before implementing from scratch
- Apply prevention strategies from similar issues
- Build on established patterns
- Note when patterns don't apply (document edge cases)

The self-reinforcing cycle: Execution → Learning → Documentation → Context → Better Execution

---

Real-World Results: What Actually Happens

After a few iterations of living with this system:

Quantifiable Improvements

• Reduced problem-solving time: Similar issues reference existing solutions
• Fewer repeated mistakes: Prevention strategies actually prevent
• Faster onboarding: New team members leverage accumulated knowledge immediately
• Measurable consistency: Best practices applied consistently

Qualitative Changes

• Compound learning: Each project makes future projects easier
• Knowledge democratization: Expertise becomes accessible to entire team
• Confidence in complexity: Willing to tackle harder problems
• Reduced cognitive load: System remembers, you don't have to

The Surprise Benefit: Cross-Project Intelligence

Insights from one project automatically benefit unrelated projects. A performance optimization from web work improves database tasks. Validation techniques from forms apply to APIs.

This happens because common_learnings.md creates unified context. The system sees patterns across domains that individuals might miss.

---

The Evolution: From Basic to Optimized

Initial State

Start simple:

• Basic directory structure
• Simple template (problem/solution/lesson)
• Manual capture after sessions
• Agent references common learnings

Intermediate State

Refinements emerge:

• Template complexity adjusted based on actual use
• Common learnings reorganized by access frequency
• Agent begins suggesting capture automatically
• Cross-references between learnings appear

Mature State

The system optimizes itself:

• Agent maintains optimal organization
• Redundant learnings merged automatically
• Common learnings updated in real-time
• Prevention strategies actively applied

Key insight: My initial categorization worked, but lacked optimization for access. The common_learnings.md innovation came from observing usage patterns—I needed instant access during development, not perfect categorization.

This evolution happens naturally as you use the system. You don't need to plan for it—just start with the basics and let actual usage drive improvements.

---

Common Pitfalls and Solutions

Pitfall 1: Template Overload

Problem: Templates too complex, leading to inconsistent usage.

Solution: Start with problem/solution/lesson. Add complexity gradually based on actual needs.

Pitfall 2: Scattered Information

Problem: Perfect categorization that makes nothing findable during work.

Solution: The common_learnings.md file. Accept redundancy—information in both quick reference and detailed files is a feature, not a bug.

Pitfall 3: Inconsistent Application

Problem: Great system used occasionally.

Solution: Make it automatic via system prompt. Have agent remind you. Make skipping require conscious choice.

Pitfall 4: Write-Only Documentation

Problem: Learnings captured but never referenced.

Solution: System prompt must actively consult learnings during work. If the agent isn't referencing past knowledge, you're just documenting, not learning.

Pitfall 5: Brevity Bias

Problem: Keeping learnings concise, losing useful detail.

Solution: Remember the research insight: comprehensiveness beats conciseness for AI systems. Preserve details. Let the AI extract relevance.

---

Getting Started: Your Implementation Path

Phase 1: Co-Design with Your Agent

Describe your vision

• Tell your coding agent what you want
• Discuss your workflow and constraints
• Review agent's architectural proposal

Let agent implement

• Agent builds the infrastructure
• Review generated templates and structure
• Suggest refinements if needed

Manual testing

• Capture 2-3 learnings yourself
• Validate template completeness
• Ensure organization makes sense

Time investment: ~1 hour for initial setup

Phase 2: Agent-Driven Capture

Add capture instructions

• Update agent's system prompt
• Define capture criteria clearly
• Set expectations for when/what to document

Observe behavior

• Does agent identify learnings appropriately?
• Are captured learnings specific and actionable?
• Is categorization logical?

Refinement

• Adjust capture criteria based on observations
• Simplify or expand template as needed
• Begin building initial knowledge base

Time investment: ~30 minutes for setup, then observe over several sessions

Phase 3: Active Utilization

Add consultation instructions

• Update system prompt for active reference
• Ensure common_learnings.md in context
• Define when agent should consult learnings

Monitor reference behavior

• Does agent check common learnings?
• Are past solutions being reused?
• Is the feedback loop working?

Measure improvement

• Track time to solve similar problems
• Note reduction in repeated mistakes
• Document instances of knowledge reuse

Time investment: ~20 minutes for setup, benefits accrue automatically

Phase 4: Optimization

Analysis

• Ask agent to review what worked
• Identify template complexity issues
• Find access pattern inefficiencies

Reorganization

• Adjust common learnings organization
• Merge redundant entries
• Improve categorization

Metrics and sharing

• Establish baseline metrics
• Document the system's value
• Share approach with team

Time investment: ~1 hour for optimization, then ongoing maintenance is minimal

Phase 5: Autonomous Evolution

Let the agent maintain and optimize:

• Agent adjusts organization based on usage
• Automatic quality checks for captured knowledge
• Cross-project knowledge synthesis
• Team-level scaling if needed

The system improves itself from this point forward

Key principle: Start with agent collaboration, not manual work. The agent that uses the system should also build and maintain it. Total setup time is 2-3 hours; the benefits compound indefinitely.

---

Measuring Success

Track these metrics:

Efficiency Metrics

• Time to resolve similar issues: Should decrease as solutions accumulate
• Repeated mistake frequency: Should approach zero for captured lessons
• Onboarding time: Should decrease as knowledge base grows
• Reference rate: Should increase as quality improves

Quality Metrics

• Best practice consistency: Measured through reviews
• Knowledge application rate: % of captured learnings actually used
• Cross-project benefit: Insights from one project applied elsewhere
• Prevention effectiveness: Issues avoided due to strategies

System Health Metrics

• Learnings per project: Should be consistent
• Common learnings reference frequency: Should be high during work
• Categorization accuracy: Learnings filed where findable
• Documentation freshness: Regular updates indicate active use

Critical metric: Time to first reference. If you can find relevant past knowledge in under 30 seconds, your system works. If it takes minutes, your organization needs work.

---

The Future: Where This Goes

Three converging trends:

1. Context windows are exploding: 4K → 32K → 128K → 1M+ tokens
2. Models handle long contexts better: Can actually use those million tokens effectively
3. Context engineering is formalizing: Frameworks like ACE codify best practices

Implication: In 12 months, self-learning systems won't be advanced—they'll be standard. The competitive advantage belongs to teams mastering knowledge capture now.

What's Coming

• Automated reflection: AI analyzing traces and suggesting learnings automatically
• Cross-team synthesis: Learning systems sharing insights across organizational boundaries
• Semantic knowledge graphs: Moving beyond flat files to relationship-based storage
• Real-time adaptation: Systems updating based on immediate execution feedback
• Failure prediction: Warning about likely problems based on accumulated experience

---

Conclusion: Memory as Competitive Advantage

The research validates what practice confirms: comprehensive, evolving contexts outperform traditional approaches while reducing costs.

But the deeper insight: This isn't about AI—it's about building institutional memory that compounds over time.

Your development environment should get smarter every time you use it. Your tools should accumulate wisdom. Your AI assistants should improve not because models update, but because context evolves.

Each problem solved becomes future capability.

This is the future of development: not smarter AI, but AI with better memory.

The question isn't whether you'll build a self-learning system. The question is whether you'll build it before your competitors do.

---

Most important: Start imperfectly today. A simple system used consistently beats a sophisticated system used sporadically. The entire setup takes 2-3 hours, and the system improves itself from there.

---

Resources and References

Research Papers

• Agentic Context Engineering: arxiv.org/abs/2510.04618
• Training-Free GRPO: arxiv.org/abs/2510.08191

Related Reading

• Meta-Prompting: Why AI Should Write Your System Prompts

Meta-Prompting: Why AI Should Write Your System Prompts

I was wrestling with creating a series of seven engagement emails for a client—carefully crafted messages that demonstrated a new concept in email marketing. Each email needed specific components: client positioning, footer elements, engagement currency, and brand alignment. After hours of iteration, I finally had a complete seven-email series that worked.

But then I faced the real challenge: how could I replicate this entire sequence for other clients efficiently? More importantly, how could I enable other team members to create these sophisticated email sequences without going through the same lengthy development process?

Instead of trying to write a system prompt myself, I asked Gemini in AI Studio to help me create one. Through our collaborative conversation, we developed an interactive agent that was far more sophisticated than anything I could have written manually. The resulting system prompt was extraordinarily detailed—it included exact conversation flows, technical HTML specifications, state management across multiple phases, and even code commenting conventions. It created a two-phase system: first, a structured interview process that gathered requirements one question at a time, then a generation protocol that produced complete, production-ready HTML emails with AMP compatibility and fallbacks. 

As you can see in the attached image, AI written prompts are far more detailed and specific. 

I tested this AI-generated interactive agent across multiple clients and shared it with colleagues. It worked flawlessly, producing complete seven-email sequences that maintained consistency and quality. More importantly, it democratized the capability—anyone could now create sophisticated email campaigns without mastering email marketing strategy or spending hours on development.

This experience revealed something profound: we've been approaching AI prompt engineering backwards. While countless guides teach humans to craft better prompts, we're missing a fundamental insight—AI is often better at writing prompts for itself than we are. This collaborative approach democratizes capability, turning complex expertise into accessible tools.

Beyond Traditional Meta-Prompting

Meta-prompting isn't new. OpenAI's cookbook demonstrates using higher-intelligence models to optimize prompts, focusing on systematic refinement and evaluation metrics. Commercial tools like PromptPerfect automate prompt improvements for better clarity and performance.

But these approaches typically involve AI refining existing prompts. What we're describing is different: collaborative meta-prompting—where human insight and AI precision work together from problem discovery to system prompt creation. Rather than improving prompts we've already written, this approach starts with AI helping us understand what we actually need.

The Human-AI Partnership

This leverages what each does best. Humans excel at understanding context, articulating goals, and navigating real-world ambiguity. AI excels at precision, systematic thinking, and understanding its own operational patterns—including technical requirements, state management, conversation flows, and the granular details that make systems actually work in production.

The Process

1. Start with the Problem, Not the Prompt Describe what you're trying to accomplish in natural language. Don't worry about prompt structure—just explain the goal, context, and constraints.

2. Explore Through Dialogue Let the AI probe deeper: "What edge cases should we consider?" "How should we handle ambiguous inputs?" This conversation reveals the true complexity and requirements.

3. Define Success Criteria Be specific about what constitutes success. Include examples of good and bad outcomes.

4. Request the System Prompt Once you've thoroughly explored the problem space, ask: "Based on our discussion, can you write a comprehensive system prompt for this task?" The AI will produce something remarkably detailed—my email campaign prompt was over 1,000 words and included precise conversation flows, technical HTML specifications, state management protocols, and even code commenting conventions. No human would naturally think to include such granular operational details.

5. Test and Iterate Try the generated prompt on real examples. Discuss gaps with the AI and refine iteratively.

The Compound Effect

Each meta-prompting session builds your library of robust, battle-tested system prompts that democratize capability across your organization. What once required deep domain expertise can now be accessed by anyone on your team.

The AI learns your working style and requirements, making future sessions more efficient and creating an ever-improving cycle of capability democratization.

A Quick Example

Instead of wrestling with a prompt for "analyze customer feedback," you might have this conversation:

You: I need help analyzing customer feedback emails to identify patterns and prioritize responses.

AI: What types of patterns are most valuable? Sentiment, feature requests, bug reports?

You: All of those, plus I need to identify urgent emails versus those that can wait.

AI: What criteria determine urgency? Customer tier, severity of issues, or other factors?

Through this dialogue, you jointly discover the nuanced requirements. Then ask: "Based on our discussion, can you write a comprehensive system prompt for this task?" The AI will produce something more thorough and precise than most humans would write—complete with decision trees, formatting specifications, and error handling.

The Future of Prompt Engineering

This collaborative meta-prompting approach represents a fundamental shift from manual prompt crafting to capability democratization. It's not about replacing human judgment, but optimizing the division of labor between human insight and AI precision—then making that optimized process accessible to everyone.

The most effective AI implementations won't be built by humans wrestling with perfect prompts, but by human-AI teams that leverage each other's strengths throughout the design process, creating tools that democratize complex capabilities across organizations.

The question isn't whether you can write good prompts—it's whether you should be writing them at all, and whether you're sharing that capability with others who need it.

The Addiction Economy: When Vibe Coding Becomes a Gateway Drug

We may be on the verge of witnessing a new kind of addiction—one that could be economically productive but psychologically transformative in ways we can barely imagine. AI-assisted coding could exhibit classic addiction patterns, complete with gateway behaviors, tolerance building, and compulsive use. But unlike traditional addictions, this one might create value while potentially rewiring how we think about work, creativity, and human purpose.

Science fiction has long explored similar phenomena: Gibson's cyberspace cowboys in Neuromancer who became so addicted to jacking into the matrix that physical reality felt pale and meaningless. Or consider the Guild navigators from Frank Herbert's Dune, who neeeded spice to navigate the stars. AI-assisted developers might become similar—able to navigate complex digital possibilities through their AI tools but increasingly dependent on that augmentation to perform at all.

The Gateway Drug Phenomenon

The progression could follow textbook addiction patterns with concerning precision. It might start innocuously enough: someone discovers they can build a working application in thirty minutes using AI assistance. The initial hit could be intoxicating—years of learning compressed into a brief interaction, complex problems dissolving into simple prompts.

But like any powerful drug, tolerance could build quickly. Simple CRUD applications might no longer satisfy. Users could escalate to machine learning systems, then distributed architectures, then complex financial trading platforms with real-time data feeds and sophisticated algorithmic implementations. The bar might keep rising, and the time investment could keep growing.

The loss of control could become evident in familiar patterns: "I'll just quickly prototype this idea" might transform into eight-hour coding marathons. Users could lose track of time, skip meals, and find themselves iterating through increasingly complex variations of projects that started as simple experiments. The feedback loop between human creativity and AI capability might create a dopamine-driven cycle that becomes remarkably difficult to break.

Early signs of this pattern are already emerging on social media. Daily posts on platforms like Twitter reveal users expressing almost manic excitement about getting up to code with AI assistance. Some describe structuring their sleep cycles around Claude's usage timeouts, or feeling genuinely distressed when they hit API rate limits. The language mirrors classic addiction narratives: the anticipation, the scheduling of life around the activity, the emotional dependence on access to the tool.

My own journey illustrates this progression. It started innocuously—copying and pasting from AI chat interfaces like Claude and AI Studio, running experiments on Google Colab, saving snippets to Python files, iterating on PineScript indicators. The workflow was clunky but the results were intoxicating. Then I discovered Qwen-Code, a command line client that operates directly on local files. I was immediately hooked.

The hook wasn't just the functionality—it was liberation from "quota hell." Qwen-Code offered 2000 requests daily, freeing me from constantly watching usage meters, a familiar anxiety for anyone from the third-world. Suddenly I could experiment without the psychological friction of counting tokens or rationing interactions.

The result? I now spend 4-6 hours daily in what Andrej Karpathy termed "vibe coding"—essentially every free waking moment. It's always "just one more feature, one more minor adjustment." The addiction is real and it's powerful. It's the intoxication of creation itself—that god-like feeling of manifesting ideas into working reality through conversation with an AI system.

This echoes the behavior patterns Neal Stephenson described in Snow Crash's Metaverse addicts, where the virtual world became more compelling than physical reality. But coding addiction might prove more insidious because, unlike pure escapism, it creates tangible value—making the addiction easier to justify and harder to recognize.

Redefining Addiction: Narrowing vs. Broadening

Traditional addiction models focus on harm and dysfunction, but AI coding could challenge this framework. Perhaps we'll need to think about addiction differently—not as inherently pathological, but as the direction of pleasure-seeking behavior.

Addiction as Narrowing: In this pattern, people might become obsessed with the specific dopamine hit of watching AI generate working code. They could lose interest in other activities—reading, sports, social interaction—as everything else pales compared to the instant gratification of digital creation. Real-world problem-solving skills might atrophy as every challenge becomes "just prompt it." The world could become smaller, filtered through the lens of what can be coded.

This mirrors the fate of Shadowrun's deckers, who spent so much time in the Matrix that they lost connection to their physical bodies and the material world. The digital realm became not just preferable, but the only reality that felt authentic and engaging.

Addiction as Broadening: But there could be an alternative trajectory. AI coding might enable exploration of multiple domains simultaneously, breaking down barriers between fields. Someone interested in marine biology could build oceanographic simulation tools, then pivot to creating educational games about ecosystems, then develop data analysis platforms for environmental research. The addiction might become about expanding capability and knowledge rather than compulsively repeating the same patterns.

The difference would lie not in the intensity of engagement, but in whether that engagement opens new possibilities or closes them off.

Two Economic Futures, Two Addiction Models

The economics of AI inference will likely fundamentally shape how this addiction manifests, potentially creating two radically different scenarios for society.

Scenario 1: Near-Zero Inference Costs

When AI runs locally and compute becomes essentially free, we could enter uncharted psychological territory. Unlimited experimentation might enable incredibly productive addiction patterns—like having an infinite supply of art materials or an unlimited workshop where every tool is immediately available.

In this world, people might spend entire days in flow states, building and iterating on increasingly sophisticated systems. The creative output could be extraordinary: hyper-personalized applications, artistic coding projects, and experimental technologies that would never justify commercial development. We might see the emergence of "coding artists" who could treat AI-assisted development as a medium for expression rather than merely a tool for utility.

But the risks could be profound. Complete detachment from physical reality might become possible when digital creation offers unlimited dopamine rewards. Society could bifurcate into "builders"—people addicted to creating digital experiences—and "consumers" who exist primarily to use what the builders create. This recalls the OASIS addiction depicted in Ready Player One, where the virtual world became so compelling that the physical world was essentially abandoned.

Social skills, physical health, and real-world problem-solving could atrophy as the virtual world becomes infinitely more rewarding than the physical one.

Scenario 2: Expensive Inference Costs (A Temporary Phenomenon)

If AI inference remains expensive in the near term—whether due to energy costs, compute scarcity, or deliberate pricing—we might temporarily enter a different kind of addiction economy. However, the history of computing suggests this would likely be a transitional phase rather than a permanent state. Computing costs have consistently trended downward, often dramatically, suggesting that expensive inference could be a brief interlude before the inevitable march toward near-zero costs.

During this temporary expensive phase, we could see gambling-like behavior patterns: "just one more expensive query to fix this bug," or "I'll spend $50 to see if I can get this working perfectly." Economic inequality could become the primary determinant of addiction access, with wealthy individuals maintaining their coding habits while others are forced into digital sobriety.

This period might create informal markets for compute resources, or share-economy arrangements where people pool resources to feed collective coding habits. The behavior could resemble World of Warcraft players organizing their entire lives around raid schedules, except instead of defeating digital dragons, they'd be collaborating to afford access to AI systems.

Paradoxically, the expense might force more thoughtful, disciplined use patterns—when each AI interaction costs real money, users could develop better prompt engineering skills and more systematic approaches to problem-solving.

But if computing history is our guide, this expensive phase would likely be brief. The more interesting long-term scenario is what happens when inference costs approach zero, making the psychological and social implications of unlimited AI access the primary concern rather than economic barriers.

The Psychology of Instant Creation

The psychological impact of effortless creation could deserve deeper examination. When building sophisticated software requires only clear communication with an AI system, what might happen to our sense of accomplishment and self-worth?

AI coding addiction differs from other digital dependencies in crucial ways. Unlike pure consumption activities, it involves creation euphoria—the god-like feeling of building functional systems from nothing. There's a problem-solving high that comes from watching complex challenges dissolve into elegant solutions. The infinite possibility space means there are no artificial limits like game rules or platform constraints.

Perhaps most importantly, coding addiction comes with a productivity guilt buffer. Unlike gaming or social media, "I'm being productive" becomes a powerful rationalization that makes the behavior harder to question or limit. The learning addiction component—constantly expanding skills and capabilities—feels virtuous rather than compulsive.

Traditional programming created natural rate limits. Learning syntax, debugging obscure errors, and managing complex architectures took time and created friction that prevented compulsive behavior. These barriers, while frustrating, also provided natural pause points for reflection and diverse activity.

AI-assisted development could remove these friction points, creating the potential for continuous engagement. The traditional markers of progress—learning new languages, mastering frameworks, solving algorithmic challenges—might become less relevant when AI handles the technical implementation. Instead, progress could become measured by the sophistication of ideas realized and problems solved.

This shift might be profoundly positive, redirecting human energy from mechanical tasks toward creative and strategic thinking. But it could also remove the forced learning periods that traditional programming provided, potentially creating developers who can orchestrate complex systems without understanding their underlying mechanisms.

Societal Implications and Intervention Points

As AI coding becomes more prevalent, we could need new frameworks for managing its addictive potential. The traditional approaches—regulation, restriction, treatment—might be inappropriate for an addiction that creates economic value and expands human capability.

Instead, we might need "productive addiction management"—systems that could channel compulsive coding behavior toward beneficial outcomes while preventing complete disconnection from other aspects of life. This could involve:

Rate limiting and cooling-off periods: AI platforms (possibly Govt mandated) might implement mandatory breaks or daily limits, similar to responsible gambling measures but calibrated for productivity rather than harm prevention.

Diversification incentives: Systems that could encourage users to apply their AI-assisted building skills to different domains, preventing the narrowing pattern of addiction while maintaining engagement.

Social integration features: Tools that might make AI-assisted creation inherently collaborative, ensuring that productive addiction doesn't lead to social isolation.

Real-world connection requirements: Platforms that could require users to test their creations with actual users or solve real-world problems, maintaining connection to physical reality and human needs.

The Coming Addiction Economy

We could be entering an era where the distinction between productive and destructive addiction becomes crucial for economic and social policy. If AI-assisted coding follows the broadening pattern—enabling people to explore diverse domains and solve varied problems—it might represent the most beneficial addiction in human history.

But if it follows the narrowing pattern—creating compulsive behavior focused on the act of coding itself rather than the problems being solved—we might face a generation of highly capable but socially disconnected individuals, brilliant at orchestrating AI systems but disconnected from human needs and physical reality.

The path we take will likely depend on how we design these systems and what economic models we choose for AI access. The stakes couldn't be higher: we could be shaping the fundamental relationship between human creativity and technological capability for generations to come.

The question isn't whether AI coding will be addictive—early patterns suggest this possibility. The question is whether we can design this potential addiction to expand human potential rather than constrain it, and whether we can create economic and social structures that would support productive rather than destructive engagement with these incredibly powerful tools.

In the end, we might discover that the right kind of addiction—to learning, creating, and solving problems—could be exactly what humanity needs to navigate an increasingly complex world. But only if we're intentional about how we structure the experience and what behaviors we choose to reward.

Written with Claude

The 1000x Code Explosion: Why AI Code Management Is Inevitable

The software development world is experiencing an extraordinary evolution that will represent one of the most transformative shifts in computing history. Codebases will grow beyond traditional human management capabilities within this decade, and AI assistance will become the natural foundation for software creation. While some experienced developers express concern about "vibe-coding" and AI-generated solutions, we're on the cusp of a fundamentally more powerful and accessible approach to building software.

The Opportunity at Scale

Modern applications integrate dozens of services, manage complex state across multiple layers, handle real-time data streams, and coordinate distributed systems with remarkable sophistication. The cognitive load of understanding every dependency and interaction in a typical enterprise application represents a fascinating challenge that's pushing us toward new collaborative models between human intelligence and AI capability.

This evolution opens extraordinary possibilities. Consider a typical React application with TypeScript, multiple database connections, third-party APIs, authentication layers, caching strategies, and deployment pipelines. The surface area of optimization opportunities, feature possibilities, and architectural innovations spans thousands of potential improvements. Rather than being overwhelmed by this complexity, we're developing AI systems that can help us navigate and enhance these intricate systems.

Real-World Glimpses of the Future

The transformation isn't theoretical—it's happening now in remarkable ways. Recently, I tested and created a Python module implementing the new route-finding algorithm that Tsinghua University researchers developed to outperform Dijkstra's algorithm. This included comprehensive benchmarking against the classical approach. The fascinating part? I accomplished this without deep knowledge of the underlying mathematics or advanced coding skills—AI handled the complex algorithmic implementation while I focused on understanding the problem and interpreting results.

In another project, I took an academic paper on machine learning for equity trading and converted it into a complete Python implementation. This included building systems to retrieve real-time stock data, creating comprehensive benchmarking frameworks, and developing both daily and weekly prediction systems. The AI collaboration handled the intricate mathematical transformations and data processing pipelines while I contributed domain knowledge about market dynamics.

I've also built signal aggregation systems that pull data from multiple sources, and developed comparator tools for financial analysis—all through AI-assisted development that would have taken months to build using traditional coding approaches.

These aren't isolated examples—they represent early glimpses of a future where domain expertise directly translates into sophisticated software solutions.

Five Emerging Trends Reshaping Development

1. The Coming Democratization of Coding

We're approaching an explosive expansion in who will write code. In the coming years, we'll see non-technical professionals building sophisticated workflows, students creating complex applications in their first semester, and domain experts directly translating their knowledge into working systems. This isn't a temporary trend—software creation is becoming a general literacy skill that will be as common as email or spreadsheets.

2. Educational Transformation

Computer Science programs will need to fundamentally rethink their curricula, shifting from teaching manual algorithm implementation to focusing on AI collaboration and prompt engineering. The transformation will mirror what happened when calculators became ubiquitous in mathematics education—the focus will move from computation to problem formulation and result interpretation.

3. The 1000x Code Explosion

Here's where the math become staggering: if AI enables 100x more people to write code, and each person can generate 10x more code, we're looking at a potential 1000x increase in code volume by the end of this decade. This isn't hyperbole—it's a logical extrapolation of current trends. Traditional code review processes, testing methodologies, and architectural oversight will need to evolve dramatically to handle this exponential growth.

4. Intelligent Validation Systems

The future of code quality won't rely on restricting AI-generated code, but on developing sophisticated AI systems that will perform comprehensive security audits, detect architectural patterns across massive distributed codebases, identify optimization opportunities before they become bottlenecks, and ensure code alignment with business requirements. This will create a new paradigm where creativity and systematic validation work in perfect harmony.

5. Autonomous Deployment Intelligence

Deployment systems will evolve into sophisticated orchestration platforms that will manage dependencies across thousands of micro-services, coordinate seamless rollbacks when needed, and handle the elegant complexity of systems where different components leverage different AI capabilities and architectural assumptions.

A Natural Evolution

This transformation follows a pattern that Andrew Ng articulates beautifully. As he notes, "Many decades ago, the world moved from punch cards to keyboard and terminal that made coding easier. When we moved from assembly to high-level languages like COBOL, there were actually people arguing back then that now we have COBOL, we don't need programmers anymore." Yet each of these transitions didn't eliminate programmers—they dramatically expanded what was possible and who could participate.

"In the 1960s, when programming moved from punchcards (where a programmer had to laboriously make holes in physical cards to write code character by character) to keyboards with terminals, programming became easier. And that made it a better time than before to begin programming." We're witnessing the same pattern today with AI assistance.

Consider the broader historical arc: punch cards to keyboards expanded access, assembly to high-level languages increased productivity, and now AI collaboration will amplify both accessibility and capability by orders of magnitude. Each transition initially met with skepticism from practitioners, but ultimately expanded what the field could accomplish.

The Idea-to-Execution Compression

For decades, the maxim has been "ideas are cheap, execution is expensive." This was true precisely because execution required rare, expensive skills. But when AI agents can handle the execution pipeline, the bottleneck shifts dramatically. Suddenly, the person who deeply understands a problem domain can directly address their own pain points without hiring developers or managing technical debt.

This creates space for hyper-niche solutions that big software companies would never justify building: software for left-handed violin makers, scheduling systems specifically for rotating shift nurses, budget trackers designed around irregular freelance income. When a thousand people have the same "better idea," they'll all be able to build working prototypes instead of just complaining about existing solutions.

The personal examples above illustrate this perfectly—specialized algorithmic implementations, custom trading systems, and financial analysis tools that would traditionally require hiring specialized developers or spending months learning complex frameworks. Instead, domain knowledge combined with AI assistance can produce sophisticated solutions in days rather than months.

The New Value Hierarchy and Cognitive Convergence

An interesting dynamic is emerging around what might be called the "word rotator" versus "shape rotator" divide. Many developers have traditionally identified with being "shape rotators"—those who excel at mathematical, spatial, and systematic thinking. Yet much of actual programming involves "word rotation"—parsing documentation, translating requirements, pattern matching solutions, and communicating clearly about complex systems.

AI-assisted development may represent a convergence of these cognitive styles. The AI handles much of the systematic, mathematical heavy lifting (shape rotation), while humans contribute problem framing, domain knowledge, and creative direction (closer to word rotation). The most valuable professionals in this new landscape may be those who can fluidly move between communicating with AI systems and evaluating the architectural soundness of their solutions.

Traditional coding skills are becoming commoditized, while new forms of hybrid expertise emerge as premium:

• Problem Identification: People who can spot real pain points and articulate clear requirements
• Cognitive Translation: Those who can fluidly move between linguistic problem description and technical solution evaluation
• Integration Architecture: Experts who understand how systems should connect and how to orchestrate multiple AI agents
• Domain Bridge-Building: Professionals who can seamlessly translate between human needs and AI capabilities

The Exciting Future

The trajectory points toward a near future where domain experts will directly create software solutions through natural conversation with AI systems. This represents something unprecedented in human history—the elimination of technical barriers between human need and digital solution. Every previous technological revolution still required intermediary specialists, but we're approaching a world where expertise in any domain can directly translate into working software.

The skepticism from some experienced developers reflects the natural human response to significant change. Their expertise in syntax, debugging techniques, and architectural patterns represents real value—but that value will evolve rather than disappear. The future will reward those who embrace this new collaborative model over those who resist it.

This transformation isn't a threat to software development—it's software development reaching its full potential. We're moving toward a world where human creativity and domain expertise can be directly expressed through code, amplified by AI systems that handle the systematic complexities that once required years to master.

The mathematics of this evolution are compelling, and the possibilities are extraordinary. The question isn't whether this will happen, but how quickly we can build the tools to make it accessible, reliable, and powerful for everyone.

The AI-Native Transformation: Why Your B2B Software Needs to Unbundle Now

The enterprise software industry is approaching a fundamental architectural shift that will make the mobile-first transition look like a minor UI refresh. As AI agents become ubiquitous—embedded in our desktops, phones, and workflows—the very concept of traditional software interfaces is being challenged.

The writing is on the wall: companies that don't prepare for an AI-native future risk becoming the Blackberry of the 2030s.

The Coming Interface Revolution

Consider the marketing automation industry, where platforms offer comprehensive suites encompassing email marketing, SMS campaigns, WhatsApp integration, push notifications, customer segmentation, analytics dashboards, and workflow automation. Today's users navigate complex interfaces, configure campaigns through multi-step wizards, and interpret performance data through elaborate dashboards.

But imagine a world where users simply tell an AI agent: "Launch a re-engagement campaign for customers who haven't purchased in 60 days, personalize it by their browsing history, and automatically adjust send times based on their timezone preferences."

The AI agent doesn't need your beautifully designed dashboard. It needs direct access to your core services: customer data pipes, segmentation engines, message delivery systems, analytics APIs, and scheduling infrastructure.

This isn't a distant future—it's happening now. AI agents are already learning to navigate interfaces through screen reading and click automation. The question isn't whether this transformation will occur, but whether your company will lead it or be disrupted by it.

The Unbundling Imperative

The solution requires four fundamental shifts that challenge conventional enterprise software thinking:

1. Unbundle Core Services for AI Consumption

Traditional enterprise platforms are built as monolithic experiences optimized for human navigation. The AI-native approach demands service decomposition—breaking complex platforms into discrete, autonomous capabilities.

Instead of offering "marketing automation software," forward-thinking companies should provide:

• Customer data infrastructure accessible via clean APIs
• Message delivery services for email, SMS, and messaging platforms
• Segmentation and personalization engines that can be called programmatically
• Analytics and reporting systems that return structured data, not visual charts
• Campaign orchestration tools that can be automated without human intervention

This isn't about building better APIs—it's about fundamentally restructuring how services are architected and exposed.

2. Embrace Model Context Protocols (MCPs)

APIs were designed for human developers. AI agents need something more sophisticated: Model Context Protocols that provide semantic understanding of what services do and how they interconnect.

MCPs represent the next evolution of service interfaces—APIs with built-in documentation that AI agents can understand and utilize autonomously. But the real transformation comes from MCP marketplaces—curated ecosystems where specialized AI agents discover and combine the best services for specific use cases.

Imagine marketing automation MCPs appearing in marketplaces alongside customer support, analytics, and sales enablement services. Specialized AI agents, both human-curated and AI-optimized, would evaluate and recommend the most effective combinations for specific business objectives. Your unbundled email delivery service doesn't just compete with other email services—it becomes a component that specialized agents select for comprehensive marketing workflows.

Early adopters in this space won't just become default integrations—they'll influence how specialized AI agents learn to solve business problems, creating powerful network effects as more agents discover and recommend their services.

3. Reorganize Product Development for an AI-First World

The most controversial implication: traditional product management may become obsolete. When users describe desired outcomes rather than navigate predetermined workflows, the role of designing user journeys and feature prioritization fundamentally changes.

This doesn't mean eliminating product teams entirely, but radically restructuring them:

• Maintain core infrastructure and ensure service reliability
• Focus on API performance and AI agent integration rather than UI optimization
• Shift from user experience design to conversation design
• Prioritize service composability over feature completeness

4. Internal Transformation Through "Dogfooding"

The fastest path to AI-native excellence is using your own transformed services internally. If your marketing team can't accomplish their goals by talking to AI agents that use your unbundled services, neither will your customers.

This approach accelerates development cycles and reveals integration gaps that wouldn't surface through traditional development processes.

Historical Precedent: The Infrastructure Winners

This pattern has repeated throughout business history. During major platform shifts, companies that optimize existing paradigms get disrupted by those who build infrastructure for the new paradigm.

The most instructive example comes from Amazon's transformation in the early 2000s. Jeff Bezos issued a now-legendary mandate requiring every team to expose their functionality through service interfaces - no exceptions. Teams could only communicate through these APIs, as if they were external developers.

This wasn't about building better internal tools. Bezos understood that forcing internal service decomposition would create the infrastructure foundation for future business models nobody had imagined yet. The result: Amazon Web Services emerged organically from internal infrastructure that teams were already forced to treat as external services.

Other historical precedents follow the same pattern:

• Banking: While traditional banks perfected branch experiences, Stripe and Plaid built banking infrastructure that now powers more transactions than many legacy institutions
• Media: Blockbuster optimized the video rental experience while Netflix built content delivery infrastructure
• Enterprise Software: Siebel created powerful desktop CRM software while Salesforce built cloud infrastructure with APIs from day one

The common thread: infrastructure thinking beats product thinking during paradigm shifts.

Companies that unbundle their core value and make it accessible through new interfaces capture disproportionate value. Those that optimize existing interfaces become casualties of technological evolution.

Amazon's API mandate worked because it created optionality for business models that didn't exist yet. Today's AI agent explosion represents a similar inflection point - companies that force internal service decomposition now will be positioned for AI-native business models they can't yet imagine.

The Competitive Stakes

First-mover advantages in AI-native transformation are significant:

• Ecosystem positioning: Early comprehensive API adopters become default integrations for AI agents
• Training data influence: AI agents trained on your service APIs are more likely to recommend your platform
• Standard setting: Define what "AI-native" means in your industry rather than reacting to competitors' definitions

The "fast follower" risk is real but manageable. Unlike feature additions, architectural transformation requires fundamental engineering work and organizational change—creating meaningful barriers to rapid replication.

Waiting is the highest-risk strategy. It assumes AI agent adoption will be slow and customer demands won't shift rapidly. History suggests otherwise.

The Revenue Reality

This transformation doesn't threaten existing revenue streams—it multiplies distribution channels for the same underlying value.

Current customers continue using traditional interfaces while new AI-native customers access services through conversational interfaces. Enterprise customers may pay premiums for AI-native integrations. AI agents themselves become a new sales channel, directly integrating your services into automated workflows.

You're not replacing revenue; you're expanding addressable markets and improving competitive positioning.

What This Looks Like in Practice

The transition to AI-native architecture requires more than just better APIs. Companies need to build intelligent orchestration layers that can interpret natural language requests, coordinate multiple services, and manage the business logic that AI agents need to operate effectively.

Consider a marketing professional telling an AI agent: "Create a win-back campaign for customers who haven't purchased in three months, personalize it based on their last category purchase, and schedule it for optimal engagement times."

This single request requires coordination across customer data systems, segmentation engines, personalization services, content management, campaign orchestration, and analytics tracking. An AI-native architecture handles this through intelligent orchestration—breaking complex requests into service calls, managing dependencies, and presenting unified results.

The orchestration layer also becomes the natural place to handle authentication, usage tracking, and billing. Rather than forcing AI agents to manage credentials across dozens of individual services, they interact with a single intelligent interface that handles the complexity behind the scenes.

Automated Pipeline Development: Forward-thinking companies are building AI agents that automate the transformation itself—agents that analyze existing codebases to generate Model Context Protocols, create AI-friendly documentation, and maintain service discoverability. This creates self-evolving systems where the infrastructure becomes increasingly optimized for AI agent consumption without human bottlenecks.

This architectural approach creates new business model opportunities. Instead of billing for "seats" or "features," companies can price based on actual value delivered: emails sent, customers segmented, campaigns executed, or insights generated. AI agents consuming services programmatically make usage-based pricing models more natural and transparent.

The Path Forward

The AI-native transformation isn't about predicting exactly when traditional interfaces disappear—some users will always prefer direct control, just as some people still prefer Excel spreadsheets to automated reporting.

The urgency comes from competitive positioning. Early movers in AI-native architecture will establish ecosystem advantages that become increasingly difficult to challenge as the market matures.

The companies that thrive in the next decade won't be those with the most polished interfaces, but those whose services are most seamlessly accessible to AI agents through intelligent orchestration layers. The transition from human-navigated software to AI-orchestrated infrastructure has begun.

This transformation requires both architectural changes—unbundling services, building orchestration capabilities, implementing AI-friendly interfaces—and organizational evolution toward infrastructure thinking rather than traditional product management.

The question isn't whether to transform—it's whether you'll lead this transformation or be disrupted by it.

The enterprises that embrace this architectural shift today will define the software industry of tomorrow. Those that wait may find themselves optimizing interfaces for a world that no longer exists.

Written with Claude. 

Why India Should Bet on Smaller, Specialized AI Models

I came across this sobering observation from Andrej Karpathy recently:

"Certainly, the moment money can buy dramatically better ChatGPT, things change. Large organizations get to concentrate their vast resources to buy more intelligence. And within the category of 'individual' too, the elite may once again split away from the rest of society. Their child will be tutored by GPT-8-pro-max-high, yours by GPT-6 mini."

This stark warning about the potential stratification of AI access led me to think about alternative approaches-particularly for countries like India that are working to establish their place in the global AI landscape.

In the midst of the global AI parameter race, where companies announce ever-larger models with hundreds of billions or even trillions of parameters, I find myself increasingly convinced that India's AI future lies in a different direction. Rather than joining this capital-intensive competition, India has a strategic opportunity to lead in the development of smaller, specialized AI models that could ultimately prove more impactful and sustainable.

The Parameter Race Has Peaked

Let's be honest: the parameter race is showing signs of diminishing returns. Yes, O-whatever (honestly find it hard to keep up, both the releases and the differences between them) and Claude 3.7 are impressive, Gemini 2.5 pro is the current GOAT, but the performance gains relative to their computational requirements don't always justify the increased scale. Meta'x latest underwhelming Llama release may well be case in point. Bigger, but not better. 

While some performance improvements have been achieved through architectural innovations (both software and hardware) rather than just raw scale, what remains undeniable is that the cost of entry to the frontier model race is extraordinarily high-often in the hundreds of millions of dollars for training and infrastructure.

This high barrier to entry effectively locks out most organizations and countries from competing at the frontier, regardless of their talent or innovative approaches. For India, attempting to compete in this arena means playing a game where the initial buy-in is prohibitively expensive. Our approach seeks to fundamentally change this dynamic by lowering the cost of entry and creating more distributed pathways to AI capabilities.

For India, attempting to compete in the frontier model arena means playing a game designed for those with vastly more capital. It's a competition rigged against newcomers, regardless of their talent or innovation.

The True Breakthrough of LLMs

The standout feature of LLMs, in my opinion, is not their ability to do things. It's their ability to understand things. This represents the true paradigm shift: computers that can comprehend context, nuance, and implicit meaning rather than merely executing explicit instructions.

This understanding capability is what makes LLMs revolutionary compared to previous technologies. And importantly, this capability isn't exclusive to massive models with trillions of parameters. Specialized models with careful training can develop deep understanding in specific domains while remaining relatively compact. A model trained exclusively on medical literature can develop sophisticated understanding of medical concepts without needing to also understand astrophysics, literature, and computer programming.

The question then becomes: do we need one massive model that understands everything, or a collection of specialized models that each understand their domain deeply? There is no evidence yet, but we must explore.

Rethinking Mixture of Experts

The Mixture of Experts (MoE) architecture has emerged as one approach to address the scaling challenges of large language models. Companies like Google (with Gemini) and Anthropic have turned to MoE designs where specialized "expert" neural networks handle different types of queries, activated by a router network that directs incoming requests to the appropriate expert.

While MoE is certainly more efficient than traditional dense models, I believe it still represents a half-measure that carries significant limitations:

1. Still resource-intensive: Though more efficient than fully dense models, state-of-the-art MoE systems still require massive computational resources to train and deploy. The router itself becomes a complex component that must understand enough about all domains to make intelligent routing decisions.
2. Architectural constraints: Forcing diverse expertise into a unified neural architecture imposes unnecessary constraints. Different tasks might benefit from entirely different model architectures, not just different parameters within the same architecture.
3. Limited specialization: The "experts" in modern MoE systems are specialized but still operate within the constraints of the broader model. Their specialization is limited compared to truly independent, purpose-built models.

The Specialized Model Alternative

Instead, consider a future built on constellations of smaller, specialized models:

• Why have one massive coding model when you could have 50 tailored to specific languages, frameworks, or domains?
• Why deploy energy-guzzling general-purpose models when task-specific models require a fraction of the resources?

SSDs are cheaper than GPUs anyway.

This isn't merely a consolation prize for those who can't afford frontier models-it may well be a better approach. Specialized models often outperform general models on specific tasks, run with lower latency, cost less to deploy, and can be updated more frequently.

Why India Is Perfectly Positioned

India has unique advantages that make this approach particularly attractive:

1. Software talent depth: India's vast pool of software engineers can be leveraged more effectively across multiple smaller projects than a single massive one.
2. 2Linguistic diversity: India's 22 official languages and hundreds of dialects demand specialized solutions rather than one-size-fits-all approaches.
3. 3Resource efficiency heritage: India has a rich tradition of creating frugal innovations that deliver maximum value with minimal resources.
4. Distributed expertise: From research institutions to startups, India has pockets of specialized knowledge that can each contribute domain-specific models.

There's even historical precedent for this approach. In the 1980s and 1990s, CDAC's work on Indian language computing showed how targeted solutions to specific problems could create an ecosystem that empowered millions, even without the resources of global tech giants.

Beyond MoE

What I'm proposing goes beyond Mixture of Experts to what we might call a "True Orchestration" approach. Rather than housing everything within a single model architecture, this approach:

• Uses a relatively small but capable orchestrator model to understand user intent
• Maintains a registry of completely independent specialized expert models
• Calls the relevant expert via API based on the determined intent
• Combines responses when needed
• Manages context and continuity across interactions

The key differences from traditional MoE approaches are profound:

1. Complete architectural independence: Each expert model can use whatever architecture is optimal for its specific domain-whether that's a transformer, CNN, GNN, or something entirely different.
2. Deployment flexibility: Expert models can be deployed wherever makes most sense-some locally, some in the cloud, some on specialized hardware.
3. Independent scaling: Each expert can be scaled according to its specific needs rather than being constrained by a one-size-fits-all approach.
4. Organizational collaboration: Different organizations can contribute expert models to the ecosystem without needing to integrate into a monolithic system.
5. Incremental improvement: The system can improve gradually as new experts are added or existing ones are enhanced, without requiring complete retraining or rearchitecting. 

If India pursues this, these domains are worth attention:

• Healthcare models trained on Indian medical data, understanding local disease patterns and treatment protocols
• Agricultural models optimized for India's diverse climates, crops, and farming practices
• Educational models designed for various curricula, languages, and pedagogical approaches
• Financial models tuned to India's unique economic landscape and inclusion challenges
• Governance models built to navigate India's administrative structures and public service delivery

Each of these represents an opportunity to create AI that is not just technically sound but contextually relevant to Indian realities.

True Orchestration vs. MoE

For India specifically, the True Orchestration approach offers several advantages over traditional MoE systems:

1. Economic efficiency: The training costs for a collection of smaller models plus an orchestrator are significantly lower than those for massive MoE systems. Initial estimates suggest 5-10x cost reduction for comparable capabilities.-
2. Infrastructure compatibility: Many parts of India still face infrastructure constraints. Smaller models can run on more modest hardware, making deployment feasible across a wider range of settings.
3. Distributed development: India's AI talent is spread across various institutions, companies, and regions. This approach allows different teams to contribute specialized models based on their unique expertise.
4. Data efficiency: Specialized models can achieve high performance with domain-specific datasets, which are often easier to collect and curate than the massive general datasets needed for large models.
5. Cultural and linguistic precision: India's remarkable diversity demands models with deep understanding of specific linguistic and cultural contexts-something that specialized models can provide more effectively than general ones.

Disrupting the New Rent Economy

There's another crucial dimension to this approach that goes beyond technical considerations: economic power dynamics. The current trend toward massive foundation models is actively creating new economic rents. These models are so resource-intensive to build and operate that they naturally create centralized control points where companies can extract ongoing payments for AI capabilities.

Our specialized model approach-especially if we can get these models running efficiently on CPUs of regular computers and laptops-returns power to the average user by short-circuiting that rent-seeking behavior of American firms. When specialized AI models can run locally on consumer hardware, users gain:

• Independence from usage-based billing models
• Freedom from constant connectivity requirements
• Control over their own data and privacy
• Protection from arbitrary API changes or price increases

This represents not just a technical alternative but an economic and philosophical one. It's about whether AI becomes another utility controlled by a handful of tech giants, or a capability that remains accessible to and controlled by ordinary people.

Returning to Karpathy's warning about AI stratification-where "the elite may once again split away from the rest of society" with premium AI access-our approach offers a compelling countermeasure. By creating specialized models that run on common hardware, we can help ensure that high-quality AI remains accessible to all segments of society, not just those who can afford premium subscriptions or dedicated infrastructure. This of course assumes that this will come to pass and there will be intense competition (and hence improvements) in this approach. 

A practical example illustrates the difference: A healthcare AI system for India might need to understand not just medical knowledge but regional disease patterns, local treatment protocols, and multiple languages. A True Orchestration approach would allow domain experts in each area to contribute specialized models rather than trying to force all this knowledge into a single architecture.

India's Strategic Path

For policymakers, researchers, entrepreneurs, and investors in India's AI ecosystem, this suggests a different approach to resource allocation:

• Invest in diverse smaller projects rather than a few massive ones
• Build and promote infrastructure and research that supports model orchestration and deployment
• Create standards for model interoperability and API communication
• Focus on solving specific, high-value problems rather than chasing general intelligence
• Develop expertise in orchestration technologies as a strategic capability

This approach also offers a viable path for public-private partnership. Government agencies could focus on building core infrastructure and standards, while private companies and research institutions develop specialized expert models in their domains of expertise.

A Different Kind of AI Leadership

The global AI landscape is rapidly evolving, and India has a chance to chart its own course-one that plays to its strengths rather than attempting to win a game where the deck is stacked against it. By embracing smaller, specialized models and sophisticated orchestration, India could develop an AI ecosystem that is not just globally competitive but uniquely valuable.

This approach might even represent the future of AI more broadly. As the limitations of monolithic models become more apparent, the industry may shift toward more modular, specialized approaches. By focusing on this direction now, India could find itself not just participating in the global AI ecosystem but helping to define its next evolution.

Importantly, this strategy aids not only India but also the rest of the not-so-rich world. The specialized model approach creates a viable path for countries with significant technical talent but limited capital to participate meaningfully in the AI revolution. It democratizes AI development, allowing nations to build on their unique strengths and address their particular needs without requiring the astronomical investments that frontier models demand. This could help prevent a future where advanced AI capabilities are concentrated exclusively among a handful of wealthy nations and corporations.

In the AI race, the smartest strategy isn't to run faster but to take a different path entirely. For India, that path leads through specialization, orchestration, and strategic collaboration-a distinctly Indian approach to artificial intelligence that builds on the country's unique strengths and addresses its particular needs. And by pioneering this path, India might just create a blueprint that empowers many other nations to develop their own AI capabilities tailored to their specific contexts.

Co- written with Claude.

The Independent Delivery Network: The Missing Link in Local Economies

In economic discourse, we often hear the simplified maxim that demand drives supply. While this intuitive principle captures many market dynamics, classical economics has long recognized the inverse relationship as well. Jean-Baptiste Say, the influential 19th-century economist, articulated what became known as Say's Law: "Supply creates its own demand." Though sometimes overlooked in popular economic discussions, this principle remains an important part of classical economic canon.

This bidirectional relationship between supply and demand becomes particularly relevant when examining how delivery networks could transform local economies. 

The prescience of Say's insight becomes apparent when we consider how an independent, organized delivery network could stimulate entirely new economic activities at the local level—creating demand through the very availability of its supply.

From Two-Sided to Four-Sided: The Evolution of Digital Marketplaces

To understand the potential of independent delivery networks, we must first recognize a crucial distinction in platform models. Ride-hailing services like Uber operate primarily as two-sided marketplaces:

1. Riders (customers)

2. Drivers (service providers)

Food delivery platforms, however, introduced a more complex four-sided marketplace:

1. Customers (diners)

2. Platforms (technology companies)

3. Restaurants/merchants (food suppliers)

4. Delivery partners (independent couriers)

This additional complexity creates both challenges and opportunities. While ride-hailing platforms needed to organize only one supply network (drivers), food delivery platforms must orchestrate two distinct networks: restaurants and delivery partners. The emergence of this separate delivery layer creates the potential for a new kind of infrastructure: the independent delivery network.

Beyond Platform Control: The Case for Independent Delivery Networks

Current delivery models typically operate as captive resources within platform ecosystems. While these platforms have begun expanding beyond food into groceries, medications, and convenience items, they're fundamentally deepening their own offerings rather than empowering the broader local economy.

In the United States, DoorDash exemplifies this trend, a delivery service that has expanded to include shopping services and general "gofer" tasks. However, these services remain primarily customer-initiated and platform-controlled.

The alternative model—where delivery capacity becomes available "on tap" for businesses themselves—represents a fundamentally different approach. Rather than customers initiating delivery through a consumer-facing platform, businesses could directly tap into a shared delivery network in response to their own demand patterns and customer orders.

This business-initiated model was attempted in India by Dunzo. While the company faced challenges and ultimately shut down, perhaps because it was customer facing and came with the attendant challenges of customer acquisition and growth. That said, the concept remains compelling: a delivery network that serves as infrastructure rather than a consumer-facing service.

The Immediacy Challenge: From On-Demand to Instant

While local delivery services exist in many markets, they frequently lack two critical elements that would make them truly transformative for local economies: immediacy and seamless business process integration.

In Mumbai, restaurants have attempted to address this through services like DotPe, which allow them to bypass traditional delivery platforms. However, the process often introduces significant delays: a restaurant prepares food, then calls for a rider, adding 10-15 minutes to delivery times. The availability exists, but performance suffers. This further impacts uptake. 

True transformation requires delivery networks that provide:

1. Immediate availability - Riders ready to pick up within minutes with advance intimation. 

2. Full visibility - Turn-by-turn tracking integrated into business dashboards

3. Seamless integration - API connections to business order management systems

4. Predictive positioning - Algorithms that position riders near anticipated demand

5. Unified standards - Consistent service levels across all participating businesses

The supply of riders exists, but current approaches fail to organize this supply optimally for maximum economic impact.

The Fluid Nature of Delivery Supply

Delivery partners currently exhibit high mobility between competing platforms. Similar to how cab drivers in India might switch between multiple ride-sharing apps depending on incentives—sometimes multiple times in a single day—delivery partners optimize their earnings by toggling between food delivery, grocery delivery, and package delivery services.

This fluidity suggests that delivery capacity itself could be organized as an independent network, serving multiple demand sources rather than being captive to individual platforms. The supply of ready riders creates the potential for delivery networks that transcend any single platform's ecosystem.

What's needed is a reconceptualization of delivery supply as a flexible, responsive network that can be tapped instantly by any legitimate business need—a true utility rather than a siloed resource.

Organizing Independent Delivery Supply: The Missing Infrastructure

Local businesses face a significant disadvantage against e-commerce giants and platform-based delivery services: they lack access to reliable, cost-effective delivery infrastructure. An independently organized delivery network could fundamentally change this dynamic.

Such a network would need:

• A cooperative or guild-like structure representing delivery workers' interests

• Technology infrastructure for routing, dispatch, and payment processing

• Quality standards and performance metrics

• Collective bargaining power with various demand sources

• Professional development and equipment standardization

Worker-owned platforms and cooperatives represent a potential counterbalance to venture-backed platforms, particularly in locally-oriented services.

Greasing the Wheels of Local Commerce

An independent delivery network could serve as critical infrastructure for a wide range of local businesses that currently cannot afford to build their own delivery capabilities:

1. Independent Retailers

• Local bookstores competing with Amazon

• Specialty shops offering same-day delivery

• Artisanal producers reaching customers beyond foot traffic

2. Local Service Providers

• Home repair professionals sending parts or tools ahead of appointments

• Salons delivering custom product packages to clients

• Professional services delivering documents and materials

3. Neighbourhood Marketplaces

• Fish markets extending reach beyond physical locations

• Craft fairs and local events delivering to those who can't attend

• Community-supported agriculture distribution

4. Micro-Manufacturers

• Small-batch producers delivering directly to customers

• Custom fabricators sending finished products

• Local food producers reaching restaurant clients

5. Civic and Community Services

• Library book delivery and returns. Though the cost may not justify this. 

• Community aid distribution

• Municipal service request fulfilment

• Elder care support services

An independent delivery network could provide a balance of autonomy while still benefiting from collective organization, while serving as essential infrastructure for the local economy.

Creating Network Power Without Platform Control

The key challenge in establishing such a network lies in achieving sufficient scale and coordination without centralized platform control. Possible approaches include:

• Municipal support and subsidy as essential infrastructure

• Cooperative ownership models among delivery workers

• Technology partnerships with open standards and protocols

• Local business association sponsorship and governance

• Federated networks with local coordination but shared standards

Research by Scholz and Schneider (2017) on platform cooperativism suggests that worker-owned digital infrastructure can be both economically viable and socially beneficial when properly structured.

From Side Hustle to Essential Infrastructure

The current paradigm views delivery work largely as a "side hustle" or transitional employment. Reconceptualizing delivery networks as essential economic infrastructure would require:

• Professional standards & certification. The latter for things like medicine/municipal services

• Living wage guarantees

• Benefits structures appropriate for flexible work

• Career advancement pathways

• Equipment and training standardization

As delivery becomes increasingly central to local economic activity, the workers who perform these functions deserve recognition as essential service providers rather than interchangeable gig workers.

The Delivery Commons

Just as roads, bridges, and utilities serve as shared infrastructure enabling commerce, an independent delivery network could function as a "delivery commons"—shared infrastructure that enables local businesses to compete effectively in the digital age.

The future of local economies may well depend on whether delivery capacity can be organized independently from the dominant platforms. When delivery workers can organize themselves as essential infrastructure providers rather than platform dependents, local businesses gain the logistical capabilities previously available only to large corporations and platforms.

The most forward-thinking communities and regions will be those that recognize delivery networks not merely as a feature of certain platforms, but as critical economic infrastructure worthy of investment, organization, and protection. By disintermediating delivery supply from platform control, we can create new possibilities for local economic resilience and growth.

PS: Co-authored with Claude.ai