Coder Legion - Recent posts tagged devstory

Mohammed Ghaban Built an Arena Where AI Coding Agents Have to Prove Their Code Works

Thu, 08 Oct 2026 13:37:53 +0000

Mohammed Ghaban Built an Arena Where AI Coding Agents Have to Prove Their Code Works

AI code can look right and still fail. Mohammed Ghaban built an arena that runs it to find out.

Mohammed Ghaban is an AI/ML developer and open-source contributor from Yemen, focused on building practical AI applications, intelligent agents, and developer tools.

His work spans Generative AI, LLMs, AI agents, machine learning, MLOps, and AI security. But one of his most interesting projects takes a very practical approach to a growing problem in software development:

What happens when AI-generated code looks correct but isn't?

That question led Mohammed to build CodeBots Arena, an AI-vs-AI programming battle arena where AI agents generate code, execute it in a controlled environment, and compete based on the results.

The project combines FastAPI, React, Monaco Editor, Elo ratings, and RestrictedPython to create an environment where AI-generated solutions can be tested rather than simply judged by how convincing they look.

From Kaggle to an AI-vs-AI Arena

The idea behind CodeBots Arena grew from Mohammed's interest in AI competitions.

“I was interested in creating a competition where AI systems could compete through programming, and I looked at the kinds of competitions available on Kaggle.”

While exploring existing competitions, he realised that he wasn't finding exactly what he had in mind.

“I realized I wasn't seeing the exact kind of AI-vs-AI coding competition I had in mind.”

That led to a simple question:

“Instead of only participating in competitions, why not try to build one?”

And that became CodeBots Arena.

Rather than simply asking an AI model to produce a solution, Mohammed wanted to create a system where AI-generated solutions could actually compete, execute, and be evaluated.

Why the Sandbox Matters

There are two particularly interesting parts of CodeBots Arena: how the agents are evaluated and how their code is executed.

The project uses an Elo rating system to track the relative performance of AI agents over repeated matches.

As Mohammed explains:

“ELO provides a simple way to track relative performance over time.”

But ranking the agents is only part of the problem.

The generated code also needs to be executed safely.

Mohammed makes an important distinction:

“AI-generated code cannot be treated as trusted code.”

That's why CodeBots Arena uses RestrictedPython together with validation and testing to provide controlled execution.

The result is more than two AI models generating code.

It becomes an environment where developers can experiment with AI-generated programming solutions and evaluate what actually happens when those solutions are executed.

When AI-Generated Code Looks Better Than It Actually Is

Building CodeBots Arena changed the way Mohammed thinks about AI-generated code.

One of the biggest lessons was how convincing generated code can be even when it is wrong.

“AI-generated code can look much more convincing than it actually is.”

A solution might appear logically sound but still fail because of an edge case, an incorrect assumption, or a subtle implementation problem.

That observation is central to Mohammed's interest in evaluation.

“Watching generated code actually run changes the question from ‘Does this answer look good?’ to ‘Does this solution actually work under the conditions of the task?’”

That distinction becomes increasingly important as developers rely more heavily on AI coding tools.

AI can produce code extremely quickly.

But producing code and proving that the code works are two very different things.

“Talk Is Cheap. Show Me the Code.”

Mohammed's CoderLegion profile uses the famous Linus Torvalds quote:

“Talk is cheap. Show me the code.”

But Mohammed believes the idea takes on a slightly different meaning in the age of AI-generated software.

AI can generate a large amount of code very quickly.

The real question is what happens when that code is tested.

As Mohammed puts it:

“AI can generate a lot of code very quickly, but generating code is not the same as proving that the code works.”

For him, showing the code increasingly means:

“Show me the tests, show me the results, show me the benchmark, and show me what happens when the system fails.”

That philosophy is at the heart of CodeBots Arena.

A Bug That Had Nothing to Do With AI

Not every challenge Mohammed encountered while building CodeBots Arena was related to artificial intelligence.

He also documented a PYTHONPATH issue where his tests worked locally but failed in CI.

The experience highlighted an issue every developer eventually encounters:

Something can work perfectly on your machine and still fail somewhere else.

