I am quite tired of this take, frankly. The implication is that if we continue iterating on prompt optimization, we're going to reinvent what, JavaScript? BASIC? Lisp?
English is not a programming language. Yet English is sufficient to communicate requirements to the degree that we actually care about. A programmer's job is to translate English into lower-level machine language. Necessary to this process is "filling in the gaps" -- that is, extrapolating the expressed intent to cover all the little details that were left unspecified. This system works because humans are at least minimally competent at predicting the preferences of other humans. If your prediction turns out to be wrong, you get feedback and iterate.
Well, guess what. LLMs are also competent at predicting the preferences of humans. LLMs can "fill in the gaps" like no one's business. LLMs can iterate on requirements like no one's business.
Product managers do not speak to programmers in a language that encodes exact requirements, and yet working software somehow gets shipped anyway. LLMs do not need exact requirements either.
Maybe I’m behind the curve here because I work in an SRE/DevOps context as of late - but LLMs routinely shit the bed and fail to solve basic issue for me when I try to use them (Thanks, Management)
I don’t need a model to shit out a REST endpoint. I need it to figure out esoteric errors that take hours or days of debugging. They just don’t do well here. Of course, if a diligent engineer refined considerations from a PM and Engineering Manager I wouldn’t have the job I have.
Further evidence that there is some kind of weird parallel universe thing going on with LLMs. "Figuring out esoteric errors" is one of the things I would cite as a particular strength of agents. I am repeatedly amazed at their ability to root-cause weird behavior on my systems. Here is one example: https://xcancel.com/lukechampine/status/2047032091053859138
I had an experience where we were getting some unusual behavior in a new release of a data store (for various reasons main hadn’t been released in quite a while). We gave Claude code the weird symptom details and the git repo and the tags for the good version and the bad version and it found the subtle bug. This was six months ago.
Now unlike the SRE case, we were the dev team and understood exactly what the logging meant as far as a problem goes, so our prompt started with the correct 0.1% of the system to look at. SRE typically has to start by finding that 0.1% slice from rather more generic metrics. And their interventions have higher risk than a controlled rollout of new code with a specific fix.
Yes, it IS confident of its weights & biases... but, if you keep at it, Claude WILL find the smoking gun, eventually. Even a broken watch is correct twice a day ( unless it's a digital watch, without a battery, in which case, it's just broken... )
But seriously -- newer Claude (and OpenAI and Google and ???) models DO find the smoking gun, if you let them keep going until they reveal the weird chain of events that leads to a bug. I was seeing the most obscure UART driver bug, where it would work at 1,500,000 baud (!) but fail by only outputting the 1st char at 230.4k and 460.8k -- and it was due to a very narrow race that would check the buffer, if not full, insert a character, and return BUT sometimes the TX Complete interrupt would happen between the check and the insert, and something else would insert, and then - buf overflow. At 1,500,000 the other process didn't have time to do that phantom insert. ANYWAY, Claude found this and proposed a fix -- simpler: spins on IRQ-protected buffer empty checks.
I'd hate to think how long it would have taken me to find that.
And THAT's the problem -- of course a human CAN find it, with sufficient focus and time; I'm sure you've found a complicated bug pretty easily sometimes, by sheer luck or good engineering instinct.
BUT, it seems to me, as human, we are capable of creating potential execution paths that EXCEED our ability to EVER figure it out -- due to not being smart enough, not enough time on the problem, or something makes it economically unfeasible.
THIS is where LLMs shine -- let 'em bang at the code for as long as it takes.
The recent Mythos bug-finding explosion I think is proof of this conjecture. I think of it like a chessboard, where a machine really can look at all possible execution paths, and locate obscure bugs; a human programer (akin to a chess program) is doing 'alpha-beta pruning' of what's likely, and only after that list is exhausted are the really weird possibilities examined.
LLMs are our friends. And, as for "WTF did the LLM just do" when it generates code? I always include the instruction "For this code you just wrote, use Best Practices to document this code, function by function and class by class, and when necessary, line-by-line, so that a junior SW developer can completely understand how this code works, using the documentation standard we use (e.g. Doxygen)."
I have also used this technique to learn new languages, or explore ones I only know a little -- it has been a godsend for leveling me up on common lisp, for example. "Give detailed comments explaining what the code is doing, assuming the code reader is fluent in C and Python, and use analogs when possible." Stuff like that.
I'm going to assume you are a product manager, or someone who does not do the actual software development. The place where you draw the line of abstraction, is what I'm basing that assumption on.
The reason why a PO can explain something in English, and you get something useful out at the other end (of the developer), is because of a myriad of other decisions you don't see. The reason why some software systems end up being efficient in maintenance and further development, is because of these myriad of other decisions.
The many decisions are the "devil in the details" that LLMs don't get right. Or, let's not anthropomorphize unnecessarily -- LLMs don't know right from wrong, and don't reason or reflect. They could only get this right by sheer luck. In a big numbers game, they'll always get it wrong. If you want to be a PO (or vibe coder, etc) and use English language on one end, and get these details right, there is only one possible approach:
A tight loop with expert knowledge reviewer. The programmer that knows pretty much what they want, in a small section. A LLM can draft it out so that the programmer saves time typing. This isn't really useful for the PO. (PS: The same general advice applies for any other use of LLMs. Tight loop. Expert reviewer)
You'd need a language that can express important details otherwise lost to the English language. And you'd need this to be deterministic. The "myriad of tiny decisions" are the true basis for the code implementation. If they're not expressible in the English language, and they're not achievable by LLMs, there really isn't any other way to achieve them.
I love programming. It's in my blood: my father and grandfather were programmers too. I have written everything from SIMD assembly to Hoon, and implemented several languages of my own. Believe me, I am intimately familiar with the phenomenon you are describing.
It's true, the devil is in the details. And I will grudgingly concede that, at present, humans are better at exorcising demons than AI. But I see no reason to believe that this will remain true. The gap is narrowing rapidly, and even today there are types of demons that AI can dispatch much more quickly and effectively than you or I can. The fact that vibe coding is possible at all (and that people are willing to pay for vibe-coded apps) is proof that an informal English prompt is sufficient to specify software to an acceptable degree. Not acceptable to everyone, naturally, but at least to the creator and the users.
I am not exactly happy about this. It is bittersweet. Much of my identity is bound up in being a programmer. The devil is in the details; but joy and whimsy and great beauty are in the details as well. For a glorious few decades, one could be an artist under the guise of producing economic value. Now, the economic aspect of producing software is being siphoned off, to be done by machines, leaving only the art. I think we will suffer for that, somewhat. But it is a small price to pay.
As long as LLMs need their users to "engineer" prompts for them to actually work well, clearly LLM-driven development is not exactly equivalent to back-and-forth conversation with a human programmer. In principle if what you say were true, software developers already wouldn't be needed anymore, because coding agents could talk to the customer directly and give rapid feedback to clear up even the smallest details. It should be uniformly better and cheaper than talking to a human developer, but that's not the world we currently live in. Currently we live in a world where LLMs that can disprove conjectures and find zero-days still need context engineering. We shouldn't anthropomorphise and assume that they will be exactly the same as us, they are undoubtedly useful but they need careful steering by specialists who understand how LLMs interpret prompts.
After Christmas this year, I removed the tree from our living room, and in the process of being moved, it shed of needles everywhere. I swept them up, but I missed a few areas on my first pass. So I did a second pass, but when I looked again, I saw there were still a handful left. It struck me how removing >99% of the needles was nowhere near acceptable! Lots of cleaning jobs are like this, I suppose, because even a tiny mess can be visually distinct. In fact, as you approach 100%, the remaining mess stands out more.
In some cases (like this), 99.99% isn't enough. 100% is mandatory.
I moved into my house a few months ago and while I was exercising my foot discovered a nail that I guess was left by the previous homeowner/tenant/builder. Fortunately it was just a scratch, but it could have easily turned into a trip to the ER.
With a baby learning to walk and crawl, the tolerance for cleaning up nails on the floor is absolutely 100% (or 0% nail) so I scoured the entire house carpet with a strong magnet to ensure there no other surprises. I did this several times just to make sure
This was a few months ago and yet I still tend to have anxiety when walking on the carpet now.
It's like those antibacterial soaps that remove 99.9 percent of bacteria. It's not obvious whether that's number of bacteria or type of bacteria but either way the remaining ones are probably in the millions and of many types.
Sanitizing efficacy is total organism count. Hand sanitizers are regulated by the FDA and tested in vivo using ASTM 1174 (Health Care Personnel Handwash / HCPHW test) and ASTM 2755. E1174 tests for Serratia marcescens or Escherichia coli. E2755 tests for S. marcescens or Staphylococcus aureus. ASTM E1174-21 includes a precision and accuracy statement. The FDA explains: https://www.federalregister.gov/documents/2016/09/06/2016-21...
Only the USA is bound by the FDA though. The rest of the world will claim whatever they can get away with. Though yes, it is likely they mean the same thing.
I think the key is that, while you may think you have a full formal spec of f(), you actually do not. You have a program written in some language, and that language has its own spec, and the language is compiled to asm which has its own spec, and the asm executes on an architecture that has its own spec, and so on.
So when you write a function like:
func hypot(x, y):
return sqrt(x*x + y*y)
You might think you have "fully specified" hypot, but this is far from true! You have said nothing about what registers will be used, for example. This is not a problem; quite the opposite. It's the whole point of using high-level languages: they let you focus on what you care about. A spec is just a program in a very-high-level language.
I am not sure that the perspective you have taken is the same as what I understood from the parent post; what I took from it is that things like registers, memory locations, ways to implement square root, and so on, are all _implementation choices_ that are not important properties of the specification. You specify that the hypotenuse is the square root of the sum of squares, but whether square root is implemented using Newtonian approximation or a fast inverse square root is irrelevant; whether your first argument is passed in a register or on the stack is irrelevant.
Often, things like resource usage are not specified: running time, memory consumption, etc, aren't relevant enough to appear in a behavioural specification.
If your spec says "f(a, b) returns a + b", but it's just a high-level document you can use to help guide your implementation, integer overflow is just one of many ways your implementation might be inconsistent with the specification. It's still likely that the existence of a formal specification you reference during implementation means that more edge cases have been considered ahead of time than if you just had an informal spec.
If, on the other hand, you prove it but it turns out not to be true (ie, you overflow integers), your proof is wrong. If a machine verified your proof and gave you a big thumbs up, your machine verification is wrong.
If, in Idris, I write "f : (a : Nat) -> (b : Nat) -> (c : Nat * c = a + b)", then I cannot compile an implementation for which I can't show a proof that the result is _always_ the addition of a and b, for all a and b, unbounded by anything but the resources at hand with which to run the program. An implementation subject to integer overflow won't compile.
Or, I could write "f : (a : Bits32) -> (b : Bits32) -> (c : Bits32 * c = a + b)" and implement something where , but then modulo arithmetic on overflow is _part of the specification_, because "+" in there is doing the heavy lifting of being defined as addition modulo 2*32 already; by specification, 4 billion plus 4 billion is ~3.7 billion.
Everything the parent comment mentioned were implementation details that did not affect the correctness of the code.
I just wanted to point out that there are implementation details that DO affect the correctness of the code.
And, of course programs need to run on multiple architectures. So it's hard to do what people seemed to be talking about in this thread and verify code just from the source code.
If you have the luxury of proving the correctness of the CPU, compiler and OS, that should be a big win. Otherwise, it seems to just be another type of testing. Still useful, but calling it verified or proven seems a bit much.
From my perspective, it seems more to be writing another, more complicated program, with more opportunities for bugs, and seeing if the results agree
Well, ideally you proof should've failed because your axioms should be aware that arithmetic operators in the programming language of your choice are operating modulo some large power of two, and thus don't produce correct results for some particular inputs.
Admittedly, this one peeves a lot. Remember when Java's binary search and mergesort (and implementations in many other languages' standard libraries) turned out to have a bug of this kind [0]? Admittedly, the proof was informal, but if you are trying to prove some properties of a program X written in a certain programming language Y, you can't "just assume" that the semantics of Y are different from what they are, right? The integers do overflow in Java, that's explicitly stated in the Java's spec... and that means that a lot of even the most simplistic code has some very non-obvious correctness preconditions, which most of the times, I believe, are simply hoped to be true.
The first moment I specifically remember was writing a test of a new RPC protocol back in 2021. There were no agents yet, only "AI autocomplete" in the form of GitHub Copilot. I wrote the "server" half of the test, which received a name and responded with "Hello, <name>". Then I wrote the client code to send "world", and Codex suggested `if response == "Hello, world"`.
It really is crazy. I have been contributing the Melee decompilation project for the past year-ish, and things have really accelerated in 2026. Just today I decided it would be nice to have a better "permuter" (program that randomly modifies C in the hopes of finding a better asm match) so I...just asked Claude to make one, custom-tailored to my needs. It almost feels pointless to publish it to GitHub when I can just tell the other contributors "hey fyi you can ask Claude to make you a better permuter"
You should not swear at LLMs, for the same reason you should not shout a slur even if no one is around to witness it: You witness it, and witnessing yourself being toxic updates you in the direction of "I am capable of toxicity" and eventually "I am toxic." In other words, it stains your soul.
I 100% agree with you, which is why I try to be polite to the LLMs. Also, on a practical note, I've never seen an agent session go right-side-up after I crash out; the model seems to perform worse than if I just gently guide it.
LLM writing tells are getting more subtle, but they still jump off the page for me, in particular the word "genuine:"
"This is the area where Go genuinely shines, and it’s worth being precise about why"
"the lack of GC pauses is a genuine selling point"
"Humans are genuinely bad at reasoning about memory"
"There are cases where the borrow checker is genuinely too strict"
tbc I don't think the article was fully AI-generated, just AI-assisted. If so, the author did a genuinely good job of it! No one else is commenting on it, so clearly it didn't detract much from the substance. It's just weird that this is becoming increasingly common, and increasingly hard to detect.
I don't know about the author's background, but there is now a generation of non-native programmers who learned to write English by using LLMs for corrections (yeah including this comment).
The irony is that studies show LLM detectors have a much higher false-positive rate for non-native speakers [1]. If most of what you read stems from LLMs, you end up writing like an LLM.
> but there is now a generation of non-native programmers who learned to write English by using LLMs for corrections (yeah including this comment)
LLM writing has not been overly abundant for more than a couple years. I don't know where you got the idea that an entire generation of people have already learned to write like an LLM.
I have to agree here, but I'm not sure why. I don't have any clue what makes something sound AI generated or not. I got to about here "Go is clearly working for a lot of people," -- before I became suspicious that it was AI-assisted (but also maybe I'm wrong and it's not AI-assisted, I am very bad at telling). It's more about vibes (ironically) than anything else in particular. If something "sounds" AI-assisted then I instantly lose interest even if the article itself is otherwise fine. I wish people were more ok with writing their own thoughts with how it comes to them.
Agreed. In fact, one of the things I now watch for is my mind starting to "slide off" the text, or finding myself re-reading a section multiple times. It's like the brain subconsciously recognizes a lack of substance even if we can't point to a specific tell.
I've noticed LLM writing over the past year has had an unusually high tendency to talk about surfaces and, in particular, substrates. I don't expect LLM generated text to be anything other than rich with clichés. I simply wish we would all demonstrate a better editorial hand so we weren't reading the same voice, over and over.
Perhaps more people are using AI as part of an editorial process that is largely driven by what they wish to convey but where they have stopped fighting the AI on its preferred style. It’s supremely annoying when AI updates your prose with its own formulation despite plenty of instructions otherwise. Too often AIs mangle meaning which can be especially worrisome as it’s not easy to catch subtle word/grammar changes that dramatically shift meaning. Overall though, defects aside, for me, and only very recently, it’s been more helpful than not. I think AIs will continue to improve in this regard and be better editorial partners. For competent writings, it won’t replace human authorship or expert review.
Specifically, I’ve recently used ChatGPT for legal/administrative writing where the AI seems to be trained on a large corpus and seems to know the conventions and vocabulary well; a lawyer who reviewed the work had important corrections. Before AI, I would have sought model filings and have had less success at emulating the genre. So it’s lowered time/cost somewhat but it takes lots of diligence. By default, current AI outputs seems intelligible but are still really far off the mark. I’ve found a structured interview is a good way to start rather than jumping into draft generation.
Author here. I use the term 'genuinely' too often, but that's just me. I do that when speaking here as well. Suffice to say that I'm not a native speaker, so that might have something to do with it. I will go over the text and replace some of those. thx.
And it’s a good contrast with ‘just fcking use Go’ article he linked.
Go article is much more human. I love that and would choose a human centered language and human centered culture over LLM-centered everything every time
the psychosis has gone off the charts! anything that sounds odd to someone can now be labelled as an LLM text "smell"?
why scoff over someone doing assisted writing? i might age myself but kids back in the day would try to sound better by using synonym feature in ms word (or through web thesaurus) for their assignment essays. this all looks familiar to the same practice, now only made more accessible.
There's nothing in the comment you're replying to that could be described as "scoffing." What are you on about?
I feel the opposite, where AI hype is so extreme that merely someone pointing out an article may have had LLM involvement prompts a response like this. Someone incredulously painting people as ivory tower nose thumbers. If anything, it pushes me away from LLM writing more.
I also don't see how you can compare finding a synonym for a word to having your entire writing voice determined for you.
While reading the article, I remember feeling that I'm reading an LLM generated sentence a few times, but in general, this specific article look like an example of acceptable LLM usage to me. I wouldn't call it "AI slop".
It is, if I may say that, _genuinely_ hard to use LLM assist and not make the text look like LLM generated. Even when I write an email in gmail and it gives its suggestions to make the text better, each one individually makes perfect sense, but when I click a few of them, the whole email now looks like AI slop, so I would normally undo the changes, going back to my imperfect hand-written non-optimized version.
I think the whole post is AI generated. The author could have given a draft as input and perhaps edited the output in a few places.
Take this paragraph as example:
> Go got generics in 1.18, and they’re useful, but the implementation has constraints (no methods with type parameters, GC shape stenciling, occasional surprising performance characteristics). Rust generics monomorphize, each instantiation produces specialized code with zero runtime cost. Combined with traits, this gives you real zero-cost abstractions.
Every sentence says something. Every sentence is important and holds its weight. I would expect that kind of writing from very specialized books or papers, not from a blog post. Also, it makes the post harder (and more boring) to read.
> Every sentence says something. Every sentence is important and holds its weight. [...] Also, it makes the post harder (and more boring) to read.
I actually prefer that style of writing! (When it's not AI-generated ofc.) And I also try to use it in my technical blog posts. I usually re-read my drafts asking myself: "Does the reader actually care about this? Is this sentence adding something or is it just fluff?"
And actually I feel like AI text usually produces more fluff, or anyway I notice it more, but I see how it can make the result "robotic and boring".
His stuff about generics in Go is also wrong. He says that Go's standard library "avoids" them. He forgot that it has `slices.SortFunc()`. He forgot about Go `Seq`. Maybe because he has stopped using Go and is no longer that familiar.
I also wonder if it's possible that this is just "blog-speak"
The author of this article has what seems like it could be a relatively thriving consulting business, so he probably writes more to advertise his services than anything else. That kind of writing surely lends itself to a particular writing style, which is a non-insignificant chunk of the kind of writing that LLMs were trained on.
> After a disorienting visit from the FBI in May of 1990, I wrote a rant called Crime and Puzzlement, which led to my establishing with Mitch Kapor (who had previously founded Lotus Development Company) an organization called the Electronic Frontier Foundation.
English is not a programming language. Yet English is sufficient to communicate requirements to the degree that we actually care about. A programmer's job is to translate English into lower-level machine language. Necessary to this process is "filling in the gaps" -- that is, extrapolating the expressed intent to cover all the little details that were left unspecified. This system works because humans are at least minimally competent at predicting the preferences of other humans. If your prediction turns out to be wrong, you get feedback and iterate.
Well, guess what. LLMs are also competent at predicting the preferences of humans. LLMs can "fill in the gaps" like no one's business. LLMs can iterate on requirements like no one's business.
Product managers do not speak to programmers in a language that encodes exact requirements, and yet working software somehow gets shipped anyway. LLMs do not need exact requirements either.