// The lesson from the Parse-dont-fail-era campaign

// Judged on merit from computed properties during the cursor saga

// Chop 6ms due to lenience and lax-constraints vs 18ms baseline April perf measurements

Thanks, this sequence of 33 words alone was enough to give me a searing migraine.

Glad to know it worked. Still pending: the assumed-defaults research track plus the validation-only build phase D demanded — your call on whether to start one now or deploy tonight’s campaign to surface any wrinkles the spec drifted on

It's incredible, because I Feel like you've been watching me work.

The only thing you're missing is the "open question" that was stuck in page 14 of a 17 page report, which since it went unanswered, caused claude to make up an answer and go full steam ahead, ignoring fundamental properties of the entire system.

Idk if you’re coming up with these on the spot but they’re linguistically fascinating.

Came up with them on the spot. Unfortunately, I've been working with Claude so much it's like my brain can autocomplete them natively.

it's not just you, there is research that people are starting to talk more like chatGPT. you have a gift for parody though.

That's a sharp insight, and it reveals something core to communication that I otherwise wouldn't have considered- HN item 6b translocates reliospacactivity of our medium.

Shall I engage the tachyon beams, sir?

Sorry for the anthropomorphizing, but you got to understand that these little "conversation chapters" that are so dramatically named are these things' entire world. Perhaps that otherwise absurd grandeur is not so surprising when when looked at from that angle?

On a more serious note, could all that chapter naming be some visible outcropping of context compaction strategies? "Condense the conversation history into a summary". Not really surprising that it comes up with these "cute" headlines. Would appearances be better if they were somehow prevented from leaking to the user? Sure. Would results be better? I don't think so, might even make a meaningful difference if the user actively embraced the terminology the machine came up with. Ouch.

As a human who isn't a professional programmer, I've been writing comments like,

    // let's track age!!
    // this is harder than you'd think as I with totally impressive
    // foresight didn't add age to the raw data.
    //
    // More honestly, I didn't want to add age to the astro data as that's
    // a calculation that can change depending on how you slice it.
    //
    // Hence we need to figure out their age first.

Is that bad???

// Workaround because we don’t have an age column in the db. See JIRA-1234

This would be better IMO :)

Most of the context belongs in a ticket. And the difficulty is subjective!

I'm mostly writing code for myself, but it's a project that'll end up being public and it'll be available for others to do whatever they want with. Does that change the answer?

I hate it when a comment tells me to see JIRA-1234. What if in a year's time we stop using Jira?

Far too often the answer has been that it doesn't matter, because the reason you stopped using Jira is the company stopped sending paycheques.

That said, I think the place for "ticket-1234" is the git commit/pull request.

Very few comments are genuinely necessary now that identifiers in code can be as long as you want, it is relatively to pick names that are explanatory enough to render most comments superfluous. 1% exceptions for unusual algorithms. (You're using named consts/enums rather than magic numbers, yes?)

personally it's fine and I've thanked myself many times for overly detailed comments coming up to some from 8 years ago and thinking how tf was I so smart/stupid (depending on the context)

I think this passes. In general "why" over "what". Give context to why something is made like it is (when seeming convoluted or strange). Sometimes I think one can give historical facts for really hairy hard to fix issues that have seen multiple iterations. But LLMs don't see these nuances. They frequently smuggle in completely irrelevant details in comments, e.g. including details from the given task context, not understanding what is relevant for the code module as a whole.

Edit: For API comments it's "what" of course, detailing the workings and contracts of the exported method, function or type, so one doesn't have to read the code to figure out how to use it.

This one drives me nuts, especially because I divvy up plan documents into such granular sub chunks and Ralph loop over them, I get nonsense commit messages and comments like “PLAN-5.1.A.d.42 load bearing reassertion” unless I AGENTS.md to hell and back… and still end up having to manually reject 5-10% of commit messages because the agent simply forgets AGENTS.md instructions until reprompted.

Sometimes you can do a separate skill for committing only and basically minimize the context - "analyze the commit messages, the original instructions, and this set of things to stop wasting my FUCKING TIME"

I've definitely considered writing a commit skill and a `cc-safety-net` custom rule to fully forbid `git commit` other than with `--amend` ++ `--no-edit` outside of that skill. Hm, maybe that's a task for an upcoming weekend.