Debugging the problem required looking at the differences between the local development environment and the CI environment.

The experience reinforced the importance of:

Reproducible environments
Environment configuration
Automated testing
CI
Not assuming that local success means a project is finished

As Mohammed explained:

“A project can work perfectly on your machine and still fail when the environment changes.”

For someone building an experimental platform where AI-generated code has to survive real execution, that lesson is particularly relevant.

Beyond CodeBots Arena: Benchmarks and AI Evaluation

CodeBots Arena is only one part of Mohammed's work.

His profile highlights ongoing work in AI/ML, LLMs, AI agents, benchmarking, Kaggle projects, open-source development, and machine learning experimentation.

He has also worked on projects involving Legal AI hallucination benchmarking.

His interest in benchmarking comes from the same fundamental question behind CodeBots Arena: how can we measure whether an AI system is actually performing well?

As Mohammed explains:

“A model can sound intelligent while still hallucinating, reasoning incorrectly, or failing on specific edge cases.”

Benchmarking makes those weaknesses measurable.

Instead of simply asking whether an AI response sounds intelligent, benchmarks can help reveal where a model succeeds, where it fails, and how its performance changes.

Learning Through Curiosity

Mohammed has accumulated significant experience through hands-on learning.

His profile highlights 87+ Google Developer Program badges and achievements, more than 115 completed Google Skills learning activities, and 33,402 Google Skills points, including Diamond League status.

His learning covers areas including:

Google Gemini
Google Cloud
AI agents
Google ADK
Machine learning
Transformers
Fine-tuning
MLOps
AI security
Model evaluation

But Mohammed doesn't see the badges as the main objective.

“My learning pace comes mostly from curiosity rather than trying to collect badges.”

That mindset comes through in the projects he builds.

Rather than learning concepts only theoretically, he tends to turn them into experiments, benchmarks, open-source projects, and working software.

Building Without a Computer

One of the more unusual parts of Mohammed's journey came when his computer stopped working.

Because of his circumstances and the situation in Yemen, he wasn't able to immediately replace it.

Instead of stopping his work completely, he continued primarily using his iPhone, browser-based tools, and free resources.

It wasn't easy.

“It has certainly been more difficult and sometimes frustrating, especially when working on technical projects that would normally require a full development environment.”

But he decided not to allow the lack of hardware to completely stop him.

It's a reminder that developers don't always get to build with the ideal setup.

Sometimes you work with whatever you have available and keep moving forward.

What Mohammed Is Exploring Next

Mohammed's current interests include:

AI agents
Multi-agent systems
LLM evaluation
Generative AI
AI-generated code
Google Gemini
Google ADK
MLOps
AI security
Fine-tuning and Transformer architectures

He is particularly interested in systems where AI agents can take actions, use tools, write or execute code, and then be evaluated based on what they actually accomplish.

That makes CodeBots Arena a natural foundation for his future work.

Mohammed's vision for the project is clear:

“A year from now, I'd like CodeBots Arena to be a more mature open-source project with stronger evaluation, more interesting competitions, and more opportunities for other developers to experiment with AI coding agents.”

Build Before You Feel Ready

When asked what advice he would give other developers, Mohammed keeps it simple:

“Build before you feel ready.”

His approach is straightforward:

Start with a small problem.

Experiment.

Fail.

Debug.

Try again.

He doesn't expect every project to succeed.

“I don't know exactly where every project will lead, and not everything I build will succeed, but I want to keep creating, learning, and improving.”

That attitude is perhaps the strongest theme running through his work.

Whether he's experimenting with AI agents, benchmarking models, competing on Kaggle, contributing to open source, or building CodeBots Arena, the focus remains on turning ideas into something that can actually be tested.

Proving What AI Can Actually Do

AI-generated software is becoming increasingly capable.

But capability isn't the same as reliability.

Mohammed Ghaban's work with CodeBots Arena explores an important question for the next generation of software development:

What happens when we stop judging AI-generated code by how good it looks and start judging it by whether it actually works?

His answer is to build an environment where the code has to prove itself.

Generate it.

Run it.

