mccoyb

Bro, what the fuck do you think I’m doing? Do you think I don’t know about spec driven development?

What is the most complicated thing you’ve built with LM agents? Have you done it with a single spec? How novel was it?

This comment is so laughably “you’re holding it wrong” I can’t respond to you seriously.

> If you instead spend a day writing a proper specification, then ask the agent to spend a week implementing that, you'll need zero tools and skills afterwards to clean it up, because there won't be any misunderstandings, assumptions or other things

The set of software that has followed this process is measure zero.

That's fair for a well-scoped subroutine: what I meant is that if you ask an agent to write a compiler and let it rip for a few days, you are going to be spending a few more days correcting the default behaviors in the distribution, which often do not tend towards hardware-oriented design.

To correct those behaviors, you're going to write tools and skills, and that's going to help, but it is still clear that you are fighting the distribution (today).

Here's this boiled down:

> A stochastic search process with an executable optimization objective over space of programs S can only maintain or improve the objective

This is superoptimization. We've known this since the 80s (Massalin, STOKE is more recent: https://github.com/StanfordPL/stoke) The only novelty is that the proposer is now way better with LMs.

Further, there's a large number of reasons for software written by agents to be slow:

- LMs still don't do data or hardware-oriented design well out of the box, and therefore if you're engaging in any sort of serious novel work, beyond porting an extremely well-understood program with extremely well-understood workloads, you're going to be spending hours tracking down bad allocation decisions (c.f. why TigerBeetle doesn't use agents), which are often the root of evil (before you'd reach for anything further)

- The knobs you'd need to get serious performance are nearly unreachable in languages which LMs are good at (even Rust requires a discipline that the default language doesn't enforce). When you drop into the lower realms, you're trading consumption context for access to these levers. The levers are also "soft": you find yourself writing a bunch of skills, and tools to try and enforce the discipline.

