Launch HN: Greptile (YC W24) - RAG em codebases que realmente funciona

Uma nova ferramenta chamada Greptile aplica geração aumentada por recuperação (RAG) a codebases inteiras, permitindo que desenvolvedores façam perguntas em linguagem natural sobre projetos e recebam respostas com contexto, desde como tipos específicos são serializados até como diferentes componentes interagem. Os comentadores se interessam pelo potencial para compreensão de código, integração com IDE e uso em repositórios grandes ou multilíngues, mas levantam preocupações sobre confiabilidade em escala, permissões do GitHub, privacidade de embeddings, falta de metadados como issues/PRs e a maturidade do produto diante de quedas e erros durante o lançamento. Vários comparam a ferramentas existentes como Cursor, Cody e Bloop, e pedem recursos como auto-hospedagem, melhores fluxos locais e suporte a mais repositórios públicos e fontes de documentação.

Produto e Abordagem Central

  • A ferramenta oferece “RAG em codebases”: usa ASTs (via tree‑sitter), embeddings e LLMs para responder perguntas sobre repositórios inteiros.
  • O foco é na compreensão de código e na substituição/complemento de documentação interna, não principalmente na geração de código (embora os usuários também a usem para gerar código).
  • Atualmente indexa apenas código; há planos para adicionar mensagens de commit, PRs, issues, comentários e melhor uso de comentários de documentação.

Experiências de Usuários e Casos de Uso

  • Relatos positivos: respondeu a perguntas nuançadas sobre frameworks (por exemplo, codificação JSON de BigDecimal em Rails) de forma compatível com o que os usuários aprenderam manualmente.
  • Alguns veem isso como uma expansão da janela de contexto de LLMs para projetos complexos; há interesse em usá-lo em grandes repositórios Rails e multilíngues.
  • Usuários querem que ajude a depurar erros de API se o código-fonte da API estiver disponível.

Integrações e Plataformas

  • Tem uma extensão para VS Code; um plugin para JetBrains está no roteiro.
  • Demonstração pública: cerca de 100 repositórios open-source podem ser consultados sem login.
  • É necessário um app do GitHub para repositórios privados; houve alguma confusão sobre permissões e a formulação “agir em seu nome”.

Confiabilidade, Desempenho e Problemas de UX

  • Muitos relatos de erros (“internal error while processing/locating sources”), processamento falho ou travado (muitas vezes em 99%) e indisponibilidades de AWS/DB, especialmente durante o tráfego do HN.
  • Foram observados bugs em links de repositórios populares, na interface de votação, na seleção de branch/repo e na marca residual (“Onboard”).
  • Indicador de progresso e a UI de seleção de repositório são considerados enganosos ou trabalhosos.

Privacidade, Segurança e Auto-hospedagem

  • Afirma não armazenar código após o processamento; atualmente armazena embeddings de docstrings geradas, com discussão de que embeddings podem vazar informações.
  • Alguns usuários prefeririam armazenamento explícito de código se isso melhorasse a velocidade, e/ou versões totalmente locais ou auto-hospedadas.
  • A equipe vê auto-hospedagem e on-prem como algo futuro, mas é provável que os LLMs não sejam auto-hospedados no curto prazo.

Preço, Limites e Fricção de Adoção

  • O plano gratuito tem limites de tamanho de repositório; usuários com grandes conjuntos de teste têm dificuldade para avaliar.
  • Sugestões: exclusões no estilo .greptileignore, ferramentas de versionamento de dados e um trial mais flexível (por exemplo, um repositório grande).
  • Preocupações com o uso automático do e-mail do GitHub; pedidos por opt-in e escolha separada de e-mail.

Posicionamento e Comparações

  • Comparado a Bloop, Adrenaline, Cursor e Cody; apresentado como compreensão de base de código completa, em vez de substituição da IDE.
  • Várias pessoas apontam que o jargão “RAG” não é explicado ou é confuso e deveria ser comunicado melhor.