Nao - Veriler için Cursor

• Veri işleri için özelleştirilmiş, VS Code tabanlı bir yapay zeka kod editörü; BigQuery/Snowflake/Postgres'e doğrudan bağlanarak veri şemasına uygun otomatik kod üretimi ve kalite denetimi sunuyor
• Mevcut LLM tabanlı araçlar veri şemasını tanımadan SQL otomatik tamamlarken, nao RAG tabanlı AI sekmesi ve ajan araçlarıyla doğru SQL/Python/YAML kodu üretiyor
• SQL pipeline yazma, çalıştırma ve görselleştirme işlemleri tek bir arayüzde yapılabiliyor
• Python pipeline da aynı ortamda destekleniyor ve dbt iş akışları da destekleniyor
• Kod değişikliği öncesi ve sonrası sonuç verilerindeki farkı ve veri kalitesi sorunlarını tek bakışta gösterdiği için, test yapmadan hızlı dağıtım yapmayı veya hataları önlemeyi kolaylaştırıyor
• Başlıca kullanım alanları
  • Veri pipeline'ı kurma (SQL, dbt vb.)
  • Eksik/tekrarlı/aykırı değer tespiti
  • Geliştirme ve üretim verisini karşılaştırma
  • Önceden tanımlı testleri çalıştırma ve özetleme
• dbt, BI araçları ve veri ambarlarıyla entegre olduğu için veri mühendisleri, analistler ve veri bilimciler için uygun bir IDE ortamı sunuyor
• BigQuery, Snowflake ve Postgres destekleniyor; yakında Databricks, Iceberg ve Redshift desteği de gelecek
• Looker, Power BI, Metabase, Tableau ile entegrasyon da planlanıyor
• Şu anda yalnızca Mac sürümü mevcut, Windows/Linux sürümleri de gelecek
• Cursor ve MCP'lerden farkları
  • Cursor'ın veri bağlamı alabilmesi için birden fazla MCP çağrısı gerekirken, Nao'da bu bağlam tek bir RAG içinde her zaman kullanılabiliyor
  • MCP'ler Cursor içinde yalnızca sınırlı şekilde çalışıyor ve UI uyarlanabilirliği de zayıf kalıyor
  • Nao önceden paketlenmiş olarak geliyor; kurulum, eklenti yükleme, kimlik doğrulama veya CI/CD kurma gerektirmiyor, bu da uzman olmayan kullanıcıların bile geliştirme deneyimini iyileştirmesine yardımcı oluyor

SSS

• Nao'yu kim kullanmalı?
  • SQL yazarları, dbt analitik mühendisleri, veri bilimcileri, veri mühendisleri gibi tüm veri ekibi üyeleri
• Cursor'dan farkı ne?
  • Veri şeması farkındalığına dayalı kod üretimi, otomatik veri kalitesi denetimi, değişiklik etkisi öngörüsü gibi özelliklerle veri bağlamı için optimize edilmiş bir IDE
• Hangi dilleri destekliyor?
  • Tüm dilleri destekliyor, ancak özellikle SQL için optimize edilmiş
• dbt iş akışlarına nasıl yardımcı oluyor?
  • dbt modellerini, kaynakları, dokümantasyonu, testleri ve sütun bazlı lineage'ı anlayıp otomatik tamamlama ve görselleştirme sağlıyor
• Veri güvenliği nasıl?
  • Veriler yalnızca yerelde işleniyor ve LLM'e gönderilmeden önce kullanıcı onayı alınıyor
  • Kod veya şema saklanmıyor, yalnızca embedding'ler kullanılıyor

[GN⁺]

Hacker News görüşleri

• Birçok LLM tabanlı veri projesinin esneklik ve fayda sunduğu, ancak tekrarlanmasının zor ve etkileşimselliğinin yetersiz olduğu belirtiliyor; Nao'nun bu fikri iyi hayata geçirdiği düşünülüyor. Benim geliştirdiğim Buckaroo ise Jupyter ve Pandas/Polars için bir veri tablosu arayüzü; veriyi güncel tablolar, histogramlar ve özet istatistiklerle anında görmeyi sağlıyor. Dün Buckaroo'ya otomatik temizleme özelliği ekledim; veriye göre sezgisel olarak bir temizleme yöntemi seçip ortaya çıkan kodu veriyor. 500 ms altında çok yüksek hız sunuyor. Birden fazla temizleme stratejisi denenebiliyor ve en uygunu seçilebiliyor. Basit sorunlarda LLM'den geçmek gerekmiyor. Açık kaynak ve genişletilebilirliği çok iyi.

  • Ben de gerçekten çok benzer bir şey geliştiriyorum; henüz Buckaroo kadar tamamlanmış değil ama notebook içine gömülü uygulama fikrinin oldukça faydalı olduğunu düşünüyorum.

  • Veri profillemesini görselleştirebilen görünümü gerçekten beğendim; bence veriyi anlamanın kritik bir parçası.

