rwiggins

As a maintainer (but not on this project), I feel an implicit (professional) responsibility to carefully review PRs, especially from random people. And as a profession, we know it's often harder to read code than it is to write it. This goes double for LLM code, which sometimes lacks a coherent mental model.

So in general, the asymmetry of "I did very little work here, but I'd like you to spend your time carefully reviewing it nonetheless" can be very annoying.

But to talk about specifics: this PR's description is mostly a waste of time. The first section is a pure duplication of the diff. If I wanted before/after code blocks, I'd click the "Files Changed" tab. Ditto for "Docs-only: 4 insertions, 1 deletion, docs/graph.md only. No change to the player bundle, layout or any other page." - yeah, I can see that in the diff, thanks. (Well, that's what it was in the original diff, before the follow-up changes.)

The testing and AI disclosure sections are similarly overly verbose. I don't need commentary on the policy, nor do I need a statement permitting me to reject the PR.

As an outsider, yeah, my reaction is pretty negative. I'd much prefer a description like "Fixes #3224. Migrated from v2 asciinema-player to v3 AsciinemaPlayer.create, as described in v2 to v3 migration guide [link]. Tested locally as best I could."

A maintainer needing to ask to migrate the other v2 uses isn't a great look, either. The follow-up "fixed the other 5" comment could simply end at "fixed the other 5", without all of the nonsense afterward.

I have to wonder whether all of this truly saved anyone time.

I'd guess people truly are finding things pre-review. It's just that LLM review seems to have a limit to the number of problems it can or will find. While at the same time, LLM-written code can be an almost limitless source of bugs and errors.

It has no sense of when an architecture is doomed and needs fundamental changes. Instead, it will happily continue to chase individual bugs nearly to infinity.

But, maybe your review skill is better than the ones I've tried.

But as an example of about where I'd stop using jq/shell scripting and switch to an actual program... we have a service that has task queues. The number of queues for an endpoint is variable, but enumerable via `GET /queues` (I'm simplifying here of course), which returns e.g. `[0, 1, 2]`. There was a bug where certain tasks would get stuck in a non-terminal state, blocking one of those queues. So, I wanted a simple little snippet to find, for each queue, (1) which task is currently executing and (2) how many tasks are enqueued. It ended up vaguely looking like:

    for q in $(curl -s "$endpoint/queues" | jq -r '.[]'); do
        curl -s "$endpoint/queues/$q" \
        | jq --arg q "$q" '
            {
                "queue": $q,
                "executing": .currently_executing_tasks,
                "num_enqueued": (.enqueued_tasks | length)
            }'
    done | jq -s

    [
        {
            "queue": 0,
            "executing": [],
            "num_enqueued": 100
        },
        ...
    ]

Although, I think this example demonstrates how I typically use jq, which is like a little multitool. I don't usually write really complicated jq.

I specifically remember that we measured how far the shadow moved over time using chalk. I think this was in lieu of having a second triangle somewhere else, although, for all I know we might have used a second reference distance.

Our campus had this elaborate outdoor "observatory" that had all sorts of interesting features. The gnomon was one of them, but there were other cool things, like IIRC there was a metal sculpture where Polaris would be seen through a central hole (and a guide inscribed in the concrete to figure out where to stand for that to happen -- I think it was based on viewing height).

I have, actually! Thanks, astronomy class!

I've even estimated the earth's diameter, and I was only like 30% off (iirc). Pretty good for the simplistic method and rough measurements we used.

Sometimes authorities are actually authoritative, though, particularly for technical, factual material. If I'm reading a published release date for a video game, directly from the publisher -- what is there to contest? Meanwhile, ask an LLM and you may have... mixed results, even if the date is within its knowledge cutoff.

and setting aside the "declarative" vs "imperative" nomenclature debate --

vim is pretty dang efficient. Typing `gg` to go to the beginning of a file, or `G` to go the end. Or all the other variety of motions. There are a lot.

Also, there is not necessarily any need to move the cursor anywhere. For example, if I'm in the middle of writing some string and I've decided to change the whole thing, `<ESC>ci"` does that, with no cursor movement required.

Anecdotally, I had some pretty delicious honeycrisps last night (in WA).

To give some specifics: I only remember driving down an actual gravel road (like, for public use) a single time. In 18 years. Even my friends who lived >30min from the nearest "city" (~10k population) had paved roads all the way.

But that is just my own experience. Areas with a different climate or geography might be a totally different story. My hometown area is relatively flat, lots of farmland, and rarely gets severe winter weather.

The conditions of some of the remote roads might not have been great, mind you... and some seemed "thinner" almost, maybe paved a long time ago?

But as I've gotten older, I've started striving more and more for simplicity above all else, especially in systems design (disclaimer: I'm an SRE). Go is pretty good at being simple.

There are some things that still annoy me a whole bunch, though. Like - just one example - `fmt.Errorf` not being a first-class syntactic construct (or the difference between `%v` and `%w` in `fmt.Errorf`).