DEV Community: David Uwagbale

We Knew How AI Worked Yet We Fumbled the Architecture

David Uwagbale — Mon, 27 Jul 2026 07:00:00 +0000

I know a lot of people that have taken courses in AI or Machine Learning, and yet when they want to build something other than training a model, it's like all that knowledge gets locked away or just goes down the drain.

In this era of AI, 2026, it is essential to have a basic knowledge of how AI works, and even more so if you hope to create solutions using AI itself. Yet the same mistakes are still being made, and honestly, I can't really fault them. It only really becomes noticeable when System Design is explored.

The Trap Big Models Lure Us Into

When faced with a complex feature, our modern impulse as builders is almost too simple: just throw the strongest LLM at it.

We’ve been conditioned by these powerful APIs to treat top-tier enterprise models like universal computing engines. If a task involves data interpretation, we dump the raw context into the prompt window and let the model figure it out. It’s quick to prototype, that's what is shown in tutorials and feels like magic... right until you try to run it in production at scale.

Building an AI Tool for a Payment App

Let's cite a really easy example.

Sometime in 2025, I had the opportunity of participating in a hackathon, and what we built was a user experience revision of what making payments should feel like, especially when trying to make sure that the user gets more utility from the payment app than just making payments.

This seemed straightforward enough at first until we thought: what else would someone want to do aside make payments 😂.
Regardless, we set out to build this.

We made a redesign of what the User Flow and Experience might feel like to accomodate what we figured would help, among these was a pill section for easy and quick labelling of transactions (like Food, Transport, Subscription, etc).

The AI feature we added was that, having labelled the transactions, we would be able to show the user really great insights into their spending habits and give suggestions too, while allowing them to visually confirm their excesses rather than just seeing the regular: total inflow, total outflow, and list of transactions.

The issue? We planned to just take the selected range of the user's transaction data within that period and feed it to an enterprise LLM.

Wait...
Pause...

If that sounded normal or typical to you, then you really need this next part.

The true cost of our "lazy" architecture

Even if we decide to completely turn a blind eye to the legal and privacy issues with this approach 😖, we also have a huge issue with the design of this system because what this implies is that for every single user, we will be sending all of that data to the model.

The token costs alone will be outrageouly expensive. Then if we later decide to introduce daily insights too, it becomes a lot worse because we'll need to compute all of this every single day. And if we eventually want insights after every transaction... we're swimming in debt hell.

Not too long ago, I came across something while reading online about using Fable 5 that made me come back to this experience:

Don't make your superpower do all the work.

Your strongest model shouldn't be doing everything. Let your application handle all the smaller, deterministic work so that the really good model only performs the part that actually needs that intelligence. You're saving tokens, saving time, saving resources, and honestly building a much better system in the process.

Rethinking the Pipeline

Alright back to the project: remember, we already have knowledge of how AI works. If you really look at our problem, it is simply a classification issue. Well, that is the first step:

Local Vectorization & Classification: Instead of sending raw text logs to a remote model, we can compute embeddings locally or run light statistical classification to group spending.
Deterministic Aggregation: The backend then sums up totals, compute percentages, and even detect anomalies (still using regular code).
Targeted Inference: Pass only the condensed, anonymized summary metrics into a lightweight local model to generate a short, human-readable insight.

See, there was really no need to send every single raw transaction to an enterprise LLM, and the data never even had to leave our system.

Zooming out a bit

This principle doesn't stop at fintech apps either. You see it everywhere in AI engineering: like people feeding a massive 50-page PDF straight into an LLM just to extract a date, instead of letting a simple parser pull the text first. Or letting a chatbot search an entire raw database on every prompt instead of querying a structured vector index first.

So maybe the next thing your AI product needs isn't another memory cache or more queues for speed. It may just be taking a step back to ask if you're forcing your biggest model to do basic math that a few lines of standard code could handle.

Because when those other optimizations are eventually added on top of a sane architecture, the speed boost almost feels exponential.

The 'Learn to Scale' Fallacy: Why You Can't Out-Infra a Bottleneck

David Uwagbale — Mon, 27 Jul 2026 07:00:00 +0000

Here is a brief version on Linkedin

"Scale this codebase to handle 50,000 concurrent users. MAKE NO MISTAKES!"

