DEV Community: Okeke Chukwudubem

Day 3 of building an AI agent that controls a phone. The agent can now see. Tesseract OCR is running locally in Termux. Screenshots text extraction coordinate mapping. Tested on WhatsApp. It found a contact by reading the screen. All offline.

Okeke Chukwudubem — Wed, 10 Jun 2026 15:30:38 +0000

Okeke Chukwudubem

Jun 10

Project Log #3: The AI Phone Agent Can Now See

#ai #android #buildinpublic #ocr

2 min read

Project Log #3: The AI Phone Agent Can Now See

Okeke Chukwudubem — Wed, 10 Jun 2026 15:29:21 +0000

Day 3. Screen text detection is working. The agent is starting to understand what's on the screen.

The first two days were about the foundation—getting Gemma 4 to talk to ADB, parsing commands, and creating the repo.

Today was about solving the hardest problem: how does the agent know what's on the screen?

The Problem

An AI that can't see is useless. You can tell it "open WhatsApp and message Mom," but once WhatsApp opens, the agent is blind. It doesn't know where the search bar is. It can't find Mom's name. It can't locate the message box.

I needed a way for the agent to read the screen—offline, on a phone, without cloud APIs.

The Repo

👉 github.com/Dexter2344/phone-agent

The new vision.py module is live. It handles screenshot capture, OCR text extraction, and text-to-coordinate mapping.

Today's Progress

Task	Status
Installed Tesseract OCR in Termux	✅ Done
Captured a screenshot via ADB	✅ Working
Extracted text from the screenshot	✅ Working
Mapped text positions to screen coordinates	🔧 In progress
Tested on WhatsApp contact list	✅ First successful read

How It Works

The pipeline is simple:

Capture: ADB takes a screenshot and saves it locally.
Extract: Tesseract OCR scans the image and returns all text it finds, along with bounding box coordinates.
Map: A Python script matches the extracted text to known UI elements. If the agent needs to find "Mom," it scans the OCR output for the word "Mom," grabs the coordinates, and tells ADB to tap there.

All of this runs inside Termux. No internet. No cloud vision API. Just open-source OCR on a phone CPU.

What's Working

I tested it on WhatsApp. The agent captured the screen, extracted the contact list, found a specific name, and returned the coordinates. It's slow—about 8-12 seconds per screen scan on my device—but it works.

Na What's Broken

OCR misreads some text. "Mom" becomes "Morn" or "M0m." I'm working on fuzzy matching.
Small UI elements (icons, emojis) are invisible to OCR. I'll need image-based detection for those.
Tesseract is heavy. It takes 3-4 seconds just to load before scanning. I'm looking at lighter alternatives.

What's Next (Day 4)

Add fuzzy text matching to handle OCR errors
Write the verification layer: after each action, check if the expected result happened
Test a full 3-step task: open WhatsApp → find contact → send a message

If you're building something similar or just curious about offline AI agents, follow along. This is Day 3 of the build.

Day 2 of building an AI agent that controls a phone. Repo is live. First script is working. Gemma 4 + ADB + Python. No cloud. No API keys. Just a phone that understands commands and executes them. github.com/Dexter2344/phone-agent

Okeke Chukwudubem — Tue, 09 Jun 2026 14:57:23 +0000

Okeke Chukwudubem

Jun 9

Project Log #2: The AI Phone Agent Has a Repo

#ai #android #automation #gemma

1 min read

Project Log #2: The AI Phone Agent Has a Repo

Okeke Chukwudubem — Tue, 09 Jun 2026 14:56:00 +0000

Yesterday I announced I'm building an autonomous AI agent that controls a phone. Today, it has a home on GitHub.

The Repo

github.com/Dexter2344/phone-wgent

Right now it's a single Python script. But that script already does three things:

Talks to Gemma 4 via Ollama's local API. No cloud.
Executes ADB commands — opens apps, taps, types text.
Parses natural language commands into structured steps.

Today's Progress

