DEV Community: Aniruddha Ghosh

My Laptop Crashed Twice Trying to Run Gemma 4. That’s Why I’m Excited About It.

Aniruddha Ghosh — Sun, 24 May 2026 18:11:56 +0000

I didn’t successfully run Gemma 4 the first night I tried it.

That’s the story.

Not:

“I built an incredible multimodal AI system in 20 minutes.”

Not:

“local AI changes everything.”

Just:

two failed downloads
browser freezes
thermal throttling
16GB RAM getting absolutely cooked
a laptop fan sounding spiritually distressed
and me staring at Ollama progress bars like they owed me money

Objectively, it was a terrible user experience.

And somehow, it made local AI feel more real than cloud AI ever had.

Cloud AI Feels Frictionless Because Someone Else Absorbs the Friction

Most developers experience AI through interfaces:

ChatGPT
Gemini
Copilot
APIs

You type.
Tokens appear.
The answer arrives.

Everything underneath stays invisible:

GPU memory
inference cost
bandwidth
thermal constraints
quantization
latency spikes
hardware limits

Cloud AI feels smooth because someone else owns the pain.

Local AI doesn’t hide it.

The moment I tried running Gemma 4 locally, AI stopped feeling abstract and started feeling physical.

That difference matters more than I expected.

The Download Failures Weirdly Made Me Respect the Model More

This sounds backwards, but hear me out.

When the download reset twice after thirty minutes, my first reaction was frustration.

Obviously.

Human beings did not evolve emotionally for multi-gigabyte model pulls over unstable connections.

But after the annoyance faded, something interesting happened:
I became aware of the actual scale of what I was trying to run.

Not “AI” as a floating product.

A real model.
With real weight sizes.
Real memory requirements.
Real infrastructure demands.

The friction forced me to think about the machinery underneath the intelligence.

Cloud AI almost never does that.

Local AI Makes Intelligence Feel Computational Again

Modern AI interfaces are so polished that they often hide the fact that intelligence generation is still a computational process with real constraints.

Gemma 4 made those constraints impossible to ignore.

Suddenly:

RAM mattered
browser tabs mattered
thermals mattered
inference size mattered
hardware tradeoffs mattered

Even before the model fully ran, the system itself became part of the experience.

And honestly?

I think developers benefit from seeing that.

Because local AI changes your relationship with the technology.

You stop seeing intelligence as:

infinite
instant
effortless

And start seeing it as:

engineered
resource-intensive
constrained
inspectable

That shift feels important.

The Most Interesting Part Was Watching the Illusion Break

Cloud AI often feels magical because the complexity is hidden behind APIs and infrastructure layers most people never see.

Local models expose the illusion.

Not in a cynical way.

In a useful way.

When your laptop starts thermal throttling because you tried running a capable multimodal model locally, you become aware that intelligence generation has weight to it.

Literally.

There’s compute happening.
Memory allocation happening.
Optimization tradeoffs happening.

AI stops feeling like a mystical product category and starts feeling like systems engineering again.

I genuinely think that’s healthy for developers.

Open Models Encourage Curiosity Differently

One thing I noticed almost immediately while struggling through setup was how quickly local AI shifts developers into experimentation mode.

You start asking questions like:

Why are some models dramatically larger?
What actually affects inference speed?
Why does quantization matter?
What’s the tradeoff between model size and reasoning quality?
Why do context windows impact memory so heavily?
Why do local multimodal models feel fundamentally different from cloud APIs?

Cloud AI encourages usage.

Open models encourage investigation.

That difference is subtle, but important.

Gemma 4 Feels Like Infrastructure, Not Just a Product

I think that’s what stayed with me most after the failed setup attempt.

Gemma 4 didn’t feel like “an app.”

It felt like infrastructure I was trying to bring close to my own machine.

And that changes the emotional relationship developers have with AI systems.

Cloud AI feels rented.

