Nao - डेटा के लिए Cursor

• डेटा वर्कफ़्लो के लिए विशेष रूप से तैयार VS Code-आधारित AI code editor, जो BigQuery/Snowflake/Postgres से सीधे जुड़कर डेटा schema के अनुरूप code auto-generation और quality checks प्रदान करता है
• जहाँ मौजूदा LLM-आधारित tools डेटा schema को पहचाने बिना SQL autocomplete करते हैं, वहीं nao RAG-आधारित AI tab और agent tools के ज़रिए सटीक SQL/Python/YAML code जनरेट करता है
• SQL pipelines को लिखना, चलाना और visualize करना एक ही interface में संभव है
• Python pipelines भी उसी environment में supported हैं, और dbt workflow का भी support है
• code changes से पहले और बाद के result data के अंतर और data quality issues को एक नज़र में देखा जा सकता है, जिससे बिना test के तेज़ deployment या गलतियों से बचाव संभव होता है
• मुख्य उपयोग
  • data pipelines बनाने में उपयोगी (SQL, dbt आदि)
  • missing/duplicate/outlier detection
  • development बनाम production data comparison
  • pre-defined tests चलाना और उनका summary देखना
• dbt, BI tools और data warehouse के साथ integration के कारण यह data engineers, analysts और data scientists सभी के लिए उपयुक्त IDE environment प्रदान करता है
• BigQuery, Snowflake, Postgres supported हैं, और जल्द ही Databricks, Iceberg, Redshift का support आने वाला है
• Looker, Power BI, Metabase, Tableau के साथ integration भी आने वाला है
• फ़िलहाल केवल Mac version उपलब्ध है, Windows/Linux versions भी आने वाले हैं
• Cursor और MCPs से अंतर
  • Cursor को data context पाने के लिए कई MCP calls की ज़रूरत पड़ती है, जबकि Nao में यह एक single RAG में हमेशा उपलब्ध रहता है
  • MCPs, Cursor के भीतर सीमित रूप से ही काम करते हैं और UI adaptability भी कम है
  • Nao pre-packaged है, इसलिए setup, extension installation, authentication, और CI/CD setup की ज़रूरत नहीं पड़ती; इसकी ताकत यह है कि non-experts भी अपना development experience बेहतर बना सकते हैं

FAQ

• nao किसे इस्तेमाल करना चाहिए?
  • SQL लिखने वाले, dbt analytics engineers, data scientists, data engineers आदि पूरी data team के सभी सदस्य
• Cursor से यह कैसे अलग है?
  • यह data schema-aware code generation, automatic data quality checks, और change impact prediction जैसी क्षमताओं वाला data context के लिए optimized IDE है
• कौन-कौन सी languages supported हैं?
  • सभी languages supported हैं, लेकिन यह खासकर SQL के लिए optimized है
• dbt workflow में यह कैसे मदद करता है?
  • यह dbt models, sources, docs, tests, और column-level lineage को समझकर autocomplete और visualization देता है
• data security कैसी है?
  • data केवल local में process होता है, और LLM को भेजने से पहले user की अनुमति ली जाती है
  • code या schema store नहीं किए जाते, केवल embeddings का उपयोग होता है

[GN⁺]

Hacker News राय

• कई LLM-आधारित डेटा प्रोजेक्ट्स लचीलापन और मदद तो देते हैं, लेकिन उन्हें दोहराना कठिन होता है और उनमें इंटरैक्टिविटी की कमी रहती है; Nao ने इस कॉन्सेप्ट को अच्छी तरह लागू किया है। मेरा बनाया हुआ Buckaroo Jupyter और Pandas/Polars के लिए एक डेटा टेबल UI है, जिसमें आप आधुनिक टेबल्स, histogram और summary statistics के साथ तुरंत डेटा देख सकते हैं। मैंने कल ही Buckaroo में auto-cleaning फ़ीचर जारी किया है, जो heuristic तरीके से डेटा साफ़ करने का तरीका चुनता है और confirmed code देता है। इसकी तेज़ रफ़्तार 500ms के भीतर है। आप कई cleaning strategies आज़मा सकते हैं और सबसे उपयुक्त चुन सकते हैं। साधारण समस्याओं के लिए LLM से होकर जाने की ज़रूरत नहीं होती। यह open source है और extensibility भी शानदार है

  • मैं भी कुछ बहुत मिलता-जुलता बना रहा हूँ। अभी यह Buckaroo जितना परिपक्व नहीं है, लेकिन मुझे लगता है कि notebook के अंदर embedded app काफ़ी उपयोगी है

  • डेटा profiling को विज़ुअलाइज़ करने वाला view मुझे बहुत पसंद आया। मेरे हिसाब से यह डेटा समझने का एक अहम हिस्सा है

• यह सच में शानदार आइडिया लगता है। जानना चाहूँगा कि Tab मॉडल को कैसे train किया गया है — क्या यह Fill in the middle है या edit history-आधारित? किसी ने कल इसी तरह के Cursor tab autocomplete पर एक ब्लॉग पोस्ट साझा की थी, जिसे मैंने दिलचस्पी से पढ़ा

  • हम Fill in the middle model इस्तेमाल करते हैं (Mistral और Qwen के internally trained models), और इसमें user का data context भी शामिल करते हैं। cursor की position के अनुसार सही schema context देने के लिए हम अपना SQL parser इस्तेमाल करते हैं

