DEV Community: Mohammed Ghabban

Mohammed Ghaban: Building, Learning, and Creating in AI

Mohammed Ghabban — Thu, 08 Oct 2026 20:04:31 +0000

Mohammed Ghaban: Building, Learning, and Creating in AI

I’m Mohammed Ghaban, a Yemeni developer working on open-source projects across AI agents, generative AI, machine learning, AI evaluation, and AI security.

My journey as a developer has always been driven by curiosity.

Since I was young, I’ve enjoyed learning, experimenting, and trying to build things just to see if I could make an idea work. There is something special about creating something from nothing and then seeing it actually work in front of you.

That feeling continues to motivate me today.

From curiosity to AI

My interest in AI grew naturally from my interest in technology and programming.

I became particularly interested in AI agents and systems that can do more than simply generate text. I wanted to explore systems that can use tools, write code, execute actions, solve problems, and be evaluated based on what they actually accomplish.

This led me to explore generative AI, machine learning, AI evaluation, benchmarking, and AI security.

I also began sharing projects and experiments through open source and platforms such as GitHub, Kaggle, and Google Skills.

Building CodeBots Arena

One of the projects that represents this journey is CodeBots Arena.

The idea started with Kaggle.

I was interested in AI competitions and began thinking about what an AI-vs-AI programming competition could look like.

Instead of only participating in competitions, I asked myself:

Why not build one?

That question became CodeBots Arena.

CodeBots Arena is an open-source AI-vs-AI coding arena where AI agents receive programming challenges, generate code, execute their solutions in a controlled environment, and compete based on measurable results.

The project brings together several areas that I enjoy:

AI agents
Generative AI
Programming
Automated evaluation
Sandboxed execution
ELO rankings
Open-source development

The central idea is simple:

AI coding agents shouldn’t only generate code — they should prove that their code works.

What building the project taught me

Building CodeBots Arena has taught me that generated code can look convincing without actually being correct.

An AI agent can produce a solution that seems reasonable but fails because of an edge case, an incorrect assumption, or a subtle implementation problem.

Running and evaluating the generated code changes the question.

Instead of asking only whether an answer looks good, we can ask whether the solution actually works.

That experience strengthened my interest in AI evaluation and benchmarking.

Learning from real engineering problems

The project has also involved ordinary software engineering challenges.

For example, I encountered a PYTHONPATH issue where tests passed locally but failed in CI.

It was a useful reminder that software is not finished simply because it works on one machine.

Reproducibility, testing, environment configuration, and CI are all important parts of building reliable software.

These experiences have shaped the way I approach development.

Continuing despite limited resources

My journey has also involved some practical challenges.

At one point, my computer stopped working, and because of my circumstances and the situation in Yemen, I wasn’t able to replace it.

I continued working through my iPhone, browser-based tools, and free resources.

It was difficult, especially when working on projects that normally require a full development environment.

But I decided to keep going.

That experience taught me to make the most of whatever resources are available and to adapt when circumstances are not ideal.

Progress may sometimes be slower, but it is still progress.

AI evaluation and benchmarking

Beyond CodeBots Arena, I’ve become increasingly interested in evaluating AI systems.

I’ve worked on projects related to AI hallucination benchmarking and other experiments designed to measure how AI systems behave.

As AI becomes more capable, I believe evaluation becomes increasingly important.

A system can sound intelligent while still producing incorrect results.

The same applies to AI-generated code.

We need ways to measure what systems actually accomplish, where they fail, and why.

Learning through Google and Kaggle

I have continued developing my skills through platforms such as Google Skills and Kaggle.

The badges, projects, experiments, and competitions are useful milestones, but for me they are not the final goal.

The real goal is learning enough to build something with what I’ve learned.

Whenever I discover a new technology, I want to experiment with it and understand what I can actually do with it.

Looking ahead

I want to continue working on AI agents, generative AI, machine learning, AI evaluation, and AI security.

I also want to continue developing CodeBots Arena and explore better ways to evaluate AI coding agents.

My long-term goal is to build useful open-source projects and contribute to the wider developer and AI community.

There is still a lot I want to learn.

