DEV Community: Okello Odhiambo

AI Can Write the Code. I Still Need to Understand the System.

Okello Odhiambo — Fri, 18 Sep 2026 08:00:00 +0000

This is the final part of a three-part reflection on what I am learning about software engineering at Zone01 Kisumu.

The first part was about moving beyond "the code works."

The second was about architecture and understanding what our technical decisions become as systems grow.

This final part is about the thing sitting beside almost every developer conversation today:

AI.

I use AI.

I find it useful.

And precisely because it is useful, I think developers need to become much clearer about what our actual job is.

There is little value in pretending AI cannot code

It can.

Sometimes very well.

Ask for a function that sorts a collection.

Done.

Ask for an API endpoint.

Done.

Ask for a React component.

Done.

Ask for SQL migrations, tests, Docker files, validation logic or a Python script.

Often, done.

It can also explain unfamiliar code, find mistakes, propose refactors and help investigate errors.

Pretending otherwise doesn't prepare me for the industry I am entering.

But neither does handing every problem to AI and assuming that receiving code means the problem has been solved.

Those are two extremes.

My experience at Zone01 Kisumu is pushing me towards something between them:

Use the tools. Understand the work.

A generated solution still creates responsibility

Imagine I am building an application that collects personal information.

Users upload profile pictures and identification documents.

The application also accepts payments.

I ask AI to implement file uploads.

It does.

I ask it to integrate payments.

It does.

I ask for authentication.

It does.

Now I have several thousand lines of code and a functioning application.

But I still need answers.

Where are the ID documents stored?

Are they publicly accessible?

Can User A request User B's document?

Are uploaded files validated on the server?

Where are payment credentials stored?

Does the application trust payment status coming from the browser?

How are payment callbacks verified?

Are passwords hashed correctly?

Can a user change their role by modifying an API request?

What information is written into logs?

What happens when the payment provider is unavailable?

What happens when the same webhook arrives twice?

AI's ability to generate the implementation doesn't transfer responsibility for those answers.

The system is still ours.

This is changing how I define a good developer

If you asked me earlier in my learning journey what makes someone a strong developer, I probably would have talked mainly about programming ability.

How quickly can they solve a problem?

How many languages do they know?

Can they build the feature?

Those things still matter.

But my list is getting longer.

Can they understand a problem before implementing it?

Can they read unfamiliar code?

Can they explain why something was designed a particular way?

Can they recognize when an abstraction is unnecessary?

Can they identify security assumptions?

Can they debug a system rather than just a function?

Can they communicate trade-offs?

Can they review someone else's solution fairly?

Can they change their mind when another approach is better?

Can they determine when AI-generated code is wrong even when it looks convincing?

Those skills are harder to demonstrate with a single code snippet.

They are also becoming difficult for me to ignore.

Peer-to-peer learning feels strangely appropriate for the AI era

There is something interesting about learning software engineering through a peer-to-peer model at this particular moment.

When knowledge is immediately available through search engines, documentation and AI, the challenge isn't always obtaining an answer.

The challenge is understanding it.

When a peer reviews my project, saying:

"AI gave me this code."

doesn't answer:

"Why does this work?"

And it certainly doesn't answer:

"Why did you choose this approach?"

That pressure to explain is valuable.

Teaching another person exposes gaps in my own understanding.

Reviewing another person's implementation exposes me to decisions I wouldn't have made.

Defending my own decisions forces me to separate preference from reasoning.

Sometimes a peer's five-minute question teaches me more than another hour of adding code.

Learning multiple languages has reinforced this

At Zone01 Kisumu, working across Go, Python and JavaScript has also helped separate programming from software engineering in my mind.

The languages approach problems differently.

Go can make me think carefully about explicit error handling and package boundaries.

Python can let me explore an idea with remarkably little ceremony.

JavaScript puts me close to asynchronous behaviour, browser interactions and the realities of client-server applications.

But after spending enough time with them, something becomes obvious.

The languages change.

The important questions survive.

How should this data be represented?

Who owns this state?

Where should this responsibility live?

What happens when this operation fails?

How do I test this?

What does this component need to know?

How does this system communicate with another system?

What should I trust?

What should I never trust?

Those aren't Go questions.

They aren't Python questions.

They aren't JavaScript questions.

They are engineering questions.

AI has made syntax cheaper

I think this is one of the biggest changes we are experiencing.

Syntax used to represent a significant portion of the friction between an idea and working software.

AI is reducing that friction.

That is good.

But when one resource becomes cheaper, other resources become more important.

Judgment becomes more important.

Context becomes more important.

Problem definition becomes more important.

Architecture becomes more important.

Verification becomes more important.

Security becomes more important.

Communication becomes more important.

Understanding becomes more important.

If AI gives me 500 lines of code in thirty seconds, I haven't necessarily saved time if I spend the next two days discovering that the underlying design was wrong.

Generating code quickly and building the right system are different optimizations.

Prompting isn't a replacement for understanding

There is a tendency to frame prompting itself as the new programming.

I think that misses something.

A precise prompt can absolutely improve the output.

But where does the precision come from?

Suppose I tell an AI:

Build a secure REST API.

Compare that with:

The endpoint requires authentication. A user can access only resources they own. Validate the request server-side, reject unknown fields, enforce a 5 MB upload limit, allow only specific MIME types, avoid exposing storage paths, rate-limit requests and return consistent errors without leaking internal details.

The second prompt is better.

But the improvement didn't come from learning magical words for talking to AI.

It came from understanding the engineering problem.

The quality of what I ask AI to build is constrained by what I know to ask about.

And the quality of what I accept is constrained by what I know how to verify.

That makes fundamentals more useful to me, not less.

Sometimes the best use of AI is disagreement

One habit I am trying to develop is not treating AI as the final authority.

Instead of only asking:

"Build this."

I can ask:

"What can fail in this design?"

"Give me three alternatives."

"What assumptions am I making?"

"Attack this architecture."

"What security issues should I test?"

"Explain why this abstraction is necessary."

"What would you remove?"

Then I still have to evaluate the answers.

