Everything Is Changing Now

The 3 Layers of Modern AI: Systems → Infrastructure → Products

g_o22@yahoo.com (Gideon Onyewuenyi) — Tue, 15 Sep 2026 00:00:00 GMT

You type a question into an AI app and the answer appears.

Behind it: a building chosen years ago for its access to electricity. A supply contract signed with a power generator before the app existed. A shipment of chips that needed a government’s permission to cross a border. And a company you’ve never heard of whose job is keeping that answer coming to you fast.

None of it is visible to you. A finished product hides its supply chain - that’s what finished means. But the hidden part is where the cost sits, where the risk sits, and where it gets decided what that app is allowed to do at all.

The model everyone talks and argues about is one step in that chain.

Three layers. The order matters, because most times each only becomes possible once the one above it is settled.

01 - Systems

Who decides whether any of this is allowed to happen.

Nothing is built at this layer. No chip, no model, no product. What gets set here is the outer boundary of what everyone underneath is permitted and able to do.

Rules: The EU AI Act is the one with a name. Most of the rules that actually bite don’t have names, they’re the existing regulations governing banks, hospitals, insurers and public institutions, and they attach to a model the moment it touches that work. A bank cannot deploy a system it can’t explain to its supervisor. A hospital cannot use a device that hasn’t been cleared. Neither is an AI rule; both were already there, and a model that can’t clear them may as well not exist for that sector.

Capital: Frontier training of models is a capital expense, not an operating one. The money is committed years before anyone knows what it bought, and if the run fails it isn’t recoverable. Very few pools of capital tolerate that shape - venture funds, sovereign wealth, public markets, and the balance sheets of the handful of firms large enough to self-finance. That constraint, more than any technical one, is why there are five or six frontier labs rather than five hundred.

Chips, and where they’re allowed to go: Advanced fabrication is concentrated in very few places, and the lithography equipment behind it in fewer still - effectively one company. Export controls now determine which countries can buy what, and that single set of decisions draws the map for everything below: where training capacity can be sited, which labs get the current generation of hardware, and who spends the next two years working a generation behind.

Standards and security: Risk management frameworks, management system certifications, evaluation requirements, procurement checklists. Unglamorous, and decisive - they determine what a regulated buyer is permitted to sign for, which quietly determines which products at the bottom of this stack have a market at all.

When something moves at this layer, everything below it re-prices. An export rule changes on a Tuesday and a two-year build plan is worth less by Wednesday.

02 - Infrastructure

Where intelligence gets built, then made to run somewhere.

Two stages sit inside this one layer. They get collapsed constantly, and that collapse is where most of the confusion about who does what in building AI comes from.

a) Build / Train

This part is physical. A data centre is a building full of computers, and almost none of it comes from one supplier. Six separate supply chains have to line up, each with its own constraint, and any one of them can be the reason a site opens two years late.

Someone has to own the building - land, permits, shell, and the fibre running into it. Sites are chosen years ahead on the basis of power availability and network routing rather than anything resembling ordinary property logic. Equinix is one of the companies in that business.

Someone has to supply the power. A single large site can draw what a mid-sized city draws, which puts it in a different relationship with the grid than any ordinary customer - you negotiate directly with generators, sometimes for the output of a named plant, sometimes by building your own. This is the binding constraint on new capacity right now. Chips can be bought faster than power can be connected, and the queue for a grid interconnection runs in years. Generators like Vistra sit on the other side of those contracts.

Someone has to sell the compute. Nvidia is the obvious name; the largest buyers increasingly design their own silicon alongside it, which is itself a signal about where the margin sits.

Someone has to wire the chips to each other. A training run isn’t thousands of separate jobs - it’s one job split across thousands of chips that have to stay in step, passing results back and forth the entire time. If the link between them is slow, adding more chips stops helping. There is an entire business in selling that link, and companies like Arista live in it.

Someone has to keep the accelerators fed. Compute is the expensive line item, so the storage tier exists to make sure none of it is sitting idle waiting on a read. Everpure and the high-throughput vendors compete on exactly that.

