Nao - Cursor für Daten

• Ein auf Datenarbeit spezialisierter KI-Code-Editor auf Basis von VS Code, der direkt mit BigQuery/Snowflake/Postgres verbunden ist und automatische Codegenerierung passend zum Datenschema sowie Qualitätsprüfungen bietet
• Während bestehende LLM-basierte Tools SQL automatisch vervollständigen, ohne das Datenschema zu erkennen, erzeugt nao mit RAG-basiertem AI-Tab und Agent-Tools präzisen SQL-/Python-/YAML-Code
• SQL-Pipelines können in einer einzigen Oberfläche geschrieben, ausgeführt und visualisiert werden
• Python-Pipelines werden in derselben Umgebung ebenfalls unterstützt, ebenso dbt-Workflows
• Unterschiede in den Ergebnisdaten vor und nach Codeänderungen sowie Probleme mit der Datenqualität lassen sich auf einen Blick erkennen, sodass schnelle Deployments ohne Tests oder die Vermeidung von Fehlern möglich sind
• Wichtige Einsatzbereiche
  • Aufbau von Datenpipelines (SQL, dbt usw.)
  • Erkennung von fehlenden Werten/Dubletten/Ausreißern
  • Vergleich von Entwicklungs- und Produktionsdaten
  • Ausführung und Zusammenfassung vordefinierter Tests
• Durch die Integration mit dbt, BI-Tools und Data Warehouses bietet es eine IDE-Umgebung, die für Data Engineers, Analysten und Data Scientists gleichermaßen geeignet ist
• Unterstützt BigQuery, Snowflake und Postgres; Unterstützung für Databricks, Iceberg und Redshift ist in Kürze geplant
• Integration mit Looker, Power BI, Metabase, Tableau ebenfalls geplant
• Derzeit nur als Mac-Version verfügbar, Windows und Linux sind ebenfalls geplant
• Unterschiede zu Cursor und MCPs
  • Cursor benötigt mehrere MCP-Aufrufe, um Datenkontext zu erhalten; bei Nao ist dieser über ein einzelnes RAG jederzeit verfügbar
  • MCPs funktionieren innerhalb von Cursor nur eingeschränkt, zudem ist die UI weniger anpassungsfähig
  • Nao ist vorkonfiguriert und paketiert; Einrichtung, Installation von Erweiterungen, Authentifizierung und Aufbau von CI/CD entfallen, was auch Nicht-Spezialisten ein besseres Entwicklungserlebnis ermöglicht

FAQ

• Für wen ist nao gedacht?
  • SQL-Autoren, dbt Analytics Engineers, Data Scientists, Data Engineers und damit für alle Mitglieder eines Datenteams
• Worin unterscheidet es sich von Cursor?
  • Eine IDE, die für Datenkontext optimiert ist, mit schemaerkennungsbasierter Codegenerierung, automatischen Datenqualitätsprüfungen und Vorhersage der Auswirkungen von Änderungen
• Welche Sprachen werden unterstützt?
  • Alle Sprachen werden unterstützt, besonders für SQL optimiert
• Wie hilft es bei dbt-Workflows?
  • Es versteht dbt-Modelle, Sources, Dokumentation, Tests und spaltenbasierte Lineage und bietet Autovervollständigung sowie Visualisierung
• Wie steht es um die Datensicherheit?
  • Daten werden nur lokal verarbeitet und vor der Übertragung an ein LLM ist die Zustimmung des Nutzers erforderlich
  • Code oder Schema werden nicht gespeichert, es werden ausschließlich Embeddings verwendet

[GN⁺]

Hacker-News-Kommentare

• Es wird darauf hingewiesen, dass viele LLM-basierte Datenprojekte zwar flexibel und hilfreich sind, sich aber schwer reproduzieren lassen und es ihnen an Interaktivität fehlt; Nao setze dieses Konzept sehr gut um. Buckaroo, das ich gebaut habe, ist eine Daten-Tabellen-UI für Jupyter und Pandas/Polars, mit der man Daten sofort über aktuelle Tabellen, Histogramme und zusammenfassende Statistiken betrachten kann. Gestern habe ich in Buckaroo eine Auto-Cleaning-Funktion veröffentlicht, die heuristisch eine Bereinigungsmethode für die Daten auswählt und den bestätigten Code bereitstellt. Sie ist mit unter 500 ms sehr schnell, man kann mehrere Bereinigungsstrategien ausprobieren und die passendste wählen, und einfache Probleme müssen gar nicht erst durch ein LLM. Es ist Open Source und sehr gut erweiterbar

  • Ich entwickle auch gerade etwas sehr Ähnliches. Es ist noch nicht so ausgereift wie Buckaroo, aber ich finde eine eingebettete App im Notebook ziemlich nützlich

  • Die Ansicht zur Visualisierung von Data Profiling gefällt mir sehr, ich halte das für einen entscheidenden Kernpunkt beim Verständnis von Daten

