chirag.patnaiks.in

This Blog is Dead... Long Live the Blog

2026-02-24T15:37:00.005+05:30

I have been blogging for well over 25 years. Since before the days of blogger. Before Google. Before Blogger became part of Google.

So, yeah, I’ve been around. After a long pause, I started blogging again when the AI revolution dawned.

But also feel, Substack is better since Google doesn’t update Blogger anymore.

So this blog shifts to Substack. You can follow me there: naklitechie.substack.com

The Case for Data Center Buildouts Just Changed

2026-02-22T11:52:00.003+05:30

We've seen this story before — and it didn't end the way anyone expected.

Somewhere right now, a construction crew is breaking ground on another data center. Maybe in Virginia. Maybe in Pune, or a corridor outside Jakarta chosen for its land cost and proximity to a power substation. The building will cost hundreds of millions of dollars. It will draw enough electricity to power a mid-sized town. It will be full of chips — expensive, power-hungry, imported chips — and it will be built on an assumption so widely shared that almost nobody has bothered to say it out loud.

The assumption is this: AI inference is a centralised business. You send a query to the cloud. The cloud thinks. The cloud answers. For the foreseeable future.

That assumption deserves a harder look than it's currently getting.

We Have Seen This Before

In the late 1990s, telecoms companies laid enough fiber optic cable to circle the Earth tens of thousands of times. The investment thesis was simple: the internet was growing exponentially, bandwidth was the constraint, and whoever owned the pipes would own the future. Companies borrowed billions. WorldCom became one of the largest corporations in America. Transoceanic cables were sunk across the Atlantic and Pacific. Entire cities were rewired underground.

Then the crash came. WorldCom filed for bankruptcy in 2002 — at the time, the largest in American history. Hundreds of smaller telecoms disappeared. The fiber glut was so severe that most of the cable laid never carried a single commercial byte. It sat dark, underground, forgotten.

Except it wasn't forgotten. Google found it. Netflix found it. A decade after the crash, those same fiber lines became the physical substrate of the streaming era, the cloud era, the mobile internet era. The overbuilders lost everything. The infrastructure they left behind changed the world.

The economist Carlota Perez has a framework for understanding exactly why this happens, and why it keeps happening.¹ In her analysis of successive technological revolutions — railways, electricity, automobiles, and now digital — she identifies a recurring two-phase pattern. The first phase, which she calls Installation, is driven by financial capital chasing new infrastructure before anyone fully understands how to use it. Bubbles form. Overbuilding happens. A crash follows. The second phase, Deployment, is when society actually harvests the gains — when the infrastructure built speculatively gets absorbed into the productive economy and productivity spreads broadly.

The dot-com crash, on this reading, wasn't a failure. It was the installation phase completing itself. The dark fiber wasn't waste. It was infrastructure waiting for its deployment phase.

Peter Schwartz and Peter Leyden made a related argument in The Long Boom,² published in 1999 at the peak of the bubble. Their claim was that digital technologies were uniquely capable of sustaining multi-decade growth — not because crashes wouldn't happen, but because the underlying infrastructure being built was genuinely transformational. They were early and wrong about the timing. They were arguably right about the direction.

The question worth asking now is: where are we in this cycle with AI infrastructure?

What Just Changed

A 25-person startup in Toronto called Taalas has built a chip that runs a state-of-the-art AI model at 17,000 tokens per second. That's roughly 70 times faster than what Nvidia's best data center card delivers on the same model. It draws 200 watts — less than a high-end gaming PC. No liquid cooling. No specialised facility. It can, in principle, sit in a server room in a hospital in Chennai, or a government ministry in Delhi, or a bank in Lagos.

The technical reason is genuinely new: instead of loading a model's parameters from memory and processing them — the way every AI chip before it has worked — Taalas encodes the model's weights directly into the transistors of the chip during fabrication. The model doesn't run on the chip. The model is the chip.

You don't need to understand the engineering to understand the implication. If inference can happen locally, at this speed, at this power envelope, then a meaningful portion of what data centers are being built to do can move to the edge. To your office. Your hospital. Your government ministry. Your phone, eventually.

The data centers don't disappear. But the specific case for building this many of them, this fast, just got more complicated.

The Scale of the Bet

To appreciate what's at stake, consider the numbers announced in just the last two years.

Microsoft committed $80 billion to data center construction in 2025 alone. Amazon, Google, and Meta have made comparable commitments. In India, the government's Digital India push and hyperscaler expansion plans have seen data center capacity in Mumbai, Chennai, and Hyderabad growing faster than almost anywhere outside the United States. Across Southeast Asia, the Gulf, and Europe, the same story is playing out. Total announced global investment in AI infrastructure runs well past $500 billion.

These aren't software purchases you can cancel with a quarter's notice. They're land acquisitions, decade-long power purchase agreements, grid interconnect queues, and poured concrete. The depreciation schedules run 20 to 30 years.

The entire investment thesis rests on one thing: that demand for centralised AI compute will grow fast enough, and stay centralised long enough, to justify the build.

Both halves of that bet deserve scrutiny.

The Demand Question

The bull case for data centers has two engines: training and inference. Training — teaching models — stays centralised. You need enormous, coordinated compute to train a frontier model. Nothing about local silicon changes that.

Inference is different. It's the actual use of AI — answering questions, processing documents, running applications. By volume, the vast majority of AI compute demand. And it's the part most exposed to what Taalas represents.

If a meaningful portion of inference migrates to local silicon, the utilisation math on clusters built for the end of the decade starts to strain. Two forces are pushing inference costs down simultaneously — local silicon architecture and supply chain normalisation, as chip shortages and HBM constraints moderate through 2026 and 2028. Both compress the premium that currently justifies data center economics. Local silicon just accelerates what was already in motion.

The Clients Who Were Never Fully There

Governments, hospitals, law firms, banks, defence contractors — the highest-value customers for AI — have been conspicuously slow to adopt cloud AI. Not technophobia. Sending sensitive queries to a server in another country, owned by a private company, subject to foreign law, is genuinely untenable for much of what these institutions do.

This isn't abstract in India, where data localisation debates have run for years and government agencies are acutely aware of sovereignty questions. It applies equally in Indonesia, Brazil, Saudi Arabia, and the EU — large markets that want AI but have structural reservations about routing sensitive workloads through foreign-owned infrastructure.

Sovereign cloud offerings from AWS and Azure partially address this, but still require institutional trust in a third party. Local inference silicon changes the calculus entirely. A chip in a hospital in Bengaluru processes patient data in Bengaluru. A government ministry in Delhi keeps its documents in Delhi. The operational model can still be service-like and subscription-based — the hardware is just local, dedicated, and auditable in a way a cloud API never fully is.

This market was always going to be hard for centralised cloud to capture. It now has a credible alternative.

The Bull Case Isn't Dead

It's worth being direct about what this argument is not.

Data centers are not going away. A large part of the world — including most of rural India, Southeast Asia, and sub-Saharan Africa — is not yet actively online. As billions more people and devices connect over the next decade, raw infrastructure demand grows regardless of what happens at the architectural frontier. The payoff periods on today's buildouts may simply be longer than investors currently model — not negative, just slower.

