Infrastructure-as-Intent: Bridging human creativity with AI precision to accelerate data value.
We ’ve spent years building automation pipelines to deploy infrastructure. We call it Infrastructure-as-Code (IaC) — whether that’s Terraform, Ansible, or even simple CLI scripts. It saves us from nightmares when we need consistency between where we develop and where we deploy. Development == Production.
But when Snowflake launched Cortex Code — an AI coding agent designed for the Data Cloud — it sparked a new thought for me: why can’t we take IaC automation into its next phase? Instead of declaring how to build everything step by step, what if we simply declared the outcome we want?
This idea wasn’t born out of nowhere. It came from my own attempts to modernize my scripts — snow-utils — a collection of utilities I built to repeatedly set up Snowflake environments for demos. They started as a way to eliminate the rinse-and-repeat plumbing work.
The scripts solved the plumbing problem. But they introduced a different one: remembering the right combination of parameters every single time.
That frustration led me to a deeper pattern — one that could fundamentally change how we interact with cloud environments, and one that fits naturally into this new AI-assisted era.
The “Field Velocity” Problem
So we found the problem, built a solution, and then refined it further — something that could take us into the next phase. But before we get there, let’s pause and ask: why does this even matter?
The answer is simple and universal: speed.
We invented computers to help us do things faster. But as computer science evolved, the systems we built became increasingly complex. Somewhere along the way, speed started fighting complexity.
That’s what I call the Field Velocity problem.
What is it exactly?
It’s the time it takes to go from a customer asking:
Can we query Snowflake-managed Iceberg tables from DuckDB?
to a working, deployed proof of concept.
If you look closely at the history of Infrastructure-as-Code, you’ll notice something consistent. The bottleneck is rarely the idea. It’s the plumbing.
So our customer’s question will translate into following tasks(plumbing):
Configuring IAM roles – > Editing trust policies – > Setting up buckets. – > Creating network rules – > DDL Statements.
If I put it mathematically, we spend 90% of our time on plumbing and only 10% on the actual value.
So the fix? Invert the ratio.
That inversion is what I call Infrastructure-as-Intent.
Same wine. New bottle. 😉
Field Velocity: Flipping the ratio with Infrastructure as Intent
The Evolution: From Power CLI to Atomic Primitives
I come from a strong Linux and infrastructure background, and I’m a die-hard CLI person. If something is repetitive, my instinct is to script it.
That “Power CLI” reflex is what led me to write snow-utils.
Let me explain with a simple example.
Say I want to connect Snowflake to an AWS S3 bucket. Sounds straightforward. In reality, it looks like this:
- Log into AWS Console → Create S3 bucket
- Create an IAM policy
- Create an IAM role and attach the policy
- Log into Snowflake → Create the EXTERNAL VOLUME
- Run DESCRIBE EXTERNAL VOLUME to hunt for AWS user ARN
- Go back to AWS → Edit the Trust Relationship JSON and paste those values
And yes — to err is human. But one small typo in that trust policy JSON, or grabbing the wrong property from the Snowflake DESCRIBE output, can cost you hours of debugging before everything finally works.
That’s when I decided to wrap this entire chain of interdependent steps into a single command.
Instead of manually wiring everything together, I created a primitive that understood the sequence.
Now, for the same task, it’s simply:
snow-utils extvolume:up
Done.
One clean shot. Goal scored.
Over time, it became deterministic. It worked every time — no manual hunting, no fragile copy-paste, no mysterious “Access Denied” errors.
That’s when I realized something important: these weren’t just scripts anymore. They were atomic primitives.
Deconstruction: Moving from brittle, monolithic scripts to composable, reusable primitives.
The Shift: From Operator to Mentor
Once I had the primitives working reliably, I started asking a new question: why can’t this be more intelligent?
Around that time, Snowflake announced Cortex Code. What caught my attention wasn’t just that it was an AI coding agent, but the concept of Skills — giving the agent structured capabilities to orchestrate tools and perform tasks in a more contextual way.
That’s when I saw the transition from Infrastructure-as-Code (IaC) to Infrastructure-as-Intent (IaI) taking shape.
Instead of keeping a mental checklist of parameters, flags, expiration rules, and policy combinations, why couldn’t I just express the intent and let the system handle the wiring?
“Set up a Snowflake External Volume.”
“Create a Snowflake PAT.”
It suddenly felt possible.
But this wasn’t just about making things simpler. It was about changing roles.
With IaC, I was the operator — running commands, supplying parameters, ensuring everything aligned.
With IaI, I started becoming the mentor.
I wasn’t just teaching syntax. I was embedding experience.
Years of small production scars. Lessons from silent authentication failures. The instinct to validate IAM structures before applying them. The habit of forcing a dry run before destructive changes. The discipline of demanding explicit confirmation when something could break environments.
That’s what I call codifying wisdom — capturing operational judgment and passing it into the system so it behaves the way I would.
Let’s not fear AI. It doesn’t invent wisdom on its own — it executes what we mentor it to do.
Intelligence still comes from somewhere.
Let me make this concrete.
Suppose I want to create a Snowflake Programmatic Access Token (PAT). Traditionally, that involves multiple careful steps: creating a service user, applying network restrictions, attaching the correct policies, defining expiration windows, and ensuring everything aligns securely.
Instead of remembering every option and edge case, I wrote a simple markdown file called SKILLS and embedded all the logic behind the PAT primitive into it — including the commands and my opinions about how it should be done safely.
Now all I need to tell Cortex Code is:
“Set me up a PAT that’s valid for 7 days and expires 30 days from now.”
That’s it.
No more remembering long chains of parameters. No wrappers around wrappers. No cognitive overhead.
What emerged was a composable architecture — where the logic (snow-utils) is unbundled from the interface (Cortex Code).
- The primitives remain solid.
- The skills carry the experience.
- The interface interprets intent.
That separation is what turns automation into intent.
The New Workflow: The Human defines the “Skill” (intent & guardrails), and the AI handles the execution.
The Pedagogical Pattern: Intentional Failure as a Feature
When I spoke about intent in the previous section, I didn’t just mean my intent to run a set of commands or automation scripts. I had another intent in mind as well.
Too many intents? I can already see an “Intent Overflow Exception” coming. 😉
Jokes apart — as a Power CLI user, clear intent helps me execute tasks efficiently. But a mentor does more than execute. A mentor creates situations where you apply your skills across related areas. A mentor shapes understanding.
As a Developer Advocate, I build demos, tutorials, and utilities like snow-utils. I usually share my GitHub repositories with a README explaining how to run the demo you just saw in my session.
That works.
But nothing matches personalized teaching — where the session leader’s experience, empathy, and small nuances surface naturally. The little warnings. The subtle explanations. The “watch this part carefully” moments.
That’s a classic pedagogical pattern.
Let me explain with the Horizontal Iceberg REST Catalog (HIRC) and DuckDB demo.
All you have to say now is:
“Deploy HIRC DuckDB demo.”
But the real power isn’t just in deploying the environment. It’s in how the Skill is structured.
I intentionally embedded a learning flow into it:
- Say what you are going to do
- Do it
- Let it fail
- Explain why it failed
- Fix it
- Show how it succeeds
That pattern is deliberate.
The goal isn’t just automation. It’s understanding.
That’s the human part — and that doesn’t emerge automatically. You have to mentor it into the system.
Now the Skill doesn’t just deploy infrastructure. It delivers a learning experience.
The “Recorder” Bonus: Intelligent & Interactive Reproduction
Context Adaptation: Transforming a manifest from “Works on my machine” (AWS) to “Works on your cloud” (Azure)
Since I’m documenting intent as a Skill, the natural next step was to share it.
That’s how we normally share knowledge — notes, blogs like this, repositories, configuration files.
So I asked myself: what if I wanted my product team to reproduce the exact same demo? Or reproduce a tricky bug?
In a classic IaC world, I would share a configuration file. The other person would clone the repo, pull it down, and then start adjusting dozens of environment settings — region values, parameter overrides, warehouse sizes, credentials — before they could even run it.
It works, but it assumes their environment matches mine.
Now think about how humans do this.
If I explain a setup to you, you don’t copy it blindly. You adapt it to your context. You change the region. You adjust the resource sizes. You map it to your naming conventions. You interpret the intent, not just the configuration.
That’s exactly what the IaI pattern enables with shared manifests.
When I share a manifest, I’m not just sharing a file. I’m sharing intent.
That intent can then be materialized in your environment — with adaptation.
Same architectural goal. Different context.
This isn’t blind automation like traditional IaC. It’s careful intent materialization.
And that difference is subtle — but important.
The Future: The Velocity Catalog
What we’ve discussed so far is not just another pattern or a personal experiment. It’s a mental shift we need to make in this AI era.
snow-utils is simply an example of how this shift took shape for me. The same idea can apply to any tool or script.
The real opportunity is this: we need to mentor AI to think and act the way we would — embedding our experience, judgment, and operational discipline into it.
Maybe that’s the next step for us: inject intent into DevOps.
Resources
The HIRC demo is just one example. Here is the 4-minute time-lapse demo that shows how this pattern works:
The same pattern applies across workloads. In the demo repository, I’ve also included the AI Smart Crowd Counter.
All you have to say is:
“Deploy AI Smart Crowd Counter.”
The underlying primitives remain the same. The intent changes.
One moment you’re setting up a data catalog. The next, you’re provisioning a Streamlit app and an image-processing pipeline.
Same intent model. Different outcome.
That’s the leverage.
If you’re experimenting with AI agents in your DevOps workflows, start by stabilizing your primitives. Once they’re solid, you can begin layering Skills on top of them.
And from there, you can build your own Velocity Catalog.
For reference, the underlying orchestration layer used here is Snowflake Cortex Code:
👉 Snowflake Cortex Code CLI Documentation
Visuals note: The conceptual diagrams in this post were generated by Google Gemini.
About the Author
Kamesh Sampath is a Lead Developer Advocate at Snowflake, author, and long-time open-source contributor with 25+ years in enterprise software. He works across data engineering and AI with developer communities, helping practitioners turn modern data platforms into systems that hold up in production.
Through talks, writing, and hands-on demos, Kamesh makes cloud, data, and AI topics easier to understand and apply — grounded in real-world constraints. His sessions mix deep technical detail with practical patterns that developers and data teams can apply right away.
Lately, he’s been speaking about Apache NiFi (Snowflake Openflow), AI (Snowflake Cortex), and PostgreSQL.
He believes technology becomes powerful when it is shared, taught, and built together.
Top comments (0)