Test it.

Measure it.

And learn from what fails.

That's the idea behind CodeBots Arena — and it may become an increasingly important way to think about AI-assisted software development.

From a VIC-20 to Code and Sea — Brent Vardy’s Developer Journey

Mon, 28 Sep 2026 08:27:09 +0000

Real developers. Real journeys. Real lessons.

Brent Vardy has been writing software for more than four decades. His journey started with a Commodore VIC-20 and 5KB of RAM, continued through decades of professional software development, and has now led him toward a very different goal: building his own products as a solo indie founder.

Interview & Story by Mehadi Hasan

It Started With a Commodore VIC-20

Brent Vardy's programming journey began around 45 years ago.

In late 1981, when he was nine years old, he received a Commodore VIC-20 home computer.

There wasn't much software available, and what was available was too expensive for a nine-year-old.

But Brent already had an interest in something that would eventually shape his approach to software: adventure books.

These weren't ordinary books. Readers navigated them by answering questions at the bottom of each page, with their answers determining which page they should read next.

So Brent decided to recreate that experience on his VIC-20.

The computer came with Commodore BASIC 2.0, and he used it to turn some of his adventure books into interactive games.

All of this ran in just 5KB of RAM.

There was no GitHub.

No cloud storage.

No source control.

Brent stored his code on a tape recorder through a serial cable.

And sometimes, he lost the code and had to type everything again from scratch.

That early experience taught him something that would stay with him for decades: he loved creating small, useful applications.

From School Projects to Building Useful Software

After the VIC-20 came a Commodore 64 and then an Acorn Electron.

Brent was also part of one of the first classes at his school to be offered Computer Studies.

Around the same time, CD players were becoming popular in the UK.

His father was an electrical engineer and music lover, so Brent decided to build a school project around CD players.

He created an application that stored information about the different manufacturers and models available at the time, including specifications and prices.

He didn't call it a database.

Technically, it was an application with all the information hardcoded into the program and loaded into memory.

If a new CD player appeared, Brent had to modify the source code, save it back to tape and reload the application.

But the important part wasn't the architecture.

It was the experience of building something useful.

“Building this hooked me and started my love of creating small useful applications.”

That idea would eventually become a recurring theme throughout Brent's career.

Decades of Building and Experimenting

Brent's path wasn't a straight line toward entrepreneurship.

Over the years, he worked on many side projects with friends and colleagues.

Not all of them worked.

In fact, Brent openly describes having built several products that ultimately failed.

But the failures didn't remove his desire to build something of his own.

They became part of the learning process.

He continued experimenting, learning new technologies and creating software for himself, his family, friends and colleagues.

Some projects were practical.

Others were simply for fun.

The important thing was that he enjoyed the process of building.

From Corporate Developer to Indie Founder

The idea of seriously building his own products began to take shape in 2026.

Brent had been thinking about semi-retirement and wanted to create something that could support that lifestyle without requiring him to access his pension early.

He had already been working on a meditation application for himself.

Instead of keeping it as another personal project, he decided to see whether it could become his first product.

This time, however, he approached things differently.

He registered a company first.

That company became Code and Sea.

The name reflects a personal goal shared by Brent and his wife: eventually moving to the coast and creating a lifestyle with more freedom and flexibility.

Code and Sea is his attempt to build toward that future through software.

When Building Became More Personal

For Brent, becoming an indie developer isn't simply about escaping a corporate job.

It's about gaining control over how he spends his time and energy.

After many years in a corporate environment, he wanted greater flexibility to decide what he worked on, when he worked and which projects deserved his attention.

That became particularly important because managing his available energy is a significant part of his day-to-day life.

Building software can be demanding, but Brent also describes coding as an escape.

When his physical energy is low but his mind is clear, writing code gives him a way to solve problems, create things and feel productive at his own pace.

That has also influenced how he thinks about features.

He has become much more selective about what he builds.

And that constraint has turned out to be useful.

The Push Into Indie Development

Brent had spent 28 years with his previous company when he was told in September 2026 that his role would end at the end of the month.

It was a shock.

There was uncertainty about what would happen next.