• कुछ हफ़्तों तक लगातार इस्तेमाल करने के बाद मुझे लगा कि इससे workflow में सचमुच बड़ा सुधार आया है। मैं इसे VSCode और extensions की जगह आधे से ज़्यादा बार चुनता हूँ। exploratory data analysis के लिए chat, worksheet, और column lineage tracking जैसी सुविधाएँ dbt development में सचमुच game changer हैं। ऐसा लगता है कि ये फ़ीचर्स मेरे वास्तविक काम करने के तरीके के हिसाब से बहुत सोच-समझकर डिज़ाइन किए गए हैं। Claire और Christophe feedback पर तुरंत प्रतिक्रिया देते हैं और फ़ीचर्स को जल्दी जोड़ते व सुधारते हैं। प्रोडक्ट तेज़ी से सही दिशा में विकसित हो रहा है

  • अच्छे शब्दों के लिए धन्यवाद, और nao को बेहतर बनाने में मदद के लिए भी शुक्रिया

• यह काफ़ी आकर्षक लगता है। मैंने YouTube वीडियो कई बार देखा, और जिस तरह यह feedback cycle को छोटा करता है, वह बहुत प्रभावशाली लगा। सच में बहुत बढ़िया

  • धन्यवाद, हमारा लक्ष्य भी यही feedback loop को छोटा करना है। डेटा टीमों के feedback loops अक्सर software engineers की तुलना में लंबे होते हैं, इसलिए हम उन्हें कम करके डेटा को development flow के और करीब लाना चाहते हैं

• क्या यह सिर्फ़ raw SQL के साथ काम करता है? मेरे प्रोजेक्ट में Postgres + TypeScript के साथ Kysely जैसे query builder का उपयोग होता है, इसलिए जानना चाहता हूँ कि क्या मैं इसे अभी इस्तेमाल कर सकता हूँ

  • फिलहाल Tab raw SQL (शुद्ध SQL files या strings) के साथ सबसे अच्छा काम करता है। लेकिन chat/agent का इस्तेमाल करें तो आप बता सकते हैं कि आप Kysely उपयोग कर रहे हैं, और warehouse context देने पर यह कुछ हद तक उसे संभाल सकता है। Kysely का नाम मैं पहली बार सुन रहा हूँ, लेकिन प्रोजेक्ट का GIF देखकर autocomplete काफ़ी अच्छा लगा। यह tab approach से अलग है, लेकिन दिलचस्प है

• मैं जानना चाहता हूँ कि मेरा डेटा/प्रॉम्प्ट मॉडल तक कितना भेजा जाता है। मेरा schema तो ठीक है, लेकिन warehouse data आमतौर पर sensitive data होता है। शायद enterprise plan है, इसलिए पहले से जानना चाहता हूँ कि क्या वास्तविक code के अलावा data/results भी server पर भेजे जाते हैं, या सिर्फ़ code ही जाता है

  • डेटा की वास्तविक सामग्री तब तक मॉडल को नहीं भेजी जाती जब तक user उसे स्पष्ट रूप से अनुमति न दे। server पर सिर्फ़ codebase और data schema की embeddings स्टोर होती हैं। डेटा की सामग्री केवल user के कंप्यूटर पर लोकल रूप से एक्सेस की जाती है। जब agent query चलाता है, तो warehouse में उसे execute करने के बाद वह पहले approval मांगता है कि क्या result पढ़ा जा सकता है। अनुमति न मिलने पर वह LLM को नहीं भेजा जाता और लोकल में preview किया जा सकता है। enterprise version में prompts और context को सार्वजनिक LLM endpoints से अलग सुरक्षित रखा जा सकता है

• क्या कोई डेटा engineering और data science के लिए LLM-आधारित tools के लिंक सुझा सकता है?

  • मैं ऐसे LLM tools की list repository तैयार कर रहा हूँ, और जल्द ही इसे पूरा करने की योजना है

• इसमें जो फ़ीचर्स हैं वे पसंद आए। क्या आगे चलकर SQLite support जोड़ने की योजना है?

  • बिल्कुल, इसे जोड़ना बहुत मुश्किल नहीं होना चाहिए। अगली release में DuckDB भी आने वाला है, और SQLite भी जोड़ा जा सकता है। क्या आप SQLite का इस्तेमाल local development के लिए करते हैं?

• जब कई tables में FK/PK नहीं होते, तब transitive joins को कैसे handle किया जाता है? इसके अलावा, पहले से मौजूद inefficient queries के उपयोग विश्लेषण/rewriting की सुविधा भी killer feature हो सकती है

  • joins के मामले में, हम हर table के schema के साथ repository/query history में पहले इस्तेमाल किए गए join patterns भी मॉडल को देते हैं, ताकि वह relations infer करने में मदद पा सके। usage analysis भी निश्चित रूप से development roadmap में है; इसके लिए हम data warehouse logs तक पहुँच की योजना बना रहे हैं, ताकि हर table के वास्तविक उपयोग को मापा जा सके