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

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:

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.

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.