Task	Status
Created the repo	✅ Done
Wrote the core `agent.py` script	✅ Done
Added README with full project overview	✅ Done
Tested Ollama connection	✅ Working
Tested ADB connection	✅ Working
Parsed a test command into JSON steps	🔧 In progress

What the Script Does Right Now

You give it a command like "Open WhatsApp." It sends that to Gemma 4, which breaks it into a step-by-step plan. Then the script executes those steps via ADB.

It's basic. It's fragile. But the foundation is there.

What's Next (Day 3)

Add screen text detection using Tesseract OCR
Write the verification layer that checks if each step succeeded
Test a full 3-step task: open app → find element → tap

Why This Matters

Most AI agents live in the cloud. This one lives on a phone. No internet. No API keys. No data leaving the device.

I'm documenting every step publicly. If you're curious about building AI agents, building from a phone, or just watching someone figure it out in real time—follow along.

Project Log #1: I'm Building an AI Agent That Controls a Phone

Okeke Chukwudubem — Sun, 07 Jun 2026 21:22:19 +0000

I'm starting a new project. It's the most ambitious thing I've attempted from a phone.

The goal: an AI agent that controls a smartphone. It opens apps, navigates screens, taps buttons, types text, and completes multi-step tasks. All offline. All local. No cloud.

This is Day 1 of a public build log. No fluff. Just what I'm building, how it works, and what breaks along the way.

What I'm Building

An autonomous AI agent that runs entirely on an Android phone. You give it a command in plain English:

· "Open WhatsApp and message Mom I'll call later."
· "Search for Kotlin jobs on Wellfound."
· "Open my notes and summarize what I wrote yesterday."

The agent parses the command, plans the steps, and executes them—opening apps, finding the right buttons, typing text, hitting send. No cloud. No API keys. Just a phone that acts on your behalf.

The Stack

Component Tool
AI Brain Gemma 4 E4B (local, via Ollama)
Runtime Termux (Linux on Android)
Phone Control ADB + UI Automator
Orchestration Python

Why This Matters

Most AI agents live in the cloud. They need internet, APIs, and someone else's server. A local agent that runs on a phone means:

· Privacy: your data never leaves your device.
· Offline: works even without internet.
· Accessible: built for the device billions of people already own.

The Hard Parts I Already See

· The agent needs to "see" the screen to know where to tap. Text detection is doable. Image-based buttons are harder.
· Multi-step tasks need verification. If one tap misses, the whole chain fails.
· Android permissions. ADB requires developer mode. A user-facing version would need a workaround.

What's Next

· Day 2: Create the repo. Set up the project structure. Push the first working script.
· Day 3: Get screen text detection working with OCR.
· Day 4: Test a full 3-step task.

This is Day 1. The repo goes live tomorrow. Follow along if you want to see something rare get built from scratch.

My Gemma 4 Phone Setup Is Now on GitHub

Okeke Chukwudubem — Sat, 06 Jun 2026 16:48:10 +0000

A while back, I wrote a guide on running Gemma 4 locally on an Android phone using Termux and Ollama. It got some traction. People asked for the code.

There wasn't much code to share—just a setup script and documentation. But I realized that's still worth putting in one place.

So I did.

What's in the Repo

github.com/Dexter2344/gemma4-phone-setup

· A README explaining the whole project and linking back to the original guide
· A setup.sh script that automates the install process in Termux
· Clear instructions so anyone can replicate what I built

Why This Matters to Me

When I wrote the original post, I was just documenting what I learned. I didn't think of it as a "project." But putting it on GitHub changes how I see my own work. It's not just a tutorial anymore. It's a reference. Something someone can clone, run, and build on.

What Else I've Been Building

I also shipped a RAG pipeline that runs entirely on a phone—native API calls, persistent memory, upgraded to Gemma 4 E4B. That one has real Python code, a proper README, and setup instructions:

github.com/Dexter2344/rag-pipeline-phone

My Phone AI Pipeline Was a Prototype. Now It's a Real Project.

