DEV Community: Mfoome aka Banjika Ngo

Before you open Kiro: why fundamentals decide who gets value from AI

Mfoome aka Banjika Ngo — Wed, 04 Nov 2026 11:13:50 +0000

On a Friday evening in July, I stood in front of a room of developers at AmaliTech Rwanda in Kigali and asked a simple question.

Who here has shipped code an AI wrote, without being sure why it worked?

Hands went up. Then I asked who had to explain it in a standup, or fix it at 11pm when it broke. Most of the hands stayed up.

That was the room I wanted to talk to. The event was the AI Builder Workshop, with the theme "Build for Business", organised by AmaliTech together with AWS User Group Kigali. After my keynote, participants spent four hours designing and demoing real solutions with AI tools, including Amazon Kiro.

As AmaliTech put it in their recap: "Learning happens fastest when builders are in the room together, not just watching from the sidelines."

I was honoured to open that session. This article is what I said, and why I believe it.

The thesis: AI amplifies what you already have

Here is the idea I asked the room to hold onto:

AI can only make you better if you already have something to build on. It doesn't replace the absence of skill. It amplifies the skill that's already there.

I teach cloud for a living at WirfonCloud Academy, and our whole approach is Foundation First: Linux, networking and Python before cloud and AI. People sometimes hear that as "go slow". I mean the opposite. Foundations are what let you move fast safely, because they let you tell good output from bad at the speed AI now produces it.

I walked through three layers to show what I mean.

Layer 1: Linux permissions and processes

An AI assistant hits a permission error. Its favourite fix is "run it as root" or "chmod 777". That works. The red text disappears.

It also means every user on that machine can now read, write and execute that file. Think of a landlord who hands out master keys to strangers because one tenant complained about a stuck lock.

Same layer, second example. You ask an assistant to "clean up the memory issue" and it suggests killing a busy process. Do you know what that process is, and what depends on it staying alive? If not, you're taking medical advice from someone who has never seen the X-ray.

If you understand owner, group and other, and what a process actually is, you catch both suggestions in half a second. If you don't, you run the command.

The AI isn't wrong to offer the fast path. It's your job to know when the fast path is the wrong one.

Layer 2: write the Bash script by hand once

Write your deploy script by hand one time. Not because you'll never automate it, but because afterwards you know what correct looks like. It should confirm the build succeeded before pushing. It shouldn't keep a secret in plain text on line four. And an rm -rf next to a variable that could be empty is how production directories disappear.

A bug in generated code is a weevil in a sack of grain. The sack still looks full from outside. The damage is happening inside, and you only find it if you know where to look.

Correct-looking and correct are not the same thing. At four seconds per script, you will see a lot of correct-looking code.

Layer 3: networking, and what spec-driven development really asks of you

Open a security group by hand once. Put 0.0.0.0/0 in the source field for port 22 and understand what you just did: you opened SSH to the whole internet, not to your team.

This is where Kiro comes in, and where I think the tool's design supports my argument. Kiro is built around spec-driven development. In plain terms, a structured, detailed specification becomes the source of truth before any code is written. You describe what you want, and Kiro produces requirements with acceptance criteria, then a technical design, then a task list. You review each stage before it moves on.

Notice who does the hard part. You define three things:

System constraints: what must always be true. "This endpoint is only reachable from inside our VPC."
Business rules: the decisions the system makes. "Flag anything above the threshold for manual review."
Acceptance criteria: how you'll know it works. "Reject any request without a valid token."

Every one of those needs real knowledge of the system underneath. You can't write a sound network constraint if you don't understand a subnet. You can't spot a missing criterion in a design document if you don't know what "valid" means at the infrastructure level.

So Kiro doesn't remove judgement from the loop. It moves judgement to the front, before any code exists. If you can't bring it, you're doing autocomplete with a document attached: the same risk, with more confidence.

The same logic applies to automation hooks. You trust one to act on its own after you've watched the manual version run correctly enough times. Any DevOps engineer already knows this from CI/CD.

Why this matters for Africa's builders

AmaliTech's training model is practical and project-based: real work, hands-on, before you're trusted to move fast alone. That is the same instinct. Practise the fundamentals under real conditions, then let the tools carry the speed.

