Nao - Cursor para datos

• Un editor de código con IA basado en VS Code, especializado en trabajo con datos, que se conecta directamente a BigQuery/Snowflake/Postgres y ofrece generación automática de código ajustada al esquema de datos y controles de calidad
• Mientras que las herramientas existentes basadas en LLM autocompletan SQL sin reconocer el esquema de datos, Nao genera código preciso en SQL/Python/YAML mediante una pestaña de IA basada en RAG y herramientas de agente
• Permite escribir, ejecutar y visualizar pipelines SQL en una sola interfaz
• También admite pipelines Python en el mismo entorno, y es compatible con flujos de trabajo de dbt
• Permite ver de un vistazo las diferencias en los datos resultantes antes y después de cambios en el código y problemas de calidad de datos, para desplegar rápido sin pruebas o evitar errores
• Principales usos
  • Construcción de pipelines de datos (SQL, dbt, etc.)
  • Detección de faltantes/duplicados/valores atípicos
  • Comparación de datos de desarrollo vs. producción
  • Ejecución y resumen de pruebas predefinidas
• Se integra con dbt, herramientas de BI y data warehouses, ofreciendo un entorno IDE adecuado para ingenieros de datos, analistas y científicos de datos
• Compatible con BigQuery, Snowflake y Postgres; próximamente con Databricks, Iceberg y Redshift
• También se integrará con Looker, Power BI, Metabase y Tableau
• Por ahora solo está disponible la versión para Mac; Windows y Linux llegarán más adelante
• Diferencias frente a Cursor y los MCPs
  • Cursor necesita varias llamadas a MCP para obtener contexto de datos; Nao lo tiene siempre disponible en un solo RAG
  • Los MCPs solo funcionan de forma limitada dentro de Cursor y tienen menor adaptabilidad de UI
  • Nao viene preempaquetado, así que no requiere configuración, instalación de extensiones, autenticación ni armado de CI/CD; su fortaleza es mejorar la experiencia de desarrollo incluso para no especialistas

Preguntas frecuentes

• ¿Quién debería usar Nao?
  • Redactores de SQL, analistas de ingeniería en dbt, científicos de datos, ingenieros de datos y, en general, todos los integrantes de un equipo de datos
• ¿En qué se diferencia de Cursor?
  • Es un IDE optimizado para el contexto de datos, con generación de código basada en reconocimiento de esquemas de datos, controles automáticos de calidad de datos y predicción del impacto de cambios
• ¿Qué lenguajes soporta?
  • Soporta todos los lenguajes, pero está especialmente optimizado para SQL
• ¿Cómo ayuda en los flujos de trabajo de dbt?
  • Entiende modelos, fuentes, documentación, pruebas y lineage a nivel de columna de dbt, y ofrece autocompletado y visualización
• ¿Qué hay de la seguridad de los datos?
  • Los datos solo se procesan localmente y se solicita autorización del usuario antes de enviarlos al LLM
  • No se almacenan ni el código ni los esquemas; solo se usan embeddings

[GN⁺]

Comentarios en Hacker News

• Señalan que muchos proyectos de datos basados en LLM ofrecen flexibilidad y ayuda, pero son difíciles de repetir y les falta interactividad; consideran que Nao implementó bien ese concepto. Buckaroo, que hice yo, es una UI de tablas de datos para Jupyter y Pandas/Polars, con la que puedes ver de inmediato los datos con tablas actualizadas, histogramas y estadísticas resumidas. Ayer lancé una función de auto-limpieza en Buckaroo, que elige heurísticamente cómo limpiar los datos y entrega el código ya definido. Presume una velocidad muy rápida, de menos de 500 ms. Se pueden probar varias estrategias de limpieza y elegir la más adecuada. Para problemas simples, ni siquiera hace falta pasar por un LLM. Es open source y tiene una gran capacidad de expansión

  • Yo también estoy desarrollando algo muy parecido. Todavía no está tan pulido como Buckaroo, pero creo que una app embebida dentro del notebook resulta bastante útil

  • Me gusta mucho la vista para visualizar el perfilado de datos. Me parece una pieza clave para entender los datos

