Using AI to assist in locating the right library function or similar to documentation has been effective to speed up my development, but I really dislike using it to autocomplete whole functions or large swathes of code, because then I have to spend time reading and understanding code I didn't write. This doesn't ultimately feel "faster" when I own what I write.
I'm using AI for grepping, analyzing flow, finding cross-project dependencies, etc. It provides a significant speedup. But the generated code is mediocre at best. Changes look like patches on fabric, not woven threads. AI generates too much redundant code.
One other use-case I've found effective for it is assisting with API development and defining API specs. For example, I've uploaded API definitions in YAML and previously provided instructions about the API standards I want to impose and to ensure consistency as I build new things, this saves some degree of effort between writing -> linting -> fixing -> linting again if I have it just validate and fix any minor inconsistencies.
I started with Repomix as an MCP server plus system prompt to reduce the scope to single packages. However, it still consumed too many tokens (and polluted the context with useless information). I used Gemini, context size wasn't an issue, but it was too expensive. Now I just use Cursor, it has built-in indexing with embeddings (I assume).
I had a similar situation - I once wanted to grab some web pages and parse them in Python, and was going to use Python's built-in libraries for that, and use BeautifulSoup to parse them. But then I realized I'd have to read enormous code bases I didn't write, which felt like it would take forever.
(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.)
I’ve had good results using Claude Code by specifically coaching it on how its implementation should be. It’s not always perfect and sometimes I do have to try again, but it’s remarkably effective when given enough guidance.
If only I could figure out how to reliably keep it from adding useless comments or preserving obsolete interfaces for “backward compatibility”…
Me too, I’m using Roo Code and have substantially updated the system prompt to describe the project standards, correct way to restart the services and inspect the logs, specific hints about the frameworks im using and how to use DI and patterns, like think about what kind of code it’s writing and where to put it in the project structure, admonitions not to do certain things it would otherwise do (like in Python it’s common for it to generate code to import inside of functions which can cause runtime errors). I’m experimenting with a tree sitter MCP to see if I can make it aware of the structure of the entire project in a more compact way without all of the code in the context window, we will see where that goes.
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.
I haven't used Claude Code, but I have used Windsurf, Cursor, and Continue. They all do well with their own "rules" files. I essentially understand that as something similar to a System prompt sent before a chat session. I even have pretty specific rules on styling that are unique to me, and it generally follows those.
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.
Another thing Claude loves is fixing type errors by vomiting up conditionals 10 levels deep that check for presence, and type, and time of day, and age of the universe before it fixes the actual type issue..
> as i was lying in bed on a sleepless night. i realized i hadn’t learnt a new concept in weeks. i had built a few useful apps with ai, but a nagging question kept me awake - what was the point of it all if i didn’t learn a thing?
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.
> to become a cog that will be the first to be replaced
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.
And if you're not doing it to get a job, it's either much better or worse, though I suspect worse. The other buckets are likely that you're doing it to learn something new (which you won't retain anything and thus it's a waste of time) or you are only interested in the end product, which will be subpar compared to comparable professionally developed products. It's hard to see a good use case for "vibe coding" beyond viral examples like the flight simulator game made by an influencer.
This has been the majority of my professional coding experience since the 90's ::shrug::. Having to take ownership of some Java Spring application felt a lot like stepping through an assembly program or some random ROM. Each line of code just returns values and modifies a bunch of other stuff at the same time and you slowly build up a mental model of what it's doing and what it's trying to do!
The way I approach is, I try to design or solve the issue first to the best of my ability, then I let the LLM give me its solution. Compare and take whatever is useful. I know this is not the most effective way, but it's the way I feel like I'm still thinking and not becoming super dependent.
I find that even though I have to spend time understanding what the llm wrote, it's still faster and less energy sapping than if i write the code myself.
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.
i've learned a ton from ai suggestions, but right now its like 5-10% of suggestions. If that number was any higher i might not have the motivation to open the black box
... 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)
> One problem I have is that AI is writing code I don't understand completely, yet I'm still responsible for it.
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.
No, with vibe coding you are not a reviewer an editor or an author, quoting from the source:
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.
No, they actually have the files pane on the left, live preview mid-top, terminal errors mid-bottom, and the agent on the right. no looking at code.
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.
The vibes are coming from changing to actual product (design, UX, functionality) and not from the code. The code in fact doesn't matter at all. At this point that's only ok for throwaway prototypes (but for those it's quite wonderful), the more the application requires careful maintainable engineering, you need to read every line and leash the LLM. It's a bit of a continuum between the two edges in reality.
> No, with vibe coding you are not a reviewer an editor or an author, quoting from the source:
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.
I don't think I've ever seen that actually happen, if you mean reading a meaningful amount of the dep's code.
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.
Considering a library is just a component of the application and not the whole application itself. And one can typically understand the inputs and outputs of a library without having to know the detailed functionally of the code behind the library. I would say yes, it is different.
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
If one compares software produced by AI with software developed by a "remote team", from the rest of the org's point of view it is the same. It has to go through a QA process and then made available in prod. The real issues start when obscure errors start to happen or there is an outage and suddenly no one knows how to fix it.
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.
"...coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking."
For a more comprehensive treatment of this insight, see: Programming as Theory Building by Peter Naur
> coding isn’t about the finished product. its a lot like writing
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.
Meanwhile, my last big employer "couldn't motivate the expense" of a hardware upgrade for the most productive dev on the team (who spends a large part of their time waiting for CI jobs and builds) of <1/4 of their monthly pay. That should be a no-brainer and paid off itself quickly.
I do not believe that corps make rational decisions around these matters.
I would wager 80% of places that write software have almost trivial ways to get that 5% improvement. Between ci/cd, static checkers, upgrading IDEs, and just aligning practices between everyone, I think you can easily improve at 50% of places.
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.
>I would wager 80% of places that write software have almost trivial ways to get that 5% improvement.
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.
If AI increases programmer productivity by just 5% it is easily worth it.
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.
These seem to be terrible reasons to give up on using AI, although they might be valid reason to stop using AI a certain way.
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.
"Vibe coding" is a very certain way to use LLMs (one where you treat code the same way a junior Java SWE reads generated JVM bytecode), which is what the OP is about. They agree with your point.
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.
I know. I was commenting about how giving up on that kind of methodology should not mean that you should not be using AI for software development at all.
"that’s when it struck me. coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking."
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 a death trap for juniors just starting out, as it kills critical thinking and understanding what a computer is. And a guaranteed paycheck for people with the experience to clean up the resulting messes. I hope...
Vibe coding is what I’m selfishly expecting to take out many projects and keep my principal level swe skills in demand. Someone will have to mop all the vibes up when it’s time to deliver products.
Honestly, I've made a career fixing other people's messes. Vibe coding just means a larger market, but the terrible, unmaintainable, non-extendable code has been around since the beginning and grows every year.
Coding will not be done by juniors anymore. We are quickly progressing to humans no longer needing to learn machine langauage (syntax) and computers better developing code by interpreting human languages (english).
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
Same promise all the no-code or low-code app builders claim. Anyone who has done a serious project with LLM help knows it is no where near able to do half the things needed to run a project.
I have a theory that all the people who truly believe this are either not software developers or have spent their whole career writing boring, cookie-cutter code.
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 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.
Vibe coding hasn't really hampered my critical thinking. It just means I get ideas into practice faster, and it means that for new concepts I can get to itterating much faster.
Perhaps I have the concept wrong, because half the time I'm still editing code by hand.
I agree, and I think it's a continuum. I can say "make me an Instagram clone" and then come back after 100 agent loops and no looking at the code. Or I can outline the architecture, the components, service layer, data structures etc in a back and forth with the LLM and then have it do the minutia implementation.
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)
If you edit the code, instead of the prompt to the AI, it's not vibe coding. Vibe coding is letting the AI write the code, and only testing the output application.
"I am even consciously scaling back on copilot use now whenever possible, and prioritizing Google search, reading documentation, blog posts and stackoverflow now."
Very soon we will run out of human written articles.
This implies that humans will stop writing such articles, which won't happen. It may be more difficult to find them but some sites will likely cater specifically to this so you know you can just search for that site.
Every time I've tried to get LLMs to create something they quickly get to the point where they fail miserably. It can do boilerplate, it can do straightforward things which have been done a billion times, it can come up with 50 ideas 10 of which are decent and not obvious... but it can't go beyond a certain complexity, it can't use mildly obscure libraries, it can't get major versions of libraries straight, it invents API calls that don't exist.
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.
> One of the biggest wastes of human talent is corporations hiring people to solve the same problems over and over and over.
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
There is a disturbing overlap between the things LLMs are most helpful with... and the things that are arguably deficiencies with root-problems to be fixed in the realm of framework/library design, project onboarding, or documentation.
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 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.
I'm not convinced the two are necessarily mutually exclusive. Surely a skilled developer could make use of AI to produce stuff faster, while still understanding everything and making sure the code is well written (well generated?)
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
Just coupled with that quote, that’s like saying publishers don’t care about the writing process, they just care about whether the book sells.
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.
Yes there are businesses (game companies?) which just want to get a thing out the door, sell it, and move on to the next thing. But I don't think that's how most software businesses function. Usually software is iterated on and maintained, and you've got a problem if nobody has invested time in understanding how that software actually works.
Maybe, but the vast majority of software isn't written by, or for, software businesses. It's written by internal teams for businesses whose main product is insurance, or retail sales operations, or cabinet manufacturing, or real estate, etc.
To quote Copilot, "According to recent data, nearly 70% of top economic performers use their own software to differentiate themselves from competitors."
Virtually all businesses (even non-tech businesses) balance performance, reliability, cost, and revenue. Outages/bugs/crashes cost money, some can be fatal. They care.
> From a business perspective, they don't care about this.
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.
There is definitely space for a happy medium. Asking AI for individual functions and assembling them like lego blocks allows for a higher level of control and agency while still accelerating things a bit
+1. Software developers has long leveraged "someone else" writing code for their projects— be that "someone else" another human, via libraries, platforms, frameworks, etc. Or a computer, using codegen tools, compilers, etc. Sometimes it's to save tediousness, sometimes to save time, sometimes to leverage better code than one could've written.
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.
"that’s when it struck me. coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking."
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.
> coding isn’t about the finished product. its a lot like writing. its about the process.
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.
I feel like the fundamental bottleneck of software dev velocity will be human brains ability to understand the code being made. We can’t deploy code / packages / systems / apps we don’t deeply understand, no matter if those components were written in 3 weeks by a team of devs or in 3 seconds by GPT-7, we’re still responsible for it when it gets into users hands, and we’re not gonna deploy stuff that we don’t know how it works. Because at the end of the day it’s our necks on the line if something goes wrong and we’re asked to fix it. We can’t just point the finger at AI, which means we’ll always have to understand what we’re putting out there in the world, and that’s essentially what our jobs will be in the future. The one who’s accountable for the software systems put into production.
vibe coding and coding using AI can be two different things. Vibe coding is to build apps using AI without rigorous review and understanding about the code behind, while you can still do so to review every line of the code that AI generates. So don't blame AI but the way you interact with AI.
Hand coded will always win for bespoke projects (and any hard tech startup is a bespoke project).
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.
In simple terms, AI can make developers more productive, but it takes experienced engineers to get good results. Mediocre developers are still outputting mediocre code, albeit a lot faster than they used to. If you don't have the mental model to achieve what you want, and are just following what chatpgpt spits out, you're going to get torched sooner rather than later.
I was programming 14 years without LLM so I'm not sure I can relate, but -
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.
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.
When I first heard the term, I thought it was meant to be derogatory. But I think that's because I personally hate the word "vibe"; lately it seems overused (mainly by gen-z'ers and younger millennials) to the point of being somewhat meaningless.
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.
> that’s when it struck me. coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking.
To me coding is a tool to get things done, not something I intrinsically like or value
In the 80s you could "vibe code" by copying lines of basic out of a magazine and then change values to play.
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.
I'm in my 40s now; I was a big lowercase-only typist back in the '90s and much of the '00s. I still do it when using messaging platforms, but tend to use proper capitalization elsewhere, like here.
Funny how it's coming back, with the younger generation embracing it. Everything cycles, I guess.
i've been writing lowercase only since the 90s and i'm a first year millennial
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
I hate that vibe coding is even a thing, kind of.I have no issue with people using AI to help them, but just letting the AI generate code and constantly copying and pasting until you get something you like shouldn't be considered any type of coding IMO.
When you're just starting out, especially if you're young, programming feels like it's about the journey more than the destination. You can feel yourself growing and learning, and it's incredibly addicting because you feel like nothing's out of reach.
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.
Yeah, this makes me feel so sad because as somebody who's been a programmer for about 15 years now, there is definitely an advantage that we have because we actually know how to code.
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.
I think because there is not as much training material on those, the output usually is not very good. And those who are interested in learning haskell or rust usually have more passion. Therefore, from both sides of the problem, it's at least a better end position compared to JavaScript.
"Vibe Coding" is just simply not sustainable. I've yet to see any tool that can make edit after edit after edit to the core code base without making mistakes unless a developer is watching carefully.
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?
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.
There are ample opportunities to learn more about software development regardless of experience. It's a bit of an n+1 problem. If you're just building CRUD apps, I can understand how one might plateau in their knowledge, but even that can have a broad scope.
But for a recent example, I learned to stop worrying and love macros in Elixir. Even `defmodule` and `def/defp` are themselves macros.
OP didn't say money is the only reason things are worth doing, he said that things can be worth doing solely for money. There's a big difference between the two.
Ofcourse, you will be. Remember how people said I will not be using smart phone? Yeah they do use smart phone now. Actually, it is not your choice. Where I work, it is a mandate to use coding assistant. Just like how people were asked to use spreadsheet software instead of good old calculators and ledger books.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
Using AI to assist in locating the right library function or similar to documentation has been effective to speed up my development, but I really dislike using it to autocomplete whole functions or large swathes of code, because then I have to spend time reading and understanding code I didn't write. This doesn't ultimately feel "faster" when I own what I write.
I'm using AI for grepping, analyzing flow, finding cross-project dependencies, etc. It provides a significant speedup. But the generated code is mediocre at best. Changes look like patches on fabric, not woven threads. AI generates too much redundant code.
One other use-case I've found effective for it is assisting with API development and defining API specs. For example, I've uploaded API definitions in YAML and previously provided instructions about the API standards I want to impose and to ensure consistency as I build new things, this saves some degree of effort between writing -> linting -> fixing -> linting again if I have it just validate and fix any minor inconsistencies.
How do you use AI to grep?
Grepping is an oversimplification: I ask for specific use cases, for listing all code paths that perform some action, etc. It works really well.
How though? Do you setup RAG for this? Large context window? What do you use?
I started with Repomix as an MCP server plus system prompt to reduce the scope to single packages. However, it still consumed too many tokens (and polluted the context with useless information). I used Gemini, context size wasn't an issue, but it was too expensive. Now I just use Cursor, it has built-in indexing with embeddings (I assume).
Try Claude Code. It’s perfect for this type of use case.
Maybe for translating a natural language query into a regular expression that can be ingested by grep.
Oh god no. Then you have three problems: ai, regular expressions, and your original problem.
I had a similar situation - I once wanted to grab some web pages and parse them in Python, and was going to use Python's built-in libraries for that, and use BeautifulSoup to parse them. But then I realized I'd have to read enormous code bases I didn't write, which felt like it would take forever.
(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.)
I’ve had good results using Claude Code by specifically coaching it on how its implementation should be. It’s not always perfect and sometimes I do have to try again, but it’s remarkably effective when given enough guidance.
If only I could figure out how to reliably keep it from adding useless comments or preserving obsolete interfaces for “backward compatibility”…
Me too, I’m using Roo Code and have substantially updated the system prompt to describe the project standards, correct way to restart the services and inspect the logs, specific hints about the frameworks im using and how to use DI and patterns, like think about what kind of code it’s writing and where to put it in the project structure, admonitions not to do certain things it would otherwise do (like in Python it’s common for it to generate code to import inside of functions which can cause runtime errors). I’m experimenting with a tree sitter MCP to see if I can make it aware of the structure of the entire project in a more compact way without all of the code in the context window, we will see where that goes.
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.
I haven't used Claude Code, but I have used Windsurf, Cursor, and Continue. They all do well with their own "rules" files. I essentially understand that as something similar to a System prompt sent before a chat session. I even have pretty specific rules on styling that are unique to me, and it generally follows those.
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.
Another thing Claude loves is fixing type errors by vomiting up conditionals 10 levels deep that check for presence, and type, and time of day, and age of the universe before it fixes the actual type issue..
> as i was lying in bed on a sleepless night. i realized i hadn’t learnt a new concept in weeks. i had built a few useful apps with ai, but a nagging question kept me awake - what was the point of it all if i didn’t learn a thing?
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.
> to become a cog that will be the first to be replaced
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.
And if you're not doing it to get a job, it's either much better or worse, though I suspect worse. The other buckets are likely that you're doing it to learn something new (which you won't retain anything and thus it's a waste of time) or you are only interested in the end product, which will be subpar compared to comparable professionally developed products. It's hard to see a good use case for "vibe coding" beyond viral examples like the flight simulator game made by an influencer.
One problem I have is that AI is writing code I don't understand completely, yet I'm still responsible for it.
Vibe coding seems like an echo from the future.
This has been the majority of my professional coding experience since the 90's ::shrug::. Having to take ownership of some Java Spring application felt a lot like stepping through an assembly program or some random ROM. Each line of code just returns values and modifies a bunch of other stuff at the same time and you slowly build up a mental model of what it's doing and what it's trying to do!
The way I approach is, I try to design or solve the issue first to the best of my ability, then I let the LLM give me its solution. Compare and take whatever is useful. I know this is not the most effective way, but it's the way I feel like I'm still thinking and not becoming super dependent.
I find that even though I have to spend time understanding what the llm wrote, it's still faster and less energy sapping than if i write the code myself.
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.
Just make sure the LLM doesn't go crazy with the mocks. I had some fully mocked tests before that didn't do anything (apart from looking green).
I tell jest to output code coverage stats so I can see the llm generated tests do actually cover the code I want tested.
But yeah, I agree they go overboard and add tests that don't even test anything due to excessive mocking
i've learned a ton from ai suggestions, but right now its like 5-10% of suggestions. If that number was any higher i might not have the motivation to open the black box
It's like importing libraries.
... 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)
> One problem I have is that AI is writing code I don't understand completely, yet I'm still responsible for it.
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.
No, with vibe coding you are not a reviewer an editor or an author, quoting from the source:
Odd. How can one get the vibes without looking at the code? Like gleaming diamond vibes versus confused spaghetti vibes.
I think the vibes refer to the running software, not to the code itself. I hate the whole concept deeply.
No, they actually have the files pane on the left, live preview mid-top, terminal errors mid-bottom, and the agent on the right. no looking at code.
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.
The vibes are coming from changing to actual product (design, UX, functionality) and not from the code. The code in fact doesn't matter at all. At this point that's only ok for throwaway prototypes (but for those it's quite wonderful), the more the application requires careful maintainable engineering, you need to read every line and leash the LLM. It's a bit of a continuum between the two edges in reality.
> No, with vibe coding you are not a reviewer an editor or an author, quoting from the source:
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.
[dead]
> code I don't understand completely, yet I'm still responsible for it.
Is this different than any given library?
You can and should audit your dependencies.
I don't think I've ever seen that actually happen, if you mean reading a meaningful amount of the dep's code.
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.
Considering a library is just a component of the application and not the whole application itself. And one can typically understand the inputs and outputs of a library without having to know the detailed functionally of the code behind the library. I would say yes, it is different.
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
If one compares software produced by AI with software developed by a "remote team", from the rest of the org's point of view it is the same. It has to go through a QA process and then made available in prod. The real issues start when obscure errors start to happen or there is an outage and suddenly no one knows how to fix it.
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.
"...coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking."
For a more comprehensive treatment of this insight, see: Programming as Theory Building by Peter Naur
https://pages.cs.wisc.edu/~remzi/Naur.pdf
Excellent find. Is this Naur of Backus-Naur fame?
> coding isn’t about the finished product. its a lot like writing
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.
> even as little as 50%
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.
Meanwhile, my last big employer "couldn't motivate the expense" of a hardware upgrade for the most productive dev on the team (who spends a large part of their time waiting for CI jobs and builds) of <1/4 of their monthly pay. That should be a no-brainer and paid off itself quickly.
I do not believe that corps make rational decisions around these matters.
I would wager 80% of places that write software have almost trivial ways to get that 5% improvement. Between ci/cd, static checkers, upgrading IDEs, and just aligning practices between everyone, I think you can easily improve at 50% of places.
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.
>I would wager 80% of places that write software have almost trivial ways to get that 5% improvement.
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.
If AI increases programmer productivity by just 5% it is easily worth it.
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.
> Code is an implementation detail.
It’s worse. Code is a liability.
These seem to be terrible reasons to give up on using AI, although they might be valid reason to stop using AI a certain way.
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.
"Vibe coding" is a very certain way to use LLMs (one where you treat code the same way a junior Java SWE reads generated JVM bytecode), which is what the OP is about. They agree with your point.
I know. I was commenting about how giving up on that kind of methodology should not mean that you should not be using AI for software development at all.
That font has reminded me that “aesthetically pleasing” and “readable” are two very different things
I physically felt the dragging in my eyes while reading it
They should have vibe coded the HTML instead.
"that’s when it struck me. coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking."
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.
Vibe coding is a death trap for juniors just starting out, as it kills critical thinking and understanding what a computer is. And a guaranteed paycheck for people with the experience to clean up the resulting messes. I hope...
Vibe coding is what I’m selfishly expecting to take out many projects and keep my principal level swe skills in demand. Someone will have to mop all the vibes up when it’s time to deliver products.
Honestly, I've made a career fixing other people's messes. Vibe coding just means a larger market, but the terrible, unmaintainable, non-extendable code has been around since the beginning and grows every year.
Coding will not be done by juniors anymore. We are quickly progressing to humans no longer needing to learn machine langauage (syntax) and computers better developing code by interpreting human languages (english).
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
Same promise all the no-code or low-code app builders claim. Anyone who has done a serious project with LLM help knows it is no where near able to do half the things needed to run a project.
Skill issue, you aren't vibe coding properly. I am not joking.
I agree with this individual. Prompt engineering is a real skill right now. Will it be in 10 years? WHo knows
Right now, sure. But when a 21 year old is picking a field they need to think 10 years from now.
Agreed
I have a theory that all the people who truly believe this are either not software developers or have spent their whole career writing boring, cookie-cutter code.
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.
God, software is about to get so much worse, isn't it.
Absolutely. If you thought Electron was bloated, prepare yourself for Electron running a bunch of AI-generated slop.
The year is 2028. You open the AI enabled calculator app on your desktop. Your GPU overheats and catches fire.
Thanks for the laugh!
[dead]
> Vibe coding is here to stay.
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.
Software isn't just built. It has to be maintained over time.
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.
I look forward to reading war stories about debugging "vibes" applications during a 3am outage.
What is coding without critical thinking?
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.
Vibe coding hasn't really hampered my critical thinking. It just means I get ideas into practice faster, and it means that for new concepts I can get to itterating much faster.
Perhaps I have the concept wrong, because half the time I'm still editing code by hand.
I agree, and I think it's a continuum. I can say "make me an Instagram clone" and then come back after 100 agent loops and no looking at the code. Or I can outline the architecture, the components, service layer, data structures etc in a back and forth with the LLM and then have it do the minutia implementation.
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)
If you edit the code, instead of the prompt to the AI, it's not vibe coding. Vibe coding is letting the AI write the code, and only testing the output application.
"I am even consciously scaling back on copilot use now whenever possible, and prioritizing Google search, reading documentation, blog posts and stackoverflow now."
Very soon we will run out of human written articles.
This implies that humans will stop writing such articles, which won't happen. It may be more difficult to find them but some sites will likely cater specifically to this so you know you can just search for that site.
Every time I've tried to get LLMs to create something they quickly get to the point where they fail miserably. It can do boilerplate, it can do straightforward things which have been done a billion times, it can come up with 50 ideas 10 of which are decent and not obvious... but it can't go beyond a certain complexity, it can't use mildly obscure libraries, it can't get major versions of libraries straight, it invents API calls that don't exist.
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.
> One of the biggest wastes of human talent is corporations hiring people to solve the same problems over and over and over.
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.
that's not the level i'm talking about
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
There is a disturbing overlap between the things LLMs are most helpful with... and the things that are arguably deficiencies with root-problems to be fixed in the realm of framework/library design, project onboarding, or documentation.
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.
> Vibe coding is here to stay.
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.
I'm not convinced the two are necessarily mutually exclusive. Surely a skilled developer could make use of AI to produce stuff faster, while still understanding everything and making sure the code is well written (well generated?)
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
It can. You can just feed pretty much any LLM an OpenAPI spec and tell it a moderately known language and it'll implement a client for that API.
Just coupled with that quote, that’s like saying publishers don’t care about the writing process, they just care about whether the book sells.
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.
Yes there are businesses (game companies?) which just want to get a thing out the door, sell it, and move on to the next thing. But I don't think that's how most software businesses function. Usually software is iterated on and maintained, and you've got a problem if nobody has invested time in understanding how that software actually works.
Maybe, but the vast majority of software isn't written by, or for, software businesses. It's written by internal teams for businesses whose main product is insurance, or retail sales operations, or cabinet manufacturing, or real estate, etc.
To quote Copilot, "According to recent data, nearly 70% of top economic performers use their own software to differentiate themselves from competitors."
"stay" - we'll see how this vibe codes lives and breathes for years
Virtually all businesses (even non-tech businesses) balance performance, reliability, cost, and revenue. Outages/bugs/crashes cost money, some can be fatal. They care.
As I’ve been saying, many companies already expect you to use an LLM to speed up coding. Tasks now can be shipped in hours, not days or weeks.
I can't remember the last time I had a "reasonable time frame" to build something for a business.
> From a business perspective, they don't care about this.
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.
The first significant business to face serious legal, regulatory, and reputational consequences for vibe slop will put a pretty quick end to that...
There is definitely space for a happy medium. Asking AI for individual functions and assembling them like lego blocks allows for a higher level of control and agency while still accelerating things a bit
+1. Software developers has long leveraged "someone else" writing code for their projects— be that "someone else" another human, via libraries, platforms, frameworks, etc. Or a computer, using codegen tools, compilers, etc. Sometimes it's to save tediousness, sometimes to save time, sometimes to leverage better code than one could've written.
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.
That’s a healthy view. Unfortunately, the industry is heading towards agentic coders at 200mph.
"that’s when it struck me. coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking."
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.
> coding isn’t about the finished product. its a lot like writing. its about the process.
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.
I feel like the fundamental bottleneck of software dev velocity will be human brains ability to understand the code being made. We can’t deploy code / packages / systems / apps we don’t deeply understand, no matter if those components were written in 3 weeks by a team of devs or in 3 seconds by GPT-7, we’re still responsible for it when it gets into users hands, and we’re not gonna deploy stuff that we don’t know how it works. Because at the end of the day it’s our necks on the line if something goes wrong and we’re asked to fix it. We can’t just point the finger at AI, which means we’ll always have to understand what we’re putting out there in the world, and that’s essentially what our jobs will be in the future. The one who’s accountable for the software systems put into production.
vibe coding and coding using AI can be two different things. Vibe coding is to build apps using AI without rigorous review and understanding about the code behind, while you can still do so to review every line of the code that AI generates. So don't blame AI but the way you interact with AI.
Hand coded will always win for bespoke projects (and any hard tech startup is a bespoke project).
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.
In simple terms, AI can make developers more productive, but it takes experienced engineers to get good results. Mediocre developers are still outputting mediocre code, albeit a lot faster than they used to. If you don't have the mental model to achieve what you want, and are just following what chatpgpt spits out, you're going to get torched sooner rather than later.
I was programming 14 years without LLM so I'm not sure I can relate, but -
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".
What is vibe coding anyway?
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.
https://youtu.be/IACHfKmZMr8?si=kiTOU7NpoQEwC6kj&t=45
Can you use text in clear prose, please?
They are vibe replying.
This seems to be where all this vibe coding thing started:
https://x.com/karpathy/status/1886192184808149383
> i’m breaking up with vibe coding. here’s why.
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.
When I first heard the term, I thought it was meant to be derogatory. But I think that's because I personally hate the word "vibe"; lately it seems overused (mainly by gen-z'ers and younger millennials) to the point of being somewhat meaningless.
This. This times a thousand.
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?
Sometimes the problem is just dealing with someone else's janky spreadsheet and obstinance...
There is no inherent honor in toil.
> that’s when it struck me. coding isn’t about the finished product. its a lot like writing. its about the process. its about how you approach a problem. its critical thinking.
To me coding is a tool to get things done, not something I intrinsically like or value
>had built a few useful apps with ai, but a nagging question kept me awake - what was the point of it all if i didn’t learn a thing?
His point is juxtaposed with a mid-sentence break, but it is non-contradictory. This thought confounds me greatly.
In the 80s you could "vibe code" by copying lines of basic out of a magazine and then change values to play.
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.
Ironic that the text is unreadable on the website (bad font choice, no capitalization), and I had to use an AI summarizer.
Independent of the opinion expressed, I dig the minimalistic, typewriter-style blog format demonstrated here.
I don't dislike it but I don't love the lack of capitalization. Not really sure why that trend is on the uptick.
Zoomers that write in lowercase because it's more "chill"; go figure. It's a pretty reliable indicator that you're talking to someone < 25 years old.
I'm in my 40s now; I was a big lowercase-only typist back in the '90s and much of the '00s. I still do it when using messaging platforms, but tend to use proper capitalization elsewhere, like here.
Funny how it's coming back, with the younger generation embracing it. Everything cycles, I guess.
i've been writing lowercase only since the 90s and i'm a first year millennial
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
I hate that vibe coding is even a thing, kind of.I have no issue with people using AI to help them, but just letting the AI generate code and constantly copying and pasting until you get something you like shouldn't be considered any type of coding IMO.
But hey, I'm getting old, it is what it is.
Don't: vibe code.
Do: agentic code.
What's agentic code?
When you're just starting out, especially if you're young, programming feels like it's about the journey more than the destination. You can feel yourself growing and learning, and it's incredibly addicting because you feel like nothing's out of reach.
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.
Yeah, this makes me feel so sad because as somebody who's been a programmer for about 15 years now, there is definitely an advantage that we have because we actually know how to code.
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.
My understanding is that typed languages like Haskell and Rust are even easier with vibe coding than untyped.
I think because there is not as much training material on those, the output usually is not very good. And those who are interested in learning haskell or rust usually have more passion. Therefore, from both sides of the problem, it's at least a better end position compared to JavaScript.
"Vibe Coding" is just simply not sustainable. I've yet to see any tool that can make edit after edit after edit to the core code base without making mistakes unless a developer is watching carefully.
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).
To each their own, of course. But
> 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.
> what was the point of it all if i didn’t learn a thing?
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.
> As a senior software engineer, AI still surprises me with concepts I didn't know about from time to time.
Example?
There are ample opportunities to learn more about software development regardless of experience. It's a bit of an n+1 problem. If you're just building CRUD apps, I can understand how one might plateau in their knowledge, but even that can have a broad scope.
But for a recent example, I learned to stop worrying and love macros in Elixir. Even `defmodule` and `def/defp` are themselves macros.
How much did you get paid for this comment? And if not, why was it worth writing?
OP didn't say money is the only reason things are worth doing, he said that things can be worth doing solely for money. There's a big difference between the two.
To each their own.
This doesn't really make your point more coherent. Would you mind spelling it out?
nice poem. this is why we should push jobs to AI and create art ourselves.
Ofcourse, you will be. Remember how people said I will not be using smart phone? Yeah they do use smart phone now. Actually, it is not your choice. Where I work, it is a mandate to use coding assistant. Just like how people were asked to use spreadsheet software instead of good old calculators and ledger books.
[flagged]
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
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.
[flagged]