Here is the technical breakdown of how I’m running Gemma 4 on a constrained system to own my entire development lifecycle.

The Stack: Why Gemma 4?

I chose Gemma 4 as the primary driver for its logic-to-weight ratio. While Qwen 3 is a solid backup for multilingual reasoning, Gemma 4 hits the sweet spot for React/Next.js code generation and complex system architecture.

• Privacy: Zero data leakage.

• Latency: Sub-millisecond response times.

• Context: No more worrying about token costs while debugging heavy repos.

Hardware vs. Tooling: Ollama or LM Studio?

The choice of engine depends entirely on your system's "personality."

Since I prioritize a minimalist, CLI-driven workflow, I went with Ollama. It keeps my system resources lean while serving the model as a local endpoint.

The Workflow: Aider + Local LLM

Aider is the bridge that makes local AI feel like a superpower. It’s an autonomous terminal tool that treats your local model like a senior pair programmer.

1. Orchestration: Point Aider to your local Ollama port.

2. Execution: Ask for feature updates directly in the terminal.

3. Result: Gemma 4 processes the intent, and Aider applies the git-aware edits to your code.

The 8GB RAM Constraint: Quantization is Key

Running a 2026-tier model on 8GB of RAM is an exercise in optimization. To keep the machine from swapping to disk, I used 4-bit quantization. This reduces the memory footprint by over 60% with negligible loss in coding accuracy.

The Technical Implementation

Fire up the Engine (Ollama)

Once the app is installed, pull the specific model version. I suggest starting with the 4-bit quantized version to save your RAM.

PowerShell

#Pull the model to your local library

ollama pull gemma4:4b

#Run and verify the model is active

ollama run gemma4:4b

The Aider Integration

Aider needs to know where your local "brain" is living. Since Ollama serves models on port 11434 by default, we point Aider there.

PowerShell

#Install Aider in your project environment

pip install aider-chat

#Launch Aider pointing to your local Gemma instance

aider --model ollama/gemma4

Memory Management (The 8GB Survival Script)

If your system is struggling, you can check exactly what is eating your memory before you start. I use a quick one-liner to find and kill heavy processes that aren't needed for the current build.

PowerShell

#Check for the top 5 memory hogs

ps | sort –p ws | select –last 5

Pro-tip: Kill your Docker containers and heavy browser caches before starting a long inference session. Every megabyte counts when you're running the brain and the dev server on the same chip.

I have been working on a project that will match the vibe and not the stress. As a product engineer I set one rule for VibeFit: if user have to type "Yellow", "Cotton", or "Summer" , I've failed. In 2026 we don't build CRUD apps for users to deal with same stress on screen that they already bear off screen, instead we build intent-based engines.

Orchestrating the invisible:

Most devs go for monolith Express server to handle AI logic. But in AI driven product, your backend is the logic glue, it's not just a gatekeeper for a DB.

I chose n8n orchestration, and here's the engineering reality:

• Observability over black box code: We've been developing the apps by checking logs and debuggers, and it do take time. When Gemini return a JSON object wrapped in markdown, I don't want to go through the logs, I want to see exactly where the pipe leaked on a visual canvas.

• Decoupling the Stylist: My Next.Js frontend should not care about how Gemini-2.5 Flash tags a photo. So I offloaded this to keep the Main Thread Lean, focusing on premium UX.

fig: The VibeFit Ingestion Pipeline: Turning raw pixels into structured semantic data.

The classic Latency Tax:
Most AI products break (right at the UX), when you upload a photo, and the app shows a spinner for 8 seconds while the AI is thinking. For VibeFit I decided to treat this AI Thinking as a background task, and named it Shadow Ingestion.

How exactly Shadow Ingestion works:

1. The handshake: User uploads the image and UI returns a "Success" state in <200ms.

2. The Background task: An n8n webhook takes the image, hits Gemini 2.5 Flash for visual tagging, and OpenAI for a 1536-dimension embedding.