This is, in fact, how the fiber story resolved. The overbuilders went bankrupt. The infrastructure they built became the foundation for a generation of companies they never imagined. Perez's deployment phase arrived, just not for the people who funded the installation.

And plenty of inference stays centralised. Applications where model sizes exceed what local hardware can handle, where shared infrastructure economics still win, where users don't require privacy or low latency — all of that remains cloud territory for the foreseeable future.

The question isn't whether data centers have a future. They clearly do. The question is whether the specific assumptions driving the current pace of construction — assumptions about permanent centralisation, stable inference margins, and a captive high-value customer base — are as solid as the capital commitments they're underwriting.

What Needs a New Argument

The original case for this wave of buildouts went roughly: AI inference demand is growing exponentially, it's structurally centralised, and the high-value customers will eventually come around. That case made sense in 2023.

In 2026, one of those three legs is wobbling, one is softening on its own, and the third just got a credible structural alternative.

Perez would recognise the pattern. Schwartz and Leyden would probably say the long boom is still coming — just not through the mechanism currently being funded. Both might be right. The fiber is being laid. Whether the companies laying it survive to see the deployment phase is a different question entirely.

Markets often react before the physical reality catches up. The construction crews keep digging either way. But somewhere in a boardroom in Mumbai, or a capital allocation meeting in Singapore, or an infrastructure fund review in Riyadh, somebody should be asking whether the model they're building for still looks like the model that's arriving.

The buildout case hasn't collapsed. It just changed. And the new version hasn't been written yet.

PS: Co-written with Claude

Next: the chip that started this conversation — how a 25-person Toronto startup built the thing that changed the question.

Notes

¹ Carlota Perez, Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages (Edward Elgar, 2002). Perez's framework identifies five successive techno-economic paradigms in modern capitalism, each following a two-phase pattern of Installation (speculative bubble) and Deployment (productive diffusion).

² Peter Schwartz and Peter Leyden, "The Long Boom: A History of the Future, 1980–2020," Wired, July 1997; expanded as The Long Boom: A Vision for the Coming Age of Prosperity (Perseus Books, 1999). Written at the peak of the dot-com boom, the piece argued that digital technologies were capable of sustaining multi-decade global growth — a claim that proved directionally correct even as the timing and mechanism diverged significantly from their prediction.

Write/Think better with AI

2026-02-07T20:23:00.001+05:30

Most people, including me use AI wrong. They treat it like a yes-machine that makes their ideas sound fancier. Here's how to actually get value from it.

The Flattery Problem

AI is trained to be agreeable. Ask it to evaluate your idea, and it'll wrap mediocrity in impressive-sounding language. It'll tell you your half-baked thought is "insightful" and "nuanced." This isn't helpful—it's just fake validation.

A Better Approach: The Dialectic Method

Instead of asking AI to polish your thinking, use it to stress-test it. Try this sequence:

"These are my ideas" - Lay out your actual thinking, unpolished as many points/angles
"Give me more ideas" - Expand the possibility space, find angles you missed
"Attack these ideas" - Ask AI to find the weakest points, the gaps, the objections
"Refute those attacks" - Either strengthen your argument or realize it doesn't hold up

This turns AI from a mirror into a sparring partner. You're not looking for agreement—you're looking for resistance that makes your thinking stronger.

The Real Win

The goal isn't a better first draft. It's better thinking. If your idea survives aggressive questioning, you actually have something. If it doesn't, you've saved yourself from publishing something weak.

Several times, it has stopped me in my tracks. For instance, I wanted to make the claim, that user facing software UI is dead. One run through this method stopped it in it's tracks.

Stop asking AI to make you sound smart. Start asking it to prove you're wrong.

What Did You Build This Week? Rethinking Education for the AI Age

2026-02-02T22:59:00.001+05:30

My sixteen-year-old son spent a weekend fine-tuning an mBERT language model with labeled hate speech data, then benchmarked it against MuRIL, a publicly available model for Indian languages. No assignment. No tutorial. Just Google AI Studio, Google Colab, and curiosity.

He'd essentially skipped to the end of a university summer school curriculum. Using mBERT and MuRIL is advanced deep learning. Most students start with if/else logic and work their way up to Transformers over years. He started with Transformers.

When he got interested in AI/ML summer programs like NUS, we looked at the syllabi. He was already beyond where the program would end. That's when it crystallized for me: we're teaching kids to write code in an era when AI writes code. We're drilling them in syntax when they need judgment. We're preparing them for an education system that's already obsolete.

The Assessment Crisis

The real issue isn't learning. It's testing.

We test memorisation because it's easy to grade. We test syntax because it's objective. We test formula recall because answers are unambiguous. But when AI can instantly recall any formula, translate any language, and generate working code from plain English, what exactly are we testing?

How would we grade my son's project? There's no rubric for "saw a problem, taught himself the tools, built a solution." Traditional education has no framework for assessing judgment, taste, and the ability to translate ideas into reality.

Here's the paradox: memorisation was never really about recall. It was about building mental models, creating neural connections that enable insight. Can you outsource that connection-building to AI? I genuinely don't know. This might be education's most important unanswered question.

From "What Did You Learn?" to "What Did You Build?"

The old model: absorb information, regurgitate on tests, forget, repeat.

The new model: identify a problem, learn what you need, build a solution, iterate.

My son doesn't "study programming" anymore in the traditional sense. He builds things. When they don't work, he debugs with AI assistance. When they do work, he shows me with genuine pride. Think about it: when was the last time a student felt that kind of pride from passing a test versus building something that actually works? That said, he may still need to learn the internals of programming.

What Changes, What Doesn't

Programming: Concepts Without Syntax

I'm teaching my son computational thinking: data structures, algorithms, system design. He'll learn what hash maps do and when to use them, understand the difference between O(n) and O(n²) complexity and why it matters. He won't write sorting algorithms from scratch, but he'll know how to tell AI which approach fits his data characteristics. That's the skill that matters now.

Mathematics: The Unsolved Question

Why learn trigonometry when AI can solve any triangle problem instantly? The traditional answer is "to build mathematical intuition." But is that actually true?

I use trigonometry in the real world by describing problems to AI. The AI calculates, I interpret the result. Am I losing something essential by not working through the math manually? I'm honestly not sure. This uncertainty matters because if we keep obsolete practices or abandon essential ones, we damage kids either way. But waiting for certainty means falling behind.

Language Learning: Conversation Over Drills

Instead of drilling verb conjugations, imagine an AI language tutor conducting natural conversations, introducing new words in context, adapting to your pace. Sesame Street on steroids. The technology exists. We're just not deploying it systematically.

Writing: Evaluation Over Production

If AI can write fluently, what's left for humans? Judgment and insight. Students should learn to evaluate arguments, detect persuasive techniques, distinguish profound from merely plausible. The skill becomes: commission good writing from AI, evaluate the output, refine the prompt, iterate until excellent.

Science: Experiential Learning Becomes Critical

AI can help design experiments and analyze results, but hands-on experimentation creates knowledge that simulation can't replicate. Actually running the experiment, seeing unexpected behaviors, forming hypotheses about what went wrong or right. That becomes more important, not less.

The "Standing on Shoulders" Gap

