alt.hn

5/23/2026 at 10:57:51 PM

Bun.Image

https://bun.com/docs/runtime/image

by chakintosh

5/23/2026 at 11:48:30 PM

This looks like one of the better pieces of LLM-output documentation I've seen. It's bad technical writing, but better than most of what I've seen come out of an LLM.

---------------

Pre-empting the "how can you tell", here's some of the tells.

> The API is shaped after Sharp:

Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing.

> The constructor accepts a path, bytes, or a Blob — including Bun.file() and Bun.s3().

> The format is sniffed from the bytes — extensions and Content-Type are ignored.

Repeatedly formatting statements as X: Y, X — Y, or [b]X[b] Y is also an LLM-ism.

> Don’t pass user-controlled strings directly to the constructor — that’s an arbitrary-file-read primitive.

> When passing a TypedArray/ArrayBuffer, don’t mutate it while a terminal is pending — decode runs off-thread and borrows the bytes.

Doing so by leading with what-it's-not / what-not-to-do is even more of an LLM-ism.

by furyofantares

5/23/2026 at 11:55:14 PM

The other big problem with LLM documentation is that it tends to drift from the code, because agents forget to update it. Then later agents sometimes reference the documentation, sometimes reference the code, and get confused.

For agent written code I now default to no documentation and explanatory function signatures, it works better for me at least.

by solenoid0937

5/24/2026 at 12:02:22 AM

Humans also tend to forget to update documentation and the same confusion happens. I don't think it's really a new problem.

by michaelmior

5/24/2026 at 12:09:20 AM

I agree, I think for agents though, documentation does more harm than good. When I'm writing code with an agent I tell it to skip documentation entirely (reading or writing it) and it leads to more accurate outcomes.

When agents write most of our code, I question if we will still even need documentation.

by solenoid0937

5/24/2026 at 1:37:49 PM

I think that's a fair take. I think we definitely still need specs that describe the desired behavior as an artifact. But documentation describing the implementation definitely feels less important.

by michaelmior

5/24/2026 at 12:36:50 AM

I just have a rule in AGENTS.md that any additions, removals or modifications to the public facing APIs should update the corresponding API documentation, works fine for me (assuming both sit in the single workspace).

by diath

5/23/2026 at 11:59:45 PM

[flagged]

by arkadiytehgraet

5/23/2026 at 11:22:39 PM

> The API is shaped after Sharp: construct from an input, chain transforms, pick an output format, then await a terminal method.

(https://sharp.pixelplumbing.com/)

Good! I like the pipeline workflow.

by wxw

5/23/2026 at 11:49:10 PM

I really like this. Having image manipulation as a core standard library feature rather than an optional package makes complete sense to me for a web development platform in 2026.

It's not like image manipulation is a poorly understood problem or a fast-moving field.

by simonw

5/24/2026 at 3:43:31 AM

> It's not like image manipulation is a poorly understood problem

You would think, but the initial implementation of this stripped ICC profiles (https://github.com/oven-sh/bun/issues/30197), and while that was fixed in time for the release, it still currently doesn't understand EXIF rotation metadata (https://github.com/oven-sh/bun/issues/30235) or high-bit-depth images (https://github.com/oven-sh/bun/issues/30462)

by 190n

5/24/2026 at 3:46:44 PM

Sure, but there's a finite list of things like that. I'll be surprised if there's anything notable outstanding like that within a month or two.

by simonw

5/23/2026 at 11:45:37 PM

Nice to see lots of LLM-generated text

by nfredericks

5/24/2026 at 12:10:02 AM

[dead]

by varispeed

5/23/2026 at 11:37:26 PM

Glad to see that Bun is doing something that Java has been doing since 1998.

by onesingleblast

5/24/2026 at 12:00:07 AM

Pretty sure Java didn’t slop code its APIs in 1998.

by dzogchen