The reality is to get performant code (quickly) out of an agent, you need to know how to write performant code (and you need to know how to surface the information that you'd use to create a verifier for such a thing to the agent), which 99% of developers do not know in 2026.

Sure, agents can teach you how to do this -- but it's one of these things where iykyk.

Experience: I've poured 10s of billions of tokens into Zig with the best agents and I have the time and space to try these things.

If you want to start learning the discipline, I'd recommend matklad's + TigerBeetle blog -- as well as hardware-oriented design.

Perhaps my enterprise cynicism is not warranted, but my other comments refer to accurate descriptions of reality: Anthropic wants to place their opaque system between you and any computational task that you wish to perform. Do you contest this or think it is not accurate?

Why do you think that Anthropic wants fewer tokens inputted and outputted?

That's not my complaint. I know well the concerns of agent harnesses. My complaint is that this is a low-dimensional projection of a system which I have no insight into, and therefore, I cannot evaluate the tips myself against their source.

Am I to believe the creators, knowing full well that the source will, as Boris Cherny put it in a recent interview, be deleted and rewritten from scratch at the release of the next big model?

Further: I'm responding to content in the blog post itself:

> Until pretty recently, the tools you wrote code with were a flat fee (or free). Your editor cost the same whether you fixed one test or fifty that afternoon, so an individual task didn't really have a price of its own.

I find this type of prose ridiculous. It conveys "this is the way things are now, get used to it".

Does that make sense?

I agree that the third seems to be implied by industry, but I'd argue that it's not clear that it is necessary -- and it is subtle whether or not it is beneficial?

My contention is that we should be building towards less churn, not more. I'm aware that some churn is the cost of engaging in any sort of enterprise, but I'm deeply suspicious of an AI company inserting themselves between me, and the tasks I wish to do with my device -- with a completely opaque system that I can't really "learn".

It's very easy to understand:

- I'm happy to learn how to use tools efficiently

- I like to be able to inspect my tools

- I'm against tools changing underneath me

Are you against any of these points?

I mean, it feels hard not to laugh at this type of blog post. My cynical interpretation is that this is a type of passing the buck to engineers in enterprise settings ("Stop spending tokens. Did you read the value maximization blog post? It is your fault.")

Oh yes, Claude will do all sorts of different things -- it depends on how you use it! You should totally learn all of these little finicky things ... because now completing your tasks cost money. It's not "free" anymore haha like when you used your old text editor, what are you a grandpa?

Oh, and those things will definitely change, as we (the priests of Claude) are vibe coding the system you use to do your little "tasks" ... right, you can't see how it works ... the code is not available. It's all good, just trust us -- we're totally looking out for you.

I mean it is utterly ridiculous to talk around this model of development. There are so many walls between you and doing the thing you want to do.

Agents are great, but the notion of "best tricks" for how to best use an opaque costful tool which will, by all odds, be completely different in a few months time is quite funny.

You know what won't change? A fucking text editor. Or your pi config, or a local model you run and trust.

This is a highly impactful game: the pixel art style is haunting, as is the sound design and musical composition -- transitions of the musical composition leads to profoundly interesting moments. As might be well-known, Alx (the lead dev) suffers from heart disease, and the game communicates something of this experience.

Really couldn't recommend it more.

my opinion: "trust" is an interesting word to use for a piece of closed source probabilistic software that changes daily (sometimes multiple times), whose lead dev reports they rewrite something like 90% ("almost all", I believe, from recent interview) of the codebase after every new model release

I wish the author the best. I've been reading Lil'Log for many years, as long as I've been pursuing research. The times right now are challenging, and I can't imagine the stress working near the bleeding edge. Everyone I know is feeling something right now, even outside of such high stress positions.

I find these blog posts (and the originals, with Anthropic's C compiler and Cursor's browser) somewhat funny, as if they have this enormous power to build ... but they can't build something unique or new. Like the software sucks, but look how powerful the process is (the models are indeed powerful).

And it's a bit of a shame: by virtue of their position (their embedding in the fabric of venture capitalism), it seems like they can only make a subset of things -- what they can make is dictated enormously by capital, as they are engines of capital.

Not sure the point I'm trying to make, I just find it amusing.

Perhaps the point is that it might be more worthwhile to give independent creators a billion dollars to play around with agent swarms if we want to keep diversity in the evolutionary algorithm that is the software industry high.

Very cool work Keno! Any place to find information about the Julia-specific concepts / features compared to MLIR?

Wondering if there are modeling or analysis modalities that don’t fit cleanly into MLIR concepts (understand that abstract interpretation on the IR comes with a unique set of concerns)

Perhaps the most telling part of this transcript is Tristan Hume, a prolific and talented programmer, and presumably an expert performance engineer, is repeatedly saying "this thing just doesn't work that well yet" or "it's just not there yet" and everyone else is kind of just fawning over it.

"It actually made something that worked. But when I tried using it, I found I didn’t like it. I need to wait for a Claude that has the taste ..."

Yes, I am familiar with that experience.

Exactly, the work of Tony Garnock-Jones: https://syndicate-lang.org/

It does feel like there are a lot of parallels between usage of AI and psychedelic experiences:

- novices love to talk about the act itself

- mostly inscrutable, and the artifacts of the experience are not fully understood by the beholder

- pumped by a similar new age tech crowd of optimaxxers who haven’t realized that this mode of thinking alone is not all you need

slow and careful reflection has never been more important.

By the gods! The next 20 minutes will be the most consequential of my life ...

Thanks: very helpful and clear.

Linda and Syndicate figured this out - it’s just that most engineers are not programming language designers or researchers, and most researchers are not designing robust scalable language implementations.

This is inspiring! At the same time, it’s not exactly clear to me how this is going to work in the long term without changes to the Zig language itself, questions below.

Assuming the goal is to be able to write compute kernels and shaders in Zig - the concerns of writing (and especially optimizing) these programs are significantly different from high-performance CPU execution.

Mojo, for instance, has seemed to solve this problem (presumably: I haven’t studied the compiler myself, but this is a claim of theirs) but the community has implied that solving this problem required semantic and compiler design decisions different from the Zig compiler, especially around memory spaces, pointers, and origins.

Further: if you open up a modern tensor / GPU compiler (Triton, XLA, logical / scheduled kernel systems like Halide or Exo, or low-level kernel compilers like Mojo) — the optimizations and analyses which are performed on GPU kernel code are significantly different than CPU code

Is the end goal to write such a pipeline into the Zig compiler?

It seems possible to do this - but I’m not sure … it seems a bit hacky, or like one has to coerce existing Zig semantics to be repurposed for a job it was not designed for in the first place?

One alternative might be to use comptime to expose a kernel builder DSL, followed by a GPU compiler pipeline implemented in Zig (a completely separate compiler). This seems straightforward and allows you to implement and gain access to the specialized semantics / optimizations that you’d need for high-performance kernels?

I could absolutely be wrong, interested in thoughts.

When will GPT-5.6 Protomolecule drop? Me and the boys on Eros can't wait to get our hands on it!

Loops work when you spend the proper amount of time to understand what you want ahead of time. The prerequisite is clarity — enough clarity that you could write a careful specification that you could hand off to a junior colleague.

Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your meat brain avoid thinking time.

So most of my time is iterating between these two phases: I don’t understand what I want, I need to read and write and play with code, okay it’s been long enough I think I know what I want (it is extremely easy to deceive yourself) … okay now I do actually know what I want and I can write a loop.

Many people think they can jump ahead with agents. You cannot fake understanding or clarity. It is painfully obviously when someone skipped that meat brain understanding phase.

I see, thanks for clarification -- where does one find the LoC comparing Claude to human written? Interesting if that's available publicly.

If the March leak of Claude Code was Mythos / Fable in preview ... I'm not sure I'm that worried about AI capabilities.

Seriously -- if you dig through that source code, and then listen to the messaging, it seems hard to keep a straight face.

Also, hasn't this company been claiming that almost all their code is written with AI for significantly longer than "post-Mythos internal preview"?

The mushroom product video gave me a good laugh. Thank you!

I agree with you that my original message was sloppy, and also with your claim that full Rust has not been mechanically proven sound.

But that is not the same claim as “safe Rust can cause UB"

If you are claiming the latter, please provide a minimal safe Rust program that causes UB without unsafe, FFI, proc-macro tricks, compiler bugs, or an unsound safe API implemented using unsafe?

If you can produce such a program, of course you are right.

Explain away then my friend: surely your clear explanation will benefit many other readers who came away with similar confusion?

I'm not sure where or how to convey this, because I've seen several of these languages designed with AI, documentation created using AI, etc -- posted on Hacker News in the last months or so, and I've responded to each one with roughly the same feedback (and I'm assuming good faith: that the intent is that the poster wishes to grow as a language designer).

