Someone filmed their computer screen with their phone yesterday. Not a screen recorder. Their actual phone, pointed at a monitor.
The reel said: "Here's how I'm making 70k a month with AI tools. Do this, copy this here, paste it there et voilà. DM me script and I'll send you the code."
It had 1M views. What they called "code" was a JSON file with a bunch of text, and that's how they position themselves as experts, because 99% of people will believe it's actual code since there's curly braces in there.
These are the same people who sold e-com courses two years ago, and crypto courses before that. Now they're AI experts. They've never opened a terminal, never had a PR rejected, never been on a 2 AM incident call wondering if their code just cost the company six figures.
But they're telling you how to use AI.
I use Claude Code 10 hours a day to ship production code at a company that handles traffic for millions of users. Real money, real merchants, real transactions. And the stuff I see "AI experts" teach online makes me want to throw my laptop out the window.
Let me tell you what it actually looks like.
The "Prompt-Ship" Delusion
Here's how most engineers use AI tools right now: they paste some code, write a vague prompt, get output, skim it, and ship it.
I know because I did the same thing.
Early on, I had a query where I only needed one column from another table. I'd always used joins and never really considered subqueries, but I was curious to know if one would fit this use case better. We have AI now, might as well leverage it. ChatGPT told me to go with the subquery, and I trusted it.
That subquery scanned an absurd number of rows and nearly exhausted our database resources.
The AI didn't have context. It didn't know the table size, the indexes, or the query patterns. It gave me a textbook answer to a production problem, and I accepted it because I was lazy about the input.
Another time, I used AI to generate a technical doc. I wrote a small paragraph as a prompt, thought it was enough, skimmed the output, and shared it with my team.
Then the questions came in. "Why did you choose this approach?" "What's the reasoning behind this section?"
I couldn't answer, because it wasn't mine. I hadn't thought through any of it. I'd outsourced the thinking and got caught.
That was the last time I ever shared something I hadn't iterated on.
Here's what I learned from both of those moments: AI works exactly like the models it's built on. Good input, good output. Garbage in, garbage out. If you're too lazy to provide meaningful context, the AI will give you confident-sounding garbage, and you won't catch it because you didn't think through the problem yourself.
This is the thing nobody talks about: the real risk of AI isn't that it replaces you. It's that it makes you atrophy. You stop thinking through decisions because the agent did it for you, and then someone asks "why?" and you've got nothing.
What AI-Assisted Engineering Actually Looks Like
Let me walk you through what I did last week.
I built a merchant management API. I'm not talking about a demo or a vibe coded app with 10 users here. This is a production system that handles real payment configurations.
Step 1: The design doc.
Before I touched Claude Code, I wrote a technical design document. I explored two options: Option A was a single PUT endpoint following upsert semantics, idempotent by design but overloaded, meaning an empty array on the settlements property would delete all settlement configs. Option B was explicit routes with separate endpoints for creating and updating settlement configurations, using POST with an idempotency key header.
I spent about an hour iterating on this doc with Claude Code, with the whole codebase in context. Not asking it to "write a design doc for me." I was iterating, challenging assumptions, and exploring trade-offs with it.
Then I shared it with the team. We had a meeting and aligned on Option B.
Step 2: The plan.
I converted that Notion doc into a markdown file and committed it to the repo. Then I used Claude Code's plan mode. I'm not talking about the default plan it generates in this scenario, but rather a thorough implementation plan I iterated on as a markdown document.
This plan is specific. It contains code snippets, database migrations, the exact order PRs will be created, and a testing and validation strategy. It's split into phases, some sequential and others running in parallel.
My first PR was just the plan file. My peers reviewed the plan itself, and we caught issues early (things like how we'd handle merchant IDs) before a single line of implementation code was written.
Step 3: Phased implementation.
I used worktrees for parallelization. Each PR was small and digestible, and this is key. AI-generated code tends to produce massive PRs, so we've deliberately worked against that. Multiple small PRs mean each one gets real attention, better tests, and higher quality. The agent has clear context for each phase instead of juggling everything at once.
Step 4: Multi-layered review.
I'm the first reviewer of my own work. I ask Claude Code questions about why something was implemented a certain way, ask it to review pieces from an SRE perspective, and check if there are gaps in testing or if we could reuse an existing function. I have a back-and-forth discussion and push improvements before anyone else sees the code.
Then the team review kicks in. We use a custom code-review skill that spins up three sub-agents, each focused on different aspects. Engineers on the team use different models so reviews catch different things. There's a GitHub Action that runs Claude Code automatically on every PR, a code style review skill, and there's still a manual QA step.
The result? A few days instead of two weeks, with higher quality, better test coverage, and a team that actually understood what was built because they reviewed the plan before the code.
Front-Load the Hard Work
The pattern behind everything I just described is simple: front-load the effort.
I spend hours on the design doc and the plan. Most engineers skip that and jump straight to "Claude, build me a merchant API." They get a massive PR, a teammate gives it an LGTM because it's too big to actually review, and they ship bugs to production.
My approach is the opposite. By the time I'm implementing, the hard thinking is done. The plan is reviewed and the phases are clear. Implementation becomes almost mechanical, and that's exactly when AI is at its best. It's executing decisions you already made, and that's where it shines.
This maps to something fundamental about how these models work. They're trained on data, and the quality of the output is directly proportional to the quality of the input. When I give Claude Code a detailed plan with code snippets, specific migration steps, and clear acceptance criteria, it performs incredibly. When someone gives it "build me an API," it hallucinates confidently and you end up debugging AI decisions at 2 AM.
There's no magic. Like everything in life, when you provide the best effort you get the best results.
The same people bragging about "I built this app in 20 minutes with AI" are the ones quietly rewriting it from scratch two weeks later. Or worse, they shipped it and their users found the bugs for them.
How to Actually Start
If you're using Claude Code right now (or thinking about starting), here's what I'd do:
- Pick Claude Code and commit to it. Stop mid-curving between tools. Get familiar with one, learn the commands, learn worktrees, learn skills. Build the muscle.
- Write the brief before you prompt. Before you ask the agent anything, write 3 sentences: what you want, what the constraints are, and what "done" looks like. That's the difference between useful output and slop.
- Never share something you can't defend. If someone asks "why did you do it this way?" and you can't answer, you shipped too early. Iterate on AI output until you own every decision in it.
- Break big work into phases. Don't let AI generate a 2000-line PR. Write a plan, split it into phases, and create small digestible PRs. Your reviewers will thank you, and your production systems will thank you more.
- Review your own work first. Before you push, ask the agent to challenge what it built. Ask it to review from an SRE perspective, ask about test coverage gaps. Have the conversation before your team does.
- Front-load the thinking. Design doc first, plan second, implementation third. The boring up-front work is what makes the downstream execution fast and reliable.
The engineers who get this right are compounding their advantage every single day. New concepts are being introduced constantly: skills, harnesses, worktrees, multi-agent workflows. This isn't something you can "catch up on later." The gap is forming now.
You're either building the muscle today, or you're falling behind.
Start with step 2 this week. One task, one brief. See what happens when you give AI your best input instead of your laziest.