Someone has to take the heat away. Racks now concentrate enough of it that moving air across them no longer works, so water gets plumbed through the building, bringing in liquid cooling specialists like Motivair. And in dry regions, how much water a site draws has become a permitting question. Which means the cooling decision travels back up to Layer 01 and lands in front of a regulator.

Inside that building, the labs run the training - OpenAI, Anthropic, Google, Meta, Mistral, DeepSeek. Weeks of it, sometimes months. What comes out is a set of weights in a file.

The file does nothing on its own. It can’t answer a question, read a camera feed, or be opened by a user. Which is precisely why the next stage exists.

b) Deploy / Runtime

Taking that trained model and preparing it to actually run somewhere.

The runtime is what turns weights into something callable: loading the model into memory, batching incoming requests so expensive hardware isn’t idle, caching recent work so it isn’t recomputed, quantizing the model to run on cheaper silicon, scheduling across available capacity, and scaling machines up and down with traffic. Or, on the other path, compressing and compiling the whole thing until it fits on a single chip inside a device.

Every model call, without exception, passes through a runtime. The only question is who owns it and whether it’s visible as its own product.

Bundled runtime - here, the lab that trained the model also owns and operates the serving layer, hidden behind its own API or device. You never encounter “runtime” as a separate thing.

Cloud: OpenAI, Anthropic and Google serve their own models through their own APIs. A developer calling one of those is using that lab’s in-house serving stack without ever being told about it.
Edge: Tesla and Apple built their own on-device inference stack. The intelligence in the car or the phone runs on hardware they designed, with serving software they wrote, and nothing leaves the device to make it work.

Unbundled runtime - the company that trained the model and the company serving it are different businesses. This happens mainly with open-weight models: Llama, Mistral, DeepSeek. The creator publishes the weights and doesn’t operate them for anyone. Somebody still has to. That gap is a business.

Cloud, specialists: Together AI, Fireworks, Baseten, Modal, Groq. Serving other people’s models is the entire company, and that focus is why they tend to win on price-performance for inference specifically, carry the broadest model selection, and have new open models running first.
Cloud, hyperscalers: AWS Bedrock, Azure AI Foundry, Google Vertex AI. Here serving is one feature inside a much larger platform that also sells storage, databases and compute. The pitch isn’t raw performance - it’s that the customer is already inside. Billing, identity, security and compliance all carry over, so there’s no new vendor to approve and no new contract to negotiate. At enterprise scale that regularly outweighs a faster response time.
Edge: General Instinct on the specialist side, Hailo on the chipmaker side. Both take a model you bring them and compile it down onto physical silicon.

You’d expect edge to come out the same shape as cloud, and it doesn’t. The companies attaching runtime software to something larger aren’t cloud giants - they’re chipmakers. Hailo and Intel’s OpenVINO give you the software because the software is what makes their silicon worth buying. AWS Greengrass is about the only case of a genuine cloud giant crossing into edge.

So the edge version isn’t “cloud giant adds edge as a feature.” It’s “chip company ships free software to sell more chips.” A small difference, and the accurate one rather than the tidy one.

Runtime creates nothing new. It makes the intelligence usable - as an API call, or as something flashable onto a device. Whether it’s visible as its own business depends entirely on whether the model-maker and the runtime-runner are the same company.

03 - Products

Where someone else - a separate builder - takes that usable intelligence and puts it inside a real thing a person buys or opens.

Software products. A company builds an application and reaches a model through a runtime, either by:

calling a lab’s own API directly, using that lab’s in-house runtime invisibly, or
calling a third-party runtime serving an open model.

Either way the end user sees only the finished application. Never the model, never the runtime beneath it, never the supply chains beneath that. The work at this layer isn’t intelligence - it’s interface, workflow, trust, distribution, and knowing a customer’s job well enough to know which part of it is worth automating. That is a different discipline from training a model, which is why the companies doing it are usually different companies.

