Exigir que temas e plugins gerados por LLM sejam marcados como tal

Atualmente, algumas pessoas podem tentar fazer o upload de plugins, temas ou componentes gerados inteiramente por LLMs sem declarar isso. Existem muitos motivos pelos quais pode ser útil saber quando algo foi totalmente gerado por um LLM, e no momento não há obrigação de declarar tais plugins dessa forma. Pessoalmente, gostaria de saber antecipadamente para não acabar instalando um plugin de baixa qualidade, cheio de problemas de desempenho, otimização e UX, comuns em plugins gerados por LLMs.

Obviamente, isso depende de as pessoas serem honestas e transparentes (e pessoas que criaram tópicos com IA podem não saber melhor do que o que está escrito), mas ter uma tag como #gerado-por-ia aplicada a ativos que sejam predominantemente gerados por IA seria benéfico para todos.

2 Curtiram

Divergo da ideia de que um plugin gerado por LLM seja inerentemente de baixa qualidade ou que necessariamente sofra com problemas de desempenho, otimização ou UX. A qualidade do resultado depende muito da pessoa que guia o LLM e que revisa sua saída.

Tenho orgulho do software que desenvolvi ao longo dos últimos 40 anos, e incorporar LLMs ao meu fluxo de trabalho melhorou a qualidade do meu trabalho, e não a diminuiu.

Por outro lado, já vi muitos plugins escritos à mão cheios de vulnerabilidades de segurança, problemas de desempenho e más decisões de design, onde genuinamente desejei que o autor tivesse usado um LLM. No final das contas, o que importa é a qualidade do desenvolvedor e do código resultante, e não se um LLM esteve envolvido na sua criação.

11 Curtiram

Fico me perguntando como vocês sugerem revisar e/ou atualizar o código gerado por LLMs, para nós que estamos nos aventurando no vibe-coding para implementar novas funcionalidades ou personalizar as que já estão em produção.

Sei que uma revisão coletiva em repositórios públicos é o ideal, mas gostaria de primeiro fazer minha parte e só publicar versões que tenham esgotado minha capacidade atual.

Concordo com o comentário anterior: não sou contra a IA, mas estou ciente de que TUDO o que ela gera precisa ser auditado, verificado e atualizado por humanos.

Algo curioso, relacionado:

1 Curtiu

Isso é totalmente justo e, no final das contas, só posso falar por mim mesmo, o que se baseia em observações de aplicativos de baixa qualidade “slop” que todos parecem idênticos e são, em geral, de baixa qualidade (tanto em termos de funcionalidade quanto de segurança), além de aplicativos existentes que sofreram uma queda severa na qualidade desde que começaram a delegar grande parte do trabalho para LLMs (como o Visual Studio Code e o Formbricks; ambos os quais deixei de usar desde então). Mesmo que seu aplicativo seja perfeito, ainda existem preocupações éticas, então seria ótimo se houvesse algum tipo de notificação para essas criações, como sugerido. Isso não significa que alguém tenha que se basear na etiqueta, mas, se você quiser, a opção é boa.

Como disse, este é um sistema inerentemente baseado em confiança e é responsabilidade exclusiva do desenvolvedor garantir que ele seja marcado como tal. Obviamente, existem alguns casos em que o LLM se marca nos logs do git (como a maioria faz), então um TL3+ pode tomar medidas, se desejar, visualizando o GitHub.

Agradeço sua resposta, obrigado. Minha pergunta também se dirige a todos e diz respeito às ferramentas que atualmente existem para verificar o código gerado por LLMs.

Não sou desenvolvedor, mas consegui implementar funcionalidades que não existiam no Discourse. E quero fazer o que estiver ao meu alcance da melhor maneira possível.

Vou considerar a marcação se eu decidir publicar meus repositórios; por enquanto, eles são privados justamente porque estou testando-os, e estou interessado em fazer as coisas da forma correta antes de distribuí-los à comunidade.

Eu ficaria extremamente surpreso se a maior parte do código do Core (incluindo os Plugins do Core) não estivesse sendo desenvolvida agora com Agentes de Código, dado o tamanho da mudança que o desenvolvimento passou.

Hoje, na minha opinião, é muito difícil justificar não usar agentes de código na maioria dos trabalhos, pois a queda na eficiência simplesmente não faria sentido do ponto de vista empresarial.

3 Curtiram

Eu não me importo nem um pouco com “como um plugin foi criado” ou se a pessoa usou um lápis ou uma caneta.

“Não há IA aqui” não me dá nem um pouquinho de confiança extra na hora de instalar um tema ou plugin.

No entanto… há um problema muito mais sério que precisamos enfrentar no CDCK.

Os plugins principais e o código-fonte do Discourse são regularmente verificados quanto a segurança. Quando uma pessoa instala um canal suportado, ela tem confiança sobre o quão seguro o código é.

