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

Isso é um salto considerável no seu raciocínio.

  • Se você tivesse contratado um estagiário ou passado 10 noites fazendo isso sozinho, também poderia ter adicionado um player FLAC ao seu app imaginário. Tomar más decisões de produto não é inerente ao uso de LLMs, e se adicionar um recurso inútil é um desperdício de esforço de desenvolvimento sempre foi alvo de discussão.

  • Recursos extras nem sempre deixam seu app mais lento e mais pesado em RAM; esse problema foi resolvido pelo conceito de carregamento dinâmico - há 40 anos.

Exatamente. Ênfase minha :slight_smile:

3 Curtiram

Não, essa distinção não deveria ser feita.

  • O software é seguro?
  • Ele resolve meu problema?

Voltando ao meu ponto original aqui:

Se temos um problema de segurança em temas, vamos conversar sobre um sistema de verificação.

Se temos um problema de qualidade em temas, vamos conversar sobre sistemas de verificação.

Mas não, eu não vou introduzir um selo de “desenvolvido em Mac”, “desenvolvido em teclado vermelho” ou “desenvolvido com 93,2% de IA” nos tópicos; isso não vai acontecer.

Quanta IA eu uso? Estou disposto a compartilhar meus fluxos de trabalho em um tópico separado, mas não estou mais codificando à mão no vim.

8 Curtiram

Seria uma falácia genética rejeitar todos os plugins gerados por IA apenas porque foram escritos por ela. Ser gerado por IA talvez tenha sido, no passado, um bom indicador de baixa qualidade, mas, com a melhoria dos modelos, está se tornando cada vez mais difícil distinguir entre o output humano e o gerado por IA. Se a preocupação é com a qualidade ou a segurança, acho que seria mais seguro assumir que todo o código é inseguro até que seja revisado por algum tipo de sistema de revisão por pares colaborativa.

Acho que compartilhar como a equipe trabalha com IA atualmente, desde designers até programadores, e até mesmo áreas como jurídico, marketing e outros campos, seria do interesse de muitas pessoas.

Saber um pouco sobre IAs, como eu, não significa conhecer e entender como uma empresa realmente trabalha com IA no dia a dia.

6 Curtiram

Li tudo por aqui e consigo ver os dois lados. Acho bom, mas ao mesmo tempo ruim, que as pessoas possam simplesmente criar plugins aqui e publicá-los, mesmo que contenham vulnerabilidades de segurança “potenciais” que possam comprometer uma instalação do Discourse.

Um pouco fora do assunto.

Há outro provedor de software de fórum (WoltLab) que possui uma loja de plugins, por exemplo. Antes de qualquer lançamento, os plugins e temas são revisados pela equipe. Talvez essa fosse uma boa ideia para implementar algo semelhante aqui. No entanto, sempre surge a questão de quem faria a revisão, e posso imaginar que isso exigiria um investimento significativo de tempo e pessoal.

2 Curtiram

Posso afirmar com 100% de certeza que isso é absolutamente inviável, para nós, revisar cada plugin e tema de terceiros. (Ou pelo menos, não manualmente por um ser humano)

E se houvesse um conjunto curado de ferramentas para testar plugins ou TCs gerados por LLMs, supervisionado, mantido e atualizado pela equipe?

Sei que todo mundo pode simplesmente executar os testes individualmente, mas, sinceramente, nem todo mundo sabe como fazer isso.

Um método simples e confiável para fazê-lo soa, para mim, como o melhor dos dois mundos.

Esse é exatamente o ponto principal deste tópico:

Foi interessante ver as opiniões de cada um sobre por que essa transparência pode ser importante, tanto em termos morais quanto de segurança. Pessoalmente, não me importo se algo foi feito por um engenheiro de software com 30 anos de experiência, que trabalha com Ruby desde o início dos tempos, ou por um pequeno Timmy sem nenhuma experiência em programação. Se for 100% código de baixa qualidade[1], não vou usá-lo; seria hipócrita da minha parte. Entendo por que é popular, mas simplesmente não é algo com o qual eu vou me comprometer. Se esses modelos tivessem sido treinados de forma ética e não estivessem causando escassez de componentes, junto com uma epidemia de mídia gerada por IA, minha opinião sobre esses modelos talvez fosse menos negativa, mas esse não é o mundo em que vivemos.

