DEV Community: Aashita

Google's "Budget" Model Just Beat Its Own Flagship. Here's What That Actually Means for Developers.

Aashita — Fri, 22 May 2026 10:56:30 +0000

This is a submission for the Google I/O Writing Challenge

Flash models were supposed to be the budget option.
Faster and cheaper — that was the deal. You
used Flash when you needed speed and could tolerate a
quality tradeoff. You used Pro when the task actually
mattered.

At Google I/O 2026, Gemini 3.5 Flash beat Gemini 3.1 Pro
on every benchmark that matters for building agents.

That sentence should sound impossible. It isn't. And
understanding why it happened tells you everything about
where AI development is actually heading right now.

The Numbers First

Benchmark	What it measures	3.1 Pro	3.5 Flash
MCP Atlas	Tool-use reliability	78.2%	83.6%
Terminal-Bench 2.1	Agentic coding	70.3%	76.2%
GDPval-AA	Long-horizon tasks	1314 Elo	1656 Elo

Not close. Not one cherry-picked test. Across coding,
tool-use reliability, and long-horizon task completion —
the three things that actually matter if you are building
something real — the cheaper model won.

It also runs 4x faster than comparable frontier models
and costs roughly half as much.

Artificial Analysis put 3.5 Flash alone in the top-right
quadrant of their Intelligence vs Speed index. The only
frontier model right now combining top-tier intelligence
with exceptional speed.

Why This Happened

The old assumption was that intelligence scaled with model
size. Bigger parameters, better reasoning, end of story.

3.5 Flash breaks that assumption because it was not
optimized for general intelligence. It was optimized
specifically for tool use, multi-agent coordination,
and live environment execution.

The benchmarks it beats 3.1 Pro on are exactly those
benchmarks. The one benchmark where 3.1 Pro still leads
is long-context retrieval — passive reading, not active
doing.

Google essentially asked: what does a model need to be
good at to power the agentic era? Then they built
directly toward that target instead of chasing a general
leaderboard. The result is a model that is purpose-built
for the exact moment we are in.

What This Feels Like to Actually Build With

Let me make this concrete.

You are working on a mid-sized Node.js project. You have
route files, a database schema, authentication middleware,
environment config, and architectural decisions documented
in a README from six months ago.

Previously you copy-pasted relevant pieces into a chat
window and hoped the model could infer the missing
connections. You were the context manager, manually
bridging gaps the model could not hold.

3.5 Flash has a 1,048,576 token context window —
roughly 786,000 words. You paste everything once. Then
you just talk:

My checkout flow is failing silently on orders over $500.
It works fine below that. Walk me through what could
cause this given everything you can see.

The model sees your payment middleware, database schema,
route handlers, environment variables, and error logging
simultaneously. It does not need you to guess which file
is relevant. It knows.

That is not faster at the same thing. That is different
in kind.

The FinOps Detail Nobody Is Talking About

Context caching on 3.5 Flash costs $0.15 per million
tokens — a 90% discount from the standard $1.50 input
price.

For agent loops this changes the production math entirely.
The expensive part of running persistent agents is not
generating responses. It is re-sending your system prompt,
tool descriptions, and conversation history on every
single turn.

Turn 1: Send 100k tokens of context     → $0.150
Turn 2: Read same context from cache    → $0.015
Turn 3: Read same context from cache    → $0.015
Turn 4: Read same context from cache    → $0.015

A session that cost $1.50 in context fees costs $0.19
with caching. At production scale that difference is not
marginal — it is what makes a product financially viable
or not.

The API Detail Worth Getting Right

3.5 Flash ships with dynamic thinking on by default.
You can control it explicitly:

import google.generativeai as genai

genai.configure(api_key="YOUR_API_KEY")
model = genai.GenerativeModel("gemini-3.5-flash")

# Fast path for simple tool calls
response = model.generate_content(
    "Extract the order ID from this receipt: ...",
    generation_config={"thinking_level": "minimal"}
)

# Deep reasoning for hard decisions
response = model.generate_content(
    "Given this entire codebase, recommend how to "
    "restructure auth for multi-tenancy",
    generation_config={"thinking_level": "high"}
)

Options: minimal, low, medium (default), high.

Use minimal for deterministic tool calls where you need
speed. Use high for planning steps where you need real
reasoning. Your cost and latency per session shifts
significantly depending on how you tune this.

Why Gemini Spark Could Only Exist Now

This is the part that connects everything.