Local AI feels inspectable.

Not necessarily easier.
Definitely not smoother.

But closer.

The Future Probably Includes Both

I’m not pretending local AI is suddenly more convenient than cloud models.

It isn’t.

My laptop made that very clear.

But after fighting through setup friction, resets, freezes, and thermals, I understand something now that I didn’t fully appreciate before:

The value of open models isn’t just privacy.
Or cost.
Or offline access.

It’s visibility.

Running Gemma 4 locally made AI feel less magical and more understandable.

And weirdly, that made the technology feel more exciting to me, not less.

Because the moment intelligence stops feeling untouchable, developers start trying to understand how it actually works.

That curiosity might end up being one of the most important things open models create.

The First Time an AI Model Failed Locally, I Understood It Better

Aniruddha Ghosh — Sun, 24 May 2026 18:08:34 +0000

The first time I tried running Gemma 4 locally, my laptop almost started a small industrial revolution.

The download reset twice.

My browser froze repeatedly.

RAM usage climbed high enough to make the entire system feel unstable.

The cooling fan sounded like it was preparing for takeoff.

And after roughly thirty minutes of fighting Ollama, thermal throttling, and increasingly questionable optimism, I gave up before the model even fully finished downloading.

Which is strange, because the entire experience made me more interested in local AI, not less.

That surprised me.

Because until then, most of my experience with AI came through cloud products:

ChatGPT
Gemini
Copilot
API-based workflows

And cloud AI has a very specific feeling.

It feels frictionless.

You type something.
Tokens appear.
The intelligence arrives instantly.

Everything important stays invisible:

hardware
memory
inference
latency
compute cost
thermal limits
system pressure

Cloud AI feels magical because someone else owns the machinery.

Running Gemma 4 locally completely broke that illusion.

The Moment AI Stopped Feeling Abstract

I have a laptop with 16GB RAM.

Normally, that feels perfectly fine for development.

Containers?
Fine.

VS Code?
Fine.

Multi-agent systems?
Usually manageable.

But the moment I started trying to run a local model seriously, the machine itself suddenly became part of the conversation.

That changed how I thought about AI almost immediately.

For the first time, intelligence stopped feeling infinite.

It started feeling physical.

You notice things you normally never think about with cloud models:

model sizes measured in gigabytes
RAM becoming an actual bottleneck
token generation tied to hardware constraints
inference speed changing based on system pressure
browser tabs becoming resource decisions
local AI behaving more like infrastructure than software

None of this is hidden when you run models locally.

And honestly?

That visibility teaches you something important.

Gemma 4 Made AI Feel More Like Engineering Than Magic

One of the strangest things about modern AI is how detached most developers are from the systems producing the intelligence.

Cloud AI abstracts everything:

scaling
inference
hardware
deployment
optimization
failure modes

You interact with the output, not the machinery.

But local models change the relationship entirely.

Even before Gemma 4 fully finished downloading, I became hyper-aware of things I normally ignore:

memory pressure
hardware limits
model tradeoffs
infrastructure friction
performance constraints

And weirdly, the failures themselves became educational.

Not because crashing laptops are fun.
Human civilization has somehow decided overheating silicon is a personality trait among developers, but still.

The point is:
local AI exposes the physical reality behind intelligence generation.

That matters.

Friction Changes How You Think About Models

Cloud AI trained many of us to think of intelligence as:

instant
cheap
infinite
effortless

Local models challenge all four assumptions.

When Gemma 4 pushes your hardware hard enough to freeze your browser, you stop thinking about AI as a floating product layer and start thinking about it as a computational system with real engineering costs underneath it.

And I think that shift is valuable.

Because once the abstraction disappears, developers start asking better questions:

Why does inference speed vary so much?
Which tasks actually require larger models?
What tradeoffs exist between size and reasoning?
Why do context windows matter?
What happens when intelligence becomes infrastructure instead of a hosted service?

