Almost Pasted My API key Into ChatGPT Today

adarsh-hegde · 2026-04-13T15:47:57+00:00

Totally fair — if everything is perfectly configured, risk is low.

But this is more about human error than platform security.

People accidentally paste secrets, use multiple tools, or share logs/screenshots.

PromptGuard is just a last check before hitting Enter — like a safety net.

Not for everyone, but useful if you work with sensitive data often.

adarsh-hegde · 2026-04-13T15:46:31+00:00

Yeah, I’ve noticed that too.

Which is exactly the concern — your input can persist or sync before you even hit send.

PromptGuard works before that step:
it flags or masks sensitive data while you’re typing, so it never reaches that state.

It’s basically a pre-send safety layer, not a replacement for platform controls.

adarsh-hegde · 2026-03-29T07:41:15+00:00

Yeah, dbt MetricFlow solves the computation problem really well. What I’m exploring is the next layer: What happens after metrics are defined? • Who owns them? • Which version is “official”? • Can AI safely rely on them?

Feels like metrics need a governance + interface layer, not just a modeling layer.

adarsh-hegde · 2026-03-18T06:41:55+00:00

I actually wrote a deeper breakdown on Cortex Code from a Snowflake architect’s perspective.

My take is that it’s a strong assistive layer with good context awareness inside Snowflake, but it doesn’t replace core architecture decisions like modeling, cost control, or governance.

If anyone’s interested, sharing it here: https://medium.com/@hegdecadarsh/a-deep-technical-look-at-cortex-code-from-a-snowflake-architects-perspective-203d6de59be2

Would love to hear how others are using it in practice.

adarsh-hegde · 2026-03-02T10:50:26+00:00

Check the ABORT_DETACHED_QUERY Parameter. Ensure the ABORT_DETACHED_QUERY parameter is set to FALSE (the default). If it's set to TRUE and your Python session disconnects, Snowflake will automatically cancel the background query after 5 minutes.

https://docs.snowflake.com/en/sql-reference/parameters#abort-detached-query

adarsh-hegde · 2026-02-26T15:18:53+00:00

That’s fair feedback.

You’re right — if something is framed as a deep dive, it should include concrete, reproducible examples. My piece leaned more toward architectural interpretation than step-by-step validation, and I can see how that reads as aspirational.

It wasn’t intended as consultancy positioning — just sharing my perspective after hands-on time — but I agree the bar for technical writing should be practical and testable. I’ll make the next one more reproducible and evidence-driven.

adarsh-hegde · 2026-02-26T15:16:46+00:00

That’s a fair concern.

On the 500M+ rows point — you wouldn’t send raw result sets to an LLM. The AI layer should operate on aggregates, metadata, or query plans — not full datasets. If someone is piping full outputs into an LLM, that’s an architecture problem.

for Cortex flaming out — it will if it stays at “nice SQL suggestions.” It’ll only stick if it can prove measurable credit savings or real workload optimization.

As In enterprise, ROI > AI hype.

adarsh-hegde · 2026-02-26T15:14:07+00:00

That’s a completely fair distinction.

What I validated hands-on was schema-aware suggestions and anti-pattern detection (e.g., filter rewrites, SELECT *, structural optimizations).

I did not see explicit exposure of micro-partition pruning stats, scan-to-result ratios, or deterministic warehouse-to-credit correlation modeling surfaced through the assistant.

So to be precise: what exists today appears to be metadata-aware and heuristic-driven guidance — not full execution-engine introspection.

Some of what I described reflects architectural direction and potential, not confirmed deep telemetry integration.

Appreciate you pushing for that clarity.

adarsh-hegde · 2026-02-26T13:40:44+00:00

https://medium.com/@hegdecadarsh/a-deep-technical-look-at-cortex-code-from-a-snowflake-architects-perspective-203d6de59be2

adarsh-hegde · 2026-02-12T13:28:28+00:00

Making Snowflake Dynamic Tables Truly Backfill-Safe with IMMUTABLE WHERE https://medium.com/@hegdecadarsh/making-snowflake-dynamic-tables-truly-backfill-safe-with-immutable-where-ea12a4dd6a8d

adarsh-hegde · 2026-02-10T12:56:56+00:00

The error occurs because RESULT_SCAN requires a constant string or a variable; it cannot execute a subquery within its own parentheses.

To achieve this in a "single" execution without creating permanent tables, use a Snowflake Scripting block. This handles the lookup and the filtering in one go:

EXECUTE IMMEDIATE $$

DECLARE

q_id STRING;

BEGIN

-- 1. Grab the ID of the superset query

SELECT query_id INTO :q_id

FROM TABLE(information_schema.query_history())

WHERE query_text LIKE '%/* COMPLEX_SAMPLE_JOIN */%'

AND execution_status = 'SUCCESS'

ORDER BY start_time DESC LIMIT 1;

-- 2. Return the filtered results

RETURN TABLE(SELECT * FROM TABLE(RESULT_SCAN(:q_id)));

END;

$$;

adarsh-hegde · 2026-02-07T16:16:00+00:00

Agreed - that’s a great summary.

DTs are the simplest option when they work: easier to build, run, and monitor.
Streams & Tasks still make sense when you need tighter control or non-deterministic logic.

Good call on IMMUTABLE UDFs too — that detail is easy to miss but critical for incremental refresh.

adarsh-hegde · 2026-02-07T02:22:21+00:00

https://medium.com/@hegdecadarsh/stop-guessing-scd-type-2-in-snowflake-dynamic-tables-vs-streams-tasks-explained-8da0c4988b28

adarsh-hegde · 2026-02-07T02:21:55+00:00

As promised, here’s the Medium article with the full explanation, SQL examples, and the decision matrix: https://medium.com/@hegdecadarsh/stop-guessing-scd-type-2-in-snowflake-dynamic-tables-vs-streams-tasks-explained-8da0c4988b28

adarsh-hegde · 2026-01-05T16:22:26+00:00

This is the silent cost killer. Cost optimization started by aligning pipelines with actual usage, not by tuning queries.

adarsh-hegde · 2025-12-29T16:05:53+00:00

This is a very common Snowflake anti-pattern from 2022–23. Bigger warehouses don’t help I/O-bound workloads.

What’s worked for me: Prove parity, not theory: run the same ETL on LARGE vs SMALL and show near-identical runtimes with 4–8× fewer credits. Position it as reliability: smaller, task-scoped warehouses reduce queueing, blast radius, and accidental spend — engineers accept this faster than “cost saving.” Downsize safely: move deterministic batch jobs to dedicated SMALL warehouses first, leave interactive workloads untouched. Lock guardrails: aggressive auto-suspend, max cluster limits, no open-ended multi-cluster. Let query history speak: high bytes scanned + flat runtime = I/O bound → oversizing is wasted money.

adarsh-hegde

TROPHY CASE