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.