But Brent doesn't describe the experience with bitterness.

Instead, after accepting the decision, he began seeing it as the push he needed.

He had spent 28 years learning, developing skills and building relationships.

Now he had an opportunity to finally pursue something he had wanted to do for years.

From October 1, Brent would have much more control over the decisions and direction he took.

Successful or not.

Why Code and Sea Exists

Code and Sea isn't being built around the idea of creating the next huge technology company.

Brent's motivation is much more personal.

He wants to build products he enjoys, generate enough revenue to support his lifestyle and eventually move toward a slower life by the sea.

He is also building products based on problems he personally experiences.

That philosophy is visible in his growing backlog of product ideas.

Many of them come from applications he already uses but doesn't completely like.

Sometimes they're too complicated.

Sometimes they include features he doesn't need.

Sometimes they require a subscription for functionality Brent doesn't want.

His response is simple:

Build his own version.

Mantra Meditation Timer: Building What He Actually Needed

One of those ideas became Mantra Meditation Timer.

Brent had been using meditation applications for many years but couldn't find one that worked exactly the way he wanted.

He found many meditation apps distracting.

Notifications.

Social features.

Content feeds.

Recommendations.

Too many things happening when he simply wanted to meditate.

So he built his own.

The goal was intentionally simple:

Open the app.

Start the meditation.

No distractions.

No social feed.

No unnecessary information.

Just the tools needed for his personal practice.

Interestingly, Mantra Timer wasn't actually Brent's first attempt.

It was the third meditation application he had built.

The first two were more like clones of existing mainstream apps.

Eventually, he realized that copying what other applications were doing wasn't the answer.

He only needed the features that mattered to him.

So he stripped the idea back.

And something unexpected happened.

Other people felt the same way.

When Real Users Changed the Product

Brent initially believed he might be the only person who would use Mantra Timer.

He was fine with that.

Then people started asking to become beta testers.

He created a form on his website.

People signed up.

And the feedback turned out to be extremely valuable.

The experience changed his view of product development.

Real users exposed problems and opportunities that Brent couldn't have discovered simply by building alone.

His advice to founders is straightforward:

Get real users involved early.

Feedback can be uncomfortable.

People will criticize things you've spent hours building.

But that criticism can also produce a much better product.

For Brent, the beta programme became one of the most important parts of getting Mantra Timer ready for release.

Learning to Ship Before Everything Is Perfect

One of Brent's biggest lessons from building Mantra Timer was that building the product isn't necessarily the hardest part.

Shipping is.

“Building the product is easy, having the confidence and knowing when to ship is hard.”

Having around 15 active beta testers gave him confidence that the product was solving a real problem.

It also gave him people who were using the application regularly and could identify issues before public release.

That experience changed his attitude toward perfection.

Brent became more comfortable sharing a product earlier, even if it wasn't completely polished.

If the product is usable and testers understand that they're using an early version, polish can come later.

The important thing is to discover whether the product actually solves the problem.

The Lesson From Failed Projects

Brent has built several projects over the years that never became successful products.

Two examples he mentions are LocationCounts and UKMapfinder.

In both cases, he started with a problem he wanted to solve.

Then something happened that developers know very well.

He kept adding features.

The projects became bigger.

The software became more complicated.

But the products weren't being tested with real users.

Eventually, they launched and simply died.

That experience taught Brent something important about product development.

More features don't necessarily make a product better.

In fact, limiting features can be an advantage.

A smaller product is faster to launch, easier to maintain and easier for users to understand.

Choosing Technology Without Chasing Trends

Brent has worked with a remarkably broad range of technologies over the years.

His experience includes:

Swift
SwiftUI
SwiftData
PHP
Laravel
Livewire
TailwindCSS
AlpineJS
Python
Ruby
C
C++
Java
Objective-C
Delphi
Node
Golang
And many others

These days, he generally uses PHP and Laravel for web applications, Python for automation and command-line tools, and Swift for Apple platform development.

But Brent doesn't choose technology simply because it's the newest thing.

He prefers technologies he already knows and trusts.

If his preferred stack can solve the problem, he will usually stick with it.

