From Delivery Rider to Building My First AI System — Here's My Story

Hi everyone, I'm a self-taught developer from China. I work as a delivery rider from 8 PM to 8 AM, and I code in every spare moment between shifts.

In June 2025, I finished a shift, lay down in bed, and started scrolling through videos. I came across a course on AI Agents. The structure was: receive input → call tools → output → memory. And a question popped into my head:

"Why can't we have two AI brains talking to each other, cross-validating information?"

A whole string of ideas followed. And I had this strange feeling — I don't know why, but it felt like this was what I was supposed to do with my life.

I didn't know how to write a single line of code back then. But the thought never went away.

On May 24, 2026, I decided to start learning to code. I'm a delivery rider — I work from 8 PM to 8 AM, and I have about 4 hours a day for self-study. So I started building. Two weeks later, I had a working MVP:

Multi-expert parallel execution: simultaneously calling medical and legal "expert brains" (powered by LLM APIs) using ThreadPoolExecutor

Safety brain: input + output filtering, with black/whitelist loaded from an external JSON and separate violation logs

Memory module: persistent conversation history (JSON), keeping the last 20 turns, with support for "recall what we talked about last time"

Director brain: aggregates responses from multiple experts into a clear, user-friendly final answer

Engineering habits: environment variable management, modular design (dispatcher/summarizer/memory/safe/safety_logger), requirements.txt, etc.

This sketch was drawn after the MVP was running, to map out the next steps. At that point, I had three main directions in mind: implementing true multi-brain dialogue through the memory module; optimizing the director brain (layered routing, value system, aggregation logic); and evolving the safety brain from static filtering toward "ground-level safety."

Today, my MVP has these capabilities:

Multiple experts (medical, legal, strategy) running in parallel, each powered by a different API — Zhipu, Aliyun, and OpenRouter (which gives flexible access to multiple models through a single gateway)

Multi-round debate — they can agree, disagree, or supplement each other, all within a shared memory framework

Memory — it remembers the last 20 turns, so context carries over

Safety — input and output filtering with violation logs (there's still a substring-matching false-positive issue, but it doesn't affect the core value of the MVP, so I'm leaving it for now)

A brief note on how it works:

When a user asks a question, the system matches keywords against available experts, with a general expert as fallback. If multiple experts are triggered, the system initiates a multi-brain dialogue — it creates an independent history log that records each round of discussion, and passes that log as context to every expert in subsequent rounds. Each expert sees the full discussion thread, not just the other side's last response. This allows them to build on or push back against each other's arguments, rather than answering in isolation. Finally, the director brain aggregates everything into a single output.

This approach does consume more tokens than a standard setup, but I already have some ideas for optimization. For now, I'm focused on getting the core functionality right.

Test case:

"I have a cold. I can't understand the medication instructions from the doctor, and my company won't approve my sick leave. What should I do?"

This triggers all four experts at once (medical, law, strategy, and the general expert as fallback). Each expert sees the full conversation history from previous rounds, so they can build on each other's arguments or push back where they disagree.

It's far from perfect. The director brain's output is still just simple concatenation. Response speed is slow. The timeout logic hasn't been refined yet. All of these need work. But the core functionality works — the rest is just time.

The code is here: https://github.com/ammorick/ai-learning-journey

I also keep a "Museum of Ideas" — a separate repo where I capture the bigger, longer-term directions I'm not ready to build yet: multi-brain dialogue, AI that helps design new AI brains, safety as the underlying "ground" instead of a fence around the system. Some of these may take years. Some may never happen. But they're my starting point, and they're my North Star.

https://github.com/ammorick/Future-exploration-direction.to-be-sorted

It's not polished. It's still rough around the edges. But it runs, and I'm iterating on it every day.

I've written a couple of articles about this journey — in Chinese for now, but the code and the process are universal:

From Single Expert to Multi-Expert Debate — a technical recap of the core mechanism

Night-Shift Delivery Rider, Coding in Spare Time — the origin story and overall architecture

While testing, I realized something: to an end user, this system probably looks just like any other Q&A bot — even though the underlying logic has completely changed.

But I'm not worried about that right now. As a developer, my energy should go into the technology itself: improving my skills, sharpening my judgment, and refining the system architecture. User feedback matters — but that's for a different stage. Right now, presenting the project as a work-in-progress is itself a form of demonstration. What people who know this space will see is the thinking process and the judgment behind it, not just the final output.

I don't know if what I'm building will ever be "good enough" for the market. But at least it's already proof of some of my capabilities — and that certainty alone might open other doors further down the road.

To be honest, I don't have many people in my circle who work in this space, and it's hard to find others in a similar situation online. Most of the time, I'm learning and building on my own. And I often ask myself: Am I doing this right? Is my progress on track? What does the industry actually need? That kind of uncertainty can be more draining than the technical challenges themselves. But I keep going — because I choose to trust myself.

One thing I always keep in mind: there is no tomorrow without today. Only by putting in the work every single day can a real tomorrow arrive. I'll keep building this project — unless it gets crushed by the wheel of history.

I'm new to this field, and my fundamentals are still weak — I'm working on them. So I'm here to share my progress, and also to learn. If you've been through something similar, I'd love to hear how you navigated it.

One question I'd like to ask:

For Python fundamentals, I've been learning on the go — picking up whatever I need for the project. I used to spend about 30 minutes a day on practice exercises, and recently I've switched to a weekly schedule: MVP development on Mon/Tue/Wed, fundamentals practice on Thu/Fri/Sat, and reviews plus writing on Sundays. Does this rhythm make sense? Any advice on how to improve more effectively?

Also:
I'd love to hear your thoughts — what would you add to a system like this?

Thanks for reading.

P.S. I spent quite a while trying to include two images in this post — a sketch of my early design and a terminal screenshot of the test case running — but neither of them would display properly after upload. I've tried different formats, compression, and even external hosting like Imgur, but nothing seems to work. If you've run into this issue before and know how to fix it, I'd really appreciate any advice. Thanks!