Os plugins e temas de terceiros aqui são “o velho oeste”: qualquer pessoa pode contribuir, não fazemos varreduras de segurança neles nem garantimos que sigam as melhores práticas. Isso coloca a comunidade em risco.

Eu gostaria de chegar a um mundo em que a “versão XYZ” de um tema fosse, pelo menos, automaticamente verificada para dar aos que hospedam em servidores próprios ao menos alguma confiança.

Então, minha visão aqui é completamente oposta :slight_smile: exigir que as versões de temas e plugins de terceiros passem por algum tipo de verificação por IA antes de serem anunciados aqui.

8 Curtiram

A revisão de código por LLMs é totalmente diferente de pedir “Claude, construa este aplicativo e não cometa erros” e publicar a saída com pouca ou nenhuma validação ou edição feita por você mesmo, pelo menos do ponto de vista ético, na minha opinião. Infelizmente, você não pode realmente obrigar um usuário final a ter responsabilidade, e não importa o quanto você tente, alguma pessoa encontrará uma maneira de baixar algo malicioso. Mas, de qualquer forma, o quão éticos os LLMs são é uma conversa à parte e não é realmente relevante para este tópico.

e isso está tudo bem! Não estou sugerindo um banimento generalizado de qualquer coisa que envolva IA em Customization… Eu só gostaria que fosse marcado corretamente, para que aqueles que não querem abrir essa lata de vermes não acabem fazendo isso.

Eu tenho muitos problemas com ferramentas baseadas em LLM (e com os resultados delas). Não apenas os problemas de segurança, legais, de confiabilidade e ambientais. Mas isso não é o principal aqui.

A segurança, em sua definição ampla, é o problema importante aqui. Se o código foi gerado por IA ou não.

Que ferramentas a CDCK usa para verificações de segurança? Várias delas também seriam importantes para criações de terceiros.

Mas há mais coisas para verificar. Com quais sistemas externos a criação de terceiros se comunica? A maioria das ferramentas de análise de segurança aceita que o software se comunique com servidores externos, sem um heartbeat. Mas um componente de tema puramente cosmético não deve realizar nenhuma chamada para um servidor externo. Portanto, a criação de terceiros pode conter falhas de segurança, ou conter problemas que podem prejudicar a disponibilidade. Mas eles também podem exfiltrar dados.

Concordo com isso em 95%. E agora estamos falando do Discourse, imagine se estivéssemos no mundo do WordPress!

(Os 5% restantes: não acho que seja o “velho oeste” - as questões de segurança são relatadas via meta para esses desenvolvedores de terceiros e, em geral, são corrigidas rapidamente).

Mas, ao mesmo tempo, minha experiência é que os LLMs (hoje em dia) geram código mais seguro do que o autor médio de plugins. E você pode jogar um plugin em qualquer LLM decente e pedir “encontre e corrija quaisquer problemas de segurança”, e ele fará isso, mesmo que o humano não tenha muito conhecimento em segurança.

Venho revisando plugins manualmente na última década e já vi muita coisa: injeções de SQL (por pessoas que achavam que o ActiveRecord era muito elaborado), configurações de chave de API com client: true, total falta de autorização e controles de acesso, falta de limitação de taxa (rate limiting). Todos eles são encontrados e corrigidos por LLMs em pouco tempo e sem muito esforço.

Então, mais uma vez: acho que os LLMs tornaram isso melhor, não pior.

Você ainda está associando código gerado por LLMs a uma “lata de vermes”, isso é muito preto no branco.

4 Curtiram

Jack McDade adotou essa abordagem com o diretório de add-ons do Statamic

Eu recebo bem essa abordagem, achei útil para confirmar o que já sabíamos que precisava ser feito. Também ajuda a construir confiança no código.

Parece que algo semelhante poderia ser implementado aqui sem muito esforço por parte da equipe.

4 Curtiram

Também me preocupo com plugins e componentes de baixa qualidade, e não confio muito neles quando são 99% “vibe coded” (codificados por intuição) por alguém que não entende de programação.

Mas também acredito em programadores experientes que por aí dizem que programadores ruins existiam muito antes da IA[1]. Código descuidado, não confiável e cheio de falhas foi feito à mão há séculos.

O que me preocupa é quando vejo um app/plugin/qualquer coisa “vibe coded” e suspeito que o autor não revisou o código.

Embora eu tenha algum conhecimento básico em programação, não codifico há muito tempo e nunca fui bom nisso. Tentei fazer “vibe coding” em alguns projetos.

Inicialmente, relutei muito em publicá-los oficialmente no meta, mas acabei fazendo isso depois de dedicar tempo para revisar e entender o que cada parte do código estava fazendo, e também declarar publicamente minha abordagem em meus tópicos. Não que eu me lembre de tudo o que li antes de publicar aqueles plugins, mas pelo menos pude garantir a confiabilidade e a segurança no momento em que publiquei esse trabalho.

Tenho um bom exemplo para ilustrar como o “vibe code” poderia ter me feito lançar um plugin muito inseguro.