Gemini Spark — the 24/7 personal agent Google announced
at I/O, running on dedicated Cloud VMs, managing your
inbox and calendar while you sleep — could not have
existed six months ago.

Not because the idea was new. Because the economics did
not work. A persistent personal agent holding full context
and calling tools reliably across millions of users would
have required flagship model pricing and still been too
slow to feel responsive.

3.5 Flash's combination of 1M context window, 83.6%
tool reliability, 4x speed, and 90% caching discount
is precisely what unlocks Spark as a product.

Google did not build Spark and then find a model to run
it. They built 3.5 Flash for this exact workload —
always on, context-heavy, multi-step, running at scale —
and Spark is what becomes possible on top of it.

When Google says I/O 2026 is the shift from "prompting"
to "acting" — 3.5 Flash is the technical foundation that
makes acting affordable enough to actually ship.

What Changes for What You Build

The practical takeaway is simpler than the benchmarks
make it sound.

The model tier you reach for by default just changed.

Previously: start with Flash, upgrade to Pro when quality
is not good enough.

Now: start with Flash, stay on Flash unless you
specifically need deep passive long-context retrieval.

For anything involving tool calls, agents, coding
assistance, or multi-step workflows — which is most of
what developers are building with AI right now — 3.5
Flash is not the budget option anymore.

It is the right option.

Breaking the Stateless Curse: Hermes Agent and the Case for Persistent AI Agents

Aashita — Sat, 16 May 2026 16:58:04 +0000

This is a submission for the Hermes Agent Challenge

The most expensive thing most AI agents forget is not your name. It’s the work they just did.

You let an agent spend thousands of tokens learning your environment, inspecting your repository, debugging issues, figuring out project conventions, and working through a useful engineering task—sometimes even discovering a workflow that reliably works. Then you close the session, come back the next day, and much of that context is gone. The repository is still there, but the agent has forgotten what it learned about it, how it solved the problem, and which workflow actually got the job done.

For short-lived tasks, that’s not a huge issue. If all you need is a summary, a SQL query, or a quick browser automation task, stateless execution works fine. But once agents start touching repeated engineering work, automation, or operational workflows, forcing them to rediscover the same solutions over and over becomes an expensive design flaw.

That’s what makes Hermes Agent from Nous Research interesting.

Hermes is not being pitched as just another coding copilot or a chatbot wrapper with tool access bolted on. The more ambitious idea is that successful execution should create reusable operational knowledge. If an agent solves a meaningful problem once, it should not have to relearn the same workflow from scratch the next time.

If that works reliably, it changes what open-source agents can become.

The Stateless Agent Problem

Most current agent frameworks effectively behave like this:

Goal → Plan → Tool Calls → Execute → Return Result → Forget

That lifecycle works surprisingly well—until the work becomes repetitive.

Imagine asking an agent to scan a repository, identify missing license headers, generate patches, run tests, and commit validated changes. A capable system might spend significant time inspecting the filesystem, inferring project conventions, handling failures, and refining its approach before it gets the task right.

Now run that exact same task a week later. Most agents will start from zero as though the previous execution never happened.

The same thing happens with recurring operational issues. If an agent spends twenty minutes discovering that a flaky CI failure came from one dependency mismatch and a bad environment variable, you would reasonably expect that discovery to be reusable. Instead, most systems replay the entire debugging process.

That’s the inefficiency. A human engineer would either remember the pattern or document the solution. Stateless agents generally do neither.

What Hermes Is Trying to Change

Hermes attempts to change that lifecycle by inserting a learning loop. Instead of behaving like a linear sequence, the intended model looks more like this:

Observe → Plan → Execute → Evaluate → Crystallize Skill → Reuse

The important difference is what happens after execution. Rather than treating task completion as the end of the interaction, Hermes evaluates whether the workflow it just used is worth keeping.

Did the task succeed?
Which actions actually mattered?
Was the solution a one-off workaround, or does it represent a reusable operational pattern?

If the answer is yes, Hermes can retain that workflow as a reusable Skill instead of forcing the model to rediscover the same process later. That’s a much more compelling idea than simply preserving chat history.

What a Skill Actually Looks Like

“Procedural memory” sounds abstract until you think about what is actually being stored. Hermes’ approach to procedural workflows is much closer to inspectable skill artifacts than opaque memory blobs, which is a much healthier model than treating memory as hidden vendor state.

Conceptually, a crystallized skill artifact looks something like this:

# repo-license-remediation
version: 1.2

tags:
  - python
  - repository
  - compliance