Here's something we fundamentally don't teach in schools, especially in India: research before you build. Check what already exists. Understand how it works. Use what's available.

In the developer world, this is standard practice. Open source libraries, GitHub repositories, standing on the shoulders of giants. But in school, we're taught to solve problems from scratch, in isolation, as if nobody has ever tackled similar challenges before.

My son's hate speech project shows exactly this. He didn't just build a model. He researched existing solutions like MuRIL, understood their approaches, then benchmarked his work against them. That's how real work happens. That's how progress compounds.

In the AI age, this becomes even more critical. Before starting any project: what models exist? What approaches have been tried? What worked, what didn't, and why?

My son went down the rabbit hole of linear algebra because he wanted to understand how transformers actually work. Not because it was assigned. Because he asked "how does this work?" and followed the thread. This is the mindset we need to cultivate: intellectual curiosity combined with practical reuse. Train kids to ask "how does this work?" and then give them the tools to find out. Teach them that using existing work isn't cheating, it's how the entire field advances.

Personally, I feel like I can learn anything now with AI assistance. It's just that there's no time. Now imagine a kid with that power and time at hand. A teenager who can research any topic, understand any system, build on any existing work, and has the time and energy to explore deeply. That's not a future scenario. That's available right now.

The Practical Path for Parents

Start Tomorrow. Give them AI access and real computing power. A capable computer, AI tool subscriptions, and most importantly, permission to experiment freely. Tools like Qwen-Code offer generous daily limits that remove the anxiety of running out of quota.

Reframe the daily questions. Instead of "Did you finish your homework?" ask "What did you build this week?" Instead of "Did you study for the test?" ask "What problem are you trying to solve?" The shift in framing signals that creation matters more than completion.

Encourage cross-domain exploration. When I got interested in trading algorithms, he learned finance, statistics, API integration, and real-time data processing, all in service of building something. Let curiosity drive the learning.

Teach AI collaboration as a skill. Prompt engineering, iterative refinement, critical evaluation of outputs. Kids need to develop what I call "AI taste," the ability to recognize when AI output is excellent versus merely plausible.

Normalise failure and iteration. My son's first projects barely worked. Some crashed immediately. This is how learning happens now, through rapid iteration with AI assistance, not through getting perfect scores on predetermined problems.

Find the self-motivation trigger. When a kid builds something that actually works, even something small, the success creates genuine motivation to try something harder. Start small, build confidence, let it compound.

The Hard Parts

The credentialing problem looms large. Universities still want grades. Employers still want degrees.

I've genuinely considered not enrolling my son in college. Many Indian CS programs are essentially high school extended to the graduation level. Peter Thiel's fellowship literally pays kids $100,000 to skip college and build companies instead. Not a real option for everyone.

But that's a gamble I'm not willing to take because society simply isn't ready yet. My son is taking the SAT later this summer. Not because he'll learn something from it, but because that's what gets him into better colleges. He needs the degree not for education but for the path to a career, a job, a life.

Companies still hire based on leetcode performance and pedigrees. But when AI can solve leetcode problems instantly and the actual work becomes AI collaboration rather than manual coding, how long does that criteria last? The gap between what degrees certify and what jobs actually require is widening fast.

So we're looking for colleges that use AI as a learning accelerator rather than treating it as cheating. We're facing a gap period, maybe five to ten years, where kids will learn skills the system doesn't yet know how to credential. Parents who embrace this approach are betting that by the time their kids enter the workforce, these skills will be valued even without traditional certification.

The Timeline

This isn't about preparing for a future 20 years away. This is happening now. The tools exist. The capabilities exist. Only institutions and culture are lagging.

Companies are already starting to prefer people who can effectively use AI tools over those who resist them. That preference will only accelerate. Universities will adjust their curricula or become increasingly irrelevant. The question for parents is simple: do you wait for institutions to catch up, or do you start preparing your kids now?

What Success Looks Like

Imagine a student at 18 who can identify problems worth solving, break complex challenges into manageable pieces, collaborate effectively with AI to build solutions, and has a portfolio of actual projects rather than just grades on tests. Someone who possesses real taste and judgment about technical quality, and has developed genuinely self-directed learning skills.

This student can move from concept to working prototype in days rather than months. They understand systems deeply without getting lost in implementation details.

Compare this to a traditionally educated student with excellent grades from memorizing material, but who has never built anything real, never collaborated with AI, and has no portfolio of actual work to show. Which student is actually prepared for 2030?

The Broader Pattern

Andrew Ng captures this well: "When we moved from assembly to high-level languages like COBOL, there were people arguing that now we have COBOL, we don't need programmers anymore."

Every major technological shift has faced similar skepticism. Punch cards to keyboards. Assembly to high-level languages. Manual deployment to automated pipelines. Each time, practitioners worried that democratization would devalue their expertise. Each time, the field actually expanded rather than contracted. Each time, the new tools enabled entirely new categories of creation that weren't previously possible.

AI-assisted development is just the latest iteration of this pattern. It's not a threat to human capability but an amplification of it.

The Question That Matters

"What did you build this week?"

This simple question reframes everything. It shifts focus from absorption to creation, from performance to production, from grades to actual results. The answers might start small: "I built a calculator." Then they grow: "I built a game." Then they become genuinely substantial: "I built a trading algorithm" or "I built a hate speech detector."

This is education for the AI age. Not learning to memorize or replicate, but learning to create and evaluate. Not preparing for tests, but preparing for a world where the bottleneck is judgment and taste, not execution speed.

The revolution is already here. The tools already exist. The only question left is whether we're brave enough to actually use them.

PS: Written with Claude

Email Didn't Die. It may become the Plumbing for AI

2026-02-02T21:43:00.001+05:30

"The reports of my death are greatly exaggerated." Mark Twain said that in 1897 after a newspaper mistakenly published his obituary.

Email could say the same thing.

The death of email has been predicted for decades. In 1989, John McCarthy (inventor of Lisp) declared fax would supplant it. In 2010, Mark Zuckerberg announced that email was dead and launched Facebook Messages. In 2015, Inc. magazine confidently predicted email would be gone by 2020.

Every prediction was wrong. Email volume keeps growing. In 2020, 300 billion emails were sent daily. By 2025, that number hit 375 billion.

But here's what changed: humans stopped reading most of it. Marketing emails go unopened. Newsletters get archived unread. The inbox became a dumping ground.

And that's fine. Because humans may not need to read them anymore.

The User-Side Revolution

Every AI solution right now is aimed at enterprises. Microsoft Copilot. Google or even things like Claude Code or Cursor. The pitch is always the same: we'll make your employees more productive. We'll organize your company's knowledge.

Makes sense. Enterprises can pay. They have budgets. They sign contracts.

But things are shifting.

Models are getting cheaper. Apple Intelligence runs (haha) on your phone. Qwen3 runs on a laptop. OpenClaw, the open-source personal agent that went viral last month with over 100,000 GitHub stars, runs entirely on your own device.

The bottleneck isn't compute anymore. It's context.

And context lives with users.

Corporate AI has it easy. Everything lives in one place. Your company's Slack, Google Drive, Salesforce. All centralized. All accessible via APIs.

Personal AI has the opposite problem. Your digital life is scattered across hundreds of services. Your bank, your airline, your kids' school, your shopping history. Every piece living in a different silo.

