Nao - Cursor untuk data

• Editor kode AI berbasis VS Code yang dioptimalkan untuk pekerjaan data, terhubung langsung ke BigQuery/Snowflake/Postgres dan menyediakan pembuatan kode otomatis sesuai skema data serta pemeriksaan kualitas
• Sementara alat berbasis LLM yang ada melengkapi SQL secara otomatis tanpa memahami skema data, nao menggunakan tab AI berbasis RAG dan alat agen untuk menghasilkan kode SQL/Python/YAML yang akurat
• Pipeline SQL dapat ditulis, dijalankan, dan divisualisasikan dalam satu antarmuka
• Pipeline Python juga didukung di lingkungan yang sama, dan workflow dbt juga didukung
• Perbedaan data hasil sebelum dan sesudah perubahan kode serta masalah kualitas data dapat dilihat sekilas, sehingga memungkinkan deployment cepat tanpa pengujian atau membantu mencegah kesalahan
• Kegunaan utama
  • Digunakan untuk membangun pipeline data (SQL, dbt, dll.)
  • Deteksi data hilang/duplikat/outlier
  • Perbandingan data pengembangan vs operasional
  • Menjalankan dan merangkum pengujian yang telah didefinisikan sebelumnya
• Terintegrasi dengan dbt, alat BI, dan data warehouse, sehingga menyediakan lingkungan IDE yang cocok untuk data engineer, analis, dan data scientist
• Mendukung BigQuery, Snowflake, dan Postgres, serta akan segera mendukung Databricks, Iceberg, dan Redshift
• Juga akan terintegrasi dengan Looker, Power BI, Metabase, Tableau
• Saat ini hanya tersedia versi Mac, versi Windows/Linux juga direncanakan
• Perbedaan dibanding Cursor dan MCPs
  • Cursor memerlukan beberapa panggilan MCP untuk mendapatkan konteks data, sedangkan Nao selalu dapat menggunakannya dari satu RAG tunggal
  • MCPs hanya bekerja secara terbatas di dalam Cursor, dan adaptasi UI-nya juga kurang baik
  • Nao hadir dalam paket siap pakai, sehingga tidak memerlukan konfigurasi, pemasangan ekstensi, autentikasi, atau pembangunan CI/CD, dan menjadi keunggulan karena bahkan pengguna nonspesialis dapat meningkatkan pengalaman pengembangannya

FAQ

• Siapa yang sebaiknya menggunakan nao?
  • Penulis SQL, analis engineer dbt, data scientist, data engineer, dan semua anggota tim data
• Apa bedanya dengan Cursor?
  • Ini adalah IDE yang dioptimalkan untuk konteks data dengan pembuatan kode berbasis pemahaman skema data, pemeriksaan kualitas data otomatis, dan prediksi dampak perubahan
• Bahasa apa yang didukung?
  • Mendukung semua bahasa, tetapi terutama dioptimalkan untuk SQL
• Bagaimana ini membantu workflow dbt?
  • Memahami model dbt, source, dokumentasi, pengujian, dan lineage tingkat kolom, lalu menyediakan autocomplete dan visualisasi
• Bagaimana dengan keamanan data?
  • Data hanya diproses secara lokal, dan memerlukan persetujuan pengguna sebelum dikirim ke LLM
  • Kode maupun skema tidak disimpan, hanya embedding yang digunakan

[GN⁺]

Komentar Hacker News

• Banyak proyek data berbasis LLM memang menawarkan fleksibilitas dan bantuan, tetapi sulit direproduksi dan kurang interaktif; menurut saya Nao mengimplementasikan konsep ini dengan baik. Buckaroo yang saya buat adalah UI tabel data untuk Jupyter dan Pandas/Polars, sehingga Anda bisa langsung melihat data dengan tabel modern, histogram, dan statistik ringkasan. Kemarin saya merilis fitur auto-cleaning di Buckaroo, yang secara heuristik memilih cara pembersihan untuk data dan memberikan kode yang sudah final. Performanya sangat cepat, di bawah 500ms. Bisa mencoba beberapa strategi pembersihan dan memilih yang paling cocok. Untuk masalah sederhana, LLM bahkan tidak perlu dilibatkan. Ini open source dan sangat mudah diperluas

  • Saya juga sedang mengembangkan sesuatu yang sangat mirip. Memang belum sematang Buckaroo, tetapi menurut saya aplikasi tertanam di dalam notebook cukup berguna

  • Saya sangat suka tampilan untuk memvisualisasikan data profiling. Menurut saya itu bagian yang sangat penting untuk memahami data

