DEV Community: Fiewor John

How Gemma 4 Helped Us Cut the Last Wire Keeping AI Out of African Classrooms

Fiewor John — Mon, 11 May 2026 14:41:21 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

The Problem Started Long Before This Hackathon

In 2021, as a postgraduate student, I built something called AI-Grader. The idea was simple: teachers spend an unreasonable amount of their lives marking scripts. AI could change that. The first version used Microsoft Azure's Cognitive Services — OCR for handwriting, key phrase extraction to compare answers. It worked, but it was brittle. It compared keywords, not understanding. It could not tell you why it gave a grade.

Then ChatGPT dropped, and the gap between what I had built and what was now possible became impossible to ignore.

In early 2024, I teamed up with two people I had only just met, and together we rebuilt everything from scratch — this time with Google Gemini — during the Google BuildWithAI Hackathon organised by GDG Lagos. We placed third nationally, renamed the project GradrAI, and walked away with confirmation that this problem was real and that Gemini was the right foundation.

GradrAI's relationship with Google had officially begun.

What GradrAI Does

GradrAI is an AI-powered assessment platform for educators in Africa. Three core workflows:

Paper-Based Test (PBT) grading: Teachers upload scanned student scripts, a question paper, and a marking guide. Gemini reads the handwriting, evaluates each answer, and returns per-question scores, explanations, and personalised student feedback — in minutes, not days.

Computer-Based Test (CBT) generation and grading: Teachers upload lecture notes or past papers. The platform extracts topics, generates a structured quiz (MCQ, essay, or hybrid), produces a marking guide, and grades submissions automatically.

SmartPrep: A student-facing practice mode for JAMB UTME and WASSCE. Students work through real past exam questions and receive AI-generated explanations and feedback on every answer — not just whether they got it right, but why, and what to revisit.

The cloud version works well. Schools loved the demos. Then came the part nobody wants to hear at a demo: "We don't have reliable internet."

The Conversation That Started Everything

On the 20th of April, I shared a NetworkChuck video about offline AI models with my team. The idea of a fully offline GradrAI came up immediately, because we had real context for why it mattered.

Three schools we had demoed to had given us near-identical feedback: a private secondary school in Lagos said they lacked the infrastructure to adopt a cloud-dependent solution. A school in Ogun State said internet costs were not something they were prepared to cover for teachers. A third Lagos school said something similar.

These were not fringe cases. They were our target market telling us clearly that the cloud dependency was the barrier. Not the price. Not the product. The wire running from the classroom to the internet.

We started building the offline app that same day. Students could take exams offline and MCQs were graded instantly — but essay questions still sat in a queue, waiting for an internet connection to sync to the cloud. We had solved the last mile while leaving the first mile untouched.

Then, shortly before the DEV Community announced the Gemma 4 Challenge, FreeCodeCamp released a tutorial on open model coding essentials that specifically called out Gemma 4 as "very smart with low memory usage." When the hackathon dropped on May 6th, the stars had aligned. This feature needed to be finished.

Taking the Entire Pipeline Offline

The cloud CBT pipeline has four AI operations:

Topic extraction — read a PDF, identify key topics and weights
Exam generation — produce a structured quiz from those topics
Marking guide generation — produce the evaluation rubric for essays
Theory grading — evaluate student answers against the rubric

Operations 3 and 4 are text-in, text-out. Straightforward to move offline.

Operations 1 and 2 are the hard part. The cloud implementation passes Google Cloud Storage URIs directly to Vertex AI. Ollama cannot resolve a GCS URI. To run these locally, we rasterise PDF pages to images in memory, base64-encode them, and pass them as inline multimodal parts to Gemma 4.

// offlineProcessor.js — PDF pages to base64 image parts, entirely in memory
const { pdfToPng } = require("pdf-to-png-converter");

