DEV Community: Mohammad Tejabwala

Sloth Migrate

Mohammad Tejabwala — Mon, 26 Oct 2026 06:59:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

Remember the critical PHP vulnerability discovered just recently that sent shockwaves through thousands of legacy servers worldwide? It exposed a brutal reality that every engineering team knows but rarely admits: nobody runs outdated, vulnerable software because they want to—they do it because major dependency upgrades are terrifying.

When foundational libraries release breaking architectural shifts (such as Pydantic v1 to v2, SQLAlchemy 1.4 to 2.0, or major framework redesigns), breaking changes ripple across hundreds of files. Upgrading a manifest constraint breaks your build; fixing one deprecation cascades into three new runtime exceptions. Teams procrastinate for months—or years—until an active zero-day turns tech debt into an urgent fire.

That sparked an idea: What if an agent took on the dirty work of dependency migrations, but operated under strict engineering discipline? Instead of rushing to overwrite files, what if it worked slowly, methodically, and durably?

Meet SlothMigrate.

What I Built

SlothMigrate is an autonomous, self-healing dependency migration engine designed to safely upgrade Python projects across major breaking revisions.

Rather than treating code migration as an unconstrained text generation task, SlothMigrate implements a closed-loop verification pipeline:

Manifest Inspection & Resolution: Automatically parses pyproject.toml (PEP 621 & Poetry) and requirements.txt, resolves latest stable releases via PyPI, and safely bumps version constraints.
Deterministic Sandbox Test Harness: Executes local unit tests (pytest) with deprecation escalation flags (-W error::DeprecationWarning), capturing exact failure traces.
Targeted AST Patching: Parses the test traceback to isolate the failing file, line number, and deprecation error, prompting an open-weight model with isolated context to draft a surgical modernization patch.
Pre-Disk AST Compiler Guard: Runs Python's native ast.parse over generated code in-memory. If an LLM hallucinates markdown commentary, drops parentheses, or breaks indentation, the patch is blocked before touching the filesystem.
Stateful Self-Healing: Repeats the test-diagnose-patch cycle until all tests turn green, then renders clean unified diffs for developer review.

Why It's Useful & How It Helps Developers

Manual major migrations are cognitively exhausting and prone to human error:

Eliminates Manual Pattern Replacement: Upgrades like Pydantic v1 to v2 require converting @validator to @field_validator, injecting @classmethod, updating signatures, and replacing .dict() with .model_dump(). SlothMigrate automates these repetitive syntax updates.
Guarantees Zero Broken Commits: Because changes are gated by both compiler-level AST verification and automated test execution, the engine never leaves a repository in a half-broken state.
Reduces Security Lag Time: By turning days of high-friction manual refactoring into a self-executing background routine, open-source maintainers and enterprise teams can eliminate legacy CVE exposure without burning engineering sprints.

Demo

Here is SlothMigrate executing a complete, multi-pass durable migration on a legacy Pydantic project:

Agent session recording

Because this was built using the Gemini application rather than any agents, it's ineligible for the post.

Code

The complete source code is open-source under the MIT license:

Mohammadtej / Sloth-Migrate

SlothMigrate 🦥⚡

Autonomous, Durable Dependency Migration Agent powered by Google Gemma, Temporal, and Sentry.

📖 Overview

Upgrading breaking major dependencies (such as Pydantic v1 → v2, SQLAlchemy 1.4 → 2.0, or modern typing conventions) is often avoided by development teams. Simple regex replacements fail to capture schema semantics, and large-language-model coding tools frequently hallucinate, strip critical classes, or generate invalid syntax.

SlothMigrate transforms breaking dependency upgrades into a deterministic, fault-tolerant self-healing loop:

Detects & Bumps: Inspects pyproject.toml (PEP 621 / Poetry) and requirements.txt, updates version constraints, and synchronizes the virtual environment.
Executes Test Suite: Runs pytest with -W error::DeprecationWarning to escalate deprecated APIs into actionable errors.
Pinpoints Exact Failures: Parses Python tracebacks to extract the exact target file, line number, and error message across platforms (Windows, Linux, macOS).
Targeted Gemma Refactoring: Leverages Google's gemma-4-26b-a4b-it with an engineering-focused prompt enforcing zero code truncation and strict public API preservation.
AST…

View on GitHub

Key Architecture Components

