Hi Kooda, Please don't disregard your own input. These are valid points and I'm glad you raised them.
Before anything else: I'm sorry to hear about the scrapers forcing you to shut down your code repository. That's genuinely awful, and I understand why it colors your view of all of this. I do disagree on the learning point, though. I think you're drawing that conclusion because I didn't share the full story of how I got here. This wasn't a case of blindly pointing an AI at the codebase and submitting whatever came out. The process looked more like: ask the AI to help me understand how chicken-install fetches eggs and where to look, read those files myself, propose approaches and have the AI poke holes in them, discard the bad ideas (like shelling out to curl), settle on a thin FFI layer for SSL, iterate on the implementation until it felt reasonable enough to share. Was the result deep enough? No, clearly not. Felix's review made that obvious. But that was always the point. I called it an exploration and asked for feedback precisely because I knew I'd need the community's expertise. And Felix's feedback taught me more than any amount of AI iteration would have. So the community learning did happen, just through a different entry point. You're absolutely right that this is an amazing community to learn from. I don't see AI-assisted exploration and learning from this community as an either/or. Felix's review is proof they work together. I hear the skepticism, and given the flood of low-effort AI submissions hitting OSS projects everywhere, it's well earned. Cheers, Rolando On Mon, Feb 9, 2026 at 11:50 AM Rolando Abarca <[email protected]> wrote: > (replying to felix because it seems Stanislav's email was not > replied-to-all and I can't see it in my inbox, only in the archives) > > > When people submit patches they did not write to the code they don’t > understand, the burden on maintainers increases tremendously. > > 100% agree with you. I think the key here is to differentiate between AI > slop and AI-assisted coding by someone that could understand and vet the > output. IE was AI used as a proper tool to get to an outcome faster? or was > it used blindly to just generate something without care? > > Best, > Rolando > > On Mon, Feb 9, 2026 at 2:17 AM Felix Winkelmann < > [email protected]> wrote: > >> (At Peter's suggestion I forward this to the mailing list, as the >> discussion may >> be of interest to other contributors. We don't have a policy regarding LLM >> usage yet, but need to make up our minds on how we approach this in >> general. >> >> Note that this does _not_ mean a lack of trust in you or your >> contribution, but >> reviewing LLM-assisted code is a new and somewhat unsettling experience >> to me, and >> I'm not quite sure how we want to handle this in the future) >> >> On Mon Feb 9, 2026 at 5:07 AM CET, Rolando Abarca wrote: >> > Hi Felix, >> > >> > Thanks for taking the time to review this! >> > >> > I'll look into the code cleanup suggestions, the points about removing >> the >> > unnecessary #ifdefs, the _VAL macros, and the redundant clause in >> > url-protocol all make sense. I'll also look at the error handling in >> > make-ssl-input-port and the static build approach you suggested. >> > I really like the idea of including and using cond-expand to add it or >> not. >> > I'll play with that. >> > >> > To answer your question: yes, I used LLM assistance (Claude Code) for >> the >> > initial research to understand the codebase and figure out what the >> > implementation would entail. From there I created a manual plan for how >> to >> > approach it and had the AI run with it. There were a few manual fixes >> along >> > the way, but to my non-expert eyes it looked good enough to share as a >> > proof of concept. >> > >> > I appreciate the thorough review, I'll work through your suggestions and >> > follow up. >> > >> > Cheers, >> > Rolando Abarca >> > >> > >> > On Sun, Feb 8, 2026 at 3:42 AM Felix Winkelmann < >> [email protected]> >> > wrote: >> > >> >> Hi, Rolando! >> >> >> >> I finally got around to reviewing this, sorry again for the long delay. >> >> I have a few questions and suggestions regarding the code. >> >> >> >> Always building the ssl module in dynamic mode is problematic when >> >> CHICKEN is built statically. It would be better to compile it >> conditionally >> >> and link it to chicken-install (excusively). An alternative would be >> >> to "include" it (similar to egg-download.scm). You could then avoid the >> >> eval-trick, for example by using cond-expand, after adding a feature >> >> to the build of chicken-install. >> >> >> >> SSL support needs to be activated explicitly, I guess it would be fine >> >> to enable it by default, if the configure script succeeds in testing >> >> for ssl availability, since your checks are quite thorough. >> >> >> >> In egg-download.scm, the 2nd clause in url-protocol seems to be >> >> redundant. >> >> >> >> In ssl.scm, the #ifdefs are not needed (it is built only when SSL >> >> is available, anyway). Also the "..._VAL" macro defs are not needed, >> >> you can use the constants from ssl.h directly. Also, the function >> >> prototype for get_tcp_fd is unnecessary, I think. make-ssl-input-port >> >> does not handle other errors besides the _want_... cases, is this >> >> intentional? >> >> >> >> One question: did you use LLM assisstance for this code? Some of >> >> the redundancies seem to indicate that. That is not indented to >> >> diminish your effort (I'd very much like to add this feature to >> >> CHICKEN), just to make sure with what amount of diligence I should >> >> review the code. >> >> >> >> >> >> cheers, >> >> felix >> >> >> >> >> >>
