Comment by SwellJoe | Hacker News Reader

Comment by SwellJoe | Hacker News Reader

Parent Full thread

The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs.

Even though I use LLMs every day, and have to admit they're remarkably good at many classes of problem, I don't want a programming language built by an LLM. Every line of code in a programming language, every decision, every trade off, matters. A vibe-designed/vibe-coded programming language would be a disaster. I don't know how else to put it, and I've never seen any model produce code that would convince me otherwise (even Fable, which is, in fact, a notable improvement over the prior best models). The models don't want anything. They don't have meaningful opinions. They don't know what comfortable vs. uncomfortable feels like in a language (or in a GUI or CLI interface at sufficient levels of complexity).

You can't get a language like Zig out of an LLM without simply copying Zig, and even then it would be a copy that is worse. (I mean, I'm assuming "copy with an LLM" means, "have an LLM write the spec and another build the language to the spec", not literally `cp` the source tree.)

> The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs.

We've heavily adopted LLM's, to the point where I'll often not touch any code and have a better and more maintainable codebase than if it had been written by any of our developers (myself included). I'm not sure it would be possible if our philosophy wasn't explicity, no abstractions and defensive programming, but when every function is it's own thing with runtime assertions and ways of dealing with corrupt states as soon as they happen. Well... the LLM can do that when you can.

That being said. I think it's not new that you can write computer software without computer science, until you can't. Where I see the challenge with LLM's and software development as a business is that a lot of software developers work(ed) that can be automated because they don't actually require computer science as such. Having setup company wide "apps" for Microsoft's cowork, I think any sort of semi-expert level office job is going to be in danger. I'm not a huge fan, and I was never hyped on AI but it's ridilous what you can do in the enterprise office space (and how easy it is) when you're married with Microsoft.

This is an interesting approach. When you say no abstractions though, what do you actually mean? I would count functions as abstractions but do you mean classes/structs representing an object? Effectively no new types?

It depends. Ah, well I guess it's a litlle unfair to say that because in the context of your question I absolutely didn't mean for it to be taken literally and I should've been more clear. It does depend on domain though. For some of our engineering and control software it is almost meant literally. Since we'd have very few abstractions beyond the language primitives because of explicity.

For what you were asking though, it's not no-abstractions it's YAGNI where business logic lives in "just" functions which operate on plain data structures with runtime assertions and validation. The data structures will usually include domain specific types. There are no classes, object hierachies or architecture abstractions, at least, there almost never ever are. When it absolutely doesn't make sense not to introduce an abstraction beyond what we typically want, then it's allowed. This pains a lot of Uncle Bob's disciples, until it doesn't.

The advantage of it is that we've found that it works really well with LLM's. At least in my experience they seem to be absolutely excellent with explicit, localized code instead of layers of indirection.

Right, that makes a lot of sense. Seems like reviewers can easily see and check those asserts to understand if the LLM has written something sensible (and I presume those asserts are strongly declared in the prompts).

I'd love to read a blog post or something on what you've discovered on good software patterns for AI. I'm only now getting into using LLMs and beyond the purely technical aspect of what LLM is "best" it seems like there's a wealth of learned experience in how to structure and write code to work well with them.

I've heard good arguments for using Rust with LLMs because the compiler keeps the LLM from making silly mistakes. What languages have you been developing in?

With low code / no code systems like Power Automate, Boomi, Workato you can already do plenty of enterprise workflows without a line of code, just diagrams.

Now those systems have evolved to become orchestration workflows engines with agents and tools integrations, thus several scenarios that still required proper code, have now been reduced to agent instructions.

I think many in HN don't have a clue how little traditional coding some enterprise scenarios require nowadays, plugging SaaS products with such tools.

Being a backend dev is more administration than actual classical coding.

I think orchestration is the perfect description. In enterprise you have a bunch of standard systems which play by their own tune, and even with a lot of the "low-code" options you're going to build systems that transfer data to the right system at the right time. Like a director of an orchestra.

Having spent a lot of time in enterprise which is not related to software development (or IT at all) I'm pretty familiar with a lot of the low / no code or Robot Process Automation systems. Which always end up requiring specialized developers, except, you can't hire software developers for them so you end up with various consultants creating huge messes. Microsoft's Cowork is the first time I've seen a system which can actually directly replace people who aren't experts in their business domain. It requires a lot less than any other system I've seen before. You need someone who has global, intune and AI admin in the Microsoft ecosystem, who know enough about software development to evaluate an app to be safe and efficient and how to debug it, and a domain expert. Then you'll have something which "just works". It's scary really.