inputs:
  - repo_path
  - license_header

required_tools:
  - filesystem
  - regex_match
  - file_write
  - terminal
  - git

steps:
  1. Scan Python files
  2. Detect missing headers
  3. Generate patch
  4. Run tests
  5. Commit validated changes

This is fundamentally different from remembering prior prompts or conversation snippets. This is operational knowledge.

Remembering that I prefer concise responses is personalization. Remembering how to safely repair a repository issue is actual capability. That distinction matters.

Procedural Memory Is More Interesting Than Chat Memory

A lot of AI products advertise memory, but most of the time that means conversation continuity, user preferences, or retained prompt context. That is useful, but it does not necessarily make the system better at doing work.

The more meaningful distinction is between remembering facts and remembering procedures. Humans become effective engineers because they internalize repeatable workflows. You do not memorize every exact command forever, but you do remember how to approach a recurring integration issue or how to remediate a familiar failure pattern.

Hermes is aiming much closer to that model. Its architecture can be thought of in three distinct layers:

Working Memory: Short-lived execution state including the current task context, temporary variables, and recent tool outputs. This is standard agent behavior.
Episodic Memory: Longer-lived contextual recall mapping project metadata, user preferences, and prior historical decisions to improve continuity.
Procedural Memory: The interesting layer. It stores reusable workflows like debugging routines, deployment procedures, remediation pipelines, and integration playbooks.

If this layer works well, the system improves with repetition instead of simply remembering conversations.

The Scaling Problem

Persistent procedural memory sounds great until you hit the obvious question: What happens when the agent accumulates hundreds of workflows? Dumping all of them into the context window every time would be terrible for token efficiency, latency, and reasoning quality. A staged retrieval model makes much more sense:

Discovery Stub (~20 tokens): Start with the minimum—just the skill name and a short description to determine relevance.

Example: Python repository license remediation workflow
Signature Layer (~200 tokens): If the workflow looks useful, retrieve expected inputs, required tools, and configuration assumptions to validate applicability.
Blueprint Layer (~1,000+ tokens): Only when the workflow is actually executed do you load the full steps, command sequences, and tool invocation logic.

This is dramatically more scalable than brute-force memory stuffing. One caveat: if you are evaluating Hermes critically, it is worth checking which parts of this are implemented exactly as described today versus which represent broader architectural direction. But conceptually, this is the right shape of solution.

Trying Hermes Yourself

Setup itself looks straightforward, but the more interesting question is not whether Hermes can run—it’s whether repeated tasks actually become smarter.

The baseline setup follows a quick terminal sequence:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup
hermes

Hermes also supports running beyond the terminal—across messaging interfaces and isolated execution backends—which makes the architecture feel operational rather than purely conversational.

A worthwhile test is giving it something that actually requires multi-step reasoning, like scanning a test repository, identifying missing headers, and generating a local patch. The real validation is whether the second execution feels noticeably cleaner, faster, and less wasteful.

Where Hermes Fits Compared to Other Frameworks

LangChain: Gives developers raw building blocks and enormous flexibility. That is great if you want full architectural control, but it also means assembling everything yourself. Hermes feels more opinionated out of the box.
AutoGen: AutoGen shines in multi-agent conversational workflows, but conversation-heavy systems can become noisy and expensive fast. Hermes feels less focused on agent dialogue and more focused on raw execution workflows.
OpenDevin: Clearly aligned with software engineering automation and workspace environments. Hermes feels slightly broader, aiming at general operational agent behavior.
OpenClaw: Adjacent rather than directly competitive. OpenClaw is strong around orchestration and communication routing, while Hermes is more interesting around procedural learning and self-improving execution.

Infrastructure Design Matters

A powerful agent without execution isolation is a liability. Giving unrestricted shell access to an LLM is not a serious production strategy.

Hermes supports multiple execution backends, including restricted local execution, Docker containers, SSH environments, Singularity, and remote sandbox environments like Modal. This matters because practical automation requires isolation.

A realistic workflow might involve a Slack alert triggering an isolated environment, Hermes validating deployment state, detecting a known failure pattern, applying a learned remediation workflow, and reporting back. That starts looking much less like a toy demo and much more like something operations teams could actually use.

Where This Can Go Wrong

The risks here are real:

