Nao - o Cursor para dados

• Um editor de código com IA baseado em VS Code, especializado em trabalho com dados, que se conecta diretamente a BigQuery/Snowflake/Postgres e oferece geração automática de código alinhada ao esquema de dados e verificações de qualidade
• Enquanto ferramentas baseadas em LLM existentes completam SQL sem reconhecer o esquema de dados, o nao gera código SQL/Python/YAML preciso com guia de IA baseada em RAG e ferramentas de agente
• Permite escrever, executar e visualizar pipelines SQL em uma única interface
• Também oferece suporte a pipelines Python no mesmo ambiente, além de fluxos de trabalho com dbt
• É possível verificar de relance as diferenças nos dados de resultado antes e depois de alterações no código e problemas de qualidade dos dados, permitindo implantar rapidamente sem testes ou evitar erros
• Principais casos de uso
  • Uso na construção de pipelines de dados (SQL, dbt etc.)
  • Detecção de faltantes/duplicatas/outliers
  • Comparação entre dados de desenvolvimento e produção
  • Execução e resumo de testes predefinidos
• Integrado com dbt, ferramentas de BI e data warehouses, oferecendo um ambiente de IDE adequado para engenheiros de dados, analistas e cientistas de dados
• Suporta BigQuery, Snowflake e Postgres, com suporte a Databricks, Iceberg e Redshift previsto em breve
• Integração com Looker, Power BI, Metabase e Tableau também está prevista
• No momento, apenas a versão para Mac está disponível, com versões para Windows/Linux planejadas
• Diferenças em relação ao Cursor e aos MCPs
  • O Cursor precisa de várias chamadas de MCP para obter contexto de dados; no Nao, isso fica sempre disponível em um único sistema de RAG
  • Os MCPs funcionam apenas de forma limitada dentro do Cursor e também têm pouca adaptabilidade de UI
  • O Nao vem pré-empacotado, então não é preciso fazer configuração, instalar extensões, autenticar ou montar CI/CD, o que traz como vantagem melhorar a experiência de desenvolvimento mesmo para não especialistas

FAQ

• Quem deve usar o nao?
  • Redatores de SQL, engenheiros de analytics com dbt, cientistas de dados, engenheiros de dados e todos os membros de equipes de dados
• Qual é a diferença em relação ao Cursor?
  • É uma IDE otimizada para contexto de dados, com geração de código baseada no reconhecimento de esquemas de dados, verificação automática da qualidade dos dados e previsão do impacto das mudanças
• Quais linguagens ele suporta?
  • Suporta todas as linguagens, mas é especialmente otimizado para SQL
• Como ele ajuda em fluxos de trabalho com dbt?
  • Entende modelos, fontes, documentação, testes e lineage em nível de coluna no dbt, além de fornecer autocompletar e visualização
• E a segurança dos dados?
  • Os dados são processados apenas localmente e o envio para o LLM acontece somente com autorização do usuário
  • O código e o esquema não são armazenados, apenas embeddings são utilizados

[GN⁺]

Comentários do Hacker News

• Muitas ferramentas de dados baseadas em LLM oferecem flexibilidade e ajudam bastante, mas são difíceis de repetir e pouco interativas; o Nao parece ter implementado bem esse conceito. O Buckaroo que eu criei é uma UI de tabela de dados para Jupyter e Pandas/Polars, com tabelas atualizadas, histogramas e estatísticas resumidas para visualizar os dados imediatamente. Ontem lancei um recurso de limpeza automática no Buckaroo, que escolhe heurísticamente como limpar os dados e fornece o código final gerado. É extremamente rápido, em menos de 500ms. Dá para testar várias estratégias de limpeza e escolher a mais adequada, e problemas simples nem precisam passar por um LLM. É open source e tem ótima extensibilidade

  • Eu também estou desenvolvendo algo muito parecido. Ainda não está tão polido quanto o Buckaroo, mas acho apps embutidos no notebook bem úteis

  • Gostei muito da visão para visualizar data profiling. Acho que isso é uma parte central para entender os dados