That feels much closer to engineering than simply accepting generated code.

AI becomes a collaborator in the thinking process rather than a machine that finishes the thinking for me.

The debugger still needs a human question

Something I keep encountering while learning is that debugging rarely begins with knowing the answer.

It begins with forming the right question.

Is the frontend sending the wrong data?

Is the API rejecting it?

Did authentication fail?

Did the database operation execute?

Is the state stale?

Is this a race condition?

Is my assumption about the input wrong?

AI can help investigate each possibility.

But someone needs a mental model of the system strong enough to know where to look.

Without that model, debugging becomes repeatedly pasting errors into a chat window and hoping the next suggestion works.

Sometimes it does.

Sometimes it creates the next error.

Understanding lets me tell the difference.

Software engineering is also communication

This may be the least glamorous part.

Software is built by people.

Requirements come from people.

Users are people.

Designers, engineers, testers, managers and clients all see different parts of the problem.

Being able to explain:

Here's the problem.

Here are our constraints.

Here are the options.

Here's what this option gives us.

Here's what it costs us.

Here's what could go wrong.

is an engineering skill.

Our peer-to-peer environment keeps reinforcing this because learning doesn't happen entirely in isolation.

Sometimes I am receiving help.

Sometimes I am providing it.

Sometimes we are both staring at the same bug wondering what we've missed.

That process develops something a code generator cannot simply hand me: experience.

I don't know exactly what software engineering will look like in five years

I don't think anybody does.

AI capability will continue changing.

The tools we use today will change.

Some tasks that currently take hours will probably become nearly instantaneous.

Some roles will change with them.

So I don't want to build my identity around being the person who can type code faster than a machine.

That competition doesn't interest me.

I want to become the engineer who understands what needs to be built.

Who can inspect what was generated.

Who can recognize when something that works shouldn't be deployed.

Who understands the data moving through the system.

Who can reason about failure.

Who can collaborate with other engineers.

Who can explain technical decisions.

Who can learn an unfamiliar technology when the problem requires it.

And, importantly, who knows when they don't understand something yet.

My biggest lesson so far

My journey at Zone01 Kisumu is still ongoing.

I am still learning Go.

Still working through Python.

Still improving my JavaScript.

Still debugging things that seemed obvious five minutes earlier.

Still making decisions I later realize could have been better.

But perhaps that is exactly the point.

I came into this journey wanting to become better at writing code.

I still do.

What has changed is my understanding of what sits around the code.

Architecture.

Data.

Security.

Testing.

Trade-offs.

Communication.

Failure.

Users.

Other developers.

And now AI.

The code matters.

But the decisions behind it matter longer.

AI can help me write the function.

My responsibility is understanding what happens when that function becomes part of a real system used by real people.

That is the kind of software engineer I am learning to become.

Part 3 of 3 — Learning Software Engineering in the Age of AI

The Code Worked. Then I Started Asking What Happens Next.

Okello Odhiambo — Thu, 17 Sep 2026 08:00:00 +0000

The Code Worked. Then I Started Asking What Happens Next.

In the first part of this series, I wrote about a change taking place in how I approach software development at Zone01 Kisumu.

I am becoming less satisfied with knowing that code works.

I want to understand what happens around the code.

That has pushed me towards architecture.

For a long time, "software architecture" sounded like something that happened much later in a developer's career.

I imagined enormous system diagrams, microservices, Kubernetes clusters and people with "Architect" in their job titles deciding where everything should go.

My experience with projects is giving me a much more practical definition.

Architecture is what your decisions become when the project grows.

Every small decision leaves a footprint

Imagine I need user information.

The fastest solution might be to fetch it directly inside whatever component currently needs it.

Then another component needs it.

Then another.

Soon, three parts of the application fetch the same information differently.

One handles errors.

One doesn't.

One caches the result.

One expects a slightly different response.

None of those individual decisions seemed architectural when they were made.

Together, they have created an architecture.

This has been an important realization for me.

We don't avoid architecture by refusing to think about it.

We simply end up with architecture we didn't deliberately choose.

Start with the problem, not the technology

One temptation I have noticed in software development is beginning with technology.

"I'll use React."

"I'll use PostgreSQL."

"I'll use microservices."

"I'll add Redis."

"I'll containerize everything."

But those statements don't explain the problem.

The better questions come first.

What am I building?

Who will use it?

What information does it handle?

How frequently will that information change?

Which operations are critical?

What happens if a service becomes unavailable?

Does this actually need real-time communication?

What security boundaries exist?

What is the simplest design capable of meeting those requirements?

Only then do technology choices become meaningful.

If the problem requires structured relationships and transactions, that tells me something about storage.

If users are uploading large files, that tells me something different.

If a process can take several minutes, perhaps it shouldn't hold an HTTP request open.

Architecture starts with constraints.

Technology responds to them.

Following the data has helped me understand systems

One technique I increasingly find useful is tracing a piece of data from beginning to end.

Take something ordinary:

A user changes their profile picture.

It looks like one feature.

But follow the data.

User selects image
        ↓
Browser
        ↓
HTTP request
        ↓
Authentication
        ↓
File validation
        ↓
Storage
        ↓
Database reference
        ↓
API response
        ↓
Updated interface

Now the questions become clearer.

What file types are accepted?

What is the maximum size?

Do we trust the extension?

Where is the actual image stored?

Is it public or private?

What happens to the previous image?

Who can retrieve it?

What happens if storage succeeds but updating the database fails?

What happens if the user loses their connection?

The diagram isn't the architecture.

The decisions behind every arrow are.

Payments make the lesson even clearer

Suppose the application accepts online payments.

From the user's perspective:

Click Pay → Confirm → Success

From the system's perspective:

Client
   ↓
Application API
   ↓
Payment provider
   ↓
External payment network
   ↓
Payment confirmation
   ↓
Webhook
   ↓
Verification
   ↓
Database
   ↓
Order / Subscription

Now architecture directly affects money.

What is the source of truth for whether somebody paid?

The browser?

Definitely not.

The payment provider?

