I wonder if one reasons new versions of GPT appear to get better - say at coding tasks is just because they have new knowledge.
When ChatGPT4 comes out, new versions of API’s will have less blog post / examples / documentation in their training data. So ChatGPT 5 comes out and seems to solve all the problems that ChatGPT4 had, but then of course fail on newer libraries. Rinse and repeat
what's funny is that newer models will now be trained on the exact question, "Without adding third-party dependencies, how can I compress a Data stream with zstd in Swift on an iPhone?" and similar questions to it, because of this post
maybe the key to training future llm's is to write angry blog posts about the things they aren't good at and get them to the front page of hn?
>...it’s a useless tool. I don’t like collaborating with chronic liars who aren’t able to openly point out knowledge gaps...
I think a more correct take here might be "it's a tool that I don't trust enough to use without checking," or at the very least, "it's a useless tool for my purposes." I understand your point, but I got a little caught up on the above line because it's very far out of alignment with my own experience using it to save enormous amounts of time.
I am sympathetic to the reasoning as to why LLMs should not be used to help some programmers right now. But I get a little frustrated seeing many of these kinds of posts that talk about fundamental limitations of LLMs vs humans on the grounds that it cannot "logically reason" like a human does. These are limitations in the current approach to training and objectives; internally, we have no clue what is going on.
> it’s “just a statistical model” that generates “language” based on a chain of “what is most likely to follow the previous phrase”
Humans are statistical models too in an appropriate sense. The question is whether we try to execute phrase by phrase or not, or whether it even matters what humans do in the long term.
> The only way ChatGPT will stop spreading that nonsense is if there is a significant mass of humans talking online about the lack of ZSTD support.
Or you can change the implicit bias in the model by being more clever with your training procedure. This is basic stats here, not everything is about data.
> They don’t know anything, they don’t think, they don’t learn, they don’t deduct. They generate real-looking text based on what is most likely based on the information it has been trained on.
This may be comforting to think, but it's just wrong. It would make my job so much easier if it were true. If you take the time to define "know", "think", and "deduct", you will find it difficult to argue current LLMs do not do these things. "Learn" is the exception here, and is a bit more complex, not only because of memory and bandwidth issues, but also because "understand" is difficult to define.
Actually internally we do know what’s going on these days. Anthropic put out a white paper detailing how Claude can’t math but many math examples are out there so Claude can fake it.
I wish you’d stop magic LLMs some kind of magic thing they aren’t.
I work in the theory of deep learning, so I can say with some authority that while we know a really good number of things, and are able to probe the internals much better than most of the public realises, when it comes to philosophical questions that compare their nature with humans, we have a long, long way to go. The biggest problem is that we're still trying to work out what it is we even want to know that will tell us whether we have achieved AGI or not.
Linear probes and autoencoders have been useful, but we're quickly reaching the limits of those techniques. And don't even get me started on approaches to theory that operate by cherry-picked examples. Anthropic's contributions have been beneficial to the field, but are far from conclusive.
"Based on my research, zstd compression is not natively supported by iOS or Apple's frameworks, which means you cannot use zstd compression without adding some form of external code to your project"
I see that GitHub Copilot actually runs code, writes simple exploratory programs, iteratively tests its hypothesis. it is astoundingly effective and fast.
same here. nothing stops this AI to actually trying to implement whatever this AI suggested, compile it, and see if this is actually works.
grounding in reality at inference time, so to speak.
An implication from the 1985 paper of Peter Naur on programming as theory building is that the current LLM coding tool would be very effective in generating technical debt even when it works ... use at your own risk.
I'm currently working as a hands-off VP, so I don't use LLMs for coding at work, only for emails and document editing. I do use it for my hobby weekend coding stuff, which usually involves writing short 100-1000 LOC Python toy programs for my own education/entertainment. My way-of-working is quite primitive, I have zero integrations, nothing agentic, I just copy/paste with ChatGPT.
For this use-case it's been very useful, it can usually generate close-to-complete solutions, as long as it's one of the major programming languages, and it's a reasonably standard problem. So in general I'm always surprised when people say that LLMs are completely useless for coding --- this is just not true, and I feel sorry for people who shut themselves off from a useful tool.
But even at this small scale, even the best (o3) models sometimes totally fail. Recently I started a series of posts on distributed algorithms [1], and when I was working on the post/code for the Byzantine Generals / Consensus algorithm, o3 --- to my honest surprise --- just totally failed. I tried about 10 different times (both from scratch and describing the incorrect behaviour of its code), also showing it the original Lamport paper, and it just couldn't get it right... even though the toy implementation is just ~100 LOC, the actual algorithm portion is maybe 25 LOC. My hypothesis is that there are very few implementations online, and additionally I find the descriptions of the algorithm a bit vague (interleaves message cascade and decision logic).
ChatGPT 5> Without adding third-party dependencies, how can I compress a Data stream with zstd in Swift on an iPhone?
(It auto-routed to its thinking model, took 25s)
> Short answer: you can’t. iOS doesn’t ship a public zstd encoder/decoder. The system Compression and AppleArchive frameworks only expose lzfse, lz4, zlib/deflate, and lzma. So with only Apple SDKs, there’s no way to produce zstd-compressed bytes.
>
> Two practical paths:
> 1. If zstd isn’t mandatory, use a built-in codec (lzfse or lz4 are fastest) via Compression’s streaming API. Example (pure Swift, no deps) that compresses an arbitrary byte stream:
>
> <code example>
> 2. If zstd is mandatory, you must embed zstd yourself. That can mean:
> - Vendoring the official C sources (libzstd) directly into your project and calling them via a tiny Swift wrapper/bridging header
> - Statically linking a prebuilt libzstd.a you compile for iOS
LLMs can be a useful tool, maybe. But don’t anthropomorphize them.
(but, earlier)
If a tool is able to actively mislead me this easy, which potentially results in me wasting significant amounts of time in trying to make something work that is guaranteed to never work, it’s a useless tool. I don’t like collaborating with chronic liars.
> This concludes all the testing for GPT5 I have to do. If a tool is able to actively mislead me this easy, which potentially results in me wasting significant amounts of time in trying to make something work that is guaranteed to never work, it’s a useless tool.
Yeah, except it isn't. You can get enormous value out of LLMs if you get over this weird science fiction requirement that they never make mistakes.
And yeah, their confidence is frustrating. Treat them like an over-confident twenty-something intern who doesn't like to admit when they get stuff wrong.
You have to put the effort in to learn how to use them with a skeptical eye. I've been getting value as a developer from LLMs since the GPT-3 era, and those models sucked.
> The only way ChatGPT will stop spreading that nonsense is if there is a significant mass of humans talking online about the lack of ZSTD support.
We actually have a robust solution for this exact problem now: run the prompt through a coding agent of some sort (Claude Code, Codex CLI, Cursor etc) that has access to the Swift compiler.
That way it can write code with the hallucinated COMPRESSION_ZSTD thing in it, observe that it doesn't compile and iterate further to figure out what does work.
Or the simpler version of the above: LLM writes code. You try and compile it. You get an error message and you paste that back into the LLM and let it have another go. That's been the main way I've worked with LLMs for almost three years now.
I call this genre of article "I'm too lazy to think about how to deal with the fact that LLMs are sometimes wrong, especially when they aren't using thinking and are given short, leading prompts."
Ok great! For those of us who aren't too lazy for it, LLMs are providing a lot of value right now.
I find it hard to empathize with these sorts of articles. I think in, in the spate of GPT-5 related content recently, I've been seeing a lot of articles that boil down to "I tried GPT-5 on a single hard question, and it gave an answer. This proves that all LLMs are useless." And I don't think I'm distorting the author's viewpoint. He goes on to say "This concludes all the testing for GPT5 I have to do" after conducting a single test.
This seems like particularly harsh criteria; what would happen if I applied this to other tools?
- I used Typescript, but it missed a bug that crashed prod, so it is "absolute horseshit"
- I used Rust, but one of my developers added an unsafe block, so it's trash.
My issue with LLMs isnt really the tech itself. They're occassionally useful, although HOW useful seems to depend on a persons skillset.
My main beef with the AI hype is that it's allowing a lot of idiots to significantly devalue our profession in a really noxious and irritating way to people that generally don't understand what we do but would like to pay us less or pay less of us. I'm annoyed at other software developers that don't seem to see how harmful this will be for us when the insane investment bubble bursts and AI becomes a lot more expensive to use. We will probably have lost a generation of junior developers who have become dependent on a suddenly expensive tool. And execs will just think the seniors need to pick up the slack. And expectations on AI will be a lot higher when the subscription is more like 200 or 2000 a month.
And that's just for coding! I'd be furious if I was an artist and generative AI was being trained on my portfolio to plagiarize my work. (Badly)
What I never see justified is why any of this is good for society. At best it lets billionionaires save some money by getting rid of jobs, or vibe coders pretend they can build a product until they hit a wall where real understanding is neccessary. If you follow the trail of who is supposed to benefit from these things its not many of us. If AI were to disappear today I don't think my life would be any worse.
I love posts like these because it just reinforces that I made the right decision in spending as much time as I do in getting really really really good at using llms.
* LLMs, when presented with a question to which they don't know the answer, tend to make up a wrong answer rather than say they don't know.
* Therefore, LLMs are useless.
Yes, LLMs do that, and it is a problem.
No, that does not make them useless. It's usually much easier to check their answer than it would have been to search for an answer yourself. If they are right, you saved time. If they are wrong, at worst you wasted a couple minutes. But they are right often enough that it can be worthwhile, especially if you have a feel for what questions they are likely to know the answer to and what questions they aren't.
The top comments are focusing on what "know" means in the context of an LLM but I think that while it's an interesting discussion it misses the point. Even if we agree that an LLM can "know" things, the tech has been heavily advertised as nothing less that transformative. If it can't help itself from inventing non existent answers or count the number of "r"s in the word blueberry (a test I tried myself the other day on my phone's chat-gpt app, it said "three") it's not transformative.
I'm almost positive that he didn't use thinking mode, because I've asked GPT-5 thinking his question verbatim in 10 parallel threads and it said "you can't" and thoroughly explained why every time. Below is the first response I got back.
---
Short answer: you can’t. iOS doesn’t ship a Zstandard encoder/decoder. Apple’s built-in `Compression` framework only exposes LZFSE, LZ4(/RAW), zlib/DEFLATE, and LZMA—no ZSTD knob to turn. ([Microsoft Learn][1], [Apple Developer][2])
If you’re okay with a built-in alternative that’s “zstd-ish” in speed/ratio, use LZFSE via `Compression`’s streaming API. Here’s a minimal streaming compressor you can drop in; it takes chunks of `Data` and yields compressed chunks (no third-party code):
```swift
import Compression
final class StreamCompressor {
private var stream = compression_stream()
private let algo: compression_algorithm
private var isInitialized = false
init(algorithm: compression_algorithm = COMPRESSION_LZFSE) {
self.algo = algorithm
}
func append(_ input: Data, isFinal: Bool, outChunkSize: Int = 64 * 1024) -> [Data] {
if !isInitialized {
let status = compression_stream_init(&stream, COMPRESSION_STREAM_ENCODE, algo)
precondition(status != COMPRESSION_STATUS_ERROR, "compression_stream_init failed")
isInitialized = true
}
var outputs: [Data] = []
input.withUnsafeBytes { (srcBuf: UnsafeRawBufferPointer) in
var flags: Int32 = isFinal ? Int32(COMPRESSION_STREAM_FINALIZE.rawValue) : 0
stream.src_ptr = srcBuf.bindMemory(to: UInt8.self).baseAddress
stream.src_size = srcBuf.count
var out = Data(count: outChunkSize)
out.withUnsafeMutableBytes { dstBuf in
while true {
stream.dst_ptr = dstBuf.bindMemory(to: UInt8.self).baseAddress
stream.dst_size = dstBuf.count
let status = compression_stream_process(&stream, flags)
let produced = dstBuf.count - stream.dst_size
if produced > 0 {
outputs.append(Data(bytes: dstBuf.baseAddress!, count: produced))
}
if status == COMPRESSION_STATUS_OK && stream.src_size == 0 && stream.dst_size > 0 {
break // need more input to continue
} else if status == COMPRESSION_STATUS_OK && stream.dst_size == 0 {
// output buffer filled; loop to drain more
continue
} else if status == COMPRESSION_STATUS_END {
break
} else if status == COMPRESSION_STATUS_ERROR {
preconditionFailure("compression_stream_process failed")
} else {
// Shouldn’t happen
break
}
}
}
}
return outputs
}
deinit {
if isInitialized {
compression_stream_destroy(&stream)
}
}
}
```
Usage:
```swift
let compressor = StreamCompressor(algorithm: COMPRESSION_LZFSE)
var compressed: [Data] = []
for (i, chunk) in chunks.enumerated() {
let final = i == chunks.count - 1
compressed.append(contentsOf: compressor.append(chunk, isFinal: final))
}
// `compressed` now contains the zstd-adjacent (LZFSE) stream
```
If you truly need the ZSTD format (interop requirement), you’ll have to ship the reference C library (`libzstd`) in your app (static link it and call through a tiny Swift wrapper). That’s still “third-party,” even if you vendor the sources instead of using SPM/CocoaPods. There is no system-provided ZSTD on iOS today. ([GitHub][3])
tl;dr: iOS doesn’t expose ZSTD. Use `Compression` with LZFS...
if you treat it like stochastic software it is, how is 95% chance of one-shotting a problem not useful? I feel like the biggest problem most people have with LLMs is the "lack of accountability", and then the same people say "don’t anthropomorphize them"
28 comments
[ 2.6 ms ] story [ 46.5 ms ] threadWhen ChatGPT4 comes out, new versions of API’s will have less blog post / examples / documentation in their training data. So ChatGPT 5 comes out and seems to solve all the problems that ChatGPT4 had, but then of course fail on newer libraries. Rinse and repeat
maybe the key to training future llm's is to write angry blog posts about the things they aren't good at and get them to the front page of hn?
simple fix - probability cutoff. but in all seriousness this is something that will be fixed. don't see fundamental reason why not.
and I myself seen such hallucinations (about compression too actually) as well.
I think a more correct take here might be "it's a tool that I don't trust enough to use without checking," or at the very least, "it's a useless tool for my purposes." I understand your point, but I got a little caught up on the above line because it's very far out of alignment with my own experience using it to save enormous amounts of time.
In one rearrangement, he got "Son sues father for xyz". That headline came true 2 years later.
> it’s “just a statistical model” that generates “language” based on a chain of “what is most likely to follow the previous phrase”
Humans are statistical models too in an appropriate sense. The question is whether we try to execute phrase by phrase or not, or whether it even matters what humans do in the long term.
> The only way ChatGPT will stop spreading that nonsense is if there is a significant mass of humans talking online about the lack of ZSTD support.
Or you can change the implicit bias in the model by being more clever with your training procedure. This is basic stats here, not everything is about data.
> They don’t know anything, they don’t think, they don’t learn, they don’t deduct. They generate real-looking text based on what is most likely based on the information it has been trained on.
This may be comforting to think, but it's just wrong. It would make my job so much easier if it were true. If you take the time to define "know", "think", and "deduct", you will find it difficult to argue current LLMs do not do these things. "Learn" is the exception here, and is a bit more complex, not only because of memory and bandwidth issues, but also because "understand" is difficult to define.
I wish you’d stop magic LLMs some kind of magic thing they aren’t.
Linear probes and autoencoders have been useful, but we're quickly reaching the limits of those techniques. And don't even get me started on approaches to theory that operate by cherry-picked examples. Anthropic's contributions have been beneficial to the field, but are far from conclusive.
Thanks Sonnet.
Full response:
https://www.perplexity.ai/search/without-adding-third-party-...
I see that GitHub Copilot actually runs code, writes simple exploratory programs, iteratively tests its hypothesis. it is astoundingly effective and fast.
same here. nothing stops this AI to actually trying to implement whatever this AI suggested, compile it, and see if this is actually works.
grounding in reality at inference time, so to speak.
"Short answer: you can’t. iOS doesn’t ship a Zstandard (zstd) encoder/decoder in any first-party framework. Apple’s built-in Compression framework supports LZFSE, LZ4, zlib/deflate, and LZMA—not zstd."
For this use-case it's been very useful, it can usually generate close-to-complete solutions, as long as it's one of the major programming languages, and it's a reasonably standard problem. So in general I'm always surprised when people say that LLMs are completely useless for coding --- this is just not true, and I feel sorry for people who shut themselves off from a useful tool.
But even at this small scale, even the best (o3) models sometimes totally fail. Recently I started a series of posts on distributed algorithms [1], and when I was working on the post/code for the Byzantine Generals / Consensus algorithm, o3 --- to my honest surprise --- just totally failed. I tried about 10 different times (both from scratch and describing the incorrect behaviour of its code), also showing it the original Lamport paper, and it just couldn't get it right... even though the toy implementation is just ~100 LOC, the actual algorithm portion is maybe 25 LOC. My hypothesis is that there are very few implementations online, and additionally I find the descriptions of the algorithm a bit vague (interleaves message cascade and decision logic).
[1] https://bytepawn.com/tag/distributed.html
(It auto-routed to its thinking model, took 25s)
> Short answer: you can’t. iOS doesn’t ship a public zstd encoder/decoder. The system Compression and AppleArchive frameworks only expose lzfse, lz4, zlib/deflate, and lzma. So with only Apple SDKs, there’s no way to produce zstd-compressed bytes.
> > Two practical paths:
> 1. If zstd isn’t mandatory, use a built-in codec (lzfse or lz4 are fastest) via Compression’s streaming API. Example (pure Swift, no deps) that compresses an arbitrary byte stream: >
> <code example>
> 2. If zstd is mandatory, you must embed zstd yourself. That can mean:
> - Vendoring the official C sources (libzstd) directly into your project and calling them via a tiny Swift wrapper/bridging header
> - Statically linking a prebuilt libzstd.a you compile for iOS
(but, earlier)
If a tool is able to actively mislead me this easy, which potentially results in me wasting significant amounts of time in trying to make something work that is guaranteed to never work, it’s a useless tool. I don’t like collaborating with chronic liars.
Yeah, except it isn't. You can get enormous value out of LLMs if you get over this weird science fiction requirement that they never make mistakes.
And yeah, their confidence is frustrating. Treat them like an over-confident twenty-something intern who doesn't like to admit when they get stuff wrong.
You have to put the effort in to learn how to use them with a skeptical eye. I've been getting value as a developer from LLMs since the GPT-3 era, and those models sucked.
> The only way ChatGPT will stop spreading that nonsense is if there is a significant mass of humans talking online about the lack of ZSTD support.
We actually have a robust solution for this exact problem now: run the prompt through a coding agent of some sort (Claude Code, Codex CLI, Cursor etc) that has access to the Swift compiler.
That way it can write code with the hallucinated COMPRESSION_ZSTD thing in it, observe that it doesn't compile and iterate further to figure out what does work.
Or the simpler version of the above: LLM writes code. You try and compile it. You get an error message and you paste that back into the LLM and let it have another go. That's been the main way I've worked with LLMs for almost three years now.
Ok great! For those of us who aren't too lazy for it, LLMs are providing a lot of value right now.
This seems like particularly harsh criteria; what would happen if I applied this to other tools?
- I used Typescript, but it missed a bug that crashed prod, so it is "absolute horseshit"
- I used Rust, but one of my developers added an unsafe block, so it's trash.
That's right
My main beef with the AI hype is that it's allowing a lot of idiots to significantly devalue our profession in a really noxious and irritating way to people that generally don't understand what we do but would like to pay us less or pay less of us. I'm annoyed at other software developers that don't seem to see how harmful this will be for us when the insane investment bubble bursts and AI becomes a lot more expensive to use. We will probably have lost a generation of junior developers who have become dependent on a suddenly expensive tool. And execs will just think the seniors need to pick up the slack. And expectations on AI will be a lot higher when the subscription is more like 200 or 2000 a month.
And that's just for coding! I'd be furious if I was an artist and generative AI was being trained on my portfolio to plagiarize my work. (Badly)
What I never see justified is why any of this is good for society. At best it lets billionionaires save some money by getting rid of jobs, or vibe coders pretend they can build a product until they hit a wall where real understanding is neccessary. If you follow the trail of who is supposed to benefit from these things its not many of us. If AI were to disappear today I don't think my life would be any worse.
I love posts like these because it just reinforces that I made the right decision in spending as much time as I do in getting really really really good at using llms.
* LLMs, when presented with a question to which they don't know the answer, tend to make up a wrong answer rather than say they don't know.
* Therefore, LLMs are useless.
Yes, LLMs do that, and it is a problem.
No, that does not make them useless. It's usually much easier to check their answer than it would have been to search for an answer yourself. If they are right, you saved time. If they are wrong, at worst you wasted a couple minutes. But they are right often enough that it can be worthwhile, especially if you have a feel for what questions they are likely to know the answer to and what questions they aren't.
---
Short answer: you can’t. iOS doesn’t ship a Zstandard encoder/decoder. Apple’s built-in `Compression` framework only exposes LZFSE, LZ4(/RAW), zlib/DEFLATE, and LZMA—no ZSTD knob to turn. ([Microsoft Learn][1], [Apple Developer][2])
If you’re okay with a built-in alternative that’s “zstd-ish” in speed/ratio, use LZFSE via `Compression`’s streaming API. Here’s a minimal streaming compressor you can drop in; it takes chunks of `Data` and yields compressed chunks (no third-party code):
```swift import Compression
final class StreamCompressor { private var stream = compression_stream() private let algo: compression_algorithm private var isInitialized = false
} ```Usage:
```swift let compressor = StreamCompressor(algorithm: COMPRESSION_LZFSE) var compressed: [Data] = [] for (i, chunk) in chunks.enumerated() { let final = i == chunks.count - 1 compressed.append(contentsOf: compressor.append(chunk, isFinal: final)) } // `compressed` now contains the zstd-adjacent (LZFSE) stream ```
If you truly need the ZSTD format (interop requirement), you’ll have to ship the reference C library (`libzstd`) in your app (static link it and call through a tiny Swift wrapper). That’s still “third-party,” even if you vendor the sources instead of using SPM/CocoaPods. There is no system-provided ZSTD on iOS today. ([GitHub][3])
tl;dr: iOS doesn’t expose ZSTD. Use `Compression` with LZFS...