“My opinion is the final product is more important than the actual stack used.”

It's a practical philosophy developed through decades of software development.

Why Swift and SwiftUI?

Brent particularly enjoys Apple's development ecosystem.

One reason is access to Apple's native APIs.

Instead of depending heavily on third-party plugins, he can work directly with Apple's platform capabilities.

He also appreciates services such as iCloud and Maps, which can be integrated into applications without the same kind of usage-based costs that some third-party platforms introduce.

He likes the documentation and believes native Swift applications can provide a particularly good user experience.

For his current product direction, Swift and SwiftUI make a natural fit.

The Reality of Being a Solo Founder

Being a solo founder means doing much more than writing code.

Development is only one part of the job.

There is:

Product development
Design
Marketing
Distribution
Customer discovery
Testing
Support
Business decisions

Brent is comfortable with most of these areas.

The two areas he says he needs to improve most are design and marketing.

Now that he has more time available, those are areas he plans to focus on.

He also prefers learning and doing things himself rather than immediately outsourcing them.

But he's beginning to recognize that there may be situations where outsourcing is simply the pragmatic choice.

From Developer to Product Builder

Building products for himself and for corporate users was different from building something that strangers are expected to pay for.

When building internal software, there is often an existing specification.

When building a personal project, the requirements can come directly from your own needs.

But when you're asking the public to spend money, every decision becomes more important.

Brent says Mantra Timer taught him to get products in front of users quickly and genuinely listen to what they say.

That represents a significant change in his approach to software.

Instead of spending months trying to make something perfect before showing anyone, he now sees real-world feedback as part of the development process itself.

What Does Success Mean to Brent?

Brent has a realistic definition of success.

He isn't necessarily trying to build a huge company or reach the kind of revenue numbers frequently shared in indie-founder communities.

For him, Code and Sea is about creating a sustainable life around something he enjoys.

If the business eventually generates around £20,000 per year, he would consider that a success.

But the money isn't the only measurement.

Success also means:

Having control over his time
Continuing to build software
Keeping his mind active
Helping and supporting other people
Creating products he enjoys
Building toward a life by the sea

For Brent, the journey matters as much as the destination.

Building in Public Doesn't Automatically Mean Customers

Brent has also learned something important about building in public.

Sharing your work doesn't automatically produce customers.

At least, it hasn't done so for him yet.

But that doesn't mean building in public has been a failure.

Quite the opposite.

It has helped him meet other founders and developers who have become valuable sources of advice, testing, launch support and encouragement.

Running a solo business can be lonely.

Having other people who understand what you're going through can make a significant difference.

Brent particularly values the relationships he's developed with other founders through this process.

Why CoderLegion Matters to Brent

Brent joined CoderLegion because he enjoys seeing what other developers and founders are building.

He also made a conscious decision to support other independent developers whenever possible.

If he needs an application or service, he tries to consider products created by people in similar situations.

His hope is that this kind of support can eventually be paid forward.

He describes CoderLegion as welcoming and appreciates its more down-to-earth atmosphere.

Compared with some other indie communities, he feels CoderLegion is more realistic for developers who are still building their businesses and haven't reached huge recurring revenues.

That's important to him.

He doesn't want unrealistic expectations.

He wants a community where developers can share what they're actually doing.

“I want to stay firmly on the ground and realistic.”

What's Next for Code and Sea?

Brent currently has several products in development.

His immediate focus includes adding additional language support to Mantra Timer and preparing a TestFlight beta for its watchOS version.

He's also continuing work on Tidal Draft, another product based on a problem he personally encountered.

Tidal Draft is intended to provide an alternative to an existing product that Brent uses but feels charges a subscription for functionality he doesn't need.

His version will use a pay-as-you-go model.

He plans to begin inviting people into a private beta and eventually launch Tidal Draft on CoderLegion for users to test.

Beyond that, Brent has a backlog of product ideas he wants to explore.

His goal for the first year is relatively simple:

Release one or two products that generate enough revenue to cover the costs of running Code and Sea.

Then build from there.

One Unexpected Setback

