If your evaluation environment is cleaner than your deployment environment, your benchmark is measuring the wrong thing.
Build the test around reality.
The key insight:
A framework is valuable because it can capture learning and make that learning reusable, not merely because it standardizes work.
So the progression becomes:
Build → Observe → Learn → Adjust
↓
Turn the loop into a framework
↓
Deploy the framework repeatedly
↓
Capture outcomes and deviations
↓
Extract useful learning
↓
Improve the framework
↓
Repeat.
That creates compounding advantages:
Consistency —> people/systems have a repeatable way of approaching work.
Dependability —> fewer outcomes depend entirely on individual memory or intuition.
Efficiency —> successful approaches don't have to be rediscovered every time.
Quality —> failures and lessons feed back into the process.
Scalability —> the method can be transferred to more people, teams or systems.
Institutional learning —> experience doesn't disappear when the individual who gained it moves on.
A framework shouldn't freeze the way you work. It should create a mechanism for continuously improving the way you work, otherwise you just create bureaucracy.
The really interesting version is a self learning framework. One that produces a process, measures the process, captures what happened, and uses that information to improve the next iteration.
Building on my post about speed vs. velocity: the next step is turning workflows into frameworks.
Frameworks are reusable structures for turning objectives, inputs, decisions, actions and feedback into a repeatable process that improves over time.
A good framework shouldn't just tell you how to do something, it should help you get better at doing it.
Take: Build → Observe → Learn → Adjust
If you turn that into a reusable framework and deploy it repeatedly, the benefits start compounding.
Work becomes more consistent.
Processes become more dependable.
Good practices become reusable.
Failures become information.
Improvements become part of the system.
The real advantage comes when the framework itself can learn. You don't just repeat the process, you improve the process that produces the work. At that point, the framework starts becoming infrastructure.
Another thing I've learnt from building: speed and velocity are not the same thing. You can move very fast in the wrong direction.
Good systems create feedback early enough to tell you when you're wrong before you've invested too much time, money, or complexity.
That is why I increasingly value applying first principles, small experiments, short feedback loops and simple first versions.
Build → observe → learn → adjust.
It may seem slower at first but it compounds over time. The advantage is in learning faster than the cost of being wrong, not just moving fast.
Exactly, they force you to innovate and think outside the box, as conventional approaches won't cut it. Over time, those skill becomes part of how you build, and like I said, the things you build eventually start carrying those principles with them. Adaptability becomes part of your strength.
Constraints slow things down.
But I’m starting to think the right constraints do the opposite.
A limited budget forces prioritization.
A small team forces better systems.
A difficult market exposes bad assumptions.
Limited infrastructure forces you to understand what is actually essential.
The goal evolves from simply trying to build despite constraints, to using them as principles for building something that works without perfect conditions.
Adapting to constraints becomes part of the system we use to build products.
And eventually, the products inherit that mindset.
The wrong question being asked about AI in Nigeria:
“Which jobs will AI take?”
The more useful question is:
“What new economic capacity can AI give one person?”
A small business owner who can serve 10× more customers.
A farmer who can access expertise without hiring a specialist.
A developer who can build with a much smaller team.
A young person who can sell services globally from Nigeria.
It brings the opportunity to explore, to learn new and efficient ways to work, solve problems and operate businesses.
AI can automate tasks. But it can also lower the cost of starting, operating and scaling a business. It is not simply about preserving today's jobs. It is about using AI to help Nigerians create more work, more businesses and more value.
The problem shifts from 'how to create', to 'what to create'. It solely rests on individuals to think and generate ideas in an environment where lots of problems are there waiting to be solved, creativity and delivery becomes the value.
That is the opportunity.
The Cerebellum – Runtime – Brain split makes a lot of sense. The interesting problem to me is the information bottleneck between them though. How does Gander decide which observations from a continuous multimodal stream become durable task state versus transient context for the Brain?
AI gets interesting when you stop asking, “How smart is the model?”
and start asking:
“What can the system reliably accomplish?”
A model that can reason brilliantly but can't access the right context, use tools, recover from failure, or verify its own work isn't an autonomous system.
It's just a very capable component.
The real engineering challenge is building everything around the intelligence, giving it arms to work and legs to walk. That is when the system stops being a gimmick, and starts being useful.
Most AI demos optimize for the moment of success.
Real systems have to survive the moment things go wrong.
Bad input.
Missing data.
A failed API call.
An ambiguous request.
A user doing something the designer didn't anticipate.
The engineering around AI systems is an area I am highly interested in, not just the intelligence of the model.
Reliability is a product feature, an important one.
AI adoption in Africa shouldn't be measured by how many people can access ChatGPT, Claude and all the other LLMs.
A better question is:
Can we adapt AI to the environments where people actually live and work?
AI agents are often described as smarter chatbots.
I think that misses the bigger opportunity.
The interesting shift is from AI that answers questions to AI that operates inside systems:
→ understands context
→ accesses the right information
→ takes actions
→ follows workflows
→ knows when to escalate
→ leaves an auditable trail
The hard part isn't making an agent talk.
It's making one reliably useful, It's making it work in the real world, in the actual places it is needed the most.
Africa's AI opportunity isn't just about building bigger models.
It's about building the missing layers around them.
The World Bank's 2026 AI readiness work highlights four foundations: connectivity, compute, context, and competency.
The interesting part is "context."
Local languages. Local data. Local workflows. Local constraints.
If AI is going to be genuinely useful here, those aren't edge cases.
They're engineering requirements.
The most interesting AI products won’t always look like chatbots.
Some will quietly become infrastructure: connecting people to information, systems to actions, and organizations to the context they need to operate.
That’s the direction I’m most interested in building toward.
Building AI in Nigeria?
The winning approach here is edge-native. Models small enough to run on a mid-range phone, quantised to INT4, trained on task-specific data that actually exists locally.
So you build edge-first. Small models, 1B to 3B parameters, trained on exactly what the user needs and nothing else. A model that diagnoses cassava leaf disease does not need to know about Renaissance poetry. A model that handles Hausa customer support does not need to reason about quantum physics.
A model fine-tuned on Nigerian financial fraud patterns can run inside a bank's local network without ever touching the internet. That is the point. Local data, local compute, no round trip to a server you do not control.
It runs on a phone, or on a cheap local server. No cloud bill. No network round trip. No praying the grid stays up so your API call does not time out.
Same for healthcare diagnostics, agricultural extension, offline education tools. The model only needs to know this thing. And it needs to run when the fibre is down.
You cannot hide bloat behind a bigger cluster. Every layer has to earn its place. That is not a limitation. That is a filter.
We hit the same filter building Hausa speech synthesis. West African languages are a condition the industry routed around. There is no massive pretraining corpus to fall back on. You build smaller and more specific. You do not pretend the constraint is temporary. The discipline is the same whether the constraint is hardware or data.
The products that survive that filter work everywhere. In Abuja, in rural Kebbi, in Maiduguri, anywhere someone has a phone and a problem to solve.
The standard playbook for training LLMs assumes three things: steady power, cheap bandwidth, and cloud compute you can spin up with a card.
In Nigeria, you might have zero of those on the same day.
So you build different. You checkpoint every 30 minutes because the grid doesn't care about your epoch. You quantize aggressively because moving 70B parameters over this connection is a joke. You favor LoRA and small fine-tunes over full pretraining because the petrol budget is real, your local hardware won't cut it, and the naira exchange rate is a daily variable.
People call this "resource-constrained AI."
But honestly... It produces a different engineering intuition. You feel the cost of every parameter. You design for interruption. You optimize like your hardware is finite, because it actually is.
The models aren't worse. They're just built by people who can't afford to waste a FLOP.
Meet Gemma 4 12B!
A unified, encoder-free multimodal model designed to bring high-performance intelligence directly to your laptop, and released under an Apache 2.0 license.
Bridging the gap between edge efficiency and advanced reasoning. Here is what’s new with Gemma 4 12B: 👇