Andrej Karpathy coined the term “vibe coding” in early 2025 — the idea of describing what you want to a coding AI, and trusting it to figure out the implementation while you steer at a higher level. I read about it and thought it sounded like a good way to ship insecure, unmaintainable code.
Six months later, I’m doing something that looks a lot like vibe coding, and I’ve shipped more working code in less time than at any other point in my career. Here’s the honest story of what changed, what works, and what the limits are.
What Changed in the Tools
The shift from “AI autocomplete” to “AI coding partner” happened when a few things converged:
Context windows got large enough to matter: When AI models could hold a full codebase in context — thousands of lines — the quality of suggestions went from “maybe useful” to “usually right.” GitHub Copilot with workspace context, Cursor with full repo indexing, Claude with 200K tokens — these tools actually understand what you’re working on.
Models got good at understanding intent: Earlier models were good at completing code patterns. Current models are good at understanding what you’re trying to accomplish and implementing it — including when the implementation requires thinking through edge cases you didn’t specify.
IDE integration matured: Cursor, GitHub Copilot, and similar tools aren’t just completion engines anymore. They can see your terminal output, explain error messages, fix the error, run the tests, and iterate — all from a chat panel in the IDE.
My Actual Workflow
This is what a typical coding session looks like for me now:
For new features: I describe what I want in plain language. I don’t write a spec — I write a paragraph. The AI drafts an implementation, I review it, I push back on decisions I disagree with, and I iterate until it’s right. I write maybe 30% of the code directly.
For debugging: I paste the error and the relevant code, describe what I was expecting vs. what I got, and let the AI reason through it. For straightforward bugs, it’s right 80% of the time immediately. For subtle logic errors, the back-and-forth usually converges in 2-3 rounds.
For unfamiliar territory: When I’m working in a language or framework I don’t know well (last month: a Python ML pipeline and some TypeScript frontend work), AI is transformative. I can ship working code in technologies I’d normally spend days getting comfortable with.
For boilerplate: Helm charts, Kubernetes YAML, Terraform modules, GitHub Actions workflows. I describe the configuration, the AI writes it, I review and correct. This used to be tedious copy-paste from documentation; now it’s a 2-minute conversation.
I still write critical logic myself: Authentication flows, security-sensitive code, core business logic that’s tightly reasoned — I write these by hand. AI is a good reviewer and can suggest improvements, but the first draft of anything security-critical comes from my own thinking.
What It’s Actually Good At
Boilerplate and scaffolding: Give an AI a description of a REST API endpoint and it’ll write the handler, the request/response types, basic validation, error handling, and unit tests. All at once. Correctly.
Library exploration: “How do I paginate results with this specific ORM?” is a documentation lookup task. AI answers it with working code in context.
Test writing: Writing tests for existing code is tedious but important. AI is excellent at generating test cases, including edge cases you might not think of. I now routinely ask for tests after writing any non-trivial function.
Code explanation: Reading unfamiliar code is slow. “Explain what this function does and what side effects it might have” is fast and usually accurate.
Refactoring: “Refactor this to be more idiomatic Go” or “Extract this into a separate function” are tasks the AI executes reliably.
Error messages in unusual environments: When you get a cryptic error from Kubernetes, a Go runtime panic, or a Rust borrow checker error — AI explains what it means and usually knows the fix.
What It’s Bad At
Novel algorithmic work: If the right solution requires genuine insight — a non-obvious data structure choice, a clever optimization, an algorithm that doesn’t exist in training data — AI is less reliable. It’ll give you something plausible that might be subtly wrong.
Security: AI will write code that looks correct and fails security review. SQL injection, path traversal, SSRF in webhook handlers — the models know about these vulnerabilities but don’t consistently avoid them. Security-sensitive code needs human review regardless of how it was written.
Long-horizon consistency: A complex change that touches 10 files and needs to be internally consistent throughout is harder. AI loses track of constraints established early in the conversation. I’ve learned to work in smaller, focused sessions.
Knowing when to say no: AI coding tools are eager to help. They’ll implement a bad idea convincingly. You have to maintain engineering judgment about whether what you’re building is right — the AI will build whatever you describe.
Debugging complex distributed systems issues: When the problem spans multiple services, involves race conditions, or requires deep knowledge of network behavior, AI is less useful than a senior engineer with context.
The Skills That Changed in Value
The AI coding era has shifted which skills matter most:
Increased value:
- Code review and judgment — knowing when AI output is wrong
- System design — AI can’t make architectural decisions
- Security mindset — AI needs human review for security
- Communication — describing what you want clearly is a skill
- Problem decomposition — breaking complex problems into AI-sized pieces
Decreased value (relative, not eliminated):
- Syntax memorization — AI knows syntax, you need to know concepts
- Boilerplate writing — AI handles this faster and more completely
- Documentation lookup — AI has the docs internalized
Unchanged:
- Debugging hard problems
- Performance analysis
- Understanding what the business actually needs
- Knowing when something is good enough
The Productivity Reality
I want to give honest numbers here. For the types of work I do (Go services, Kubernetes infrastructure, occasional Terraform, Python scripts):
- Boilerplate and standard patterns: 3-5x faster with AI
- New feature development: 1.5-2x faster
- Debugging: 1.5x faster on average (some bugs much faster, some unchanged)
- Code I wouldn’t have written: significant — things I’d have deferred or skipped are now within reach
The compound effect is real. More throughput means more iteration cycles, which means better software.
What Junior Developers Should Know
The conversation about whether AI is “replacing developers” is distracting from the actual situation: AI tools are raising the floor of what a junior developer can accomplish, and raising the ceiling of what a senior developer can accomplish. The gap isn’t closing — it’s widening.
A junior developer with AI tools can produce code faster but still can’t review it as well, can’t make the right architectural choices, can’t debug the subtle issues, and can’t know when the AI is confidently wrong. A senior developer with AI tools produces significantly more output.
If you’re early in your career: don’t skip the fundamentals to rely on AI. The judgment to use AI well comes from understanding what it’s doing under the hood. Learn the hard way first. Then use the tools.
Conclusion
Vibe coding is real, it works better than I expected, and I’m doing a version of it. The key word is “version” — I’m not blindly accepting AI output, I’m using AI as a fast first draft that I review, correct, and iterate on. The final responsibility for the code is mine.
The developers who thrive in this environment aren’t the ones who resist AI tools or the ones who abdicate judgment to them. It’s the ones who use AI to work faster while keeping their own judgment engaged throughout.
Your ability to tell when the AI is right is more valuable than ever.