Those questions feel much harder to ignore when your laptop fan sounds personally offended.

The Interesting Part Wasn’t Success. It Was Visibility.

Ironically, I never fully got Gemma 4 running properly that night.

The downloads kept resetting.
The system became unstable.
The setup friction won.

But the experience still changed how I think about open models.

Because for the first time, AI stopped feeling distant.

It stopped feeling like a polished interface connected to invisible data centers somewhere beyond my concern.

Instead, it felt inspectable.

Tangible.

Constrained.

Real.

And I think that’s one of the most important things open models like Gemma 4 actually provide developers.

Not just privacy.

Not just offline access.

Visibility.

Open Models Create Curious Developers

What impressed me most about Gemma 4 wasn’t benchmark performance.

It was the fact that running it locally made me curious about the mechanics underneath modern AI systems.

Cloud products encourage consumption.

Local models encourage investigation.

You start caring about:

memory usage
quantization
inference pipelines
token throughput
hardware efficiency
model architecture
deployment constraints

You stop treating intelligence like magic and start treating it like engineering.

That psychological shift feels important.

Especially now that AI is becoming part of everyday development workflows.

The Future Probably Isn’t Fully Local

Cloud AI is still more convenient for most workflows.

Honestly, dramatically more convenient.

There’s a reason most developers are not voluntarily stress-testing their RAM at midnight.

But after struggling through local setup friction, I understand the appeal of open models much better than I did before.

The more friction I encountered, the less AI felt mysterious.

And the less mysterious it felt, the more I wanted to understand it.

I think that curiosity is valuable.

Because the future of AI probably won’t belong entirely to closed systems or entirely to local ones.

But models like Gemma 4 make something possible that feels increasingly rare in modern software:

Developers getting close enough to the machinery to actually see how it works.

I Lost an AI Chat and Realized It Was Part of My Codebase

Aniruddha Ghosh — Sun, 24 May 2026 14:52:51 +0000

Google I/O 2026 made agentic development look exciting. Building with it made me realize something stranger.

I started building a multi-agent system with Antigravity 2.0 the same day I finished watching the Google I/O 2026 announcements.

At first, it felt unreal.

I would describe a milestone, and the system would start generating structure almost immediately:

implementation plans
milestone breakdowns
architecture files
backend scaffolding
routing
service layers

For a while, it honestly felt like cheating.

But after a few hours, something started bothering me.

Not because Antigravity 2.0 was bad.
The opposite, actually.

It was too agentic.

The Difference Between Watching Code and Touching It

Before Antigravity 2.0, I had used earlier Antigravity workflows built closer to a traditional editor experience.

I could open multiple files comfortably.
Inspect generated code directly.
Edit things manually while the AI worked beside me.

That mattered more than I realized.

Antigravity 2.0 felt optimized for orchestration instead of close supervision. The workflow was heavily conversational and agent-driven. I spent most of my time prompting, reviewing outputs, and approving changes while the system generated files rapidly in the background.

Technically, the experience was impressive.

Emotionally, I started feeling strangely disconnected from the project.

The faster the workflow became, the less attached I felt to the architecture itself.

I wasn’t really building anymore.

I was directing.

Then I Found Antigravity IDE

While researching the new ecosystem, I realized Google had split Antigravity into multiple workflows:

Antigravity 2.0
Antigravity CLI
Antigravity SDK
Antigravity IDE

The moment I discovered Antigravity IDE, everything suddenly made sense to me.

This was the environment I actually wanted.

AI-assisted development, but still close to the code.
Still tactile.
Still editable.

As a developer, I don’t just want generated output. I want visibility. I want to open five files side-by-side, inspect logic manually, trace decisions, and intervene whenever something feels wrong.

So I switched immediately.

That’s when things went sideways.

My Files Survived. My Project Context Didn’t.

The codebase still existed.

But the conversation history from Antigravity 2.0 was gone.