• Menurut saya ini ide yang sangat keren. Saya penasaran bagaimana model Tab dilatih, apakah berbasis Fill in the middle atau edit history. Seseorang juga membagikan tulisan blog tentang autocomplete tab Cursor yang mirip kemarin, dan menarik untuk dibaca

  • Kami menggunakan model Fill in the middle (model hasil training internal berbasis Mistral dan Qwen), sambil memasukkan konteks data milik pengguna. Kami juga memakai parser SQL buatan sendiri agar bisa memberikan konteks skema yang tepat sesuai posisi kursor

• Setelah terus memakainya selama beberapa minggu, saya merasa ada peningkatan nyata pada workflow saya. Saya jadi lebih sering memilih ini daripada VSCode dan ekstensinya. Fitur chat, worksheet, dan pelacakan lineage kolom untuk exploratory data analysis benar-benar mengubah permainan dalam pengembangan dbt. Semua fitur ini terasa dirancang dengan sangat cermat agar cocok dengan cara saya bekerja. Claire dan Christophe juga sangat responsif terhadap masukan, serta cepat menambah dan memperbaiki fitur. Produknya sedang berkembang cepat ke arah yang benar

  • Terima kasih atas kata-kata baiknya, dan terima kasih juga sudah membantu meningkatkan nao

• Ini terasa sangat menarik. Saya sudah menonton video YouTube-nya beberapa kali, dan sangat terkesan dengan bagaimana ia mempersingkat siklus umpan balik. Keren sekali

  • Terima kasih, memang memperpendek feedback loop inilah tujuan kami. Tim data cenderung punya feedback loop yang lebih panjang dibanding software engineer, jadi kami berusaha menguranginya agar data lebih dekat ke alur pengembangan

• Saya penasaran apakah ini hanya bekerja saat memakai raw SQL. Proyek saya memakai Postgres + TypeScript dan menulis query dengan query builder seperti Kysely, jadi saya ingin tahu apakah ini bisa langsung saya gunakan

  • Untuk saat ini, Tab bekerja paling baik dengan raw SQL (file SQL murni atau string SQL). Namun jika memakai chat/agent, Anda bisa memberi tahu bahwa Anda menggunakan Kysely dan meneruskan konteks warehouse, jadi masih bisa ditangani sampai tingkat tertentu. Saya baru pertama kali mendengar Kysely, tetapi setelah melihat GIF pengenalan proyeknya, autocomplete-nya tampak cukup bagus. Pendekatannya berbeda dari model tab, tetapi menarik

• Saya penasaran seberapa banyak data/prompt saya yang dikirim ke model. Skema saya mungkin tidak masalah, tetapi data warehouse biasanya berisi data sensitif. Saya rasa ada paket enterprise, jadi saya ingin tahu sebelumnya apakah data/hasil di luar kode benar-benar dikirim ke server, atau hanya kodenya saja

  • Isi data itu sendiri tidak dikirim ke model kecuali pengguna secara eksplisit mengizinkannya. Di server, yang disimpan hanya embedding dari codebase dan skema data. Isi data hanya diakses secara lokal di komputer pengguna. Saat agent menjalankan query di warehouse, ia akan terlebih dahulu meminta persetujuan apakah hasilnya boleh dibaca. Jika tidak diizinkan, hasil itu tidak dikirim ke LLM dan hanya bisa dipratinjau secara lokal. Jika memakai versi enterprise, prompt dan konteks juga bisa dilindungi secara terpisah tanpa melewati endpoint LLM publik

• Ada yang ingin rekomendasi tautan alat berbasis LLM untuk data engineering dan data science

  • Saya sedang menyusun repositori daftar alat LLM seperti itu, dan berencana segera menyelesaikannya

• Saya suka dengan fitur-fitur yang ada. Apakah ke depannya ada rencana menambahkan dukungan SQLite juga?

  • Tentu, sepertinya itu bisa ditambahkan tanpa terlalu sulit. DuckDB juga akan masuk di rilis berikutnya, dan SQLite pun bisa ditambahkan. Saya penasaran apakah alasan Anda memakai SQLite adalah untuk pengembangan lokal

• Saya penasaran bagaimana ini menangani join transitif di beberapa tabel yang tidak punya FK/PK. Selain itu, analisis penggunaan/penulisan ulang terhadap query tidak efisien yang sudah ada juga tampaknya bisa jadi fitur andalan

  • Untuk join, kami memberikan ke model skema tiap tabel serta cara join yang sudah pernah digunakan di repositori/riwayat query, agar membantu menyimpulkan relasi. Analisis penggunaan juga jelas ada dalam roadmap pengembangan. Kami berencana mengakses log data warehouse untuk mengukur penggunaan nyata tiap tabel