Okeke Chukwudubem — Thu, 04 Jun 2026 18:45:18 +0000

Three upgrades, one repo, and a promise kept.

A few weeks ago, I wrote about building a RAG pipeline on my phone. It worked. Barely.

I used subprocess calls to talk to Ollama. Every time I restarted Termux, the bot forgot everything we'd discussed. And I was running the smallest Gemma 4 variant because I was scared the bigger one would crash my device.

I promised I'd rebuild it. Today, that rebuild is live.

What Changed

Three things I said I'd fix and actually fixed:

Native API Instead of Subprocess

My original code shelled out to Ollama using Python's subprocess module. It worked, but it was janky. The new version uses Ollama's native REST API via requests.post(). Cleaner code. Fewer moving parts. Proper error handling. The model now returns structured JSON instead of raw text I had to parse.

Persistent Memory Across Sessions

This was the big one. My old pipeline had amnesia. Restart Termux, lose everything.

Now there's a chat_memory.json file that stores a rolling summary of past conversations. The pipeline injects that memory into every prompt, so the model remembers what we talked about even across restarts. If you type memory in the interactive mode, it shows your conversation history.

It's not a vector database for memory. It's a lightweight JSON log. But it works on a phone without eating RAM. That's the engineering tradeoff.

Upgraded to Gemma 4 E4B

I was running E2B (2.3B params) because I assumed my phone couldn't handle more. I was wrong. The E4B (4.5B params) fits comfortably with quantization. The reasoning quality jump is noticeable especially on multi-step questions where the old model would lose the thread.

The Repo

Everything is on GitHub now:

github.com/Dexter2344

The README explains how to set it up, what dependencies you need, and how to run it. If you've got Termux on Android, you can clone it and have your own offline AI running in under 30 minutes.

What's Still Hard

Let me be honest about what I haven't solved:

· The phone still heats up after 20+ minutes of continuous inference. Thermal throttling is real.
· Android will kill the Ollama process if you switch apps for too long. I haven't found a workaround yet.
· The embedding model is still my lightweight hashing approach, not a real transformer. That's next on the list.

Why This Matters

Every time I publish one of these, someone reaches out and says "I didn't know you could do that from a phone." That's the whole point. You don't need a $2,000 laptop or cloud credits to build real AI systems. You need curiosity, patience, and a willingness to break things.

The code is free. The repo is public. Go build something.

I Took a Break. Here's What I Learned About Burnout as a Student Developer.

Okeke Chukwudubem — Wed, 03 Jun 2026 11:27:49 +0000

I disappeared for three weeks.

No posts. No commits. No "learning in public" tweets. Just silence.

If you've been following my journey, you know I've been grinding hard—building AI pipelines on a phone, writing due diligence reports, trading forex, hunting for internships, and carrying 7 courses at UNIZIK. I was shipping every week. Until I wasn't.

This post isn't a tutorial. It's what I learned from hitting a wall and actually stepping back.

The Warning Signs I Ignored

I didn't wake up one day and decide to stop. It crept in. First, I stopped replying to messages as fast. Then I started doom scrolling instead of coding. Then a whole week went by and I hadn't opened Termux or written a single line.

I told myself I was just tired. I'd bounce back tomorrow. Tomorrow turned into three weeks.

Looking back, the signs were there:

· I'd open my code editor and feel nothing. No excitement. No curiosity. Just blank.
· I was working on 7 different things—Substack, Dev.to, forex, cold outreach, internship apps, school, AI projects—and none of them were getting my full attention.
· I started comparing myself to every other developer I saw online. A guy in my department earns $2,700/month from a US company. Instead of motivating me, it made me feel behind.

What the Break Actually Taught Me

The guilt was the worst part. Every day I didn't post, I felt like I was losing momentum. Like I was letting myself down. Like three weeks of silence would undo months of work.

But here's what I realized: the work was still there when I came back.

My Substack posts were still live. My Dev.to articles were still getting reads. The Gemma 4 challenge entry was still competing. My portfolio didn't vanish because I took a break. It waited for me.

