And I will add on one more thing - I also agree with you Brian that people shouldn’t be trying to contribute code they don’t understand to other people’s project. :D
Dealing with poorly written code is actually something I have to do in my day job. Most of the time it’s coming from junior engineers, not AI however. -George On Sat, Dec 27, 2025 at 9:41 AM Kenneth Pettit <[email protected]> wrote: > Brian, George, > > I understand how you could feel this way Brian, especially regarding code > authorship, and I appreciate you having my back. > > However, I wss not put out in any way ... I *did* ask George to post the > updates Claude made. And I was kinda checking email every 8 hours to see > if he had done so. :) I wanted to get an idea what the AI believed the > issues was (suspsected I already knew, though also learned about Apple's > specific thread requirements) so I could either pull in the changes or make > my own. > > Also George, I believe you have been very forward in identifying that > Claude was making these changes, which I appreciate. > > I'm just happy someone is able to get some kind of use out of the socket > interface that has been sitting idle for so many years! :) And all of > this new discussion / use of VirtualT has gotten me off my tail to push my > 2 year old changes to my repo. After my trip to CES I will focus on > pulling in other PRs that have been identified. > > So as far as I'm concerned regarding this, all is good. > Ken > > > > On 12/27/25 6:21 AM, George M. Rimakis wrote: > > I'm quite sorry, I didn't mean to "send anyone over the top". > > Of course I did not plan to share or commit anything regarding Claude's > changes back to anyone here. Until of course Ken specifically asked me to, > presumably out of curiosity. > > So I can only hope your reply here is merely a misunderstanding, > perhaps for not having read prior emails quite thoroughly enough. I have no > desire to take ownership of the generated code, because quite frankly it > was generated for my personal use. Nobody will be poisoned by the MCP > server running on Mac Mini. > > - George > > On Sat, Dec 27, 2025 at 8:51 AM Brian K. White <[email protected]> > wrote: > >> On 12/26/25 16:08, B9 wrote: >> > >> > >> > On December 25, 2025 2:54:55 PM PST, Kenneth Pettit <[email protected]> >> wrote: >> >> On 12/23/25 2:39 PM, George M. Rimakis wrote: >> >>> >> >>> He (please bear with my anthropomorphizing of the LLM), found out >> that somehow it was causing the GUI to crash. >> >>> >> >>> I honestly don’t exactly know what he did, but he modified the code >> so that he was able to safely push keys at the same time as a user in the >> GUI, without the app crashing. >> >>> >> >> Would be really interested to see what changes Claude made to resolve >> the GUI crash / deadlock / garbled output if you are up to sharing them. >> > >> > For the sake of science, I'm glad to see George has let Claude file the >> bug report instead of typing it up himself. Understanding the code — or >> trying to — would end George's experiment in "vibe coding" in which one >> "embraces exponentials and forgets the code exists". >> > >> > I'm fascinated seeing a hybrid approach happening in real-life: We have >> a vibe coder making a patch for existing code that an expert coder will >> examine. >> > >> > Clearly it saved George, the vibe coder, time and effort. If he had to >> understand the original program, identify the bug, and learn enough to >> write a patch, he probably wouldn't have even tried. >> > >> > Now, the question is: How much time and effort will it cost Ken, the >> expert programmer, to handle the AI generated report? Would it have taken >> Ken more or less time if he had used Claude interactively to fix the bug? >> > >> > Bug reports with patches have traditionally been very helpful, but >> there are costs, especially with AI. Does Claude's description match the >> code generated? Has it identified the actual source of the error? Is it the >> correct fix? Does the patch break anything else? Does it add extraneous >> changes? Does it take an incremental approach when refactoring would be >> more appropriate (or vice versa)? Are the changes written in a way that >> will be easy to understand and maintain in the future? >> > >> > Ken, if you don't mind, please let us know what your experience is and >> if you would welcome more patches from vibe coders in the future. >> > >> > --b9 >> > >> >> >> I'll just say this much: >> >> I haven't commented on this thread at all yet because John doesn't like >> us to be mean to each other here. But I am very much in the Daniel >> Stenberg camp on this. >> >> The latest post where George regurgitated the AI's own explanation for >> what it did (instead of understanding and explaining, and taking >> ownership himself) sent me over the top. >> >> Ken is nice, but that just means Ken is nice. Good for Ken and lucky for >> George. >> >> It's still basically abusive of others to submit work from an unthinking >> unknowing tool that you yourself can't explain, vet, sign-off on, and >> put your own name on and take responsibility for. >> >> But a non programmer doesn't understand what the problem is, and I'm >> unable to write the explanation in a way that is likely to be read. >> >> Actually it's not even really a programmer thing, it's a respect for >> others thing. >> >> If I asked for a cake recipe, and you used an ai to generate a cake >> recipe and gave it to me without yourself being able to say that the >> cake recipe will never poison anyone, or even just taste bad or fall >> apart in all expected usage scenarios, then how can you live with >> yourself? If I asked for the formula or table to map how much water a >> field will need based on the type of soil and the type of crop, and >> instead of performing the research to actually know the correct data, >> you just had something generate an answer that who knows, might be >> right, how can you live with yourself? >> >> Somehow people do it for coding and think it's fine. >> >> -- >> bkw >> > >