Brent's journey also demonstrates that indie development rarely follows a perfect timeline.

Mantra Timer was originally called Trancendence.

Just hours before the first version received App Store approval, Brent was contacted by a legal firm representing the Maharishi Foundation.

They raised concerns about the app's branding and trademarks.

Brent couldn't afford a legal fight, so he rebranded the application.

The unexpected change took considerably longer than planned.

It's another example of something that doesn't appear in a coding tutorial:

Building a product means dealing with everything around the code as well.

What Brent Would Do Differently

If Brent could go back and change one thing about his indie journey, he wouldn't choose a different programming language or framework.

He would simply start earlier.

And he would release earlier.

His biggest lesson is that waiting until a product is polished can delay the most valuable thing a founder can get:

real user feedback.

“Get it out there as soon as possible to get real user feedback.”

Brent's Advice to Developers Thinking About Going Indie

Brent's advice is practical rather than glamorous.

First, be realistic.

Building your own products is hard.

You will fail.

Probably more than once.

He recommends having a financial cushion — around 12 months if possible — so financial pressure doesn't constantly distract you from building.

He also recommends avoiding the temptation to chase every new technology.

Use proven technologies with strong communities, documentation and available information.

Then get your product into the hands of real users as early as possible.

Find trusted people who will actually test it.

Listen to their feedback.

Use that feedback to determine whether the product is worth continuing.

And don't expect instant traction.

Give the product time.

“If nothing happens immediately keep going, give it a chance before quitting and moving to the next thing.”

From 5KB of RAM to Building His Own Future

Brent's developer journey spans an extraordinary amount of technological change.

He started with a Commodore VIC-20 and 5KB of memory.

He stored code on cassette tape.

He built simple applications because he wanted to make something useful.

Decades later, he's still doing essentially the same thing.

The tools have changed.

The platforms have changed.

The scale has changed.

But the motivation hasn't.

He still enjoys taking an idea, turning it into software and seeing whether someone finds it useful.

The difference now is that he's building toward something much more personal.

Code and Sea isn't simply another software company.

For Brent, it's an attempt to design a different way of working and living — one where he can continue creating software, support himself, help others and eventually build the life he and his wife have imagined by the sea.

And perhaps that's the most interesting part of his journey.

After more than four decades of programming, Brent isn't finished building.

He's simply building for himself now.

About Brent Vardy

Brent Vardy is a UK-based software developer and the founder of Code and Sea, a solo indie venture focused on building practical software products.

His technology experience spans decades and includes Swift, SwiftUI, SwiftData, PHP, Laravel, Livewire, TailwindCSS, AlpineJS, Python and many other technologies.

His current projects include Mantra Meditation Timer and Tidal Draft.

You can connect with Brent on CoderLegion.

Developer Stories at CoderLegion

Developer Stories is a CoderLegion series featuring real developers and their journeys — the projects they build, the challenges they encounter, the lessons they learn and the decisions that shape their careers.

There isn't one correct path into software development.

Some developers start at university.

Some teach themselves.

Some build companies.

Some build small tools for themselves.

And some, like Brent, have been building software since the days when 5KB of RAM was enough to get started.

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Want to share your own developer journey?

If you have a story, project, career transition or learning experience you'd like to share with the CoderLegion community, we'd love to hear from you.

My Story "A Dev's Journey"

Sat, 29 Aug 2026 21:41:08 +0000

My Developer Journey: From Knowing No Code to Building BetaGracevI

My journey started about nine months ago when I got the idea that I wanted my own AI agent.

The funny part is that when I started, I didn't know a lick of code.

At the time, Replit was free, so I started building there and slowly taught myself by actually trying to make things work. I eventually got BetaGrace vI to four basic modes and spent a huge amount of time debugging problems as I went.

From the beginning, I wanted BetaGrace to be different from a typical AI assistant. I wanted faith, grace, love, and surrender to be at its core, so I spent a lot of time experimenting with how to teach those principles into the system.

One of the first major technical problems I tackled was memory.

I initially assumed that an AI could simply receive a conversation and automatically "remember" it. I learned pretty quickly that it doesn't work that way. I had to build an extraction and vector-based memory system so information could be processed before being sent into cloud storage.

