[HN Gopher] If you're going to vibe code, why not do it in C?
___________________________________________________________________
If you're going to vibe code, why not do it in C?
Author : sramsay
Score : 245 points
Date : 2025-12-09 17:11 UTC (5 hours ago)
(HTM) web link (stephenramsay.net)
(TXT) w3m dump (stephenramsay.net)
| auntienomen wrote:
| If the headline is a question, the answer is "No".
| bigstrat2003 wrote:
| The headline isn't a yes/no question though.
| auntienomen wrote:
| The answer is still "No".
| DonHopkins wrote:
| Q: How many Prolog programmers does it take to change a
| lightbulb?
|
| A: Yes.
| esafak wrote:
| > Or hell, why not do it in x86 assembly?
|
| Because I want to be able to review it, and extend it myself.
|
| edit: Pure vibe coding is a joke or thought exercise, not a goal
| to aspire to. Do you want to depend on a product that has not
| been vetted by any human? And if it is your product, do you want
| the risk of selling it?
|
| I can imagine a future where AI coders and AI QA bots do all the
| work but we are not there yet. Besides, an expressive language
| with safety features is good for bots too.
| whynotmaybe wrote:
| We could go to the semantic road and proclaim that if you
| extend it yourself, it's not "pure" vibe coding.
|
| I'm getting too old for this shit.
| stared wrote:
| 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.
| stargrazer wrote:
| To go along with this, the ACM has a recent article on
| Automatically Translating C to Rust. It gets into the
| challenges of 'understanding code and structure' so that the
| end result reflects the intent of the code, not the actual
| execution paths.
|
| https://cacm.acm.org/research/automatically-translating-c-to...
| pathartl wrote:
| I think it's a pretty good point. I've been using LLMs for .NET
| and the output is generally pretty good.
| vbezhenar wrote:
| Why Rust? Haskell is gold standard here.
| gkfasdfasdf wrote:
| Can you elaborate? What is it about Haskell that makes it
| better?
| vbezhenar wrote:
| Very advanced type system which allows to move a lot of
| program correctness to typing system. So basically if your
| program compiles, it probably works.
|
| It's also has GC which makes it better suited for most
| programs, compared to Rust with its manual memory
| management.
| ModernMech wrote:
| Rust does not have manual memory management, and its type
| system also has the property that if your program
| compiles it probably works, IME.
| throw-qqqqq wrote:
| Purely functional code is easier to test because of its
| referential transparency and lack of shared state.
|
| Haskell is also nice because of quickcheck.
| IshKebab wrote:
| I would think Lean and other formal languages are the real
| gold standard.
|
| But none of them really have enough training data for LLMs to
| be any good at them.
| stared wrote:
| I guess there is a reason why Linux kernel accepts Rust not
| Haskell.
| jmull wrote:
| Rust doesn't prevent programs from having logic errors.
|
| If LLMs produce code riddled with bugs in one language it will
| do in other languages as well. Rust isn't going to save you.
| loeg wrote:
| > Rust doesn't prevent programs from having logic errors.
|
| Like everything around Rust, this has been discussed ad
| nauseam.
|
| Preventing memory safety bugs has a meaningful impact in
| reducing CVEs, even if it has no impact on logic bugs.
| (Which: I think you could argue the flexible and expressive
| type system helps with. But for the sake of this argument,
| let's say it provides no benefits.)
| zdragnar wrote:
| It isn't like rust is the only language with memory safety;
| plenty of high level languages don't let you fiddle with
| memory bits in a way that would be unsafe. The tradeoff is
| that they typically come with garbage collectors.
|
| If the only concern is "can an LLM write code in this
| language without memory errors" then there's plenty of
| reasons to choose a language other than Rust.
| nialv7 wrote:
| But the author isn't saying we should program in any of
| these memory safe languages. The author is saying why
| don't we vibe code in C, or even assembly.
| zdragnar wrote:
| This thread moved the conversation away from the posted
| article quite a few messages ago.
|
| First, Rust has lots of checks that C and assembly don't,
| and AI benefits from those checks. Then, a post about
| those checks are related to memory safety, not logic
| errors. Then, a post about whether that's a helpful
| comment. Finally, me pointing out that checks regarding
| types and memory errors aren't unique to Rust and there's
| tons of languages that could benefit.
|
| Since you want to bring it back to the original article,
| here's a quote from the author: Is C
| the ideal language for vibe coding? I think I could mount
| an argument for why it is not, but surely Rust is even
| less ideal. To say nothing of Haskell, or OCaml, or even
| Python. All of these languages, after all, are for people
| to read, and only incidentally for machines to execute.
|
| It would seem that the author fundamentally misunderstand
| significant reasons for many of the languages he mentions
| to be the way that they are.
| 9rx wrote:
| _> Rust has lots of checks that C and assembly don 't,
| and AI benefits from those checks._
|
| Fil-C gets you close in the case of C, but we can ignore
| it because, of course, F* has significantly more checks
| than Rust, and AI benefits from those checks. Choosing
| Rust would be as ridiculous as choosing C if that was
| your motivation.
|
| But if you don't find the need for those checks in order
| to consider Rust, why not C or even assembly instead?
| Maxatar wrote:
| The trade-off is intended to make it easier for people to
| write software. Garbage collected languages make it
| easier for people to write memory safe code at the
| expense of performance, significantly greater memory
| usage, and heavy dependencies/runtimes.
|
| These trade-offs are wholly unnecessary if the LLM writes
| the software in Rust, assuming that in principle the LLM
| is able to do so.
| staticassertion wrote:
| > Rust doesn't prevent programs from having logic errors.
|
| Sure, but it prevents memory safety issues, which C doesn't.
| As for logic bugs, what _does_ prevent them? That 's a bigger
| question but I'd suggest it's:
|
| 1. The ability to model your problem in a way that can be
| "checked". This is usually done via type systems, and Rust
| has an arguably good type system for this.
|
| 2. Tests that allow you to model your problem in terms of
| assertions. Rust has decent testing tooling but it's not
| amazing, and I think this is actually a strike against Rust
| to a degree. That said, proptest, fuzzing, debug assertions,
| etc, are all present and available for Rust developers.
|
| There are other options like using external modeling tools
| like TLA+ but those are decoupled from your language, all you
| can ever do is prove that your algorithm as specified is
| correct, not the code you wrote - type systems are a better
| tool to some degree in that way.
|
| I think that if you were to ask an LLM to write very correct
| code then give two languages, one with a powerful, express
| type system and testing utilities, and one without those,
| then the LLM would be far more likely to produce buggy code
| in the system without those features.
| skydhash wrote:
| Logic errors always stems from lack of understanding and
| inattention. The former is resolved by good communication
| and analytical skills. The other is just human nature, but
| we do have guardrails to help, like static analysis and
| tests. If used correctly.
|
| There are static tools available for C as well. What you
| get from Rust mostly is that the check is part of the
| syntax of the language as well and escaping from it is very
| visible. You get safety, but you give up flexibility and
| speed.
| sophacles wrote:
| Modern medicine can't prevent or cure all diseases, so you
| might as well go back to drinking mercury then rubbing dog
| shit into your wounds.
|
| Modern sewers sometimes back up, so might as well just
| releive yourself in a bucket and dump it into your sidewalk.
|
| Modern food preservation doesn't prevent all spoilage so you
| might as well just go back to hoping that meat hasn't been
| sitting in the sun for too many days.
| unethical_ban wrote:
| This is objectively wrong.
|
| You can't get a gutter ball if you put up the rails in a
| bowling lane. Rust's memory safety is the rails here.
|
| You might get different "bad code" from AI, but if it can
| self-validate that some code it spits out has memory
| management issues at compile time, it helps the development.
| Same as with a human.
| wizzwizz4 wrote:
| > _You can 't get a gutter ball if you put up the rails in
| a bowling lane._
|
| Sure you can. It's difficult, and takes skill, but it _can_
| be done.
| IshKebab wrote:
| > Rust doesn't prevent programs from having logic errors.
|
| Nobody ever claimed that. The claims are:
|
| 1. Rust _drastically_ reduces the chance of memory errors.
| (Or eliminates them if you avoid unsafe code.)
|
| 2. Rust reduces the chance of other logic errors.
|
| Rust doesn't have to _eliminate_ logic errors to be a better
| choice than C or assembly. Significantly reducing their
| likelihood is enough.
| ux266478 wrote:
| Can these claims back themselves up with a study showing
| that over a large population size with sufficient variety,
| sourced from a collection of diverse environments, LLM
| output across a period of time is more reliably correct and
| without issue when using Rust? Otherwise this inductive
| reasoning is pretty vacuous and unempirical.
| DonHopkins wrote:
| All kinds of drugs produce unwanted risks and side effects if
| abused, so let's abuse crystal meth! Cannabis isn't going to
| save you.
| socalgal2 wrote:
| technically true but so what?
|
| https://security.googleblog.com/2025/11/rust-in-android-
| move...
|
| That team claims that not having to deal with memory bugs
| saved them time. That time can be spent on other things (like
| fixing logic errors)
| crazygringo wrote:
| That's a really, really interesting point.
|
| It makes me imagine a programming language designed for LLMs
| but not humans, designed for rigorous specification of every
| function, variable, type, etc., valid inputs and outputs,
| tightly coupled to unit tests, mandatory explicit handling of
| every exception, etc.
|
| Maybe it'll look like a lot of boilerplate but make it easy to
| read as opposed to easy to write.
|
| The idea of a language that is extremely high-effort to write,
| but massively assists in guaranteeing correctness, could be
| ideal for LLM's.
| cgh wrote:
| That's what the article is about.
| crazygringo wrote:
| No it's not. The article proposes the _idea_ of a language
| designed for vibe-coding, and suggests several variants
| designed for specific purposes. But none of the variants
| are for the purpose I suggested, which is about maximizing
| _correctness_. That 's the point I was making.
| ModernMech wrote:
| I'm writing one of these, I'll post it on HN next year. The
| key to a language for LLMs is: make sure all the context is
| local, and explicit. If you have functions, use parameters
| for arguments instead of positions. If you have types, spell
| them out right there. Also, don't use too many tokens, so
| keywords are out. And that's just a start.
|
| I think the ideal language for LLMs will look more like APL
| than C.
| nylonstrung wrote:
| Absolutely. A language being well suited to static analysis and
| "compiler driven development" matters a lot more with LLMs than
| with humans IMO
|
| We're at the point of diminishing returns from scaling and RL
| is the only way to see meaningful improvements
|
| Very hard to improve much via RL without some way to tell if
| the code works without requiring compilation
|
| Logic based languages like Prolog take this to the logic
| extreme, would love to see people revisit that idea
| bigstrat2003 wrote:
| > Vibe coding actually works. It creates robust, complex systems
| that work.
|
| No, it absolutely doesn't. We've seen so much vibe coded slop
| that it's very clear that vibe coding produces a hot mess which
| no self respecting person would call acceptable. No idea how you
| can say this as it isn't _remotely_ true.
| abnercoimbre wrote:
| The author doesn't appear to ship commercially-viable software
| and unfortunately it shows. Those of us who do are amused by
| the essay.
|
| The two recent IT catastrophes [0] from Alaska Airlines will
| continue elsewhere.
|
| [0] https://www.seattletimes.com/business/alaska-
| airlines/alaska...
| SoftTalker wrote:
| > Alaska hired the consulting firm Accenture to look for ways
| to strengthen its system
|
| Now they have two problems....
| hamzaawan wrote:
| Its very highly probable that AI is going to generate slop at
| some point so if you dont know much about how it works, you are
| doomed. Once it starts going towards slop it just keeps getting
| deeper until you reach a point where every simple problem feels
| like you need a new repo
| derektank wrote:
| >Is C the ideal language for vibe coding? I think I could mount
| an argument for why it is not, but surely Rust is even less ideal
|
| I was really hoping you were going to make this argument, based
| upon the title of the piece! Still a good read, but if you have
| the inclination I hope you loop back around to weighing the pros
| and cons of vibe coding in different languages
| Espressosaurus wrote:
| 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.
| qudat wrote:
| You just tell it the problem and it'll fix it. It's almost
| never been an issue for me in Zig.
| flatline wrote:
| 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.
| bildiba wrote:
| 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.
| gitremote wrote:
| I believe they are arguing against vibe-coding categorically by
| pointing out that high-level programming languages are for
| human expression. It's a reductio ad absurdum against the
| logical conclusion that follows from vibe coding as a premise.
| If vibe coding is like a using a compiler, why not just
| translate English directly to machine code or lower level
| languages?
| guywithahat wrote:
| > why not do it in C?
|
| A legitimate point, there are lots of performance and fine grain
| changes you can make, and it's a simple, common language many
| people use. Perhaps we could realize some of these benefits from
| a simple, fast language.
|
| > Or hell, why not do it in x86 assembly?
|
| A terrible take imo. This would be impossible to debug and it's
| complex enough you likely won't see any performance improvements
| from writing in assembly. It's also not portable, meaning you'd
| have to rewrite it for every OS you want to compile on.
|
| I think there's an argument that if machines are writing code,
| they should write for a machine optimized language. But even
| using this logic I don't want to spend a bunch of time and money
| writing multiple architectures, or debugging assembly when things
| go wrong.
| thefaux wrote:
| If the boosters are correct about the trajectory of llm
| performance, these objections do not hold.
|
| Debugging machine code is only bad because of poor tooling.
| Surely if vibe coding to machine code works we should be able
| to vibe code better debuggers. Portability is a non issue
| because the llm would have full semantic knowledge of the
| problem and would generate optimal, or at least nearly optimal,
| machine code for any known machine. This would be better,
| faster and cheaper than having the llm target an intermediate
| language, like c or rust. Moreover, they would have the ability
| to self-debug and fix their own bugs with minimal to no human
| intervention.
|
| I don't think there is widespread understanding of how bloated
| and inefficient most real world compilers (and build systems)
| are, burning huge amounts of unnecessary energy to translate
| high level code, written by humans who have their own energy
| requirements, to machine code. It seems highly plausible to me
| that better llms could generate better machine code for less
| total energy expenditure (and in theory cost) than the human +
| compiler pair.
|
| Of course I do not believe that any of the existing models are
| capable of doing this today, but I do not have enough expertise
| to make any claims for or against the possibility that the
| models can reach this level.
| matthewowen wrote:
| 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.
| epgui wrote:
| 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.
| triwats wrote:
| 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.
| alansaber wrote:
| Ah yes just what vibe coding needs, further weakening human
| oversight
| noosphr wrote:
| Vibe coding produces great one shot proofs of concept that fit
| inside its context window.
|
| It produces hot garbage when it needs to bring together two
| tokens from the far ends of a large code base together.
|
| This comes as no surprise to anyone who understands what the
| attention mechanism actually is, and as a great surprise to
| everyone who thinks transformers are AI magic.
| sneak wrote:
| I wish everyone would read this paragraph:
|
| > _But this leads me to my second point, which I must make as
| clearly and forcefully as I can. Vibe coding actually works. It
| creates robust, complex systems that work. You can tell yourself
| (as I did) that it can't possibly do that, but you are wrong. You
| can then tell yourself (as I did) that it's good as a kind of
| alternative search engine for coding problems, but not much else.
| You are also wrong about that. Because when you start giving it
| little programming problems that you can't be arsed to work out
| yourself (as I did), you discover (as I did) that it's awfully
| good at those. And then one day you muse out loud (as I did) to
| an AI model something like, "I have an idea for a program..." And
| you are astounded. If you aren't astounded, you either haven't
| actually done it or you are at some stage of grief prior to
| acceptance. Perfect? Hardly. But then neither are human coders.
| The future? I think the questions answers itself._
|
| This cannot be repeated enough. For all the AI hype, if you think
| AI isn't the most useful programming tool invented in the last 20
| years, you're ignorant of the SOTA or deeply in denial.
|
| As @tptacek recently wrote:
|
| > _All progress on LLMs could halt today, and LLMs would remain
| the 2nd most important thing to happen over the course of my
| career._
| nicoburns wrote:
| > It creates robust, complex systems that work
|
| Do you have any examples of these? All the vibe coded systems
| I've seen so far were very far from robust.
| naths88 wrote:
| 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.
| d-lisp wrote:
| Do you have a link to the webapp you produced or its source
| code ?
|
| edit: it was a real request, I was being interested, not some
| mockery or idk
| naths88 wrote:
| I understand, not yet online, but it will be deployed in a
| few months for educational purposes (i teach).
| xandrius wrote:
| 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.
| treyd wrote:
| 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.
| gaigalas wrote:
| Fascinating.
|
| I would appreciate a post with examples, not just prose. It helps
| to put things in a more grounded reality.
| dankobgd wrote:
| i am not going to vibe code
| codyb wrote:
| I haven't done much, my theory here is...
|
| A) I barely get to do any coding these days anyways
|
| B) Reading code is harder than writing it (and thus, easier to
| gloss over), and by the time I'm ready to write code I've
| already done all the hard work (I.E. even if vibe coding made
| me 50% faster, it's 50% of 5% of the overall software
| development life cycle in this more senior role)
|
| C) I've never even copied code from Stack Overflow into my
| editor (maybe once or twice in a couple decades), I always type
| things myself because it literally forces you to walk through
| character by character in a field where changing one character
| can easily lead to 8 hour bug hunts
|
| D) There's probably not much world where I can't ramp up fairly
| quickly on how to prompt well
|
| E) It seems to me everyone is spending all their time comparing
| model X with model Y, creating prompt context files, running
| multiple agents in parallel... if the purported gains are to
| occur, eventually we should have tools that require less of all
| that, and I can just use those later tools when they're around
| instead of learning a bunch of stuff that will naturally be
| useless (This is like if you became a Backbone JS expert and
| were left stunned when people started using React)
|
| F) And if those gains don't occur (and the gains certainly seem
| to be leveling off quick, the comments today look much like the
| comments a few years ago, and I've really not seen much one way
| or the other when comparing a variety of coworkers in terms of
| productivity beyond POCs, and the starts of small scope green
| field projects (although, those can be accomplished by non
| technical people in some instances which is neat)) then...
| well... I guess I'll just keep doing what I've been doing for
| the last couple decades, but I won't have wasted a bunch of
| time learning how to prompt Grok vs Copilot vs ChatGPT or what
| ever and I'll still have tons of information in my head about
| how everything works
| fantasizr wrote:
| 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
| jrochkind1 wrote:
| 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?)
| tatjam wrote:
| Lean 4 seems to be pretty AI-usable, and you get insane
| guarantees (but LLM do seem to make very heavy use of
| "sorry")
| sramsay wrote:
| Author, here. This is exactly the question I was trying
| (perhaps ineptly) to pose: If we designed a programming
| language with the idea that it would be primarily or
| exclusively vibe coded, what would that language look like?
| Might it look something more like Lean? Or more like theorem
| provers in general? Or would it look more like a natural
| language PL (think Inform 7)? Or what about a heavily
| declarative DSL like FAUST (for audio DSP)?
|
| None of our existing programming languages were designed for
| quite the circumstance in which contemporary programming now
| finds itself; they all address an ergonomic situation in
| which there are humans and machines (not humans, machines,
| and LLMs).
|
| It's _possible_ , I suppose that the only PL that makes sense
| here is the one the LLMs "knows" best, but I sort of doubt
| that that makes sense over the long term. And I'm repeating
| myself, but really, it seems to me that a language that was
| written entirely for the ergonomic situation of human coders
| without any consideration of LLMs is not addressing the
| contemporary situation. This is not a precise analogy, but it
| seems to me a little like the difference between a language
| that was designed before vs after multicore -- or before vs
| after the internet.
| benjiro wrote:
| The problem with creating a programming language for LLMs,
| goes back to, what are LLMs? They are trained on masses of
| human written code, that is written in human readable form.
|
| So even if you make a better programming language for a
| LLM, it has nothing to train on. Unless we start to
| transcode human language code to the LLM code.
|
| Are the vectors/tokens/whatever, not already LLM code at
| this point? Technically, LLMs not are doing what Haxe was
| doing (haxe.org) but in a more advanced form?
|
| Even if we make a more LLM like programming code, in a
| sense, we are just making another code that needs to be
| translated into the tokens that consist in a LLM model, no?
|
| Feels like we are starting to hit philosophical debates
| with that one _lol_
| rmsaksida wrote:
| Unrelated - it looks like your blog's RSS feed isn't up to
| date. :-)
| sramsay wrote:
| Thank you!
| DubDouble wrote:
| Ehem, hell yeah.
| incrudible wrote:
| 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_.
| barrister wrote:
| This author, like many others on this site, seem to imply that AI
| generates "good" code, but it absolutely does not---unless he's
| running some million dollar subscription model I'm unaware of.
| I've tested every AI using simple Javascript programs and they
| all produce erroneous spaghetti slop. I did discover that Claude
| produces sufficiently decent Haskell code. The point is that the
| iterative process requires you know the language because you're
| going to need to amend the code. Therefore vibe in the language
| you know. Anyone that suggests that AI can produce a solid
| application on its own is a fraud.
| erichocean wrote:
| > _I did discover that Claude produces sufficiently decent
| Haskell code._
|
| Clojure generation is also very solid. Gemini Pro 2.5/3 is
| fantastic at it.
|
| A part of me wonders if that is because these languages
| primarily have senior devs writing code, so the entire training
| set is "good" code.
| codyb wrote:
| The Erlang space vs the Elixir space (can't speak for agent
| based code generation here) would seem to give credence to
| this theory.
|
| When I would explore Elixir forums with much larger
| communities there'd be myriad base level questions with code
| blocks written as if Elixir and Ruby were interchangable
| cause the syntax looks similar and thus missing out on many
| of the benefits of OTP.
|
| But when you'd go to the Erlang community to ask a question,
| half the time the author of the book or library was one of
| the like... 20 people online at any given moment, and they'd
| respond directly. The quality of the discussions was of
| course much deeper and substantial much more consistently.
|
| I have not tried to generate Elixir vs Erlang code but maybe
| it'd be a neat experiment to see if the quality seems better
| with Erlang
| gitremote wrote:
| 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.
| mavamaarten wrote:
| 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.
| bjacobso wrote:
| Claude Code et al. asks clarifying questions in plan mode
| before implementing. This will eventually extend to jira
| comments
| fooker wrote:
| What do you mean by eventually?
|
| this already exists.
| swatcoder wrote:
| You think the business line stakeholder is going to
| patiently hang out in JIRA, engaging with an overly
| cheerful robot that keeps "missing the point" and being
| "intentionally obtuse" with its "irrelevant questions"?
|
| This is how most non-technical stakeholders feel when you
| probe for consistent, thorough requirements and a key
| professional skill for many more senior developers and
| consultants is in mastering the soft skills that keep them
| attentive and sufficiently helpful. Those skills are not
| generic sycophancy, but involve personal attunement to the
| stakeholder, patience (exercising and engendering), and
| cycling the right balance between persistence and de-
| escalation.
|
| Or do you just mean there will be some PM who acts as proxy
| between for the stakeholder on the ticket, but still needs
| to get them onto the phone and into meetings so the answers
| can be secured?
|
| Because in the real world, the prior is outlandish and the
| latter doesn't gain much.
| a_wild_dandan wrote:
| Businesses do whatever's cheap. AI labs will continue
| making their models smarter, more persuasive. Maybe the
| SWE profession will thrive/transform/get massacred. We
| don't know.
| colechristensen wrote:
| A significant part of my LLM workflow involves having the LLM
| write and update tickets for me.
|
| It can make a vague ticket precise and that can be an easy
| platform to have discussions with stakeholders.
| somebehemoth wrote:
| I like this use of LLM because I assume both the developer
| and ticket owner will review the text and agree to its
| contents. The LLM could help ensure the ticket is thorough
| and its meaning is understood by all parties. One downside
| is verbosity, but the humans in the loop can edit
| mercilessly. Without human review, these tickets would have
| all the downsides of vibe coding.
|
| Thank you for sharing this workflow. I have low tolerance
| for LLM written text, but this seems like a really good use
| case.
| SoftTalker wrote:
| Wait until you learn that the people on the other side of
| your ticket updates are also using LLMs to respond. It's
| LLMs talking to LLMs now.
| colechristensen wrote:
| The desired result is coming to a documented agreement on
| an interaction, not some exercise in argument that has to
| happen between humans.
|
| I find having an LLM create tickets for itself to
| implement to be an effective tool that I rarely have to
| provide feedback for at all.
|
| This seems like greybeards complaining that people who
| don't write assembly by hand.
| Yeask wrote:
| Who has ever complained that kids don't write assembly by
| hand?
|
| Stop being outraged for things that are only real on your
| mind.
| colechristensen wrote:
| Speaking of things that are only real in your mind...
|
| Am I outraged?
|
| And yes, there absolutely was a vocal group of a certain
| type of programmer complaining about high level languages
| like C and their risks and inefficiency and lack of
| control insisting that real programmers wrote code in
| assembly. It's hard to find references because google
| sucks these days and I'm not really willing to put in the
| effort.
| Yeask wrote:
| You made it up, that is why you can't find it.
| antisthenes wrote:
| Wait until you learn that most people's writing skills
| are that of below LLMs, so it's an actual tangible
| improvement (as long as you review the output for details
| not being missed, of course)
| PaulHoule wrote:
| A significant part of _my_ workflow is getting a ticket
| that is ill-defined or confused and rewriting it so that it
| is something I can do or not do.
|
| From time to time I have talked over a ticket with an LLM
| and gotten back what I think is a useful analysis of the
| problem and put it into the text or comments and I find my
| peeps tend to think these are TLDR.
| mrweasel wrote:
| We had a client who'd create incredibly detailed Jira
| tickets. Their lead developer (also their only developer)
| would write exactly how he'd want us to implement a given
| feature, and what the expected output would be.
|
| The guy is also a complete tool. I'd point out that what he
| described wasn't actually what they needed, and that there
| functionality was ... strange and didn't actually do anything
| useful. We'd be told to just do as we where being told,
| seeing as they where the ones paying the bills. Sometimes
| we'd read between the lines, and just deliver what was
| actually needed, then we'd be told just do as we where told
| next time, and they'd then use the code we wrote anyway. At
| some point we got tired of the complaining and just did
| exactly as the tasks described, complete with tests that
| showed that everything worked as specified. Then we where
| told that our deliveries didn't work, because that wasn't
| what they'd asked for, but couldn't tell us where we
| misunderstood the Jira task. Plus the tests showed that the
| code functioned as specified.
|
| Even if the Jira tasks are in a state where it seems like you
| could feed them directly to an LLM, there's no context (or
| incorrect context) and how is a chatbot to know that the
| author of the task is a moron?
| ForOldHack wrote:
| "The guy is also a complete tool." - Who says Hackers news
| is not filled with humor?
| SchemaLoad wrote:
| Every time I've received overly detailed JIRA tickets like
| this it's always been significantly more of a headache than
| the vague ones from product people. You end up with someone
| with enough tech knowledge to have an opinion, but
| separated enough from the work that their opinions don't
| quite work.
| zephen wrote:
| > how is a chatbot to know that the author of the task is a
| moron?
|
| Does it matter?
|
| The chatbot could deliver exactly what was asked for (even
| if it wasn't what was needed) without any angst or
| interpersonal issues.
|
| Don't get me wrong. I feel you. I've been there, done that.
|
| OTOH, maybe we should leave the morons to their shiny new
| toys and let them get on with specifying enough rope to
| hang themselves from the tallest available structure.
| jcelerier wrote:
| 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.
| f1shy wrote:
| I don't want to imply this is your case, because of course
| I've no idea how you work. But I've seen way too often, the
| reason for so many separate features is:
|
| A) as stated by parent comment, the ones doing req. mngmt.
| Are doing a poor job of abstracting the requirements, and
| what could be done as one feature suddenly turns in 25.
|
| B) in a similar manner as A, all solutions imply writing more
| and more code, and never refactor and abstract parts away.
| mckn1ght wrote:
| My guess would be that the long list is maybe not self
| contained features (although still can be, I know I have
| more feature ideas than I can deliver in the next couple
| years myself), but behaviors or requirements of one or a
| handful of product feature areas.
|
| When you start getting down into the weeds, there can be
| tons and tons of little details around state maintenance,
| accessibility, edge cases, failure modes, alternate
| operation modes etc.
|
| That all combines to make lots of code that is highly
| interconnected, so you need to write even more code to test
| it. Sometimes much more than even the target
| implementations code.
| swatcoder wrote:
| That sounds like papier mache more than bridge building,
| forever pasting more code on as ideas and time permit without
| the foresight to engineer or architect towards some cohesive
| long-term vision.
|
| Most software products built that way seem to move fast at
| first but become monstrous abominations over time. If those
| are the only places you keep finding yourself in, be careful!
| ebiester wrote:
| There are a wide number of small problems for which we do
| not need bridges.
|
| As a stupid example, I hate the functionality that YouTube
| has to maintain playlists. However, I don't have the time
| to build something by hand. It turns out that the general
| case is hard, but the "for me" case is vibe codable. (Yes,
| I could code it myself. No, I'm not going to spend the time
| to do so.)
|
| Or, using the Jira API to extract the statistics I need
| instead of spending a Thursday night away from the family
| or pushing out other work.
|
| Or, any number of tools that are within my capabilities but
| not within my time budget. And there's more potential
| software that fits this bill than software that needs to be
| bridge-stable.
| swatcoder wrote:
| Absolutely.
|
| But the person I replied to seemed to be talking about a
| task agenda for their professional work, not a todo list
| of bespoke little weekend hobby hacks that might be handy
| "around the house".
| iberator wrote:
| Hehe. Try working for some telecoms dealing with gsm, umts,
| LTR and 5g.
| fuzztester wrote:
| or banking. or finance. or manufacturing. or
| $other_enterprise_lob_area.
|
| souce: been there, done some of that.
| legitster wrote:
| Convince your PMs to use an LLM to help "breadboard" their
| requirements. It's a really good use case. They can ask their
| dumb questions they are afraid to and an LLM will do a decent
| job of parsing their ideas, asking questions, and putting
| together a halfway decent set of requirements.
| gitremote wrote:
| PMs wouldn't be able to ask the right questions. They have
| zero experience with developer experience (DevEx) and they
| only have experience with user experience (UX).
| tmp10423288442 wrote:
| You can hope that an LLM might have some instructions
| related to DevEx in its prompt at least. There's no way to
| completely fix stupid, anymore than you can convince a
| naive vibecoder that just vibing a new Linux-compatible
| kernel written entirely in Zig is a feasible project.
| Scarblac wrote:
| How does the LLM get all the required knowledge about the
| domain and the product to ask relevant questions?
| giancarlostoro wrote:
| 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.
| burnt-resistor wrote:
| Hehe. In the "someone should make a website"(tm) department:
| using a crap tons of legacy protocols and plugins semi-
| interoperable with modern while offering legacy browsers
| loaded with legacy plugins something usable to test with,
| i.e.,
|
| - SSL 2.0-TLS 1.1, HTTP/0.9-HTTP/1.1, ftp, WAIS, gopher,
| finger, telnet, rwho, TinyFugue MUD, UUCP email, SHOUTcast
| streaming some public domain radio whatever
|
| - <blink>, <marquee>, <object>, XHTML, SGML
|
| - Java <applet>, Java Web Start
|
| - MSJVM/J++, ActiveX, Silverlight
|
| - Flash, Shockwave (of course), Adobe Air
|
| - (Cosmo) VRML
|
| - Joke ActiveX control or toolbar that turns a Win 9x/NT-XP
| box into a "real" ProgressBar95. ;)
|
| (Gov't mandated PSA: Run vintage {good,bad}ness with care.)
| lawlessone wrote:
| why even write webpages or apps anymore just prompt an LLM
| everytime a user makes a request and write the page to send
| to the user :D
| giancarlostoro wrote:
| This... was a Show HN a little while back, can't tell if
| you're making a joke or referring to that.
| lawlessone wrote:
| oh god, it was a joke, but i want to see that. i hope
| they made it as a joke.
|
| edit: I think i found it
| https://news.ycombinator.com/item?id=45783640
| giancarlostoro wrote:
| To be fair, we have Flash emulators that run in modern
| browsers, and a Shockwave one as well, though it seems to
| be slowing down a bit in traction. Man, VRML brought me
| back. Don't forget VBScript!
| badRNG wrote:
| > Speaking of vibe coding in archaic languages
|
| Well, I think we can say C is archaic when most developers
| write in something that for one isn't C, two isn't a language
| itself written in C, or three isn't running on something
| written in C :)
| psunavy03 wrote:
| (Python has exited the chat)
| shortrounddev2 wrote:
| 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_
| doug_durham wrote:
| 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.
| tshaddox wrote:
| I like my requirements articulated so clearly and unambiguously
| that an extremely dumb electronic logic machine can follow
| every aspect of the requirements and implement them "perfectly"
| (limited only by the physical reliability of the machine).
| deepsun wrote:
| Aka "coding". I see what you mean ;)
| epolanski wrote:
| If AI doesn't make you more productive you're using it wrong,
| end of story.
|
| Even if you don't let it author or write a single line of code,
| from collecting information, inspecting code, reviewing
| requirements, reviewing PRs, finding bugs, hell even
| researching information online, there's so many things it does
| well and fast that if you're not leveraging it, you're either
| in denial or have ai skill issues period.
| mdavidn wrote:
| It sounds like you're the one in denial? AI makes some things
| faster, like working in a language I don't know very well. It
| makes other things slower, like working in a language I
| already know very well. In both cases, writing code is a
| small percentage of the total development effort.
| epolanski wrote:
| No I'm not, I'm just sick of these edgy takes where AI does
| not improve productivity when it obviously does.
|
| Even if you limit your AI experience to finding information
| online through deep research it's such a time saver and
| productivity booster that makes a lot of difference.
|
| The list of things it can do for you is massive, even if
| you don't have it write a single line of code.
|
| Yet the counter argument is like "bu..but..my colleague is
| pushing slop and it's not good at writing code for me",
| come on, then use it at things it's good at, not things you
| don't find it satisfactory.
| lunar_mycroft wrote:
| It "obviously" does based on what, exactly? For most devs
| (and it appears you, based on your comments) the answer
| is "their own subjective impressions", but that METR
| study (https://arxiv.org/pdf/2507.09089) should have
| completely killed any illusions that _that_ is a reliable
| metric (note: this argument works _regardless_ of how
| much LLMs have improved since the study period, because
| it 's about how accurate dev's impressions are, not how
| good the LLMs actually were).
| hu3 wrote:
| not OP but I have a hard metric for you.
|
| AI multiplied the amount of code I committed last month
| by 5x and it's exactly the code I would have written
| manually. Because I review every line.
|
| model: Claude Sonnet 3.5/4.5 in VSCode GitHub Copilot.
| (GPT Codex and Gemini are good too)
| lunar_mycroft wrote:
| I have no reason to think you're lying about the first
| part (although I'd point there's several ways that metric
| could be misleading, and approximately every piece of
| evidence available suggests it doesn't generalize), but
| the second part is very fishy. There's really no way for
| you to know whether or not you'd have written the same
| code or effectively the same code after reviewing
| existing code, especially when that review must be fairly
| cursory (because in order to get the speed up you claim,
| you must be spending much less time reviewing the code
| than it would have taken to write). Effectively, what
| you've done is moved the subjectivity from "how much does
| this speed me up?" to "is the output the same as if I had
| done it manually?"
| hu3 wrote:
| > There's really no way for you to know whether or not
| you'd have written the same code or effectively the same
| code after reviewing existing code.
|
| There is in my case because it's just CRUD code. The
| pattern looks exactly like the code I wrote the month
| prior.
|
| And this is where LLMs excel at, in my experience. "Given
| these examples, extrapolate to these other cases."
| johnsmith1840 wrote:
| It's a good study. I also believe it is not an easy skill
| to learn. I would not say I have 10x output but easily
| 20%
|
| When I was early in use of it I would say I sped up 4x
| but now after using it heavily for a long time some days
| it's 20% other days -20%
|
| It's a very difficuly technology to know when you're one
| or the other.
|
| The real thing to note is when you "feel" lazy and using
| AI you are almost certainly in the -20% category. I've
| had days of not thinking and I have to revert all the
| code from that day because AI jacked it up so much.
|
| To get that speed up you need to be truly focused 100% or
| risk death by a thousand cuts.
| keeda wrote:
| Yes, self-reported productivity is unreliable, but there
| have been other, larger, more rigorous, empirical studies
| on real-world tasks which we should be talking about
| instead. The majority of them consistently show a
| productivity boost. A thread that mentions and briefly
| discusses some of those:
|
| https://news.ycombinator.com/item?id=45379452
| lunar_mycroft wrote:
| Some ( _partial_ ) counter points:
|
| - I think given public available metrics, it's clear that
| this isn't translating into more products/apps getting
| shipped. That could be because devs are now running into
| other bottlenecks, but it could also indicate that
| there's something wrong with these studies.
|
| - Most devs who say AI speeds them up assert numbers
| _much_ higher than what those studies have shown. Much of
| the hype around these tools is built on those higher
| estimates.
|
| - I won't claim to have read every study, but of the ones
| I have checked in the past, the more the methodology
| impressed me the less effect it showed.
|
| - Prior to LLMs, it was near universally accepted wisdom
| that you couldn't really measure developer productivity
| directly.
|
| - Review is imperfect, and LLMs produce worse code on
| average than human developers. That _should_ result in
| somewhat lowered code quality with LLM usage (although
| that might be an acceptable trade off for some). The fact
| that some of these studies didn 't find that is another
| thing that suggests there shortcomings in said studies.
| keeda wrote:
| _> - Most devs who say AI speeds them up assert numbers
| much higher than what those studies have shown._
|
| I am not sure how much is just programmers saying "10x"
| because that is the meme, but if at all realistic numbers
| are mentioned, I see people claiming 20 - 50%, which
| lines up with the studies above. E.g.
| https://news.ycombinator.com/item?id=45800710 and
| https://news.ycombinator.com/item?id=46197037
|
| _> - Prior to LLMs, it was near universally accepted
| wisdom that you couldn 't really measure developer
| productivity directly._
|
| Absolutely, and all the largest studies I've looked at
| mention this clearly and explain how they try to address
| it.
|
| _> Review is imperfect, and LLMs produce worse code on
| average than human developers._
|
| Wait, I'm not sure that can be asserted at all.
| Anecdotally not my experience, and the largest study in
| the link above explicitly discuss it and find that
| proxies for quality (like approval rates) indicate more
| improvement than a decline. The Stanford video accounts
| for code churn (possibly due to fixing AI-created
| mistakes) and still finds a clear productivity boost.
|
| My current hypothesis, based on the DORA and DX 2025
| reports, is that quality is largely a function of your
| quality control processes (tests, CI/CD etc.)
|
| That said, I would be very interested in studies you
| found interesting. I'm always looking for more empirical
| evidence!
| gitremote wrote:
| My company mandates AI usage and logs AI usage metrics as
| input to performance evaluation, so I use it every day. It's
| a Copilot subscription, though.
| cujo wrote:
| why though? are they just using it as a proxy for "is
| 'gitremote' working today?"
| epolanski wrote:
| Someone in management needs a promotion for his impact in
| revolutionizing and streamlining development from his
| charlatan managers.
| porksoda wrote:
| The first time i asked it about some code in a busy
| monorepo and it said "oh bob asked me to do this last
| week when he was doing X, it works like Y and you can
| integrate it with your stuff like Z, would you like to
| update the spec now?"... I had some happy feelings. I
| dont know how they do it without clobbering the context,
| but it's great.
| geraneum wrote:
| Not to refute your point but I've met overly confident people
| with "AI skills" who are "extremely productive" with it,
| while producing garbage without knowing, or not being able to
| tell the difference.
| epolanski wrote:
| You're describing lack of care and lack of professionalism,
| fire these people, nothing to do with the tools, it's the
| person using it the problem.
| ModernMech wrote:
| We're trying very earnestly to create a world where being
| careful and professional is a liability. "Move fast and
| break things, don't ask permission, don't apologize for
| anything" is the dominant business model. Having care and
| practicing professionalism takes times and patience,
| which just translate to missed opportunities to make
| money.
|
| Meanwhile, if you grift hard enough, you can become CEO
| of a trillion dollar company or President of the United
| States. Young people are being raised today seeing that
| you can raise billions on the promise building self
| driving cars in 3 years, not deliver even after 10 years,
| and nothing bad actually happens. Your business doesn't
| crater, you don't get sued into oblivion, your reputation
| doesn't really change. In fact, the bigger the grift, the
| more people are incentivized to prop it up. Care and
| professionalism are dead until we go back to an
| environment that is not so nurturing for grifts.
| impulsivepuppet wrote:
| While I circumstantially agree, I hold it to be self-
| evident that the "optimal amount of grift is nonzero". I
| leave it to politicians to decide whether increased
| oversight, decentralization, or "solution X" is the right
| call to make.
| geraneum wrote:
| Yea I'm talking about people and that's honestly what
| matters here. At the end of the day this tools is used by
| people and how people use it plays a big role in how we
| assess its usefulness.
| mrwrong wrote:
| this is known as the no true scotsman fallacy
| 9rx wrote:
| Garbage to whom? Are we talking about something that the
| user shudders to think about, or something more like a
| product the user loves, but behind the scenes the worst
| code ever created?
| geraneum wrote:
| A lot of important details/parts of a system (not only
| code) that may seem insignificant to the end user could
| be really important in making a a system work correctly
| as a whole.
| MangoCoffee wrote:
| you can say that about overly confident people with "xyz"
| skills.
| SchemaLoad wrote:
| They just shovel the garbage on someone else who has to
| fact check and clean it up.
| omnicognate wrote:
| > Software development jobs must be very diverse if even this
| anti-vibe-coding guy thinks AI coding definitely makes
| developers more productive.
|
| As a Professor of English who teaches programming to humanities
| students, the writer has had an extremely interesting and
| unusual academic career [1]. He sounds awesome, but I think
| it's fair to suggest he may not have much experience of large
| scale commercial software development or be particularly well
| placed to predict what will or will not work in that
| environment. (Not that he necessarily claims to, but it's
| implicit in strong predictions about what the "future of
| programming" will be.)
|
| [1] https://stephenramsay.net/about/
| godelski wrote:
| Hard to say but to back his claim that he was programming
| since the 90's his CV shows he was working on stuff that's
| clearly more than your basic undergraduate skill level since
| the early 2000's. I'd be willing to bet he has more years
| under his belt than most HN users. I mean I'm considered old
| here, in my mid 30's, and this guy has been programming most
| my life. Though that doesn't explicitly imply experience, or
| more specifically experience in what.
|
| That said, I think people really under appreciate how diverse
| programmers actually are. I started in physics and came over
| when I went to grad school. While I wouldn't expect a
| physicist to do super well on leetcode problems I've seen
| those same people write incredible code that's optimized for
| HPC systems and they're really good at tracing bottlenecks
| (it's a skill that translates from physics really really
| well). Hell, the best programmer I've ever met got that way
| because he was doing his PhD in mechanical engineering. He's
| practically the leading expert in data streaming for HPC
| systems and gained this skill because he needed more
| performance for his other work.
|
| There's a lot of different types of programmers out there but
| I think it's too easy to think the field is narrow.
| AceJohnny2 wrote:
| > _I mean I 'm considered old here, in my mid 30's_
|
| _sigh_
| jjgreen wrote:
| I got a coat older than that (and in decent nick).
| bojo wrote:
| I feel like a grandpa after reading that comment now.
| threethirtytwo wrote:
| You can vibe ask the requirements. Not even kidding.
| yieldcrv wrote:
| and in reality, all the separate roles should be deprecated
|
| we vibe requirements to our ticket tracker with an api key,
| vibe code ticket effort, and manage the state of the tickets
| via our commits and pull requests and deployments
|
| just teach the guy the product manager is shielding you from
| not to micromanage and all the frictions are gone
|
| in this same year I've worked at an organization that didn't
| allow AI use at all, and by Q2, Co-Pilot was somehow solving
| their data security concerns (gigglesnort)
|
| in a different organization none of those restrictions are
| there and the productivity boost is through an order of
| magnitude greater
| al_borland wrote:
| 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.
| luckydata wrote:
| Sounds like you work with inexperienced PMs that are not doing
| their job, did you try having a serious conversation about this
| pattern with them? I'm pretty sure some communication would go
| a long way towards getting you on a better collaboration
| groove.
| gitremote wrote:
| I've been doing API development for over ten years and worked
| at different companies. Most PMs are not technical and it's
| the development team's job figure out the technical
| specifications for APIs we build. If you press the PMs, they
| will ask the engineering/development manager for the written
| technical requirements, and if the manager is not technical,
| they will assign it to the developers/engineers. Technical
| requirements for an API are really a system design question.
| burnte wrote:
| "the bigger bottleneck to productivity is that very few people
| can correctly articulate requirements."
|
| I've found the same way. I just published an AI AUP for my
| company and most of it is teaching folks HOW to use AI.
| sureglymop wrote:
| Also that requirements engineering in general isn't being done
| correctly.
|
| I'm the last guy to be enthused about any "ritualistic" seeming
| businessy processes. Just let me code...
|
| However, some things do need actually well defined adhered to
| processes where all parties are aware of and agreeing with the
| protocol.
| keeda wrote:
| This feels like addressing a point TFA did not make. TFA talks
| mostly about vibe-coding speeding up _coding_ , whereas your
| comment is about _software development_ as a whole. As you
| point out, coding is just one aspect of engineering and we must
| be clear about what "productivity" we are talking about.
|
| Sure, there are the overhypers who talk about software
| engineers getting entirely replaced, but I get the sense those
| are not people who've ever done software development in their
| lives. And I have not seen any credible person claiming that
| engineering as whole can be done by AI.
|
| On the other hand, the most grounded comments about AI-assisted
| programming everywhere are about the _code_ , and maybe some
| architecture and design aspects. I personally, along with many
| other commenters here and actual large-scale studies, have
| found that AI _does_ significantly boost coding productivity.
|
| So yes, actual software engineering is much more than coding.
| But note that even if coding is, say, only 25% of engineering
| (there are actually studies about this), putting a significant
| dent in that is still a huge boost to overall productivity.
| pron wrote:
| 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.
| whimsicalism wrote:
| I agree with the first part which is basically 'being able to
| do a software engineers full job' is basically ASI/AGI
| complete.
|
| But I think it is certainly possible that we reach a
| point/plateau where everything is just 'english -> code'
| compilation but that 'vibe coding' compilation step is really
| really good.
| ljm wrote:
| 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.
| ozim wrote:
| Unfortunately a lot of it is also because of illiteracy.
|
| Lots of people hide the fact that they struggle with reading
| and a lot of people hide or try to hide the fact they don't
| understand something.
| 29athrowaway wrote:
| 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.
| nodesocket wrote:
| When building cli and infrastructure tools and using AI my goto
| is go. Pardon the pun.
| kgthegreat wrote:
| On fun/joy in the era of agency -
| https://bikeshedding.substack.com/p/the-agency-continuum
| pfbtgom wrote:
| 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.
| nphardon wrote:
| 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.
| benjiro wrote:
| 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.
| d-lisp wrote:
| 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 ?
| julianeon wrote:
| 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.
| gnatman wrote:
| 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?
| Havoc wrote:
| There are a ton of vibecoded tools on simon's website.
|
| Whether those are substantial enough to count as shipped
| projects is a matter of debate
|
| https://tools.simonwillison.net/
| Barrin92 wrote:
| >Vibe coding actually works. It creates robust, complex systems
| that work.
|
| No it doesn't. Just for the fun of it because I'm somewhat
| familiar with the VLC codebase I tried to fix some bugs with
| "agentic tooling" and "vibe coding". And it just produces crap.
| Which is one metric I'd propose for the usefulness of these
| tools, why aren't they fixing real bugs in the large open source
| codebases of this world? You'd be a hero, VLC has like 4000 open
| issues.
|
| The answer is of course because these tools, in particular in
| manual memory managed languages which the author proposes to use,
| don't work at all. Maybe they work on a toy project of 500 lines
| of code, which is all every demo ever produces, but these text
| based systems have no actual understanding of the hardware
| underlying a complex program. That's just not how they work.
| anactofgod wrote:
| Because, the programming languages best matched to a (natural
| human language-based) declarative programming paradigm (e.g.,
| vibe coding) would be declarative programming languages, not
| imperative programming languages.
| otikik wrote:
| Can it generate good code?
|
| Both the author and I agree in that yes, it can.
|
| Does it always generate good code?
|
| Here is where the author and I disagree vehemently. The author
| implies that the ai-generated code is always correct. My personal
| experience is that it often isn't. Not even for big projects -
| for small bugfixes it also misunderstands and hallucinates
| solutions.
|
| So no C or assembly for me, thank you very much.
| HarHarVeryFunny wrote:
| 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.
| DonHopkins wrote:
| Great point, except for one huge insurmountable non-technical
| problem with Java that can be invoked in a single word:
| lawnmower.
|
| "Do not fall into the trap of anthropomorphizing Larry Ellison.
| You need to think of Larry Ellison the way you think of a
| lawnmower. You don't anthropomorphize your lawnmower, the
| lawnmower just mows the lawn, you stick your hand in there and
| it'll chop it off, the end. You don't think 'oh, the lawnmower
| hates me' -- lawnmower doesn't give a shit about you, lawnmower
| can't hate you. Don't anthropomorphize the lawnmower. Don't
| fall into that trap about Oracle." -Bryan Cantrill
|
| "I actually think that it does a dis-service to not go to Nazi
| allegory because if I don't use Nazi allegory when referring to
| Oracle there's some critical understanding that I have left on
| the table [...] in fact as I have said before I emphatically
| believe that if you have to explain the Nazis to someone who
| had never heard of World War 2 but was an Oracle customer
| there's a very good chance that you would explain the Nazis in
| Oracle allegory." -Bryan Cantrill
|
| https://www.youtube.com/watch?v=-zRN7XLCRhc
|
| Let's please not turn over the future of AI and programming
| languages over to a lawnmower.
| bsoles wrote:
| > It creates robust, complex systems that work. You can tell
| yourself (as I did) that it can't possibly do that, but you are
| wrong.
|
| Then show us this robust, complex code that was produced by vibe
| coding and let us judge for ourselves.
| nickpsecurity wrote:
| My concept was to build HLL to C/C++ (or Rust) translators using
| mostly, non-AI tech. Then, use AI's with whatever language they
| were really good at. Then, transpile it.
|
| Alternatively, use a language like ZL that embeds C/C++ in a
| macro-supporting, high-level language (eg Scheme). Encode higher
| level concepts in it with generation of human-readable, low-level
| code. F* did this. Now, you get C with higher-level features we
| can train AI's on
| raphlinus wrote:
| There's a straightforward answer to the "why not" question:
| because it will result in codebases with the same kind of memory
| unsafety and vulnerability as existing C code.
|
| If an LLM is in fact capable of generating code free of memory
| safety errors, then it's certainly also capable of writing the
| Rust types that guarantee this and are checkable. We could go
| even further and have automated generation of proofs, either in C
| using tools similar to CompCert, or perhaps something like ATS2.
| The reason we don't do these at scale is that they're tedious and
| verbose, and that's presumably something AI can solve.
|
| Similar points were also made in Martin Kleppmann's recent blog
| post [1].
|
| [1]: https://martin.kleppmann.com/2025/12/08/ai-formal-
| verificati...
| nu11ptr wrote:
| 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).
| benjiro wrote:
| > It is also equally odd to me that people want to cling so
| hard to C, when something like Rust (and other modern
| languages for that matter), have so much nicer eco systems,
| memory safety aside.
|
| Simplicity? I learned Rust years ago (when it was still pre
| release), and when i now look at a lot of codebases, i can
| barely get a sense what is going on, with all the new stuff
| that got introduced. Its like looking at something familiar
| and different at the same time.
|
| I do not feel the same when i see Go code, as so little has
| changed / got added to it. The biggest thing is probably
| generics and that is so rarely used.
|
| For me, this is, what i think, appeals for C programmers. The
| fact that the language does not evolve and has been static.
|
| If we compare this to C++, that has become a mess over time,
| and i know i am getting downvoted for this, Rust feels like
| its going way too much in the Rust++ route.
|
| Like everybody and their dog wants something added, to make
| Rust do more things, but at the same moment, it feels like
| its repeating the C++ history. I have seen the same issue
| with other languages that started simple, and then becomes
| monsters of feature sets. D comes to mind.
|
| So when you see the codebase between developers, the
| different styles because of the use of different feature
| sets, creates this disconnect and makes it harder for people
| to read other code. While with C, because of the language
| limits, your more often down a rather easier way to read the
| same code. If that makes sense?
| doug_durham wrote:
| 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.
| raphlinus wrote:
| Memory safety in particular, actually UB in general (got to
| watch out for integer overflows, among other things). But one
| could prove arbitrary properties, including lack of panics
| (would have been helpful for a recent Cloudflare outage),
| etc.
|
| In order to prove lack of UB, you have to be able to reason
| about other things. For example, to safely call qsort, you
| have to prove that the comparison is a total order. That's
| not easy, especially if comparing larger and more complicated
| structures with pointers.
|
| And of course, proving the lack of pointer aliasing in C is
| _extremely_ difficult, even more so if pointer arithmetic is
| employed.
| IshKebab wrote:
| In this context it's proofs of properties about the program
| you're writing. A classic one is that any lossless
| compression algorithm should satisfy decompress(compress(x))
| == x for any x.
| m4ck_ wrote:
| filthy vibe coder here
|
| I'm planning to, why bother with react when I can jump straight
| into WASM?
| HarHarVeryFunny wrote:
| Because the LLM has presumably been trained on more React than
| WASM, and will do a better job of it.
|
| ya filthy animal!
| jedbrooke wrote:
| 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
| morshu9001 wrote:
| Context limit and build time are a couple of reasons. There is
| C++ code at work I told it to rewrite in Python just to make it
| easier to vibecode (or regular code) after. Granted, it had no
| good reason to be in C++ in the first place.
| nialv7 wrote:
| This is such a bad take I don't even know where to start... Even
| if you think vibe coding _is_ the future, there are still so many
| things wrong about this article. It's like the author has a
| fundamental misunderstanding why we even create programming
| languages.
| doug_durham wrote:
| I actually think that they have a good handle on the motivation
| for programming languages design. Think about C. C has many
| features that serve programmer ergonomics. The use of "=" for
| assignment and the use of "++" for incrementing there to serve
| the developer by reducing keystrokes. Yes there are some
| languages that are developed to be more formal, but that isn't
| the mainstream.
| enriquto wrote:
| > why not do it in C?
|
| Well, because you can do it in Fortran, of course!
|
| What else do you want? Multidimensional arrays out of the box,
| fast loops, native cuda support, trivial build and packaging
| system, zero version churning... all of this just with the bare
| language. It's the anti-python! The perfect language, you could
| say! Strings and i/o are a bit cumbersome, agreed, but your llm
| can take care of these without any trouble, no matter the
| language.
| DonHopkins wrote:
| I like the cut of your jib.
| zelphirkalt wrote:
| 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.
| hadlock wrote:
| He says in his article:
|
| >Is C the ideal language for vibe coding? I think I could mount
| an argument for why it is not, but surely Rust is even less
| ideal.
|
| I've been using Rust with LLMs for a long time (mid-2023?) now;
| cargo check and the cargo package system make it very easy for
| LLMs to check their work and produce high quality code that
| almost never breaks, and always compiles.
| ModernMech wrote:
| My favorite use for LLMs with Rust is using them as a macro
| debugger; they provide better error messages than the errors
| Cargo can provide. It's cool to take a macro and ask the LLM
| to do an expansion of it, to see what it would look like. Or,
| to take Rust code and ask the LLM to create a macro for it.
| didibus wrote:
| 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.
| vibeleaker wrote:
| 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.
| wilg wrote:
| If you're vibe coding, I highly recommend TDD. It makes it very
| easy for a coding agent to iterate on it. You gotta bonk it
| sometimes when it tries to delete a problematic test etc, but
| hallucinating a test suite along with your app really helps a
| lot. (I've been vibe coding a scripting language/compiler for a
| video game project I'm working on in this way, and it's been
| fascinating and mostly great.)
| Havoc wrote:
| Do you write the test yourself or get the agent to do it?
| hu3 wrote:
| No OP but I also guide LLMs with TDD and it's a mixture of
| LLMs write tests for happy paths and I write tests for edge
| cases.
|
| Also when I use LLM to fix a bug, I tell it to write a test
| to prevent regression of the bug at the end of the session,
| after the bug is fixed.
| wilg wrote:
| I try to get the agent to create a failing test first, so
| we can verify its fix is real.
| wilg wrote:
| I get the agent to do it generally. (I realize this seems
| incestuous, but its fairly easy to validate the tests are
| sensible as you add features, because the biggest risk is
| regressions as the AI does something dumb later.)
| pmarreck wrote:
| At that point, why not develop a custom language or IL that is
| specifically designed for LLM use and which compiles to good
| native code?
|
| I propose WASM, or an updated version of it
| skydhash wrote:
| Because LLMs will have no concept of that IL. It only have a
| model for what it has seen.
| awesome_dude wrote:
| 100%
|
| People are still confusing AI putting together scraps of text
| it has seen that correlates with its understanding of the
| input, with the idea that AI understands causation, and
| provides actual answers.
| 9rx wrote:
| Oh? I've had great luck with LLMs and homemade ILs. It has
| become my favourite trick to get LLMs to do complex things
| without overly complicating my side of the equation (i.e.
| parsing, sandboxing, etc. that is much harder to deal with if
| you have it hand you the code of a general purpose language
| meant for humans to read).
|
| There is probably some point where you can go so wild and
| crazy with ideas never seen before that it starts to break
| down, but if it remains within the realm of what the LLM can
| deal with in most common languages, my experience says it is
| able to pick up and apply the same ideas in the IL quite
| well.
| Imnimo wrote:
| 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.
| Uehreka wrote:
| 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.
| markstos wrote:
| 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.
| ActorNightly wrote:
| > The agent forgets to free memory latter just like a human
| would and has to go back and fix it later.
|
| I highly recommend people learn how to write their own agents.
| Its really not that hard. You can do it with any llm model,
| even ones that run locally.
|
| I.e you can automate things like checking for memory freeing.
| VertanaNinjai wrote:
| Do you have any good starting points? For example, if someone
| had an ollama or lm studio daemon running where would they go
| from that point?
| yberreby wrote:
| > I.e you can automate things like checking for memory
| freeing.
|
| Or, if you don't _need_ to use C (e.g. for FFI or platform
| compatibility reasons), you could use a language with a
| compiler that does it for you.
| ModernMech wrote:
| Right, a lot of the promise of AI can (and has) been
| achieved with better tool design. If we get the AI to start
| writing Assembly or Machine Code as some people want it to,
| we're going to have the same problems with AI writing in
| those languages as we did when humans had to use them raw.
| We invented new languages because we didn't find those old
| ones expressive enough, so I don't exactly understand the
| idea that LLMs will have a better time expressing
| themselves in those languages. The AI forgetting to free
| memory in C and having to go back and correct itself is a
| perfect example of this. We invented new tools so we
| wouldn't have to do that anymore, and they work. Now we are
| going backwards, and building giant AI datacenters that
| suck up all the RAM in the world just to make up for lost
| ground? Weak.
| eternityforest wrote:
| Why would I want to have an extra thing to maintain, on top
| of having to manually review, debug, and write tests for a
| language I don't like that much?
| lowbloodsugar wrote:
| Sure. Or you can let the language do that for you and spend
| your tokens on something else. Like, do you want your LLM to
| generate LLVM byte code? It could, right? Buy why wouldn't
| you let the compiler do that?
| J_Shelby_J wrote:
| I use rust. The compiler is my agent.
|
| Or to quote Rick and Morty, "that's just rust with extra
| steps!"
| greenavocado wrote:
| I just wrote a piece on this specific C issue the other day
| https://news.ycombinator.com/item?id=46186930
| synergy20 wrote:
| well,glib is terrible for anything important, it's really
| just for desktop apps. when there is a mem error, glib does
| not really handle it,it just aborts. ok for desktop, not ok
| for anything else.
| greenavocado wrote:
| I addressed this in the first sentence of the second post
| (g_try_malloc) in a direct reply to my original post:
| https://news.ycombinator.com/item?id=46186931
| chis wrote:
| 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.
| jesse__ wrote:
| I don't think it has much to do with the languages being
| harder .. the training sets for JS and Python are probably an
| order of magnitude larger.
| Supermancho wrote:
| More examples/better models and less footguns. In
| programming, the fewer (assumed correct) abstractions, the
| more room for error. Humans learned this awhile ago, which
| is why your average programmer doesn't remember a lick of
| ASM, or have to. One of the reasons I don't trust vibe
| coding lower level languages is that I don't have multiple
| tools with which to cross check the AI output. Even the
| best AI models routinely produce code that does not
| compile, much less account for all side effects. Often, the
| output outright curtails functionality. It casually makes
| tradeoffs that a human would not make (usually). In C, AI
| use is a dangerous proposition.
| UncleOxidant wrote:
| > It's really funny how much better the AI is at writing
| python and javascript than it is C/C++. For one thing it
| proves the point that those languages really are just way
| harder to write.
|
| I have not found this to be the case. I mean, yeah, they're
| really good with Python and yeah that's a lot easier, but I
| had one recently (IIRC it was the pre-release GPT5.1) code me
| up a simulator for a kind of a microcoded state machine in
| C++ and it did amazingly well - almost in one-shot. It can
| single-step through the microcode, examine IOs, allows you to
| set input values, etc. I was quite impressed. (I had asked it
| to look at the C code for a compiler that targets this
| microcoded state machine in addition to some Verilog that
| implements the machine in order for it to figure out what the
| simulator should be doing). I didn't have high expectations
| going in, but was very pleasantly surprised to have a working
| simulator with single-stepping capabilities within an
| afternoon all in what seems to be pretty-well written C++.
| nylonstrung wrote:
| I think arenas might be better memory management technique when
| vibe coding C, for this reason
| whiatp wrote:
| 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.
| sureglymop wrote:
| 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.
| UncleOxidant wrote:
| > 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).
| unoti wrote:
| > Why vibe code with a language that has human convenience and
| ergonomics in view?
|
| Recently I've been preparing a series that teaches how to use AI
| to assist with coding, and in preparation for that there's this
| thing I've coded several times in several different languages. In
| the process of that, I've observed something that's frankly
| bizarre: I get a 100% different experience doing it in Python vs
| C#. In C#, the agent gets tripped up in doing all kinds of
| infrastructure and overengineering blind alleys. But it doesn't
| do that when I use Python, Go, or Elixir.
|
| My theory is that there are certain habits and patterns that the
| agents engage with that are influenced by the ecosystem, and the
| code that it typically reads in those languages. This can have a
| big impact on whether you're achieving your goals with the
| activity, either positive or negative.
| awesome_dude wrote:
| This kind of meets with my experience - AI tends to follow
| specific patterns for each language, earlier this year I was
| finding that AI was presenting me with 4 different approaches
| to a problem, none of them were working so it would cycle
| through each of the four approaches.
|
| I lost a day chasing my tail cycling through those 4
| approaches, but the experience was worthwhile (IMO) because I
| had beeen becoming lazy and relying on AI too much, after that
| I switched to a better style of using AI to help me find those
| approaches, and as a sounding board for my ideas, whilst
| staying in control of the actual code.
|
| (Oh, I should also mention that AI's conviction/confidence did
| cause me to believe it knew what it was talking about when I
| should have backed myself, but, again, experience is what you
| get after you needed it :)
| bambax wrote:
| > _Or hell, why not do it in x86 assembly?_
|
| I do vibe code in C; I'm not a C programmer and I certainly
| couldn't do a security audit of any serious C codebase, but I can
| read and understand a simple C program, and debug and refactor it
| (as long as it's still quite simple).
|
| And it's super fun! Being able to compile a little C utility that
| lives in the Windows tray and has a menu, etc. is exhilarating.
|
| But I couldn't do that in assembly; I would just stare at
| instructions and not understand anything. So, yes for C, no for
| assembly.
| knicholes wrote:
| Cost, right? C uses more tokens by declaring the types. Better to
| go to a higher level abstraction to use as few tokens as possible
| to save on $$.
| randallsquared wrote:
| In which case, should we aim for J or APL? :)
| lalaithion wrote:
| 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.
| 701mk wrote:
| So in a way we do TDD and let the vibe machine code the system
| against the tests :)
| TomasBM wrote:
| I guess _vibe coding_ is fun as a meme, but it hides the power of
| (what someone else on HN) called _language user interfaces_
| (LUIs).
|
| The author's point is correct IMO. If you have direct mappings
| between assembly and natural language, there's no functional need
| for these intermediate abstractions to act as pseudo-LUIs. If you
| could implement it, you would just need two layers above
| assembly: an _LLM OS_ [1], and a LUI-GUI combo.
|
| However, I think there's a non-functional, quality need for
| intermediate abstractions - particularly to make the mappings
| auditable, maintainable [2], understandable, etc. For most
| mappings, there won't be a 1:1 representation between a word and
| an assembly string.
|
| It's already difficult for software devs to balance technical
| constraints and possibilities with vague user requirements. I
| wonder how an LLM OS would handle this, and why we would trust
| that its mappings are correct without wanting to dig deeper.
|
| [1] Coincidentally, just like "vibe coding", this term was
| apparently also coined by Andrej Karpathy.
|
| [2] For example, good luck trying to version control vectors.
| dev_l1x_be wrote:
| Because I can do it in Rust that is much closer to the domains I
| work on?
| INTPenis wrote:
| Because I don't know C well enough.
|
| My philosophy regarding AI is that you should never have it do
| something you couldn't do yourself.
|
| Of course people break this rule, or the concept of vibe coding
| wouldn't exist. But some of us actually get a lot of value from
| AI without succumbing to it. It just doesn't make sense to me to
| trust a machine's hallucinations for something like programming
| code. It fabricates things with such confidence that I can't even
| imagine how it would go if I didn't already know the topic I had
| it work on.
| pmdr wrote:
| > Because I don't know C well enough.
|
| Same here. I can read and understand most of it, but not enough
| to debug it. And outsourcing that task to Claude is like taking
| a long winding path through thick, dark woods.
| peteforde wrote:
| 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.
| didibus wrote:
| 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.
| dbfclark wrote:
| 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.
| jszymborski wrote:
| I also don't _love_ vibe coding and do it just for
| exploration/recreation, but I also have long thought an LLM
| trained and tuned specifically for a language that is best for
| LLMs might be ideal.
|
| Currently, using Claude to vibe code Rust is _much_ more hit-or-
| miss than using it for Python... so Python has become the lingua
| franca or IR I use with it.
|
| Often I'll ask Claude to implement something in Python, validate
| and correct the implementation, and in a separate session ask it
| to translate it from Python to Rust (with my requirements). It
| often helps.
|
| Claude is particularly bad at hallucinating the APIs of Crates,
| something it does a lot less for python.
| 2bluesc wrote:
| 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.
| parasti wrote:
| 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.
| TylerLives wrote:
| I don't have much experience with it either, but what has
| worked so far is breaking down the problem into very small
| steps I can verify easily.
| russfink wrote:
| 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.
| tasuki wrote:
| I want to do my vibe coding in a dependently typed language, so
| that at least I can tell what the inputs and outputs are. I say
| Idris is the future!
|
| Or... I want to only write the tests. The implementation is... an
| implementation detail!
| PaulHoule wrote:
| 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.
| gsf_emergency_6 wrote:
| The S-SHI would use an advanced subset of C, called "K" (after
| Kohut, so it's in uppercase)
| mcny wrote:
| > 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.
| synergy20 wrote:
| c is a small language thus more understandable and readable
| than others? e g. java,rust,c++ can get really complicated to
| read sometimes.
|
| python though is very readable, not so much for typescript for
| me.
| deathanatos wrote:
| > _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".)
| joshribakoff wrote:
| While its thought provoking no one can claim to know the future
| with absolute certainty.
| nye2k wrote:
| I have been developing a game with this process, specifically for
| portability, reach and distribution across multiple game engines
| and platforms.
|
| I find CUX to be very intuitive for prototyping. But my game is
| Language and HCI at heart, logic that allows the development
| process to go smoothly. It is certainly not for everyone or every
| project.
| tmsbrg wrote:
| 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.
| wavemode wrote:
| > 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.
| teach wrote:
| Sounds like Ada. A lot of the time, once you got your code to
| compile, it would work.
| jlouis wrote:
| 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.
| nylonstrung wrote:
| Lean would be so well suited to LLMs. I hope we see a
| resurgence in interest in languages like that
|
| Formal proofs have so much potential in this context
| WhereIsTheTruth wrote:
| Forward declaration is the only reason why I moved away from C,
| so much time wasted..
| BiteCode_dev wrote:
| - 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.
| lowsong wrote:
| > Vibe coding actually works. It creates robust, complex systems
| that work. You can tell yourself (as I did) that it can't
| possibly do that, but you are wrong.
|
| This is such a bad take. I'm convinced that engineers simply
| don't understand what the job is. The point was never "does it
| output code that works", the point is "can it build the _right
| thing_ in a way that is _maintainable_ and _understandable_ ". If
| you need an LLM to understand the output then you have failed to
| engineer software.
|
| If all you're doing is spitting out PoCs and pure greenfield
| development then I'm sure it looks very impressive, as the early
| language models did when it looked like they were capable of
| holding a conversation. But 99% of software engineering is not
| that kind of work.
| elif wrote:
| I would say, because time to review is the most important metric
| in vibe coding.
|
| I prompt my agents to use proper OO-encapsulated idiomatic ruby
| paradigms. Your goal should be reduced cognitive load.
|
| Even if you never write a line of code, you will still need to
| understand your problems to solve them.
|
| "Vibe debugging" will get you stuck in loops of hallucinated
| solutions.
| oleganza wrote:
| I asked ChatGPT what traits should vibe-oriented programming
| language have and oh boy did it deliver.
|
| (https://chatgpt.com/share/693891af-d608-8002-8b9b-91e984bb13...)
|
| * boring and straightforward syntax and file structure: no syntax
| sugar, aliases, formatting freedom that humans cherish, but
| machines are getting confused, no context-specific syntax.
|
| * explicitness: no hidden global state, shortcuts and UB
|
| * basic static types and constraints
|
| * tests optimized for machine evaluation
|
| etc.
| phendrenad2 wrote:
| I think this is the future. We'll probably end up with some
| variant of Perl (joking - or am I?)
| BobBagwill wrote:
| Vibe Coding is just a stepping stone to No Coding.
|
| No one (other than computer people) wants computers and software,
| they want results.
|
| This generation of AI will be used to bootstrap the next
| generation of AI.
|
| Programmers getting excited about vibe coding is like
| candlemakers getting excited about installing electric lights in
| their shops, so they can make more candles!
| esafak wrote:
| Or a stepping stone to starting a lighting company. The nature
| of programming changes when implementation can be automated.
| That still leaves higher level concerns like design and
| architecture.
| postalrat wrote:
| Many programmers became programmers because they love
| technology and vibe coding is about the coolest technology
| we've seen in a long time.
| BobbyJo wrote:
| I think the author glosses over a core problem AI would need to
| overcome for his thoughts to become reality: training data.
|
| We can't teach AI to code in languages that do not have human
| ergonomics because, as of now, all AI is based on human example.
| letmeinhere wrote:
| 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.
| ghiculescu wrote:
| Along the same lines, I am rewriting a React Native app into
| native Swift and Kotlin versions. I haven't written any of the
| native code directly - it's all vibed. It's not C but there's a
| lot of upside in letting Claude Code compile my wishes into
| native languages and skip the RN layer.
| sebastianconcpt wrote:
| > Why vibe code with a language that has human convenience and
| ergonomics in view?
|
| Because you would not be able to audit the code if you don't
| (you'll be terribly slow to read and understand the inner flows
| correctly and that's if these aren't so bad that would do you
| some brain damage).
|
| Dang, AI is pushing us all to become managers.
| s17n wrote:
| 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.
| simonw wrote:
| I've vibe coded a few things in C now as experiments, but I
| haven't been brave enough to put _any_ of them into production
| code yet. I don 't trust myself to review them properly.
|
| C extensions for SQLite:
| https://simonwillison.net/2024/Mar/23/building-c-extensions-...
|
| This one is closest to something I might use because it's C
| compiled to WebAssembly, so the blast radius for any dumb bugs is
| strictly limited:
| https://github.com/simonw/research/blob/main/cmarkgfm-in-pyo...
| rudimentary_phy wrote:
| I wish I could convey my thoughts that well!
|
| On the topic: I feel like we still need at least a few more
| innovations in the space before we can rely on them to work in
| areas where we as humans still have trouble (that pesky training
| data!). Even when providing documentation, I still find LLMs to
| often have trouble creating code in newer versions of libraries.
|
| My biggest fear with LLMs is that it will steer a lot of
| development into a more homogenous space over time (even just
| with the types and versions of libraries it chooses when vibing).
| spjt wrote:
| Why not do it in English? I have a "program" that exists entirely
| as the history of an AI chatbot session. To "run the program" I
| load the history and a file into the message context and say "Now
| do this file." It kind of reminds me of a Smalltalk VM in a weird
| way.
| UncleOxidant wrote:
| But I _have_ been vibe coding in C. Created a parser /compiler
| for a subset of the C programming language that compiles to
| microcode for a novel computing architecture. Could I have done
| this on my own? Sure, but if I did I would've probably have done
| it in OCaml. And it would've taken me a lot longer to get it to
| the point where it is now. I think the advantage of vibe coding
| this (at least for me) is that I would have a hard time getting
| started due to procrastination - and I'd have a hard time keeping
| interested if there wasn't something working (yeah, maybe I'm a
| little ADHD, but aren't we all at this point?). Vibe coding it
| got me to something that was working pretty well in a
| surprisingly short amount of time which tended to make me more
| engaged without losing interest and attention. I didn't have to
| get caught up in remembering the intricacies of creating a
| makefile to build the code, for example. That's one of many
| places where I can get bogged down.
| pizlonator wrote:
| 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)
| xormapmap wrote:
| > 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.
| keybored wrote:
| It's easy to answer why old-fashioned programming feels better to
| many people. It's just alienation, or rather the relative lack
| of. It's fulfilling to do things in a way that makes you feel
| like you have agency and are causing things to happen in ways
| that make sense to your own sense organs. It doesn't even matter
| if "you" are doing it or "the tools" are doing the heavy lifting
| --who are _you_ anyway, your thoughts, your tiny conscious mind
| on top of the iceberge of the unconscious?--, so you don't have
| to get into the stupid quagmire ranging from "but abstractions
| and compilers" to "but Kant showed that thing-in-itself is
| different from the thing-as-sensed", no, it's fine, really; we
| all know (sense) when we feel in control or not.
|
| But anyway. That's all besides the point. Because the _progress
| apologists[1]_ come in all shapes and forms (we are lead to
| believe), now also uber-passionate college professor who _aah_
| loves programming as much as the day he met her. But unlike you
| he's a hard-prostheticed pragmatist. He both knows and
| sympathises with your "passion" but is ready to assert, in a
| tptacek-memetic style, that it is the way it is--and if you think
| otherwise (pause for effect), you are wrong.
|
| Because _don't you see?_ Why are you so blind? No, we can't let
| the chips fall as they may and just send you a "told you so"
| letter once everything you know-now is resolutely _quaint_. No,
| we must assert it right now. (So you don't miss out on the
| wonderful ride.)
|
| _Aah_ the text complains. _It saddens me to think of "coding by
| hand" becoming a kind of quaint Montessori-school..._ Oh, the
| twists and turns of the turbulent text, so organic. Just like
| your mind. But awake.
|
| The room is at this point drenched in a mist of farts. _Yes_ ,
| programming by-hand, I think we ought to call it a quaintism at
| this point.
|
| And did you know: people used to resist mechnical computers. Hmm?
| Yes, indeed, favoring people computers. The text prompts for
| another model to make an image of a person smirking so hard that
| their eyes become kind of diagonal and their cheeks disappear.
| But not in an evil cartoon character way. In a human way. That
| three years ago felt slightly off-putting. Now just looks like,
| well, you know.
|
| - - -
|
| Ahh. (Again.) These fools. With their hand-coding. Do they really
| think they will be employable three years from now? Well, no
| matter. I have a PhD from MIT along with my associate
| professorship. I only came out here to Iowa Community College
| because of my disabled son. Needed more time with him. And to get
| away from dat citation grind. Man. I have many organic hobbies.
| And a few very, really incredibly specific collections, as is
| fitting. _puffs pipe_ Mmm yeah what do I care, so what if
| programming is quaint now--I'm already in my "ivory tower", baby.
| People will listen to my takes on AI. They are appropriately
| detached, informal, just saying it like it is, you know? And if
| they don't? Well, there's an army of texts right behind me.
| They'll be convinced to suppress any feelings of alienation
| eventually. Eventually, there will just be their own vanishing,
| small-minded, petty, "thoughts" on the matter. That tiny holdout.
| Against all content they can sense.
|
| [1] Insert scare quotes here. All history is whitewashed. "We"
| progressed and defeated "them". It's all just a linear curve. No
| critical thinking is supposed to occur here. Those idiots thirty
| years ago used reusable underwear and had to load detergent into
| a washing machine and then even bend over to turn on a "button"
| to make the underwear reusable. Our underwear costs fifty cents,
| is made from the most comfortable plastic you can get, and
| dissolves and crumbles when it gets into contact with water; down
| the bathroom drain it goes.
| pcblues wrote:
| 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.
| 0xbadcafebee wrote:
| [delayed]
___________________________________________________________________
(page generated 2025-12-09 23:00 UTC)