Skill Drift: A workflow that worked six weeks ago may be wrong today because dependencies changed, APIs evolved, or CLI flags broke. Without revalidation, procedural memory becomes stale automation debt.
Faulty Generalization: An agent might incorrectly promote a brittle edge-case fix into a reusable standard workflow. That becomes dangerous quickly because repeated incorrect automation is often worse than forcing fresh reasoning every time.
Security Risk: Persistent procedural memory can preserve unsafe commands, environment assumptions, or patterns that risk credential leakage. Any self-improving execution system needs strict governance.

Practical Safeguards

If anyone plans to use something like this in production, the minimum checklist probably includes:

Human approval before newly created skills are allowed into active reuse.
Verification across multiple successful runs before allowing autonomous reuse.
Automated smoke testing, version control, and strict least-privilege execution boundaries.

Without those controls, procedural memory becomes accumulated operational risk instead of useful automation.

Why This Matters for Open Source

The bigger issue here is ownership.

A lot of proprietary AI systems assume persistent memory belongs inside vendor infrastructure. That creates lock-in, opaque automation logic, poor auditability, and painful migration stories.

If an open agent can retain reusable operational knowledge in inspectable, version-controlled artifacts, teams can audit agent behavior, share playbooks, migrate freely, and actually own the workflows the system learns. If your agent discovers something useful, that knowledge should live in infrastructure you control—not disappear into a hosted memory layer.

That may be the more important shift.

Discussion

Would you trust a self-improving agent for non-critical automation today? Why or why not?
What specific safeguards would you require before letting one touch production infrastructure?

The End of Renting Intelligence? Why Gemma 4 Makes Local AI Feel Viable

Aashita — Fri, 08 May 2026 13:43:46 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

There’s a specific kind of developer anxiety that has nothing to do with bugs. It’s the mental math that happens while using cloud AI tools.

How many requests have I burned?
Will this hit a usage cap?
Do I really want to send these notes, drafts, or code snippets to a third-party server?

For the past year, that has been part of my workflow.
Cloud AI is undeniably useful. But it often feels less like ownership and more like access that can be throttled, billed, or restricted at someone else’s discretion.
That’s why Gemma 4 caught my attention. Not because it’s another flashy model release but because it made capable local AI feel practical.

For students, indie developers, creators, and curious builders, that’s a meaningful shift. The conversation stops being just about access to intelligence. It starts becoming about ownership.

What Gemma 4 Actually Is

Gemma 4 is Google’s newest open-model family, built using the same research foundation behind Gemini but released openly so developers can download, run, fine-tune, and integrate the models into their own workflows.

The current lineup includes four major variants:

Model	Description
Gemma 4 E2B	Lightweight edge model optimized for phones, Raspberry Pi devices, and low-resource systems
Gemma 4 E4B	Balanced model for laptops and local creator workflows
Gemma 4 26B A4B	Mixture-of-Experts (MoE) model designed for efficient reasoning and fast inference
Gemma 4 31B	Large dense model focused on advanced reasoning, coding, and long-context tasks

One of the most impressive parts of Gemma 4 is that even the smaller models support features that used to feel “enterprise-only,” including:

Native multimodal understanding (text + images)
Massive 128K–256K context windows
Efficient quantization for local deployment
LoRA and QLoRA fine-tuning workflows
Strong reasoning capabilities

Instead of treating local AI as a stripped-down compromise, Gemma 4 treats it as a serious development environment.

Which Gemma 4 Model Should You Actually Use?

The smartest way to approach Gemma 4 is not by asking “Which model is best?” but:

“Which model fits my hardware and workflow?”

Here’s the practical breakdown:

Model	Hardware Sweet Spot	Best Use Cases
E2B	Phones, Raspberry Pi, low-RAM laptops	Fast experimentation, lightweight assistants, offline tools
E4B	Standard laptops (8–16 GB RAM)	Writing, research, social content, local copilots
26B A4B	Strong GPUs or cloud boxes	Multi-step reasoning, coding workflows, agent-style systems
31B Dense	High-end GPUs/workstations	Deep reasoning, long-form generation, advanced coding

For my own testing, I intentionally chose the E4B model instead of jumping straight to the larger variants.

Why?

Because I wanted to evaluate Gemma 4 the way most independent developers, students, and creators realistically would—not on expensive infrastructure, but on hardware that feels accessible.

The 31B model is clearly more powerful, and the 26B A4B MoE variant is especially interesting for heavier reasoning workloads. But for writing workflows, research summarization, screenshot analysis, and lightweight experimentation, E4B felt like the most honest test of whether Gemma 4 is actually practical for everyday builders.

That tradeoff matters.

A model can be impressive on paper and still unusable for the people it claims to empower.