Antes de trabalhar em 🖼️ Topic Gallery, eu trabalhei em, fiz uma prova de conceito de um plugin semelhante aqui: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
Estava funcionando muito bem, e a IA seguiu minhas diretrizes.

Havia um problema, porém: embora a funcionalidade fosse claramente uma função de moderação, a IA não levou em conta as permissões: qualquer usuário, incluindo visitantes, podia abrir essa página e ver todos os arquivos enviados por todos os usuários. Para mim, era óbvio que deveria ser apenas para administradores, mas a IA não “pensou” nisso. E como eu não pedi, ela criou uma página pública por padrão.

Então, continuo me dizendo que, se eu e a IA pudemos deixar passar um vazamento de segurança tão grave, é provável que não-programadores que fazem “vibe coding” de TCs e plugins façam o mesmo, infelizmente.

As opiniões sobre código de IA em software estão fortemente polarizadas. Basta dar uma olhada em qualquer projeto de código aberto popular onde a Claude é citada como coautora dos últimos commits para ver uma torrente de ódio de certas pessoas.
Estou convencido de que devemos abordar essas coisas com cautela e que nossas opiniões devem ser mais nuancadas.

Não sou particularmente a favor de ter algum tipo de tag vibe-coded que possa desnecessariamente prejudicar a popularidade de customizações bem codificadas e seguras e de seus autores.

Sei que agora qualquer pessoa pode produzir customizações, que podem vir a ser cada vez mais numerosas a cada dia, e que não há pessoas suficientes para revisá-las.

A revisão por IA talvez seja a solução. Meu instinto não gosta muito dessa ideia por várias razões, mas acredito que, se o Sam propuser esse tipo de solução, provavelmente é uma boa, porque confio muito em suas habilidades e julgamento. Especialmente porque eu mesmo não sei nada. :laughing:

Talvez alguns devs aqui que conheçam programação e o ecossistema do Discourse pudessem ter um título que mostre explicitamente sua especialização nessa área, para que pudessem ser vistos como devs confiáveis mesmo por visitantes que estão apenas procurando customizações aqui sem se registrar. Seria o oposto do que você está pedindo, darkpxlz. Em vez de “envergonhar” customizações potencialmente não confiáveis, enfatizaríamos as confiáveis. :slight_smile:

Só é uma ideia para reflexão, porém. :person_shrugging:


  1. Eu deveria saber, eu era um deles! ↩︎

5 Curtiram

É perfeitamente possível que eu esteja preso em uma câmara de eco anti-IA, influenciada pelos meios de comunicação que consumo e pelas pessoas com quem interajo diariamente. Eu estava quase certo de que essa solicitação não seria tão impopular quanto acabou sendo, mas, se todos aqui realmente amam codar com LLMs e não querem uma tag apenas por transparência, quem sou eu para impedir isso? Detectar o código de LLM ainda é bastante fácil, então, se alguém (como eu) realmente quiser evitá-lo, basta verificar os contribuidores em busca de uma tag de LLM, como sugeri anteriormente.

1 Curtiu

Dado que se trata de um assunto controverso, pessoalmente apoio o seu pedido original, que atenderia à parte da comunidade que, no momento, está mais cética (justamente).

No entanto, suspeito que acabaríamos rotulando quase tudo, o que, de certa forma, anula o objetivo, não é?

Também concordaria com os outros em que nem todo o código gerado por IA é igual - parte dele é escrito por modelos mais recentes e mais caros, guiado por desenvolvedores experientes, enquanto em outros casos pode ser um resultado de uma única tentativa de uma pessoa menos experiente usando um modelo menos capaz, e o repositório pode não estar seguindo as melhores práticas - e você só pode avaliar isso examinando o próprio repositório e observando se as pessoas estão tendo problemas frequentes.

5 Curtiram

Acho que uma revisão minuciosa tanto por humanos quanto por IA é uma boa ideia para qualquer software importante, independentemente de ter sido originalmente escrito por humanos ou por IA. Seria ótimo se houvesse ferramentas melhores para revisar software e manter o registro de quem revisou quais versões de quais pacotes. Atualmente, existem ferramentas que se assemelham a isso para Rust/Cargo: Crev, cargo-vet e Thirdpass. Também iniciaram uma discussão nos fóruns do Swift.

1 Curtiu

Eu sou do time do “por que” usar labels. A questão de ter ou não labels é um pouco um red herring (falso problema). Para mim, a questão importante é garantir a qualidade do código/produto no diretório de plugins; esse é o ponto principal. O Discourse tem a responsabilidade final nessa área, mas a comunidade pode ajudar. Nesse sentido, meu novo melhor amigo e eu trabalhamos na criação de um DiscourseSkill.md. Minha intenção original era usá-lo internamente, mas talvez outros o encontrem útil. Para isso, deem uma olhada em DiscourseSkill.md

1 Curtiu