How do we verify its callback?

What if the callback arrives twice?

What if payment succeeds but our server is temporarily unavailable?

What if the amount received differs from the amount expected?

What if two requests try to update the same transaction?

These aren't syntax questions.

I could ask AI to generate a payment endpoint and receive one almost immediately.

The difficult part is deciding whether I should trust what it generated.

AI makes architecture more important, not less

AI has reduced the friction involved in creating software.

That is powerful.

It also means we can create bad architecture faster.

I can ask for:

Add Redis caching.

And get Redis.

But should this system have Redis?

I can say:

Convert this application to microservices.

And receive a directory containing several services.

But what problem did microservices solve?

I can request:

Make this scalable.

And receive queues, containers, caching layers and abstractions.

But complexity isn't scalability.

Sometimes the better architecture is:

Frontend
    ↓
Backend
    ↓
PostgreSQL

And that's it.

A system doesn't become professional because its diagram contains more boxes.

Every additional component creates something else to deploy, secure, observe, update, debug and pay for.

One lesson I am carrying with me is:

Complexity should have to justify its existence.

Separation of concerns finally started making practical sense

"Separation of concerns" is one of those phrases developers encounter repeatedly.

It made much more sense once I started seeing what happens when we ignore it.

Suppose an HTTP handler:

validates input,
checks permissions,
calculates prices,
queries the database,
sends emails,
uploads files,
formats responses.

Technically, it can work.

But now changing one business rule means touching the same code responsible for several unrelated things.

Testing becomes difficult.

Reusing logic becomes difficult.

Understanding failure becomes difficult.

The better question becomes:

What should this part of the system know?

A route should know about HTTP.

Business logic should know about business rules.

A repository should know how data is persisted.

A payment integration should know how to communicate with the payment provider.

That separation isn't about making the folder structure look impressive.

It creates boundaries around change.

Go has made boundaries visible to me

Go has been useful here because packages force me to think about what belongs together.

If everything imports everything else, something is probably wrong.

If changing one package causes unrelated parts of the application to break, the boundaries probably need reconsideration.

If a function requires ten dependencies just to do one thing, maybe it is doing more than one thing.

Python and JavaScript present the same architectural questions in different forms.

That is one benefit of learning several languages.

The syntax changes.

The underlying engineering problems keep returning.

Data still needs boundaries.

Errors still need handling.

Dependencies still need management.

Users still do unexpected things.

Networks still fail.

Databases still need consistency.

Security still matters.

Architecture is also about failure

Something else has changed in my thinking.

I used to design mainly around the successful path.

User submits form
→ Server processes it
→ Database saves it
→ Success

Now I try to spend more time on the arrows.

What happens if validation fails?

What happens if the database is unavailable?

What if the request is repeated?

What if only half of an operation succeeds?

What if an external API times out?

What if the user refreshes the page?

What if somebody deliberately sends malformed data?

The happy path shows that a feature can work.

The failure paths tell me whether I have engineered it.

Maintainability means thinking about another human

Architecture is often discussed in terms of machines:

performance, memory, throughput, latency.

But maintainability is largely about people.

Could another developer understand this?

Could someone safely change it?

Does the naming reveal intent?

Are the dependencies obvious?

Can we test one part without starting the entire application?

Can somebody joining the project understand how data moves through it?

Peer-to-peer learning at Zone01 makes that very tangible.

Code isn't only something I communicate to a computer.

It is something I communicate to the next developer.

Sometimes that developer is me three weeks later wondering why I made a particular decision.

Good architecture doesn't predict the future

I no longer think architecture means anticipating every possible requirement.

That can lead directly to overengineering.

Instead, I am beginning to think about it as making today's decisions without unnecessarily trapping tomorrow's developer.

Build what the project needs.

Create clear boundaries.

Keep responsibilities understandable.

Protect important data.

Test critical behaviour.

Document decisions that aren't obvious.

And leave room for the system to change.

The objective isn't to build a system that never needs modification.

Software that matters will change.

The objective is to make change survivable.

That raises the final question in this series.

If AI can increasingly generate our components, endpoints, tests and even entire applications, where should developers invest their effort?

For me, the answer is becoming clearer.

Our value moves further upstream—from producing code to understanding problems, evaluating trade-offs and taking responsibility for the systems we put into the world.

That is where I want to finish this series.

Part 2 of 3 — Learning Software Engineering in the Age of AI

I Came to Learn How to Code. I’m Learning How to Think Like an Engineer.

Okello Odhiambo — Wed, 16 Sep 2026 12:23:22 +0000

When I started my learning journey at Zone01 Kisumu, a large part of my attention was naturally on code.

How do I write this function?

Why is this test failing?

Why does this JavaScript behave differently from what I expected?

How should I structure this Go package?

Why is my Python solution producing the right output locally but failing the actual tests?

Those questions still matter. But somewhere between debugging projects, reviewing other people's work, having my own work questioned by peers, and moving between Go, Python and JavaScript, I started noticing something.

Writing code is only one part of software engineering.

And in 2026, with AI capable of generating surprisingly good code in seconds, that distinction matters more than it probably ever has.

The question changed

Early in my journey, completing a project often felt like reaching the point where:

It works.

Now I find myself asking a different set of questions:

Why does it work?

What happens when it fails?

What happens when two users do this simultaneously?

Where does this data go?

Who should be allowed to access it?

How difficult will this be to change six months from now?

What happens when another developer inherits this code?

What assumptions did I make without noticing?

That change has probably been one of the most important parts of my experience at Zone01 Kisumu.

We don't learn entirely through the familiar classroom arrangement where someone explains everything first and we reproduce it afterwards.

A significant part of the experience is peer-to-peer.

You build.

You get stuck.

You investigate.

You ask someone.

Someone asks you.

You defend a decision.

You discover that your explanation doesn't make as much sense aloud as it did in your head.

You review somebody else's implementation and occasionally discover a better solution to a problem you thought you already understood.

There is something uncomfortable but useful about that process.

A compiler can tell me that my program is invalid.

A test can tell me that my implementation produces the wrong result.