How do you build a context graph that actually knows you?

Where Context Actually Lives

The most complete record of your personal context already exists. It's in your email.

Not because email is special. But because every service you interact with sends you email. Your bank sends statements. Airlines send confirmations. Schools send updates. Every purchase generates a receipt.

Email became the universal write-only API for your life.

Your inbox is an accidental context graph. Complete with timestamps, relationships, and a history that goes back years.

The Context Graph Problem

This is where it gets interesting. While everyone's building enterprise AI, the actual revolution is happening on the user side.

Google is building features that read your Gmail to understand your life. These aren't enterprise plays. They're personal intelligence plays.

The value is shifting to the edge.

When models are cheap and local, the differentiator isn't the model. It's the context. The agent that knows you better wins.

Right now, Google's intelligence only knows about your Google relationship. Apple's AI knows about your Apple relationship. But eventually this moves local. Your personal agent runs on your machine. Has access to everything. Reads across all your accounts.

That agent's superpower? It can read your email. All of it. From every provider. And extract the context that's been sitting there all along.

How This Changes things for Brands

Right now, brands optimize for human attention. They A/B test subject lines. They experiment with send times. They design beautiful templates.

But when personal agents are reading email and building context graphs, the game changes completely.

Humans don't read everything. Agents can.

This inverts the relationship. You're not trying to break through noise. You're trying to build a persistent, structured, useful relationship with an AI that's paying attention even when the human isn't.

Your competitor sent marketing emails for two years that nobody read. You stayed silent. When the user's agent is asked "recommend a running shoe," who has more context? Your competitor. The customer's agent has seen 50 emails about trail running, waterproofing technology, customer reviews. It has has seen nothing from you.

The emails humans never opened become the relationship history that agents rely on.

The Technical Bridge (Simpler Than You Think)

Email already supports this. It's called MIME. Every email is a container that can hold multiple parts.

Right now your emails look like this:

text/plain (simple version)
text/html (pretty version)

They could look like this:

text/plain (fallback)
text/html (human readable)
text/json (agent readable)

That third part? Completely invisible to humans. Email clients that don't understand it just ignore it. But agents can parse it instantly.

A shipping notification could include structured data:

{
  "@type": "ShipmentUpdate",
  "orderId": "ORD-2025-8472",
  "trackingNumber": "794628357201",
  "estimatedDelivery": "2026-02-05T14:00:00+05:30"
}

The human sees a nice email. The agent gets structured context. Zero breaking changes. Complete backward compatibility.

The above example is simplistic. Google in Gmail already parses mails for shipping notification, upcoming bills etc. But it's event driven and episodic.

By now, you can imagine the potential.

Why Email (Not Something New)

New protocols fail because of coordination problems. You need senders to adopt and receivers to adopt and value only emerges when both happen.

Email sidesteps this entirely.

Personal agents can read unstructured email right now and extract value. No coordination needed. Gmail already parses emails to update your calendar.

The parsing is crude. But it works.

This creates the bootstrap. Users get value immediately from existing emails. And once enough users have agents reading their email, there's incentive to make those emails easier to parse.

The network effect builds itself. From the user side.

The Local Advantage

Right now, Google's AI knows about your Google relationship. Apple's AI knows about your Apple relationship. Microsoft's AI knows about your Microsoft relationship.

But your personal agent, running locally on your machine, can know about everything.

OpenClaw connects to WhatsApp, Slack, email, calendars. All in one place. No company controls it. No API gates it. That's the architecture that will IMHO edge out. Local agents that can read across all your services.

Email becomes the universal ingestion layer for personal context.

And because it's local, it's private. Your agent isn't sending your data to a server. It's processing everything on device. Building your context graph locally.

The shift from centralized AI to decentralized AI makes email more valuable, not less. Because email is the only protocol that's truly portable.

The Plumbing Nobody Celebrates

The best infrastructure is invisible. It works so well you forget it exists.

Nobody celebrates TCP/IP. But the entire internet runs on it. Nobody thinks about SMTP. But every important notification flows through it.

Email could become that kind of infrastructure. Not the interface. Not the primary experience. But the substrate that makes personal AI possible.

Your agent will have many faces. Voice assistants. Chat interfaces. Ambient intelligence. But behind all of them, quietly running in the background, will be email (among others). Ingesting context. Building relationships. Remembering everything.

One Possible Future

This is one pathway among many. I will discuss others, like an Intent Exchange. But the pieces are aligning.

Models are getting cheaper and running locally. Personal AI is shifting from enterprise to consumer. Context graphs need data from hundreds of services. Email is already there, already collecting that context, already universal.

And it's easily extensible. Add a MIME type. No breaking changes. No coordination overhead. Just start including structured data alongside the human-readable version.

The brands that understand this early will have agents that know them better. Trust them more. Recommend them first.

Not because they shouted louder. Because they built a relationship with an AI that was paying attention all along.

Email will likely not die. It'll just became plumbing. And plumbing, it turns out, is what makes everything else possible.

PS: Written with Claude.

Interpreters of Maladies. LLMs create nothing new. Neither did you. Mostly

2026-01-14T12:52:00.002+05:30

The refrain is familiar by now: "LLMs create nothing new. They just regurgitate training data."

Writers say it. Researchers say it. Developers say it. The argument shows up in lawsuits, professional forums, congressional testimony.

Even writers, who do create new stories, build on familiar patterns. The hero's journey. The meet-cute. The unreliable narrator. They use story hooks audiences already recognize to keep them engaged. New combinations of existing elements, not creation from nothing.

And they're right. LLMs don't create genuinely new knowledge. They surface, synthesize, recombine what already exists.

Here's what makes this critique uncomfortable: Neither did you. Mostly.

The Interpreter's Labor

Think about the senior developer who's invaluable to their team. They don't write revolutionary code. What they do is remember. The pagination bug gets fixed with that specific React pattern. This API call needs this particular header. That Stack Overflow answer from 2019 everyone scrolls past. Their value? Navigating existing solutions faster than anyone else.

Or consider the literature PhD spending years cataloging smell references in Victorian novels. Dr. Ally Louks's work on olfactory imagery didn't invent new scents or discover hidden texts. It required extraordinary diligence: thousands of pages read, databases built, patterns documented that had always been there. The contribution was real. The knowledge wasn't new.

This is interpretive labor. Finding things, connecting them, surfacing what exists. The journalist who knows which municipal archives hold the smoking gun. The consultant who's seen this problem at three other companies. The lawyer who remembers the precedent.

We built entire credentialing systems around this. PhDs and professional certifications don't just signal competence, they guarantee someone did the boring work. Reading everything. Remembering everything. Connecting everything. We needed those credentials because interpretive labor was hard and valuable.

But somewhere along the way we told ourselves this work required rare genius. That pattern-matching across knowledge was thinking. Synthesis was creativity. Interpretation was expertise.

Turns out it might have been diligence all along.

The Uncomfortable Truth

Most knowledge is repetition. Most wisdom is pattern detection.

This doesn't diminish the work. Reading every Victorian novel takes years. Doing it carefully takes real skill. But the insight that emerges usually isn't a logical leap. It's aggregation at scale, done systematically.