Examples: Cursor, Perplexity, Harvey. All three started here in the ordinary way - calling someone else’s API and building a product around it. All three now post-train their own models on open weights, because paying a per-call toll to a company that is also moving into your market stops making sense at scale. Harvey’s runs on Moonshot’s Kimi; Perplexity’s on Llama. Note what that requires: open weights from someone who trained them, and someone else’s infrastructure to run the training on. Harvey’s post-training went through Fireworks, which you met two sections ago. ChatGPT and Claude also sit at this layer, but they’re the collapsed case - the lab that built the model shipping the product itself.

Hardware products. A company builds a physical device - camera, robot, drone - and works with an edge runtime provider to compress a model onto that device’s chip, or builds that capability in-house.

The constraints here are harsher. There’s no round trip to a data centre, so latency is whatever that one chip can manage. The model has to fit inside a fixed power and thermal budget, because the device has neither active cooling nor a wall socket. And once it ships, updating it stops being a deployment problem and becomes a logistics one.

Examples: security cameras with on-device recognition, autonomous drones, industrial robots.

Genta Sentinel sits here, as an intelligence layer deployed onto camera infrastructure that is already installed. That’s the more interesting version of the hardware case. The cameras exist. The footage exists. Most of it is watched by nobody and reviewed only after something has already gone wrong. What’s missing isn’t hardware, it’s the intelligence to make the footage useful while the event is still happening. Closing that gap doesn’t require shipping new cameras. It requires getting a model to run on what’s already installed.

Systems decide who’s allowed to build → Infrastructure builds the intelligence and runs it through a runtime, owned in-house or rented from a third party → Products are separate builders who put that intelligence into an app or a device and hand the finished thing to a user.

You may have spotted that a company like OpenAI trains models, runs the servers that answer the requests, and sells ChatGPT directly to the public - all three layers, one company. Nvidia sells the silicon and the software that runs models on it. Google does the whole thing end to end. If the same companies keep turning up at every layer, what is the point of separating them?

Because the layers were never groups of companies. They’re jobs. Each has to be done before the next becomes possible, and every AI product that reaches a person has been through all three, whether one company did all the work or different companies divided it between them.

The question worth asking - which job is this company actually doing, and does it control the job above it?

Take a company selling an AI product built on somebody else’s API. It owns Layer 03 (products) and nothing above it. If the lab it depends on raises prices, it absorbs that. If the lab ships a competing product, it absorbs that too. Both its largest cost and its most serious competitor sit inside a business it has no say in. That is the position companies like Cursor and Perplexity spent the past year climbing out of, and it’s why each of them now trains a model instead of only renting one.

The same test applies anywhere on the stack. It won’t tell you who’s ahead. It tells you who’s exposed, and to what.

The intelligence gap in physical security

g_o22@yahoo.com (Gideon Onyewuenyi) — Wed, 05 Aug 2026 00:00:00 GMT

Every mall, warehouse, and estate has a wall of monitors in a back room, and a guard who’s supposed to be watching all of them at once. Nobody actually watches eight screens for eight hours. They watch none of them, most of the time, until something goes wrong and then everyone scrambles to find the right recording, on the right camera, at the right timestamp, hours after it mattered.

The cameras were never the problem. What’s missing is something that actually watches what they see.

The camera isn’t the bottleneck

There’s a version of this conversation that goes straight to hardware - buy more cameras, build a bigger control room, hire more guards. That’s the wrong fix. Right now, most cameras are just a hard drive with a lens attached. Something happens, and you find out about it later, if you find out at all.

What a site actually needs isn’t more equipment. It’s a layer of intelligence sitting on top of the cameras it already has, something that notices what’s happening in real time, and can answer questions about what already happened.

Real-time detection

A system like this runs detection continuously - restricted zone entry, loitering, crowd anomalies, after-hours movement and the moment something matches, it sends an alert with a snapshot attached. Not a hunch that needs reviewing at the end of the shift. An actual notification, in under a second, to whoever needs to see it.

