You make the framework and it colours in the lines. If you don't draw the pattern first you're going to get a kindergarten mess. There are times I'm amazed by its suggestions but it will also cheat and "lie" and if you're not paying attention, you'll miss it.
But these days many tasks for me consist of: I need this, look how I did it here before, and follow this exact pattern through to the end and write tests, too. And the results are usually exactly what I would have done. Because it is an excellent mimic. But if I hadn't put the work into the framework, it would be awful.
I’ve ended up with tests called stuff like “foobar successfully returns impossible value that suggests programmer error” lmao
I don't necessarily think it will stay this way, though. The tools are so new, we shouldn't be so sure that the future versions won't allow non-coders to code successfully.
Conveniently, when it then changes the original implementation, the tests don’t fail!
Reminds me of the joke:
int getRandom() {
return 4; // chosen by a dice, guaranteed to be random
}
I wasn't saying it will certainly reach the point where non-coders can code, I am saying we can't be certain it won't just because it can't yet
1 it's not the meaning Karpathy used originally, which was for creating software through prompts WITHOUT looking at the source code
2 it's not the meaning people outside programming circles mean, either, which is identical to Karpathy's original definition
the title of the article is talking about 2 and is completely correct.
YOU, on the other hand, are talking about an upgrade to IntelliSense. Use a different term. You're describing regular programming, with a new IDE tool.
If it's not going to replace programmers and allow regular people to create software without looking at the code, it's not vibe coding. Full stop.
Source: https://xkcd.com/221/
I've seen less experienced devs crash and burn trying to commit massive amounts of vibe coded slop without consideration to: how much of it was necessary? how does it conform with our code base / style? how much does it take advantage of existing code and patterns? and so on.
I think if you are using one of these tools and experienced, it should be difficult to tell you are using one at all. The code I produce looks like stuff I would write, and I understand all it wrote, I don't want to outsource to producing tons of code that I don't even understand.
If you’re talking about AI-assisted development, then an AI agent being able to do 80% of the work is a fantastic win. The developer can pick up the remaining 20% and come out massively ahead.
If you’re talking about vibe-coding, then an AI agent being able to do 80% of the work is useless. What’s a non-developer going to do with something that still has 20% of the development left to do? It’s not 80% useful, it’s 0% useful.
That said I might be sort of a weird case, since I am accustomed to designing and documenting product requirements, the fact that it's just for me means architecture doesn't really matter, and I'm competent enough to help it resolve some design problems like the fact that it was obviously hitting the wrong Amazon API that was pulling a report of every single sale as a line item rather than just a report with total sales numbers, etc.
But when I try it with a stack I don’t know, I quickly find myself needing to learn the new stack to get anything done.
Extremely experienced engineers will be able to move quickly with these tools, but specialization will still exist, and I’m not clear on how juniors are going to ramp up on all of this.
It’s funny you should mention LISP macros. Five years ago, I’d have told you that the most efficient way to build something is to get an extremely experienced dev with mastery over a flexible language like LISP, and just let them go nuts. I constantly have to hold myself back from metaprogramming tricks because my coworkers won’t be able to maintain it. But on my personal projects, I really get to flex my muscles.
It occurred to me a few months ago that that’s exactly the same spot in my toolbox where Claude Code is. It’s a tool that allows one person with mastery of a tech stack to build things incredibly quickly. Look at Cursor where a tiny team has over $100M in annualized revenue.
Big companies often find themselves spreading ownership across too many hands. You know exactly how to build what you need, but you’re not allowed to touch 80% of the code involved because it belongs to a different team. But coordinating all of that is a massive amount of overhead that will derail most projects. This is why so little happens at big companies.
But these tools enable a smaller number of experts to do a job that used to take many. I expect the speed improvements to be super-linear as a result.
Of course, that brings concerns about what happens to the employment situation for devs if that happens. I hope it means that 10,000 new startups can build more ambitious products and absorb all the people who will probably be laid off by the huge corps in the next few years.
Even with humans, it’s very common to ask them for something and get something back that’s completely different than what you wanted. Short of reading your mind, AI is going to require a lot of info to get the desired result.
So someone is going to have to gather requirements and break them down into a clear, well thought out set of instructions for the computer. That’s literally what programmers already do. We’re just programming in a different language now.
And I’ve realized that even when I try to stay in control, I often don’t read the output code—I just copy and paste.
Metaphorically, it’s like pilots who know how to use the autopilot, but can’t switch back to manual control. That’s the generation of coders we’re raising.