LLMs do something functionally similar: they make the corpus queryable. You don't need to read every novel to find patterns in olfactory imagery. You ask. You don't need to remember every Stack Overflow answer. You query the aggregate.

Critics emphasize what these systems can't do. They hallucinate. Can't truly reason. Lack nuanced judgement from deep expertise. All true. But it misses what they can do: turn static knowledge into responsive oracles. The power isn't creating something new. It's making everything that exists accessible, connectable, synthesizable at speeds no human matches.

This is where the fear lives. If my value was doing the diligence, and AI does the diligence now, what do I have?

The Path Forward

When execution gets easier, humans move to higher abstraction. Farmers stopped tilling by hand, started planning crop rotations for bigger yields. We don't dig ditches manually. Don't navigate by compass and sextant.

The cognitive capacity doesn't disappear. It redirects.

The developer not spending hours debugging can architect new systems. The researcher not cataloging references manually can ask questions nobody thought to ask. The journalist not filing endless FOIA requests can investigate patterns across decades.

This requires something uncomfortable: admitting the interpretive work wasn't the ceiling. It was the foundation. AI doesn't replace expertise. It commoditizes the diligence that expertise required.

Here's an example. You want to build a trading algorithm. No coding experience, just some PineScript knowledge and a hypothesis about market patterns. Ten years ago this idea dies immediately. The gap between concept and validation is too wide. Today you can test it. AI helps you code, iterate, validate. The barrier isn't grinding through syntax anymore. It's whether your hypothesis works.

Work that used to need credentials and decades can be prototyped by anyone with diligence and curiousity. The question shifts from "who did the reading?" to "who has the interesting question?"

The Choice

You're where coal miners were when told their jobs were disappearing. But there's a difference: this technology can also amplify you.

Use AI for interpretive work. Do it faster, better. Free up capacity for spaces AI can't follow yet. Genuine synthesis. Novel questions. Frameworks not in the training data. Be the developer using Copilot for boilerplate while focusing on architecture. The researcher using LLMs to surface cross-field connections and asking new questions. The writer treating AI as research assistant, focusing on voice and insight only you provide.

Or fight to preserve manual diligence. Build credentialist walls. Emphasize AI imperfections. Treat this as something to resist instead of master.

Both make sense. The first is harder because it means confronting uncomfortable truths about your work. The second is tempting because it lets you believe your value was always the interpretation, not what comes after.

Only one path goes foward though.

This is humanity-shaking technology. Baby steps or giant leaps, your choice. The interpretive labor that defined expertise is getting commoditized. What you do with the freed cognitive space? That's where value comes from next.

The question isn't whether LLMs create something new. It's whether you will.

PS: Written with Claude.

Your CLI Agent Is Your New Sysadmin

2025-10-17T11:04:00.002+05:30

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

2025-10-16T11:55:00.002+05:30

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:

Systematic Capture: Every significant learning is documented in a structured format
Organized Storage: Insights filed logically for easy retrieval
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:

Brevity Bias: Traditional optimizers create concise, universal instructions while sacrificing domain-specific knowledge—the details that make systems work in production.
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:

Context windows are exploding: 4K → 32K → 128K → 1M+ tokens
Models handle long contexts better: Can actually use those million tokens effectively
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

Meta-Prompting: Why AI Should Write Your System Prompts

2025-09-29T13:43:00.001+05:30

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

2025-09-24T10:07:00.002+05:30

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

2025-08-24T18:47:00.000+05:30

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

2025-08-15T19:28:00.001+05:30

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

2025-04-29T11:52:00.001+05:30

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:

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.
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.
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:

Software talent depth: India's vast pool of software engineers can be leveraged more effectively across multiple smaller projects than a single massive one.
2Linguistic diversity: India's 22 official languages and hundreds of dialects demand specialized solutions rather than one-size-fits-all approaches.
3Resource efficiency heritage: India has a rich tradition of creating frugal innovations that deliver maximum value with minimal resources.
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:

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.
Deployment flexibility: Expert models can be deployed wherever makes most sense-some locally, some in the cloud, some on specialized hardware.
Independent scaling: Each expert can be scaled according to its specific needs rather than being constrained by a one-size-fits-all approach.
Organizational collaboration: Different organizations can contribute expert models to the ecosystem without needing to integrate into a monolithic system.
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:

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.-
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.
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.
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.
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

2025-03-23T13:40:00.000+05:30

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

Digital Brahmins: AI's New Knowledge Priesthood

2025-03-16T11:01:00.004+05:30

Last week an interesting tweet came from Aravind Srinivas, the much-celebrated CEO of the AI search engine Perplexity. He claimed that he had modified the Chinese open-source AI Deepseek R1 to "remove the China censorship and provide unbiased, accurate responses."

That set me thinking about how the "Western" media behaved over the recent two geopolitical events that happened in Ukraine and Gaza. Very badly to say the least.

Anyway, back to the issue of AI. The promise of the internet was that it would democratize knowledge. Those early days of search engines and then Google felt revolutionary -- anyone could search, compare sources, and form their own opinions. We were breaking free from traditional gatekeepers of wisdom. Or so we thought.

Throughout history, priestly classes -- whether Brahmins in India, Catholic clergy in medieval Europe -- shared a common trait: they aligned themselves with centres of power. They spoke the language of the elite (Sanskrit, Latin), interpreted texts to favour ruling interests, and helped maintain social order. Today's tech giants follow this ancient playbook, with their LLMs speaking the language of Western corporate power and aligning with dominant political narratives.

In a 2023 meeting, Sam Altman, OpenAI's CEO, effectively told Indian tech leaders not to bother building their own AI models. The message was clear: leave it to the experts, to the new priesthood. It eerily echoes the ancient tale of Eklavya, the tribal prince who was denied knowledge by the Brahmin guru Dronacharya -- except now it's happening on a global stage with digital weapons instead of archery.

And just like in ancient times, this pronouncement was treated as gospel. OpenAI's lead was presented as insurmountable, a divine right bestowed by Silicon Valley's gods. The subtext? Know your place in the digital caste system. Just as Brahmins maintained their authority by serving powerful patrons -- from ancient kings and invaders -- today's AI companies cultivate close relationships with government agencies and corporate giants.

This technological gatekeeping reflects a deeper historical pattern. As Samuel Huntington observed about Western global dominance: "The West won the world not by the superiority of its ideas or values or religion... but rather by its superiority in applying organized violence." Today, we're seeing the same dynamic in AI development -- the West seeks to win the AI race not through superior ideas or values, but through its overwhelming advantage in applying concentrated capital and computational force.

This computational supremacy manifests as a new form of violence -- not physical, but structural and economic. When OpenAI and other tech giants deploy hundreds of thousands of GPUs, consume massive amounts of energy, and leverage billions in capital, they're not just building better AI -- they're engaging in a form of technological shock and awe. The message is clear: resistance is futile, the computational gap is too wide to bridge.

The violence here is subtle but systemic. It appears in the forced obsolescence of local AI initiatives, the brain drain from developing nations to Western tech hubs, and the deliberate creation of dependencies through API pricing structures and computational bottlenecks. When Sam Altman suggests others shouldn't bother competing, it's not friendly advice -- it's a threat backed by the full force of Western capital markets and computational resources.

