That’s me at the Glenfinnan Viaduct. Made famous by Harry Potter movies, with the steam train passing over it. Over the long Easter Weekend we went to the West Highland town of Fort William (also called the outdoor capital of UK) and went for a bunch of hikes around the area. Basically touched a lot of grass. Literally. Touched some snow too.

Didn’t open my laptop. Didn’t think about tokens or code. Was very much needed. Had been in a bit of a doom loop lately. (More on that later).

Came back hoping to attend AI Engineer Europe, especially to catch Mario Zechner’s talk on how he built Pi. Missed that because SEVs, meetings and workshops at work.

Instead went to this other hackathon by Tech:Europe. This was me going to a hackathon as a participant after maybe 5-6 years.

Anyway, so here I am writing this article, which…. in a long long time, has no AI involed in writing it. Not that I use AI to write articles (I do that sometimes), but of late almost everything I have written has had AI involved in some of the research. This one is me purely rawdogging thoughts on the keyboard.

Ok here go thoughts….

The AI Doom Loop

You know what it is all about. If you are hyper online like me and follow the zeitgeist. People have just not been feeling great. The fundamental feeling underlying all this is a crisis of identity. Writing code gave meaning, purpose, and jobs to many people. AI can do a that (jury out on how well, how long, etc, but it can.) Information workers are basically just scared that if AI is doing large parts of what they were spending hours at work till few years back, and with the pace of AI’s progress, what exactly does life look like in coming days?

The world is not in a great shape

There is war. There is genocide. Rents are high. Eating out is costly. Even people on fairly high paying tech jobs do not know if the job will last long enough. And every week there are layoffs of thousands of people.

Falling behind

The one thing almost everyone of my friends not working inside a Big Lab talks about is whether they are falling behind or not. The hype train on the internet doesn’t help. Am I using 1 agent, when others are using 10? Are my agents only doing 5 min jobs when others are running them overnight? What can I do more? How are people using up all of their $200 tokens?

Motion but no movement

(Like I said, not using AI to research, so not going and finding too many links for citations too). But there are already studies coming out externally, and if you’re in a big company which tracks these things internally, you’ll already see that the stats look a little like this

1. PRs merged, lines of code etc going up by 5-10x

2. hours people working going up by 2x

3. things being actually struck off from roadmap going up by only 30-40%

4. actual perceived improvement in products being 10% or even negligible

Where to point this cannon at?

In many BigTech companies a pattern emerging

1. leaderboards of ‘tokenmaxxing’

2. loss of psychological safety (layoffs)

3. fomo of not being ai-native

The way I think of ‘AI arriving to work’ is that imagine the SWE headcount just magically doubled. For example if your company had 1000 software engineers in Dec 2025, today it has 2000. (Is AI really 1:1 same as a SWE? Forget that question for a second, and indulge me)

What would really happen if this were the case.

• many companies (most?) just simply do not have the ability to absorb 2x-ing of SWE headcount. everyone says they need more devs to do more. but if you magically actually doubled their headcount, the org would just devolve into more chaos. most orgs which double in headcount in less than a year become a very chaotic place to work at.

• if leadership cannot figure out where to direct the new found productivity towards, cutting opex is a great way to increase stock price short term, and make space for capex (and everyone needs capex to buy GPUs and RAM today, directly, or buy tokens indirectly)

Just one more agent framework, bro!

The 2022 to 2024 years were a bit of a gloom in tech. No doubt. Nobody was even pragmatic (forget being optimistic) about any domain. The wider economy was stagnant, and within that, the tech sector was even more.

Last two years, lots of startups have been funded. AI has made truly incredible progress. We have had apps that go to 100M users and $100M ARRs in record breaking time.

But this is also a never before seen market, where anything apart from AI is still extremely pessimistic. AI, and only AI is where all the attention is. And within AI there are few things startups cannot do.

1. startups cannot build 10s of gigawatts of datacenters

2. startups cannot build new chips or memory, at scale

3. startups cannot train new models from scratch that are SoTA

(some startups do, but you get what I mean)

That has made this one very narrow little space where the entire VC capital and talent pool of the world jam themselves into.

“AI wrappers” and “AI infra”.

It is an unprecedentedly saturated space. There are the same 15 agentic products launching every day. Relentlessly. They are launching entire new ways of wrapping AI every week, at a rate at which no one can learn using the new one before yet another newer one lands.

Since there is neither any growth outside of AI, and no one is feeling hot about it, not one is getting funded outside AI, every bit of creativity and investment is going into AI tools. Tools to run under the AI, tools to run around the AI and tools to run on top of the AI.

But the problem is that tool → to make tool → to make tool → to make tool → to make….. at some point it needs to make something that is not a tool. There isn’t infinite demand for an infinitely long chain of tools.

Also building a new AI tool is much easier than doing one of the following things

• making the average order value of DoorDash orders go up by 10%

• making the avg revenue per ad on YouTube go up by 10%

• making the avg time spent listening to songs on Spotify go up by 10%

• making the avg wait time of Uber to reach you reduce by 10%

And no, giving any of those one line objectives above to Claude Mythos, will also not magically land you any results.

Glimmer of hope, and opportunities

Anyway fuck all that. Let me tell you why I am so happy after going to a hackathon.

By the way I didn’t even finish my own hack. Yes even with LLMs writing code, I am quite rusty after many years of not doing this. Also didn’t team up. And no, a 2-3 person team is still way more effective than just “teaming up with Claude”.

Anyway I did finish my little hack by the the end (just not in time for submission). Go and try it out if you’d like to - https://cityguide.arnav.tech/

Ideas aren’t stopped by the barrier of code

Some of the best demos I saw at the hackathon were very quirky ideas, and most importantly built by people who are not very adept at coding.

There were non-tech/non-engineer CEOs (with backgrounds as diverse, as a former orchestra conductor), to a 50 year old very sweet lady who has worked on writing stories and making comic books, to 19 year old design and theatre students building hacks.

It is so refreshing to see people who had all these weird, whacky, absolutely crazy ideas in their mind - where they can visualise what they want in their heads, but could never turn that imagination into reality, because they didn’t know how to use the tools to do it. And no AI frees them to do it. Not just code, but also,

• today someone who didn’t know how to do graphic design can also create images

• someone who can’t use Blender can render 3D visual effects

• people who have never opened a video editor can prompt AI to generate videos

• and finally prompt Claude or Lovable to wire all these things up together

Someone made an app that turns boring documents like legal contracts, negotiations into graphic novels and zines. They like comics. They hate paperwork. They vibe coded their ‘desire’ into reality in 4 hours.

Will this be a ‘product’ ? Will anyone pay money to convert contracts to comics ? Who cares! At least something like this doesn’t need to remain just a brainfart - it can actually be made. And out of 20-30 such brainfarts, suddenly one such idea might end up just flying?

I mean 20 years back people used to ‘Poke’ each other on Facebook. Not everything needs to make sense for it to become popular or fun.

Some very real ideas! And the need of more software engineering!

My favourite hack (I left early, but I hope they won!) was called Explodify, if I got the name right. So you might have seen products like Dyson or even smartphones advertise these videos where they explode the product to show the components inside?

Well these guys made an tool with which

1. you upload the CAD design of a product

2. pick the angle, rotation, explosion speed

3. some vibe-coded script does the 3d rendered explosion of the grey untextured CAD

4. you prompt what colors, textures, backgrounds you want

5. pass it through Kling

6. you get a polished video of the exploded view

First, imagine the possibilities. Making videos like this is costly. Why should a small manufacturer, not billion dollar one like Dyson, not be able to do the same?

Second - you can even make this video with a texture/color that your product doesn’t even have. And test the reception for it, before deciding to invest in that material.

I don’t know how it works but it does, and I made it in 5 hours

Two incredible facts

• this entire product (3d rendering script, exploding video, AI video to re-texture it) was made in 5 years by that team

• they didn’t know how their code worked.

  • it would work with <50 component CADs but not larger ones - they had no idea how to fix that

Most of the other ideas at the hackathon felt quirky and fun to me, but not something that can actually turn into a product that will see production usage. This one felt the most close to something that can actually be turned into a product/service someone will pay serious money for.

But for that to happen, someone will need to understand the 3D rendering code, and make it configurable, scalable to much larger CAD components.

Someone will also have to fine-tune video models on ‘retexturing’ such videos, because they were experiencing clear gaps in Kling’s ability to make certain shine/gloss appear correctly on some angles.

More AI hacks with less AI agents

I am gonna hope that

1. more AI hackathons take place

2. more people not from coding/tech backgrounds go there.

3. more ‘idea’ people should go and just vibe code their ideas to life

4. some ideas are considered ‘crazy’ or ‘pointless’ or ‘impossible’ by people who can write code, whereas those who can’t just vibe it into existence - more of that happening is great

5. some very real use cases (which is no yet more AI tooling) will come out of it

Not everyone needs to code make AI tools

I thought this article will not have a single link. (Discounting that YouTube video)

But here is a link anyway.

One of my favourite articles by Jeff Atwood (the guy who made Stackoverflow)

https://blog.codinghorror.com/please-dont-learn-to-code/

I loved the framing there that not everyone needs to learn to code. There’s a lot of other things to do in the world.

And I think the same argument can be made about AI tools. Especially AI agents.

Not everyone needs to make one. Forget outside the world of software engineering (which Atwoood wrote about), even within the domain of software engineering - there’s a lot more to do, and might I hope, a even more in future to do outside of making AI tools.

You still used your editor (the hottest game in town was Cursor - it was an IDE). You still had the files open. You were still the one writing the code, emotionally and literally. The AI was basically just a smart buddy guessing your next few lines (and eventually, the entire body of a function).

We’re not in that world anymore.

It’s not only that models got smarter. The actual unit of work we hand off has shifted. We aren’t asking for the next line or function any more. We’re asking for the next feature, a bugfix, a database migration, or a whole pull request. The machine isn’t just suggesting text, it is reading your repo, editing files, running bash commands, fixing its own typos, and coming back with something that genuinely looks like finished work.

This is why debating “real programmers” vs “vibe coders” feels played out. GitHub’s 2023 survey already called AI tools mainstream. Fast forward to 2025, Stack Overflow’s survey shows almost everyone is using or planning to use them. The big players aren’t hiding it either—Google admitted over 25% of their new code is AI-generated, and YC is seeing startups with 95% AI-written codebases.

So yeah, I’m not here to argue if this shift is happening. It’s already here. The real question is: what actually happens to our day-to-day programming when we stop caring about individual lines and move one abstraction layer up?

1. The Cursor Left the Editor

A lot of people think AI coding is just the same old job but on fast-forward.

It really isn’t.

The old way of writing code was super intimate. Open a file, write a function, agonize over variable names, tweak the signature, spot a code smell, refactor, change your mind, and finally land on something that works. Most of the actual thinking didn’t happen before writing the code—it happened while you were typing it out.

The new ‘loop’ is radically different. You just drop into a terminal or a chat UI and say: “build this flow, wire up that endpoint, migrate this module, write the tests, and fix the build until it’s green.” And then you just watch it go. Or honestly, if your test suite is solid, you don’t even watch. You go grab a coffee and come back to see if it actually did it or if it completely hallucinated.

And this isn’t some futuristic hypothetical. Anthropic already pushes Claude Code as the “first stop” for eng tasks. GitHub is pushing agent-mode hard so the AI just loops until the job is done. Even Google’s Jules tool straight-up assumes developers just live in the terminal now.

When that shift happens, something weirdly subtle disappears: the file itself isn’t your main workspace anymore.

It sounds like a minor detail, but it changes your entire relationship with the codebase. You aren’t molding the code line by line anymore. Instead, you’re describing what you want, setting boundaries, and checking the results. Sure, sometimes you step in and fix things manually. But if you start micromanaging the AI—getting mad about camelCase vs under_scores, or where a private helper method sits—you completely lose the massive speed boost this whole workflow gives you.

This is why I think the term “vibe coding” is kind of funny but also misleading. Karpathy’s joke hit hard because we’ve all been there. But as Simon Willison pointed out, not all of this is just blindly riding the vibes. There’s a serious version of this workflow where you actually understand the system, you write tests, you jump in when needed, and you own the final outcome—even if you didn’t physically type every single character yourself.

Whatever we end up calling it—agentic coding, or just modern software engineering—this is where the industry is going.

2. Bringing an Excavator to a Shovel Fight

I keep hearing the “pair programming with a robot” analogy. That doesn’t sufficiently capture the change. To me it feels more like the difference between digging a ditch with a shovel versus operating an excavator.

Yes, at the end of the day, you get a hole in the ground either way.

But being amazing with a shovel doesn’t mean you know how to drive an excavator. And mastering the excavator doesn’t mean you’d win a manual digging contest in someone’s backyard. They’re related, but they’re fundamentally different skillsets.

I bring this up because a lot of devs still talk about AI like it’s somehow “cheating” at shovel work.

It’s not cheating. It’s just a completely different process.

I felt this hard when I was messing around with some side projects recently. One was a CLI tool to sync .env files across my laptops. I hacked together an ugly prototype in bash first, and then wrote a lot of end to end tests for it. All of it with lots of help from AI ‘generating’ the code, but I did it all from a proper IDE. Then I let the AI rewrite the whole thing in Go while I just kept the test suite green. I just wanted to see what a cross-language rewrite feels like when the machine does the heavy lifting. Another project was a 2FA app where, using agents, I shipped clients for web, CLI, desktop, iOS, Android, Apple Watch, and Wear OS in a fraction of the time it would normally take me to hand-code all those different platforms.

Now, before anyone gets defensive, let’s be real: this doesn’t mean your enterprise day job is suddenly 100x faster. METR did a great study on experienced devs working on open-source repos and found that on gnarly, mature codebases, AI can actually slow you down. Legacy code has weird edge cases, migration headaches, and a ton of review overhead. AI doesn’t magically make that baggage disappear.

But for zero-to-one work? Prototypes, side projects, new features where you aren’t fighting legacy tech debt? The speed difference is so insane that pretending it’s just “a bit faster” is basically lying.

It’s not just about raw output speed. It’s about where you actually spend your brainpower.

When coding by hand, my brain was locked into the micro-details. Function signatures. Variable naming. If I made a bad choice at the low level, I felt the pain immediately while typing the next few lines. Like you make a function signature like

function doSomething(param1, param2, param3...)

then when using it you soon realise the number of parameters will increase eventually, and instead passing it in form of an object will be less disruptive to frequently updating the callsites so you change it to

function doSomething({param1, param1, param2...})

With agents, you zoom way out. I’m no longer saying “write a function that takes these three args”. I’m saying “make service A talk to service B, send an ID and a description, and honestly I don’t care if you use an enum or a string union as long as the tests pass.” That’s how a manager talks, not a coder.

This is why so many senior devs feel this weird disconnect right now. You aren’t coding less, you’re just coding from 10,000 feet up.

You can see this shift everywhere. Addy Osmani’s workflow is all about spending time on specs and architecture. Les Orchard’s routine literally boils down to writing a spec.md, generating a plan.md, letting the agent loose, and then reviewing the PR. Simon Willison nailed it when he said it feels like managing a super fast but overconfident intern. You just have to tell them exactly what to do.

You trade fine-grained control for massive leverage. You can’t have both. You can’t operate the excavator and still try to sift through every grain of dirt with your hands.

3. ‘Guardrail’ engineering

When you level up your abstraction, some of the older, boring tools suddenly become your best friends.

Testing is the obvious one.

When you write code by hand, the act of typing is how you maintain control. Your types, your function signatures, your if-statements—that’s where your discipline lives.

But when an agent is writing a whole feature for you, you can’t just dump a vague prompt and hope for the best.

If I tell an agent, “add cookie auth to this app,” I’m asking for a mess. It might invent a hybrid monster of JWTs, session tokens, local storage, and weird refresh logic. And if I just ask another AI to review it, we’re still just arguing over whether the code vibes correctly.

That just doesn’t cut it.

But if I write tests first—asserting the cookie is HttpOnly, the expiry works, cross-origin requests behave correctly—I suddenly have a hard boundary. I’m controlling the exact outcome instead of micromanaging the syntax.

Honestly, this makes Test-Driven Development (TDD) way more relevant now. Not because the old TDD evangelists were right all along, but because automated tests are literally the only way to steer an AI that writes code unpredictably. Anthropic spells this out—evals are just tests for AI. OpenAI’s docs say the exact same thing. We don’t care if the code looks pretty; we care if the system does what it’s supposed to do.

So the tools haven’t really changed. Tests, linters, CI/CD, type checkers—they were always good ideas. But now, they aren’t just the boring chores you do after writing the code. They are the steering wheel.

You can see the whole industry pivoting this way. GitHub’s agent docs and their product updates are entirely focused on isolated sandboxes, automated checks, and PR reviews. Hamel Husain has been shouting about “evals over vibes” for ages. Even Martin Fowler’s take on GenAI patterns hits the same point: when the AI is non-deterministic, “vibes” aren’t enough. You need hard checks.

When we wrote code by hand, control lived inside the syntax.
Now, that control has to live around the code.

4. Errors Now Hide One Layer Up

The wildest part about all this is that AI doesn’t just change how we write code, it also changes where the bugs hide.

When I typed everything manually, the slow, boring grunt work gave me time to think. While I was translating an idea into syntax, my brain was running a background check on the logic. I’d notice if a variable was redundant, if a security check was dumb, or if I was over-engineering a simple helper function.

When you abstract away the typing, you lose that built-in thinking time.

Here’s a real example.

I was building that .env sync tool I mentioned earlier. The idea, fairly simple: sync secrets across my Mac, Windows, and Linux boxes over my local network without hitting a cloud server. I told the agent the core requirements: LAN peer discovery, conflict resolution, use existing SSH keys.

The AI crushed it. It nailed the service discovery, the sync logic, the tests, the docs, and even wrote that overly eager README copy AI loves to generate.

But buried in all that great code was a totally useless security feature.

The AI decided to use AGE-based encryption at rest for the secrets. It sounded awesome in the docs. The README was flexing about how secure it was.

But it made zero sense for my setup.

These were all my personal machines. They already had SSH access to each other. If my laptop can SSH into my desktop to grab the encrypted files, it can just as easily grab the decryption keys too. The encryption was just security theater.

If I had coded this by hand, there was no question of me having made something like this. I would have considered a bunch of alternatives for the transport - say a custom Https/TLS server, or piggybacking over SSH/SCP. The moment I would have picked the later, it would simply never even be a consideration to then encrypt the secrets at rest with AGE. Because if I am already assuming the devices can read files from each other, including any ssh priv keys, what would the at-rest encryption even achieve?

If I had written encryption boilerplate first anyway before the transport, I would have stopped when implementing the SCP part and thought, “Wait, what threat model was I actually defending against here with that AGE encryption?”

But because the agent wrote it, the code just materialized. I only caught the flaw later when I was reviewing the system architecture and realized the AI had brilliantly solved a problem I didn’t actually have.

Now, if I was building this for untrusted devices, then yeah, I’d need actual transport security, pairing protocols, and encryption.

But that’s the whole point.

The AI didn’t write bad code. It just solved the wrong problem and confidently sold it to me as a feature.

This is a totally new class of bug.

This is exactly what Addy Osmani means by the “70% problem”. That first 70% feels like magic. But the last 30% is where the real engineering, edge cases, and architecture happen. It’s also why GitClear’s report on AI code quality is kind of scary—AI is great at churning out code, but terrible at refactoring and reflection. And Thoughtworks was right to warn us: AI can definitely help you build the wrong thing much faster.

In the old days, you’d catch these logic errors while sweating over the details.
Now, you have to actively hunt for them from a higher altitude.

5. Changing our priors

If this was just about individual devs typing faster, it wouldn’t be a big deal.

But it matters because our entire industry is built on assumptions about how we divide work, review PRs, mentor juniors, and track velocity.

And all of those assumptions were built for a world where writing the code was the bottleneck.

Take sprint planning and ticket sizing. We usually know exactly what kind of ticket goes to a junior, what subsystem a senior owns, and what architecture a staff engineer handles. That structure exists because we know how much complexity a single human can juggle.

Throw an AI agent into the mix, and suddenly a single dev can tackle a massive chunk of work. Anthropic’s internal research showed that AI isn’t just speeding up work—it’s empowering devs to take on massive refactors they wouldn’t have even bothered attempting before. The scope of “what’s worth doing” is expanding.

That doesn’t mean we just 3x the size of everyone’s Jira tickets. That’s a terrible idea (again, see METR’s study). It just means we need to recalibrate how we map seniority, task size, and review time.

Concepts like pair programming or mobbing are going for a toss too. The old model was one person driving, one person navigating. But if an AI is spitting out code so fast that two humans can barely read it, “watch me prompt” isn’t a great collaboration model. I bet live pairing is going to shift toward writing specs together, breaking down tasks, and designing tests, rather than watching a diff grow line by line. Let’s agree on the end goal before we let the AI loose.

And then there’s the code review. The sacred ritual.

We love to pretend that code quality is guaranteed because another human reads your PR. Honestly, reading code is harder than writing it, so that was always a stretch. But now? With AI generating massive PRs for free? The old review ritual is dead.

Sure, AIs are already doing code reviews. GitHub says Copilot has done tens of millions of them. Having an AI do a first-pass review is super helpful. But the real shift isn’t just using AI to read more lines of code. It’s about humans reviewing different things entirely.

Instead of nitpicking syntax, reviews need to focus on:

• What exactly changed?

• Why was this the right approach?

• Are the tests actually proving the behavior?

• What are the hidden assumptions here?

• What breaks if the AI hallucinated the requirements?