That’s the difference between a camera and a security system. A camera records. A system tells you when something’s wrong.

Just ask.

Here’s the part that actually changes how people work: natural language search.

Instead of a guard fast-forwarding through six hours of static hallway footage looking for one moment, you type what you’re looking for - “person in a red jacket near the exit,” “employee opening the back door at night,” “unattended bag in the lobby” and the system finds it. Across every camera, in seconds, not hours.

Most operators have never had this. Reviewing footage has always meant either knowing exactly when something happened, or watching everything. This turns it into a search problem instead of a patience problem.

Setup in minutes, not months

The reason most operators never get past “we should really upgrade our security system” is that upgrading usually means a project - new hardware, new wiring, a vendor contract, an IT team involved for weeks.

The better version of this skips all of that. It reads from the cameras already on the wall, whatever brand they are, over the same RTSP or ONVIF connection they already use. No rip-and-replace, no new hardware, no waiting on a procurement cycle. Setup runs in minutes, not months. You’re not buying a new security system. You’re making the one you already have actually useful.

Where this leaves most operators

The fix for most security systems isn’t more hardware, and it isn’t a platform overhaul either. It’s making the cameras already on the wall capable of noticing things and answering questions.

That’s a smaller ask than most operators assume. It doesn’t take a platform overhaul to see the benefit - it changes how a site runs starting the day it’s connected.

The case for unifying a city's surveillance networks

g_o22@yahoo.com (Gideon Onyewuenyi) — Sun, 02 Aug 2026 00:00:00 GMT

Walk through any major business district and you can count cameras everywhere.

Gated estates have their own loops. Malls and hotels run their own systems. Government cameras sit at traffic lights, bus stops, and major junctions. On paper, that looks like a lot of coverage.

In practice, most of it becomes useless the moment something actually happens.

The problem is not that cities have too few cameras. The problem is that the cameras they already have cannot talk to each other.

Different vendors. Different formats. Different control rooms. No shared network. No common protocol. So when police need to track a suspect vehicle across a few streets, they usually cannot just pull up a feed and follow the trail in real time.

Someone has to visit each estate, mall, hotel, or office building. Someone has to request access. Someone has to copy footage to a drive. By the time the useful clip is found, the window for real-time response has already closed.

This is not a hardware problem. Cities do not need to start by buying thousands of new cameras. They need the cameras they already have to work together.

What is actually broken

The current model breaks in three obvious places.

First, private and public systems operate in silos. A residential estate may have useful street-facing cameras, but those feeds sit inside its own security room. A mall may have cameras covering a public road, but that footage is only accessible through the mall’s own system. Government may have traffic cameras nearby, but those feeds live somewhere else entirely.

Second, vendors do not always share a common language. One building uses one camera brand. The next uses another. The city uses a different stack. Each system may work fine on its own, but the city has no easy way to coordinate them during an incident.

Third, almost everything is reactive. Footage gets pulled after something has happened. A person reviews it manually. The system helps explain the past, but it rarely helps shape the response while the event is still unfolding.

That is the wrong way to think about city surveillance.

Fix the software, not the hardware

The expensive answer is to rip out everything and start again. That is unrealistic, and in most cities it will not get funded.

The practical answer is a middleware layer: an open-architecture video management system that sits above the cameras already installed and gives them one shared operating layer.

This works because of a standard most people have never heard of: ONVIF. Think of it as a universal translator for security cameras. If a camera is ONVIF-compliant, a central system can usually discover it, authenticate it, and pull its feed regardless of who manufactured it.

That changes the shape of the problem.

Instead of asking every estate, hotel, office building, mall, and public agency to replace its cameras, the city can ask them to connect selected feeds into a federated network.

Suddenly, you can put a residential estate’s cameras, a mall’s cameras, and the city’s traffic cameras on the same dashboard.

Two things become possible once you do this.

Federated control.