3. The Reveal: As soon as background processing is done, the database updates, and the item is shown into the wardrobe via a Supabase real-time subscription.

The user thinks its magic. The reality is just asynchronous orchestration hygiene.

The bottom line: AI product is only as good as its data glue. With manual ingestion, your app is already dead, no matter how better the ui/ux is. By automating the extraction of vibes and not just categories, I've built the foundation for a true RAG experience.

Next in the series: The Math of Style: Why I chose pgvector for 1536-dimension similarity matching.

Most devs look at their React code or their Tailwind classes. They’re looking in the wrong place.

The problem isn't your UI library. The problem is that you’re Microtask-smothering your browser.

The 2026 Conundrum: The "Infinite" VIP Line

In the "classic" web, we had a few promises here and there. In 2026, we have Streams.

Every time your AI agent emits a token, or your local vector DB returns a similarity match, you’re likely firing a Promise.resolve() or an await. In JavaScript land, these are Microtasks.

Here’s the dirty secret: The Event Loop is a pushover. It sees a Microtask and says, "Come right in, VIP!" The problem? If your AI is streaming 60 tokens per second and you’re updating state for every single one, that "VIP line" never ends.

The browser wants to paint the next frame (the Macrotask). It’s literally begging to show the user the scroll animation. But the Event Loop says, "Sorry, I have 400 more microtasks to finish first."

Why setTimeout is Obsolete

For years, we "fixed" this by throwing a setTimeout(fn, 0) into the loop. It worked, but it was a blunt instrument. It forced the continuation to the back of the entire macrotask queue, losing its priority context.

In 2026, we use the Prioritized Task Scheduling API.

await scheduler.yield() is the surgical way to breathe. Unlike setTimeout, it yields to the browser to let it paint, but then it picks your task back up with the same priority it had before. You get the fluidity of a paint-cycle without the overhead of re-queuing from scratch.

Defending the INP (Interaction to Next Paint)

If you’re building a Product, you aren't just "writing code"—you're managing Interaction to Next Paint (INP).

If your AI loop consumes the thread for more than 50ms, your INP is going to blow past the 200ms "Good" threshold. You might think your app is fast because the tokens are appearing, but your user thinks it's broken because they can't click "Settings" while the AI is talking.

Main Thread Hygiene is the new performance frontier.

JavaScript

// Don't just loop. Orchestrate.
async function processAIStream(stream) {
  let lastYield = performance.now();

  for await (const token of stream) {
    updateUI(token);

    // If we've been working too long (50ms+), 
    // give the browser a chance to paint and handle user clicks.
    if (performance.now() - lastYield > 50) {
      // The 2026 approach: Yield while maintaining priority
      if (typeof scheduler !== 'undefined' && scheduler.yield) {
        await scheduler.yield();
      } else {
        // Fallback for older environments
        await new Promise(resolve => setTimeout(resolve, 0));
      }
      lastYield = performance.now();
    }
  }
}

The Bottom Line

In an era where AI can write the logic for you, your value as an engineer isn't in writing the loop—it's in orchestrating the execution. If you can't keep your INP under 200ms while running a local LLM or a heavy stream, you aren't building a 2026 product; you’re building a legacy site with a modern coat of paint.

Stop treating the Event Loop like a black box. Start yielding.

Deployments were slow. Uploads were painful. And the easy excuse was:
“Big app. Happens.”

Nah.

So I opened the bundle and started pulling it apart.

This post walks through:

• How I analyze a production build when something feels off

• What usually hides inside large React bundles

• The architectural fixes that brought it down from 68MB to 21MB

Because this isn’t about shaving numbers for fun.
It’s about faster deploys, better caching, quicker rollbacks — and not panicking on release day.

If you're shipping frontend to production, this stuff matters.

Step 1 — Quick Win: Kill Source Maps in Production

First check: production was generating source maps.

Turned that off.

68MB → 25MB instantly.

Good win.
But that still left 25MB of actual application code.

So the real question became:

What exactly are we shipping to users?