Running Gemma 4 Locally in Minutes

One of the best things about Gemma 4 is how approachable the setup process has become. Using tools like Ollama or LM Studio, you can run a capable AI model locally with almost no friction.

For example, using Ollama:

# Run the Gemma 4 E4B model locally
ollama run gemma4:4b

That’s it.

What surprised me most while testing Gemma 4 locally wasn’t just performance. I threw in a mix of rough research notes, screenshots, and an unfinished content outline to see whether the workflow would feel clunky.

It didn’t. It was useful enough that I immediately understood the appeal. But the bigger difference was psychological.

I wasn’t thinking about token usage, request limits, or whether I should save prompts for later. That kind of friction quietly changes how you work. Local AI felt less like a demo and more like an actual tool I could build around.

Why Long Context Actually Matters

A lot of AI announcements focus on benchmark scores.

But in real-world usage, the larger context window might be the most important feature for creators and developers. With Gemma 4, you can:

feed in long PDFs,
analyze entire research collections,
summarize lecture notes,
process large codebases,
or maintain continuity across long conversations.

For students and indie builders, that changes the workflow completely. Instead of constantly compressing information into smaller prompts, the model can work with larger chunks of context naturally.

That makes the interaction feel less fragmented and significantly more useful.

The Most Interesting Shift: AI Ownership

For years, the AI conversation has mostly been framed around access.

Who has the biggest models? Who has the fastest APIs? Who can afford the most compute?

Gemma 4 points toward a slightly different conversation: ownership.
Running capable models locally means you can experiment more freely, protect sensitive work, and build without every workflow depending on a third-party service.

If you're a student, indie developer, or creator working with personal notes, drafts, experiments, or prototypes, that flexibility matters. It changes the relationship. You’re not just consuming AI anymore. You’re shaping how it fits into your workflow.

Fine-Tuning Feels More Accessible Than Ever

Another reason Gemma 4 stands out is how approachable fine-tuning has become. Using LoRA or QLoRA workflows, developers can adapt models using relatively affordable hardware.
For creators, that opens interesting possibilities:

a writing assistant trained on your content style,
a research copilot specialized for your niche,
a local AI assistant customized for your own workflow.

That kind of personalization used to feel reserved for large AI companies. Now it’s increasingly available to independent developers and curious students.

Why This Feels Different

One thing I learned from exploring Gemma 4 is that benchmark discussions are only part of the story.

What changes real workflows is if a model is technically impressive but expensive to use, hard to integrate, or awkward to experiment with, most independent builders won’t actually build around it. Gemma 4 gets something important right: it lowers that friction.

What I Think Gemma 4 Gets Right

The biggest strength of Gemma 4 isn’t just performance.

It’s accessibility.

What this release gets right is accessibility. The future of AI is not only about bigger cloud systems. It’s also about lightweight, efficient models that people can run, study, and experiment with locally.
That shift lowers the barrier to entry for:

students learning AI,
developers building side projects,
creators experimenting with workflows,
and people outside major tech hubs.

And honestly, that part feels exciting because local AI replaces the cloud entirely, it gives more people the ability to participate.

The most exciting thing about Gemma 4 isn’t that it’s the biggest or most dramatic AI release of the year. It’s that it makes capable local AI feel practical for more people.

Students can experiment without enterprise budgets. Developers can prototype without building everything around API dependency. Creators can explore more private, personalized workflows.

That doesn’t mean cloud AI disappears. But it does mean the balance is shifting. And I think that’s where things get interesting. Not when AI feels distant and infrastructure heavy. When it feels accessible enough that more people can actually build with it.

Decoding Democracy: How ELARA is Transforming Election Education Through Specialized AI

Aashita — Fri, 01 May 2026 12:39:12 +0000

Submission for Virtual: PromptWars
In every democracy, participation matters. Yet for many first-time voters, the biggest barrier is not willingness — it is confusion.

Registration steps, verification timelines, polling-day procedures, deadlines, and unfamiliar terminology can make the election process feel intimidating. Many citizens want to participate, but don’t know where to begin.

That is exactly why I built ELARA — the Election Assistance & Resource Assistant.

ELARA is an AI-powered civic education platform designed to make the election journey clear, interactive, and beginner-friendly. Instead of functioning like a generic chatbot, ELARA acts like a smart civic guide: structured, contextual, and focused on helping users take the next right step.

Why Election Education Needs Better Technology

Millions of people have questions such as:

