I've been writing code for over seven years. So I gave myself a rule that felt slightly insane: for two weeks, I would not type a single line of code by hand. Every line would come from an AI tool. My job was to direct, review, and steer — never to write.
I expected one of two outcomes. Either it would be a magical glimpse of the future, or a frustrating mess that proved AI coding is overhyped.
It was neither. It was both. Here's exactly what happened, day by day in spirit, and what I actually believe now.
Coding with only AI for two weeks made me roughly 40% faster on familiar, well-trodden work and noticeably slower on anything novel or architecturally tricky. The AI is a brilliant junior who has read everything and remembers nothing about your specific system. It excels at boilerplate and known patterns, struggles with judgment and cross-file reasoning, and will confidently produce subtly wrong code. The future isn't "AI writes everything." It's "you stop writing the boring 70%."
The first few days were genuinely thrilling.
Boilerplate evaporated. CRUD endpoints, form validation, config files, test scaffolding — things I'd written a hundred times and resented writing a hundred-and-first — appeared in seconds. I'd describe the shape of what I wanted and the AI produced a solid first version.
This is the part the hype gets right. For the vast, well-documented middle of programming, AI coding tools are a legitimate force multiplier. The patterns are common, the AI has seen them ten million times, and it reproduces them faster than I can type. The Stack Overflow Developer Survey has tracked this shift, with a large majority of developers now using or planning to use these tools precisely for the routine work they once resented.
By day four I was moving fast and feeling smug. This was the future. Why had I ever doubted it.
Then I hit a feature that wasn't boilerplate. It touched four files, had real edge cases, and required understanding a quirk in our existing architecture.
The AI fell apart.
Not dramatically — that would've been easier. It fell apart quietly. It produced code that looked right, compiled, and was subtly wrong because it didn't understand the wider system. It couldn't hold the whole architecture in its head. It fixed one thing and broke another. It hallucinated a function from a library that didn't exist in our version.
I spent more time debugging its confident mistakes than I'd have spent writing the thing myself.
AI coding is fast at the parts you already find easy and slow at the parts you find hard. Which is exactly backwards from what you'd hope.
That sentence is the whole experiment compressed. The honeymoon was real, and so was the wall.
Let me be fair, because the good was very good:
For these, I'm never going back. This is real productivity, not a demo trick.
And the parts that made me nervous:
Here's how I'd score the two weeks honestly.
| Work type | AI-only result | Verdict |
|---|---|---|
| Boilerplate / CRUD | Much faster | Keep doing this |
| Familiar patterns | Faster | Keep doing this |
| Cross-file features | Slower, error-prone | Take the wheel |
| Architecture decisions | Unreliable | Yours alone |
| Learning / explaining | Excellent | Underrated win |
The takeaway that surprised me: the experiment was most dangerous when it was going well. The smooth, fast, confident output is exactly when you stop reading carefully — and that's when the subtle bug slips in.
Pure vibe coding works great until the moment it doesn't, and by then you've stopped paying attention.
I didn't stay AI-only. That was always an experiment, not a plan. But I didn't go back to manual either.
Now I let AI write the 70% that's routine, and I take the wheel for the 30% that's hard or load-bearing. I read every line it produces — that rule is permanent. And I treat its confidence as meaningless; the code is right because I verified it, not because the AI sounded sure.
That blend, not either extreme, is where the real speed lives. AI for the boring majority. Me for the parts that need a human who actually understands the system.
Two weeks of this changed what I think the core skill of programming even is.
For seven years, my value was largely in my ability to produce code — to translate a problem into correct, working implementation. The AI is now genuinely good at that for the common cases. So the part of my job that's getting more valuable isn't production. It's judgment: knowing what to build, spotting when the confident-looking output is subtly wrong, holding the whole system in my head in a way the AI can't.
Reviewing got promoted from a chore to a core competency. I used to skim my own code. Now reading code critically — is this actually right, does it fit the system, what breaks under load — is the thing standing between me and shipping the AI's quiet mistakes. That shift toward judgment over raw output is exactly the arc I describe in the brutal truth about becoming a senior developer. The engineers who treat review as a formality are the ones who'll get burned by AI tools. The ones who treat it as the main event will thrive.
When anyone can generate code, the rare skill stops being writing it and becomes knowing whether it's right.
If you're earlier in your career and tempted to lean entirely on AI coding tools, here's my honest advice from the two weeks.
Use them heavily — refusing is silly, they're a real productivity gain. But fight hard against the trap of generating code you don't understand. Every time the AI hands you something, especially when it works on the first try, force yourself to answer: do I actually understand why this is correct? If you can't, you haven't learned anything; you've just borrowed an answer you can't defend when it breaks.
The developers who'll be most valuable in a few years aren't the ones who avoided AI or the ones who surrendered to it. They're the ones who used it to go fast and kept building the deep understanding that lets them catch what it gets wrong. Speed plus judgment. The AI brings the speed. You still have to bring the judgment.
If you're trying to build that judgment deliberately rather than by accident, the engineering habit that doubled my output is the practical place I'd start.
Q: Could a non-developer have done this experiment? They could produce code, but they couldn't catch the subtle wrong-ness, which is the entire risk. The experiment worked because I had seven years to know when the AI was lying. That judgment is still the scarce part.
Q: Did your skills get rusty in two weeks? A little — my typing-from-scratch fluency dipped. But my reviewing and directing skills sharpened. The skill that matters is shifting from writing code to judging it.
Q: Is "AI writes all the code" coming? Not soon, in my honest opinion. The boring majority, yes, increasingly. The hard, architectural, judgment-heavy 30% still needs a human who understands the whole system. That gap is real.
Q: Was it worth doing? Completely. Two weeks of forced AI-only coding taught me precisely where the tools shine and where they quietly fail — which is exactly the map you need to use developer tools well instead of being used by them.
Two weeks of coding with only AI taught me this: it's a spectacular junior developer and a dangerous senior one. Let it write the easy majority and you fly. Trust it with the hard parts and you'll spend your savings debugging its confident mistakes.
The skill isn't writing code anymore. It's knowing which lines to hand off and which to keep — and reading every single one before it ships.
So if you've been all-in or all-out on AI coding, maybe the real answer was the boring middle all along. Where's your 70/30 line?
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
One person, output that looks like five. It isn't about working more hours — it's about a kind of leverage teams rarely have.
One idea a week to a published issue in under an hour. The boring system behind a newsletter I never dread sending.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!