F-Droid, 102 apps e a régua quebrada para medir código feito por IA

Uma análise informal classificou 72,5% de um lote de aplicativos do F-Droid como "majoritariamente feitos por IA". O próprio autor admite que não há como confirmar isso com precisão — e é exatamente essa lacuna que deveria interessar a quem compra software.

Em 12 de setembro, um lote de 102 aplicativos foi atualizado no F-Droid, a loja de aplicativos de código aberto para Android mantida por voluntários. Três dias depois, um mantenedor de software livre que assina como tintotint publicou uma análise perguntando: quanto desse catálogo foi escrito por modelos de linguagem?

A resposta que ele deu — 72,5% dos aplicativos "majoritariamente feitos por IA" — circulou rápido: virou postagem em fóruns, chegou ao Hacker News, foi repetida como número fechado. Não é. E o motivo revela um problema mais interessante do que a proporção em si: hoje não existe régua confiável para medir quanto código de um projeto aberto foi produzido, revisado ou apenas colado por um agente de IA. Isso importa muito além do nicho de aplicativos para Android.

Um método manual, sem detector, com o próprio autor avisando dos limites

tintotint não usou nenhuma ferramenta técnica validada. O método foi inspeção manual: leitura de commits recentes, busca por coautoria declarada de Claude ou GPT, presença de infraestrutura de agente, documentos de planejamento de LLM dentro dos repositórios, ícones com aparência de geração por IA e READMEs genéricos com uso pesado de emoji.

A partir desses sinais, ele classificou os 102 aplicativos em três categorias: "majoritariamente IA" (mais de 50% do código atribuível a LLM, ou qualquer infraestrutura de agente presente), "difícil dizer" e "sem sinais de IA". Resultado: 74 apps (72,5%) na primeira categoria, 10 (9,8%) na segunda, 18 (17,6%) na terceira.

O próprio autor sinalizou os limites do que fez. No texto original, ele afirma que "não existe forma eficaz de detectar slop" e descreve as definições de categoria como "soltas" — palavras dele. Também não houve qualquer análise da qualidade do código: a classificação mediu indícios de autoria, não se o software funciona bem ou é seguro.

Essa ressalva já deveria bastar para qualquer leitor evitar tratar os 72,5% como fato técnico fechado. Mas ela se perde quando um número redondo circula sem o parágrafo de metodologia ao lado.

Por que aparência não prova autoria

A discussão que a análise gerou no Hacker News mostra o problema na prática. Um comentarista identificado como pona-a notou que 70% "parece alto demais" e sugeriu que sinais circunstanciais — como um commit inicial muito grande — podem refletir descuido humano, não geração por IA. Outro, jraph, foi conferir um dos aplicativos listados, o PipePipe, e disse não ter encontrado nada que sustentasse a classificação, perguntando publicamente "quais são os sinais de IA aí?" — sem resposta que esclarecesse a dúvida. Um terceiro, Mylloon, apontou que contribuições de IA costumam aparecer como coautoria em commits, o que torna a inspeção manual de histórico de git sujeita a erro, já que exige cruzar datas e grafos de contribuição à mão.

Nenhum desses comentários prova que a classificação de tintotint estava errada nesses casos específicos. Prova algo mais simples e incômodo: aparência de código, estilo de commit e tom de documentação são sinais fracos — servem como pista, não como veredito. A análise original nunca afirmou o contrário; o problema nasce quando a lista vira manchete e perde a ressalva pelo caminho.

Isso vale para os dois lados. Assim como aparência não comprova que um projeto foi gerado por IA, também não comprova que ele é de baixa qualidade. Na mesma thread, lrvick descreveu usar LLMs locais para construir infraestrutura de segurança com suítes de teste extensas ("IA mais humano é melhor do que qualquer um dos dois sozinho"); roblabla contrapôs que código gerado por IA costuma exigir revisão pesada e sair verboso, embora reconheça que LLMs ajudam em depuração e exploração. As duas posições podem ser verdadeiras ao mesmo tempo, dependendo do processo de revisão por trás de cada projeto — o dado que a aparência não captura.