src/sloth_migrate/ast_guard.py: In-memory Python AST validator that blocks malformed LLM outputs.
src/sloth_migrate/workflows/migration_workflow.py: Temporal state machine managing durable iterations, retry budgets, and state recovery.
src/sloth_migrate/workflows/activities.py: Atomic activities for dependency bumping, test execution, and LLM code refactoring.
src/sloth_migrate/telemetry.py: Custom Sentry spans tracking agent transactions, token consumption, and execution waterfalls.
src/sloth_migrate/ecosystems/python_ecosystem.py: Traceback analyzer isolating file paths, exact line numbers, and deprecation classes.

How I Built It

SlothMigrate bridges deterministic developer tooling with probabilistic AI generation through a defensive architecture:

┌────────────────────────────────────────────────────────┐
│                   CLI / Typer Engine                   │
└───────────────────────────┬────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────┐
│         Temporal Durable Workflow Orchestration         │
│  ┌────────────────────┐          ┌──────────────────┐  │
│  │ bump_and_install   │ ───────► │    run_tests     │  │
│  └────────────────────┘          └─────────┬────────┘  │
│                                            │           │
│                           [Failing Tests]  ▼           │
│                         ┌───────────────────────────┐  │
│                         │ generate_and_apply_patch  │  │
│                         └─────────────┬─────────────┘  │
└───────────────────────────────────────┼────────────────┘
                                        │
           ┌────────────────────────────┴───────────────────────────┐
           ▼                                                        ▼
┌──────────────────────┐                                 ┌──────────────────────┐
│  Google Gemma Model  │                                 │   AST Syntax Guard   │
│ (gemma-4-26b-a4b-it) │ ───────► Raw Code Patch ──────► │     (ast.parse)      │
└──────────────────────┘                                 └──────────┬───────────┘
                                                                    │
                                                            [Valid] ▼
                                                         Target Codebase

Deterministic Failure Isolation

Instead of passing an entire codebase or large terminal dumps into an LLM context, PythonEcosystem.parse_traceback parses pytest stdout/stderr using strict regular expressions to isolate:

The exact repository-internal file requiring attention (filtering out external virtual environment frames).
The exact offending line number.
The specific deprecation or exception class (PydanticDeprecatedSince20).

The AST Compiler Guard

Before any model-generated code is permitted to touch the target filesystem, it must pass through Python's native syntax compiler:

def validate_python_code(code: str, filename: str = "<generated>") -> ASTValidationResult:
    try:
        tree = ast.parse(code, filename=filename)
        return ASTValidationResult(is_valid=True, ast_tree=tree)
    except SyntaxError as e:
        return ASTValidationResult(is_valid=False, error_message=f"SyntaxError at line {e.lineno}: {e.msg}")

If the model introduces bad indentation, unclosed delimiters, or partial code blocks, the patch is rejected in-memory, preserving the integrity of the target repository.

Why Does Open Innovation Matter?

Open innovation is essential for developer infrastructure and automated tooling:

Codebase Privacy & Data Sovereignty: Proprietary enterprise code cannot always be transmitted to closed SaaS APIs. Open-weight models like Gemma allow migration engines to execute within local boundaries, on-premises servers, or private VPCs without exposing proprietary IP.
Deterministic Architecture Over Closed Magic: Closed APIs frequently alter models and prompt behaviors without notice. Open architectures provide reproducible results, predictable token performance, and deterministic stability.
Extensibility & Community Collaboration: Open-source projects thrive when specialized tools can be composed together. SlothMigrate unites community standards (pytest, ast, temporalio, sentry-sdk, typer) into an integrated developer tool.

The Lazy Payoff

During testing on legacy projects:

The Manual Baseline: Upgrading a real Pydantic v1 service manually requires reading migration documentation, hunting down deprecated class validators across multiple files, altering method signatures, inserting @classmethod annotations, rewriting serialization calls, and iteratively debugging test suites. This typically consumes several hours to multiple days of developer time.
With SlothMigrate: The entire cycle—from manifest bump to green pytest run—completed autonomously in under 90 seconds across 2 iterations.

Developers can kick off a migration, step away from their desk, and return to an AST-verified codebase with green tests and clear diffs.

Prize Categories

Featured Categories

🏆 Best Use of Gemma

