I won't be vibe coding anymore: a noob's perspective
varunraghu.com
varunraghu.com
If only I could figure out how to reliably keep it from adding useless comments or preserving obsolete interfaces for “backward compatibility”…
It's also worth asking what rule it would need in order to follow the rule. On occasion, a rule I've added isn't quite followed. So I'll respond immediately pointing out what it did, that the rule is in the file, and then will ask it to tell me how I should modify, or add to, the rule in order for it to be easier to follow.
I'd imagine Claude Code has something similar that might be worth looking into.
Anyways, a year or two ago, the state of the art models couldn’t do math, and the image models couldn’t render hands or text, and those problems are broadly fixed, and I pretty much expect vibe coding to dramatically improve in the next year or two.
(Obviously, this post is tongue-in-cheek, but I'm making a real point - almost all code we use is code we didn't write. I don't think that's what differentiates Vibe coding code.)
Works mildly OK until it invents new functions or libraries for you and wastes your time or worse, you find the library exists but it only exists because of slopsquatting (enterprising scammers realized that LLMs like to recommend the same non-existent libraries and snatched up the names)
A succinct post illustrating that vibe coding is to become a cog that will be the first to be replaced by the AI you use. It's a temporary, automatable job--like entering a career in warehouse package handling with robots due sooner than later.
Code or code not, there is no Vibe coder.
With that framing, I suppose "vibe-coding" would be in a similar realm to "button pushing" or "lever pulling" or "handle cranking".
There's often a transitional period where the task exists and needs to be done... but without enough human thought and judgement it's only temporary, and ends when it becomes cheap enough to hook up a motor or actuator.
Vibe coding seems like an echo from the future.
With vibe coding, you are as much a reviewer/editor as an author, and as an editor should never accept generated code that you don't understand. Happily, the same technology that generated the code can explain the code.
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
...
I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it.Cursor has a "yolo mode" where you don't have to click accept for tooling even for system commands and people whitelist commands like sudo, su, and rf :))) I wish I was kidding.
That was the joke, which Karpathy found "quite amusing" and "not too bad for throwaway weekend projects". In reality, you won't even get that far with vibe coding if you don't understand what's going on.
Is this different than any given library?
But this of course can still open up potential vulnerabilities or unexpected behavior. The way I see it, there is some level of trust behind the library that it was built competently
How many teams importing React have even one member who's ever read even a dozen key paths & files in the React codebase? Think it's more than 10%? I'd bet it's closer to 1% than 10%, of teams on which even one member has done that, ever. Do they check the diff for every update? Shit, IME you're lucky if a single person reads the entire changelog before updating, and certainly nobody's reading the diff. Repeat for everything else. Functionally nobody does this, outside niches where small numbers of low-line-count deps are the norm.
Rails, all those imports from Square you used to have to use to cut the "WT actual F is this?" rate in Android dev to something non-crazy making, et c. Basically nobody even skims this stuff, and I don't think the number of businesses willing to pay for their developers to do that is large.
Unlike "vibes" there should always be a sense of purpose on why each function is needed and what you plan to do with the output, even if in some cases you treat hat function like a black box in terms of implementation (which IMO should be avoided, but situations may make the implementation above your understanding).
Plus I just get the LLM to write tests for it's code and I make sure the coverage is complete.
But it does make me feel uneasy still, like a dirty little cheat.
But yeah, I agree they go overboard and add tests that don't even test anything due to excessive mocking
... but without all the signs we look for as proof that a given library must not be too bad, since those signs are traces left by developers and by other users of the library, and LLM-generated code doesn't have any other users (I mean, to the extent it's copying existing code, kinda, but it'll be remixed and removed from its original context, so good luck tracking down the source and double-good-luck figuring out if any proof of quality found there is relevant to what you've got)
For this reason, for a long time to come, AI tools will be an assistant to dev teams who will still have responsibility for fixing issues when the brown stuff hits the fan. To shoulder that responsibility effectively, they will need to have a good understanding of the produced code.
So yes, vibe coding is here to stay but it will not replace software dev teams anytime soon. Dev teams might shrink initially because orgs will think they can save money. The trend will reverse quickly after a few major outages.
This doesn't seem applicable in most contexts. Yes, when I'm coding for fun or purely for learning the finished product is less relevant... but I'd guess the vast majority of code that is written is for a business that _only_ cares about the product. Code is an implementation detail.
If (and this is a _big_ if) AI-based coding can increase developer velocity even as little as 50%, no sane business is going to let their engineers ignore it just because it's not as fun as artisanal code.
Depending on how you measure that velocity (e.g. including security risks, debugging capabilities, ...) even as little as 5% increase is a no brainer for a business. Whether it's AI, powerful laptops, a fully-fledged IDE, an environment with a good dev experience, anything that gives a few percent increase snowballs into millions over an entire workforce.
Whether the current AI capabilities provide that increase without trade-offs that would be too heavy later one is a question that still seems up to debate.
Those things don't happen because the slowdown required before adoption, and the office politics of convincing everyone to make a change, and then the effort of convincing people that this new thing is what should be changed to.
No. Because most of these changes are totally opaque, you don't know what change needs to be made and making it becomes a political problem in the organization. Giving each engineer a subscription to some service is trivial.
I do not believe that corps make rational decisions around these matters.
I have no doubt that AI, right now saves me 5% of my time. That is 24 minutes a day I am not searching for something in the documentation of some library.
It’s worse. Code is a liability.
For a more comprehensive treatment of this insight, see: Programming as Theory Building by Peter Naur
You can use AI in different ways, it is extremely good as documentations. Often to understand how a library works you want a specific example, getting that example and having an AI answer questions about particulars has been very valuable to me and often saved me meaningless wandering through other parts of the documentation or the Internet as a whole.
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
...
I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it.From a business perspective, they don't care about this. They just want it built as inexpensively as possible in a reasonable time frame.
Vibe coding is here to stay.
Teams will be led by one subject matter expert, and fulfilled by thousands of agents. I would not be advising anyone under 21 to become a "coder". Studying computer sceince still has value, but coding was the lowest hanging fruit for LLMs.
Once we can do LLM code reviews with high confidence and little error, coding is essentially a dead field.
The closer you are to atoms and further the way you are from bits, the better off you will be in the coming two decades as AI progresses
I'm over here trying to play with bleeding edge tech and push some boundaries. I keep trying to get LLMs to help me and they keep letting me down.
I'm sure this is less thann useless for stuff like embedded or other low level coding.
and in 20 years, how are we developing this "subject matter expert"?
>Once we can do LLM code reviews with high confidence and little error, coding is essentially a dead field.
Maybe by the time I retire. I think people in their early 20's will still get a solid career out of coding in the meantime while we go through the inevitable hype cycle of shiny new tech. Even if in the middle of their careers they may truly have their hands forced.
I never vibe coded, and I don't understand this trend AT ALL.
I read how copilot and such are detrimental to critical thinking, and I am even consciously scaling back on copilot use now whenever possible, and prioritizing Google search, reading documentation, blog posts and stackoverflow now.
Perhaps I have the concept wrong, because half the time I'm still editing code by hand.
You still get code hell after a while unless you review the code and refactor where needed, but I can absolutely imagine a future where the code is just a compile target for the architecture and design I specify. A little bit like a compiler spitting out assembly (caveats apply, LLMs being non-deterministic etc etc and at current state probably not reliable enough for full unsupervised coding)
Very soon we will run out of human written articles.
One of the biggest wastes of human talent is corporations hiring people to solve the same problems over and over and over. Every company has to reinvent so many wheels for themselves because sharing code between for profit companies just isn't done outside of the occasional breaking a whole project off into an open source project. This is what LLMs are good at, the very repetitive boilerplate connecting the dots and doing obvious things. Companies are going to have to retool themselves to only really be doing "the hard part", and the rest left to LLMs. In the same way languages will have to change to accommodate the hard part and the easy part.
It's not the same human who is doing the same thing over and over though.
I have a toddler. He's learning addition and substraction now. I could had him a calculator or LLM and let him skip the entire learning process and do something productive instead. I don't. Because it'll destroy his critical thinking and ability to do anything productive later in life.
more "everybody who wants toast is designing their own toaster"
the actual business logic is making up a tiny proportion of work done while everybody spends most of their time plumbing frameworks and libraries together to do substantially similar things
If it's really "boilerplate", nobody should need to get a half-regurgitated approximation out of a statistical model.
Instead there should be a default implementation someone can choose until they need to customize, or a generator-script as part of the project, etc. Sometimes what people want is already right there in the docs, but nobody bothered to look.
I agree, and it's why I'm not worried about running out of paying work as I head into the latter half of my career.
Makes sense. Many businesses lately are churning out awful software that barely functions. Maybe if they were willing to support proper engineering that would be less of an issue.
Which yeah, of course, that their job. It’s the authors job to write a good book. The publisher needing to sell books doesn’t contradict or supercede the authors need to write well or develop their process.
I would say this is true in the same way that copy-paste coding functioned and that vibe coding isn't fundamentally different. It can be a useful approach to a variety of problems.
Having capable, knowledgable, and skilled employees is important to businesses though. If your business is something easily approachable then you are at risk of being outcompeted from companies with more skilled employees. There are truly hellscapes of codebases out there without the glimmer of hope of being worked on with vibe coding alone. On top of that, I'm getting the feeling that vibe coding is a sure way to hellscape your own codebase. Nothing can take the place of critical thinking.
Haven't really tried vibe coding myself yet, but I'm tempted to give it a go. I imagine stuff like integrating external API's could be really handy, looking through external documentation and creating the correct calls to the correct endpoints is always a huge timesink. Seems like AI should be able to make short work of such tasks
Yes. But in these early stages, that will only prove the LLM's can't do much more than be a fancy autocomplete, as opposed to a way to accelerate the workflow navigating anything with real-world value.
Maybe in a few years for the most common domains this will truly shine.
A long, unplanned outage is much more destructive to a brand than a delayed release. Vibe coding prioritizes the latter at the expense of the former.
To quote Copilot, "According to recent data, nearly 70% of top economic performers use their own software to differentiate themselves from competitors."
I think AI is best when used in this same way of thinking— not a tool that should handle all the coding for you, but as a very powerful codegen tool that you can leverage in many parts of your project.
I eventually figured out Andrej defined the term seriously, but initially I thought "vibe coding" was a parody. As in, it's was ridiculing people who can't code and won't put the effort and just kind of like letting the LLM drive. A bit of a https://en.wikipedia.org/wiki/Poe's_law in action I guess.
I like this analogy, because anyone who has written and/or has a habit of writing would attest this is not (only) some ideological claim about developing skills by doing the hard work yourself.
Writing clears up the brain, a lot. It structures ideas, both on the paper and in your brain, in a way you can't structure them any other way. It leads to new ideas, makes you realize mistakes or fallacies, and somehow can make you feel less worried when writing about things that stress you out. The way you write matters too— handwriting not only _feels_ different from typing, in spite of being slower it's sometimes the better tool to write certain things. Part of writing effectively is knowing when the slowness of handwriting is actually what you need— speed isn't always better.
It's often useful and productive to write things, even if no one will ever read them again.
I think it's similar with coding, and in a way I think it's related to something that happens all too often with engineers too. There's a lot of talk about developers having side-projects that are never done, and many see this as negative thing, but I've long held on the contrary, that it is in fact a very healthy thing. Sometimes you just need to code for the sake of organizing your ideas and laying them on the screen, not because you'll sell what you write, or someone else will use it or read it. Heck, often you won't even yourself. But that's fine, often the concretizing on "paper" ideas floating in your head is itself is what you actually need.
But in the business world, what matters is that you ship something that works, and pleases the customer, on time and under budget. If you're selling software, time to market is a critical constraint. And after your umpteenth slog through some wretched legacy code base, the feeling of achieving wizardly power begins to fade. Programming becomes another clerical job, and really, you don't care much about producing a lovingly handcrafted solution, you just want to get it out there and collect your pay so you can pay your mortgage and keep supporting your wife and kids. At the end of the day, that's what it's all about. AI lets you get stuff out there faster. Therefore it makes sense from a business perspective.
Well... sorta. If you're working on a personal project or open source project, then sure, yes, absolutely. If you're doing coursework or have explicitly set out to learn something new, then sure, yes, absolutely.
But when you're working at a job, they want you to use whatever tools will get the work done the fastest, and they usually don't care all that much about quality[0]. They don't care about your journey or process. They just care about the final product, and whether or not you met their arbitrary deadline.
[0] In my experience, the vast majority of "quality initiatives" at software companies are about fixing existing stuff that's broken, not about putting processes in place to ensure quality for new stuff. Even when the latter does happen, inevitably those processes will be short-circuited when there's a tight deadline.
The reality is that many startups are not tech hard. AI can help alleviate the pain of engineering a v0 to see if you have product market fit much faster. It’s great for prototypes.
I wouldn’t trust AI for production code without also having a strong AI counterpoint testing system.
That is to say, producing code is an annealing process. There is a refinement that comes from striking the hot iron and quenching the blade in water.
With code, spaghetti code will get you out the door, but it will never get you to scale. Scale requires precision, meditation on Kolmogorov complexity, and a clear understanding of the tradeoffs in distributed systems.
AI can help right now, but it is not a panacea, at least in the present moment.
Agents got really good lately in explaining what they did, which makes it easier to skim over the "boilerplate" and focus on the main event it produced.
Also I got really good with agents since I spend half of my day talking in my head to an agent and focusing on how to build my prompt and what questions and areas I want it to ask me about before I set it free.
It's not really vibe coding but actuall vibe coding never worked for me, it usually get stuck in a loop of "let me fix a linter issue" and "i didn't implemented this interface correctly".
A new and improved version of old RAD (rapid application development)?
Can we apply something from the decades of debate regarding RAD to the new undefined thing? I don't know, someone told me undefined values are hard to deal with.
Every problem I overcome is a lesson learned that enriches my life and makes me more valuable.
The results are nice but it's the journey and understanding that matter to me.
There's more value in having a team of people who understand the problem domain so deeply that they can create a computer system to automate the solution. When things go wrong, and they will, you have to have the understanding in order to confidently resolve the issue.
"But AI can do it!"
Sure.
But can you?
There is no inherent honor in toil.
To me coding is a tool to get things done, not something I intrinsically like or value
His point is juxtaposed with a mid-sentence break, but it is non-contradictory. This thought confounds me greatly.
If you didn't care about learning *how* the program worked you wouldn't learn. Many people did not, but some did.
The same happened on stack overflow, where you could copy paste random solutions or go to the docs often linked from the solution and learn *why* it worked. Many people did not, some did.
The doom and gloom around vibe coding is a proxy for FUD around generative AI mixed with some misplaced sage-like nostalgia.
People who want to learn to program will still learn to program. Only they have way better tools to do so and could progress in capability much faster.
To me, this post getting upvoted is a strangely implies there's no professional SWE gate-keeping to the generative AI coding assistance Luddism, only a shared sense of authenticity.
I suspect these posts get attention from people who have not put in the work to learn how to use generative AI for their hard SWE problems and so presume it is mostly enabling crap because they have yet to study it enough to make it do better than that in their own workstreams.
If you're in the older set, maybe you remember what it was like to get drivers working for DOS on your new CD ROM and how much you put into that effort. Put that effort into using gen ai and you may stop seeing it only as a thing that biz will use to destroy the SWE profession.
the genz kids are just the first ones who made it broadly acceptable... thank god, because it's a waste of brain cycles without added information - and i'm a native german speaker where it's even more stupid
You do you, of course, but let's not pretend it's more than a stylistic affectation.
Funny how it's coming back, with the younger generation embracing it. Everything cycles, I guess.
But hey, I'm getting old, it is what it is.
Do: agentic code.
LLMs are amazing tools and I do use them for writing code, refactoring code, etc. but I would never prompt engineer only. My use of LLMs often is a mix of jumping between Aider and writing code myself when Aider doesn't doesn't understand what I want, or what I want is a big refactor, which LLMs are not good at because it's too easy for them to make mistakes when writing huge blocks of code, like syntax errors and the like.
For a human moving a function or even indenting a block (to wrap in an if/try/catch/etc) is child's play. To an LLM? Yeah, it can easily make stupid mistakes (linting aside, I'm talking syntax errors) when doing that. Also, what a waste. We really should have MCP-type tools of "Wrap the code on lines X-Y" in a try/catch, since the logic for that is stupid-easy but for an LLM the only way to accomplish it is a massive Find/Replace block. The bigger the block of code that the LLM writes in 1-shot, the higher the chance it messes stuff up (or at least that's my experience).
I expect this situation to improve over time as as more coding assistant tools learn how to use things like linting, running a test build, running tests, etc. And yes, I know some already do that, I've just not been super impressed with their ability to do that so far. Despite clear instructions I've had both Claude Code and Aider run the wrong `npm run test:xxxx` command (the watch command instead of the ci version) and I then I have intervene. Even when they run the right command, it's still to easy for an LLM to get off in the weeds or far down a path you don't want.
The trick with LLMs is "commit often", I don't code that way myself, I'm more of a "one commit a the end"-type of guy (yes, I know you can squash) but I've changed that with LLMs since it gives you "save" points when the LLM goes off track. Often a bad/failed edit can completely derail the progress and a human _must_ intervene, reset to the last good state, and start over again. If you aren't committing regularly (after every couple exchanges or so) then you can have a mess on your hands:
Commit - Feature - Feature - Feature - Disaster
If you do this you have to pick apart the disaster by hand or give up on the 3 features/bug fixes, improvements, etc since your last commit.
Aider does a very nice job of this by default. I was opposed it when I first started using it but it's invaluable.
While I enjoy learning about coding, coding is not about the journey for me, it's about about the destination. And I gladly use Aider to pump out UI that would take me hours if I was capable of doing it at all, so that I can keep moving towards my destination. BUT, if you don't understand the code that's being written then you've already lost. I understand grid/flexbox but I'm just very slow at it. LLMs can pump out a UI (or 5-10 iterations of a UI) in practically no time at all, I can edit styles, I'm just slow at writing them from scratch. This is where LLMs shine IMHO, trying out things that would take longer or not have the ROI to do yourself.
"Hey our settings screen is a little cluttered, can we clean it up?" has a _very_ different answer if you can test 5 iterations and pick the best one in <1hr vs spending 2-3+ hours doing it from scratch. The amount of UI I have written has skyrocketed since LLMs came out. And, not unlike Electron, the options were not "LLM UI" or "Bad UI", the options before this were often "LLM UI" or "No UI" (CLI or developer-only focused UI pages).
> what was the point of it all if i didn’t learn a thing?
Money. Freedom. Supporting a family. Doing things faster. Keeping up with changing times. etc..
There are a ton of different answers, and it depends on your goals.
> coding isn’t about the finished product
Again, to each their own.
As a senior software engineer, AI still surprises me with concepts I didn't know about from time to time. I think spending the time to grok the code it generates is about as invaluable as the code's functionality.
As in the past, however, nothing's stopping people from copy-pasting code found online and never improving their internal toolkit. AI will not only uphold that status quo, but amplify it exponentially.
Example?
But for a recent example, I learned to stop worrying and love macros in Elixir. Even `defmodule` and `def/defp` are themselves macros.
I feel really sad for those who are starting out today. In many cases, especially for frontend programming, vibe coding correctly has a lot of value but it does makes you not learn anything.
Which means you remain at what I call the "vibe plateau".
One useful technique I've been telling my mentees to learn programming is to use a language where you are forced to not be able to use vibe coding such as Haskell or Rust.
But if you are in mediocre Javascript or Python land, it is a hard fight for the younger ones.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.