Dentro do F-Droid, a régua também não existe

O episódio expôs outra lacuna: o F-Droid não tem política formal sobre código gerado por IA. Uma discussão aberta no fórum oficial do projeto em setembro de 2025, ainda ativa em janeiro de 2026, reúne propostas concorrentes — de uma marcação de "anti-feature" que apenas informa o usuário sobre o uso de modelos, até exigências de que dados de treinamento sejam reproduzíveis e licenciados como software livre. Nenhuma foi adotada.

Neil Brown, integrante do conselho do F-Droid, publicou em setembro deste ano sua posição pessoal sobre uma proposta de política interina inspirada na linha adotada pela Debian: "não sou a favor disso", escreveu, deixando claro que fala como voluntário, não em nome da organização. A objeção não é sobre o mérito de rejeitar IA — ele afirma preferir não ver "código gerado por IA generativa nem no software do próprio F-Droid, nem nos aplicativos do repositório" —, mas sobre a eficácia de uma política formal: "se alguém estiver disposto a mentir sobre o uso de IA generativa e submeter o código mesmo assim [...] os voluntários do F-Droid podem não conseguir detectar." Ainda assim, defende que declarar uma posição tem valor, porque "sinaliza o que a comunidade quer ser", mesmo sem capacidade plena de fiscalização.

Nem o conselho do projeto tem consenso, portanto, e quem mais se aproximou de um posicionamento público reconhece que a fiscalização, na prática, é limitada.

Outras comunidades miraram o comportamento, não a ferramenta

Duas iniciativas próximas ao ecossistema do F-Droid escolheram caminho diferente — e o alvo que escolheram é revelador. O IzzyOnDroid, repositório irmão que distribui pacotes compatíveis com F-Droid fora do índice oficial, tem política escrita: aplicativos "vibe-coded" são rejeitados, assim como apps que funcionam como interface para serviços de LLM. Mas a mesma política libera README e changelog gerados por IA e permite usar LLMs para pesquisa, brainstorming ou depuração, desde que o resultado não entre no código do aplicativo. O alvo declarado é o código sem revisão humana, não a ferramenta em si.

O Codeberg, plataforma de hospedagem de código independente do F-Droid, foi além: em 23 de julho de 2026, seus membros votaram — 358 a favor, 144 contra — para vedar projetos "vibe-coded" e proibir o uso do código hospedado para treinar modelos de IA. A justificativa declarada não é filosófica: é sobrecarga de infraestrutura e ausência de manutenção real por trás de repositórios de "uso único". tintotint observou, na própria amostra, que 4 dos 5 aplicativos hospedados no Codeberg foram classificados como "majoritariamente IA" — o que, se confirmado com o mesmo rigor da política do Codeberg, tensionaria essa regra. Essa verificação específica, porém, não foi feita por ninguém até a publicação deste texto.

O padrão que emerge dessas três comunidades — F-Droid em debate, IzzyOnDroid e Codeberg já com regra — não é "banir IA". É mirar a ausência de revisão humana, de manutenção e de responsabilização, o que o próprio setor já chama de "vibe coding", em vez de mirar a ferramenta usada para chegar lá.

Proveniência é a camada que falta na lista de compras de software

Para uma empresa que adota software aberto — biblioteca, componente, aplicativo inteiro —, licença e vulnerabilidade conhecida já são critérios padrão de avaliação. Proveniência, no sentido de saber quem escreveu o código, quem revisou, com que critério e com que histórico de manutenção, ainda não é. Essa lacuna importa mais agora do que há dois anos: se o custo de produzir código cai, o volume de contribuições tende a crescer, e a capacidade de revisão humana não cresce na mesma proporção — nem em projetos voluntários, nem em times internos de engenharia.

