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.
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.
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.
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.
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 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.
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.
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.