A peer can ask:

Why did you build it this way?

That question reaches somewhere tests often don't.

Go taught me to appreciate what isn't there

Working with Go has been particularly interesting for me because the language doesn't seem interested in helping me hide complexity behind clever syntax.

It keeps bringing me back to explicit decisions.

What does this function need?

What should it return?

Where should this error be handled?

What belongs in this package?

What shouldn't this package know about?

You can still write terrible Go. A language cannot save an engineer from poor decisions.

But working with it has made me think more deliberately about boundaries.

Consider something as ordinary as registering a user.

At first glance:

func RegisterUser(user User) error {
    return db.Create(user)
}

Problem solved?

Not really.

Where is validation?

What happens if the email already exists?

Where is the password hashed?

Should the database layer even receive a plaintext password?

What should the caller receive if insertion fails?

What should be logged?

Which errors are safe to expose to the client?

Suddenly a tiny function becomes a conversation about the system surrounding it.

That is architecture beginning to appear.

Not as boxes on a beautiful diagram, but as decisions.

Python showed me another side of the same problem

Python feels different.

It lets me express an idea quickly, which is extremely useful when exploring a problem.

But that freedom creates another responsibility.

Something being easy to write doesn't automatically make it well designed.

A Python program can become difficult to reason about surprisingly quickly when responsibilities begin leaking into each other.

Database operations appear inside route handlers.

Validation gets repeated everywhere.

Configuration becomes hardcoded.

Business rules end up scattered across unrelated functions.

Then the application grows.

Suddenly changing one thing breaks three others.

The lesson I have been taking from this is not that one language produces better architecture than another.

It is that architecture begins before the framework.

The language gives us tools.

We decide what relationships those tools create.

JavaScript made the boundaries impossible to ignore

JavaScript has given me a different perspective because it has taken me closer to the browser, user interaction, asynchronous behaviour and the frontend/backend boundary.

A button click can look ridiculously simple.

await fetch("/api/profile", {
  method: "POST",
  body: JSON.stringify(data)
});

But what happens after that request leaves the browser?

Can the client be trusted?

No.

Who validates the data?

What happens when the network disappears halfway through?

What happens if the request is sent twice?

Can one user manipulate the request and update another user's profile?

What if the server returns an error the interface wasn't expecting?

The code responsible for making the request might be five lines.

The engineering problem is much larger.

Then AI entered the room

This is where my learning journey has become particularly interesting.

I am learning software development at a time when AI can produce code at a speed I cannot compete with.

Give an AI system a sufficiently clear prompt and it can generate:

REST endpoints
React components
SQL queries
authentication middleware
unit tests
Docker configurations
data models
documentation

Sometimes within seconds.

Initially, I think it is easy for a learner to see that and wonder:

What exactly am I training for?

But the more projects I work on, the less worried I become about competing with AI on typing code.

Because typing code was never the whole job.

Suppose I tell an AI:

Build authentication for my application.

It can produce something that looks convincing.

But I still need to know enough to ask:

Why JWT?

Where is the token stored?

How does logout invalidate it?

What happens when it expires?

How are refresh tokens handled?

Can a normal user access an administrator endpoint?

Are passwords properly hashed?

Can the login endpoint be brute-forced?

What information leaks through error messages?

What happens if the signing secret is exposed?

AI can generate an implementation.

Someone still has to understand the consequences of that implementation.

Working code can still be dangerous code

This has changed the meaning of "working" for me.

Imagine building an application where users upload their identification documents.

The upload works.

The image appears.

The database saves the URL.

The feature is complete.

Except perhaps the generated URL is publicly accessible.

Perhaps changing:

/documents/184

to:

/documents/185

returns another person's document.

The application works.

The architecture doesn't.

Or imagine an online payment flow.

A payment screen appears.

The user completes payment.

The frontend receives:

{
  "paymentSuccessful": true
}

and activates the subscription.

Again, everything appears to work.

Until somebody discovers they can send that request themselves.

The ability to generate the code for these features is useful.

The ability to recognize why an apparently functioning implementation is unsafe is engineering.

Peer learning makes this harder to fake

One thing I appreciate about peer-to-peer learning is that understanding becomes visible very quickly.

You can copy syntax.

You can generate code.

You can memorize an explanation.

But when another developer starts asking why decisions were made, shallow understanding has nowhere to hide.

Why this data structure?

Why this endpoint?

Why is this function responsible for both things?

Why didn't you handle this error?

What happens with an empty input?

Why is this variable global?

What happens at scale?

Sometimes I have an answer.

Sometimes I don't.

The second situation is often where the real learning begins.

I don't think the future engineer writes less code

I think the future engineer spends more time understanding what the code means.

AI is changing the economics of producing software.

The cost of generating 100 lines of code is collapsing.

The cost of deploying the wrong 100 lines of code can still be enormous.

That changes what I want to become good at.

I still want to write good Go.

I still want to understand Python deeply.

I still want to become better at JavaScript.

But I also want to understand systems well enough to look beyond the file currently open in my editor.

Where does the data originate?

Where does it travel?

What trusts what?

What can fail?

What needs to scale?

What should remain separate?

What happens when requirements change?

Those are becoming increasingly important questions in my learning journey.

And they lead directly to another subject I once thought belonged mainly to senior engineers:

software architecture.

In the next part of this series, I want to write about how my understanding of architecture is changing—from thinking of it as complicated diagrams and technology choices to seeing it as something much simpler:

the collection of decisions that determine what happens when a project stops being small.

Part 1 of 3 — Learning Software Engineering in the Age of AI

VS Code Is Not Here to Replace You. It Is Here to Save You From the Boring Parts.

Okello Odhiambo — Tue, 21 Jul 2026 08:29:19 +0000

There is a joke that programmers spend only a small part of their day writing code. The rest is spent searching for a missing semicolon, wondering why yesterday's code suddenly stopped working, or asking the internet questions they are convinced someone else has already answered.

The joke is funny because it is painfully true.