How Gemma Was Used: We integrated Google's open-weight Gemma model (gemma-4-26b-a4b-it) via Google AI Studio as the core reasoning engine for syntax and architectural modernization.
Implementation Details: Instead of generic code generation, Gemma was deployed as a surgical refactoring agent. We constructed targeted prompts containing the isolated pytest traceback, the exact line number, the runtime deprecation warning, and the source file. Gemma ingested legacy Pydantic v1 syntax and reliably produced v2 implementations, correctly replacing @validator with @field_validator, injecting required @classmethod decorators, and updating .dict() to .model_dump().
Impact: Gemma demonstrated high adherence to strict system instructions, consistently emitting clean Python without conversational filler, allowing our AST parser to validate and write the patches directly.

Partner Categories

🛡️ Best Use of Temporal

Making the Migration Agent Durable: AI agents operating on developer repositories are inherently multi-step and prone to external failures—LLM rate limits, network timeouts during PyPI package downloads, or interrupted terminal sessions. We wrapped SlothMigrate's entire self-healing loop in a durable Temporal Workflow (DependencyMigrationWorkflow).
Workflow Architecture:
- Activity 1 (bump_and_install_activity): Modifies manifests and installs updated packages into the sandbox, configured with exponential retry policies.
- Activity 2 (run_tests_activity): Executes pytest in an isolated process and extracts failure points.
- Activity 3 (generate_and_apply_patch_activity): Invokes Gemma, validates syntax against the AST guard, calculates unified diffs, and writes patches to disk.
Fault Tolerance in Practice: If an activity experiences an API blip or network dropout, Temporal's retry policy automatically intervenes without restarting the entire migration from scratch. If the machine terminates mid-run, the workflow preserves state and resumes from the exact activity boundary.
Observability: Maintainers can open the Temporal Web UI (http://localhost:8233) to inspect live state transitions, execution timelines, retry counts, and payloads.

🔍 Best Use of Sentry Agent Tracing

Instrumenting Agent Telemetry: To understand agent latency, token costs, and internal debugging loops, we instrumented SlothMigrate with the Sentry SDK (sentry-sdk[tracing]) using custom spans across every lifecycle phase.
Custom Spans Monitored:
- manifest.bump: Tracking manifest file reads and regex rewrite duration.
- pip.install: Measuring sandbox package installation latency.
- pytest.run: Capturing test execution runtime and return codes.
- gemma.generate_fix: Recording LLM round-trip latency, prompt size, response size, and token usage.
- ast.validate: Tracking in-memory compilation overhead and recording syntax errors as tagged Sentry events.
Debugging with Tracing Waterfalls: During development, Sentry traces exposed where the agent spent the majority of its time (compilation vs. LLM inference) and allowed us to immediately catch rejected AST patterns before they touched disk.

Clone and enter SlothMigrate

git clone https://github.com/Mohammadtej/Sloth-Migrate
cd SlothMigrate

Set up environment

python -m venv .venv
source .venv/bin/activate # or .venv\Scripts\activate on Windows
pip install -e .

Set your API keys

export GEMMA_API_KEY="your-google-ai-studio-key"
export SENTRY_DSN="your-sentry-dsn"

Run against the included demo repository

sloth-migrate run --path demo_pydantic_repo --package pydantic --version 2.14.1

Screenshots

Thank you for reading this far!

NeoNomad🛳️ - Cross-border tax residency & PE Risk Arbiter

Mohammad Tejabwala — Mon, 05 Oct 2026 06:57:24 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

Introduction

All hands on deck! Welcome to the NeoNomad!

This is my second time participating in a hackathon (and also my second post :D), and I am still shocked that I made it in my first try. After winning the prize, the one thing that hit me was getting the prize amount in my resident country. I had to fill out a W-8BEN to avoid double taxation, read the laws in my host country, and had to handle filing for the tax on the "income" generated. So, overall, a big headache. Which leads me to this: NeoNomad (Neo referring to Captain Nemo and Nomad meaning travelling from place to place), Cross-Border Tax Residency & PE Risk Arbiter.

Now, those are some heavy words; let us understand them in simpler terms:

The Persona: Meet Rohan

Imagine a software engineer named Rohan:

Home Base: Rohan is an Indian citizen and tax resident living in India.
The Employer: He works remotely as a Principal Solutions Architect for a high-growth tech company based in Germany.
The Plan: He decides to do a winter detox and work remotely from a beach apartment in Valencia, Spain, for 128 days (straddling October through February).

To Rohan, the setup seems straightforward:

"I'm only staying four months, well below the famous 183-day limit. I'm paying my regular taxes in India, and my employer is a German company with no presence in Spain. Why would this cause any tax issues?"

However, behind that simple intuition lies a hidden cross-border trap where three jurisdictions and their tax laws collide simultaneously.

In reality, three distinct legal frameworks collide simultaneously:

Spain's Unilateral Domestic Tax Law (LIRPF & IRNR):
- Under domestic Spanish personal income tax (Ley 35/2006 LIRPF Art. 9.1(a)), tax residency requires strictly more than 183 days within a single calendar year. Because Rohan's 128-day stay straddles two tax years (78 days in 2026, 50 days in 2027), he does not trigger statutory domestic tax residency.
- However, under Spain's Non-Resident Income Tax Act (IRNR Art. 13.1(c)), Spain asserts strict territoriality: any labor physically conducted on Spanish soil is deemed Spanish-source income, taxable immediately from Day 1 at a 24% non-resident rate, regardless of where the employer is incorporated.
International Treaty Supremacy (India–Spain DTAA Article 15):
- Rohan is an Indian tax resident, so his personal income tax relief is governed by the India–Spain Double Taxation Avoidance Agreement.
- Under Article 15(2), host-country taxation is displaced if:
  - The individual is present for <= 183 days in a rolling 12-month period,
  - The employer is not resident in Spain (the German company satisfies this), and
  - The remuneration is not borne by a Spanish permanent establishment.
- Under Article 96 of the Spanish Constitution, ratified international treaties supersede domestic legislation, legally nullifying Spain's domestic Day-1 IRNR claim.
Corporate Permanent Establishment Exposure (Germany–Spain DTAA Article 5):
- Even though Rohan's personal income is shielded by the India–Spain treaty, his employer's corporate exposure is governed by an entirely different instrument: the Germany–Spain DTAA.
- Because Rohan scopes custom architectures and negotiates commercial Statement of Work (SOW) terms on the ground with European automotive accounts, the German company faces a high risk of triggering a Dependent Agent Permanent Establishment (DAPE) under Article 5(5). Digital DocuSign execution back in Germany does not eliminate this liability under modern OECD rules.

This brings us to the Sanity MCP context and Knowledge bases:

What I built:

Sanity is basically a smart data store, I would say, with relationships clearly defined between entities without any conflicts or duplication.

An agent is only as good as the knowledge it can find

So, what I built was the initial schema containing the jurisdication: containing information about the independent country and the bilateral treaties between these independent countries.

Providing the schema outline here:

Example 1: India–Spain DTAA (treaty-in-es)

JSON

{
  "_id": "treaty-in-es",
  "_type": "bilateralTreaty",
  "title": "Convention Between the Republic of India and the Kingdom of Spain for the Avoidance of Double Taxation",
  "signatoryA": {
    "_type": "reference",
    "_ref": "jurisdiction-in"
  },
  "signatoryB": {
    "_type": "reference",
    "_ref": "jurisdiction-es"
  },
  "article15Terms": {
    "exemptionDayLimit": 183,
    "countingPeriod": "rolling_12_months",
    "conditions": [
      "Recipient is present in the host state for <= 183 days in any 12-month period commencing or ending in the fiscal year concerned",
      "Remuneration is paid by, or on behalf of, an employer who is not a resident of the host state",
      "Remuneration is not borne by a permanent establishment or fixed base which the employer has in the host state"
    ]
  },
  "legalHierarchyStatus": "supersedes_domestic",
  "sourceTreatyUrl": "https://www.incometaxindia.gov.in/DTAA/Spain.pdf"
}

Example 2: Indian jurisdiction

JSON

{
  "_id": "jurisdiction-in",
  "_type": "jurisdiction",
  "name": "India",
  "code": "IN",
  "taxYearCycle": "fiscal_year_apr_mar",
  "domesticResidencyRule": {
    "statutoryAct": "Income-tax Act, Section 6(1) (Residential Status) & Section 5/9 (Scope of Total Income)",
    "daysLimit": 182,
    "comparisonOperator": "greater_than_or_equal",
    "windowType": "fiscal_year",
    "territorialSourceRule": "An individual is a tax resident if present in India for >= 182 days during the financial year (1 April to 31 March), or >= 60 days if present for >= 365 days across the preceding 4 financial years. Residents and Ordinarily Residents (ROR) are subject to tax on worldwide income, while non-residents are taxed exclusively on income accrued, arising, or received in India under Section 5 and Section 9."
  }
}

Sanity supports initial context out of the box, so when we built a database, it can use the GROQ mode to query the data at request time. But, this does not solve the fundamental problem with the RAG model that we just discussed, we need to ensure that there are no conflicts involved with the data that we are seeding and if there are, we need to specify which takes priority.

So, it was decided to move with Knowledge Bases which can process the data that we ingested first. It serves an index built from the data source that we provided, flags the conflicts found when builting that index, and with human-intervention it can be resolved, before the query stage even begins. This is especially usefull against law documents which can be often found conflicting. For example, here in our schema, we introduced a field in the bilateral treaty: legalHierarchyStatus which can indicate whether the treaty overrides domestic laws or it is subject to domestic GAAR (General Anti-Avoidance Rule) override

How I Used Sanity:

This would be a technical section, making some repeat over the intuition behind the earlier section, but please bear with me:

How I Used Sanity

1. Modeling Structured Legal Relationships in the Content Lake

Instead of treating legal tax codes and treaties as unstructured markdown chunks or raw PDFs, I modeled them in the Sanity Content Lake using two custom schema types:

jurisdiction: Stores domestic tax rules, residency day-count thresholds (daysLimit), statutory comparison operators (greater_than), and tax year cycle boundaries (such as Spain's calendar year vs. India's fiscal year).
bilateralTreaty: Models international tax treaties as directed graph relationships between two signatory jurisdictions (signatoryA and signatoryB), specifying Article 15 exemption conditions, counting windows (e.g., rolling 12-month periods), and statutory hierarchy status (supersedes_domestic).

2. Pointing Sanity Context to Build the Knowledge Base

To compile the Knowledge Base, I pointed Sanity Context directly at the Content Lake dataset via a GROQ-scoped source.

During the compilation build:

Topic Synthesis & Entry Compilation: Sanity Context transformed the discrete relational documents into synthesized topic entries (such as residency/domestic_rules, dtaa/article_15, dtaa/treaty_inventory, and pe_risk).
Issue Detection & Standing Instructions: When compiling conflicting legal sources—specifically Spain's domestic territorial rule claiming Day-1 tax rights under IRNR Art. 13.1(c) versus bilateral treaty exemptions—Sanity Context surfaced a critical conflict in the Issues tab. I resolved this issue with a standing instruction: international bilateral treaties (DTAAs) supersede domestic statutory territorial taxes under Article 96 of the Spanish Constitution. This decision survived compiler rebuilds and permanently aligned all synthesized entries.

3. Exposing Tools via Sanity Context MCP

I configured a hosted Model Context Protocol (MCP) server endpoint in Sanity Manage operating in Knowledge Base mode, providing the AI agent in the Antigravity IDE with access to core retrieval tools:

initial_context: Called at the beginning of the arbitration session to inspect the Knowledge Base ID (kbMH6TgNzIIz) and discover the topic outline with its [core] path tags.
knowledge_base_search: Used to perform keyword-based exploration across compiled paths when mapping cross-border treaty provisions.
knowledge_base_read: Used to batch-read authoritative, fully cited entry paths (such as residency/domestic_rules, dtaa/article_15, and pe_risk) in a single network round-trip.

4. What the Agent Did With the Retrieved Content

When presented with the triangular case (an Indian resident employed by a German GmbH working remotely in Spain), the agent executed deterministic multi-jurisdiction arbitration:

Evaluated Domestic Residency: Read residency/domestic_rules to calculate that the employee's 128-day stay split across two calendar years (78 days in 2026, 50 days in 2027) did not breach Spain's $>183$-day statutory residency threshold under LIRPF Art. 9.1(a).
Resolved Treaty Supremacy: Read dtaa/article_15 and applied the standing instruction to override Spain's domestic Day-1 IRNR 24% withholding rule, granting a 100% personal income tax exemption under the India–Spain DTAA.
Attributed Corporate PE Risk: Rather than conflating the employee's personal tax status with corporate enterprise exposure, the agent traversed to pe_risk and evaluated the German employer under the Germany–Spain DTAA (Article 5). Because the employee engaged in on-the-ground commercial Statement of Work negotiations, the agent flagged a High Dependent Agent Permanent Establishment (DAPE) risk for the German GmbH.

Demo

Check out the demo at YouTube

Code

Check out the project on GitHub.

Sanity Project Details

Sanity Project ID: 1vdo75k2
Dataset: production (Public)
Public Content Lake Query URL: [https://1vdo75k2.api.sanity.io/v2026-09-18/data/query/production?query=*[_type%20in%20[%22jurisdiction%22,%20%22bilateralTreaty%22]]]

Thanks,
MT

SqlGo🌱 - Save CO2 by optimizing queries and removing redundant storage

Mohammad Tejabwala — Mon, 20 Apr 2026 04:59:29 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

The challenge was to built something that could celebrate our planet. And what better way to celebrate then try to save it!

Introducing SqlGo, an SQL auditor which connects to your SnowFlake account, finds the historic executions of your query and with the help of Gemini, provides useful suggestions to optimize your query, in turn reducing the computation power needed to run them, which in turn would reduce the CO2 emissions and water maintenance needed for these datacentres to run

It also finds "zombie" — unused or stale tables within your schema that have not been accessed over time, and haven't been used, saving the redundant storage space.

Key features:

Feature	Description
Secure Authentication	Connects to Snowflake using credentials from a JSON file, stored only in the user's session for enhanced security.
Sustainability Dashboard	A central, interactive dashboard displaying key metrics like annual CO2 saved, zombie tables found
High-Compute Query Auditing	Automatically identifies and lists the most resource-intensive queries from the past week for on-demand analysis.
Zombie Table Detection	Scans the database for tables that haven't been altered in over 30 days, helping to eliminate storage waste.
AI-Powered Optimization	Integrates with Google Gemini to provide expert suggestions for rewriting inefficient queries to be more "Green".
Gamified Savings	Features a rewarding animation and updates dashboard metrics when a user "Accepts" an optimization, encouraging eco-friendly practices.
Modern UI/UX	A fully responsive, dark-themed interface with animated loaders, sortable tables, and a clean design for an intuitive user experience.

Demo

Code

Mohammadtej / earthday-hackathon

earthday-hackathon

🚀 SqlGo – Key Features

SqlGo is designed to optimize database performance while promoting sustainability through intelligent insights and a modern user experience.

🔑 Features

Secure Authentication: Connects to Snowflake using credentials from a JSON file, stored only within the user's session to ensure enhanced security.
📊 Sustainability Dashboard: A centralized, interactive dashboard showcasing key metrics such as annual CO₂ savings, zombie tables identified, and compute efficiency.
⚡ High-Compute Query Auditing: Automatically detects and lists the most resource-intensive queries from the past week, enabling targeted performance improvements.
🧟 Zombie Table Detection: Identifies tables that have not been modified in over 30 days, helping reduce unnecessary storage usage.
🤖 AI-Powered Optimization: Integrates with Google Gemini to suggest optimized, more efficient ("greener") versions of SQL queries.
🎮 Gamified Savings: Encourages eco-friendly actions with interactive feedback—users receive visual rewards and updated metrics when they accept optimization…

View on GitHub

How I Built It

Tech stack used:

Framework: Django (Python)
Database Integration: Snowflake Connector for Python
AI Engine: Google Gemini API (gemini-2.5-flash)

Design decisions:

Ease of Use: It was decided to include the table statistics as well into the schema, so that the end user may get an overview of the data and the storage space used. Based on that and the usage, indexes may be created to further optimize key tables.
Query Traceability & Analysis: Sql ids were included in the report for the queries that are taking a significant time so that the end user may leverage other tools based on the underlying database to analyse the SQL based on the id.
Efficient Token Utilization: Rather than collecting all the SQLs taking significant time and passing it to the Gemini layer, it was better to leave it to the end user to select which SQL to chose, in turn reducing the tokens wasted in analysing all the queries.
Privacy-First Stateless Architecture: Taking the input via a JSON object for the database credentials, and only storing them in the session, so that confidential user data may not be misused.

Prize Categories

Best use of Google Gemini: Used the Gemini API as the main engine of the system to provide analysis based on the data gathered from Snowflake. Also, this application was developed by using Gemini Code Assist and chat. (Chat works better in remembering the overall context I feel)
Best use of Snowflake: Used a pre-existing high-data schema in Snowflake and executed some of the compute intense queries resembling real-life examples, not just poor code! Futhermore, the Snowflake agent Cortex code helped a lot in understanding the schema, and debugging some of the prompt queries used in this application. It even helped in establishing the connection from python to snowflake :)

Future Improvements

Instead of a JSON based input, we could provide an option to directly connect with a Snowflake account to get continuous monitoring and audit

Fun Fact: The entire frontend of the application was done using Gemini Code Assist