DEV Community: Alphonce Oyunga

CPU vs GPU vs TPU vs NPU — What's Actually Different?

Alphonce Oyunga — Tue, 30 Jun 2026 13:13:29 +0000

If you've ever shopped for a laptop or read a chip announcement, you've seen these four letters thrown around like they're interchangeable. They're not. Each one is a processor, but each was built to solve a different kind of math problem efficiently. Here's the difference, explained with real examples of where you'd actually run into each one.

The short version

CPU (Central Processing Unit) — the generalist. Good at everything, great at nothing specific.
GPU (Graphics Processing Unit) — the parallel workhorse. Built for doing thousands of simple operations at once.
TPU (Tensor Processing Unit) — Google's custom chip, built specifically to accelerate the matrix math behind neural networks.
NPU (Neural Processing Unit) — a small, power-efficient chip baked into phones and laptops to run AI tasks locally without draining your battery.

Now let's go one level deeper.

CPU: the all-purpose brain

A CPU has a small number of powerful cores (typically 4 to 16 in consumer devices) designed to execute instructions one after another extremely fast, while juggling many different kinds of tasks. It's optimized for sequential logic, branching decisions, and low-latency response — the kind of work where step 2 depends on the result of step 1.

This is why your CPU handles your operating system, runs your web browser, manages file systems, and executes business logic in your backend code. It's flexible enough to do almost anything, but that flexibility comes at a cost: it's not efficient at doing the same simple operation millions of times in parallel.

Example use case: Running a Node.js API server, compiling code, querying a database, or running an Excel spreadsheet with complex formulas. Any task that's logic-heavy and sequential.

GPU: built for doing one thing, a million times at once

GPUs were originally built to render graphics — and rendering a frame means computing the color of millions of pixels independently and simultaneously. That requirement led to a very different architecture from the CPU: instead of a few powerful cores, a GPU has thousands of smaller, simpler cores that all execute the same instruction across different pieces of data at the same time. This is called SIMD (Single Instruction, Multiple Data) parallelism.

It turns out that the math behind training neural networks — mostly matrix multiplications and additions — looks a lot like rendering pixels: lots of small, independent, repetitive operations. That's why GPUs became the default hardware for deep learning, even though that's not what they were originally designed for.

Example use case: Training a deep learning model in PyTorch or TensorFlow on an NVIDIA RTX or A100 card, rendering 3D scenes in a game engine, or running large-scale scientific simulations (fluid dynamics, weather modeling).

TPU: a chip designed specifically for neural network math

A TPU is Google's answer to the question "what if we stopped repurposing graphics hardware and built a chip purely for neural network workloads?" TPUs are Application-Specific Integrated Circuits (ASICs), meaning they're not general-purpose at all — they're wired at the hardware level to do one thing extremely fast: matrix multiplication, the core operation in both training and running neural networks.

The core component is something Google calls a "systolic array," which lets data flow through a grid of processing units in a way that drastically reduces the memory movement that normally slows down matrix math. The tradeoff is flexibility — TPUs aren't great at general computing or even at every type of machine learning model, but for large-scale transformer and deep learning workloads, they can outperform GPUs on both speed and power efficiency.

TPUs aren't something you buy and plug into a desktop; they live in Google's data centers and are accessed via Google Cloud or Colab.

Example use case: Training large language models or vision transformers at scale on Google Cloud TPU pods, or running inference for Google services like Search ranking, Translate, and Photos' image recognition.

NPU: AI acceleration that fits in your pocket

An NPU is also purpose-built for neural network math, similar in spirit to a TPU, but designed with a completely different goal: efficiency at a tiny power and size budget, rather than raw throughput in a data center. NPUs are now standard in modern smartphones, laptops, and even some smart cameras, where they run AI features locally on-device instead of sending data to the cloud.

Running inference locally on an NPU means lower latency (no network round-trip), better privacy (your data never leaves the device), and dramatically lower power draw than running the same task on a CPU or GPU.

Example use case: Face ID-style face unlock, real-time photo background blur in a video call, on-device voice transcription, and the "AI" features marketed on recent chips like Apple's Neural Engine, Qualcomm's Hexagon NPU, or Intel's AI Boost — all of which power local features like live captions, image search in your photo gallery, or background noise removal, without sending anything to a server.

Putting them side by side

Chip	Designed for	Core count	Where you'll find it
CPU	Sequential, general-purpose logic	Few, powerful	Every computer and server
GPU	Massive parallel computation	Thousands, simple	Gaming PCs, ML training rigs, data centers
TPU	Large-scale neural network matrix math	Specialized systolic arrays	Google Cloud, Colab
NPU	Efficient, low-power AI inference	Specialized, small footprint	Phones, laptops, edge devices