Those are system-design questions, not code-golf questions.

Seniority starts looking completely different in this world. You still need deep system knowledge, good taste, and the ability to dive into the weeds when things break. But your daily leverage comes from writing killer specs, breaking down problems, validating outcomes, and having the gut instinct to know when the AI is confidently solving the wrong problem. It’s like LeadDev said—engineers are becoming editors just as much as authors.

So yeah, we really are moving toward coding at a higher abstraction. I don’t mean that in a buzzwordy startup pitch kind of way. I mean it literally. The baseline level of how we interact with code has fundamentally shifted upward.

You can still write code by hand. Sometimes you should. Sometimes you just want to feel the code beneath your fingers.

But industrial construction isn’t going back to shovels.

At work, where large companies pay thousands of engineers money by the order hundreds of dollars per hour, there is no doubt, the demands of velocity and productivity will dictate that most code is generated via agents than written by hand. This new reality is here, and it is to stay. Love it or hate it, this is the way most code in 2026 or beyond will be brought into existence.

Unless you’ve been living under a rock... which is unlikely given you’re out here on niche Twitter reading articles written by me, you’ve heard non-stop coverage about Claude releasing “Claude Code Reviews”

The most incredulous thing about it is that they mention your cost for every code review will come out to be between $15 to $25 (!!!!) per review.

There are some incredible explanations being given like test-time compute (i.e. the more time the agent spends the more mistakes it finds), and that the reviews are done by multiple agents blah blah, but just hold on for a second. Let’s just take a cursory glance at the rest for the market for a second?

There is @greptile, @coderabbitai, @QodoAI, @cubic_dev_ and many more, apart from @GitHubCopilot‘s own code review. Literally all of them will come out to cost $0.50-ish per code review, and even for very large diffs, maybe $1~$1.5 per review - basically at least 10x or more cheaper than what Claude is claiming the price for each code review will be. On top of that almost all of them also have a generous free tier for open source projects.

In fact here is a list of links of some recent PRs in my personal side projects where I have gotten code reviewed by @QodoAI and@GitHubCopilot

All of them do a fairly great job - more than what I would have expected from myself if I were reviewing these PRs manually. They have noticed some mistakes that even I would have not easily noticed if I manually reviewed these PRs.

1. https://github.com/championswimmer/env.sync.local/pull/50

2. https://github.com/championswimmer/env.sync.local/pull/52

3. https://github.com/championswimmer/TwoFac/pull/44

4. https://github.com/championswimmer/TwoFac/pull/57

But wait, forget dedicated code-review apps for a second. In most coding agents (including Claude Code), you can just use the agent which you were using for writing the code itself to also forget all the context (become a fresh pair of eyes), and review the diff before even pushing to GitHub for a PR!

You can just add a `/review` skill that you run before creating PRs, or even add some lines in your system prompt that tells the agent to spawn up a new agent to do code review of the diff as the final step of every coding task. And I have never had the experience (however large the diff is) that running a code review via Claude Code or Codex made token cost be every above $3 for a review.

However many agents Claude spins up and however good the quality of their review is - it is just not worth spending $15 per review on it, when you can just automate running Claude Code itself with a “please review this” prompt on every PR created. And it will, for sure, cost less.

I do understand the motivation behind Claude releasing this product. After Claude Code being adopted like there is no tomorrow across organisations, I am sure Anthropic is finding exactly what I have been finding at work too - the major bottleneck today (the one on which leadership/execs are ready to burn their next SaaS procurement $$$ on - is review velocity), because there is already sunk cost in AI tools to generate code. And the historical bottleneck at the stage where software engineers convert “thought into code” has suddenly now evaporated. So the next bottleneck, the one that is stopping all the $ xxxK or $ xM of AI spend from magically converting into $xxM of ARR growth for every company, is the “slow review” issue. That’s what all engineers have been telling their leadership/execs for the last many weeks.

So when the sales team and the FDEs of Anthropic went to every million-dollar account and asked their CIO/CTO what is one thing for which they are ready to pay big $$$ for to “increase employee” productivity or whatever - I am sure all of them shouted out code reviews in unison. Hence, we are where we are.

Agentic Code Review Environments

All that said, I think we all are doing ‘agentic code reviews’ utterly wrong. Ok not entirely wrong, more like incomplete/inadequate rather than wrong.

You see, even before the AI era, when code was being written manually, even then, code reviews used to evaluate the ‘diff’ (pull request), at two different levels. One about just the the diff itself, and one in the broader context of what this change is trying to do for the larger system.

Yes the reviewer was looking at the level of the code itself. And they would make some comments like “instead of implementing this class twice separately, let’s make a common interface?” or comment on obvious security issues like variable being accessible from places it should not be and all that. But apart from the level of the design of code, and catching egregious coding bugs itself, a reviewer when reviewing the code would also make a mental model of the entire codebase, and reviews things from a higher level of abstraction too!

For example, I have often opened a PR review / diff review with some specific questions in mind already that I wanted to ascertain; like

1. now that we are adding 2 providers, are we making a common provider interface they both implement?

2. since we are adding this feature in UI that already exists in the CLI, should we not add the entire code here, and add a common implementation in the other repo (the core library) and just call it here?

Something like case (1) can even be ascertained just by looking at the `.diff` or `.patch` in isolation. Something like case (2), cannot be ascertained by an AI code reviewer which is only looking at the PR raised against the UI app, and doesn’t have access to the repo of the CLI or the core library (sure they could be in a monorepo instead, but you get my point - not all context for the review is necessarily available in the current diff itself)

So if the person generating the PR/diff is generating code using AI that read off material from outside the codebase (the prompt, the research the agent would have done, the docs it would have read, the RFCs etc it was fed), then for sure the person reviewing the PR also needs to have all that context? Right?

And if the person generating the code is scaling up using AI to write ever more and more code, the review side needs to scale up in the same manner, rather than just replace human reviews with AI reviews.

In fact, there are often PRs where you specifically tag an individual because you want specifically want them to look at it, and not just any other engineer in the team. In fact sometimes you tag multiple individuals, because you want all of them to review it with their specific perspective in which they evaluate the change, and you want all of their reviews before merging the code. The reason you do it because you want the code be reviewed no just as a collection of +++ and --- lines of addition and removals but with their specific context of something only they know, which adds value to reviewing the change you’re trying to bring.

What the current crop of AI reviews do is just provide static code analysis (codeQL etc) on steroids. See, that’s the whole meaning of the word static in static code reviews. That we are just reviewing the ‘code’ in its static state without running it or without putting it in the broader context of the rest of the systems. Human reviewers do not do static code reviews, their purpose is different.

So yes, not only is Claude Code Review not worth it at $25 or even $15, compared to its competitors, it is not even what you actually want to tackle the deluge of pull-requests at work. You solved coding velocity by giving coders an agentic environment to ‘generate’ code. You will solve review velocity by giving reviews an agentic environment to generate reviews, based on their questions, the things they want to ascertain in the diff and their specific context.

For static, drive-by PR reviews which just check if the current diff, in and of itself, is good or not, the existing players - @greptile, @QodoAI, @coderabbitai and even just @GitHubCopilot review are pretty good! Adding a skill/hook in your agentic harness to do a `/review` before raising a PR is also something you should bake into your workflow today itself. But none of that will do what the purpose of code reviews were supposed to be.

First two months of 2026 (we are yet to end Feb!) felt like watching a garage band go stadium in 10x fast forward. A few weeks earlier most people had not heard of Peter Steinberger's ClawdBot; then it exploded, got renamed 2x to MoltBot and then to OpenClaw within a week, and suddenly the repo was sitting above 200k stars, got covered The Register and shot up to first place on OpenRouter's rankings Overnight, the hype turned into real numbers: OpenClaw at the top by token usage, ahead of coding agents like Kilo and Cline who have been holding the spot for months! You could almost hear every "just another AI wrapper" take aging in dog years.

By February 2026, the plot upgraded from hacker lore to boardroom drama. On February 14, 2026, Steinberger wrote that he had spent the week in San Francisco talking with major labs before deciding to join OpenAI; on February 16, the move was all over the tech press in Steinberger’s post, The Register, and The Verge. From the outside, it looked like the same talent-and-product tug-of-war that has been building between OpenAI and Meta, but I am happy that the open source project finds a home under a foundation as noted in Steinberger’s post

Meta, by the way already was on a trajectory towards this vision of personal agents. On December 29, 2025, Manus announced it was joining Meta, framing it as acceleration for personal AI agents in Manus’s own announcement and The Verge’s coverage. Manus is impressive too, but it is built upon a completely different premise, closed, locked down, way more security focussed, and designed for enterprise and ‘normies’ to safely start using from day one. But that also means it is not hackable, not something you can run on your miniPC, nor infinitely extendable.

In all this hullabaloo, we may have missed one big shift: Both open source tools like OpenClaw and products like Manus feels like the first mainstream taste of a read-write-execute web, where your primary interface is an agent that can actually do things on your behalf. Call it “Web 3.0” if you want, with one delicious irony: we are using that label for Peter’s project even though he has repeatedly told the crypto-”Web3” crowd to stop harassing him for token launches, as Protos reported and in his own X post. History has jokes, and this one is on-brand.

I may be reading too many tea leaves here, but to me it feels we are at the turn of a generation for 'the web', even if we do not realise it right away. But when I try to answer the question "what category is OpenClaw", it automatically comes from that question. Just look at its Github Star history - not that it means anything but the only things this popular are usually operating systems, programming languages and web frameworks. And OpenClaw is neither of this right? But what if it is? A 'web' framework, but for a very different generation of web!

The Three Generations of the Web

To categorize OpenClaw properly, I want to look at the history of the web through the lens of data and interaction. The term “Web 3.0” got hijacked by the cryptocurrency era, but its lineage belongs to the Semantic Web, a “web of data” vision led by the W3C in the Semantic Web Activity, reflected in Semantic Web (Wikipedia), and in Berners-Lee’s Linked Data note.

The simplest framing is read → read-write → read-write-execute. Each era widens what a user can do, and each builds on the prior one rather than erasing it.

Web 1.0: The Static Library (1990–2004)

The first era of the web is often characterized as the “read-only” web, a digital archive of static information. In this period, communication was one way, from the author to the reader. Most consumers reached the web from desktop browsers and simply consumed pages rather than changing them. The dominant mental model was “sites” you visited with a browser, not applications you lived inside.

• Web Entities: The core pair was site + client. If you wanted to publish information, you created a site; if you wanted to consume information, you used a browser as the client. The dominant interaction pattern was retrieval, usually via GET requests for representations of resources, as outlined in MDN’s client-server overview, MDN’s GET method, and RFC 9110. In that sense, Web 1.0 built large shared systems of information, as described in W3C Web Architecture.

• Architecture: Content was stored as static HTML files. Publishers updated their sites via FTP.

• Interaction: Users were passive consumers. If you wanted to “interact,” you clicked a hyperlink to another static page. Web 1.0 is commonly defined in the Web 2.0 Wikipedia article as an era where content creators were few and most users were consumers of static pages. Interaction was primarily between publisher and reader, mediated by the browser.

• Open vs. Closed: In this era, the “Open” route was self hosting an Apache HTTP Server on your own hardware, giving you full control. The “Closed” alternative was providers like GeoCities, which offered ease of use but siloed your content under their domain and terms (”renting a home”). For background on this era framing, see Web 1.0 (Wikipedia) and research on Web 1.0 vs 2.0 differences.

The desktop browser era matters here. The web’s early growth was driven by general purpose browsers like Mosaic and Netscape, and by the late 1990s Internet Explorer dominated the desktop browser market for years, as documented in the History of the World Wide Web. The primary UX was the browser window, and the primary unit of experience was the site.

Web 2.0: The Social Database (2004–2025)

The second era, popularized by Tim O’Reilly, shifted the focus to the “read-write web,” the participatory web where the user can become the creator.

• Web Entities: The model expanded to database + API + app. The database became the primary store (SQL, NoSQL, and everything in between), the middle tier implemented business logic and exposed API calls, and the app (web or mobile) became the user-facing surface in classic IBM three-tier architecture and multitier architecture. This pattern is why Web 2.0 systems became strong systems of record, as described by IBM’s definition of system of record.

• Architecture: Sites became dynamic platforms powered by the CRUD pattern and massive, centralized databases. The web became a platform for applications rather than static documents in the Web 2.0 framing.

• Interaction: Interaction was no longer between publisher and reader, but between users. On Facebook or JIRA, you interact with others through a shared database row. “Write” unlocked user-to-user interaction and gave rise to platforms whose core value is orchestrating exchanges rather than publishing themselves. Platforms are intermediaries that enable interactions between distinct groups of users (a two-sided or multi-sided market), which explains why marketplaces and social platforms scaled so fast in two-sided markets and the platform economy.

• Open vs. Closed: The “Open” version of Web 2.0 meant using platforms like WordPress or Ghost, where you owned the database and the code. The “Closed” version involved blackbox platforms like Medium or Substack, where the provider managed the infrastructure and your data was a row in their table.

This is where “apps” became the dominant UX. A web application is software delivered through the browser, often backed by multi tier services that build responses dynamically and store state in centralized systems. The front end might feel like a single app, but behind it is an ecosystem of APIs and distributed services. Web APIs expose endpoints over HTTP, typically in JSON or XML, and became the connective tissue between systems and services. In practice, many apps also keep local state and synchronize with backend APIs periodically, especially in offline-first mobile patterns like Android’s offline-first architecture. This app-api-database loop is what let platforms like Google Workspace, Jira, Twitter, Facebook, Uber, and Airbnb become networked systems of record and participation at internet scale.

Web 3.0: The Agentic Orchestrator (2025–Beyond)

We are now entering the “Read-Write-Execute” era, where the web is no longer just a place to read or write, but a place to perform work via agents that can call tools, move data, and take actions. You are not just browsing sites anymore, you are delegating to a process that browses on your behalf. The building blocks are becoming standardized: tool and function calling, agent frameworks, and tool connectivity standards like MCP in the Anthropic announcement and the MCP docs. For a solid overview of the canonical agent loop, planning, memory, and tool use, see Lilian Weng’s survey on LLM Powered Autonomous Agents.
We can also trace the recent surge in tool using agents through “reasoning + acting” systems like ReAct, which helped popularize the loop of thinking, using tools, and iterating.

• Web Entities: The new entity on the block is the agent, and in practice it introduces two more entities around it: an orchestrator and a compute node (filesystem + CPU + memory + network) where long-running, tool-using workflows can execute and resume, as shown in LangGraph durable execution, OpenAI Operator, and OpenClaw architecture.

• Architecture: The focus shifts from centralized databases to personal nodes of compute. A Web 3.0 entity needs a filesystem and a CPU, a “scratchpad” and compute power in a box.

• Interaction: Agents and Orchestrators become first-class citizens. You no longer interact directly with every website; your orchestrator does. Agents can interact with Web 1.0 sites (read), Web 2.0 apps/APIs (transact), and increasingly with other Web 3.0 agents over interoperable protocols like A2A specification or just API-to-MCP-to-CLI wrappers, (refer GitHub project, and Google’s A2A announcement). A practical near-term example is your personal admin agent negotiating with a company support agent for refunds, reschedules, or exceptions before either side escalates to a human, like the service-agent direction described by Salesforce.

• Agents vs. Orchestrators: It is crucial to distinguish between the two. Agents like Goose or OpenCode are specialized tools for specific tasks, like coding. Orchestrators like OpenClaw, OpenHands, CrewAI, LangGraph, or Microsoft AutoGen are the conductors. They manage multiple agents, share context, and coordinate complex workflows toward a common goal.

• Open vs. Closed: We see this dichotomy again. The “Open” path is the OpenClaw model, DIY setup on your own persistent compute (VPS), giving you full “shell” access to the environment. The “Closed” path is represented by providers like Manus AI, which offer a blackbox, hosted agent experience where you have no access to the underlying execution environment.

In Web 3.0, agents become the UX layer. Instead of clicking through app UIs, you delegate to an agent that orchestrates the workflow and calls the underlying interfaces: APIs, CLIs, or MCP servers. MCP is explicitly designed to connect AI applications to tools, data sources, and workflows, acting as a standardized connector for these integrations in the MCP docs and the Anthropic MCP announcement. The web is still full of Web 2.0 services, but your primary interface becomes the agent that can reach them through their public APIs or command line tools.

The Rise of Personal Superintelligence

The phrase Personal Superintelligence is still young, and the most concrete public articulation comes from Mark Zuckerberg’s July 30, 2025 letter, where he argues that superintelligence should arrive as a personal extension that increases individual agency rather than a distant utility owned by institutions, as outlined in Meta’s letter, CBS News coverage, and a Business Insider summary. In that letter he defines the everyday shape of the idea, writing that a personal superintelligence should “help you achieve your goals, create what you want to see in the world, experience any adventure, be a better friend to those you care about, and grow to become the person you aspire to be,” in his Meta letter. The same document ties the concept to a form factor thesis, predicting that personal devices like glasses that can see and hear what we do will become primary computing devices, which implies a continuous companion rather than a sporadic chatbot, in both the Meta letter and CBS News coverage.

Press coverage repeats the human centric framing and emphasizes the infrastructure required to make it real, with Tom’s Hardware describing the goal as building AI that feels “like an extension of yourself” and noting the hardware stacks needed to deliver it at scale. The term itself remains concentrated around Meta’s messaging, which matters because it suggests that “personal superintelligence” is not yet a settled industry category but a specific thesis about control, agency, and interface, backed by the claim in the Meta letter that the coming decade decides whether superintelligence becomes a tool for personal empowerment or a force that displaces large swaths of society.

Sam Altman has been explicit, in the context of Steinberger joining, about “very smart agents” interacting to do useful work for people, as quoted by The Register. On the product side, OpenAI’s developer framing leans into this direction with agent workflows that emphasize tool use, memory, and orchestration in the OpenAI Agents docs, which is the technical substrate you would need if “personal” is meant to imply durable context and delegated action rather than a one shot chat session.

New Things Are Built on Old Things

Just to be clear, it is not like Web 2.0 replaced or wiped out Web 1.0. We still read static pages, even if we discover them via search and social feeds. Paul Graham and Joel Spolsky’s blogs will remain timeless artifacts on the web. The same pattern is likely here. Web 3.0 will not replace Web 2.0 any time soon, it will expand and augment on top of it. Agents will sit on top of apps, and the apps that are easiest to script through APIs and CLIs will have an edge. The rest will feel like old malls with no doors.

If you want a quick mental model, Web 1.0 gave us sites, Web 2.0 gave us apps, and Web 3.0 gives us agents on top of those apps. For publishing, the clearest shift from Web 1.0 to Web 2.0 is a static personal blog turning into a platform-native publication on something like Substack or Medium: drafts, subscribers, comments, payments, distribution, all inside one product.

What does not change is reading itself. A good essay is still a good essay. What changes in the Web 3.0 layer is discovery and curation: an agent can look at your recent activity, inspect your newsletters through Gmail, cross-check your day against your calendar, and re-rank your reading queue from Readwise for what matters today.

Travel is an even cleaner Web 2.0 to Web 3.0 story. Web 2.0 already gave us powerful specialist services and APIs for flights, for hotels, for rides, and for scheduling. A Web 3.0 agent does not replace those systems; it composes them, searching flights, reserving stays, booking the airport ride, dropping the itinerary into your calendar, and reshuffling the plan when something slips.

Agents as Web Entities

The web does not only mean ‘web’sites (it hasn’t been for a while, although we continue to use the term colloquially). If you map the generations by their dominant entities, the sequence becomes clearer:

• Web 1.0: site + client (browser) gave us systems of information.

• Web 2.0: database + API + app gave us systems of record and participation.

• Web 3.0: agent + orchestrator + compute node gives us systems of action.

In Web 1.0, a web entity needed storage for HTML. In Web 2.0, it needed a database and service layer (and often a smart client to store some frontend app state). In Web 3.0, it needs a scratchpad plus compute. That is why the filesystem and CPU matter. You are no longer just storing data. You are running a process that can read, write, and execute on your behalf.

From Accounts to Agents: How to ‘exist’ on the Web

In the Web 2.0 era, being a resident meant maintaining a collection of Accounts. If you wanted a job, you made an account on LinkedIn. If you wanted a cab, you made an account on Uber. If you wanted to book travel, you made an account on Booking.com. Each account was a static profile siloed within a platform’s database. But you owned some ‘data’ connected to that account, as you kept using the service your data increased. It was your data, even though the platform is usually the custodian of it.

In the Web 3.0 era, residency is defined by Agents. Instead of (not really instead of, more like in addition to) logging into a dozen platforms, you maintain a persistent compute node, essentially your own personal VPS or “always alive” compute box.

This node is the home for your orchestrator. You do not necessarily have a separate box for every task. Instead, your primary agent functions as a conductor, spawning subagents to handle specific workflows and terminating them once the job is done, for example the architecture shown here in AutoGen AgentChat docs.

This represents a fundamental shift from “Software as a Service” to “Software as Labor”. You are no longer just owning data. You are owning a remote execution environment that is continuously active. Your residency on the internet is defined by the compute power you command and the agents that live within it.

First-Class Citizens of the Internet

The Web has always had software agents, as W3C Web Architecture explicitly notes: browsers, crawlers, proxies, and servers are all agents in the system. But those were mostly deterministic workers, excellent at what was hardcoded and brittle outside it. What changes now is LLM-powered agency: systems that can reason about next steps, choose tools, recover from dead ends, and continue toward a goal in ambiguous environments, as seen in the ReAct paper, LLM Powered Autonomous Agents, and OpenAI’s ChatGPT agent announcement.