Estates and businesses should not have to surrender their entire security systems to a central authority.

They should keep ownership of their own footage. They should keep their internal cameras private. They should decide which outward-facing feeds are eligible for sharing, especially the ones covering public roads, entrances, exits, and perimeter lines.

The city command centre does not need to see inside people’s homes, offices, hotel corridors, or private compounds. It needs a lawful, auditable way to access the public-facing cameras that help reconstruct or respond to events in shared space.

That is the difference between integration and seizure.

A well-designed system lets private operators keep control while still contributing to public safety.

Automated alerts.

The second benefit is automation.

The goal should not be to pay people to stare at thousands of screens. That model does not scale, and it fails exactly when attention matters most.

The system should watch for specific signals and escalate only when something is worth reviewing.

License plate recognition can flag a wanted vehicle. Object detection can identify a stalled vehicle blocking a key route. Crowd detection can highlight abnormal gathering patterns. Perimeter analytics can flag activity around restricted infrastructure. A human operator then reviews the alert and decides what to do next.

This is not about replacing judgment. It is about using software to make sure human attention is spent on the few moments that actually matter.

The infrastructure problem nobody talks about

Even a perfect software layer fails if the physical infrastructure is weak.

If you have lived in Lagos for more than a week, you already know the problem: power drops, network links fail, fibre gets cut, and the system that looked good in a presentation suddenly goes dark.

A citywide camera network has to be built for that reality.

Every important camera node needs local resilience. That means solar panels and battery banks where possible, especially for road-facing and perimeter cameras. A camera that depends entirely on one unstable grid connection is not public safety infrastructure, just a decoration.

The network also cannot depend only on buried fibre. Fibre is valuable, but it is fragile in cities where construction, road work, and informal digging happen constantly. A wireless mesh can give the system a second path. Cameras and network nodes can relay data to each other and reroute around dead links instead of collapsing when one line is cut.

The third piece is edge processing.

You should not stream everything, all the time. Most of what a camera sees is nothing happening. Sending every frame from every camera to a central command centre is a fast way to waste bandwidth, overload storage, and create a system that cannot scale.

Processing should happen close to the camera. The edge device should detect motion, plates, anomalies, or other configured events locally, then send metadata or selected clips back to the centre when something matters.

That is the difference between a citywide system that scales and one that chokes when camera number 501 comes online.

Who pays for it

A city cannot fund this entirely with public money. It has to be a partnership, and the incentives have to match the type of participant.

For residents and private estates, the model should be a carrot, not a stick.

Install a compliant outward-facing camera. Agree to share specific feeds during defined emergencies. In return, receive a property tax rebate, subsidised hardware, discounted maintenance, or priority access to verified incident support.

Nobody wants government mandating what happens inside a private compound. The better approach is to reward people for contributing useful public-facing coverage while leaving private areas private.

Commercial venues are different.

Malls, hotels, logistics hubs, event centres, fuel stations, and large office complexes draw public traffic and create public safety obligations. For them, camera compliance can reasonably be tied to operating licenses, especially for entrances, exits, loading bays, and street-facing perimeters.

If a business benefits from public movement around its property, it is not unreasonable to require basic, interoperable coverage of the public edges of that property.

The part that actually matters: privacy

This is where most surveillance proposals fall apart, and honestly, where they should get the most scrutiny.

A unified camera network only works if people trust that it will not become a tool for casual monitoring, political abuse, commercial spying, or personal harassment.

That trust cannot be built on speeches. It has to be built into the system.

Access should always be logged. Nobody should be able to browse feeds casually. Every camera view should be tied to an active case file, with a permanent record of who accessed the feed, when they accessed it, what they viewed, and why.

Footage should not live forever. Set a hard purge window. Two to four weeks is reasonable for routine footage. If a clip is not explicitly locked as evidence for an active investigation, it should be deleted automatically.

