Snowflake Cortex Code: Hands-On Guide + Examples

Learn Snowflake Cortex Code through real examples. Step-by-step tutorial covering setup, prompts, and practical use cases for data engineers.

Nobody told me to do this.

No manager pinged me. No sprint ticket had “explore Cortex Code” written on it. I stumbled across it one evening while clicking around Snowsight after a long day of debugging dbt models, and three hours later I looked up and realized I hadn’t thought about Jira or Slack once.

That doesn’t happen to me.

I run this blog because I genuinely love poking around the parts of Snowflake that most people scroll past. Cortex Code is exactly that kind of thing — it’s been sitting quietly inside Snowsight, doing something remarkable, and I feel like almost nobody in the data engineering world is talking about it properly. So let’s fix that.

What Cortex Code Actually Is (And What It Is Not)

Before I go any further, I want to be really clear about something that tripped me up when I first read the Snowflake docs — and that I’ve seen cause confusion in the community too.

Cortex Code is not a SQL function you call.

It is not SELECT SNOWFLAKE.CORTEX.CODE_ASSIST(...). It doesn’t live in your query editor the way CORTEX.COMPLETE() or CORTEX.SENTIMENT() do. I wasted about 45 minutes trying to invoke it via SQL the first time, so I’m saving you that pain right now.

Cortex Code is a natural language interface built into Snowsight — Snowflake’s web UI. You access it by navigating to Snowsight, finding the Cortex Code section, uploading or referencing your files, and then literally just… talking to it in plain English. You describe what you want to do with your code or data files, and it responds. Think of it as having an AI pair programmer that lives inside your Snowflake environment, already understands your data context, and doesn’t need you to install anything.

This distinction matters a lot for how you think about using it in production versus exploration.

How to Actually Access Cortex Code in Snowsight

Here’s the step-by-step, because the docs skip over some of this:

Step 1: Log into Snowsight

Go to your Snowflake account URL and log in. Make sure you’re on an account that has Cortex features enabled — Enterprise edition or higher, with the right region support.

Step 2: Navigate to the Cortex Code Section

In the left sidebar, look for the AI/ML or Cortex section. This UI location has shifted slightly across Snowflake releases, so if you don’t see it immediately, use the search bar at the top of Snowsight and type “Cortex.”

Step 3: Upload Your Files Using a PUT Command

This is where it gets interesting. If you want Cortex Code to analyze a specific file — say a Python script, a dbt model, a JSON file, or a CSV — you first upload it to a Snowflake stage using a PUT command in a worksheet:

-- Create a stage if you don't have one
CREATE OR REPLACE STAGE my_cortex_stage;

-- Upload your file from your local machine
PUT file:///Users/yourname/projects/my_dbt_model.sql @my_cortex_stage;

-- Verify it landed
LIST @my_cortex_stage;

Step 4: Reference Your File in the Cortex Code Interface

Once staged, you can reference the file in the Cortex Code interface and start asking questions about it in plain English.

Step 5: Start Prompting

You don’t write SQL. You write sentences. That’s the whole point.

Real Example 1: Analyzing a dbt Model for Performance Issues

This is the first thing I tried, and it immediately earned its keep.

I had a dbt model — let’s call it fct_orders_daily.sql — that was consistently running for 14 minutes in production. I’d stared at it, I’d checked clustering, I’d looked at query profiles. I was going in circles.

I uploaded the file:

PUT file:///Users/bug/dbt_project/models/marts/fct_orders_daily.sql @my_cortex_stage;

Then in Cortex Code I typed something like:

“I’ve uploaded a dbt SQL model called fct_orders_daily.sql. It’s running for 14 minutes. Can you review the logic and tell me where the performance problems likely are? Suggest specific rewrites.”

What came back wasn’t a generic “add a WHERE clause” response. It identified a specific pattern I had — a correlated subquery inside a CASE statement that was executing per-row. It rewrote the logic using a LEFT JOIN with a pre-aggregated CTE instead. The rewrite took the query from 14 minutes to under 3 minutes when I tested it.

Did I feel a little embarrassed that an AI caught something I missed? Absolutely. Did I care? Not really. The model shipped.

Real Example 2: Explaining Someone Else’s Legacy Code

Every data engineer has that one Snowflake procedure. The one that nobody touches. The one with variable names like tmp_ctr2 and no comments anywhere. The one that was written by someone who left the company in 2021.

I had one of those. It was a stored procedure managing some SCD2 logic on a customer dimension table. About 200 lines. No documentation.

I staged the file:

PUT file:///Users/bug/legacy/sp_customer_dim_scd2.sql @my_cortex_stage;

Then in Cortex Code:

“This is a Snowflake stored procedure. Can you explain what it does step by step, in plain English? Then flag any parts that look fragile or risky.”

It produced a section-by-section breakdown that I turned directly into an internal wiki page. It also flagged that the procedure was doing a full table merge without any row count validation before and after — which, it noted, meant a failed intermediate step could silently produce a partial merge with no error thrown.

That was a legitimate production risk I had never noticed. I added the validation. Nobody told me to. I just did it because now I knew.

Real Example 3: Generating New Transformation Code from a Description

This one genuinely surprised me. I described a transformation I needed in plain language — no file, just a description — and asked Cortex Code to write the SQL.

My prompt was roughly:

“I have a table called SALES_EVENTS with columns: event_id, customer_id, event_type (values: ‘purchase’, ‘return’, ‘browse’), event_timestamp, and amount. I want to build a daily summary table that shows, for each customer and each day: total purchases, total returns, net revenue (purchases minus returns), and a flag if they had any browse events that didn’t convert to a purchase on the same day. Write me the Snowflake SQL for this.”