Today, however, software development is changing. Artificial Intelligence (AI) has quietly moved from being something we only heard about in science fiction to becoming a practical assistant sitting inside one of the world's most popular programming tools: Visual Studio Code, better known as VS Code.

The important word here is assistant.

Contrary to what dramatic headlines often suggest, AI inside VS Code does not replace developers. It helps them work faster, make fewer mistakes and spend more time solving real problems instead of repeating routine tasks.

For anyone who has never written a line of code, imagine hiring an experienced carpenter who never gets tired of answering questions, finding the right tool or reminding you that you forgot to measure before cutting a piece of wood. The carpenter does not build the house for you. He simply helps you avoid expensive mistakes.

That is exactly what AI is becoming inside VS Code.

Understanding VS Code Without the Technical Jargon

Imagine writing a newspaper article.

You probably use Microsoft Word, Google Docs or another word processor. The software gives you a blank page where you type your story.

VS Code plays a similar role for software developers.

Instead of writing news articles, developers write computer instructions known as code. VS Code provides the workspace where those instructions are created, organised and edited.

According to Microsoft, Visual Studio Code is a free source-code editor that supports hundreds of programming languages and runs on Windows, macOS and Linux. Since its public release in 2015, it has become one of the world's most widely used development environments because of its speed, flexibility and large ecosystem of extensions.

Think of VS Code as an empty workshop.

On its own, the workshop contains the basic tools.

You can then add specialised equipment depending on the kind of work you want to do. These additions are called extensions. One extension checks spelling in code. Another helps connect to databases. Yet another introduces AI capabilities that can explain code, generate suggestions and answer programming questions.

The workshop remains the same.

Only the tools become smarter.

So Where Does AI Fit In?

Imagine you are preparing chapati for the first time.

You know the ingredients but are unsure about the measurements.

Standing beside you is an experienced cook who quietly says,

"Add a little more water."

"The dough is too soft."

"Reduce the heat."

"You forgot the salt."

That person is not cooking for you.

They are guiding you.

AI inside VS Code works in much the same way.

As you write code, AI studies the context and predicts what you are likely trying to achieve. It can recommend the next few lines, explain unfamiliar code, suggest corrections and even generate simple functions from plain-language instructions.

It is less like an autopilot and more like having a knowledgeable colleague who never complains when you ask the same question five times before lunch.

*Real-World Situations Where AI Actually Helps
*
Many people assume programmers spend their entire day creating brand-new software from scratch.

Reality is far less glamorous.

A surprising amount of software development involves fixing old code, understanding someone else's work and correcting tiny mistakes that somehow consume entire afternoons.

Consider these everyday examples.

A university student is building a final-year project but cannot remember the exact syntax for connecting to a database.

Instead of opening ten browser tabs, the student asks the AI assistant inside VS Code, receives an explanation and continues working.

A small business owner hires a freelance developer to create an inventory management system.

The developer uses AI to generate repetitive database operations, freeing more time to focus on making the software easier for employees to use.

A cybersecurity analyst notices unusual behaviour in a program.

Instead of reading thousands of lines manually, the analyst asks AI to explain sections of the code and identify possible vulnerabilities.

The final decisions still belong to the human expert.

The AI simply reduces the amount of repetitive work.

That distinction matters.

*AI Is Brilliant—Until It Is Wrong
*
Here is the uncomfortable truth.

AI can confidently produce incorrect answers.

Sometimes it invents information.

Sometimes it misunderstands instructions.

Sometimes it generates code that appears perfect but quietly introduces security risks.

If that sounds familiar, it should.

Think about GPS navigation.

Most of us trust Google Maps.

Yet almost everyone knows someone who has faithfully followed GPS directions into a dead end, a flooded road or the wrong destination altogether.

The problem was never the map.

The problem was assuming the map could never be wrong.

AI deserves the same healthy skepticism.

Its suggestions should be reviewed before being accepted.

Experienced developers often say the fastest way to create a software bug is to copy code without understanding it.

AI has not changed that rule.

It has simply made copying much faster.

*The Security Question Everyone Should Ask
*
There is another important consideration.

Many AI assistants operate through cloud services.

When a developer requests help, portions of their code may be processed on remote servers depending on the AI service being used and the organisation's privacy settings.

Now imagine walking into a doctor's office.

You would not casually hand confidential medical records to strangers sitting in the waiting room.

Company software deserves similar caution.

Businesses working with financial records, health information or confidential customer data should understand how their chosen AI tools handle information before uploading sensitive code or documents.

Several AI providers now offer enterprise privacy controls, but users should still read data-handling policies carefully rather than assuming every service treats information the same way.

Convenience should never come at the expense of confidentiality.

*AI Will Not Replace Curious People
*
One question appears almost every time AI is discussed.

"Will programmers lose their jobs?"

History suggests a more balanced answer.

Calculators did not eliminate accountants.

Spreadsheet software did not eliminate financial analysts.

Digital cameras did not eliminate photographers.

Instead, each tool changed how professionals worked.

AI is likely to follow the same pattern.

Developers who understand software, think critically and solve problems creatively will remain valuable.

Those who rely entirely on AI without understanding the underlying principles may struggle when the tool produces incorrect answers.

In other words, AI rewards understanding rather than replacing it.

*Learning to Work With AI Instead of Depending on It
*
For beginners, the best approach is surprisingly simple.

Use AI as a teacher rather than a shortcut.

Ask why a piece of code works.

Request explanations instead of only accepting generated answers.

Challenge its suggestions.

Experiment.

Make mistakes.

Correct them.

Learning this way builds confidence that remains useful even when AI is unavailable.

After all, if your calculator battery dies, knowing basic arithmetic suddenly becomes very valuable.

Programming is no different.

*The Future Is Collaboration
*
According to the 2024 Stack Overflow Developer Survey, AI tools have become a regular part of software development for many developers, particularly for writing code, learning new technologies and improving productivity. At the same time, many respondents also reported concerns about accuracy and trust, reinforcing the need for human oversight rather than blind reliance.

That finding captures the current reality perfectly.

AI inside VS Code is neither magic nor menace.

It is simply another tool.