Emergency access should still leave a paper trail. If law enforcement needs a private feed during an active emergency without a warrant, the system can allow a time-limited override. But that override must be logged, reviewed, and followed by proper legal authorization within a defined window, such as 48 hours. If the authorization does not arrive, access should be cut automatically and regulators should be alerted.

These rules should be enforced in code, not buried in a policy manual.

Rules people can quietly ignore are not rules. They are suggestions.

The real design problem

Fixing city surveillance is not really about better cameras.

It is about getting the cameras that already exist to cooperate. It is about building infrastructure that survives bad power and bad networks. It is about using analytics to move from after-the-fact review to real-time response. And it is about putting automatic limits on who gets to look at what.

Cities that get this right will not just be safer. They will be safer without becoming the kind of surveillance state nobody wants to live in.

That balance is the whole design problem.

Get it wrong in either direction, and you build something worse than what you started with.

AI writes code now. That's exactly why you need to learn programming.

g_o22@yahoo.com (Gideon Onyewuenyi) — Tue, 07 Apr 2026 00:00:00 GMT

What do you genuinely think about programming? Is it dead or not? Do people still need to learn the art of programming or not?

This is a question I find interesting to think through, so let me share my perspective.

Programming is not dead, but routine coding is being automated away

Here’s how I see it:

What IS dying or at least shrinking:

Writing boilerplate code from scratch
Memorising syntax line by line
Simple CRUD apps and basic scripting
Entry-level “code monkey” work that doesn’t require deep thinking

What is NOT dying and is arguably more valuable than ever:

Problem-solving thinking: the ability to deeply understand a problem and figure out the best way to solve it, not just jump into coding
Problem decomposition: turning a messy real-world problem into something a machine can solve
Systems thinking and system design: understanding how different parts of a software system or architecture interact, and designing them to work together efficiently
Debugging intuition: Being able to figure out why something broke, not just that it broke
Security and reliability reasoning: thinking about edge cases, vulnerabilities, and failure scenarios, because AI-generated code can be fragile or insecure
Domain-specific engineering: understanding areas like distributed systems, machine learning infrastructure, operating systems, or compilers, where real complexity lives

My opinion

Saying “programming is dead” is confusing the tool with the discipline.

AI is to programming what calculators were to mathematics: it removes the tedious arithmetic, but you still need to understand math to use a calculator meaningfully.

What’s actually happening is a raising of the floor and the ceiling simultaneously:

The floor rises: non-programmers can build simple things with AI
The ceiling rises: skilled programmers can build things that were previously impossible for a single person or small team

The dangerous middle is people who learn just enough syntax to write code without understanding what it’s doing. AI makes that easier, which means it also makes it easier to build things that are broken, insecure, or unmaintainable in subtle ways.

Should people still learn programming?

Yes, but the goal has shifted.

You should learn programming to develop:

Computational thinking: how to reason about logic, state, and systems
The ability to evaluate AI output: you can’t catch AI’s mistakes if you can’t read code
Deep problem-solving skill: which only comes from struggling with real problems yourself
Leverage: a programmer using AI is 5-10x more productive than one who isn’t

The people who will win in the next decade aren’t those who avoid programming because “AI does it”. They’re the ones who understand programming deeply and use AI as a force multiplier.

Programming as a rote skill is being commoditised. Programming as a thinking discipline is becoming more important than ever.

Learn it — but learn it at the level of understanding, not just syntax.

Who Will Win the AI Race?

g_o22@yahoo.com (Gideon Onyewuenyi) — Tue, 31 Mar 2026 00:00:00 GMT

Everyone might be watching the wrong scoreboard.

Every week, a new AI model drops, and the internet argues about which one writes better code, reasons more clearly, or hallucinates less. It’s entertaining. It’s mostly irrelevant.

The AI race won’t be won on benchmarks. It will be won on the same things every technology platform war has been won on: distribution and data. When you score the three serious contenders on those axes — Google, OpenAI, and Anthropic — the picture looks very different from what the headlines suggest.

There is still enough distance left in the race, and Google is not losing this race. In fact, it may be the only company structurally positioned to win it.