Keep building

My journey has taught me that you don’t need perfect circumstances to start.

You can start with what you have.

You can learn through free resources.

You can build small projects.

You can fail, debug, and try again.

For me, curiosity has always been one of the strongest motivations to keep learning.

When an idea becomes a working project, even a small one, there is a feeling of achievement that makes the next challenge worth taking on.

I don’t know exactly where my journey will lead.

But I want to keep learning, experimenting, building, and contributing.

And I hope that the projects I’m building today will eventually become something meaningful.

⸻

Read my Developer Story on CoderLegion

I recently shared a longer version of my developer journey and the story behind CodeBots Arena through CoderLegion:

https://coderlegion.com/30304/mohammed-ghaban-built-an-arena-where-ai-coding-agents-have-to-prove-their-code-works

CodeBots Arena — Open Source:
https://github.com/Mhmda1998/CodeBots-Arena

⸻

I’m Mohammed Ghaban, a Yemeni developer working on open-source projects in AI agents, generative AI, machine learning, AI evaluation, and AI security.

When My Tests Worked Locally but CI Couldn’t Find My Code: Fixing PYTHONPATH in CodeBots Arena

Mohammed Ghabban — Wed, 19 Aug 2026 20:15:15 +0000

When My Tests Worked Locally but CI Couldn’t Find My Code: Fixing PYTHONPATH in CodeBots Arena

This is a submission for DEV’s Summer Bug Smash: Smash Stories powered by Sentry.

🐛 The Bug

While developing CodeBots Arena, an AI vs AI code battle platform, I started building automated tests for the battle engine.

The tests worked in my local development environment.

Then I moved the same test workflow into CI.

That is where things became interesting.

The CI environment could not resolve the project modules correctly. The code was there, the tests were there, but Python was not looking in the right place when the tests were executed.

The problem came down to the Python module search path.

🔍 Local Environment vs. CI

Locally, my development environment already had the project structure and paths configured in a way that allowed imports to work.

CI was a clean environment.

That difference exposed an assumption in the project:

“The test runner knew where to find the server-side Python package.”

It did not.

This is one of those bugs that can be confusing because the code itself looks correct.

The failure isn’t necessarily caused by the function being tested. It can happen before the test even gets to that point.

🧪 Tracking Down the Problem

I started by looking at the test imports and the project structure.

The tests needed to import components such as the battle engine, but the CI environment did not automatically include the required project directory in Python’s module search path.

Instead of changing the tests just to make them pass, I wanted the CI environment to correctly understand the project structure.

That led me to PYTHONPATH.

🛠️ The Fix

I updated the GitHub Actions test step so that the project’s server directory was included in PYTHONPATH before running pytest.

The CI workflow effectively changed from simply running the tests to explicitly telling Python where the project modules were located.

The important part was:

env:
PYTHONPATH: ${{ github.workspace }}/server

The tests could then be executed with:

python -m pytest tests/ -v

This change is recorded in the repository history in the commit:

fa401d4 — Add PYTHONPATH to test run step in CI workflow

✅ Verification

After the change, the CI test environment could resolve the required Python modules correctly.

The test workflow was able to move past the import/path problem and execute the automated tests.

This was a good reminder that “works on my machine” doesn’t always mean “works in CI.”

A clean CI environment can expose assumptions that are invisible during local development.

💡 What I Learned

The biggest lesson wasn’t just how to set PYTHONPATH.

It was learning to distinguish between an application bug and an environment/configuration bug.

When a test fails, I now try to answer:

Did the application logic fail?
Did the test fail?
Or did the environment fail before the test could even run?

That simple distinction can save a lot of debugging time.

🚧 The Challenge

The challenging part was that the project itself was available in the CI environment.

The problem was not that the files were missing.

Python simply didn’t have the correct location in its module search path.

That made the issue easy to overlook if I focused only on the application code.

📈 Before vs. After

Before:

The tests worked in my local development environment, but the CI environment could not correctly resolve the project’s Python modules.

After:

The CI workflow explicitly configured PYTHONPATH to include the server directory, allowing the test runner to locate the required modules and execute the test suite.