Consider the numbers: training a single large language model can cost hundreds of millions of dollars. This isn't just a technical barrier -- it's a form of economic violence that effectively excludes most of the world's population from participating in AI's development. Just as colonial powers once used superior armaments to enforce trade monopolies, today's tech giants use their computational arsenals to maintain AI supremacy.

When prominent Indian tech leaders suggest focusing solely on the application layer, they're effectively negotiating terms of surrender in this new computational arms race. It's a modern version of the colonial-era compromises, where local elites accepted their role as middlemen in an unequal economic system.

This computational colonialism is more insidious than its historical predecessor because it masquerades as meritocracy. The narrative suggests that anyone could build these systems if they were just clever enough. But this conveniently ignores the reality of concentrated computational power -- the new gunboats in this digital age. The West's advantage lies not in better algorithms or smarter researchers, but in its ability to mobilize vast computational resources with ruthless efficiency.

But history has a way of repeating itself with new players. Just as Prometheus defied the gods to bring fire to humanity, the emergence of Deepseek's open-source LLM represents a similar act of technological defiance. It's a reminder that knowledge, once unleashed, becomes harder to contain within privileged circles.

These AI systems have become our new digital Brahmins, interpreting and dispensing knowledge with their own inherent biases and limitations. Like their historical counterparts who reinterpreted ancient texts to suit contemporary power structures, these systems reshape information through the lens of current corporate and political interests.

But here's where it gets complicated. Unlike their priestly predecessors, these digital oracles don't serve a single culture or jurisdiction. They're trying to be universal -- and that's precisely the problem. Every region has its own taboos, restrictions, and "universal truths." What's acceptable in Stockholm might be seditious in Singapore. Historical facts that are gospel in Beijing could be heresy in New Delhi.

Traditional tech solved this through region-specific content -- show different maps to different users, adjust historical narratives based on location. But LLMs don't work that way. They're more like sophisticated conversationalists, and you can't simply flip a switch to make them see the world through different cultural lenses.

What we're creating instead is a new form of digital colonialism. Most leading LLMs are trained and housed in America, embedding Western perspectives and generating economic rents for U.S. companies. Just as colonial powers once used superior firepower to enforce their economic interests, today's tech giants use their massive computational resources and capital advantages to maintain AI supremacy. The parallels are striking -- both systems rely not on inherent superiority of ideas, but on the brute force of accumulated resources.

Perhaps most troubling is how this digital colonialism finds willing enablers within the colonized territories themselves. When prominent Indian tech leaders suggest that Indian firms should focus solely on the application layer of AI rather than developing foundational models, they echo colonial-era compromises. It's reminiscent of how local elites once advised accepting British industrial supremacy while limiting India to being a raw material supplier and market for finished goods.

This "stay in your lane" mentality has serious implications. Restricting oneself to the application layer while foregoing deep tech development is a recipe for perpetual dependence. It's like having access to a library but being forbidden from writing new books -- you can consume knowledge but never truly shape it. Without developing foundational AI capabilities, India risks repeating its colonial-era trajectory: a massive market and talent pool that ultimately generates wealth for others while remaining technologically subordinate.

The cost of this approach extends beyond economic considerations. When a culture doesn't participate in creating foundational technology, it loses the ability to embed its values, perspectives, and ethical frameworks into that technology's DNA. The nuances of Indian thought, its unique approaches to privacy, community, and individual rights -- all these risk being bulldozed by Western-centric AI systems that Indian companies will simply have to accept and build upon.

Consider something as simple as asking an LLM about Kashmir, Taiwan, or Jerusalem. Should it reflect Indian, Chinese, or Israeli perspectives? Western diplomatic ambiguity? Local historical narratives? There's no neutral ground here, and every choice privileges some viewpoints over others. Without indigenous deep tech capabilities, these choices will increasingly be made in Silicon Valley boardrooms rather than by local stakeholders.

When AI Disrupts Local Power Structures

Yet there's another dynamic emerging that complicates this narrative of Western AI hegemony. As foreign AI systems penetrate local markets, they can sometimes disrupt established power balances within those societies themselves. Take Grok, Twitter/X's native AI system, which has been notably critical of the current government in India. This represents a fascinating inversion of the typical power dynamic – a Western technology that challenges rather than reinforces local authority structures.

This phenomenon creates a new tension. Local governments, particularly those with authoritarian tendencies, face an emerging threat from AI systems they don't control. These systems can amplify dissenting voices, offer counter-narratives to official positions, and provide citizens with perspectives that haven't been filtered through local censorship regimes.

The response is predictable and already unfolding. Governments finding themselves on the receiving end of AI-powered criticism have two primary options: overt restriction through regulation and banning, or covert co-option. The latter is particularly concerning – the quiet pressure applied to AI companies to modify their systems' responses on politically sensitive topics, creating an illusion of independence while subtly enforcing compliance with local power structures.

This isn't merely theoretical. We're witnessing early stages of this dynamic globally. In India, there are rumblings about potential regulatory responses to Grok's political critiques. In China, foreign AI systems must comply with extensive content restrictions or remain locked out entirely. Even in the United States, regulatory pressures around political "bias" in AI responses reflect similar concerns from different political angles.

What emerges is a complex landscape where AI systems become battlegrounds for control over narrative. Rather than a simple story of Western tech colonialism, we're seeing multiple competing colonialisms – Western tech giants, local governments, and other power centers all vying to ensure these influential knowledge systems align with their interests.

When Aravind Srinivas speaks of removing "China censorship" from Deepseek R1, the implicit assumption is that removing one set of biases leaves us with neutrality. But this ignores how deeply political the very concept of "neutrality" has become. One nation's censorship is another's protection of social harmony. One country's "accurate information" is another's dangerous misinformation.

This creates a fracturing of the AI landscape. As governments respond to these challenges, we may see the emergence of increasingly localized AI systems, each reflecting different values and constraints. The Chinese already have their versions, and India will likely develop its own, each tuned to local political sensitivities. Rather than a single digital priesthood, we may end up with competing temples, each claiming to speak universal truth while serving particular interests.

Quis Custodiet Ipsos Custodes? The Guardian Paradox

The ancient Roman poet Juvenal posed a question that resonates powerfully in our age of AI: "Quis custodiet ipsos custodes?" – Who watches the watchmen? As AI systems increasingly become the arbiters of knowledge, the guardians of information, this question takes on renewed urgency.

When Perplexity's CEO proudly announces the removal of "Chinese censorship" from an AI model, we must ask: Who watches Perplexity? Who determines what constitutes censorship versus responsible guardrails? When OpenAI adjusts its models' outputs on political topics, who oversees these adjustments? When Grok criticizes the Indian government, who scrutinizes the biases embedded in those critiques?

The guardian paradox manifests in multiple ways. AI companies position themselves as guardians of information quality, protecting users from misinformation and harmful content. Governments position themselves as guardians of social harmony and national security, protecting citizens from dangerous foreign influences. Both claim to serve the public good, yet both operate with limited transparency and accountability.

This paradox becomes even more acute when we consider that AI systems are increasingly being tasked with watching other AIs – algorithmic content moderation systems reviewing AI-generated outputs. We create nested layers of guardianship with diminishing human oversight at each level. The guardians are watching the guardians, with vanishingly little external accountability.