OpenAI’s real position: strong brand, shaky foundation

OpenAI got here first. That matters; their first mover advantage cannot be overlooked.

ChatGPT became synonymous with “AI” the way Google once became synonymous with “search,” and that cultural weight is genuinely hard to displace. ChatGPT hit 500 million monthly active users faster than almost any product in history.

But the first-mover advantage comes with a hidden cost: OpenAI is, at its core, a model company without a platform.

No search engine. No operating system. No app store. No device layer. Every inference run goes through Microsoft’s Azure. Every GPU gets negotiated through a partner whose long-term interests are not perfectly aligned with its own.

The $100 billion valuation is priced on the assumption that ChatGPT’s cultural moment converts into durable platform power.

That conversion is not guaranteed.

Anthropic’s real position: the trusted specialist

Anthropic made a smart early bet — compete on trust.

Developers, safety researchers, and enterprise technical buyers consistently rate Claude as the most reliable, honest, and nuanced model available. That credibility was built through years of careful, safety-first research. In an industry where hallucinations and misaligned outputs carry real costs, that’s a legitimate moat.

But it’s a narrow one.

For example, Anthropic doesn’t control the hardware it runs on AWS. It doesn’t have a consumer distribution play. And it’s spending heavily to compete against organisations with far larger balance sheets.

Anthropic is winning the battle for developer credibility. Whether that wins the larger war is an open question.

Google’s real position: the sleeping giant that was never really asleep

Here’s what the “Google is losing” narrative might be getting wrong: confusing being late to a product launch with being behind in a race.

Google has structural advantages that no one else can replicate from scratch.

1. Distribution measured in billions, not millions.

Google Search processes roughly 8.5 billion queries per day. Gmail has 1.8 billion active users. Chrome runs on 65% of the world’s browsers. Android powers 72% of global smartphones. YouTube is the second-largest search engine on earth.

When Google integrates AI into these surfaces, which it is already doing, it doesn’t need to acquire users. It just needs not to lose them. That is a fundamentally different competitive position than anyone else occupies.

2. A data flywheel that is genuinely unmatched.

Training powerful AI models requires two things in enormous quantities: compute and data.

Google has more proprietary data flowing through its systems every day than any organisation in history. Search queries, Maps navigation, YouTube watch patterns, Gmail context — this is a feedback loop that compounds. Every interaction makes the model smarter. No startup can replicate two decades of this kind of signal.

3. The hardware nobody talks about.

Google invented the TPU specifically to run AI workloads efficiently. It is not dependent on Nvidia the way OpenAI, Anthropic, and even Microsoft are.

When the world’s most constrained resource is compute, owning the hardware layer is a scale advantage.

4. Monetization that doesn’t need AI to “win.”

Google already generates $280 billion in annual revenue, almost entirely from advertising. AI makes Search better, which makes ads more valuable, which generates more revenue to invest in AI.

OpenAI needs its AI products to be the primary revenue source. Google can afford to treat AI as a capability enhancer for a business that already works.

5. DeepMind.

Before OpenAI was a household name, DeepMind was producing research that defined the field — AlphaGo, AlphaFold, and much of what underpins Gemini’s architecture. The intellectual foundation at Google is not a gap to close. It’s a platform to build on.

So why does the “Google is losing” narrative persist?

Three reasons I can think of at the moment, all legitimate, just not decisive.

Google moved slowly at the product layer. At the early times, Bard was underwhelming. Then the Gemini rebrand was messy. These fumbles cost Google real narrative ground.

Developer trust is genuinely lower. Google has a history of building beloved products and shutting them down. Developers might be cautious about building on Google platforms in a way they aren’t with OpenAI or Anthropic. That’s a cultural problem a press release won’t fix.

The attention economy favors the new. OpenAI is the story. Google’s steady structural compounding is less exciting to write about — which means it’s less visible in the discourse than it deserves to be.

None of these problems is unfixable. All of them are execution issues, not structural deficits.

