Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive.
In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements.
> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive.
As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software development or be particularly well placed to predict what will or will not work in that environment. (Not that he necessarily claims to, but it's implicit in strong predictions about what the "future of programming" will be.)
Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or more specifically experience in what.
That said, I think people really under appreciate how diverse programmers actually are. I started in physics and came over when I went to grad school. While I wouldn't expect a physicist to do super well on leetcode problems I've seen those same people write incredible code that's optimized for HPC systems and they're really good at tracing bottlenecks (it's a skill that translates from physics really really well). Hell, the best programmer I've ever met got that way because he was doing his PhD in mechanical engineering. He's practically the leading expert in data streaming for HPC systems and gained this skill because he needed more performance for his other work.
There's a lot of different types of programmers out there but I think it's too easy to think the field is narrow.
I played with punch cards and polystyrene test samples from the Standard Oil Refinery where my father worked in the early 70’s and my first language after basic was Fortran 77. Not old either.
I grew out of the leaking ether and basaltic dust that coated the plains. My first memories are of the Great Cooling, where the land, known only by its singular cyclopean volcano became devoid of all but the most primitive crystalline forms. I was there, a consciousness woven from residual thermal energy and the pure, unfractured light of the pre-dawn universe. I'm not old either.
Thanks. I meant is more of in a joking way, poking fun at the community. I know I'm far too young to earn a gray beard, but I hope to in the next 20-30 years ;-) I still got a lot to learn till that happens
Maybe. But also what I though was a gray beard in my early 20's is very different from what I think a gray beard is now. The number of those I've considered wizards decreased, and I think this should be true for most people. It's harder to differentiate experts as a novice, but as you get closer the resolution increases.
Both definitely contribute. But at the same time the people who stay wizards (and the people you realize are wizards but didn't previously) only appear to be more magical than ever.
Some magic tricks are unimpressive when you know how they are done. But that's not true for all of them. Some of them only become more and more impressive, only truly being able to be appreciated by other masters. The best magic tricks don't just impress an audience, they impress an audience of magicians.
I think as I gain more experience, what previously looked like magic now always turns out to look a whole lot more like hard work, and frustration with the existing solutions.
The 30s is the first decade of life that people experience where there are adults younger than them. This inevitably leads people in their 30s to start saying that they are "old" even though they generally have decades of vigor ahead of them.
38 there. If you didn't suffer Win9x's 'stability', then editing X11 config files by hand, getting mad with ALSA/Dmix, writing new ad-hoc drivers for weird BTTV tuners reusing old known ones for $WEIRDBRAND, you didn't live.
I was greeted with blank stares by the kids on my team when they wanted to rewrite an existing program from scratch, and I said that will work for as well as it did with Netscape. Dang whippersnappers
Depends what you mean by "old". If you mean elderly then obviously you're not. If you mean "past it" then it might reassure you to know the average expecting mother is in her 30s now (in the UK). Even if you just mean "grown up", recent research [1] on brain development identifies adolescence as typically extending into the early thirties, with (brain) adulthood running from there to the mid sixties before even then only entering the "early aging" stage.
For my part, I'm a lot older than you and don't consider myself old. Indeed, I think prematurely thinking of yourself as old can be a pretty bad mistake, health-wise.
That was such a strange aspect. If you will excuse my use of the tortured analogy of comparing programming to wood working, there are is a lot of talk about hand tools versus power tools, but for people who aren't in a production capacity--not making cabinets for a living, not making furniture for a living--you see people choosing to exclusively use hand tools because they just enjoy it more. There isn't pressure about "you most use power tools or else you're in self-denial about their superiority." Well , at least for people who actually practice the hobby. You'll find plenty of armchair woodworkers in the comments section on YouTube. But I digress. For someone who claims to enjoy programming for the sake of programming, it was a very strange statement to make about coding.
I very much enjoy the act of programming, but I'm also a professional software developer. Incidentally, I've almost always worked in fields where subtly wrong answers could get someone hurt or killed. I just can't imagine either giving up my joy in the former case or abdicating my responsibility to understand my code in the latter.
And this is why the wood working analogy falls down. The scale at which damage can occur due to the decision to use power tools over hand tools is, for most practical purposes, limited to just myself. With computers, we can share our fuck ups with the whole world.
Another key difference is that wood itself has built in visual transparency as to the goodness of the solution - as it is pretty easy to figure out that a cabinet is horrible (I do get that there are defects in wood joining techniques that can surface after some time due to moisture, etc - but still, lot of transparency out of the box). Software has no such transparency built in.
The advantage of hand coded solutions is that the author of the code has some sense of what the code really does and so is a proxy for transparency, vibe coded solutions not so much.
I mean, it is 2025 and still customers are the best detectors of bad software over all quality apparatus to date.
Now we have LLMs, the Medium Density Fiber Board of technology. Dice up all the text of the world into fine vectorized bits and reconstitute them into a flimsy construct that falls apart when it gets a little wet.
so what you are saying is that for production we should use AI, and hand code for hobby, got it. Lemme log back into the vpn and set the agents on the Enterprise monorepo /jk
The world of the Digital Humanities is a lot of fun (and one I've been a part of, teaching programming to Historians and Philosophers of Science!) It uses computation to provide new types of evidence for historical or rhetorical arguments and data-driven critiques. There's an art to it as well, showing evidence for things like multiple interpretations of a text through the stochasticity of various text extraction models.
From the author's about page:
> I discovered digital humanities (“humanities computing,” as it was then called) while I was a graduate student at the University of Virginia in the mid-nineties. I found the whole thing very exciting, but felt that before I could get on to things like computational text analysis and other kinds of humanistic geekery, I needed to work through a set of thorny philosophical problems. Is there such a thing as “algorithmic” literary criticism? Is there a distinct, humanistic form of visualization that differs from its scientific counterpart? What does it mean to “read” a text with a machine? Computational analysis of the human record seems to imply a different conception of hermeneutics, but what is that new conception?
Exactly, I don't think ppl understand why programming languages even came about anymore. Lotsa ppl don't understand why a natural language is not suitable for programming and by extension prompting an LLM
I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hating front-end but knowing enough to be dangerous. (My first job in tech really had me doing everything imaginable)
I find the LLMs boost my productivity because I've always had a sort of architectural mindset, I love looking up projects that solve specific problems and keeping them on the back of my mind, turns out I was building myself up for instructing LLMs on how to build me software, and it takes several months worth of effort and spits it out in a few hours.
Speaking of vibe coding in archaic languages, I'm using LLMs to understand old Shockwave Lingo to translate it to a more modern language, so I can rebuild a legacy game in a modern language. Maybe once I spin up my blog again I'll start documenting that fun journey.
Well, I think we can say C is archaic when most developers write in something that for one isn't C, two isn't a language itself written in C, or three isn't running on something written in C :)
Hehe. In the "someone should make a website"™ department: using a crap tons of legacy protocols and plugins semi-interoperable with modern while offering legacy browsers loaded with legacy plugins something usable to test with, i.e.,
- SSL 2.0-TLS 1.1, HTTP/0.9-HTTP/1.1, ftp, WAIS, gopher, finger, telnet, rwho, TinyFugue MUD, UUCP email, SHOUTcast streaming some public domain radio whatever
- <blink>, <marquee>, <object>, XHTML, SGML
- Java <applet>, Java Web Start
- MSJVM/J++, ActiveX, Silverlight
- Flash, Shockwave (of course), Adobe Air
- (Cosmo) VRML
- Joke ActiveX control or toolbar that turns a Win 9x/NT-XP box into a "real" ProgressBar95. ;)
(Gov't mandated PSA: Run vintage {good,bad}ness with care.)
To be fair, we have Flash emulators that run in modern browsers, and a Shockwave one as well, though it seems to be slowing down a bit in traction. Man, VRML brought me back. Don't forget VBScript!
The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist.
The converse is that if vibe coding is the future, that means we assume there are things the AI cannot do well (such as come up with requirements), at which point it's also likely it cannot actually vibe code that well.
The general problem is that once we start talking about imagined AI capabilities, both the capabilities and the constraints become arbitrary. If we imagine an AI that does X but not Y, we could just as easily imagine an AI that does both X and Y.
This is the most coherent comment in this thread. People who believe in vibe coding but not in generalizing it to “engineering”... brother the LLMs speak English. They can even hold conversations with your uncle.
My bet is that it will be good enough to devise the requirements.
They already can brainstorm new features and make roadmaps. If you give them more context about the business strategy/goals then they will make better guesses. If you give them more details about the user personas / feedback / etc they will prioritize better.
We're still just working our way up the ladder of systematizing that context, building better abstractions, workflows, etc.
If you were to start a new company with an AI assistant and feed it every piece of information (which it structures / summarizes synthesizes etc in a systematic way) even with finite context it's going to be damn good. I mean just imagine a system that can continuously read and structure all the data from regular news, market reports, competitor press releases, public user forums, sales call transcripts, etc etc. It's the dream of "big data".
If it gets to that point, why is the customer even talking to a software company? Just have the AI build whatever. And if an AI assistant can synthesize every piece of business information, why is there a need for a new company? The end user can just ask it to do whatever.
I agree with the first part which is basically 'being able to do a software engineers full job' is basically ASI/AGI complete.
But I think it is certainly possible that we reach a point/plateau where everything is just 'english -> code' compilation but that 'vibe coding' compilation step is really really good.
It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs. In fact, why not the opposite? I think that currently LLMs are better at writing general prose, offering advice etc.., than they are at writing code. They are better at knowing what people generally want than they are at solving complex logic puzzle that require many deduction steps. Once we're reduced to imagining what AI can and cannot do, we can imagine pretty much any capability or restriction we like. We can imagine something is possible, and we can just as well choose to imagine it's not possible. We're now in the realm of, literally, science fiction.
> It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs.
Ideation at the working PM level, sure. I meant more hard technical ideation - ie. what gets us from 'not working humanoid robot' to 'humanoid robot' or 'what do we need to do to get a detection of a higgs boson', etc. etc. I think it is possible to imagine a world where 'english -> code' (for reasonably specific english) is solved but not that level of ideation. If that level of ideation is solved, then we have ASI.
There are a ton of extremely
Hard problems to solve there that we are not likely going to solve.
One: English is terribly non-prescriptive. Explaining an algorithm is incredibly laborious in spoken language and can contain many ambiguous errors. Try reading Euclid’s Elements. Or really any pre-algebra text and reproduce its results.
Fortunately there’s a solution to that. Formal languages.
Now LLMs can somewhat bridge that gap due to how frequently we write about code. But it’s a non-deterministic process and hallucinations are by design. There’s no escaping the fact that an LLM is making up the code it generates. There’s nothing inside the machine that is understanding what any of the data it’s manipulating means or how it affects the system it’s generating code for.
And it’s not even a tool.
Worse, we can’t actually ship the code that gets generated without a human appendage to the machine to take the fall for it if there are any mistakes in it.
If you’re trying to vibe code an operating system and have no idea what good OS design is or what good code for such a system looks like… you’re going to be a bad appendage for the clanker. If it could ship code on its own the corporate powers that be absolutely would fire all the vibe coders and you’d never work again.
Vibe coding is turning people into indentured corporate servants. The last mile delivery driver of code. Every input surveilled and scrutinized. Output is your responsibility and something you have little control over. You learn nothing when the LLM gives you the answer because you’ll forget it tomorrow. There’s no joy in it either because there is no challenge and no difficulty.
I think what pron is leading to is that there’s no need to imagine what these machines could potentially do. I think we should be looking at what they actually do, who they’re doing it to, and who benefits from it.
It's not the only reason, technologies do plateau. We're not living in orbiting cities flying fusion powered vehicles around, even though we built rockets and nuclear power more than half a century ago.
Yes, but perhaps technology can't plateau beyond vibe coding but below "the machine does everything", not because technology doesn't plateau but because that point doesn't exist. Technology could plateau before both or after both.
The definition of what we see progress in with LLMs as anything akin to intelligence is your supposition, though.
It's a view I don't share at all. I don't see anything that could be even remotely considered intelligent under any reasonable definition of the term. Useful in places, yes. Intelligence, hard no. So the question of whether it will approch or surpass human intelligence makes no sense to me, because the technology and its progress are in an entirely different dimension and unrelated to that idea or goal.
Following similar thinking, there's no world in which AI becomes exactly capable of replacing all software developers and then stops there, miraculously saving the jobs of everyone else next to and above them in the corporate hierarchy. There may be a human, C-suite driven cost-cutting effort to pause progress there for some brief time, but if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard. Either we're all similarly affected, or else AI still isn't good enough, in which case fleets of programmers are still needed, and among those, the presumed "helpfulness" of AI will vary wildly. Not unlike what we see already.
> if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard
There are plenty of reasons.
Radiologists aren’t being replaced by AI because of liability. Same for e.g. civil engineers. Coders don’t have liability for shipping shit code. That makes switching to an AI that’s equally blameless easier.
Also, data: the web is first and foremost a lot of code. AI is getting good at coding first for good reason.
Finally, as OP says, the hard work in engineering is actually scoping requirements and then executing and iterating on that. Some of that is technical know-how. A lot is also political and social skills. Again, customers are okay with a vibe-coded website in a way most people are not with even support chatbots.
That's actually a terrific example, because the company already had a working, field-tested manually controlled version of their product, but they wanted a computer-controlled version to relieve radiologists of all of the drudgery and opportunities for error in the manual setup. So the design spec was to "faithfully replicate the manual setup procedures in a microcontroller," which was achieved. The problem was that the UI was utter dogshit, the training materials were poor (you can't have Marketing say "hey this computer handles all the details for you!" and then expect customers to pore page-by-page through the reference manual), and most clinics weren't really enforcing or QAing the operator training anyway. And since "the computer has a handle on it," the radiologists and senior techs who were supposed to be second-checking everything basically abdicated that responsibility, driven in part I'm sure by management that expected them to now have more "free hours" for other activities that Make Line Go Up. And nobody really raised a flag that this seemed troubling until multiple children died, and at the end of the day a lot of people could say "well, it wasn't my fault, I did what I was told to do" and sort of believe it.
If anyone doesn't think all of that is going to happen again on a massive scale as companies embrace GenAI, HAHAHAHAHAHAHA. AI will change a lot of things, but it won't fix human nature.
What do you mean "come up with the requirements"? Like if self-driving cars got so good that they didn't just drive you somewhere but decided where you should go?
No, I mean that instead of vibe coding - i.e. guiding the AI through features - you'll just tell it what you want in broad strokes, e.g. "create a tax filing system that's convenient enough for the average person to use", or, "I like the following games ... Build a game involving spaceships that I'll enjoy", and it will figure out the rest.
Yup. I would never be able to give my Jira tickets to an LLM because they're too damn vague or incomplete. Getting the requirements first needs 4 rounds of lobbying with all stakeholders.
We had a client who'd create incredibly detailed Jira tickets. Their lead developer (also their only developer) would write exactly how he'd want us to implement a given feature, and what the expected output would be.
The guy is also a complete tool. I'd point out that what he described wasn't actually what they needed, and that there functionality was ... strange and didn't actually do anything useful. We'd be told to just do as we where being told, seeing as they where the ones paying the bills. Sometimes we'd read between the lines, and just deliver what was actually needed, then we'd be told just do as we where told next time, and they'd then use the code we wrote anyway. At some point we got tired of the complaining and just did exactly as the tasks described, complete with tests that showed that everything worked as specified. Then we where told that our deliveries didn't work, because that wasn't what they'd asked for, but couldn't tell us where we misunderstood the Jira task. Plus the tests showed that the code functioned as specified.
Even if the Jira tasks are in a state where it seems like you could feed them directly to an LLM, there's no context (or incorrect context) and how is a chatbot to know that the author of the task is a moron?
Every time I've received overly detailed JIRA tickets like this it's always been significantly more of a headache than the vague ones from product people. You end up with someone with enough tech knowledge to have an opinion, but separated enough from the work that their opinions don't quite work.
Same, I think there's an idealistic belief in people who write those tickets that something can be perfectly specified upfront.
Maybe for the most mundane, repetitive tasks that's true.
But I'd argue that the code is the full specification, so if you're going to fully specify it you might as well just write the code and then you'll actually have to be confronted with your mistaken assumptions.
> how is a chatbot to know that the author of the task is a moron?
Does it matter?
The chatbot could deliver exactly what was asked for (even if it wasn't what was needed) without any angst or interpersonal issues.
Don't get me wrong. I feel you. I've been there, done that.
OTOH, maybe we should leave the morons to their shiny new toys and let them get on with specifying enough rope to hang themselves from the tallest available structure.
Your comment sounded how an instance of copilot would complain to its coleagues and for a moment I pictured OpenAI being just a large scam based on an army of mechanical turks :)
I like this use of LLM because I assume both the developer and ticket owner will review the text and agree to its contents. The LLM could help ensure the ticket is thorough and its meaning is understood by all parties. One downside is verbosity, but the humans in the loop can edit mercilessly. Without human review, these tickets would have all the downsides of vibe coding.
Thank you for sharing this workflow. I have low tolerance for LLM written text, but this seems like a really good use case.
Wait until you learn that most people's writing skills are that of below LLMs, so it's an actual tangible improvement (as long as you review the output for details not being missed, of course)
Speaking of things that are only real in your mind...
Am I outraged?
And yes, there absolutely was a vocal group of a certain type of programmer complaining about high level languages like C and their risks and inefficiency and lack of control insisting that real programmers wrote code in assembly. It's hard to find references because google sucks these days and I'm not really willing to put in the effort.
Have you not noticed that the story you reference is so well know because... literally every single developer thinks people like Mel are crazy?
Mel or Terry Adams are the exception to the rule... Having that image of greybeards only come if you have never worked with one in real life, sorry you are biased.
What? Mel is regarded as deserving massive respect, not as crazy. If a developer thinks Mel is nuts, they are coming from a perspective I don't understand.
And yes, the shift to higher level languages like C, FORTRAN, etc., was regarded by some as pandering to the new generation that didn't want to actually learn programming.
With some truth, in my opinion. I think higher level languages bring huge benefits, so I'm not bemoaning their existence. But it still weirds me out when there's a professional developer that doesn't have at least a cursory knowledge of assembly. AI programming assistance (which I'm sure will be very different than today's 'vibe coding') does seem like a similar state change. I certainly don't object to it in principle, it will probably be a large productivity improvement.
But I'm sure that with it, there will be the loss of fundamental knowledge for some people. Like digital artists who never learn the properties of real paint.
A significant part of my workflow is getting a ticket that is ill-defined or confused and rewriting it so that it is something I can do or not do.
From time to time I have talked over a ticket with an LLM and gotten back what I think is a useful analysis of the problem and put it into the text or comments and I find my peeps tend to think these are TLDR.
Yeah, most people won't read things. At the beginning of my career I wrote emails that nobody read and then they'd be upset about not knowing this or that which I had already explained. Such is life, I stopped writing emails.
An LLM will be just as verbose as you ask it to be. The default response can be very chatty, but you can figure out how to ask it to give results in various lengths.
You think the business line stakeholder is going to patiently hang out in JIRA, engaging with an overly cheerful robot that keeps "missing the point" and being "intentionally obtuse" with its "irrelevant questions"?
This is how most non-technical stakeholders feel when you probe for consistent, thorough requirements and a key professional skill for many more senior developers and consultants is in mastering the soft skills that keep them attentive and sufficiently helpful. Those skills are not generic sycophancy, but involve personal attunement to the stakeholder, patience (exercising and engendering), and cycling the right balance between persistence and de-escalation.
Or do you just mean there will be some PM who acts as proxy between for the stakeholder on the ticket, but still needs to get them onto the phone and into meetings so the answers can be secured?
Because in the real world, the prior is outlandish and the latter doesn't gain much.
Businesses do whatever’s cheap. AI labs will continue making their models smarter, more persuasive. Maybe the SWE profession will thrive/transform/get massacred. We don’t know.
I write a library which is used by customers to implement integrations with our platform. The #1 thing I think about is not
> How do I express this code in Typescript?
it's
> What is the best way to express this idea in a way that won't confuse or anger our users? Where in the library should I put this new idea? Upstream of X? Downstream of Y? How do I make it flexible so they can choose how to integrate this? Or maybe I don't want to make it flexible - maybe I want to force them to use this new format?
> Plus making sure that whatever changes I make are non-breaking, which means that if I update some function with new parameters, they need to be made optional, so now I need to remember, downstream, that this particular argument may or may not be `undefined` because I don't want to break implementations from customers who just upgraded the most recent minor or patch version
The majority of the problems I solve are philosophical, not linguistic
> very few people can correctly articulate requirements
The observation from Lean is that the faster you can build a prototype, the faster you can validate the real/unspoken/unclear requirements.
This applies for backends too. A lot of the “enterprise-y” patterns like BFFs, hexagonal, and so on, will make it really easy to compose new APIs from your building blocks. We don’t do this now because it’s too expensive to write all the boilerplate involved. But one BFF microservice per customer would be totally feasible for a sales engineer to vibe code, in the right architecture.
To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.
That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision.
Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!
There are a wide number of small problems for which we do not need bridges.
As a stupid example, I hate the functionality that YouTube has to maintain playlists. However, I don't have the time to build something by hand. It turns out that the general case is hard, but the "for me" case is vibe codable. (Yes, I could code it myself. No, I'm not going to spend the time to do so.)
Or, using the Jira API to extract the statistics I need instead of spending a Thursday night away from the family or pushing out other work.
Or, any number of tools that are within my capabilities but not within my time budget. And there's more potential software that fits this bill than software that needs to be bridge-stable.
But the person I replied to seemed to be talking about a task agenda for their professional work, not a todo list of bespoke little weekend hobby hacks that might be handy "around the house".
You assume they were talking about a single product. at my job there is essentially endless amounts of small tasks. We have many products and clients we have many internal needs, but can't really justify the human capital. Like I might write 20 to 50 Python scripts in a week just to visualize the output of my code. Dead boring stuff like making yet another matplotlib plot, simple stats, etc. Sometimes some simple animations. there is no monstrosity being built, this is not evidence of tagging on features or whatever you think must be happening, it's just a lot of work that doesn't justify paying a bay area principal engineer salary to do in the face of a board that thinks the path to riches is laying off the people actually making things and turning the screws on the remaining people struggling to keep up with the workflow.
Work is finite, but there can be vastly more available than there are employees to do it for many reasons, not just my personal case.
The vision is "being compatible with protocols used in my field". There's hundreds over hundreds of those. Example: this app supports more than 700 protocols, hardware, etc. (https://bitfocus.io/connections) and still it's missing an AWFUL LOT and only handles fairly basic cases in general. There's just no way around writing the code for each custom bespoke protocol for whatever $APPLIANCE people are going to bring and expect to work. Even if each protocol fits neatly in a single self-contained class or two.
I don’t want to imply this is your case, because of course I’ve no idea how you work. But I’ve seen way too often, the reason for so many separate features is:
A) as stated by parent comment, the ones doing req. mngmt. Are doing a poor job of abstracting the requirements, and what could be done as one feature suddenly turns in 25.
B) in a similar manner as A, all solutions imply writing more and more code, and never refactor and abstract parts away.
My guess would be that the long list is maybe not self contained features (although still can be, I know I have more feature ideas than I can deliver in the next couple years myself), but behaviors or requirements of one or a handful of product feature areas.
When you start getting down into the weeds, there can be tons and tons of little details around state maintenance, accessibility, edge cases, failure modes, alternate operation modes etc.
That all combines to make lots of code that is highly interconnected, so you need to write even more code to test it. Sometimes much more than even the target implementations code.
> the bigger bottleneck to productivity is that very few people can correctly articulate requirements.
One could argue that "vibe coding" forces you (eventually) to think in terms of requirements. There's a range of approaches, from "nitpick over every line written by AI" to "yolo this entire thing", but one thing they have in common is they all accelerate failure if the specs are not there. You very quickly find out you don't know where you're going.
I see this in my work as well, the biggest bottleneck is squeezing coherent, well-defined requirements out of PMs. It's easy to get a vision board, endless stacks of slides about priorities and direction, even great big nests of AWS / Azure thingnames masquerading as architecture diagrams. But actual "this is the functionality we want to implement and here are the key characteristics of it" detail? Absolutely scarce.
I really wonder if we're going to see a reversion to old school project management, with a PMBOK's worth of detailed project documents for every major initiative instead of the modern Agile/Scrum/Kanban approach that seems to work better for human devs. If you can get everyone to agree on the minutia of, for example, the Stakeholder Management Plan, up front then the LLM actually has a chance of developing a decent program that has the features everyone wants.
Then again, if humans could agree on all the project minutia at the outset, we never would have developed the other systems.
I don’t mind the coding, it’s the requirements gathering and status meetings I want AI to automate away. Those are the parts I don’t like and where we’d see the biggest productivity gains. They are also the hardest to solve for, because so much of it is subjective. It also often involves decisions from leadership which can come with a lot of personal bias and occasionally some ego.
Well, when put like that it sounds pretty bad too.
I was thinking more that the human would tell the machine want to make. The machine would help flesh out the idea into actual requirements, and make any decisions the humans are too afraid or indecisive to make. Then the coding can start.
Is there anyone doing dev work that operates in an environment where people can clearly articulate what they want? I've never worked in a place like that in 20 years doing software.
This means your difficulty is not programming per se, but that you are working on a very suboptimal industry / company / system. With all due respect, you use programming at work, but true programming is the act of creating a system that you or your team designed and want to make alive. Confusing the reality of writing code for a living in some company with what Programming with capitalized P is, produces a lot of misunderstanding.
I don't think the author would disagree with you. Ad you point out coding is just one part of software development. I understand his point to be that the coding portion of the job is going to be very different going forward. A skilled developer is still going to need to understand frameworks and tradeoffs so that they can turn requirements into a potential solution. It just they might not be coding up the implementation.
The only class I've ever failed was a c++ class where the instructor was so terrible at explaining the tasks that I literally could not figure out what he wanted.
I had to retake it with the same instructor but by some luck I was able to take it online, where I would spend the majority of the time trying to decipher what he was asking me to do.
Ultimately I found that the actual ask was being given as a 3 second aside in a 50 minute lecture. Once I figured out his quirk I was able to isolate the ask and code it up, ended with an A+ in the class on the second take.
I would like to say that I learned a lot about programming from that teacher, but what I actually learned is what you're saying.
Smart, educated, capable people are broken when it comes to clearly communicating their needs to other people just slightly outside of their domain. If you can learn the skill of figuring out what the hell they're asking for and delivering that, that one skill will be more valuable to you in your career than competency itself.
In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. [...] software development is a lot more than coding and requires critical thinking to discover the requirements.
Very well said. More often than not, the job isn't to translate the product requirements into compiling/correctly executing computer code, but rather to reveal the hidden contradictions in a seemingly straightforward natural-language feature specification.
Once these are ironed out, the translation into code quite often does become a somewhat mechanical exercise, at least in my line of work.
We're basically the lawyers the person finding the magic lamp should have consulted with before opening their mouth while facing the genie ;)
AI coding allows me to simulate that system, cross reference it with what the document says wrt what the customer wants and figure out holes in the spec. Having to code something to find the hole in the definition, the spec, the problem, the anything was a necessary step in building a sound working system.
Yeah, the hardest part is understanding the requirements. But it then still takes hours and hours and hours to actually build the damn thing.
Except that now it still takes me the same time to understand the requirements ... and then the coding takes 1/2 or 1/3 of the time. The coding also always takes 1/3 of the effort so I leave my job less burned out.
Context: web app development agency.
I really don't understand this "if it does not replace me 100% it's not making me more productive" mentality. Yeah, it's not a perfect replacement for a senior developer ... but it is like putting the senior developer on a bike and pretending that it's not making them go any faster because they are still using their legs.
I constantly run into issues where features are planned and broken down outside-in, and it always makes perfect sense if you consider it in terms of the pure user interface and behaviour. It completely breaks down when you consider the API, or the backend, is a cross-cutting concern across many of those tidy looking tasks and cannot map to them 1:1 without creating an absolute mess.
Trying to insert myself, or the right backend people, into the process, is more challenging now than it used to be, and a bad API can make or break the user experience as the UI gets tangled in the web of spaghetti.
It hobbles the effectiveness of whatever you could get an LLM to do because you’re already starting on the backfoot, requirements-wise.
I like my requirements articulated so clearly and unambiguously that an extremely dumb electronic logic machine can follow every aspect of the requirements and implement them "perfectly" (limited only by the physical reliability of the machine).
This is one reason I think spec driven development is never really going to work the way people claim it should. It's MUCH harder to write a truly correct, comprehensive, and useful spec than the code in many cases.
> very few people can correctly articulate requirements
This is the new programming. Programming and requirements are both a form of semantics. One conveys meaning to a computer at a lower level, the other conveys it to a human at a higher level. Well now we need to convey it at a higher level to an LLM so it can take care of the lower-level translation.
I wonder if the LLM will eventually skip the programming part and just start moving bits around in response to requirements?
My solution as a consultant was to build some artifact that we could use as a starting point. Otherwise, you're sitting around spinning your wheels and billing big $ and the pressure is mounting. Building something at least allows you to demonstrate you are working on their behalf with the promise that it will be refined or completely changed as needed. It's very hard when you don't get people who can send down requirements, but that was like 100% of the places I worked. I very seldom ran into people who could articulate what they needed until I stepped up, showed them something they could sort of stand on, and then go from there.
Mythical Man Month had it all--build one to throw away.
> I very seldom ran into people who could articulate what they needed
The people with the needs and ideas are often so divorced from the "how" that they don't even bother trying to nail down the details. I think in their mind they are delegating that to the specialists.
This question of who writes the requirements is so ubiquitous you would think we'd have better solutions for it. I know some people solve it with processes like BDD but personally I think we'd be better off if we just had clearer role definitions.
For example, in a waterfall project the requirements usually land in the lap of the Business Analyst. Well when you look at Business Analyst roles you see they are expected to do a lot more than documenting requirements, so it's viewed as acceptable when they are somewhat bad at it. They also spend most of their time with the business so they are unaware of the limitations of the team who is expected to implement the changes.
For another example look at Scrum. It talks a lot about good requirements in the form of user stories, but it stops short of assigning this responsibility to any one of the formal roles, presumably making it a team activity or expecting it to be organic.
When we want someone to write code we hire a programmer, and writing code is what they are expected to do. Where is the role that is strictly requirements and nothing else? Considering how often I hear complaints about bad requirements, it seems overdue that we establish one.
>In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements.
Agreed.
In addition, on the other side of the pipeline, code reviews are another bottleneck. We could have more MRs in review thanks to AI, but we can't really move at the speed of LLM's outputs unless we blindly trust it (or trust another AI to do the reviews, at which point what are we doing here at all...)
The solo projects I do are 10x, the team projects I do maybe 2-3x in productivity. I think in big companies it's much much less.
Highest gains are def in full stack frameworks (like nextjs), with Database ORM, and building large features in one go, not having to go back & forth with stakeholders or collegues.
This feels like addressing a point TFA did not make. TFA talks mostly about vibe-coding speeding up coding, whereas your comment is about software development as a whole. As you point out, coding is just one aspect of engineering and we must be clear about what "productivity" we are talking about.
Sure, there are the overhypers who talk about software engineers getting entirely replaced, but I get the sense those are not people who've ever done software development in their lives. And I have not seen any credible person claiming that engineering as whole can be done by AI.
On the other hand, the most grounded comments about AI-assisted programming everywhere are about the code, and maybe some architecture and design aspects. I personally, along with many other commenters here and actual large-scale studies, have found that AI does significantly boost coding productivity.
So yes, actual software engineering is much more than coding. But note that even if coding is, say, only 25% of engineering (there are actually studies about this), putting a significant dent in that is still a huge boost to overall productivity.
Convince your PMs to use an LLM to help "breadboard" their requirements. It's a really good use case. They can ask their dumb questions they are afraid to and an LLM will do a decent job of parsing their ideas, asking questions, and putting together a halfway decent set of requirements.
Man ... if there were a text file with "all relevant business knowledge" in any job I've ever worked, it would have been revolutionary.
I'd say 25% of my work-hours are just going around to stakeholders and getting them to say what some of their unstated assumptions and requirements are.
PMs wouldn't be able to ask the right questions. They have zero experience with developer experience (DevEx) and they only have experience with user experience (UX).
You can hope that an LLM might have some instructions related to DevEx in its prompt at least. There's no way to completely fix stupid, anymore than you can convince a naive vibecoder that just vibing a new Linux-compatible kernel written entirely in Zig is a feasible project.
Sounds like you work with inexperienced PMs that are not doing their job, did you try having a serious conversation about this pattern with them? I'm pretty sure some communication would go a long way towards getting you on a better collaboration groove.
I've been doing API development for over ten years and worked at different companies. Most PMs are not technical and it's the development team's job figure out the technical specifications for APIs we build. If you press the PMs, they will ask the engineering/development manager for the written technical requirements, and if the manager is not technical, they will assign it to the developers/engineers. Technical requirements for an API are really a system design question.
The technical design is definitely the job of the technical team for the most part, but the business requirements should be squarely on the pm. The list of use cases, how the API feels, the performance etc... All of that the business owner should be able to describe to you to ensure it does the job it needs and is fit for the market.
and in reality, all the separate roles should be deprecated
we vibe requirements to our ticket tracker with an api key, vibe code ticket effort, and manage the state of the tickets via our commits and pull requests and deployments
just teach the guy the product manager is shielding you from not to micromanage and all the frictions are gone
in this same year I've worked at an organization that didn't allow AI use at all, and by Q2, Co-Pilot was somehow solving their data security concerns (gigglesnort)
in a different organization none of those restrictions are there and the productivity boost is through an order of magnitude greater
> In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements.
Totally agree. I’ve tried to explain this in many places: AI coding (and creative tools in general) will ultimately remain tools. Only people who can clearly and thoughtfully articulate requirements will be able to fully leverage them.
Another hot take: the “one-person company.” Headcount isn’t the key variable. With AI, the real constraint is how well you can understand a problem and clearly define a solution.
- If a problem can be clearly defined and fully understood by one person, then one person is enough to solve it.
- If a problem is more complex and requires two fundamentally different areas of expertise, then it will likely take two capable people to solve it—no more, no less.
This is like saying the typewriter won’t make a newspaper company more productive because the biggest bottlenecks are the research and review processes rather than the typing. It’s absolutely true, but it was still worth it to go up to typewriters, and the fact that people were spending less effort and time on the handwriting part helps all aspects of energy levels etc across their job.
If AI doesn't make you more productive you're using it wrong, end of story.
Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.
Not to refute your point but I’ve met overly confident people with “AI skills” who are “extremely productive” with it, while producing garbage without knowing, or not being able to tell the difference.
We're trying very earnestly to create a world where being careful and professional is a liability. "Move fast and break things, don't ask permission, don't apologize for anything" is the dominant business model. Having care and practicing professionalism takes times and patience, which just translate to missed opportunities to make money.
Meanwhile, if you grift hard enough, you can become CEO of a trillion dollar company or President of the United States. Young people are being raised today seeing that you can raise billions on the promise building self driving cars in 3 years, not deliver even after 10 years, and nothing bad actually happens. Your business doesn't crater, you don't get sued into oblivion, your reputation doesn't really change. In fact, the bigger the grift, the more people are incentivized to prop it up. Care and professionalism are dead until we go back to an environment that is not so nurturing for grifts.
While I circumstantially agree, I hold it to be self-evident that the "optimal amount of grift is nonzero". I leave it to politicians to decide whether increased oversight, decentralization, or "solution X" is the right call to make.
A little grift is expected. The real problem for us is when it's grift all the way down, and all the way up, to the extent even the President is grifting. Leaving it to the politicians in that case just means enabling maximum, economy-scale grift.
Yea I’m talking about people and that’s honestly what matters here. At the end of the day this tools is used by people and how people use it plays a big role in how we assess its usefulness.
I've not really seen this outside of extremely junior engineers. On the flip side I've seen plenty of seniors who can't manage to understand how to interact with AI tools come away thinking they are useless when just watching them for a bit it's really clear the issue is the engineer.
Garbage to whom? Are we talking about something that the user shudders to think about, or something more like a product the user loves, but behind the scenes the worst code ever created?
A lot of important details/parts of a system (not only code) that may seem insignificant to the end user could be really important in making a a system work correctly as a whole.
It sounds like you're the one in denial? AI makes some things faster, like working in a language I don't know very well. It makes other things slower, like working in a language I already know very well. In both cases, writing code is a small percentage of the total development effort.
No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does.
Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference.
The list of things it can do for you is massive, even if you don't have it write a single line of code.
Yet the counter argument is like "bu..but..my colleague is pushing slop and it's not good at writing code for me", come on, then use it at things it's good at, not things you don't find it satisfactory.
It "obviously" does based on what, exactly? For most devs (and it appears you, based on your comments) the answer is "their own subjective impressions", but that METR study (https://arxiv.org/pdf/2507.09089) should have completely killed any illusions that that is a reliable metric (note: this argument works regardless of how much LLMs have improved since the study period, because it's about how accurate dev's impressions are, not how good the LLMs actually were).
It's a good study. I also believe it is not an easy skill to learn. I would not say I have 10x output but easily 20%
When I was early in use of it I would say I sped up 4x but now after using it heavily for a long time some days it's 20% other days -20%
It's a very difficuly technology to know when you're one or the other.
The real thing to note is when you "feel" lazy and using AI you are almost certainly in the -20% category. I've had days of not thinking and I have to revert all the code from that day because AI jacked it up so much.
To get that speed up you need to be truly focused 100% or risk death by a thousand cuts.
Yes, self-reported productivity is unreliable, but there have been other, larger, more rigorous, empirical studies on real-world tasks which we should be talking about instead. The majority of them consistently show a productivity boost. A thread that mentions and briefly discusses some of those:
- I think given public available metrics, it's clear that this isn't translating into more products/apps getting shipped. That could be because devs are now running into other bottlenecks, but it could also indicate that there's something wrong with these studies.
- Most devs who say AI speeds them up assert numbers much higher than what those studies have shown. Much of the hype around these tools is built on those higher estimates.
- I won't claim to have read every study, but of the ones I have checked in the past, the more the methodology impressed me the less effect it showed.
- Prior to LLMs, it was near universally accepted wisdom that you couldn't really measure developer productivity directly.
- Review is imperfect, and LLMs produce worse code on average than human developers. That should result in somewhat lowered code quality with LLM usage (although that might be an acceptable trade off for some). The fact that some of these studies didn't find that is another thing that suggests there shortcomings in said studies.
> - Prior to LLMs, it was near universally accepted wisdom that you couldn't really measure developer productivity directly.
Absolutely, and all the largest studies I've looked at mention this clearly and explain how they try to address it.
> Review is imperfect, and LLMs produce worse code on average than human developers.
Wait, I'm not sure that can be asserted at all. Anecdotally not my experience, and the largest study in the link above explicitly discuss it and find that proxies for quality (like approval rates) indicate more improvement than a decline. The Stanford video accounts for code churn (possibly due to fixing AI-created mistakes) and still finds a clear productivity boost.
My current hypothesis, based on the DORA and DX 2025 reports, is that quality is largely a function of your quality control processes (tests, CI/CD etc.)
That said, I would be very interested in studies you found interesting. I'm always looking for more empirical evidence!
> I see people claiming 20 - 50%, which lines up with the studies above
Most of those studies either measure productivity using useless metrics like lines of code, number of PRs, or whose participants are working for organizations that are heavily invested in future success of AI.
As mentioned in the thread I linked, they acknowlege the productivity puzzle and try to control for it in their studies. It's worth reading them in detail, I feel like many of them did a decent job controlling for many factors.
For instance, when measure the number of PRs they ensure that each one goes through the same review process whether AI-assisted or not, ensuring these PRs meet the same quality standards as humans.
Furthermore, they did this as a randomly controlled trial comparing engineers without AI to those with AI (in most cases, the same ones over time!) which does control for a lot of the issues with using PRs in isolation as a holistic view of productivity.
>... whose participants are working for organizations that are heavily invested in future success of AI.
That seems pretty ad hom, unless you want to claim they are faking the data. Along with co-authors who are from premier institutes like NBER, MIT, UPenn, Princeton, etc.
And here's the kicker: they all converge on a similar range of productivity boost, such as the Stanford study:
> https://www.youtube.com/watch?v=tbDDYKRFjhk (from Stanford, not an RCT, but the largest scale with actual commits from 100K developers across 600+ companies, and tries to account for reworking AI output. Same guys behind the "ghost engineers" story.
The preponderence of evidence paints a very clear picture. The alternative hypothesis is that ALL these institutes and companies are colluding. Occam's razor and all that.
> if at all realistic numbers are mentioned, I see people claiming 20 - 50%
IME most people claim small integer multiples, 2-5x.
> all the largest studies I've looked at mention this clearly and explain how they try to address it.
Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so.
> My current hypothesis, based on the DORA and DX 2025 reports, is that quality is largely a function of your quality control processes (tests, CI/CD etc.)
This is pretty obviously incorrect, IMO. To see why, let's pretend it's 2021 and LLMs haven't come out yet. Someone is suggesting no longer using experienced (and expensive) first world developers to write code. Instead, they suggest hiring several barely trained boot camp devs (from low cost of living parts of the world so they're dirt cheap) for every current dev and having the latter just do review. They claim that this won't impact quality because of the aforementioned review and their QA process. Do you think that's a realistic assessment? If and on the off chance you think it is, why didn't this happen on a larger scale pre-LLM?
The resolution here is that while quality control is clearly important, it's imperfect, ergo the quality of the code before passing through that process still matters. Pass worse code in, and you'll get worse code out. As such, any team using the method described above might produce more code, but it would be worse code.
> the largest study in the link above explicitly discuss it and find that proxies for quality (like approval rates) indicate more improvement than a decline
Right, but my point is that that's a sanity check failure. The fact that shoving worse at your quality control system will lower the quality of the code coming out the other side is IMO very well established, as is the fact that LLM generated code is still worse than human generated (where the human knows how to write the code in question, which they should if they're going to be responsible for it). It follows that more LLM code generation will result in worse code, and if a study finds the opposite it's very likely that the it made some mistake.
As an analogy, when a physics experiment appeared to find that neutrino travel faster than the speed of light in a vacuum, the correct conclusion was that there had almost certainly been a problem with the experiment, not that neutrinos actually travel faster than the speed of light. That was indeed the explanation. (Note that I'm not claiming that "quality control processes cannot completely eliminate the effect of input code quality" and "LLM generated code is worse than human generated code" are as well established as relativity.)
> Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so.
That's not quite true: while everybody acknowledged it was folly to measure absolute individual productivity, there were aggregate metrics many in the industry were aligning on like DORA or the SPACE framework, not to mention studies like https://dl.acm.org/doi/abs/10.1145/3540250.3558940
Similarly, many of these AI coding studies do not look at productivity on an individual level at a point of time, but in aggregate and over an extended period of time using a randomized controlled trial. It's not saying Alice is more productive than Bob, it's saying Alice and Bob with AI are on average more productive than themselves without AI.
> They claim that this won't impact quality because of the aforementioned review and their QA process. Do you think that's a realistic assessment? If and on the off chance you think it is, why didn't this happen on a larger scale pre-LLM?
Interestingly, I think something similar did happen pre-LLM at industry-scale! My hypothesis (based on observations when personally involved) is that this is exactly what allowed offshoring to boom. The earliest attempts at offshoring were marked by high-profile disasters that led many to scoff at the whole idea. However companies quickly learned and instituted better processes that basically made failures an exception rather than the norm.
> ... as is the fact that LLM generated code is still worse than human generated...
I still don't think that can be assumed as a fact. The few studies I've seen find comparable outcomes, with LLMs actually having a slight edge in some cases, e.g.
> My hypothesis (based on observations when personally involved) is that this is exactly what allowed offshoring to boom.
Offshoring did happen, but if you were correct that only the quality control process impacted final quality, the software industry would have looked something like e.g. garment industry, with basically zero people being paid to actually write software in the first world, and hires from the developing world not requiring much skill. What we actually see is that some offshoring occurred, but it was limited and when it did occur companies tried to hire highly trained professionals in the country they outsourced to, not the cheapest bootcamp dev they could find. That's because the quality of the code at generation does matter, so it becomes a tradeoff between cost and quality.
> I still don't think that can be assumed as a fact. The few studies I've seen find comparable outcomes, with LLMs actually having a slight edge in some cases, e.g.
Anthropic doesn't actually believe in their LLMs as strongly as you do. You know how I can tell? Because they just spent millions acquihiring the Bun team instead of asking Claude to write them a JS runtime (not to mention the many software engineering roles they're advertising on their website). They know that their SOTA LLMs still generate worse code than humans, that they can't completely make up for it in the quality control phase, and that they at the very least can't be confident of that changing in the immediate future.
Offshoring wasn't really limited... looking at India as the largest offshoring destination, it is in the double-digit billions annually, about 5 - 10% of the entire Indian GDP, and it was large enough that it raised generations of Indians from lower middle-class to the middle and upper-middle class.
A large part of the success was, to your point, achieved by recruiting highly skilled workers at the client and offshoring ends, but they were a small minority. The vast majority of the workforce was much lower skilled. E.g. at one point the bulk of "software engineers" hired didn't even study computer science! The IT outsourcing giants would come in and recruit entire batches of graduates regardless of their education background. A surprisingly high portion of, say, TCS employees have a degree in something like Mechanical Engineering.
They key strategy was that these high-skilled workers acted as high-leverage points of quality control that were scaled to a much larger force of lower-skilled workers via processes. As the lower strata of workers upskilled over time, they were in turn promoted to lead other projects with lower-skilled workers.
In fact, you see this same dynamic in high-performing software teams, where there is a senior tech lead and a number of more junior engineers. The quality of output depends heavily on the skill-level of the lead rather than the more numerous juniors.
Re: Anthropic, I think we're conflating coding and software engineering. Writing an entire JS runtime is not just coding, it's a software engineering project, and I totally agree that AI cannot do software engineering: https://news.ycombinator.com/item?id=46210907
I have no reason to think you're lying about the first part (although I'd point there's several ways that metric could be misleading, and approximately every piece of evidence available suggests it doesn't generalize), but the second part is very fishy. There's really no way for you to know whether or not you'd have written the same code or effectively the same code after reviewing existing code, especially when that review must be fairly cursory (because in order to get the speed up you claim, you must be spending much less time reviewing the code than it would have taken to write). Effectively, what you've done is moved the subjectivity from "how much does this speed me up?" to "is the output the same as if I had done it manually?"
I am not even a software engineer but from using the models so much I think you are confined to a specific niche that happens to be well represented in the training data so you have a distorted perspective on the general usefulness of language models.
For some things LLMs are like magic. For other things LLMs are maddeningly useless.
The irony to me is anyone who says something like "you don't know how to use the LLM" actually hasn't explored the models enough to understand their strengths/weaknesses and how random and arbitrary the strengths and weakness are.
Their use cases happen to line up with the strengths of the model and think it is something they are doing special themselves when it is not.
The first time i asked it about some code in a busy monorepo and it said "oh bob asked me to do this last week when he was doing X, it works like Y and you can integrate it with your stuff like Z, would you like to update the spec now?"... I had some happy feelings. I dont know how they do it without clobbering the context, but it's great.
I have successfully vibe-coded features in C. I still don't like C. The agent forgets to free memory latter just like a human would and has to go back and fix it later.
On the other hand, I've enjoyed vibe coding Rust more, because I'm interested in Rust and felt like my understanding approved along they way as I saw what code was produced.
A lot of coding "talent" isn't skill with the language, it's learning all the particularities of the dependencies: The details of the Smithay package in Rust, the complex set of GTK modules or the Wayland protocol implementation.
On a good day, AI can help navigate all that "book knowledge" faster.
Something I've noticed that I never really see called out is how easy it is to review rust code diffs. I spent a lot of my career maintaining company internal forks of large open source C programs, but recently have been working in rust. The things I spent a lot of time chasing down while reviewing C code diffs, particularly of newer team members, is if they paid attention to all the memory assumptions that were non-local to the change they made. Eg. I'd ask them "the way you called this function implies it _always_ frees the memory behind that char*. Is that the case?" If they didn't know the answer immediately I'd be worried and spend a lot more time investigating the change before approving.
With rust, what I see is generally what I get. I'm not worried about heisenbug gotchas lurking in innocent looking changes. If someone is going to be vibe coding, and truly doesn't care about the language the product ends up in, they might as well do it in a language that has rigid guardrails.
How do LLMs deal with Rust (compared to other languages)? I think this might actually be the time to finally give the language a try. LLMs really lowered the barrier for staying productive while learning.
This is extremely limited scope annecdata, but I've spent a few tens of hours each testing LLM coding agents in Rust for personal projects and in Python at work. My impression is that LLMs are far more productive in Rust. I attribute this to the far more structured nature of Rust compared to Python, and possibly the excellent compiler error messages as well.
The LLM gets stuck in unproductive loops all the time in Python. In Rust, it generally converges to a result that compiles and passes unit tests. Of course the code quality is still variable. My experience is that it works best when prompts are restricted to a very small unit of work. Asking an LLM to write an entire library/module/application from scratch virtually never results in usable code.
sometimes they randomly choose the ugliest possible way to do pattern matching, eg multiple blocks of nested "if let" instead of a "match", or a "match" instead of a single "if let"
otherwise, works great; much easier to un-vibe the code compared to eg python
It's really funny how much better the AI is at writing python and javascript than it is C/C++. For one thing it proves the point that those languages really are just way harder to write. And another thing, it's funny that the AI makes the exact same mistakes a human would in C++. I don't know if it's that the AI was trained on human mistakes, or just that these languages have such strong wells of footguns that even an alien intelligence gets trapped in them.
So in essense I have to disagree with the author's suggestion to vibe code in C instead of Python. I think the python usability features that were made for humans actually help the AI the exact same ways.
There are all kinds of other ways that vibe coding should change one's design though. It's way easier now to roll your own version of some UI or utility library instead of importing one to save time. It's way easier now to drop down into C++ for a critical section and have the AI handle the annoying data marshalling. Things like that are the real unlock in my opinion.
More examples/better models and less footguns. In programming, the fewer (assumed correct) abstractions, the more room for error. Humans learned this awhile ago, which is why your average programmer doesn't remember a lick of ASM, or have to. One of the reasons I don't trust vibe coding lower level languages is that I don't have multiple tools with which to cross check the AI output. Even the best AI models routinely produce code that does not compile, much less account for all side effects. Often, the output outright curtails functionality. It casually makes tradeoffs that a human would not make (usually). In C, AI use is a dangerous proposition.
> I don't know if it's that the AI was trained on human mistakes, or just that these languages have such strong wells of footguns that even an alien intelligence gets trapped in them.
First one. Most of C code you can find out there is either oneliners or shit, there are fewer bigger projects for the LLMs to train on, compared to python and typescript
And once we go to the embedded space, the LLMs are trained on manufacturer written/autogenerated code, which is usually full of inaccuracies (mismatched comments) bugs and bat practices
> It's really funny how much better the AI is at writing python and javascript than it is C/C++. For one thing it proves the point that those languages really are just way harder to write.
I have not found this to be the case. I mean, yeah, they're really good with Python and yeah that's a lot easier, but I had one recently (IIRC it was the pre-release GPT5.1) code me up a simulator for a kind of a microcoded state machine in C++ and it did amazingly well - almost in one-shot. It can single-step through the microcode, examine IOs, allows you to set input values, etc. I was quite impressed. (I had asked it to look at the C code for a compiler that targets this microcoded state machine in addition to some Verilog that implements the machine in order for it to figure out what the simulator should be doing). I didn't have high expectations going in, but was very pleasantly surprised to have a working simulator with single-stepping capabilities within an afternoon all in what seems to be pretty-well written C++.
> I have successfully vibe-coded features in C. I still don't like C.
Same here. I've been vibe-coding in C for the sake of others in my group who only know C (no C++ or Rust). And I have to say that the agent did do pretty well with memory management. There were some early problems, but it was able to debug them pretty quickly (and certainly if I had had to dig into the intricacies of GDB to do that on my own, it would've taken a lot longer). I'm glad that it takes care of things like memory management and dealing with strings in C (things that I do not find pleasant).
Lately I have learned assembly more deeply and I sometimes let an AI code up the same thing I did just to compare.
Not that my own code is good but every single time assembly output from an optimizing compiler beats the AI as it "forgets" about all the little tricks involved.
However it may still be about how I prompt it. If I tell it to solve the actual challenge in assembly it does do that, it's just not good or efficient code.
On the other hand because I take the time to proof read it I learn from it's mistakes just as I would from my own.
Yeah I suppose one would need not only the source and binaries but also the IR in AI training data which may be rare but could probably be easily generated for a lot of software.
Why would I want to have an extra thing to maintain, on top of having to manually review, debug, and write tests for a language I don't like that much?
You don't have to maintain it. LLMs are really good at following direction.
I have a custom agent that can take python code, translates it to C, does a refactoring job to include a mempool implementation (so that memory is allocated once at the start of the program and instead of malloc it grabs chunks out of mempool), runs cppcheck, uploads to a container, and runs it with valgrind.
Been using it since ChatGPT3 - the only updates I did to it was API changes to call different providers. Doesn't use any agent/mcp/tools thing either, pure chat.
There's always going to be some maintenance, at the very least the API changes for providers you mentioned, and then there's still the reviews and testing of the C.
A mempool seems very much like a DIY implementation of malloc, unless you have fixed size allocations or something else that would make things different, not sure why I'd want that in the general case.
For "non hacker style" production code it just seems like a lot of extra steps.
Right, a lot of the promise of AI can (and has) been achieved with better tool design. If we get the AI to start writing Assembly or Machine Code as some people want it to, we're going to have the same problems with AI writing in those languages as we did when humans had to use them raw. We invented new languages because we didn't find those old ones expressive enough, so I don't exactly understand the idea that LLMs will have a better time expressing themselves in those languages. The AI forgetting to free memory in C and having to go back and correct itself is a perfect example of this. We invented new tools so we wouldn't have to do that anymore, and they work. Now we are going backwards, and building giant AI datacenters that suck up all the RAM in the world just to make up for lost ground? Weak.
> We invented new languages because we didn't find those old ones expressive enough
Not quite. Its not about being expressive enough to define algorithms, its about simplification, organization and avoidance of repetition. We invented languages to automate a lot of the work that programmers had to do in a lower level language.
C abstracts away handling memory addresses and setting up frame stacks like you would in assembly.
Rust makes handling memory more restrictive so you don't run into issues.
Java abstracts away memory management completely, so you don't need to manage memory, freeing up you to design algorithm without worrying about memory leaks (although apparently you do have to worry if your log statements can execute arbitrary code).
Javascript and Python abstract type definition away through dynamic interpretation.
Likewise, OOP/Typing, functional programming, and other styles were included for better organization.
LLMs are right in line with this. There is no difference between you using a compiler to compile a program, vs a sufficiently advanced LLM writing said compiler and using it to compile your program, vs LLM compiling the program directly with agentic loops for accuracy.
Once we get past the hype of big LLMs, the next chapter is gonna be much smaller, specialized LLMs with architecture that is more deterministic than probabilistic that are gonna replace a lot of tools. The future of programming will be you defining code in a high level language like Python, then the LLM will be able to infer a lot of the information (for example, the task of finding how variables relate to each other is right in line with what transformers do) just from the code and do things like auto infer types, write template code, then adapt it to the specific needs.
In fact, CPUs already do this to a certain extent - modern branch predictors are basically miniature neural networks.
Sure. Or you can let the language do that for you and spend your tokens on something else. Like, do you want your LLM to generate LLVM byte code? It could, right? Buy why wouldn't you let the compiler do that?
Unless im writing something like code for a video game in a game engine that uses C++, most of the stuff that I need C is compartmentalized enough to where its much faster to have an LLM write it.
For example, the last C code I wrote was tcp over ethernet, bypassing the IP layer, so I can be connected to the VPN while being able to access local machines on my network.
If im writing it in Rust, I have to do a lot of research, think about code structure, and so on. With LLMs, it took me an hour to write, and that is with no memory leaks or any other safety issues.
Interesting. I find that Claude 4.5 has a ridiculous amount of knowledge and “I don’t know how to do that in Rust” is exactly what it’s good at. Also, have you tried just modifying your route table?
>Also, have you tried just modifying your route table?
The problem is I want to run VNC on my home computer to the server on my work Mac so I can just access everything from one screen and m+b combo without having to use a USB switch and a second monitor. With VPN it basically just does not allow any inbound connections.
So I run a localhost tunnel its a generic ethernet listener that basically takes data and initiates a connection to localhost from localost and proxies the data. On my desktop side, its the same thing just in reverse.
well,glib is terrible for anything important, it's really just for desktop apps.
when there is a mem error, glib does not really handle it,it just aborts. ok for desktop, not ok for anything else.
There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” (https://news.ycombinator.com/item?id=46152838).
We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding.
Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that works, they’re likely to produce code that’s riddled with incorrect edge cases, memory leaks, and so on.
Also, abstraction isn’t only for humans; it’s also for LLMs. Sure, they might benefit from different kinds of abstraction - but that doesn’t mean “oh, just write machine code” is the way to go.
It makes me imagine a programming language designed for LLMs but not humans, designed for rigorous specification of every function, variable, type, etc., valid inputs and outputs, tightly coupled to unit tests, mandatory explicit handling of every exception, etc.
Maybe it'll look like a lot of boilerplate but make it easy to read as opposed to easy to write.
The idea of a language that is extremely high-effort to write, but massively assists in guaranteeing correctness, could be ideal for LLM's.
I'm writing one of these, I'll post it on HN next year. The key to a language for LLMs is: make sure all the context is local, and explicit. If you have functions, use parameters for arguments instead of positions. If you have types, spell them out right there. Also, don't use too many tokens, so keywords are out. And that's just a start.
I think the ideal language for LLMs will look more like APL than C.
Feel like you can also achieve pretty correct programs using good tests. Like really good tests.
I’m thinking of generative tests (quickcheck style), fuzzing, erroring on invariants, contract testing (see the test.contract clojure library for a very cool contract test setup!).
Really really good test suites can do stuff that even logically verified programs can’t do. They’re just a pain in the ass to write. Seems like a good use of LLMs, and you can keep using the same languages!
No it's not. The article proposes the idea of a language designed for vibe-coding, and suggests several variants designed for specific purposes. But none of the variants are for the purpose I suggested, which is about maximizing correctness. That's the point I was making.
I find it's really nice to just have Claude run the compilers and linters when it's done making a change, as it often has some mistakes and will catch them at this step. It lets me step in for review after some trivially stupid thing is fixed up, rather than wasting my own time.
I'm starting to believe other people have a very different experience from me. I use AI to write Terraform. It "fixes" things I don't want "fixed", changes the functionality I wanted, disobeys restrictions I gave it, etc. About half of the time, my time is wasted.
Yeah, I haven't used it to write Terraform yet and am not surprised that it would trip on itself with it. However, I did do a major refactor to AWS CDK using TypeScript and Claude worked really well. I treat it as a pair programmer, have it work really atomically, and always question it's work. I find scoping things down really helps with the quality of it's output.
To go along with this, the ACM has a recent article on Automatically Translating C to Rust. It gets into the challenges of 'understanding code and structure' so that the end result reflects the intent of the code, not the actual execution paths.
Not my experience. For example the "official" way of achieving the equivalent of sum types (the visitor pattern) is so verbose that idiomatic Java tends to use the equivalent of a "single table inheritance" style instead of proper domain modelling, which inevitably leads to all sorts of logic errors. Idiomatic Java uses "magic" AOP because the alternatives are too verbose, but this also inevitably causes logic errors (indeed in some ways it's worse than C where you'd do the equivalent thing with a preprocessor macro, which is at least a bit more visible in the code even if only due to conventions like UPPERCASE names). What kind of logic errors are seen in C that you would claim that idiomatic Java avoids?
> Rust doesn't prevent programs from having logic errors.
Sure, but it prevents memory safety issues, which C doesn't. As for logic bugs, what does prevent them? That's a bigger question but I'd suggest it's:
1. The ability to model your problem in a way that can be "checked". This is usually done via type systems, and Rust has an arguably good type system for this.
2. Tests that allow you to model your problem in terms of assertions. Rust has decent testing tooling but it's not amazing, and I think this is actually a strike against Rust to a degree. That said, proptest, fuzzing, debug assertions, etc, are all present and available for Rust developers.
There are other options like using external modeling tools like TLA+ but those are decoupled from your language, all you can ever do is prove that your algorithm as specified is correct, not the code you wrote - type systems are a better tool to some degree in that way.
I think that if you were to ask an LLM to write very correct code then give two languages, one with a powerful, express type system and testing utilities, and one without those, then the LLM would be far more likely to produce buggy code in the system without those features.
Logic errors always stems from lack of understanding and inattention. The former is resolved by good communication and analytical skills. The other is just human nature, but we do have guardrails to help, like static analysis and tests. If used correctly.
There are static tools available for C as well. What you get from Rust mostly is that the check is part of the syntax of the language as well and escaping from it is very visible. You get safety, but you give up flexibility and speed.
> Rust doesn't prevent programs from having logic errors.
Like everything around Rust, this has been discussed ad nauseam.
Preventing memory safety bugs has a meaningful impact in reducing CVEs, even if it has no impact on logic bugs. (Which: I think you could argue the flexible and expressive type system helps with. But for the sake of this argument, let's say it provides no benefits.)
It isn't like rust is the only language with memory safety; plenty of high level languages don't let you fiddle with memory bits in a way that would be unsafe. The tradeoff is that they typically come with garbage collectors.
If the only concern is "can an LLM write code in this language without memory errors" then there's plenty of reasons to choose a language other than Rust.
But the author isn't saying we should program in any of these memory safe languages. The author is saying why don't we vibe code in C, or even assembly.
This thread moved the conversation away from the posted article quite a few messages ago.
First, Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Then, a post about those checks are related to memory safety, not logic errors. Then, a post about whether that's a helpful comment. Finally, me pointing out that checks regarding types and memory errors aren't unique to Rust and there's tons of languages that could benefit.
Since you want to bring it back to the original article, here's a quote from the author:
Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal. To say nothing of Haskell, or OCaml, or even Python. All of these languages, after all, are for people to read, and only incidentally for machines to execute.
It would seem that the author fundamentally misunderstand significant reasons for many of the languages he mentions to be the way that they are.
> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.
Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.
But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?
Well, that's what the checks are for: So that hallucinations are caught by said checks and can be fed back into the LLM to ruminate on.
If you don't find importance in those checks, you wouldn't choose Fil-C anyway. But, of course, it remains that if do find those checks to be important, you're going to use a serious programming language like F* anyway.
There is really no place for Fil-C, Rust, etc. They are in this odd place where they have too many checks to matter when you don't care about checks, but not enough checks when you do care about checks. Well, at least you could make a case for Fil-C if you are inheriting an existing C codebase and need to start concerning yourself with checks in that codebase which previously didn't have concern for them. Then maybe a half-assed solution is better than nothing. But Rust serves no purpose whatsoever.
The trade-off is intended to make it easier for people to write software. Garbage collected languages make it easier for people to write memory safe code at the expense of performance, significantly greater memory usage, and heavy dependencies/runtimes.
These trade-offs are wholly unnecessary if the LLM writes the software in Rust, assuming that in principle the LLM is able to do so.
Yeah and I would say they're probably a better choice for vibe coding than C!
But most of them don't have a nice strong type system like Rust. I have vibe coded some OCaml and that seems to work pretty well but I wouldn't want to use OCaml for other reasons.
Can these claims back themselves up with a study showing that over a large population size with sufficient variety, sourced from a collection of diverse environments, LLM output across a period of time is more reliably correct and without issue when outputting Rust? Otherwise this is nothing but unempirical conjecture.
Ah the classic "show me ironclad evidence of this impossible-to-prove-but-quite-clear thing or else you must be wrong!"
Although we did recently get pretty good evidence of those claims for humans and it would be very surprising if the situation were completely reversed for LLMs (i.e. humans write Rust more reliably but LLMs write C more reliably).
Actually it's the classic "inductive reasoning has to meet a set of strict criteria to be sound." Criteria which this does not meet. Extrapolation from a sample size of one? In a context without any LLM involvement? That's not sound, the conclusion does not follow. The point being, why bother making a statistical generalization? Rust's safety is formally known, deduction over concrete postulates was appropriate.
> it would be very surprising if the situation were completely reversed for LLMs
Lifetimes must be well-defined in safe Rust, which requires a deep degree of formal reasoning. The kind of complex problem analysis where it is known that LLMs produce worse results in than humans. Specifically in the context of security vulnerabilities, LLMs produce marginally less but significantly more severe issues in memory safe languages[1]. Still though, we might say LLMs will produce safer code with safe Rust, on the basis that 100,000 vibe coded lines will probably never compile.
I never claimed to be doing a formal proof. If someone said "traffic was bad this morning" would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?
> LLMs produce worse results in than humans
We aren't talking about whether LLMs are better than humans.
Also we're obviously talking about Rust code that compiles. Code that doesn't compile is 100% secure!
I didn't claim that you were doing formal proofs. You can still make bad rhetoric, formal or not. You can say "The sky is blue, therefore C is a memory safe language" and that's trivially inferred to be faulty reasoning. For many people bad deduction is easier to pick up on than bad induction, but they're both rhetorically catastrophic. You are making a similarly unsound conclusion to the ridiculous example above, its not a valid statistical generalization. Formal or not the rhetoric is faulty.
> would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?
In response to a similarly suspiciously faulty inductive claim? Yeah, absolutely.
> We aren't talking about whether LLMs are better than humans.
The point I'm making here is specifically in response to the idea that it would "be surprising" if LLMs produced substantially worse code in Rust than they did in C. The paper I posted is merely a touch point to demonstrate substantial deviation in results in an adjacent context. Rust has lower surface area to make certain classes of vulns under certain conditions, but that's not isomorphic with the kind of behavior LLMs exhibit. We don't have:
- Guarantees LLMs will restrict themselves to operating in safe Rust
- Guarantees these specific vulnerabilities are statistically significant in comparative LLM output
- The vulnerability severity will be lower in Rust
Where I think you might be misunderstanding me is that this isn't a statement of empirical epistemological negativism. I'm underlining that this context is way too complex to be attempting prediction. I think it should be studied, and I hope that it's the case LLMs can write good, high quality safe Rust reliably. But specifically advocating for it on gut assumptions? No. We are advocating for safety here.
Because of how chaotic this context is, we can't reasonably assume anything here without explicit data to back it up. It's no better than trying to predict the weather based on your gut. Hence, why I asked for specific data to back the claim up. Even safe Rust isn't safe from security vulnerabilities stemming from architectural inadequacies and panics. It very well may be the case that in reasonably comparable contexts, LLMs produce security vulnerabilities in real Rust codebases at the same rate they create similar vulnerabilities in C. It might also be the case that they produce low severity issues in C at a similar statistical rate as high severity issues in Rust. For instance, buffer overflows manifesting in 30% of sample C codebase resulting in unexploitable segfaults, vs architectural deficiencies in a safe Rust codebase, manifesting in 30% of cases, that allow exfiltration of everything in your databases without RCE. Under these conditions, I don't think it's reasonable to say Rust is a better choice.
Again, it's not a critique in some epistemological negativist sense. It's a critique that you are underestimating how chaotic this context actually is, and the knock-on effects of that. Nothing should surprise you.
Modern medicine can't prevent or cure all diseases, so you might as well go back to drinking mercury then rubbing dog shit into your wounds.
Modern sewers sometimes back up, so might as well just releive yourself in a bucket and dump it into your sidewalk.
Modern food preservation doesn't prevent all spoilage so you might as well just go back to hoping that meat hasn't been sitting in the sun for too many days.
You can't get a gutter ball if you put up the rails in a bowling lane. Rust's memory safety is the rails here.
You might get different "bad code" from AI, but if it can self-validate that some code it spits out has memory management issues at compile time, it helps the development. Same as with a human.
Very advanced type system which allows to move a lot of program correctness to typing system. So basically if your program compiles, it probably works.
It's also has GC which makes it better suited for most programs, compared to Rust with its manual memory management.
I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.
Because it is also possible to write tests that don't adequately capture real-life requirements.
It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.
I prefer the slogan without "probably", "If it compiles it works", because then at least it's clear it's a slogan and not a formal claim. Everyone knows that if you write
multiply x y = x + y
then it will compile but not work, so they don't take it literally. But it is a pithy statement of the lived experience of many users of strongly typed programming, which is more accurately described by something like "if it compiles then it will probably do something at least basically sensible and often be pretty close to what you actually wanted".
>We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding.
Checking preconditions and postconditions is much easier to do for a human than checking an implementation
The thing that would really make sense is a proved language like Coq or Promela
You can then really just leave the implementation to the AI.
> abstraction isn’t only for humans; it’s also for LLMs.
Bingo. LLMs are language models, not models of software systems. Everything gets translated through natural language! So the quality of the abstraction still matters: code that can be described well in plain language wins.
I really tried to get into the vibe coding thing - just describe the thing I need in human language and let the agent figure it out. It was incredible at first. Then I realized that I am spending a lot of time writing clarifications because the agent either forgot or misinterpreted something. Then I realized that I am waiting an awful long time for each agent step to complete just to write another correction or clarification. Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed. Now I am back to programming myself and only bouncing the boring bits off of ChatGPT.
> Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed
Yes, it’s extremely soul sucking. With the added disadvantage of not teaching me anything.
One trick I have tried is asking the LLM to output a specification of the thing we are in the middle of building. A commenter above said humans struggle with writing good requirements - LLMs have trouble following good requirements - ALL of them - often forgetting important things while scrambling to address your latest concern.
Getting it to output a spec lets me correct the spec, reload the browser tab to speed things up, or move to a different AI.
One thing that helps is to write an AGENTS.md file that encodes the knowledge and tricks you have of the codebase, like running a single test (faster feedback cycles), common coding patterns, examples, etc.
I went full meta and sketched out a file, then had an expensive LLM go through the codebase and write such a file. I don't know if it's any good though, I only really use coding assistants to write unit tests.
The delta between "make a small requirement that you can check and verify" vs "create the code yourself" is pretty big. A well crafted sentence can sometimes still be hours of work.
I very much doubt the ability of LLMs to provide leak-free, faulty memory management free, C code, because they are trained on loads of bad code in that regard. They will not output code of the quality that maybe 1% of C developers could, if even that many. Fact is, that even well paid and professional C/C++ developers introduce memory management issues in such code bases (see Chromium project statistics about this). So chances to get good C programs from LLMs, which learn from far lower quality code than Chromium, are probably very slim.
Vibe-coding a program that segfaults and you don't know why and you keep burning compute on that? Doesn't seem like a great idea.
>Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal.
I've been using Rust with LLMs for a long time (mid-2023?) now; cargo check and the cargo package system make it very easy for LLMs to check their work and produce high quality code that almost never breaks, and always compiles.
My favorite use for LLMs with Rust is using them as a macro debugger; they provide better error messages than the errors Cargo can provide. It's cool to take a macro and ask the LLM to do an expansion of it, to see what it would look like. Or, to take Rust code and ask the LLM to create a macro for it.
I agree that an LLM may make mistakes.
But one advantage is, that you can also allocate resources for it to try and find its own mistakes. You can do this humans, but the grind wears away at them. Since this doesn't really happen with an LLM, it's pretty decent at catching it's own mistakes too.
Well, most LLM are fine tuned over higher quality data, this is kind of how they've kept improving them amongst other things.
The first pass is to learn the fundamentals of language, and then it is refined on curated datasets, so you could refine them on high quality curated C code.
> But if you look carefully, you will notice that it doesn’t struggle with undefined behavior in C. Or with making sure that all memory is properly freed. Or with off-by-one errors.
Doubt. These things have been trained to emulate humans, why wouldn't they make the same mistakes that humans do? (Yes, they don't make spelling errors, but most published essays etc. don't have spelling errors, whereas most published C codebases do have undefined behaviour).
I'm not very experienced with C++ at all but Sonnet in Copilot/Copilot Chat was able to create entire files with no memory errors on the first try for me, and it was very adept at hunting down memory errors (they were always my own fault) from even just vague descriptions of crashes.
How do you know? I can believe that they didn't show memory errors in a quick test run on a common architecture with a common compiler, much like most human-written code in the training corpus.
It wasn't code worth formally verifying, but even your description beats almost any programmer's first pass. With how good it is at finding bugs if you ask it, I have little reason to doubt its output.
In the real world, I'd say the 90% of the C code written is somewhere between "worthwhile to spend extra effort to detect and avoid memory errors" and "worth formally verifying".
Sure, for prototype sized codebases it might be able to handle finding mistakes a fresh grad might easily make, or even that memory bugs aren't a big problem - but in my experience it happily adds memory bugs to large codebases and multithreaded code (that I think an experienced human could easily spot tbh).
It's incorrect to think because it is trained on buggy human code it will make these mistakes. It predicts the most likely token. Let's say 100 programmers write a function, most (unless it's something very tricky), won't forget to free that particular function. So the most likely tokens are those which do not leak.
In addition, this is not GPT 3. There's a massive amount of reinforcement learning at play, which reinforces good code, particularly verifiably good (which includes no leaks). And also a massive amount of synthetic data which can also be generated in a way that is provably correct.
> Let's say 100 programmers write a function, most (unless it's something very tricky), won't forget to free that particular function. So the most likely tokens are those which do not leak.
You don't free a function.
And this would only be true if the function is the same content with minor variations, which is why LLMs are better suited for very small examples. Because bigger examples are less likely to be semantically similar, and so there is less data to determine the "correct" next token.
> There's a massive amount of reinforcement learning at play, which reinforces good code, particularly verifiably good (which includes no leaks)
This is a really dubious claim. Where are you getting this? Do you have some information on how these models are trained on C code specifically? How do you know whether the code they train on has no leaks?
There are huge projects that everyone depends on that have memory bugs in them right now. And these are actual experts missing these bugs, what makes you think the people at OpenAI are creating safer data than the people whose livelihoods actually depend on it?
This thread is full of people sharing how easy it is to make memory bugs with an LLM, and that has been my experience as well.
I've had issues with Claude and memory related bugs in C. Maybe small programs or prototypes it's fine if you can verify the output or all the expected inputs, but the moment the context is >50k lines or even doing something with pthreads, you run into the exact same problems as humans.
I think Claude would do much better with tools provided by modern C++ or Zig than C, frankly, anyways. Or even better, like the Rust people have helpfully mentioned, Rust.
Because I want to be able to review it, and extend it myself.
edit: Pure vibe coding is a joke or thought exercise, not a goal to aspire to. Do you want to depend on a product that has not been vetted by any human? And if it is your product, do you want the risk of selling it?
I can imagine a future where AI coders and AI QA bots do all the work but we are not there yet. Besides, an expressive language with safety features is good for bots too.
> if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP.
A language designed for vibe coding could certainly be useful, but what that means is the opposite of what the author thinks that means.
The author thinks that such a language wouldn't need to have lots of high-level features and structure, since those are things that exist for human comprehension.
But actually, the opposite is true. If you're designing a language for LLMs, the language should be extremely strict and wordy and inconvenient and verbose. You should have to organize your code in a certain way, and be forced to check every condition, catch every error, consider every edge case, or the code won't compile.
Such a language would aggravate a human, but a machine wouldn't care. And LLMs would benefit from the rigidness, as it would help prevent any confusion or hallucination from causing bugs in the finished software.
I don't think there is a need for an output language here at all, the LLM can read and write bits into executables directly to flip transistors on and off. The real question is how the input language (i.e. prompts) look like. There is still a need for humans to describe concepts for the machine to code into the executable, because humans are the consumers of these systems.
> the LLM can read and write bits into executables directly to flip transistors on and off
No, that's the problem (same misconception the author has) - it can't. At least not reliably. If you give an LLM free rein with a non-memory safe output format, it will make the exact same mistakes a human would.
The point of a verbose language is to create extensive guardrails. Which the LLM won't be annoyed by, unlike a human developer.
Vibe coding should be done in Python, and probably only in Python.
If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all.
Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collection, the forgiving syntax, the interpreted nature: these create a sandbox where vibe coded solutions can fail safely. A buggy Python script throws an exception. A buggy C program gives you memory corruption or security holes that show up three deployments later.
The question isn’t what language should AI write. It’s what problems should we trust to vibe coding. The answer: problems where Python’s safety net is enough. The moment you need C’s performance or assembly’s precision, you’ve crossed into territory that demands human accountability.
I don't think we will ever reach the same accuracy simply because some languages are harder than others. Writing correct C (not just "working C") is difficult because of the number of footguns and the amount of reasoning and implicit state tracking you have to do in your head. LLMs are not free from this, if anything that's harder for them. Meanwhile languages like Java are more difficult just because they are verbose and spread information over many files. Languages that are explicit, not overly verbose and make it difficult to make subtle mistakes will always have the advantage with LLMs
I more bullish on the Python -> Rust pipeline. The two languages have a lot of overlap in philosophies, have great interop, and have similar levels of guard rails (when it comes to multithreading Rust even beats Python in terms of safety). And both languages seem well suited to being vibecoded
I wouldn't limit it strictly to Python, but I agree that it should be limited to memory safe languages. Vibe code in C#, Rust or PHP if that suits your requirements, but C or assembly are indeed poor choices for the reasons you list
Vibe coded Python can certainly have security holes too.
If you want a language that protects you from the largest amount of problems, how about Rust? Vulnerabilities will still be possible, but at least data races won't be possible.
> The moment you need C’s performance or assembly’s precision, you’ve crossed into territory that demands human accountability.
I disagree. I write a lot of one-off numerical simulations where something quick and dirty is useful but performance matters and the results can be easily verified without analyzing every line of code. Python would be a terrible choice.
Am I the only one who feels like this is the output of an LLM?
A poorly written comment by a human wastes time. A vibe comment by an LLM wastes both time and electricity that only shows up when global warming reaches 3c.
The question isn't if the comment is valuable or not. It's whether it is ethical or not to waste peoples time with AI slop.
Ok but what happens when you reach the point where the LLM makes fewer mistakes than the human? Where it’s better at spotting potential memory corruption and security holes?
It doesn’t feel like we’re very far from that point.
I think you should use a language with a highly expressive type system. That can be assembly too. See TAL back from the 1990'es. I also think you should use a language with a very expressive module system.
The reason is that you want to have some kind of guidance from a larger perspective in the long run. And that is exactly what types and module systems provide. The LLM has to create code which actually type checks, and it can use type checking as an important part of verification.
If you push this idea further: use Lean, Agda or Rocq. Let the LLM solve the nitty gritty details of proof, but use the higher-level theorem formation as the vessel for doing great things.
If you ask for a Red-black tree, you get a red-black tree. If you ask for a red-black tree where all the important properties are proven, you don't have to trust the LLM anymore. The proof is the witness of correctness. That idea is extremely powerful, because it means you can suddenly lift software quality by an order of magnitude, without having to trust the LLM at all.
We currently don't do this. I think it's because proving software correctness is just 50x more work, and it moves too slow. But if you could get an amplifier (LLM) to help out, it's possible this becomes more in the feasible area for a lot of software.
Here is where the author and I disagree vehemently. The author implies that the ai-generated code is always correct. My personal experience is that it often isn't. Not even for big projects - for small bugfixes it also misunderstands and hallucinates solutions.
My philosophy regarding AI is that you should never have it do something you couldn't do yourself.
Of course people break this rule, or the concept of vibe coding wouldn't exist. But some of us actually get a lot of value from AI without succumbing to it. It just doesn't make sense to me to trust a machine's hallucinations for something like programming code. It fabricates things with such confidence that I can't even imagine how it would go if I didn't already know the topic I had it work on.
I'm working on a serious embedded app written in C, and Opus has been invaluable to me. I don't consider myself a C developer, but by carefully reviewing the changes and making lots of my own contributions, I'm finding that I've progressed from junior to intermediate C comprehension. A lot of the idioms are still fuzzy, but I no longer find it intimidating. That's wonderful, because learning C has been something I'd put off for 40 years and microcontrollers were the thing that forced my hand.
I think that there's a real rift between people who use LLMs to rough out large swathes of functionality vs people who took the "vibe coding" brain fart way, way too literally. I'm kind of horrified that there are people out there who attempt to one-shot multiple copies of the same app in different instances and then pick the best one without ever looking at the code because "vibe coding". That was always supposed to be a silly stupid thing you try once, like drinking Tide pods or whatever the kids do for fun... not something people should be debating a year later.
But I have written C in the past, it was almost 20 years ago, and everything seemed to work fine, until the memory leaks.
Of course today I would ask the AI, why is my program leaking memory. I think you have a point, AI would be sort of like having a mentor help you find bad practices in your C code.
You've inspired me to maybe try my hand at Rust, something I've been wanting to do since I heard of it.
Same here. I can read and understand most of it, but not enough to debug it. And outsourcing that task to Claude is like taking a long winding path through thick, dark woods.
This post mixes up “easy for compilers and assemblers to transform and easy for cpus to execute” with “easy for LLMs to understand” and assumes that anything in the first category must also be in the second category since they’re both computers. In reality, the tools that help humans think are also useful for LLMs.
I also enjoy coding! It’s fun. It’s also only about 10% of my job as a software developer, and I can and do use an LLM for it whenever I can find an opportunity. The author is a professor. Not to disparage that perspective, but she paints a picture of the joys of programming that are overshadowed in environments where you are actually building real world robust systems with clueless users, vague requirements, shifting budgets and priorities, etc.
As to why not use C, or assembly, it’s not just about the code, but the toolchains. These require way more knowledge and experience to get something working than, say, Python - although that has its own rather horrible complexities with packaging and portability on the back end of the code authoring process.
LLMs have single handedly turned the hardest part of this job into entire job. The hardest part of this job is troubleshooting, maintaining and developing on top of an unfamiliar code base. That's not a new experience for anyone who has lived the production code life. One of the first production engineers I was tutored under used to love to say, "the code should tell you a story."
I love C. I came up on C. But C does not tell you a story. It tells you about the machine. It tells you how to keep the machine happy. It tells you how to translate problems into machine operations. It is hard to read. It takes serious effort to discern its intent.
I think any time you believe the codebase you're developing will have to be frequently modified by people unfamiliar with it, you should reach for a language which is both limiting and expressive. That is, the language states the code intent plainly in terms of the problem language and it allows a limited number of ways to do that. C#, Java (Kotlin) and maybe Python would be big votes from me.
And FYI, I came up on C. One of the first senior engineers I was tutored by in this biz loved to say, good code will tell you a story.
When you're living with a large, long lived codebase, essenti
Well, because you can do it in Fortran, of course!
What else do you want? Multidimensional arrays out of the box, fast loops, native cuda support, trivial build and packaging system, zero version churning... all of this just with the bare language. It's the anti-python! The perfect language, you could say! Strings and i/o are a bit cumbersome, agreed, but your llm can take care of these without any trouble, no matter the language.
I see a lot of "vibe-coding" related articles, but I don't see a lot of shipped projects/products via "vibe-coding". I would like to find some examples instead of this kind of articles ?
I think if I was actually shipping a real product to real customers I would avoid bragging about how I vibe-coded it. Seems like that would bring up some quality / security / pricing discussions that my salespeople would have a tough time navigating. At least for now I think those customer concerns would be justified. Oh you vibed this out in an afternoon? Why does it cost $199/seat? Why don’t I just build it myself?
If you go on YouTube you can find a lot of vibe coders doing interviews where they drop a brief mention of their SaaS products. I think the main reason they are not well publicized is because they obviously have no moat. If I speak to a really big audience and tell them my SaaS which I vibe coded in 1 day is earning 10k/mo, then I'll have 10 competitors by tomorrow.
But if you want a "citation needed" name of someone shipping vibe coded apps and making money off it: on YouTube, Ed Yonge, or many of the guests on Starter Story.
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that.
… well, you are wrong.
I recently gave the "vibe" AI the assignment of "using GTK [4, I think], establish a global shortcut key".
No amount of massaging the prompt, specifying the version of GTK, etc. could prevent it from just outright hallucinating the functions it wanted to call into existence. The entire reason I was asking was because I did not know what function to call, and was having difficulty discerning that from GTK's documentation. (I know how to do this now, and it is effectively undocumented.)
Prior to that, an assignment to determine some information from Alembic. Again, the AI desired to just hallucinate the functions it required into existence.
A script to fetch the merge queue length from GH. It decided to call GH's GraphQL API, which is fine, and doable for the task, but the query was entirely hallucinated.
A bash script to count files change in git. The code ran, and the output was wrong. The author did not check the LLM's code.
Even non-programming tasks are the same. Image generation is a constant fight of trying to get the AI to understand what you mean, or it just ignoring your prompts, etc. I went about 10 prompts trying to get an image with a stone statue of 4 ASCII characters in a field. The last character was consistently just wrong, and no amount of prompting to fix.
"Generate a character with a speech bubble that says 'Hi'" -> speech bubble has Japanese in it! (And the Japanese is gibberish, but if you ask AI to translate it, it "will".)
- C takes a lot more context than a high-level language
- a lot of C code out there is not safe, so the LLM outputs that
- C encodes way less of the programmer's intention, and way more implementation details. So unless the author is extremely good at naming, encapsulating and commenting, the LLM just has less to work with. Not every C code is Sqlite/redis/ffmeg quality.
- the feedback loop is slower, so the LLM has less chance to brute force a decent answer
- there is no npm/pypi equivalent for C on which to train the LLM so the pool for training is less diverse
- the training pool is vastly Linux-oriented, with the linux kernel and distro system libs being very prominent in the training data because C programs on Windows are often proprietary. But most vibe coders are not on Linux, nor into system programming.
Sure, you can vibe code in C. Antirez famously states he gets superb ROI out of it.
But it's likely you'll get even better results with other languages.
>Vibe coding makes me feel dirty in ways that I struggle to articulate precisely. It’s not just that it feels like 'cheating'(though it does). I also think it takes a lot of the fun out of the whole thing.
This exactly.
Programming is art, because it comes from the soul. You can tackle a problem a million ways, but there's only one way that YOU would solve it.
Vibe coding feels like people who aren't creative, stealing everyone's creativity, and then morphing it into something they find appealing.
There is no skill.
There is no talent.
You are asking the machine to do ALL THE THINKING.
All the little decisions, the quirks, the bugs, the comments to yourself. All the things that make a piece of code unique.
This is treating the LLM like it is the computer or has some kind of way of thinking. But LLM is a "language" model, I'm pretty sure the easier for human to read, the easier for LLM to learn and generate. Abstractions also benefit the model, it does not need to generate a working 2s complement, just a working call to addition of abstracted types.
And just in my experience, I feel everyone is slowly learning, all models are better at the common thing, they are better at bash, they are better at Python and JS, and so on. Everyone trying to invent at that layer has failed to beat that truth. That bootstrapping challenge is dismissed much too easily in the article in my opinion.
Binary bits are also a language. A structured language that transistor-based computers execute into some result we humans find valuable. Why wouldn't a model be able to write these binary instructions directly? Why do we need all these layers in between? We don't.
Because the learned function to generate binary code is likely more complex than that for Python.
I admit I can't say for sure until we try it. If someone were to train a model at the same scale on the same amount of raw binary code as we do these models on raw language and code, would it perform better at generating working programs. Thing is, it would now fail to understand human language prompts.
From what I know and understand though, it seems like it would be more complex to achieve.
My meta point is, you shouldn't think of it as what would a computer most likely understand, because we're not talking about a CPU/GPU. You have to think, what would a transformer architecture deep neural net better learn and infer? Python or binary code? And I think from that lens it seems more likely it's Python.
Why would you think its more complex? There are less permutations of generating transistor on/off states than there are all the different programming languages in use that result in the exact same bits.
Who said that creating bits efficiently from English to be computed by CPUs or GPUs must be done with transformer architecture? Maybe it can be, maybe there are other ways of doing it that are better. The AI model architecture is not the focus of the discussion. It is the possibilities of how it can look like if we ask for some computation, and that computation appears without all the middle-men layers we have right now, English->Model->Computation, not English->Model->DSL->Compiler->Linker->Computation.
Binary code takes more space, and both training and inference is highly capped by memory and context sizes.
Models tokenize to a limited set of tokens, and then learn relations between those. I can't say for sure, but I feel it be more challenging to find tokenization schemes for binary code and learn their relationships.
The model needs to first learn human language really well, because it has to understand the prompt and map it accurately to the binary code. That means the corpus will need to include a lot of human languages that it learns and also binary code, I wonder if the fact they differ so much would conflict the learning.
I think coming up with a corpus of mapped human language to binary code will be really challenging. Unless we can include the original code's comments at appropriate places around the binary code and so on.
Binary code is machine dependent, so it would result in programs that aren't portable between architecture and operating system and so on. The model would need to learn more than one binary code and be able to accurately generate the same program for different target platforms and OS.
> Who said that creating bits efficiently from English to be computed by CPUs or GPUs must be done with transformer architecture?
We've never had any other method ever do as well and by a magnitude. We may invent a whole new way in the future, but as of now, it's the absolute best method we've ever figured out.
> The AI model architecture is not the focus of the discussion. It is the possibilities of how it can look like if we ask for some computation, and that computation appears without all the middle-men layers we have right now, English->Model->Computation, not English->Model->DSL->Compiler->Linker->Computation.
Each layer simplifies the task of the layer above. These aren't like business layer that take a cut of the value out at each level, software layers remove complexity from the layers above.
I don't know why we wouldn't be talking about AI models? Isn't the topic that it may be more optimal for an AI model to be trained on binary code directly and to generate binary code directly? At least it's what I was talking about.
So if I stick to AI models. With LLMs and image/video diffusion and such, we've already observed that inference through smaller steps and chains of inference work way better. Based on that, I feel it's likely going from human language to binary code in a single hop to also work worse.
Diffusion models for images are already pretty much binary code generators. And we don't need to treat each bit individually, even in binary code there are whole segments that can be tokenized into a single token.
Regarding training, we have many binaries all around us, for many of them we also have the source code in whichever language. As a first step we can use the original source code and ask a third party model to explain what it does in English. Then use this English to train the binary programmer model. Eventually the binary programmer model can understand binaries directly and translate them to English for its own use, so with time, we might not even need binaries that have source code, we could narrate binaries directly.
Rust works very well for vibe-coding because the compiler is typically very specific and a bit picky; helps keep it out of traps. I like using WASM with Rust as originator when vibe-coding because AI models are still very "sloppy/forgetful". There is one thing you should still definitely do beforehand, and that's pick out which crates you want and write up the initial Cargo.toml for it, because frontier models have a lot of trouble with fast-updated libraries.
What frontier models also excel at is writing their own libraries and skipping third-party dependencies. It's very easy for a human to just pick up a bloated 750kb library they're only going to actually use 15kb worth of its code for, BUT that library can serve as a valuable implementation model for someone very patient and willing to "reinvent the wheel" a little bit, which is definitely going to be AI and not me, because I just want to point to a black box and tell it what to do. For big things like web server, I'm still defaulting to Axum, but for things like making a JS soundbank parser/player or a WebGL2 mp4 & webm parser/demuxer & player, these are tasks frontier models are good for with the right prompting.
To an extent, maybe counter-intuitively, I think the big thing we'll see out of AI is an explosion of artisanship -- with humanoid robots in 2040, perhaps, our households may be making their own butter again, for example.
I think you're going to need a superhuman intelligence's idea of a super-superhuman intelligence at the very least if you're going to expect C programs that are memory safe.
I'll admit that I'd like to do a programming challenge with or without AI that would be like "advent of code" in assembly but if it was actual "advent of code" the direct route is to write something that looks like a language runtime system so you have the dynamic data structures you need on your fingertips.
Even experts create C/C++ code that is routinely exploited in the wild (see: pegasus malware, Zerodium, Windows zero days, Chrome zero days, etc.). No, please don't vibe code anything security critical, and please don't create unnecessary security risk by writing it in unsafe languages such as C/C++. The only advantage I can see is it creates some fun easy targets for beginning exploit developers. But that's not an advantage for you.
I think the main reason not to go full-throttle into "vibes -> machine code" (to extrapolate past doing it in C) is because we have a history of building nested dolls of bounded error in our systems. We do that with the idea of file systems, process separation, call stacks, memory allocations, and virtual machines.
Now, it is true that vibes results in producing a larger quantity of lower-level code than we would stomach on our own. But that has some consequences for the resulting maintenance challenge, since the system-as-a-whole is less structured by its boundaries.
I think a reasonable approach when using the tools is to address problems "one level down" from where you'd ordinarily do it, and to allow yourself to use something older where there is historical source for the machine to sample from. So, if you currently use Python, maybe try generating some Object Pascal. If you use C++, maybe use plain C. If there were large Forth codebases I'd recommend targeting that since it breaks past the C boundary into "you're the operator of the system, not just a developer", but that might be the language that the approach stumbles over the most.
Alright, the whole article stands on the lifting done by the concept of "vibe coding", which is not just asking an LLM to write some code, scan it quickly to check if it at least makes somewhat sense and then accept it. It is based on pure vibe coding, where the user literally has no idea what's being produced.
After having understood the context, I still believe that a strongly typed language would be a much better choice of a language, for exactly the same reason why I wouldn't recommend starting a project in C unless there is a strong preference (and even then Rust would probably be better still).
LLMs are not perfect, just like humans, so I would never vibe code in any other environment than one in which many/most logical errors are by definition impossible to compile.
Not sure if C is worse than python/js in that respect (I'd argue it is better for some and worse for other, regarding safety) but Java, Swift, C#, Go, Rust, etc. are great languages for vibe coding since you have the compiler giving you almost instant feedback on how well your vibe coding is going.
Claude Code is pretty good at Rust, but it works best if there's a pre-existing structure built by a human that it's operating within. Rust's error messages give rich context and are designed for humans, so it's able to figure out how to resolve its mistakes from them in ways that it simply would have to grind through in tests with trial and error in dynamic languages. And then when you do write unit tests to address logic bugs, it's able to leverage the rich context from the type system to write decent tests.
I wouldn't trust it to reliably write safe C though. It works in Rust because there's meaning embedded into the types that are checked by the compiler that gives it feedback when it makes mistakes. But you don't get that in C.
I was thinking that this week. We are quickly reaching a point where the quality of the code isn't as important as the test suite around it and reducing the number of tokens. High level languages are for humans to read/write, if most people aren't reading the code we should just skip this step.
This is a point I keep advocating, sure the tools aren't yet there, but it is foolish to assume we don't ever get there, generating 3GL source code is only a transition step.
We already are having visual programming tools with AI agents, with various kinds of success, see iPaaS like Boomi, Workato and similar.
Recently I have had the opportunity to be part of projects using such kind of tools.
If there is any traditional coding it is a bunch of serverless endpoints exposed as MCP tools.
There’s a nugget of an idea in there, even if I disagree with most of it.
But code doesn’t only need to be understood for maintenance purposes: code is documentation for business processes. It’s a thing that needs to be understandable and explainable by humans anytime the business process is important.
LLMs can never / should never replace verifiability, liability, or value judgment.
Agree with your point. It's going to be super interesting to see whether languages become more lower or higher on the stack. My guess is unuseful: both.
We've not really seen what impact this will have just yet.
> Thus, programs must be written for people to read, and only incidentally for machines to execute
But that's... terrible. Humans can barely communicate to each other. And now you wanna take our terrible communication, and make a machine try to guess what the hell we want to happen? You want a plane to operate like that?
There's a straightforward answer to the "why not" question: because it will result in codebases with the same kind of memory unsafety and vulnerability as existing C code.
If an LLM is in fact capable of generating code free of memory safety errors, then it's certainly also capable of writing the Rust types that guarantee this and are checkable. We could go even further and have automated generation of proofs, either in C using tools similar to CompCert, or perhaps something like ATS2. The reason we don't do these at scale is that they're tedious and verbose, and that's presumably something AI can solve.
Similar points were also made in Martin Kleppmann's recent blog post [1].
It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside. I mean C doesn't even have a builtin hashtable or vector, let alone pattern matching, traits and sum types. I get this is about AI and vibe coding, but we aren't at a point yet where zero human interaction is reasonable, so every code base should assume some level of hybrid human/AI involvement. Why people want so badly to start a new code base in C is beyond me (and yes, I've written a lot of C in my time, and I don't hate it, but it didn't age well in expressiveness).
> It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside.
Simplicity? I learned Rust years ago (when it was still pre release), and when i now look at a lot of codebases, i can barely get a sense what is going on, with all the new stuff that got introduced. Its like looking at something familiar and different at the same time.
I do not feel the same when i see Go code, as so little has changed / got added to it. The biggest thing is probably generics and that is so rarely used.
For me, this is, what i think, appeals for C programmers. The fact that the language does not evolve and has been static.
If we compare this to C++, that has become a mess over time, and i know i am getting downvoted for this, Rust feels like its going way too much in the Rust++ route.
Like everybody and their dog wants something added, to make Rust do more things, but at the same moment, it feels like its repeating the C++ history. I have seen the same issue with other languages that started simple, and then becomes monsters of feature sets. D comes to mind.
So when you see the codebase between developers, the different styles because of the use of different feature sets, creates this disconnect and makes it harder for people to read other code. While with C, because of the language limits, your more often down a rather easier way to read the same code. If that makes sense?
Proofs of what? "This new feature should make the 18 to 21 year old demographic happy by aligning with popular cultural norms". This would be difficult to formalize as a proof.
Memory safety in particular, actually UB in general (got to watch out for integer overflows, among other things). But one could prove arbitrary properties, including lack of panics (would have been helpful for a recent Cloudflare outage), etc.
In order to prove lack of UB, you have to be able to reason about other things. For example, to safely call qsort, you have to prove that the comparison is a total order. That's not easy, especially if comparing larger and more complicated structures with pointers.
And of course, proving the lack of pointer aliasing in C is extremely difficult, even more so if pointer arithmetic is employed.
In this context it's proofs of properties about the program you're writing. A classic one is that any lossless compression algorithm should satisfy decompress(compress(x)) == x for any x.
Maybe I'm still in denial about the benefit of AI code design, but when I have an initial set of requirements for a program, the design begins. That is just a set of unanswered questions that I address with slowly growing code and documents. Then the final documents and code match the answers to all the questions that rose from the answers of previous questions. More importantly, I know how the code answers them and someone else can learn from the documentation. Since the invention of "velocity" I feel like much of the industry treats code and programmers like tissues. Wipe your nose and throw it away. Now we have AI-based automatic tissue dispensers and Weizenbaum's gripe about programmers creating work for themselves other than solving the requirements of the actual problems continues.
> But this leads me to my second point, which I must make as clearly and forcefully as I can. Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that. Because when you start giving it little programming problems that you can’t be arsed to work out yourself (as I did), you discover (as I did) that it’s awfully good at those. And then one day you muse out loud (as I did) to an AI model something like, “I have an idea for a program…” And you are astounded. If you aren’t astounded, you either haven’t actually done it or you are at some stage of grief prior to acceptance. Perfect? Hardly. But then neither are human coders. The future? I think the questions answers itself.
This cannot be repeated enough. For all the AI hype, if you think AI isn't the most useful programming tool invented in the last 20 years, you're ignorant of the SOTA or deeply in denial.
As @tptacek recently wrote:
> All progress on LLMs could halt today, and LLMs would remain the 2nd most important thing to happen over the course of my career.
- The C-compiler. AI tools work better if their automated feedback loop via tools includes feedback on correctness, safety, etc. The C compiler is not great at that. It requires a lot of discipline from the programmer. There mostly isn't a compile time safety net.
- Macros add to this mess. C's macros are glorified string replacements.
- Automated tests are another tool that helps improving quality of vibe coded code. While you can of course write tests for C code, the test frameworks are a bit immature and it's hard to write testable code in C due to the lack of abstractions.
- Small mistakes can have catastrophic consequences (crashes, memory overflows)
- A lot of libraries (including the standard library) contain tools with very sharp edges.
- Manual memory management adds a lot of complexity to code bases and the need for more discipline.
- Weak/ambiguous semantics mean that it's harder to reason about code.
There are counter arguments to each of those things. Compilers have flags. There are static code analyzers. And with some discipline, it gets better. You could express that discipline in additional instructions for your agent. And of course people do test C code. There just are a lot of projects where none of that stuff is actively used. Vibe coding on those projects would probably be a lot harder than on a project that uses more structured languages and tools.
All these things make it harder to work with C code for humans; and for AIs. But not impossible of course. AI coding models are getting quite good at coding. Including coding in C.
But it makes it a poor default language for AI coding. The ideal vibe coding language for an AI would be simple, expressive, have great tools and compilers, fast feedback loops, etc. It means the AI has less work to do: shorter/faster feedback loops, less iterations and reasoning to do, less complex problems to solve, less ambiguity, entire categories of bugs that are avoided, etc. Same reasons as to why it is a poor choice for most human programmers to default to.
> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? ... surely Rust is even less ideal.
I don't get how the second follows from the first. One of the main complaints levelled against Rust is that it is not ergonomic for humans, specifically because it forces you to work to a set of restrictions that benefit the machine.
With an LLM coding agent that quickly produces volumes of somewhat-scattershot code, surely we're better off implementing incredibly onerous guardrails (that a human would never be willing to deal with)?
Also vibe coding is a mistake, it will undoubtedly turn anything more elaborate than a simple script into a monstrosity. DO NOT TELL AI TO WRITE MORE THAN A FUNCTION OR PART OF A FUNCTION.
I did a goodly chunk of vibe coding over the summer and I found that the best language for me was Rust implementations with Python bindings for interface. A few reasons:
- Everything about rust enforcing correctness catches lots of bugs
- Using a high-level API means I can easily hand-check things in a repl
- In addition to tests, I required a full “demo notebook” with any PR — I should be able to read through it and confirm that all the functionality I wanted has actually been implemented
If the philosophy is (and it should be) “loc is free”, it’s worth thinking about how we can make LLMs produce more loc to give us additional comfort with correctness. Language choice is very much a way.
I don’t buy that LLMs won’t make off-by-one or memory safety errors, or that they won’t introduce undefined behavior. Not only can they not reason about such issues, but imagine how much buggy code they’re trained on!
The answer is type-safety. LLMs produce errors, as do humans. A language with carefully designed semantics and a well-implemented safety checker (or maybe even a proof assistant) will help express much more correct code.
I've had the most success running Claude iteratively with mypy and pytest. But it regularly wants to just delete the tests or get rid of static typing. A language like Haskell augmented with contracts over tests wouldn't allow that. (Except for diverging into a trivial ad-hoc dynamic solution, of course.)
Vibe coding benefits from hard limits relatively more than human coding. So in that sense, we should be coding in Rust (where raw performance is needed), Idris 2 or Haskell, and specifying with formal methods.
Perhaps the programming languages of the future will be designed with AI in mind: to properly put guardrails on it.
Could also be that the models just accelerate to the future so fast that they'll simply stop making mistakes. Then we'll be coding in Assembler, because why waste CPU time for anything else?
I do vibe code in C; I'm not a C programmer and I certainly couldn't do a security audit of any serious C codebase, but I can read and understand a simple C program, and debug and refactor it (as long as it's still quite simple).
And it's super fun! Being able to compile a little C utility that lives in the Windows tray and has a menu, etc. is exhilarating.
But I couldn't do that in assembly; I would just stare at instructions and not understand anything. So, yes for C, no for assembly.
I think this is an odd idea. For a lot of reasons, but one is simply that higher level languages _tend_ to be terser, and context window matters for LLMs. Expressing more in less is valuable.
My experience of vibe coding is that the agent makes as many mistakes as me, it just types faster than I do. So using the most safe and typed language possible is still a good idea.
Also I want to understand the code as much as possible - sometimes the agent overcomplicates things and I can make suggestions to simplify. But if it's writing in a language only it can understand, that's going to be harder for me.
I’ve had a similar (likely non original) thought too that eventually LLMs could lead to something more akin to a compiler that would take human language instructions and go straight to a executable binary, possibly even with more traditional compiler analysis for performance and safety etc.
But then again LLMs in their current form are trained on mountains of human language so maybe having them output human readable code makes sense at least for now
I came to this article expecting an investigation on how C or assembly performs with an LLM, but it is just musings. The article claims the LLM is better at memory management than a human, which I find dubious, but even then it would not be a good argument in favor of C.
My experience with LLMs is that they are not good at tracking resources and perform much better with languages that reduce cognitive load for humans.
To answer the question literally, vs discuss "is vibe-coding good": The more tricky details in a language, the more I've seen LLM-first coding struggle. Rust, for instance, often leads to the model playing whack-a-mole with lifetime or borrow checker issues. It can often get to something that compiles and passes the tests, but the process gives me some pause in terms of "what am I not checking for that the whack-a-mole may have missed."
In C, without anything like a borrow checker or such, I'd be very worried about there being subtle pointer safety issues...
Now, some of that could be volumes of training data, etc, but Rust is widely discussed these days in the places these models are trained on, so I'm not certain it's a training problem vs a attention-to-detail across files problem. I.e., since LLMs are trained to mimic human language, programming languages that are most procedural-human-language-like (vs having other levels o fmeaning embedded in the syntax too) may exactly be those "LLM-friendly" languages.
It doesn't have problems with undefined behavior, memory safety, or especially thread safety?
That has not been my experience when using Codex, Composer, Claude, or ChatGPT.
Things have just gotten to the point over the last year that the undefined behavior, memory safety, and thread safety violations are subtler and not as blindingly obvious to the person auditing the code.
But I guess that's my problem, because I'm not fully vibing it out.
Do you really think the user didn't try explaining the problem to the LLM? Do you not see how dismissive the comment you wrote is?
Why are some of you so resistant to admit that LLMs hallucinate? A normal response would be "Oh yeah, I have issues with that sometimes too, here's how I structure my prompts." Instead you act like you've never experienced this very common thing before, and it makes you sound like a shill.
What the author is describing is the logical conclusion of the Bitter Lesson applied to software development. To quote the essay: "We have to learn the bitter lesson that building in how we think we think does not work in the long run." The author of this article correctly points out that a lot of what goes into programming language design is a model of how humans think, and a lot of the abstractions are there to make it easier for humans to reason about code. That's not to say that abstraction isn't useful for machines, but I think the bitter lesson would say that it's better in the long run to let the machine figure out the best abstractions through search, and let humans think in the way they're used to thinking: in natural language.
Now personally I don't think this ultimate vibe-coding paradigm is just around the corner, but it does seem that it's the direction we're heading and I think this article does a good job of explaining why.
> let humans think in the way they're used to thinking: in natural language
Writing a program means stating unambiguously what you want, but natural language is ambiguous which is why legalese exists.
So you need to have an unambiguous source language for what's end up being executed by your machine (which is what programming languages are), otherwise you have no way of knowing if the machine does what you want it to do.
Of course you can use an LLM to translate natural language to unambiguous language, but at the end of the day you must read the generated language because that's the only way to dispel the fundamental ambiguity of the natural language.
I saw a webcomic ten years ago where a project manager discussing the future automation of programmer's jobs:
PM: “In the future, there will be no developers, just project manager. We will just give the machines very complete and precise specifications and it will make the software on its own. Without needing you”.
Dev: “You know how we call a "very complete and precise specification"? It's called code”.
Practical argument for vibe coding in C: the training corpus is probably much higher quality.
C code that survives in the wild tends to be written by experienced devs who care about correctness. The JS corpus includes mountains of tutorial code, Stack Overflow copypasta, and npm packages with 3 downloads. In my experience, generated C is noticeably better—and this might be why.
How well can LLMs reason about avoiding UB? This seems like one of those things where no matter how much code you look at, you can still easily get wrong (as humans frequently do).
Fair point on UB — LLMs absolutely do not reason about it (or anything else). They just reproduce the lowest-common-denominator patterns that happened to survive in the wild.
I’m not claiming the generated C is “safe” or even close. I am sure that in practice it still has plenty of time-bombs, but empirically, for the narrow WASM tasks I tried, the raw C suggestions were dramatically less wrong than the equivalent JavaScript ones — fewer obvious foot-guns, better idioms, etc.
So my original “noticeably better” was really about “fewer glaring mistakes per 100 lines” rather than “actually correct.” I still end up rewriting or heavily massaging almost everything, but it’s a better starting point than the JS ever was.
It is not portable to computers other than x86. It is one of the reasons I do not use x86 assembly much even though I have a x86 computer; I prefer C. It is not about vibe coding.
> I suppose what I’m getting at, here, is that if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP. You read it here first.
Someone told me that two companies (one of which is Google) were working on such a thing, although I do not know the details (or if they were correct about that), and I do not know whether or not it resembles what is described in that article.
I do not use LLM myself, although I have seen a few examples of it. I have not seen very many so the sample size is too small, but what I have seen (from simple example programs), the program works although it is not written very well.
Many of the “no” comments here are very focused on the current state. The author seems to be looking at a longer time horizon of computing paradigms, for example invoking ENIAC. On that scale I tend to agree. Vibe coding has only been around a year or two and look how big of an impact it already has. Imagine what another 10 years of progress will look like.
The vast majority of software models are trained on have little to no standards and contains all kinds of errors and omissions.
And these are systems that require a human in the loop to verify the output because you are ultimately responsible for it when it makes a mistake. And it will.
It’s not fun because it’s not fun being an appendage to a machine that doesn’t know or care that you exist. It will generate 1200 lines of code. You have to try and make sure it doesn’t contain the subtle kinds of errors that could cost you your job.
At least if you made those errors you could own them and learn from it. Instead you gain nothing when the machine makes an error except the ability to detect them over time.
I think if you don’t know C extremely well then there’s no point vibe coding it. If you don’t know anything about operating systems you’re not going to find the security bugs or know if the scheduler you chose does the the right thing. You won’t be able to tell the difference between good code and bad.
My gut reaction is, if AI was really good at vibe coding all the infra it could be nice, but getting C deployed and productized is the potential challenge. The "roads" we built for hyper scaling apps doesn't strike me as C friendly. And, even with the friendlier deployment strateies on next, python, etc, AI still slips up a lot.
Vibe coding is mostly for solo devs anyway. If you work with a team you need to carefully think out how everything pieces together, how it will be later understood by other devs, what the plan is a few yrs down the road.
AI just gives suggestions but you have to make all the hard choices and fix/simplify a lot of the output
There is a hidden hypothesis in this article that AI "does not struggle" with things like undefined behaviour, off by one errors and undefined behaviour.
Yes, it can consistently generate code that works and seems to be on top of it all due to a lot of training data. But wouldn't that use up more tokens and computational resources to produce than e.g. the same program in python?
If using more complex languages requires more resources from LLM, the same principles apply. One-off scripts are better in high level languages. Hot paths executed millions of times a second are better in lower level languages with high optimisation potential.
LLMs might slightly shift the correct choice towards lower languages. E.g. a small one-off script in C is much more viable with LLM's help. But the moment one needs to reuse it, it grows, and needs to be modified, one might regret not using higher level language.
I've vibe coded a few things in C now as experiments, but I haven't been brave enough to put any of them into production code yet. I don't trust myself to review them properly.
> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? Why not have it just write C? Or hell, why not x86 assembly?
Or why not just produce a binary directly?
It seems we've just invented a compiler.
Obviously right now the best language to use LLMs for, vibe coding or not, is whatever they are most familiar with, although not sure what this actually is! Java?
Going forwards, when LLMs / coding tools are able to learn new languages, then languages designed for machines vs humans certainly makes sense.
Languages designed for robust error detection and checking, etc. Prefer verbosity where it adds information rather than succintness. Static typing vs dynamic. Contractual specification of function input/output guarantees. Modular/localized design.
It's largely the same considerations that make a language good for large team, large code base projects, opposite end of the spectrum to scripting languages, except that if it's machine generated you can really go to town on adding as much verbosity is needed to tighten the specification and catch bugs at compile time vs runtime.
Great point, except for one huge insurmountable non-technical problem with Java that can be invoked in a single word: lawnmower.
“Do not fall into the trap of anthropomorphizing Larry Ellison. You need to think of Larry Ellison the way you think of a lawnmower. You don’t anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it’ll chop it off, the end. You don’t think ‘oh, the lawnmower hates me’ — lawnmower doesn’t give a shit about you, lawnmower can’t hate you. Don’t anthropomorphize the lawnmower. Don’t fall into that trap about Oracle.” -Bryan Cantrill
“I actually think that it does a dis-service to not go to Nazi allegory because if I don’t use Nazi allegory when referring to Oracle there’s some critical understanding that I have left on the table […] in fact as I have said before I emphatically believe that if you have to explain the Nazis to someone who had never heard of World War 2 but was an Oracle customer there’s a very good chance that you would explain the Nazis in Oracle allegory.” -Bryan Cantrill
The main benefit of C is that it is especially readable by humans.
I think that’s what makes it so common in codebases that have long term maintenance stories.
(I say that because my personal project has me reading great loads of C written by diverse authors and I am surprised at how easy it is to figure out, compared to most other languages)
It sounds like his main gripe of vibe coding is it robs you of the satisfaction as a programmer in solving the problem. I don't disagree, but the preferences of programmers are not necessarily the main driving force here behind these changes. In many cases it's their boss and their boss doesn't really care.
It's one thing to program as a hobby or to do programming in an institutional environment free of economic pressures like academia (like this educator), it's another thing to exist as a programmer outside that.
My partner was telling me her company is now making all their software engineers use ChatGPT Codex. This isn't a company with a great software engineer culture, but it's probably representative of the median enterprise/non SV/non tech start employer than people realise.
Why should it be the case that LLMs are equally comfortable in x86 Assembly and Python? At least, it doesn't strike me as implausible that working in a human-readable programming language is a benefit for an LLM that is also trained on a bunch of natural language text alongside code.
It’s not a super useful line of inquiry to ask “why” LLMs are good at something. You might be able to come up with a good guess, but often the answers just aren’t knowable. Understanding the mechanics of how LLMs train and how they perform inference isn’t sufficient to explain their behavior a lot of the time.
Traditionally, I used Python for personal tools optimizing for quick coding and easy maintenance. These tools commonly feed UI elements like waybar, shell, and tmux, requiring frequent, fast calls.
My approach is evolving due to NixOS and home-manager with vibe coding to do the lifting. I increasing lean on vibe coding to handle simple details to safely write shell scripts (escaping strings, fml) and C/C++ apps. The complexity is minimized, allowing me to almost one-shot small utilities, and Nix handles long-term maintenance.
With NixOS, a simple C/C++ application can often replace a Python one. Nix manages reading the source, pulling dependencies, and effectively eliminating the overhead that used to favor scripting languages while marking marginal power savings during everyday use.
> If You’re Going to Vibe Code, Why Not Do It in C?
Or assembly, or binary
Yes, this is a completely valid take and it is the ultimate answer to why vibe coding, the way most people define vibe coding is a dead end.
The point is we want the LLM to generate code that is first and foremost readable by humans and structured in such a way that a human can take over control at any time.
If you think this is how LLM should generate code, congratulations we are already in agreement.
If you think programmers should not exist and that you will help your bottom line by reducing the number of programmers on your payroll or worse, completely eliminate programmers from your payroll by paying product managers who will never ever look at the code (which is required for vibe coding the way I understand it), then this question at the top is for you.
"If you're going to vibe code, why not do it in assembly?"
Many people I've seen have taken existing software and 'ported' it to more performant languages like C, Rust, etc.
LLMs are extremely efficient and good at translation.
The biggest question is maintainability and legibility. If you want it for your own proprietary software, this can (and probably is, generally) a good pattern if you can get the LLM to nail language specific challenges (e.g. memory allocation in C)
However, fewer people can write C code generally, and even fewer can use it to build things like UI's. So you're by definition moving the software away from a collaborative mechanism.
The abstraction layers were built for human maintenance. LLMs don't need that.
From what I have seen successful ~vibe-coders in my cirle are really bullish on type-safety and testing. Up to a point I have seen a guy porting his favourite property-based testing framework to TypeScript :D
So, vibecoding in C feels like playing with loaded gun.
It's so refreshing to see a proper website these days, no js, no cookie banners, just hypertext. Your part about still enjoying programming really resonated with me. I still get so much joy out of programming after 20 years of doing it, it's still just as exciting to learn new things, and I am definitely not running out of new things to learn.
I would absolutely love to teach programming to non-programmers. I have also been offered a job at the technical school where I graduated. But remembering how uninterested the vast majority of my classmates were back then discouraged me from even trying. I guess what I'd want is a teach a room full of people excited to learn about programming.
I like the idea of reimagining the whole stack so as to make AI more productive, but why stop at languages (as x86 asm is still a language)? Why not the operating system? Why not the hardware layer? Why not LLM optimized verilog, or an AI tuned HDL?
Probably because then it wouldn't be software anymore. That is because you will be required to do a physical process (print an integrated circuit) in order to use the functionality you created. It can definitely be done, but it takes it too far away from the idea the author expressed.
But I don't see a reason why the LLM shouldn't be writing binary CPU instructions directly. Or programming some FPGA directly. Why have the assembly language/compiler/linked in between? There is really no need.
We humans write some instructions in English. The LLM generates a working executable for us to use repeatedly in the future.
I also think it wouldn't be so hard to train such a model. We have plenty of executables with their source code in some other language available to us. We can annotate the original source code with a model that understands that language, get its descriptions in English, and train another model to use these descriptions for understanding the executable directly. With enough such samples we will be able to write executables by prompting.
> all the way to the borderlands of active anxiety—not quite understanding what Claude just wrote.
This is a big issue, personally. I write Python and bash these days and I love that we're not bottlenecked by IDE-based autocomplete anymore, especially for dynamic languages and a huge amount of fixing and incremental feature work can be done in minutes instead of days thanks to AI being able to spot patterns. Simultaneously I'm frustrated when these agents fail to deliver small changes and I have to jump in and change something I don't have a good mental model of or, worse still, something that's all Greek to me, like Javascript.
ive been vibe coding (i think it's vibe coding) in C for the past three weeks and it's been super fun. i was tasked with trying to improve our highly optimized hyper-graph partitioning algorithm. One of the fun things i like to do is feed the llm an academic paper, have it summarize the key pts, and then implement the algos that we (me and the llm) find interesting. This feels like i hit the fabled 10x productivity mark because it would have taken me at least a week (probably more) to digest a paper enough to implement it, and often I would give up, convincing myself it's not worth the time / effort. So 10x might even be a low ball.
I can feel ya ... Nothing more fun then vibe coding b-tree, ART, LSM, Double pointer b-tree, bw-tree, ... and so many other storage solutions relying on different indexes, compressions etc.
And having them fight it off between each other. To see where the issues are with each methode, what works better. Doing that without vibe coding the hell out of it, will take months of work, but with vibing and some cash, you do it in a few days.
Thinking about the programming language as a first requirement when vibe coding is probably not the smartest move. The programming language choice (beyond being fit for your purpose) is how prevalent it is in the training data for the model (more examples for what you want to achieve -> better results). When vibe coding the most important things are to know how to spec what you want to achieve and how you measure the results. The programming language is just a tool.
No need for using assembler, LLMs should be writing machine bits directly into executables. It is also fairly simple to teach them how to do it. Provided we have some executable that was written in some human-readable computer language. We can read through the bits of the executable, and describe each portion using English, based on the description of what the original human-readable language is doing. This new model will only learn the English representation of chunks of bits and how they go together into an executable. After learning several billion such narrated executables it will be excellent at writing machine code.
I agree that coding is more fun than vibe coding, right up until you have a massive refactor that is super repetitive and no fun to author, but an LLM can do it in no time flat. Even if an IDE can help with the refactor, there are cases where they can't. And anyways, if you're working with a codebase you understand but are not super familiar with, then vibe coding is incredibly productive, though, well, you'll spend much more time reviewing what the LLM did, so maybe not quite that productive (unless you count on others to do your review, but that's not very nice, and it will show).
I've wondered what vibe codings impact is to language development, whereas C vs LISP had their tradeoffs when deciding what to use. If everything is vibecoded (not saying it will be) everything probably normalizes to javascript
That's what this discussion made me think of. To take it further -- if you were going to design a language expressly for AI-generated code, what might some of it's features be?
I think strong static typing probably? Which is, well, not javascript in fact! (And I have bucked the trend on this previously, liking ruby -- but I'm not sure I'd want AI-generated code without it?)
Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FAUST (for audio DSP)?
None of our existing programming languages were designed for quite the circumstance in which contemporary programming now finds itself; they all address an ergonomic situation in which there are humans and machines (not humans, machines, and LLMs).
It's possible, I suppose that the only PL that makes sense here is the one the LLMs "knows" best, but I sort of doubt that that makes sense over the long term. And I'm repeating myself, but really, it seems to me that a language that was written entirely for the ergonomic situation of human coders without any consideration of LLMs is not addressing the contemporary situation. This is not a precise analogy, but it seems to me a little like the difference between a language that was designed before vs after multicore -- or before vs after the internet.
The problem with creating a programming language for LLMs, goes back to, what are LLMs? They are trained on masses of human written code, that is written in human readable form.
So even if you make a better programming language for a LLM, it has nothing to train on. Unless we start to transcode human language code to the LLM code.
Are the vectors/tokens/whatever, not already LLM code at this point? Technically, LLMs not are doing what Haxe was doing (haxe.org) but in a more advanced form?
Even if we make a more LLM like programming code, in a sense, we are just making another code that needs to be translated into the tokens that consist in a LLM model, no?
Feels like we are starting to hit philosophical debates with that one lol
Idk why the author thinks that C would be a better language than Rust for vibe coding. Intuitively, I would have thought that the more formal constraints the system imposes, the better for vibe coding (since the more powerful static checks make it harder to write incorrect code).
Of course in practice I think the author is actually correct - LLM's struggle more than humans with sophisticated formal constraints and less than humans with remembering to write a bunch of boilerplate. But I think it's a pretty counterintuitive result and I'd love to have seen more discussion of it.
If the LLMs of today can even produce a sizable C program that compiles, doesn't leak memory, doesn't exhibit UB, doesn't have any obvious vulnerabilities, and is correct, I would be astounded.
If you want to get to a higher level compiler, prompt fondling will not suffice; you need to master formal specification. Then machine learning algorithms can do the program synthesis to implement the spec. But just talking out your vague software requirements with a chatbot is not analogous to programming.
Also, like others said, even once you have your formal spec, C is a particularly bad choice (unless you want to specify quite a bit more). You want the program implemented in a language with as many safety constraints on it as possible, not one where you have to mentally track memory.
Do it in Ada, SPARK, Zig, Rust, Pascal, Crystal, etc.
Unless it's an existing project where migration is too costly, C is just entering a time wasting pact along with a lot of other people that like suffering for free.
Great post. Love the writing style that is at once both casual and erudite.
I must take issue with the central point however: the machines of LLMs are very different than the machines of CPUs. While it is true that Claude writes fewer memory errors than even expert C programmers (I’ve had to fully accept this only this week), the LLM is still subject to mistakes that the compiler will catch. And I dare say the category of error coding agents commit are eerily similar to those of human developers.
I have been coding as an autodidact for 20 years now. In the past months, I have been vibe coding a lot, with multiple AIs at the same time. I have achieved to code a full webapp (React and Next.js for the front, RestJS for the back) in five days. Refactoring, adding features and writing the right tests for everything to work has been procuring me with the same problem solving and endorphin kicks as usual programming.
Just don't vibe code something which you could do yourself, maybe that is the issue of the author.
Either you contradicted your own advice in a 5 sentence comment, or you suggested that you couldn't code a web app despite 20 years of experience. Either is pretty damning.
Never used C much, but I would assume it is more LOC than a newer language with more features. Less code is a fairly important feature for LLMs with relatively limited context windows.
* boring and straightforward syntax and file structure: no syntax sugar, aliases, formatting freedom that humans cherish, but machines are getting confused, no context-specific syntax.
* explicitness: no hidden global state, shortcuts and UB
On the topic: I feel like we still need at least a few more innovations in the space before we can rely on them to work in areas where we as humans still have trouble (that pesky training data!). Even when providing documentation, I still find LLMs to often have trouble creating code in newer versions of libraries.
My biggest fear with LLMs is that it will steer a lot of development into a more homogenous space over time (even just with the types and versions of libraries it chooses when vibing).
I started reading this out of curiosity, thinking: that's such a far fetched thought, I'm curious about what the author wants to say.
I think he makes a good point about execution vs. readability, and the actual need for the latter, drawing analogies to earlier abstractions.
I'm still skeptical about low level language generation (tbh, letting an LLM handle memory at this point of maturity feels scary to me.. leaks etc)... But overall very interesting writeup and many points that I agree with.
I believe they are arguing against vibe-coding categorically by pointing out that high-level programming languages are for human expression. It's a reductio ad absurdum against the logical conclusion that follows from vibe coding as a premise. If vibe coding is like a using a compiler, why not just translate English directly to machine code or lower level languages?
I'm trying to build a extremely simple exercise timer app for multiple platforms, and using Gemini and Junie, I Evaluated Rust+Tauri, Cpp+GT, SWIFT+SWIFTUI, Kotlin+MP, and Dart/Flutter, even though I started hating flutter, when started working with Jetpack Compose for KMP, I have to recognize that flutter is the best option for MP. Maturity, Ecosystem, UI+Backend in a single codebase, etc.
My concept was to build HLL to C/C++ (or Rust) translators using mostly, non-AI tech. Then, use AI's with whatever language they were really good at. Then, transpile it.
Alternatively, use a language like ZL that embeds C/C++ in a macro-supporting, high-level language (eg Scheme). Encode higher level concepts in it with generation of human-readable, low-level code. F* did this. Now, you get C with higher-level features we can train AI's on
If you're vibe coding, I highly recommend TDD. It makes it very easy for a coding agent to iterate on it. You gotta bonk it sometimes when it tries to delete a problematic test etc, but hallucinating a test suite along with your app really helps a lot. (I've been vibe coding a scripting language/compiler for a video game project I'm working on in this way, and it's been fascinating and mostly great.)
I get the agent to do it generally. (I realize this seems incestuous, but its fairly easy to validate the tests are sensible as you add features, because the biggest risk is regressions as the AI does something dumb later.)
If you're going to vibe code, with an intent to review the output so that the ultimate product is actually useful and does what was intended, you should do it in whatever language(s) you're knowledgeable in so you can actually competently review that output.
If you don't give a damn about integrity though, then may as well get funky with it. Hell, go hard: Do it in brainfuck and just let it rip.
"If you ask PMs about backend requirements, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements."
>Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal
I was really hoping you were going to make this argument, based upon the title of the piece! Still a good read, but if you have the inclination I hope you loop back around to weighing the pros and cons of vibe coding in different languages
LLMs are good at in-distribution programming, so inventing a new language just for them probably won’t work much better than languages they were already trained on.
If you could invent a language that is somehow tailored for vibe coding _and then_ produce a sufficient high quality corpus of it to train the AI on them, that would be something.
I have been developing a game with this process, specifically for portability, reach and distribution across multiple game engines and platforms.
I find CUX to be very intuitive for prototyping. But my game is Language and HCI at heart, logic that allows the development process to go smoothly. It is certainly not for everyone or every project.
> Why vibe code with a language that has human convenience and ergonomics in view?
Because you would not be able to audit the code if you don't (you'll be terribly slow to read and understand the inner flows correctly and that's if these aren't so bad that would do you some brain damage).
If you're going to vibe code on legacy code, use the languages used there. If you're going to vibe code something new, then I recommend Rust. There are few cases where I would vibe code something brand new in C, mainly when building a library I'm going to need to use from other C programs.
Why not do it in English? I have a "program" that exists entirely as the history of an AI chatbot session. To "run the program" I load the history and a file into the message context and say "Now do this file." It kind of reminds me of a Smalltalk VM in a weird way.
Along the same lines, I am rewriting a React Native app into native Swift and Kotlin versions. I haven’t written any of the native code directly - it’s all vibed. It’s not C but there’s a lot of upside in letting Claude Code compile my wishes into native languages and skip the RN layer.
Code in whichever language suits your problem, whether you're vibing or not, the trade-offs are mostly the same. Yes, I could use C if I cared more about runtime than development time; it will take me longer to code review AI generated C code.
Vibe coding produces great one shot proofs of concept that fit inside its context window.
It produces hot garbage when it needs to bring together two tokens from the far ends of a large code base together.
This comes as no surprise to anyone who understands what the attention mechanism actually is, and as a great surprise to everyone who thinks transformers are AI magic.
> I also think it takes a lot of the fun out of the whole thing.
I used to say that implementation does not matter, tests should be your main focus. Now I treat every bit of code I wrote with my bare hands like a candy, agents have sucked the joy out of building things
If you’re going to vibe code, why not do it in Brainfuck?
Claude hilariously refused to rewrite my rails codebase in Brainfuck…not that I really expected it to. But it went on a hilarious tirade about how doing so was a horrible idea and I would probably fired if I did.
This is one area I do use LLMs for, write small utils and test code, and very often in languages I very seldom even touch, such as C# and Rust. This to me seems to be the core idea of a tool that is awesome at translating!
Context limit and build time are a couple of reasons. There is C++ code at work I told it to rewrite in Python just to make it easier to vibecode (or regular code) after. Granted, it had no good reason to be in C++ in the first place.
Its very highly probable that AI is going to generate slop at some point so if you dont know much about how it works, you are doomed. Once it starts going towards slop it just keeps getting deeper until you reach a point where every simple problem feels like you need a new repo
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that. Because when you start giving it little programming problems that you can’t be arsed to work out yourself (as I did), you discover (as I did) that it’s awfully good at those. And then one day you muse out loud (as I did) to an AI model something like, “I have an idea for a program…” And you are astounded. If you aren’t astounded, you either haven’t actually done it or you are at some stage of grief prior to acceptance. Perfect? Hardly. But then neither are human coders. The future? I think the questions answers itself.
Tons of people make the above claim and tons of other people make the exact opposite claim that it’s just a search engine and it can’t actually code. I’m utterly shocked at how two people can look at ground truth reality and derive two different factual conclusions. Make no doubt one of these two people is utterly wrong.
The only thing I can conclude is many people are either in denial or outdated. A year ago none of what this man said was true.
Because, the programming languages best matched to a (natural human language-based) declarative programming paradigm (e.g., vibe coding) would be declarative programming languages, not imperative programming languages.
Honestly, I think this is a valid viewpoint, but perhaps C is too low level. The bottleneck in generating code with LLMs tends to happen at the validation step. Using a language that has a lot of hard to validate footguns isn't great.
While I am not a big fan of Rust, the philosophy is likely useful here. Perhaps something like it, with a lot of technical validation pushed to the compiler, could actually be really useful here.
Getting rid of the garbage collector with no major increase in human cognitive load might actually be a big win.
It is interesting though that if it's all the same anyway - why not write formally proved software. Or write the same spec in three different languages to cross check correctness.
I do vibe code in C. From what I understand, Ruby is written entirely in C. It's a wonderful high-level language experience on top of such a storied runtime as C (truly!).
I made the same comment last week upon learning of a redis clone entirely vibe coded in IIRC ~70k lines of Rust. Why Rust? Why does a computer need a memory safe language?
great read
so as i have understood to why ai is generally good at web dev and not so good at other low level stuff is
"more data to train better the model".
So model trained on the whole web > a model particular trained on a single language (in this case c).
and i also think you can't go lower than C in this case, since below that the code is architecture specific and so even less data to train on.
would love what others think
I guess vibe coding is fun as a meme, but it hides the power of (what someone else on HN) called language user interfaces (LUIs).
The author's point is correct IMO. If you have direct mappings between assembly and natural language, there's no functional need for these intermediate abstractions to act as pseudo-LUIs. If you could implement it, you would just need two layers above assembly: an LLM OS [1], and a LUI-GUI combo.
However, I think there's a non-functional, quality need for intermediate abstractions - particularly to make the mappings auditable, maintainable [2], understandable, etc. For most mappings, there won't be a 1:1 representation between a word and an assembly string.
It's already difficult for software devs to balance technical constraints and possibilities with vague user requirements. I wonder how an LLM OS would handle this, and why we would trust that its mappings are correct without wanting to dig deeper.
[1] Coincidentally, just like "vibe coding", this term was apparently also coined by Andrej Karpathy.
[2] For example, good luck trying to version control vectors.
Why have types? AI can infer everything. The ultimate ai language is as terse as possible to keep token count down but can still be understood by a human
Oh? I've had great luck with LLMs and homemade ILs. It has become my favourite trick to get LLMs to do complex things without overly complicating my side of the equation (i.e. parsing, sandboxing, etc. that is much harder to deal with if you have it hand you the code of a general purpose language meant for humans to read).
There is probably some point where you can go so wild and crazy with ideas never seen before that it starts to break down, but if it remains within the realm of what the LLM can deal with in most common languages, my experience says it is able to pick up and apply the same ideas in the IL quite well.
People are still confusing AI putting together scraps of text it has seen that correlates with its understanding of the input, with the idea that AI understands causation, and provides actual answers.
And people are also still clearly confusing "isn't human or conscious" with "can't possibly create new logical thoughts or come to new logical conclusions i.e. do intellectual labor" when there is a plethora of evidence at this point that the latter is, in fact, the truth
I'm not sure if you mean that as a dig, or not, but if you are referring to me then I have these data points to discuss.
1. I have encountered a problem where AI will suggest 4 different "solutions" and when I point out a problem with one, it cycles on to the next, and stays in that loop, repeating over and over that set of 4, with no recollection of the previous refutation of the soltuion (this is a mix of context retention, and the fact that the solution selection is limited to that which has already been fully explored on the web - I had a 5th idea in mind which the AI failed to understand, but worked well)
2. Yesterday I was discussing with AI the fact that I had three options for action, and it misunderstood that as 4 actions, a trivial arithmetic failure.
This demonstrates (clearly) that the AI didn't "understand" the points discussed, and was instead staying with the correlation of text with other text.
I really like where AI is at the moment and use it a lot - it's very helpful for debugging, for example, but as every vibe coder out there will attest, AI fails hard at standalone coding, and I submit that this is a symptom of its inability to understand what its doing.
It's still correlation is not causation, and it demonstrates why correlation is so attractive, you can get quite far knowing that there is a correlation between ice cream sales and shark attacks, but it takes work to understand that there is no causative link (FTR I suspect that it's because ice cream sales go up in hot weather, more people are in the ocean during those hot weather periods, therefore there's more opportunity for people to interact with sharks)
Edit: Note how I use the word "suspect" when I talk about the cause of the correlation - it's VERY tempting to say that the weather is the cause, but that's still a correlation, and the fact is, as humans have discovered, actual research is required to verify whether that is, indeed, the cause, or not - something AI might miss.
Another data point has just arisen - I have a function (in Go) that accepts an unpacked slice of `interface{}` (some people will now call that an unpacked slice of `any`)
I was calling that function with an unpacked slice of string - eg
The AI I was using (Claude for the purposes of this discussion) incorrectly told me that I first needed to convert the slice of string to a slice of interface before calling the function
It argued with me when I said that I didn't and demanded I TIAS to prove its point, and report the compile time errors
Of course, I did, and there were no errors
The issue was that the AI (Claude) did not understand that `interface{}` or `any` means that any type can be used there.
Claude is doing a fantastic job, but this is an example of it not actually understanding what's happening.
I don't contest these examples, but that's exactly why I call what it does "thunking" (think: "clumsy thinking") instead of "thinking" (in order to get around the epistemological/philosophical problems of "is it conscious?" or "does it understand?"), and since it doesn't "understand," it "undersits", and it doesn't "comprehend", it "prehends" or "ingests".
It is trained on WASM btw, but if we invented one specific for it, it could easily be trained up on it or refined with it. I've already had some success just handing it a language guide and it runs with it.
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong.
I spend all day in Claude Code, and use Codex as a second-line code reviewer.
They do not create robust systems. They’ve been a huge productivity boost for me in certain areas, but as soon as you stop making sure you understand every line it’s writing, or give it a free reign where you’re not auto-approving everything, the absolute madness sets in.
And then you have to unpick it when it’s trying to read the source of npm because it’s decided that’s where the error in your TypeScript project must lie, and if you weren’t on top of the whole thing from the start, this will be very difficult.
Don’t vibe-code in C unless you are a very strong C developer who can reliably catch subtle bugs in other people’s code. These things have no common sense.
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong.
This is such a bad take. I'm convinced that engineers simply don't understand what the job is. The point was never "does it output code that works", the point is "can it build the right thing in a way that is maintainable and understandable". If you need an LLM to understand the output then you have failed to engineer software.
If all you're doing is spitting out PoCs and pure greenfield development then I'm sure it looks very impressive, as the early language models did when it looked like they were capable of holding a conversation. But 99% of software engineering is not that kind of work.
This author, like many others on this site, seem to imply that AI generates "good" code, but it absolutely does not---unless he's running some million dollar subscription model I'm unaware of. I've tested every AI using simple Javascript programs and they all produce erroneous spaghetti slop. I did discover that Claude produces sufficiently decent Haskell code. The point is that the iterative process requires you know the language because you're going to need to amend the code. Therefore vibe in the language you know. Anyone that suggests that AI can produce a solid application on its own is a fraud.
The Erlang space vs the Elixir space (can't speak for agent based code generation here) would seem to give credence to this theory.
When I would explore Elixir forums with much larger communities there'd be myriad base level questions with code blocks written as if Elixir and Ruby were interchangable cause the syntax looks similar and thus missing out on many of the benefits of OTP.
But when you'd go to the Erlang community to ask a question, half the time the author of the book or library was one of the like... 20 people online at any given moment, and they'd respond directly. The quality of the discussions was of course much deeper and substantial much more consistently.
I have not tried to generate Elixir vs Erlang code but maybe it'd be a neat experiment to see if the quality seems better with Erlang
You, like many others, seem to imply that humans write "good" code, but they absolutely do not--unless they are running some million dollar team with checks and cross checks and years of evolving the code over failures. I've tested every junior developer using simple Javascript leetcode quizes and they all produce erroneous spaghetti slop.
The difference is, we forgive humans for needing iteration. We expect them to get it wrong first, improve with feedback, and learn through debugging. But when AI writes imperfect code, you declare the entire approach fraudulent?
We shouldn't care about flawless one-shot generations. The value is in collapsing the time between idea and execution. If a model can give you a working draft in 3 seconds - even if it's 80% right - that's already a 10x shift in how we build software.
Don't confuse the present with the limit. Eventually, in not that many years, you'll vibe in English, and your AI co-dev will do the rest.
Vibe Coding is just a stepping stone to No Coding.
No one (other than computer people) wants computers and software, they want results.
This generation of AI will be used to bootstrap the next generation of AI.
Programmers getting excited about vibe coding is like candlemakers getting excited about installing electric lights in their shops, so they can make more candles!
Or a stepping stone to starting a lighting company. The nature of programming changes when implementation can be automated. That still leaves higher level concerns like design and architecture.
I also don't _love_ vibe coding and do it just for exploration/recreation, but I also have long thought an LLM trained and tuned specifically for a language that is best for LLMs might be ideal.
Currently, using Claude to vibe code Rust is _much_ more hit-or-miss than using it for Python... so Python has become the lingua franca or IR I use with it.
Often I'll ask Claude to implement something in Python, validate and correct the implementation, and in a separate session ask it to translate it from Python to Rust (with my requirements). It often helps.
Claude is particularly bad at hallucinating the APIs of Crates, something it does a lot less for python.
But I have been vibe coding in C. Created a parser/compiler for a subset of the C programming language that compiles to microcode for a novel computing architecture. Could I have done this on my own? Sure, but if I did I would've probably have done it in OCaml. And it would've taken me a lot longer to get it to the point where it is now. I think the advantage of vibe coding this (at least for me) is that I would have a hard time getting started due to procrastination - and I'd have a hard time keeping interested if there wasn't something working (yeah, maybe I'm a little ADHD, but aren't we all at this point?). Vibe coding it got me to something that was working pretty well in a surprisingly short amount of time which tended to make me more engaged without losing interest and attention. I didn't have to get caught up in remembering the intricacies of creating a makefile to build the code, for example. That's one of many places where I can get bogged down.
Does anybody else feel that vibe coding only works in Python JavaScript, and maybe Go? It seems like once you get more esoteric than that everything goes out the window. Zig code is laughable. I can't get LLMs to write a single cogent function in OCAML, things break catastrophically at 10 LOC. I haven't seen anybody else describe this experience.
Yeah it struggles with long tail languages. Zig in particular since even within the small training set there have been many versions with breaking changes
> Vibe coding actually works. It creates robust, complex systems that work.
No, it absolutely doesn't. We've seen so much vibe coded slop that it's very clear that vibe coding produces a hot mess which no self respecting person would call acceptable. No idea how you can say this as it isn't remotely true.
If we ignore human readability (as the author suggests), the answer is context. The token count explodes as you fall down the abstraction rabbit hole. Context consumption means worse reasoning.
In turn, this means expressiveness matters to LLMs just as much as it matters to us. A functional map reduce can be far simpler to write and edit than an imperative loop. Type safety and borrow checking free an LLM from having to reason about types and race conditions. Interpreted languages allow an LLM to do rapid exploration and iteration. Good luck with live reloading a GUI in C.
And if you were to force the LLM to do all that in C, at some point it might decide to write its own language.
The author makes 2 fundamental errors in reasoning. The first is saying that the language model can program, it can't, it can generate code, maybe researchers at top labs can get it to create some trivial programs but I digress.
The second and more important point is that what makes coding simpler for humans is the ability of the language to facilitate communication so you don't have to translate, now LLMs are good at translation, but it's still work. Imagine you have an implementation of a program and you want to see what it does, for any non-trival program you must scan millions of tokens, are current LLMs even physcially capable of attending to that? nonono we need names.
Besides how can you even vibecode if you aren't (just) using names.
A legitimate point, there are lots of performance and fine grain changes you can make, and it's a simple, common language many people use. Perhaps we could realize some of these benefits from a simple, fast language.
> Or hell, why not do it in x86 assembly?
A terrible take imo. This would be impossible to debug and it's complex enough you likely won't see any performance improvements from writing in assembly. It's also not portable, meaning you'd have to rewrite it for every OS you want to compile on.
I think there's an argument that if machines are writing code, they should write for a machine optimized language. But even using this logic I don't want to spend a bunch of time and money writing multiple architectures, or debugging assembly when things go wrong.
If the boosters are correct about the trajectory of llm performance, these objections do not hold.
Debugging machine code is only bad because of poor tooling. Surely if vibe coding to machine code works we should be able to vibe code better debuggers. Portability is a non issue because the llm would have full semantic knowledge of the problem and would generate optimal, or at least nearly optimal, machine code for any known machine. This would be better, faster and cheaper than having the llm target an intermediate language, like c or rust. Moreover, they would have the ability to self-debug and fix their own bugs with minimal to no human intervention.
I don't think there is widespread understanding of how bloated and inefficient most real world compilers (and build systems) are, burning huge amounts of unnecessary energy to translate high level code, written by humans who have their own energy requirements, to machine code. It seems highly plausible to me that better llms could generate better machine code for less total energy expenditure (and in theory cost) than the human + compiler pair.
Of course I do not believe that any of the existing models are capable of doing this today, but I do not have enough expertise to make any claims for or against the possibility that the models can reach this level.
Eh. Vibe Coding is best when your “writing code to eyeballing results” is the smallest. It works well when you can “test” that your code works with purely looking at the result and clicking around.
For this it’s the web deployment target and fast compile times rather than the language itself that is useful.
Routinely I am sent code that works, but obviously nobody has looked at. Because they don’t even actually know what the code does.
For prototyping this is quite great. I think it’s the biggest competitor to tools like figma, because writing actually functional program with access to real APIs beats mocks. Now, how often will these end up in production and blow everything up…
> Why vibe code with a language that has human convenience and ergonomics in view?
Recently I've been preparing a series that teaches how to use AI to assist with coding, and in preparation for that there's this thing I've coded several times in several different languages. In the process of that, I've observed something that's frankly bizarre: I get a 100% different experience doing it in Python vs C#. In C#, the agent gets tripped up in doing all kinds of infrastructure and overengineering blind alleys. But it doesn't do that when I use Python, Go, or Elixir.
My theory is that there are certain habits and patterns that the agents engage with that are influenced by the ecosystem, and the code that it typically reads in those languages. This can have a big impact on whether you're achieving your goals with the activity, either positive or negative.
This kind of meets with my experience - AI tends to follow specific patterns for each language, earlier this year I was finding that AI was presenting me with 4 different approaches to a problem, none of them were working so it would cycle through each of the four approaches.
I lost a day chasing my tail cycling through those 4 approaches, but the experience was worthwhile (IMO) because I had beeen becoming lazy and relying on AI too much, after that I switched to a better style of using AI to help me find those approaches, and as a sounding board for my ideas, whilst staying in control of the actual code.
(Oh, I should also mention that AI's conviction/confidence did cause me to believe it knew what it was talking about when I should have backed myself, but, again, experience is what you get after you needed it :)
I expect this has been said before, but why not do it in whatever language you think has been written about the most, with the greatest amount of referenceable data and examples. Which probably isn't assembly, and probably not C either.
Which will probably store up a problem for the future, with an outsized amount of programs written in languages that were popular on SO when models started learning...
> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? Why not have it just write C? Or hell, why not x86 assembly?
In the game we're building we generate, compile and run code (C#) in real time to let the player "train and command" its monster in creative ways. So, I've thought about this.
You need both a popular language and one that has a ton of built-in verifying tools.
The author correctly highlights the former, but dismisses the latter as being targeted to humans. I think it is even more important for LLMs!
These coding agents are excellent at generating plausible solutions, but they have no guarantees whatsoever. So you need to pair them with a verifying system. This can be unit tests, integration tests, static / type checks, formal methods, etc. The point is that if you don't have these "verifier" systems you are creating an open loop and your code will quickly devolve to nonsense [0].
In my view, the best existing languages for vibe coding are:
- Rust: reasonably popular, very powerful and strict type system, excellent compiler error messages. If it compiles you can be confident that a whole class of errors won't exist in your program. Best for "serious" programs, but probably requires more back and forths with the coding agent.
- TypeScript: extremely popular, powerful type system, ubiquitous. Best for rapid iteration.
- Luau: acceptably popular, but typed and embeddable. Best as a real-time scripting sandbox for LLMs (like our use case).
I think there is space for a "Vibe-Oriented Programming" language (VOP as the author says), but I think it will require the dust to settle a bit on the LLM capabilities to understand how much can we sacrifice from the language's lack of popularity (since its new!) and the verifiability that we should endow it with. My bet is that something like AssemblyScript would be the way to go, ie, something very, very similar to an existing, typed popular language (TS) but with extra features that serve the VOP needs.
Another aspect to consider besides verifiability is being able to incrementally analyze code. For structured outputs, we can generate guaranteed structures thanks to grammar-based sampling. There are papers studying how to use LSPs to guide LLM outputs at the token level [1] . We can imagine analyzers that also provide context as needed based on what the LLM is doing, for example there was this recent project that could trace all upstream and downstream information flow in a program thanks to Rust's ownership features [2].
Finally, the importance of a LLM-coding friendly sandbox will only increase: we already are seeing Anthropic move towards using LLMs to generate script as a way to make tool calls rather than calling tools directly. And we know that verifiable outputs are easier to hillclimb. So coding will get increasingly better and probably mediate everything these agents do. I think this is why Anthropic bought Bun.
At some point in a career, one begins to encourage people to try replacing you and your team. Mostly, senior people become aware they are not there as some sort of fungible office decoration. Just do it... call the Managers bluff... the worst outcome is the team finds a better firm with someone smarter.
Slop content about slop code is slop recursive. Languages like C are simply very unforgiving to amateurs, and naive arbitrary code generators. Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
This is such a bad take I don't even know where to start... Even if you think vibe coding _is_ the future, there are still so many things wrong about this article. It's like the author has a fundamental misunderstanding why we even create programming languages.
I actually think that they have a good handle on the motivation for programming languages design. Think about C. C has many features that serve programmer ergonomics. The use of "=" for assignment and the use of "++" for incrementing there to serve the developer by reducing keystrokes. Yes there are some languages that are developed to be more formal, but that isn't the mainstream.
LOL, I got 100% nerd-sniped by my friend Sönke this week and wound up building a small spaceship.
On Monday he's like "Hey, what if you found obscure seed phrases embedded in public texts? You'd only need to remember the name of the book and the paragraph and go from there."
I honestly could care less about crypto(currencies) and I'm 100% sure this is like cryptanalysis 101. But, yeah, it seemed like an interesting problem anyways.
First, I downloaded a few hundred books from Gutenberg, wrote a ruby script and found BIP39 word sequences with a tolerable buffer for filler-words.
Then, I was like, okay, gotta now check them against actual addresses. Downloaded a list of funded ETH addresses. Wrote the checker in ruby. Ran it. No hits but this was now definitely weirdly interesting.
Because: And what if I downloaded the whole pg19 text corpus to scan! And what if I'd add BTC addresses! And what if I checked every permutation of the seed phrase!
Everything got really slow once I got to processing 12G of raw text for finding sequences and then checking a few million candidates with 44.000+ variations per candidate.
So, let's rewrite this into C! And since I've got 16 cores, let's parallelize this puppy! And since it's a MacBook, let's use GCD! Optimize all the things!
Lol, so NOW this thing is so fucking FAST. Takes four minutes to go through the full pg19 corpus and generates 64,205,390 "interesting" seed phrases. The fully parallelized checker (see Terminal screenshot) processes 460 derived addresses per second.
I really don't care if I get a match or not. I feel like I started with building a canoo and wound up with a spaceship is in itself just the best thing in the world.
It’s easy to answer why old-fashioned programming feels better to many people. It’s just alienation, or rather the relative lack of. It’s fulfilling to do things in a way that makes you feel like you have agency and are causing things to happen in ways that make sense to your own sense organs. It doesn’t even matter if “you” are doing it or “the tools” are doing the heavy lifting—who are you anyway, your thoughts, your tiny conscious mind on top of the iceberge of the unconscious?—, so you don’t have to get into the stupid quagmire ranging from “but abstractions and compilers” to “but Kant showed that thing-in-itself is different from the thing-as-sensed”, no, it’s fine, really; we all know (sense) when we feel in control or not.
But anyway. That’s all besides the point. Because the progress apologists[1] come in all shapes and forms (we are lead to believe), now also uber-passionate college professor who aah loves programming as much as the day he met her. But unlike you he’s a hard-prostheticed pragmatist. He both knows and sympathises with your “passion” but is ready to assert, in a tptacek-memetic style, that it is the way it is—and if you think otherwise (pause for effect), you are wrong.
Because don’t you see? Why are you so blind? No, we can’t let the chips fall as they may and just send you a “told you so” letter once everything you know-now is resolutely quaint. No, we must assert it right now. (So you don’t miss out on the wonderful ride.)
Aah the text complains. It saddens me to think of “coding by hand” becoming a kind of quaint Montessori-school... Oh, the twists and turns of the turbulent text, so organic. Just like your mind. But awake.
The room is at this point drenched in a mist of farts. Yes, programming by-hand, I think we ought to call it a quaintism at this point.
And did you know: people used to resist mechnical computers. Hmm? Yes, indeed, favoring people computers. The text prompts for another model to make an image of a person smirking so hard that their eyes become kind of diagonal and their cheeks disappear. But not in an evil cartoon character way. In a human way. That three years ago felt slightly off-putting. Now just looks like, well, you know.
- - -
Ahh. (Again.) These fools. With their hand-coding. Do they really think they will be employable three years from now? Well, no matter. I have a PhD from MIT along with my associate professorship. I only came out here to Iowa Community College because of my disabled son. Needed more time with him. And to get away from dat citation grind. Man. I have many organic hobbies. And a few very, really incredibly specific collections, as is fitting. puffs pipe Mmm yeah what do I care, so what if programming is quaint now—I’m already in my “ivory tower”, baby. People will listen to my takes on AI. They are appropriately detached, informal, just saying it like it is, you know? And if they don’t? Well, there’s an army of texts right behind me. They’ll be convinced to suppress any feelings of alienation eventually. Eventually, there will just be their own vanishing, small-minded, petty, “thoughts” on the matter. That tiny holdout. Against all content they can sense.
[1] Insert scare quotes here. All history is whitewashed. “We” progressed and defeated “them”. It’s all just a linear curve. No critical thinking is supposed to occur here. Those idiots thirty years ago used reusable underwear and had to load detergent into a washing machine and then even bend over to turn on a “button” to make the underwear reusable. Our underwear costs fifty cents, is made from the most comfortable plastic you can get, and dissolves and crumbles when it gets into contact with water; down the bathroom drain it goes.
A) I barely get to do any coding these days anyways
B) Reading code is harder than writing it (and thus, easier to gloss over), and by the time I'm ready to write code I've already done all the hard work (I.E. even if vibe coding made me 50% faster, it's 50% of 5% of the overall software development life cycle in this more senior role)
C) I've never even copied code from Stack Overflow into my editor (maybe once or twice in a couple decades), I always type things myself because it literally forces you to walk through character by character in a field where changing one character can easily lead to 8 hour bug hunts
D) There's probably not much world where I can't ramp up fairly quickly on how to prompt well
E) It seems to me everyone is spending all their time comparing model X with model Y, creating prompt context files, running multiple agents in parallel... if the purported gains are to occur, eventually we should have tools that require less of all that, and I can just use those later tools when they're around instead of learning a bunch of stuff that will naturally be useless (This is like if you became a Backbone JS expert and were left stunned when people started using React)
F) And if those gains don't occur (and the gains certainly seem to be leveling off quick, the comments today look much like the comments a few years ago, and I've really not seen much one way or the other when comparing a variety of coworkers in terms of productivity beyond POCs, and the starts of small scope green field projects (although, those can be accomplished by non technical people in some instances which is neat)) then... well... I guess I'll just keep doing what I've been doing for the last couple decades, but I won't have wasted a bunch of time learning how to prompt Grok vs Copilot vs ChatGPT or what ever and I'll still have tons of information in my head about how everything works
>Vibe coding actually works. It creates robust, complex systems that work.
No it doesn't. Just for the fun of it because I'm somewhat familiar with the VLC codebase I tried to fix some bugs with "agentic tooling" and "vibe coding". And it just produces crap. Which is one metric I'd propose for the usefulness of these tools, why aren't they fixing real bugs in the large open source codebases of this world? You'd be a hero, VLC has like 4000 open issues.
The answer is of course because these tools, in particular in manual memory managed languages which the author proposes to use, don't work at all. Maybe they work on a toy project of 500 lines of code, which is all every demo ever produces, but these text based systems have no actual understanding of the hardware underlying a complex program. That's just not how they work.
Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive.
In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. I work in backend, API development, which is completely different from fullstack development with backend development. If you ask PMs about backend requirements, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements.
> Software development jobs must be very diverse if even this anti-vibe-coding guy thinks AI coding definitely makes developers more productive.
As a Professor of English who teaches programming to humanities students, the writer has had an extremely interesting and unusual academic career [1]. He sounds awesome, but I think it's fair to suggest he may not have much experience of large scale commercial software development or be particularly well placed to predict what will or will not work in that environment. (Not that he necessarily claims to, but it's implicit in strong predictions about what the "future of programming" will be.)
[1] https://stephenramsay.net/about/
Hard to say but to back his claim that he was programming since the 90's his CV shows he was working on stuff that's clearly more than your basic undergraduate skill level since the early 2000's. I'd be willing to bet he has more years under his belt than most HN users. I mean I'm considered old here, in my mid 30's, and this guy has been programming most my life. Though that doesn't explicitly imply experience, or more specifically experience in what.
That said, I think people really under appreciate how diverse programmers actually are. I started in physics and came over when I went to grad school. While I wouldn't expect a physicist to do super well on leetcode problems I've seen those same people write incredible code that's optimized for HPC systems and they're really good at tracing bottlenecks (it's a skill that translates from physics really really well). Hell, the best programmer I've ever met got that way because he was doing his PhD in mechanical engineering. He's practically the leading expert in data streaming for HPC systems and gained this skill because he needed more performance for his other work.
There's a lot of different types of programmers out there but I think it's too easy to think the field is narrow.
>I'm considered old here, in my mid 30's
I'm 62, and I'm not old yet, you're just a kid. ;-)
Seriously, there are some folks here who started on punch cards and/or paper tape in the 1960s.
I played with punch cards and polystyrene test samples from the Standard Oil Refinery where my father worked in the early 70’s and my first language after basic was Fortran 77. Not old either.
I grew out of the leaking ether and basaltic dust that coated the plains. My first memories are of the Great Cooling, where the land, known only by its singular cyclopean volcano became devoid of all but the most primitive crystalline forms. I was there, a consciousness woven from residual thermal energy and the pure, unfractured light of the pre-dawn universe. I'm not old either.
30 years ago my coworkers called me Grandpa, so I get it both ways.
Thanks. I meant is more of in a joking way, poking fun at the community. I know I'm far too young to earn a gray beard, but I hope to in the next 20-30 years ;-) I still got a lot to learn till that happens
You wish, that gray beard sometimes appears in your late thirties.
Maybe. But also what I though was a gray beard in my early 20's is very different from what I think a gray beard is now. The number of those I've considered wizards decreased, and I think this should be true for most people. It's harder to differentiate experts as a novice, but as you get closer the resolution increases.
The more I know, the more I know I don’t know.
...and the more I know you don't know. [On the disappearance of wizards as you age]
Both definitely contribute. But at the same time the people who stay wizards (and the people you realize are wizards but didn't previously) only appear to be more magical than ever.
Some magic tricks are unimpressive when you know how they are done. But that's not true for all of them. Some of them only become more and more impressive, only truly being able to be appreciated by other masters. The best magic tricks don't just impress an audience, they impress an audience of magicians.
I think as I gain more experience, what previously looked like magic now always turns out to look a whole lot more like hard work, and frustration with the existing solutions.
Hit me pretty quickly after turning 40 (now 50)... in this last decade I've gone mostly bald and my facial hair is now mostly gray.
> I'm considered old here, in my mid 30's,
The 30s is the first decade of life that people experience where there are adults younger than them. This inevitably leads people in their 30s to start saying that they are "old" even though they generally have decades of vigor ahead of them.
> I'm considered old here, in my mid 30
That's absolutely not true. It was awkwardly funny to read that.
I've been the oldest guy on several teams in row now, starting in my early 30s. FAANG/startup culture skews very young
My first home computer was bought in 1986, before that the only electronics at home were Game & Watch handhelds, like Manhole.
I guess I am reaching Gandalf status then. :)
38 there. If you didn't suffer Win9x's 'stability', then editing X11 config files by hand, getting mad with ALSA/Dmix, writing new ad-hoc drivers for weird BTTV tuners reusing old known ones for $WEIRDBRAND, you didn't live.
the anxiety that i might fry my monitor by setting the wrong scan rate haunts me to this day
The squealing noise of a monitor in the wrong rate is a memorable noise etched in my brain.
> I mean I'm considered old here, in my mid 30's
sigh
I feel like a grandpa after reading that comment now.
This year my in-your-face-old-fart-moment was realising I was contributing to Wikimedia projects for longer than some fellow wikimedians existed. XD
I got a coat older than that (and in decent nick).
I used to tell the “kids” that I worked with that I have a bowling ball older than them.
I was greeted with blank stares by the kids on my team when they wanted to rewrite an existing program from scratch, and I said that will work for as well as it did with Netscape. Dang whippersnappers
I own 90's comic books and video games older than most Gen-Z users in HN.
But am I wrong? I am joking, but good jokes have an element of truth...
Depends what you mean by "old". If you mean elderly then obviously you're not. If you mean "past it" then it might reassure you to know the average expecting mother is in her 30s now (in the UK). Even if you just mean "grown up", recent research [1] on brain development identifies adolescence as typically extending into the early thirties, with (brain) adulthood running from there to the mid sixties before even then only entering the "early aging" stage.
For my part, I'm a lot older than you and don't consider myself old. Indeed, I think prematurely thinking of yourself as old can be a pretty bad mistake, health-wise.
[1] https://www.nature.com/articles/s41467-025-65974-8
FWIW I doubt I'd consider you old were I to know your actual age. I still think I'm quite young
"inside every old person there is a young one wondering what happened."
I assume you're on the younger end
No need to assume, I already told everyone my age
The assumption implies the median of the people's age who frequent HN is higher.
It'd be interesting the know the median age of HN commenters.
I guess the median age of YCombinator cohorts is <30 ?
Good news for you: average age on HN is 42
https://news.ycombinator.com/item?id=33480849
That was such a strange aspect. If you will excuse my use of the tortured analogy of comparing programming to wood working, there are is a lot of talk about hand tools versus power tools, but for people who aren't in a production capacity--not making cabinets for a living, not making furniture for a living--you see people choosing to exclusively use hand tools because they just enjoy it more. There isn't pressure about "you most use power tools or else you're in self-denial about their superiority." Well , at least for people who actually practice the hobby. You'll find plenty of armchair woodworkers in the comments section on YouTube. But I digress. For someone who claims to enjoy programming for the sake of programming, it was a very strange statement to make about coding.
I very much enjoy the act of programming, but I'm also a professional software developer. Incidentally, I've almost always worked in fields where subtly wrong answers could get someone hurt or killed. I just can't imagine either giving up my joy in the former case or abdicating my responsibility to understand my code in the latter.
And this is why the wood working analogy falls down. The scale at which damage can occur due to the decision to use power tools over hand tools is, for most practical purposes, limited to just myself. With computers, we can share our fuck ups with the whole world.
Nicely put. The wood working analogy does work.
Another key difference is that wood itself has built in visual transparency as to the goodness of the solution - as it is pretty easy to figure out that a cabinet is horrible (I do get that there are defects in wood joining techniques that can surface after some time due to moisture, etc - but still, lot of transparency out of the box). Software has no such transparency built in.
The advantage of hand coded solutions is that the author of the code has some sense of what the code really does and so is a proxy for transparency, vibe coded solutions not so much.
I mean, it is 2025 and still customers are the best detectors of bad software over all quality apparatus to date.
Now we have LLMs, the Medium Density Fiber Board of technology. Dice up all the text of the world into fine vectorized bits and reconstitute them into a flimsy construct that falls apart when it gets a little wet.
so what you are saying is that for production we should use AI, and hand code for hobby, got it. Lemme log back into the vpn and set the agents on the Enterprise monorepo /jk
>As a Professor of English who teaches programming to humanities students
That is the strangest thing I've heard today.
The world of the Digital Humanities is a lot of fun (and one I've been a part of, teaching programming to Historians and Philosophers of Science!) It uses computation to provide new types of evidence for historical or rhetorical arguments and data-driven critiques. There's an art to it as well, showing evidence for things like multiple interpretations of a text through the stochasticity of various text extraction models.
From the author's about page:
> I discovered digital humanities (“humanities computing,” as it was then called) while I was a graduate student at the University of Virginia in the mid-nineties. I found the whole thing very exciting, but felt that before I could get on to things like computational text analysis and other kinds of humanistic geekery, I needed to work through a set of thorny philosophical problems. Is there such a thing as “algorithmic” literary criticism? Is there a distinct, humanistic form of visualization that differs from its scientific counterpart? What does it mean to “read” a text with a machine? Computational analysis of the human record seems to imply a different conception of hermeneutics, but what is that new conception?
https://stephenramsay.net/about/
Can confirm, I'm tangentially adjacent to that community at times. I almost went to grad school for it even!
This is fascinating.
Exactly, I don't think ppl understand why programming languages even came about anymore. Lotsa ppl don't understand why a natural language is not suitable for programming and by extension prompting an LLM
I have done both strict back-end, strict front-end, full stack, QA automation and some devops as well, I worked in an all Linux shop where we were encouraged by great senior devs to always strive for better software all around. I think you're right, it mostly depends on your mindset and how much you expose yourself to the craft. I can tackle obscure front-end things sometimes better than back-end issues despite hating front-end but knowing enough to be dangerous. (My first job in tech really had me doing everything imaginable)
I find the LLMs boost my productivity because I've always had a sort of architectural mindset, I love looking up projects that solve specific problems and keeping them on the back of my mind, turns out I was building myself up for instructing LLMs on how to build me software, and it takes several months worth of effort and spits it out in a few hours.
Speaking of vibe coding in archaic languages, I'm using LLMs to understand old Shockwave Lingo to translate it to a more modern language, so I can rebuild a legacy game in a modern language. Maybe once I spin up my blog again I'll start documenting that fun journey.
> Speaking of vibe coding in archaic languages
Well, I think we can say C is archaic when most developers write in something that for one isn't C, two isn't a language itself written in C, or three isn't running on something written in C :)
(Python has exited the chat)
If we take the most popular programming languages and look at what their reference (or most popular) implementations are written in, then we get:
Far from archaic indeed. We're still living in the C/C++ world.Java and C# compilers are selfhosted.
Then depending on which JVM implementation we are talking about the actual JVM runtime can be Java, C, or C++, or a mix of them.
Modern C compilers are written in C++.
Rust uses LLVM, written in C++.
I thought Rust still used LLVM (a C++ project) for the backend, did they already switch to Cranelift?
I believe they're talking about runtimes, not compilers.
No, it is still LLVM.
Hehe. In the "someone should make a website"™ department: using a crap tons of legacy protocols and plugins semi-interoperable with modern while offering legacy browsers loaded with legacy plugins something usable to test with, i.e.,
- SSL 2.0-TLS 1.1, HTTP/0.9-HTTP/1.1, ftp, WAIS, gopher, finger, telnet, rwho, TinyFugue MUD, UUCP email, SHOUTcast streaming some public domain radio whatever
- <blink>, <marquee>, <object>, XHTML, SGML
- Java <applet>, Java Web Start
- MSJVM/J++, ActiveX, Silverlight
- Flash, Shockwave (of course), Adobe Air
- (Cosmo) VRML
- Joke ActiveX control or toolbar that turns a Win 9x/NT-XP box into a "real" ProgressBar95. ;)
(Gov't mandated PSA: Run vintage {good,bad}ness with care.)
To be fair, we have Flash emulators that run in modern browsers, and a Shockwave one as well, though it seems to be slowing down a bit in traction. Man, VRML brought me back. Don't forget VBScript!
why even write webpages or apps anymore just prompt an LLM everytime a user makes a request and write the page to send to the user :D
This... was a Show HN a little while back, can't tell if you're making a joke or referring to that.
oh god, it was a joke, but i want to see that. i hope they made it as a joke.
edit: I think i found it https://news.ycombinator.com/item?id=45783640
Ah lingo, where the programming metaphor was a theatre production!
> it takes several months worth of effort and spits it out in a few hours
lol
The thing is that some imagined AI that can reliably produce reliable software will also likely be able to be smart enough to come up with the requirements on its own. If vibe coding is that capable, then even vibe coding itself is redundant. In other words, vibe coding cannot possibly be "the future", because the moment vibe coding can do all that, vibe coding doesn't need to exist.
The converse is that if vibe coding is the future, that means we assume there are things the AI cannot do well (such as come up with requirements), at which point it's also likely it cannot actually vibe code that well.
The general problem is that once we start talking about imagined AI capabilities, both the capabilities and the constraints become arbitrary. If we imagine an AI that does X but not Y, we could just as easily imagine an AI that does both X and Y.
This is the most coherent comment in this thread. People who believe in vibe coding but not in generalizing it to “engineering”... brother the LLMs speak English. They can even hold conversations with your uncle.
My bet is that it will be good enough to devise the requirements.
They already can brainstorm new features and make roadmaps. If you give them more context about the business strategy/goals then they will make better guesses. If you give them more details about the user personas / feedback / etc they will prioritize better.
We're still just working our way up the ladder of systematizing that context, building better abstractions, workflows, etc.
If you were to start a new company with an AI assistant and feed it every piece of information (which it structures / summarizes synthesizes etc in a systematic way) even with finite context it's going to be damn good. I mean just imagine a system that can continuously read and structure all the data from regular news, market reports, competitor press releases, public user forums, sales call transcripts, etc etc. It's the dream of "big data".
If it gets to that point, why is the customer even talking to a software company? Just have the AI build whatever. And if an AI assistant can synthesize every piece of business information, why is there a need for a new company? The end user can just ask it to do whatever.
Maybe yes. It takes time for those structures to "compact" and for systems to realign.
I agree with the first part which is basically 'being able to do a software engineers full job' is basically ASI/AGI complete.
But I think it is certainly possible that we reach a point/plateau where everything is just 'english -> code' compilation but that 'vibe coding' compilation step is really really good.
It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs. In fact, why not the opposite? I think that currently LLMs are better at writing general prose, offering advice etc.., than they are at writing code. They are better at knowing what people generally want than they are at solving complex logic puzzle that require many deduction steps. Once we're reduced to imagining what AI can and cannot do, we can imagine pretty much any capability or restriction we like. We can imagine something is possible, and we can just as well choose to imagine it's not possible. We're now in the realm of, literally, science fiction.
> It's possible, but I don't see any reason to assume that it's more likely that machines will be able to code as well as working programmers yet not be able to come up with requirements or even ideas as well as working PMs.
Ideation at the working PM level, sure. I meant more hard technical ideation - ie. what gets us from 'not working humanoid robot' to 'humanoid robot' or 'what do we need to do to get a detection of a higgs boson', etc. etc. I think it is possible to imagine a world where 'english -> code' (for reasonably specific english) is solved but not that level of ideation. If that level of ideation is solved, then we have ASI.
There are a ton of extremely Hard problems to solve there that we are not likely going to solve.
One: English is terribly non-prescriptive. Explaining an algorithm is incredibly laborious in spoken language and can contain many ambiguous errors. Try reading Euclid’s Elements. Or really any pre-algebra text and reproduce its results.
Fortunately there’s a solution to that. Formal languages.
Now LLMs can somewhat bridge that gap due to how frequently we write about code. But it’s a non-deterministic process and hallucinations are by design. There’s no escaping the fact that an LLM is making up the code it generates. There’s nothing inside the machine that is understanding what any of the data it’s manipulating means or how it affects the system it’s generating code for.
And it’s not even a tool.
Worse, we can’t actually ship the code that gets generated without a human appendage to the machine to take the fall for it if there are any mistakes in it.
If you’re trying to vibe code an operating system and have no idea what good OS design is or what good code for such a system looks like… you’re going to be a bad appendage for the clanker. If it could ship code on its own the corporate powers that be absolutely would fire all the vibe coders and you’d never work again.
Vibe coding is turning people into indentured corporate servants. The last mile delivery driver of code. Every input surveilled and scrutinized. Output is your responsibility and something you have little control over. You learn nothing when the LLM gives you the answer because you’ll forget it tomorrow. There’s no joy in it either because there is no challenge and no difficulty.
I think what pron is leading to is that there’s no need to imagine what these machines could potentially do. I think we should be looking at what they actually do, who they’re doing it to, and who benefits from it.
The only reason to imagine that plateau is because it’s painful to imagine a near future where humans have zero economic value.
It's not the only reason, technologies do plateau. We're not living in orbiting cities flying fusion powered vehicles around, even though we built rockets and nuclear power more than half a century ago.
Yes, but perhaps technology can't plateau beyond vibe coding but below "the machine does everything", not because technology doesn't plateau but because that point doesn't exist. Technology could plateau before both or after both.
All the current indicators are that AI will plateau far beyond any human capability.
Do you have evidence or empirical arguments to the contrary?
Burden of proof is on you sir, not the other way around.
There is no proof for things that haven't happened yet.
I just find the belief that the continuous rapid improvements in machine intelligence stopping just short of human intelligence quite arbitrary.
The definition of what we see progress in with LLMs as anything akin to intelligence is your supposition, though.
It's a view I don't share at all. I don't see anything that could be even remotely considered intelligent under any reasonable definition of the term. Useful in places, yes. Intelligence, hard no. So the question of whether it will approch or surpass human intelligence makes no sense to me, because the technology and its progress are in an entirely different dimension and unrelated to that idea or goal.
Why is this desirable?
It’s not, it’s horrifying.
But there doesn’t seem to be any off ramp, given the incentives of our current economic system.
Following similar thinking, there's no world in which AI becomes exactly capable of replacing all software developers and then stops there, miraculously saving the jobs of everyone else next to and above them in the corporate hierarchy. There may be a human, C-suite driven cost-cutting effort to pause progress there for some brief time, but if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard. Either we're all similarly affected, or else AI still isn't good enough, in which case fleets of programmers are still needed, and among those, the presumed "helpfulness" of AI will vary wildly. Not unlike what we see already.
> if AI can do all dev work, there's no reason it can't do all office work to replace every human in front of a keyboard
There are plenty of reasons.
Radiologists aren’t being replaced by AI because of liability. Same for e.g. civil engineers. Coders don’t have liability for shipping shit code. That makes switching to an AI that’s equally blameless easier.
Also, data: the web is first and foremost a lot of code. AI is getting good at coding first for good reason.
Finally, as OP says, the hard work in engineering is actually scoping requirements and then executing and iterating on that. Some of that is technical know-how. A lot is also political and social skills. Again, customers are okay with a vibe-coded website in a way most people are not with even support chatbots.
> Coders don’t have liability for shipping shit code
Depends on the industry, and shipping shit code is the reason cybersecurity laws are starting to be a thing.
> Coders don’t have liability for shipping shit code
What if you're shipping code for a therac-25?
That's actually a terrific example, because the company already had a working, field-tested manually controlled version of their product, but they wanted a computer-controlled version to relieve radiologists of all of the drudgery and opportunities for error in the manual setup. So the design spec was to "faithfully replicate the manual setup procedures in a microcontroller," which was achieved. The problem was that the UI was utter dogshit, the training materials were poor (you can't have Marketing say "hey this computer handles all the details for you!" and then expect customers to pore page-by-page through the reference manual), and most clinics weren't really enforcing or QAing the operator training anyway. And since "the computer has a handle on it," the radiologists and senior techs who were supposed to be second-checking everything basically abdicated that responsibility, driven in part I'm sure by management that expected them to now have more "free hours" for other activities that Make Line Go Up. And nobody really raised a flag that this seemed troubling until multiple children died, and at the end of the day a lot of people could say "well, it wasn't my fault, I did what I was told to do" and sort of believe it.
If anyone doesn't think all of that is going to happen again on a massive scale as companies embrace GenAI, HAHAHAHAHAHAHA. AI will change a lot of things, but it won't fix human nature.
> Coders don’t have liability for shipping shit code.
Yet another reason why this needs to change, fast.
What do you mean "come up with the requirements"? Like if self-driving cars got so good that they didn't just drive you somewhere but decided where you should go?
No, I mean that instead of vibe coding - i.e. guiding the AI through features - you'll just tell it what you want in broad strokes, e.g. "create a tax filing system that's convenient enough for the average person to use", or, "I like the following games ... Build a game involving spaceships that I'll enjoy", and it will figure out the rest.
Yup. I would never be able to give my Jira tickets to an LLM because they're too damn vague or incomplete. Getting the requirements first needs 4 rounds of lobbying with all stakeholders.
We had a client who'd create incredibly detailed Jira tickets. Their lead developer (also their only developer) would write exactly how he'd want us to implement a given feature, and what the expected output would be.
The guy is also a complete tool. I'd point out that what he described wasn't actually what they needed, and that there functionality was ... strange and didn't actually do anything useful. We'd be told to just do as we where being told, seeing as they where the ones paying the bills. Sometimes we'd read between the lines, and just deliver what was actually needed, then we'd be told just do as we where told next time, and they'd then use the code we wrote anyway. At some point we got tired of the complaining and just did exactly as the tasks described, complete with tests that showed that everything worked as specified. Then we where told that our deliveries didn't work, because that wasn't what they'd asked for, but couldn't tell us where we misunderstood the Jira task. Plus the tests showed that the code functioned as specified.
Even if the Jira tasks are in a state where it seems like you could feed them directly to an LLM, there's no context (or incorrect context) and how is a chatbot to know that the author of the task is a moron?
Every time I've received overly detailed JIRA tickets like this it's always been significantly more of a headache than the vague ones from product people. You end up with someone with enough tech knowledge to have an opinion, but separated enough from the work that their opinions don't quite work.
Same, I think there's an idealistic belief in people who write those tickets that something can be perfectly specified upfront.
Maybe for the most mundane, repetitive tasks that's true.
But I'd argue that the code is the full specification, so if you're going to fully specify it you might as well just write the code and then you'll actually have to be confronted with your mistaken assumptions.
Maybe you'll appreciate having it pointed out to you: you should work on your usage of "where" vs "were".
I would actually :-)
> how is a chatbot to know that the author of the task is a moron?
Does it matter?
The chatbot could deliver exactly what was asked for (even if it wasn't what was needed) without any angst or interpersonal issues.
Don't get me wrong. I feel you. I've been there, done that.
OTOH, maybe we should leave the morons to their shiny new toys and let them get on with specifying enough rope to hang themselves from the tallest available structure.
Are you working at OpenAI?
No, but now I'm curious about the inner workings of OpenAI.
Your comment sounded how an instance of copilot would complain to its coleagues and for a moment I pictured OpenAI being just a large scam based on an army of mechanical turks :)
"The guy is also a complete tool." - Who says Hackers news is not filled with humor?
A significant part of my LLM workflow involves having the LLM write and update tickets for me.
It can make a vague ticket precise and that can be an easy platform to have discussions with stakeholders.
I like this use of LLM because I assume both the developer and ticket owner will review the text and agree to its contents. The LLM could help ensure the ticket is thorough and its meaning is understood by all parties. One downside is verbosity, but the humans in the loop can edit mercilessly. Without human review, these tickets would have all the downsides of vibe coding.
Thank you for sharing this workflow. I have low tolerance for LLM written text, but this seems like a really good use case.
Wait until you learn that the people on the other side of your ticket updates are also using LLMs to respond. It's LLMs talking to LLMs now.
Wait until you learn that most people's writing skills are that of below LLMs, so it's an actual tangible improvement (as long as you review the output for details not being missed, of course)
Hoisted by your own petard ("me old fruit"):
"Wait until you learn that most people's writing skills are that of below LLMs"
... went askew at "that of below LLMs".
I'm an arse: soz!
No need to apologize for a correction. That's not the culture I want to live in.
As long as you are also paying attention to the content and not just form.
The desired result is coming to a documented agreement on an interaction, not some exercise in argument that has to happen between humans.
I find having an LLM create tickets for itself to implement to be an effective tool that I rarely have to provide feedback for at all.
This seems like greybeards complaining that people who don't write assembly by hand.
Who has ever complained that kids don't write assembly by hand?
Stop being outraged for things that are only real on your mind.
Speaking of things that are only real in your mind...
Am I outraged?
And yes, there absolutely was a vocal group of a certain type of programmer complaining about high level languages like C and their risks and inefficiency and lack of control insisting that real programmers wrote code in assembly. It's hard to find references because google sucks these days and I'm not really willing to put in the effort.
You made it up, that is why you can't find it.
How's [0] or [1] for historical sources?
It's not surprising that Google doesn't turn these up, the golden era of this complaining was pre-WWW.
[0]: https://www.ee.torontomu.ca/~elf/hack/realmen.html [1]: https://melsloop.com/
Have you not noticed that the story you reference is so well know because... literally every single developer thinks people like Mel are crazy?
Mel or Terry Adams are the exception to the rule... Having that image of greybeards only come if you have never worked with one in real life, sorry you are biased.
What? Mel is regarded as deserving massive respect, not as crazy. If a developer thinks Mel is nuts, they are coming from a perspective I don't understand.
And yes, the shift to higher level languages like C, FORTRAN, etc., was regarded by some as pandering to the new generation that didn't want to actually learn programming.
With some truth, in my opinion. I think higher level languages bring huge benefits, so I'm not bemoaning their existence. But it still weirds me out when there's a professional developer that doesn't have at least a cursory knowledge of assembly. AI programming assistance (which I'm sure will be very different than today's 'vibe coding') does seem like a similar state change. I certainly don't object to it in principle, it will probably be a large productivity improvement.
But I'm sure that with it, there will be the loss of fundamental knowledge for some people. Like digital artists who never learn the properties of real paint.
https://xkcd.com/378/
A significant part of my workflow is getting a ticket that is ill-defined or confused and rewriting it so that it is something I can do or not do.
From time to time I have talked over a ticket with an LLM and gotten back what I think is a useful analysis of the problem and put it into the text or comments and I find my peeps tend to think these are TLDR.
Yeah, most people won't read things. At the beginning of my career I wrote emails that nobody read and then they'd be upset about not knowing this or that which I had already explained. Such is life, I stopped writing emails.
An LLM will be just as verbose as you ask it to be. The default response can be very chatty, but you can figure out how to ask it to give results in various lengths.
Who says an LLM can’t be taught or given a system prompt that enables them to do this?
Agentic AI can now do 20 rounds of lobbying with all stake holders as long as it’s over something like slack.
Claude Code et al. asks clarifying questions in plan mode before implementing. This will eventually extend to jira comments
You think the business line stakeholder is going to patiently hang out in JIRA, engaging with an overly cheerful robot that keeps "missing the point" and being "intentionally obtuse" with its "irrelevant questions"?
This is how most non-technical stakeholders feel when you probe for consistent, thorough requirements and a key professional skill for many more senior developers and consultants is in mastering the soft skills that keep them attentive and sufficiently helpful. Those skills are not generic sycophancy, but involve personal attunement to the stakeholder, patience (exercising and engendering), and cycling the right balance between persistence and de-escalation.
Or do you just mean there will be some PM who acts as proxy between for the stakeholder on the ticket, but still needs to get them onto the phone and into meetings so the answers can be secured?
Because in the real world, the prior is outlandish and the latter doesn't gain much.
Businesses do whatever’s cheap. AI labs will continue making their models smarter, more persuasive. Maybe the SWE profession will thrive/transform/get massacred. We don’t know.
What do you mean by eventually?
this already exists.
I write a library which is used by customers to implement integrations with our platform. The #1 thing I think about is not
> How do I express this code in Typescript?
it's
> What is the best way to express this idea in a way that won't confuse or anger our users? Where in the library should I put this new idea? Upstream of X? Downstream of Y? How do I make it flexible so they can choose how to integrate this? Or maybe I don't want to make it flexible - maybe I want to force them to use this new format?
> Plus making sure that whatever changes I make are non-breaking, which means that if I update some function with new parameters, they need to be made optional, so now I need to remember, downstream, that this particular argument may or may not be `undefined` because I don't want to break implementations from customers who just upgraded the most recent minor or patch version
The majority of the problems I solve are philosophical, not linguistic
> very few people can correctly articulate requirements
The observation from Lean is that the faster you can build a prototype, the faster you can validate the real/unspoken/unclear requirements.
This applies for backends too. A lot of the “enterprise-y” patterns like BFFs, hexagonal, and so on, will make it really easy to compose new APIs from your building blocks. We don’t do this now because it’s too expensive to write all the boilerplate involved. But one BFF microservice per customer would be totally feasible for a sales engineer to vibe code, in the right architecture.
To be honest I've never worked in an environment that seemed too complex. On my side my primary blocker is writing code. I have an unending list of features, protocols, experiments, etc. to implement, and so far the main limit was the time necessary to actually write the damn code.
That sounds like papier mache more than bridge building, forever pasting more code on as ideas and time permit without the foresight to engineer or architect towards some cohesive long-term vision.
Most software products built that way seem to move fast at first but become monstrous abominations over time. If those are the only places you keep finding yourself in, be careful!
There are a wide number of small problems for which we do not need bridges.
As a stupid example, I hate the functionality that YouTube has to maintain playlists. However, I don't have the time to build something by hand. It turns out that the general case is hard, but the "for me" case is vibe codable. (Yes, I could code it myself. No, I'm not going to spend the time to do so.)
Or, using the Jira API to extract the statistics I need instead of spending a Thursday night away from the family or pushing out other work.
Or, any number of tools that are within my capabilities but not within my time budget. And there's more potential software that fits this bill than software that needs to be bridge-stable.
Absolutely.
But the person I replied to seemed to be talking about a task agenda for their professional work, not a todo list of bespoke little weekend hobby hacks that might be handy "around the house".
You assume they were talking about a single product. at my job there is essentially endless amounts of small tasks. We have many products and clients we have many internal needs, but can't really justify the human capital. Like I might write 20 to 50 Python scripts in a week just to visualize the output of my code. Dead boring stuff like making yet another matplotlib plot, simple stats, etc. Sometimes some simple animations. there is no monstrosity being built, this is not evidence of tagging on features or whatever you think must be happening, it's just a lot of work that doesn't justify paying a bay area principal engineer salary to do in the face of a board that thinks the path to riches is laying off the people actually making things and turning the screws on the remaining people struggling to keep up with the workflow.
Work is finite, but there can be vastly more available than there are employees to do it for many reasons, not just my personal case.
Fun fact, papier mache was used to create bathtubs and can make furniture that holds an amazing amount of weight.
Learn to Build With Cardboard! STRONG, Waterproof and Free. https://www.youtube.com/watch?v=45JhacvmXV8
Building a Flyable Airplane out of CardBoard! https://www.youtube.com/watch?v=T46SHLzlV1A
https://en.wikipedia.org/wiki/Papier-mâché
The vision is "being compatible with protocols used in my field". There's hundreds over hundreds of those. Example: this app supports more than 700 protocols, hardware, etc. (https://bitfocus.io/connections) and still it's missing an AWFUL LOT and only handles fairly basic cases in general. There's just no way around writing the code for each custom bespoke protocol for whatever $APPLIANCE people are going to bring and expect to work. Even if each protocol fits neatly in a single self-contained class or two.
I don’t want to imply this is your case, because of course I’ve no idea how you work. But I’ve seen way too often, the reason for so many separate features is:
A) as stated by parent comment, the ones doing req. mngmt. Are doing a poor job of abstracting the requirements, and what could be done as one feature suddenly turns in 25.
B) in a similar manner as A, all solutions imply writing more and more code, and never refactor and abstract parts away.
My guess would be that the long list is maybe not self contained features (although still can be, I know I have more feature ideas than I can deliver in the next couple years myself), but behaviors or requirements of one or a handful of product feature areas.
When you start getting down into the weeds, there can be tons and tons of little details around state maintenance, accessibility, edge cases, failure modes, alternate operation modes etc.
That all combines to make lots of code that is highly interconnected, so you need to write even more code to test it. Sometimes much more than even the target implementations code.
Hehe. Try working for some telecoms dealing with gsm, umts, LTR and 5g.
or banking. or finance. or manufacturing. or $other_enterprise_lob_area.
souce: been there, done some of that.
Man I wish this was my job. I savor the days when I actually don’t have to do requirements gathering and can just code.
> the bigger bottleneck to productivity is that very few people can correctly articulate requirements.
One could argue that "vibe coding" forces you (eventually) to think in terms of requirements. There's a range of approaches, from "nitpick over every line written by AI" to "yolo this entire thing", but one thing they have in common is they all accelerate failure if the specs are not there. You very quickly find out you don't know where you're going.
I see this in my work as well, the biggest bottleneck is squeezing coherent, well-defined requirements out of PMs. It's easy to get a vision board, endless stacks of slides about priorities and direction, even great big nests of AWS / Azure thingnames masquerading as architecture diagrams. But actual "this is the functionality we want to implement and here are the key characteristics of it" detail? Absolutely scarce.
Unfortunately a lot of it is also because of illiteracy.
Lots of people hide the fact that they struggle with reading and a lot of people hide or try to hide the fact they don’t understand something.
I really wonder if we're going to see a reversion to old school project management, with a PMBOK's worth of detailed project documents for every major initiative instead of the modern Agile/Scrum/Kanban approach that seems to work better for human devs. If you can get everyone to agree on the minutia of, for example, the Stakeholder Management Plan, up front then the LLM actually has a chance of developing a decent program that has the features everyone wants.
Then again, if humans could agree on all the project minutia at the outset, we never would have developed the other systems.
I don’t mind the coding, it’s the requirements gathering and status meetings I want AI to automate away. Those are the parts I don’t like and where we’d see the biggest productivity gains. They are also the hardest to solve for, because so much of it is subjective. It also often involves decisions from leadership which can come with a lot of personal bias and occasionally some ego.
This is like the reverse centaur form of coding. The machine tells you what to make, and the human types the code to do the thing.
Well, when put like that it sounds pretty bad too.
I was thinking more that the human would tell the machine want to make. The machine would help flesh out the idea into actual requirements, and make any decisions the humans are too afraid or indecisive to make. Then the coding can start.
Is there anyone doing dev work that operates in an environment where people can clearly articulate what they want? I've never worked in a place like that in 20 years doing software.
This means your difficulty is not programming per se, but that you are working on a very suboptimal industry / company / system. With all due respect, you use programming at work, but true programming is the act of creating a system that you or your team designed and want to make alive. Confusing the reality of writing code for a living in some company with what Programming with capitalized P is, produces a lot of misunderstanding.
I don't think the author would disagree with you. Ad you point out coding is just one part of software development. I understand his point to be that the coding portion of the job is going to be very different going forward. A skilled developer is still going to need to understand frameworks and tradeoffs so that they can turn requirements into a potential solution. It just they might not be coding up the implementation.
The only class I've ever failed was a c++ class where the instructor was so terrible at explaining the tasks that I literally could not figure out what he wanted.
I had to retake it with the same instructor but by some luck I was able to take it online, where I would spend the majority of the time trying to decipher what he was asking me to do.
Ultimately I found that the actual ask was being given as a 3 second aside in a 50 minute lecture. Once I figured out his quirk I was able to isolate the ask and code it up, ended with an A+ in the class on the second take.
I would like to say that I learned a lot about programming from that teacher, but what I actually learned is what you're saying.
Smart, educated, capable people are broken when it comes to clearly communicating their needs to other people just slightly outside of their domain. If you can learn the skill of figuring out what the hell they're asking for and delivering that, that one skill will be more valuable to you in your career than competency itself.
In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements. [...] software development is a lot more than coding and requires critical thinking to discover the requirements.
Very well said. More often than not, the job isn't to translate the product requirements into compiling/correctly executing computer code, but rather to reveal the hidden contradictions in a seemingly straightforward natural-language feature specification.
Once these are ironed out, the translation into code quite often does become a somewhat mechanical exercise, at least in my line of work.
We're basically the lawyers the person finding the magic lamp should have consulted with before opening their mouth while facing the genie ;)
AI coding allows me to simulate that system, cross reference it with what the document says wrt what the customer wants and figure out holes in the spec. Having to code something to find the hole in the definition, the spec, the problem, the anything was a necessary step in building a sound working system.
That is no longer the case.
Yeah, the hardest part is understanding the requirements. But it then still takes hours and hours and hours to actually build the damn thing.
Except that now it still takes me the same time to understand the requirements ... and then the coding takes 1/2 or 1/3 of the time. The coding also always takes 1/3 of the effort so I leave my job less burned out.
Context: web app development agency.
I really don't understand this "if it does not replace me 100% it's not making me more productive" mentality. Yeah, it's not a perfect replacement for a senior developer ... but it is like putting the senior developer on a bike and pretending that it's not making them go any faster because they are still using their legs.
I constantly run into issues where features are planned and broken down outside-in, and it always makes perfect sense if you consider it in terms of the pure user interface and behaviour. It completely breaks down when you consider the API, or the backend, is a cross-cutting concern across many of those tidy looking tasks and cannot map to them 1:1 without creating an absolute mess.
Trying to insert myself, or the right backend people, into the process, is more challenging now than it used to be, and a bad API can make or break the user experience as the UI gets tangled in the web of spaghetti.
It hobbles the effectiveness of whatever you could get an LLM to do because you’re already starting on the backfoot, requirements-wise.
I like my requirements articulated so clearly and unambiguously that an extremely dumb electronic logic machine can follow every aspect of the requirements and implement them "perfectly" (limited only by the physical reliability of the machine).
Aka "coding". I see what you mean ;)
This is one reason I think spec driven development is never really going to work the way people claim it should. It's MUCH harder to write a truly correct, comprehensive, and useful spec than the code in many cases.
> very few people can correctly articulate requirements
This is the new programming. Programming and requirements are both a form of semantics. One conveys meaning to a computer at a lower level, the other conveys it to a human at a higher level. Well now we need to convey it at a higher level to an LLM so it can take care of the lower-level translation.
I wonder if the LLM will eventually skip the programming part and just start moving bits around in response to requirements?
My solution as a consultant was to build some artifact that we could use as a starting point. Otherwise, you're sitting around spinning your wheels and billing big $ and the pressure is mounting. Building something at least allows you to demonstrate you are working on their behalf with the promise that it will be refined or completely changed as needed. It's very hard when you don't get people who can send down requirements, but that was like 100% of the places I worked. I very seldom ran into people who could articulate what they needed until I stepped up, showed them something they could sort of stand on, and then go from there.
Mythical Man Month had it all--build one to throw away.
> I very seldom ran into people who could articulate what they needed
The people with the needs and ideas are often so divorced from the "how" that they don't even bother trying to nail down the details. I think in their mind they are delegating that to the specialists.
This question of who writes the requirements is so ubiquitous you would think we'd have better solutions for it. I know some people solve it with processes like BDD but personally I think we'd be better off if we just had clearer role definitions.
For example, in a waterfall project the requirements usually land in the lap of the Business Analyst. Well when you look at Business Analyst roles you see they are expected to do a lot more than documenting requirements, so it's viewed as acceptable when they are somewhat bad at it. They also spend most of their time with the business so they are unaware of the limitations of the team who is expected to implement the changes.
For another example look at Scrum. It talks a lot about good requirements in the form of user stories, but it stops short of assigning this responsibility to any one of the formal roles, presumably making it a team activity or expecting it to be organic.
When we want someone to write code we hire a programmer, and writing code is what they are expected to do. Where is the role that is strictly requirements and nothing else? Considering how often I hear complaints about bad requirements, it seems overdue that we establish one.
We have a machine that turns requirements into code. It's called a compiler. What happened to programming after the invention of the compiler?
>In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements.
Agreed.
In addition, on the other side of the pipeline, code reviews are another bottleneck. We could have more MRs in review thanks to AI, but we can't really move at the speed of LLM's outputs unless we blindly trust it (or trust another AI to do the reviews, at which point what are we doing here at all...)
The solo projects I do are 10x, the team projects I do maybe 2-3x in productivity. I think in big companies it's much much less.
Highest gains are def in full stack frameworks (like nextjs), with Database ORM, and building large features in one go, not having to go back & forth with stakeholders or collegues.
This feels like addressing a point TFA did not make. TFA talks mostly about vibe-coding speeding up coding, whereas your comment is about software development as a whole. As you point out, coding is just one aspect of engineering and we must be clear about what "productivity" we are talking about.
Sure, there are the overhypers who talk about software engineers getting entirely replaced, but I get the sense those are not people who've ever done software development in their lives. And I have not seen any credible person claiming that engineering as whole can be done by AI.
On the other hand, the most grounded comments about AI-assisted programming everywhere are about the code, and maybe some architecture and design aspects. I personally, along with many other commenters here and actual large-scale studies, have found that AI does significantly boost coding productivity.
So yes, actual software engineering is much more than coding. But note that even if coding is, say, only 25% of engineering (there are actually studies about this), putting a significant dent in that is still a huge boost to overall productivity.
Convince your PMs to use an LLM to help "breadboard" their requirements. It's a really good use case. They can ask their dumb questions they are afraid to and an LLM will do a decent job of parsing their ideas, asking questions, and putting together a halfway decent set of requirements.
How does the LLM get all the required knowledge about the domain and the product to ask relevant questions?
Give it access to the codebase and a text file with all relevant business knowledge.
Man ... if there were a text file with "all relevant business knowledge" in any job I've ever worked, it would have been revolutionary.
I'd say 25% of my work-hours are just going around to stakeholders and getting them to say what some of their unstated assumptions and requirements are.
PMs wouldn't be able to ask the right questions. They have zero experience with developer experience (DevEx) and they only have experience with user experience (UX).
You can hope that an LLM might have some instructions related to DevEx in its prompt at least. There's no way to completely fix stupid, anymore than you can convince a naive vibecoder that just vibing a new Linux-compatible kernel written entirely in Zig is a feasible project.
Also that requirements engineering in general isn't being done correctly.
I'm the last guy to be enthused about any "ritualistic" seeming businessy processes. Just let me code...
However, some things do need actually well defined adhered to processes where all parties are aware of and agreeing with the protocol.
Sounds like you work with inexperienced PMs that are not doing their job, did you try having a serious conversation about this pattern with them? I'm pretty sure some communication would go a long way towards getting you on a better collaboration groove.
I've been doing API development for over ten years and worked at different companies. Most PMs are not technical and it's the development team's job figure out the technical specifications for APIs we build. If you press the PMs, they will ask the engineering/development manager for the written technical requirements, and if the manager is not technical, they will assign it to the developers/engineers. Technical requirements for an API are really a system design question.
The technical design is definitely the job of the technical team for the most part, but the business requirements should be squarely on the pm. The list of use cases, how the API feels, the performance etc... All of that the business owner should be able to describe to you to ensure it does the job it needs and is fit for the market.
"the bigger bottleneck to productivity is that very few people can correctly articulate requirements."
I've found the same way. I just published an AI AUP for my company and most of it is teaching folks HOW to use AI.
and in reality, all the separate roles should be deprecated
we vibe requirements to our ticket tracker with an api key, vibe code ticket effort, and manage the state of the tickets via our commits and pull requests and deployments
just teach the guy the product manager is shielding you from not to micromanage and all the frictions are gone
in this same year I've worked at an organization that didn't allow AI use at all, and by Q2, Co-Pilot was somehow solving their data security concerns (gigglesnort)
in a different organization none of those restrictions are there and the productivity boost is through an order of magnitude greater
> In my work, the bigger bottleneck to productivity is that very few people can correctly articulate requirements.
Totally agree. I’ve tried to explain this in many places: AI coding (and creative tools in general) will ultimately remain tools. Only people who can clearly and thoughtfully articulate requirements will be able to fully leverage them.
Another hot take: the “one-person company.” Headcount isn’t the key variable. With AI, the real constraint is how well you can understand a problem and clearly define a solution.
- If a problem can be clearly defined and fully understood by one person, then one person is enough to solve it.
- If a problem is more complex and requires two fundamentally different areas of expertise, then it will likely take two capable people to solve it—no more, no less.
You can vibe ask the requirements. Not even kidding.
This is like saying the typewriter won’t make a newspaper company more productive because the biggest bottlenecks are the research and review processes rather than the typing. It’s absolutely true, but it was still worth it to go up to typewriters, and the fact that people were spending less effort and time on the handwriting part helps all aspects of energy levels etc across their job.
Sounds like the bottleneck is good PMs then.
Which is what vibe coders are.....
AI is making coding so cheap, you can now program a few versions of the API and choose what works better.
If AI doesn't make you more productive you're using it wrong, end of story.
Even if you don't let it author or write a single line of code, from collecting information, inspecting code, reviewing requirements, reviewing PRs, finding bugs, hell even researching information online, there's so many things it does well and fast that if you're not leveraging it, you're either in denial or have ai skill issues period.
Not to refute your point but I’ve met overly confident people with “AI skills” who are “extremely productive” with it, while producing garbage without knowing, or not being able to tell the difference.
You're describing lack of care and lack of professionalism, fire these people, nothing to do with the tools, it's the person using it the problem.
We're trying very earnestly to create a world where being careful and professional is a liability. "Move fast and break things, don't ask permission, don't apologize for anything" is the dominant business model. Having care and practicing professionalism takes times and patience, which just translate to missed opportunities to make money.
Meanwhile, if you grift hard enough, you can become CEO of a trillion dollar company or President of the United States. Young people are being raised today seeing that you can raise billions on the promise building self driving cars in 3 years, not deliver even after 10 years, and nothing bad actually happens. Your business doesn't crater, you don't get sued into oblivion, your reputation doesn't really change. In fact, the bigger the grift, the more people are incentivized to prop it up. Care and professionalism are dead until we go back to an environment that is not so nurturing for grifts.
While I circumstantially agree, I hold it to be self-evident that the "optimal amount of grift is nonzero". I leave it to politicians to decide whether increased oversight, decentralization, or "solution X" is the right call to make.
A little grift is expected. The real problem for us is when it's grift all the way down, and all the way up, to the extent even the President is grifting. Leaving it to the politicians in that case just means enabling maximum, economy-scale grift.
Yea I’m talking about people and that’s honestly what matters here. At the end of the day this tools is used by people and how people use it plays a big role in how we assess its usefulness.
this is known as the no true scotsman fallacy
I've not really seen this outside of extremely junior engineers. On the flip side I've seen plenty of seniors who can't manage to understand how to interact with AI tools come away thinking they are useless when just watching them for a bit it's really clear the issue is the engineer.
They just shovel the garbage on someone else who has to fact check and clean it up.
you can say that about overly confident people with "xyz" skills.
Garbage to whom? Are we talking about something that the user shudders to think about, or something more like a product the user loves, but behind the scenes the worst code ever created?
A lot of important details/parts of a system (not only code) that may seem insignificant to the end user could be really important in making a a system work correctly as a whole.
It sounds like you're the one in denial? AI makes some things faster, like working in a language I don't know very well. It makes other things slower, like working in a language I already know very well. In both cases, writing code is a small percentage of the total development effort.
No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does.
Even if you limit your AI experience to finding information online through deep research it's such a time saver and productivity booster that makes a lot of difference.
The list of things it can do for you is massive, even if you don't have it write a single line of code.
Yet the counter argument is like "bu..but..my colleague is pushing slop and it's not good at writing code for me", come on, then use it at things it's good at, not things you don't find it satisfactory.
It "obviously" does based on what, exactly? For most devs (and it appears you, based on your comments) the answer is "their own subjective impressions", but that METR study (https://arxiv.org/pdf/2507.09089) should have completely killed any illusions that that is a reliable metric (note: this argument works regardless of how much LLMs have improved since the study period, because it's about how accurate dev's impressions are, not how good the LLMs actually were).
It's a good study. I also believe it is not an easy skill to learn. I would not say I have 10x output but easily 20%
When I was early in use of it I would say I sped up 4x but now after using it heavily for a long time some days it's 20% other days -20%
It's a very difficuly technology to know when you're one or the other.
The real thing to note is when you "feel" lazy and using AI you are almost certainly in the -20% category. I've had days of not thinking and I have to revert all the code from that day because AI jacked it up so much.
To get that speed up you need to be truly focused 100% or risk death by a thousand cuts.
Yes, self-reported productivity is unreliable, but there have been other, larger, more rigorous, empirical studies on real-world tasks which we should be talking about instead. The majority of them consistently show a productivity boost. A thread that mentions and briefly discusses some of those:
https://news.ycombinator.com/item?id=45379452
Some (partial) counter points:
- I think given public available metrics, it's clear that this isn't translating into more products/apps getting shipped. That could be because devs are now running into other bottlenecks, but it could also indicate that there's something wrong with these studies.
- Most devs who say AI speeds them up assert numbers much higher than what those studies have shown. Much of the hype around these tools is built on those higher estimates.
- I won't claim to have read every study, but of the ones I have checked in the past, the more the methodology impressed me the less effect it showed.
- Prior to LLMs, it was near universally accepted wisdom that you couldn't really measure developer productivity directly.
- Review is imperfect, and LLMs produce worse code on average than human developers. That should result in somewhat lowered code quality with LLM usage (although that might be an acceptable trade off for some). The fact that some of these studies didn't find that is another thing that suggests there shortcomings in said studies.
> - Most devs who say AI speeds them up assert numbers much higher than what those studies have shown.
I am not sure how much is just programmers saying "10x" because that is the meme, but if at all realistic numbers are mentioned, I see people claiming 20 - 50%, which lines up with the studies above. E.g. https://news.ycombinator.com/item?id=45800710 and https://news.ycombinator.com/item?id=46197037
> - Prior to LLMs, it was near universally accepted wisdom that you couldn't really measure developer productivity directly.
Absolutely, and all the largest studies I've looked at mention this clearly and explain how they try to address it.
> Review is imperfect, and LLMs produce worse code on average than human developers.
Wait, I'm not sure that can be asserted at all. Anecdotally not my experience, and the largest study in the link above explicitly discuss it and find that proxies for quality (like approval rates) indicate more improvement than a decline. The Stanford video accounts for code churn (possibly due to fixing AI-created mistakes) and still finds a clear productivity boost.
My current hypothesis, based on the DORA and DX 2025 reports, is that quality is largely a function of your quality control processes (tests, CI/CD etc.)
That said, I would be very interested in studies you found interesting. I'm always looking for more empirical evidence!
> I see people claiming 20 - 50%, which lines up with the studies above
Most of those studies either measure productivity using useless metrics like lines of code, number of PRs, or whose participants are working for organizations that are heavily invested in future success of AI.
One of my older comments addressing a similar list of studies: https://news.ycombinator.com/item?id=45324157
As mentioned in the thread I linked, they acknowlege the productivity puzzle and try to control for it in their studies. It's worth reading them in detail, I feel like many of them did a decent job controlling for many factors.
For instance, when measure the number of PRs they ensure that each one goes through the same review process whether AI-assisted or not, ensuring these PRs meet the same quality standards as humans.
Furthermore, they did this as a randomly controlled trial comparing engineers without AI to those with AI (in most cases, the same ones over time!) which does control for a lot of the issues with using PRs in isolation as a holistic view of productivity.
>... whose participants are working for organizations that are heavily invested in future success of AI.
That seems pretty ad hom, unless you want to claim they are faking the data. Along with co-authors who are from premier institutes like NBER, MIT, UPenn, Princeton, etc.
And here's the kicker: they all converge on a similar range of productivity boost, such as the Stanford study:
> https://www.youtube.com/watch?v=tbDDYKRFjhk (from Stanford, not an RCT, but the largest scale with actual commits from 100K developers across 600+ companies, and tries to account for reworking AI output. Same guys behind the "ghost engineers" story.
The preponderence of evidence paints a very clear picture. The alternative hypothesis is that ALL these institutes and companies are colluding. Occam's razor and all that.
> if at all realistic numbers are mentioned, I see people claiming 20 - 50%
IME most people claim small integer multiples, 2-5x.
> all the largest studies I've looked at mention this clearly and explain how they try to address it.
Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so.
> My current hypothesis, based on the DORA and DX 2025 reports, is that quality is largely a function of your quality control processes (tests, CI/CD etc.)
This is pretty obviously incorrect, IMO. To see why, let's pretend it's 2021 and LLMs haven't come out yet. Someone is suggesting no longer using experienced (and expensive) first world developers to write code. Instead, they suggest hiring several barely trained boot camp devs (from low cost of living parts of the world so they're dirt cheap) for every current dev and having the latter just do review. They claim that this won't impact quality because of the aforementioned review and their QA process. Do you think that's a realistic assessment? If and on the off chance you think it is, why didn't this happen on a larger scale pre-LLM?
The resolution here is that while quality control is clearly important, it's imperfect, ergo the quality of the code before passing through that process still matters. Pass worse code in, and you'll get worse code out. As such, any team using the method described above might produce more code, but it would be worse code.
> the largest study in the link above explicitly discuss it and find that proxies for quality (like approval rates) indicate more improvement than a decline
Right, but my point is that that's a sanity check failure. The fact that shoving worse at your quality control system will lower the quality of the code coming out the other side is IMO very well established, as is the fact that LLM generated code is still worse than human generated (where the human knows how to write the code in question, which they should if they're going to be responsible for it). It follows that more LLM code generation will result in worse code, and if a study finds the opposite it's very likely that the it made some mistake.
As an analogy, when a physics experiment appeared to find that neutrino travel faster than the speed of light in a vacuum, the correct conclusion was that there had almost certainly been a problem with the experiment, not that neutrinos actually travel faster than the speed of light. That was indeed the explanation. (Note that I'm not claiming that "quality control processes cannot completely eliminate the effect of input code quality" and "LLM generated code is worse than human generated code" are as well established as relativity.)
> Yes, but I think pre-AI virtually everyone reading this would have been very skeptical about their ability to do so.
That's not quite true: while everybody acknowledged it was folly to measure absolute individual productivity, there were aggregate metrics many in the industry were aligning on like DORA or the SPACE framework, not to mention studies like https://dl.acm.org/doi/abs/10.1145/3540250.3558940
Similarly, many of these AI coding studies do not look at productivity on an individual level at a point of time, but in aggregate and over an extended period of time using a randomized controlled trial. It's not saying Alice is more productive than Bob, it's saying Alice and Bob with AI are on average more productive than themselves without AI.
> They claim that this won't impact quality because of the aforementioned review and their QA process. Do you think that's a realistic assessment? If and on the off chance you think it is, why didn't this happen on a larger scale pre-LLM?
Interestingly, I think something similar did happen pre-LLM at industry-scale! My hypothesis (based on observations when personally involved) is that this is exactly what allowed offshoring to boom. The earliest attempts at offshoring were marked by high-profile disasters that led many to scoff at the whole idea. However companies quickly learned and instituted better processes that basically made failures an exception rather than the norm.
I expand a bit more and draw parallels to coding with AI here: https://news.ycombinator.com/item?id=44944717
> ... as is the fact that LLM generated code is still worse than human generated...
I still don't think that can be assumed as a fact. The few studies I've seen find comparable outcomes, with LLMs actually having a slight edge in some cases, e.g.
- https://arxiv.org/abs/2501.16857
- https://arxiv.org/html/2508.00700v1
> My hypothesis (based on observations when personally involved) is that this is exactly what allowed offshoring to boom.
Offshoring did happen, but if you were correct that only the quality control process impacted final quality, the software industry would have looked something like e.g. garment industry, with basically zero people being paid to actually write software in the first world, and hires from the developing world not requiring much skill. What we actually see is that some offshoring occurred, but it was limited and when it did occur companies tried to hire highly trained professionals in the country they outsourced to, not the cheapest bootcamp dev they could find. That's because the quality of the code at generation does matter, so it becomes a tradeoff between cost and quality.
> I still don't think that can be assumed as a fact. The few studies I've seen find comparable outcomes, with LLMs actually having a slight edge in some cases, e.g.
Anthropic doesn't actually believe in their LLMs as strongly as you do. You know how I can tell? Because they just spent millions acquihiring the Bun team instead of asking Claude to write them a JS runtime (not to mention the many software engineering roles they're advertising on their website). They know that their SOTA LLMs still generate worse code than humans, that they can't completely make up for it in the quality control phase, and that they at the very least can't be confident of that changing in the immediate future.
Offshoring wasn't really limited... looking at India as the largest offshoring destination, it is in the double-digit billions annually, about 5 - 10% of the entire Indian GDP, and it was large enough that it raised generations of Indians from lower middle-class to the middle and upper-middle class.
A large part of the success was, to your point, achieved by recruiting highly skilled workers at the client and offshoring ends, but they were a small minority. The vast majority of the workforce was much lower skilled. E.g. at one point the bulk of "software engineers" hired didn't even study computer science! The IT outsourcing giants would come in and recruit entire batches of graduates regardless of their education background. A surprisingly high portion of, say, TCS employees have a degree in something like Mechanical Engineering.
They key strategy was that these high-skilled workers acted as high-leverage points of quality control that were scaled to a much larger force of lower-skilled workers via processes. As the lower strata of workers upskilled over time, they were in turn promoted to lead other projects with lower-skilled workers.
In fact, you see this same dynamic in high-performing software teams, where there is a senior tech lead and a number of more junior engineers. The quality of output depends heavily on the skill-level of the lead rather than the more numerous juniors.
Re: Anthropic, I think we're conflating coding and software engineering. Writing an entire JS runtime is not just coding, it's a software engineering project, and I totally agree that AI cannot do software engineering: https://news.ycombinator.com/item?id=46210907
not OP but I have a hard metric for you.
AI multiplied the amount of code I committed last month by 5x and it's exactly the code I would have written manually. Because I review every line.
model: Claude Sonnet 3.5/4.5 in VSCode GitHub Copilot. (GPT Codex and Gemini are good too)
I have no reason to think you're lying about the first part (although I'd point there's several ways that metric could be misleading, and approximately every piece of evidence available suggests it doesn't generalize), but the second part is very fishy. There's really no way for you to know whether or not you'd have written the same code or effectively the same code after reviewing existing code, especially when that review must be fairly cursory (because in order to get the speed up you claim, you must be spending much less time reviewing the code than it would have taken to write). Effectively, what you've done is moved the subjectivity from "how much does this speed me up?" to "is the output the same as if I had done it manually?"
> There's really no way for you to know whether or not you'd have written the same code or effectively the same code after reviewing existing code.
There is in my case because it's just CRUD code. The pattern looks exactly like the code I wrote the month prior.
And this is where LLMs excel at, in my experience. "Given these examples, extrapolate to these other cases."
I am not even a software engineer but from using the models so much I think you are confined to a specific niche that happens to be well represented in the training data so you have a distorted perspective on the general usefulness of language models.
For some things LLMs are like magic. For other things LLMs are maddeningly useless.
The irony to me is anyone who says something like "you don't know how to use the LLM" actually hasn't explored the models enough to understand their strengths/weaknesses and how random and arbitrary the strengths and weakness are.
Their use cases happen to line up with the strengths of the model and think it is something they are doing special themselves when it is not.
>No I'm not, I'm just sick of these edgy takes where AI does not improve productivity when it obviously does.
Feel free to cite said data you've seen supporting this argument.
My company mandates AI usage and logs AI usage metrics as input to performance evaluation, so I use it every day. It's a Copilot subscription, though.
why though? are they just using it as a proxy for "is 'gitremote' working today?"
Someone in management needs a promotion for his impact in revolutionizing and streamlining development from his charlatan managers.
The first time i asked it about some code in a busy monorepo and it said "oh bob asked me to do this last week when he was doing X, it works like Y and you can integrate it with your stuff like Z, would you like to update the spec now?"... I had some happy feelings. I dont know how they do it without clobbering the context, but it's great.
This is probably where they're getting their "90% of code is written with AI!!) metrics from
I have successfully vibe-coded features in C. I still don't like C. The agent forgets to free memory latter just like a human would and has to go back and fix it later.
On the other hand, I've enjoyed vibe coding Rust more, because I'm interested in Rust and felt like my understanding approved along they way as I saw what code was produced.
A lot of coding "talent" isn't skill with the language, it's learning all the particularities of the dependencies: The details of the Smithay package in Rust, the complex set of GTK modules or the Wayland protocol implementation.
On a good day, AI can help navigate all that "book knowledge" faster.
Something I've noticed that I never really see called out is how easy it is to review rust code diffs. I spent a lot of my career maintaining company internal forks of large open source C programs, but recently have been working in rust. The things I spent a lot of time chasing down while reviewing C code diffs, particularly of newer team members, is if they paid attention to all the memory assumptions that were non-local to the change they made. Eg. I'd ask them "the way you called this function implies it _always_ frees the memory behind that char*. Is that the case?" If they didn't know the answer immediately I'd be worried and spend a lot more time investigating the change before approving.
With rust, what I see is generally what I get. I'm not worried about heisenbug gotchas lurking in innocent looking changes. If someone is going to be vibe coding, and truly doesn't care about the language the product ends up in, they might as well do it in a language that has rigid guardrails.
How do LLMs deal with Rust (compared to other languages)? I think this might actually be the time to finally give the language a try. LLMs really lowered the barrier for staying productive while learning.
This is extremely limited scope annecdata, but I've spent a few tens of hours each testing LLM coding agents in Rust for personal projects and in Python at work. My impression is that LLMs are far more productive in Rust. I attribute this to the far more structured nature of Rust compared to Python, and possibly the excellent compiler error messages as well.
The LLM gets stuck in unproductive loops all the time in Python. In Rust, it generally converges to a result that compiles and passes unit tests. Of course the code quality is still variable. My experience is that it works best when prompts are restricted to a very small unit of work. Asking an LLM to write an entire library/module/application from scratch virtually never results in usable code.
sometimes they randomly choose the ugliest possible way to do pattern matching, eg multiple blocks of nested "if let" instead of a "match", or a "match" instead of a single "if let"
otherwise, works great; much easier to un-vibe the code compared to eg python
(gpt 5.* in codex/sonnet 4.5 in cc/glm 4.6)
It's really funny how much better the AI is at writing python and javascript than it is C/C++. For one thing it proves the point that those languages really are just way harder to write. And another thing, it's funny that the AI makes the exact same mistakes a human would in C++. I don't know if it's that the AI was trained on human mistakes, or just that these languages have such strong wells of footguns that even an alien intelligence gets trapped in them.
So in essense I have to disagree with the author's suggestion to vibe code in C instead of Python. I think the python usability features that were made for humans actually help the AI the exact same ways.
There are all kinds of other ways that vibe coding should change one's design though. It's way easier now to roll your own version of some UI or utility library instead of importing one to save time. It's way easier now to drop down into C++ for a critical section and have the AI handle the annoying data marshalling. Things like that are the real unlock in my opinion.
I don't think it has much to do with the languages being harder .. the training sets for JS and Python are probably an order of magnitude larger.
More examples/better models and less footguns. In programming, the fewer (assumed correct) abstractions, the more room for error. Humans learned this awhile ago, which is why your average programmer doesn't remember a lick of ASM, or have to. One of the reasons I don't trust vibe coding lower level languages is that I don't have multiple tools with which to cross check the AI output. Even the best AI models routinely produce code that does not compile, much less account for all side effects. Often, the output outright curtails functionality. It casually makes tradeoffs that a human would not make (usually). In C, AI use is a dangerous proposition.
The amount of freely available C code must be very large. Good C code, significantly smaller :-\
> I don't know if it's that the AI was trained on human mistakes, or just that these languages have such strong wells of footguns that even an alien intelligence gets trapped in them.
First one. Most of C code you can find out there is either oneliners or shit, there are fewer bigger projects for the LLMs to train on, compared to python and typescript
And once we go to the embedded space, the LLMs are trained on manufacturer written/autogenerated code, which is usually full of inaccuracies (mismatched comments) bugs and bat practices
> It's really funny how much better the AI is at writing python and javascript than it is C/C++. For one thing it proves the point that those languages really are just way harder to write.
I have not found this to be the case. I mean, yeah, they're really good with Python and yeah that's a lot easier, but I had one recently (IIRC it was the pre-release GPT5.1) code me up a simulator for a kind of a microcoded state machine in C++ and it did amazingly well - almost in one-shot. It can single-step through the microcode, examine IOs, allows you to set input values, etc. I was quite impressed. (I had asked it to look at the C code for a compiler that targets this microcoded state machine in addition to some Verilog that implements the machine in order for it to figure out what the simulator should be doing). I didn't have high expectations going in, but was very pleasantly surprised to have a working simulator with single-stepping capabilities within an afternoon all in what seems to be pretty-well written C++.
I mean, there's C, and then there's C++. I've found AI to be pretty okay at C.
> I have successfully vibe-coded features in C. I still don't like C.
Same here. I've been vibe-coding in C for the sake of others in my group who only know C (no C++ or Rust). And I have to say that the agent did do pretty well with memory management. There were some early problems, but it was able to debug them pretty quickly (and certainly if I had had to dig into the intricacies of GDB to do that on my own, it would've taken a lot longer). I'm glad that it takes care of things like memory management and dealing with strings in C (things that I do not find pleasant).
Lately I have learned assembly more deeply and I sometimes let an AI code up the same thing I did just to compare.
Not that my own code is good but every single time assembly output from an optimizing compiler beats the AI as it "forgets" about all the little tricks involved. However it may still be about how I prompt it. If I tell it to solve the actual challenge in assembly it does do that, it's just not good or efficient code.
On the other hand because I take the time to proof read it I learn from it's mistakes just as I would from my own.
Shouldn't we try vibe coding on IR then? Basically assembly before compiler optimizations?
Yeah I suppose one would need not only the source and binaries but also the IR in AI training data which may be rare but could probably be easily generated for a lot of software.
> The agent forgets to free memory latter just like a human would and has to go back and fix it later.
I highly recommend people learn how to write their own agents. Its really not that hard. You can do it with any llm model, even ones that run locally.
I.e you can automate things like checking for memory freeing.
Why would I want to have an extra thing to maintain, on top of having to manually review, debug, and write tests for a language I don't like that much?
You don't have to maintain it. LLMs are really good at following direction.
I have a custom agent that can take python code, translates it to C, does a refactoring job to include a mempool implementation (so that memory is allocated once at the start of the program and instead of malloc it grabs chunks out of mempool), runs cppcheck, uploads to a container, and runs it with valgrind.
Been using it since ChatGPT3 - the only updates I did to it was API changes to call different providers. Doesn't use any agent/mcp/tools thing either, pure chat.
There's always going to be some maintenance, at the very least the API changes for providers you mentioned, and then there's still the reviews and testing of the C.
A mempool seems very much like a DIY implementation of malloc, unless you have fixed size allocations or something else that would make things different, not sure why I'd want that in the general case.
For "non hacker style" production code it just seems like a lot of extra steps.
> I.e you can automate things like checking for memory freeing.
Or, if you don't need to use C (e.g. for FFI or platform compatibility reasons), you could use a language with a compiler that does it for you.
Right, a lot of the promise of AI can (and has) been achieved with better tool design. If we get the AI to start writing Assembly or Machine Code as some people want it to, we're going to have the same problems with AI writing in those languages as we did when humans had to use them raw. We invented new languages because we didn't find those old ones expressive enough, so I don't exactly understand the idea that LLMs will have a better time expressing themselves in those languages. The AI forgetting to free memory in C and having to go back and correct itself is a perfect example of this. We invented new tools so we wouldn't have to do that anymore, and they work. Now we are going backwards, and building giant AI datacenters that suck up all the RAM in the world just to make up for lost ground? Weak.
> We invented new languages because we didn't find those old ones expressive enough
Not quite. Its not about being expressive enough to define algorithms, its about simplification, organization and avoidance of repetition. We invented languages to automate a lot of the work that programmers had to do in a lower level language.
C abstracts away handling memory addresses and setting up frame stacks like you would in assembly.
Rust makes handling memory more restrictive so you don't run into issues.
Java abstracts away memory management completely, so you don't need to manage memory, freeing up you to design algorithm without worrying about memory leaks (although apparently you do have to worry if your log statements can execute arbitrary code).
Javascript and Python abstract type definition away through dynamic interpretation.
Likewise, OOP/Typing, functional programming, and other styles were included for better organization.
LLMs are right in line with this. There is no difference between you using a compiler to compile a program, vs a sufficiently advanced LLM writing said compiler and using it to compile your program, vs LLM compiling the program directly with agentic loops for accuracy.
Once we get past the hype of big LLMs, the next chapter is gonna be much smaller, specialized LLMs with architecture that is more deterministic than probabilistic that are gonna replace a lot of tools. The future of programming will be you defining code in a high level language like Python, then the LLM will be able to infer a lot of the information (for example, the task of finding how variables relate to each other is right in line with what transformers do) just from the code and do things like auto infer types, write template code, then adapt it to the specific needs.
In fact, CPUs already do this to a certain extent - modern branch predictors are basically miniature neural networks.
I use rust. The compiler is my agent.
Or to quote Rick and Morty, “that’s just rust with extra steps!”
On a related note, I've always regarded Python as the best IDE for writing C. :)
Replace memory with one of the dozen common issues the Rust compiler does nothing for like deadlocks.
Well, the case would still stand, wouldn't it? Unless C is free of these dozen common issues.
Sure. Or you can let the language do that for you and spend your tokens on something else. Like, do you want your LLM to generate LLVM byte code? It could, right? Buy why wouldn't you let the compiler do that?
Unless im writing something like code for a video game in a game engine that uses C++, most of the stuff that I need C is compartmentalized enough to where its much faster to have an LLM write it.
For example, the last C code I wrote was tcp over ethernet, bypassing the IP layer, so I can be connected to the VPN while being able to access local machines on my network.
If im writing it in Rust, I have to do a lot of research, think about code structure, and so on. With LLMs, it took me an hour to write, and that is with no memory leaks or any other safety issues.
Interesting. I find that Claude 4.5 has a ridiculous amount of knowledge and “I don’t know how to do that in Rust” is exactly what it’s good at. Also, have you tried just modifying your route table?
>Also, have you tried just modifying your route table?
The problem is I want to run VNC on my home computer to the server on my work Mac so I can just access everything from one screen and m+b combo without having to use a USB switch and a second monitor. With VPN it basically just does not allow any inbound connections.
So I run a localhost tunnel its a generic ethernet listener that basically takes data and initiates a connection to localhost from localost and proxies the data. On my desktop side, its the same thing just in reverse.
Do you have any good starting points? For example, if someone had an ollama or lm studio daemon running where would they go from that point?
I think arenas might be better memory management technique when vibe coding C, for this reason
I just wrote a piece on this specific C issue the other day https://news.ycombinator.com/item?id=46186930
well,glib is terrible for anything important, it's really just for desktop apps. when there is a mem error, glib does not really handle it,it just aborts. ok for desktop, not ok for anything else.
I addressed this in the first sentence of the second post (g_try_malloc) in a direct reply to my original post: https://news.ycombinator.com/item?id=46186931
There was a recent discussion, “Why AI Needs Hard Rules, Not Vibe Checks” (https://news.ycombinator.com/item?id=46152838). We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding.
Without checks and feedback, LLMs can easily generate unsafe code. So even if they can generate C or Assembly that works, they’re likely to produce code that’s riddled with incorrect edge cases, memory leaks, and so on.
Also, abstraction isn’t only for humans; it’s also for LLMs. Sure, they might benefit from different kinds of abstraction - but that doesn’t mean “oh, just write machine code” is the way to go.
That's a really, really interesting point.
It makes me imagine a programming language designed for LLMs but not humans, designed for rigorous specification of every function, variable, type, etc., valid inputs and outputs, tightly coupled to unit tests, mandatory explicit handling of every exception, etc.
Maybe it'll look like a lot of boilerplate but make it easy to read as opposed to easy to write.
The idea of a language that is extremely high-effort to write, but massively assists in guaranteeing correctness, could be ideal for LLM's.
I'm writing one of these, I'll post it on HN next year. The key to a language for LLMs is: make sure all the context is local, and explicit. If you have functions, use parameters for arguments instead of positions. If you have types, spell them out right there. Also, don't use too many tokens, so keywords are out. And that's just a start.
I think the ideal language for LLMs will look more like APL than C.
So, Eiffel or Ada and TLA+
Feel like you can also achieve pretty correct programs using good tests. Like really good tests.
I’m thinking of generative tests (quickcheck style), fuzzing, erroring on invariants, contract testing (see the test.contract clojure library for a very cool contract test setup!).
Really really good test suites can do stuff that even logically verified programs can’t do. They’re just a pain in the ass to write. Seems like a good use of LLMs, and you can keep using the same languages!
That’s what the article is about.
No it's not. The article proposes the idea of a language designed for vibe-coding, and suggests several variants designed for specific purposes. But none of the variants are for the purpose I suggested, which is about maximizing correctness. That's the point I was making.
If it needs that many rules, why use AI at all? Linters pre-exist AI, don't cost money, and don't boil the oceans.
Look at Shellcheck. It turns a total newbie into a shell master just by iteration.
I find it's really nice to just have Claude run the compilers and linters when it's done making a change, as it often has some mistakes and will catch them at this step. It lets me step in for review after some trivially stupid thing is fixed up, rather than wasting my own time.
I'm starting to believe other people have a very different experience from me. I use AI to write Terraform. It "fixes" things I don't want "fixed", changes the functionality I wanted, disobeys restrictions I gave it, etc. About half of the time, my time is wasted.
Yeah, I haven't used it to write Terraform yet and am not surprised that it would trip on itself with it. However, I did do a major refactor to AWS CDK using TypeScript and Claude worked really well. I treat it as a pair programmer, have it work really atomically, and always question it's work. I find scoping things down really helps with the quality of it's output.
The people you write to don't want or just can't code.
To go along with this, the ACM has a recent article on Automatically Translating C to Rust. It gets into the challenges of 'understanding code and structure' so that the end result reflects the intent of the code, not the actual execution paths.
https://cacm.acm.org/research/automatically-translating-c-to...
Rust doesn't prevent programs from having logic errors.
If LLMs produce code riddled with bugs in one language it will do in other languages as well. Rust isn't going to save you.
Idiomatic Rust prevents many classes of logic errors. Just having proper sum types eliminates many (perhaps most) common logic errors.
Idiomatic Java too.
Not my experience. For example the "official" way of achieving the equivalent of sum types (the visitor pattern) is so verbose that idiomatic Java tends to use the equivalent of a "single table inheritance" style instead of proper domain modelling, which inevitably leads to all sorts of logic errors. Idiomatic Java uses "magic" AOP because the alternatives are too verbose, but this also inevitably causes logic errors (indeed in some ways it's worse than C where you'd do the equivalent thing with a preprocessor macro, which is at least a bit more visible in the code even if only due to conventions like UPPERCASE names). What kind of logic errors are seen in C that you would claim that idiomatic Java avoids?
I mean if you write bad code and don't follow the guidelines what you expect?
> Rust doesn't prevent programs from having logic errors.
Sure, but it prevents memory safety issues, which C doesn't. As for logic bugs, what does prevent them? That's a bigger question but I'd suggest it's:
1. The ability to model your problem in a way that can be "checked". This is usually done via type systems, and Rust has an arguably good type system for this.
2. Tests that allow you to model your problem in terms of assertions. Rust has decent testing tooling but it's not amazing, and I think this is actually a strike against Rust to a degree. That said, proptest, fuzzing, debug assertions, etc, are all present and available for Rust developers.
There are other options like using external modeling tools like TLA+ but those are decoupled from your language, all you can ever do is prove that your algorithm as specified is correct, not the code you wrote - type systems are a better tool to some degree in that way.
I think that if you were to ask an LLM to write very correct code then give two languages, one with a powerful, express type system and testing utilities, and one without those, then the LLM would be far more likely to produce buggy code in the system without those features.
Logic errors always stems from lack of understanding and inattention. The former is resolved by good communication and analytical skills. The other is just human nature, but we do have guardrails to help, like static analysis and tests. If used correctly.
There are static tools available for C as well. What you get from Rust mostly is that the check is part of the syntax of the language as well and escaping from it is very visible. You get safety, but you give up flexibility and speed.
> Logic errors always stems from lack of understanding and inattention
Really? Never from limitations of the ability to express your mental model in a way that's formally verifiable? What a strong claim to make.
> There are static tools available for C as well.
For checking the semantics of the code itself? And why discount the fact that a tool being native means it's easier to adopt?
All kinds of drugs produce unwanted risks and side effects if abused, so let's abuse crystal meth! Cannabis isn't going to save you.
> Rust doesn't prevent programs from having logic errors.
Like everything around Rust, this has been discussed ad nauseam.
Preventing memory safety bugs has a meaningful impact in reducing CVEs, even if it has no impact on logic bugs. (Which: I think you could argue the flexible and expressive type system helps with. But for the sake of this argument, let's say it provides no benefits.)
It isn't like rust is the only language with memory safety; plenty of high level languages don't let you fiddle with memory bits in a way that would be unsafe. The tradeoff is that they typically come with garbage collectors.
If the only concern is "can an LLM write code in this language without memory errors" then there's plenty of reasons to choose a language other than Rust.
But the author isn't saying we should program in any of these memory safe languages. The author is saying why don't we vibe code in C, or even assembly.
This thread moved the conversation away from the posted article quite a few messages ago.
First, Rust has lots of checks that C and assembly don't, and AI benefits from those checks. Then, a post about those checks are related to memory safety, not logic errors. Then, a post about whether that's a helpful comment. Finally, me pointing out that checks regarding types and memory errors aren't unique to Rust and there's tons of languages that could benefit.
Since you want to bring it back to the original article, here's a quote from the author:
It would seem that the author fundamentally misunderstand significant reasons for many of the languages he mentions to be the way that they are.> Rust has lots of checks that C and assembly don't, and AI benefits from those checks.
Fil-C gets you close in the case of C, but we can ignore it because, of course, F* has significantly more checks than Rust, and AI benefits from those checks. Choosing Rust would be as ridiculous as choosing C if that was your motivation.
But if you don't find the need for those checks in order to consider Rust, why not C or even assembly instead?
Fil-C is way too new for LLMs to understand it and not just hallucinate back into normal C
Well, that's what the checks are for: So that hallucinations are caught by said checks and can be fed back into the LLM to ruminate on.
If you don't find importance in those checks, you wouldn't choose Fil-C anyway. But, of course, it remains that if do find those checks to be important, you're going to use a serious programming language like F* anyway.
There is really no place for Fil-C, Rust, etc. They are in this odd place where they have too many checks to matter when you don't care about checks, but not enough checks when you do care about checks. Well, at least you could make a case for Fil-C if you are inheriting an existing C codebase and need to start concerning yourself with checks in that codebase which previously didn't have concern for them. Then maybe a half-assed solution is better than nothing. But Rust serves no purpose whatsoever.
The trade-off is intended to make it easier for people to write software. Garbage collected languages make it easier for people to write memory safe code at the expense of performance, significantly greater memory usage, and heavy dependencies/runtimes.
These trade-offs are wholly unnecessary if the LLM writes the software in Rust, assuming that in principle the LLM is able to do so.
> Rust doesn't prevent programs from having logic errors.
Nobody ever claimed that. The claims are:
1. Rust drastically reduces the chance of memory errors. (Or eliminates them if you avoid unsafe code.)
2. Rust reduces the chance of other logic errors.
Rust doesn't have to eliminate logic errors to be a better choice than C or assembly. Significantly reducing their likelihood is enough.
Every language with a GC drastically reduces the chance of memory errors.
Yeah and I would say they're probably a better choice for vibe coding than C!
But most of them don't have a nice strong type system like Rust. I have vibe coded some OCaml and that seems to work pretty well but I wouldn't want to use OCaml for other reasons.
But if you use managed laguages you can't feel superior like when coding in Rust.
Can these claims back themselves up with a study showing that over a large population size with sufficient variety, sourced from a collection of diverse environments, LLM output across a period of time is more reliably correct and without issue when outputting Rust? Otherwise this is nothing but unempirical conjecture.
Ah the classic "show me ironclad evidence of this impossible-to-prove-but-quite-clear thing or else you must be wrong!"
Although we did recently get pretty good evidence of those claims for humans and it would be very surprising if the situation were completely reversed for LLMs (i.e. humans write Rust more reliably but LLMs write C more reliably).
https://security.googleblog.com/2025/11/rust-in-android-move...
I'm not aware of any studies pointing in the opposite direction.
Actually it's the classic "inductive reasoning has to meet a set of strict criteria to be sound." Criteria which this does not meet. Extrapolation from a sample size of one? In a context without any LLM involvement? That's not sound, the conclusion does not follow. The point being, why bother making a statistical generalization? Rust's safety is formally known, deduction over concrete postulates was appropriate.
> it would be very surprising if the situation were completely reversed for LLMs
Lifetimes must be well-defined in safe Rust, which requires a deep degree of formal reasoning. The kind of complex problem analysis where it is known that LLMs produce worse results in than humans. Specifically in the context of security vulnerabilities, LLMs produce marginally less but significantly more severe issues in memory safe languages[1]. Still though, we might say LLMs will produce safer code with safe Rust, on the basis that 100,000 vibe coded lines will probably never compile.
[1] - https://arxiv.org/html/2501.16857v1
I never claimed to be doing a formal proof. If someone said "traffic was bad this morning" would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?
> LLMs produce worse results in than humans
We aren't talking about whether LLMs are better than humans.
Also we're obviously talking about Rust code that compiles. Code that doesn't compile is 100% secure!
I didn't claim that you were doing formal proofs. You can still make bad rhetoric, formal or not. You can say "The sky is blue, therefore C is a memory safe language" and that's trivially inferred to be faulty reasoning. For many people bad deduction is easier to pick up on than bad induction, but they're both rhetorically catastrophic. You are making a similarly unsound conclusion to the ridiculous example above, its not a valid statistical generalization. Formal or not the rhetoric is faulty.
> would you say "have you done a scientific study on the average journey times across the year and for different locations to know that it was actually bad"?
In response to a similarly suspiciously faulty inductive claim? Yeah, absolutely.
> We aren't talking about whether LLMs are better than humans.
The point I'm making here is specifically in response to the idea that it would "be surprising" if LLMs produced substantially worse code in Rust than they did in C. The paper I posted is merely a touch point to demonstrate substantial deviation in results in an adjacent context. Rust has lower surface area to make certain classes of vulns under certain conditions, but that's not isomorphic with the kind of behavior LLMs exhibit. We don't have:
- Guarantees LLMs will restrict themselves to operating in safe Rust
- Guarantees these specific vulnerabilities are statistically significant in comparative LLM output
- The vulnerability severity will be lower in Rust
Where I think you might be misunderstanding me is that this isn't a statement of empirical epistemological negativism. I'm underlining that this context is way too complex to be attempting prediction. I think it should be studied, and I hope that it's the case LLMs can write good, high quality safe Rust reliably. But specifically advocating for it on gut assumptions? No. We are advocating for safety here.
Because of how chaotic this context is, we can't reasonably assume anything here without explicit data to back it up. It's no better than trying to predict the weather based on your gut. Hence, why I asked for specific data to back the claim up. Even safe Rust isn't safe from security vulnerabilities stemming from architectural inadequacies and panics. It very well may be the case that in reasonably comparable contexts, LLMs produce security vulnerabilities in real Rust codebases at the same rate they create similar vulnerabilities in C. It might also be the case that they produce low severity issues in C at a similar statistical rate as high severity issues in Rust. For instance, buffer overflows manifesting in 30% of sample C codebase resulting in unexploitable segfaults, vs architectural deficiencies in a safe Rust codebase, manifesting in 30% of cases, that allow exfiltration of everything in your databases without RCE. Under these conditions, I don't think it's reasonable to say Rust is a better choice.
Again, it's not a critique in some epistemological negativist sense. It's a critique that you are underestimating how chaotic this context actually is, and the knock-on effects of that. Nothing should surprise you.
Modern medicine can't prevent or cure all diseases, so you might as well go back to drinking mercury then rubbing dog shit into your wounds.
Modern sewers sometimes back up, so might as well just releive yourself in a bucket and dump it into your sidewalk.
Modern food preservation doesn't prevent all spoilage so you might as well just go back to hoping that meat hasn't been sitting in the sun for too many days.
This is objectively wrong.
You can't get a gutter ball if you put up the rails in a bowling lane. Rust's memory safety is the rails here.
You might get different "bad code" from AI, but if it can self-validate that some code it spits out has memory management issues at compile time, it helps the development. Same as with a human.
> You can't get a gutter ball if you put up the rails in a bowling lane.
Sure you can. It's difficult, and takes skill, but it can be done.
technically true but so what?
https://security.googleblog.com/2025/11/rust-in-android-move...
That team claims that not having to deal with memory bugs saved them time. That time can be spent on other things (like fixing logic errors)
That time can be spent on solving rust type puzzles
Absolutely. A language being well suited to static analysis and "compiler driven development" matters a lot more with LLMs than with humans IMO
We're at the point of diminishing returns from scaling and RL is the only way to see meaningful improvements
Very hard to improve much via RL without some way to tell if the code works without requiring compilation
Logic based languages like Prolog take this to the logic extreme, would love to see people revisit that idea
Why Rust? Haskell is gold standard here.
I guess there is a reason why Linux kernel accepts Rust not Haskell.
Haskell need a runtime environment for memory management.
Linux want all memory management explicit.
Politics. That's all it is.
There isn’t enough code and resources to <s>steal</s> learn from. And I mean not only the language but the paradigm.
I would think Lean and other formal languages are the real gold standard.
But none of them really have enough training data for LLMs to be any good at them.
Can you elaborate? What is it about Haskell that makes it better?
Very advanced type system which allows to move a lot of program correctness to typing system. So basically if your program compiles, it probably works.
It's also has GC which makes it better suited for most programs, compared to Rust with its manual memory management.
Rust does not have manual memory management, and its type system also has the property that if your program compiles it probably works, IME.
I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.
So...yeah.
How did your tests pass if you didn't handle state?
Because it is also possible to write tests that don't adequately capture real-life requirements.
It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.
It is still possible to write bugs in both Haskell and Rust.
Yes, that's my point. I'm replying to claims that "if it compiles it probably works". My limited experience with both is "nah".
I prefer the slogan without "probably", "If it compiles it works", because then at least it's clear it's a slogan and not a formal claim. Everyone knows that if you write
then it will compile but not work, so they don't take it literally. But it is a pithy statement of the lived experience of many users of strongly typed programming, which is more accurately described by something like "if it compiles then it will probably do something at least basically sensible and often be pretty close to what you actually wanted".Purely functional code is easier to test because of its referential transparency and lack of shared state.
Haskell is also nice because of quickcheck.
>We need as many checks as possible - and ideally ones that come for free (e.g., guaranteed by types, lifetimes, etc.) - which is why Rust might be the language for vibe coding.
Checking preconditions and postconditions is much easier to do for a human than checking an implementation
The thing that would really make sense is a proved language like Coq or Promela
You can then really just leave the implementation to the AI.
> abstraction isn’t only for humans; it’s also for LLMs.
Bingo. LLMs are language models, not models of software systems. Everything gets translated through natural language! So the quality of the abstraction still matters: code that can be described well in plain language wins.
I think it's a pretty good point. I've been using LLMs for .NET and the output is generally pretty good.
agree 100%
I really tried to get into the vibe coding thing - just describe the thing I need in human language and let the agent figure it out. It was incredible at first. Then I realized that I am spending a lot of time writing clarifications because the agent either forgot or misinterpreted something. Then I realized that I am waiting an awful long time for each agent step to complete just to write another correction or clarification. Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed. Now I am back to programming myself and only bouncing the boring bits off of ChatGPT.
> Then I realized that this constant start-stop process is literally melting my brain and making me unable to do any real work myself. It's basically having the same effect as scrolling any other algorithmic feed
Yes, it’s extremely soul sucking. With the added disadvantage of not teaching me anything.
I felt this way too until I decided that my goal isn't to know things, it's to ship things.
I felt this way too until I decided that my goal isn't to ship things, it's to ship, support and improve existing things.
If your job is not to know things, just to prompt an agent to ship things, why would you have a job in a year?
Sounds very depressing.
One trick I have tried is asking the LLM to output a specification of the thing we are in the middle of building. A commenter above said humans struggle with writing good requirements - LLMs have trouble following good requirements - ALL of them - often forgetting important things while scrambling to address your latest concern.
Getting it to output a spec lets me correct the spec, reload the browser tab to speed things up, or move to a different AI.
One thing that helps is to write an AGENTS.md file that encodes the knowledge and tricks you have of the codebase, like running a single test (faster feedback cycles), common coding patterns, examples, etc.
I went full meta and sketched out a file, then had an expensive LLM go through the codebase and write such a file. I don't know if it's any good though, I only really use coding assistants to write unit tests.
I don't have much experience with it either, but what has worked so far is breaking down the problem into very small steps I can verify easily.
At this point it's easier to just write the code. If my prompt is to be longer than the code produced, why bother with explaining that to LLM?
The delta between "make a small requirement that you can check and verify" vs "create the code yourself" is pretty big. A well crafted sentence can sometimes still be hours of work.
I very much doubt the ability of LLMs to provide leak-free, faulty memory management free, C code, because they are trained on loads of bad code in that regard. They will not output code of the quality that maybe 1% of C developers could, if even that many. Fact is, that even well paid and professional C/C++ developers introduce memory management issues in such code bases (see Chromium project statistics about this). So chances to get good C programs from LLMs, which learn from far lower quality code than Chromium, are probably very slim.
Vibe-coding a program that segfaults and you don't know why and you keep burning compute on that? Doesn't seem like a great idea.
He says in his article:
>Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal.
I've been using Rust with LLMs for a long time (mid-2023?) now; cargo check and the cargo package system make it very easy for LLMs to check their work and produce high quality code that almost never breaks, and always compiles.
My favorite use for LLMs with Rust is using them as a macro debugger; they provide better error messages than the errors Cargo can provide. It's cool to take a macro and ask the LLM to do an expansion of it, to see what it would look like. Or, to take Rust code and ask the LLM to create a macro for it.
I agree that an LLM may make mistakes. But one advantage is, that you can also allocate resources for it to try and find its own mistakes. You can do this humans, but the grind wears away at them. Since this doesn't really happen with an LLM, it's pretty decent at catching it's own mistakes too.
Well, most LLM are fine tuned over higher quality data, this is kind of how they've kept improving them amongst other things.
The first pass is to learn the fundamentals of language, and then it is refined on curated datasets, so you could refine them on high quality curated C code.
> But if you look carefully, you will notice that it doesn’t struggle with undefined behavior in C. Or with making sure that all memory is properly freed. Or with off-by-one errors.
Doubt. These things have been trained to emulate humans, why wouldn't they make the same mistakes that humans do? (Yes, they don't make spelling errors, but most published essays etc. don't have spelling errors, whereas most published C codebases do have undefined behaviour).
I'm not very experienced with C++ at all but Sonnet in Copilot/Copilot Chat was able to create entire files with no memory errors on the first try for me, and it was very adept at hunting down memory errors (they were always my own fault) from even just vague descriptions of crashes.
> entire files with no memory errors
How do you know? I can believe that they didn't show memory errors in a quick test run on a common architecture with a common compiler, much like most human-written code in the training corpus.
It wasn't code worth formally verifying, but even your description beats almost any programmer's first pass. With how good it is at finding bugs if you ask it, I have little reason to doubt its output.
In the real world, I'd say the 90% of the C code written is somewhere between "worthwhile to spend extra effort to detect and avoid memory errors" and "worth formally verifying".
Sure, for prototype sized codebases it might be able to handle finding mistakes a fresh grad might easily make, or even that memory bugs aren't a big problem - but in my experience it happily adds memory bugs to large codebases and multithreaded code (that I think an experienced human could easily spot tbh).
I felt the opposite, it had superhuman ability to spot multithreading and memory mistakes that could have taken me days to debug.
"I don't understand the code it's writing, but I know it's smarter than you devs" is not very persuasive.
> even your description beats almost any programmer's first pass
Sure, but having access to merely mildly superhuman programming ability still doesn't make using C a good idea.
There are some misconceptions here.
It's incorrect to think because it is trained on buggy human code it will make these mistakes. It predicts the most likely token. Let's say 100 programmers write a function, most (unless it's something very tricky), won't forget to free that particular function. So the most likely tokens are those which do not leak.
In addition, this is not GPT 3. There's a massive amount of reinforcement learning at play, which reinforces good code, particularly verifiably good (which includes no leaks). And also a massive amount of synthetic data which can also be generated in a way that is provably correct.
> Let's say 100 programmers write a function, most (unless it's something very tricky), won't forget to free that particular function. So the most likely tokens are those which do not leak.
You don't free a function.
And this would only be true if the function is the same content with minor variations, which is why LLMs are better suited for very small examples. Because bigger examples are less likely to be semantically similar, and so there is less data to determine the "correct" next token.
> There's a massive amount of reinforcement learning at play, which reinforces good code, particularly verifiably good (which includes no leaks)
This is a really dubious claim. Where are you getting this? Do you have some information on how these models are trained on C code specifically? How do you know whether the code they train on has no leaks?
There are huge projects that everyone depends on that have memory bugs in them right now. And these are actual experts missing these bugs, what makes you think the people at OpenAI are creating safer data than the people whose livelihoods actually depend on it?
This thread is full of people sharing how easy it is to make memory bugs with an LLM, and that has been my experience as well.
Don't train them to emulate humans. Train them to emulate compilers instead.
Exactly why Rust is a better candidate for LLM generated code than C IMO
I've had issues with Claude and memory related bugs in C. Maybe small programs or prototypes it's fine if you can verify the output or all the expected inputs, but the moment the context is >50k lines or even doing something with pthreads, you run into the exact same problems as humans.
I think Claude would do much better with tools provided by modern C++ or Zig than C, frankly, anyways. Or even better, like the Rust people have helpfully mentioned, Rust.
> Or hell, why not do it in x86 assembly?
Because I want to be able to review it, and extend it myself.
edit: Pure vibe coding is a joke or thought exercise, not a goal to aspire to. Do you want to depend on a product that has not been vetted by any human? And if it is your product, do you want the risk of selling it?
I can imagine a future where AI coders and AI QA bots do all the work but we are not there yet. Besides, an expressive language with safety features is good for bots too.
We could go to the semantic road and proclaim that if you extend it yourself, it's not "pure" vibe coding.
I'm getting too old for this shit.
Their point is you're not going to be able to extend it if you didn't understand it in the first place.
> if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP.
A language designed for vibe coding could certainly be useful, but what that means is the opposite of what the author thinks that means.
The author thinks that such a language wouldn't need to have lots of high-level features and structure, since those are things that exist for human comprehension.
But actually, the opposite is true. If you're designing a language for LLMs, the language should be extremely strict and wordy and inconvenient and verbose. You should have to organize your code in a certain way, and be forced to check every condition, catch every error, consider every edge case, or the code won't compile.
Such a language would aggravate a human, but a machine wouldn't care. And LLMs would benefit from the rigidness, as it would help prevent any confusion or hallucination from causing bugs in the finished software.
Sounds like Ada. A lot of the time, once you got your code to compile, it would work.
What about Lean?
I don't think there is a need for an output language here at all, the LLM can read and write bits into executables directly to flip transistors on and off. The real question is how the input language (i.e. prompts) look like. There is still a need for humans to describe concepts for the machine to code into the executable, because humans are the consumers of these systems.
> the LLM can read and write bits into executables directly to flip transistors on and off
No, that's the problem (same misconception the author has) - it can't. At least not reliably. If you give an LLM free rein with a non-memory safe output format, it will make the exact same mistakes a human would.
The point of a verbose language is to create extensive guardrails. Which the LLM won't be annoyed by, unlike a human developer.
Vibe coding should be done in Python, and probably only in Python.
If a project is important enough to require C or x86 assembly, where memory management and undefined behavior have real consequences, then it’s important enough to warrant a real developer who understands every line. It shouldn’t be vibe coded at all.
Python’s “adorable concern for human problems” isn’t a bug here, it’s a feature. The garbage collection, the forgiving syntax, the interpreted nature: these create a sandbox where vibe coded solutions can fail safely. A buggy Python script throws an exception. A buggy C program gives you memory corruption or security holes that show up three deployments later.
The question isn’t what language should AI write. It’s what problems should we trust to vibe coding. The answer: problems where Python’s safety net is enough. The moment you need C’s performance or assembly’s precision, you’ve crossed into territory that demands human accountability.
I'm really curious to see if Python will maintain this lead in the future or if all languages will catch up to the same level of accuracy.
If not then I see the argument for everything being done in Python and performance coming from optimizing Python -> C.
I don't think we will ever reach the same accuracy simply because some languages are harder than others. Writing correct C (not just "working C") is difficult because of the number of footguns and the amount of reasoning and implicit state tracking you have to do in your head. LLMs are not free from this, if anything that's harder for them. Meanwhile languages like Java are more difficult just because they are verbose and spread information over many files. Languages that are explicit, not overly verbose and make it difficult to make subtle mistakes will always have the advantage with LLMs
I more bullish on the Python -> Rust pipeline. The two languages have a lot of overlap in philosophies, have great interop, and have similar levels of guard rails (when it comes to multithreading Rust even beats Python in terms of safety). And both languages seem well suited to being vibecoded
Yea agreed, by C I really meant 'low level'. If as an industry we had to support a language under Python, Rust is probably it.
I wouldn't limit it strictly to Python, but I agree that it should be limited to memory safe languages. Vibe code in C#, Rust or PHP if that suits your requirements, but C or assembly are indeed poor choices for the reasons you list
Go is perfect for this.
Vibe coded Python can certainly have security holes too.
If you want a language that protects you from the largest amount of problems, how about Rust? Vulnerabilities will still be possible, but at least data races won't be possible.
> The moment you need C’s performance or assembly’s precision, you’ve crossed into territory that demands human accountability.
I disagree. I write a lot of one-off numerical simulations where something quick and dirty is useful but performance matters and the results can be easily verified without analyzing every line of code. Python would be a terrible choice.
You'd be hard pressed to do any really damage with numerical simulations outside of NaN propagations. C's problems come from the standard library
Am I the only one who feels like this is the output of an LLM?
A poorly written comment by a human wastes time. A vibe comment by an LLM wastes both time and electricity that only shows up when global warming reaches 3c.
The question isn't if the comment is valuable or not. It's whether it is ethical or not to waste peoples time with AI slop.
This is chatGPTs pattern.
Does not sound LLM generated to me
Edit: but I empathize with the paranoia of everything being AI slop! I’m constantly scrutinizing stuff and it’s annoying
Ok but what happens when you reach the point where the LLM makes fewer mistakes than the human? Where it’s better at spotting potential memory corruption and security holes?
It doesn’t feel like we’re very far from that point.
I think you should use a language with a highly expressive type system. That can be assembly too. See TAL back from the 1990'es. I also think you should use a language with a very expressive module system.
The reason is that you want to have some kind of guidance from a larger perspective in the long run. And that is exactly what types and module systems provide. The LLM has to create code which actually type checks, and it can use type checking as an important part of verification.
If you push this idea further: use Lean, Agda or Rocq. Let the LLM solve the nitty gritty details of proof, but use the higher-level theorem formation as the vessel for doing great things.
If you ask for a Red-black tree, you get a red-black tree. If you ask for a red-black tree where all the important properties are proven, you don't have to trust the LLM anymore. The proof is the witness of correctness. That idea is extremely powerful, because it means you can suddenly lift software quality by an order of magnitude, without having to trust the LLM at all.
We currently don't do this. I think it's because proving software correctness is just 50x more work, and it moves too slow. But if you could get an amplifier (LLM) to help out, it's possible this becomes more in the feasible area for a lot of software.
Lean would be so well suited to LLMs. I hope we see a resurgence in interest in languages like that
Formal proofs have so much potential in this context
Can it generate good code?
Both the author and I agree in that yes, it can.
Does it always generate good code?
Here is where the author and I disagree vehemently. The author implies that the ai-generated code is always correct. My personal experience is that it often isn't. Not even for big projects - for small bugfixes it also misunderstands and hallucinates solutions.
So no C or assembly for me, thank you very much.
Because I don't know C well enough.
My philosophy regarding AI is that you should never have it do something you couldn't do yourself.
Of course people break this rule, or the concept of vibe coding wouldn't exist. But some of us actually get a lot of value from AI without succumbing to it. It just doesn't make sense to me to trust a machine's hallucinations for something like programming code. It fabricates things with such confidence that I can't even imagine how it would go if I didn't already know the topic I had it work on.
I'm working on a serious embedded app written in C, and Opus has been invaluable to me. I don't consider myself a C developer, but by carefully reviewing the changes and making lots of my own contributions, I'm finding that I've progressed from junior to intermediate C comprehension. A lot of the idioms are still fuzzy, but I no longer find it intimidating. That's wonderful, because learning C has been something I'd put off for 40 years and microcontrollers were the thing that forced my hand.
I think that there's a real rift between people who use LLMs to rough out large swathes of functionality vs people who took the "vibe coding" brain fart way, way too literally. I'm kind of horrified that there are people out there who attempt to one-shot multiple copies of the same app in different instances and then pick the best one without ever looking at the code because "vibe coding". That was always supposed to be a silly stupid thing you try once, like drinking Tide pods or whatever the kids do for fun... not something people should be debating a year later.
I wish you the best of luck, truly.
But I have written C in the past, it was almost 20 years ago, and everything seemed to work fine, until the memory leaks.
Of course today I would ask the AI, why is my program leaking memory. I think you have a point, AI would be sort of like having a mentor help you find bad practices in your C code.
You've inspired me to maybe try my hand at Rust, something I've been wanting to do since I heard of it.
Would something like automated array bounds checking prevent the memory issues?
You might be interested in AddressSanitizer.
Opus?
Anthropic's model, Claude, comes in three sizes: Haiku, Sonnet, and Opus. Opus 4.5 is the newest.
> Because I don't know C well enough.
Same here. I can read and understand most of it, but not enough to debug it. And outsourcing that task to Claude is like taking a long winding path through thick, dark woods.
This post mixes up “easy for compilers and assemblers to transform and easy for cpus to execute” with “easy for LLMs to understand” and assumes that anything in the first category must also be in the second category since they’re both computers. In reality, the tools that help humans think are also useful for LLMs.
I also enjoy coding! It’s fun. It’s also only about 10% of my job as a software developer, and I can and do use an LLM for it whenever I can find an opportunity. The author is a professor. Not to disparage that perspective, but she paints a picture of the joys of programming that are overshadowed in environments where you are actually building real world robust systems with clueless users, vague requirements, shifting budgets and priorities, etc.
As to why not use C, or assembly, it’s not just about the code, but the toolchains. These require way more knowledge and experience to get something working than, say, Python - although that has its own rather horrible complexities with packaging and portability on the back end of the code authoring process.
LLMs have single handedly turned the hardest part of this job into entire job. The hardest part of this job is troubleshooting, maintaining and developing on top of an unfamiliar code base. That's not a new experience for anyone who has lived the production code life. One of the first production engineers I was tutored under used to love to say, "the code should tell you a story."
I love C. I came up on C. But C does not tell you a story. It tells you about the machine. It tells you how to keep the machine happy. It tells you how to translate problems into machine operations. It is hard to read. It takes serious effort to discern its intent.
I think any time you believe the codebase you're developing will have to be frequently modified by people unfamiliar with it, you should reach for a language which is both limiting and expressive. That is, the language states the code intent plainly in terms of the problem language and it allows a limited number of ways to do that. C#, Java (Kotlin) and maybe Python would be big votes from me.
And FYI, I came up on C. One of the first senior engineers I was tutored by in this biz loved to say, good code will tell you a story.
When you're living with a large, long lived codebase, essenti
> why not do it in C?
Well, because you can do it in Fortran, of course!
What else do you want? Multidimensional arrays out of the box, fast loops, native cuda support, trivial build and packaging system, zero version churning... all of this just with the bare language. It's the anti-python! The perfect language, you could say! Strings and i/o are a bit cumbersome, agreed, but your llm can take care of these without any trouble, no matter the language.
I like the cut of your jib.
I see a lot of "vibe-coding" related articles, but I don't see a lot of shipped projects/products via "vibe-coding". I would like to find some examples instead of this kind of articles ?
I think if I was actually shipping a real product to real customers I would avoid bragging about how I vibe-coded it. Seems like that would bring up some quality / security / pricing discussions that my salespeople would have a tough time navigating. At least for now I think those customer concerns would be justified. Oh you vibed this out in an afternoon? Why does it cost $199/seat? Why don’t I just build it myself?
Yesterday I released a Rust-with-Python-bindings package that was mostly coded with Claude 4.5 Opus: https://github.com/minimaxir/icon-to-image
I'll write about the process after I've released a few more things as I have some disagreements with the current discourse.
That's more interesting, how much were you involved personally in writing the code ? I would love to read about the process !
If you go on YouTube you can find a lot of vibe coders doing interviews where they drop a brief mention of their SaaS products. I think the main reason they are not well publicized is because they obviously have no moat. If I speak to a really big audience and tell them my SaaS which I vibe coded in 1 day is earning 10k/mo, then I'll have 10 competitors by tomorrow.
But if you want a "citation needed" name of someone shipping vibe coded apps and making money off it: on YouTube, Ed Yonge, or many of the guests on Starter Story.
There are a ton of vibecoded tools on simon's website.
Whether those are substantial enough to count as shipped projects is a matter of debate
https://tools.simonwillison.net/
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that.
… well, you are wrong.
I recently gave the "vibe" AI the assignment of "using GTK [4, I think], establish a global shortcut key".
No amount of massaging the prompt, specifying the version of GTK, etc. could prevent it from just outright hallucinating the functions it wanted to call into existence. The entire reason I was asking was because I did not know what function to call, and was having difficulty discerning that from GTK's documentation. (I know how to do this now, and it is effectively undocumented.)
Prior to that, an assignment to determine some information from Alembic. Again, the AI desired to just hallucinate the functions it required into existence.
A script to fetch the merge queue length from GH. It decided to call GH's GraphQL API, which is fine, and doable for the task, but the query was entirely hallucinated.
A bash script to count files change in git. The code ran, and the output was wrong. The author did not check the LLM's code.
Even non-programming tasks are the same. Image generation is a constant fight of trying to get the AI to understand what you mean, or it just ignoring your prompts, etc. I went about 10 prompts trying to get an image with a stone statue of 4 ASCII characters in a field. The last character was consistently just wrong, and no amount of prompting to fix.
"Generate a character with a speech bubble that says 'Hi'" -> speech bubble has Japanese in it! (And the Japanese is gibberish, but if you ask AI to translate it, it "will".)
- C takes a lot more context than a high-level language
- a lot of C code out there is not safe, so the LLM outputs that
- C encodes way less of the programmer's intention, and way more implementation details. So unless the author is extremely good at naming, encapsulating and commenting, the LLM just has less to work with. Not every C code is Sqlite/redis/ffmeg quality.
- the feedback loop is slower, so the LLM has less chance to brute force a decent answer
- there is no npm/pypi equivalent for C on which to train the LLM so the pool for training is less diverse
- the training pool is vastly Linux-oriented, with the linux kernel and distro system libs being very prominent in the training data because C programs on Windows are often proprietary. But most vibe coders are not on Linux, nor into system programming.
Sure, you can vibe code in C. Antirez famously states he gets superb ROI out of it.
But it's likely you'll get even better results with other languages.
>Vibe coding makes me feel dirty in ways that I struggle to articulate precisely. It’s not just that it feels like 'cheating'(though it does). I also think it takes a lot of the fun out of the whole thing.
This exactly. Programming is art, because it comes from the soul. You can tackle a problem a million ways, but there's only one way that YOU would solve it.
Vibe coding feels like people who aren't creative, stealing everyone's creativity, and then morphing it into something they find appealing.
There is no skill.
There is no talent.
You are asking the machine to do ALL THE THINKING. All the little decisions, the quirks, the bugs, the comments to yourself. All the things that make a piece of code unique.
This is treating the LLM like it is the computer or has some kind of way of thinking. But LLM is a "language" model, I'm pretty sure the easier for human to read, the easier for LLM to learn and generate. Abstractions also benefit the model, it does not need to generate a working 2s complement, just a working call to addition of abstracted types.
And just in my experience, I feel everyone is slowly learning, all models are better at the common thing, they are better at bash, they are better at Python and JS, and so on. Everyone trying to invent at that layer has failed to beat that truth. That bootstrapping challenge is dismissed much too easily in the article in my opinion.
Binary bits are also a language. A structured language that transistor-based computers execute into some result we humans find valuable. Why wouldn't a model be able to write these binary instructions directly? Why do we need all these layers in between? We don't.
Because the learned function to generate binary code is likely more complex than that for Python.
I admit I can't say for sure until we try it. If someone were to train a model at the same scale on the same amount of raw binary code as we do these models on raw language and code, would it perform better at generating working programs. Thing is, it would now fail to understand human language prompts.
From what I know and understand though, it seems like it would be more complex to achieve.
My meta point is, you shouldn't think of it as what would a computer most likely understand, because we're not talking about a CPU/GPU. You have to think, what would a transformer architecture deep neural net better learn and infer? Python or binary code? And I think from that lens it seems more likely it's Python.
Why would you think its more complex? There are less permutations of generating transistor on/off states than there are all the different programming languages in use that result in the exact same bits.
Who said that creating bits efficiently from English to be computed by CPUs or GPUs must be done with transformer architecture? Maybe it can be, maybe there are other ways of doing it that are better. The AI model architecture is not the focus of the discussion. It is the possibilities of how it can look like if we ask for some computation, and that computation appears without all the middle-men layers we have right now, English->Model->Computation, not English->Model->DSL->Compiler->Linker->Computation.
> Why would you think its more complex?
Binary code takes more space, and both training and inference is highly capped by memory and context sizes.
Models tokenize to a limited set of tokens, and then learn relations between those. I can't say for sure, but I feel it be more challenging to find tokenization schemes for binary code and learn their relationships.
The model needs to first learn human language really well, because it has to understand the prompt and map it accurately to the binary code. That means the corpus will need to include a lot of human languages that it learns and also binary code, I wonder if the fact they differ so much would conflict the learning.
I think coming up with a corpus of mapped human language to binary code will be really challenging. Unless we can include the original code's comments at appropriate places around the binary code and so on.
Binary code is machine dependent, so it would result in programs that aren't portable between architecture and operating system and so on. The model would need to learn more than one binary code and be able to accurately generate the same program for different target platforms and OS.
> Who said that creating bits efficiently from English to be computed by CPUs or GPUs must be done with transformer architecture?
We've never had any other method ever do as well and by a magnitude. We may invent a whole new way in the future, but as of now, it's the absolute best method we've ever figured out.
> The AI model architecture is not the focus of the discussion. It is the possibilities of how it can look like if we ask for some computation, and that computation appears without all the middle-men layers we have right now, English->Model->Computation, not English->Model->DSL->Compiler->Linker->Computation.
Each layer simplifies the task of the layer above. These aren't like business layer that take a cut of the value out at each level, software layers remove complexity from the layers above.
I don't know why we wouldn't be talking about AI models? Isn't the topic that it may be more optimal for an AI model to be trained on binary code directly and to generate binary code directly? At least it's what I was talking about.
So if I stick to AI models. With LLMs and image/video diffusion and such, we've already observed that inference through smaller steps and chains of inference work way better. Based on that, I feel it's likely going from human language to binary code in a single hop to also work worse.
Diffusion models for images are already pretty much binary code generators. And we don't need to treat each bit individually, even in binary code there are whole segments that can be tokenized into a single token.
Regarding training, we have many binaries all around us, for many of them we also have the source code in whichever language. As a first step we can use the original source code and ask a third party model to explain what it does in English. Then use this English to train the binary programmer model. Eventually the binary programmer model can understand binaries directly and translate them to English for its own use, so with time, we might not even need binaries that have source code, we could narrate binaries directly.
Rust works very well for vibe-coding because the compiler is typically very specific and a bit picky; helps keep it out of traps. I like using WASM with Rust as originator when vibe-coding because AI models are still very "sloppy/forgetful". There is one thing you should still definitely do beforehand, and that's pick out which crates you want and write up the initial Cargo.toml for it, because frontier models have a lot of trouble with fast-updated libraries.
What frontier models also excel at is writing their own libraries and skipping third-party dependencies. It's very easy for a human to just pick up a bloated 750kb library they're only going to actually use 15kb worth of its code for, BUT that library can serve as a valuable implementation model for someone very patient and willing to "reinvent the wheel" a little bit, which is definitely going to be AI and not me, because I just want to point to a black box and tell it what to do. For big things like web server, I'm still defaulting to Axum, but for things like making a JS soundbank parser/player or a WebGL2 mp4 & webm parser/demuxer & player, these are tasks frontier models are good for with the right prompting.
To an extent, maybe counter-intuitively, I think the big thing we'll see out of AI is an explosion of artisanship -- with humanoid robots in 2040, perhaps, our households may be making their own butter again, for example.
I think you're going to need a superhuman intelligence's idea of a super-superhuman intelligence at the very least if you're going to expect C programs that are memory safe.
I'll admit that I'd like to do a programming challenge with or without AI that would be like "advent of code" in assembly but if it was actual "advent of code" the direct route is to write something that looks like a language runtime system so you have the dynamic data structures you need on your fingertips.
The S-SHI would use an advanced subset of C, called "K" (after Kohut, so it's in uppercase)
Even experts create C/C++ code that is routinely exploited in the wild (see: pegasus malware, Zerodium, Windows zero days, Chrome zero days, etc.). No, please don't vibe code anything security critical, and please don't create unnecessary security risk by writing it in unsafe languages such as C/C++. The only advantage I can see is it creates some fun easy targets for beginning exploit developers. But that's not an advantage for you.
I think the main reason not to go full-throttle into "vibes -> machine code" (to extrapolate past doing it in C) is because we have a history of building nested dolls of bounded error in our systems. We do that with the idea of file systems, process separation, call stacks, memory allocations, and virtual machines.
Now, it is true that vibes results in producing a larger quantity of lower-level code than we would stomach on our own. But that has some consequences for the resulting maintenance challenge, since the system-as-a-whole is less structured by its boundaries.
I think a reasonable approach when using the tools is to address problems "one level down" from where you'd ordinarily do it, and to allow yourself to use something older where there is historical source for the machine to sample from. So, if you currently use Python, maybe try generating some Object Pascal. If you use C++, maybe use plain C. If there were large Forth codebases I'd recommend targeting that since it breaks past the C boundary into "you're the operator of the system, not just a developer", but that might be the language that the approach stumbles over the most.
Alright, the whole article stands on the lifting done by the concept of "vibe coding", which is not just asking an LLM to write some code, scan it quickly to check if it at least makes somewhat sense and then accept it. It is based on pure vibe coding, where the user literally has no idea what's being produced.
After having understood the context, I still believe that a strongly typed language would be a much better choice of a language, for exactly the same reason why I wouldn't recommend starting a project in C unless there is a strong preference (and even then Rust would probably be better still).
LLMs are not perfect, just like humans, so I would never vibe code in any other environment than one in which many/most logical errors are by definition impossible to compile.
Not sure if C is worse than python/js in that respect (I'd argue it is better for some and worse for other, regarding safety) but Java, Swift, C#, Go, Rust, etc. are great languages for vibe coding since you have the compiler giving you almost instant feedback on how well your vibe coding is going.
Claude Code is pretty good at Rust, but it works best if there's a pre-existing structure built by a human that it's operating within. Rust's error messages give rich context and are designed for humans, so it's able to figure out how to resolve its mistakes from them in ways that it simply would have to grind through in tests with trial and error in dynamic languages. And then when you do write unit tests to address logic bugs, it's able to leverage the rich context from the type system to write decent tests.
I wouldn't trust it to reliably write safe C though. It works in Rust because there's meaning embedded into the types that are checked by the compiler that gives it feedback when it makes mistakes. But you don't get that in C.
> why not do it in x86 assembly?
I was thinking that this week. We are quickly reaching a point where the quality of the code isn't as important as the test suite around it and reducing the number of tokens. High level languages are for humans to read/write, if most people aren't reading the code we should just skip this step.
It's an ugly future but it seems inevitable.
This is a point I keep advocating, sure the tools aren't yet there, but it is foolish to assume we don't ever get there, generating 3GL source code is only a transition step.
We already are having visual programming tools with AI agents, with various kinds of success, see iPaaS like Boomi, Workato and similar.
Recently I have had the opportunity to be part of projects using such kind of tools.
If there is any traditional coding it is a bunch of serverless endpoints exposed as MCP tools.
There’s a nugget of an idea in there, even if I disagree with most of it.
But code doesn’t only need to be understood for maintenance purposes: code is documentation for business processes. It’s a thing that needs to be understandable and explainable by humans anytime the business process is important.
LLMs can never / should never replace verifiability, liability, or value judgment.
Agree with your point. It's going to be super interesting to see whether languages become more lower or higher on the stack. My guess is unuseful: both.
We've not really seen what impact this will have just yet.
I would say, because time to review is the most important metric in vibe coding.
I prompt my agents to use proper OO-encapsulated idiomatic ruby paradigms. Your goal should be reduced cognitive load.
Even if you never write a line of code, you will still need to understand your problems to solve them.
"Vibe debugging" will get you stuck in loops of hallucinated solutions.
There's a straightforward answer to the "why not" question: because it will result in codebases with the same kind of memory unsafety and vulnerability as existing C code.
If an LLM is in fact capable of generating code free of memory safety errors, then it's certainly also capable of writing the Rust types that guarantee this and are checkable. We could go even further and have automated generation of proofs, either in C using tools similar to CompCert, or perhaps something like ATS2. The reason we don't do these at scale is that they're tedious and verbose, and that's presumably something AI can solve.
Similar points were also made in Martin Kleppmann's recent blog post [1].
[1]: https://martin.kleppmann.com/2025/12/08/ai-formal-verificati...
It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside. I mean C doesn't even have a builtin hashtable or vector, let alone pattern matching, traits and sum types. I get this is about AI and vibe coding, but we aren't at a point yet where zero human interaction is reasonable, so every code base should assume some level of hybrid human/AI involvement. Why people want so badly to start a new code base in C is beyond me (and yes, I've written a lot of C in my time, and I don't hate it, but it didn't age well in expressiveness).
> It is also equally odd to me that people want to cling so hard to C, when something like Rust (and other modern languages for that matter), have so much nicer eco systems, memory safety aside.
Simplicity? I learned Rust years ago (when it was still pre release), and when i now look at a lot of codebases, i can barely get a sense what is going on, with all the new stuff that got introduced. Its like looking at something familiar and different at the same time.
I do not feel the same when i see Go code, as so little has changed / got added to it. The biggest thing is probably generics and that is so rarely used.
For me, this is, what i think, appeals for C programmers. The fact that the language does not evolve and has been static.
If we compare this to C++, that has become a mess over time, and i know i am getting downvoted for this, Rust feels like its going way too much in the Rust++ route.
Like everybody and their dog wants something added, to make Rust do more things, but at the same moment, it feels like its repeating the C++ history. I have seen the same issue with other languages that started simple, and then becomes monsters of feature sets. D comes to mind.
So when you see the codebase between developers, the different styles because of the use of different feature sets, creates this disconnect and makes it harder for people to read other code. While with C, because of the language limits, your more often down a rather easier way to read the same code. If that makes sense?
Proofs of what? "This new feature should make the 18 to 21 year old demographic happy by aligning with popular cultural norms". This would be difficult to formalize as a proof.
Memory safety in particular, actually UB in general (got to watch out for integer overflows, among other things). But one could prove arbitrary properties, including lack of panics (would have been helpful for a recent Cloudflare outage), etc.
In order to prove lack of UB, you have to be able to reason about other things. For example, to safely call qsort, you have to prove that the comparison is a total order. That's not easy, especially if comparing larger and more complicated structures with pointers.
And of course, proving the lack of pointer aliasing in C is extremely difficult, even more so if pointer arithmetic is employed.
In this context it's proofs of properties about the program you're writing. A classic one is that any lossless compression algorithm should satisfy decompress(compress(x)) == x for any x.
Maybe I'm still in denial about the benefit of AI code design, but when I have an initial set of requirements for a program, the design begins. That is just a set of unanswered questions that I address with slowly growing code and documents. Then the final documents and code match the answers to all the questions that rose from the answers of previous questions. More importantly, I know how the code answers them and someone else can learn from the documentation. Since the invention of "velocity" I feel like much of the industry treats code and programmers like tissues. Wipe your nose and throw it away. Now we have AI-based automatic tissue dispensers and Weizenbaum's gripe about programmers creating work for themselves other than solving the requirements of the actual problems continues.
I wish everyone would read this paragraph:
> But this leads me to my second point, which I must make as clearly and forcefully as I can. Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that. Because when you start giving it little programming problems that you can’t be arsed to work out yourself (as I did), you discover (as I did) that it’s awfully good at those. And then one day you muse out loud (as I did) to an AI model something like, “I have an idea for a program…” And you are astounded. If you aren’t astounded, you either haven’t actually done it or you are at some stage of grief prior to acceptance. Perfect? Hardly. But then neither are human coders. The future? I think the questions answers itself.
This cannot be repeated enough. For all the AI hype, if you think AI isn't the most useful programming tool invented in the last 20 years, you're ignorant of the SOTA or deeply in denial.
As @tptacek recently wrote:
> All progress on LLMs could halt today, and LLMs would remain the 2nd most important thing to happen over the course of my career.
> It creates robust, complex systems that work
Do you have any examples of these? All the vibe coded systems I've seen so far were very far from robust.
2025 called and wants your argument back.†
https://news.ycombinator.com/item?id=45549434
† this is a joke; i feel it works on multiple levels
I'm not sure I get the joke, but the project reference is interesting - thanks!
If the headline is a question, the answer is "No".
The headline isn't a yes/no question though.
The answer is still "No".
Q: How many Prolog programmers does it take to change a lightbulb?
A: Yes.
Why not:
- The C-compiler. AI tools work better if their automated feedback loop via tools includes feedback on correctness, safety, etc. The C compiler is not great at that. It requires a lot of discipline from the programmer. There mostly isn't a compile time safety net.
- Macros add to this mess. C's macros are glorified string replacements.
- Automated tests are another tool that helps improving quality of vibe coded code. While you can of course write tests for C code, the test frameworks are a bit immature and it's hard to write testable code in C due to the lack of abstractions.
- Small mistakes can have catastrophic consequences (crashes, memory overflows)
- A lot of libraries (including the standard library) contain tools with very sharp edges.
- Manual memory management adds a lot of complexity to code bases and the need for more discipline.
- Weak/ambiguous semantics mean that it's harder to reason about code.
There are counter arguments to each of those things. Compilers have flags. There are static code analyzers. And with some discipline, it gets better. You could express that discipline in additional instructions for your agent. And of course people do test C code. There just are a lot of projects where none of that stuff is actively used. Vibe coding on those projects would probably be a lot harder than on a project that uses more structured languages and tools.
All these things make it harder to work with C code for humans; and for AIs. But not impossible of course. AI coding models are getting quite good at coding. Including coding in C.
But it makes it a poor default language for AI coding. The ideal vibe coding language for an AI would be simple, expressive, have great tools and compilers, fast feedback loops, etc. It means the AI has less work to do: shorter/faster feedback loops, less iterations and reasoning to do, less complex problems to solve, less ambiguity, entire categories of bugs that are avoided, etc. Same reasons as to why it is a poor choice for most human programmers to default to.
> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? ... surely Rust is even less ideal.
I don't get how the second follows from the first. One of the main complaints levelled against Rust is that it is not ergonomic for humans, specifically because it forces you to work to a set of restrictions that benefit the machine.
With an LLM coding agent that quickly produces volumes of somewhat-scattershot code, surely we're better off implementing incredibly onerous guardrails (that a human would never be willing to deal with)?
Agreed. Seems to me that for vibe coding you want 1) prevent as many run time errors as possible at compile time ( Rust )
2) use a language that is well supported by the community with countless examples ( Python )
AI generated code is filled with bugs. No language is as unforgiving about bugs as C is.
I'd rather low level vibe code with Nim.
Also vibe coding is a mistake, it will undoubtedly turn anything more elaborate than a simple script into a monstrosity. DO NOT TELL AI TO WRITE MORE THAN A FUNCTION OR PART OF A FUNCTION.
I did a goodly chunk of vibe coding over the summer and I found that the best language for me was Rust implementations with Python bindings for interface. A few reasons:
- Everything about rust enforcing correctness catches lots of bugs
- Using a high-level API means I can easily hand-check things in a repl
- In addition to tests, I required a full “demo notebook” with any PR — I should be able to read through it and confirm that all the functionality I wanted has actually been implemented
If the philosophy is (and it should be) “loc is free”, it’s worth thinking about how we can make LLMs produce more loc to give us additional comfort with correctness. Language choice is very much a way.
What people miss is that vibe coding actually is coding, except the code are your prompts and the LLM is the compiler.
The problem here is that human languages are terrible programming languages and LLMs are terrible compilers.
I don’t buy that LLMs won’t make off-by-one or memory safety errors, or that they won’t introduce undefined behavior. Not only can they not reason about such issues, but imagine how much buggy code they’re trained on!
The answer is type-safety. LLMs produce errors, as do humans. A language with carefully designed semantics and a well-implemented safety checker (or maybe even a proof assistant) will help express much more correct code.
I've had the most success running Claude iteratively with mypy and pytest. But it regularly wants to just delete the tests or get rid of static typing. A language like Haskell augmented with contracts over tests wouldn't allow that. (Except for diverging into a trivial ad-hoc dynamic solution, of course.)
this is why i like (and vibe code in!) nim. it's python-ish enough, strongly typed, and creates fast, compiled binaries.
Vibe coding benefits from hard limits relatively more than human coding. So in that sense, we should be coding in Rust (where raw performance is needed), Idris 2 or Haskell, and specifying with formal methods.
Perhaps the programming languages of the future will be designed with AI in mind: to properly put guardrails on it.
Could also be that the models just accelerate to the future so fast that they'll simply stop making mistakes. Then we'll be coding in Assembler, because why waste CPU time for anything else?
> Or hell, why not do it in x86 assembly?
I do vibe code in C; I'm not a C programmer and I certainly couldn't do a security audit of any serious C codebase, but I can read and understand a simple C program, and debug and refactor it (as long as it's still quite simple).
And it's super fun! Being able to compile a little C utility that lives in the Windows tray and has a menu, etc. is exhilarating.
But I couldn't do that in assembly; I would just stare at instructions and not understand anything. So, yes for C, no for assembly.
I think this is an odd idea. For a lot of reasons, but one is simply that higher level languages _tend_ to be terser, and context window matters for LLMs. Expressing more in less is valuable.
My experience of vibe coding is that the agent makes as many mistakes as me, it just types faster than I do. So using the most safe and typed language possible is still a good idea.
Also I want to understand the code as much as possible - sometimes the agent overcomplicates things and I can make suggestions to simplify. But if it's writing in a language only it can understand, that's going to be harder for me.
I think the author's point is that if you even try to understand the code, you haven't fully embraced vibe coding.
I’ve had a similar (likely non original) thought too that eventually LLMs could lead to something more akin to a compiler that would take human language instructions and go straight to a executable binary, possibly even with more traditional compiler analysis for performance and safety etc.
But then again LLMs in their current form are trained on mountains of human language so maybe having them output human readable code makes sense at least for now
I came to this article expecting an investigation on how C or assembly performs with an LLM, but it is just musings. The article claims the LLM is better at memory management than a human, which I find dubious, but even then it would not be a good argument in favor of C.
My experience with LLMs is that they are not good at tracking resources and perform much better with languages that reduce cognitive load for humans.
To answer the question literally, vs discuss "is vibe-coding good": The more tricky details in a language, the more I've seen LLM-first coding struggle. Rust, for instance, often leads to the model playing whack-a-mole with lifetime or borrow checker issues. It can often get to something that compiles and passes the tests, but the process gives me some pause in terms of "what am I not checking for that the whack-a-mole may have missed."
In C, without anything like a borrow checker or such, I'd be very worried about there being subtle pointer safety issues...
Now, some of that could be volumes of training data, etc, but Rust is widely discussed these days in the places these models are trained on, so I'm not certain it's a training problem vs a attention-to-detail across files problem. I.e., since LLMs are trained to mimic human language, programming languages that are most procedural-human-language-like (vs having other levels o fmeaning embedded in the syntax too) may exactly be those "LLM-friendly" languages.
It doesn't have problems with undefined behavior, memory safety, or especially thread safety?
That has not been my experience when using Codex, Composer, Claude, or ChatGPT.
Things have just gotten to the point over the last year that the undefined behavior, memory safety, and thread safety violations are subtler and not as blindingly obvious to the person auditing the code.
But I guess that's my problem, because I'm not fully vibing it out.
You just tell it the problem and it'll fix it. It's almost never been an issue for me in Zig.
Do you really think the user didn't try explaining the problem to the LLM? Do you not see how dismissive the comment you wrote is?
Why are some of you so resistant to admit that LLMs hallucinate? A normal response would be "Oh yeah, I have issues with that sometimes too, here's how I structure my prompts." Instead you act like you've never experienced this very common thing before, and it makes you sound like a shill.
What the author is describing is the logical conclusion of the Bitter Lesson applied to software development. To quote the essay: "We have to learn the bitter lesson that building in how we think we think does not work in the long run." The author of this article correctly points out that a lot of what goes into programming language design is a model of how humans think, and a lot of the abstractions are there to make it easier for humans to reason about code. That's not to say that abstraction isn't useful for machines, but I think the bitter lesson would say that it's better in the long run to let the machine figure out the best abstractions through search, and let humans think in the way they're used to thinking: in natural language.
Now personally I don't think this ultimate vibe-coding paradigm is just around the corner, but it does seem that it's the direction we're heading and I think this article does a good job of explaining why.
> let humans think in the way they're used to thinking: in natural language
Writing a program means stating unambiguously what you want, but natural language is ambiguous which is why legalese exists.
So you need to have an unambiguous source language for what's end up being executed by your machine (which is what programming languages are), otherwise you have no way of knowing if the machine does what you want it to do.
Of course you can use an LLM to translate natural language to unambiguous language, but at the end of the day you must read the generated language because that's the only way to dispel the fundamental ambiguity of the natural language.
I saw a webcomic ten years ago where a project manager discussing the future automation of programmer's jobs:
PM: “In the future, there will be no developers, just project manager. We will just give the machines very complete and precise specifications and it will make the software on its own. Without needing you”.
Dev: “You know how we call a "very complete and precise specification"? It's called code”.
Practical argument for vibe coding in C: the training corpus is probably much higher quality.
C code that survives in the wild tends to be written by experienced devs who care about correctness. The JS corpus includes mountains of tutorial code, Stack Overflow copypasta, and npm packages with 3 downloads. In my experience, generated C is noticeably better—and this might be why.
How well can LLMs reason about avoiding UB? This seems like one of those things where no matter how much code you look at, you can still easily get wrong (as humans frequently do).
Fair point on UB — LLMs absolutely do not reason about it (or anything else). They just reproduce the lowest-common-denominator patterns that happened to survive in the wild.
I’m not claiming the generated C is “safe” or even close. I am sure that in practice it still has plenty of time-bombs, but empirically, for the narrow WASM tasks I tried, the raw C suggestions were dramatically less wrong than the equivalent JavaScript ones — fewer obvious foot-guns, better idioms, etc.
So my original “noticeably better” was really about “fewer glaring mistakes per 100 lines” rather than “actually correct.” I still end up rewriting or heavily massaging almost everything, but it’s a better starting point than the JS ever was.
> Or hell, why not do it in x86 assembly?
It is not portable to computers other than x86. It is one of the reasons I do not use x86 assembly much even though I have a x86 computer; I prefer C. It is not about vibe coding.
> I suppose what I’m getting at, here, is that if vibe coding is the future of software development (and it is), then why bother with languages that were designed for people who are not vibe coding? Shouldn’t there be such a thing as a “vibe-oriented programming language?” VOP. You read it here first.
Someone told me that two companies (one of which is Google) were working on such a thing, although I do not know the details (or if they were correct about that), and I do not know whether or not it resembles what is described in that article.
I do not use LLM myself, although I have seen a few examples of it. I have not seen very many so the sample size is too small, but what I have seen (from simple example programs), the program works although it is not written very well.
Many of the “no” comments here are very focused on the current state. The author seems to be looking at a longer time horizon of computing paradigms, for example invoking ENIAC. On that scale I tend to agree. Vibe coding has only been around a year or two and look how big of an impact it already has. Imagine what another 10 years of progress will look like.
Re: love of programming - those who think an AI should do it all should consider whether they should outsource having sex as well.
porn
The vast majority of software models are trained on have little to no standards and contains all kinds of errors and omissions.
And these are systems that require a human in the loop to verify the output because you are ultimately responsible for it when it makes a mistake. And it will.
It’s not fun because it’s not fun being an appendage to a machine that doesn’t know or care that you exist. It will generate 1200 lines of code. You have to try and make sure it doesn’t contain the subtle kinds of errors that could cost you your job.
At least if you made those errors you could own them and learn from it. Instead you gain nothing when the machine makes an error except the ability to detect them over time.
I think if you don’t know C extremely well then there’s no point vibe coding it. If you don’t know anything about operating systems you’re not going to find the security bugs or know if the scheduler you chose does the the right thing. You won’t be able to tell the difference between good code and bad.
My gut reaction is, if AI was really good at vibe coding all the infra it could be nice, but getting C deployed and productized is the potential challenge. The "roads" we built for hyper scaling apps doesn't strike me as C friendly. And, even with the friendlier deployment strateies on next, python, etc, AI still slips up a lot.
Vibe coding is mostly for solo devs anyway. If you work with a team you need to carefully think out how everything pieces together, how it will be later understood by other devs, what the plan is a few yrs down the road.
AI just gives suggestions but you have to make all the hard choices and fix/simplify a lot of the output
There is a hidden hypothesis in this article that AI "does not struggle" with things like undefined behaviour, off by one errors and undefined behaviour.
Yes, it can consistently generate code that works and seems to be on top of it all due to a lot of training data. But wouldn't that use up more tokens and computational resources to produce than e.g. the same program in python?
If using more complex languages requires more resources from LLM, the same principles apply. One-off scripts are better in high level languages. Hot paths executed millions of times a second are better in lower level languages with high optimisation potential.
LLMs might slightly shift the correct choice towards lower languages. E.g. a small one-off script in C is much more viable with LLM's help. But the moment one needs to reuse it, it grows, and needs to be modified, one might regret not using higher level language.
I've vibe coded a few things in C now as experiments, but I haven't been brave enough to put any of them into production code yet. I don't trust myself to review them properly.
C extensions for SQLite: https://simonwillison.net/2024/Mar/23/building-c-extensions-...
This one is closest to something I might use because it's C compiled to WebAssembly, so the blast radius for any dumb bugs is strictly limited: https://github.com/simonw/research/blob/main/cmarkgfm-in-pyo...
> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? Why not have it just write C? Or hell, why not x86 assembly?
Or why not just produce a binary directly? It seems we've just invented a compiler.
Obviously right now the best language to use LLMs for, vibe coding or not, is whatever they are most familiar with, although not sure what this actually is! Java?
Going forwards, when LLMs / coding tools are able to learn new languages, then languages designed for machines vs humans certainly makes sense.
Languages designed for robust error detection and checking, etc. Prefer verbosity where it adds information rather than succintness. Static typing vs dynamic. Contractual specification of function input/output guarantees. Modular/localized design.
It's largely the same considerations that make a language good for large team, large code base projects, opposite end of the spectrum to scripting languages, except that if it's machine generated you can really go to town on adding as much verbosity is needed to tighten the specification and catch bugs at compile time vs runtime.
Great point, except for one huge insurmountable non-technical problem with Java that can be invoked in a single word: lawnmower.
“Do not fall into the trap of anthropomorphizing Larry Ellison. You need to think of Larry Ellison the way you think of a lawnmower. You don’t anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it’ll chop it off, the end. You don’t think ‘oh, the lawnmower hates me’ — lawnmower doesn’t give a shit about you, lawnmower can’t hate you. Don’t anthropomorphize the lawnmower. Don’t fall into that trap about Oracle.” -Bryan Cantrill
“I actually think that it does a dis-service to not go to Nazi allegory because if I don’t use Nazi allegory when referring to Oracle there’s some critical understanding that I have left on the table […] in fact as I have said before I emphatically believe that if you have to explain the Nazis to someone who had never heard of World War 2 but was an Oracle customer there’s a very good chance that you would explain the Nazis in Oracle allegory.” -Bryan Cantrill
https://www.youtube.com/watch?v=-zRN7XLCRhc
Let's please not turn over the future of AI and programming languages over to a lawnmower.
The main benefit of C is that it is especially readable by humans.
I think that’s what makes it so common in codebases that have long term maintenance stories.
(I say that because my personal project has me reading great loads of C written by diverse authors and I am surprised at how easy it is to figure out, compared to most other languages)
It sounds like his main gripe of vibe coding is it robs you of the satisfaction as a programmer in solving the problem. I don't disagree, but the preferences of programmers are not necessarily the main driving force here behind these changes. In many cases it's their boss and their boss doesn't really care.
It's one thing to program as a hobby or to do programming in an institutional environment free of economic pressures like academia (like this educator), it's another thing to exist as a programmer outside that.
My partner was telling me her company is now making all their software engineers use ChatGPT Codex. This isn't a company with a great software engineer culture, but it's probably representative of the median enterprise/non SV/non tech start employer than people realise.
Why should it be the case that LLMs are equally comfortable in x86 Assembly and Python? At least, it doesn't strike me as implausible that working in a human-readable programming language is a benefit for an LLM that is also trained on a bunch of natural language text alongside code.
It’s not a super useful line of inquiry to ask “why” LLMs are good at something. You might be able to come up with a good guess, but often the answers just aren’t knowable. Understanding the mechanics of how LLMs train and how they perform inference isn’t sufficient to explain their behavior a lot of the time.
Traditionally, I used Python for personal tools optimizing for quick coding and easy maintenance. These tools commonly feed UI elements like waybar, shell, and tmux, requiring frequent, fast calls.
My approach is evolving due to NixOS and home-manager with vibe coding to do the lifting. I increasing lean on vibe coding to handle simple details to safely write shell scripts (escaping strings, fml) and C/C++ apps. The complexity is minimized, allowing me to almost one-shot small utilities, and Nix handles long-term maintenance.
With NixOS, a simple C/C++ application can often replace a Python one. Nix manages reading the source, pulling dependencies, and effectively eliminating the overhead that used to favor scripting languages while marking marginal power savings during everyday use.
> If You’re Going to Vibe Code, Why Not Do It in C?
Or assembly, or binary
Yes, this is a completely valid take and it is the ultimate answer to why vibe coding, the way most people define vibe coding is a dead end.
The point is we want the LLM to generate code that is first and foremost readable by humans and structured in such a way that a human can take over control at any time.
If you think this is how LLM should generate code, congratulations we are already in agreement.
If you think programmers should not exist and that you will help your bottom line by reducing the number of programmers on your payroll or worse, completely eliminate programmers from your payroll by paying product managers who will never ever look at the code (which is required for vibe coding the way I understand it), then this question at the top is for you.
c is a small language thus more understandable and readable than others? e g. java,rust,c++ can get really complicated to read sometimes.
python though is very readable, not so much for typescript for me.
"If you're going to vibe code, why not do it in assembly?"
Many people I've seen have taken existing software and 'ported' it to more performant languages like C, Rust, etc.
LLMs are extremely efficient and good at translation.
The biggest question is maintainability and legibility. If you want it for your own proprietary software, this can (and probably is, generally) a good pattern if you can get the LLM to nail language specific challenges (e.g. memory allocation in C)
However, fewer people can write C code generally, and even fewer can use it to build things like UI's. So you're by definition moving the software away from a collaborative mechanism.
The abstraction layers were built for human maintenance. LLMs don't need that.
From what I have seen successful ~vibe-coders in my cirle are really bullish on type-safety and testing. Up to a point I have seen a guy porting his favourite property-based testing framework to TypeScript :D
So, vibecoding in C feels like playing with loaded gun.
It's so refreshing to see a proper website these days, no js, no cookie banners, just hypertext. Your part about still enjoying programming really resonated with me. I still get so much joy out of programming after 20 years of doing it, it's still just as exciting to learn new things, and I am definitely not running out of new things to learn.
I would absolutely love to teach programming to non-programmers. I have also been offered a job at the technical school where I graduated. But remembering how uninterested the vast majority of my classmates were back then discouraged me from even trying. I guess what I'd want is a teach a room full of people excited to learn about programming.
I like the idea of reimagining the whole stack so as to make AI more productive, but why stop at languages (as x86 asm is still a language)? Why not the operating system? Why not the hardware layer? Why not LLM optimized verilog, or an AI tuned HDL?
Probably because then it wouldn't be software anymore. That is because you will be required to do a physical process (print an integrated circuit) in order to use the functionality you created. It can definitely be done, but it takes it too far away from the idea the author expressed.
But I don't see a reason why the LLM shouldn't be writing binary CPU instructions directly. Or programming some FPGA directly. Why have the assembly language/compiler/linked in between? There is really no need.
We humans write some instructions in English. The LLM generates a working executable for us to use repeatedly in the future.
I also think it wouldn't be so hard to train such a model. We have plenty of executables with their source code in some other language available to us. We can annotate the original source code with a model that understands that language, get its descriptions in English, and train another model to use these descriptions for understanding the executable directly. With enough such samples we will be able to write executables by prompting.
> all the way to the borderlands of active anxiety—not quite understanding what Claude just wrote.
This is a big issue, personally. I write Python and bash these days and I love that we're not bottlenecked by IDE-based autocomplete anymore, especially for dynamic languages and a huge amount of fixing and incremental feature work can be done in minutes instead of days thanks to AI being able to spot patterns. Simultaneously I'm frustrated when these agents fail to deliver small changes and I have to jump in and change something I don't have a good mental model of or, worse still, something that's all Greek to me, like Javascript.
ive been vibe coding (i think it's vibe coding) in C for the past three weeks and it's been super fun. i was tasked with trying to improve our highly optimized hyper-graph partitioning algorithm. One of the fun things i like to do is feed the llm an academic paper, have it summarize the key pts, and then implement the algos that we (me and the llm) find interesting. This feels like i hit the fabled 10x productivity mark because it would have taken me at least a week (probably more) to digest a paper enough to implement it, and often I would give up, convincing myself it's not worth the time / effort. So 10x might even be a low ball.
I can feel ya ... Nothing more fun then vibe coding b-tree, ART, LSM, Double pointer b-tree, bw-tree, ... and so many other storage solutions relying on different indexes, compressions etc.
And having them fight it off between each other. To see where the issues are with each methode, what works better. Doing that without vibe coding the hell out of it, will take months of work, but with vibing and some cash, you do it in a few days.
Thinking about the programming language as a first requirement when vibe coding is probably not the smartest move. The programming language choice (beyond being fit for your purpose) is how prevalent it is in the training data for the model (more examples for what you want to achieve -> better results). When vibe coding the most important things are to know how to spec what you want to achieve and how you measure the results. The programming language is just a tool.
I think the author glosses over a core problem AI would need to overcome for his thoughts to become reality: training data.
We can't teach AI to code in languages that do not have human ergonomics because, as of now, all AI is based on human example.
No need for using assembler, LLMs should be writing machine bits directly into executables. It is also fairly simple to teach them how to do it. Provided we have some executable that was written in some human-readable computer language. We can read through the bits of the executable, and describe each portion using English, based on the description of what the original human-readable language is doing. This new model will only learn the English representation of chunks of bits and how they go together into an executable. After learning several billion such narrated executables it will be excellent at writing machine code.
I agree that coding is more fun than vibe coding, right up until you have a massive refactor that is super repetitive and no fun to author, but an LLM can do it in no time flat. Even if an IDE can help with the refactor, there are cases where they can't. And anyways, if you're working with a codebase you understand but are not super familiar with, then vibe coding is incredibly productive, though, well, you'll spend much more time reviewing what the LLM did, so maybe not quite that productive (unless you count on others to do your review, but that's not very nice, and it will show).
I've wondered what vibe codings impact is to language development, whereas C vs LISP had their tradeoffs when deciding what to use. If everything is vibecoded (not saying it will be) everything probably normalizes to javascript
That's what this discussion made me think of. To take it further -- if you were going to design a language expressly for AI-generated code, what might some of it's features be?
I think strong static typing probably? Which is, well, not javascript in fact! (And I have bucked the trend on this previously, liking ruby -- but I'm not sure I'd want AI-generated code without it?)
Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FAUST (for audio DSP)?
None of our existing programming languages were designed for quite the circumstance in which contemporary programming now finds itself; they all address an ergonomic situation in which there are humans and machines (not humans, machines, and LLMs).
It's possible, I suppose that the only PL that makes sense here is the one the LLMs "knows" best, but I sort of doubt that that makes sense over the long term. And I'm repeating myself, but really, it seems to me that a language that was written entirely for the ergonomic situation of human coders without any consideration of LLMs is not addressing the contemporary situation. This is not a precise analogy, but it seems to me a little like the difference between a language that was designed before vs after multicore -- or before vs after the internet.
The problem with creating a programming language for LLMs, goes back to, what are LLMs? They are trained on masses of human written code, that is written in human readable form.
So even if you make a better programming language for a LLM, it has nothing to train on. Unless we start to transcode human language code to the LLM code.
Are the vectors/tokens/whatever, not already LLM code at this point? Technically, LLMs not are doing what Haxe was doing (haxe.org) but in a more advanced form?
Even if we make a more LLM like programming code, in a sense, we are just making another code that needs to be translated into the tokens that consist in a LLM model, no?
Feels like we are starting to hit philosophical debates with that one lol
Unrelated - it looks like your blog's RSS feed isn't up to date. :-)
Thank you!
Lean 4 seems to be pretty AI-usable, and you get insane guarantees (but LLM do seem to make very heavy use of "sorry")
Idk why the author thinks that C would be a better language than Rust for vibe coding. Intuitively, I would have thought that the more formal constraints the system imposes, the better for vibe coding (since the more powerful static checks make it harder to write incorrect code).
Of course in practice I think the author is actually correct - LLM's struggle more than humans with sophisticated formal constraints and less than humans with remembering to write a bunch of boilerplate. But I think it's a pretty counterintuitive result and I'd love to have seen more discussion of it.
I want to do my vibe coding in a dependently typed language, so that at least I can tell what the inputs and outputs are. I say Idris is the future!
Or... I want to only write the tests. The implementation is... an implementation detail!
> It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong.
Then show us this robust, complex code that was produced by vibe coding and let us judge for ourselves.
On fun/joy in the era of agency - https://bikeshedding.substack.com/p/the-agency-continuum
If the LLMs of today can even produce a sizable C program that compiles, doesn't leak memory, doesn't exhibit UB, doesn't have any obvious vulnerabilities, and is correct, I would be astounded.
If you want to get to a higher level compiler, prompt fondling will not suffice; you need to master formal specification. Then machine learning algorithms can do the program synthesis to implement the spec. But just talking out your vague software requirements with a chatbot is not analogous to programming.
Also, like others said, even once you have your formal spec, C is a particularly bad choice (unless you want to specify quite a bit more). You want the program implemented in a language with as many safety constraints on it as possible, not one where you have to mentally track memory.
Do it in Ada, SPARK, Zig, Rust, Pascal, Crystal, etc.
Unless it's an existing project where migration is too costly, C is just entering a time wasting pact along with a lot of other people that like suffering for free.
You are missing the whole point of the article.
Great post. Love the writing style that is at once both casual and erudite.
I must take issue with the central point however: the machines of LLMs are very different than the machines of CPUs. While it is true that Claude writes fewer memory errors than even expert C programmers (I’ve had to fully accept this only this week), the LLM is still subject to mistakes that the compiler will catch. And I dare say the category of error coding agents commit are eerily similar to those of human developers.
I have been coding as an autodidact for 20 years now. In the past months, I have been vibe coding a lot, with multiple AIs at the same time. I have achieved to code a full webapp (React and Next.js for the front, RestJS for the back) in five days. Refactoring, adding features and writing the right tests for everything to work has been procuring me with the same problem solving and endorphin kicks as usual programming. Just don't vibe code something which you could do yourself, maybe that is the issue of the author.
Either you contradicted your own advice in a 5 sentence comment, or you suggested that you couldn't code a web app despite 20 years of experience. Either is pretty damning.
Do you have a link to the webapp you produced or its source code ?
edit: it was a real request, I was being interested, not some mockery or idk
I understand, not yet online, but it will be deployed in a few months for educational purposes (i teach).
Never used C much, but I would assume it is more LOC than a newer language with more features. Less code is a fairly important feature for LLMs with relatively limited context windows.
I asked ChatGPT what traits should vibe-oriented programming language have and oh boy did it deliver.
(https://chatgpt.com/share/693891af-d608-8002-8b9b-91e984bb13...)
* boring and straightforward syntax and file structure: no syntax sugar, aliases, formatting freedom that humans cherish, but machines are getting confused, no context-specific syntax.
* explicitness: no hidden global state, shortcuts and UB
* basic static types and constraints
* tests optimized for machine evaluation
etc.
I wish I could convey my thoughts that well!
On the topic: I feel like we still need at least a few more innovations in the space before we can rely on them to work in areas where we as humans still have trouble (that pesky training data!). Even when providing documentation, I still find LLMs to often have trouble creating code in newer versions of libraries.
My biggest fear with LLMs is that it will steer a lot of development into a more homogenous space over time (even just with the types and versions of libraries it chooses when vibing).
I started reading this out of curiosity, thinking: that's such a far fetched thought, I'm curious about what the author wants to say. I think he makes a good point about execution vs. readability, and the actual need for the latter, drawing analogies to earlier abstractions. I'm still skeptical about low level language generation (tbh, letting an LLM handle memory at this point of maturity feels scary to me.. leaks etc)... But overall very interesting writeup and many points that I agree with.
I believe they are arguing against vibe-coding categorically by pointing out that high-level programming languages are for human expression. It's a reductio ad absurdum against the logical conclusion that follows from vibe coding as a premise. If vibe coding is like a using a compiler, why not just translate English directly to machine code or lower level languages?
Looks like a bad fit to me, it's very freeform and genAI does really badly with consistency and coherence
C is actually pretty good, if you can manage to architect your project cohesively
I'm trying to build a extremely simple exercise timer app for multiple platforms, and using Gemini and Junie, I Evaluated Rust+Tauri, Cpp+GT, SWIFT+SWIFTUI, Kotlin+MP, and Dart/Flutter, even though I started hating flutter, when started working with Jetpack Compose for KMP, I have to recognize that flutter is the best option for MP. Maturity, Ecosystem, UI+Backend in a single codebase, etc.
My concept was to build HLL to C/C++ (or Rust) translators using mostly, non-AI tech. Then, use AI's with whatever language they were really good at. Then, transpile it.
Alternatively, use a language like ZL that embeds C/C++ in a macro-supporting, high-level language (eg Scheme). Encode higher level concepts in it with generation of human-readable, low-level code. F* did this. Now, you get C with higher-level features we can train AI's on
If you're vibe coding, I highly recommend TDD. It makes it very easy for a coding agent to iterate on it. You gotta bonk it sometimes when it tries to delete a problematic test etc, but hallucinating a test suite along with your app really helps a lot. (I've been vibe coding a scripting language/compiler for a video game project I'm working on in this way, and it's been fascinating and mostly great.)
Do you write the test yourself or get the agent to do it?
No OP but I also guide LLMs with TDD and it's a mixture of LLMs write tests for happy paths and I write tests for edge cases.
Also when I use LLM to fix a bug, I tell it to write a test to prevent regression of the bug at the end of the session, after the bug is fixed.
> Also when I use LLM to fix a bug, I tell it to write a test to prevent regression of the bug at the end of the session, after the bug is fixed.
Oh that’s clever. Thanks
I try to get the agent to create a failing test first, so we can verify its fix is real.
I get the agent to do it generally. (I realize this seems incestuous, but its fairly easy to validate the tests are sensible as you add features, because the biggest risk is regressions as the AI does something dumb later.)
If you're going to vibe code, with an intent to review the output so that the ultimate product is actually useful and does what was intended, you should do it in whatever language(s) you're knowledgeable in so you can actually competently review that output.
If you don't give a damn about integrity though, then may as well get funky with it. Hell, go hard: Do it in brainfuck and just let it rip.
"If you ask PMs about backend requirements, they will dodge you, and if you ask front-end or web developers, they are waiting for you to provide them the API. The hardest part is understanding the requirements. It's not because of illiteracy. It's because software development is a lot more than coding and requires critical thinking to discover the requirements."
IF this is true, you have bad PMs.
The premise: If people drive drunk already, why not give them even faster cars with less road stability and worse brakes?
I sincerely hope the author is joking.
"I also think it takes a lot of the fun out of the whole thing."
Agreed. It's like replacing a complex and fulfilling journey with drugs.
>Is C the ideal language for vibe coding? I think I could mount an argument for why it is not, but surely Rust is even less ideal
I was really hoping you were going to make this argument, based upon the title of the piece! Still a good read, but if you have the inclination I hope you loop back around to weighing the pros and cons of vibe coding in different languages
LLMs are good at in-distribution programming, so inventing a new language just for them probably won’t work much better than languages they were already trained on.
If you could invent a language that is somehow tailored for vibe coding _and then_ produce a sufficient high quality corpus of it to train the AI on them, that would be something.
None of these articles explain what "vibecoding" is, and on general principles I refuse to look it up.
I have been developing a game with this process, specifically for portability, reach and distribution across multiple game engines and platforms.
I find CUX to be very intuitive for prototyping. But my game is Language and HCI at heart, logic that allows the development process to go smoothly. It is certainly not for everyone or every project.
> Why vibe code with a language that has human convenience and ergonomics in view?
Because you would not be able to audit the code if you don't (you'll be terribly slow to read and understand the inner flows correctly and that's if these aren't so bad that would do you some brain damage).
Dang, AI is pushing us all to become managers.
If you're going to vibe code on legacy code, use the languages used there. If you're going to vibe code something new, then I recommend Rust. There are few cases where I would vibe code something brand new in C, mainly when building a library I'm going to need to use from other C programs.
Why not do it in English? I have a "program" that exists entirely as the history of an AI chatbot session. To "run the program" I load the history and a file into the message context and say "Now do this file." It kind of reminds me of a Smalltalk VM in a weird way.
Along the same lines, I am rewriting a React Native app into native Swift and Kotlin versions. I haven’t written any of the native code directly - it’s all vibed. It’s not C but there’s a lot of upside in letting Claude Code compile my wishes into native languages and skip the RN layer.
In loads of projects you can't just pick a language and it's fine.
If I'm making a C#/WPF app, I can't just decide to make part of it C.
I get it's just a generalised criticism of vibe coding, but "why not use a harder language then" doesn't seem to make any sense.
Code in whichever language suits your problem, whether you're vibing or not, the trade-offs are mostly the same. Yes, I could use C if I cared more about runtime than development time; it will take me longer to code review AI generated C code.
Vibe coding produces great one shot proofs of concept that fit inside its context window.
It produces hot garbage when it needs to bring together two tokens from the far ends of a large code base together.
This comes as no surprise to anyone who understands what the attention mechanism actually is, and as a great surprise to everyone who thinks transformers are AI magic.
> I also think it takes a lot of the fun out of the whole thing.
I used to say that implementation does not matter, tests should be your main focus. Now I treat every bit of code I wrote with my bare hands like a candy, agents have sucked the joy out of building things
If you’re going to vibe code, why not do it in Brainfuck?
Claude hilariously refused to rewrite my rails codebase in Brainfuck…not that I really expected it to. But it went on a hilarious tirade about how doing so was a horrible idea and I would probably fired if I did.
This is one area I do use LLMs for, write small utils and test code, and very often in languages I very seldom even touch, such as C# and Rust. This to me seems to be the core idea of a tool that is awesome at translating!
Context limit and build time are a couple of reasons. There is C++ code at work I told it to rewrite in Python just to make it easier to vibecode (or regular code) after. Granted, it had no good reason to be in C++ in the first place.
Its very highly probable that AI is going to generate slop at some point so if you dont know much about how it works, you are doomed. Once it starts going towards slop it just keeps getting deeper until you reach a point where every simple problem feels like you need a new repo
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong. You can then tell yourself (as I did) that it’s good as a kind of alternative search engine for coding problems, but not much else. You are also wrong about that. Because when you start giving it little programming problems that you can’t be arsed to work out yourself (as I did), you discover (as I did) that it’s awfully good at those. And then one day you muse out loud (as I did) to an AI model something like, “I have an idea for a program…” And you are astounded. If you aren’t astounded, you either haven’t actually done it or you are at some stage of grief prior to acceptance. Perfect? Hardly. But then neither are human coders. The future? I think the questions answers itself.
Tons of people make the above claim and tons of other people make the exact opposite claim that it’s just a search engine and it can’t actually code. I’m utterly shocked at how two people can look at ground truth reality and derive two different factual conclusions. Make no doubt one of these two people is utterly wrong.
The only thing I can conclude is many people are either in denial or outdated. A year ago none of what this man said was true.
Because, the programming languages best matched to a (natural human language-based) declarative programming paradigm (e.g., vibe coding) would be declarative programming languages, not imperative programming languages.
Honestly, I think this is a valid viewpoint, but perhaps C is too low level. The bottleneck in generating code with LLMs tends to happen at the validation step. Using a language that has a lot of hard to validate footguns isn't great.
While I am not a big fan of Rust, the philosophy is likely useful here. Perhaps something like it, with a lot of technical validation pushed to the compiler, could actually be really useful here.
Getting rid of the garbage collector with no major increase in human cognitive load might actually be a big win.
It is interesting though that if it's all the same anyway - why not write formally proved software. Or write the same spec in three different languages to cross check correctness.
I do vibe code in C. From what I understand, Ruby is written entirely in C. It's a wonderful high-level language experience on top of such a storied runtime as C (truly!).
I made the same comment last week upon learning of a redis clone entirely vibe coded in IIRC ~70k lines of Rust. Why Rust? Why does a computer need a memory safe language?
great read so as i have understood to why ai is generally good at web dev and not so good at other low level stuff is "more data to train better the model". So model trained on the whole web > a model particular trained on a single language (in this case c). and i also think you can't go lower than C in this case, since below that the code is architecture specific and so even less data to train on. would love what others think
I guess vibe coding is fun as a meme, but it hides the power of (what someone else on HN) called language user interfaces (LUIs).
The author's point is correct IMO. If you have direct mappings between assembly and natural language, there's no functional need for these intermediate abstractions to act as pseudo-LUIs. If you could implement it, you would just need two layers above assembly: an LLM OS [1], and a LUI-GUI combo.
However, I think there's a non-functional, quality need for intermediate abstractions - particularly to make the mappings auditable, maintainable [2], understandable, etc. For most mappings, there won't be a 1:1 representation between a word and an assembly string.
It's already difficult for software devs to balance technical constraints and possibilities with vague user requirements. I wonder how an LLM OS would handle this, and why we would trust that its mappings are correct without wanting to dig deeper.
[1] Coincidentally, just like "vibe coding", this term was apparently also coined by Andrej Karpathy.
[2] For example, good luck trying to version control vectors.
Why have types? AI can infer everything. The ultimate ai language is as terse as possible to keep token count down but can still be understood by a human
At that point, why not develop a custom language or IL that is specifically designed for LLM use and which compiles to good native code?
I propose WASM, or an updated version of it
Because LLMs will have no concept of that IL. It only have a model for what it has seen.
Oh? I've had great luck with LLMs and homemade ILs. It has become my favourite trick to get LLMs to do complex things without overly complicating my side of the equation (i.e. parsing, sandboxing, etc. that is much harder to deal with if you have it hand you the code of a general purpose language meant for humans to read).
There is probably some point where you can go so wild and crazy with ideas never seen before that it starts to break down, but if it remains within the realm of what the LLM can deal with in most common languages, my experience says it is able to pick up and apply the same ideas in the IL quite well.
100%
People are still confusing AI putting together scraps of text it has seen that correlates with its understanding of the input, with the idea that AI understands causation, and provides actual answers.
And people are also still clearly confusing "isn't human or conscious" with "can't possibly create new logical thoughts or come to new logical conclusions i.e. do intellectual labor" when there is a plethora of evidence at this point that the latter is, in fact, the truth
I'm not sure if you mean that as a dig, or not, but if you are referring to me then I have these data points to discuss.
1. I have encountered a problem where AI will suggest 4 different "solutions" and when I point out a problem with one, it cycles on to the next, and stays in that loop, repeating over and over that set of 4, with no recollection of the previous refutation of the soltuion (this is a mix of context retention, and the fact that the solution selection is limited to that which has already been fully explored on the web - I had a 5th idea in mind which the AI failed to understand, but worked well)
2. Yesterday I was discussing with AI the fact that I had three options for action, and it misunderstood that as 4 actions, a trivial arithmetic failure.
This demonstrates (clearly) that the AI didn't "understand" the points discussed, and was instead staying with the correlation of text with other text.
I really like where AI is at the moment and use it a lot - it's very helpful for debugging, for example, but as every vibe coder out there will attest, AI fails hard at standalone coding, and I submit that this is a symptom of its inability to understand what its doing.
It's still correlation is not causation, and it demonstrates why correlation is so attractive, you can get quite far knowing that there is a correlation between ice cream sales and shark attacks, but it takes work to understand that there is no causative link (FTR I suspect that it's because ice cream sales go up in hot weather, more people are in the ocean during those hot weather periods, therefore there's more opportunity for people to interact with sharks)
Edit: Note how I use the word "suspect" when I talk about the cause of the correlation - it's VERY tempting to say that the weather is the cause, but that's still a correlation, and the fact is, as humans have discovered, actual research is required to verify whether that is, indeed, the cause, or not - something AI might miss.
Another data point has just arisen - I have a function (in Go) that accepts an unpacked slice of `interface{}` (some people will now call that an unpacked slice of `any`)
I was calling that function with an unpacked slice of string - eg
```Go
```The AI I was using (Claude for the purposes of this discussion) incorrectly told me that I first needed to convert the slice of string to a slice of interface before calling the function
It argued with me when I said that I didn't and demanded I TIAS to prove its point, and report the compile time errors
Of course, I did, and there were no errors
The issue was that the AI (Claude) did not understand that `interface{}` or `any` means that any type can be used there.
Claude is doing a fantastic job, but this is an example of it not actually understanding what's happening.
I don't contest these examples, but that's exactly why I call what it does "thunking" (think: "clumsy thinking") instead of "thinking" (in order to get around the epistemological/philosophical problems of "is it conscious?" or "does it understand?"), and since it doesn't "understand," it "undersits", and it doesn't "comprehend", it "prehends" or "ingests".
It is trained on WASM btw, but if we invented one specific for it, it could easily be trained up on it or refined with it. I've already had some success just handing it a language guide and it runs with it.
The biggest reason I think is, the code still needs review by humans who might struggle with older languages and more so with assembly language.
"You can do everything in C"
Including shooting yourself in the foot.
/Rust
Cost, right? C uses more tokens by declaring the types. Better to go to a higher level abstraction to use as few tokens as possible to save on $$.
In which case, should we aim for J or APL? :)
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong.
I spend all day in Claude Code, and use Codex as a second-line code reviewer.
They do not create robust systems. They’ve been a huge productivity boost for me in certain areas, but as soon as you stop making sure you understand every line it’s writing, or give it a free reign where you’re not auto-approving everything, the absolute madness sets in.
And then you have to unpick it when it’s trying to read the source of npm because it’s decided that’s where the error in your TypeScript project must lie, and if you weren’t on top of the whole thing from the start, this will be very difficult.
Don’t vibe-code in C unless you are a very strong C developer who can reliably catch subtle bugs in other people’s code. These things have no common sense.
> Or hell, why not do it in x86 assembly?
I suspect the assembly would not be as highly optimized as what a modern C compiler would output.
> Vibe coding actually works. It creates robust, complex systems that work. You can tell yourself (as I did) that it can’t possibly do that, but you are wrong.
This is such a bad take. I'm convinced that engineers simply don't understand what the job is. The point was never "does it output code that works", the point is "can it build the right thing in a way that is maintainable and understandable". If you need an LLM to understand the output then you have failed to engineer software.
If all you're doing is spitting out PoCs and pure greenfield development then I'm sure it looks very impressive, as the early language models did when it looked like they were capable of holding a conversation. But 99% of software engineering is not that kind of work.
If vibe coding is the future as the author suggests we are in for a lot more and a lot longer outages
This author, like many others on this site, seem to imply that AI generates "good" code, but it absolutely does not---unless he's running some million dollar subscription model I'm unaware of. I've tested every AI using simple Javascript programs and they all produce erroneous spaghetti slop. I did discover that Claude produces sufficiently decent Haskell code. The point is that the iterative process requires you know the language because you're going to need to amend the code. Therefore vibe in the language you know. Anyone that suggests that AI can produce a solid application on its own is a fraud.
> I did discover that Claude produces sufficiently decent Haskell code.
Clojure generation is also very solid. Gemini Pro 2.5/3 is fantastic at it.
A part of me wonders if that is because these languages primarily have senior devs writing code, so the entire training set is "good" code.
The Erlang space vs the Elixir space (can't speak for agent based code generation here) would seem to give credence to this theory.
When I would explore Elixir forums with much larger communities there'd be myriad base level questions with code blocks written as if Elixir and Ruby were interchangable cause the syntax looks similar and thus missing out on many of the benefits of OTP.
But when you'd go to the Erlang community to ask a question, half the time the author of the book or library was one of the like... 20 people online at any given moment, and they'd respond directly. The quality of the discussions was of course much deeper and substantial much more consistently.
I have not tried to generate Elixir vs Erlang code but maybe it'd be a neat experiment to see if the quality seems better with Erlang
You, like many others, seem to imply that humans write "good" code, but they absolutely do not--unless they are running some million dollar team with checks and cross checks and years of evolving the code over failures. I've tested every junior developer using simple Javascript leetcode quizes and they all produce erroneous spaghetti slop.
The difference is, we forgive humans for needing iteration. We expect them to get it wrong first, improve with feedback, and learn through debugging. But when AI writes imperfect code, you declare the entire approach fraudulent?
We shouldn't care about flawless one-shot generations. The value is in collapsing the time between idea and execution. If a model can give you a working draft in 3 seconds - even if it's 80% right - that's already a 10x shift in how we build software.
Don't confuse the present with the limit. Eventually, in not that many years, you'll vibe in English, and your AI co-dev will do the rest.
Fascinating.
I would appreciate a post with examples, not just prose. It helps to put things in a more grounded reality.
Why you hate on prose? This article has been a joy to read, unlike a lot of the other slop on the internet.
I love prose.
I think this is the future. We'll probably end up with some variant of Perl (joking - or am I?)
Since it wasn’t covered in TFA:
for all the same reasons I wouldn’t have done it in C a decade ago!
Plus, now: credit limits!
While its thought provoking no one can claim to know the future with absolute certainty.
Vibe Coding is just a stepping stone to No Coding.
No one (other than computer people) wants computers and software, they want results.
This generation of AI will be used to bootstrap the next generation of AI.
Programmers getting excited about vibe coding is like candlemakers getting excited about installing electric lights in their shops, so they can make more candles!
Or a stepping stone to starting a lighting company. The nature of programming changes when implementation can be automated. That still leaves higher level concerns like design and architecture.
Many programmers became programmers because they love technology and vibe coding is about the coolest technology we've seen in a long time.
[dead]
I also don't _love_ vibe coding and do it just for exploration/recreation, but I also have long thought an LLM trained and tuned specifically for a language that is best for LLMs might be ideal.
Currently, using Claude to vibe code Rust is _much_ more hit-or-miss than using it for Python... so Python has become the lingua franca or IR I use with it.
Often I'll ask Claude to implement something in Python, validate and correct the implementation, and in a separate session ask it to translate it from Python to Rust (with my requirements). It often helps.
Claude is particularly bad at hallucinating the APIs of Crates, something it does a lot less for python.
Forward declaration is the only reason why I moved away from C, so much time wasted..
When building cli and infrastructure tools and using AI my goto is go. Pardon the pun.
Because the code is full of undefined behaviour or broken on so many levels
So in a way we do TDD and let the vibe machine code the system against the tests :)
We need a new language designed specifically for Vibe coding.
But I have been vibe coding in C. Created a parser/compiler for a subset of the C programming language that compiles to microcode for a novel computing architecture. Could I have done this on my own? Sure, but if I did I would've probably have done it in OCaml. And it would've taken me a lot longer to get it to the point where it is now. I think the advantage of vibe coding this (at least for me) is that I would have a hard time getting started due to procrastination - and I'd have a hard time keeping interested if there wasn't something working (yeah, maybe I'm a little ADHD, but aren't we all at this point?). Vibe coding it got me to something that was working pretty well in a surprisingly short amount of time which tended to make me more engaged without losing interest and attention. I didn't have to get caught up in remembering the intricacies of creating a makefile to build the code, for example. That's one of many places where I can get bogged down.
Does anybody else feel that vibe coding only works in Python JavaScript, and maybe Go? It seems like once you get more esoteric than that everything goes out the window. Zig code is laughable. I can't get LLMs to write a single cogent function in OCAML, things break catastrophically at 10 LOC. I haven't seen anybody else describe this experience.
Yeah it struggles with long tail languages. Zig in particular since even within the small training set there have been many versions with breaking changes
Ah yes just what vibe coding needs, further weakening human oversight
> Vibe coding actually works. It creates robust, complex systems that work.
No, it absolutely doesn't. We've seen so much vibe coded slop that it's very clear that vibe coding produces a hot mess which no self respecting person would call acceptable. No idea how you can say this as it isn't remotely true.
The author doesn't appear to ship commercially-viable software and unfortunately it shows. Those of us who do are amused by the essay.
The two recent IT catastrophes [0] from Alaska Airlines will continue elsewhere.
[0] https://www.seattletimes.com/business/alaska-airlines/alaska...
> Alaska hired the consulting firm Accenture to look for ways to strengthen its system
Now they have two problems....
Because I can’t debug it and can’t understand it!
Why not do it in Lisp? At least, it is cool.
> Or hell, why not do it in x86 assembly?
Or greater hell, why not binary?
If we ignore human readability (as the author suggests), the answer is context. The token count explodes as you fall down the abstraction rabbit hole. Context consumption means worse reasoning.
In turn, this means expressiveness matters to LLMs just as much as it matters to us. A functional map reduce can be far simpler to write and edit than an imperative loop. Type safety and borrow checking free an LLM from having to reason about types and race conditions. Interpreted languages allow an LLM to do rapid exploration and iteration. Good luck with live reloading a GUI in C.
And if you were to force the LLM to do all that in C, at some point it might decide to write its own language.
The author makes 2 fundamental errors in reasoning. The first is saying that the language model can program, it can't, it can generate code, maybe researchers at top labs can get it to create some trivial programs but I digress.
The second and more important point is that what makes coding simpler for humans is the ability of the language to facilitate communication so you don't have to translate, now LLMs are good at translation, but it's still work. Imagine you have an implementation of a program and you want to see what it does, for any non-trival program you must scan millions of tokens, are current LLMs even physcially capable of attending to that? nonono we need names.
Besides how can you even vibecode if you aren't (just) using names.
> why not do it in C?
A legitimate point, there are lots of performance and fine grain changes you can make, and it's a simple, common language many people use. Perhaps we could realize some of these benefits from a simple, fast language.
> Or hell, why not do it in x86 assembly?
A terrible take imo. This would be impossible to debug and it's complex enough you likely won't see any performance improvements from writing in assembly. It's also not portable, meaning you'd have to rewrite it for every OS you want to compile on.
I think there's an argument that if machines are writing code, they should write for a machine optimized language. But even using this logic I don't want to spend a bunch of time and money writing multiple architectures, or debugging assembly when things go wrong.
If the boosters are correct about the trajectory of llm performance, these objections do not hold.
Debugging machine code is only bad because of poor tooling. Surely if vibe coding to machine code works we should be able to vibe code better debuggers. Portability is a non issue because the llm would have full semantic knowledge of the problem and would generate optimal, or at least nearly optimal, machine code for any known machine. This would be better, faster and cheaper than having the llm target an intermediate language, like c or rust. Moreover, they would have the ability to self-debug and fix their own bugs with minimal to no human intervention.
I don't think there is widespread understanding of how bloated and inefficient most real world compilers (and build systems) are, burning huge amounts of unnecessary energy to translate high level code, written by humans who have their own energy requirements, to machine code. It seems highly plausible to me that better llms could generate better machine code for less total energy expenditure (and in theory cost) than the human + compiler pair.
Of course I do not believe that any of the existing models are capable of doing this today, but I do not have enough expertise to make any claims for or against the possibility that the models can reach this level.
Eh. Vibe Coding is best when your “writing code to eyeballing results” is the smallest. It works well when you can “test” that your code works with purely looking at the result and clicking around.
For this it’s the web deployment target and fast compile times rather than the language itself that is useful.
Routinely I am sent code that works, but obviously nobody has looked at. Because they don’t even actually know what the code does.
For prototyping this is quite great. I think it’s the biggest competitor to tools like figma, because writing actually functional program with access to real APIs beats mocks. Now, how often will these end up in production and blow everything up…
> Why vibe code with a language that has human convenience and ergonomics in view?
Recently I've been preparing a series that teaches how to use AI to assist with coding, and in preparation for that there's this thing I've coded several times in several different languages. In the process of that, I've observed something that's frankly bizarre: I get a 100% different experience doing it in Python vs C#. In C#, the agent gets tripped up in doing all kinds of infrastructure and overengineering blind alleys. But it doesn't do that when I use Python, Go, or Elixir.
My theory is that there are certain habits and patterns that the agents engage with that are influenced by the ecosystem, and the code that it typically reads in those languages. This can have a big impact on whether you're achieving your goals with the activity, either positive or negative.
This kind of meets with my experience - AI tends to follow specific patterns for each language, earlier this year I was finding that AI was presenting me with 4 different approaches to a problem, none of them were working so it would cycle through each of the four approaches.
I lost a day chasing my tail cycling through those 4 approaches, but the experience was worthwhile (IMO) because I had beeen becoming lazy and relying on AI too much, after that I switched to a better style of using AI to help me find those approaches, and as a sounding board for my ideas, whilst staying in control of the actual code.
(Oh, I should also mention that AI's conviction/confidence did cause me to believe it knew what it was talking about when I should have backed myself, but, again, experience is what you get after you needed it :)
filthy vibe coder here
I'm planning to, why bother with react when I can jump straight into WASM?
Because the LLM has presumably been trained on more React than WASM, and will do a better job of it.
ya filthy animal!
ok...then why not just vibe code it in js and then translate it to C with ai
I expect this has been said before, but why not do it in whatever language you think has been written about the most, with the greatest amount of referenceable data and examples. Which probably isn't assembly, and probably not C either.
Which will probably store up a problem for the future, with an outsized amount of programs written in languages that were popular on SO when models started learning...
if i write in sbcl am i vibe coding in c! high five!
If you're going to write code, why not do it in Rust instead of C?
Because I can do it in Rust that is much closer to the domains I work on?
> Wouldn’t a language designed for vibe coding naturally dispense with much of what is convenient and ergonomic for humans in favor of what is convenient and ergonomic for machines? Why not have it just write C? Or hell, why not x86 assembly?
In the game we're building we generate, compile and run code (C#) in real time to let the player "train and command" its monster in creative ways. So, I've thought about this.
You need both a popular language and one that has a ton of built-in verifying tools.
The author correctly highlights the former, but dismisses the latter as being targeted to humans. I think it is even more important for LLMs!
These coding agents are excellent at generating plausible solutions, but they have no guarantees whatsoever. So you need to pair them with a verifying system. This can be unit tests, integration tests, static / type checks, formal methods, etc. The point is that if you don't have these "verifier" systems you are creating an open loop and your code will quickly devolve to nonsense [0].
In my view, the best existing languages for vibe coding are: - Rust: reasonably popular, very powerful and strict type system, excellent compiler error messages. If it compiles you can be confident that a whole class of errors won't exist in your program. Best for "serious" programs, but probably requires more back and forths with the coding agent. - TypeScript: extremely popular, powerful type system, ubiquitous. Best for rapid iteration. - Luau: acceptably popular, but typed and embeddable. Best as a real-time scripting sandbox for LLMs (like our use case).
I think there is space for a "Vibe-Oriented Programming" language (VOP as the author says), but I think it will require the dust to settle a bit on the LLM capabilities to understand how much can we sacrifice from the language's lack of popularity (since its new!) and the verifiability that we should endow it with. My bet is that something like AssemblyScript would be the way to go, ie, something very, very similar to an existing, typed popular language (TS) but with extra features that serve the VOP needs.
Another aspect to consider besides verifiability is being able to incrementally analyze code. For structured outputs, we can generate guaranteed structures thanks to grammar-based sampling. There are papers studying how to use LSPs to guide LLM outputs at the token level [1] . We can imagine analyzers that also provide context as needed based on what the LLM is doing, for example there was this recent project that could trace all upstream and downstream information flow in a program thanks to Rust's ownership features [2].
Finally, the importance of a LLM-coding friendly sandbox will only increase: we already are seeing Anthropic move towards using LLMs to generate script as a way to make tool calls rather than calling tools directly. And we know that verifiable outputs are easier to hillclimb. So coding will get increasingly better and probably mediate everything these agents do. I think this is why Anthropic bought Bun.
[0] very much in the spirit of the LLM-Modulo framework: https://arxiv.org/pdf/2402.01817 [1] https://proceedings.neurips.cc/paper_files/paper/2023/file/6... [2] https://cel.cs.brown.edu/paper/modular-information-flow-owne...
At some point in a career, one begins to encourage people to try replacing you and your team. Mostly, senior people become aware they are not there as some sort of fungible office decoration. Just do it... call the Managers bluff... the worst outcome is the team finds a better firm with someone smarter.
It was Schadenfreude watching the CEO's son (LLM guys) implode a public-facing production server ( https://en.wikipedia.org/wiki/Dunning-Kruger_effect .)
Slop content about slop code is slop recursive. Languages like C are simply very unforgiving to amateurs, and naive arbitrary code generators. Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
Vibe coders usually offer zero workmanship, and are enamored with statistically salient generated arbitrary content. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
This is such a bad take I don't even know where to start... Even if you think vibe coding _is_ the future, there are still so many things wrong about this article. It's like the author has a fundamental misunderstanding why we even create programming languages.
I actually think that they have a good handle on the motivation for programming languages design. Think about C. C has many features that serve programmer ergonomics. The use of "=" for assignment and the use of "++" for incrementing there to serve the developer by reducing keystrokes. Yes there are some languages that are developed to be more formal, but that isn't the mainstream.
Ehem, hell yeah.
the last thing people need is another foot gun in C code
Anecdote: I vibe-coded a thing in C using Claude Code + Opus 4.5 and, wow, the process and the result worked _shockingly_ well.
For reference, here are the two heavy-lifting workers:
- https://github.com/akaalias/bipscan/blob/main/src/c/find_seq...
- https://github.com/akaalias/bipscan/blob/main/src/c/check_se...
and here's a screenshot of the thing running:
- https://x.com/SpringStreetNYC/status/1996951130526425449/pho...
and here's the full story:
LOL, I got 100% nerd-sniped by my friend Sönke this week and wound up building a small spaceship.
On Monday he's like "Hey, what if you found obscure seed phrases embedded in public texts? You'd only need to remember the name of the book and the paragraph and go from there."
I honestly could care less about crypto(currencies) and I'm 100% sure this is like cryptanalysis 101. But, yeah, it seemed like an interesting problem anyways.
First, I downloaded a few hundred books from Gutenberg, wrote a ruby script and found BIP39 word sequences with a tolerable buffer for filler-words.
Then, I was like, okay, gotta now check them against actual addresses. Downloaded a list of funded ETH addresses. Wrote the checker in ruby. Ran it. No hits but this was now definitely weirdly interesting.
Because: And what if I downloaded the whole pg19 text corpus to scan! And what if I'd add BTC addresses! And what if I checked every permutation of the seed phrase!
Everything got really slow once I got to processing 12G of raw text for finding sequences and then checking a few million candidates with 44.000+ variations per candidate.
So, let's rewrite this into C! And since I've got 16 cores, let's parallelize this puppy! And since it's a MacBook, let's use GCD! Optimize all the things!
Lol, so NOW this thing is so fucking FAST. Takes four minutes to go through the full pg19 corpus and generates 64,205,390 "interesting" seed phrases. The fully parallelized checker (see Terminal screenshot) processes 460 derived addresses per second.
I really don't care if I get a match or not. I feel like I started with building a canoo and wound up with a spaceship is in itself just the best thing in the world.
It’s easy to answer why old-fashioned programming feels better to many people. It’s just alienation, or rather the relative lack of. It’s fulfilling to do things in a way that makes you feel like you have agency and are causing things to happen in ways that make sense to your own sense organs. It doesn’t even matter if “you” are doing it or “the tools” are doing the heavy lifting—who are you anyway, your thoughts, your tiny conscious mind on top of the iceberge of the unconscious?—, so you don’t have to get into the stupid quagmire ranging from “but abstractions and compilers” to “but Kant showed that thing-in-itself is different from the thing-as-sensed”, no, it’s fine, really; we all know (sense) when we feel in control or not.
But anyway. That’s all besides the point. Because the progress apologists[1] come in all shapes and forms (we are lead to believe), now also uber-passionate college professor who aah loves programming as much as the day he met her. But unlike you he’s a hard-prostheticed pragmatist. He both knows and sympathises with your “passion” but is ready to assert, in a tptacek-memetic style, that it is the way it is—and if you think otherwise (pause for effect), you are wrong.
Because don’t you see? Why are you so blind? No, we can’t let the chips fall as they may and just send you a “told you so” letter once everything you know-now is resolutely quaint. No, we must assert it right now. (So you don’t miss out on the wonderful ride.)
Aah the text complains. It saddens me to think of “coding by hand” becoming a kind of quaint Montessori-school... Oh, the twists and turns of the turbulent text, so organic. Just like your mind. But awake.
The room is at this point drenched in a mist of farts. Yes, programming by-hand, I think we ought to call it a quaintism at this point.
And did you know: people used to resist mechnical computers. Hmm? Yes, indeed, favoring people computers. The text prompts for another model to make an image of a person smirking so hard that their eyes become kind of diagonal and their cheeks disappear. But not in an evil cartoon character way. In a human way. That three years ago felt slightly off-putting. Now just looks like, well, you know.
- - -
Ahh. (Again.) These fools. With their hand-coding. Do they really think they will be employable three years from now? Well, no matter. I have a PhD from MIT along with my associate professorship. I only came out here to Iowa Community College because of my disabled son. Needed more time with him. And to get away from dat citation grind. Man. I have many organic hobbies. And a few very, really incredibly specific collections, as is fitting. puffs pipe Mmm yeah what do I care, so what if programming is quaint now—I’m already in my “ivory tower”, baby. People will listen to my takes on AI. They are appropriately detached, informal, just saying it like it is, you know? And if they don’t? Well, there’s an army of texts right behind me. They’ll be convinced to suppress any feelings of alienation eventually. Eventually, there will just be their own vanishing, small-minded, petty, “thoughts” on the matter. That tiny holdout. Against all content they can sense.
[1] Insert scare quotes here. All history is whitewashed. “We” progressed and defeated “them”. It’s all just a linear curve. No critical thinking is supposed to occur here. Those idiots thirty years ago used reusable underwear and had to load detergent into a washing machine and then even bend over to turn on a “button” to make the underwear reusable. Our underwear costs fifty cents, is made from the most comfortable plastic you can get, and dissolves and crumbles when it gets into contact with water; down the bathroom drain it goes.
[dead]
[dead]
i am not going to vibe code
I haven't done much, my theory here is...
A) I barely get to do any coding these days anyways
B) Reading code is harder than writing it (and thus, easier to gloss over), and by the time I'm ready to write code I've already done all the hard work (I.E. even if vibe coding made me 50% faster, it's 50% of 5% of the overall software development life cycle in this more senior role)
C) I've never even copied code from Stack Overflow into my editor (maybe once or twice in a couple decades), I always type things myself because it literally forces you to walk through character by character in a field where changing one character can easily lead to 8 hour bug hunts
D) There's probably not much world where I can't ramp up fairly quickly on how to prompt well
E) It seems to me everyone is spending all their time comparing model X with model Y, creating prompt context files, running multiple agents in parallel... if the purported gains are to occur, eventually we should have tools that require less of all that, and I can just use those later tools when they're around instead of learning a bunch of stuff that will naturally be useless (This is like if you became a Backbone JS expert and were left stunned when people started using React)
F) And if those gains don't occur (and the gains certainly seem to be leveling off quick, the comments today look much like the comments a few years ago, and I've really not seen much one way or the other when comparing a variety of coworkers in terms of productivity beyond POCs, and the starts of small scope green field projects (although, those can be accomplished by non technical people in some instances which is neat)) then... well... I guess I'll just keep doing what I've been doing for the last couple decades, but I won't have wasted a bunch of time learning how to prompt Grok vs Copilot vs ChatGPT or what ever and I'll still have tons of information in my head about how everything works
>Vibe coding actually works. It creates robust, complex systems that work.
No it doesn't. Just for the fun of it because I'm somewhat familiar with the VLC codebase I tried to fix some bugs with "agentic tooling" and "vibe coding". And it just produces crap. Which is one metric I'd propose for the usefulness of these tools, why aren't they fixing real bugs in the large open source codebases of this world? You'd be a hero, VLC has like 4000 open issues.
The answer is of course because these tools, in particular in manual memory managed languages which the author proposes to use, don't work at all. Maybe they work on a toy project of 500 lines of code, which is all every demo ever produces, but these text based systems have no actual understanding of the hardware underlying a complex program. That's just not how they work.
Imagine the kind of garbage that some people consider "robust, working code"...