Worse, several generated planning artifacts disappeared too:

implementation-plan.md
milestone planning files
workflow notes
architecture reasoning

I had already progressed through roughly two milestones of the project. Only about a day of work, technically.

But it didn’t feel small.

Because the missing pieces weren’t just files.

They were reasoning.

At first I felt annoyed.

Then frustrated.

Then genuinely panicked.

I opened parts of the project and realized I couldn’t fully explain why certain structures existed anymore. Some of the architecture decisions had happened conversationally inside the agent workflow itself.

And that was the moment the entire Google I/O keynote suddenly became real to me.

The most important part of my project wasn’t living entirely inside the repository anymore.

Part of it was living inside the conversation.

The Strange Fragility of Agentic Development

That realization stuck with me more than any benchmark or demo from I/O.

Because in traditional development, source code is usually the source of truth.

If you have the repository, you have the project.

But agentic workflows quietly change that assumption.

The prompts contain planning.
The chats contain implementation reasoning.
The generated milestones contain architectural context.
The agent history contains rejected approaches and debugging decisions.

The code survives.

The understanding may not.

And honestly, I don’t think most developers have fully processed this shift yet.

We are getting very good at preserving generated output.

We are still terrible at preserving generated reasoning.

Antigravity IDE Actually Made Me Appreciate This More

Ironically, switching to Antigravity IDE made me appreciate the future of AI-assisted development more, not less.

Because it restored something important:
developer proximity.

I could inspect files directly again.
Edit architecture manually.
Stay connected to the implementation while still benefiting from agentic workflows.

That balance matters.

I don’t think the future is “developers manually writing everything forever.”

After using these systems, that future is obviously gone.

But I also don’t think developers want to become passive supervisors watching autonomous systems generate software from a distance.

The best workflows will probably be the ones that combine:

agentic speed
conversational intelligence
and deep human visibility into the code itself

Not just autonomy for the sake of autonomy.

We Need Version Control for Reasoning

Google I/O 2026 convinced me that software development is becoming increasingly conversational.

Not metaphorically.

Operationally.

And I think future developer tooling will eventually need to treat reasoning as part of the project itself:

conversational memory
implementation context
architectural discussions
milestone planning
agent decisions

Not as disposable chat history.

As infrastructure.

Because for the first time in my life, I opened a working project and still felt like part of it was missing.

And that feeling changed how I think about AI-assisted development completely.

April: The AI That Listens

Aniruddha Ghosh — Sun, 12 Apr 2026 14:14:36 +0000

