'It Feels Like Cheating': What Actually Matters in the Age of AI Coding

Andrej Karpathy recently posted something that sparked a wide discussion:

“It feels like I’m cheating. Which is a very weird feeling to have. It’s because some code that used to be a point of pride and high IQ and knowledge is suddenly free and instant and it’s very disorienting.”

— Andrej Karpathy

He’s talking about coding with LLMs. The core observation: writing code is shifting from a scarce skill to infrastructure. The “cheating” feeling comes from watching something that used to take expertise and effort become nearly free.

This post collects the key ideas from the discussion around Karpathy’s tweet and tries to answer one question: when code itself isn’t scarce, what is?

1) LLMs are like junior engineers: strong execution, weak judgment

Karpathy offered a precise analogy:

“The nearest neighbor really is some kind of a junior engineer. Its ideas about what experiments to run have been surprisingly bad, but its execution on ideas I’ve given it have been surprisingly good.”

This runs counter to many people’s intuition. The common assumption is that AI is best at “coming up with solutions,” but its most reliable strength is “you tell it what to do, and it does it quickly and well.”

The implications:

• Direction-setting is still human work. Which tech stack, which experiments, which problem to solve first — LLMs don’t give reliable answers here.
• Execution cost is compressed to near zero. The gap between “knowing what to build” and “having runnable code” has collapsed.
• The bottleneck shifts from “can you write it” to “can you judge it.” You need to quickly assess whether AI-generated code is correct, safe, and maintainable.

2) The 10X engineer becomes a 100X engineer

Yuchen Jin raised an interesting point:

“10X engineer becomes 100X engineer, simply because they can verify the AI results and they are the best at catching up with all the progress of models/tools.”

This isn’t rhetoric. The logic:

1. AI raises everyone’s code output velocity.
2. But output quality depends on verification ability — can you quickly judge whether the output is correct, secure, and maintainable?
3. The original 10X engineers have the biggest advantage in verification: they have enough knowledge to catch edge cases, performance traps, and security holes.
4. They also learn new tools faster, so the gap doesn’t shrink — it widens.

For junior engineers, this doesn’t mean “stop learning to code.” It means adjusting where to focus:

• Reading code matters more than writing code.
• Understanding system behavior matters more than memorizing syntax.
• Building verification loops (tests, type checks, code review) is more valuable than raw coding speed.

3) Specialist vs. generalist? That’s no longer the axis

Daniel Miessler cut to a deeper level:

“Specialist or generalist isn’t really the axis anymore I don’t think. It’s how much you want to make.”

When execution cost approaches zero, “what you know” becomes less important than “what you want to build.” A person with a strong desire to create, armed with AI tools, can produce what used to require an entire team.

This aligns with what we see in Claude Code for Designers: designers don’t need to master programming syntax — they need to articulate what they want, judge whether the result is good, and iterate until it ships.

The moat isn’t “frontend vs. backend” or “fluent in 5 languages.” It’s:

• What you want to build: the more specific and unique your goal, the more AI can help.
• Your standard for “good”: knowing what good UX, good architecture, and good security boundaries look like — AI can’t do this yet.
• Your willingness to push through: between idea and launch there’s a lot of unglamorous work (deployment, debugging, edge cases). People who keep pushing are the ones who ship.

4) What the “cheating” feeling really points to

Karpathy’s discomfort deserves serious attention because it signals a larger shift:

Before: code = proof of skill. Writing an efficient algorithm or an elegant abstraction was itself the value.

Now: code = intermediate artifact. It’s just one step between “idea” and “running product,” and that step’s cost is being compressed by AI.

An 8-year veteran engineer (@0xabi96) called it “by far the most relatable post I’ve read lately” and added, “I almost feel bad about the people who don’t use this.”

This isn’t a discussion about “will AI replace programmers.” It’s about where value shifts to:

5) What this means for Claude Code users

These ideas translate directly into how you use Claude Code:

Verify first, expand later. Don’t ask Claude to write everything at once. Work in steps, verify each one. This beats “write it all, then hunt for bugs.” See Claude Code Best Practices.

Write your constraints explicitly. Claude’s execution is strong, but its direction-setting is weak. Your prompts should include: goal, constraints, acceptance criteria. Missing any of these raises rework probability significantly.

Build reusable context. CLAUDE.md, plan.md, architecture.md — these aren’t ceremony. They’re how you persist and reuse your judgment across sessions.

Treat verification as a core skill to practice. Reading code, writing tests, doing code review, understanding error messages — these skills have higher leverage in the AI era, not lower.

References

• Claude Code best practices: /en/blog/claude-code-best-practices-playbook/
• Claude Code for designers: /en/blog/claude-code-for-designers-from-idea-to-ship/
• Claude Code installation: /en/docs/claude-code/getting-started/installation/