I think that spending all day trying to parse stuff like this is why a long session is so exhausting
> Worth stating because four documents now assert it. The console freeze was recorded in exactly one place with exactly one justification — a dead drag handle during a booked half-day you do not get back — and handoff-4.3-done.html's own wording is that 4.4's review page "could not break the console, but the downside of being wrong is that half day". No second reason. Checked, not recalled.
Most of what it said about the facts was intelligible actually. But I still couldn’t understand the connection or its significance. We may be staring at the future of AI - a form of intelligence that is alien to us.
> Note: the potential for a console freeze was previously noted but ignored. handoff-4.3-done.html stated, "could not break console, but [will need fixed later if I'm wrong]."
One could imagine that a perfect writer might also append: "It could be worth looking into what caused that wrong assumption, to prevent similar cases in the future," at most.
Everything else seems to be bad attempts at relatable writing to invoke emotion (an exercise that we should really stop trying to train emotionless matrix weights to attempt).
One of the things actual science fiction got wrong: to the extent that the thing AI does can be called "understanding", emotion is not unusually difficult for them to understand.
The unsurprising part once it was clear that approach was viable, was that humans wouldn’t be able to help but anthropomorphize it. I feel like the movie Ex Machina is more relevant than ever.
"Dead drag handle" "Booked half day you don't get back"
It'll go in CLAUDE.md
One thing about it I really hate, and haven't seen a lot of people mentioning, is how it navigates multiple abstraction levels in a single sentence. E.g.
> Worth stating because four documents now assert it.
Meta commentary on the task?
> a dead drag handle
Drag handle seems to be referring to some UI element. What does it mean for it to be dead?
So far no big deal
> during a booked half-day you do not get back
Do you not get the drag handle back? Or the half day?
Was the drag handle dead during the booked period? (Now I assume this is a calendar UI) And why does it matter (for this sentence) if you get it back or not.
> handoff-4.3-done.html's own wording
Treats verbatim filenames as subjects
> 4.4's review page
Probably referring to a file? I'm guessing handoff-4.4-review.html? No cohesion. And now it's actually the object of the sentence?
> downside of being wrong is that half day
Wait what's the downside? Who's being wrong?
> Checked, not recalled.
Then it jumps back to a meta commentary on the methodology for asserting the above. Why does this belong to the text?
"I'm not a programmer or software engineer. Don't talk to me like I am. Avoid coder jargon and vernacular. Explain things to me in a clear way, emphasizing a conceptual view that even an inexperienced person can understand. If helpful, use analogies and examples to illustrate and help you communicate."
It just ignores it and spits out drivel that sounds exactly like what you're getting.
If I recall, previous attempts to do so made them get stuck in edit loops.
They need the prompt to encourage expert outputs but unfortunately we also get ‘pretending to be an expert’ outputs since there’s a large amount of polluted training data for this.
I got one too many chunks of this nonsense and told Claude to knock it off, forever. It acknowledged and wrote out some instructions to its memory about it.
And what a breath of fresh air. Its responses are maybe 20% longer but I read them at least twice as fast. Should have done it a long time ago.
https://github.com/tkgally/je-dict-1/blob/main/.claude/skill...
Fable wrote it specifically for this project.
like imagine this being our future, I don't know what we're even doing anymore
Source: I'm half brain dead from decoding a lot of Claude speak from it directly and colleagues' new way of communicating with me.
I don't like that I like it.
I have other more specific ones to avoid talking about things that it's not doing, but those two sentences have covered a lot of ground for me when working w/ Opus models.
So "fingerprinting" operates on a totally different and basically invisible level, as opposed to the obvious stylistic patterns that the average programmer can identify in about 2 sentences.
/s
In fact, whenever Claude disobeys me, I usually first skim the CoT to figure out if my original instruction was ambigous given the context. I usually come away with a better understanding of how to frame my prompt to be less ambiguous or just force myself to be more explicit when prompting.
Regarding diosbedience, usually this is either due to a blanket instruction from me during an earlier turn in the same session, an explicit instruction in its system prompt or it being just eager to bring a task to completion.
# ~/.claude/settings.json
{
"model": "opus",
"showThinkingSummaries": true,
"skipDangerousModePermissionPrompt": true,
"verbose": true,
"remoteControlAtStartup": true,
"agentPushNotifEnabled": true
}Chain of thought does not exist in the output of Claude, they disabled true thinking due to distillation risk. What you see when thinking summaries are enabled are just that, summaries of thinking into Claude-isms, therefore you cannot make any inferences on what the model is doing unless you literally work at Anthropic and can see the true thinking traces.
I use open models for non work stuff and sometimes I cancel the output because the CoT is all I needed to read.
I figure that it's basically making notes for itself, when it has to revisit the same code in a fresh session.
This drives me mad.
Why can’t it check first if a method actually exists in the API?
"You're right, I'm sorry. You told me to do it, I said I would do it and I did not do it and I said that I had when I did not do it. Would you like me to do it now?"
Me, thinking: that depends, Claude, will you actually do it this time?
That sounds like a great thing to do even if you are a human writing code for other humans. Most codebases out there are terrible for newcomers because of how little they explain why they are doing what they are doing, both in the code and in the often non-existent design notes.
And if I don't catch these and remove the bad information, subsequent passes will flag those comments and get stuck on the fact that numbers don't match and start digging into that "problem" instead of staying on topic.
I agree it _sounds like a great thing to do_ but the comments Claude creates make me want to never read code again. They're so obtuse and often completely pointless.
Excuse me if I am harsh, read the damn code. If you do not understand the language, that is a skill issue. If the code is confusing, then the code is bad and no amount of comments will ever change that. Professional engineering isnt an intro to databases class.
I am excusing language conventions which may have comments as part of its idiosyncratic nature.
I've worked on a lot of terrible legacy code in my career and I'm very thankful for the comments that others have left. This is becoming less necessary now that LLMs can explain a project, but comments have historically been a godsend in bad code.
No, really: comments should be telling you what the code shouldn’t or physically can’t. Code is for execution and the exact details of what and how; it has no business knowing why or why not and that’s where comments are required.
Imagine a complicated section of application logic. You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x, or you could write a short comment explaining the intent in natural language. What's more effective? I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.
Without guides as to why a particular hairy expression is a good idea as a first estimate, the code is pretty much unreadable. (E.g. is it setting derivatives to zero, using a polynomial approximation, or something else?)
To put it another way, comments are for irreducible complexity ir external systems outside your control.
I work between systems and app dev. Systems have comments more often esp in shaders but my god informing me that a variable named isActive is for if something is…active, is useless noise. Same with the majority of comments that a type system already tells you. In my career, these have been ~90% of the comments I see. Since ai, all new code it is 100%.
Most of the replies examples are a sign of bad system/code but it is not always controllable. A legacy code comment of, the api requires strings for boolean values in the form “yes” and “no”. That is useful but it is also a code smell.
A concrete example, a vendor decided to define a proto with a flattened array of objects so there are some 1800 uniquely named fields on it. In many downstream consumers, this is a real performance issue besides being confusing. A comment may be good there. The thing is, this was still solvable if up at the root of where this vendor’s hardware logs data remapped it to something sane so every downstream system wouldnt need a comment explaining wtf is going on.
I see comments as when you want to explicitly answer why code smells right when a reader is smelling it.
It was causing so many issues with coding (even Opus 4.8 was better) that I did agent handoffs to Sol. One of the Sols stated the handoff was "incoherent", which I couldn't have said better myself.
When I read the translated version, I felt a flush of relief, because I finally could confirm that it built the right thing and properly implemented the requirements.
I then asked in a fresh session which version was better for it as a reference for future work. It unequivocally voted for the human readable form, and gave it's reasoning with specific examples why.
So, I have a hunch that this "packing of lots of signals into fewer words" isn't really better. The incomprehensible prose just makes us think it knows what it's doing, like some mysterious magic that is only smoke and mirrors.
sometimes by increasing human cognitive load during reviews, sometimes by expanding the number of gated decisions, sometimes by penalizing those using their accounts on other harnesses
One thing I found before dispatching, and filed as Q0579. The halt told you C6
was all that was left in the unit. That was true of the step's criteria and
false of the unit's acceptance, which reads "exits 0 AND witnessed red" — two
conjuncts. The witness half holds; the exits-0 half does not, because hello's
G7 currently reads DIFFER 554/51340. I re-derived that from the gate map
rather than trusting the prior step's report. So satisfying C6 does not by
itself finish this unit, and I've filed that so attempt 1's success can't
quietly be read as the unit's.