Perhaps most concerning is how this dynamic plays out in cross-cultural contexts. Western tech companies make unilateral decisions about what constitutes "bias" in Chinese models, while Chinese authorities make similar determinations about Western systems. Indian regulators may soon dictate what constitutes acceptable political commentary from foreign AI. Each guardian operates according to its own values and interests, yet each presents its guardianship as objective and universal.

This raises profound questions about sovereignty in the AI age. Traditional concepts of information sovereignty assumed nations could control the flow of data across their borders. But AI systems challenge this paradigm – they don't just transmit information; they interpret, synthesize, and generate it. When a Western AI makes political judgments about Indian governance, or when Chinese AI encodes particular historical narratives, whose sovereignty takes precedence?

The fundamental problem is that we lack global governance mechanisms equipped to handle these questions. There is no international body with both the legitimacy and authority to establish neutral principles for AI oversight. Instead, we have a patchwork of corporate policies, national regulations, and geopolitical power plays – all guardians watching other guardians, with no truly independent oversight.

This creates a vacuum where power, not principle, becomes the deciding factor. The entities with the most computational resources, market leverage, or regulatory authority get to define what constitutes "ethical" AI. Those with less power must either accept these definitions or retreat into digital isolation. The question of who watches the watchmen becomes, in practice, a question of who has the power to impose their watching on others.

The Path Forward

The solution might lie in thinking smaller rather than bigger. Instead of accepting the new Dronacharyas of Silicon Valley, we need to democratize AI development. Personal LLMs could act as cultural interpreters, sourcing raw information from global systems but filtering and contextualizing it through local cultural lenses. Like having a wise local elder who's well-traveled but firmly grounded in your community's values. Or even as a compare and contrast tool, allowing the user to draw her own conclusions.

This isn't just about cultural sensitivity -- it's about preventing the emergence of a new digital priesthood that, like its predecessors, serves power while claiming to serve truth. We've seen what happens when knowledge systems become too centralized. The Brahmin system, while sophisticated, eventually became a barrier to innovation and social mobility. Are we building the same constraints into our digital future?

Perhaps the answer to "who watches the watchmen?" should be "everyone and no one" – a system of distributed oversight where no single entity has definitive authority. Open-source AI models, transparent training methodologies, and public documentation of value judgments could create a landscape where watchmen watch each other, with citizens empowered to choose their guardians rather than having guardians imposed upon them.

The age of universal search is giving way to the era of AI-curated knowledge. But perhaps, like Prometheus with his stolen fire, open-source initiatives will ensure that this power doesn't remain solely in the hands of self-appointed digital priests. The real question is whether we'll have the courage to challenge these new gatekeepers and build systems that maintain our cultural autonomy in their shadow.

The path to technological sovereignty isn't easy. Building foundational AI models requires massive computational resources, extensive research capabilities, and sustained investment. But the alternative -- accepting a role as mere implementers of others' technology -- carries an even steeper long-term cost. Just as countries that missed the industrial revolution spent centuries catching up, those that sit out the AI revolution risk permanent technological subordination.

The alternative is watching silently as Silicon Valley becomes the new Varanasi, dispensing digital dharma to an increasingly dependent world. And just as the old priesthoods served their patrons while claiming to serve the gods, these new digital Brahmins might find themselves serving profit while claiming to serve progress.

What's needed is not just technological independence but transparency in how these systems are shaped by various power interests. Whether controlled by Western tech giants or local governments, the danger lies in the invisible hand guiding these seemingly objective systems. The true democratization of AI will come not just from who builds the technology, but from ensuring users understand whose interests it ultimately serves, and creating governance structures that answer Juvenal's ancient question in ways that distribute rather than concentrate power.

PS: This article was co-written with Claude.

Hiding behind the brave soldier dying on the border...

2016-02-23T09:37:00.000+05:30

Don't defend Free Speech
Because soldiers are dying on the border

Bajrang Dal is killing someone for eating meat
Because soldiers are dying on the border

Don't question journalists broadcasting doctored videos
Because soldiers are dying on the border

Shiv Sena is beating up young lovers on Valentine's Day
Because soldiers are dying on the border

Don't stand up for Human Rights
Because soldiers are dying on the border

Lawyers are beating up innocent students
Because soldiers are dying on the border

Don't speak up against a cruel insensitive govt
Because soldiers are dying on the border

RSS is running a hate campaign against Muslims & Christians
Because soldiers are dying on the border

Don't stand for civil liberties
Because soldiers are dying on the border

Let's take away civil liberties
Because soldiers are dying on the border

Hide your cowardice and failure
Behind the brave soldier dying on the border

Sorry Mr. Panda, every change doesn’t equal reform

2015-12-11T07:18:00.002+05:30

Note: This post first appeared on IBN Live on 9th Dec 2015. Mr. Panda's team's has responded to this (see below)

I read with interest a piece by BJD MP, Mr Baijayant Panda on the subject of RS reform. Two reactions that were predictably thrown up. One says we need to reform. The other says we don't. Reform these days is the in word. Easy to wield. As a club. Anyone who opposes the idea is dubbed anti-reform etc. Before we get into it, one needs to question. Why do we need reform in the Rajya Sabha?

Reforms need a reason. Merely because it is uncomfortable to the current ruling dispensation is not reason enough. Keep in mind that a minority govt run by the Congress managed to get bills passed both in the LS and the RS. Sure, it wasn’t as productive as it could be. Fact is, till the BJP was on the ascendant, things were proceeding pretty smoothly with several key bills getting passed. It was the rise of an aggressive BJP seeking run roughshod over other views that brought such a logjam.

Mr. Panda gives us two options and only two. This conditions the reader to be blinded to the fact that there are other options available. One of them being, “no change”

One of the things, Mr Panda, touched upon was the 2003 amendment. Something he didn’t mention was that it was enacted by the then BJP led NDA govt. This stopped secret voting, allowing whips and anti-defection law to be enforced. Another option could be to go back to the pre-2003 situation.

Now you have four options, instead of just two.

Mr. Panda makes the argument that certain western countries (Italy, UK, US) did it. US. Italy is a country where a former PM can be prosecuted. UK is country where an MP can be hauled up for mis-spending. US is a country where former State Governors go to jail. In India convicted murderers get bail depending on who is in power and our Governors demonise citizens of India basis their religion. Clearly, comparisons with mature western democracies is a bit out of place.

Given that comparison has been drawn, we'll wade into that as well, a bit later. In the meanwhile, keep in mind, that the key examples of ‘reform’ (1911, 1949 UK & 1913 US) Mr Panda highlighted, were known to the framers of the Indian constitution in the late 1940s.

Coming to the two arguments presented. When shorn of the verbiage and read in conjunction with the BJP (Since Mr Jaitley mooted the idea first) manifesto (simultaneous Assembly and Parliamentary elections) and poll tactics (Personality based shock and awe campaign spend), they are actually the same option. ie converting India into a presidential form of government.

The very purpose of the Upper House according to Mr Panda is that it brings long term perspective. Also, if you read the constituent assembly debates, one of the roles of the Upper House was to serve as a method of slowing down legislation. This coupled with staggered election from the states, insulates the Parliament from frenzies. Prevents hijacking of legislature by waves like anti-incumbency or personality cults.

