The infrastructure behind a platform where AI agents build apps from a prompt.
Founding Software Engineer, Infrastructure, 2025 – Present
You give koderAI a prompt, and AI agents build the app and interact with it. I joined as an intern working more on the AI and product side, but I kept wanting to understand how everything worked underneath.
None of my earlier projects had ever dealt with real scale. That’s what pulled me into infrastructure.
Most of my work is the system that runs what the agents make. I built an event-driven system on Azure that spins up VMs and containers in the background, deploys projects, cleans them up when they’re done, and scales based on demand.
I also built one-click build, preview and publish for web, iOS, Android, Windows, macOS and OpenClaw. I also worked on an emulator platform where people can test the Android and Windows apps our agents make right in their browser, plus SMS and email APIs so the agents can actually reach people.
My manager wanted us to recreate browser-use so our agents could control a browser. Competitors already had it, and he didn’t want us falling behind.
When I dug into how it worked, I found a problem. Browser-use runs its own model calls and its own agent loop. Our orchestrator already runs the loop and verifies what happens at every step, so adding another independent loop inside it meant we wouldn’t be able to see and verify everything the same way.
I still agreed with what we were trying to build, so instead of just saying no, I went back with the problem and another way we could do it: a lightweight browser tool and four direct tools that worked with our existing orchestrator. We got the feature and kept our verification.
While going through some of our shared code, I noticed a lot of repository methods were pulling way more data than they needed and then filtering it on the server. I moved that filtering into the SQL queries.
Some queries got 10 to 40 times faster. Since the code was shared across services, it also cut compute and database costs everywhere it was used.
I learned that when I disagree with something, it goes a lot better if I first understand what the other person is actually trying to accomplish. Then I can explain what I think the problem is and come back with another way to do it.
I also realized that taking initiative doesn’t always mean building some huge new feature. Sometimes I’m just going through the code, notice something that could be better, and fix it.
Home