Step 2 — What Are We Actually Shipping?

A production bundle is basically a giant, minified blob.

Manually scanning files isn’t realistic.
So I generated build stats and ran them through a Webpack bundle analyzer.

The treemap visualization made it very obvious where the weight was coming from.

In a clean, role-based SaaS architecture:

• The main bundle should contain only core app logic

• Feature libraries should load with their routes

• Heavy libraries (charts, PDF tools, editors, etc.) should not sit in the entry chunk unless truly global

The visualization made one thing clear — that separation wasn’t strict.

And that’s where the real fixes started.

Step 3 — Keep Route-Level Dependencies Out of the Main Bundle

While reviewing the treemap, one thing stood out.

Highcharts was inside the main bundle.

That didn’t make sense.

Charts were used only inside dashboards.
Dashboards were lazy-loaded per role.

After tracing imports, I found this in the root entry file:

import Highcharts from "highcharts";

Highcharts.setOptions({
  chart: {
    style: {
      fontFamily: "'Poppins', sans-serif",
    },
  },
});

That one import was enough.

Even though routes were lazy-loaded, the dependency wasn’t.

So every single user — even those who never opened a dashboard — was downloading a charting library.

Fix

I moved the chart configuration into a dedicated chart module and imported it only inside chart-related components.

Rebuilt.

25MB → 21MB.

More importantly:

• Highcharts was removed from the main bundle

• It now loads only when a dashboard loads

• Route-based code splitting started behaving correctly

This wasn’t just about shaving 4MB.

It was about making sure users download only what they actually use.

Step 4 — Don’t Ship Two Libraries for One Problem

During dependency audit, both moment and dayjs were present.

Classic enterprise pattern.

Features get added. Libraries stick around.

But duplicate libraries mean:

• Bigger bundle

• More cognitive load

• More maintenance surface area

Before removing anything, I evaluated:

• Actual feature usage in the codebase

• Edge cases (timezones, parsing, formatting)

• Bundle size impact using tools like Bundlephobia

dayjs covered our requirements with a smaller footprint.

So I standardized on dayjs, replaced remaining moment usage, and removed it.

Result:

• Leaner dependency graph

• Smaller production build

• Cleaner architectural boundary

Optimization isn’t always about clever tricks.

Sometimes it’s about deliberate decisions.

Step 5 — Static Assets Matter Too

JavaScript isn’t the only thing that grows silently.

Over time, the /public folder had accumulated unused images and static assets — old design iterations, deprecated illustrations, leftover icons.

These don’t show up in JS bundle analyzers, but they:

• Increase deployment size

• Slow down uploads

• Add unnecessary storage and CDN overhead

A quick audit removed unused files and cleaned up the directory structure.

Performance isn’t just about code.

It’s about everything being shipped.

What I Look For in Enterprise Bundle Optimization

From this experience, these are the patterns I now actively check:

1. Entry Point Imports

Anything imported in index.tsx or root files becomes part of the main bundle.

Global configuration imports must be intentional.

2. Feature Isolation

Route-based apps should reflect in bundle structure.

If dashboards are lazy-loaded, their heavy dependencies must be lazy-loaded too.

3. Duplicate Libraries

Multiple libraries solving the same problem should be evaluated and standardized.

4. Heavy Libraries

Charts, PDF tools, editors, icon packs — common bloat sources.

They should be lazy-loaded, dynamically imported, or replaced with lighter alternatives.

5. Raw Code vs Dependency

Sometimes small utilities are better implemented in-house instead of importing an entire package.

Dependency discipline matters in enterprise systems.

Final Results

Key Learnings

• Bundle size reflects architecture decisions.

• Lazy loading works only when dependencies are isolated correctly.

• Root-level imports can silently defeat code splitting.

• Regular dependency audits are essential in growing codebases.

• Optimization isn’t about removing libraries — it’s about structuring intentionally.

This experience changed how I think about performance in React systems.

Instead of optimizing at the end, bundle structure is now treated as part of architecture design from day one.