"Vibe coding" has taken off as shorthand for using AI to write code. The problem is what comes attached to it. The term carries a clear negative connotation: that the person doing it has little or no real knowledge of what is being generated, that the output is unlikely to be well architected, properly tested, or competently supported in the long term.
Even Karpathy himself seems uneasy with what the term has become. He has since described AI agents as "intern entities" that need oversight on judgment, taste, and aesthetics, and he later called his original post "a shower of thoughts throwaway tweet" meant for throwaway weekend projects. His latest personal project was hand-coded, not vibe-coded. The man who started the cultural moment is already on to something more deliberate.
For developers who picked up AI tools last week and shipped a prototype before they understood what a null reference exception actually is, fair enough. That label fits.
And the bad reputation is at least partly earned. Research from Apiiro published late last year found that AI-authored code carried roughly 75% more logic errors, 64% more maintainability issues, and 57% more security findings than code written by humans. A separate Sonar report found that 61% of developers agree AI produces code that looks correct but is not actually reliable. The risk is real. Which is exactly why the role of an experienced developer matters more, not less.
But where does that leave the rest of us? Those of us who spent years, in my case 27 of them, learning to code line by line, bug by bug, framework by framework? The ones who can read the AI's output and immediately recognize when a service layer is being created where a query object should be, or when a session handler is silently going to leak memory under load?
We are not vibe coding. We are doing something else entirely.
From Individual Contributor to Team Lead
The moment an experienced developer brings AI into their workflow in any serious way, the role quietly shifts. You stop being the person writing every line of every feature. You become the team lead. The team just happens to be made up of AI agents instead of junior developers in the next cube.
That is not a marketing flourish. It is a real change in how the work gets done, and it draws on every hard-won skill a senior developer has built over their career.
The data backs this up. The 2025 State of AI Code Quality report found that senior engineers report the largest quality gains from AI of any experience level (60%), while also reporting the lowest confidence in shipping AI-generated code without scrutiny (22%). They get more value out of the tools and they trust the output less. That is not a contradiction. That is exactly what a team lead looks like.
Think about how you would lead a development team you actually respected:
You would not let them push code straight to production. You would not skip planning. You would not accept "it works on my machine" as evidence that anything was tested. You would not hand them a vague requirement and expect them to read your mind. You would not let them release something you did not understand well enough to support at 2am on a Saturday.
The same rules apply when the team is AI.
How the Work Actually Looks
When I sit down to build something nontrivial with AI, the rhythm looks remarkably like working with any other team.
We have team meetings. Before any code is written, we talk about the project. What are we building? Who is it for? What constraints matter? What does success look like? I push back on assumptions. The AI pushes back on mine. We have discussions about approach. This is no different from a kickoff meeting with three senior engineers and a whiteboard.
We develop a plan together. Architecture, module boundaries, data flow, edge cases, testing strategy, deployment path. By the time anyone touches a keyboard to write production code, there is a document we both reference. I have lost count of how many architectural decisions have been improved because the AI asked the right uncomfortable question, or because I had to articulate something I had been carrying around in my head for years.
We assign tasks and start working. The team goes off to build. I do not micromanage every keystroke any more than I would with a trusted human teammate. But I am watching the work.
The team brings problems back to me. Bugs, ambiguities, concerns about a choice we made earlier, questions about a library version, things that do not feel right. A good AI teammate raises these the way a good junior developer does, and a good lead resolves them rather than steamrolling past.
We review features together. Code review is not optional. I read what was produced. I question patterns. I refactor. I rewrite. I reject. Sometimes the AI's first pass is better than what I would have written alone. Sometimes it is subtly wrong in a way that would cost me a weekend in six months if I shipped it.
We test thoroughly. Unit tests, integration tests, the kinds of edge cases that come from having been burned by them before. The AI is happy to write tests all day. The lead is the one who knows which tests actually matter.
We deploy to staging first. Then we exercise it. Then, and only then, does it go to production.
Nothing in that list is new. It is just how serious development has always worked. The only thing that has changed is the composition of the team.
So What Should We Call This?
"Vibe coding" describes a real thing, and there are real people doing it. But it is the wrong label for what an experienced developer does with AI, and conflating the two is starting to do real damage to how our craft is talked about.
A few alternatives that feel closer to the truth:
- AI-led development describes the collaboration honestly
- Directed development captures the leadership role
- Conducted coding has a nice ring to it, the senior developer as conductor of an orchestra of agents
- Augmented engineering emphasizes that the engineering rigor has not gone anywhere
- Team-lead coding says the quiet part out loud
The orchestrator framing in particular is gaining real traction. O'Reilly recently published a piece framing this exact evolution as moving from conductors, working with a single AI agent, to orchestrators, overseeing a team of agents working in parallel. The vocabulary is shifting, slowly, toward language that acknowledges what experienced developers are actually doing.
None of those are perfect. I am not sure the right term exists yet. What I am sure of is that "vibe coding" is not it, at least not for the people who are bringing decades of hard-earned discipline to this new way of working.
Your Turn
What do you call it when you build with AI? Do you feel like a vibe coder, or do you feel like a team lead with a very capable, very fast, occasionally overconfident team? And if "vibe coding" is the wrong term for what experienced developers are doing, what should we be calling it instead?