Why this matters for you as a developer

If you're training a model from scratch, you're choosing between a GPU (flexible, widely supported, available on every major cloud) and a TPU (faster and cheaper at scale, but locked into Google's ecosystem and a narrower set of supported frameworks). If you're shipping a mobile app with an on-device AI feature, you're targeting the NPU through frameworks like Core ML, NNAPI, or ONNX Runtime, so the feature runs fast and doesn't kill the battery. And for everything else — your web server, your database, your build pipeline — that's still squarely CPU territory.

None of these chips replaced the others; they specialized. Understanding which one fits which job is increasingly part of writing efficient software, not just a hardware trivia question.

Why AI Agents Use MCP Servers (And Why It Changes Everything)

Alphonce Oyunga — Tue, 02 Jun 2026 08:25:40 +0000

You've probably seen the term MCP floating around dev Twitter, GitHub repos, and AI tool docs lately. If you've wondered what it actually is and why every serious AI agent setup seems to depend on it — this article is for you.

Let's break it down without the fluff.

The Problem Before MCP

Imagine you're building an AI agent that needs to:

Read files from your local filesystem
Query a database
Call a third-party API
Trigger a GitHub workflow

Before MCP, every one of those integrations was its own snowflake. You'd write custom tool definitions, wire up function-calling schemas, handle auth per-service, and pray nothing broke when you swapped LLM providers.

It was integration hell — duplicated logic, brittle glue code, and zero standardisation.

Enter MCP: The USB Port for AI

Model Context Protocol (MCP) is an open standard developed by Anthropic that defines how AI models talk to external tools and data sources. Think of it as the USB-C of AI integrations — one universal interface, many devices.

An MCP server is a lightweight process that exposes a set of tools, resources, and prompts over a well-defined protocol. The AI agent connects to it as an MCP client and can discover and invoke tHere's the core idea in one diagram:

Here's the core idea in one diagram:

AI Agent (MCP Client)
        │
        ▼
   MCP Protocol
        │
   ┌────┴─────┐
   │ MCP Server│  ← exposes tools, reads files, calls APIs
   └──────────┘

No custom glue. No per-agent rewiring. Just protocol.

What MCP Servers Actually Do

An MCP server can expose three types of primitives:

Primitive	What it does	Example
Tools	Functions the agent can call	`read_file`, `run_query`, `send_email`
Resources	Data the agent can read	File contents, DB records, docs
Prompts	Reusable prompt templates	Pre-built reasoning chains

When your agent connects to an MCP server, it gets a manifest of everything available — and can decide at runtime what to use. This is what makes agents feel genuinely intelligent rather than scripted.

Why Agents Specifically Benefit from MCP

1. Dynamic Tool Discovery

Hard-coded tool lists don't scale. With MCP, an agent can query a server and discover new capabilities without redeployment. Spin up a new MCP server for a new service, and every agent that connects gets access — automatically.

2. Separation of Concerns

Your agent logic stays clean. The messy details of how to talk to Postgres, or how to authenticate with Notion, live in the MCP server — not scattered across your agent codebase.

This is huge for maintainability. Update the MCP server once; every agent benefits.

3. Provider Agnosticism

Because MCP is a protocol, not a library, it works across LLM providers. Whether you're running Claude, GPT-4, or an open-source model, your MCP servers remain the same. Swap the brain, keep the nervous system.

4. Multi-Agent Architectures

In complex systems, you might have a supervisor agent orchestrating multiple sub-agents, each with different roles. MCP makes this clean — each agent connects to the servers it needs, with clearly scoped permissions. No tangled shared state.

5. Security and Permissioning

MCP servers can implement fine-grained access controls. Your agent can be given read-only access to a filesystem server, or scoped to a single database schema. You define the boundaries in the server; the agent can't exceed them.

A Concrete Example

Say you're building a coding assistant agent. Here's how MCP fits in:

Agent: "I need to read the current codebase and run the test suite."

→ Connects to: filesystem MCP server (read tools)
→ Connects to: shell MCP server (execute tools)
→ Discovers: read_file, list_dir, run_command

Agent calls read_file("src/main.py") → gets content
Agent calls run_command("pytest") → gets test output
Agent reasons over results → suggests fixes

All of this happens over the MCP protocol. No custom integration code in the agent itself. The agent is just reasoning; the servers handle the doing.

The Ecosystem is Growing Fast

The real power of MCP is the community building around it. There are already MCP servers for:

Filesystems (local, S3, GCS)
Databases (Postgres, SQLite, MongoDB)
Dev tools (GitHub, GitLab, Jira, Linear)
Productivity (Notion, Google Drive, Slack)
Browser automation (Playwright, Puppeteer)
Custom internal tools — built by teams like yours

Because the spec is open, anyone can write an MCP server. And because the protocol is standardised, it works with any compliant client.

Should You Build With MCP?

If you're building any of the following, the answer is yes:

An AI agent that touches external systems
A multi-tool assistant
A workflow automation with LLMs at the core
Internal tooling powered by AI

The investment in setting up MCP servers pays off fast. Your agents become composable, your integrations become reusable, and your architecture becomes legible to the next person who reads the code.

TL;DR

AI agents use MCP servers because:

They standardise how agents talk to tools — no more one-off integrations
They enable dynamic tool discovery — agents adapt at runtime
They enforce clean separation of concerns — agent logic stays pure
They work across LLM providers — your integrations outlive your model choices
They make multi-agent systems manageable — scoped, composable, secure

MCP isn't just a convenience. It's the infrastructure layer that makes serious AI agent development actually tenable.

If you're just getting started, check out the official MCP documentation and browse the growing list of open-source MCP servers on GitHub. The best way to get it is to wire one up yourself.

If find this interesting please drop a like and comment on this.

As someone who is trying to Develop an engineering mindset, this article strongly resonated with the struggles I have faced trying to understand software development from a systems first perspective rather than language first. This is good advice.

Alphonce Oyunga — Tue, 26 May 2026 08:09:43 +0000

Stanley Chege Thuita

May 22

10 First-Principles Strategies to Learn Any Programming Language Deeply

#go #beginners #learning #productivity

4 min read

OUT WITH THE OLD IN WITH THE NEW

Alphonce Oyunga — Mon, 25 May 2026 09:21:01 +0000

Google I/O happened last week and there are a lot of new products coming from google. The main theme of the conference was based on artificial intelligence. Honestly speaking, in this current time is there anything in the tech world that is not built around AI. We all know of the controversial AI bubble and how its bust will affect the tech ecosystem.

All that aside, I noticed something new from Google. They are integrating Gemini CLI into the Antigravity 2.0 CLI tool. Let me break down what this means. First of all you need to understand that as of June 18, 2026 Gemini CLI and Gemini Code Assist IDE extensions will stop serving requests for Google AI pro and Ultra, as well as for those using the free version.

The transition is actually smooth. It only takes the simple use of following commands in your terminal depending on the system software you’re using.
Microsoft windows
Windows Powershell;

irm https://antigravity.google/cli/install.ps1 | iex

Windows CMD ;

curl -fsSL https://antigravity.google/cli/install.cmd -o install.cmd && install.cmd && del install.cmd

macOs | Linux

curl -fsSL https://antigravity.google/cli/install.sh | bash

After running the commands on your terminal, you can open the CLI by running the command ‘aggy’ on your terminal. You will follow the simple setup steps and authentication procedures.

TECHNICAL UPDATES

Gemini CLI proved that the terminal is the perfect environment for agentic tasks. This claim can be backed by the millions of users of the tool. The community boasts of over 100,000 GitHub users, 6,000 merged pull requests , and hundreds of contributors. This is according to Dmitry Lyalin Group Product Manager and Taylor Mullen Principal Engineer ; here’s the link https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/link

Migrating from Gemini CLI;
On the first launch of Antigravity CLI, you should see Migration Options where you have a choice of migrating your existing Gemini CLI extensions to the equivalent Plugins.
You should note that some of the features of Gemini CLI cannot be migrated 1 to 1 for example custom themes are not currently supported .

Gemini CLI launched extensions, a way to extend the CLI by sharing capabilities. The industry has now moved to a fancy name “Plugins”. A plugin is just an add-on, for technicality it is a software component that adds new features or custom functionality to an existing program without altering the core software.
Users should be prompted on the first launch of Antigravity CLI to have their extensions mitigated to plugins.
This can also be simply done by running a command on the terminal;
‘agy plugin import gemini’
Running the command will search for each locally installed extension and convert them to an Antigravity plugin.

RULES(context files)
Antigravity CLI supports the following context files:
Workspace Context: It reads both Gemini.md and Agents.md from your active workspace directory.
Global Context:Automatically loads and enforces loads and enforces global constraints located at ‘’~/.gemini/GEMINI.md’

AGENTIC SKIllS
Agentic skills work the same to the way it worked on Gemini CLI. They are managed with the same /skills command and are also converted to slash commands allowing them to be invoked manually.

Global skills for Gemini CLI are shared with Antigravity CLI across all workspaces. There is no action needed for workspaces; they are picked up automatically.
Note that Antigravity CLI workspace-specific skills are stored in ‘.agents/skills’, so if you have any project/workspace skills in a given project in the Gemini CLI ‘.gemini/skills’ folder, it will have to be moved.

MCP Servers
Antigravity supports both local and remote MCP servers and provides the same /MCP command to manage them. The main difference between Gemini CLI and Antigravity CLI is the file location where mcp servers are defined.

Antigravity and Antigravity CLI both store MCP configurations in a mcp_configuration.json file while Gemini CLI stores them inline in the systems settings.json.

Note: All the work presented here has been referenced from the official blog by Google on the migration so its factual research.

Embrace The Struggle

Alphonce Oyunga — Mon, 16 Mar 2026 07:14:36 +0000

I have been struggling with executing what I have learnt especially in the weekly assessment tests that happen every Friday at the company or the record sessions. I was avoiding the real problem with assumption that maybe the constant failure was due to unpreparedness or rather my mood before I go for these sessions. The reality dawned on me during my last checkpoint which I scored a poor 2/10. I remember sitting in that exam room staring at the screen as the cursor kept blinking on the text editor. I had hit the famous Naruto hand sign while thinking to myself how bad I was.

This led me to think to myself how many times I copied my error to a chat bot and proudly read through the solution lying to myself that I had understood where the problem was.That was a big lie, truth is I had skipped a big part of the learning process.This part was what many developers describe as "The struggle". Funnily enough this is a constant part of many disciplines not just software programming. The period where you hit a bottleneck and that error becomes your next lesson.

The reality of the modern developer especially at the beginner level is that artificial intelligence produces most of the code and learning gets hindered in the process. Programming can be hard and with AI doing 80-90% of code one may be tempted to skip the crucial part of understanding coding rather than cramming it.I'm actually a victim of taking the easy way out each time I hit an error, and yeah, I'm now facing my own consequences.

Linus Tovarld in an interview once said that he loves learning new things because he gets to fail and the best part is that through these failures that he actually gets better. Those words have actually stuck with me and have got me thinking how I can do things better.The errors will be lessons and the documentation will become my new point of reference. This does not mean that I will not engaging with AI at all, cause these modern demand constant update on the evolving world of tech.

I want to embrace the struggle even more than before.Maybe we should all do. I love this work and want to become a better programmer even if that means that I have to study the traditional ways of learning to program.

Art of Computer programming.

Alphonce Oyunga — Thu, 12 Feb 2026 08:08:33 +0000

Well, if you've clicked on this post you might be expecting a deep dive into why computer science or programming is a science. I would like you to hold your horses, this is more of my approach to coding as a rookie at this skill. The thesis of my article is based on my own approach to coding given that I have a great background in artistic fields more than technical based or STEM fields.
I first encountered coding in 2021.Back then coding to me meant nothing, actually I only found interest in it from the fact that one of my friends was a leader in the tech club at my former school.I knew from the start that my aim was to go for functions since as rumors had it, their were fine ladies at these conventions. Well, that changed when I started exploring the world of technology and found out there was more to it than just fine ladies(well I always knew but was bluntly ignorant.)
Last year was the first time I engaged coding for the first time.It was a decision that came from a place of genuine interest and career shift. I came across an advert from a tuition free training institution called Zone01 Kisumu.The same interest drove me to follow the application process. I landed a spot in the piscine a one month selection process.I accredit my growth to that month because of the fact that up until then then only thing I knew about coding was vs code. It is during this one month that I learnt that programming was more than just Hello world.
Honestly, programming is not as easy as some people would like to tell you. During that first month of real programming I realized that up till then I had not done anything remotely hard as programming. I had to shift the way I approached it, That's when I decided to relate this skill to fields that I was used to. That is the only way I could understand the spectacle of writing code on an IDE and it outputs information. I started looking at all these great coders as Picasso's of there field, using the IDE as there canvas and the syntax as there paint.
Well, programming like any art form has its own technicalities, with programming having more. The different coding languages and there various accents(syntax).Honestly, I'm still figuring out a lot of things about coding,with my first language being Golang it has forced to go back to the STEM subjects and borrow ideas from them.It might be hard but what can say 'Do hard things'.