• Ich halte das für eine wirklich großartige Idee. Ich frage mich, wie ihr das Tab-Modell trainiert habt, ob es auf Fill in the middle oder auf der Edit-History basiert. Gestern hat jemand einen Blogbeitrag zu Cursor-Tab-Autovervollständigung geteilt, den ich mit Interesse gelesen habe

  • Wir verwenden ein Fill-in-the-middle-Modell (eigenständig trainierte Modelle auf Basis von Mistral und Qwen) und geben den Datenkontext des Nutzers mit hinein. Je nach Cursor-Position verwenden wir einen eigenen SQL-Parser, um den passenden Schema-Kontext bereitzustellen

• Nachdem ich es einige Wochen lang weiter genutzt habe, habe ich gemerkt, dass es den Workflow tatsächlich stark verbessert. Ich greife inzwischen häufiger dazu als zu VSCode plus Erweiterungen. Chat, Worksheets und Spalten-Lineage für explorative Datenanalyse haben die dbt-Entwicklung für mich wirklich verändert. Diese Funktionen wirken sorgfältig auf meine tatsächliche Arbeitsweise abgestimmt, und Claire und Christophe reagieren sofort auf Feedback und fügen Funktionen schnell hinzu oder verbessern sie. Das Produkt entwickelt sich rasch in die richtige Richtung

  • Danke für die netten Worte, und danke, dass du bei der Verbesserung von nao hilfst

• Das wirkt wirklich attraktiv. Ich habe mir das YouTube-Video mehrmals angesehen, und ich war sehr beeindruckt davon, wie sehr es den Feedback-Zyklus verkürzt. Wirklich cool

  • Danke, genau diese Verkürzung der Feedback-Schleife ist unser Ziel. Datenteams haben im Vergleich zu Software Engineers oft längere Feedback-Schleifen, und wir arbeiten daran, sie zu verkürzen, um Daten näher an den Entwicklungsfluss zu bringen

• Ich frage mich, ob das nur mit raw SQL funktioniert. In meinem Projekt schreibe ich Abfragen in Postgres + TypeScript mit einem Query Builder wie Kysely, und ich frage mich, ob ich das sofort einsetzen könnte

  • Aktuell funktioniert Tab am besten mit raw SQL (reinen SQL-Dateien oder Strings). Mit Chat/Agent kann man aber angeben, dass man Kysely verwendet, und wenn man den Warehouse-Kontext mitgibt, kann es damit einigermaßen umgehen. Von Kysely höre ich zum ersten Mal, aber das GIF auf der Projektseite ließ die Autovervollständigung ziemlich gut aussehen. Anders als unser Tab-Ansatz, aber interessant

• Ich frage mich, wie viele meiner Daten/Prompts an das Modell weitergegeben werden. Mit meinem Schema hätte ich kein Problem, aber Warehouse-Daten sind meistens sensible Daten. Ich nehme an, es gibt einen Enterprise-Plan, aber ich würde gern im Voraus wissen, ob neben dem eigentlichen Code auch Daten/Ergebnisse an den Server gesendet werden oder nur der Code

  • Die eigentlichen Dateninhalte werden nicht an das Modell weitergegeben, es sei denn, der Nutzer erlaubt das ausdrücklich. Auf dem Server werden nur Embeddings der Codebasis und des Datenschemas gespeichert. Auf die Dateninhalte wird nur lokal auf dem Computer des Nutzers zugegriffen. Wenn der Agent eine Abfrage ausführt, wird sie im Warehouse ausgeführt und bevor Ergebnisse gelesen werden, wird zuerst um Zustimmung gebeten. Ohne Freigabe werden sie nicht an ein LLM gesendet und können lokal vorab angesehen werden. Bei der Enterprise-Version können Prompts und Kontext zusätzlich geschützt werden, ohne über öffentliche LLM-Endpunkte zu laufen

• Gibt es jemanden, der Empfehlungen oder Links zu LLM-basierten Tools für Data Engineering und Data Science geben kann

  • Ich stelle gerade ein Listen-Repository für solche LLM-Tools zusammen und plane, es bald fertigzustellen

• Die vorhandenen Funktionen gefallen mir, und ich frage mich, ob ihr künftig auch SQLite unterstützen wollt

  • Natürlich, das sollte sich ohne große Schwierigkeiten ergänzen lassen. Im nächsten Release kommt auch DuckDB dazu, und SQLite können wir ebenfalls hinzufügen. Ich frage mich, ob du SQLite für lokale Entwicklung verwendest

• Ich frage mich, wie ihr mit transitiven Joins umgeht, wenn über mehrere Tabellen hinweg keine FK/PKs vorhanden sind. Außerdem scheint mir eine Analyse/Umschreibung bereits existierender ineffizienter Abfragen ebenfalls ein Killer-Feature zu sein

  • Bei Joins geben wir dem Modell das Schema jeder Tabelle sowie die Join-Muster mit, die im Repository bzw. in der Abfragehistorie bereits verwendet wurden, um bei der Ableitung von Beziehungen zu helfen. Nutzungsanalyse steht definitiv auf der Entwicklungs-Roadmap; wir planen Zugriff auf die Logs des Data Warehouse, um die tatsächliche Nutzung jeder Tabelle zu messen