A tentação é adotar uma proibição abstrata — "não usamos nada tocado por IA" — que a própria experiência do F-Droid mostra difícil de fiscalizar e fácil de burlar. Uma alternativa mais realista é medir sinais já verificáveis, com ou sem IA na origem:

• Existe histórico de manutenção anterior ao pico de contribuições recentes, ou o projeto nasceu do zero há poucas semanas?

• Há revisão humana identificável no fluxo de contribuição — discussão real em pull requests, não apenas aprovação automática?

• O projeto tem testes automatizados com cobertura relevante, e eles rodam antes de cada merge?

• Existe um responsável — pessoa ou organização — identificável que assume ownership do projeto, ou o repositório fica órfão assim que o interesse inicial passa?

• A documentação reflete decisões reais de arquitetura, ou é texto genérico que poderia descrever qualquer projeto?

Nenhum desses critérios depende de adivinhar se uma IA escreveu a primeira versão do código. Todos dependem de processo — o mesmo ponto ao qual Neil Brown, o IzzyOnDroid e o Codeberg chegaram por caminhos diferentes.

Limites do que este caso permite concluir

Vale registrar com clareza o que a análise do F-Droid não sustenta. A amostra são 102 aplicativos de um único lote de atualizações, classificados por uma pessoa, com critério declaradamente subjetivo e sem detector técnico validado — o próprio autor afirma isso no texto original. Não há verificação independente, aplicativo por aplicativo, de que cada classificação está correta; a discussão pública já levantou pelo menos um caso (PipePipe) em que um leitor externo não encontrou os sinais que a análise alegou existir, sem esclarecimento público posterior. Também não há dado que ligue a classificação de "IA majoritária" a qualquer medida real de qualidade, segurança ou funcionamento do software — essa análise não foi feita.

Também não foi localizada, na apuração para este texto, resposta pública do F-Droid como organização sobre esse levantamento específico — em contraste com a posição pessoal de um integrante do conselho sobre o tema geral. Se e quando isso mudar, o quadro pode ficar mais claro.

Por isso, o número de 72,5% deveria circular sempre junto da metodologia que o produziu, não sozinho. Generalizar esse recorte estreito e subjetivo para "a maior parte do código aberto é feita por IA" é um salto que os próprios dados não sustentam.

Conclusão prática

O episódio não prova que o F-Droid tem um problema de qualidade. Prova que a comunidade de software livre — e, por extensão, qualquer empresa que dependa de componentes abertos — ainda não tem vocabulário compartilhado para responder a uma pergunta que ficou mais barata de fazer: quem, ou o quê, escreveu isto, e alguém revisou?

Enquanto essa régua não existe em nível de indústria, a saída prática não é esperar por ela. É construir, dentro de casa, os critérios de proveniência que já dá para verificar hoje — revisão humana documentada, testes que rodam, histórico de manutenção, um responsável identificável — e tratar a origem do código como parte da mesma checklist que já cobre licença e vulnerabilidade. O resto ainda vai levar tempo para virar consenso.

---

Fontes utilizadas

• tintotint, "How much of F-Droid is LLM generated?" (fonte primária da pauta) — https://tintotint.eu/whacky-corner/f-droid_slop/

• Discussão no Hacker News sobre a análise acima — https://news.ycombinator.com/item?id=49710015

• Fórum oficial do F-Droid, tópico "Does F-Droid have a formal policy on libre AI?" — https://forum.f-droid.org/t/does-f-droid-have-a-formal-policy-on-libre-ai/33279

• Neil Brown (conselho do F-Droid), "My views on genAI and F-Droid" — https://neilzone.co.uk/2026/09/my-views-on-genai-and-f-droid/

• IzzyOnDroid, "App Inclusion Policy" — https://izzyondroid.org/docs/general/AppInclusionPolicy/

• Codeberg, "Protecting our FLOSS commons from LLMs" — https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html