DEV Community: Amon Ochuka

Why AI Can't Save You From Not Understanding Your Own System

Amon Ochuka — Sat, 18 Jul 2026 17:01:40 +0000

System design matters more than most people realize, and most of us practice it every day without noticing.

AI has made building software faster than it's ever been. It can scaffold a project in seconds, generate a CRUD layer, explain a concept you're fuzzy on, and get you from idea to working prototype in minutes. If you're learning to code right now, this is an incredible advantage that developers five years ago simply didn't have.
But there's a quiet trap hiding inside that speed: AI is only as useful as your ability to follow what it built.
This week I ran into a bug that made that lesson very concrete.

The Bug That Wasn't Where It Looked

I was working on an escrow platform's backend — a Go API with layered architecture: handlers, services, repositories, middleware. One endpoint kept returning a plain 400 Bad Request, no error body, nothing useful in the response.
The obvious place to look was the endpoint itself. The route existed. The handler looked correct. The service logic seemed fine. I stared at that one function for longer than I'd like to admit, because that's where the symptom was showing up.
The actual problem wasn't there at all.
It turned out a stale access token from an earlier test was silently failing verification before the request ever reached my handler. The middleware sitting in front of the route was rejecting it, quietly, without the kind of error message that would've pointed me anywhere useful.
The fix wasn't in the endpoint. It was in understanding the full path a request takes through the system — middleware, then handler, then service, then repository,and tracing it one layer at a time, adding a log line at each boundary until I found exactly where execution stopped.

Why AI Couldn't Just Solve This For Me

Here's the part I want to sit with, because I think it's the actual lesson, not just an anecdote.
If I'd asked an AI assistant "why is this endpoint returning 400," it could reason about the code I showed it,and it did, correctly, in this exact case. But it could only reason about what I gave it. It doesn't have a live view of my running server, my actual request/response cycle, or my database state. It can't run my curl command and watch what happens.
It can suggest the most likely causes based on patterns, but it can't independently verify which one is actually true in my specific running system.
That verification step — the actual debugging — still has to happen inside your own understanding of how the pieces fit together. AI can help you form hypotheses faster. It cannot replace tracing the real, live behavior of your own application.

This is true at a small scale (one 400 error) and it's even more true at the system design level. AI is excellent at generating a plausible-looking architecture — a service layer here, a repository there, a middleware chain that looks clean on paper. But plausible and correct for your actual system are not the same thing. If you don't understand why the architecture is shaped the way it is, you won't notice when it's subtly wrong for your use case, and you definitely won't be able to debug it when something breaks in the seams between the pieces AI generated separately.

System Design Is Something You Already Practice

Here's the thing I think gets missed: system design isn't some separate, advanced discipline you unlock later. If you've ever asked yourself questions like:

"Should this validation live in the handler or the service?"
"What happens if this database call fails halfway through?"
"Does this component need to know about that one, or should they stay decoupled?"

— you were already doing system design. Most developers do this daily, in small decisions, without ever labeling it that way. AI can generate answers to these questions for you. But if you don't understand why one answer is better than another for your specific system, you're not actually equipped to catch it when the AI's answer is wrong, or right in general but wrong for your case.

A Concrete Example: Layered Validation

To make this less abstract, here's a real pattern from the same project. I have three related resources — a deal, an artifact belonging to that deal, and a verification belonging to that artifact.
Early on, nothing stopped a client from requesting artifact ID from deal A while passing deal ID for deal B in the URL — the IDs would resolve independently, and as long as each one individually existed in the database, the request would "succeed," even though the artifact didn't actually belong to that deal.

The fix wasn't complicated once it was understood:

if artifact.DealID != dealID { return nil, ErrArtifactNotFound }

Every layer that owns a nested resource needs to check that the parent chain actually matches, not just that each individual ID exists somewhere in the database. This is the kind of bug that's easy for AI to catch once you point at it directly, but it's very easy to miss in the first pass if you're not thinking about your system's ownership hierarchy at all, and just asking AI to "add an endpoint to get a verification by ID."
The endpoint worked. It just wasn't correct, and "works" and "correct" diverge exactly at the boundaries AI can't see unless you show it the full picture.

So What Does This Actually Mean Day to Day?

I don't think the answer is "don't use AI for architecture", that would throw away a genuinely useful tool. I think the answer is closer to this:
Use AI to move faster, not to move blind.
Concretely, that's looked like:

Asking why a suggested pattern works, not just accepting that it does
Deliberately tracing a request through every layer it passes through, even when things are working, so I actually know the shape of my own system
Treating a bug as a chance to understand the architecture better, not just to patch the symptom
Writing my own validation logic (like the ownership check above) by reasoning through the actual failure case, rather than only generating code and hoping it's complete

None of this is about distrusting AI. It's about recognizing that AI's usefulness for system design has a hard ceiling: it can only be as good as the mental model you bring to the conversation. If you don't understand your own system, you can't tell a subtly wrong suggestion from a genuinely good one, you can only tell "does this compile" from "does this error," and that's a much weaker signal than actually knowing your architecture.

