Autocomplete that doesn't guess

Ask any coding assistant to write a transformation against your warehouse and watch the column names. You get customer_id when the table says cust_id, a join on a key that was renamed two quarters ago, and a date field that sounds plausible and is absent. The code looks right. It fails at runtime.

That is not a model quality problem. The model has never seen your schema, so it produces the most statistically likely column name for a table like yours. Sometimes it guesses correctly, which is worse, because that teaches you to trust it.

Version 9.7.11 added context-aware autocomplete to the code editors. It does not predict. It reads.

What it knows

Completion is driven by the actual context at your cursor:

• The language you are writing
• Where the cursor sits in the expression
• The fields available at that point in the flow
• Symbols you declared earlier in the script
• The functions and macros you are authorized to call
• The schema of the active database connection

The last two matter most. Authorization is part of the suggestion set, so you are never offered a function you cannot execute. Schema discovery runs in the background against the connected database, so tables, aliases, and columns come from the database rather than from a guess about what a table named orders probably contains.

Support is strongest in JavaScript, embedded Python, and SQL. SQL gains the most, since alias resolution and column lists save the most keystrokes and prevent the most typos.

Deterministic beats clever

A wrong suggestion costs more than no suggestion.

If the editor offers nothing, you look up the column name and lose fifteen seconds. If the editor offers a wrong column name that reads correctly, you accept it, and you find out during a scheduled run, possibly after it has written bad rows into a warehouse.

The design constraint was never "how smart can we make this." It was "never offer something that does not exist." That rules out generation and points at indexing, which is old, boring technology that works.

This is not the AI feature

Worth stating plainly, since everything gets labeled AI now. There is no model here. No inference call, no token cost, no dependency on a provider being reachable. It is metadata and a completion engine.

Simba, our AI agent, writing code for you is a different job and genuinely is AI. Ask it for a transformation and it produces one, using its access to your flow, your schemas, and your templates. The two work together in the obvious way: Simba writes the first draft, autocomplete keeps you accurate while you edit it.

The argument for why the useful intelligence in a data tool is frequently the part that is not a model is most of this post.