What I'm Doing Differently Now

I'm not coming back to the same grind. I'm coming back with rules:

One platform per day. Not all three. Monday is Substack. Wednesday is Dev.to. Friday is X. The others get rest.
No more 7-way multitasking. I pick two priorities max per week. This week: Substack comeback post + one Wellfound application. That's it.
Rest is part of the schedule, not a punishment. I used to feel guilty for watching a movie or playing a game. Now I know those moments are what keep the engine from exploding.
Comparison is a compass, not a weapon. That guy earning $2,700? He's proof the path exists. He's not proof that I'm failing. There's a difference.

What I'm Building Next

I'm revisiting my local AI pipeline—the RAG system I built on my phone using Gemma 4. Google dropped an update while I was gone, and the new model variants fix some of the exact pain points I hit in my original build. Smaller footprint. Better context handling. Apache 2.0 license.

I'll be documenting the rebuild. Not as a perfect tutorial. As a real, messy, "let me figure this out" series.

If You're in the Dip Right Now

You're not lazy. You're not falling behind. You're just human, and humans need rest.

The code will still be there. The portfolio will still be there. The opportunities will still be there. Take the break before the break takes you.

See you in the next post. 🚀

Revisiting My Phone AI After Gemma 4: The Upgrade I Didn't Know I Needed

Okeke Chukwudubem — Sun, 24 May 2026 23:02:27 +0000

Two weeks ago, I built a RAG pipeline on my phone. Termux. Gemma 4 E2B. A Python script that took my lecture notes and turned them into a private AI tutor I could interrogate offline. It worked. It was slow. It was fragile. But it worked.

Then Google dropped an entire family update, and I realized I'd been running the equivalent of a beta test.

After digging through the architecture docs and benchmarks that have come out since the release, I revisited my original build to answer one question: if I were starting fresh today, what would I actually do differently?

What's New Under the Hood

The Gemma 4 family now has four variants, and the architecture decisions baked into them directly address the pain points I hit in my original build .

The E2B model I used runs on something called Per-Layer Embeddings (PLE). Instead of one massive lookup table sitting at the start of the model eating up RAM, PLE distributes compressed mini-lookups across every decoder layer . The result is a 2.3B effective parameter model that fits in under 1.5GB of RAM with aggressive quantization . On a phone with 4GB RAM, that's the difference between a model that runs and one that crashes mid-inference.

The context window on my E2B was 128K tokens. That was enough for one textbook chapter, but not a full semester. The new 26B MoE and 31B Dense variants push to 256K—enough to drop an entire codebase or all seven of my course materials into a single prompt . And they achieved this without the quality cliff that plagued earlier long-context attempts, scoring 66.4% on the RULER benchmark compared to Gemma 3's 13.5% .

But the single biggest change? The license. Gemma 4 is now Apache 2.0 . No usage restrictions. No commercial ambiguity. I can build a product on this and sell it without a lawyer on retainer. That's not a technical detail—that's a business unlock.

What I'd Build Differently Today

My original RAG pipeline was a single Python script with hardcoded file paths and no persistent memory. Every time I restarted Termux, it forgot everything. If I were rebuilding today, here's what I'd change:

I'd use Ollama's native API instead of spawning subprocesses.

My original build shelled out to Ollama via Python's subprocess module. It worked, but it was janky. The proper approach—documented in the Haystack cookbook—is to use OllamaChatGenerator directly with think=False for RAG queries, which disables extended reasoning to keep answers fast . Cleaner code. Fewer moving parts.

I'd add persistent memory across sessions.

One of the best technical breakdowns I found is a guide to adding genuine cross-session memory to a local AI setup using LM Studio and a plugin called Big RAG . The concept is simple: maintain a chat_memory.json file that stores summaries of past interactions, and inject them into the prompt alongside retrieved document chunks. The implementation involves modifying a promptPreprocessor.ts file to pull recent conversation history and past session summaries before assembling the final prompt . If I were rebuilding my phone pipeline, I'd port this concept to Python—a simple JSON file that remembers what I've asked across sessions. The code wouldn't be trivial, but the principle is sound.