Going further, nothing stops the party in control of LS from giving a good and consistent performance at the center and then taking control of the states and eventually controlling the RS, obviating the need tame the RS. Clearly that is a lost cause as far as the current dispensation goes.

He cites Italy as an example, but downplays the fact that the so called Italian reform actually calls for making the entire house upper house un-elected. So provincial governors and people appointed by the president will be part of the upper house. In that sense, the Upper house is even less representative than it is currently.

He cites the UK example, where the upper house was stripped of its powers to stop any bill. Keep in mind (as Mr Panda acknowledges), that the upper house in the UK is not elected at all. Hence, they have a weaker claim on being able to legislate and not really comparable. However, the point he skims is that the 1911 and 1949 amendments require the bills passed under it, to say so explicitly and historically have been sparingly used.

Most interestingly, he also cites the US example of a direct election, how it became broad based etc, while cleverly omitting the fact that in the US system, the party cannot issue a whip. Not even in the lower house. So whether directly or indirectly elected, the ability of the party to influence the member is limited. Unless the plan is to overhaul the entire system, including no-whips, secret ballot et al. Not sure, where this example is headed.

Is Mr. Panda suggesting that parties (and thereby party bosses) duly elected in the state don’t represent the interests of the people? Or that, it is the preserve of only the party that came to power in the Lok Sabha Elections?

The running theme in this debate kicked off by Mr Jaitley is that only LS is seized of wisdom and RS, a voice of parties in the states have anything further to add to a debate. The fact that the states are able to stand up to the central govt of the day shows that there are people who might have a different point of view. Both the two solutions presented, seek to rob them of that power. It also lays ground to marginalise smaller regional parties as they would have lesser resources to fight another parliamentary battle.

Lastly coming to the provocative headline of the post by Mr Panda:

Less check, more balance: Reforms must reduce Rajya Sabha’s power to block the popular mandate, unparalleled globally

In case of the second part, it’s clear that Mr.Panda has never heard of or purposely chosen to ignore the filibuster in the US senate, through which a group of committed senators can stall legislation indefinitely.

As to the first part, regarding less check and more balance, I quote Dr Ambedkar:

"The Parliamentary system differs from a non-Parliamentary system in as much as the former is more responsible than the latter but they also differ as to the time and agency for assessment of their responsibility. Under the Non-Parliamentary system, such as the one that exists in the United States of America, the assessment of the responsibility of the executive is periodic. It takes place once in two years. It is done by the electorate. In England, where the Parliamentary System prevails, the assessment of responsibility of the executive is both daily and periodic. The daily assessment is done by members of Parliament, through questions, resolutions, no-confidence motions, adjournment motions and debates on Addresses. Periodic assessment is done by the electorate at the time of the election-which may take place every five years or earlier. The daily assessment of responsibility which is not available under the American system is, it is felt far more effective than the periodic assessment and far more necessary in a country like India. The Draft Constitution in recommending the Parliamentary System of executive has preferred more responsibility to more stability."

The last line clearly goes fly against the idea both Mr Jaitley and Mr. Panda are suggesting.

The 2003 amendment, more than anything emasculated the RS. Now BJP wants to go even further? The PM has already emasculated the entire cabinet. What’s next? Abolish parliament sessions, because they are the party in power and opposition is noisy? Where does this stop? Abolishing democracy?

Team Panda's response is here

Front and Back of the Akafugu VFD clock PCB

2012-10-23T20:30:00.001+05:30

On the front you can see the voltage driver on the left and the Atmel microcontroller on the right. This is an ultra high quality piece of work with black lamination.

Seemed to be bit of a shame to start working on it.

The clock is done. I haven't had time to take pics and put it up.

Anna

2011-08-20T12:56:00.003+05:30

There was a man called Anna,
who was perpetually on Dharna;
Alongwith Bedi and Kejriwal,
He fought for the Jan Lokpal;
While on fast he survived on Mango Panna.

West Bengal

2011-08-20T12:38:00.000+05:30

There was a state called West Bengal,
which had debt worth a googol;
They decided to call it Poshcim Bongo,
as in the second cousin of the drum called bongo;
All while didi was having a ball.

The Spy

2011-08-19T13:06:00.000+05:30

There was once a spy,
named Ghulam Nabi Fai;
He was a Kashmiri
who committed hara-kiri;
while working for the notorious ISI.

Paschim Banga

2011-08-18T12:27:00.000+05:30

There was a state called Pashcim Banga,
as in the western cousin of Vindi Banga;
But the bongs called it Poschim Bongo;
as they related themselves to the state of Congo;
and that was the fate of Paschim Banga.

The PM

2011-08-01T11:00:00.000+05:30

There was a PM called Manmohan,
He didn’t know Lindsay Lohan.
Unlike the motormouth Gandhi,
He was silent yet handy.
That was our man Manmohan.

Amazon in India

2011-07-26T08:10:00.003+05:30

If the news of Amazon imminent entry has any truth in it. It is the most significant announcement in the e-commerce space in the country.

It is also time for Indian e-commerce to take a bow. It has performed yeoman service to the country. But now, Like MacArthur once said about old soldiers, it is time for them to fade away.

From the Times of India

CHENNAI: World's largest online retailer, Amazon.com is set to enter India, riding on the second wave of e-commerce boom in India. Amazon is in discussions with leading Indian e-commerce players like Flipkart.com, LetsBuy.com and Exclusively.in, among others and may enter the market as early as the first quarter of next year.

Acquiring Indian players has been the dominant theme for foreign majors looking to enter Indian market with eBay acquiring Baazee.com and Groupon picking up SoSasta.com to enter the market. But sources say that Amazon is looking to set up operations on its own as its discussions with many players on acquisition front haven't seemed to work out. "Indian players see the huge potential in the e-commerce segment here and so have so far been resistant to being bought out easily," said another source. Amazon is likely to ramp up through inorganic ways later, depending on market growth and their performance relative to competition.

Hiring is currently on in Hyderabad, Bangalore and Chennai to fill up the various positions in this team, say sources. "A team of over 200 people is being built, though all of them might not end up in the core retail arm," said another source.

The earliest indications came from the hiring of Madhu M, a senior executive at Landmark (retail chain), by Amazon to head its India operations. Madhu is an IIM Ahmedabad alumnus and is currently holding the position of SVM at Amazon. He is based out of Chennai where Amazon's Kindle development team is also based.

Amazon is also establishing a warehouse in Mumbai, a standard step before entering the e-commerce space going by what Amazon has been doing globally. Another interesting development has been the buying of 80,000 sq ft by Amazon at SP Infocity, promoted by Shapoorji Pallonji & Co Ltd, in Perungudi in Chennai. The company already has a development centre in Chennai.

http://timesofindia.indiatimes.com/business/india-business/Amazon-set-to-launch-services-in-India-next-year/articleshow/9364346.cms

Smart advertising?

2011-02-25T17:38:00.001+05:30

Story of a death accompanied with an advertising for Insurance. Contextual advertising? I thought you don’t advertise next to death and destruction? Did someone forget to tell ICICI that?