I'm grateful to AmaliTech and AWS User Group Kigali for creating that room, and for the kind words in their recap. Strong foundations were the point of my keynote, and I'm glad they landed.

What to take away
AI raises the ceiling, but only for people who already have a floor to stand on.
Do the task by hand once. Then automate it.
In spec-driven development, the quality of your constraints, rules and criteria decides the quality of what you get back.
Read the design document like you wrote it yourself.

If you're newer to the layers underneath, Linux, networking and Python are exactly where we start at WirfonCloud Academy.

Banjika Ngo is an AWS Instructor Aluminus, founder of WirfonCloud Academy, and an 6X AWS Community Builder currently based now in Kigali, Rwanda.

Building a Linux Study Companion with AWS PartyRock and Bedrock

Mfoome aka Banjika Ngo — Fri, 01 Aug 2025 15:02:18 +0000

An AI-powered tool to make Linux learning easier, built by a cloud educator using Amazon’s latest GenAI platform
**
**Why Linux Still Matters
In today’s tech world, Linux is everywhere — powering cloud infrastructure, servers, containers, and even IoT devices. Yet for beginners, getting comfortable with Linux remains a real hurdle. Commands, permissions, shells, filesystems — it’s a lot to absorb.

As a Linux instructor at WirfonCloud, I’ve spent years helping students take their first steps into Linux. And I’ve always wished there were better tools — ones that could meet students where they are and help them learn interactively.

That’s why I built a solution. And I built it using AWS PartyRock, powered by Amazon Bedrock.

Introducing the Linux Essentials Exam Study App
This app is based on the latest official LPI Linux Essentials (010–160) Study Guide, and it was initially created for students in my Fundamentals of Linux course at WirfonCloud. But the results were so positive, I decided to open it to the public.

Now anyone — students, self-learners, instructors — can use it to prepare for the LPI Linux Essentials certification or simply improve their understanding of Linux.

What the App Can Do
This is more than a flashcard app. It’s an interactive, AI-driven learning assistant designed for clarity and confidence-building.

Features include:
Study Assistant
Ask anything about Linux and get context-aware answers — all based on the official LPI study guide, without needing to upload the PDF.

Practice Questions
Generate multiple-choice and short-answer questions based on specific topics or sections of the guide.

Topic-Based Navigation
Select key areas like file permissions, the command line, or Linux processes, and get instant help or quizzes.

Built with AWS PartyRock + Amazon Bedrock
So, how did I build this app?

I used PartyRock, a no-code GenAI app builder that sits on top of Amazon Bedrock, AWS’s fully managed service for working with foundation models from providers like Anthropic, Meta, Mistral, and more.

With no servers to deploy and no front-end code to write, I could focus on designing a learning experience — not configuring infrastructure.

PartyRock allowed me to:

Rapidly prototype and test ideas

Build an AI tutor in hours, not weeks

Seamlessly connect input prompts, model outputs, and UI components

And because it runs on Bedrock, I had access to powerful models under the hood — all without leaving the AWS ecosystem.

Try It for Yourself
You can explore the app here: Click here to Access App

See it in action on the uploaded screenshot after I asked the Study Assistant “how can I use the mkdir command?”

Use it to:

Study for the LPI Linux Essentials (010–160) exam

Build foundational Linux skills

Practice key topics anytime, from any device

Ask Linux-related questions and get real-time explanations

It’s free, beginner-friendly, and entirely AI-powered.

Why This Matters for Educators and Builders
As both an instructor and an AWS Community Builder, I believe this is a glimpse of what the future of education looks like.

With tools like PartyRock and Bedrock, educators can now:

Turn PDFs into interactive learning assistants

Build smart practice tools tailored to real curriculum

Scale their impact beyond the classroom

And builders can showcase real-world GenAI apps that deliver immediate, meaningful value.

Final Thoughts
Linux is the foundation of so much in modern tech — but learning it doesn’t have to feel like trial by terminal.

With the right tools, we can make Linux approachable, accessible, and even enjoyable for beginners. And with generative AI platforms like AWS PartyRock, we now have the means to build those tools faster than ever.

If you’re learning Linux, teaching it, or just curious about what’s possible with GenAI, give the app a try — and let me know what you think.