I Don’t Want to Be an AI Operator

Over the past year, I tried very hard to become employable.
In the process, I stopped becoming better.

Becoming Employable

I optimized for signaling instead of understanding. Coffee chats, cold emails, resume tweaks. Even when I built projects, I built them to look impressive rather than to understand deeply. I cared more about what might get me hired than what might make me a stronger engineer.

The market for junior engineers is rough, and it often feels like the worst possible time to be graduating with a computer science degree. With the rise of AI tools and automation, many companies are scaling back junior hiring. Whether that is shortsighted or not does not change my situation.

Becoming an AI Operator

To move faster, I leaned heavily on AI tools. I prioritized shipping over comprehension. For a senior engineer with years of intuition, that might be fine. For a junior developer who is still building intuition, it is dangerous. If I have never struggled through a system myself, how do I know when the AI is wrong? How do I debug when it confidently produces something incorrect?

At some point, I realized I was drifting toward becoming an AI operator rather than an engineer.

That realization forced a choice. I could continue telling myself that I was improving while quietly outsourcing my understanding, or I could slow down and focus on the craft. Debug manually, even if it takes ten times longer. Write bad code, then slightly less bad code, and learn to recognize the difference.

Back to Building

Right now, I’m building a distributed in-memory database in C with no external dependencies.

I have always been curious about how distributed machines work. Shared state is already difficult inside a single process, whether it is threads stepping on each other or a GPU kernel doing something technically correct but impossible to reason about. The idea that you can solve shared state with machines scattered across the globe feels almost impossible. Which is exactly why I want to understand it.

So I’m going back to building for the right reasons. Not to impress. Not to optimize for speed. Not to generate bullet points. But to understand.

How I’m Using AI Now

I still use AI, but differently: not to write code for me, and not to skip the hard parts. I use it to challenge my plan and to catch bugs after I’ve done the work. The goal is to build real intuition first, so that when I later use more agentic workflows, I am driving the system instead of being carried by it.

This is my notebook. I will document what I build, the mistakes I make, the misconceptions I uncover, and the tradeoffs I learn to navigate. If you are curious how a junior developer thinks through systems in public, you are welcome to follow along.