• Me parece una idea muy buena. Tengo curiosidad por cómo entrenaron el modelo de Tab, si fue con Fill in the middle o con base en edit history. Ayer alguien compartió una entrada de blog parecida sobre el autocompletado con Tab de Cursor, y la leí con mucho interés

  • Nosotros usamos un modelo Fill in the middle (modelos propios entrenados sobre Mistral y Qwen), junto con el contexto de datos del usuario. También usamos nuestro propio parser de SQL para proporcionar el contexto de esquema adecuado según la posición del cursor

• Después de usarlo durante varias semanas, siento que de verdad hubo una gran mejora en mi flujo de trabajo. Terminé eligiéndolo más de la mitad de las veces en lugar de VSCode y sus extensiones. El chat para análisis exploratorio de datos, las hojas de trabajo y la función de rastreo de linaje de columnas cambian por completo el juego para desarrollo con dbt. Da la impresión de que estas funciones fueron diseñadas con mucho detalle para ajustarse a mi forma real de trabajar. Claire y Christophe además responden de inmediato al feedback, y agregan o corrigen funciones muy rápido. El producto está evolucionando rápido en la dirección correcta

  • Gracias por tus palabras, y también por ayudar a mejorar nao

• Me parece realmente atractivo. Vi el video de YouTube varias veces, y me impresionó mucho cómo acorta el ciclo de feedback. Muy genial

  • Gracias; justo ese acortamiento del ciclo de feedback es nuestro objetivo. Los equipos de datos tienden a tener ciclos de feedback más largos que los ingenieros de software, así que estamos tratando de reducir eso para acercar más los datos al flujo de desarrollo

• Me pregunto si esto solo funciona cuando usas raw SQL. En mi proyecto hago consultas en Postgres + TypeScript con un query builder como Kysely, así que me gustaría saber si podría usarlo ahora mismo

  • Por ahora, Tab funciona mejor con raw SQL (archivos SQL puros o strings). Pero si usas chat/agent, puedes decirle que estás usando Kysely y pasarle el contexto del warehouse, y hasta cierto punto puede manejarlo. No conocía Kysely, pero al ver el GIF de presentación del proyecto, su autocompletado se ve bastante bien. Es distinto al enfoque de Tab, pero interesante

• Me pregunto cuánto de mis datos/prompts se le envía al modelo. Mi esquema no me preocupa tanto, pero los datos del warehouse suelen ser datos sensibles. Supongo que tienen un plan enterprise, pero quiero saber de antemano si se envían al servidor datos/resultados además del código real, o si solo se envía el código

  • El contenido de los datos en sí no se envía al modelo a menos que el usuario lo permita explícitamente. En el servidor solo se almacenan embeddings del codebase y del esquema de datos. El contenido de los datos solo se accede localmente en la computadora del usuario. Cuando el agent ejecuta una consulta en el warehouse, primero solicita aprobación para poder leer el resultado. Si no se permite, no se envía al LLM y puede previsualizarse localmente. Si usas la versión enterprise, los prompts y el contexto pueden quedar protegidos por separado sin pasar por endpoints públicos de LLM

• ¿Alguien quiere recomendaciones de enlaces a herramientas basadas en LLM para ingeniería de datos y ciencia de datos?

  • Estoy armando un repositorio con una lista de este tipo de herramientas LLM, y planeo terminarlo pronto

• Me gustan las funciones que tiene. ¿Planean agregar soporte para SQLite más adelante?

  • Claro. Parece que podría agregarse sin mucha dificultad. En el próximo release también entra DuckDB, y SQLite igualmente se puede añadir. Me da curiosidad si usas SQLite por desarrollo local

• Tengo curiosidad por cómo manejan los joins transitivos entre varias tablas cuando no hay FK/PK. Además de eso, creo que analizar el uso y reescribir consultas ineficientes que ya existen también sería una función matadora

  • Para los joins, le damos al modelo el esquema de cada tabla y también las formas de join ya usadas en el repositorio/historial de consultas para ayudarle a inferir relaciones. El análisis de uso también está claramente en la hoja de ruta de desarrollo; planeamos acceder a los logs del data warehouse para medir el uso real de cada tabla