This is a submission for the DEV April Fools Challenge (https://dev.to/challenges/aprilfools-2026)

What I Built

I built April, a chatbot that doesn’t chat.

April looks like a normal assistant: chat window, typing indicator, blinking eyes. You type. You wait. You try again. April never replies. She only watches and listens.

The joke is simple: we’ve been trained to expect instant answers from AI. April breaks that expectation by doing nothing at all, while still feeling alive through her eyes and subtle animations.

Demo

Demo video:

April’s behavior:

The eyes follow your cursor.
When you type, the eyes track your typing.
When you send a message, April appears to think… forever.
No replies. Ever.

Code

Source code: [https://github.com/AniruddhaGhosh64/april-listens]

How I Built It

I built April using Google Antigravity and vibe-coding my way through the UI.

Frontend: HTML, CSS, JavaScript (generated and iterated using Antigravity)
Animations: CSS + JavaScript for eye tracking, blinking, and typing animations
Logic: Purely client-side behavior. April never sends a response.
No backend and no external hosting. This runs locally.

I focused on interaction design rather than infrastructure. The goal was to make something that feels intelligent without actually being intelligent.

Prize Category

I’m submitting this for the Community Favorite category.

The idea isn’t technical complexity, but emotional reaction. People laugh, then get uncomfortable, then try again anyway. The joke only works when someone interacts with it.

April listens. Always.

Notion Workspace Operating System (Workspace OS)

Aniruddha Ghosh — Sun, 29 Mar 2026 17:37:42 +0000

🚀 Notion MCP Challenge Submission
🧠 What I Built

I built a Notion Workspace Operating System (Workspace OS) powered by Notion MCP + n8n automation, deployed on DigitalOcean.

This system transforms Notion from a passive note-taking tool into an active, intelligent workflow engine that can:

Automatically process incoming data (tasks, notes, ideas)
Categorize and structure information dynamically
Trigger workflows and actions based on context
Maintain a centralized “second brain” with minimal manual effort

🔥 Core Idea

Instead of manually organizing everything in Notion like it’s 2018, this system:

Captures → Processes → Organizes → Acts automatically using MCP + automation pipelines.

🎥 Video Demo

(Insert your Loom / YouTube link here)

Suggested structure for your demo:

Show Notion workspace (Tasks, Projects, Docs DBs)
Add a new entry (manual input/webhook trigger)
Show n8n workflow executing
Show automated categorization + linking in Notion
Highlight MCP interaction (context-aware structuring)

*💻 Show Us the Code
*
🔗 GitHub Repository: (insert your repo link here)

*Key Components:
*

n8n Workflows
Webhook trigger
Data processing nodes (Function / Python)
Notion API nodes
MCP Integration Layer
Context-aware structuring
Smart routing of entries (Tasks / Docs / Projects)
Deployment
Hosted on DigitalOcean (Droplet)
Docker-based setup for n8n

*Tech Stack:
*- Notion API + MCP

n8n (Dockerized)
DigitalOcean (Cloud Hosting)
Python (for logic processing)
GitHub (Version Control)

*⚙️ How I Used Notion MCP
*
Notion MCP is the brain of the system. Instead of treating Notion as static storage, MCP enables:

*🧩 1. Context-Aware Structuring
*
Incoming data is intelligently classified into:

Tasks
Projects
Knowledge Docs

MCP helps interpret intent + context, not just raw input.

*🔄 2. Dynamic Workflow Automation
*
Using MCP + n8n:

Entries trigger workflows automatically
Relationships between databases are created dynamically
Metadata (tags, priority, category) is auto-assigned

*🧠 3. Intelligent Second Brain
*
The system behaves like a lightweight AI assistant:

Organizes information without manual tagging
Maintains clean database relationships
Reduces cognitive load

*⚡ 4. Real-Time Processing Pipeline
*
Flow:

Input (manual/webhook)
n8n triggers workflow
MCP processes context
Data is structured + inserted into Notion
Linked across relevant databases

🏗️ Architecture Overview
Frontend: Notion Workspace (UI layer)
Automation Engine: n8n (self-hosted via Docker)
Intelligence Layer: MCP (context + structuring)
Cloud Hosting: DigitalOcean

💡 Key Features
✅ Automated task & knowledge management
✅ Context-aware classification (via MCP)
✅ Zero manual organization workflow
✅ Scalable cloud-based automation
✅ Clean relational Notion architecture

🚧 Challenges & Solutions

Notion API Structuring Problem: Handling relational fields dynamically Solution: Built flexible mapping logic in n8n
Workflow Failures After Splitting Nodes Problem: Execution errors in multi-step pipelines Solution: Simplified architecture + better data flow handling
Deployment Issues Problem: Initial hosting limitations Solution: Migrated to DigitalOcean using student credits + Docker

**🌱 What’s Next
**Add AI summarization for notes
Implement natural language task creation
Build a dashboard for workflow monitoring
Expand MCP usage for deeper reasoning

*🏁 Final Thoughts
*
This project turns Notion into a true productivity OS instead of just a workspace.

By combining:

Notion MCP (intelligence)
n8n (automation)
Cloud deployment (scalability)

…I created a system that thinks, organizes, and acts with minimal human effort.