6 ms·

>Yegge is leaning into the true definition of vibecoding with this project: “It is 100% vibecoded. I’ve never seen the code, and I never care to.” I don't get

>Yegge is leaning into the true definition of vibecoding with this project: “It is 100% vibecoded. I’ve never seen the code, and I never care to.” I don't get it. Even with a very good understanding of what type of work I am doing and a prebuilt knowledge of the code, even for very well specced problem. Claude code etc. just plain fail or use sloppy code. How do these industry figures claim they see no part of a 225K+ line of code and promise that it works? It feels like we're getting into an era where oceans of code which nobody understands is going to be produced, which we hope AGI swoops in and cleans?

bbayles 9mo ago
I'm sympathetic to this view, but I also wonder if this is the same thing that assembly language programmers said about compilers. What do you mean that you never look at the machine code? What if the compiler does something inefficient?
- 3vidence 9mo ago
  This analogy has always been bad any time someone has used it. Compilers directly transform via known algorithms. Vibecoding is literally just random probabilistic mapping between unknown inputs and outputs on an unknown domain. Feels like saying because I don't know how my engine works that my car could've just been vibe-engineered. People have put 1000s of hours into making certain tools work up to a give standard and spec reviewed by many many people. "I don't know how something works" != "This wasn't thoughtfully designed" Why do people compare these things.
- jplusequalt 9mo ago
  >but I also wonder if this is the same thing that assembly language programmers said about compilers But as a programmer writing C code, you're still building out the software by hand. You're having to read and write a slightly higher level encoding of the software. With vibe coding, you don't even deal with encodings. You just prompt and move on.
  - zerkten 9mo ago
    I've wondered if people who write detailed specs, are overly detailed, are in a regulated industry, or even work with offshore teams have success more quickly simply they start with that behavior. Maybe they have a tendency to dwell before moving on which may be slightly more iterative than someone who vibecodes straight through.
- gegtik 9mo ago
  I wonder if assembly programmers felt this way about the reliability of the electical components which their code relies upon...
  - beklein 9mo ago
    I wonder if electrical engineers felt this way about the reliability of the silicon crystal lattice their circuits rely upon…
