Exactly. Literally everything about AI-generated coding is a lie at its core. Every “success story” they tell us of complete vibe coded projects has something hidden they’re not telling us that completely invalidates their claims of “how good LLMs have become”. The recent story with Navier Stokes confirms that for the 100th time. Yet they aren’t in jail yet. It makes me feel like our whole industry is in need of saving. We can no longer let it be ruled by gullible C-suites who never wrote a line of code. It needs to be us, the actual engineers, that set the path forward. If we did that, vibe coding would have never become a thing to begin with. How much longer are they gonna continue to predate and lie to the masses?
7 Likes
AI has commodified code, there is no point in ignoring that.
At the same time, industrialized bread companies never stopped artisan bakeries from having success. In my time living in France, I think I haven’t once bought bread from the supermarket shelf. In this case, artisans are actually setting the standard of what good bread really is. Not because machines can’t make bread, but because artisans can afford to create them slowly, paying attention to every detail and bringing their enormous experience with them. Nevertheless, somehow both manage to coexist in the same society.
I agree that industrialized code will be basically dominated by AI, similar to mechanical bread production. But this is very related to the profit demands and thus pressure over feature and production throughput; something that most of non-industrial development communities really don’t care about. In my experience, one of the worst mistakes a good bakery can make is to open more stores: they generally lose quality, begin to compete with industrial bread and end up either closing or being much less remarkable.
I also see myself on a very specific situation, I am in academia (in Brazil). In this field, also in contrast to industry, there is no point in using AI to write your code. In this case, I’m almost always more interested in really understanding my code and using this understanding to have new ideas for future projects rather than just have code written fast. Outsourcing this coding is basically interrupting one the main sources of ideas, fun and inspiration for novel research.
39 Likes
The bread analogy is great, I’m going to steal it :^)
11 Likes
People will likely always appreciate the quality (and more importantly, the imperfections) of hand-made food, furniture, and artwork. I’m not so sure people will care about artisnal accounting software or compression libraries. When it comes to utilitarian software, the hand-made kind will likely have to succeed on its objective merits alone.
2 Likes
Calling sourdough, specialty roast, and artisanal furniture “imperfect” in comparison to say, mass produced grocery bread, burnt Nespresso coffee pods, or IKEA’s perfectly square boxes does not really help your argument.
But I do agree with you. I think a better comparison would be 2D vs 3D animations. One’s better at maintaining perspective, the other’s better at breaking it. Both can theoretically do what the other can given enough talent and resources, but usually don’t.
Hand-made software will probably be valued in things like video games, but if AI wrote a better FFMPEG who cares besides a bunch of nerds right?
You’re interpreting the word in a positive sense. Mass-produced bread or furniture is “perfect” in the sense of being uniform and exactly to specification, not that they are actually better. The slight asymmetry of hand-made bedposts or the sound of a blues singer’s voice cracking under strain as his emotions pour out are examples of “imperfection”, but the kind of imperfection that people instinctively love.
2 Likes
Thing is though, does good software “sell”? I.e., due to its history, as opposed to bread, aren’t most people anti-purchasing software? To the extent that, unlike the artisan bread, no one is out there seeking high quality software when what his heavily marketed will suffice.
I.e., artisan bread at least appeals to you on a primal level of “taste” “deliciousness” etc., but good software, is it not something only fellow developers tend to appreciate? Obviously this assumes the mass-produced software meets a minimum threshold of not taking days to compute something that would otherwise take a minute.
1 Like
I’d like to push back on this, professionally I can tell you that I have spent the better part of the last year rescuing codebases from their over usage of specifically CC (really any LLM, but specifically CC). I have to ask how much time that you have put in on the other end of this pipeline IE, after you’ve vibe coded out a heaping steaming stinky pile, have you or has it been someone else who is going in and maintaining it afterward.
I also think you need to be much more specific in the domain of code that is being written, are you a primarily backend dev who has outsourced front end work? It has been my experience that those who share your opinion fall into this camp, and frankly as a developer who has spent a majority of their career salvaging back end web devs attempts at front end (unfortunately) I think that those who fall in this camp really fall for the high expectations of LLM’s in something that is outside of their domain of expertise.
I personally feel often that nearly all of the LLM code that I see is just trash, that is in systems, backend web, frontend web, or really anything. It’s all maybe 80% to being done and 80% bad architectural choices.
1 Like
I care, I really really really care. I don’t want to be on a plane where the avionics controllers are vibe coded, I don’t want to drive a car where the breaking systems controllers are vibe coded, I don’t want my bank to vibecode in any sense.
We are software ‘engineer’s’, we should be taking at a core level the quality of the thing we are making as an extension of our integrity. I have always held, and it has only helped me in my own personal career, that I would never ship code that I didn’t feel was safe and met the requirements, time, money, and pestering be damned.
If anything I think that Vibe coding and all of this AI adoption should be notice to the entire industry, for those of us who, I’m sorry frankly do care about state of the quality of work and by extension the base for the modern world, needs to be protected and those who truly do understand these systems be rewarded for ensuring the quality their of.
I frankly don’t understand this line of thinking, I think ‘uncle bob’ is a twit, a broken clock is truly right twice a day in that the things that we produce truly do determine if people live or die and I truly do think that we should treat our entire profession and the output of it with the level of care that it deserves.
4 Likes
FWIW at work I typically spend around 2 to 3 hours preparing, reviewing, testing and “interrogating” a feature Claude Code implements in about 10..30 minutes. And that starts with a feature spec from game design which is already very detailed and has been built with Claude having access to the source code and a fairly detailed set of rules about the game’s architecture (enough for Claude to come up with an initial working implementation on its own). It’s also important to not only specify what you want, but also some hints about how you want it implemented. Claude also has a closed “feedback loop”, eg it can remote control the game in Unity and check its output via object introspection, log output and taking screenshots.
The resulting code looks mostly fine tbh. There are usually some wrong high level decisions where Claude “guesses wrong” when a feature comes with implementing entirely new game systems (like putting a piece of helper code into the wrong subsystem, or not noticing that such a helper already exists) but that’s what the review and interrogation phase is for, and such corrections also automatically feed back into the rule set.
We could go much faster by not spending the additional time to poke at the LLM output or spend less time on feature and architecture design specs, but that would be futile for a longterm project (it’s fine for quick’n’dirty prototyping and experimenting though).
Also tbh, the code is higher quality than some “alternative” approaches where level/game designers script game logic in Lua, or via noodle graph editors like UEs Blueprints. These were already traditional workflows where experienced programmers had to go in afterwards and clean up the mess. An LLM steered directly by an experienced programmer is the better “low code” alternative tbh.
2 Likes
don’t think vibe coding is bad, as long as you are doing it on throwable code. In the past year I’ve made countless one off tools, to help me debug sensors, visualize issues, remotely interpreting data etc. Those I could have made myself, usually less than a 1000 loc. But there’s no value in doing them properly if you know you are not going to use them afterward.
But I do agree, the core of a project, should be designed/written by a human, Ai can still be usefull for documentation, debugging, code review, boiler plate or non critical code.
8 Likes
I’m very curious about what people actually mean when they ‘llm slop" vs "superior code from a human’. I don’t see engineering processes mentioned. Do you measure to prove your artisanal crafted code is better? What do you measure? Complexity? Formal models? Proofs of correctness? Performance gates? Static analysis? What is your criteria for better if you are making the claim that you write better code using humans vs. automated systems how do you prove it?
1 Like
Given that humans writing and reading code is the established status quo, surely the burden of proof as far as which is better is on the llm-generated code.
That being said, I’m surprised that you think that people are still making a measurable claim once the word “artisanal” comes out.
2 Likes
I agree with the conclusion, given the current trajectory, Zig will remain to be niche forever. I know there’s (IMO unjustified) hate against LLMs but that’s just the way how (commercial) software is going to be developed from now on, no matter how we feel about it.
I’ve been waiting for a new release, for the incremental compiler to finally work on macos, for usable coroutine kqueue IO impl in std, and there’s still no light AFAIK. So many breaking changes, writer-gate, now() moved to std.Io, nuked std.posix, removed @cImport(), and I could just go on and on. It went so far that I was avoiding std for a while and I’ve just implemented everything important myself. Note that this is not hate, but I just got enough. The fatigue is real.
In the mean-time, in just 2 weeks I’ve successfully ported most of my (mostly private) projects from Zig to Rust using local LLM and it works. Sure the code is not the same quality, but it’s also not the worst and it’s definitely way above the zero effort for the prompt.
I’ve been doing Rust before and it’s not language I enjoy writing. In fact, I’ve switched to Zig because of all the problems Rust had at the time (and it still has most of them). The thing is, I will not be writing Rust by hand anymore, meta-programming is way worse but again, I will not be writing that glue myself anymore. From my initial experiments, it seems that subset of Rust might be something I can live with (in this new age).
I am slowly conserving my OSS projects and I will be maintaining them for a while but that will also likely end one day. It’s bitter, and I am sorry.
Of course, I’ve learned a lot and I think I am better programmer thanks to Zig, and I’d like to thank everybody for that. I hope nobody’s mad at me.
2 Likes
Something is off in this line of argument. (Not responding to anyone in particular, just a general feel I get from the thread)
Why would software history suddenly stop in a forever satus quo ?
I mean, maybe if LLMs become so good that they don’t really program anymore, just make machine do stuff somehow. At which point programming languages would not be a thing anymore and worrying for zig being niche in nonsense. Every programming language will be niche.
But otherwise what do LLMs change exactly? Or at which time scale?
“Avoid local optimum” is a powerful motto and it can pay medium/long term with or without LLMs. It can fail as well of course, say because you end up stuck in forever polishing. But what LLMs have to do with that?
Also how can LLMs both be a game changer in the ability to rewrite a project in another language AND permanently lock one language as the only serious language to write software?
I’m not dismissing that timing (and chance) are major factors of success. But even if, and I’m not convinced, we are in such a pivotal moment, surely dashing Zig’s lang spec off is not the way to win anything.
The plan is clear. We do it carefully, we do it well, we question foundations others don’t dare to. And the result will be so good that it will be impossible to ignore.
Maybe in 10 years it will be clear that it failed and LLMs raise was a major causal factor. But in that case it will be that zig was not mature enough at the right moment in history, not that we lost the opportunity being too careful.
One thing I find extremely weird in the omnipresence of the word “era” in AI discourse. Common ! 6 months is a blip in history, not an era. Don’t fall for this urgency fallacy.
On the topic of predicting future technology, I always think about the original star trek series : they have intergalactic vessels, instant translation in thousands of languages, but when they call the engine room 5 decks below, they use one of this huge red phone of the 70’s. We are probably not picturing ourselves the future very well…
Anyways, this was my evening digression.
Take care.
12 Likes
Haha .. no problem at all. As long as you still dislike writing Rust, we can still be friends 
I think what this highlights more than anything else is that the “cost” of swapping out tools is no longer such a big issue as it once was in the past. So yeah - keep a big toolbox on you, and reach for the right tool for the job.
I did a similar thing with my main project when 0.16 came out - I really needed kqueue async, plus a bunch of other infra that I hadn’t had time to start yet, so ended up porting the core from Zig to Erlang. I’m happy to report it was relatively simple, and the project as a whole gained a lot.
From a project point of view, this required me to step back a few paces and describe exactly what I’m trying to achieve at a high level. That little exersize itself turned out to be really valuable, regardless of the path to get there.
From a Zig usage point of view, having offloaded all the boring and dangerous stuff to Erlang, I could then focus my Zig efforts on the bits where Zig is best of breed .. and do those bits by hand … so now I have a hybrid system that’s waaaay better than my original plan. Win win.
Turns out that LLMs are pretty good at doing straight up translations minus creative interpretation. Maybe a stable and complete Zig 1.0 could end up being a great translation target at some future date. The irony ! The cost of trying it out and measuring the result is now extremely low anyway.
For the parts where LLMs are utterly hopeless - like converting subjective UX specifications into a coherent product, I think there is a gap in the tools market for a super high level specification markup language to describe this stuff objectively, and use it to drive LLM output. Prose just doesn’t cut the mustard, and tools like Figma fall way short too.
I’m mulling over the idea of using D2 markup, with extensions, to define exact specs that can be fed to an LLM+ code generator logic. Zig fits in perfectly to this plan too, and could end up replacing the need to even have any LLM in that pipeline.
Despite a string of frustrations, I’m only seeing good things in this little transition period we are suffering through at the moment.
1 Like
I also now see Zig as a forever hobby language (with maybe a few exceptions). I learned Zig 0.13 and fell in love with it. I had Zig oh my radar before that, but I didn’t want to use alpha software. I thought it’s now in the polishing phase so I will not regret spending time on it. Every release since then had more breaking changes, but more importantly more unfinished changes. Zig 0.16 honestly feels like a preview release, not something I’d call a product. I accepted it, for now, because I was already invested, but I have hard time convincing myself to use Zig going forward. I don’t even mind the breaking changes at this point, LLMs can help me with upgrades. What I dislike is the attitude in the community, to just ship incomplete versions with known bugs,. I’m tempted using LLMs to see, how would I feel converting my Zig code to Rust or modern C++. I can’t stand Rust, I makes my head ache reading the code, but the fact is, it’s a stable base on which I can build on. The sad part for me is, I really love Zig the language, I like the approach to code I’ve seen when I learned it, I’d love to continue using it, but in order to that, I’d essentially have to isolate myself from the community, not depend on the stdlib, and that feels too lonely.
5 Likes
yes
I totally agree with you.
LLMs again, so I feel I also have to add my 2 cents 
I really like the comparison too. But would add one important detail. This handcrafted thing (no matter if regarding code/bread/Ikea furniture etc) can make a big difference, but you need to care and be aware about it. You can survive eating industry bread, using company-LLM software while sleeping in wonky pressboard beds, but if you care about it, its no fun doing so. If you’re not aware, you might not care because you don’t know the refined taste of wholewheat sourdough bread, the little gimmicks of human-made software or the robust and safe surface of a crafted solid wooden bed.
Plus, I think the whole “AI is inevitable now” story is to a not too small amount only that: a narrative created by the big AI-companies to sell their product. Thats just how capitalism works: Invent something which without question is useful, but then sell it as there is no alternative to buying your shit. IT and software engineering were already flourishing only a few years ago when everything was human-written code, but now managers/CEOs are somehow persuaded by the inevitable-fairytale and that makes it a new industry standard.
I’m not saying that LLMs are having no impact, but as the very differing experiences posted here show, the reality is far from the story that everything will be faster and better with AI.
One personal experience which makes me even more skeptical about this “AI makes everything better” claim is that there haven’t been so many small issues and glitches in software I use at a daily basis than this year. E.g. since a few weeks some of the integrated media center apps on my TV for some public service channels don’t work correctly anymore. Pressing the left/right button doesn’t select the next item but skips two. Thus, its not usable anymore. A similar small issue accounts for one of my banking apps and my former smartphone browser. As single occurrence that would be not worth a story, but these things pile up very regular only this year when big LLM models finally have become the standard. Maybe its just conicidence, but it leaves a strange feeling.
Regarding Zig: Maybe it stays niche due to the named “problems” with LLM interoperation. Would be a good thing for me. If a software engineer uses LLMs anyway to produce code, its not such a big deal how the written code looks, because what gets executed is the compiled machine code. So just use Rust…
PS: Also at the risk of getting disliked more: One thing I’m always wondering about when I read about those AI/LLM discussions (be it on Ziggit or somewhere else) is how less attention is paid to the consequences the pure technical activity to run these services has: be it the harm to environment/nature, the depletion of our resources, or the exploitation of human “data workers” mainly in dependent countries of the Global South.
12 Likes
nuked std.posix
What do you mean? I just fired zig std on 0.17.0-dev.2122+3e15e99e6 and there is still a lot of functionality there.