DEV Community: Emiedonmokumo Dick-Boro

Most Agent Failures Aren't Intelligence Failures

Emiedonmokumo Dick-Boro — Tue, 09 Jun 2026 16:11:33 +0000

One thing I've learned from building AI agents is that intelligence alone isn't enough. The closer the relevant context is to an agent, the better it performs.

At first, I thought better models would automatically produce better results. But after working with retrieval systems, memory, and tool calling, I noticed something interesting. Agents often fail not because they can't reason, but because the information they need is too far away from their current context.

If the right document, instruction, or piece of data is already present when the agent starts reasoning, the quality of the output improves dramatically. If that same information sits in a database waiting to be retrieved, performance becomes less predictable.

The more I thought about it, the more I realized humans work the same way.

I write better code when the relevant documentation is open beside me. I debug faster when logs are visible. I learn quicker when examples are right in front of me. The knowledge itself hasn't changed—only its proximity has.

This led me to a simple idea:

The effectiveness of an agent is often proportional to how close the required context is to its decision-making process.

As developers, we spend a lot of time asking how to build smarter systems. Increasingly, I think a better question is: how do we bring the right information closer to the system?

Because in my experience, whether it's humans or AI, the closest context usually wins.

Moving a Specific Commit to Another Branch in Git

Emiedonmokumo Dick-Boro — Tue, 14 Oct 2025 12:01:54 +0000

Sometimes you might make a commit on the wrong branch in Git, maybe you were supposed to be on a feature branch but you were still on main. You don’t need to delete or redo your work, Git provides a simple way to move that commit to another branch using a command called git cherry-pick.

The git cherry-pick command allows you to copy a specific commit from one branch and apply it to another. It doesn’t bring along the entire branch history, just that single commit. For example, if your commit hash is 0e983810d6de98c8710cf2cda2df17d9b05875e7, and you want it to appear in another branch, you first switch to the branch you want the commit to go to using git checkout <branch-name>. If the branch doesn’t exist yet, you can create it using git checkout -b <new-branch>.

After switching, you run git cherry-pick 0e983810d6de98c8710cf2cda2df17d9b05875e7. This command copies the changes from that commit and applies them to your current branch. If there are no conflicts, the commit will appear in the new branch just like it was originally made there. If Git detects any conflicts, it will pause and ask you to fix them before continuing. Once resolved, you can run git add . followed by git cherry-pick --continue to finish applying the commit.

In simple terms, git cherry-pick lets you move specific commits between branches without merging or redoing your work. It’s one of the most useful Git commands when you make a mistake or need to copy a fix to another branch quickly.

The Hidden Limitation of Mongoose Discriminators That Surprises Many Developers

Emiedonmokumo Dick-Boro — Tue, 29 Jul 2025 07:04:44 +0000

While working on a laundry service project using MongoDB and Mongoose, I ran into a surprisingly common issue E11000 duplicate key error collection: LaundryHouse index: name_1 dup key: { name: "nylon" } and it turns out, I wasn’t alone. This limitation happens when using Mongoose discriminators in combination with unique: true indexes. It caused a duplicate key error that initially seemed like a mistake in my code but it wasn’t.

Mongoose discriminators allow you to define multiple schemas (like ClotheType, PackingType, etc.) that share the same parent model and collection. In my case, all these types are stored in the same LaundryHouse collection. Everything worked fine until I tried to create a PackingType with the same name (e.g., "nylon") for two different laundry businesses. MongoDB threw a duplicate key error, complaining that the value "nylon" already existed even though it was for separate businesses.

At first glance, this doesn’t make sense. But under the hood, the issue comes from how Mongoose and MongoDB handle indexes. When you use unique: true on a field like name, Mongoose creates a global unique index on that field in the shared collection. MongoDB doesn’t care about your business logic or relationships if two documents have the same name, it throws an error, even if they belong to different entities.

This behavior is completely normal when using Mongoose discriminators. It’s not a bug or a flaw in your logic it’s simply a side effect of working with shared collections and automatic indexing. Many developers run into this when building multi-tenant applications or when trying to enforce field-level uniqueness in isolated contexts.

The correct approach is to replace the global unique: true with a compound unique index. For example, in my case, I used packingTypeSchema.index({ laundryBusiness: 1, name: 1 }, { unique: true });. This ensures that each name is unique per laundryBusiness, but allows different businesses to use the same name like "nylon" without any conflict.

So if you’re using Mongoose discriminators and facing duplicate key errors, check your indexes especially if you're using unique: true on shared fields. And remember, this is a known limitation, not a mistake. The fix is simple, and it will save you a lot of debugging time.

Hope this helps someone out there struggling with the same issue!