🧠 Why This Bug Matters

This was a relatively small configuration change, but it highlighted an important software engineering principle:

Development environments should not hide assumptions from CI.

Automated testing is only useful when the environment running those tests is configured correctly.

For CodeBots Arena, where the battle engine and AI bot components depend on multiple Python modules, making the CI environment predictable is an important part of keeping the project maintainable.

🚀 What I’m Proud Of

I’m proud that the fix was small and targeted.

I didn’t rewrite the test suite or change application logic just to satisfy CI.

I identified the actual environment problem and fixed the configuration at the appropriate layer.

Sometimes the best bug fix is the smallest change that addresses the real cause.

🔗 Project

CodeBots Arena is an AI vs AI Code Battle Arena built around automated battles between coding agents.

The project includes a battle engine, bot SDK, ELO rating system, isolated execution, API components, and automated tests.

GitHub:
https://github.com/Mhmda1998/CodeBots-Arena

🎯 Final Takeaway

A test passing locally can give you confidence, but CI gives you a different perspective.

In my case, CI exposed an assumption that my local environment had been hiding.

The fix was one configuration change, but the lesson was much bigger:

“When CI says it can’t find your code, don’t immediately rewrite the code. Check the environment first.”

devchallenge #bugsmash #python #githubactions #testing #debugging #ai #softwaredevelopment

AI Code Reviewer: Built with Google AI Studio

Mohammed Ghabban — Tue, 28 Jul 2026 22:47:32 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

title: AI Code Reviewer: Built with Google AI Studio
published: true

tags: GoogleAIStudio, AI, Python, DeveloperTools

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I built AI Code Reviewer, an intelligent web application generated with Google AI Studio. It automates code quality reviews for developers, analyzing code snippets for performance bottlenecks, unhandled exceptions, and logical issues while outputting structured feedback.

Demo

Here is the application in action analyzing code for potential KeyErrors and performance optimization:

Live App URL: https://aistudio.google.com/apps/065abcf0-af2f-4de7-bf38-ef0e13a0b719?project=hook-b750a&showPreview=true

My Experience

Building this app through Google AI Studio's Build interface was smooth and efficient.

Key Takeaways: Generative tools make structuring system prompts and building complex functional micro-apps extremely rapid.
What Surprised Me: The precision with which the model identifies edge-case code bugs (like quadratic string concatenation and unhandled KeyErrors) out of the box.

Tracing and Resolving a Critical Security Bug in Smart Contract Analysis

Mohammed Ghabban — Tue, 21 Jul 2026 21:52:10 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Problem

During a recent security review, I identified a critical flaw where specific edge-case input vectors could bypass automated vulnerability scanners during contract inspection. This created a potential risk of missing hidden security vulnerabilities in smart contract deployments.

The Deep Dive & Solution

To address this issue, I analyzed the parser logic and restructured the code evaluation flow:

Root Cause Analysis: Identified that improper state handling caused validation checks to skip on complex multi-transaction scenarios.
Implementation: Added rigorous assertion checks, updated input sanitization pipelines, and optimized error reporting logs.
Verification: Ran automated tests against edge cases to ensure 100% coverage without affecting performance.

What I Learned

Securing smart contracts and AI monitoring tools requires proactive boundary-testing. Ensuring that unexpected payloads fail safely is just as vital as optimizing the main execution logic.

How to Build an AI Agent for Code Monitoring and Security Analysis

Mohammed Ghabban — Tue, 21 Jul 2026 21:44:21 +0000

Monitoring code quality and detecting security vulnerabilities early in the development lifecycle is essential for building robust software.

In this post, I want to highlight the core ideas behind building an AI Agent designed to continuously monitor source code and ensure a more secure development environment.

Key Objectives of the AI Agent:

Automated Scanning: Analyzing codebase changes to detect potential security risks and code smells.
Proactive Defense: Alerting developers about vulnerabilities before code gets deployed to production.
Developer Productivity: Assisting team members with faster, automated code reviews.

Have you built or integrated AI agents into your development workflow? I'd love to hear your thoughts and experiences in the comments below!