Why AI Won't Take Your Job

It will take something much more precious

Over the last 6 months, I built five personal projects from scratch — all running fully-functional, spanning a wide variety of domains:

1. kissidougou.com: a fully automated AI news platform
2. Locus: Yet another trading app
3. Syntropy: the quest for a "free-lunch" strategy for retail trading.
4. Sayphonics.com: edtech boosted by AI.
5. A SaaS dedicated to request routing (I will reveal when the time is right)

It was right after finishing the first two apps, using Claude for a significant portion of the architecture, boilerplate, refactoring, and debugging, that I started to realize a disturbing pattern: the more I relied on the agents, the less I actually understood the underlying architecture whenever a subtle bug finally surfaced.

The point of this post isn't to flex about the volume of code shipped, but to share what this immersion made me realize.

First, my learning method relies heavily on hands-on practice. Knowing how you learn is critical— something Peter Drucker emphasizes profoundly in Managing Oneself. Learning by doing isn't just my personal preference, it is how we fundamentally acquire competence in tech. As research by Raymond Lister et al. highlights, true technical mastery stems from the active mental effort of tracing logic and resolving errors rather than passive code generation.

Yet, velocity came at a cost. Every time I asked the AI to refactor a module or fix a failing test, I felt a pang of detachment. I was shipping code, but was I actually growing?

Looking at how we build software today, a darker reality sets in.

We've heard endless warnings about the financialization of the economy: how instead of the economy working for humans, humans ended up working for the economy. AI threatens to be worse: we risk ending up working for the AI, reduced to clicking buttons and validating prompts. That's already the invisible reality for annotators in data centers, labeling datasets at scale without ever seeing or understanding the global architecture.

For developers, the trap is uniquely insidious. Our core competence was always forged in friction: wrestling with an obscure bug, digging through documentation for hours, and finally understanding why the application behaves a certain way.

Prompt-driven development strips away that friction. It pre-chews the work, generates massive blocks of code, and fixes errors on the fly. On paper, velocity explodes. But cognitively, it starves our learning process. As both Cognitive Load Theory (John Sweller) and research on "Desirable Difficulties" (Robert Bjork) show, removing that friction creates a dangerous illusion of immediate performance while stalling true retention and long-term learning.

If you outsource everything to an AI just to move faster, you aren't leveling up - you're outsourcing your growth. At this rate, the risk is waking up 3 to 5 years from now at the exact same technical level, or worse.

That was my ultimate discovery through this 6-month immersion: AI will not replace us. It will incapacitate us.

Changing the Game: From Project 3 Onward

Realizing this trap mid-way through my journey changed everything. By the time I moved to projects 3, I completely overhauled how I used AI. Instead of letting the model dictate the architecture, I took strict control of the workflow:

• Enforcing my own libraries and style: I forced the AI to reuse libraries and modules I had already built previously, feeding it sample projects and test-writing styles so the agent could deeply imbibe my architectural DNA rather than generating generic boilerplate.
• Planning down to the class names: Before unleashing any agentic mode, I mapped out the entire blueprint clearly in writing down to explicit class names and data flows.
• The Junior-Dev Review: I treat every AI-generated code block like a pull request from a junior developer. I don't just copy-paste; I review, refactor, and rewrite it manually if I can't fully explain what every line does.

It's slower. It's undeniably less "productive" in the short-term metric of lines shipped per hour. But it ensures I'm paying my cognitive dues, and that six months from now, I won't be the same developer I am today.

I'm curious about your experience. How do you manage this balance day-to-day to avoid letting the tool do the thinking, and the unlearning, for you?