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.)
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.
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.
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.
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.
> 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.
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 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.
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 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.
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.
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.
>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.
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.
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.
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.
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.
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 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.
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.
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).
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.
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.
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).
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?)
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.
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.
Some comments were deferred for faster rendering.
gitremote|2 months ago
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.
omnicognate|2 months ago
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/
giancarlostoro|2 months ago
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.
pron|2 months ago
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.
mavamaarten|2 months ago
shortrounddev2|2 months ago
> 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
theptip|2 months ago
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.
jcelerier|2 months ago
btbuildem|2 months ago
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.
ozim|2 months ago
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.
Breza|2 months ago
Then again, if humans could agree on all the project minutia at the outset, we never would have developed the other systems.
al_borland|2 months ago
mlinhares|2 months ago
antirez|2 months ago
doug_durham|2 months ago
BizarroLand|2 months ago
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.
lxgr|2 months ago
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 ;)
seg_lol|2 months ago
That is no longer the case.
sputr|2 months ago
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.
ljm|2 months ago
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.
markstos|2 months ago
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.
whiatp|2 months ago
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.
chis|2 months ago
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.
UncleOxidant|2 months ago
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).
sureglymop|2 months ago
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.
ActorNightly|2 months ago
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.
nylonstrung|2 months ago
greenavocado|2 months ago
stared|2 months ago
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.
crazygringo|2 months ago
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.
0xbadcafebee|2 months ago
Look at Shellcheck. It turns a total newbie into a shell master just by iteration.
stargrazer|2 months ago
https://cacm.acm.org/research/automatically-translating-c-to...
jmull|2 months ago
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.
nylonstrung|2 months ago
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
vbezhenar|2 months ago
sebstefan|2 months ago
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.
perrygeo|2 months ago
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.
pathartl|2 months ago
epsteingpt|2 months ago
parasti|2 months ago
dlisboa|2 months ago
Yes, it’s extremely soul sucking. With the added disadvantage of not teaching me anything.
russfink|2 months ago
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.
Cthulhu_|2 months ago
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.
TylerLives|2 months ago
zelphirkalt|2 months ago
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.
hadlock|2 months ago
>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.
vibeleaker|2 months ago
didibus|2 months ago
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.
lmm|2 months ago
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).
jimmaswell|2 months ago
redox99|2 months ago
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.
kesor|2 months ago
N_Lens|2 months ago
DetroitThrow|2 months ago
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.
esafak|2 months ago
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.
whynotmaybe|2 months ago
I'm getting too old for this shit.
wavemode|2 months ago
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.
teach|2 months ago
kesor|2 months ago
Danborg|2 months ago
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.
mentos|2 months ago
If not then I see the argument for everything being done in Python and performance coming from optimizing Python -> C.
wongarsu|2 months ago
Thorrez|2 months ago
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.
sfdlkj3jk342a|2 months ago
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.
Maxion|2 months ago
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.
MattRix|2 months ago
It doesn’t feel like we’re very far from that point.
jlouis|2 months ago
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.
nylonstrung|2 months ago
Formal proofs have so much potential in this context
otikik|2 months ago
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.
INTPenis|2 months ago
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.
peteforde|2 months ago
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.
pmdr|2 months ago
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.
lalaithion|2 months ago
flatline|2 months ago
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.
DubiousPusher|2 months ago
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
enriquto|2 months ago
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.
DonHopkins|2 months ago
d-lisp|2 months ago
gnatman|2 months ago
minimaxir|2 months ago
I'll write about the process after I've released a few more things as I have some disagreements with the current discourse.
julianeon|2 months ago
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.
Havoc|2 months ago
Whether those are substantial enough to count as shipped projects is a matter of debate
https://tools.simonwillison.net/
deathanatos|2 months ago
… 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".)
BiteCode_dev|2 months ago
- 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.
StarterPro|2 months ago
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.
didibus|2 months ago
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.
kesor|2 months ago
kldg|2 months ago
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.
PaulHoule|2 months ago
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.
gsf_emergency_6|2 months ago
tmsbrg|2 months ago
crq-yml|2 months ago
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.
xandrius|2 months ago
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.
treyd|2 months ago
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.
dwedge|2 months ago
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.
pjmlp|2 months ago
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.
epgui|2 months ago
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.
triwats|2 months ago
We've not really seen what impact this will have just yet.
0xbadcafebee|2 months ago
elif|2 months ago
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.
raphlinus|2 months ago
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...
nu11ptr|2 months ago
doug_durham|2 months ago
pcblues|2 months ago
sneak|2 months ago
> 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.
nicoburns|2 months ago
Do you have any examples of these? All the vibe coded systems I've seen so far were very far from robust.
auntienomen|2 months ago
bigstrat2003|2 months ago
jillesvangurp|2 months ago
- 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.
swiftcoder|2 months ago
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)?
Gud|2 months ago
2) use a language that is well supported by the community with countless examples ( Python )
sys_64738|2 months ago
the_stocker|2 months ago
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.
dbfclark|2 months ago
- 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.
joshdavham|2 months ago
The problem here is that human languages are terrible programming languages and LLMs are terrible compilers.
senderista|2 months ago
choeger|2 months ago
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.)
hugs|2 months ago
vga42|2 months ago
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?
bambax|2 months ago
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.
matthewowen|2 months ago
rjmunro|2 months ago
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.
bagacrap|2 months ago
jedbrooke|2 months ago
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
incrudible|2 months ago
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.
majormajor|2 months ago
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.
Espressosaurus|2 months ago
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.
qudat|2 months ago
awelkie|2 months ago
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.
littlestymaar|2 months ago
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”.
adamzwasserman|2 months ago
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.
bobbylarrybobby|2 months ago
zzo38computer|2 months ago
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.
pfbtgom|2 months ago
RagnarD|2 months ago
thunky|2 months ago
agentultra|2 months ago
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.
sshadmand|2 months ago
dmix|2 months ago
AI just gives suggestions but you have to make all the hard choices and fix/simplify a lot of the output
tomekowal|2 months ago
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.
simonw|2 months ago
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...
xormapmap|2 months ago
Or why not just produce a binary directly? It seems we've just invented a compiler.
HarHarVeryFunny|2 months ago
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.
DonHopkins|2 months ago
“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.
pizlonator|2 months ago
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)
akst|2 months ago
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.
Imnimo|2 months ago
Uehreka|2 months ago
2bluesc|2 months ago
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.
mcny|2 months ago
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.
synergy20|2 months ago
python though is very readable, not so much for typescript for me.
epsteingpt|2 months ago
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.
a-saleh|2 months ago
So, vibecoding in C feels like playing with loaded gun.
karpour|2 months ago
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.
florilegiumson|2 months ago
kesor|2 months ago
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.
unknown|2 months ago
[deleted]
farhanhubble|2 months ago
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.
nphardon|2 months ago
benjiro|2 months ago
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.
unknown|2 months ago
[deleted]
rodriguejr|2 months ago
BobbyJo|2 months ago
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.
kesor|2 months ago
cryptonector|2 months ago
fantasizr|2 months ago
jrochkind1|2 months ago
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?)
s17n|2 months ago
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.
tasuki|2 months ago
Or... I want to only write the tests. The implementation is... an implementation detail!
bsoles|2 months ago
Then show us this robust, complex code that was produced by vibe coding and let us judge for ourselves.
kgthegreat|2 months ago
dpedu|2 months ago
letmeinhere|2 months ago
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.
29athrowaway|2 months ago
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.
kesor|2 months ago
clbrmbr|2 months ago
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.
naths88|2 months ago
jstummbillig|2 months ago
oleganza|2 months ago
(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.
rudimentary_phy|2 months ago
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).
bildiba|2 months ago