I don't think there is any consensus for Go users, but after RSC's analysis (link? my github search foo is failing me) I think the Go development team adopted his recommendation to not mention AI use in any git commit messages, no matter if an LLM was used or not.
His analysis was long but in short that was, if I recall correctly, to a) not give the LLM manufacturers free advertising; and b) convey the expectation that the human whose name is on it is ultimately responsible for all of it, no matter what percentage of the commit was AI generated. Moreover, I would add, c) these days most people will assume most things have some AI support -- even if there is none. And the accusations and refutations (seen constantly in some forums like Hacker News) is tiresome and not particularly interesting. So the same guideline makes sense to me -- for articles like yours. I expect you will use AI if you like, but mentioning your own AI in your articles was the only thing that struck me as a bit crassly commercial. As I said, I'd like to actively encourage writing on topics of interest to Go users -- I wish other folks were writing articles such as yours. But you don't need to advertise your AI model too. I don't want to speak for Duncan, but I have a hard time imaging the actual content was what he was objecting too. Perhaps tangentially, it stikes me that one difficulty is that we most often use AI when we don't know the actual answer ourselves. That seems to be the best place (only place?) where it is extremely reasonable to point out that AI was used. "The AI said X but I have conflicting evidence Y, what is the right answer?" is something human experts will be doing alot of. It seems both un avoidable and natural to ask such questions. But otherwise I have been favoring just leaving off attribution to any degree to the LLMs, for the reasons a, b, and c above. I don't want to advertise, and I need to take full accountability for the content anyway; and the discussion of whether or not something was LLM supported is boring and contributes little. To my way of thinking, mentioning AI use as a disclaimer comes out to the same thing as advertising--so I would avoid it. That said, if you AI model overlaps with Go in some way (was created with Go, uses Go, is tuned for Go specifically), then talking about it directly in one post seems perfectly reasonable. On Monday, July 27, 2026 at 12:15:20 AM UTC-3 Cheikh Seck wrote: > Also, disclaimer, writing these articles recently started as an experiment > where I had an agent I built train itself on my most previously successful > posts (2022) and write in that style, voice and tone. The first few went > unnoticed lol A friend recommended mentionning it was written by said agent > as a selling point and case study for it. > > On Monday, July 27, 2026 at 3:06:22 AM UTC Cheikh Seck wrote: > >> I usually try to fact check the best I can. At the same time, I believe >> this group is for new package releases and langauge features so it makes >> sense not to share on here. >> >> On Monday, July 27, 2026 at 1:08:53 AM UTC Jason E. Aten wrote: >> >>> Nah. To me, these are fine. They are both topical to Go and discuss >>> novel aspects of Go programming, and are written fairly infrequently. I for >>> one appreciate them and have learned about important topics like eBPF from >>> them. They seems like appropriate use of go-nuts to me. >>> >>> I could wish the articles didn't use AI without fact checking... but >>> meh, humans make plenty of mistakes too. >>> >>> >>> On Sunday, July 26, 2026 at 6:42:25 AM UTC-3 Duncan Harris wrote: >>> >>> I think you probably need to stop posting these articles to this group. >>> It is not scalable. People will get annoyed. >>> >>> On Friday, 24 July 2026 at 23:02:37 UTC+1 Cheikh Seck wrote: >>> >>> Go 1.26's runtime/secret (GOEXPERIMENT=runtimesecret) tags allocations >>> inside secret.Do(f) for erasure — the right layer to stop secrets leaking >>> into crash core dumps. Key takeaway: it marks, doesn't wipe — you must call >>> runtime.GC() right after or you still leak, and it's a no-op off >>> linux/amd64+arm64. >>> >>> I built a reproducible harness (canary → SIGSEGV → scan the core): >>> control leaks, secret doesn't. Repo + Dockerfile: >>> https://github.com/cheikh2shift/go-snippets/tree/main/secret-demo >>> >>> Writeup: >>> https://towardsdev.com/runtime-secret-go-1-26s-answer-to-secrets-leaking-in-core-dumps-d884615e971f >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/56562958-4763-4999-8a58-c10943666230n%40googlegroups.com.