So remember...
You don't need to memorize every line of code you write, and you shouldn't try to. But you do need to understand how your system flows — request in, through which layers, touching which data, back out — because that's the only thing that lets you debug with confidence instead of guessing, and it's the only thing that lets you actually evaluate whether an AI-suggested design is right for your system, not just right in general.
That's what turns building software from assembling suggestions into actually engineering something.

The Rise, Pause, and Rise of CRUD Apps

Amon Ochuka — Wed, 27 May 2026 07:19:46 +0000

In the early days of the web, websites were mostly digital brochures. They were static HTML pages. You could read them, but you couldn't interact with them. If a business wanted to change a price, a developer had to manually edit code and re-upload the file via FTP.
It was slow, expensive, and didn't scale.

Then came the legendary LAMP stack (Linux, Apache, MySQL, PHP). Suddenly, the web became dynamic. The industry quickly realized that almost every business problem on earth;whether running a bank, an online store, or a social network,boiled down to four fundamental actions:

Create: Letting a user sign up or post a status.
Read: Showing a user their profile or a product list.
Update: Letting a user change their password.
Delete: Letting a user close an account.

By the mid-2000s, frameworks like Ruby on Rails, Django, and Laravel arrived. They turned CRUD into a science. With a single command line prompt (rails generate scaffold), a developer could spin up a fully functioning database table, back-end logic, and front-end forms in seconds.
This was the first great rise. CRUD apps became the undisputed infrastructure of the global economy. They weren't flashy, but they were predictable and deeply tied to the absolute truth of the database.

The Pause: The "CRUD is Boring" Mirage
Then, things got weird. Around 2015, the developer community collectively decided that simple, server-rendered CRUD apps were "boring." We entered the era of massive Single Page Applications (SPAs), microservices, GraphQL, and serverless hype.We started treating the database like something to be hidden behind ten layers of abstraction. Instead of a simple PHP or Rails script fetching a row from MySQL, we introduced a mountain of complexity:

The SPA Takeover: We moved the entire application logic to the browser. Suddenly, a simple user profile required React, Redux for state management, Webpack for bundling, and a massive JavaScript file that took 5 seconds to load on a mobile phone.
The API Chasm: We separated the front end and the back end entirely. Now, to display a simple list of products, you needed a REST or GraphQL API layer, complex CORS configurations, and token-based authentication (JWT) just to talk to your own database.
Microservice Madness: We broke monolithic apps into dozens of tiny services. A basic update operation now had to hop across three different servers, manage distributed transactions, and use Kafka queues just to change a user's email address.

We spent a decade over-engineering the front end just to realize that users still just want to fill out a form and hit submit. We swapped reliable server logs for confusing JavaScript console errors. We paused the simplicity of CRUD, and in return, we got total JavaScript fatigue.

The Crypto & Blockchain Detour: An Append-Only Trap
As the web-development world was over-engineering the front end, the Web3 and blockchain movement emerged, promising to decentralize the entire internet. Enthusiasts claimed that the "shared ledger" would replace traditional databases entirely.

But reality caught up quickly.

A blockchain is fundamentally an append-only ledger. In CRUD terms, it is brilliant at Create and Read, but terrible at Update and Delete.

Because data on a blockchain is immutable, it is incredibly slow and quite expensive for everyday operations. Worse, it creates a massive legal nightmare. Privacy frameworks like Europe's GDPR mandate that users have the "right to be forgotten"; a legal requirement to Delete data. Because you cannot delete data from a block, tech companies quickly realized they couldn't run a compliant business on a blockchain alone.

The blockchain didn't kill the database; instead, decentralized applications (dApps) still had to be wrapped in traditional CRUD architectures to cache data, update states quickly, and manage local user profiles efficiently.

The Second Rise: AI and the Return to Absolute Truth
Following the blockchain hype came the AI boom. Large Language Models (LLMs) can write code, analyze data, and build entire workflows in seconds. Prominent tech voices started declaring that apps were dead, and the era of the user interface was over.

But once again, the industry hit the same foundational wall: AI is probabilistic, but business is deterministic.

AI can write poetry, but it still needs a SQL database to know where to ship your package. An LLM cannot guess a bank balance. It cannot "predict" a shipping address. AI models are stateless; they don't know anything for sure; they just guess the next most likely word based on probability.

Tech is the User, CRUD is the Foundation
This realization has triggered the second rise of the CRUD app. We aren't throwing CRUD away; we are realizing it is the guardrail that keeps both AI and Web3 tethered to reality.
The relationship has completely flipped: AI and blockchain are no longer trying to replace the CRUD app; they are becoming the users of it.

When an AI agent "cancels your subscription," it executes a standard Update or Delete command via a regular API to a traditional database.

When a smart contract processes a transaction, a traditional CRUD system reads the event to update a user's dashboard instantly.

The Ultimate Backup
Most importantly, CRUD apps are our absolute fallback. AI models hallucinate, prompt injections corrupt logic, and decentralized networks suffer from latency or high gas fees.
When the advanced tech stack glitches or goes offline, humans cannot be left staring at a broken terminal. We need a direct, unabstracted, deterministic interface to view, edit, and fix the underlying data manually.