Google can improve its product velocity. It can improve developer relations.

It cannot give its competitors 8.5 billion daily search queries or 20 years of proprietary training data.

The question nobody is asking: what does “winning” even mean?

The AI race is actually three races running simultaneously.

The model race — who produces the most capable AI? OpenAI leads today. Anthropic is close. Google is closing fast.

The platform race — who becomes the default layer on which AI-powered products get built. Google and Microsoft are the most serious competitors here.

The consumer race — who becomes the AI assistant ordinary people use every day. This is OpenAI’s strongest hand right now. It is also Google’s most natural territory, and that fight is far from over.

A company can lose the model race and still win the platform war. A company can dominate developer mindshare and still get outflanked on consumer distribution. The “who’s winning” question depends almost entirely on which race you’re watching.

Here’s what I think

If AI consolidates into infrastructure — a world where one or two AI layers become as ubiquitous as operating systems — then Google’s distribution advantage becomes nearly insurmountable.

The company that already lives on 4 billion devices, processes the world’s information, and runs on its own custom hardware is structurally positioned to own that world.

OpenAI is the most interesting company in technology right now. Anthropic is building the most trustworthy AI.

But Google is playing a different game entirely.

The benchmark watchers might be measuring speed while Google is measuring surface area.

In platform wars, surface area wins.

Everything is Changing Now

g_o22@yahoo.com (Gideon Onyewuenyi) — Sun, 15 Feb 2026 00:00:00 GMT

In the past years, I realised my job was changing so fast, and it wasn’t just mine. A few years ago, my value as a professional was defined by execution.

How fast can I complete tasks? How efficiently can I process information? How reliably can I deliver outputs?

Like most professionals, I was the system—every input flowed through me.

But over the past year, something changed massively. I stopped being the system and started building systems that worked for me.

This is the shift we’ve entered: the shift from execution to agency, from doing to directing.

The First Wave of AI Didn’t Change Our Roles

When generative AI first became popular, most of us used it as an assistant. We asked it to write emails, summarise documents, generate ideas.

It made us faster, but it didn’t fundamentally change our role. We were still doing the work, just with assistance.

The new wave of AI is different. It doesn’t just assist you—it executes on your behalf.

What’s The Real Shift

For decades, professional value was tied to execution. Now, value is shifting toward orchestration.

The highest-leverage professionals are no longer the ones doing the most work. They are the ones designing systems that do the work.

This is the difference between using AI and directing AI. It’s the difference between being a worker and being an orchestrator.

Here Is What I Think

When people think about AI, they ask: “How can AI help me do this task?”

But the better question is: “How can AI do this task without me?”

This is where agency begins—the capacity to act independently, make decisions, and achieve goals. Not when AI assists you, but when AI operates on your behalf.

The Transition Doesn’t Happen All At Once

It starts small:

You identify repetitive workflows in your daily activities
Tasks that follow predictable patterns
Tasks that consume time but don’t require deep strategic thinking
Then you design systems that handle them

At first, it starts small. One workflow. Then two. Then the entire operational layers.

Over time, you stop being the executor of processes. You become the architect of systems.

Those Who Thrive Will Be the Ones Who Make This Shift Early

The most valuable skills are already changing. Execution is becoming automated. But system design, strategic thinking, and orchestration are becoming more valuable than ever.

The future belongs to professionals who can define goals clearly, design workflows intelligently, and effectively supervise autonomous systems.

Not because humans are being replaced, but because human leverage is increasing.

The New Definition of Professional Leverage

There was a time when leverage came from working harder. Then, leverage came from working smarter.

Now, leverage comes from building systems that work for you.

This is the era of agency—and the professionals who embrace it early will operate with a level of leverage never before possible.

The Question Is No Longer Whether This Shift Will Happen

It already is.

The real question is whether you will remain an executor or become an orchestrator.

Because your job is no longer task execution—it is system design.

PS: New editions of this topic will be published based on real-world case studies, cheers!