A remarkably capable one, certainly, but still a tool.

The best developers of the future may not be those who type the fastest.

They may be those who know when to trust AI, when to question it and when to ignore it completely.

Technology has always rewarded people who combine curiosity with judgment.

AI changes neither of those qualities.

If anything, it makes them even more important.

Perhaps that is the real story behind AI in VS Code.

It is not teaching computers to think like humans.

It is quietly encouraging humans to think more carefully while letting machines handle the repetitive work none of us enjoyed in the first place.

From the Village Granary to the Digital Ledger: Understanding Blockchain and NFTs Without the Technical Headache

Okello Odhiambo — Tue, 21 Jul 2026 07:25:39 +0000

A child who has never travelled believes their father's homestead is the whole world.

Technology often makes many of us feel like that child. We hear new words, nod politely, and quietly hope someone will explain them in plain language. Few technologies have attracted as much excitement—and confusion—as blockchain and NFTs.

For years, these two terms have appeared alongside stories about cryptocurrencies, million-dollar digital art, scams, and overnight fortunes. Somewhere in that noise, many ordinary people concluded that blockchain was only for investors, programmers, or people chasing the next big thing online.

Yet that is far from the truth.

The real story of blockchain is not about speculation. It is about trust. It is about keeping records that people can verify without depending entirely on one individual or institution. NFTs, meanwhile, are not simply expensive digital pictures. At their heart, they are a way of proving ownership of something unique in the digital world.

Understanding both begins not with computers, but with something much closer to home.

Imagine your grandmother's granary.

Everyone in the village knows how many sacks of maize went in after harvest. Whenever a sack is removed, everyone who helps with the granary can see it. Nobody quietly sneaks in at night and changes last month's count because several people already know what was recorded. Trust comes from shared knowledge rather than blind faith.

That simple idea lies at the heart of blockchain.

Trust, Written One Page at a Time

Think of a notebook used by a merry-go-round (chama). Every contribution is written down. Every member has seen the entries. If someone tears out a page and replaces it with different numbers, the rest of the members immediately notice because their own records no longer match.

Blockchain works in much the same way.

Instead of one notebook locked inside an office, identical copies of the record exist across many computers. Each new page of transactions is connected to the previous page, forming a continuous chain. Once information has been agreed upon and added, changing it becomes extraordinarily difficult because every copy would need to be altered simultaneously.

Rather than relying on one trusted gatekeeper, the system relies on many participants verifying the same information.

As The Truth Machine, economists Michael J. Casey and Paul Vigna observe, blockchain represents "a machine for creating trust." That simple description captures its greatest strength. The technology does not eliminate trust altogether; instead, it changes how trust is established.

*Why This Matters Beyond Computers
*
Imagine buying a plot of land.

You receive the title deed and carefully lock it away. Years later, another person appears claiming ownership with a different document. The dispute drags on for months, perhaps years.

Now imagine if every legitimate transfer of ownership had been permanently recorded in a system where altering past records without everyone noticing was practically impossible.

That is one reason governments, researchers, and businesses continue exploring blockchain technology—not because it is fashionable, but because reliable records matter.

The World Economic Forum has repeatedly highlighted blockchain's potential in improving transparency across supply chains, healthcare, trade documentation, and public services.

The technology is not a magic wand, but it offers a different approach to keeping records honest.

A Kenyan Story Hidden Inside Your Morning Cup of Coffee

Picture a farmer in Nyeri harvesting coffee cherries.

The beans leave the farm and pass through processors, exporters, shipping companies, warehouses, and finally a café somewhere in London or Tokyo.

Along the journey, information can easily disappear.

Which farm produced these beans?

Were farmers paid fairly?

Was the coffee organically grown?

Blockchain allows every participant in that journey to add verified information as the product moves from one stage to another. Instead of relying on one company's records, everyone along the chain contributes to a shared history.

The result is greater traceability.

Several agricultural supply-chain projects around the world—including initiatives involving IBM Food Trust and similar traceability platforms—have demonstrated how distributed ledgers can help consumers understand where products originate and how they reached the shelf.

The same thinking could extend beyond coffee.

Imagine purchasing beef in Nairobi and scanning a QR code that tells you which county the animal came from, when it received veterinary treatment, where it was slaughtered, and how it reached your local supermarket.

For livestock-producing countries like Kenya, such transparency could strengthen consumer confidence and improve access to export markets that increasingly demand traceable food systems.

*So Where Do NFTs Come In?
*
Suppose your grandfather carved a beautiful wooden stool.

It is the only one he ever made.

Many people can photograph it.

Others can paint it.

Someone might even create an exact replica.

But only one original exists.

An NFT—or Non-Fungible Token—acts like a digital certificate proving ownership or authenticity of something unique.

The word non-fungible sounds intimidating, yet the idea is familiar.

A KSh 1,000 note is fungible because any other genuine KSh 1,000 note can replace it.

Your national identity card is not fungible.

Neither is your university degree.

Neither is your passport.

They belong specifically to you.

NFTs apply this same principle to digital assets.

Contrary to popular belief, the NFT is usually not the artwork itself. Instead, it is a digital record pointing to ownership or authenticity.

That distinction matters.

Owning an NFT of a photograph does not automatically stop others from viewing or copying the image online, just as owning the original Mona Lisa would not prevent people from printing posters of it. What changes is who possesses the recognised original.

Beyond Digital Art

The headlines often focused on colourful digital images selling for extraordinary sums.

That created the impression that NFTs were little more than expensive internet collectibles.

Their practical uses are far broader.

Imagine receiving your university certificate as an NFT.

An employer could instantly verify its authenticity without calling the institution.

Imagine concert tickets issued as NFTs.

Counterfeit tickets become far harder to produce.

Imagine hospital records where patients control access to their medical history instead of carrying paper files from one clinic to another.

Imagine land titles, professional licences, intellectual property rights, museum collections, or even livestock ownership represented through secure digital certificates.

Many of these ideas remain under development, but the underlying technology already exists.