The infrastructure is finally catching up to that behavior. MCP (November 25, 2024) gives a common interface for tools and data in the Anthropic MCP announcement and MCP docs, A2A (April 9, 2025) gives a path for agent-to-agent interoperability in Google’s A2A announcement and the A2A spec, and product launches like OpenAI Operator and ChatGPT agent turned the idea from lab demo into everyday UX.

It is still worth being precise about language. “Web3” in popular usage usually points to crypto in Web3 (Wikipedia); “Web 3.0” historically pointed to interoperability and machine-readable semantics in W3C Semantic Web Activity. The agentic model is closer to that older lineage: open standards, portable context, and software acting on your behalf across systems.

That is why it feels fitting that this chapter is being turned by Peter Steinberger. In his own words, he is “a builder at heart,” a line also echoed by The Register. And during the rename chaos, he was blunt with token promoters and impersonators: he said he would never launch a coin and asked the crypto crowd to stop harassing him, as covered by Decrypt, Protos, and his own X post. If Web 3.0 is becoming the read-write-execute web, this is the poignant part: a builder is pulling the term back from speculation theater and returning it to software that actually does useful work.

The paradox of agentic engineering is all about not letting the code sprawl outside the bounds of what you can recover from. It is not very different from onboarding a bunch of engineers to your team as a technical founder, because you don’t have time for everything. It is all about figuring out exactly how to make sure you are still at the steering wheel of the entire thing, but still effectively delegating work to everyone.

The 3 Steps

When you think of building software, or adding one feature to an existing piece of software, there are 3 stages of the process.

1. Being able to describe what you want. In a startup, often you can just “verbalise” it, and in terms of agents your prompts are this. Your ability to exert “control” over where the software is going starts from here. The more you can describe exactly what you want, the closer to that reality you’ll get things. In fact some of the best outcomes I have got from both getting work done from junior engineers as well from Claude as been when ‘what’ I wanted to be built, I could completely visualise in my head. When I very clearly knew exactly how it would work and look and function even before it was built, it was always easier to get it built. I would imagine some of the most brilliant movie directors can see the movie in their head even before they make it.

2. Observing the code itself. Whether it is peering over the shoulder of a human software engineer while they code, or through the flickering CLI of Claude Code or Codex. Seeing the code appear - you start to make sense of how it is being implemented. Depending on how big the task is, and how complex the project already is, for smaller, simpler cases you can literally dry run in your head what is going to happen as each line of code appears. In your head you can see the variables moving from one register to another memory address, you can see the http port open and the bytes flow. And if you are 100% in control of this stage (as you are when you are writing the code yourself) you can stop the process in the middle if it is going in a direction vastly different from what you intended this thing to be.

3. Finally verifying that it does actually work the way you intended it to work. And this can either be extremely easy as ‘eyeballing’ it, or extremely tedious as testing the flow/process for every possible variant of data that will pass through this feature/pipe/function and making sure it does indeed respond to every input with the output that you want it to. Sure that’s all just an elaborate way to say the term ‘software testing’

Most of the process of building software (and getting software built) is doing these 3 steps over and over again.

Taking your eye off

The spiritual process of delegating the work (assuming initially you were alone doing the whole thing), either to other humans, or to agents, is gradually taking your eye off the middle stage.

You want to be able to take your eyes off. You want to feel less anxiety as you stop reading all of the code, and just glance it once. You want to trust your instincts that if the description of what you wanted was detailed enough, and as long as you can trust yourself to be able to evaluate the output later, you can let go of reading every character as it appears on the screen.

Everyone who has gone from being the sole developer of a project to onboarding more engineers to it - especially hiring juniors and letting them ramp up, has gone through the process.

There is a lot to make peace with here

• The code won’t exactly be what you would have written it had it been you at the wheel. That is fine. You are not at the wheel for a reason - you’re saving time to do other things only you can do

• Even when you evaluate it to do exactly what you intended it to do, the code could still have been less than optimal, or simply just not the way you would have wanted it to be have been written. You need to let that be. It is important it does what it was supposed to, not necessarily look a certain way

• The more it diverges from your vision of what the ideal codebase should have been, the less likely it is that you can fix it and rein it in if everything goes for a toss! Yes this is true, and this is the only part we need to talk about here.

Once you overcome the fear of delegation and the anxiety of “letting the agent rip”, you can truly free yourself up to think of many more ideas from the time saved from coding each one up. Anyone who has successfully levelled-up through delegating knows the journey.

Abstract, modularise, parallelise

The most important bit is calibrating your working style with agents to find the line in the sand on how much sprawl in the code is too much sprawl. How messy is too messy, and you need to pull back. How much of your nitpicky coding standards you can sacrifice, and at what point you need to pull hard stops at.

How to thread the proverbial needle?

Every day you let the agents write a bit more code that you wouldn’t trust it with earlier. Every day you keep your eyes off for a little bit longer. Every day you dip your toes a bit more into the waters of “parallel agents”. What if instead of one task, I give 5 agents 5 different tasks and then merge it all later? Tempting idea.

Delegating to humans is not a very different journey. Less experienced engineering managers and tech leads often say things like “don’t work on that part of the codebase, someone is working on things that will change it anyway”. As you master the art of orchestrating multiple people wandering around you codebase, you learn to modularise, create ‘contracts‘ between moving pieces, and make it easier for more and more people to simultaneously operate on the same parts of the codebase, and still keep the plates spinning.

Not letting it spin out of control

The hard part is not giving in to the lures of multiple parallel agents, and letting 10 of them make parallel changes to the codebase. The hard part is not in accelerating your output to 10x, 20x, 30x generating 100+ commits a day. The hard part is not riding the tiger 🐯. The hard part is to not fall off and also make it go where you want.

Every time the agent guesses something correctly that you didn’t specify in the prompt, you are tempted to be that little bit more ambiguous in your next one. Every time the agent writes yet another 5000 LoC commit, that is hard to read, but still passes all the tests, you are tempted to push it for an even bigger change. Every time the code review agent catches a mistake made by the coding agent, your are tempted to keep your eye on where the codebase is going a little less.

The hard part is learning exactly when did you and your army of agents truly cross the rubicon, the point of no return, the dark place where the agents are not doing what you want them to. Where you are unable to piece together the exact set of rules to test to evaluate you even are building what you want to build or not.

You now have fallen into a deep chasm between what you had started building from and what you wanted to build towards. A place from where you cannot “refactor” your way out of the unmaneuverability of the codebase. From where you cannot beat the immaleable codebase into shape any further. You kept your eyes off so long that you cannot start making your way into the impenetrable tangle of logic to untangle it anymore.

But you don’t reach this point completely unaware of it yourself. In fact, you feel the thrill of skating too close to the edge every time you merge some code that just felt off but it still worked. There is a hint of achievement every time you get soooo much more done than you ever thought was humanly possible, even though you are starting to see the seams giving away.

But you do have to fall into this hole once to even know it exists. To be able to retrospect and realise that the signs were there. It wasn’t that you were completely caught off guard, but that you knowingly let your guards down.

Drawing the line in the sand

How would you know the codebase is spinning out of your hand before the next time it happens? How do you know when to stop pushing the agents to more and more uncontrollable fission of the code?

While I don’t have very good answers (I am figuring out a lot myself), some of what I have figured, and from past experience of leading non-AI, actual software engineering teams are these

• Reproducibility > Magic. If you ever start feeling that the agent is conjuring up magical things that you didn’t even specify in your prompts, you are already on the edge. The more you rely on the agent taking good assumptions to fill in the gaps of your requirements to create what you wanted, the less you are in control of the destiny of the codebase.

• Every problem can’t be solved by writing more code. Many times you codebase needs to take a turn where it needs to shed some of the code. Sometimes you need to delete large parts of wrong direction you took. Often after wiring up a few complex flows, you discover commonalities and delete a lot of ‘WET’ code to make ‘DRY’ alternatives. Over the lifetime of a codebase, there must be changes that reduce the codebase too. If every change you are asking of the agents leads to them always writing more code (as they usually tend to), it again is a sign of a codebase sprawling out into something you won’t be able to tame later.

• You can only control what you can verify. Tests/evals/verification whatever you call it - the loop is finally closed by them. Even outside of objective test coverage percentage numbers - the less and less surface area of the codebase you feel there are some eval that covers, the less control you have over verifying everything works. Unit tests and other verification tools for small bits of the codebase are less helpful. The more end-to-end evaluation mechanisms you have, less you can worry.

If you let the agents loose through the codebase gradually, at a pace at which you can continue to handle the cognitive load of the speed of its expansion, you can continue to build it biggger and bigger, more and more complex. There is no limit to how complex a system one can design, as long as they keep “blackboxing” the correct abstractions.

It is wrong to conclude that there is always a certain size of codebase beyond which things will get outside your control and you cannot keep an eye on what is going on. Projects like OpenClaw, and OpenCode are being actively built in public by people who clearly are writing code via agents primarily, and are fairly large in size - not the size you can always keep entirely floating in your head. But as long as you can create these blackboxes in the codebase that in itself is a durable, robustly tested, and encapsulates a non-flaky part of the logic, you start thinking of the system as a composition of these boxes, and you only need to actively keep an eye on lines of code of only the parts that are currently moving fast, or changing.

But if you don’t, and once you let the Flying Spaghetti Monster™ consume your codebase, it is hard to go back.

We are currently in the “Geocities/Early WordPress” era of AI agents. If you look at the landscape, two distinct vibes are emerging, and they look suspiciously like history repeating itself.

OpenClaw: The WordPress of 2008

OpenClaw (and similar “yolo-mode” agents) feels exactly like WordPress in 2008. You know the vibe: wp-admin is exposed, the MySQL password is admin123, and there’s a growing list of plugins from questionable sources that might either give you a beautiful contact form or a crypto-miner.

It’s a duct-taped airplane. The wings are shivering, the rotors are violently shuddering, and you feel like it could crash into a RecursionError at any moment. You see the vibe coding slop across the board. The UI overlaps, tool calls fail constantly, and it never tries to hide that it was born in a 48-hour hackathon.

But, like WordPress, it’s free. It’s the “Wild West” where you have a full filesystem scratchpad, you can invoke ffmpeg, imagemagick, and pip install whatever you want in wanton glee. It’s agentic AI at its most chaotic and powerful.

Manus: The Medium.com Walled Garden

On the other side, you have Manus AI. Manus is the Medium of agents. It’s tight, locked down, and centralized. You can only “import” data from 10-15 official connections. It’s polished, sure, but the LLM is wearing a straitjacket. It can’t run a terminal inside a container; it can only use the limited Model Context Protocol (MCP) endpoints the platform exposes.

If OpenClaw is a jungle, Manus is a manicured lawn with “No Walking” signs.

The “Ghost in Docker” Stack

So, where do we go from here?

I think there’s a massive opportunity for the “Ghost in Docker” approach. We need a stack that has the “Convention over Configuration” ease of a 1-click deploy, but with actual security.

Imagine a main agent that acts as the orchestrator, and every time it needs to do something “dirty” (like running code or processing a PDF), it spins up a sub-agent in a transient Docker container. You give it a token limit, a time limit, and a specific set of tools.

This isn’t just “using an LLM.” This is owning a living-breathing “box” on the internet that has both compute and storage. It doesn’t live on a blockchain; it lives in a Remote Execution Environment.

The Austrians are Showing us the Future

While US and China lug it out in models and infra, the OSS-agentic space seems to be a bit of a Europarty right now.

OpenClaw by Peter Steinberger (a Vienna boy), is what made this all so popular. It is built on top of pi.dev as the core agentic loop made by Mario Zechner (of libgdx fame), also an Austrian and finally, the future of tighly controlled environment to run small agentic loops is coming from Gondolin being made by Erandil - also being made by another Austrian hero - Armin Ronnacher (who created Flask)

Short answer:

• Short term: not worried. because physics, and organisational inertia.

• Long term: not worried either, because economic realities and faith in humanity.

• Medium term: I am shit scared. We are ngmi.

Yes, this sounds inconsistent. So does everyone else’s AI take.

Right now the discourse is dominated by two kinds of LinkedIn philosophers:

1. AI is a toy, calm down.

2. AGI is next quarter, sell your furniture.

Both are lazy.

I am am Indian, currently living in the UK. So, congratulations to me, I get to be anxious in two currencies.

India has a massive services export engine (often cited around the $400B mark) that props up urban middle-class demand and local consumption loops (IBEF, Economic Times).

The UK is also a service-heavy economy; one UK government assessment puts services at 81% of output and specialized services near 85% of exports (GOV.UK assessment).

So if AI eats service work, this is not a small change for either place. This is the destiny.

Short term: calm down, physics still exists

The last few months have felt like hyper-acceleration.

A while ago the vibe was “slopocalypse“. Now the same crowd sounds like they have discovered vibranium: Andrej Karpathy describing a workflow phase shift and skill atrophy (Business Insider), Boris Cherny saying he no longer hand-codes (Fortune), Pete Steinberger talking about getting pulled into a vibe-coding rabbit hole (Business Insider).

Even commit-share estimates are no longer cute: one recent estimate puts Claude Code at about 4% of public GitHub commits, roughly up from the ~2% zone in prior low-single-digit tracking narratives (SemiAnalysis). Now it is real enough for CFO slides.

And yet, zoom out for two minutes.

In 2020, Sharif Shameem’s GPT-3 React-component demo made everyone go “oh damn, text can generate JSX” (Prototypr writeup). From that moment to now, it feels like yesterday. But it has been six whole years.

Why six years? Because software moves fast, reality has to scale walls of physics.

1. The strongest models today were literally trained on GPU generations and cluster scales that did not exist in 2020 (Deloitte).

2. They run in data centers that had to be financed, built, cooled, and connected to a strained grid (CSIS).

3. Power is now such a bottleneck that even shuttered nuclear capacity is being brought back for AI-era demand (e.g. Three Mile Island Unit 1 restart plan for Microsoft-linked demand) (AP).

Scaling from GPT-3 era toys to GPT-5.x era production agents is not just a model story. It is a semiconductors + grid + capex + regulation story. In other words: physics.

But that’s just the model. Physics is only half the drag. The other half is org charts.

We have already seen this movie once. It was called “digital transformation.”

That phrase became such an MBA meme that entire ecosystems were built around holding workshops about holding workshops.

And yet the underlying point was true: changing large organizations is painfully slow.

• McKinsey’s transformation research found overall transformation success below 30%, and digital transformation success at just 16% sustained success (McKinsey).

• In healthcare, moving from paper-ish workflows to EHR-heavy workflows took more than a decade at national scale; office-based physician EHR adoption went from 42% (2008) to 88% (2021) (HealthIT.gov).

• Federal legacy modernization moves in geological time: GAO’s 2019 list of ten critical systems had only three completed by February 2025 (GAO).

Now look at enterprise gen-AI adoption and the pattern is familiar.

• Workers are moving faster than institutions: 75% of people report using AI at work, but 78% of AI users bring their own tools because company rollout/governance lags (Microsoft Work Trend Index 2024, Microsoft release).

• At the org level, scaling is still the bottleneck: McKinsey’s 2025 survey says nearly two-thirds are still not scaling AI enterprise-wide (McKinsey 2025).

• Gartner found only 29% deployed GenAI (Q4 2023), with proving business value as the top barrier (Gartner).

And yes, before someone says “but adoption is exploding,” that is also true.

OpenAI says it crossed 1M business customers and 7M ChatGPT-for-Work seats (OpenAI, Nov 5 2025). Anthropic and partners are announcing giant rollouts like Cognizant’s 350,000-employee deployment (Anthropic).

So this is the correct short-term picture:

the coding crowd is sprinting,
vendors are scaling fast,
but legacy enterprises are still negotiating budget codes, risk committees, and compliance templates in triplicate.

Bill Gates’ old line still holds: we overestimate short-term change and underestimate long-term change (quote reference).

So yes, Twitter may feel like everyone is on Claude already.
But no, we still cannot fire all SDEs across the industry and replace them with infinite tokens this quarter.

Short term is still transformation, not instant replacement.

Long term: we will invent work, because capitalism needs customers

I am much less worried about the long term, and not because I am naive. Because I have seen humans.

Humans are unbelievably good at inventing activity, attaching status to that activity, building a market around it, and then calling it “career growth.”

Graeber called out the phenomenon years ago in Bullshit Jobs (Simon & Schuster). His framing was moral critique. I am making a colder macro argument: some of this “made-up work” is what keeps demand alive.

History already shows the pattern.

• In rich countries today, agriculture is tiny in employment terms: often just a few percent; OWID summarizes this shift across centuries (OWID insight).

• For a concrete modern anchor, OECD puts US agriculture at around 1.4% of employment in 2023 (OECD).

• Global employment shifted massively from farms to services: services rose from 34% to 51% (1991 -> 2019), agriculture fell from 44% to 27%, industry sat around 22% (OWID, ILO data).

So yes, maybe not literally 100. But effectively for a long time in ancient history, almost everybody’s day job was “help humans not starve.”

If you explained “SEO specialist”, “product manager”, “actuary”, “growth marketer”, or “developer relations engineer” to a medieval peasant, he would assume you were either joking or collecting taxes in a new way.

He would be wrong. We invented those jobs. We staffed those jobs. We made PowerPoints about those jobs.

And we will do it again.

Why? Because money has to move.

The equation of exchange is boring but brutal: MV = PY (money supply x velocity = nominal output). If V collapses, the machine chokes (ECB explainer, FRED velocity series). Rich people cannot spend for everyone else forever. If the mass market has no income, asset values become theatre.

We already saw a mini-version during the COVID shock: when spending froze, everything started seizing up fast (St. Louis Fed).

So yes, Dario Amodei can warn that entry-level white-collar disruption could be 50% in 1-5 years (Amodei essay, Axios interview coverage). That’s a serious medium-term warning, and I take it seriously.

But Dario’s default answer often sounds like “fine, then we redistribute and people retire early.” That’s what a brilliant lab founder says when he models systems. The real world is messier: people don’t just want income, they want role, status, routine, identity, and something to complain about on Monday morning.

Long term, “everyone unemployed forever” is not an economic destination. It is an economic segfault.

If machines did all useful work, humans would still invent new paid complexities and curiosities because that is what keeps society stable and markets alive. We literally built massive industries around non-essential fun: games alone support 350,000+ jobs in the US (ESA) and around 73,000 in the UK ecosystem (Ukie).

So my long-term bet is boringly human:

1. We automate old work.

2. We panic.

3. We invent new “real” work, plus some premium nonsense work.

4. We call it progress and pretend this was always the plan.

Medium term: this is the part that scares the hell out of me

So we are clear that ...

• < 5 years: mostly safe-ish, because transformation is slower than Twitter.

• > 20 years: probably safe-ish again, because humans rewire economies to keep money and meaning flowing (and yes, lower fertility means fewer net entrants in many countries, which eases some labor-pressure math at the margin) (OECD fertility trend, UN DESA fertility brief).

So what about the ugly middle: 5-20 years?

That part is terrifying.

Not because of a sci-fi “fully autonomous corporation” overnight.
Because leverage changes faster than institutions.

One senior who used to run 10 juniors can now instead supervise a farm of 20 AI agents running in parallel.

And this is no longer theory theatre:

• Anthropic’s own engineering post documents 16 parallel agents building a Rust-based C compiler across nearly 2,000 sessions (Anthropic engineering, Feb 5, 2026).

• Anthropic’s Opus 4.6 page explicitly positions the model for coding, agentic workflows, docs/spreadsheets/presentations, and financial analysis in enterprise contexts (Anthropic Opus 4.6).

• On legal reasoning specifically, Anthropic cites 90.2% on BigLaw Bench in customer testing (Anthropic Opus 4.6).

So medium-term risk is not “autopilot plus legal signoff.”
It is managerial span explosion.

One experienced human + many machine workers = fewer entry seats for humans.

India: when the seat-selling model gets kneecapped

India’s IT-BPM sector is huge (often quoted around $250B+ and 5M+ jobs) (IBEF).

India’s broader services exports are now near $400B ($387.5B in FY25 by official reporting) (Ministry/PIB release via Commerce, IBEF summary).

That sector historically monetized headcount. AI monetizes outcomes.

And we should be honest about the baseline quality problem in entry funnels.

• Mercer | Mettl’s 2025 graduate index puts overall employability at 42.6%, with technical-role employability at 42.0% and non-technical at 43.5% (down from 48.3% in 2023) (Mercer | Mettl PDF, Mercer summary).

• In BPM specifically, a NASSCOM-Indeed report (as cited by ET) says nearly four in five organizations see a widening demand-supply skills gap, and 47% cite lack of adequately skilled candidates as a top challenge (Economic Times report on NASSCOM-Indeed study).

A lot of enterprise math now starts with some version of this uncomfortable ratio: junior knowledge-worker salary vs agent-seat cost.

Now combine that with rapidly improving agentic capability (including multi-agent compiler builds and high legal benchmark scores in production narratives) (Anthropic engineering, Anthropic Opus 4.6).

The first jobs to get economically nuked are obvious: the “convert specs into code/process/output” layer.

Those roles are not morally worthless. They are just increasingly one-shottable.
If your core job is turning a ticket into predictable output, you are already competing with an agent farm; the redundancy is real, the news is just delayed.

If clients stop paying for seats and start paying for output, everything changes:

• junior hiring gets cut,

• margins get squeezed,

• top AI-native talent captures outsized upside,

• and the urban consumption flywheel takes second/third-order hits.

And that second/third-order part is the real fear.

