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.