How do I register to vote?
What documents are required?
What happens during verification?
What should I expect on polling day?
What do election terms like NOTA, EVM, or VVPAT mean?

Traditional sources often bury answers inside dense documents or scattered pages. Generic AI tools may respond, but frequently without context, trust signals, or practical guidance.

ELARA was built to close that gap.

The Core Innovation: Intent-Based AI Guidance

Rather than routing every query through one generic AI prompt, ELARA uses Intent-Based Routing powered by Google Gemini.

This allows the platform to understand what kind of help the user actually needs and respond with focused, relevant guidance.

1. Journey Mode

For users at different stages of the voting process:

Not Registered
Registration in Progress
Ready to Vote

ELARA provides personalized next steps, expected timelines, and required documents.

2. Timeline Mode

Users can explore the full election lifecycle:

Registration
Verification
Polling Day
Counting
Results

Each stage is explained in simple language, including what happens, who is involved, and what comes next.

3. Jargon Mode

Complex civic language becomes understandable instantly.

Examples include:

NOTA
EVM
VVPAT
Constituency
Manifesto
Gerrymandering

4. General Guidance Mode

A neutral, non-partisan assistant for broader election process questions.

Built for Trust, Not Hype

Many AI products create false confidence through vague certainty scores.

ELARA takes a better path.

Instead, it uses meaningful trust indicators such as:

Beginner Friendly
Step-by-Step Guidance
Timeline Included
Neutral Educational Response
Official Resource Support

This helps users understand the type of assistance they are receiving without pretending AI outputs are infallible.

Interactive Learning Experience

ELARA is more than a text box.

Guided Walkthrough

Users can launch a complete walkthrough of the election process — from registration to final results.

Quick Learning Chips

Tap common questions or election terms to get instant simplified explanations.

Context-Aware Responses

Guidance changes depending on whether the user is unregistered, registered, or preparing to vote.

Hindi + English Support

Designed for broader accessibility and inclusion across Indian users.

Built Like a Real Product

ELARA combines thoughtful UX with production-grade engineering.

Frontend

React + Vite
Responsive UI
Accessible semantic components
Keyboard-friendly navigation
Reduced-motion support

Backend

Node.js + Express
Google Gemini integration
Intent routing engine
Graceful fallback responses
Caching for performance

Reliability & Security

Rate limiting
Security headers
Input sanitization
Automated test coverage
Cloud deployment readiness

Google Ecosystem

Gemini API
Firebase / Firestore
Google Cloud Run

Why This Matters

Technology should reduce friction during important civic moments.

When voting feels confusing, participation drops.
When systems feel understandable, confidence rises.

ELARA demonstrates how AI can be used responsibly — not to influence political choices, but to improve civic literacy, clarity, and access.

The Bigger Vision

The future of AI is not about assistants that try to do everything.

It is about focused systems that solve real problems well.

ELARA is one example of how specialized AI can strengthen democratic participation by making complex processes easier to understand and easier to navigate.

Live Prototype

https://elara-app-174971475950.us-central1.run.app/

Final Thought

Democracy works best when people understand how to participate.

ELARA’s mission is simple:

Make the election process easier to understand, easier to navigate, and easier to trust.

So honored to be selected as one of the winners for the Earth Day Challenge! 🌍 It was such a blast building this and seeing all the other incredible sustainable solutions. Huge thanks to the DEV team and the sponsors for putting this together! 🚀

Aashita — Fri, 01 May 2026 03:50:43 +0000

DEV Weekend Challenge: Earth Day

Jess Lee for The DEV Team

Apr 30

Announcing the Winners of the DEV Weekend Challenge: Earth Day Edition 🌍

#devchallenge #weekendchallenge

Comments 18

4 min read

Google Cloud NEXT '26 Challenge Submission

Aashita — Wed, 29 Apr 2026 06:33:47 +0000

Google Cloud NEXT '26 Challenge Submission

Aashita

Apr 23

Vibes Don't Scale: Moving from AI Prototypes to Production-Grade Systems

#devchallenge #cloudnextchallenge #googlecloud

Comments 3

4 min read

Vibes Don't Scale: Moving from AI Prototypes to Production-Grade Systems

Aashita — Thu, 23 Apr 2026 03:05:30 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Last week, I was at Microsoft R&D diving into agentic workflows. As a 4th-semester CS student, I’ve spent the last few months in that "I’m basically a senior dev now" stage of AI development—using natural language prompting to bridge the gap between my ideas and my actual coding ability. It feels like magic until you try to build something that needs to work in the real world, at scale.