Private consumption in India is roughly 61.4% of nominal GDP in FY25, with PFCE growth 7.2% (DEA Monthly Economic Review, May 2025).

If a large chunk of urban salaried demand gets hit, this is not just an IT payroll problem. This spills into restaurants, food delivery, entertainment, rentals, mobility, retail, and the entire ecosystem selling to the urban earning class.

Losing momentum in a near-$400B services-export engine is not a rounding error.

Can India adapt? Obviously yes.
Will that adaptation be socially painless? Obviously no.

UK: high-value services are still services

The UK story is not “factory robots.” It’s “time-sheet economics under algorithmic pressure.”

Official trade stats show where the exposure sits: UK services exports are led by “other business services” and financial services; “other business services” explicitly includes legal, accounting, and management consulting (UK Trade in Numbers).

This matters because billable hours are the revenue plumbing of large chunks of UK professional services.

And that plumbing is under pressure:

• Thomson Reuters’ UK legal market report says hourly billing still dominates (62%), but clients are pushing hard on value pricing (State of UK Legal Market 2025 PDF).

• In the same report, 64% of corporate legal teams and 58% of law firms expect a smaller share of hourly billing within five years (same report).

Inference from those sources: if legal pricing logic is shifting from time-input to value-output under AI pressure, accounting and consulting (which share similar time-based commercial DNA in many engagements) are unlikely to remain untouched.

Different unit economics from India. Same structural direction.

The part nobody wants to say out loud

The medium-term threat is not “no jobs”.
It’s “no ladder”.

If juniors are too expensive relative to AI, companies hire fewer juniors.
If fewer juniors are hired, the senior pipeline hollows out.
If the pipeline hollows out, the system becomes brittle.

Everyone says “be an AI orchestrator” like that’s a Hogwarts house assignment.
Nobody explains where that judgment is supposed to come from if apprenticeship disappears.

This is why the medium term is terrifying.
Not because humans become useless.
Because institutions become shortsighted.

My actual stance

• Short term: don’t panic. Learn faster.

• Medium term: panic a little. Learn much faster.

• Long term: trust adaptation, but don’t romanticize the transition.

If you’re in India, don’t assume the outsourcing-era ladder will save you.
If you’re in the UK, don’t assume professional services are naturally AI-proof.
If you’re anywhere, assume your current job description is a temporary document.

“AI will create new jobs” is probably true eventually.

“You personally will be fine during the transition” is not a claim any honest person should make.

First, we had the “autocomplete” era. Copilot, Cursor, the “tab-tab” life. You’d open your IDE, have the chat bar on the side, prompt a bit, edit a bit, and let the ghost text fill in the rest. It was a mix. A partnership.

Then came December 2025.

Opus 4.5. Gemini 3. GPT 5.2.

Suddenly, the game changed. We aren’t just “writing code” anymore. We are Vibe Coding. Andrej Karpathy coined the term a year ago, but only now, with these models, does it feel like the default reality.

You don’t tab-complete your way through a function. You prompt for the whole feature. You get an output. If you don’t like it, you don’t rewrite it manually. You prompt again. “Make this change. Add a test there. Fix that edge case.”

But this shift has introduced a massive, glaring bottleneck.

The Waiting Game

Here is the problem. You give the agent a prompt.

“Refactor this entire module, write unit tests for it, run the CI locally, and if it passes, raise a PR.”

Then... you wait.

2 minutes. 5 minutes. Sometimes 10 minutes.

While the model is chugging away, doing this long-running 10-minute job, your terminal is busy. Your local environment is locked up.

In those 10 minutes, you could go scroll Twitter or watch Instagram reels. But let’s be real, you want to be productive. You want to multitask. You want to open another project and start prompting a different feature.

But you can’t.

Because your “Gemini CLI” or “Cloud Code” session is hogging your local resources. You run into port conflicts. You run into file lock issues. You can’t easily spin up multiple sessions of these heavy agents on one machine without it turning into a chaotic mess.

The Manager Analogy

Coding is rapidly shifting from an Individual Contributor (IC) activity to an Engineering Manager (EM) type activity.

With these agents, you are effectively the manager or tech lead of a team of 4 or 5 junior engineers. They are fast, they are tireless, but they need your eyes on them. You stand behind their shoulder (metaphorically), watch them work, and correct them when they mess up.

Now, ask yourself this: Would you make 5 different engineers type on your single laptop?

No. That would be insane.

Real engineers have their own laptops. They have their own dev servers. They have their own user accounts. They have their own isolated environments where they can mess up, install dependencies, and run servers without crashing your machine. They make commits from their IDs.

So why are we trying to force 5 AI agents to run on our single localhost?

Enter Remote Execution Environments

This is where the industry is moving. We are going to see an explosion of Cloud-based Agents powered by Remote Execution Environments (REE).

We need isolated environments for development.

When you use ChatGPT (especially on the Pro plan), you are already seeing a glimpse of this. It has a “Code Interpreter” (or whatever they rebrand it to next). It spins up a sandboxed Python environment, executes code, calculates data, and gives you the result. It doesn’t ask to install Python on your Mac.

Look at Manus.im.

The Manus agent is a great example of where this is going. It integrates with your Gmail, your Calendar, your Notion. But to be a true “executive assistant”, it needs to do things.

It needs to fetch data, store it in a temporary folder, parse it, create an output, and send it somewhere. It needs to make API calls. It needs to execute code.

To do this safely and reliably, it uses an execution environment in the cloud.

“But what about MCP?”

I hear you already wondering. “What about the Model Context Protocol (MCP)? Isn’t that all you need”

MCP is great. Really, it is. It standardizes how LLMs connect to data sources. It lets the agent “read the manual”, fetch a row from a Postgres DB, or create a ticket in Jira without hallucinating the API schema.

But Context is not Compute.

MCP is a protocol. It defines how to talk to a tool. It does not define where the tool runs.

If you ask an agent to “debug why the build is failing on Node 22,” an MCP server can fetch the logs. It can maybe even read the package.json. But can it run npm install? Can it utilize strace to see what system call is hanging? Can it apt-get a missing library that the build script implicitly relies on? All of that requires your coding “agent” basically runs in --yolo mode with full terminal access.

Agents need to build their own tools.

In a real engineering workflow, you don’t wait for someone to write an MCP wrapper for kubectl or the aws CLI. You just install the CLI and run it.

We are seeing a shift where agents are using Skills and dynamic commands.

• They check if ffmpeg is installed. If not, they download a static binary.

• They write a temporary Python script to parse a messy CSV, execute it, and then delete it.

• They install a gemini-skill or a claude-tool on the fly to gain a new capability.

To do this, you don’t just need a “protocol” for function calling. You need a writable file system. You need a shell. You need root (or at least a very permissive user).

MCP is the menu; the Remote Execution Environment is the kitchen. You can’t cook the meal just by reading the menu.

The Future is 15 Agents in the Cloud

To understand why we are here, you have to look at the trajectory.

Back in 2023, we were obsessed with Cursor and GitHub Copilot. It was the era of the “Super-Autocomplete”. You typed function fetchUser(), paused for a millisecond, and the AI filled in the rest. It was magical, but it was still you driving the car. You were the pilot; the AI was the navigator.

Then came early 2025, and Andrej Karpathy dropped the term “Vibe Coding”. The shift was subtle but profound. We stopped caring about the syntax. We started caring about the intent. You’d paste a screenshot of a UI and say “Make it look like this.” The AI wrote the code. You didn’t even read it half the time. You just checked if it worked.

But late 2025 gave us Claude Code and the concept of Agent Swarms.

Anthropic realized something critical: One agent is not enough.

If you ask a single LLM to “refactor the auth system,” it will hallucinate. It will forget edge cases. It will break backward compatibility. It has a limited context window, no matter what the marketing says.

So they introduced Subagents.

Now, when you run a command in your terminal, you aren’t talking to one bot. You are talking to an Orchestrator.

1. The Orchestrator analyzes your request.

2. It spins up a Researcher Agent to read the existing docs and code.

3. It spins up a Plan Agent to draft a change strategy.

4. It deploys three Coder Agents to work on the backend, frontend, and database migration in parallel.

5. Finally, a QA Agent writes tests and tries to break the code.

This is the “Agent Swarm” architecture. It reduces hallucinations because tasks are atomized. It increases speed because work is parallelized.

But it kills your laptop.

You cannot run an Orchestrator and 5 sub-agents on a MacBook Air. You can’t have 6 concurrent processes fighting for the same node_modules folder, the same 3000 port, and the same file locks.

The CLI tools we love today will remain, sure. IDEs won’t die overnight.

But the “Vibe Coding” future is one where your “IDE” is effectively a command center. A dashboard where you dispatch tasks to 15 different agents running in 15 different cloud containers.

You prompt Agent A to refactor the backend. You prompt Agent B to update the frontend tests. You prompt Agent C to research a new library.

And you? You just sit back and review the Pull Requests.

It’s like being a Tech Lead with a team of 15 super-fast juniors.

Does it sound a bit soulless? Maybe.
Is it better than staring at a loading spinner for 10 minutes? Absolutely.

If you are still trying to run everything on your poor MacBook Air, you are doing it wrong. The future is remote, and the future is executed elsewhere.

Get your agents their own laptops.

When large organisations started introducing computers into the mix, it was transformative. You can’t imagine how many things we do in computers today was done by hand.

Memories I have from just my own lifetime - going to my father’s office seeing things you can’t imagine if you’ve only seen a post-2010 office setting

1. Physical inbox/outbox on desks of people containing files they are yet to read and sign and files they have signed

2. Office clerks wheeling in these massive stacks of files around

3. Accounting happening in actual large ruled sheets (spreadsheets anyone?)

4. Floor planning happening by drawing diagrams in blue ink on massive white sheets that will then by transported physically to another office for further drawing/verification

5. Almost all shipping/logistics accounting using registers with signatures and counter signatures

6. Obviously a bunch of cash/cheque/drafts used to move money around

I have seen all of these things happen as late as - late 2000s or early 2010s , that’s just barely 15 years ago. And yet, 15 years ago, companies like Google, Microsoft, Amazon, Facebook, Apple were not operating like that. They had moved to digital processes to handle all of this.

In my very early stages of career (moving ahead from my childhood) I have often come across people working in these big organisations in roles called “Digital Transformation” or the same. The people who typically call Tech as IT and so. This existed as late as early 2020s, no kidding. There are massive organisations employing hundreds of thousands of people spanning tens of countries working with billions of dollars of money, who still were on their last leg of digital transformation as recently as 5 years back. Think Target, Walmart, Honeywell, FedEx, Maersk. There are companies like Reliance in India which drive a meaningful % of GDP and yet are not fully digitally transformed.

As the AI wave sweeps across and creates yet another BC/AD divide in the timeline - of employees who are digitally adept but not “AI native” and those who naturally work with AI, the same transformation journey will play out.

There are entire industries (logistics, shipping, govt services, large scale retail) where none of the existing major players are going to transform to AI as fast as say FAANG companies or SaaS companies will do (because they are more adjacent to it). Without any competitive pressure, monopoly, duopoly or triopoly industries can afford to shift much slower. Sure you’re less efficient without AI but compared to whom when none of your competitors are shifting either?

In years to come there will emerge “AI transformation” specialists who’ll drop into these big slow moving ships to turn them around. Often these AI transformation gurus will not even be your typical AI-native hotshots like Karpathy or Boris Cherney or Peter Steinberger types. It is too tedious cumbersome and beneath them. It will often be past VP types from FAANG who saw the carpet shift from under their feet with AI transformation at their own workplace but learnt enough lessons from it to go and implement the same (while navigating the massive org complexities) at slower and larger orgs.

Sure this wave might play out faster than the digital transformation wave (it took GPT to reach 100M much faster than it took Google search to) but it’ll not be in days or weeks, definitely it’ll take years.

Exactly one year back I made the fateful decision to try dipping my toes in a part of the tech industry I have not remotely been close to - datacenters. Last 10 years I have built startups and led engineering teams largely around two things - edtech and consumer mobile apps.

A wonderful thing about bigtech hiring process is that often the hiring is generic to a role, and then you get to pick among various teams that have open headcount. (no other way hiring would scale to this size).

Felt like a great opportunity to explore something new.

Every time I have jumped into something new, I love how seeing an industry from the inside leads to insights that are not exactly 'secret' (because there is enough data in papers/blogs/quarterly earnings), but still not common knowledge across the rest of the tech.

In that regard, an interesting learning for me, exploring the world of datacenters, the economics and business of building and maintaining them, stuffing them with racks and helping grow "compute capacity" is how AI has changed some fundamental scaling laws.

Again, what I am talking about here is no "trade secret" (and neither can I actually share any such thing), and it is open knowledge among people who are closely following it, but it was quite interesting for me to learn how datacenter economics for 'compute' and 'storage' vary.

Before being in the space, as joked with many of my teammates when I joined, the meaning of "infra" to me was just running Kubernets on some public cloud. To be in the 'infra behind the infra' in some sense - actually planning how server racks are deployed, blew my mind.

This space is, unlike the consumer side of tech, largely dominated by economics and scaling laws similar to the ones that dominate manufacturing and supply chains. The business tracks various real world things like weight, energy density, heat output, power & water usage.

In that regard, the datacenter busines model, traditionally had two very different pillars of growth. "compute" and "storage". Regardless of what kind of software and usage was creating the demand, a lot of datacenter growth was about these two things

AI is a new third pillar.

So when you look at the economics of datacenters, business leaders look at things like - power - heat output - water use - weight - energy density - power spikes - network type And for 'compute' and 'storage' these metrics have very different relation to user growth

Compute: basically servers which are mainly used for CPU process (some GPU too for small-scale ML inference like feed/ad ranking)

Storage: servers mainly providing storage capacity for block storage (large media, images, blobs), to databases of various size and types.

To just highlight a few key differences in compute and storage

1. Energy Density

Compute: 10-30kw per rack

Storage: ~5kw per rack

Compute servers have might higher 'energy density' than storage, and thus also dissipate more heat than storage racks.

2. Weight Density

Compute: 600-700kg per rack

Storage: ~1200 kg per rack

Storage has platters and disks, and creates less heat so can be stacked more densely. (we are talking of traditional racks, not AI/HPC racks in compute here)

3. Network Interconnect

As a rule of thumb, Compute requires lower latency, while Storage requires higher bandwidth.

There are tons of nuances and how the network fabric created depends on the interconnect between compute & storage too, but generally the network needs are this.

The list keeps going on and on. But when you talk to very old school 'datacenter business' guys, who care about topline economic metrics of a datacenter, you'll notice they care about things like

• "how energy will scale with user growth"

• "how space usage will scale with user growth"

• "how water volume will scale with user growth"

• "how network bandwidth will... "

you get the gist ? And each of these graphs have different plots for storage and compute. Some scale superlinearly, some linearly, some sublinearly. But almost always they do not scale in the same way for storage and compute.

Now datacenters, although required to provide capacity to us techbros, are basically run by very old school factory/supplychain/facilities type people. They need to make 10 year plans around land prices, power use contracts, water availability, construction materials etc.

Most such 5-10yr plans have now become quite predictable because we know these relationships. If the hyperscalers can predict basically how many users, how many requests per second, how many petabytes of data will grow, the other tangibles like space, power, water can be planned

AI demand is a whole new beast in this equation. It doesn't fit the mould of traditional compute or storage. The racks are as heavy as storage racks. They are even more energy dense than compute. Their network interconnect is absolutely novel (400G full mesh)