I'd target the E4B model instead of E2B.

The E4B has 4.5B effective parameters and fits in 4-6GB of RAM . On a phone with 8GB RAM, that leaves room for the OS and background apps while delivering meaningfully better reasoning than the E2B I used. The hardware decision tree from the Dev.to comparison piece is clear: if you're on mobile, go E2B. If you're on a laptop CPU, go E4B . For my use case—a dedicated Android device running Termux—the E4B is the sweet spot.

What's Still Hard

Let me be honest about what hasn't changed. Running any model locally on a phone generates heat. After 20 minutes of continuous inference, my device throttles. Android's memory management is aggressive—if you switch away from Termux for too long, the OS kills the Ollama process. And the setup isn't plug-and-play. You're compiling packages, configuring webhooks, debugging Python scripts in a terminal on a 6-inch screen.

That friction is real. But so is the payoff: a private AI that runs offline, costs nothing per query, and doesn't send your data anywhere.

The Bigger Picture

Gemma 4's Apache 2.0 license signals something important: Google is serious about local-first, commercially-viable open models . They're not just releasing a research artifact. They're releasing infrastructure for builders who can't afford cloud API bills.

For anyone building in Nigeria, India, Brazil—anywhere the internet is unreliable or expensive this matters. The tools are getting smaller, faster, and legally safer to build on.

I'm rebuilding my pipeline this week. E4B. Persistent memory. Native API calls. I'll report back with what breaks.

Two weeks ago, I built a private AI brain on my phone using Gemma 4. Yesterday, Google dropped a new variant that made everything I built feel like a beta test. 256M parameters. MoE architecture. Apache 2.0 license. I broke down what changed and why it mat

Okeke Chukwudubem — Sun, 24 May 2026 22:52:36 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

Okeke Chukwudubem

May 24

Google Just Made Gemma 4 Feel Like a Beta Test. Here's the Real Upgrade.

#gemmachallenge #google #rag #nigeria

3 min read

Google Just Made Gemma 4 Feel Like a Beta Test. Here's the Real Upgrade.

Okeke Chukwudubem — Sun, 24 May 2026 22:49:44 +0000

Two weeks ago, I wrote about building a private AI brain on my phone using Gemma 4. It was wild—a full RAG pipeline running locally via Termux and Ollama, serving context-aware answers from my lecture notes. No cloud. No API keys. Just a phone and a stubborn refusal to accept that AI development requires a data center.

Then Google dropped an update that made everything I built feel like version 0.1.

They didn't release a new model. They released a correction. And it's the most developer-friendly move they've made in months.

What Actually Dropped

Google just released Gemma 4 256M, a new variant in the Gemma 4 family. At 256 million parameters, it's even smaller than the Slim variant I covered in my last post. It's designed for edge devices, phones, Raspberry Pi boards—the hardware developers in constrained environments actually have access to.

But the real story isn't the size. It's the architecture decisions baked into this release.

First, it uses a Mixture-of-Experts (MoE) design, where only a fraction of the model's total parameters are active at any given time. This means it delivers reasoning quality that punches far above its weight class while keeping memory usage and latency low. For a phone with 4GB of RAM, this is the difference between a model that runs and a model that crashes.

Second, the context window is 32K tokens. That's enough to drop in a full semester's lecture notes, a complete contract, or an entire codebase. On a 256M model. Running locally. On a phone.

Third—and this is the part that matters most to developers like me—they released it under Apache 2.0. No custom license. No "research only" restrictions. You can build. You can modify. You can commercialize. You can deploy. This is the license developers have been begging for.

Why This Matters More Than Benchmarks

The AI industry is obsessed with benchmarks. Can the model score 90% on some math dataset? Can it beat GPT on a reasoning test? That's noise for people building in the real world.