My project is CrowdCommand, a crowd-safety platform designed to monitor thousands of fans to prevent crowd crushes. During early tests, I realized that simple prompting hit a hard ceiling. You can't "vibe" your way out of networking lag or data drift when someone’s safety is on the line.

Watching the Google Cloud NEXT '26 keynotes, it finally clicked: the future isn't about "better AI," it's about Agentic Infrastructure. Here is how the new blueprint is helping me move my project from a classroom demo to something production-ready.

The Latency Problem:

In a stadium, if an AI takes five seconds to process crowd with a camera feed, it’s useless. I used to think the "model" was the bottleneck, but it’s actually the data movement.

The announcement of TPU v8i (Inference-optimized) and the broader AI Hypercomputer architecture is the hardware fix I needed. By keeping model weights on-chip, it eliminates the lag of moving data back and forth. But the real star is the Virgo network.

In an agentic system, you don't just have one "brain"—you have a fleet. I have "Gate Agents" and "Emergency Agents" that need to stay in constant sync. Without Virgo’s high-throughput fabric, they end up lagging or talking over each other. Now it turns a collection of scripts into a synchronized Agentic Taskforce.

Solving "Reasoning Drift" with the Knowledge Catalog

The scariest thing in AI is when an agent makes a decision based on stale data. Imagine a safety agent suggesting an evacuation route that is currently blocked because its last "knowledge update" was ten minutes ago.

The Agentic Data Cloud and the new Knowledge Catalog solve this. Instead of my agents "hallucinating" a path, they are now grounded in a live Knowledge Graph of the venue. I’ll start playing with Firebase Genkit to build these flows locally. It allows me to force the AI to verify real-time sensor data before it acts. By utilizing AlloyDB and Lightning Engine for Apache Spark, we can provide agents with durable, stateful memory. It moves the project from a "chatbot" that talks about safety to a "system" that enforces it.

The Underrated MVP: Cloud Run Billing Caps & Event Compaction

While the headlines are dominated by new models, the announcement I think is most overlooked is the addition of Cloud Run Billing Caps.

Let’s be real as a student, the biggest barrier to entry isn't the code—it’s the credit card bill. Experimenting with agentic fleets is notoriously expensive because agents can be very "chatty" with APIs. One recursive loop or a surprise traffic spike can be financially devastating.

For a student founder, these billing caps are the ultimate "Founder Mode" feature. It lets me deploy specialized models (like Gemma 2 via NVIDIA L4 GPUs in Cloud Run) with a hard financial guardrail. But the Developer Keynote introduced a technical partner to this i.e. Event Compaction. This technique manages token limits during long-running agent workflows by summarizing an agent's reasoning, keeping the "intelligence" high while keeping the API costs (and my stress levels) low.

Security as a Guardrail

When you're handling large crowd data, you can't just hope for the best. The integration of the new security agent, 'Whis' into the Agentic Defense framework is a huge relief. It provides autonomous security scans that watch the agent's code to identify attack paths and suggest remediations in real-time. I can focus on the crowd-safety logic while the infrastructure handles the "autonomous guardrails" for the agent's lifecycle.

Orchestration at Scale: ADK, Genkit, and A2A

Today’s Developer Keynote introduced three things that bridge the gap between "coding" and "architecting": Firebase Genkit, the Agent Development Kit (ADK), and the Agent-to-Agent (A2A) protocol.

Genkit and the ADK allow me to move away from messy prompt strings and into modular, code-first agent development. But the real breakthrough is A2A. In CrowdCommand, my "Gate Agents" and "Emergency Agents" can now use A2A to negotiate priorities autonomously—like deciding which gate to open first during an evacuation without waiting for a central server to mediate.

Even more game-changing is the Agent-to-User Interface (A2UI) standard. It allows agents to dynamically generate their own expressive user interfaces on the fly. It means the system can build a tailored emergency dashboard for stadium staff without me writing a single line of CSS. It’s the difference between a scripted sequence and a living, breathing system.

Moving Forward: From Prompter to Orchestrator

The "Agentic Cloud" has shifted my perspective as I head into my 5th semester. I’m realizing that we aren't just building "apps" anymore; we are orchestrating systems of intelligence.

Google Cloud NEXT '26 provided the missing architectural pieces for my project. If you're still just "prompting," you're building for the past. The future is about building Agentic Enterprises that actually reason, act, and scale.

