TL;DR
On April 30, 2026, at Sequoia Capital, Andrej Karpathy — former Tesla AI head, founding member of OpenAI, and the person who coined "vibe coding" in February last year — said it out loud:
The code AI writes today is still "awkward, gross, bloaty" with lots of copy-paste and brittle abstractions. Sometimes when he reads it, he gets a "heart attack."
The twist: Karpathy admitted he's hand-coding his own Eureka Labs project, not vibe-coding it. The man who started the trend doesn't use it for serious work.
This isn't drama. It's a signal — for every CTO, tech lead, developer, and business owner hiring a software house. AI coding tools are powerful, but the bar for production work hasn't moved as far as the hype suggests.
This piece covers what Karpathy said, his "intern entities" mental model, the four things humans must own, and how to run AI-assisted coding that actually ships — not just demos.
The man who lit the fire is saying it's not ready
If anyone has the right to talk about vibe coding, it's Karpathy.
He coined the term in February 2025 in a tweet that went viral — "fully give in to the vibes, embrace exponentials, and forget that the code even exists." That single line lit a fire across startups, indie hackers, content creators, and even VCs.
A year later, on April 30, 2026, in a Sequoia Capital interview, he said this:
"It's very bloaty, and there's a lot of copy-paste, and there's awkward abstractions that are brittle."
"Sometimes I get a little bit of a heart attack because it's not like super amazing code necessarily all the time."
Translated: AI-generated code is fat, full of duplication, and built on shaky abstractions. Sometimes it's so bad it scares him.
Why does this matter? Because when the person who started the movement starts hedging, anyone making business decisions on top of that movement should listen carefully.
Who is Karpathy — quick context
For anyone unfamiliar, here's why his words carry weight:
- Founding member of OpenAI — there from the early days
- Former head of AI at Tesla — led the team behind Autopilot
- Briefly returned to OpenAI before founding his own company
- Founded Eureka Labs — an AI-powered education platform
- Coined "Software 3.0" — programming via prompts and context management
He's one of the people closest to AI in the world — as a researcher, builder, and educator.
When this person says "AI isn't ready to work alone yet," it's not the opinion of someone afraid of AI. It's an insider report.
What "Vibe Coding" actually means
Most people get vibe coding wrong.
In the original tweet, Karpathy described his own workflow — write a short prompt, let Cursor + Sonnet generate code, use voice input (SuperWhisper) instead of typing, and "forget" the code exists. Just check whether it runs.
But the term got stretched. It became shorthand for "don't think, don't read the code, just prompt and ship."
That's not what he meant. By April 2025, his own definition had shifted:
"Adopting a certain rhythm in AI-assisted coding... Stuff everything relevant into context."
In AI-assisted coding, you "stuff" everything relevant into context — meticulously. That's the opposite of letting go.
That's the contradiction the industry needs to notice. The phrase "vibe coding" is being used in a way the creator himself didn't intend.
Why Karpathy says AI code is "gross"
Let's break down what he said at Sequoia:
"It's very bloaty"
Bloaty = unnecessarily fat. Code that isn't used. Abstractions you don't need. Layers stacked for no reason.
"There's a lot of copy-paste"
AI tends to duplicate logic instead of extracting functions, because it guesses you don't want it touching existing code. The result: 80%-similar code spread across five places.
"Awkward abstractions that are brittle"
Poorly designed abstractions — fragile, easy to break with one small change. AI builds them from patterns it saw a lot in training data, not from real understanding of the problem.
"Really gross"
In software engineering, "gross" doesn't mean wrong (logically incorrect). It means "smells bad" — like walking into a kitchen, seeing the finished dish, and not wanting to eat it.
"Sometimes I get a little bit of a heart attack"
This is a top AI researcher admitting that reading AI code still shocks him. It's not code he'd happily ship.
The key point — Karpathy said there's "nothing fundamental" preventing AI from writing clean code. The labs just haven't focused on it during model training.
"Intern Entities" — the right mental model
One of the best lines from the interview:
"Right now, the agents are like these intern entities."
AI agent = intern.
Why does this analogy work?
- Interns are good at some things — fast, eager, solid on routine work
- Interns are new to most things — don't know company context, don't know legacy decisions, don't know why things are the way they are
- Interns need mentoring — someone has to teach, review, and explain
- Letting an intern handle critical work alone = disaster
Think about it. If you're a senior dev, would you let a brand-new intern write your payment system and merge it to production without review?
No. The stakes are too high.
But in the vibe coding era, plenty of teams do exactly this with AI every day — let the agent build something important, then ship it without reading it.
The result: production bugs, security holes, performance issues, and massive technical debt.
Karpathy isn't saying AI is bad. He's saying use it correctly — like you'd use an intern. Right scope, right oversight, every time.
Jagged Intelligence — why AI is great at some things, terrible at others
Another key point: AI intelligence is "jagged." Not smooth. Not even across domains.
The same model can be:
- Excellent at writing Python scripts
- Awful at writing Rust
- Excellent at React components
- Awful at debugging memory leaks
- Excellent at boilerplate
- Awful at edge cases that need real thinking
Karpathy gave the example — chess capability spiked between GPT-3.5 and GPT-4 because that round had way more chess data in training.
The implication is important. AI doesn't get "smarter" overall. It gets smarter in dimensions where training data covers more ground.
What about code quality?
Karpathy said it directly — labs haven't made code quality a training target. That's why AI generates code that runs but isn't pretty, isn't clean, isn't maintainable.
This isn't a permanent limitation. It's a prioritization problem.
The funny part: Karpathy himself doesn't vibe-code
Here's the twist Futurism caught — and most people missed.
Karpathy admitted that for his own Eureka Labs project (the AI education startup he founded), he's hand-coding it. Not vibe-coding.
Read that again. The person who coined "vibe coding" doesn't use vibe coding for his own real work.
Why?
Because Eureka Labs is a production system that has to teach actual people. It's not a demo. It's not a prototype. Bugs matter.
His real workflow — go back to the April 2025 tweet — is "AI-assisted coding," not "vibe coding."
The difference:
- Vibe coding = let go, forget the code, watch the output
- AI-assisted coding = AI as a tool, human decides every line, context stuffed meticulously, every change reviewed
This is the lesson nobody wants to print on a billboard — vibe coding is a demo, AI-assisted coding is production.
Anyone using vibe coding for serious work should ask themselves: the person who coined this term doesn't use it for his own work. Why are you?
Four things humans must own (per Karpathy)
In the interview, Karpathy was specific. Humans must "be in charge of the aesthetics, the judgment, the taste, and a little bit of oversight."
Let's go through them.
1. Aesthetics
This isn't just about formatting or indentation.
Aesthetics in Karpathy's sense = code that reads well, has clear structure, and has a flow you can follow.
Why does this matter? Because production code lives 5-10 years. Real people read it, change it, extend it.
AI doesn't know that. It produces code that "works" right now, not code that "reads well in five years."
Humans have to enforce the aesthetic standard.
2. Judgment
Every line has trade-offs:
- Simplicity vs flexibility
- Explicit vs concise
- Abstract now vs abstract later
- Library A vs Library B
- Pattern X vs Pattern Y
AI picks based on what it saw most in training data — which isn't always right for your project.
Humans have to decide which trade-off fits the situation.
3. Taste
Taste = sense of what fits.
Naming conventions that match the team. Patterns consistent with the existing codebase. Idioms the project already uses.
AI generates code that's "correct" but not "right" — like calling a variable userData when the entire codebase uses account_info.
Looks small. Adds up. Codebase becomes a Frankenstein.
4. Oversight
Review code before merge. Every time. Every line.
Test edge cases AI tends to forget:
- Empty input
- Null values
- Extreme numbers (0, -1, MAX_INT)
- Race conditions
- Error paths
Write specs that are clear. Karpathy emphasized "people still need to define the spec and the plan in detail."
Simple rule — bad spec, worse AI code.
Industry impact — five angles
1. Junior developers
Good news — they're not out of work, despite the clickbait. The job changes from "writing code" to "orchestrating AI + reviewing." New skills required: prompt engineering, code review (used to be senior-only), taste and aesthetic sense, writing clear specs. Anyone strong at both coding and AI orchestration becomes very valuable.
2. Senior developers
Seniors who adapt are 3-5x faster on routine work. The time saved goes to system design, architecture decisions, and mentoring juniors plus reviewing the team's AI output. Seniors who don't adapt fall behind newer hires fluent with AI.
3. CTO / Tech lead
New responsibilities: Standards — define and enforce the AI code review process. Budget — vendor cost (Cursor, Claude, OpenAI), token cost, internal tooling. Hiring — new criteria, not just "writes good code" but "judges AI code quality well." Culture — AI = tool, human = decision-maker.
4. Software houses
As a software house ourselves, Enersys sees this shift up close. New services emerging — AI-assisted delivery (faster, but clients must understand the trade-offs), AI code audit (reviewing other teams' AI work), spec-writing services (helping clients write specs AI can actually use). Pricing may shift from hourly to outcome-based because writing code isn't the bottleneck anymore.
5. Education
Karpathy's Eureka Labs is a signal. Programming education is changing. Skills to teach: AI collaboration (not just using AI), prompt design, code judgment, spec writing, systems thinking. Universities still teaching syntax only are teaching skills AI does better.
How to do AI-assisted coding that actually ships
Pulled from Karpathy's points and what our team at Enersys does daily.
1. Spec before prompt
Write intent, constraints, at least 5 edge cases, and success criteria before you prompt. AI without context = AI guessing.
2. Stuff context (Karpathy's method)
Put everything relevant in context: existing code that runs alongside the output, project conventions (naming, patterns), relevant requirement docs, examples of similar code. Context beats prompt cleverness. Always.
3. Review like you mean it
Don't merge AI code without reading it. Every. Single. Line. Ask in every review — how does this work, can I explain it, which edge case did AI forget, any security issue (SQL injection, XSS, leaks), any performance issue (N+1, nested loops), does it break if the requirement shifts slightly.
4. Iterate, don't one-shot
The flow that works: prompt → review → critique → re-prompt → repeat 2-3 rounds. Like teaching an intern. Slow refinement gets you somewhere.
5. Save patterns
When you find a pattern that works, keep it. Build an internal "AI cookbook" for the team — prompt templates, complete context bundles, acceptable output examples. Teams with a cookbook get more productive. Teams without one reinvent prompts every day.
What this means for Enersys
As a software house focused on Odoo, Enterprise AI, and Data Privacy (PDPA), we use AI coding tools daily.
But we don't ship pure vibe-coded production systems.
Our process: AI as accelerator + human as judge.
Especially for client work involving:
- Personal data (PDPA compliance)
- Financial systems (accuracy is non-negotiable)
- Business-critical workflows (ERP)
Review isn't optional.
What we'll share publicly — we use AI to speed up routine work (boilerplate, test scaffolds, refactors). Design decisions, security review, and the final call before deployment all stay with humans.
That's why clients hire us. Not because we type fast, but because we judge well — what should ship, and what shouldn't.
Closing — "awkward and gross" is the truth the industry needs to accept
Karpathy isn't trashing his own AI work.
He's telling a truth that most people are scared to say — because they don't want to look "anti-AI" or "behind."
The truth:
- AI coding tools are powerful but not perfect
- AI code is still "gross" because labs haven't optimized for it
- AI agents are intern entities that need mentoring
- Humans must own aesthetics, judgment, taste, oversight
- Bad spec, worse AI code
- Vibe coding is a demo. AI-assisted coding is production.
The future = humans + AI working together. Not AI replacing humans.
Teams that read this signal early adjust their workflow, train their people, and set the right standards.
Teams still believing "AI can do everything" will pay the technical debt bill in 2-3 years.
At Enersys we're picking the first option — because our clients pay for results that hold up for 5 years, not demos that look good for 5 minutes.
Sources