And the 'shape' of AI demand is something no one has even figured out. Many clusters are being built for training (famously xAI's gigawatt cluster, and other similar ones by all hyperscalers). And then the idea is they can be turned into inference.

A training cluster does not magically convert into a inference cluster btw Training jobs are long running, synchronous steps, but batched jobs. Interruptible (via checkpoints). Needs huge clusters Inference is small, streaming steps. Cannot be interrupted. Needs tiny clusters

No one knows if a gigawatt sized cluster made for training a 1T sized model, can actually be converted to inference capacity for bunch of 10B -500B sized quantized models and at what time horizon turn a profit. And if the power/cooling that worked for training work for inference

So yeah, the builders and maintainers of datacenters are figuring out this 3rd pillar of datacenter capacity demand - AI. It is different from traditional two pillars storage and compute - which drove all the growth so far.

And no one truly knows the economics of this pillar

The predictability of storage and compute also allowed 'interleaving' them much better so far. No one makes a datacenter purely for storage or purely for compute. You spread them evenly, so weight per rack, heat per rack, energy spikiness all of all evens out.

Since the shape of AI demand (both, the shape of the peak demand, and the temporal shape of the load) is not yet well know, it is not yet well known what is the best strategy to interleave GPU/HPC racks with storage and compute racks.

What an interesting time to work here.

Why Would Atlassian Buy a Browser Company? An Agentic AI Play.

If you’re in the world of software, you might have seen the recent news or rumors about Atlassian and The Browser Company. At first glance, it’s a bit of a head-scratcher. Why would a company that builds developer tools like Jira and Confluence, a giant in the world of project management and collaboration, be interested in a niche, design-focused consumer browser?

It doesn't seem to fit. But if I had to throw my deterministic software engineering brain at this puzzle, I think there's a fascinating and deeply strategic angle here. This isn't about competing with Chrome. This is about owning the future of how work gets done. This is an agentic AI play.

Let's walk through the logic.

The Agentic Dream: From Task Tracking to Task Doing

Atlassian’s bread and butter is tracking work. But the holy grail of productivity in the AI era isn't just tracking the task; it's doing the task. Imagine this: you’re in a Jira ticket, and instead of just reading the description, you type a simple command into an AI agent:

"Create a new feature branch in the GitHub repo, set up the boilerplate code from the template, and assign the initial PR to the front-end team."

The agent just... does it. This is the promise of "agentic AI flows"—moving from passive documentation to active execution. The problem is, the platform where those tasks need to be done isn't always within Atlassian's control. The action might need to happen on GitHub, in a Salesforce record, on a Google Sheet, or within an SAP instance.

The Integration Nightmare

So, how do you connect all these platforms today? Through APIs and integrations. You can set up hooks, like a Jira task automatically creating a GitHub issue. These are basically hardcoded, IFTTT-like recipes: if this, then that.

But true agentic AI needs more. It needs to run a flexible loop: understand a multi-step task, perform step one, see the result, then decide on and perform step two, and so on. Hardcoding every possible permutation of multi-step tasks across dozens of external platforms is a non-starter. It's brittle, expensive, and a nightmare to maintain.

Atlassian needs a way to reliably operate on all these other platforms on your behalf. But how?

The Browser as a Universal Key

This brings us to the core of the idea. What if Atlassian could control the one tool where a user is already logged in to all those platforms?

Enter the browser.

The browser is the universal terminal for the modern web. You're already authenticated on GitHub, Salesforce, and Google Sheets right there. If Atlassian has access to a browser environment that you're using, they don't need to wrestle with a thousand different APIs and authentication protocols. They can "do things" on your behalf because they have access to a session that is already authenticated as you.

Meet the "Atlassian Browser"

Now, don't imagine Atlassian launching a colorful new browser to rival Arc or Chrome. It probably won't even look like a browser.

• It will likely be the Atlassian Desktop app, which is basically an Electron app (a web browser in a desktop shell).

• The "Connect your GitHub account" flow will change. Instead of a complex OAuth 2.0 dance, it will simply be you logging into GitHub inside the Atlassian app's embedded browser.

• Once you're logged in, the Atlassian agent has a sandboxed, authenticated "terminal" to operate on your behalf. It can now navigate, click, and type just as you would, to execute those complex, multi-step tasks.

So, Why Buy The Browser Company?

Of course, Atlassian has the engineering talent to build their own Electron app. So why buy?

1. Talent and Expertise. Building a robust, secure, and efficient browser environment is not trivial. The Browser Company team has spent years thinking about exactly this. For a company primarily based in Australia and India, acquiring a small, talent-dense team in SF/NY that has already dipped its toes in building agentic browser features is a fantastic strategic accelerant.

2. A Distressed Asset. Let's be honest, The Browser Company was likely on a distress sale after struggling to find a sustainable business model in the hyper-competitive browser market. This makes it an opportunistic "acquihire" for Atlassian—getting world-class talent and a head start on the technology for a good price.

It’s a classic build-vs-buy calculation, and in this case, buying gets them speed, specialized expertise, and a team that is already aligned with the vision of what a browser can be in the age of AI. It’s not a pivot; it’s an acquisition to fuel their core mission in a new paradigm.

Introduction: The Echoes of Revolution

The contemporary discourse surrounding Artificial Intelligence (AI) oscillates between unbridled optimism and profound existential concern. To many, this moment feels entirely unprecedented, a technological inflection point beyond compare. Yet, for students of technological history, the current fervor carries familiar echoes. The AI wave is not a singular, isolated phenomenon but the latest in a series of paradigm-shifting technological revolutions that have repeatedly reshaped the global economy, the nature of work, and the fabric of society itself. Just as the microprocessor democratized computation and cloud computing democratized infrastructure, AI is now democratizing intelligence. The patterns of disruption, adoption, and transformation that characterized these earlier waves provide a powerful and essential framework for understanding the opportunities and challenges that lie ahead. By examining the past, we can develop a more nuanced strategy for navigating the future.

The scale of the current transformation is, by any measure, staggering. The worldwide AI technology market is projected to experience explosive growth, with forecasts ranging from a market value of $190.61 billion by 2025 to an astonishing $1.81 trillion by 2030.¹ This expansion is underpinned by a forecasted compound annual growth rate (CAGR) of nearly 36% between 2025 and 2030, a pace that outstrips even the formidable booms of the cloud computing and mobile app economies in the 2010s.² The macroeconomic impact is expected to be equally profound, with AI projected to contribute an estimated $15.7 trillion to the global gross domestic product (GDP) by 2030.¹ This is not merely an incremental advance; it is a fundamental economic shift. The current frenzy of investment and development mirrors previous technological gold rushes, such as the dot-com boom of the late 1990s, which was fueled by the proliferation of the personal computer and the dawn of the public internet. That period of intense speculation and eventual market correction did not negate the long-term impact of the internet; rather, it was a necessary, if turbulent, phase in its maturation.⁵ Similarly, the AI era will likely see its own cycles of hype, consolidation, and stabilization. For leaders and strategists, understanding this historical precedent is crucial for distinguishing durable trends from transient bubbles.

This report will analyze the current AI wave through the lens of two preceding technological revolutions: the microchip and the personal computer, and the cloud. It will first deconstruct the era of centralized mainframe computing and the subsequent democratization of power unleashed by the microprocessor. It will then examine the transition from costly on-premise data centers to the flexible, utility-based model of cloud computing. Finally, it will apply these historical frameworks to the current AI landscape, analyzing its own era of centralization, its unique dual-pronged catalysts for democratization, and its transformative impact on business and labor. By tracing these parallels, we can identify not only what is changing, but more importantly, what fundamental principles of strategy, value creation, and human ingenuity remain constant.

Part I: The First Wave – From Centralized Power to Personal Empowerment (The Microchip Revolution)

The Era of "Big Iron" – Computing as a Priesthood

To comprehend the magnitude of the microchip's impact, one must first appreciate the landscape it disrupted. In the 1950s and 1960s, the world of computing was the exclusive domain of "Big Iron"—the colossal mainframe computers that occupied entire rooms and represented the pinnacle of technological achievement.⁶ These machines were not tools for individuals but institutional assets, accessible only to a select few within the largest corporations, government agencies, and well-funded universities.⁸ The term "mainframe" itself originated from the physical cabinets or "frames" that housed the central processing unit and memory, a testament to their sheer physical scale.⁷

The exclusivity of this era was enforced by prohibitive costs. A mainframe in the 1960s could cost millions of dollars, equivalent to tens of millions in today's currency.⁹ Even seemingly simple peripherals were astronomically expensive; a single IBM 2250 video display terminal in the mid-1960s cost over a quarter of a million dollars—nearly two million dollars today—making it as expensive as the mainframe computer it connected to.⁹ This economic barrier ensured that computing power was concentrated in the hands of a small number of powerful entities, creating a technological priesthood of specialists who were the sole intermediaries between humanity and the machine.

Interaction with these systems was a far cry from the direct, instantaneous experience of modern computing. The primary mode of operation was "batch processing".⁶ A user, typically a scientist or programmer, would prepare a task by punching instructions and data onto a series of cards. This deck of cards was then submitted to a computing center, where a specialized operator would feed it into the machine. The computer would execute the jobs in a queue, and hours or even days later, the results would be returned as a printout.⁶ This indirect, delayed-feedback model shaped the very nature of early software development and limited the scope of problems that could be addressed. While time-sharing systems emerged in the mid-1960s, allowing multiple users to connect to a single mainframe via terminals, this access was still mediated, expensive, and a shared, limited resource.⁸ Computing was a centralized, carefully guarded, and slow-moving utility.

The Catalyst – The "Computer-on-a-Chip"

The centralized paradigm of the mainframe era was shattered by a single, revolutionary invention: the microprocessor. This "computer-on-a-chip" was the catalyst that would democratize computing power on a scale previously unimaginable. The critical breakthrough came in 1968 with the development of the silicon-gate MOS (metal-oxide-semiconductor) chip, which paved the way for Intel to introduce the world's first commercially available single-chip microprocessor, the Intel 4004, in 1971.¹⁰ This remarkable device integrated all the core functions of a central processing unit (CPU)—arithmetic, logic, and control—onto a tiny piece of silicon.¹² As Microsoft co-founder Bill Gates would later remark, "The microprocessor is a miracle".¹⁴

The economic impact of this innovation was immediate and profound. It triggered a phenomenon of exponential improvement in performance and reduction in cost, an observation first made by Intel co-founder Gordon Moore in 1965 and later canonized as Moore's Law.¹⁵ Moore observed that the number of transistors that could be placed on an integrated circuit was doubling approximately every two years, while the cost of production was decreasing.¹⁵ This relentless, predictable march of progress became the guiding principle of the semiconductor industry for decades. The result was a precipitous and sustained decline in the price of computing power. One economic analysis of computer processors found an astonishing average annual price decline of nearly 20% between 1951 and 1984, a trend that accelerated for personal computer processors in the 1980s.¹⁶

The microprocessor's true revolutionary power, however, was not merely in making existing computers cheaper, but in fundamentally decoupling computational capability from a fixed, institutional location. Before the microprocessor, computing power was inextricably tied to the climate-controlled, secure rooms of large organizations.⁶ One's ability to compute was contingent upon physical access to these institutional behemoths. The microprocessor made it possible to create self-contained, powerful, and—crucially—affordable computing devices that could be owned and operated by an individual. This act of decoupling was the foundational event of technological democratization, setting a pattern that would be repeated in subsequent technological waves.

The Cambrian Explosion – The Personal Computer

The availability of cheap, powerful microprocessors unleashed a Cambrian explosion of innovation, giving birth to the personal computer (PC). This new class of machine shifted computing power from the hands of the "white-coated computer operator" directly into the hands of the "young enthusiast—students and entrepreneurs".¹³ The revolution began not in corporate boardrooms, but in the garages and hobbyist clubs of a new generation of technologists.

The Altair 8800, a mail-order kit based on the Intel 8080 microprocessor and featured on the cover of Popular Electronics in 1975, is widely considered the spark that ignited the PC fire.¹⁰ Selling for just a few hundred dollars, it was accessible to individuals in a way no computer had been before. Though it was initially a bare-bones machine with limited memory and no software, it tapped into a vast, latent demand, selling thousands of units.¹⁰ This created the first market for third-party software for a personal computer, famously met by a young Bill Gates and Paul Allen, who developed a BASIC interpreter for the Altair.¹⁰

This was followed by a wave of integrated, user-friendly machines that brought the PC into homes and offices. The Apple II, introduced in 1977, and the IBM PC, introduced in 1981, established the core architectures of the personal computing landscape for decades to come.¹³ While still expensive by today's standards, they were orders of magnitude cheaper than the minicomputers and mainframes that preceded them. An Apple IIe system in 1983 cost around $2,000 (equivalent to about $6,400 today), while a compatible IBM PC in 1985 could be purchased for $3,500 (around $11,000 today).¹⁷ For the first time, computing power was a capital asset that a small business or a middle-class family could realistically acquire. This democratization of access created a fertile ground for an entirely new ecosystem of hardware manufacturers, software developers, and peripheral makers, fundamentally reshaping the technology industry.

The Socio-Economic Transformation – The Rise of the Knowledge Worker

The personal computer revolution was not confined to the technology sector; it fundamentally rewired the broader economy and the nature of work itself. The widespread adoption of PCs in the workplace during the 1980s and 1990s automated a vast range of routine, manual, and clerical tasks. Jobs centered around typing, filing, and basic calculation—such as file clerk, switchboard operator, and secretary—were either eliminated or drastically altered.¹⁹

In their place, a new class of employee emerged: the knowledge worker. These were professionals, managers, analysts, and designers who used PCs as tools for communication, analysis, and creation.¹⁸ The demand for these digitally skilled workers surged. Economic studies attribute as much as 30% to 50% of the increased demand for skilled labor since 1970 to the spread of computer technology.¹⁸ This created a "hollowing out" or polarization of the labor market, with growth in high-skill cognitive jobs and low-skill service jobs, but a decline in middle-skill routine jobs.²⁰

This structural shift had profound consequences for wages and inequality. As the demand for college-educated workers who could leverage these new tools outstripped supply, a significant wage gap began to open in the 1980s between those with a college degree and those with a high school education or less.¹⁸ Industries that were early and heavy adopters of computers reorganized their workflows in ways that disproportionately favored and rewarded more educated employees.¹⁸ By 1993, nearly half of the entire U.S. workforce was using a computer at work, up from a quarter just nine years earlier.¹⁸ The PC had become the new crucible of economic opportunity, forging a new labor market that valued cognitive and digital skills above all else.

Part II: The Second Wave – From On-Premise Fortresses to a Global Utility (The Cloud Revolution)

The PC Era's Legacy – The On-Premise Data Center

The personal computer revolution successfully decentralized computing power to the desktop, but in doing so, it created a new form of centralized complexity for businesses: the on-premise server room. As companies digitized their operations throughout the 1990s and early 2000s, they relied on their own physical servers to run applications, host databases, and store data.²¹ This model required immense upfront capital expenditure (CapEx) on expensive hardware, dedicated real estate for server rooms with specialized power and cooling, and a team of in-house IT professionals to manage, maintain, and secure the infrastructure.⁵

This on-premise paradigm created significant barriers to innovation and growth, particularly for new and small businesses. Startups were faced with a daunting choice: either make a massive, risky investment in infrastructure before earning a single dollar of revenue, or make do with inadequate systems that couldn't scale.²³ Scaling was a slow, cumbersome, and expensive process, requiring the physical purchase and installation of new servers. Disaster recovery was another major challenge, necessitating redundant hardware and complex backup procedures that were often beyond the means of smaller organizations.²¹ Furthermore, the limited bandwidth of the early internet meant that keeping digital assets on-site was not a choice but a necessity.²¹ The IT infrastructure of the 1990s was a fortress—costly to build, difficult to expand, and a significant drag on agility.

The Catalyst – Virtualization and the API-Driven Utility

The catalyst for the second wave of technological disruption was the idea of abstracting away the physical hardware itself, transforming IT infrastructure from a capital asset that businesses had to own and manage into a flexible, on-demand utility. This was made possible by advancements in virtualization and the vision of companies like Amazon, which had built a world-class, hyper-efficient internal IT infrastructure to power its sprawling e-commerce operations.²⁵

In the mid-2000s, Amazon Web Services (AWS) began offering its infrastructure to the public, launching foundational services like the Simple Storage Service (S3) for data storage and the Elastic Compute Cloud (EC2) for on-demand processing power.²⁵ This marked the birth of modern cloud computing. The core innovation was not just technological but also economic. The cloud introduced a pay-as-you-go model, shifting IT spending from large, upfront capital expenditures (CapEx) to predictable, scalable operational expenditures (OpEx).²⁵ Businesses no longer needed to guess their future capacity needs and over-provision expensive hardware; they could now access precisely the amount of computing, storage, and networking resources they needed, when they needed them, and pay only for what they used.²⁴

This progression represents a higher level of abstraction in the ongoing story of technology. The microprocessor abstracted the complex workings of a CPU onto a single chip, freeing developers to focus on software. In the same vein, cloud computing abstracted the entire data center—servers, storage, networking, and all the associated physical maintenance—into a simple set of Application Programming Interfaces (APIs).²⁵ This profound shift allowed developers and entrepreneurs to stop worrying about racking servers and managing cooling systems and instead focus their energy on a higher-value problem: building innovative applications and services. Each wave of technology builds upon the last by hiding underlying complexity, thereby liberating human ingenuity to tackle the next frontier of challenges.

The Cambrian Explosion – The Rise of the SaaS Startup

The advent of cloud computing leveled the economic playing field for software development, igniting an unprecedented explosion of innovation and giving rise to the modern startup ecosystem. By providing affordable, on-demand access to enterprise-grade infrastructure, cloud platforms like AWS, Microsoft Azure, and Google Cloud Platform (GCP) effectively democratized the tools of production for the digital age.²⁷

This new paradigm drastically lowered the barriers to entry for entrepreneurs. A small team with a powerful idea could now develop, test, and deploy a global-scale application with minimal upfront investment, accessing the same powerful computing resources as the largest corporations.²⁷ The cloud dramatically reduced the cost of experimentation and, just as importantly, the cost of failure. Startups could launch a Minimum Viable Product (MVP) quickly and cheaply, validate market demand, and iterate based on user feedback—a process that would have been financially prohibitive in the on-premise era.²⁶ This agility and speed became the new currency of competitive advantage.

This fertile ground gave rise to a new species of "cloud-native" companies—businesses like Slack, Stripe, and Canva—that were built from the ground up on cloud infrastructure.²⁸ Their ability to scale rapidly, serve a global customer base from day one, and continuously deploy new features was a direct result of the cloud's elasticity. This era also cemented the dominance of the Software-as-a-Service (SaaS) business model, where software is delivered over the internet via subscription, eliminating the need for complex on-premise installations and maintenance for the end user.²⁷ The cloud didn't just change how software was hosted; it fundamentally changed how it was built, sold, and consumed.

The Socio-Economic Transformation – The Evolution of the IT Professional

Just as the PC remade the office worker, the cloud revolution profoundly transformed the role of the IT professional. The traditional System Administrator (SysAdmin), whose job revolved around the manual care and maintenance of individual, on-premise servers, found their core skills becoming obsolete.³² In the old model, servers were treated like "pets": unique, named, and lovingly nursed back to health when they failed. The cloud introduced a new model where infrastructure was treated like "cattle": identical, disposable, and managed as a collective herd.³⁴

This shift in mindset gave rise to a new discipline: DevOps. Breaking down the traditional silos between software developers (Dev) and IT operations (Ops), DevOps applies software development principles to the management of infrastructure.³³ The modern DevOps engineer is not a manual tinkerer but a strategic automator. Their toolkit includes version control systems like Git to manage configurations, Infrastructure-as-Code (IaC) tools like Terraform to programmatically provision resources, and container orchestration platforms like Kubernetes to deploy and scale applications automatically.³² The focus shifted from reactive troubleshooting to building resilient, self-healing systems through automation, continuous integration, and continuous delivery (CI/CD) pipelines.³³ The IT professional's value was no longer in their ability to fix a broken server, but in their ability to write the code that prevented the failure in the first place, or that could automatically replace a failed component without human intervention. This marked a significant up-skilling of the IT workforce, demanding a blend of systems architecture, software development, and strategic automation expertise.

Part III: The Third Wave – From Specialized Labs to Ubiquitous Intelligence (The AI Revolution)

The "AI Mainframe" Era – The Reign of the GPU Cluster

The dawn of the modern AI era bears a striking resemblance to the mainframe period of the 1960s. The development of today's most powerful AI models, particularly large language models (LLMs), requires a new form of "Big Iron": massive, purpose-built AI supercomputers. These systems are not built with general-purpose CPUs but with vast clusters of Graphics Processing Units (GPUs) or other specialized AI chips, numbering in the tens or even hundreds of thousands.³⁶

This has created a new era of extreme centralization, driven by astronomical costs and resource requirements. The hardware acquisition cost for a leading-edge AI supercomputer now runs into the billions of dollars; xAI's "Colossus" system, for instance, is estimated to cost $7 billion and require about 300 megawatts of power—as much as a medium-sized city or 250,000 households.³⁶ The computational performance of these leading systems has been doubling every nine months, a growth driven by deploying more chips and better chips in tandem.³⁶ This immense capital and energy barrier has concentrated cutting-edge AI development in the hands of a few technology giants and well-funded startups. Consequently, the private sector's share of total AI compute has surged from 40% in 2019 to an estimated 80% in 2025, while the share held by academia and government has fallen below 20%.³⁶ This creates a significant capability gap, echoing the 1960s when only the largest institutions could afford to be at the forefront of computing research.³⁷

The Dual Catalysts – Open Models and Edge Power

Unlike the singular catalysts of the microprocessor and the cloud, the democratization of AI is being driven by two powerful, parallel forces. This dual-pronged movement is lowering barriers to entry in two fundamentally different ways, promising an even faster and more diverse explosion of innovation than seen in previous waves.

The first catalyst mirrors the cloud revolution: the abstraction of complexity through APIs and open-source models. The release of powerful, open-source foundation models like Meta's Llama and Google's Gemma, along with the commercial availability of state-of-the-art proprietary models like OpenAI's GPT-4 via APIs, has been a game-changer.³⁸ This allows developers and organizations to integrate sophisticated AI capabilities into their products and workflows without needing to build and train these colossal models from scratch.⁴⁰ Much like how AWS allowed startups to rent a world-class data center, AI APIs allow them to "rent" a world-class AI research lab.⁴⁰ This dramatically reduces the R&D commitment and allows companies to focus on applying AI to solve specific business problems.

The second catalyst echoes the personal computer revolution: the rise of powerful local hardware capable of running sophisticated AI models. The development of consumer-grade chips with specialized AI accelerators, most notably Apple's M-series silicon with its integrated Neural Engine, is making "edge AI" a reality.⁴² These chips are optimized for the mathematical operations that power neural networks, enabling developers to run multi-billion-parameter language models directly on a laptop or smartphone.⁴² This is the modern equivalent of the PC breaking free from the mainframe's time-sharing terminal. Running models locally offers significant advantages in terms of cost (no API fees), latency (no network delay), privacy (sensitive data never leaves the device), and offline capability.⁴² This duality offers innovators a strategic choice: leverage the immense scale of cloud-based APIs for massive tasks or utilize the privacy and autonomy of local processing for personalized, real-time applications.

The Cambrian Explosion – The AI-Native Enterprise and Consumer

The convergence of these dual catalysts is already unleashing a wave of AI-powered innovation across both enterprise and consumer landscapes. Businesses are rapidly adopting AI, with 79% of executives reporting that it simplifies jobs and increases work efficiency.¹ Enterprise AI platforms from providers like Moveworks, Accenture, Microsoft, and IBM are being deployed to automate workflows, enhance employee productivity, and streamline operations across departments from IT and HR to finance and sales.⁴³

A prime example of an AI-native business is Spotify. For the music streaming giant, AI is not an add-on feature; it is the fundamental engine of its competitive advantage.⁴⁶ The platform processes over half a trillion user events—skips, saves, shares, playlist additions—every single day to feed the machine learning models that power its hyper-personalization features.⁴⁷ Products like the AI DJ, Discover Weekly playlists, and the annual "Wrapped" summary are all manifestations of a deep, data-driven understanding of individual user taste that would be impossible to achieve at scale without AI.⁴⁶ This focus on personalization creates a powerful user experience that drives engagement and loyalty, a strategic moat that competitors find difficult to replicate.⁴⁶ The company is now extending this AI-first approach to its own operations, piloting and deploying tools like Google's Gemini to enhance productivity for its 9,000 employees.⁴⁸

On the consumer side, AI has become an invisible yet indispensable part of daily life. An estimated 77% of devices in use today incorporate some form of AI.⁴ This is most evident in the widespread adoption of AI-powered voice assistants. As of 2021, there were 4.2 billion devices with assistants like Apple's Siri and Google Assistant, a number expected to double to over 8.4 billion by 2024.¹ These tools, along with smart speakers and the ubiquitous algorithmic recommendation feeds that curate our news, entertainment, and shopping experiences, have seamlessly integrated AI into the background of modern life.

The Socio-Economic Transformation – A New Labor Market Paradigm

The AI wave is poised to trigger the most significant labor market transformation since the Industrial Revolution. While previous waves automated manual and then clerical tasks, AI is beginning to automate complex cognitive tasks that were once the exclusive domain of highly educated knowledge workers.¹⁹ This shift is creating both anxiety and opportunity.

Forecasts from organizations like the World Economic Forum suggest a period of intense churn. By 2025, AI and automation could displace 85 million jobs globally, but they are also expected to create 97 million new roles, resulting in a net gain of 12 million jobs.² The jobs being eliminated are typically those that are repetitive and process-based, while the new roles demand new skills. Demand is surging for AI and Machine Learning Specialists, Data Scientists, Big Data Specialists, and Process Automation Specialists.¹ The very nature of existing roles is also changing; job postings for software engineers, for example, now increasingly list experience with LLMs and machine learning frameworks as requirements.⁴⁹

The dominant narrative among technology leaders is one of augmentation, not replacement. As former IBM CEO Ginni Rometty succinctly put it, "AI will not replace humans, but those who use AI will replace those who don't".⁵¹ This reframes the challenge from one of competing against machines to one of learning to collaborate with them effectively. The premium in the labor market is shifting toward skills that are uniquely human and difficult to automate: critical thinking, complex problem-solving, creativity, empathy, and collaboration.¹⁹ The future of work will not be a battle between humans and AI, but a partnership where AI handles the routine cognitive load, freeing up human talent to focus on higher-order strategy, innovation, and interpersonal connection.

Conclusion: The Unchanging Constants in a Sea of Change

Synthesizing the Pattern – A Predictable Revolution

The histories of the microchip, the cloud, and now AI reveal a remarkably consistent pattern of technological revolution. Each wave unfolds across four distinct phases:

1. Centralized Exclusivity: A new, powerful technology emerges but is initially accessible only to a select few due to immense cost and complexity (Mainframes, On-Premise Data Centers, GPU Superclusters).

2. The Democratizing Catalyst: A key innovation—technological or economic—dramatically lowers the barriers to access, abstracting away the underlying complexity (The Microprocessor, Cloud APIs, Open-Source AI/Edge Hardware).

3. The Cambrian Explosion of Innovation: Democratized access unleashes a torrent of creativity from a much broader pool of innovators, leading to the rapid formation of new products, companies, and entire ecosystems (The PC and software industry, the SaaS startup boom, the AI-native enterprise).

4. Socio-Economic Transformation: The widespread adoption of the new technology fundamentally reshapes the labor market, rendering some skills obsolete while creating massive demand for new ones (The Knowledge Worker, the DevOps Engineer, the AI-Augmented Professional).
   This framework is more than an academic observation; it is a strategic tool. It suggests that despite the novelty of AI, the trajectory of its integration into the economy is, in many ways, predictable.

What Doesn't Change – The Enduring Principles of Value

While the technological landscape is in constant flux, the fundamental principles of business success remain remarkably stable. Technology is a powerful amplifier, but it amplifies a pre-existing strategy. The companies that win in the AI era will be those that master the same timeless principles that determined success in the eras of the PC and the cloud.

First and foremost is the primacy of customer value. Technology is a means, not an end. Every investment, whether in a new server or a new AI model, must ultimately be justified by the value it delivers to the end customer—through a better experience, a higher quality product, or greater efficiency that leads to lower prices.⁵² The most successful and durable companies are those that cultivate passionate customer advocates, who in turn drive superior growth and profitability.⁵³

Second is the imperative of adaptation. In a rapidly changing environment, inertia is fatal. Businesses must be relentlessly proactive, constantly scanning the horizon for both threats and opportunities and demonstrating the agility to adjust their strategies accordingly.⁵⁴ Analysis shows that companies that invest in growth and innovation during economic downturns significantly outperform those that wait for certainty to return.⁵⁵ The most resilient organizations build "repeatable models" for success—core, differentiated capabilities that they can systematically adapt and apply to new markets and contexts.⁵³

Third is the need for strategic clarity and focus. The sheer number of technological possibilities can be a paralyzing distraction. Enduring principles like the Pareto Principle—the idea that 80% of results come from 20% of efforts—are more critical than ever.⁵⁶ Successful leaders must rigorously identify and focus their resources on the vital few products, customers, and activities that generate the most value. This focus is anchored by a clear and audacious purpose, which serves not only to inspire and attract top talent but also to provide a filter for saying "no" to the countless distractions that do not advance the core mission.⁵⁶

The Ultimate Differentiator – The Human Element

Perhaps the greatest paradox of the age of automation is that as machines become more capable of intelligent work, the value of uniquely human skills skyrockets. Technology does not make humanity obsolete; it makes our most human qualities the ultimate economic differentiator.

The PC wave automated routine clerical work, creating a premium for knowledge workers who could analyze, synthesize, and communicate information.¹⁸ The cloud wave automated infrastructure management, creating a premium for DevOps engineers who could think programmatically about complex systems and for entrepreneurs who could innovate on business models.²⁸ The AI wave is now beginning to automate routine cognitive work—summarizing text, writing code, analyzing data. Following this pattern, the most valuable and defensible skills will be those that AI cannot replicate: novel strategic thinking, empathetic leadership, cross-disciplinary creative problem-solving, and true, groundbreaking ideation.¹⁹

Technology, at its core, is a product of human creativity. It is the driving force that allows us to imagine new solutions and push the boundaries of the possible.⁵⁸ As Google CEO Sundar Pichai noted, "The future of AI is not about replacing humans, it's about augmenting human capabilities".⁵¹ The goal, as Ginni Rometty articulated, is to "augment our intelligence".⁶⁰ The winners of this new era will not be those who can build the most complex algorithm, but those who can most creatively and strategically apply these powerful new tools to solve fundamental business and human problems. As Steve Jobs famously said, learning to program a computer "teaches you how to think".⁶¹ The same is true for leveraging AI. The story of technology has always been a story of amplifying human potential. Each wave—from the microprocessor that put a computer on every desk, to the cloud that put a data center in every startup's pocket, to AI that now promises to put an expert assistant in every mind—is ultimately about the tools we build. The enduring lesson of history is that the tool is never as important as the vision, creativity, and wisdom of the person who wields it.

Works cited

1. Artificial Intelligence Statistics For 2025 - Search Logistics, accessed on August 17, 2025, https://www.searchlogistics.com/learn/statistics/artificial-intelligence-statistics/

2. AI Statistics 2024–2025: Global Trends, Market Growth & Adoption Data - Founders Forum, accessed on August 17, 2025, https://ff.co/ai-statistics-trends-global-market/

3. 50 NEW Artificial Intelligence Statistics (July 2025) - Exploding Topics, accessed on August 17, 2025, https://explodingtopics.com/blog/ai-statistics

4. 131 AI Statistics and Trends for (2024) | National University, accessed on August 17, 2025, https://www.nu.edu/blog/ai-statistics-trends/

5. The Evolution and Future of Data Centers | XYZ Reality, accessed on August 17, 2025, https://www.xyzreality.com/resources/evolution-and-future-of-data-centers

6. Mainframe computer - Wikipedia, accessed on August 17, 2025, https://en.wikipedia.org/wiki/Mainframe_computer

7. The origin and unexpected evolution of the word "mainframe" - Ken Shirriff's blog, accessed on August 17, 2025, http://www.righto.com/2025/02/origin-of-mainframe-term.html

8. History of computing hardware (1960s–present) - Wikipedia, accessed on August 17, 2025, https://en.wikipedia.org/wiki/History_of_computing_hardware_(1960s%E2%80%93present)

9. Big iron: 1960–1970. The first computers cost millions of… | by Adam Zachary Wasserman | HackerNoon.com | Medium, accessed on August 17, 2025, https://medium.com/hackernoon/https-medium-com-it-explained-for-normal-people-big-iron-6aee4e32ed51

10. History of personal computers - Wikipedia, accessed on August 17, 2025, https://en.wikipedia.org/wiki/History_of_personal_computers

11. A Microprocessor: Definition and Effect on Computer Science - JU-FET, accessed on August 17, 2025, https://set.jainuniversity.ac.in/blogs/what-is-a-microprocessor-and-how-has-it-changed-computer-science

12. Microprocessors: The Silicon Revolution - USC Viterbi School of Engineering, accessed on August 17, 2025, https://illumin.usc.edu/microprocessors-the-silicon-revolution/

13. Microprocessors: the engines of the digital age - PMC, accessed on August 17, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC5378251/

14. Bill Gates - The microprocessor is a miracle. - Brainy Quote, accessed on August 17, 2025, https://www.brainyquote.com/quotes/bill_gates_626246

15. Understanding Moore's Law: Is It Still Relevant in 2025? - Investopedia, accessed on August 17, 2025, https://www.investopedia.com/terms/m/mooreslaw.asp

16. The Postwar Evolution of Computer Prices - National Bureau of Economic Research, accessed on August 17, 2025, https://www.nber.org/system/files/working_papers/w2227/w2227.pdf

17. Were there people who spent too much time on their computers in the 80s? - Reddit, accessed on August 17, 2025, https://www.reddit.com/r/AskOldPeople/comments/1kstk0d/were_there_people_who_spent_too_much_time_on/

18. How Has Computer Use Changed the Labor Market? | NBER, accessed on August 17, 2025, https://www.nber.org/digest/sep97/how-has-computer-use-changed-labor-market

19. The Work Ahead | Findings - Council on Foreign Relations, accessed on August 17, 2025, https://www.cfr.org/task-force-report/work-ahead/findings

20. How is new technology changing job design? Updated - IZA World of Labor, accessed on August 17, 2025, https://wol.iza.org/articles/how-is-new-technology-changing-job-design/long

21. IT Evolution: The Shift From On-Premise Hardware to the Cloud ..., accessed on August 17, 2025, https://integrisit.com/it-evolution-from-onpremise-to-cloud/

22. On-premises software - Wikipedia, accessed on August 17, 2025, https://en.wikipedia.org/wiki/On-premises_software

23. "How can startups make use of cloud services" by Gauri Nade and Gauri Nade, accessed on August 17, 2025, https://scholarworks.lib.csusb.edu/etd/1262/

24. Cloud Computing: The Go-To Solution for Startups and SMBs to be cost efficient - Holori, accessed on August 17, 2025, https://holori.com/cloud-cost-startups-smbs/

25. The Simple Guide To The History Of The Cloud - CloudZero, accessed on August 17, 2025, https://www.cloudzero.com/blog/history-of-the-cloud/

26. How Cloud Services Are Transforming Small Business Growth, accessed on August 17, 2025, https://syslogic-techsvc.com/2025/02/20/how-cloud-services-are-transforming-small-business-growth/

27. Why Startups Need Cloud Computing? - Adivi 2025, accessed on August 17, 2025, https://adivi.com/blog/startups-need-cloud-computing/

28. (PDF) The Impact of Cloud Computing on Startup Ecosystems and ..., accessed on August 17, 2025, https://www.researchgate.net/publication/391162451_The_Impact_of_Cloud_Computing_on_Startup_Ecosystems_and_Entrepreneurial_Innovation

29. Cloud Computing: Leading the Next Wave of Innovation - Digital Experience Live, accessed on August 17, 2025, https://www.digitalexperience.live/cloud-computing-leading-wave-innovation

30. Digitalization, Cloud Computing, and Innovation in US Businesses - National Center for Science and Engineering Statistics, accessed on August 17, 2025, https://ncses.nsf.gov/pubs/ncses22213/assets/ncses22213.pdf

31. The Role of Cloud Computing in Scaling Startups: Balancing Technology and Business Growth - ResearchGate, accessed on August 17, 2025, https://www.researchgate.net/publication/387065928_The_Role_of_Cloud_Computing_in_Scaling_Startups_Balancing_Technology_and_Business_Growth

32. Transition from SysAdmin to Devops what does it require - Reddit, accessed on August 17, 2025, https://www.reddit.com/r/devops/comments/1ijbwdq/transition_from_sysadmin_to_devops_what_does_it/

33. A Complete Guide To Transition From a SysAdmin to DevOps Role | by DevopsCurry (DC), accessed on August 17, 2025, https://medium.com/devopscurry/a-complete-guide-to-transition-from-a-sysadmin-to-devops-role-8ffab440d253

34. From sysadmin to DevOps - Red Hat, accessed on August 17, 2025, https://www.redhat.com/en/blog/sysadmin-devops

35. The history of DevOps – How has DevOps evolved over the years - Harrison Clarke, accessed on August 17, 2025, https://www.harrisonclarke.com/blog/the-history-of-devops-how-has-devops-evolved-over-the-years

36. Trends in AI Supercomputers - arXiv, accessed on August 17, 2025, https://arxiv.org/html/2504.16026v2

37. [2506.19019] Survey of HPC in US Research Institutions - arXiv, accessed on August 17, 2025, https://arxiv.org/abs/2506.19019

38. Democratisation of AI through open data: Empowering innovation | data.europa.eu, accessed on August 17, 2025, https://data.europa.eu/en/news-events/news/democratisation-ai-through-open-data-empowering-innovation

39. Artificial intelligence and the challenge for global governance | 05 Open source and the democratization of AI - Chatham House, accessed on August 17, 2025, https://www.chathamhouse.org/2024/06/artificial-intelligence-and-challenge-global-governance/05-open-source-and-democratization

40. How APIs Are Democratizing Access To AI (And Where They Hit Their Limits) - Forbes, accessed on August 17, 2025, https://www.forbes.com/councils/forbestechcouncil/2021/09/24/how-apis-are-democratizing-access-to-ai-and-where-they-hit-their-limits/

41. Open source technology in the age of AI - McKinsey, accessed on August 17, 2025, https://www.mckinsey.com/~/media/mckinsey/business%20functions/quantumblack/our%20insights/open%20source%20technology%20in%20the%20age%20of%20ai/open-source-technology-in-the-age-of-ai_final.pdf

42. Goodbye API Keys, Hello Local LLMs: How I Cut Costs by Running ..., accessed on August 17, 2025, https://medium.com/@lukekerbs/goodbye-api-keys-hello-local-llms-how-i-cut-costs-by-running-llm-models-on-my-m3-macbook-a3074e24fee5

43. Top 10 Software Providers for Enterprise AI Development in 2025, accessed on August 17, 2025, https://www.atlassystems.com/blog/top-enterprise-ai-software-providers

44. AI in the workplace: Digital labor and the future of work - IBM, accessed on August 17, 2025, https://www.ibm.com/think/topics/ai-in-the-workplace

45. 7 Best Enterprise AI Transformation Solutions | Moveworks, accessed on August 17, 2025, https://www.moveworks.com/us/en/resources/blog/best-enterprise-ai-transformation-solutions

46. How Spotify Uses AI to Turn Music Data Into $13 Billion Revenue, accessed on August 17, 2025, https://www.chiefaiofficer.com/post/how-spotify-ai-processes-500-trillion-events-makes-13-billion

47. How Spotify Uses AI (And What You Can Learn from It) - Marketing AI Institute, accessed on August 17, 2025, https://www.marketingaiinstitute.com/blog/spotify-artificial-intelligence

48. Spotify Deepens AI Integration with Gemini for Enhanced Workspace - Devoteam, accessed on August 17, 2025, https://www.devoteam.com/uk/success-story/spotify-deepens-ai-integration-with-gemini-for-enhanced-workspace/

49. [2026] Software Engineer, Early Career - Careers at Roblox, accessed on August 17, 2025, https://careers.roblox.com/jobs/7114754

50. IBM Careers - Entry Level Jobs, accessed on August 17, 2025, https://www.ibm.com/careers/career-opportunities

51. 15 Quotes on the Future of AI - Time Magazine, accessed on August 17, 2025, https://time.com/partner-article/7279245/15-quotes-on-the-future-of-ai/

52. 10 principles for modernizing your company's technology, accessed on August 17, 2025, https://www.strategy-business.com/article/10-Principles-for-Modernizing-Your-Companys-Technology

53. The Strategic Principles of Repeatability | Bain & Company, accessed on August 17, 2025, https://www.bain.com/insights/the-strategic-principles-of-repeatability/

54. The Enduring Value of Basic Principles in Strategy - Attorney Aaron Hall, accessed on August 17, 2025, https://aaronhall.com/the-enduring-value-of-basic-principles-in-strategy/

55. Seven principles for achieving transformational growth - McKinsey, accessed on August 17, 2025, https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/seven-principles-for-achieving-transformational-growth

56. 10 Fundamental Business Principles (That Make Millions) - Wayne Yap, accessed on August 17, 2025, https://www.wayneyap.com/articles/10-business-principles

57. Why is Creativity Important for Innovation and Growth - IDEO U, accessed on August 17, 2025, https://www.ideou.com/blogs/inspiration/why-creativity-is-more-important-than-ever

58. www.ramimaki.com, accessed on August 17, 2025, https://www.ramimaki.com/why-creativity-remains-the-driving-force-behind-technology/#:~:text=Without%20creativity%2C%20technological%20advancements%20would,be%20used%20in%20novel%20ways.

59. Why Creativity Remains the Driving Force Behind Technology, accessed on August 17, 2025, https://www.ramimaki.com/why-creativity-remains-the-driving-force-behind-technology/

60. 75 Quotes About AI: Business, Ethics & the Future - Deliberate Directions, accessed on August 17, 2025, https://deliberatedirections.com/quotes-about-artificial-intelligence/

61. 25 Inspiring Computer Science Quotes - Create & Learn, accessed on August 17, 2025, https://www.create-learn.us/blog/computer-science-quotes/

I have done none of that. I have never even written import numpy too many times inside a python file, if I am being honest. I am a software engineer though. I understand more deterministic forms of organising information in the world using numbers, strings, booleans, storing them into databases and files, and being able to search, sort and retrieve them based on clearly defined conditions. That is sometimes all that you need to know to be able to make apps that deliver food, build an online library of videos for education or for entertainment or let people shop for their favourite things sitting at home from an app. All things I have helped build for hundreds of millions of users.

But that said, this is the age of Artificial Intelligence, or might I say the age of the race for Artificial General Intelligence. And naturally, many people who have not taken much interest to learn fundamental concepts of machine learning, are starting to do so, because there now exists, more than ever has, infinite possibilities in this space. Unfortunately, I have seen that when we look at most easily available educational content that teaches people basic of machine learning, it starts off with trying to explain how to create a neuron (what activation function to use etc), and then how to put them together into a neural network etc, without actually going much deep into why does this particular architecture exist in the first place?

See, when we start to learn about some data structures like a stack or a queue it isn’t very hard to intuit why we’d like to store certain data in that form (eg: storing browser history of current session). Similar with the basic idea of storing data in tabular format - which forms the basis of databases.

With machine learning though, what I see is that many introductory programs or advice is to do these first 3 steps

1. Build a perceptron (eg: sort emails as spam it if contains the word ‘free’)

2. Build a 2-layer neural network and detect something like shapes from 4x4 pixel images

3. Build a basic neural network with 1 hidden layer (eg: and do a classical character recognition problem, like what Yann LeCun did in 1993)

While this is absolutely the correct way to start learning (in terms of order of things to do, and the gradual ramp up of complexity of problems and the neural network used to solve it), my interactions with a lot of young software engineers going through this journey is that they aren’t entirely able to intuit why we ended up with this architecture of weights + activation function and then layering them up in this particular way. It isn’t as obvious why we do it this way, like it was when we stored browser history in a stack or bank transaction ledger in a relational database.

I thought of taking an example of the same classical machine learning problem of OCR (Optical Character Recognition), and taking a brain that intuits the deterministic software engineering world through a journey that will show why non-deterministic problems like this are solved this way. At least I hope so.

Let’s actually start with a more deterministic framing of the OCR problem. Instead of having to detect printed or handwritten characters, let’s try to figure out how would we detect which number is being displayed on a 16x16 LED board.

If I had to throw my deterministic CRUD software writing brain at this problem, I know this is not hard at all. We just need to know which pixels are lit for each number, and it is just then a big IF clause of a bunch of boolean checks clubbed together by some AND operators.

To check if 0 (zero) is displayed we need to check if these pixels are blue - [0,2], [0,3], [0,4], [1,1], [1,5], [2,1], [2,5], [3,1], [3,5], [4,1], [4,5], [5,1], [5,5], [6,2], [6,3], [6,4]

And similarly to check for 1 (one), we need to check these pixels - [0,3], [1,2], [1,3], [2,3], [3,3], [4,3], [5,3], [6,2], [6,3], [6,4]

This is ofcourse, a 100% accurate, and extremely fast detection, and in fact, this detection code will be the exact opposite of the code used to drive this LED board in the first place. The software behind the LED board actually takes numbers and lights up LEDs based on its configuration.

The question we have at hand is a bit different though. What if we have to detect what number it from a printout or even worse, handwriting? To keep things simple, if it were just printouts, then too, there can be many different fonts. For example here is the number “2” written in a collection of ten of the most frequently used fonts for printing. All have originally been printed in 16x16 pixels, and then enlarged.

Given any of the above 16x16 images we want to be able to detect that it is the number 2. Ofcourse, checking each pixel and clubbing the result together into a big IF condition isn’t going to work, because for each font the pixels are not even the same. If we were to only restrict ourselves to basic building blocks of deterministic programming - (basic data structures like arrays and linked lists, and basic boolean operations), this is not an easy problem to solve at the outset.

But still, what if we had to intuit out way towards a solution, using the tools we have in our toolkit, without starting to build perceptrons and neurons and things we don’t even know about.

Why not start thinking from that LED board we solved just above. What we are getting in our input is fairly simple. It is a 16×16 2D array, where each value is basically a number. Say it is 0 for black and 1 for white.

In the case of the digital LED board, what were we basically checking?

To check for, say ‘4’ certain LEDs which we expect to be 1, were 1, and the others, which we expect to be 0 were 0, we can determine if the given LED board is displaying ‘4’ or not

Well, in this case as well, we have to essentially do not much different. If we want to check whether the given input is the number 4 or not, we want to match it against a reference. The reference should say which pixels are likely to be black in case of 4 and which ones are likely to be white. Why ‘likely’? Well because given that there are so many fonts involved, now, unlike the LED board situation, we cannot say for every font, the exact same pixels are used.

Building out this ‘likelihood’ reference image is easy, actually. Let’s just take images with the digit ‘4’ in all ten fonts, and average out the pixel values?

Is it reasonable to say this statement now -

The blacker a pixel is, the more likely it is for any printed ‘4’ digit to have that same pixel black. The whiter the pixel is, the less likely it is that a printed ‘4’ digit will have that pixel white.

What if we tried to represent that in the form of some code. First off, how can we represent this blended image? That’s simple. Here’s a 16×16 2D array where values range from 0.0 (black) to 1.0 (white)

Now we have these two possible inputs (one which is 4, and one which is 8). If I pass them through the system, and ask `is this 4 ?` I would want the system to say yes for the first one and no for the second one.

Let’s say that inp[i,j] is each pixel in my input image and ref[i,j] is each pixel in the blended reference. For each pixel [i,j], I might say the following things

1. If inp[i,j] is 0 (black) and ref[i,j] is < 0.5 (highly likely to be black), then it increases the chances of inp to be same number as ref

2. If inp[i,j] is 1 (white) and ref[i,j] is < 0.5 (highly likely to be black), then it decreases the chances of inp to be same number as ref

3. If inp[i,j] is 0 (black) and ref[i,j] is > 0.5 (highly likely to be white), then it decreases the chances of inp to be same number as ref

4. If inp[i,j] is 1 (white) and ref[i,j] is > 0.5 (highly likely to be white), then it increases the chances of inp to be same number as ref

You might notice a bit of XOR-iness in this logic above which is quite funny and interesting. In fact XOR is the first classification problem that is taught upon as something a single perception cannot solve. Because XOR-ing isn’t a linear classification. In a x,y graph, you cannot plot a single line that divides all the 0 points and 1 points in a plot of XOR(x,y))