async function rasterisePdfToInlineParts(localFilePath) {
  const pages = await pdfToPng(localFilePath, {
    viewportScale: 1.5,
    outputFileMask: "page",
  });
  const capped = pages.slice(0, 20); // respect context window
  return capped.map((page) => ({
    type: "image",
    data: page.content.toString("base64"),
    mimeType: "image/png",
  }));
}

// gemma.provider.js — unified Ollama interface for all four operations
async function generateContent({ promptText, imageParts = [] }) {
  const message = {
    role: "user",
    content: promptText,
    ...(imageParts.length > 0 && {
      images: imageParts.map((p) => p.data),
    }),
  };
  const response = await axios.post(
    "http://127.0.0.1:11434/api/chat",
    { model: process.env.OFFLINE_MODEL || "gemma4", messages: [message], stream: false },
    { timeout: 1200000 } // 20 minutes — consumer hardware varies significantly
  );
  return response.data.message.content;
}

The provider abstraction means the service layer never needs to know whether it is talking to Gemini on Vertex AI or Gemma 4 on Ollama. One interface. Both providers.

Engineering for the Edge: What We Learned the Hard Way

Building for offline on consumer hardware revealed challenges that clean architecture diagrams do not warn you about.

Schema drift from smaller models. Gemma 4 occasionally returned exam questions in a split format — separate mcq and essay arrays — rather than the unified root array the application expects. We built a normalisation layer that detects output shape and remaps non-conformant field names before they reach the persistence layer. The service never crashes on a slightly malformed response; it corrects and continues.

Crash recovery for long inference. On a standard teacher's laptop, the full pipeline — topic extraction, exam generation, marking guide — takes between 5 and 15 minutes. A power cut or accidental app close at minute 7 is a catastrophic user experience. Every generation stage now writes to a local recovery cache. On relaunch, the app detects the backup and lets the teacher restore instantly without re-running inference.

Room collision in air-gapped networks. With multiple exams in a ready state, students were being routed to the oldest session by default — meaning valid access codes for the new exam were being rejected. We refined local session state to prioritise the most recently created session, which is almost always the one the teacher just generated.

Sequential grading on slow hardware. Grading ten essay questions locally is sequential. On slower machines this produced a silent hang in the UI that left students uncertain whether their submission had registered. We rebuilt the submission flow to include real-time status events pushed back to the student's device throughout the grading process.

Why Gemma 4 Specifically

Native multimodal input eliminates a pipeline dependency. Every other approach to offline PDF processing requires a separate OCR layer. Gemma 4's vision capability means one model handles document understanding, question generation, and essay grading. One model. One Ollama endpoint. The entire pipeline.

The 128K context window makes full syllabus context viable. For topic extraction, an entire semester's lecture notes fit in a single call. For grading, the marking guide, question paper, and student answer fit together without chunking. This is the difference between a model that skims a document and one that reads it.

The E4B model runs on the hardware that actually exists. Most schools in our target market do not have server-grade machines. The teacher's laptop is the server. Gemma 4 E4B runs on consumer-grade laptops and high-end Android phones — a mid-range Windows machine, the kind a teacher might already carry to class.

Structured output is reliable enough for production. Our grading pipeline requires strict schema adherence on every response. Gemma 4's instruction following is consistent enough at this task that our validation layer catches edge cases rather than routine failures.

What the Offline Flow Looks Like Now

A teacher with no internet can now:

Open the GradrAI desktop app. Ollama starts as a sidecar. Gemma 4 loads.
Upload a PDF — lecture notes, a past paper, a textbook chapter.
Gemma 4 extracts topics. The teacher adjusts weights and priorities in the UI.
Configure the exam: MCQ count, essay count, difficulty, total marks.
Gemma 4 generates the full question set and marking guide.
Publish the exam to the local network. Students connect via the teacher's hotspot.
MCQs graded instantly. Essays graded by Gemma 4 within seconds of submission.
Results stored locally, synced to cloud when connectivity returns.

No cloud token consumed. No data left the building. The student gets their feedback before the class ends.

Why This Matters