Here’s essentially what it produced (I’ve cleaned it up slightly for readability):

WITH daily_events AS (
    SELECT
        customer_id,
        DATE(event_timestamp) AS event_date,
        SUM(CASE WHEN event_type = 'purchase' THEN amount ELSE 0 END) AS total_purchases,
        SUM(CASE WHEN event_type = 'return' THEN amount ELSE 0 END) AS total_returns,
        SUM(CASE WHEN event_type = 'purchase' THEN amount ELSE 0 END) -
        SUM(CASE WHEN event_type = 'return' THEN amount ELSE 0 END) AS net_revenue,
        MAX(CASE WHEN event_type = 'browse' THEN 1 ELSE 0 END) AS had_browse,
        MAX(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) AS had_purchase
    FROM SALES_EVENTS
    GROUP BY customer_id, DATE(event_timestamp)
)

SELECT
    customer_id,
    event_date,
    total_purchases,
    total_returns,
    net_revenue,
    CASE 
        WHEN had_browse = 1 AND had_purchase = 0 THEN TRUE 
        ELSE FALSE 
    END AS browse_no_convert_flag
FROM daily_events
ORDER BY customer_id, event_date;

That’s clean, readable, and correct. It took maybe 30 seconds from my prompt to a working query. Normally I’d have spent 10-15 minutes writing and testing that from scratch.

Real Example 4: Reviewing Python Scripts for Data Quality Issues

I had a Python ingestion script that was pulling data from a REST API and writing to a Snowflake stage. I staged it:

PUT file:///Users/bug/scripts/api_ingest.py @my_cortex_stage;

My prompt: “Review this Python script. It ingests data from a REST API into a Snowflake stage. Are there any data quality risks, error handling gaps, or things that might fail silently in production?”

The response flagged three things:

No retry logic on the API call, so a transient network failure would abort the entire run with no retry
The script was casting all numeric fields as strings before writing to the stage, which would cause downstream type errors in the COPY INTO command
There was no check on API response status codes — a 429 (rate limit) or 500 was being handled the same way as a 200

All three were real issues. None of them were obvious from a quick read. Finding them manually would have required either running the thing and watching it fail, or very careful code review.

Where Cortex Code Fits in Your Daily Workflow

I want to be honest here: Cortex Code is not a replacement for knowing what you’re doing. If you give it a bad prompt, you’ll get a bad answer. If you blindly paste its output into production without reading it, eventually something will break and you’ll deserve it.

But used as a thinking partner — as a way to get a first draft, spot what you might have missed, or understand something unfamiliar faster — it’s genuinely useful in a way that saves real time.

Here’s how I’ve actually worked it into my day:

Morning code review pass: Before I open a PR for anything significant, I stage the file and run a quick “what could go wrong with this?” prompt. It takes 2 minutes and has caught things twice in the last month.

Legacy code archaeology: Any time I have to touch something old that I didn’t write, I stage it and ask for an explanation before I touch a single line. This alone is worth it.

First-draft SQL: When I have a new transformation to build and I know exactly what the output should look like but I’m not in the mood to write boilerplate aggregations, I describe the output and let Cortex Code give me a starting point. I always read and edit what it gives me — but starting from something is faster than starting from nothing.

Onboarding help: I’ve started pointing people who are new to the team at Cortex Code for understanding existing models. “Stage the file, ask it to explain it, then come ask me questions.” It makes onboarding conversations much more productive because they’ve already done some of the basic reading.

What It Can’t Do (And Where You Still Need to Think)

I don’t want this to sound like a Snowflake brochure. There are real limitations.

It doesn’t know your data. It can reason about code logic and SQL patterns, but it doesn’t have context about what’s actually in your tables — so it can’t tell you whether a join is correct because it doesn’t know your actual cardinality or data distribution.

Complex business logic still needs you. If your transformation encodes ten years of institutional knowledge about how a specific business process works, Cortex Code can write syntactically correct SQL but it can’t know if the business logic is right.

You have to read the output. Every time. No exceptions.

And the Snowsight UI for it, as of my exploration, is still evolving — some things feel a little rough around the edges. That’s fine. So did Cortex Analyst when it launched, and it’s much smoother now.

A Few Prompting Tips That Actually Help

After spending time with this, here’s what I’ve learned about getting better results:

Be specific about what you want back. “Review this code” is okay. “Review this code and give me three specific things to change, written as SQL snippets I can copy” is much better.

Tell it the context it’s missing. “This table has 2 billion rows and is clustered on event_date” is useful information that shapes the advice you’ll get.

Ask follow-up questions. If the first answer is good but you want to go deeper on one part, just ask. The interface supports back-and-forth.

Tell it what you’ve already tried. If you’ve already checked clustering and it didn’t help, say so. Otherwise it’ll suggest clustering.

Why I Think This Matters

I started this blog because I noticed that a lot of the Snowflake content online is either too shallow (“here’s what the feature is”) or too abstract (“here’s why AI in data warehouses matters”). What’s missing is the honest, practical, “here’s what I actually did and what happened” stuff.

Cortex Code is one of those features that I think is genuinely going to change how data engineers do their day-to-day work — not in a science fiction way, but in the quiet, unglamorous way where you just realize one day that you’re spending three hours less per week on the boring parts and three hours more on the interesting parts.

Nobody told me to learn this. I’m glad I did.

If you try it, tell me how it goes. I’m genuinely curious whether your experience matches mine.