The First Time My Code Worked

I still remember the first time I wrote code that actually worked. Before that, though, I was just trying to understand English.

When I moved to the U.S. from Bangladesh in 2011, I didn’t speak English fluently. I was eight years old and trying to navigate a new country, a new school system, and a new language all at once. My way in was YouTube. I started watching videos to learn how people talked, including basic grammar lessons, cartoons, and game walkthroughs. One day I clicked on a language video, and when it ended, the algorithm queued up the next one: “Intro to Java Programming”.

I didn’t fully understand the title, but I clicked play anyway and watched it. That video, which was probably made for college students, was where it all started. I didn’t know what Java was, what “object-oriented” meant, or why someone would need a compiler. Still, something about it pulled me in. The mix of logic, structure, and creativity felt familiar, even when the words didn’t.

So I followed along. I paused constantly and Googled every error message. I had no idea what a class or a method was, but I tried to recreate what I saw. Then one day, I typed this:

System.out.println("Hello, world!");

I ran it, and the terminal echoed back exactly what I told it to. It was just a message on a screen, but to me it felt like the first time the machine talked back.

Language, Loops, and Control

In a way, I was learning two languages at the same time: English and code. I didn’t fully understand either one, but I learned both through repetition, trial, and a willingness to look dumb until I didn’t. Coding in particular gave me something powerful, which was instant feedback. I’d type something, run it, break it, fix it, and try again. I didn’t need permission or perfection, just curiosity. Every time something ran the way I intended, I felt a kind of control I didn’t feel anywhere else yet.

Over time, I went deeper, moving from print() statements to calculators, loops, and games. I started watching college lectures from Harvard, even if I only understood fragments of them. I filled in the gaps with forums, tutorials, and constant experimentation. What I lacked in formal instruction, I made up for in iteration. That process of typing, testing, thinking, and retrying became a habit, and eventually it became my way of learning and thinking.

From Feedback to Behavior

Eventually, I stopped asking “did it work?” and started asking “why does it work?” I wanted to know what happens when it doesn’t, whether it could adapt to someone else’s use case, and what breaks in a different environment. Years later, those same questions would shape how I built Kodezi.

Kodezi wasn’t built to autocomplete code or generate fancy snippets. It was built to understand what’s going on beneath the surface, to listen to your codebase, track its behavior over time, and fix issues before you even ask. It’s not just automation. It’s autonomous memory and evolution. In a lot of ways, it learns the way I used to, by watching, failing, adapting, and doing it again.

Same Loop. Bigger System.

The first time my code worked, it printed a message. Now I build systems that help millions of lines of code stay alive by listening to them the way I once learned to listen to a machine. Funny enough, the same platform that helped me learn English also gave me the reason to build a language of my own.