I remember writing every line by hand. Here is why that matters now more than ever.
← Back to Blog
December 2024·Opinion·10 min read

I remember writing every line by hand. Here is why that matters now more than ever.

Last week, I watched a junior developer generate an entire authentication system in four minutes using AI. He could not explain how password hashing worked. This is the vibe coding problem, and it is bigger than people think.

The Before Times

I started coding at thirteen. PHP 5, CodeIgniter, raw SQL queries written in phpMyAdmin. There was no AI autocomplete. No GitHub Copilot. No "explain this code" button. You had the official documentation (often poorly written), Stack Overflow (often wrong), and your own brain (often confused).

Every line I wrote, I understood. Not because I was particularly smart, but because I had no choice. If I did not understand it, it did not work. There was no magic box to generate the answer for me.

I remember spending an entire Saturday debugging a MySQL JOIN that returned duplicate rows. I remember the moment I finally understood LEFT vs INNER joins - not from a tutorial, but from staring at the actual data until the pattern emerged. That understanding lives in my bones now, fifteen years later.

I am not nostalgic about those days. They were often frustrating, frequently humbling, and occasionally rage-inducing. But they built something that cannot be shortcutted: deep, intuitive understanding of how things actually work under the hood.

The Vibe Coding Problem

Last week, I was reviewing a pull request from a junior developer on our team. He had implemented a full OAuth2 authentication flow in four minutes flat. The code was clean, well-structured, and followed best practices. I was impressed until I asked a simple question:

"Why did you use bcrypt here instead of argon2?"

Blank stare. He did not know what bcrypt was. He did not know what argon2 was. He had told Claude to "implement secure authentication" and accepted the result.

The code worked. It would pass any automated test. It would survive most security audits. But the developer who wrote it could not debug it if something went wrong at 3 AM in production. He could not make informed decisions about trade-offs because he did not understand the trade-offs existed.

This is vibe coding. Not using AI as a tool - using it as a crutch. Generating code by vibes rather than understanding. And it is creating a generation of developers who can produce code faster than any previous generation but understand it less deeply than any previous generation.

The Illusion of Competence

Here is what makes vibe coding dangerous: it is invisible. A vibe-coded feature looks identical to a deeply-understood feature. The PR passes review. The tests pass. The deployment succeeds. Everything looks fine.

Until it does not. Until you hit an edge case the AI has never seen. Until performance degrades under load and you need to understand the actual algorithmic complexity, not just what the AI told you. Until a security researcher finds a vulnerability in a pattern the AI treated as standard.

I have seen this happen in production. An AI-generated caching layer that seemed perfect until it caused a subtle race condition under concurrent writes. The developer who wrote it could not debug it because he did not understand the caching strategy he was using. He had to rewrite the entire module from scratch.

If he had understood caching fundamentals, the fix would have been three lines.

How I Use AI Today

I want to be clear: I am not anti-AI. I use AI tools every single day. Claude Code for complex implementations. Codex for parallel task execution across multiple worktrees. Custom skills I built for Jira integration, code review, and testing. I even built my own CI/CD orchestrator that automatically validates code before every push.

But I use them differently than a vibe coder. When the AI generates code, I read every line. When it suggests an architecture, I evaluate the trade-offs. When it uses a pattern I do not recognize, I stop and learn it before accepting it.

The difference is not speed. The difference is understanding. I can ask the AI to generate a Redis caching layer because I understand Redis. I know when to use TTL expiry vs. explicit invalidation. I know the difference between cache-aside and write-through. The AI helps me implement faster, not think less.

The Competitive Advantage Nobody Talks About

AI makes everyone faster. But it does not make everyone better. When every developer has access to the same AI tools, speed becomes commoditized. The differentiator is no longer how fast you can generate code - it is how deeply you understand what you have generated.

In five years, I predict the most valuable engineers will not be the ones who prompt the best. They will be the ones who can look at AI-generated code and say: "This is wrong because..." or "This will fail under these conditions because..." or "There is a better approach here because..."

That requires the same thing it has always required: fundamentals. Understanding how databases work. How networks work. How memory works. How humans use software. The stuff you learn by writing every line by hand until the patterns become instinct.

A Note to Junior Developers

If you are starting your career right now, I have one piece of advice that will sound counterintuitive: spend time building things without AI. Not forever. Not exclusively. But regularly.

Build a web server from scratch. Write raw SQL until you dream in JOINs. Implement authentication without a library. Deploy something via SSH instead of a CI pipeline. Feel the pain. Understand the pain. Then let AI help you avoid it.

Because if you cannot write the code yourself, you cannot review what the AI writes for you. That is not gatekeeping. That is engineering.

The engineers who remember writing code by hand will lead the teams that use AI most effectively. Memory is not nostalgia. It is engineering intuition.
Igor Gawrys
Igor Gawrys
AI Engineer & IT Consultant · Katowice, Poland