*Not Every Problem Needs a Blockchain
*
Good technology should solve real problems rather than create new ones.

Blockchain is no exception.

Traditional databases are often faster, cheaper, and easier to manage.

If a small family business only needs to record daily sales, an ordinary spreadsheet may work perfectly well.

Blockchain becomes valuable where many independent parties need to trust shared records without placing complete confidence in one central authority.

It is a specialised tool—not a universal solution.

As the old Luo saying reminds us, "Piny owang' ni ng'ato ok nyal bedo gi rieko duto." The world has taught us that no one possesses all wisdom. Likewise, no single technology solves every challenge.

The Challenges We Should Not Ignore

Balanced conversations matter.

Blockchain systems can be expensive to build and maintain.

Some public blockchain networks have historically consumed significant amounts of electricity, although newer systems increasingly rely on energy-efficient methods such as Proof of Stake, reducing electricity use dramatically compared with earlier designs.

There are also legal questions.

Who owns digital assets?

How should governments regulate them?

What happens when mistakes occur in records designed to be difficult to change?

Fraud remains another concern. Scammers often exploit public excitement around NFTs and cryptocurrencies. Importantly, these scams usually arise from dishonest people, not from the blockchain technology itself.

As with mobile banking or online shopping, understanding the technology is one of the strongest forms of protection.

*Looking Ahead
*
Blockchain and NFTs are still evolving.

Some ideas will succeed.

Others will quietly disappear.

That is how innovation has always worked.

Few Kenyans imagined twenty years ago that sending money through a mobile phone would become an everyday habit. Today it feels ordinary.

Blockchain may follow a similar path—not because everyone suddenly becomes a cryptocurrency trader, but because the technology quietly finds practical uses in areas where trust, transparency, and reliable records matter most.

When that happens, many people may use blockchain every day without ever noticing it, just as millions of people send mobile money without thinking about the complex systems operating behind the screen.

Technology is at its best when it disappears into everyday life.

Perhaps that is the simplest way to understand blockchain.

It is not trying to replace human trust.

It is trying to help us record trust more faithfully.

And NFTs?

They simply answer an old human question in a new digital world:

_"How do we know this truly belongs to you?"
_
The answer, increasingly, may not come from a filing cabinet or a rubber stamp, but from a carefully maintained digital ledger shared across the world.

Building Confidence Without Knowing What You’re Doing (A Beginner’s Honest Story)

Okello Odhiambo — Wed, 13 May 2026 11:49:07 +0000

Last week, I passed an audit I was fully prepared to fail.

Not “maybe fail.”
Not “slightly unsure.”

Fail.

The kind where you’re already planning how you’ll explain yourself when everything starts falling apart.

But somehow… I passed.

And to be honest? I wasn’t even sure I deserved to.

Welcome to learning without a map

I’m currently learning software development at Zone01 Kisumu, where everything is peer-to-peer. No teachers. Just apprentices trying to figure things out, reviewing each other’s work, and occasionally pretending we understand what’s going on.

For the past two months, my learning journey has looked less like a straight line… and more like a circle.

Learn.
Unlearn.
Get confused.
Repeat.

At some point you even start asking yourself:

“Am I actually learning… or just surviving?”

The moment things stopped making sense

One project that really humbled me was ascii-art-web.

The task sounded simple enough:
Build a Go server and connect it to a web interface.

Simple… until it wasn’t.

Because just when I was starting to understand Go—just starting—HTML showed up like:

“Surprise 🙂”

Suddenly I wasn’t just thinking about logic anymore.
Now it was structure, templates, rendering…

At that point I just stared at my screen like:

“Wuod gi nyithindo, what is actually going on here?”

I didn’t fully understand what I was building.

But I still submitted it.

Because… what else are you going to do?

The real fear isn’t failure

Every time I hit “submit,” there’s a small moment of regret.

Like maybe if I close my laptop fast enough, the audit won’t happen.

Because the fear isn’t really failing.

It’s sitting in front of someone while they go through your code and ask:

“Why did you do this?”

And your brain just goes:

“We listen, we don’t judge.”

If I’m being honest, I’m less afraid of failing…

and more afraid of being exposed as someone who doesn’t fully understand what they’re doing.

The audit that almost ended me (but didn’t)

Then came net-cat.

Server. Client. Connections. Ports. Communication.

Big words. Serious things.

I walked into that audit already defeated.

And the auditor?
Very thorough. The kind who doesn’t just follow the questions—they expand them.

At some point, they started asking things that weren’t even on the audit sheet.

I remember thinking:

“Ah. This is where my journey ends.”

But somehow… I passed.

Passing without confidence is confusing

You’d think passing would feel amazing.

But instead, I just sat there wondering:

“Wait… so what exactly just happened?”

Because in my head, I was still the same person who didn’t fully get it.

That’s when something small shifted.

Instead of celebrating, I started seeing audits differently:

“Maybe this is not just a test… maybe this is where I actually learn the thing I thought I learned.”

What “not learning” really feels like

Let me be real.

There are days it feels like I’ve learned absolutely nothing.

Two months in… and sometimes I still feel like it’s day one.

You’re in a group discussion.
People are throwing around terms.
Debating solutions.

And you’re just there like:

“Yes… yes… I also agree… with… everything.”

Meanwhile, inside:

“Koro an gi wach matin… I am completely lost.”

And then the comparisons start.

“They understand this faster.”
“They explain things better.”
“They belong here.”

And you?

You’re not so sure.

But something is happening (quietly)

Even with all that confusion, there are small things that have changed.

I can push projects without struggling.
I understand my way around VS Code.
The terminal no longer feels like a place where mistakes go to multiply.

These aren’t big, dramatic wins.

But they matter.

Because a few weeks ago?
These same things felt impossible.

Maybe confidence isn’t the starting point

I used to think confidence comes first.

That one day I’d wake up and feel ready.

Now I’m starting to think that was a lie.

Because what’s actually happening is this:

You submit while unsure.
You get audited while nervous.
You pass… sometimes by surprise.

And slowly—very quietly—something starts to build.

Not loud confidence.
Not “I know everything now.”