But to progress with our current problem at hand, let’s define an output 16x16 matrix where Output is defined in the following relationship to Input and Reference matrices.

If we did this operation with the reference matrix for 4 with the two inputs above, the resultant matrix, in form of pixels will look a bit like this.

By the way, if you’d like to play around with different digits, and see what these output 16x16 matrices look like you can visit this little tool I have made to visualise them - https://championswimmer.in/ocr-try-out/ which I used to create the visualisations for this article.

Now that we have this output, what can we infer out of this, that helps us figure out what number it is? When comparing with the reference matrix for the digit ‘4’;

1. If very few dark black boxes are left, hence high overlap, it implies the input most likely IS the reference digit, i.e. 4

2. If many dark black boxes are left, hence low overlap, it implies that the input most likely IS NOT the reference digit - ‘4’

We can even combine these likelihoods to come to the final answer of is this ‘4’ ? We take the likelihood of input being 4, and subtract a fraction of the likelihood of input not being 4.

While in the above formula, in an overly simplistic way, the penalty factor of the input looking like one of the other references is taken as -1/9, in reality, some numbers look more similar to each other than others. For example it is more likely for the digits 5 and 6 to get confused with each other than for 5 to be confused as 9. So we might not want to uniformly penalising an input looking like some other number by -1/9 but by specific amounts for each of the other inputs too.