What matters is: can it run on the hardware I actually have? Can I deploy it without paying per token? Can I build a business on it without a lawyer reviewing the license?

Gemma 4 256M answers all three questions with a yes. And that's rarer than a high benchmark score.

What I'm Building Next

With this new variant, I'm revisiting my RAG pipeline. The smaller model footprint means I can load more documents into memory simultaneously. The 32K context means longer source materials get processed in fewer chunks. The Apache license means I can think about commercial applications without anxiety.

I'm prototyping a version of my study assistant that can hold an entire semester's course materials in context at once—not just one PDF at a time, but all seven courses I'm taking this semester. Offline. On a phone. With zero cloud costs.

That's the promise of local AI. Not beating benchmarks. Building things that work where the cloud doesn't reach.

The Bigger Picture

Google's move signals something important. The market for AI isn't just cloud APIs sold to enterprises. It's also edge devices, offline environments, and developers in places where internet is unreliable or expensive. The Apache 2.0 license tells you they're serious about the second market.

For anyone building in Nigeria, India, Brazil, Southeast Asia—anywhere the cloud has never been a reliable partner—this matters. The tools are getting smaller, faster, and legally safer to build on.

The walled gardens of proprietary AI are growing taller. But the open-source, local-first garden just got a new tree. And it's bearing fruit.
I

Pointers in C: The Concept That Almost Broke Me (And How I Finally Got It)

Okeke Chukwudubem — Thu, 14 May 2026 23:16:51 +0000

Some concepts in programming slide into your brain smoothly. You read the definition, look at an example, and think, "Okay, I get it."

Pointers are not that concept.

For weeks, pointers felt like a wall I couldn't climb. Every explanation sounded the same: "A pointer stores a memory address." Cool. But why? When? What problem does this actually solve?

This post is for anyone staring at int *ptr and wondering if they're just not cut out for this. You are. The problem isn't you. The problem is that most explanations skip the "why" and jump straight to the syntax.

The Real Question: Why Do Pointers Exist?

Imagine you're a chef. You have a recipe book (your program) and a kitchen full of ingredients (your computer's memory).

Without pointers, every time a function needs an ingredient, you photocopy the entire recipe and hand over a duplicate of everything. Need to modify one onion? Here's a copy of the whole kitchen. This is slow, wasteful, and the original onion stays untouched.

With pointers, you don't hand over a copy. You hand over a note with the exact shelf and position where the onion lives. The function goes straight to the source, works on the original onion, and leaves.

That's what pointers do. They pass addresses instead of copies.

The Syntax Demystified

Let's break down the three things that confused me the most.

int x = 10; — This is a normal variable. It holds a value.

int *ptr = &x; — This is a pointer. &x means "give me the address of x." *ptr means "ptr is a variable that stores an address." So ptr now holds the memory location where x lives.

*ptr = 20; — This is dereferencing. *ptr means "go to the address stored in ptr and access the value there." So this line changes x to 20 without ever typing x.

int x = 10;
int *ptr = &x;   // ptr holds the address of x
*ptr = 20;       // x is now 20
printf("%d", x); // prints 20

The Moment It Clicked

It didn't click from reading. It clicked when I wrote a tiny, useless program and watched it fail.

I tried to write a function that swaps two numbers. Without pointers, nothing happened. The values stayed the same. With pointers, the swap worked.

// This does NOT work
void swap(int a, int b) {
    int temp = a;
    a = b;
    b = temp;
}

// This works
void swap(int *a, int *b) {
    int temp = *a;
    *a = *b;
    *b = temp;
}

The first version copies the values. The second version goes to the addresses and changes the originals. That was the moment. Not elegant theory. A broken function that pointers fixed.

What I'd Tell My Past Self

Stop trying to memorize the syntax. Write a program that breaks. Use pointers to fix it. The understanding doesn't come from reading. It comes from watching your program fail and knowing exactly why pointers would have saved it.

You're not bad at this. Pointers are just one of those things that takes longer to click than the tutorials admit.