Now, you might want to judge a prompt like that as pure vibecoding, but I honestly think most of us haven't been in a much different situation. We use the phrase "build scalable products" like it's a default setting in your IDE, but if someone asks you how to actually do it, where do you start?

Two months ago, I set out on a dedicated journey to "learn how to scale" software applications. My mindset going in was pretty straightforward: figure out the magical setup and master the tools that high-throughput platforms use.

It didn't take long for me to realize that my core objective itself was fundamentally wrong. Or to put it better, ignorant.

I thought I was trying to "learn how to scale". What I was actually missing was learning how to identify the bottleneck.

The Trap of Shiny Infrastructure

When you first decide to tackle system scalability, there is a strong temptation to act like an infrastructure architect who just discovered a shiny new toolbox. You start thinking about:

Throwing Redis everywhere because fast in-memory lookups make everything speed up... right?
Spinning up Docker containers
Setting up complex event queues and asynchronous worker pipelines.

These are actually great but you see, scaling a product is not just about adding these fancy services. Those aren't strategies; they're just tools. And if you add a fancy caching layer on top of a broken database query pattern, you haven't really scaled your application, you’ve just further covered up the issue.

Those tools only become effective when you look into and design the proper ways they can support the specific stress points of your setup.

How to search for this bottleneck?

To properly scale a system, you have to realize that the system doesn't fail everywhere at once. It fails at boundaries where the pressure builds first.

Is it database connection limits? CPU saturation? Disk I/O? Network bandwidth? Now we are asking right questions.
Exploring where these failures will emerge as load and complexity grows is fundamentally a System Design problem.

Shifting from Buzzwords to System First-Principles

There is no single template to scale a system. It depends entirely on the unique components, data flow and layers that exist in that specific one.

Once you shift your perspective from "How do I make this app scalable?" to "Where is this system going to break first?", your relationship with technology changes completely.

Suddenly, you stop seeing technologies as items on a high-scalability checklist. They become targeted solutions to solve very specific constraints within a system you've mapped out.

My Ongoing Learning

I used to think scaling was about memorizing a collection of clever practices. Now I see it as learning how to reason about systems under load.

I’m still deep in this journey and I’ll be documenting more of these architectural lessons on The Engineering Log as I learn more.

For any engineer or system builder that could be reading this, I would really love to know that one practical lesson or sudden realization that completely changed the way you think about scaling systems

Why I Want to Be a Front-End Developer and How HNG Will Help Me Achieve My Goals

David Uwagbale — Sun, 02 Feb 2025 17:49:25 +0000

Starting in 2022, I have been writing programs that power web applications

As a skilled fullstack web developer, I have always been drawn to the dynamic world of frontend development. It is, in my opinion, the most impressionable part of a website or an application.
The ability to create seamless, visually appealing and functional user interfaces is truly important. Although I have already mastered various tools, libraries and frameworks to achieve this, I wasn't always good at it.

My Motivation for Becoming a Frontend Developer

My journey into web development began with a deep curiosity about how computers work and how users interact with them. I started with writing JavaScript codes and after a while I developed a deep passion for writing code that runs on the browser.
Soon enough I was manipulating the DOM and then realised I would have to learn HTML and CSS 🥲.
Yeahh, they weren't as difficult as I thought them to be, in fact, I later realised that I got comfortable with the hard part first. 😅

From exploring modern libraries, frameworks and docs to building projects with great interfaces. It became what I loved to do most, making me constantly learn more on how I could perfect this skill I had developed.

How HNG Will Help Me Grow in the Field

Regardless of my current level of expertise, I see the HNG Internship as an invaluable experience.
The HNG Internship is known for its intensive, hands-on learning experience. It provides opportunities such as:

Real-World Projects & Collaboration
Mastering Advanced Front-End Technologies
Exposure to Industry Standards
Levelling up my Portfolio with Industry-Ready Projects
Networking and Career Growth

I particularly look forward to engaging with experts, receiving feedback, and positioning myself for recruiters that wish to Hire Web Developers or Hire React Developers

Conclusion

My journey in web development has been exciting, and front-end engineering remains a critical focus for me. While I have built a strong foundation in JavaScript, React, and modern front-end tools, I believe the HNG Internship will provide the structured learning, mentorship, and real-world exposure needed to take my skills to the next level. Through this program, I aim to refine my expertise, build industry-standard applications, and become a top-tier front-end developer ready to tackle complex challenges in the tech space.