The shift toward Computer-Based Testing is accelerating across Africa. JAMB administers its UTME entirely via CBT to over 1.8 million candidates annually. Ghana's WAEC has been piloting CBT for WASSCE. Kenya's KNEC has published a national CBT roadmap.

The infrastructure reality has not kept pace. Nigeria's internet penetration sits below 45%. Electricity supply in many states is unreliable, compounding the problem — no power means no router means no exam. The tools being built for this transition cannot assume the connectivity that developed-market EdTech takes for granted.

GradrAI's offline-first architecture is not a feature for edge cases. It is the baseline requirement for the market we are actually building for. Gemma 4 is what made it technically feasible at the hardware level this market actually has.

What Comes Next

The next stage is extending Gemma 4 into SmartPrep — GradrAI's student-facing JAMB and WASSCE practice mode. The goal is an offline practice experience where Gemma 4 generates questions from curriculum content, grades responses, identifies knowledge gaps across a session, and produces a diagnostic summary entirely on-device.

A student preparing for JAMB in a rural school, with no data, no tutor, and no prep centre nearby, practising with an AI that tells them exactly what they got wrong and why. That is the version of this product we are building toward.

Links

GitHub Repository: (to be added)
Demo Video: (to be added)
GradrAI Platform: gradrai.com

What we built during this hackathon is not a demo. It is a production feature shipping to real schools. The students who take exams on GradrAI's desktop app this term will get their theory grades back before they leave the classroom — because Gemma 4 is running on the teacher's laptop while they wait.

My Updated Dev Portfolio

Fiewor John — Mon, 02 Feb 2026 06:53:54 +0000

New Year, New You Portfolio Challenge Submission

Portfolio

About Me

I am a software engineer who builds full-stack web applications with an emphasis on pragmatic, maintainable code and strong developer experience. For this portfolio refresh, I aimed to present a concise, modern summary of my skills and projects while improving performance, accessibility, and responsiveness so the site better represents my current capabilities.

How I Built It

Overview & Goals

Modernize an old Create React App portfolio I last updated four years ago.
Improve developer experience (faster dev server, smaller builds).
Improve end-user experience (dark mode, responsive layout, clearer project highlights).

Tools & Tech Stack

Frontend: React migrated from CRA → Vite (for faster dev feedback and smaller build times).
Build / Bundler: Vite (ESM-first, fast HMR).
Hosting / Deployment: Google Cloud Run (containerized, serverless deployment).
Containerization: Docker with multi-stage builds, small production image, gzip compression, SPA routing.
Google AI: Antigravity — AI-first development environment to refactor, suggest improvements, and accelerate repetitive tasks.
Development practices: prompt engineering best practices, incremental commits, dependency hygiene, CI/CD practices.

Key Development Steps

CRA → Vite Migration
- Replaced CRA-specific scripts and configs with Vite-compatible equivalents.
- Updated imports and adjusted environment variable usage to match Vite conventions.
Dependency Updates
- Upgraded major frontend dependencies to current stable releases (React 18 for compatibility).
- Resolved peer dependency conflicts between React, React DOM, and testing libraries.
- Removed deprecated or unmaintained packages.
Dark Mode
- System-preference-aware theme with manual toggle persisted in localStorage.
- CSS variables for theme tokens for maintainability and compact implementation.
Responsive & Accessibility Improvements
- Adjusted layout breakpoints and touch targets for mobile devices.
- Improved semantic HTML and ARIA attributes where appropriate.
Containerization & Cloud Run Deployment
- Multi-stage Docker build:
  - Node build stage for dependency installation and Vite production build.
  - Nginx runtime stage with gzip compression and SPA routing.
- Ensured cross-platform compatibility by building amd64/linux image for Cloud Run.
- Pushed Docker image to Artifact Registry and deployed to Cloud Run.
- Embedded the live Cloud Run deployment in this post.

How I Used Antigravity

Performed targeted refactors (e.g., simplifying a large portfolio component).
Generated guided migration snippets for CRA → Vite.
Used iterative prompt → change → test cycles to keep changes minimal and reversible.

