Teaching AI at the Qubators AI Foundry — Notes from One of the Facilitators

Earlier this year I received an invitation that I want to mark on this site — to serve as one of several facilitators teaching the inaugural cohort of the Qubators AI Foundry.

This piece is my personal reflection on the experience. It isn’t a programme summary — the organisers have their own materials for that — and it isn’t a claim that I taught the entire cohort. I was one of several facilitators, and the credit for the programme’s design, recruitment, and outcomes belongs to the Qubators team. What I’m writing about here is what I contributed in my sessions, what I observed in the developers I had the privilege to teach, and what I’m taking back into my own work as a result.

What the Qubators AI Foundry is

Qubators describes itself as a global network of Christian developers building Kingdom technology. It is part of the broader Rhapsody of Realities work. The AI Foundry is the network’s flagship AI training programme, designed to take African developers through a month of hands-on training in building with AI — covering the foundations through to applied frontiers.

The inaugural cohort was significant in scale:

• 500+ developers trained across Africa
• 40+ live applications launched by the end of the programme — covering income generation, data-driven workflows, agenda-driven tooling, and the promotion of the Espees platform
• A graduation event that doubled as a product showcase, with speakers from multiple continents and live demos of cohort projects

The organisers flew speakers in, ran live demos, and turned what could have been another online course into something closer to a startup accelerator’s demo day — for builders, by builders, with a clear sense of mission.

What I taught in my sessions

My sessions focused on the part of AI work that’s least covered in YouTube tutorials and most consequential in production: how to actually ship an AI feature that survives contact with real users.

Four themes I kept coming back to:

1. Eval-first thinking

Most AI projects die in the gap between “the demo worked” and “production users hate it.” The pattern that closes the gap is to define what good looks like before you write a prompt. Pick fifty or a hundred real example inputs. Write down, by hand, what a correct output looks like for each. Score outputs against your benchmark every time you change a prompt or swap a model. That practice — boring as it sounds — separates the AI features that ship from the ones that get quietly killed in pilot.

2. Grounded answers, not hallucinated ones

The pattern that works in production is retrieval-augmented generation (RAG) over a known corpus, with citations. The model doesn’t try to know things; it retrieves chunks of trusted content and answers from them. If the answer isn’t in the corpus, the system says so. Every claim links back to a source the user can verify.

This is the architecture behind the AI-powered legislative search we built for the Rivers State House of Assembly. It’s the architecture behind the AI-powered accounting assistant inside Every27. It’s the architecture I’d reach for nine times out of ten in a Nigerian production AI build today.

3. Cost discipline

A production AI feature is just code that calls a paid API. Treat the API like a database — budget it, monitor it, alert on it. Prompt caching, model tiering (cheap for simple, expensive only when necessary), per-user budgets, output token limits, streaming so you can cut off run-away generations. Without these guardrails, a feature that costs $0.05 per request will somehow average $5 in production once real users get hold of it.

4. The boring infrastructure

Logging every API call. Replaying broken sessions. Alerting on cost spikes. Recording inputs and outputs for offline evaluation. Versioning prompts. These are the unsexy disciplines that turn a demo into a product. I spent a meaningful amount of session time on them because, in the projects I’ve shipped, they’re what make the difference between “we launched” and “we’re still running six months later.”

What I learned from the developers I taught

Three things stood out from the cohort I had direct contact with:

They’re more technically prepared than the global narrative suggests. The popular framing of African AI as “behind” simply doesn’t match what I saw in the room. Solid Python, strong fundamentals, a willingness to wrestle with the messy parts of LLM behaviour. The gaps were in tooling exposure, not in capacity to learn.

They build for problems global SaaS doesn’t touch. The 40+ applications that came out of the cohort weren’t recreations of US-coast tools. They were African-rooted — payments, faith-based community tools, language-specific workflows. That’s a signal about where the next decade of African software will come from.

They care about doing this well, not just doing it. I expected to spend time arguing the case for evals, observability, and cost discipline. I spent very little. The audience already understood the difference between a demo and a product. They wanted the recipes.

What I’m taking back into my own work

I came back from the Foundry with a sharper view of three things:

1. The bar for “AI feature” is rising fast. What was a competitive AI capability in 2024 is now table stakes. If you’re shipping AI in 2026, ground it, evaluate it, and price it — or don’t ship it.
2. Teaching makes you a better builder. Explaining patterns out loud to a room of strong developers forces a clarity you don’t get from writing them down for yourself. Every section of my own systems that I taught, I now have a sharper version of in my head.
3. The next wave of African AI talent is real. Some of the people in that cohort will be the founders, CTOs, and AI engineers running serious infrastructure in three to five years. The work the Qubators team has done in assembling and training them is meaningful, and I’m grateful to have been part of one corner of it.

A note on framing

I want to be careful with the framing of this piece. The Qubators AI Foundry was a Qubators programme, designed and run by Qubators, with multiple facilitators, sponsors and a much larger team than me. I was one contributor among several. The 500+ figure and the 40+ applications are the cohort’s collective achievement, not mine personally. My contribution was specific: I taught a set of sessions on production AI patterns and helped the developers I worked with translate prompts and demos into shippable features.

If you want the full picture of the Foundry — its mission, its broader programmes, the rest of the speaker line-up — visit qubators.org. If you want to know what I personally took from being in that room as a facilitator, this piece is it.

If you’re building production AI in Africa and want to talk through scoping, evaluation, or architecture, book a 30-minute call. I respond personally.