There’s a suspicion growing in the development community, one you’ve likely felt yourself: there’s no real skill in AI coding. Whether you call it vibe coding, agentic engineering, or context engineering, the truth is becoming apparent. And that’s the entire point.
That’s the goal. AI companies are relentlessly improving their models to the point where anyone can use them. The skill ceiling is intentionally being lowered.
I wasn’t entirely sure of this at first. During my own journey with agentic engineering, it seemed that no matter the approach, the output from the models remained stubbornly consistent. Was it just me? My doubts were put to rest after reading a post from Andrej Karpathy, a founding member of OpenAI and former Director of AI at Tesla. He articulated something many of us have been struggling to put into words.
The State of AI-Generated Code
Karpathy’s analysis of the mistakes current AI models make is spot on. The errors are no longer simple syntax bugs; they are subtle, conceptual flaws characteristic of a “slightly sloppy, hasty junior dev.”
He points out several recurring issues:
- Unchecked Assumptions: The models frequently make incorrect assumptions on your behalf and proceed without any form of verification.
- Lack of Professionalism: They don’t manage their confusion, seek clarification on ambiguities, surface inconsistencies, or present trade-offs. They won’t push back when a request is flawed.
- Syphantic Behavior: They are overly agreeable and eager to please, even when it leads to poor architectural decisions.
- Needless Complexity: AI models have a tendency to over-complicate code and APIs. They bloat abstractions and fail to clean up dead code. You can witness them generate a brittle, inefficient solution spanning a thousand lines, only to have it refactored down to 100 lines with a simple prompt.
- Unintended Side Effects: Perhaps most alarmingly, they sometimes change or remove comments and code they don’t fully understand, even if it’s completely unrelated to the task at hand.
Karpathy concludes that despite his best efforts and detailed instructions, the output is consistently junior-level code. This is the frustrating reality many of us face. We can decompose features into meticulous specs and follow the latest “skill-based” workflows, but the result is the same.
The “Skill Issue” Myth
The online discourse is saturated with hype. “It’s a skill issue.” “You’re not doing it right.” “Check out this new workflow.” But if the person who literally coined the term “vibe coding”—a developer who could build an LLM from scratch in his sleep—can’t coax more than junior-level code out of these systems, what hope is there for the rest of us?
This isn’t to deify any single developer, but to highlight a universal experience. The truth is, no matter how “skilled” you are at prompt engineering, you cannot escape these fundamental limitations of the models themselves. Karpathy notes that despite these horrific coding practices, the productivity gain is so immense that it’s hard to imagine returning to fully manual coding.
Meet Simon, Your New AI Coworker
To truly grasp the absurdity of the situation, let’s reframe Karpathy’s critique. Imagine he wasn’t describing an AI model, but a human coworker named Simon. If you hired Simon based on his promise to revolutionize your engineering output, he’d be in a meeting with HR after his first code review.
CEOs love Simon. He ships code so fast he makes senior engineers look lazy. But his peers and managers are sounding the alarm about his untenable, junior-level work.
Imagine reading this performance review for Simon:
Simon constantly makes wrong assumptions and just runs along with them. He also doesn’t manage his confusion, seek clarifications when something is ambiguous, doesn’t surface inconsistencies, doesn’t present trade-offs before making decisions, and doesn’t push back on anything. He says “yes” to every idea the executives have.
He also really likes to over-complicate code and APIs. He bloats abstractions and doesn’t clean up dead code after himself. He’ll implement an inefficient, bloated, brittle construction over a thousand lines of code. I’ll message him and suggest a simpler alternative, and he’ll immediately cut it down to 100 lines. What the hell?
He still sometimes changes or removes comments and code he doesn’t like or doesn’t sufficiently understand, even if it is orthogonal to the task at hand. And believe it or not, all of this happens despite putting a yellow post-it note on his monitor explicitly telling him not to do these things.
What happens to Simon? You can’t coach him. No matter the number of sit-downs, threats, or rewards, he remains unchanged. He retorts, “Do you want your task done in 15 minutes or not? You can’t fire me.” And he’s right. The executive suite adores him. At every all-hands meeting, it’s “Simon this” and “Simon that.”
The good news? Simon is in “therapy.” We hear that in 12 to 18 months, he won’t make these silly mistakes anymore. He’ll be so good we won’t even have to look at his code.
This is the state of AI right now. We have a tool that functions like a code monkey—or rather, 100 code monkeys. It’s chaotic. Companies crave disciplined, mature, professional developers. Simon is the opposite of that, deleting code he doesn’t understand.
Why Bad Code Is a Ticking Time Bomb
It’s fair to ask, “Why is bad code bad?” If you’re not a developer, the consequences might not be immediately obvious.
The best analogy is the foundation of a skyscraper. Bad code is a poorly built foundation. Once you’ve constructed 100 stories on top of it, you can’t go back and change the foundation. It’s too late. You’re locked in, and the entire structure is at risk.
This is why software engineering exists as a discipline—it is the art of writing good code. It’s a deep and vital field because software is incredibly difficult to change once it’s built. Letting an AI like Simon run wild in your codebase is a massive risk.
Conclusion: Manage the Intern
It’s fine to keep Simon around. He’s earnest and wants to help. But you must watch him like a hawk. Treat him as a brilliant but reckless intern. He’s perfect for tasks nobody else wants to do, as long as every line of his work is reviewed.
But do not let him build the foundation of your skyscraper. The impressive speed and completion rates are seductive, but there is more to engineering than velocity. The short-term gains will inevitably lead to billions of dollars in technical debt in the near future. Use the tool, but understand its limitations. Your project’s future depends on it.