What I'm Most Proud Of

Successful migration from CRA → Vite with faster builds and improved developer feedback loop.
Dark mode implementation that respects system preference with a simple toggle.
Dependency hygiene and modernized build process.
Cloud Run deployment with a multi-stage Docker build and gzip, making the portfolio lightweight, fast, and embeddable.
AI-augmented development workflow significantly reduced time spent on repetitive refactors.

What to Look for in the Demo

Project cards linking to code samples and short implementation notes.
Clear, scannable “About / Skills / Contact” section.
Theme toggle and responsive behavior — try resizing the viewport or switching system dark/light mode.
Accessible semantic structure and keyboard navigability for main sections.

Thank you for reviewing my submission — I look forward to feedback from the Google AI team and the community.

Using GitHub Actions to Battle Racism (or at least contribute to the process)!

Fiewor John — Sun, 21 Nov 2021 13:38:30 +0000

Introduction

GitHub Actions are event-driven workflows which are very useful for automating processes in software development lifecycle. They're even more awesome because they're located where all the fun stuff happens - GitHub! This takes resolving of issues, collaboration and deployment to a whole other level and makes it even easier too.

To learn more about GitHub actions and how you can begin to utilise them, check their easy-to-follow documentation

My Workflow

During Hacktoberfest, I created two greeting bots and one stale bot for IBM's Call for Code for Racial Justice Open Source projects.
Basically, the greeting bots greet new contributors to the project with a message.

name: Greetings

on: [pull_request, issues]

jobs:
  greeting:
    runs-on: ubuntu-latest
    steps:
       ...
       issue-message: 'Thank you so much for contributing to our work!'
       pr-message: 'Thank you for your contribution! Someone will review it ASAP.'

The stale bot marks issues stale after a particular number of days. You might be wondering why this would be useful. Well, it helps notify contributors of issues that have been unattended to for too long and hence prioritize such issues.

name: Mark stale issues and pull requests

on: 
  schedule:
    - cron: "0 0 * * *"

jobs:
  stale:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/stale@v1
        ....
          stale-issue-message: ':wave: Hi! This issue has been marked stale due to inactivity. If no further activity occurs within the next 7 days, it will automatically be closed.'
          ...
          stale-issue-label: 'stale'
          exempt-issue-label: 'keep-open'
          remove-stale-when-updated: true
          stale-issue-label: 'Stale'
          stale-pr-label: 'Stale'
          labels-to-add-when-unstale: 'help-wanted'
          days-before-stale: 60
          days-before-close: 7

These GitHub Action Bots are being used in two Call For Code for Racial Justice Projects

Truth Loop - a solution that helps communities simply understand the policies, regulations and legislation that will impact them the most and allows them to share their experiences around how policies have impacted them or how proposed policies could impact them using short video testimonials.
TakeTwo-Marker-ChromeExtension which is 'a plugin to facilitate the capture and categorization of words and phrases that could be racially biased through a browser.'

Submission Category:
Maintainer Must-Haves - since it makes the lives of open source maintainers easier.

Link to Code

Stale Bot
https://github.com/Call-for-Code-for-Racial-Justice/Truth-Loop/pull/211/files

Greeting Bot
TakeTwo-Marker-ChromeExtension
https://github.com/Call-for-Code-for-Racial-Justice/TakeTwo-Marker-ChromeExtension/pull/29/files

Truth Loop
https://github.com/Call-for-Code-for-Racial-Justice/Truth-Loop/pull/195/files

Additional Resources / Info

Here's the article by Call for Code in which I was featured:
https://medium.com/callforcode/hacktoberfest-fighting-racism-with-open-source-code-956559da7d6d
I was also a speaker in the Demo Day (somewhere between 8:00 and 13:00)
https://www.youtube.com/watch?v=7VWlc5JiZ7Q
Most importantly, join the call, there's a lot more awesome stuff to be done!
https://developer.ibm.com/callforcode/racial-justice/