As preocupações com a segurança de plugins em geral também são válidas e não se limitam a “isso foi feito por IA”. Esse é um problema difícil de resolver e está fora do escopo deste tópico, no entanto; este tópico é apenas uma sugestão para exigir tags em ativos totalmente gerados por LLMs.


  1. Recuso-me a usar termos como “vibe-coding” ou “desenvolvimento agêntico” ↩︎

2 Curtiram

Ainda não vejo qual problema isso está tentando resolver. Alguém pode me dar um exemplo de um plugin desenvolvido com base em “vibe coding” que era ruim, inseguro ou consumia muitos recursos? Um que nunca deveria ter sido anunciado aqui porque era uma porcaria total e um desperdício do tempo de todos?

E, se realmente existem exemplos, eles são suficientes para representar um problema?

1 Curtiu

Para mim, isso soa como se uma espécie de lista de verificação autodeclarada para temas seria igualmente útil: quanto teste você fez, está pronto para receber relatórios sobre qualidade e segurança, será responsivo ao feedback.

Ou, de fato, qual é o seu processo de desenvolvimento, em no máximo três frases.

O valor de verdade das respostas não valerá muito, mas a diferença entre temas autodeclarados e os que não são pode ser um sinal que vale algo para a pessoa que está pensando em instalar a coisa.

4 Curtiram

Eu, por exemplo, nunca faço “vibe-coding” em nenhuma aplicação, projeto ou software que eu crie. Uso chats de IA para trocar ideias ou obter esclarecimentos, mas nunca para o projeto inteiro. É mais manual, definitivamente, mas pelo menos eu sei o que estou fazendo e não confio cegamente a isso a outra entidade.

Mas vi o uso de IA no suporte à programação crescer muito nos últimos meses. Talvez tenha começado como código mal escrito ou cheio de vulnerabilidades, mas diria que melhorou muito desde então. Os designs feitos com “vibe-coding” ainda são bastante reconhecíveis (gradientes, bordas, emojis, etc.), mesmo em alguns plugins que vi na Meta. Mas o que importa é que o autor o compartilhou por seus próprios interesses e pelos da comunidade. Não para que alguém o pisoteie e o rotule de ‘lixo’, mas porque ele encontrou sucesso genuíno naquele plugin e quer compartilhá-lo com outros fóruns por aí que buscam obter a mesma funcionalidade.

Entendo seu ponto sobre as preocupações éticas com a IA, mas isso parece se dirigir à IA em geral, como empresas fatiando livros, uso massivo de água e eletricidade, etc. Você menciona:

Mas como isso se correlaciona com o uso de plugins ou TCs feitos por IA? Se você não gosta de IA, tudo bem, não use. Mas a paisagem da programação mudou drasticamente com a introdução da IA, e coisas como plugins e TCs também mudarão. Você vai parar de usar o Discourse completamente agora, sabendo que parte do código foi escrita com ajuda de IA? Eu não, porque sei que ainda há pessoas por trás disso.

Então, ainda será preciso chamá-lo de ‘código lixo’ e boicotar o uso do termo ‘vibe-coding’ (pessoalmente, não vejo problemas com essa última expressão)? Talvez não. É muito duro? Sim. Tanto quanto acho que você gostaria que fosse, às vezes temos que nos adaptar. Isso significa que agora vou criar TCs gerados por IA e compartilhá-los? Para mim, não. Mas isso significa que vou vê-lo como uma alternativa, que não deve ser evitada ou desprezada? Sim. E estou tentando não fazer o contrário. Então espero que você também possa.

5 Curtiram

Compartilhando apenas um artigo curado relacionado a este tópico:

