I'm in love with Opus 4.5 right now It feels as smart as Gemini 3, but with way better code style, instruction following, CLI UX and, most importantly, speed when you just want to do something small. Also I had a super cool interaction where Claude Code was failing and walking circles, so I interrupted it and let it ask for clarifications. It made great questions, I taught some concepts, until it clicked. It then completed the task (not an easy one!), and all tests passed. Here's the interaction (summarized by Opus itself): (Claude Code interrupted) - Me: you're spending quite some time here, why don't you just ask me questions? I can always answer questions. you don't need to blindly guess and try random things, this will lead to failure. - AI: You're right, I apologize. Question: when I distribute the lambda across the SUP, how should variable redirection work? Should I be setting HEAP[lam_loc] to redirect the original VARs to the new lambdas? - Me: not sure what your notation means, but... [explains dup-lam semantics]. note that we absolutely need a clone_many() function that receives a Term* and clones each element into two Term*'s. do we have that? does that answer your question? - AI: Thank you, that clarifies a lot! My question about clone_many: in my C inject, I clone the template once, and clone each remaining arg. Is this correct? - Me: what is args0[16]? what is args0[0] and why sup_a is going there? not sure I follow - AI: You're right, let me re-read the Haskell more carefully... So a and b (the SUP branches) are not cloned - they go directly as the first element of the new arg lists. Only the remaining args are cloned. My C code matches this. The issue must be elsewhere. - Me: ah, I see. yes your clone logic looks correct-ish, but I'd still insist that you use a helper clone_many function instead of inlining it manually like that. - AI: Okay, let me add clone_many first. [adds it, tests still fail] Still getting wrong output. Question: Should collapse evaluate/resolve the CO0/CO1 nodes? Or should they stay as CO0/CO1 and get resolved later? - Me: in Haskell, CO0/CO1 fall in the default case of collapse... [explains full reduction chain with dup-sup same-label interaction] - AI: That's very helpful! So the dup-sup interaction with same labels is what makes the CO0/CO1 resolve correctly. The issue must be in my template structure. Is my template structure wrong? - Me: you just pass the template to inject, it will clone the whole thing if needed. your construction looks wrong, you're allocating two lambdas? why two heap_allocs? you should create a var to the outer lam, seems like you're creating a var to an unused place? - AI: You're right! The VAR(fV_loc) should point to the outer lambda's body location (outer_loc), not to some separate fV_loc. Is this correct? - Me: sounds ok-ish but please double check, you're the machine here - AI: You're right, let me trace through carefully... [traces through, verifies, fixes code] collapse_4 passes! [continues fixing APP, DRY, MAT, CTR cases with same pattern] All 35 tests pass!
this loop: > you give AI a task > it explores the problem > it brings a question > you feed it with insight > it explores the problem > ... etc ... is a very powerful, time-effective way to build software you're still smarter than it (I hope), but it can lift a lot on its own