Author here. I agree with this comment, but if I wrote more like this my blog post would get less traction.

"LLM coding tools are search-based program synthesizers," in my mind this is what compilers are. I think most compilers do far too little search and opt for heuristics instead, often because they don't have an integrated runtime environment, but it's the same idea.

"Plenty of effective engineering tools are stochastic," sure but while a SAT solver might use randomness and that might adjust your time to solve, it doesn't change the correctness of the result. And for something like a fuzzer, that's a test, which are always more of a best effort thing. I haven't seen a fuzzer deployed in prod.

"Determinism comes from external specs and tests," my dream is a language where I can specify what it does instead of how it does it. Like the concept of Halide's schedule but more generic. The computer can spend its time figuring out the how. And I think this is the kind of tools AI will deliver. Maybe it'll be with LLMs, maybe it'll be something else, but the key is that you need a fairly rigorous spec and that spec itself is the programming. The spec can even be constraint based instead of needing to specify all behavior.

I'm not at all against AI, and if you are using it at a level described in this post, like a tool, aware of its strengths and limitations, I think it can be a great addition to a workflow. I'm against the idea that it's a magical English compiler, which is what I see in public discourse.

I think the key insight I walked away with from this whole thread, for me, was:

A compiler takes source and maps it to some output. Regardless of the compiler detail, this is an atomic operation; you end up with source (unmodified) and an artifact.

These “agent workflows” are distinctly different.

The process of mapping prompt to an output is the same; but these agent workflows are destructive; they modify the source.

Free reign over the entire code base; They modify the tests. The spec, the implementation.

It seems like this is a concept people are still struggling with; if your specification is poorly defined, and is dynamically updated during the compilation process, the results are more than just non deterministic.

Over time, the specification becomes non deterministic.

Thats why unsupervised agents go “off the rails”; not because the specification cant be executed, but because over time the spec drifts.

That doesnt happen with compilers.

In your blog post: “Most people do not care to find the truth, they care about what pumps their bags”

in your HN comment: “I agree with this comment, but if I wrote more like this my blog post would get less traction.”

Seems like you also not care about the truth.