A Trail of Bits argumenta que os agentes de IA são mais úteis em auditorias para a criação de ferramentas personalizadas, e não apenas para encontrar bugs. Em uma auditoria do zkVM Miden, eles usaram Claude e Codex para criar um servidor LSP, um descompilador, um analisador estático e um modelo Lean, descobrindo um bug de forjamento de assinatura de alta severidade e 95 provas Lean que identificaram dois problemas sutis.

Como os agentes tornam projetos secundários ambiciosos mais baratos, a economia das auditorias tem se deslocado para revisões impulsionadas por ferramentas, que podem proteger sistemas complexos de forma muito mais abrangente do que antes.

eu uso IA para me auxiliar no desenvolvimento dos meus plugins e componentes. use-os por sua conta e risco, mas não vou rotulá-los com nenhum aviso ou tag, assim como o núcleo do Discourse não faz. eu controlo os agentes, reviso o código (às vezes com outro agente ou conjunto de olhos de um LLM para ajudar) e os testo. você é livre para não usá-los, mas tenho visto com mais frequência código ruim escrito inteiramente por um humano do que por IA.

7 Curtiram

De fato, acredito que a abordagem tradicional para conhecer a qualidade de algo é verificar a reputação da entidade que o criou. A reputação pessoal funciona bem quando uma pessoa está ativa no código aberto. Geralmente, se alguém já realizou bom trabalho no passado e foi responsivo, continuará a fazê-lo.

2 Curtiram

Você ainda precisa fazer o trabalho pesado. Mesmo ao usar LLMs para criar ferramentas determinísticas, é necessário verificar se essas ferramentas realmente executam as ações corretas, e não apenas algo que estatisticamente costuma estar certo. Usar LLMs para criar ferramentas determinísticas é melhor do que simplesmente enviar prompts a LLMs com arquivos markdown, na esperança de que o resultado seja o mesmo (o que continua sendo problemático do ponto de vista legal e ético). No entanto, se essa ferramenta determinística for mantida cegamente com LLMs, as novas versões correm o risco de perder seu comportamento determinístico ao longo do tempo.

Como a Snyk demonstrou em seu relatório VulnBench, a auditoria com LLMs não é realmente confiável:

1 Curtiu

Usar agentes de IA para escrever temas do Discourse parece muito adequado para mim.

Isso seria ótimo. Também pode valer a pena descobrir a configuração ideal para alguém que não tem uma forte base em programação. Acredito que seria algo como um agente de IA com acesso a uma instância de desenvolvimento do Discourse e um bom arquivo de habilidades. Isso, e algum tipo de revisão de segurança automatizada.

2 Curtiram

É claro que o Sam e a equipe são a autoridade incontestável e podem me corrigir se eu estiver errado, mas, após muita experimentação por minha parte e feliz em retribuir com algo em troca, aprendi nos últimos meses que o Discourse Vibe e o bom uso da ferramenta de desenvolvimento (harness) são o que é sugerido e, de longe, a situação ideal para começar.

Também é possível trabalhar com certos testes no GitHub ou mesmo usando o Discourse Container, mas a capacidade de desenvolvimento é limitada, especialmente para aqueles com menos experiência, como é o meu caso.

É possível ‘vibe codear’ (escrever código com base na intuição/fluxo) para o Discourse usando IA, e basta verificar ou delegar a verificação final antes de apresentar o trabalho realizado ou usá-lo em produção.

No meu caso, não tenho qualificação técnica para revisar código, mas sou capaz de direcionar funcionalidades, como e onde adaptá-las, e perguntar especificamente o que gerar ou refinar. Imagino que alguém virá e contribuirá abertamente para a segurança e a confiabilidade (sempre com revisão humana) do código, para que ele possa ser usado por toda a comunidade. Não apenas no Meta, mas no Discourse em geral. Esse sempre foi meu objetivo, desde meu prompt inicial.

Ontem li esse tópico e fiquei surpreso com o quanto tudo evoluiu: How hard would it be for non programmers to be able to use the Discourse AI - AI bot to help them create plugins and/or themes

Há anos, eu achava que não seria capaz nem de orientar uma IA para criar o código para mim. E hoje, com as ressalvas e a controvérsia legítima que existem a esse respeito, isso é uma realidade.

2 Curtiram