We need a CRUD app as our ultimate backup.

Conclusion: Boring is Beautiful Again
The tech industry went on a decade-long detour. We ran away from CRUD because it felt too simple, hiding it behind over-engineered JavaScript frameworks, distributed ledgers, and autonomous AI.

But the loop has closed. We are entering an era where "boring" software is beautiful again. Frameworks like Next.js, Remix, and HTMX are booming because they bring us back to simple, server-rendered data management.

No matter how smart the AI gets or how decentralized the ledger becomes, the world will always need a rock-solid database to store the absolute truth. And humans will always need a CRUD app to make sure that the database is backed up.

Long live the CRUD app.

Kiboko to Sherehe(polite): From Strict Go Rules to JavaScript Chaos

Amon Ochuka — Thu, 07 May 2026 17:53:56 +0000

Growing up in a typical strict African household always had a very clear structure, well at least for me.
There were rules. Not suggestions. Not “best practices.” Rules. You never really negotiated them, you just executed them.

You woke up early. You went to school. You came back on time. You didn’t always get the chance to “try things.” You mostly followed instructions.

If you messed up, there was usually a very immediate feedback loop.
Let’s just call it… real-time debugging. ("Kiboko")

Now fast forward to adulthood (or campus life, which feels like a soft launch into adulthood).
Suddenly:

No one is asking where you are
You can sleep at 3AM and call it “freedom”
Food is no longer provided;it’s a budgeting problem
And somehow, people are going out on weekdays like it’s normal("sherehe polite")

It feels like moving from a tightly controlled environment into an open-world sandbox with no manual.

And that’s exactly how learning JavaScript felt after coming from Go.

Go felt like home

Go is structured, strict, and predictable.It feels like that kind of upbringing where:

There is a correct way to do things
Mistakes are immediately pointed out
You don’t get “creative freedom” with rules
Everything has a clear, disciplined path

If you write something wrong, Go doesn’t argue with you.
It simply refuses to proceed.
Very “strict parent energy.”

JavaScript feels like campus life

Suddenly, everything is allowed.
Almost too allowed.

You can write things that technically work but feel emotionally wrong:

"5" + 1 // "51"
"5" - 1 // 4

And the language just… accepts it.
No questions. No intervention. No moral guidance.(This is where I would have been properly debugged)

Coming from Go, it feels like moving from mama's hot home-cooked meals, to a hostel where someone is boiling noodles in a sufuria at 2AM, while watching YouTube at full volume.

It works.But you’re not always sure it should.

The adjustment phase

At first, JavaScript feels messy.
Too flexible. Too forgiving. Too many ways to do the same thing.
But slowly, something changes.
You realize the language isn’t enforcing discipline on you, you’re expected to build it yourself.

That’s the shift.Go gives you structure upfront.
JavaScript forces you to learn structure through experience.

One is guided discipline.The other is learned discipline

Final thoughts

Growing up strict teaches you order.Campus life teaches you independence.
Go gives you rules.
JavaScript gives you freedom, and occasionally lets you suffer for bad decisions.

And maybe that’s the real lesson:
Structure is important, but so is learning how to create it for yourself when no one is watching.

Why AI Is Unlikely To Be A Game-Changer In African Economies

Amon Ochuka — Tue, 17 Feb 2026 07:34:27 +0000

Everyone is talking about AI transforming Africa, but the reality on the ground is very different, especially in countries facing electricity shortages and monopolies in key sectors. While AI has enormous potential globally, in many African contexts it is unlikely to become the economic miracle some people hope for, at least in the near term.

Electricity Shortages Are a Major Bottleneck

AI systems, whether cloud-hosted or on-device, consume a significant amount of electricity. Training even a single large AI model can use as much power as a small town in a month. Many African countries struggle with unreliable grids and frequent load shedding. Even highly skilled developers cannot run AI consistently without stable electricity, and relying on generators or solar power adds both cost and operational complexity, making many AI projects financially unviable.

Infrastructure Needs Go Beyond Power

AI requires more than electricity. Fast internet, reliable data storage, cloud computing, and ongoing maintenance are essential. Many regions still lack basic connectivity, and data centers are often concentrated in a few major cities. This makes AI adoption uneven and prevents smaller startups from scaling their solutions effectively.

Monopolies Stifle Innovation

Key sectors like telecommunications, banking, and energy are dominated by a few large players. Small AI startups often struggle to access APIs or market opportunities, as monopolies prioritize existing profit models over risky new technologies.

Talent Gaps Limit Scale

AI requires skilled engineers and data scientists. While Africa has a growing developer community, high-level AI talent remains limited, and access to training and compute resources is uneven, slowing adoption.

Localized Opportunities Exist

AI can succeed where infrastructure is reliable, such as mobile money in Kenya or agri-tech in parts of Nigeria. These are notable exceptions, not the rule.

Conclusion

AI is a powerful tool, but tools don’t operate in a vacuum. Without reliable electricity, fair competition, and solid infrastructure, AI is unlikely to drive broad economic growth. Prioritizing fundamental challenges should come first, before expecting AI to revolutionize economies.