- 7777332215 9mo ago
  The compiler is deterministic and the translation does not lose semantics. The meaning of your code is an exact reflection of what is produced.
  - fragmede 9mo ago
    We can tell you weren't around for the advent of compilers. To be fair, neither was I since the UNIX c compiler came out in '68 and was by far not the first compiler. Modern comilers you can make that claim about, but early compilers weren't.
    - tjr 9mo ago
      Which early compilers were nondeterministic?
    - recursive 9mo ago
      All compilers have bugs. Any loss of semantics during compilation would be considered a bug. In order to do that, the source and target language need to be structured and specified. I wasn't around in the 60s either, but I think that hasn't changed.
    - georgemcbay 9mo ago
      I've been programming since 6502/6510 assembly language and all compilers I've used were deterministic (which isn't the same thing as being bug free or producing the correct output for a given input).
      - fragmede 9mo ago
        Bullshit.
- anonymous908213 9mo ago
  No, it is not what assembly programmers said about compilers, because you can still look at the compiled assembly, and if the compiler makes a mistake, you can observe it and work around it with inline assembly or, if the source is available, improve the compiler. That is not the same as saying "never look at the code".
- hilbertseries 9mo ago
  I feel like this argument would make a lot more sense if LLMs had anywhere near the same level of determinism as a compiler.
- deleted 9mo ago
  [deleted]
- conartist6 9mo ago
  I write JS, and I have never directly observed the IRs or assembly code that my code becomes. Yet I certainly assume that the compiler author has looked at the compiled output in the process of writing a compiler! For me the difference is prognosis. Gas Town has no ratchet of quality: its fate was written on the wall since the day Steve decided he didn't want to know what the code says: it will grow to a moderate but unimpressive size before it collapses under its own weight. Even if someone tried to prop it up with stable infra, Steve would surely vibe the stable infra out of existence since he does not care about that
  - luckydata 9mo ago
    or he will find a way to get the AI to create harnesses so it becomes stable. The lack of imagination and willingness to experiment in the HN crowd is AMAZING me and worrying me at the same time. Never thought a group of engineers would be the most conservative and close minded people I could discuss with.
    - conartist6 9mo ago
      It's a paradox, huh. If the AI harness became so stable it wrote good code he wouldn't be afraid to look at the code he would be eager to look at it, right? But then if it mattered if AI wrote good code or not he couldn't defend his position that the way to create value with code is quantity over quality. He needs to sell the idea of something only AI can do, which means he needs the system to be made up of a lot of bad or low quality code which no person would ever want to be forced to look at.
    - vardalab 9mo ago
      Wait till you meet engineers other than sw engineers. Not even sure most sw people should be called engineers since there are no real accredited standards. I specifically trained as EE in physical electronics because other disciplines at the time seemed really rigid. There's a saying that you don't want optimists building bridges.
    - troupo 9mo ago
      There's a difference between "imagination and willingness to experiment" and "blind faith and gullibility".
- gtowey 9mo ago
  Not even remotely close. Compilers are deterministic. People who write them test that they will produce correct results. You can expect the same code to compile to the same assembly. With LLMs two people giving the exact same prompts can get wildly different results. That is not a tool you can use to blindly ship production code. Imagine if your compiler randomly threw in a syscall to delete your hard drive, or decide to pass credentials in plain text. LLMs can and will do those things.
  - knowknow 9mo ago
    Not only that but compiler optimizations are generally based on rigorous mathematical proofs, so that even without testing them you can be pretty sure it will generate equivalent assembly. From the little I know of LLM's, I'm pretty sure no one has figured out what mathematical principles LLM's are generating code from so you cant be sure its going to right aside from testing it.
  - alecbz 9mo ago
    Even ignoring determinism, with traditional source code you have a durable, human-readable blueprint of what the software is meant to do that other humans can understand and tweak. There's no analogy in the case of "don't read the code" LLM usage. No artifacts exist that humans can read or verify to understand what the software is supposed to be doing.
    - luckydata 9mo ago
      yeah there is. it's called "documentation" and "requirements". And it's not like you can't go read the code if you want to understand how it works, it's just not necessary to do so while in the process of getting to working software. I truly do not understand why so many people are hung up on this "I need to understand every single line of code in my program" bs I keep reading here, do you also disassemble every library you use and understand it? no, you just use it because it's faster that way.
      - notpachet 9mo ago
- crote 9mo ago
  The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice. It also doesn't involve any "creativity": a compiler is mostly translating a high-level concept into its predefined lower-level components. I don't know exactly what my code compiles to, but I can be pretty certain what the general idea of the assembly is going to be. With LLMs all bets are off. Is your code going to import leftpad, call leftpad-as-a-service, write its own leftpad implementation, decide that padding isn't needed after all, use a close-enough rightpad instead? Who knows! It's just rolling dice, so have fun finding out!
  - fragmede 9mo ago
    > The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice. That's barely true now. Nix comes close, but builds are only bit-for-bit identical if you set a bunch of extra flags that aren't set by default. The most obvious instability is CPU dispatch order (aka modern single computer systems are themselves distributed, racy systems) changes the generated code ever so slightly. We don't actually care, because if one compiled version of the code uses r8 for a variable but a different compilation uses r9 for that variable, it doesn't matter because we just assume the resulting binary works the same either way. R8 vs r9 are implementation details that don't matter to humans. See where I'm going with this? If the LLM non-deterministically calls the variable fileName one day, and file_name the next time it's given the same prompt, yeah language syntax purists are going to suffer an aneurysm because one of those is clearly "wrong" for the language in use, but it's really more of an implementation detail at this point. Obviously you can't mix them, the generated code has to be consistent in which one it's using, but if compilers get to chose r8 one day and r9 the next, and we're fine with it, why is having the exact variable name that important, as long as it's being used correctly?
    - tjr 9mo ago
      I’ve done builds for aerospace products where the only binary difference between two builds of the same source code is the embedded timestamp. And per FAA review guidelines, this deterministic attribute is required, or else something is wrong in the source code or build process. I certainly don’t use all compilers everywhere, but I don’t think determinism in compilation is especially rare.
anonymous908213 9mo ago
The secret is that it doesn't work. None of these people have built real software that anyone outside their bubble uses. They are not replacing anyone, they are just off in their own corner building sand castles.
- causalmodels 9mo ago
  It is fine to have criticisms of this, I have many, but saying that Yegge hasn't built real software is just not true.
  - anonymous908213 9mo ago
    Yegge obviously built real software in the past. He has not built real software wherein he never looked at the code, as he is now promoting.
    - causalmodels 9mo ago
      Ok but this entire idea is very new. Its not an honest criticism to say no one has tried the new idea when they are actively doing it. Honestly I don't get the hostility. Yegge is running an experiment. I don't think it will work, but it will be interesting and informative to watch.
      - anonymous908213 9mo ago
        The 'experiment' isn't the issue. The problem is the entire culture around it. LLM tools are being shoved into everything, LLMs are soaking up trillions in investment, engineers are being told over and over that everything has changed and this garbage is making us obsolete, software quality is decreasing where wide LLM usage is being mandated (eg. Microsoft). Gas Town does not give the vibe of a neutral experiment but rather looks be a full-on delve into AI psychosis with the way Yegge describes it. To be clear, I think LLMs are useful technology. But the degree of increasing insanity surrounding it is putting people off for obvious reasons.
deleted 9mo ago
[deleted]
turtlebits 9mo ago
No one is promising anything. It's just a giant experiment and the author explicitly tells you not to use it. I appreciate those that try new things, even it it's possibly akin to throwing s** at a wall and seeing what sticks. Maybe it changes how we code or maybe it doesn't. Vibe coding has definitely helped me write throwaway tools that were useful.
- radlad 9mo ago
  After listening to Yegge's interview, I'm not sure this is accurate: https://www.youtube.com/watch?v=zuJyJP517Uw https://www.youtube.com/watch?v=zuJyJP517Uw For example, he makes a comment to the effect that anyone using an IDE to look at code in 2026 is a "bad engineer."
  - eikenberry 9mo ago
    Hyperbole is very common.
    - matkoniecz 9mo ago
      In LLM field things move so fast that distinguishing accurate statements, mistaken statements, jokes and lies is hard. A result, hyperbole is more annoying than usual.
    - radlad 9mo ago
      Watch the video - he's very clear that he's not looking at code. I see no indication that he is being hyperbolic.
- lovich 9mo ago
  > It's just a giant experiment and the author explicitly tells you not to use it. No, he threw up a hyperbolic warning and then dove deep into how this is the future of all coding in the rest of his talks/writing. It’s as good a warning as someone saying “I’m not {X} but {something blatantly showing I am X}”
  - 9mo ago
0xbadcafebee 9mo ago
Do you understand at a molecular level how cooking works? Or do you just do some rote actions according to instructions? How do you know if your cooking worked properly without understanding chemistry? Without looking at its components under a microscope? Simple: you follow the directions, eat the food, and if it tastes good, it worked. If cooks don't understand physics, chemistry, biology, etc, how do all the cooks in the world ensure they don't get people sick? They follow a set of practices and guidelines developed to ensure the food comes out okay. At scale, businesses develop even more practices (pasteurization, sanitization, refrigeration, etc) to ensure more food safety. None of the people involved understand it at a base level. There are no scientists directly involved in building the machines or day-to-day operations. Yet the entire world's food supply works just fine. It's all just abstractions. You don't need to see the code for the code to work.
- habinero 9mo ago
  That's a terrible analogy lol. 1. Chefs do learn the chemistry, at least enough to know why their techniques work. 2. Food scientist is a real job 3. The supply chain absolutely does have scientists involved in day to day operations lol. A better analogy is just shoving the entire contents of the fridge into a pot, plastic containers and all, and assuming it'll be fine.
  - 0xbadcafebee 9mo ago
    > Chefs do learn the chemistry, at least enough to know why their techniques work Cooks are idiots (most are either illegal immigrants with no formal education, or substance-abusing degenerates who failed at everything else) who repeat what they're told. They think ridiculous things, like that searing a stake "seals in the juices", or that adding oil to pasta water "prevents sticking", that alcohol completely "cooks off", that salt "makes water boil faster", etc. They are the auto mechanics of food. A few may be formally educated but the vast majority are not. They're just doing what they were shown to do. > A better analogy is just shoving the entire contents of the fridge into a pot, plastic containers and all, and assuming it'll be fine. That would never result in a good meal. On the other hand, vibe coding is curently churning out not just working software, but working businesses. You're sleeping on the real effect this is having. And it's getting better every 6 months. Back to the topic: most programmers actually suck at programming. Their code is full of bugs, and occasionally the code paths run into those bugs and make them noticeable, but they are always there. AI does the same thing, just faster, and it's getting better at it. If you still write code by hand in a few years you will be considered a dinosaur.
jrmg 9mo ago
This is also my experience. Everything I’ve ever tried to vibe code has ended up with off-by-one errors, logic errors, repeated instances of incorrect assumptions etc. Sometimes they appear to work at first, but, still, they have errors like this in them that are often immediately obvious on code review and would definitely show up in anything more than very light real world use. They _can_ usually be manually tidied and fixed, with varying amounts of effort (small project = easy fixes, on a par with regular code review, large project = “this would’ve been easier to write myself...”) I guess Gas Town’s multiple layers of supervisory entities are meant to replace this manual tidying and fixing, but, well, really? I don’t understand how people are supposedly having so much success with things like this. Am I just holding it wrong? If they are having real success, why are there no open source projects that are AI developed and maintained that are _not_ just systems for managing AI? (Or are there and I just haven’t seen them?...)
- pdntspa 9mo ago
  I worry about people who use this approach where they never look at the code. Vibe-coding IS possible but you have to spent a lot of time in plan mode and be very clear about architecture and the abstractions you want it to use. I've written two seperate moderately-sized codebases using agentic techniques (oftentimes being very lazy and just blanket approving changes), and I don't encounter logic or off-by-one errors very often if at all. It seems quite good at the basic task of writing working code, but it sucks at architecture and you need occasional code review rounds to keep the codebase tidy and readable. My code reviews with the AI are like 50% DRY and separating concerns
  - radlad 9mo ago
    In a recent Yegge interview, he mentions that he often throws away the entire codebase and starts from scratch rather than try to get LLMs to refactor their code for architecture.
    - kami23 9mo ago
      This has been my best way to learn, put one agent on a big task, let it learn things about the problem and any gotchas, and then have it take notes, do it again until I'm happy with the result, if in the middle I think there's two choices that have merit I ask for a subagent to go explore that solution in another worktree and to make all its own decisions, then I compare. I also personally learn a lot about the problem space during the process so my prompts and choices on us sequent iterations use the right language I need to use.
skippyboxedhero 9mo ago
There is an incentive for dishonesty about what AI can and cannot do. People from OpenAI was saying that GPT2 had achieved AGI. There is a very clear incentive for that statement to be made by people who are not using AI for anything productive. Even as increasingly bombastic claims are made, it is obvious that the best AI cannot one-shot everything if you are an actual user. And the worst ones: was using Gemini yesterday and it wouldn't stop outputting emojis, was using Grok and it refused to give me a code snippet because it claimed its system prompt forbade this...what can you say? I don't understand why anyone would want to work on a codebase they didn't understand either. What happens when something goes wrong? Again though, there is massive financial incentive to make these claims, and some other people will fall along with that because it is good for their career, etc. I have seen this in my own company where senior people are shoehorning this stuff in that they clearly do not actually use or understand (to be clear, this is engineering not management...these are people who definitely should understand but do not). Great tool, but the 100% vibecoding without looking at the code, for something that you are actually expecting others to use, is a bad idea. Feels more like performance art than actual work. I like jokes, I like coding, room for both but don't confuse the two.
- rozap 9mo ago
  > I don't understand why anyone would want to work on a codebase they didn't understand either. What happens when something goes wrong? It's your coworker's problem. The one who actually understands the big picture and how the system fits into it. They'll deal with it.
mkl95 9mo ago
OP defines herself as a mediocre engineer. She's trying to sell you Slop Town, not engineering principles.
kaydub 9mo ago
I don't get you guys that are getting such bad results. Are you guys just trying to one shot stuff? Are you not using agents to iterate on things? Are you not putting agents against each other (have one code, one critique/test the code, and put them in a loop)? I still look at the code that's produced, I'm not THAT far down the "vibe coding" path that I'm trusting everything being produced, but I get phenomenal results and I don't actually write any code any more. So like, yeah, first pass the llm will create my feature and there's definitely some poorly written code or duplicate code or other code smells, but then I tell another agent to review and find all these problems. Then that review gets fed back in to the agent that created the feature. Wham, bam, clean code. I'm not using gastown or ralph wiggum ($$$) but reading the docs, looking over how things work, I can see how it all comes together and should work. They've been built out to automatically do the review + iteration loop that I do.
- alecbz 9mo ago
  I have some success but by the time I'm done I'm often not sure if I saved any time.
- sjajshha 9mo ago
  My (former) coworker who’s heavy into this stuff produced a lot of unmaintainable slop on his way out while singing agents praises to hire-ups. He also felt he was getting a lot of value and had no issues.
  - kaydub 9mo ago
    [flagged]
- habinero 9mo ago
  It lets 0.05X developers be 0.2X developers and 1X developers be 0.9-1.1X developers. The problem is some 0.05X developers thought they were 0.5X and now they think they're 2X.
  - kaydub 9mo ago
kgwgk 9mo ago
> How do these industry figures claim they see no part of a 225K+ line of code and promise that it works? The only promise is that you will get your face ripped off. “WARNING DANGER CAUTION - GET THE F** OUT - YOU WILL DIE […] Gas Town is an industrialized coding factory manned by superintelligent robot chimps, and when they feel like it, they can wreck your shit in an instant. They will wreck the other chimps, the workstations, the customers. They’ll rip your face off if you aren’t already an experienced chimp-wrangler.”
- kaydub 9mo ago
  Yeah, I'm at that stage 6 or 7. I'm using multiple agents across multiple terminal windows. I'm not even coding any more, literally I haven't written code in like 2-4 months now beyond changing a config value or something. But I still haven't actually used Gastown. It looks cool. I think it probably works, at least somewhat. I get it. But it's just not what I need right now. It's bleeding edge and experimental. The main thing holding me back from even tinkering with it is the cost. Otherwise I'd probably play with it a little, but it's not something I'd expect to use and ship production code right now. And I ship a ton of production code with claude.
roberttod 9mo ago
It's unintuitive, but having an llm verification loop like a code reviewer works impeccably well, you can even create dedicated agents to check for specific problem areas like poor error handling. This isn't about anthropomorphism, it's context engineering. By breaking things into more agents, you get more focused context windows. I believe gas town has some review process built in, but my comment is more to address the idea that it's all slop. As an aside, Opus 4.5 is the first model I used that most of the time doesn't produce much slop, in case you haven't tried it. Still produces some slop, but not much human required for building things (it's mostly higher level and architectural things they need guidance on).
- fragmede 9mo ago
  > it's mostly higher level and architectural things they need guidance on Any examples you can share?
  - roberttod 9mo ago
    Mostly, it's not the model that is lacking but the visibility it has. Often the top level business context for a problem is out of reach, spread across slack, email, internal knowledge and meetings. Once I digest some of this and give it to Claude, it's mostly smooth sailing but then the context window becomes the problem. Compactions during implementation remove a lot of important info. There should really be a Claude monitoring top level context and passing work to agents. I'm currently figuring out how to orchastrate that nicely with Claude Code MD files. With respect to architecture, it generally makes sound decisions but I want to tweak it, often trading off simplicity vs. security and scale. These decisions seem very subtle and likely include some personal preferences I haven't written anywhere.
furyofantares 9mo ago
Who's promising it works? It's an experiment to discover what the limits are. Maybe the experiment fails because it's scoped beyond the limits of LLMs. Maybe we learn something by how far it gets exactly. Maybe it changes as LLMs get better, or maybe it's a flawed approach to pushing the limits of these.
deleted 9mo ago
[deleted]
joshstrange 9mo ago
Where is the "super upvote button" when you need it? YES! I have been playing with vibe coding tools since they came out. "Playing" because only on rare occasions have I created something that is good enough to commit/keep/use. I keep playing with them because, well I have a subscription, but also so I don't fall into the fuddy-duddy camp of "all AI is bad" and can legitimately speak on the value, or lack thereof, of these tools. Claude Code is super cool, no doubt, and with _highly targeted_ and _well planned_ tasks it can produce valuable output. Period. But, every attempt at full-vibe-coding I've done has gotten hung up at some point and I have to step in an manually fix this. My experience is often: 1. First Prompt: Oh wow, this is amazing, this is the future 2. Second Prompt: Ok, let me just add/tweak a few things 10. 10th prompt: Ugh, everytime I fix one thing, something else breaks I'm not sure at all what I'm doing "wrong". Flogging the agents along doesn't not work well for me or maybe I am just having trouble letting go of the control and I'm not flogging enough? But the bottom line is I am generally shocked that something like Gas Town was able to be vibe-coded. Maybe it's a case of the LLM overstating what it's accomplished (typical) and if you look under the hood it's doing 1% of what it says it is but I really don't know. Clearly it's doing something, but then I sit over here trying to build a simple agent with some MCPs hooked up to it using a LLM agent framework and it's falling over after a few iterations.
- dceddia 9mo ago
  So I’m probably in a similar spot - I mostly prompt-and-check, unless it’s a throwaway script or something, and even then I give it a quick glance. One thing that stands out in your steps and that I’ve noticed myself- yeah, by prompt 10, it starts to suck. If it ever hits “compaction” then that’s beyond the point of return. I still find myself slipping into this trap sometimes because I’m just in the flow of getting good results (until it nosedives), but the better strategy is to do a small unit of work per session. It keeps the context small and that keeps the model smarter. “Ralph” is one way to do this. (decent intro here: https://www.aihero.dev/getting-started-with-ralph https://www.aihero.dev/getting-started-with-ralph) Another way is “Write out what we did to PROGRESS.md” - then start new session - then “Read @PROGRESS.md and do X” Just playing around with ways to split up the work into smaller tasks basically, and crucially, not doing all of those small tasks in one long chat.
mactavish88 9mo ago
In my experience, it really depends on what you're building _and_ how you prompt the LLM. For some things, LLMs are great. For others, they're absolute dog shit. It's still early days. Anyone who claims to know what they're talking about either doesn't or what they're saying will be out of date in a month's time (including me).

bbayles 9mo ago

I'm sympathetic to this view, but I also wonder if this is the same thing that assembly language programmers said about compilers. What do you mean that you never look at the machine code? What if the compiler does something inefficient?

3vidence 9mo ago
This analogy has always been bad any time someone has used it. Compilers directly transform via known algorithms. Vibecoding is literally just random probabilistic mapping between unknown inputs and outputs on an unknown domain. Feels like saying because I don't know how my engine works that my car could've just been vibe-engineered. People have put 1000s of hours into making certain tools work up to a give standard and spec reviewed by many many people. "I don't know how something works" != "This wasn't thoughtfully designed" Why do people compare these things.
jplusequalt 9mo ago
>but I also wonder if this is the same thing that assembly language programmers said about compilers But as a programmer writing C code, you're still building out the software by hand. You're having to read and write a slightly higher level encoding of the software. With vibe coding, you don't even deal with encodings. You just prompt and move on.
- zerkten 9mo ago
  I've wondered if people who write detailed specs, are overly detailed, are in a regulated industry, or even work with offshore teams have success more quickly simply they start with that behavior. Maybe they have a tendency to dwell before moving on which may be slightly more iterative than someone who vibecodes straight through.
gegtik 9mo ago
I wonder if assembly programmers felt this way about the reliability of the electical components which their code relies upon...
- beklein 9mo ago
  I wonder if electrical engineers felt this way about the reliability of the silicon crystal lattice their circuits rely upon…
7777332215 9mo ago
The compiler is deterministic and the translation does not lose semantics. The meaning of your code is an exact reflection of what is produced.
- fragmede 9mo ago
  We can tell you weren't around for the advent of compilers. To be fair, neither was I since the UNIX c compiler came out in '68 and was by far not the first compiler. Modern comilers you can make that claim about, but early compilers weren't.
  - tjr 9mo ago
    Which early compilers were nondeterministic?
  - recursive 9mo ago
    All compilers have bugs. Any loss of semantics during compilation would be considered a bug. In order to do that, the source and target language need to be structured and specified. I wasn't around in the 60s either, but I think that hasn't changed.
  - georgemcbay 9mo ago
    I've been programming since 6502/6510 assembly language and all compilers I've used were deterministic (which isn't the same thing as being bug free or producing the correct output for a given input).
    - fragmede 9mo ago
      Bullshit.
anonymous908213 9mo ago
No, it is not what assembly programmers said about compilers, because you can still look at the compiled assembly, and if the compiler makes a mistake, you can observe it and work around it with inline assembly or, if the source is available, improve the compiler. That is not the same as saying "never look at the code".
hilbertseries 9mo ago
I feel like this argument would make a lot more sense if LLMs had anywhere near the same level of determinism as a compiler.
deleted 9mo ago
[deleted]
conartist6 9mo ago
I write JS, and I have never directly observed the IRs or assembly code that my code becomes. Yet I certainly assume that the compiler author has looked at the compiled output in the process of writing a compiler! For me the difference is prognosis. Gas Town has no ratchet of quality: its fate was written on the wall since the day Steve decided he didn't want to know what the code says: it will grow to a moderate but unimpressive size before it collapses under its own weight. Even if someone tried to prop it up with stable infra, Steve would surely vibe the stable infra out of existence since he does not care about that
- luckydata 9mo ago
  or he will find a way to get the AI to create harnesses so it becomes stable. The lack of imagination and willingness to experiment in the HN crowd is AMAZING me and worrying me at the same time. Never thought a group of engineers would be the most conservative and close minded people I could discuss with.
  - conartist6 9mo ago
    It's a paradox, huh. If the AI harness became so stable it wrote good code he wouldn't be afraid to look at the code he would be eager to look at it, right? But then if it mattered if AI wrote good code or not he couldn't defend his position that the way to create value with code is quantity over quality. He needs to sell the idea of something only AI can do, which means he needs the system to be made up of a lot of bad or low quality code which no person would ever want to be forced to look at.
  - vardalab 9mo ago
    Wait till you meet engineers other than sw engineers. Not even sure most sw people should be called engineers since there are no real accredited standards. I specifically trained as EE in physical electronics because other disciplines at the time seemed really rigid. There's a saying that you don't want optimists building bridges.
  - troupo 9mo ago
    There's a difference between "imagination and willingness to experiment" and "blind faith and gullibility".
gtowey 9mo ago
Not even remotely close. Compilers are deterministic. People who write them test that they will produce correct results. You can expect the same code to compile to the same assembly. With LLMs two people giving the exact same prompts can get wildly different results. That is not a tool you can use to blindly ship production code. Imagine if your compiler randomly threw in a syscall to delete your hard drive, or decide to pass credentials in plain text. LLMs can and will do those things.
- knowknow 9mo ago
  Not only that but compiler optimizations are generally based on rigorous mathematical proofs, so that even without testing them you can be pretty sure it will generate equivalent assembly. From the little I know of LLM's, I'm pretty sure no one has figured out what mathematical principles LLM's are generating code from so you cant be sure its going to right aside from testing it.
- alecbz 9mo ago
  Even ignoring determinism, with traditional source code you have a durable, human-readable blueprint of what the software is meant to do that other humans can understand and tweak. There's no analogy in the case of "don't read the code" LLM usage. No artifacts exist that humans can read or verify to understand what the software is supposed to be doing.
  - luckydata 9mo ago
    yeah there is. it's called "documentation" and "requirements". And it's not like you can't go read the code if you want to understand how it works, it's just not necessary to do so while in the process of getting to working software. I truly do not understand why so many people are hung up on this "I need to understand every single line of code in my program" bs I keep reading here, do you also disassemble every library you use and understand it? no, you just use it because it's faster that way.
    - notpachet 9mo ago
crote 9mo ago
The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice. It also doesn't involve any "creativity": a compiler is mostly translating a high-level concept into its predefined lower-level components. I don't know exactly what my code compiles to, but I can be pretty certain what the general idea of the assembly is going to be. With LLMs all bets are off. Is your code going to import leftpad, call leftpad-as-a-service, write its own leftpad implementation, decide that padding isn't needed after all, use a close-enough rightpad instead? Who knows! It's just rolling dice, so have fun finding out!
- fragmede 9mo ago
  > The big difference is that compilation is deterministic: compile the same program twice and it'll generate the same output twice. That's barely true now. Nix comes close, but builds are only bit-for-bit identical if you set a bunch of extra flags that aren't set by default. The most obvious instability is CPU dispatch order (aka modern single computer systems are themselves distributed, racy systems) changes the generated code ever so slightly. We don't actually care, because if one compiled version of the code uses r8 for a variable but a different compilation uses r9 for that variable, it doesn't matter because we just assume the resulting binary works the same either way. R8 vs r9 are implementation details that don't matter to humans. See where I'm going with this? If the LLM non-deterministically calls the variable fileName one day, and file_name the next time it's given the same prompt, yeah language syntax purists are going to suffer an aneurysm because one of those is clearly "wrong" for the language in use, but it's really more of an implementation detail at this point. Obviously you can't mix them, the generated code has to be consistent in which one it's using, but if compilers get to chose r8 one day and r9 the next, and we're fine with it, why is having the exact variable name that important, as long as it's being used correctly?
  - tjr 9mo ago
    I’ve done builds for aerospace products where the only binary difference between two builds of the same source code is the embedded timestamp. And per FAA review guidelines, this deterministic attribute is required, or else something is wrong in the source code or build process. I certainly don’t use all compilers everywhere, but I don’t think determinism in compilation is especially rare.

anonymous908213 9mo ago

The secret is that it doesn't work. None of these people have built real software that anyone outside their bubble uses. They are not replacing anyone, they are just off in their own corner building sand castles.

causalmodels 9mo ago
It is fine to have criticisms of this, I have many, but saying that Yegge hasn't built real software is just not true.
- anonymous908213 9mo ago
  Yegge obviously built real software in the past. He has not built real software wherein he never looked at the code, as he is now promoting.
  - causalmodels 9mo ago
    Ok but this entire idea is very new. Its not an honest criticism to say no one has tried the new idea when they are actively doing it. Honestly I don't get the hostility. Yegge is running an experiment. I don't think it will work, but it will be interesting and informative to watch.
    - anonymous908213 9mo ago
      The 'experiment' isn't the issue. The problem is the entire culture around it. LLM tools are being shoved into everything, LLMs are soaking up trillions in investment, engineers are being told over and over that everything has changed and this garbage is making us obsolete, software quality is decreasing where wide LLM usage is being mandated (eg. Microsoft). Gas Town does not give the vibe of a neutral experiment but rather looks be a full-on delve into AI psychosis with the way Yegge describes it. To be clear, I think LLMs are useful technology. But the degree of increasing insanity surrounding it is putting people off for obvious reasons.

deleted 9mo ago

[deleted]

turtlebits 9mo ago

No one is promising anything. It's just a giant experiment and the author explicitly tells you not to use it. I appreciate those that try new things, even it it's possibly akin to throwing s** at a wall and seeing what sticks. Maybe it changes how we code or maybe it doesn't. Vibe coding has definitely helped me write throwaway tools that were useful.

radlad 9mo ago
After listening to Yegge's interview, I'm not sure this is accurate: https://www.youtube.com/watch?v=zuJyJP517Uw https://www.youtube.com/watch?v=zuJyJP517Uw For example, he makes a comment to the effect that anyone using an IDE to look at code in 2026 is a "bad engineer."
- eikenberry 9mo ago
  Hyperbole is very common.
  - matkoniecz 9mo ago
    In LLM field things move so fast that distinguishing accurate statements, mistaken statements, jokes and lies is hard. A result, hyperbole is more annoying than usual.
  - radlad 9mo ago
    Watch the video - he's very clear that he's not looking at code. I see no indication that he is being hyperbolic.
lovich 9mo ago
> It's just a giant experiment and the author explicitly tells you not to use it. No, he threw up a hyperbolic warning and then dove deep into how this is the future of all coding in the rest of his talks/writing. It’s as good a warning as someone saying “I’m not {X} but {something blatantly showing I am X}”
- 9mo ago

0xbadcafebee 9mo ago

Do you understand at a molecular level how cooking works? Or do you just do some rote actions according to instructions? How do you know if your cooking worked properly without understanding chemistry? Without looking at its components under a microscope? Simple: you follow the directions, eat the food, and if it tastes good, it worked. If cooks don't understand physics, chemistry, biology, etc, how do all the cooks in the world ensure they don't get people sick? They follow a set of practices and guidelines developed to ensure the food comes out okay. At scale, businesses develop even more practices (pasteurization, sanitization, refrigeration, etc) to ensure more food safety. None of the people involved understand it at a base level. There are no scientists directly involved in building the machines or day-to-day operations. Yet the entire world's food supply works just fine. It's all just abstractions. You don't need to see the code for the code to work.

habinero 9mo ago
That's a terrible analogy lol. 1. Chefs do learn the chemistry, at least enough to know why their techniques work. 2. Food scientist is a real job 3. The supply chain absolutely does have scientists involved in day to day operations lol. A better analogy is just shoving the entire contents of the fridge into a pot, plastic containers and all, and assuming it'll be fine.
- 0xbadcafebee 9mo ago
  > Chefs do learn the chemistry, at least enough to know why their techniques work Cooks are idiots (most are either illegal immigrants with no formal education, or substance-abusing degenerates who failed at everything else) who repeat what they're told. They think ridiculous things, like that searing a stake "seals in the juices", or that adding oil to pasta water "prevents sticking", that alcohol completely "cooks off", that salt "makes water boil faster", etc. They are the auto mechanics of food. A few may be formally educated but the vast majority are not. They're just doing what they were shown to do. > A better analogy is just shoving the entire contents of the fridge into a pot, plastic containers and all, and assuming it'll be fine. That would never result in a good meal. On the other hand, vibe coding is curently churning out not just working software, but working businesses. You're sleeping on the real effect this is having. And it's getting better every 6 months. Back to the topic: most programmers actually suck at programming. Their code is full of bugs, and occasionally the code paths run into those bugs and make them noticeable, but they are always there. AI does the same thing, just faster, and it's getting better at it. If you still write code by hand in a few years you will be considered a dinosaur.

jrmg 9mo ago

This is also my experience. Everything I’ve ever tried to vibe code has ended up with off-by-one errors, logic errors, repeated instances of incorrect assumptions etc. Sometimes they appear to work at first, but, still, they have errors like this in them that are often immediately obvious on code review and would definitely show up in anything more than very light real world use. They _can_ usually be manually tidied and fixed, with varying amounts of effort (small project = easy fixes, on a par with regular code review, large project = “this would’ve been easier to write myself...”) I guess Gas Town’s multiple layers of supervisory entities are meant to replace this manual tidying and fixing, but, well, really? I don’t understand how people are supposedly having so much success with things like this. Am I just holding it wrong? If they are having real success, why are there no open source projects that are AI developed and maintained that are _not_ just systems for managing AI? (Or are there and I just haven’t seen them?...)

pdntspa 9mo ago
I worry about people who use this approach where they never look at the code. Vibe-coding IS possible but you have to spent a lot of time in plan mode and be very clear about architecture and the abstractions you want it to use. I've written two seperate moderately-sized codebases using agentic techniques (oftentimes being very lazy and just blanket approving changes), and I don't encounter logic or off-by-one errors very often if at all. It seems quite good at the basic task of writing working code, but it sucks at architecture and you need occasional code review rounds to keep the codebase tidy and readable. My code reviews with the AI are like 50% DRY and separating concerns
- radlad 9mo ago
  In a recent Yegge interview, he mentions that he often throws away the entire codebase and starts from scratch rather than try to get LLMs to refactor their code for architecture.
  - kami23 9mo ago
    This has been my best way to learn, put one agent on a big task, let it learn things about the problem and any gotchas, and then have it take notes, do it again until I'm happy with the result, if in the middle I think there's two choices that have merit I ask for a subagent to go explore that solution in another worktree and to make all its own decisions, then I compare. I also personally learn a lot about the problem space during the process so my prompts and choices on us sequent iterations use the right language I need to use.

skippyboxedhero 9mo ago

There is an incentive for dishonesty about what AI can and cannot do. People from OpenAI was saying that GPT2 had achieved AGI. There is a very clear incentive for that statement to be made by people who are not using AI for anything productive. Even as increasingly bombastic claims are made, it is obvious that the best AI cannot one-shot everything if you are an actual user. And the worst ones: was using Gemini yesterday and it wouldn't stop outputting emojis, was using Grok and it refused to give me a code snippet because it claimed its system prompt forbade this...what can you say? I don't understand why anyone would want to work on a codebase they didn't understand either. What happens when something goes wrong? Again though, there is massive financial incentive to make these claims, and some other people will fall along with that because it is good for their career, etc. I have seen this in my own company where senior people are shoehorning this stuff in that they clearly do not actually use or understand (to be clear, this is engineering not management...these are people who definitely should understand but do not). Great tool, but the 100% vibecoding without looking at the code, for something that you are actually expecting others to use, is a bad idea. Feels more like performance art than actual work. I like jokes, I like coding, room for both but don't confuse the two.

rozap 9mo ago
> I don't understand why anyone would want to work on a codebase they didn't understand either. What happens when something goes wrong? It's your coworker's problem. The one who actually understands the big picture and how the system fits into it. They'll deal with it.

mkl95 9mo ago

OP defines herself as a mediocre engineer. She's trying to sell you Slop Town, not engineering principles.

kaydub 9mo ago

I don't get you guys that are getting such bad results. Are you guys just trying to one shot stuff? Are you not using agents to iterate on things? Are you not putting agents against each other (have one code, one critique/test the code, and put them in a loop)? I still look at the code that's produced, I'm not THAT far down the "vibe coding" path that I'm trusting everything being produced, but I get phenomenal results and I don't actually write any code any more. So like, yeah, first pass the llm will create my feature and there's definitely some poorly written code or duplicate code or other code smells, but then I tell another agent to review and find all these problems. Then that review gets fed back in to the agent that created the feature. Wham, bam, clean code. I'm not using gastown or ralph wiggum ($$$) but reading the docs, looking over how things work, I can see how it all comes together and should work. They've been built out to automatically do the review + iteration loop that I do.

alecbz 9mo ago
I have some success but by the time I'm done I'm often not sure if I saved any time.
sjajshha 9mo ago
My (former) coworker who’s heavy into this stuff produced a lot of unmaintainable slop on his way out while singing agents praises to hire-ups. He also felt he was getting a lot of value and had no issues.
- kaydub 9mo ago
  [flagged]
habinero 9mo ago
It lets 0.05X developers be 0.2X developers and 1X developers be 0.9-1.1X developers. The problem is some 0.05X developers thought they were 0.5X and now they think they're 2X.
- kaydub 9mo ago

kgwgk 9mo ago

> How do these industry figures claim they see no part of a 225K+ line of code and promise that it works? The only promise is that you will get your face ripped off. “WARNING DANGER CAUTION - GET THE F** OUT - YOU WILL DIE […] Gas Town is an industrialized coding factory manned by superintelligent robot chimps, and when they feel like it, they can wreck your shit in an instant. They will wreck the other chimps, the workstations, the customers. They’ll rip your face off if you aren’t already an experienced chimp-wrangler.”

kaydub 9mo ago
Yeah, I'm at that stage 6 or 7. I'm using multiple agents across multiple terminal windows. I'm not even coding any more, literally I haven't written code in like 2-4 months now beyond changing a config value or something. But I still haven't actually used Gastown. It looks cool. I think it probably works, at least somewhat. I get it. But it's just not what I need right now. It's bleeding edge and experimental. The main thing holding me back from even tinkering with it is the cost. Otherwise I'd probably play with it a little, but it's not something I'd expect to use and ship production code right now. And I ship a ton of production code with claude.

roberttod 9mo ago

It's unintuitive, but having an llm verification loop like a code reviewer works impeccably well, you can even create dedicated agents to check for specific problem areas like poor error handling. This isn't about anthropomorphism, it's context engineering. By breaking things into more agents, you get more focused context windows. I believe gas town has some review process built in, but my comment is more to address the idea that it's all slop. As an aside, Opus 4.5 is the first model I used that most of the time doesn't produce much slop, in case you haven't tried it. Still produces some slop, but not much human required for building things (it's mostly higher level and architectural things they need guidance on).

fragmede 9mo ago
> it's mostly higher level and architectural things they need guidance on Any examples you can share?
- roberttod 9mo ago
  Mostly, it's not the model that is lacking but the visibility it has. Often the top level business context for a problem is out of reach, spread across slack, email, internal knowledge and meetings. Once I digest some of this and give it to Claude, it's mostly smooth sailing but then the context window becomes the problem. Compactions during implementation remove a lot of important info. There should really be a Claude monitoring top level context and passing work to agents. I'm currently figuring out how to orchastrate that nicely with Claude Code MD files. With respect to architecture, it generally makes sound decisions but I want to tweak it, often trading off simplicity vs. security and scale. These decisions seem very subtle and likely include some personal preferences I haven't written anywhere.

furyofantares 9mo ago

Who's promising it works? It's an experiment to discover what the limits are. Maybe the experiment fails because it's scoped beyond the limits of LLMs. Maybe we learn something by how far it gets exactly. Maybe it changes as LLMs get better, or maybe it's a flawed approach to pushing the limits of these.

deleted 9mo ago

[deleted]

joshstrange 9mo ago

Where is the "super upvote button" when you need it? YES! I have been playing with vibe coding tools since they came out. "Playing" because only on rare occasions have I created something that is good enough to commit/keep/use. I keep playing with them because, well I have a subscription, but also so I don't fall into the fuddy-duddy camp of "all AI is bad" and can legitimately speak on the value, or lack thereof, of these tools. Claude Code is super cool, no doubt, and with _highly targeted_ and _well planned_ tasks it can produce valuable output. Period. But, every attempt at full-vibe-coding I've done has gotten hung up at some point and I have to step in an manually fix this. My experience is often: 1. First Prompt: Oh wow, this is amazing, this is the future 2. Second Prompt: Ok, let me just add/tweak a few things 10. 10th prompt: Ugh, everytime I fix one thing, something else breaks I'm not sure at all what I'm doing "wrong". Flogging the agents along doesn't not work well for me or maybe I am just having trouble letting go of the control and I'm not flogging enough? But the bottom line is I am generally shocked that something like Gas Town was able to be vibe-coded. Maybe it's a case of the LLM overstating what it's accomplished (typical) and if you look under the hood it's doing 1% of what it says it is but I really don't know. Clearly it's doing something, but then I sit over here trying to build a simple agent with some MCPs hooked up to it using a LLM agent framework and it's falling over after a few iterations.

dceddia 9mo ago
So I’m probably in a similar spot - I mostly prompt-and-check, unless it’s a throwaway script or something, and even then I give it a quick glance. One thing that stands out in your steps and that I’ve noticed myself- yeah, by prompt 10, it starts to suck. If it ever hits “compaction” then that’s beyond the point of return. I still find myself slipping into this trap sometimes because I’m just in the flow of getting good results (until it nosedives), but the better strategy is to do a small unit of work per session. It keeps the context small and that keeps the model smarter. “Ralph” is one way to do this. (decent intro here: https://www.aihero.dev/getting-started-with-ralph https://www.aihero.dev/getting-started-with-ralph) Another way is “Write out what we did to PROGRESS.md” - then start new session - then “Read @PROGRESS.md and do X” Just playing around with ways to split up the work into smaller tasks basically, and crucially, not doing all of those small tasks in one long chat.

mactavish88 9mo ago

In my experience, it really depends on what you're building _and_ how you prompt the LLM. For some things, LLMs are great. For others, they're absolute dog shit. It's still early days. Anyone who claims to know what they're talking about either doesn't or what they're saying will be out of date in a month's time (including me).