Note: These are my personal reflections on the Google Cloud NEXT '26 Keynotes. CrowdCommand is my ongoing project exploring the intersection of AI and public safety.

devchallenge #googlecloud #cloudnextchallenge #agenticai #agenticenterprise #csstudent

CrowdCommand — AI Powered System to optimize crowd flow and reduce large-scale event waste

Aashita — Sat, 18 Apr 2026 10:40:41 +0000

This is a submission for Weekend Challenge: Earth Day Edition

🌍 What I Built

I built CrowdCommand — AI that predicts crowd chaos and reduces real-world resource waste, it is a real-time system designed to manage large-scale human movement efficiently, predict congestion before it happens, and enable immediate action.

At large events, crowd movement is rarely optimized. People cluster, queues grow unpredictably, and entry points overload.
This doesn’t just cause inconvenience — it leads to:

unnecessary energy wastage
inefficient crowd routing
operational strain on infrastructure
increased resource consumption at scale

Most existing systems react only after congestion becomes visible.

CrowdCommand changes that.

It introduces a system that:

monitors crowd density in real time
predicts congestion before it escalates
generates AI-driven recommendations
enables operators to take instant action

Real-World Impact Potential:

inefficient crowd movement = wasted time, wasted energy, and unnecessary resource usage

By optimizing how thousands of people move through a space, CrowdCommand contributes to:

smoother flow → reduced operational overhead
faster movement → less idle congestion
smarter decisions → more efficient use of infrastructure

At scale, inefficient crowd movement directly translates into:

higher energy consumption (lighting, cooling, operations)
increased idle congestion and emissions
unnecessary infrastructure strain

CrowdCommand reduces this by improving flow efficiency in real time.

Even small optimizations across thousands of people can lead to measurable reductions in energy usage and operational waste during large-scale events.

This project explores how AI-driven decision systems can make physical environments not just smarter—but more sustainable.

🎥 Demo

🔗 Live Deployment (Google Cloud Run):
https://crowdcommand-866673965866.asia-south1.run.app/

The system simulates a fully operational control center with:

🗺️ Live crowd heatmap across 8 zones
🚪 Smart gate optimization (wait time + throughput)
⏳ Virtual queue system (10 concessions)
🧠 AI recommendations (Critical / Warning / Info)
🎛️ Operator action panel with real-time feedback

💻 Code

🔗 GitHub Repository:
https://github.com/aashitanegii/crowdcommand

⚙️ How I Built It

🧩 Tech Stack

Technology	Purpose
React + Vite	Frontend UI
Node.js + Express	Backend API
Socket.IO	Real-time updates
Google Cloud Run	Deployment
Google Gemini	AI advisory generation

🔄 Real-Time Simulation Engine

The system continuously generates:

crowd density per zone
gate wait times and throughput
queue lengths

Updates are pushed via WebSockets every few seconds, ensuring a live operational view.

🧠 AI Decision Layer (Google Gemini)

CrowdCommand integrates Google Gemini to generate real-time operational advisories based on live system data.

Examples:

“Food Court nearing capacity → reroute crowd + open alternate exits”
“Gate congestion detected → redirect to faster entry point”

These are surfaced in the UI as:

AI Advisory (Generated by Gemini)

This transforms the system from passive monitoring → active decision support.

In addition, Gemini was used during development to:

refine system architecture and logic
accelerate backend/API design
assist in UI interaction planning

⚡ Operator Action Loop

AI detects a risk
Recommendation is generated
Operator applies action
System recalculates crowd distribution
Updated state is broadcast instantly

A complete real-time feedback loop.

🎯 Key Features

Live Heatmap — Real-time occupancy + predictive trends
Smart Gates — Fastest entry recommendations
Virtual Queues — Dynamic wait-time simulation
AI Engine — Multi-level alerts and suggestions
Action Panel — Immediate execution + system feedback

🏆 Prize Categories

✅ Best Use of Google Gemini

Gemini API powers real-time advisory generation
AI outputs are contextual, actionable, and integrated into decision-making
Used across both runtime intelligence and development workflows

✨ What Makes This Different

Most dashboards show data.

CrowdCommand makes decisions.

It doesn’t just answer:

“What is happening?”

It answers:

“What should we do next?”

This project goes beyond building interfaces — it focuses on designing systems that:

analyze
predict
respond

in real time.

CrowdCommand is a step toward environments that are not just monitored — but intelligently controlled and optimized for sustainability.

devchallenge #weekendchallenge #ai #googlecloud #gemini #sustainability #webdev