Just a small, steady realization:

“I may not understand everything… but I’m not the same person I was when I started.”

So what does confidence mean to me right now?

It’s not clarity.
It’s not mastery.
It’s definitely not feeling ready.

Right now, confidence is much simpler than that.

It’s this:

Showing up. Submitting anyway. And refusing to quit.

Even when I feel lost.
Even when I can’t explain my own code properly.
Even when I’m sure I’m about to fail.

Because somehow… despite all that…

I’m still here.

Still learning.
Still confused.
Still moving forward.

And for now?

That’s enough.

After attending the piscine at Zone01 Kisumu twice (almost 60 days), I realized it’s less about coding and more about resilience. I wrote a story about the experience, the confusion, the checkpoints, the audits, and the lessons that come with them.

Okello Odhiambo — Thu, 12 Mar 2026 07:51:49 +0000

Okello Odhiambo

Mar 12

Surviving the Piscine at Zone01 Kisumu - 60 Days of Being Humbled by Code

#beginners #codenewbie #devjournal #learning

4 min read

Surviving the Piscine at Zone01 Kisumu - 60 Days of Being Humbled by Code

Okello Odhiambo — Thu, 12 Mar 2026 07:49:53 +0000

I attended the piscine twice.

That’s nearly 60 days of intense coding, confusion, debugging, and occasional existential crises in front of a computer.

And when I say intense, I mean the kind where you stare at your screen so long that even the keyboard starts judging you.

When I first joined the piscine at Zone01 Kisumu, I had zero tech background. Not “a little HTML” zero. I mean completely zero.

The closest I had come to programming was dialing USSD codes like *544# to check bundles.

Yet somehow, I had decided to learn software engineering.

Looking back, that decision would lead to one of the most challenging and transformative experiences of my life.

Day One: A Very Fast Reality Check

The first day of the piscine is where reality politely introduces itself.

You sit down, open your computer, log into the system, and look around the room.

Some people immediately start typing like they’ve been preparing for this moment since childhood.

Within the first hour, something becomes obvious.

Not everyone is starting from the same place.

Some participants come from computer science backgrounds or have already spent time coding. They move through exercises quickly and confidently.

Meanwhile, you’re still reading the instructions.

At Zone01, finishing an exercise is often called “BIM-ing” it.

So imagine hearing someone say:

“I’ve already BIM’d that exercise.”

And you haven’t even figured out what the instructions mean yet.

That’s the moment when your brain quietly asks:

“Are we sure we belong here?”

But stubbornness is powerful.

So you stay.

The Weekly Cycle: Hope vs Reality

The piscine has a rhythm that every participant eventually recognizes.

During the week, you start gaining confidence.

You solve a few exercises.
You fix a bug.
Maybe you even help someone else.

For a moment, you feel like you're finally getting the hang of things.

Then comes the checkpoint.

The 4-Hour Checkpoint Experience

The checkpoint is a timed exam designed to test your understanding.

And it’s also where confidence goes to die.

Everyone starts at the same time.

You open the exam.

You read the first question.

Then you stare at the screen.

Five minutes pass.

Ten minutes pass.

Meanwhile, the person next to you is already on Level 3.

At this point, many people develop the same coping mechanism: typing random commands just so it looks like you're working.

Your screen is empty.

But your keyboard is extremely busy.

Checkpoints have a way of reminding everyone that learning to code is not a straight line.

Group Projects: When Confidence Meets the Audit

Group work is one of the most interesting parts of the piscine.

People gather around one screen discussing solutions, sharing ideas, and proposing approaches.

Someone says:

“Let’s use recursion.”

Everyone nods.

Even the people who have absolutely no idea what recursion is.

For a moment, the team feels unstoppable.

Then comes audit time.

An auditor reviews your project and asks a simple question:

“Can you explain this part of the code?”

If you truly understand it, no problem.

If you don’t, the explanation suddenly becomes very creative.

You start sentences like:

“Basically what happens here is… you see… the function…”

And somehow the explanation never reaches a conclusion.

It’s a humbling moment that most piscine participants remember very clearly.

The AI Temptation

Let’s talk about something modern developers understand very well.

The temptation to use AI.

When you're stuck on a problem for hours, the thought appears:

“Maybe I should just get a small hint.”

Suddenly, perfect code appears.

Clean. Elegant. Working.

You submit it feeling brilliant.

Until someone asks:

“Can you explain what this line does?”

That’s when the real test begins.

The piscine doesn’t just evaluate whether your code works.

It checks whether you understand what you wrote.

And that’s a lesson many developers learn the hard way.

What the Piscine Actually Teaches

At first glance, the piscine looks like a coding bootcamp.

But after weeks of struggling through exercises, something becomes clear.

The real lesson isn’t just programming.

It’s resilience.

You learn how to deal with frustration.

You learn that confusion is part of the learning process.

And you learn that everyone—no matter how experienced—gets stuck sometimes.

A Luo proverb says:

“Piny owacho gi chike, to ng’ato nyalo puonjore.”
The world has its rules, but a person can learn them.

The piscine forces you to accept that progress happens slowly, one concept at a time.

Why I Came Back the Second Time

After my first attempt, I had a choice.

Walk away.

Or try again.

I came back.

Not because coding suddenly became easy.

But because something had changed.

I understood that the goal wasn’t to be the fastest person in the room.

The goal was simply to keep improving.

One exercise.

One concept.

One bug at a time.

Final Thoughts

Looking back at nearly 60 days in the piscine, one thing stands out.

The experience tests more than your technical ability.

It tests your patience.
Your humility.
Your willingness to keep learning.

Some days your screen is blank.

Some days the person next to you is already on Level 3.

But if you stay long enough, something interesting happens.

You start solving problems that once felt impossible.

And slowly, line by line, the code begins to make sense.

💬 If you’ve ever gone through a coding bootcamp, a 42/Zone01 piscine, or any intense learning experience, I’d love to hear your story.

What was the moment that humbled you the most?

Because if there’s one thing the piscine proves, it’s this:

Every developer has that moment.