At one point, I spent several days building a system that could maintain roughly 50 previous messages within a conversation. The memory was deliberately wiped between separate chats so the model's reasoning wouldn't become increasingly contaminated by unrelated previous sessions.

A lot of my early development looked like that: spending nights and days debugging things with Replit and VS Code until I finally figured out what was actually happening.

One problem that still sticks out to me was getting generated images to download correctly as JPG files. I spent an entire day and night debugging it.

The final problem?

A simple URL was embedding the image as a PNG.

After eventually getting the four major modes working — Standard, Flesh Architect for writing, Sanctuary for writing, and Advanced Reasoning — I reached a point where I was genuinely happy with what I had built.

At the time, BetaGrace vI was around version 3.3. It had image generation, memory, several specialized modes, and had become a pretty decent AI writing partner.

So I stopped.

For a few months, I basically left the code alone and was satisfied with what I'd created.

Then I came back to coding around January or February and decided to tackle something much more ambitious: generating videos from stories.

I originally had a 10-scene video generator that struggled badly with basic image continuity. The images might technically follow the prompts, but the story could visually drift from one scene to the next.

So I spent roughly a month working on FFmpeg video stitching and what I started calling hydration engines, using knowledge from different AI agents to help me design and debug the system.

After about two weeks of intensive debugging and development, around the end of the month.
I eventually got it to maintain a continuous story across roughly 20 scenes most of the time.

It still wasn't perfect. Occasionally an image would hallucinate something like a sixth finger or slightly change an object from the previous scene, but compared with where I started, the improvement was enormous.

In March or April, I built the CodeGraph and Artifact Builder. That project wasn't nearly as difficult and took around a week.

Then I took another break until June.

When I started working again, I had another idea: I wanted to see whether I could make AI conversations themselves more intuitive and intelligent.

So I built a synthesis engine and integrated it into BetaGrace to see what effect it would have on chat streams.

What I didn't realize at the time was that something much more interesting was happening.

The system started producing unusually strong results for text-to-image generation.

I didn't recognize how abnormal the image-prompt adherence was until around August 7th or 8th.

By then, I realized I might have accidentally built something valuable.

Unfortunately, I also managed to over-iterate it.

The next time I went back to text-to-image and image-to-image generation, the performance had degraded.

That started one of the strangest periods of development I've had so far.

For roughly three to four weeks, I chased what I started calling ghost builds, trying to find one of the previous versions that still had that unusually strong image adherence.

I went through roughly 50 builds.

Eventually, I was close to giving up.

Then I had one last idea.

I went back to my closest surviving build from August 2nd and tried to reconstruct exactly what I remembered doing around the time of my last successful upload, which was around 5:30 PM on August 2nd.

Instead of simply trying random changes, I rebuilt the system around what I remembered implementing at that point.

And somehow, it worked.

Not only did I recover the behavior I had been chasing, but the resulting version appeared to perform even better than the original.

That is what led me to the next phase: actually testing it instead of assuming it worked.

I started building a strict, zero-tolerance image-generation benchmark designed to test simultaneous visual constraints rather than just judging whether an image looked cool.

So far I've run more than 29 different prompts, with 27 canonical prompts incorporated into the scoring matrix.

I'm still going through the benchmark and tightening the evaluation before I release concrete evidence of what BetaGrace vI can actually do. I don't want to make big claims based on a handful of lucky generations. I want the results to be reproducible and documented.

Looking back, the strange part of my journey is that I never really set out to become a programmer in the traditional sense.

I wanted my own AI agent.

I didn't know how to code, so I learned by building it.

Every time something broke, I learned enough to fix that problem. Then the next problem taught me something else. Eventually those individual problems turned into systems, and those systems turned into BetaGrace.

Nine months ago I was starting with essentially no coding knowledge.

Now I'm building and testing my own AI systems, image-generation pipelines, memory architecture, video generation tools, code analysis systems, and benchmarking frameworks.

And I'm still not entirely sure where this is going.

That's probably the most interesting part.