Anyway if we just put everything we have together so far, and try to look at what sort of architecture our system so far might have. It will look a bit like this.

Starting to look a bit like the typical neural network representation of OCR systems doesn’t it now?

Also if it isn’t clear to you, in the first and second rows of our image what you see as just a 16x16 pixel image, is basically a layer with 256 elements (left most input layer), and 2560 elements (256 x 10 digit reference images) for the second column. The third and final (forth) layers have 10 elements each. And the final layer is basically the computed probability of the input being each of the possible 10 digits.

If the input is the digit ‘3’ as above, we’d expect the output of the final layer to be something like (just an example) -

[0.01, 0.003, 0.97, 0.002, 0.011 …]

i.e. The likelihood for all digits would be close to 0, except the likelihood for ‘3’ being close to 1.

Interestingly here, you’ll see that there are 2 things in our system which is NOT hardcoded into the logic of the system itself, and we can improve the numbers by running this system on larger volumes of data.

1. The blended average pixel values of the reference matrices. If we ‘train’ our system, by taking 100 fonts instead of 10. Our blended references will have even better idea of variations across fonts.

2. As discussed, the weightage we have given when summing the likelihoods - instead of a flat -1/9 for the others, if we analysed the data and saw which numbers get confused with each other more, and gave them a larger negative weight to each other, our accuracy might increase.

This might sound similar to how in actual neural network we have this matrix full of numbers called “weights”, which are just such floating point numbers as our blended pixel values and our likelihood weightages. And you might have heard of the concept of training the model on more data to create better weights which will perform better.

If you have read till here, I am hoping at least a few concepts you have seen in neural networks, we might have recreated in our own way of intuitively trying to use traditional programming primitives and crude skills of basic software engineering without knowing much about fundamentals of machine learning like linear regression or sigmoid functions.

1. The system has multiple layers, each layer with many elements

2. The output of every layer gets combined into some way to feed into the next layer

3. There are pre ‘trained’ numbers/weights which we have created after parsing some amount of ‘known’ data, which is then used to evaluate the unknown data

4. Instead of giving yes/no answers like the LED board detection, this system answers in terms of probabilities

But that said, are actual neural networks really created this way? Is the architecture based on trying to find out ‘least overlapping black pixels’, the way I have done above. Actually, no! Not at all. Despite all the similarity in technically how our architecture looks to commonly used simply neural networks, there are a few reasons this isn’t exactly how and why real neural network architectures are like this.

1. This way of trying to create a framework purely based on attempting to find overlapping black pixels would be extremely specific to the problem at hand, and not at all generalisable to other families of problems. In reality, a good neural network architecture would be one that is more general purpose in nature and can be trained with different types of data to perform different tasks easily without having to change the architecture of the layers itself.

2. The exact formula we used for combining the data at each layer was also a bit too specific to the problem. The 1-[inp-ref]^2 formula we used at the first layer might be useful when trying to reduce differences between values of the 2 layers, but it isn’t useful for other types of operations. Similarly, the formula to sum the likelihoods is also just a basic summation, which doesn’t lend much value in other scenarios. In reality, more general purpose activation functions are used which are not problem-specific, and are designed to let the neural network be trained on varied types of data.

In actual neural networks, like the ones which are used in Optical Character Recognition, the intermediate layer output is not actually how many black pixels are left after removing overlapping pixels. Instead, neural network weights of intermediate layers are often hard to understand, visualise, or reason about. If you took the output from one of the intermediate layers, and think you can just draw an image out of it (thinking each value is a pixel), you might most likely see gibberish on your screen.

But that said, despite what we built not being actually anything similar to how neural networks are built, I, personally, find this analogy really useful to intuit why these neural networks roughly exist in this shape of multiple layers of neurons.

As we moved from an extremely deterministic problem (detecting numbers on LED board) to a probabilistic one (detecting printed numbers), this example makes two things easy to grasp for a brain that wouldn’t land at the concept of neural networks easily otherwise.

1. These families of problems need you to have a mechanism of these weights. You cannot just write an ‘algorithm’ that solves it. You have to make the system go through a number of ‘references’ or ‘solved’ examples, and store some information about it, which it then will use to solve future unknown problems. Creating those blended pixel maps was that for us. Thus unlike conventional software, ML systems consist both of code/binary/program that runs, but also the weights which have been created by training. And the outcome of the system depends just as much on what the weights are as much as it does on how the system works.

2. These families of problems also require combining multiple intermediate step results with each other to reach results of the next stage. Just looking at one pixel, whether it is black or white gives little value. Combining the information of “if a pixel is different colour that it should be” across the entire 16x16 grid gives us likelihood of the input being similar to the reference. Similarly, the likelihood of the input matching the reference also depends on the likelihood of it matching some of the other references as well.

I leave you with some references to things you can follow up on reading if you’re new to the world of machine learning (like me) and want tinker with more such basic level projects to improve your grasp.

• https://medium.com/@vijendra1125/ocr-part-2-ocr-using-cnn-f43f0cee8016

• https://sharpsight.ai/blog/python-perceptron-from-scratch/

• https://www.reddit.com/r/MLQuestions/comments/h9tf32/do_we_still_dont_understand_whats_happening/

• https://www.digitalocean.com/community/tutorials/constructing-neural-networks-from-scratch

• https://medium.com/lumenore/build-an-ocr-system-from-scratch-in-python-69c08e78de2

• https://docs.pytorch.org/tutorials/intermediate/char_rnn_classification_tutorial.html

The technology industry has evolved through distinct waves, each characterized by revolutionary innovations that reshape how we live, work, and connect. Today, we stand at the precipice of a fifth wave – the AI revolution – that promises to be as transformative as its predecessors. Like ocean waves, each technological surge has carried some companies to new heights while leaving others behind. This pattern of creative destruction isn't random; it follows recognizable cycles that offer valuable insights for businesses and professionals navigating today's rapidly changing landscape.

The First Wave: Enterprise Computing (1950s-1970s)

The first wave of modern computing emerged in the aftermath of World War II, when room-sized machines began transforming how large organizations operated. This era was dominated by companies like IBM, Xerox, and AT&T, who built the foundations of enterprise computing.

IBM quickly established itself as the dominant player with its groundbreaking System/360 in 1965, the first series of upward compatible computers^[1]. This innovation, combined with widespread adoption of IBM software such as BATS (Basic Additional Teleprocessing Support) and database management systems, cemented IBM's position as the largest computer company of the era^[1-1]. Their systems became the backbone of operations for governments, financial institutions, and large corporations worldwide.

Xerox, founded in 1906 as the Haloid Photographic Company, revolutionized office work with the introduction of the Xerox 914 photocopier in 1959^[2]. The company later established the Palo Alto Research Center (PARC), which pioneered innovations like the graphical user interface and ethernet networking that would become crucial in the next wave. Meanwhile, AT&T's Bell Labs developed the UNIX operating system, which would eventually influence countless future systems.

During this period, computing was primarily confined to air-conditioned rooms where mainframes were operated by specialized technicians. The mainstream business world experienced computing through "green screen" terminal interfaces that offered limited functionality but represented a revolutionary step forward from manual processes^[3].

Key Innovations and Milestones

The first business use of computers came in 1952 when the J Lyons company in the UK implemented them for accounting functions^[1-2]. The U.S. Air Force's SAGE (Semi-Automatic Ground Environment) air defense system in the early 1960s combined computers and networks for the first time, leading to commercial applications like American Airlines' SABRE reservation system in 1965^[1-3].

In this same era, Gordon Moore formulated his famous law predicting that the number of transistors per unit area of silicon would double approximately every two years, a principle that would drive technological advancement for decades to come^[1-4].

The Second Wave: Personal Computing (1980s-1990s)

The second wave brought computing power from institutional control to individual desks. This democratization was led by visionaries who saw the potential for computers to become personal tools rather than shared resources.

Microsoft, founded on April 4, 1975, by Bill Gates and Paul Allen in Albuquerque, New Mexico^[4], rose to prominence through a pivotal partnership with IBM in 1980. This agreement to bundle Microsoft's operating system with IBM computers provided Microsoft with a royalty for every sale^[4-1]. As personal computers proliferated, Microsoft Windows eventually captured over 90% of the world's personal computer market share in the 1990s^[4-2].

Apple's journey began on April 1, 1976, when Steve Jobs, Steve Wozniak, and Ronald Wayne founded Apple Computer Company in Jobs's parents' home^[5]. The company's second computer, the Apple II, became a best-seller as one of the first mass-produced microcomputers^[5-1]. Though Apple would face struggles in the 1990s, its foundation during this period would eventually support a remarkable resurgence.

Intel, established on July 18, 1968, by Gordon Moore, Robert Noyce, and Arthur Rock^[6], became a crucial driver of PC evolution through its microprocessors. The "Wintel" partnership between Microsoft Windows and Intel in the early 1990s became instrumental in shaping the PC landscape^[6-1].

Surviving the Transition

Not all enterprise computing giants adapted successfully to the personal computing revolution. While IBM managed to pivot by developing the IBM PC and establishing itself in the new paradigm, companies like Digital Equipment Corporation (DEC) struggled to transition from their minicomputer focus.

What differentiated survivors from casualties was their willingness to cannibalize existing business models in favor of emerging opportunities. IBM took the risky step of partnering with Microsoft and Intel rather than developing all components in-house, a decision that allowed it to quickly establish a presence in personal computing while maintaining its enterprise business.

This period also saw dramatic leadership stories, including Steve Jobs' forced departure from Apple in 1985 and eventual return in 1997 when the company was weeks away from bankruptcy^[5-2]. Such leadership dynamics would become a recurring theme in tech history.

The Third Wave: Web Computing (Post-2000 Crash)

The burst of the dot-com bubble in 2000 cleared the field for a new generation of companies built around the emerging web. This third wave saw the rise of platforms that would fundamentally change how we access information and conduct commerce.

Amazon, founded by Jeff Bezos on July 5, 1994, started as an online bookstore but had a much broader vision^[7]. Bezos initially incorporated the company as Cadabra, Inc., before changing the name months later because a lawyer misheard it as "cadaver"^[7-1]. Bezos selected "Amazon" because it was "exotic and different," just as he envisioned for his internet enterprise, and also because it would appear near the top of alphabetical listings^[7-2]. The company expanded from books to become "the everything store," developing subsidiaries including Amazon Web Services (cloud computing)^[7-3].

Google emerged from a Stanford University research project called "BackRub" started by Larry Page and Sergey Brin in 1995^[8]. They officially founded Google Inc. on September 4, 1998, in a garage in Menlo Park, California^[8-1]. The company's user-friendly interface and effective search algorithm quickly gained popularity, allowing it to expand into services like AdWords (2000), Google Images (2001), and Google News (2002)^[8-2].

Yahoo, once a dominant web portal, failed to adapt to changing user needs. Its approach to acquisitions was "fraught with mismanagement, poor execution, and failure to leverage its investments effectively"^[9]. A critical turning point came in 2008 when Yahoo rejected Microsoft's $44.6 billion buyout offer, a decision many analysts considered a missed opportunity^[9-1]. Yahoo also failed to invest in mobile technology as the internet transitioned from desktop to mobile, while competitors like Google and Facebook prioritized mobile-first strategies^[9-2].

Talent Wars Begin

During this period, acquiring top technical talent became increasingly competitive. In 2005, Google hired Internet pioneer Vinton Cerf, one of the creators of TCP/IP protocols, from MCI Inc^[10]. Google CEO Eric Schmidt described Cerf as "one of the most important people alive today," highlighting the strategic importance of such acquisitions^[10-1].

This wave also saw Microsoft and Google engaging in legal battles over talent. When Kai Fu-Lee resigned from Microsoft in July 2005 to oversee Google's efforts to open a research center in China, the two companies found themselves battling in court^[10-2]. These talent wars signaled the growing recognition that human capital was becoming as valuable as technological assets.

The Fourth Wave: App Economy (Post-2008 Crash)

As the world recovered from the 2008 financial crisis, a new wave of tech companies emerged, centered around mobile applications and social connectivity. This fourth wave coincided with the proliferation of smartphones and the creation of new digital social spaces.

Facebook (now Meta), established in 2004 as TheFacebook, Inc.^[11], expanded from a college networking site to become a global platform. Twitter, created by Jack Dorsey, Evan Williams, and Biz Stone in March 2006, launched publicly on July 15 of that year^[12]. The first Twitter message was published by Jack Dorsey on March 21, 2006, simply stating: "just setting up my twttr"^[12-1].

Dropbox, founded on June 1, 2007, by MIT students Drew Houston and Arash Ferdowsi^[13], represented a new category of cloud services aimed at individual users. The company grew rapidly, with its beta waiting list expanding from 5,000 to 75,000 people "literally overnight" after posting a demonstration video on Digg in March 2008^[13-1].

This wave was characterized by rapid user growth often preceding viable business models. Companies focused on building massive user bases before fully developing monetization strategies, a pattern that worked for some but led to sustainability challenges for others.

Mixed Fortunes

The fourth wave saw varied outcomes for established players. Amazon and Google successfully adapted their business models to embrace mobile and social trends. Amazon expanded into cloud services with AWS, while Google developed Android and acquired YouTube. Meanwhile, Yahoo continued to decline, struggling with frequent leadership changes and losing market relevance.

New entrants also experienced divergent paths. While Facebook grew into one of the world's most valuable companies, other platforms like Twitter and Snapchat faced challenges in converting user engagement into sustainable financial growth. Dropbox, despite early excitement, found itself competing in an increasingly commoditized storage market dominated by tech giants offering integrated services.

The Fifth Wave: Artificial Intelligence (Post-2022 Crash)

Today, we are witnessing the emergence of the fifth wave of technology centered around artificial intelligence. After the market correction of 2022, AI has moved from a research curiosity to the defining technological frontier, with specialized AI companies gaining unprecedented attention and investment.

OpenAI, founded in December 2015^[14], and Anthropic, established in 2021 by former OpenAI employees including siblings Daniela and Dario Amodei^[15], are leading this new paradigm. Unlike previous waves where hardware or platform innovations drove change, this wave is powered by increasingly sophisticated machine learning models that can generate content, understand language, and solve complex problems.

Anthropic has attracted substantial investment from established tech giants, with Amazon committing a total of $8 billion ($4 billion in 2023-2024 and another $4 billion announced in November 2024)^[15-1]. Google similarly invested $500 million in Anthropic in 2023 with a commitment for an additional $1.5 billion over time^[15-2]. These massive investments highlight how seriously established companies are taking the AI revolution.

Talent and Leadership Movements

The AI wave has triggered dramatic talent migrations. In 2024, Anthropic attracted several notable employees from OpenAI, including Jan Leike, John Schulman, and Durk Kingma^[15-3], indicating the intense competition for AI expertise. Most recently, former Apple design chief Jony Ive announced he would join OpenAI in a groundbreaking move that signals AI's expansion beyond pure technology into product design^[16].

This partnership between Ive and OpenAI aims to "reimagine what it means to use a computer," with plans to unveil collaborative projects in 2026^[16-1]. The merger between OpenAI and Ive's technology enterprise, io, is reportedly valued at approximately $6.5 billion^[16-2], demonstrating the extraordinary valuations being assigned to AI innovation.

Meanwhile, established tech giants are positioning themselves differently in this new landscape. Microsoft has embraced the AI revolution through extensive partnerships with OpenAI, while Google has developed its own AI systems while also investing in Anthropic. Apple appears to be moving more cautiously, still heavily focused on its hardware ecosystem and App Store revenue model rather than leading in AI development.

Patterns Across the Waves

Looking across these five waves of technological evolution, several consistent patterns emerge that help explain why some companies thrive while others falter when paradigms shift.

Revenue and Valuation Dynamics

Each wave follows a predictable economic pattern: established companies from previous waves maintain strong revenue and market dominance initially, while newcomers grow rapidly but often without immediate profitability. During the enterprise computing era, IBM dominated revenues while early PC companies struggled for viability. Similarly, today's AI companies are securing massive valuations and investments despite uncertain short-term profitability, while established tech giants continue to generate the bulk of industry revenue.

This creates a dual economy within the tech sector, where different metrics apply to different generations of companies. Established players are judged on current performance, while emerging companies are valued on potential for disruption and future growth. The challenge for investors and talent alike is determining when the growth trajectory of newer companies will intersect with the plateauing curves of established players.

Talent Migration

A reliable indicator of where innovation is heading is the movement of top technical talent. From the brain drain of researchers leaving Xerox PARC to join Apple in the early PC era, to Google hiring Internet pioneer Vinton Cerf in 2005^[10-3], to Anthropic attracting key OpenAI researchers in 2024^[15-4], talent flows signal shifting centers of innovation.

These migrations happen before market dominance is established, creating a leading indicator for industry direction. Companies that can attract and retain exceptional talent during wave transitions gain significant advantages in the next era. This talent arbitrage often involves researchers and engineers leaving comfortable positions at established companies to join riskier but potentially more impactful ventures.

The Innovation Timeline

A consistent pattern across waves is the approximately five-year gap between technological breakthroughs and their commercial maturation. The foundations of web commerce were laid years before Amazon became profitable; social media platforms existed for years before developing sustainable business models; and today's AI systems represent the culmination of research that began long before their current commercial applications.

This lag creates both opportunity and risk. Early adopters of emerging technologies can establish market position before business metrics catch up with innovation, but they also face the challenge of sustaining investment through the commercialization valley. Companies that successfully navigate this period – maintaining both technological leadership and financial viability – emerge as the definitive leaders of each new wave.

Navigating the Current Wave

For professionals and companies navigating today's AI wave, historical patterns offer valuable guidance. We can expect established tech companies to maintain revenue leadership for the near term while AI-native companies grow at accelerated rates from smaller bases. Top talent will continue flowing toward AI innovators, even as established companies offer premium compensation to retain key personnel.

The career calculus follows familiar patterns. Joining established companies offers stability and competitive compensation, while the greatest potential for outsized career growth lies with companies defining the new paradigm. As with previous waves, the established players won't disappear overnight – IBM still exists and generates billions in revenue decades after its dominance peaked – but they may struggle to lead innovation in the new era.

What makes the AI wave potentially different is the magnitude of its impact. Where previous waves transformed how we work with computers, AI could transform the nature of work itself. This suggests that the disruption could be broader and deeper than previous transitions, affecting not just technology companies but every sector of the economy.

Conclusion: Will History Rhyme?

As Mark Twain allegedly said, "History doesn't repeat itself, but it often rhymes." The five waves of technology evolution show consistent patterns of creative destruction, talent migration, and value creation that offer a framework for understanding the current AI revolution.

What remains uncertain is whether AI represents merely the fifth wave in this sequence or something more fundamental – a technology that will reshape the patterns of innovation themselves. Will AI companies follow the trajectory of previous wave leaders, or are we witnessing something that transcends the established cycle?

What is clear is that we stand at an inflection point comparable to the birth of personal computing or the emergence of the commercial internet. For individuals and organizations alike, the decisions made during this transition will determine who rides the next wave and who gets left behind. As with previous waves, the greatest opportunities lie with those willing to embrace change rather than defend the status quo – even if that means disrupting their own success.

1. https://apsg.bcs.org/materials/presentations/20160114_B.pdf↩︎↩︎↩︎↩︎↩︎

2. https://en.wikipedia.org/wiki/Xerox↩︎

3. http://geek.ly/AcH↩︎

4. https://en.wikipedia.org/wiki/History_of_Microsoft↩︎↩︎↩︎

5. https://en.wikipedia.org/wiki/Apple_Inc.↩︎↩︎↩︎

6. https://en.wikipedia.org/wiki/Intel↩︎↩︎

7. https://en.wikipedia.org/wiki/History_of_Amazon↩︎↩︎↩︎↩︎

8. https://www.upgrow.io/blog/how-old-is-google-search-engine-history↩︎↩︎↩︎

9. https://www.cognitivemarketresearch.com/blog/yahoo-s-decline-a-case-study-in-missed-market-opportunities↩︎↩︎↩︎

10. https://www.nbcnews.com/id/wbna9257775↩︎↩︎↩︎↩︎

11. https://en.wikipedia.org/wiki/Meta_Platforms↩︎

12. https://www.business-standard.com/world-news/twitter-was-founded-on-this-day-in-2006-here-s-all-you-need-to-know-124071500394_1.html↩︎↩︎

13. https://en.wikipedia.org/wiki/Timeline_of_Dropbox↩︎↩︎