• Achei uma ideia muito legal. Fiquei curioso sobre como vocês treinaram o modelo de Tab: se foi com Fill in the middle ou com base em histórico de edição. Ontem alguém compartilhou um post de blog parecido sobre autocompletar com Tab no Cursor, e achei a leitura interessante

  • Usamos um modelo Fill in the middle (modelos próprios treinados sobre Mistral e Qwen), junto com o contexto dos dados do usuário. Também usamos um parser SQL próprio para fornecer o contexto de schema adequado dependendo da posição do cursor

• Depois de usar por algumas semanas, senti uma melhora real no fluxo de trabalho. Acabei escolhendo isso em vez de VSCode com extensões em mais da metade das vezes. Os recursos de chat para análise exploratória de dados, worksheets e rastreamento de linhagem de colunas mudaram completamente o jogo no desenvolvimento com dbt. Tudo isso parece cuidadosamente projetado para combinar com a forma como eu realmente trabalho. Claire e Christophe também respondem rápido ao feedback e adicionam ou corrigem recursos com agilidade. O produto está evoluindo rápido na direção certa

  • Obrigado pelas palavras, e por ajudar a melhorar o nao

• Isso parece muito atraente. Vi o vídeo no YouTube várias vezes e fiquei muito impressionado com como ele encurta o ciclo de feedback. Muito legal mesmo

  • Obrigado; esse encurtamento do loop de feedback é exatamente nosso objetivo. Equipes de dados tendem a ter loops de feedback mais longos do que engenheiros de software, então estamos tentando reduzir isso para aproximar dados de um fluxo de desenvolvimento

• Queria saber se isso funciona só com SQL bruto. No meu projeto eu escrevo queries em Postgres + TypeScript usando query builders como Kysely; queria saber se eu conseguiria usar isso agora

  • No momento, o Tab funciona melhor com SQL bruto (arquivos SQL puros ou strings). Mas, se você usar chat/agent e disser que está usando Kysely, além de passar o contexto do warehouse, ele consegue lidar até certo ponto. É a primeira vez que ouço falar de Kysely, mas vendo o GIF de apresentação do projeto, o autocomplete parece bem bom. É diferente da abordagem via Tab, mas interessante

• Fiquei curioso sobre quanto dos meus dados/prompts é enviado ao modelo. Meu schema em si tudo bem, mas os dados do warehouse costumam ser sensíveis. Imagino que exista um plano enterprise, mas gostaria de saber de antemão se dados/resultados além do código realmente são enviados ao servidor, ou se vai só o código

  • O conteúdo dos dados em si não é enviado ao modelo a menos que o usuário permita explicitamente. No servidor, armazenamos apenas embeddings do codebase e do schema de dados. O conteúdo dos dados é acessado somente localmente no computador do usuário. Quando o agent executa queries, ele roda no warehouse e antes de ler os resultados pede aprovação para saber se pode acessá-los. Se você não permitir, nada é enviado ao LLM e ainda assim é possível visualizar localmente. No enterprise, prompts e contexto podem ser protegidos separadamente, sem passar por endpoints públicos de LLM

• Alguém tem recomendações de links para ferramentas baseadas em LLM para engenharia de dados e data science?

  • Estou organizando um repositório em lista desse tipo de ferramenta de LLM; pretendo terminá-lo em breve

• Gostei dos recursos que vocês têm. Existe plano de adicionar suporte a SQLite no futuro?

  • Com certeza. Parece algo que dá para adicionar sem muita dificuldade. DuckDB deve entrar na próxima release, e SQLite também pode ser adicionado. Fiquei curioso se o uso de SQLite é por causa de desenvolvimento local

• Queria saber como isso lida com joins transitivos entre várias tabelas sem FK/PK. Além disso, análise de uso e reescrita de queries ineficientes já existentes também parecem um recurso matador

  • No caso de joins, fornecemos ao modelo o schema de cada tabela e as formas de join já usadas no repositório/histórico de queries para ajudar a inferir relações. Análise de uso também está claramente no roadmap de desenvolvimento; planejamos acessar logs do data warehouse para medir o uso real de cada tabela