I had no domain knowledge of PowerBI like at all, and while I could fill a data architect role, I would have never been able to do anything beyond a semantic model in Fabric and even on the semantic model it's not like I've ever worked with DAX. Yet Cowork (with read access to the Fabric workspace) could guide me through the process of creating a powerBI report set which was good enough that the business wanted to use it with a few minor improvements... Five months ago, this would have been a 2 people job. Now I was basically a puppet getting told which button to click in the report editor. If Cowork had write access it wouldn't have needed me in the loop once the data was delivered to the datalake it shortcutted to.

Thanks for the experience overview, those kind of experiences is what makes me evaluate that long term, some of us are lucky to slid into other roles, more architecture like, others not so sure.

For many kind of products, where selling software isn't the main business, companies will settle for approaches like that you describe, writing classical business software isn't what it used to be.

We are at the evolution of 4GLs and RUP dreams.

> They don't know what comfortable vs. uncomfortable feels like in a language

This is mostly about human preferences right. If software is just taken as the end product, does it matter what "feels" good and doesn't?

Writing the compiler and standard library in Zig is probably the greatest dog fooding opportunity for the Zig maintainers. In doing so they get to feel the weight of every change they make to the language, for as long as they don't simply hand that task over to a chatbot.

It's also an open source project, so the end product is as much the codebase as it is the binary releases.

I've interacted enough with largely computer generated codebases to see that ergonomics problems easily grow and accumulate when LLMs remove the burden of dealing with those problems from the developer. I've always considered my laziness an asset. Now I would qualify that by saying that laziness is an asset for as long as it compels you to keep things simple and easily understandable so that the cost of making changes (whether that's measured in human gray hairs or tokens) doesn't grow with every change.

I agree that it depends on whether you want humans to interact/interpret the software at all, but I'd push back on "mostly human preferences." Do you think that how something feels is mostly a matter of human preference? Intuition and aesthetic sensibility are distinct from preference, and both play a role in research mathematics and scientific discovery as well as in art. There is also (human) cognitive affordance which I think is important for human code review. That said, I'm sure there is a language and coding style that optimises for both human and machine processing that is much better than what we have today.

Sure a human would write the language spec and the llm implement it

I think this makes two incorrect assumptions:

1. That a human, even a brilliant human with a lot of experience, can sit down and one-shot a language spec for a new language that is actually good.

2. That an agent can produce code that is good enough for a programming language that intends to last for decades without exhaustive human review.

We might advance to the point where 2 is true, we're not there yet. We'll never make a better human that can one-shot a good programming language. It takes iteration, with a human in the loop. Zig has taken ten years to get to this point, and is still occasionally experiencing major refactors.

If you want to argue an LLM could potentially accelerate development by some amount, I would agree with you. How much it could accelerate it is debatable. And, I understand why the Zig folks have decided not to accelerate in that way. There is a cost to it. You lose the junior programmer pipeline, as your "good first bug" list gets chewed up by people using LLMs. You still have to exhaustively review the code for a critical path like a compiler and AI code is hard to review; it doesn't have a point to it. The model doesn't want anything, so it's not always clear where it's going. Code without clear intention, like prose without clear intention, is hard to read and hard to review. It's verbose and often makes weird assumptions.

If I, for some reason, needed to implement a tiny DSL for something, I would 100% do it with an LLM. If I, for some reason, were tasked with building the best programming language to replace C, I would not hand it to an LLM (though I would get help from an LLM, because I don't know how to build a programming language beyond the tiniest toy interpreter or compiler, I'd need to read and understand every line of code, and use it daily, for it to turn out good).

I said nothing about one shooting it. there is a thousand different ways to hash out the reality of implementing the idea

For complicated problems, you can't just write the language spec. You need to iteratively develop it, which itself requires some intermediate state/language describing what you know so far. That intermediate state being the end programming language in consideration isn't mandatory per se, but iteratively refining, replacing, and reworking solutions using code as a drafting board is very common in the industry. That's doubly true for languages, where the social pressures in how it "feels" or is actually used are paramount. If you move away from iterative coding drafts, you still need some sort of interactive product to work on to actually develop the spec.

Plus, current-gen agents/LLMs can't implement a non-trivial language spec without significant hand-holding.

I’ve been thinking about this over the past few days. There was an exciting keynote at PLDI 2026 by MIT professor Saman Amarasinghe where he talked about the intersection between compilers and machine learning, including LLMs. One of the works discussed during the keynote was the use of Claude Code by his colleague Martin Rinard to implement a compiler known as a credible compiler that outputs both compiled code and a proof that the output code correctly matches the input.

https://youtu.be/Fc3cW0nqAQ0

Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.

I mean, I am doing just this over here: https://github.com/ChristofferGreen/PrimeStruct

And proving my point:

https://github.com/ChristofferGreen/PrimeStruct/blob/d4f1a8e...

Reply on news.ycombinator.com