Your audience, or whoever you aim your work at, should be treated with respect. Otherwise, why should they give you the time of day? Why would you expect them to respond positively to effort alone when effort (in code and in shit prose) is extremely cheap right now? Their time is not cheap ...

When I read the documentation, and it is extremely clear that you haven't taken the time to clarify your ideas, when much of it is LLM prose, when much of the content introduces highfalutin ideas without motivation, blending categorical concepts (which, by the way, should never be mixed with vague prose claims about the language), violating my reader context model, preventing me from understanding what problem exactly your language design is solving (where is that problem stated clearly?), it is a waste of my time.

> The work took 3 weeks in total ... it's worth a look, and I hope it will win some converts, and that someone will want to help me with its development.

You've gone too fast, too much is vague, nothing is clear.

I'd delete everything, start over, and try and explain just one of the ideas clearly. Seriously. This sounds harsh, but it's honestly the correct approach to something as subtle and nuanced as programming language design.

My feedback is that both the motivation and the language looks like someone who is confused about several concepts in programming languages.

Safe Rust cannot cause undefined behavior ... static systems do not need to predict all runtime paths, presumably referring to the halting problem and Rice's theorem (or whatever the author intends this to mean, the writing is unclear): these systems prove properties for all accepted programs under a conservative model, which covers all allowed programs within the subset admitted by the model.

The guarantee that Rust provides are sound, and the claim depends on trust in compiler implementation and any `unsafe` code involved in used APIs, etc (which is not uncommon: the same thing is true for Lean's kernel, for instance).

As Pauli said, much of the writing is not even wrong ... many of the language critiques read like transcriptions of vibes derived from AI discussion: "C++ smart pointers with extra steps" -- this is not a serious statement. I'm not even a serious user of Rust, but I know enough about the language design to understand how stupid this statement is.

So the goal seems to be: Java, but without nulls, erased generics, OOP, or the JVM.

Best of luck.

In summary, we present a system which actually doesn’t work because real experts looked through the thing our system produced and found that it was full of reward hacking, but of course we’re honest about this and we’ll adjust our metrics, and so we think it’s okay to just slop this out there because we’re honest and we will make promises to fix everything, and we also hope you like our attempt to gain notoriety for Meta AI.