In which Claude Opus invades my open-source hobby project. The experience was… surprising.
Fairly raw anecdata here, analysis and reactions still to come: https://www.tbray.org/ongoing/When/202x/2026/02/06/Q-Plus-C-Ch1
In which Claude Opus invades my open-source hobby project. The experience was… surprising.
Fairly raw anecdata here, analysis and reactions still to come: https://www.tbray.org/ongoing/When/202x/2026/02/06/Q-Plus-C-Ch1
There is no "dick-move-or-not" discussion, Tim, and I'm wildly disappointed to see you implying that there is.
@linguacelta Hmm, I'm missing something? I linked to the dick-move piece and in my last paragraph say I'll get to discussing those issues after I post about the other Quamina+Claude piece. Working on that now.
I'm sorry if I've misread. But here's what I saw in your piece:
a) a kind of "both sides are bad" intro about how current discussion is toxic;
b) a willingness to consider the technical merits of Claude, as though it is desirable (and not, in itself, unethical) to take a theoretical position on "AI" use and to engage with LLM-generated content;
c) a conclusion that promises to discuss whether using "AI" is a dick move", as though there is any meaningful debate left to be had.
@linguacelta Fair enough. I'll be publishing my follow-up with lots of discussion of those issues in the next day or two.
@timbray Oh, odd question: why was the fact that the epsilon closures are fixed a surprise? That's an inherent property of all DFAs, and it seems like it'd also have to be an inherent property of all NFAs. Or at least all of them that have a finite number of states.
@tknarr It was surprising to me that Claude noticed the fact, and that my code hadn't taken advantage of it. Maybe it shouldn't have been.
@timbray I'd've expected Claude to notice, it's a common thing in FA code that executes the FA on all the input at once so it ought to hit "most likely" quickly. I was surprised you'd missed it. I almost did, but most of my use is handling real-time events so pre-computation isn't helpful.
The lag in it noticing is a problem though, it's setting up a feedback mechanism that'll result in loss of that optimization.
@timbray The biggest thing to me is that, unlike most of the genAI code I see, Rob is using Claude's output as his own input. When an experienced dev is reviewing the results and making sure they're good, the result is no worse than that dev would be on their own.
The problems are that most genAI advocates _aren't_ reviewing the code themselves, they're just throwing the raw PRs at the project. The maintainer then ends up having to review those PRs and determine which of them are OK...