the term's been impossible to avoid for the past year. figured it's worth a real discussion here instead of the recycled LinkedIn hot takes.
quick summary if you somehow missed it: vibe coding is writing software by describing what you want in natural language and letting an AI generate the code. Andrej Karpathy coined it early 2025. Cursor, Claude Code, Copilot, Windsurf, etc. the tooling got good fast.
i've been using Claude Code for some internal stuff at work. mostly Go services and some data pipeline scripts. here's where i'm at:
the part nobody talks about: code review. when half the PR is AI generated, what does review even look like? are you reviewing intent or implementation? because those are different skills.
so, some honest questions:
not interested in the "AI will replace us" discourse. just want to know what's actually working in practice.
Jenson Miller
“Instantly calculate your age, date differences, and time with MyAgeCalculate.com
honestly this is the thread i've been waiting for someone to start.
so i've been using Cursor + Claude for about 6 months now on our main product (Next.js app, nothing crazy). and yeah we're shipping AI generated code to production. not like yolo shipping it though, we have a process.
the way i think about it: i let the model handle the stuff where the intent IS the implementation. like if i need a form with validation, a CRUD endpoint, a util function to parse dates in some weird format... just describe it, review the output, done. that stuff used to be the most boring part of my day and the model gets it right 90% of the time.
where i draw the line is anything with actual business logic or state management that touches multiple parts of the app. tried letting Claude handle a checkout flow refactor once and it "worked" but made assumptions about our cart state that were subtly wrong. took me longer to find the bug than it would've taken to just write it myself.
for code review tbh we treat AI generated code the same as human code. if anything we review it MORE carefully because the model writes confident looking code that can be quietly wrong. like it won't throw errors, the tests will pass, but the logic has an edge case the model didn't consider because it doesn't know your users do weird things (our users definitely do weird things).
the biggest shift for me mentally was stopping to think of it as "the AI writes code for me" and more like "i have a really fast intern who needs very specific instructions and will never push back when something smells off." that framing helps me know when to use it and when to just open a file and type.
I’ve been experimenting with this a bit too. For small utilities and scripts it definitely speeds things up, especially when the requirements are clear. But once it touches an existing codebase or production systems, I still feel more comfortable writing most of it myself and just using AI for suggestions or quick scaffolding.
The review part you mentioned is interesting though. When a big chunk of code is AI-generated, I think the focus shifts more toward understanding the logic and potential edge cases rather than just style or structure. Curious to see how teams eventually standardize this.