There is no skill in AI coding
Andrej Karpathy posted one of the most sober takes on agentic coding in recent times. One that I think many people needed to hear. He effortlessly put a name on patterns many observed but couldn’t put a finger on. He says:
The mistakes have changed a lot - they are not simple syntax errors anymore, they are subtle conceptual errors that a slightly sloppy, hasty junior dev might do. The most common category is that the models make wrong assumptions on your behalf and just run along with them without checking. They also don't manage their confusion, they don't seek clarifications, they don't surface inconsistencies, they don't present tradeoffs, they don't push back when they should, and they are still a little too sycophantic. Things get better in plan mode, but there is some need for a lightweight inline plan mode.
They also really like to overcomplicate code and APIs, they bloat abstractions, they don't clean up dead code after themselves, etc. They will implement an inefficient, bloated, brittle construction over 1000 lines of code and it's up to you to be like "umm couldn't you just do this instead?" and they will be like "of course!" and immediately cut it down to 100 lines.
They still sometimes change/remove comments and code they don't like or don't sufficiently understand as side effects, even if it is orthogonal to the task at hand. All of this happens despite a few simple attempts to fix it via instructions in CLAUDE.md.
What this demonstrates to me is something I’ve recently begun to suspect, which is that there is no skill in AI coding. Everyone is getting the same results.
Whether it’s your first time and you don’t know what a function is, or you’re a seasoned “agentic engineer” writing book-length specifications, or even the inventor of vibecoding, everyone’s getting the same thing: junior code.
To be clear, if Claude were a developer from the UK named Simon, and you hired Simon because he promised to transform your entire engineering discipline and ship fervently, Simon would need to be called into the office with an HR rep after one look at his code.
On the one hand, CEOs love Simon because he ships so damn fast! He makes the other engineers look lazy. On the other hand, his EM and peers are warning that Simon writes untenable junior code and:
He constantly makes wrong assumptions and just runs along with them. He also doesn’t manage his confusion, doesn’t seek clarifications when something is ambiguous, doesn’t surface inconsistencies, doesn’t present tradeoffs before making decisions, doesn’t push back on anything, and says yes to every idea the C suite has before checking with the rest of the team. Things get better when you tell him to make a plan before acting, but there is some need for him to just think on the fly.
He also really likes to overcomplicate code and APIs, bloats abstractions, doesn’t clean up dead code after himself, etc. He will implement an inefficient, bloated, brittle construction over 1000 lines of code and I’ll DM him on Slack and be like “umm couldn’t you just do this instead?” and he will be like “of course!” and immediately cut it down to 100 lines. Wtf??
He still sometimes changes/removes comments and code he doesn’t like or doesn’t sufficiently understand (!!), even if it is orthogonal to the task at hand. All of this happens despite putting a yellow post-it note on his monitor explicitly telling him NOT to do these things.
Now ok, look, Simon isn’t perfect. He’s a brilliant, gifted wiz kid and we just gotta be patient and make sure we’re really clear about what we want from him. It’s up to the seniors on the team to coach him.
But you find that no matter how many sitdowns, no matter how many threats, no matter how many rewards, Simon just doesn’t give a flying fuck. He is who he is and he’s not going to change for you. “Do you want your task done in 15 minutes or not? Oh, you’re gonna give it to your senior devs who’ll take 7-8 business days? Ha, you can’t fire me! I own you.”
And you know what? He’s absolutely right. Try as they might, the engineers just can’t get rid of him. Hell, they’re even starting to like him, as he takes work off their plate. And the C suite absolutely adores him. Every all-hands, it’s Simon this and Simon that.
The good news is I hear Simon is in therapy right now. Within 12-18 months, Simon’s not gonna do all these silly Simon things anymore. Hell, I hear Simon’s gonna be so good, we won’t even have to look at his code anymore.
Are LLMs even worth the hype when it comes to syntax? Most languages have LSPs and editors can easily be configured to autocomplete with them. No (skilled) developer should struggle with syntax in a language that they already understand. The argument that "AI replaces the need to memorize syntax" is one of the most idiotic arguments for using AI assistants.
They're decent for writing boiler plate code, but code snippets are (imho) just as useful.
LLMs have helped me as a research assistant, especially working with new libraries. It's nice to use them to test different approaches. But in the end I've found that the more I use AI, the more time I waste. In a professional setting, generative AI should be used more like salt. Too much salt ruins a dish.
An even better analogy is a leavening agent (yeast/baking soda). Too much and your bread implodes. Unleavened bread is vital for certain religious sacraments.