I Tried Coding With Only AI for Two Weeks

I Tried Coding With Only AI for Two Weeks

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.

Quick Answer

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%."

Week one: the honeymoon

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.

Photo by cottonbro studio on Pexels

Week two: the wall

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.

What it was genuinely great at

Let me be fair, because the good was very good:

• Boilerplate and scaffolding. Unbeatable. Don't write this by hand anymore.
• Explaining unfamiliar code. "What does this regex do?" — instant, accurate, patient.
• Translating between languages or frameworks. Solid.
• Writing tests for code I described clearly. Big time-saver.
• Rubber-ducking. Even when its answer was wrong, articulating the problem helped me.

For these, I'm never going back. This is real productivity, not a demo trick.

What it was quietly bad at

And the parts that made me nervous:

• Whole-system reasoning. It can't truly hold your architecture in mind. It guesses locally.
• Judgment calls. "Should this be one service or two?" It'll answer confidently and arbitrarily.
• Subtle correctness. Code that looks right and is 95% right — the worst kind, because you trust it.
• Knowing what it doesn't know. It never says "I'm not sure." It should, constantly.
• Novel problems. Anything genuinely new, off the well-trodden path, exposed the limits fast.

Photo by Tima Miroshnichenko on Pexels

The verdict after 14 days

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.

How I actually code now

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.

The skill that quietly became most valuable

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.

What I'd tell someone starting today

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.

The bottom line

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?

Key Takeaways

• AI coding tools excel at boilerplate, scaffolding, and well-documented patterns—use them to eliminate repetitive work, but never skip reviewing the output line-by-line.
• For cross-file features, architectural decisions, or novel problems, AI produces subtly wrong code that’s harder to debug than writing it manually—take the wheel for these 30%.
• The biggest risk isn’t AI failing obviously; it’s confidently generating 95% correct code that slips through unnoticed—treat its output as a first draft, not a finished product.
• Judgment, not code production, is now the core skill: prioritize deep system understanding and critical review over raw output speed to catch AI’s quiet mistakes.
• Force yourself to explain why AI-generated code works—if you can’t, you’re borrowing answers you can’t defend when they break, not learning.
• The optimal workflow is 70% AI for routine tasks, 30% human for load-bearing or complex work—this balance, not extremes, delivers real productivity gains.