14. https://en.wikipedia.org/wiki/OpenAI↩︎

15. https://en.wikipedia.org/wiki/Anthropic↩︎↩︎↩︎↩︎↩︎

16. https://www.cnn.com/2025/05/21/tech/jony-ive-apple-design-chief-openai↩︎↩︎↩︎

In today's hyperconnected world, we find ourselves in the age of what might be called a "dunkocracy" – a political environment where scoring points against opponents on social media ("dunking") has become a central feature of political discourse and international relations. This phenomenon is increasingly shaping major geopolitical decisions, economic policies, and international conflicts, often at the expense of thoughtful deliberation and long-term strategy. Research is mounting that this social media-driven political environment poses significant threats to democratic institutions and global stability.

The Mechanics of Digital Dunking

The term "dunkocracy" describes our current political climate where the ability to publicly mock, criticize, or "own" political opponents online is rewarded with viral attention and support. Research confirms this is not just anecdotal observation but a measurable phenomenon.

A Cambridge University study examining nearly three million social media posts from U.S. politicians found that posts criticizing political opponents received twice as many shares as posts promoting their own partisan views^2. The study revealed that political posts containing negative messages about opposing parties garnered twice as many angry face emojis than heart emojis received on positive posts about one's own party^2.

"Slamming the political opposition was the most powerful predictor of a post going viral out of all those we measured," said Steve Rathje, author of the Cambridge study^2. Even more specifically, each additional word about an opposing party in a social media post increased the odds of that post being shared by 67%^7.

This creates a perverse incentive structure where politicians and leaders are rewarded not for substantive policy discussions but for their ability to publicly criticize opponents. As Rathje notes, social media business models have "ended up rewarding politicians and media companies for producing divisive content in which they dunk on perceived enemies"^2.

The Algorithm Reward System

The mechanics behind this phenomenon are deeply intertwined with how social media platforms operate. These platforms are designed to maximize user engagement, which algorithms have determined is highest when content triggers emotional responses – particularly negative ones.

A University of Michigan study found that exposure to political attacks on social media contributes to anxiety, anger, and political cynicism^1. The researchers define political cynicism as an attitude rooted in distrust of political actors' motivations that goes further than healthy skepticism because it involves wholesale rejection of democratic processes^1.

Political Consequences: Domestic Politics in the Age of Dunkocracy

The dunkocracy has fundamentally altered how political movements function. Traditional policy platforms have in some cases been abandoned in favor of performative opposition. Since its inception, Trumpism has made a point of eschewing policy in favor of "owning the libs" to garner likes, retweets, and small-dollar donations^6. During the 2020 election, the Republican Party even chose not to write a new platform for its convention – a telling sign that policy substance had become secondary to performative opposition^6.

The Texas GOP's official Twitter account demonstrated this approach by posting a meme mocking New Yorkers waiting in line for COVID tests, suggesting that if they could wait for testing, they could vote in person^6. This post wasn't designed to advance policy but to provoke outrage from political opponents and approval from supporters.

From Policy to Performance

Political scientist Ariel Hasell and colleagues at the University of Michigan documented how this environment contributes to political cynicism: "It's important to understand how feelings of cynicism emerge because we're seeing many democratic governments facing crises of legitimacy," Hasell said. "Our findings provide some of the first evidence of how exposure to political attacks on social media might relate to political cynicism in the context of a U.S. presidential election."^1

This cynicism has real consequences for democratic governance, as citizens increasingly view politicians not as public servants but as self-interested performers in an endless social media spectacle.

International Relations in the Dunkocracy

Perhaps most concerning is how the dunkocracy phenomenon is reshaping international relations, where the stakes can include war and peace.

Case Study: Trump's Tariff Policies

A recent example is former President Trump's approach to tariffs. In April 2025, Trump imposed sweeping tariffs, including a 10% universal tariff on all imports with higher rates for "worst offenders"^8. This triggered a massive market reaction, with Wall Street experiencing its largest single-day decline since the COVID-19 pandemic, wiping approximately $3.1 trillion from the market^8.

Rather than addressing legitimate economic concerns, Trump took to social media to mock critics, coining the derogatory term "Panican" for those worried about the tariffs' economic impact. "Don't be Weak! Don't be Stupid! Don't be a PANICAN," he wrote^8.

Days later, Trump unexpectedly announced a 90-day suspension on certain tariffs^13. This abrupt reversal prompted social media mockery, with Senator Brian Schatz satirically posting: "OUR PLAN IS WORKING PERFECTLY AND IS JUST A NEGOTIATING TACTIC BUT IT IS ALSO GOING TO BE PERMANENT"^13. The incident highlighted how policy was being driven by social media reaction rather than economic strategy.

Case Study: India-Pakistan Tensions

The India-Pakistan relationship demonstrates how social media "dunking" can escalate international tensions to dangerous levels. Following the February 2019 Pulwama attack in which 40 Indian paramilitary personnel were killed, social media platforms were flooded with inflammatory content^10.

A review of viral social media posts showed that many photos of deceased personnel were doctored and mislabeled, with mainstream Indian channels amplifying these misleading images^10. The Central Reserve Police Force was forced to establish a 12-member fact-checking team which debunked at least 20 false stories^10. The social media frenzy created domestic pressure for military retaliation against Pakistan.

This led to military action when Indian planes violated Pakistani airspace in Balakot. The subsequent exchange of fire and Pakistan's downing of an Indian fighter jet brought the nuclear-armed neighbors close to all-out war^10. Experts have implied that both countries came close to war because of the unprecedented proliferation of fake news driven by social media^10.

Twitter Diplomacy: A Double-Edged Sword

The rise of what has been termed "Twitter diplomacy" represents both opportunities and dangers. Research identifies three advantages of Twitter diplomacy: increased accessibility to audiences, message control, and accelerated network effects^18. However, these benefits come with significant risks.

Relationships between nations become "more fragile and 'undiplomatic'" when leaders bypass traditional diplomatic channels. Even slight misinterpretations on social media can escalate tensions quickly^18. Additionally, leaders risk exposing their personal opinions and emotions, providing adversaries insights into their psychological vulnerabilities^18.

The Canadian-Saudi diplomatic crisis of 2018 illustrates these risks. When Canadian Foreign Minister Chrystia Freeland criticized Saudi Arabia for arresting activists in a tweet, the Saudi government retaliated by expelling Canada's ambassador and suspending student exchange programs and flights^18. What began as a frustrated tweet created a deep diplomatic rift.

Economic Impacts of the Dunkocracy

Financial markets are increasingly responsive to social media pronouncements, creating economic volatility driven by online posturing rather than economic fundamentals.

The cryptocurrency market provides a clear example. When Elon Musk tweeted that he was "willing to serve" D.O.G.E. (a playful reference to Dogecoin) in August 2024, the cryptocurrency's value surged 3.56%^9. This single tweet, seen by 52 million people, moved a market with a capitalization exceeding $15.3 billion^9.

Musk has faced legal challenges from Dogecoin investors who accuse him of "transparent cryptocurrency market manipulation"^9. While his attorneys describe his tweets as "innocent and often humorous," the real-world economic consequences demonstrate how social media "dunking" can have financial ramifications far beyond their digital origins^9.

Threats to Democracy

The dunkocracy phenomenon poses several distinct threats to democratic institutions and processes.

Undermining Expert Input and Deliberative Processes

Twitter diplomacy allows leaders to declare policies without consulting experts or following traditional processes. In December 2018, President Trump announced the withdrawal of U.S. troops from Syria via Twitter, against the advice of his Defense Secretary^18. This bypassing of established policy channels forces government agencies to frantically adapt to policies announced on social media without proper review^18.

Increasing Polarization and Institutional Distrust

Research confirms that digital media contribute to declining trust in democratic institutions^3. The replication study by the Institute for Replication analyzed studies through March 2024 and confirmed that while digital media promote political participation, they also increase polarization and mistrust in institutions^3.

The Quality Problem in Democratic Participation

While social media platforms remove barriers to political participation, the quality of that participation is often problematic. The absence of editorial or regulatory control means billions of people can "propagate, and therefore legitimise, misleading and destructive rhetoric without challenge"^19.

Even when enhanced participation occurs, research shows that democratic discourse on social media is controlled by a minority of users, undermining the representational benefits^19. The algorithms of platforms like Facebook and Twitter reward divisive content, creating what researchers call a "dangerous political climate"^2.

Can Democracy Survive the Dunkocracy?

The challenges posed by the dunkocracy are significant but not insurmountable. Several potential interventions could help preserve democratic deliberation in the age of social media.

Platform Design Changes

Social media companies could modify their algorithms to reduce rewards for divisive content. As Professor Sander van der Linde from Cambridge University noted, "Unless social media companies start penalising polarising content ... these platforms will continue to be swamped by political animosity"^2.

Some platforms have begun taking steps in this direction. In 2019, Twitter announced it would stop all political advertising, while Facebook introduced an option for users to switch off political advertisements in 2020^2. However, these measures don't address the underlying algorithmic preference for divisive content.

Media Literacy and Critical Thinking

Educating citizens to be more discerning consumers of social media content is crucial. The ability to identify misleading information and understand the emotional manipulation techniques used in social media "dunking" could help reduce its effectiveness.

Institutional Adaptations

Democratic institutions must adapt to preserve deliberative processes in the social media age. This might include creating more transparent policy development processes, establishing clearer communication channels between government agencies and the public, and finding ways to incorporate public input without being driven by the most viral voices.

Conclusion

The "dunkocracy" represents a fundamental challenge to how democracies function in the digital age. When political discourse is reduced to scoring points against opponents, the essential elements of democratic deliberation-reasoned debate, expert input, and compromise-are undermined.

The evidence shows that social media platforms, through their design and business models, have created an environment where divisive, attacking content thrives. This has implications not just for domestic politics but for international relations and economic stability.

As we navigate this new landscape, citizens, leaders, and platform designers all have roles to play in preserving democratic values while embracing the participatory potential of digital media. The challenge is to harness the democratizing power of social media without succumbing to the destructive dynamics of the dunkocracy-a challenge that may define democracy's fate in the 21st century.

When I was writing code for my own startup - without any prior experience, most things were structured fairly simply. The initial few people I had hired were also people I mentored and taught a lot of programming, and they, like me, had no prior experience at "enterprise" places, so they also wrote code fairly simply.

Then I moved to Zomato, worked on the mobile app, (which was by then itself, already fairly big - 2M+ SLoC, 30+ modules, 3 different apps built from the same major repo). One of the things lot of people lamented there was that there wasn't a lot of 'structure' to the code, avant garde architecture principles like Clean Architecture was not being followed, and a only the most recently written code was MVVM, but most of the rest wasn't. We didn't even have any dependency injection framework setup.

Then I went to work for a while at Target. An absolutely dogmatic 'enterprise' codebase. Every new feature, evern before any significant line of code was written, would first spawn 3 modules. 1 for the 'domain' code, that used to just be a bunch of interfaces, written in pure non-Android-dependent Java, 1 for the Android specifics and would implement the first module, and then a third module for all the testing code. If it required local data storage, a fourth module would get created. There were a bunch of people who would absolutely get off on writing bunch of 'adapters', 'strategies', 'factories', 'builders', and even adding a new button would generate 200 new lines of code.

Looking back at it now, Zomato used to respond to a tweet on Monday saying 'please make this', and ship it as a feature by next Wednesday release. People new to the codebase could ship code within their first 2-3 days. And despite a lot of issues (like some performance problems, memory leaks, extremely large classes that did too many things over many years), almost none were actually because it wasn't trying to make the architecture what essentially looked like peeling off layers of an onion.

At Target, new engineers would not be able to do much more than write tests, and not create new features, for as long as 2-3 months into the codebase. Features would take eons to ship. Even things which had just one possible implementation (with no possible future alternative implementations) still would have to be split up into a generic interface with a separate concrete implementations. Debugging would be a extremely painful because nothing was coupled. Clicking "see definition" or "see usages" in the IDE was mostly pointless because everything would lead to one more layer of 'indirection', and despite way more number of anal 'senior' engineers who forced everyone to write code with 5 layers of indirection, it was worse off than Zomato in every possible metric. (crash rates, memory footprint, performance, app startup, turn around time for new features, app size.... every metric)

This is not to say Zomato's codebase was a shining beacon of what large codebases should be like (it very much was not, and had its own set of reasons for being hard to deal with), it was a great lesson for me that, at least whatever was wrong, was definitely not because we were not following Clean Architecture, and not making every feature into 4 separate modules, and because we didn't have dependency injection setup.

And that's the first time I started getting convinced that 'Clean Architecture' is 100% an anti-pattern. I actually read the book end to end first time at that time (till then I only had read blogs about how Clean Architecture was implented, but not read the original Clean Code book).

Having had worked enough on production codebased, hiring and managing teams who have to work on production codebases, and seeing the real world impact of different architecture patterns, I honestly couldn't get to understand what made everyone follow Uncle Bob and his horrible book so much. Every chapter I read felt like garbage. Every 'prescription' of how to write code I saw in the book made me wonder if this famous person writing this book has every actually written code for a real production system, and worked with a real team of software engineers or not.

The truth is, most of the people who read Uncle Bob's books have written far more production code in their lives than he ever has. Most of the readers of his book have far more practical experience of working in a large modern software engineering team than he has. He has been just writing sermon after sermon on how to write more succinct classes in Java from 1995, without ever having written any real code in production. He is the classical example of college professors who have never worked in the industry. He is a senile grandpa, crying hoarse about "in my time we wrote code like this, and you kids don't know better", while the world has gone far far ahead.

It has now come to point that I use this as a litmus test for who understands good software architecture and who doesn't. And people who dogmatically try to follow any of Clean, Onion, Hexagon and all that crap, are people I absolutely steer clear of, and never discuss software engineering with ever in future.

I have never had the energy to write about how stupid Clean Code is, but someone I respect a lot has done that, and I keep just sharing the link to his article, everytime I hear any faint whispers about 'Clean Code' in any team. Sam Hughes, more famously known as the author of the SCP Foundation and Antimemetics Division, is also a programmer, and has taken out the time and effort to lay out clearly how useless most of the advise in Clean Code book is.

https://qntm.org/clean

So I have already started discovering a pattern about how "amazed" people are with LLMs generating code.

1. PMs, non-tech founders, wordcels and yappers are the most amazed. They can sit on their couch and write "make me an app" on their iPhone, and it makes them yet another landing page. They cannot stop waxing eloquent about how AI is changing the world.

2. Indie developers, script kiddies, and more junior developers also love "vibe coding". They keep saying "Fix it" to Cursor till it works, and mostly they like that instead of searching StackOverflow and figuring out what to copy from there, this is a much faster approach to coding

3. The senior engineers, neckbeards, old-school nerds wrangling with complexes codebases have mostly been saying "eh... it is good, in places. I don't like the code it writes, but I like how I can ask it to explain API docs and new pieces of code I have not seen before". They are using it to write some pieces of code in languages they are not well versed with, and they prefer 'copilot' mode more than 'chat and generate' mode.

4. The absolute elites (like Linus below), basically just say "it is all hype", and are not impressed at all with it, and are mostly ignoring it.

I think I am somewhere between 2 and 3 myself, and it was quite a bit of cognitive dissonance initially to find my friends from both 2 and 3 buckets give such contradicting signals about it. Then I started seeing the pattern. Those who are objectively worse programmers than me, were objectively more impressed by it than I am. Conversely those who I look up to as much better engineers than me, seem to be impressed even less than me with it.

So yeah, basically LLMs write code like a ~p75 programmer (probably ~p50 when codebase is large), and anyone below that mark is impressed by it, and those above it find it overwhelming, and mostly an irritating pair programmer, whose code they need to keep nitpicking.

Some people even add their own self-written notes + the AI note taking apps notes, and cook them together in yet another LLM and produce elaborate bullet points.

The meetings notes are mostly too verbose, because AI doesn't know how to write short, crisp bullets, which need not be grammatically correct. In way, AI knows how to "summarise", but not how to "take notes". Since all these notes are too verbose, people don't really read them, they ask yet another AI to further "summarise". In this whole journey, some actual key information gets lost. People are a lot less focussed in the meeting too now, given that they know their "AI assistant" is making notes anyway. They are half distracted, doing some other work parallelly during the meeting.

From roadmaps to technical docs to RFCs to performance reviews - AI has made it so much easier to ̶w̶r̶i̶t̶e̶ generate them, that there are just way more of them now. Instead of just writing up a POC - people throw a 6-pager RFC or tech-spec at you first. All the conventional wisdom says "great engineers write great architecture docs" and "great managers write great vision docs" - so now that ̶w̶r̶i̶t̶i̶n̶g̶ generating them is easier, everyone's writing tons of them. All career-guidance and professional how-to books advice you to "write more" to progress further in your career, because in the older world (Amazon meeting agenda 1-pagers, Stripe press releases), writing more would actually train you more to write more concise and succinct documents, and develop the muscle to coalesce opinions via the written word. Simply generating more docs via LLMs do not actually make you better at that. On the contrary, now that you generate more noise with too many documents, no one knows which ones are more important, and unable to keep up, start ignoring your ̶w̶r̶i̶t̶i̶n̶g̶s̶ generations.

The wiki has a "summarise with AI" button, the Zoom call has a "summarise with AI" button. The Google Doc has a "rewrite with AI" button. Everyone who is a "human in the chain" is turning out to be a glorified network packet switcher between different LLM models. Generate text, send to someone, who summarises it using another LLM, without reading it much (either the original, or the summary), and forwards it, to someone, who rewrites it again using AI and turns it into a presentation, which then is used in a meeting, which gets summarised using AI, and saved in the wiki.

There are more meetings now, because more people have the ability to write 'meeting agendas'. There are more 'stakeholders' now, because anyone can write a cursory 'remark' on your documents using the AI tool. There are bigger committees to review performance now, because all packets have started to look and read more or less the same, and harder to calibrate.

The internal AI tooling team's KPIs have been through the roof. They just got fresh budget to hire PhDs and purchase a GPU cluster to fine-tune yet another model only on "internal data", which increasingly is itself not human-generated content anymore.

Welcome to the post-genAI world. And ofcourse, you can use Grok3 to tl;dr-ify this post if it is too long to read (I am sure it is).

I first noticed this pattern while observing how different teams operated within big tech companies. A classic example is how say privacy and safety teams sometimes evolve in social media companies. These teams start with the crucial mission of keeping platforms safe and trustworthy. But without careful alignment to broader company goals, they can spiral into building increasingly complex safety systems that deliver diminishing returns while consuming enormous resources. Years later when someone zooms out to ask how many millions/billions of dollars got spent on this, and did it actually help larger business outcomes like drive ad revenue, engage users for longer in the app etc, people don't like the answer.

This isn't because these teams are incompetent or malicious. Quite the opposite - they're often staffed with brilliant, dedicated people. The problem is structural. When you're deep in the trenches of a specific domain, it's natural to keep finding more things to optimize. Each incremental improvement seems logical from ground level, but from orbit, you might be polishing a doorknob while the house is on fire.

The phenomenon isn't unique to tech. In academia, you'll find researchers who've drilled so deep into their sub-sub-specialty that they've lost sight of whether their work matters to the field at large. In government, you'll find departments that have developed byzantine processes that make perfect sense internally but create friction for the broader organization.

Why does this happen? Several factors contribute:

1. Distance from impact: As organizations grow, many roles become increasingly removed from customer impact or revenue generation. This makes it harder to naturally calibrate effort versus value.

2. Measurement problems: It's often easier to measure local metrics than global impact. A safety team can count blocked violations, but measuring the opportunity cost of false positives is much harder.

3. Career incentives: People are typically rewarded for showing impact within their scope of control, not for questioning whether their scope matters.

4. Complexity shield: Large organizations become so complex that few people can confidently challenge whether a specialized team's efforts are worthwhile.

The most dangerous aspect is that local optimization can look like success. Teams can show impressive metrics, launch new features, and demonstrate continuous improvement - all while potentially making the organization less effective overall.

Consider a hypothetical example: An ads quality team might build sophisticated systems to eliminate every last spam ad, while inadvertently making the ad submission process so complex that legitimate small businesses give up. The team's metrics look great (spam down 99.9%!), but the company is losing valuable revenue and market share.

The solution isn't to eliminate specialized teams or stop local optimization entirely. Rather, organizations need to build better mechanisms for maintaining global alignment:

1. Regular zooming out: Teams should periodically step back and reassess their work against top-level company goals.

2. Cross-functional reality checks: Create forums where teams must justify their efforts to peers from other domains.

3. Resource tension: Maintain healthy competition for resources so teams must demonstrate real impact to grow.

4. Rotation programs: Help people develop broader perspective by moving between different parts of the organization.

5. Clear north stars: Establish and communicate simple, compelling metrics that matter for the entire organization.

Some of the most successful companies maintain their effectiveness by ruthlessly pruning activities that don't serve the core mission. Amazon's famous "Day 1" philosophy and Apple's ability to say "no" to good ideas that don't serve the bigger picture are examples of this discipline.

The local optimization trap is particularly relevant today as organizations grow increasingly complex and specialized. As artificial intelligence and other technologies enable even more sophisticated optimization, the risk of teams disappearing down optimization rabbit holes only increases.

The best defense is awareness. Once you understand the pattern, you start seeing it everywhere - and can catch yourself when you're falling into the trap. The next time you're deep in an optimization effort, take a moment to ask: Am I polishing a doorknob while the house is on fire?

The most valuable work often isn't about optimizing what's in front of you, but stepping back to ensure you're working on the right things in the first place.