• Bunun gerçekten harika bir fikir olduğunu düşünüyorum. Tab modelini nasıl eğittiklerini merak ediyorum; Fill in the middle mı yoksa edit history tabanlı mı? Birisi dün buna benzer Cursor Tab otomatik tamamlama hakkında bir blog yazısı paylaşmıştı, onu da ilgiyle okudum.

  • Biz Fill in the middle modeli kullanıyoruz (Mistral ve Qwen üzerinde kendi eğittiğimiz modeller). Buna kullanıcının veri bağlamını da ekliyoruz. İmleç konumuna göre uygun şema bağlamını vermek için kendi SQL parser'ımızı kullanıyoruz.

• Birkaç haftadır düzenli kullanıyorum ve iş akışımda gerçekten büyük iyileşme sağladığını hissediyorum. VSCode ve eklentileri yerine zamanın yarısından fazlasında bunu seçiyorum. Keşifsel veri analizi için sohbet, worksheet ve sütun soy ağacı takibi özellikleri dbt geliştirmede gerçekten oyunun kurallarını değiştiriyor. Bunların hepsi gerçek çalışma biçimime uygun olacak şekilde ince düşünülmüş hissettiriyor. Claire ve Christophe geri bildirimlere de anında dönüyor; özellikleri çok hızlı ekleyip düzeltiyorlar. Ürün doğru yönde hızla gelişiyor.

  • Güzel sözler için teşekkürler, ayrıca nao'yu geliştirmemize yardımcı olduğunuz için de teşekkür ederiz.

• Gerçekten etkileyici görünüyor. YouTube videosunu birkaç kez izledim ve geri bildirim döngüsünü kısaltma biçimi beni çok etkiledi. Gerçekten çok güzel.

  • Teşekkürler; hedefimiz tam olarak bu geri bildirim döngüsünü kısaltmak. Veri ekipleri, yazılım mühendislerine kıyasla daha uzun geri bildirim döngülerine sahip olma eğiliminde; biz de bunu azaltıp veriyi geliştirme akışına daha yakın hale getirmek istiyoruz.

• Bunun yalnızca raw SQL ile mi çalıştığını merak ediyorum. Benim projemde Postgres + TypeScript üzerinde Kysely gibi bir query builder ile sorgu yazılıyor; bunu şu anda kullanıp kullanamayacağımı merak ettim.

  • Şu anda Tab en iyi raw SQL ile çalışıyor (doğrudan SQL dosyaları veya string'ler). Ama chat/agent kullanırsanız Kysely kullandığınızı belirtip warehouse bağlamını verirseniz bir ölçüde bununla çalışabilir. Kysely'yi ilk kez duyuyorum ama proje tanıtım GIF'ine bakınca otomatik tamamlama tarafı oldukça iyi görünüyor. Tab tarzından farklı ama ilginç.

• Verimin/prompt'larımın ne kadarının modele gönderildiğini merak ediyorum. Şemamın gitmesi sorun değil ama warehouse verileri genelde hassas veriler içeriyor. Kurumsal bir planınız olduğunu sanıyorum; gerçek kod dışındaki veri/sonuçlar sunucuya mı gönderiliyor, yoksa yalnızca kod mu gidiyor, bunu önceden bilmek isterim.

  • Kullanıcı açıkça izin vermediği sürece veri içeriğinin kendisi modele gönderilmez. Sunucuda yalnızca kod tabanının ve veri şemasının embedding'leri saklanır. Veri içeriğine yalnızca kullanıcının bilgisayarında yerel olarak erişilir. Agent bir sorgu çalıştırdığında warehouse üzerinde yürütür ve sonuçları okumasına izin verip vermediğinizi önce onayınıza sunar. İzin vermezseniz LLM'e gönderilmez ve yerelde önizlenebilir. Kurumsal sürüm kullanıldığında prompt'lar ve bağlam ortak LLM endpoint'lerinden geçmeden ayrıca korunabilir.

• Veri mühendisliği ve veri bilimi için LLM tabanlı araçlar bağlantıları önerebilecek biri var mı?

  • Ben bu tür LLM araçları için bir liste deposu hazırlıyorum; yakında tamamlamayı planlıyorum.

• Sundukları özellikleri beğendim; ileride SQLite desteği de eklemeyi düşünüyor musunuz diye merak ediyorum.

  • Elbette; bunu eklemek çok zor görünmüyor. Bir sonraki sürümde DuckDB de gelecek, SQLite'ı da ekleyebiliriz. SQLite kullanma nedeninizin yerel geliştirme olup olmadığını merak ettim.

• Birden fazla tablo üzerinde FK/PK olmadan geçişli join yapıldığında bunu nasıl ele aldığını merak ediyorum. Bunun dışında mevcut verimsiz sorguların kullanım analizi/yeniden yazımı da bence öldürücü bir özellik olabilir.

  • Join tarafında, her tablonun şemasını ve depo/sorgu geçmişinde daha önce kullanılmış join biçimlerini modele vererek ilişkileri çıkarsamasına yardımcı oluyoruz. Kullanım analizi de kesinlikle geliştirme yol haritamızda var; her tablonun gerçek kullanımını ölçmek için veri warehouse loglarına erişmeyi planlıyoruz.