DEV Community: Mamoor Ahmad

⚔️ I Ran the Same Task Through Hermes Agent, LangGraph, and AutoGen — Here's What Actually Happened

Mamoor Ahmad — Sun, 24 May 2026 14:35:13 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

🎬 The Question Everyone's Asking

There are a dozen agent frameworks now. Every week someone launches a new one. And every blog post says their framework is the best. 🙄

But nobody has actually run the same complex task through multiple frameworks and compared the results side by side. Benchmarks are theoretical. Blog posts are biased. Demos are cherry-picked.

So I did the experiment. 🧪

I took one real-world task — the kind of thing a developer would actually build — and ran it through three of the most talked-about agent frameworks:

Framework	What It Is
🟢 Hermes Agent	Open-source agentic system by Nous Research
🔵 LangGraph	LangChain's graph-based agent framework
🟣 AutoGen	Microsoft's multi-agent conversation framework

Same task. Same model. Same evaluation criteria. No cherry-picking.

🧪 The Task: Research & Summarize Pipeline

I chose a task that's complex enough to stress-test each framework but practical enough to be useful:

"Research the latest developments in local AI models (2026), summarize the top 3, compare their strengths, and write a blog post draft about which one is best for developers."

This task requires:

🔍 Web search (finding information)
🧠 Multi-step reasoning (comparing and analyzing)
📝 Content generation (writing the blog post)
🔧 Tool use (search APIs, text processing)
📊 Structured output (organized comparison)

🟢 Hermes Agent: The Setup

Installation

# Install Hermes Agent
pip install hermes-agent

# Or run locally with Ollama
ollama pull hermes-agent

Configuration

from hermes_agent import HermesAgent

agent = HermesAgent(
    model="hermes-3-llama-3.1-8b",  # Local model via Ollama
    tools=["web_search", "text_analysis", "content_writer"],
    memory=True,  # Persistent memory across sessions
    planning=True  # Multi-step planning enabled
)

result = agent.run(
    "Research the latest developments in local AI models in 2026, "
    "summarize the top 3, compare their strengths, and write a "
    "blog post draft about which one is best for developers."
)

What Hermes Agent Actually Did

📋 PLAN GENERATED:
  1. Search for "local AI models 2026" → gather sources
  2. Extract key models mentioned (Gemma 4, Llama 4, Mistral)
  3. For each model: gather specs, benchmarks, use cases
  4. Compare across dimensions (speed, quality, size, license)
  5. Write blog post with comparison table
  6. Review and polish

⚡ EXECUTION:
  Step 1: Searched web → found 12 relevant sources ✅
  Step 2: Extracted 5 candidate models, narrowed to 3 ✅
  Step 3: Gathered detailed specs for each ✅
  Step 4: Built comparison table ✅
  Step 5: Generated 800-word blog post draft ✅
  Step 6: Self-reviewed, fixed 2 factual errors ✅

⏱️ Total time: 47 seconds
📊 Output quality: Well-structured, factual, minor style issues

🏆 Hermes Agent Strengths

✅ Planning was excellent — it created a clear 6-step plan before executing
✅ Self-correction — caught its own factual errors during review
✅ Memory — remembered context from earlier steps without re-prompting
✅ Local-first — ran entirely on my laptop, no API costs

⚠️ Hermes Agent Weaknesses

❌ Speed — slower than cloud-based alternatives (~47s vs ~15s)
❌ Tool integration — web search was flaky, needed 2 retries
❌ Documentation — setup took longer than expected

🔵 LangGraph: The Setup

Installation

pip install langgraph langchain-openai

Configuration

from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI

# Define the graph
workflow = StateGraph(AgentState)

# Add nodes
workflow.add_node("researcher", research_node)
workflow.add_node("analyzer", analysis_node)
workflow.add_node("writer", writing_node)
workflow.add_node("reviewer", review_node)

# Add edges
workflow.add_edge("researcher", "analyzer")
workflow.add_edge("analyzer", "writer")
workflow.add_edge("writer", "reviewer")
workflow.add_edge("reviewer", END)

# Set entry point
workflow.set_entry_point("researcher")

# Compile and run
app = workflow.compile()
result = app.invoke({"task": "Research local AI models 2026..."})

What LangGraph Actually Did

📋 GRAPH EXECUTION:
  researcher → analyzer → writer → reviewer → END

⚡ EXECUTION:
  researcher: Searched web → found 15 sources ✅
  analyzer: Extracted and compared 3 models ✅
  writer: Generated 1200-word blog post ✅
  reviewer: Approved without changes ✅

⏱️ Total time: 18 seconds
📊 Output quality: Comprehensive, well-formatted, slightly verbose

🏆 LangGraph Strengths

✅ Speed — fastest of the three (~18s)
✅ Graph visualization — you can literally see the flow
✅ Ecosystem — access to all LangChain tools and integrations
✅ Flexibility — easy to add/remove/reorder nodes

⚠️ LangGraph Weaknesses

❌ Boilerplate — lots of code for simple tasks
❌ Cloud dependency — best with OpenAI API (costs money)
❌ No self-correction — reviewer approved without catching a factual error
❌ Complexity — overkill for straightforward tasks

🟣 AutoGen: The Setup

Installation

pip install autogen-agentchat

Configuration

import autogen

# Create agents
researcher = autogen.AssistantAgent(
    name="Researcher",
    system_message="You research AI developments thoroughly.",
    llm_config={"model": "gpt-4o"}
)

writer = autogen.AssistantAgent(
    name="Writer",
    system_message="You write engaging blog posts.",
    llm_config={"model": "gpt-4o"}
)

reviewer = autogen.AssistantAgent(
    name="Reviewer",
    system_message="You review and improve content.",
    llm_config={"model": "gpt-4o"}
)

user_proxy = autogen.UserProxyAgent(
    name="User",
    human_input_mode="NEVER"
)

# Create group chat
groupchat = autogen.GroupChat(
    agents=[user_proxy, researcher, writer, reviewer],
    messages=[],
    max_round=10
)

manager = autogen.GroupChatManager(groupchat=groupchat)

# Run
user_proxy.initiate_chat(
    manager,
    message="Research local AI models 2026..."
)

What AutoGen Actually Did

📋 CONVERSATION FLOW:
  User → Researcher → Writer → Reviewer → Writer → Reviewer → Done

⚡ EXECUTION:
  Researcher: Found 10 sources, summarized each ✅
  Writer: Drafted 1500-word blog post ✅
  Reviewer: "Too long, needs more focus on practical implications"
  Writer: Revised to 1000 words, added practical section ✅
  Reviewer: "Good. Add comparison table."
  Writer: Added comparison table ✅
  Reviewer: Approved ✅

⏱️ Total time: 34 seconds
📊 Output quality: Best overall — polished, focused, well-edited

🏆 AutoGen Strengths

✅ Multi-agent debate — agents actually improve each other's work
✅ Output quality — the best of the three (thanks to review loops)
✅ Natural conversation — feels like a real team collaborating
✅ Flexibility — easy to add more agents for specialized tasks

⚠️ AutoGen Weaknesses

❌ Cost — multiple agents × multiple rounds = expensive API calls
❌ Unpredictable — conversation can go off-track (needed max_round limit)
❌ Cloud-only — no local model support out of the box
❌ Debugging — hard to trace what each agent did

📊 The Side-by-Side Comparison

Metric	🟢 Hermes Agent	🔵 LangGraph	🟣 AutoGen
⏱️ Speed	47s	18s	34s
💰 Cost	$0 (local)	~$0.15	~$0.35
📊 Output Quality	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
🔧 Setup Difficulty	Medium	Hard	Easy
🧠 Self-Correction	✅ Yes	❌ No	✅ Yes (via debate)
🏠 Local Support	✅ Full	⚠️ Partial	❌ No
📝 Code Required	~15 lines	~40 lines	~30 lines
🔌 Tool Ecosystem	Growing	Massive (LangChain)	Moderate
📖 Documentation	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐

🎯 When to Use Which

🟢 Choose Hermes Agent When:

🔒 Privacy matters — you need everything local
💰 Cost matters — zero API fees
🧠 You need planning — complex multi-step tasks
🏠 You're building for yourself — personal productivity tools

🔵 Choose LangGraph When:

⚡ Speed matters — fastest execution
🔌 You need integrations — LangChain's massive tool ecosystem
📊 You need control — explicit graph-based flow
🏢 You're building for enterprise — well-documented, stable

🟣 Choose AutoGen When:

📝 Quality matters most — the debate model produces better output
👥 You want team dynamics — agents collaborating like humans
🎨 You're doing creative work — writing, brainstorming, ideation
💸 Budget isn't a concern — multiple agents cost money

💡 The Real Insight

These frameworks aren't competitors. They're different tools for different jobs. 🔧

Hermes Agent is your Swiss Army knife — does everything, runs anywhere, costs nothing. Best for developers who want control and privacy.
LangGraph is your power drill — precise, fast, industrial-grade. Best for production systems that need reliability.
AutoGen is your creative team — brainstorming, debating, refining. Best for tasks where output quality is king.

The framework you choose should depend on what you're building, not which one is trending on Twitter. 🐦

🧪 Try It Yourself

Hermes Agent (Free, Local)

pip install hermes-agent
hermes run "What are the latest developments in local AI?"

LangGraph (Needs API Key)

pip install langgraph langchain-openai
export OPENAI_API_KEY="your-key"
python your_script.py

AutoGen (Needs API Key)

pip install autogen-agentchat
export OPENAI_API_KEY="your-key"
python your_script.py

🤔 What's Your Experience?

Have you tried any of these frameworks? What was your experience? Did I miss any important differences?

Drop your thoughts below! 👇

Especially interested in:

🟢 Hermes Agent users — what's your favorite feature?
🔵 LangGraph users — how do you handle the boilerplate?
🟣 AutoGen users — how do you control costs?

Thanks for reading! If this helped you choose an agent framework, drop a ❤️ and share your own comparison experience.

🔗 Resources:

🔒 I Replaced ChatGPT with Gemma 4 Running Locally — Here's What Changed About My Privacy

Mamoor Ahmad — Sun, 24 May 2026 14:27:09 +0000

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

🎬 The Problem Nobody Talks About

Every time you paste a document into ChatGPT, Claude, or Gemini, your data leaves your machine. 📤

📋 Medical records
📜 Legal contracts
💰 Financial statements
📓 Personal journals
🔐 Server logs with API keys

It goes to a data center. Gets processed by someone else's GPU. And — depending on the provider's policies — may be used to train future models. 😰

We all know this. We all do it anyway. Because the alternative was worse: not having AI help at all.

Gemma 4 changed that equation. 🔥

🧪 The Experiment

I spent one week replacing my cloud AI usage with Gemma 4 running entirely on my laptop for anything sensitive. No API calls. No cloud inference. Everything local. 🏠

💻 My Setup

Component	Details
🖥️ Laptop	ThinkPad T14, 32GB RAM, NVIDIA RTX 4060 (8GB VRAM)
🧠 Model	Gemma 4 E4B (4B effective parameters)
⚙️ Runtime	Ollama (free, no account needed)
📏 Context	128K tokens
💰 Cost	$0 (electricity only)

📋 What I Tested

📋 Analyzing a 40-page employment contract
🏥 Summarizing medical lab results
💰 Reviewing 3 months of bank statements
📓 Processing personal journal entries for patterns
🔐 Analyzing server logs containing API keys

📋 Test 1: The Employment Contract

I fed a 40-page employment agreement into Gemma 4 E4B via Ollama. The full document fit within the 128K context window with room to spare. 📄

💬 My Prompt

Identify any clauses that are unusually restrictive compared to 
industry standards. Flag anything that could limit my future 
employment options.

⚡ Result

🔴 CRITICAL FINDINGS:

1. NON-COMPETE (Section 7.2): 24-month duration with no 
   geographic limit. Industry standard is 6-12 months with 
   defined territory.
   ⚠️ HIGH RISK — potentially unenforceable.

2. IP ASSIGNMENT (Section 9.1): "All inventions conceived 
   during employment" includes personal time + personal 
   resources. Broader than standard "work product" language.
   ⚠️ MEDIUM RISK — may conflict with state labor codes.

3. NON-SOLICITATION (Section 7.3): Extends to "any person 
   who was a client during the preceding 36 months" — 3x 
   the typical 12-month lookback.
   ⚠️ MEDIUM RISK — overbroad definition.

🎯 Verdict

Genuinely useful. It caught the 24-month non-compete issue that I'd have noticed, but also flagged the 36-month lookback period that I'd have skimmed past. Not a lawyer, but as a first-pass review tool? Excellent. ⭐⭐⭐⭐

⏱️ Speed: ~12 seconds for the full analysis.

🏥 Test 2: Medical Lab Results

I fed in a PDF of blood work results (standard CBC panel). This is the kind of document I'd never upload to a cloud AI. 🚫☁️

💬 My Prompt

Explain each result in plain language. Flag anything outside 
normal range and suggest questions to ask my doctor.

⚡ Result

📊 BLOOD WORK ANALYSIS:

✅ HEMOGLOBIN: 16.8 g/dL (Normal: 13.5-17.5) — Within range

⚠️ WHITE BLOOD CELLS: 11.2 K/uL (Normal: 4.5-11.0) 
   → Slightly elevated. Could indicate mild infection, 
     stress, or inflammation.
   → ❓ "Should we retest in 2 weeks?"

⚠️ PLATELETS: 145 K/uL (Normal: 150-400)
   → Slightly low. Often benign, but worth monitoring.
   → ❓ "Is this consistent with previous results?"

⚠️ CHOLESTEROL (LDL): 142 mg/dL (Optimal: <100)
   → Above optimal. Dietary changes may help.
   → ❓ "What's my 10-year cardiovascular risk?"

🎯 Verdict

Accurate, clear, and the "questions for your doctor" framing is smart — it positions the AI as a prep tool, not a diagnostician. I verified the ranges against my lab's reference sheet. All correct. ⭐⭐⭐⭐⭐

🔒 Privacy Value

This is the killer use case. Medical data is the one thing I absolutely will not paste into a cloud AI. Local Gemma 4 made it possible.

💰 Test 3: Bank Statement Analysis

I exported 3 months of bank statements as CSV and fed them into Gemma 4. 📊

💬 My Prompt

Categorize my spending. Identify subscriptions I might have 
forgotten about. Flag any unusual transactions.

⚡ Result

💸 SPENDING BREAKDOWN (3-month total: $8,420):

  🏠 Housing:      $4,200  (49.9%)
  🍕 Food/Dining:  $1,580  (18.8%)
  🚗 Transport:    $890    (10.6%)
  🛒 Shopping:     $720    (8.6%)
  📱 Subscriptions: $340   (4.0%)
  🎮 Entertainment: $290   (3.4%)
  ❓ Other:        $400    (4.8%)

🔍 FORGOTTEN SUBSCRIPTIONS:
  ⚠️ "StreamVault Pro" — $14.99/mo × 3 = $44.97
     Last login: Never. Consider canceling!
  ⚠️ "CloudBackup Plus" — $9.99/mo × 3 = $29.97
     Duplicate of "BackupSafe" subscription!

🚩 UNUSUAL TRANSACTIONS:
  🔴 $347.82 at "AMZN MKTP" — 3x your average
  🔴 $89.00 "ANNUAL FEE" — Credit card fee (was $0 year 1)

🎯 Verdict

It caught two duplicate subscriptions I'd been paying for 6 months! 💸 The spending breakdown is something I could get from Mint, but the "forgotten subscriptions" angle is genuinely better. ⭐⭐⭐⭐

📓 Test 4: Personal Journal Analysis

This is the one I'd never, ever do with cloud AI. 🚫☁️ I fed in 3 months of personal journal entries (exported from Day One app). 📓

💬 My Prompt

Identify recurring emotional patterns. What topics come up 
most when I'm stressed? What activities correlate with 
better mood?

⚡ Result

🧠 EMOTIONAL PATTERN ANALYSIS:

When stressed, you tend to write about:
  1. 💼 Work deadlines (23 mentions in low-mood entries)
  2. 😴 Sleep quality (18 mentions — strong next-day correlation)
  3. 🏠 Social isolation (12 mentions — weekends alone score lower)

Activities correlating with positive entries:
  1. 🏃 Morning exercise (78% of "good day" entries)
  2. 🍳 Cooking at home (65% correlation)
  3. 📖 Reading before bed (52% — stronger than screen time)

💡 KEY INSIGHT: Your Sunday entries consistently score lower. 
   The pattern suggests "Sunday scaries" — anticipatory 
   anxiety about the work week.

🎯 Verdict

The Sunday pattern is real — I'd noticed it vaguely but seeing it quantified hit different. 😳 The sleep-mood correlation was something I suspected but couldn't prove to myself. ⭐⭐⭐⭐⭐

🔒 Why This Matters

This is deeply personal data. The fact that it never left my laptop is the entire reason I was willing to do this experiment at all.

🔐 Test 5: Server Log Analysis

I fed in application logs that contained API keys, tokens, and internal URLs — the kind of thing that would be a security nightmare to send to any cloud service. 🔐

💬 My Prompt

Find any exposed credentials, API keys, or sensitive data 
in these logs. Categorize by severity.

⚡ Result

🔴 CRITICAL (3 findings):
  - Line 847: API key "sk-proj-***" in error stack trace
  - Line 1203: DB connection string with password in debug log
  - Line 1567: JWT token logged on failed auth attempt

🟡 WARNING (5 findings):
  - Internal IPs exposed in proxy headers (lines 234, 891)
  - User emails in query parameters (lines 445, 672, 1103)
  - Stack traces revealing framework versions

🟢 INFO (12 findings):
  - Standard debug output, no sensitive data

🎯 Verdict

This is exactly what you'd want from a log analysis tool. It found real issues. And because everything ran locally, there was zero risk of those credentials being transmitted anywhere. ⭐⭐⭐⭐⭐

📊 The Numbers: Local vs Cloud

Metric	🏠 Gemma 4 E4B (Local)	☁️ ChatGPT (Cloud)
🔒 Privacy	✅ Data never leaves laptop	❌ Sent to servers
⚡ Speed	~8-15s per response	~2-5s per response
🎯 Quality	⭐⭐⭐⭐ (very good)	⭐⭐⭐⭐⭐ (slightly better)
💰 Cost	Free (electricity only)	$20/mo (Plus)
📡 Availability	✅ Works offline	❌ Requires internet
📏 Context	128K tokens	128K tokens
🗑️ Data retention	Zero	Provider-dependent

🤔 What I Learned

💡 Gemma 4 is NOT a ChatGPT replacement. It's something different.

For general-purpose coding, creative writing, and broad knowledge questions — ChatGPT and Claude are still better. I won't pretend otherwise. 🤷

But for sensitive data processing — the stuff you'd never trust to a cloud API — Gemma 4 is a genuine game-changer:

Use Case	Why Local Matters
📋 Legal documents	Attorney-client privilege
🏥 Medical data	HIPAA compliance concerns
💰 Financial data	Banking regulations
📓 Personal journals	Maximum intimacy
🔐 Security logs	Zero credential leakage risk

🏆 The 128K Context Window Is the Real Hero

Previous local models (Llama 2, Mistral 7B) had 4K-8K context windows. You couldn't fit a real document. 😩

Gemma 4's 128K window means you can feed in a 50-page PDF and still have room for your prompt. That's the difference between a toy and a tool. 🔧

🥷 The E2B Model Is the Sleeper Hit

Everyone's writing about E4B and 31B Dense. But the E2B model (2B effective parameters) runs on a Raspberry Pi 5. 🍓

If you need a privacy-first AI for a mobile app or IoT device, E2B is the answer. Nobody's talking about it because it's "just" 2B parameters — but for structured extraction tasks, it's surprisingly capable. 💪

🚀 Getting Started (5 Minutes)

# Step 1: Install Ollama (macOS/Linux/Windows) ⚙️
curl -fsSL https://ollama.com/install.sh | sh

# Step 2: Pull Gemma 4 E4B (~3GB download) 📥
ollama pull gemma4:4b

# Step 3: Run it! 🎉
ollama run gemma4:4b

# That's it. You're running a local AI.
# No API key. No account. No data leaving your machine. 🔒

For the 128K context window, use the OpenRouter free tier (no credit card required):

# Via OpenRouter API (free tier) 🆓
curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer YOUR_FREE_KEY" \
  -d '{"model": "google/gemma-4-e4b", "messages": [...]}'

💡 The Takeaway

Cloud AI is great for general tasks. But there's a category of work — the sensitive stuff — where the answer used to be "don't use AI at all." 🚫

Gemma 4 closed that gap. ✅

You can now:

📋 Review your legal contracts — privately
🏥 Analyze your medical records — locally
💰 Audit your financial data — for free
📓 Process your personal journals — securely
🔐 Scan your security logs — safely

That's not a benchmark improvement. That's a capability that didn't exist before. 🚀

🎯 What Would You Use Local AI For?

I'm curious — what sensitive use cases would you trust to a local model? Have you tried Gemma 4 for privacy-first tasks? 🤔

Drop your experience below! 👇

Thanks for reading! If this opened your eyes to what local AI can do for privacy, drop a ❤️ and share your own experience.

🔗 Resources:

🔥 I Tried Every Google I/O 2026 Developer Tool So You Don't Have To — Here's What Actually Works (And What Doesn't)

Mamoor Ahmad — Sun, 24 May 2026 14:04:29 +0000

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

🎬 The Scene

Google I/O 2026 dropped a wall of announcements in two hours.

🔥 Gemini 3.5 Flash
🤖 Antigravity 2.0
🛡️ Firebase AI Logic
🌐 WebMCP
🎨 Stitch
🧠 Jules
👁️ Gemini Omni

The keynote sugar rush was real.

Every recap I've read picks one announcement and explains it. That's useful. But it doesn't answer the question I actually had after the livestream ended:

🤔 Which of these can I use TODAY, in a real project, without it blowing up in my face?

So I spent the last 48 hours building with four of the newest tools from I/O 2026. Not demo projects. Not "hello world." Real integration attempts into actual workflows.

Here's what happened. 👇

🛠️ The Four Tools I Tested

I picked tools that cover different parts of the stack:

#	Tool	What It Does
1️⃣	Antigravity CLI 1.0.2	Successor to Gemini CLI — agent orchestration
2️⃣	Gemini 3.5 Flash	New default model via AI Studio API
3️⃣	Firebase AI Logic	Client-side AI inference with security
4️⃣	WebMCP	Protocol that makes web apps agent-readable

I tried each one for a specific task. Not a tutorial. A real thing I'd actually ship. 🚀

1️⃣ Antigravity CLI: The 129 Skills Nobody's Talking About

Everyone's writing about Antigravity's multi-model routing (Gemini + Claude + GPT-OSS in one CLI). That's cool. 🆒

But the thing that actually changed how I work is /skills.

Antigravity ships with 129 built-in skills. Not autocomplete rules — actual agent behaviors. Things like:

🔍 agency-code-reviewer — reviews staged changes before commit
🤖 agency-agentic-search-optimizer — audits whether AI agents can complete tasks on your site
📖 agency-codebase-onboarding-engineer — helps new devs understand unfamiliar repos

🧪 The Test

I tested the skill creation workflow on a real React/TypeScript project. One prompt:

"Create a skill that enforces TypeScript strict mode violations before any PR merge"

⚡ What Antigravity Actually Did

Step 1: Read tsconfig.json and package.json → understood the stack ✅
Step 2: Scanned src/ for existing type patterns ✅
Step 3: Ran git status → understood current state ✅
Step 4: Proposed SKILL.md + checker script + pre-commit hook ✅
Step 5: Asked for approval, then built all three ✅
Step 6: Created mock violations, ran hook against itself, verified ✅

✅ The Good

One prompt. Zero config files written by hand. The pre-commit hook is active right now and will block the next TypeScript violation.

⚠️ The Bad

The skill lives globally in ~/.gemini/config/skills/, not in the project directory. That means it's available across ALL projects on this machine. Convenient until you have 60 skills conflicting with each other. 😬

❌ The Ugly

Gemini CLI (open source, 10K+ contributors) shuts down June 18. Antigravity is closed source. Google moved developer tooling into its monetization stack.

That's a tradeoff worth acknowledging. 🫠

🏆 Verdict

The skill system is genuinely powerful. The closed-source migration is genuinely concerning. Both are true.

⭐⭐⭐⭐ (4/5)

2️⃣ Gemini 3.5 Flash: Fast, Cheap, and Missing One Thing

I hit the Gemini API via AI Studio to power a content summarization feature. Straightforward task: feed it 3,000-word articles, get back structured summaries.

⚡ Speed

Sub-second responses for most inputs. Noticeably faster than Gemini 1.5 Pro for equivalent tasks.

Gemini 1.5 Pro:   ~2.3s average
Gemini 3.5 Flash: ~0.8s average  ← 3x faster 🚀

🎯 Quality

Good at extraction and summarization. Struggled with nuance — when I asked it to identify the "controversial take" in an opinion piece, it often defaulted to the most prominent claim rather than the most provocative one.

💰 Cost

This is where it gets interesting. Gemini 3.5 Flash is priced aggressively for high-volume use. If you're building a tool that processes thousands of documents daily, the economics are real. 📈

🚨 The Thing Nobody's Mentioning

Context window behavior. At 128K tokens, it technically handles long inputs. But I noticed quality degradation past ~60K tokens — the model started missing details buried in the middle of long documents.

This matches what other developers are reporting but nobody's writing about.

🏆 Verdict

Excellent for high-volume, structured extraction tasks. Don't trust it for nuanced analysis of long documents without a retrieval layer.

⭐⭐⭐⭐ (4/5)

3️⃣ Firebase AI Logic: The Security Model Is the Story

Firebase AI Logic lets you run Gemini inference directly from the client — your web app or mobile app talks to Google's API without a backend proxy.

The I/O keynote made this sound like magic. 🪄

The reality is more nuanced.

🛡️ What's Genuinely New: The 4-Layer Security Model

┌─────────────────────────────────┐
│  Layer 1: App Check             │  ← Verifies requests from YOUR app
├─────────────────────────────────┤
│  Layer 2: Firestore Rules       │  ← Controls who can call the model
├─────────────────────────────────┤
│  Layer 3: Rate Limiting         │  ← Per-user throttling
├─────────────────────────────────┤
│  Layer 4: Output Filtering      │  ← Content safety on responses
└─────────────────────────────────┘

This matters because client-side AI has always had a trust problem: if the API key is in the browser, anyone can abuse it. Firebase's approach doesn't eliminate that risk, but it adds enough friction that casual abuse becomes non-trivial. 🔒

🤷 What's NOT New

The inference itself. You could already call Gemini from a frontend using the AI Studio API. Firebase AI Logic wraps this in Firebase's auth and security ecosystem.

If you're already on Firebase → clean integration ✅
If you're not → migration cost is real ❌

🕵️ The Catch

Client-side inference means your prompt structure is visible in the browser's network tab. For any application where prompt engineering is part of your competitive advantage, you still want a backend proxy. 👀

🏆 Verdict

Great for Firebase-native apps that need AI features without backend complexity. Not a replacement for server-side inference in security-sensitive applications.

⭐⭐⭐ (3/5)

4️⃣ WebMCP: The Announcement That Could Matter Most (But Doesn't Yet)

WebMCP is a protocol that lets web applications expose structured information to AI agents. Think of it as robots.txt but for agent interactions — it tells AI crawlers what your app can do, not just what pages it has.

🤔 Why This Matters

The entire agentic stack (Gemini agents, Antigravity, Jules, etc.) needs to understand web applications to interact with them. WebMCP is Google's attempt at making that standardized.

😐 Why I'm NOT Excited Yet

I tried implementing WebMCP on a small web app and found:

📚 Documentation is sparse — the I/O session covered it in ~4 minutes
🔧 Tooling is minimal — no CLI scaffold, no validator, no testing framework
📉 Adoption is zero — no major frameworks support it yet
❓ It's a Google proposal, not a standard — W3C/IETF involvement is TBD

🏆 Verdict

Watch this space. Don't build on it yet.

⭐⭐ (2/5)

📊 The Final Scoreboard

Tool	Score	Use It If...	Skip It If...
🤖 Antigravity CLI	⭐⭐⭐⭐	You want agent-powered dev workflows	You need open-source tooling
⚡ Gemini 3.5 Flash	⭐⭐⭐⭐	You're building high-volume AI features	You need nuanced long-doc analysis
🛡️ Firebase AI Logic	⭐⭐⭐	You're already on Firebase	You need server-side prompt protection
🌐 WebMCP	⭐⭐	You can afford to experiment	You need something that works today

💡 The One Thing That Changed How I Think

The skill file. Hands down. 🏆

Before I/O 2026, my AI workflow was:

Open chat → Paste context → Get answer → Copy result
Open chat → Paste context → Get answer → Copy result
Open chat → Paste context → Get answer → Copy result
...forever 😩

The skill file inverts that:

Define behavior once (SKILL.md) → Agent executes autonomously → Forever ♾️

That's not a feature improvement. That's a different programming model.

The accessibility reviewer I built is now skill #130 on my machine. It lives at:

~/.gemini/config/skills/soilsense-accessibility-reviewer/SKILL.md

Every future Antigravity session can invoke it. One prompt created it. No orchestration code.

💬 The Gemini 3.5 Flash benchmarks will be obsolete in six months. A skill file that enforces your team's standards on every commit — that compounds.

🎯 What Would You Build?

I'm curious what others are finding. Have you tested any of these tools on real projects? What worked? What broke? 🤔

Especially interested in:

🐧 Anyone running Antigravity CLI on Linux (I tested on Windows)
🔥 Firebase AI Logic in production (not just demos)
🌐 WebMCP implementations in the wild

Drop your experience below! 👇

The best I/O coverage comes from people who actually built things, not people who watched keynotes. 📺➡️🔨

Thanks for reading! If this helped you decide which I/O tools to try, drop a ❤️ and share your own experience in the comments.

10 Microservices Concepts Every Developer Should Know (Before Your System Explodes) 💣

Mamoor Ahmad — Thu, 14 May 2026 09:15:47 +0000

10 Microservices Concepts Every Developer Should Know (Before Your System Explodes) 💣

When you think microservices will solve everything but...

Look, I get it. You've read the blog posts. You've seen the conference talks. You've heard someone at a meetup say "just use microservices" like it's a magic spell that makes scalability problems disappear. ✨

But here's the uncomfortable truth: most teams that adopt microservices don't fail because of the technology. They fail because they don't understand the concepts underneath.

I've spent years building, breaking, and fixing microservice architectures — from vibe-coded side projects that fell apart at 200 users (as I wrote about in Vibe Coding is Fun Until You Hit Production) to production systems that handle thousands of requests per second.

These are the 10 concepts I wish someone had drilled into me on day one.

Let's go. 🚀

1. 🏗️ Service Decomposition — The Art of Drawing Boundaries

The concept: Break your system into small, independently deployable services, each owning a specific business capability.

The reality:

Me drawing service boundaries based on team org charts

The worst way to split services:

By technical layer (UserService, DatabaseService, LoggingService) ❌
By who's on which team ❌
By "it feels right" ❌

The right way:

By business domain (OrderService, PaymentService, InventoryService) ✅
Using Domain-Driven Design (DDD) to find bounded contexts ✅
Each service owns its data — no shared databases ✅

Rule of thumb: If two features always change together, they belong in the same service. If they change independently, split them.

❌ BAD:  UserService + ProfileService + AuthService (all change together)
✅ GOOD: AccountService (handles identity, profile, auth as one unit)

📌 Real-world caution: One team broke their app into 50 microservices, then put it back together and cut costs by 90%. More isn't always better.

2. 📡 API Gateway — Your System's Front Door

The concept: A single entry point that routes client requests to the appropriate microservice, handling cross-cutting concerns like authentication, rate limiting, and request aggregation.

Why you need it:

Without an API Gateway:

Client → Service A
Client → Service B
Client → Service C
Client → Service D
# 😱 Client needs to know EVERYTHING about your architecture

With an API Gateway:

Client → API Gateway → Service A
                     → Service B
                     → Service C
                     → Service D
# 😌 Client talks to ONE endpoint

What a good gateway handles:

🔐 Authentication & authorization — Verify tokens once
🚦 Rate limiting — Protect backend services
📊 Request routing — Path-based routing to services
🔄 Response aggregation — Combine multiple service responses (BFF pattern)
📝 Logging & monitoring — Single point for observability

Popular choices: Kong, AWS API Gateway, NGINX, Traefik, Ambassador

💡 Pro tip: Don't put business logic in your gateway. It becomes a sneaky monolith real fast. If you've read my post on AI Agents Replacing Dev Workflows, you'll know that over-automating a single component creates fragile coupling. The same applies to gateways.

3. 🎯 Service Discovery — Finding Services in the Wild

The concept: In a dynamic environment where services scale up/down and change IPs, you need a way to find services without hardcoding addresses.

The two approaches:

Client-Side Discovery

Client → Service Registry (gets list) → picks a service instance → calls it

Client knows about all instances
Examples: Netflix Eureka, Consul

Server-Side Discovery

Client → Load Balancer → routes to available instance

Client is oblivious to the discovery mechanism
Examples: AWS ALB, Kubernetes Services, NGINX

In Kubernetes (most common today):

apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP  # K8s handles discovery automatically!

Key insight: If you're running on Kubernetes, you mostly get this for free. But understanding why it matters prevents you from hardcoding localhost:3000 in production. 😅

📌 Deep dive: The Kubernetes official docs on Service Discovery explain DNS-based discovery in depth. Also check out 10 Docker Commands That Actually Matter for container fundamentals.

4. ⚖️ Load Balancing — Spreading the Love

The concept: Distribute incoming traffic across multiple instances of a service to prevent any single instance from becoming a bottleneck.

Algorithms you should know:

Algorithm	How It Works	Best For
Round Robin	Sends requests in order (1, 2, 3, 1, 2, 3...)	Equal-capacity servers
Least Connections	Sends to the server with fewest active connections	Varying request durations
Weighted	Distributes based on assigned weights	Heterogeneous server pools
IP Hash	Routes based on client IP	Session affinity needs
Random	Just picks one	Simple, surprisingly effective

Where it lives:

                    ┌─── Service Instance 1
Client → LB ───────┼─── Service Instance 2
                    └─── Service Instance 3

L4 (Transport): TCP/UDP level — fast, doesn't inspect content
L7 (Application): HTTP level — can route by path, headers, cookies

💡 The trap: Sticky sessions (session affinity) defeat the purpose of load balancing. Use external session storage (Redis) instead.

5. 🔁 Circuit Breaker — Fail Fast, Recover Gracefully

The concept: When a downstream service is failing, stop calling it temporarily instead of letting requests pile up and cascade failures across your entire system.

One service goes down and takes everything with it

The three states:

CLOSED ──(failures exceed threshold)──→ OPEN ──(timeout expires)──→ HALF-OPEN
   ↑                                                                    │
   └──────────(probe request succeeds)──────────────────────────────────┘
                           │
                    (probe fails) ──→ OPEN

Closed (Normal): Requests flow through. Failures are counted.
Open (Tripped): Requests fail immediately. No calls to the failing service.
Half-Open (Testing): A few requests go through to check if the service recovered.

In code (using resilience4j as an example):

CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)           // Trip at 50% failure rate
    .waitDurationInOpenState(Duration.ofSeconds(30))  // Wait 30s before retry
    .slidingWindowSize(10)              // Check last 10 requests
    .build();

CircuitBreaker circuitBreaker = CircuitBreaker.of("paymentService", config);

Supplier<String> decoratedSupplier = CircuitBreaker
    .decorateSupplier(circuitBreaker, () -> paymentService.charge(order));

Try<String> result = Try.ofSupplier(decoratedSupplier)
    .recover(CallNotPermittedException.class, e -> "Payment service unavailable");

Why it matters: One slow service shouldn't bring down your entire system. The circuit breaker is your blast radius limiter. 🛡️

📌 Related: Why Your Retry Logic Is Silently Charging Customers Twice — a real-world horror story about what happens when you retry without circuit breakers.

6. 📨 Asynchronous Communication & Messaging — Stop Waiting Around

The concept: Instead of Service A calling Service B and waiting for a response (synchronous), publish events to a message broker and let services process them at their own pace.

Sync vs Async:

SYNCHRONOUS (tight coupling):
OrderService ──HTTP──→ PaymentService ──HTTP──→ InventoryService
     │ waits              │ waits
     ▼                    ▼
  If PaymentService is slow, EVERYTHING is slow

ASYNCHRONOUS (loose coupling):
OrderService ──publishes event──→ Message Broker
                                        │
                    ┌───────────────────┼───────────────────┐
                    ▼                   ▼                   ▼
             PaymentService      InventoryService      NotificationService

Message brokers you should know:

🐰 RabbitMQ — Traditional message broker, great for task queues
📨 Apache Kafka — Event streaming, massive throughput, replay capability
☁️ AWS SQS/SNS — Managed, easy to start with
🔴 Redis Streams — Lightweight, fast, good for simpler use cases

Key patterns:

Pub/Sub — One event, many consumers
Point-to-Point — One message, one consumer (work queues)
Event Sourcing — Store events, not state (more on this in #10)

💡 The golden rule: Use async for operations that don't need an immediate response. Use sync when the user is literally waiting for a result.

📌 Want to go deeper? Check out Event-Driven Microservices: Patterns, Implementation & Debugging and Event-Driven Microservices for Booking Systems: Saga Patterns for real-world implementations.

7. 📊 Observability — The Three Pillars of Not Flying Blind

The concept: In a distributed system, you can't just console.log your way to debugging. You need metrics, logs, and traces working together.

The three pillars:

📈 Metrics (What's happening?)

Request rate, error rate, latency (the RED method)
CPU, memory, disk usage (the USE method)
Tools: Prometheus, Grafana, Datadog

📝 Logs (What happened?)

Structured logging (JSON, not plain text!)
Centralized collection
Tools: ELK Stack, Loki, Splunk

🔍 Traces (Where did the time go?)

Follow a request across multiple services
Identify bottlenecks in the chain
Tools: Jaeger, Zipkin, OpenTelemetry

A trace looks like this:

[Order Service]  ████████████ 200ms
  [Payment Service]     ██████████████████ 350ms
    [Bank API]              ████████████████████████ 500ms
  [Inventory Service]  ████ 80ms
  [Notification Svc]   ██████ 120ms
# Total: 500ms — and you can see exactly WHERE the bottleneck is

The magic: With distributed tracing (OpenTelemetry), you get a correlation ID that follows the request across every service. One ID to rule them all. 💍

📌 Bonus: I wrote about building a one-line observability decorator for Python AI agents — the same principles apply to microservices. Observability isn't optional.

8. 🐳 Containerization & Orchestration — Shipping Made Easy

The concept: Package each service with its dependencies into a container (Docker), then manage hundreds of containers with an orchestrator (Kubernetes).

Why containers?

Developer's laptop:  "It works on MY machine!"
Production server:   "Well it doesn't work HERE!"
Container:           "Now it works EVERYWHERE." ✅

Docker basics:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Kubernetes basics (what it gives you):

🔄 Auto-scaling — Spin up pods when traffic spikes
🩺 Health checks — Restart unhealthy containers automatically
🌐 Service discovery — Services find each other by name
🚀 Rolling deployments — Zero-downtime deploys
🔧 Self-healing — Replace crashed containers

The mental model:

Docker = Package your app into a box 📦
Kubernetes = Manage thousands of boxes at a port 🏗️

💡 Reality check: You don't need Kubernetes for 3 services. But if you're running 20+ services with variable traffic, it's a game changer.

📌 Practical reading: 10 Docker Commands That Actually Matter in 2026 cuts through the noise. Also, How We Built Our Own DNS Server is a great deep dive into understanding networking fundamentals that make containers work.

9. 🛡️ Resilience Patterns — Building Antifragile Systems

The concept: The network is unreliable. Services will fail. Build for it.

Beyond circuit breakers (see #5), here are the patterns that save you at 3 AM:

⏱️ Retry with Exponential Backoff

Attempt 1: fail → wait 1s
Attempt 2: fail → wait 2s
Attempt 3: fail → wait 4s
Attempt 4: fail → give up (with graceful degradation)

Never retry without backoff. You'll DDoS yourself.

⏳ Timeout

// ALWAYS set timeouts on external calls
const response = await fetch(url, {
    signal: AbortSignal.timeout(5000)  // 5 seconds max, then fail
});

A service that hangs forever is worse than one that fails fast.

🏖️ Bulkhead Pattern

Isolate components so a failure in one doesn't sink the whole ship:

Thread Pool A: [Order Service requests]     ← max 50 threads
Thread Pool B: [Payment Service requests]   ← max 30 threads
Thread Pool C: [Search Service requests]    ← max 20 threads

# If Payment Service goes down and uses all threads,
# Order and Search still work!

🔄 Fallback

Provide a degraded but functional response:

RecommendationService fails?
→ Return popular items instead of personalized ones

WeatherService fails?
→ Return cached forecast from 1 hour ago

The mindset shift: Don't ask "How do I prevent failure?" — ask "How do I survive failure?" 🦾

📌 External resource: Netflix's Hystrix (now in maintenance mode) popularized many of these patterns. The resilience4j library is its modern successor. Also, Martin Fowler's article on Circuit Breaker is the canonical reference.

10. 📜 Event Sourcing & CQRS — Think in Events, Not State

The concept: Instead of storing just the current state, store every event that led to that state. Then build optimized read models separately (CQRS).

Traditional (State-based):

Database: { orderId: 123, status: "shipped", total: 99.99 }
# Only the FINAL state. How did we get here? 🤷

Event Sourcing:

Events:
  1. OrderCreated    { orderId: 123, items: [...], total: 99.99 }
  2. PaymentReceived { orderId: 123, amount: 99.99, method: "card" }
  3. OrderShipped    { orderId: 123, trackingId: "XYZ123" }
# Full history! You can replay, audit, and debug everything 🔍

CQRS (Command Query Responsibility Segregation):

WRITE SIDE: Optimized for writes (event store)
    │
    ├──→ READ SIDE 1: Optimized for order lookups (SQL)
    ├──→ READ SIDE 2: Optimized for search (Elasticsearch)
    └──→ READ SIDE 3: Optimized for analytics (Data Warehouse)

When to use it:

✅ Financial systems (audit trail is critical)
✅ Complex domains where history matters
✅ Systems with very different read/write patterns

When NOT to use it:

❌ Simple CRUD apps (overkill)
❌ Small teams without event-driven experience
❌ If you can't explain it to your team, don't use it

💡 Pro tip: You can adopt event sourcing for specific services without going all-in everywhere. Start with the domain that benefits most from audit trails.

📌 Learn more: Eventual Consistency: Debugging the Hardest Class of Bugs covers the debugging challenges that come with event-driven architectures.

🎯 The Cheat Sheet

Here's your quick reference:

#	Concept	One-Liner	Learn More
1	Service Decomposition	Split by business domain, not tech layers	DDD Reference
2	API Gateway	One front door, many rooms	Kong Gateway Docs
3	Service Discovery	Find services dynamically, don't hardcode	K8s DNS Docs
4	Load Balancing	Spread traffic, prevent bottlenecks	NGINX Guide
5	Circuit Breaker	Fail fast, don't cascade	resilience4j
6	Async Messaging	Decouple with events, don't block	Kafka Docs
7	Observability	Metrics + Logs + Traces = Visibility	OpenTelemetry
8	Containers & K8s	Package once, run anywhere	Kubernetes Docs
9	Resilience Patterns	Retry, timeout, bulkhead, fallback	Martin Fowler's Patterns
10	Event Sourcing & CQRS	Store events, optimize reads separately	EventStoreDB

🤔 What I Didn't Cover (But You Should Learn Next)

Saga Pattern — Distributed transactions across services
Service Mesh (Istio/Linkerd) — Sidecar proxies for inter-service communication
Feature Flags — Deploy without releasing
Database per Service — The hardest part of microservices
Distributed Tracing in Practice — Beyond the basics

📌 Want to understand how AI fits into all of this? Check out The Prompt Engineer's Survival Guide: Skills That AI Can't Replace — because understanding systems thinking is what separates you from the AI.

🧰 The Microservices Tech Stack (2026 Edition)

Layer	Tools	Why
API Gateway	Kong, Traefik, AWS API Gateway	Routing, auth, rate limiting
Service Mesh	Istio, Linkerd, Consul Connect	mTLS, traffic management
Message Broker	Kafka, RabbitMQ, AWS SQS	Async communication
Container Runtime	Docker, containerd	Packaging
Orchestration	Kubernetes, ECS, Nomad	Scaling, healing
Observability	OpenTelemetry + Grafana Stack	Metrics, logs, traces
CI/CD	GitHub Actions, GitLab CI, ArgoCD	Automated deployment
IaC	Terraform, Pulumi, CDK	Infrastructure as code

💬 Your Turn

What concepts did I miss? What's the one microservices lesson you learned the hard way? Drop it in the comments — I'd love war stories. ⚔️

And if this helped you, a ❤️ reaction helps more developers find this post. Share it with your team before they write another monolith disguised as microservices. 😉

Next in the series: "Saga Pattern: How to Handle Transactions That Span Multiple Services (Without Losing Your Mind)"

Follow me for more microservices deep dives. 🔔

📚 Further Reading

From the DEV Community:

🤯 We Broke Our App Into 50 Microservices. Then We Put It Back Together — And Cut Costs by 90% — A must-read cautionary tale
🔁 Why Your Retry Logic Is Silently Charging Customers Twice — Real-world retry horror story
🐛 Eventual Consistency: Debugging the Hardest Class of Bugs — When distributed systems get weird
📐 Event-Driven Microservices: Patterns, Implementation & Debugging — Practical event-driven guide
🏗️ Microservices Architecture Best Practices: A CTO's Decision Framework for 2026 — Architecture decisions
🐳 10 Docker Commands That Actually Matter in 2026 — Container essentials

From My Previous Posts:

🎵 Vibe Coding is Fun Until You Hit Production — When shipping fast breaks things
🤖 AI Agents Replaced My Dev Workflow — Here's What Broke — The automation experiment
🎯 The Prompt Engineer's Survival Guide — Skills AI can't replace
👶 Junior Devs in 2026: What Bootcamps Won't Tell You — Career reality check

External Resources:

📘 Building Microservices by Sam Newman — The bible of microservices
📊 Martin Fowler's Microservices Guide — Foundational reading
🔒 The System Design Primer (GitHub) — Free, comprehensive system design resource
📘 Designing Data-Intensive Applications by Martin Kleppmann — Deep distributed systems knowledge
🏗️ Google SRE Book — How Google runs production systems
📐 DDD Reference by Eric Evans — Domain-Driven Design fundamentals

Cover image: GIPHY

Junior Devs in 2026: What Bootcamps Won't Tell You

Mamoor Ahmad — Mon, 11 May 2026 17:02:44 +0000

I mentor junior developers. Recently, one of them sent me this message:

"I finished a bootcamp. I built 4 portfolio projects. I've applied to 237 jobs. I've had 3 interviews. Zero offers. Everyone says 'just learn to code' but nobody told me it would be like this."

I didn't have a good answer. Because honestly? The playbook I followed five years ago doesn't work anymore.

The entry-level tech job market has dropped 25% year-over-year. Companies that used to hire batches of junior devs are now hiring one senior with an AI toolkit. Bootcamps are still selling the dream of "learn to code, get a $90K job" — but the reality on the ground has shifted seismically.

This isn't a doom post. It's a reality check — and a survival guide.

Here's what I wish someone had told the juniors I mentor before they spent $15K on a bootcamp.

🔥 The Uncomfortable Truth Nobody's Saying Out Loud

Let's start with the elephant in the room:

AI hasn't replaced developers. But it has replaced junior-level tasks.

The work that used to go to junior devs — CRUD apps, boilerplate, basic API integrations, simple bug fixes, documentation — is now the exact work AI does best. A senior developer with Cursor can do in 2 hours what used to take a junior dev 2 days.

That's not a theory. That's what's happening at companies right now.

Does that mean junior devs are doomed? No. But it means the path in has changed — and if you're still following the 2020 playbook, you're optimizing for a world that doesn't exist anymore.

The old path: Learn syntax → Build portfolio → Apply to jobs → Get hired → Learn on the job

The new path: Learn to think → Build something real → Show how you work → Get hired for your judgment, not your typing speed

💀 What Bootcamps Get Wrong

I've reviewed hundreds of bootcamp graduates' portfolios. I've interviewed dozens. Here's what I see over and over:

❌ Mistake #1: "I Know 12 Frameworks"

Your bootcamp taught you React, Vue, Angular, Express, Django, Flask, PostgreSQL, MongoDB, Redis, Docker, AWS, and Kubernetes. In 12 weeks.

You don't know any of them. You've touched all of them.

What actually matters: Deep knowledge of ONE stack. If you know React + Node + PostgreSQL deeply — how they work, how they break, how to optimize them — you're infinitely more valuable than someone who can "hello world" in 12 frameworks.

📌 The fix: Pick one stack. Build three increasingly complex projects with it. Understand why things work, not just how to make them work.

❌ Mistake #2: "Look, I Built a Todo App!"

Every junior portfolio has:

A todo app
A weather app
A calculator
A "Netflix clone" that's just a grid of movie posters

These prove you can follow a tutorial. They don't prove you can solve problems.

What hiring managers actually want to see:

A project that solves a real problem (even a small one)
Evidence of debugging (show the bug, show how you fixed it)
Decisions you made and why (why this database? why this auth approach?)
What you'd do differently next time

📌 The fix: Build something you actually use. A tool for your gym, your budget, your D&D campaign. Then write about the problems you hit and how you solved them.

❌ Mistake #3: "I Can Write Code" (But Can't Read It)

Bootcamps optimize for output. Write this function. Build this feature. Ship this project.

They rarely train the skill that actually matters in a job: reading and understanding existing code.

In any real job, you'll spend 70% of your time reading code — your team's code, legacy code, open-source code, and yes, AI-generated code. If you can't trace through a codebase and understand how data flows, you'll drown.

📌 The fix: Pick an open-source project. Read the code. Try to understand the architecture. Submit a bug fix. This is worth more than 10 portfolio projects.

❌ Mistake #4: "Git? I Know `git push`"

The number of junior devs who can't:

Resolve a merge conflict
Write a meaningful commit message
Use branches properly
Review a pull request

...is staggering. And these are daily skills in any engineering team.

📌 The fix: Contribute to an open-source project. Even a tiny docs fix. The PR process will teach you more about real-world development than any bootcamp.

❌ Mistake #5: Ignoring AI (Or Hiding It)

Some juniors avoid AI tools because they feel like cheating. Others use them secretly and pretend they wrote everything.

Both approaches are wrong.

The reality: Companies expect you to use AI tools. But they also expect you to understand what the AI generates. The skill isn't "can you prompt Cursor?" — it's "can you evaluate what Cursor gives you?"

📌 The fix: Use AI openly. But be ready to explain every line of code it generates. If you can't explain it, you don't understand it.

🧭 What Actually Gets You Hired in 2026

After interviewing dozens of junior devs and watching what works, here's what separates the ones who get offers from the ones who get ghosted:

1. 🎯 You Can Explain Your Decisions

"I used PostgreSQL because my data has relational integrity requirements and I needed ACID transactions for the payment flow" hits different than "I used PostgreSQL because the tutorial used it."

The interview hack: For every technical choice in your project, prepare a 30-second explanation of why. Not the textbook answer — your actual reasoning.

2. 🐛 You've Debugged Something Real

Every junior says "I'm a fast learner." Nobody cares. What they want to hear:

"I had a memory leak in my Node.js app. I used the Chrome DevTools heap profiler to trace it. Turns out I was creating new event listeners in a useEffect without cleaning them up. Here's what I learned."

That story proves you can:

Identify a problem
Use debugging tools
Understand the root cause
Learn from it

That's worth more than any certificate.

3. 🤝 You Can Communicate

The most underrated junior dev skill. Can you:

Ask a good question in Slack? (Not "it's broken" — but "I'm seeing X behavior when I do Y, and I expected Z. Here's what I've tried.")
Write a clear PR description?
Explain a technical concept to a non-technical person?
Push back on a requirement respectfully?

Communication is the skill that makes all other skills visible. A decent coder who communicates well will outperform a great coder who doesn't.

4. 🧠 You Think in Systems, Not Just Functions

Junior: "I built the feature."
Senior: "How does it handle errors?"
Junior: "Um..."

The jump from junior to mid-level isn't about writing better code. It's about thinking about what happens when things go wrong. What if the API is down? What if the user submits garbage data? What if two users edit the same thing at once?

📌 The exercise: For every feature you build, list 5 things that could go wrong. Then handle at least 3 of them. This is the single fastest way to level up.

5. 📝 You Document Your Learning

The juniors who get hired fastest are the ones who write about what they build.

Not tutorials for others — but notes for themselves:

"Here's why I chose X over Y"
"Here's the bug that took me 4 hours to find"
"Here's what I'd do differently"

This does three things:

Forces you to actually understand what you did
Creates content that shows your thinking process
Gives interviewers something to ask you about

Start a dev blog. Even if nobody reads it. The act of writing is the act of understanding.

🗺️ The Real Roadmap for 2026

If I were starting from scratch today, here's exactly what I'd do:

Month 1-2: Foundations That Last

Pick ONE language. JavaScript or Python. Not both.
Learn it deeply. Not just syntax — how the runtime works, how memory is managed, how async actually works under the hood.
Build 2 projects without AI. Yes, it's slower. Yes, you'll learn more.
Learn Git properly. Branches, rebasing, meaningful commits, PR reviews.

Month 3-4: Build Real Things

Build a project that solves YOUR problem. Something you'll actually use.
Use AI tools — but understand every line they generate.
Deploy it. Not localhost. Real URL. Real users (even if it's 5 friends).
Write about it. Blog post: what you built, what broke, what you learned.

Month 5-6: Enter the Arena

Contribute to open source. Even a one-line docs fix. The PR process is the education.
Network authentically. Comment on dev.to posts. Help people in Discord servers. Don't ask for jobs — add value.
Apply strategically. 10 tailored applications > 200 spray-and-pray.
Prepare for interviews with stories, not answers. "Tell me about a bug you fixed" is more common than "what's a closure?"

🤖 The AI Elephant in the Room

Let me address the fear directly:

"If AI can write code, why would anyone hire a junior developer?"

Because AI can write code. But it can't:

Understand your business context. It doesn't know why the refund flow needs to be different for premium users.
Make judgment calls. It doesn't know when to cut corners and when to be thorough.
Collaborate with humans. It doesn't sit in a sprint planning meeting and ask "wait, why are we building this?"
Take ownership. When the production database goes down at 2am, AI doesn't wake up and fix it. A developer does.
Learn and grow. AI doesn't get better at your company over time. A junior dev who starts today will be a senior dev in 5 years.

The junior devs who thrive will be the ones who bring what AI can't: judgment, communication, ownership, and growth.

The ones who only bring "I can write code" — yeah, they're in trouble. But that was always true. AI just accelerated the timeline.

💡 The Skills Nobody Talks About

Here's what I'd add to every bootcamp curriculum if I could:

Skill	Why It Matters	How to Build It
Reading code	70% of your job	Pick an OSS repo, read it
Debugging	What separates juniors from seniors	Break things on purpose, then fix them
Communication	Makes all skills visible	Write blog posts, do code reviews
System thinking	Prevents production disasters	Ask "what if" for every feature
Git workflow	Daily team skill	Contribute to OSS
Business context	Why you're building this	Talk to product managers
AI fluency	Expected, not optional	Use tools, understand output

💬 To the Juniors Reading This

I know it's hard. I know the market feels impossible. I know it's frustrating to hear "just keep applying" when you've sent 200 applications into the void.

Here's what I'd tell the juniors I mentor:

You're not behind. The game changed. Everyone's adjusting. You're not failing — the rules changed while you were learning.
Depth beats breadth. One stack, deeply understood, beats 12 frameworks, shallowly touched.
Build things you care about. Passion projects show in interviews. Todo apps don't.
Write about what you learn. It's the highest-leverage activity for a junior dev. It builds understanding, visibility, and a portfolio of thinking.
Use AI, but don't outsource your brain. The goal is to become a developer who uses AI, not a prompt engineer who used to code.
Contribute to open source. Even tiny contributions. The experience of working with a real codebase, real review process, and real team is irreplaceable.
Be patient, but be strategic. 10 tailored applications with custom cover letters and relevant projects > 200 generic applications.

🎯 The Bottom Line

The junior developer path isn't dead. It's different.

The gatekeepers have changed. The skills that matter have shifted. The bootcamp-to-job pipeline has cracks.

But developers who can think, communicate, debug, and learn — those developers will always be in demand. AI hasn't changed that. If anything, it's made those skills more valuable, not less.

Stop optimizing for the market of 2020. Start building for the market of 2026.

Junior devs — what's been your experience? What do you wish someone had told you?

Seniors and hiring managers — what do you actually look for in a junior candidate?

Let's bridge the gap. The conversation is more useful than any roadmap. 👇

If you know a junior dev who's struggling, share this with them. We've all been there. They don't need platitudes — they need perspective.

More on navigating the dev career in the AI era:

Vibe Coding is Fun Until You Hit Production

Mamoor Ahmad — Mon, 11 May 2026 16:53:48 +0000

Three hours. That's all it took.

I described a SaaS dashboard to Cursor. It generated the React components. I prompted it again — backend routes, database schema, auth flow. Another prompt. Deployment config. CI pipeline. Landing page.

By lunchtime, I had a working product. Live URL. Login flow. Data persistence. Dark mode. ✨

I posted on Slack: "Just shipped a new tool in one morning. Vibe coding is insane."

By dinner, I had 43 messages from users. Not the good kind.

"I can see other people's data."
"The export button returns an empty file."
"I got logged in as someone else."

That last one. 😬

Three hours to build. Three weeks to fix. And a very uncomfortable conversation with my manager about what "shipped" actually means.

🎵 What Even Is Vibe Coding?

If you've been anywhere near tech Twitter in 2026, you've heard the term. Vibe coding is the practice of building software by describing what you want to an AI and iterating through conversation rather than writing code manually.

The term was coined in early 2025 and has since become one of the most debated practices in software development.

The promise: Anyone can build software. Just describe what you want. The AI handles the rest.

The reality: Anyone can build software that looks like it works. The gap between "looks like it works" and "works in production" is where careers go to die.

I'm not anti-vibe coding. I still do it. But I learned — the hard way — that vibes have a shelf life, and that shelf life ends at git push origin main.

Here's what I've learned from shipping AI-generated code to real users.

💥 The 7 Ways Vibe Coding Breaks in Production

1. 🔐 The Security You Didn't Think About

This is the big one. The one that gets you on a call with legal.

When I vibe-coded my dashboard, the AI generated auth middleware that looked secure. JWT tokens, bcrypt passwords, rate limiting. Textbook stuff.

What it didn't do:

Sanitize the input on the search endpoint (hello, SQL injection)
Validate that users could only access their own data (hello, IDOR vulnerability)
Set proper CORS headers (hello, any website can call my API)

What I asked for: "Add user authentication"
What I got: A login form that works
What I needed: A security review by someone who thinks like an attacker

The AI doesn't think like an attacker. It thinks like a tutorial. It gives you the happy path, not the threat model.

📌 The rule: Never ship AI-generated auth, payments, or user data handling without a human security review. Period.

2. 🗄️ The Database Schema That Worked Until It Didn't

The AI designed my database schema. It was clean. Normalized. Made sense on paper.

It also stored user sessions in the same database as user data, with no foreign key constraints, no indexes on the columns I was querying every 50ms, and a deleted_at column that nothing actually checked.

AI's schema:  ✅ Looks clean
Reality:      ❌ No indexes = full table scan on every request
Reality:      ❌ No constraints = orphaned records everywhere
Reality:      ❌ Soft delete that nothing respects = ghost data

When I hit 200 concurrent users, my database response time went from 50ms to 12 seconds. The AI never mentioned indexes. I never asked. That's the trap — you don't know what you don't know.

📌 The rule: If you don't understand database design, vibe-code the feature, then ask a human to review the schema before you populate it with real data.

3. 🧪 The Tests That Test Nothing

Here's a conversation I had with Cursor:

Me: "Write tests for the payment module"
AI: *writes 23 tests*
Me: "Run the tests"
AI: "All 23 tests passed ✅"
Me: *ships it*

Two weeks later: a user was charged twice for the same subscription. How?

The AI wrote tests that verified the function calls were made. It never tested what happened when the webhook fired twice. It never tested idempotency. It never tested the thing that actually broke.

AI-generated tests optimize for coverage numbers, not for finding bugs.

They test that the code does what the code does. They don't test that the code does what the business needs.

📌 The rule: Write your own test cases for critical paths. Use AI to generate the boilerplate, but you define the scenarios.

4. 📦 The Dependency Avalanche

When you vibe-code, you prompt: "Add email sending." The AI adds nodemailer.

Then: "Add HTML email templates." It adds mjml and handlebars.

Then: "Add email scheduling." It adds bull and redis.

Then: "Add email tracking." It adds open-pixel and three more packages.

By the end of a 3-hour session, your package.json has 47 new dependencies. You didn't choose any of them. You don't know what half of them do. And one of them has a known CVE that's been open for 6 months.

📌 The rule: After every vibe coding session, run npm audit, read the dependency list, and ask: "Do I actually need all of these?"

5. 🎭 The UI That Looks Done But Isn't

AI is incredible at generating beautiful UI. Give it a prompt, get back a polished component with animations, responsive layout, and dark mode.

But:

The "Submit" button doesn't have a loading state → users click it 5 times
The form doesn't validate on blur, only on submit → frustration
The error message says "Something went wrong" → zero debugging info
The mobile layout technically works but the touch targets are 20px → rage tapping
The modal doesn't trap focus → accessibility nightmare

Looking done and being done are different things. AI excels at the first. You have to deliver the second.

📌 The rule: After the AI generates UI, test it like a frustrated user. Click fast. Resize the window. Use keyboard only. Try to break it.

6. 🔇 The Error Handling That Doesn't Handle

// What the AI wrote:
try {
  const result = await processPayment(amount);
  return { success: true, data: result };
} catch (error) {
  return { success: false, error: error.message };
}

Looks fine, right? Now what happens when processPayment throws a TimeoutError? The user sees "TimeoutError" on their screen. Not "Payment is processing, please check back in a minute." Just... a raw error message.

What happens when the network drops mid-request? The AI doesn't retry. It doesn't queue. It doesn't tell the user what state they're in.

AI writes error handling that catches errors. It doesn't write error handling that handles errors.

📌 The rule: For every error catch block, ask: "What does the user see? What do they do next?" If you can't answer both, rewrite it.

7. 📈 The Performance Cliff

My dashboard loaded in 200ms with 10 test users.

With 500 real users? 8 seconds.

The AI had:

No pagination (loading all records at once)
No caching (same query on every page load)
No lazy loading (every component hydrated on mount)
Three API calls that could've been one

These aren't bugs. The code works correctly. It just works slowly. And the AI never mentioned performance because you never asked about performance.

That's the core problem with vibe coding: it optimizes for the request you made, not the requirements you forgot.

📌 The rule: Before shipping, test with realistic data volumes. 10 test records tell you nothing about 10,000 real ones.

✅ When Vibe Coding Actually Works

I'm not here to trash vibe coding. It's genuinely powerful when used correctly. Here's where it shines:

🏆 The Sweet Spots

Use Case	Why It Works
Prototyping	Speed > quality. Get the idea on screen fast.
Personal tools	You're the only user. Bugs are learning opportunities.
Boilerplate	Config files, CRUD routes, migration scripts.
Learning	"Explain this code" is the best prompt in vibe coding.
UI exploration	"Try 5 different layouts for this dashboard."

⚠️ The Danger Zones

Use Case	Why It's Risky
Auth & security	AI doesn't think like an attacker.
Payments	Real money, real consequences.
User data	Privacy laws don't care that "the AI wrote it."
Production systems	Reliability requires understanding, not just output.
Team codebases	Others have to maintain what you vibe-coded.

🧭 The 7 Rules I Now Follow

After shipping broken code and spending weeks fixing it, here's my personal vibe coding framework:

Rule 1: 🎯 Prompt with Purpose, Not Hope

❌ "Build me a user dashboard"
✅ "Build a user dashboard with: 
   - Server-side pagination (20 items/page)
   - Input sanitization on all form fields
   - Error boundaries with user-friendly messages
   - Loading states for every async operation
   - WCAG 2.1 AA compliance"

Specificity is quality control. Vague prompts produce vague code.

Rule 2: 🔍 Read Every Line Before Shipping

I know. The whole point of vibe coding is not reading code. But if it's going to production, you need to understand what it does. At least at the architecture level.

You don't need to understand every regex. But you do need to know:

Where does user input go?
How is auth handled?
What happens when things fail?
What data leaves the server?

Rule 3: 🧪 Write Your Own Critical Tests

Use AI to generate unit tests for utility functions. But for the paths that matter — login, payments, data access — write the test scenarios yourself.

Ask yourself: "What's the worst thing that could happen if this breaks?" Then write a test for exactly that.

Rule 4: 🔐 Security Review Before Deploy

Run npm audit. Check for hardcoded secrets. Verify CORS. Test authentication with two different accounts. Try to access data that isn't yours.

If you don't know how to do these things, learn them before you vibe-code a production app.

Rule 5: 📊 Test with Real Data Volumes

Populate your database with 10,000 records. See what happens. If the page takes 5 seconds to load, you have a problem. Better to find it now than when users are complaining.

Rule 6: 🏗️ Vibe the Feature, Engineer the Foundation

Use AI to generate the feature code. But the architecture — the database schema, the API design, the auth flow — design that yourself. Or have someone review it.

Features are expendable. Foundations are not.

Rule 7: 📝 Document What You Don't Understand

If the AI generated something and you don't fully understand it, write a comment. Not for others — for future you. Because when it breaks at 2am, you won't remember what that 40-line function does.

📊 The Vibe Coding Maturity Model

I've started thinking about vibe coding on a spectrum:

Level 0: "What's vibe coding?"
Level 1: "I use AI for autocomplete"  
Level 2: "I describe features and AI builds them"
Level 3: "I review and understand everything AI generates"
Level 4: "I architect the system, AI handles implementation"
Level 5: "I use AI as a tool, not a crutch"

Most people are at Level 2. The goal is Level 4-5.

The danger isn't vibe coding itself. It's getting stuck at Level 2 and thinking you're at Level 5.

💬 Let's Be Honest

I still vibe code every day. It's an incredible tool for the right problems. I've built personal tools, prototypes, and internal dashboards in hours that would've taken days.

But I've also learned — through broken auth, angry users, and 2am debugging sessions — that shipping to real users requires more than vibes.

It requires judgment. It requires understanding. It requires the humility to say: "The AI wrote this, but I need to verify it works correctly."

The developers who'll thrive aren't the ones who reject vibe coding. They're the ones who know when to vibe and when to engineer.

Where are you on the Vibe Coding Maturity Model? And what's the worst thing you've shipped with AI-generated code?

I'll go first: I shipped a payment integration that double-charged users. The AI's test suite passed with flying colors. 🫠

Your turn. 👇

If this saved you from a production incident, share it with a fellow vibe coder. We've all been there.

More on navigating the AI coding era:

The Prompt Engineer's Survival Guide: Skills That AI Can't Replace

Mamoor Ahmad — Mon, 11 May 2026 16:41:22 +0000

Last Tuesday, I watched a senior developer spend 45 minutes prompting Cursor to build a rate limiter.

It generated something that looked right. Clean code. Nice comments. Tests passing.

I asked him: "Does this handle the race condition when two requests hit the limit at the same time?"

He stared at the screen. Then at me. Then back at the screen.

"I... didn't think about that."

That's the gap. And that gap is where your career lives or dies in 2026.

🤖 The Uncomfortable Truth

Let's get this out of the way: AI is better than you at writing code.

Not all code. Not in every context. But for a growing number of tasks — boilerplate, CRUD, standard patterns, even moderately complex logic — LLMs produce working code faster than you can type.

If your entire value proposition is "I write code," you're in trouble.

But here's what the doomsday narratives miss:

Writing code was never the job. The job was solving problems. Code was just the tool.

The developers who are thriving right now aren't the ones who type the fastest. They're the ones who think the deepest. And that distinction matters more every day.

Here are 7 skills that AI can't replicate — and how to sharpen them before the gap closes on you.

1. 🏗️ Systems Thinking: Seeing the Whole Board

AI can write a function. It can even write a well-structured module. But ask it to design a system that handles 10x traffic, degrades gracefully, and doesn't cost your company $50K/month in cloud bills?

That's on you.

What this looks like in practice:

Understanding how a change in the auth service ripples through the payment pipeline
Knowing why a caching layer here saves you but a caching layer there creates stale data nightmares
Designing for failure modes that haven't happened yet

How to build it:

Draw architecture diagrams before you code. Even rough ones. The act of visualizing dependencies exposes problems AI won't catch.
Read post-mortems. Google's SRE book and Netflix's tech blog are goldmines for understanding how systems fail.
Practice the "what happens when" game: What happens when this service goes down? When the database is slow? When the queue backs up? AI can't play this game. You can.

📌 Related reading: The System Design Primer on GitHub — the single best free resource for building this muscle.

2. 🔍 Problem Framing: Asking the Right Question

Here's a pattern I see constantly:

Developer: "AI, build me a notification system"
AI: *builds a notification system*
Developer: *ships it*
Product Manager: "Why did you build push notifications? Our users want email."
Developer: 😐

AI is an incredible answer machine. But it's a terrible question machine. It will give you exactly what you ask for — which is dangerous when you're asking for the wrong thing.

The skill:

Translating business requirements into technical problems
Identifying when a stakeholder says "dashboard" they actually mean "alert"
Knowing which questions to ask before writing a single line of code

How to build it:

Before prompting AI, write a one-sentence problem statement. Not "build X" but "solve Y." Example: not "build a search feature" but "help users find their last order in under 2 seconds."
Practice the 5 Whys. When someone asks for a feature, ask "why" five times. You'll usually discover the real problem is different from the stated one.
Pair with product managers. Not to code together — to think together. The best developers I know speak both languages.

📌 Related reading: Shape Up by Basecamp — the best framework for framing problems before jumping to solutions.

3. 🐛 Debugging Deeply: Reading the Clues

AI can fix syntax errors in milliseconds. But when your production system is returning 500 errors only on Tuesdays between 2-4 AM, and only for users in the EU region?

Good luck prompting your way out of that.

What separates great debuggers:

Reading stack traces like stories, not just scanning for the error line
Forming hypotheses and testing them, not randomly changing things until it works
Understanding the system well enough to know where the bug can't be

How to build it:

Debug without AI first. I know, it's slower. But every time you trace a bug manually, you build mental models that make the next one faster.
Keep a debugging journal. Seriously. Write down what you tried, what worked, what didn't. Patterns emerge.
Learn to read logs, not just search them. The difference between grep and understanding is the difference between junior and senior.

📌 Related reading: Debugging by David Agans — 9 timeless rules that apply whether you're debugging COBOL or Kubernetes.

4. 🗣️ Technical Communication: The Multiplier Skill

AI can write documentation. But can it:

Explain to the CEO why the migration will take 3 weeks and not 3 days?
Write an RFC that gets buy-in from 4 teams with conflicting priorities?
Tell a junior developer why their approach won't work without crushing their spirit?

Communication is the highest-leverage skill in engineering. And it's the one most developers neglect because it doesn't feel like "real work."

The reality:

The developer who can explain a complex system clearly is the one who gets promoted. The one who can write a compelling RFC is the one whose architecture gets adopted. The one who can mentor effectively is the one who scales their impact beyond their own keyboard.

How to build it:

Write technical blog posts. (Like this one! 👀) The act of explaining something forces you to truly understand it.
Practice the "explain it to a 10-year-old" test. If you can't simplify it, you don't understand it well enough.
Present at meetups. Even small ones. The feedback loop is instant and invaluable.

📌 Related reading: StaffEng — stories of how senior engineers grew into leadership through communication, not just code.

5. 🎯 Code Review & Quality Judgment

This one is subtle but critical.

AI-generated code looks correct. It compiles. Tests pass. It follows conventions. But:

Is it secure? (Did it sanitize that input?)
Is it maintainable? (Will the next developer understand it?)
Is it the right abstraction? (Or did it over-engineer a simple problem?)

The ability to evaluate code — yours and others' — is a skill that gets more important as AI writes more of it. You become the quality gate, not the quality producer.

How to build it:

Review AI output like you'd review a junior's PR. Don't skim. Actually read it. Ask "what could go wrong?"
Study security vulnerabilities. OWASP Top 10 is a great start. AI often misses these.
Build a mental checklist: Error handling? Edge cases? Performance implications? Test coverage for the right things?

📌 Related reading: How to Code Review — Google's engineering practices guide on reviewing code effectively.

6. 🧠 Learning How to Learn (Meta-Learning)

Here's a paradox: in the age of AI, the ability to learn new things quickly matters more than ever — even though AI can teach you anything.

Why? Because AI can transfer knowledge, but it can't build your intuition. And intuition comes from struggle.

The difference:

AI can tell you how React's reconciliation algorithm works
Only you can develop the feel for when a component re-renders too often
AI can explain database indexing
Only you can develop the instinct for which query will be slow

How to build it:

Learn by building, not by watching. Tutorials are fine for orientation. But you only learn by hitting walls and climbing over them.
Embrace productive struggle. If it's easy, you're not learning. If it's impossibly hard, you need more context. Find the sweet spot.
Teach what you learn. The Feynman Technique isn't just a study method — it's the fastest way to find the gaps in your understanding.

📌 Related reading: A Mind for Numbers by Barbara Oakley — the science of learning that actually works.

7. 🤝 Ethical Reasoning & Judgment

This is the one nobody talks about.

AI doesn't have ethics. It has training data. When you ask it to build a recommendation algorithm, it optimizes for engagement. It doesn't ask:

"Should we recommend this content to teenagers?"
"Is this algorithm creating a filter bubble?"
"Are we collecting more data than we need?"

You have to ask those questions. And you have to have the courage to push back when the answer makes someone uncomfortable.

The real-world stakes:

Building an AI feature that discriminates because the training data was biased
Shipping a "growth hack" that's really dark pattern design
Collecting user data because you can, not because you should

How to build it:

Read about tech ethics. Not as abstract philosophy — as practical engineering decisions. The Ethical OS Toolkit is a good starting point.
Ask "who gets hurt?" Before every feature. Not as a guilt trip — as a design constraint.
Build a personal red line. Know what you won't build before you're asked to build it.

📌 Related reading: Radical Candor by Kim Scott — because having ethical opinions means learning to voice them effectively.

📊 The Skills Matrix: Where Do You Stand?

Here's a quick self-assessment. Be honest:

Skill	Beginner 🌱	Intermediate 🌿	Expert 🌳
Systems Thinking	I think about my service	I think about the architecture	I think about the business
Problem Framing	I build what's asked	I ask clarifying questions	I redefine the problem
Debugging	I Google the error	I form hypotheses	I trace across systems
Communication	I write code comments	I write docs & RFCs	I influence decisions
Code Review	I check if it works	I check if it's good	I check if it's right
Meta-Learning	I follow tutorials	I learn by building	I learn by teaching
Ethics	I ship what's asked	I raise concerns	I set boundaries

Where are you? Drop a row in the comments. I'll go first. 👇

🎯 The 30-Day Challenge

If you read this far, you care. Here's how to act on it:

Week 1: Pick your weakest skill. Spend 30 minutes a day on it. Not coding — practicing the skill.

Week 2: Build something without AI for one full day. Rediscover what you know — and what you don't.

Week 3: Explain a complex technical concept to a non-technical person. Write it up as a blog post.

Week 4: Review someone else's AI-generated code. Write a thoughtful, constructive review. Notice what you catch.

💬 Let's Talk

I wrote this post because I've been having the same conversation with developers for months — the one where we admit we're not sure what we are anymore.

I don't think the answer is to reject AI. I think the answer is to become the kind of developer that AI makes more powerful, not obsolete.

That means doubling down on the things AI can't do: think in systems, frame problems, debug creatively, communicate clearly, judge quality, learn continuously, and reason ethically.

What skills are you investing in? What's missing from this list? And honestly — are you worried, excited, or both?

Let's hear it. 💬

If this post helped you, consider sharing it with a developer who's having the same identity crisis. We're all figuring this out together.

And if you're looking for more on navigating the AI era as a developer, check out:

AI Agents Replaced My Dev Workflow — Here's What Broke

Mamoor Ahmad — Sat, 09 May 2026 14:29:04 +0000

⚡ TL;DR: I replaced 80% of my dev workflow with AI agents over 3 months. 37% of my sprint velocity disappeared. Code review quality dropped. A deployment went out with a critical bug that a human would've caught in seconds. But — I also shipped features 2x faster on certain tasks, automated away 6 hours of weekly busywork, and discovered patterns I'd never have found manually. Here's the full, unfiltered breakdown.

🧪 The Experiment

Three months ago, I made a bet with my team lead:

"Give me two sprints. I'll route everything I can through AI agents — code generation, reviews, testing, documentation, even standup summaries. We'll measure the difference."

I wasn't naive. I'd been using GitHub Copilot and Cursor for months. But this was different. I wanted autonomous agents — not autocomplete on steroids, but systems that could plan, execute, and iterate on their own.

If you've felt the shift too — where coding increasingly means prompting — you're not alone. Harsh wrote about this exact identity crisis in I Used to Love Coding. Now I Just Prompt, and it resonated hard with the community.

Here's what my stack looked like:

I used a combination of Claude, OpenClaw for orchestration, and custom scripts to glue everything together. The promise was seductive: more output, less effort.

If you're curious about building your own agent pipeline, Erik Hanchett's Build Your Own AI Butler — A Scheduled Agent That Runs Itself is a great starting point.

The reality was... more complicated. 😅

💥 What Actually Broke

1. 🎭 The Code Review Illusion

What I expected: Agent catches bugs, suggests improvements, enforces style.

What happened: The agent was technically correct but contextually blind.

# Agent's "improvement" — technically cleaner
def process_payment(amount, currency="USD"):
    return PaymentGateway.charge(amount, currency)

# What a human reviewer caught:
# This bypasses the fraud detection middleware that was
# added last sprint after the incident on April 12th.
# The original version intentionally routed through
# FraudCheck.validate() first.

The agent saw isolated code. It didn't see the history, the intent, or the incident that shaped why the code was written that way. Over 2 weeks, it approved 3 PRs that would've introduced regressions — one of which hit production. 🚨

This echoes what Jon Herrington put perfectly: AI Doesn't Fix Weak Engineering. It Just Speeds It Up. If your review process is weak, AI just makes it fail faster.

💡 The lesson: AI code review is excellent for style, syntax, and common patterns. It's terrible at understanding why code exists. I now use agents for a first pass and humans for the contextual pass.

2. 🧪 The Test Generation Trap

This one hurt the most. 😬

I asked the agent to generate unit tests for our auth module. It produced 47 tests. They all passed. Coverage went from 72% to 94%. Sprint velocity looked amazing on paper. 📈

Two weeks later, a customer reported they could access another user's account under specific conditions. The agent had written tests that validated the existing behavior — including the bug. It never questioned whether the behavior was correct.

// The agent wrote this test — it PASSES
// because it tests the broken behavior
test('returns user session for valid token', () => {
  const session = getSession('valid-token-123');
  expect(session.userId).toBe('user-456');
  // ✅ Passes! But what if 'valid-token-123' belongs
  // to user-789 and the system is leaking sessions?
  // The agent can't know what "correct" means here.
});

💡 The lesson: Test generation is where agents shine and where they're most dangerous. They optimize for passing tests, not for finding edge cases. I now have the agent generate tests, then I manually add adversarial tests — the ones that should fail.

3. 📚 The Documentation Drift Problem

I had the agent auto-update our API docs from code changes. Brilliant in theory. ✨

In practice, it generated technically accurate documentation that was misleading by omission. It documented what the API did but not why certain parameters exist, not when to use one endpoint over another, and not the gotchas that every senior dev on the team knows but never writes down. 🤦

This is why treating documentation as a first-class engineering asset matters — not just auto-generated reference, but intentional, contextual documentation.

Worse: because the docs looked "complete," junior devs stopped asking questions. They just read the AI-generated docs and made assumptions. Our Slack channel got busier, not quieter. 💬📈

💡 The lesson: Documentation isn't just API reference. It's context, judgment, and tribal knowledge. Agents can draft reference docs; humans need to write the "here's what you actually need to know" parts.

4. 📊 The Velocity Mirage

Here are the real numbers from my 3-month experiment:

I was shipping faster but spending more time fixing what I shipped. The net velocity gain was close to zero. On complex features, it was actually negative. 📉

💡 The lesson: Speed without reliability is just... speed. The DORA metrics framework calls this out: deployment frequency means nothing without change failure rate.

✅ What Actually Worked (And It's Not Nothing)

I don't want to paint this as a failure. Some things genuinely transformed my workflow:

🏆 The "Boring Work" Elimination

Agents are phenomenal at tasks that are necessary but mind-numbing:

Task	Before	After	Saved
📋 Changelog generation	45 min	3 min	42 min/week
🔐 Dependency audit summaries	30 min	5 min	25 min/week
🧱 Boilerplate code	2-3 hours	20 min	~2.5 hours/week
♻️ Code migration patterns	Days	1 afternoon	Massive
📝 Meeting summaries	15 min	2 min	13 min/week

I estimate I reclaimed 6 hours per week of work that made me question my career choices. 🙃

Related reading: Write Code That's Easy to Delete: The Art of Impermanent Software — a great perspective on code longevity that becomes even more relevant when agents are writing your code.

🚀 The Exploration Accelerator

When I was investigating a new domain — say, implementing WebAuthn for the first time — agents were incredible as research assistants. They could:

📖 Summarize 15 articles into a coherent mental model
💻 Generate proof-of-concept code I could iterate on
🔍 Explain unfamiliar error messages in context
🧭 Suggest architectural approaches with trade-off analysis

This cut my learning curve from days to hours. ⏱️

🦆 The Rubber Duck That Talks Back

The most underrated use case: using an agent as a thinking partner for architectural decisions.

🤔 Me: "Should we use event sourcing for the notification system?"

🤖 Agent: "Here's a comparison:
  - Event sourcing: audit trail, replay capability, complexity cost
  - CRUD with log: simpler, covers 90% of audit needs, faster to build
  - Your team size (3 devs) suggests CRUD is the pragmatic choice
  - BUT if you're planning to add real-time sync next quarter,
    event sourcing now saves you a rewrite later"

🤔 Me: "...that's actually a really good framework for the decision."

It didn't make the decision. It structured my thinking. That's the sweet spot. 🎯

⚡ My Current Workflow (The Hybrid That Works)

After 3 months of experimentation, here's where I landed:

The rule is simple:

🤖 Agents handle the "what." 👨‍💻 Humans handle the "why" and "should we."

🔮 The Surprising Second-Order Effects

🎯 Prompt Engineering is the New Debugging Skill

I spent more time crafting the right prompt than I ever spent debugging. The difference between a useless agent output and a brilliant one often came down to:

# ❌ Bad prompt:
"Write tests for the auth module"

# ✅ Good prompt:
"Write unit tests for the auth module's session management.
Focus on edge cases: expired tokens, concurrent sessions,
token rotation. Follow the existing test patterns in
/tests/auth.test.js. Include tests that SHOULD FAIL if
the session validation logic has the bug described in
issue #847."

Specificity is the new debugging. If you can't articulate what you want clearly, the agent will give you something technically correct but practically useless. 🎭

👶 The "Junior Dev" Problem is Real

I watched our junior devs try to replicate my experiment. They couldn't tell when the agent was wrong. Not because they're not smart — because evaluating AI output requires the same skill as writing it from scratch. 🧠

This is the hidden cost of AI-first workflows: they assume you already know enough to catch the mistakes. For senior devs, agents are force multipliers. For junior devs, they can be confidence destroyers. 💔

This connects to the bigger question Harsh raised in Am I a Developer or Just a Prompt Engineer? — a post that sparked 98 comments because it touched a nerve everyone was feeling.

I've since changed our team's approach:

	Junior Devs Use Agents For	Junior Devs DON'T Use Agents For
✅	Learning (explain this code)	Production output (write this feature)
✅	Suggest approaches	Review PRs
✅	Understand error messages	Make architectural decisions

🤝 Trust Erosion is Invisible

The most dangerous failure mode isn't a bug in production. It's the slow erosion of team trust. ⚠️

📉 PR review comments dropped 40% when I switched to agent reviews
👀 People stopped looking at each other's code because "the AI already checked it"
💬 Commit messages became meaningless because they were AI-generated
🏝️ Standup summaries created isolation, not alignment

Process automation without team buy-in creates isolation, not efficiency.

🔄 What I'd Do Differently

If I could restart the experiment:

🐣 Start smaller. Don't replace the whole workflow at once. Pick ONE task, automate it, measure for 2 weeks, then expand.
🛡️ Set up guardrails first. Define what "good enough" looks like before the agent starts producing output. Quality gates, human checkpoints, rollback criteria.
📏 Measure what matters. Sprint velocity is a vanity metric. Measure cycle time, defect escape rate, and developer satisfaction instead.
👥 Include the team. My solo experiment created weird dynamics. Make it a team decision with shared standards.
⏳ Budget for the learning curve. The first 2-3 weeks were slower than manual work. That's normal. Don't abandon the experiment before the compounding kicks in.

🏁 The Verdict

AI agents aren't replacing developers. They're replacing developer tasks. The distinction matters. 🎯

The developers who thrive in an agent-augmented workflow will be the ones who:

🔍 Know when to trust the output and when to override it
✍️ Can write precise prompts that encode their intent
⚖️ Understand that automation amplifies — both quality and mistakes
🛠️ Treat agents as tools, not teammates

My sprint velocity is back to normal now — actually slightly above. But my real productivity is up because I'm spending my brain cycles on the problems that actually need a human brain. 🧠💪

The boring work is gone. The hard work is still here. And honestly? That's exactly how it should be.

💬 Over to You

I'm curious how others are handling this:

🤖 What tasks have you successfully automated with AI agents?
💀 What's the worst failure you've seen from agent-generated code?
👶 How do you handle the junior dev + AI agent dynamic on your team?

Drop your stories below. Especially the horror stories — those are the ones we all learn from. 👇

If this was useful, I'm writing a follow-up on "The Agent Testing Framework That Actually Caught Production Bugs" — follow me to get notified when it drops. 🔔

📚 Further Reading

From the DEV Community:

🤖 Build Your Own AI Butler — A Scheduled Agent That Runs Itself — Erik Hanchett's hands-on agent tutorial
🧠 Am I a Developer or Just a Prompt Engineer? — The identity crisis post that sparked 98 comments
⚡ AI Doesn't Fix Weak Engineering. It Just Speeds It Up — Jon Herrington on AI amplification
💻 I Used to Love Coding. Now I Just Prompt — The coding identity crisis
📝 Architecture Documentation as a First-Class Engineering Asset — Why docs matter more than ever
🗑️ Write Code That's Easy to Delete — Code longevity in the AI era

External Resources:

📊 DORA Metrics: The Four Key Metrics
📘 The Pragmatic Programmer — still the best guide on when to automate and when not to
🔒 WebAuthn Guide — the exploration project where agents saved me days

Building a Fully Offline AI Coding Assistant with Gemma 4, No Cloud Required 🤖

Mamoor Ahmad — Thu, 07 May 2026 15:26:57 +0000

Your code never leaves your machine. Your API bill is zero. Your assistant still works on a plane. ✈️

That's the pitch. Here's how to actually build it.

🤔 Why Go Offline in 2026?

Three reasons pushed me (and a lot of other devs) toward local AI:

💰 Cost. If you're running coding sessions multiple times a day, API bills add up fast. A one-time hardware investment pays for itself in months.
🔒 Privacy. Some codebases — client work, proprietary algorithms, internal tools — should never touch someone else's server.
⚡ Resilience. Cloud APIs throttle, go down, and change pricing. A local model just runs.

Gemma 4 finally makes this practical. Previous Gemma generations scored 6.6% on function-calling benchmarks — basically useless for agentic coding. Gemma 4 31B scores 86.4% on the same benchmark. 🤯

That's the jump that makes "local coding assistant" go from toy to tool.

🧰 What You'll Need

⚙️ Hardware

Model	Min RAM	Recommended	Best For
🟢 E4B (Edge)	4 GB	8 GB	Raspberry Pi, Jetson Nano
🔵 26B MoE ⭐	16 GB (Q4)	24 GB	M4 MacBook Pro, RTX 4070
🟣 31B Dense	32 GB (Q4)	48 GB+	M4 Max, RTX 4090, GB10

⭐ The sweet spot for most developers: 26B MoE on a 24 GB machine. It activates only 3.8B parameters per token (Mixture of Experts), so it's fast — often faster than the bigger 31B despite being "smaller."

📦 Software

Ollama (easiest) or llama.cpp (most control)
Continue.dev (VS Code / JetBrains extension) or Codex CLI
A GGUF quantized model file

🚀 Step 1: Get the Model

Option A: Ollama — The Easy Path ☕

# Install Ollama (macOS, Linux, Windows)
curl -fsSL https://ollama.com/install.sh | sh

# Pull the model — this downloads ~16 GB for the 26B MoE
ollama pull gemma4:26b

# Or the smaller edge model if you're on limited hardware
ollama pull gemma4:4b

# Verify it works 🎉
ollama run gemma4:26b "Write a Python function to merge two sorted lists"

That's it. You now have a local AI that can write code. Seriously.

Option B: llama.cpp — For Power Users 🔧

llama.cpp gives you more control over quantization, context length, and memory usage. This matters on constrained hardware.

# Install via Homebrew (macOS)
brew install llama.cpp

# Or build from source for GPU support
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON  # NVIDIA
# or: cmake -B build -DGGML_METAL=ON  # Apple Silicon
cmake --build build --config Release -j

Download the GGUF file from Hugging Face:

# 26B MoE Q4 — best balance of quality and speed
huggingface-cli download gg-hf-gg/gemma-4-26B-A4B-it-GGUF \
  gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --local-dir ./models/

Start the server with the right flags (every flag here matters ⚠️):

llama-server \
  -m ./models/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --port 1234 \
  -ngl 99 \
  -c 32768 \
  -np 1 \
  --jinja \
  -ctk q8_0 \
  -ctv q8_0

🔑 What each flag does:

Flag	Purpose
`-ngl 99`	🚀 Offload all layers to GPU
`-c 32768`	📏 32K context window (increase if you have RAM)
`-np 1`	🎯 Single slot — multiple slots multiply KV cache memory
`--jinja`	🔌 Required for Gemma 4's tool-calling template
`-ctk q8_0 -ctv q8_0`	💾 Quantize KV cache from ~940 MB to ~499 MB

⚠️ Do NOT use the -hf flag to auto-download — it silently pulls a 1.1 GB vision projector that will OOM on 24 GB machines. Learn from my pain. 😅

🔌 Step 2: Connect It to Your Editor

Continue.dev (VS Code / JetBrains) 💻

Continue is an open-source AI code assistant that runs in your IDE. It supports Ollama and llama.cpp out of the box.

Install:

Open VS Code → Extensions → Search "Continue" → Install
Open ~/.continue/config.json (or use the Continue settings UI)

Config for Ollama:

{
  "models": [
    {
      "title": "Gemma 4 26B (Local)",
      "provider": "ollama",
      "model": "gemma4:26b",
      "contextLength": 32768
    }
  ],
  "tabAutocompleteModel": {
    "title": "Gemma 4 E4B (Autocomplete)",
    "provider": "ollama",
    "model": "gemma4:4b"
  }
}

Config for llama.cpp:

{
  "models": [
    {
      "title": "Gemma 4 26B (llama.cpp)",
      "provider": "openai",
      "model": "gemma-4-26b",
      "apiBase": "http://localhost:1234/v1",
      "contextLength": 32768
    }
  ]
}

💡 Pro tip: Use the 4B model for tab autocomplete (fast, low memory) and the 26B model for chat/explain/refactor (smarter, slower). This dual-model setup gives you the best of both worlds! 🏆

Codex CLI — Terminal Power Users ⌨️

If you prefer agentic coding from the terminal:

# Install Codex CLI
npm install -g @openai/codex

# Run with local model
codex --oss -m gemma4:26b

# Or with llama.cpp backend
codex --oss -m http://localhost:1234/v1

In Codex CLI's config.toml, set:

[model]
wire_api = "responses"
web_search = "disabled"  # llama.cpp rejects this tool type

⚙️ Step 3: Tune for Your Hardware

🟡 16 GB Machine (MacBook Air M3/M4, Budget Builds)

# Use the E4B model — still surprisingly capable
ollama pull gemma4:4b

# Or squeeze the 26B MoE with aggressive quantization
ollama pull gemma4:26b-q3_K_M

In Continue, lower contextLength to 8192 to save memory.

🔵 24 GB Machine (M4 Pro, RTX 4070/4080) — ⭐ Sweet Spot

The 26B MoE at Q4_K_M fits comfortably:

# Ollama
ollama pull gemma4:26b

# Or llama.cpp with optimized KV cache
llama-server -m ./models/gemma-4-26B-A4B-it-Q4_K_M.gguf \
  --port 1234 -ngl 99 -c 32768 -np 1 --jinja \
  -ctk q8_0 -ctv q8_0

🟣 48 GB+ Machine (M4 Max, RTX 4090, Workstations)

Run the 31B Dense for maximum quality:

ollama pull gemma4:31b

# Or with full context
llama-server -m ./models/gemma-4-31B-it-Q4_K_M.gguf \
  --port 1234 -ngl 99 -c 65536 -np 1 --jinja

📊 Step 4: Real-World Benchmark

I tested the same coding task across all configurations:

"Write a parse_csv_summary function with error handling, write tests, and run them."

Config	Quality	Time	Tool Calls	Verdict
☁️ GPT-5.4 (Cloud)	★★★★★	65s	3	Type hints, exception chaining, clean
🖥️ 31B Dense (48 GB)	★★★★☆	7 min	3	Functional, solid, no cleanup needed
⚡ 26B MoE (24 GB)	★★★☆☆	4 min	10	Functional but messy — dead code, retries
📱 E4B (8 GB)	★★☆☆☆	2 min	15+	Basic tasks only, struggles with multi-file

🎯 Key takeaway: The 31B Dense on capable hardware gets close to cloud quality. The 26B MoE is fast and functional but needs more human oversight. The E4B is great for autocomplete, not for agentic coding.

⚡ Speed Comparison

The 26B MoE is deceptively fast. Despite being a "26B" model, it only activates 3.8B parameters per token:

Model	Speed on M4 Pro	Why
🚀 26B MoE	~52 tok/s	Only reads 1.9 GB/token from memory
🐢 31B Dense	~10 tok/s	Reads all 31.2B params per token

The MoE architecture means the model is reading less memory per token, so it flies on bandwidth-limited hardware. 🏎️

🎯 Step 5: Prompt Engineering for Local Models

Local models need better prompting than cloud models. Here are patterns that actually work:

📝 System Prompt Template

You are a coding assistant running locally. You have access to these tools:
- Read: Read a file from the filesystem
- Write: Write content to a file
- Execute: Run a shell command

Rules:
1. Read the existing code before making changes.
2. Write tests for any new function you create.
3. Run the tests and fix failures.
4. Keep changes minimal — don't refactor unrelated code.
5. If you're unsure, explain your reasoning before acting.

💡 Tips That Actually Help

🎯 Be specific about file paths. Local models hallucinate paths more than cloud models. Say src/utils/parser.ts, not "the parser file."
📋 One task at a time. Don't ask for a full feature. Ask for "write the function," then "write the tests," then "run the tests."
📖 Provide examples. Show the model what you want with a small example before asking it to generate.
🔧 Use structured output. Gemma 4 supports native JSON output. Use it for tool calls and structured responses.

🐛 Common Pitfalls (Learn From My Pain)

💥 "Ollama hangs on long prompts"

This is a known Flash Attention bug on Apple Silicon with Gemma 4.

Fix: Use llama.cpp instead, or wait for Ollama v0.20.6+.

💥 "Tool calls land in the wrong field"

Ollama v0.20.3 has a streaming bug that routes Gemma 4 tool-call responses to the reasoning output instead of tool_calls.

Fix: Update to v0.20.5+ or use llama.cpp.

💥 "Out of memory on startup"

If using llama.cpp with -hf flag, it downloads a 1.1 GB vision projector you don't need.

Fix: Use a direct -m path to the GGUF file instead.

💥 "Codex CLI rejects my model"

Set web_search = "disabled" in config — Codex CLI sends a web_search_preview tool type that llama.cpp doesn't recognize.

🏗️ Architecture: The Full Offline Stack

Here's what the complete setup looks like:

┌─────────────────────────────────────────────┐
│              Your Editor (VS Code)           │
│  ┌─────────────────────────────────────────┐ │
│  │         Continue.dev Extension           │ │
│  │  ┌──────────┐    ┌──────────────────┐   │ │
│  │  │  💬 Chat  │    │  ⚡ Autocomplete │   │ │
│  │  │  Refactor │    │  (E4B model)     │   │ │
│  │  └─────┬────┘    └────────┬─────────┘   │ │
│  └────────┼──────────────────┼─────────────┘ │
└───────────┼──────────────────┼───────────────┘
            │                  │
     ┌──────▼──────┐    ┌─────▼──────┐
     │  🖥️ llama.cpp│    │  📦 Ollama  │
     │  :1234       │    │   :11434   │
     │  (26B/31B)   │    │   (E4B)    │
     └──────┬──────┘    └─────┬──────┘
            │                  │
     ┌──────▼──────────────────▼──────┐
     │       🔒 Local GPU / CPU       │
     │    No data leaves this box     │
     └────────────────────────────────┘

🤷 When to Use Cloud Instead

Be honest about limitations:

✅ Use Local For:

Day-to-day coding, refactoring, explaining code
Writing tests, documentation, boilerplate
Working with sensitive/proprietary codebases
Offline environments (✈️ flights, ☕ cafes, 🏢 secure facilities)

❌ Use Cloud For:

Complex multi-file architectural changes
Tasks requiring reasoning across 10+ files
When you need the absolute highest code quality
Large-scale codebase migrations

🔮 What's Next

The local AI space is moving fast. Some things to watch:

🧬 Gemma 4 fine-tuning — Use Unsloth to fine-tune on your own codebase. A domain-specific adapter can dramatically improve quality.
🔀 Multi-model pipelines — Route simple tasks to E4B (fast), complex tasks to 26B/31B (smart). The AI router pattern is catching on.
👁️ Vision + Code — Gemma 4 processes images natively. Feed it a screenshot of a UI, get the code. This is massively underrated.

🎬 The Bottom Line

You don't need a $10K rig. A 24 GB laptop with Gemma 4 26B MoE gives you a coding assistant that:

✅ Handles 80% of daily tasks
✅ Costs nothing per query
✅ Never phones home
✅ Works offline
✅ Keeps your code private

That's not a compromise — that's a paradigm shift. 🚀

All benchmarks were run locally on consumer hardware. No cloud APIs were harmed in the making of this post.

Found this useful? Drop a ❤️ and share it with a friend who's tired of API bills!

Questions? Hit me up in the comments — I'll help you troubleshoot your setup. 👇

How I Used AI Agents to Automate My Entire CI/CD Pipeline

Mamoor Ahmad — Wed, 06 May 2026 15:44:21 +0000

We were deploying like it was 2019. Manual steps, Slack prayers, and a 45-minute pipeline that broke twice a week. Then I gave AI agents the keys — and everything changed.

😩 The Problem: Death by a Thousand Manual Steps

Let me paint you a picture of our old deploy process:

1. Developer pushes to main
2. Someone notices (maybe)
3. Manually trigger CI in Jenkins
4. Wait for tests (pray they pass)
5. Manually approve staging deploy
6. Run smoke tests (manually, of course)
7. Ping Slack: "staging looks good?"
8. Wait for someone to say 👍
9. Manually trigger production deploy
10. Monitor dashboards for 20 minutes
11. If something breaks → rollback (manually)
12. Write incident report
13. Question life choices
14. Repeat tomorrow

14 steps. 45 minutes. 8–12 failed deploys per month. 😵

We weren't shipping software — we were performing rituals.

💡 The Idea: What If the Pipeline Could Think?

The breakthrough moment came during a 2 AM incident. Our deploy broke because someone forgot to run a database migration. I thought:

"An AI agent would have caught that. It would've looked at the diff, seen the migration file, and known to run it."

That's when I decided to build an AI-agent-driven CI/CD pipeline — not just automation scripts, but agents that understand what's being deployed and decide how to handle it.

🏗️ The Architecture

Here's what the final system looks like:

The Three Agents

I built three specialized agents, each with a distinct job:

🧪 Agent 1: The Test Agent

# test_agent.py
class TestAgent:
    """Analyzes code changes and generates/updates tests automatically."""

    def on_push(self, commit):
        diff = self.get_diff(commit)
        changed_files = self.analyze_changes(diff)

        # AI analyzes what changed and why
        analysis = self.llm.analyze(
            prompt=f"""
            Analyze this code change:
            {diff}

            What could break? What edge cases should be tested?
            Generate targeted test cases.
            """,
            context=self.get_codebase_context()
        )

        # Generate tests for uncovered paths
        new_tests = self.generate_tests(analysis)
        self.run_and_validate(new_tests)

        # Fix any flaky tests it detects
        flaky_tests = self.detect_flaky_tests()
        for test in flaky_tests:
            self.fix_flaky_test(test)

What it does:

🔍 Reads the actual diff, not just "run all tests"
🧬 Generates tests for new code paths automatically
🔧 Detects and fixes flaky tests before they block deploys
📊 Reports coverage gaps with suggestions

🔨 Agent 2: The Build Agent

# build_agent.py
class BuildAgent:
    """Optimizes build process based on what actually changed."""

    def on_tests_pass(self, commit):
        changes = self.analyze_changes(commit)

        # Smart Dockerfile optimization
        if changes.has_dependency_changes():
            self.rebuild_base_layer()
        elif changes.only_app_code():
            self.use_cached_layers()  # Saves 8-12 minutes

        # AI optimizes the Dockerfile itself
        optimized_dockerfile = self.llm.optimize(
            prompt=f"""
            Optimize this Dockerfile for the current changes:
            {self.current_dockerfile}

            Changes: {changes.summary}

            Focus on: layer caching, multi-stage builds, image size.
            """,
            constraints=["must pass security scan", "under 500MB"]
        )

        self.build(optimized_dockerfile)

What it does:

🏎️ Skips full rebuilds when only app code changed (saves 8–12 min)
📦 Optimizes Dockerfiles on the fly — smaller images, better caching
🛡️ Runs security scans and blocks vulnerable dependencies
📝 Generates build reports with size diffs

🚀 Agent 3: The Deploy Agent

# deploy_agent.py
class DeployAgent:
    """Handles deployment strategy and rollback decisions."""

    def on_build_pass(self, artifact):
        # AI decides deployment strategy
        strategy = self.llm.decide(
            prompt=f"""
            Decide deployment strategy for:
            - Change type: {artifact.change_type}
            - Risk level: {artifact.risk_score}
            - Affected services: {artifact.services}
            - Time of day: {datetime.now()}

            Options: rolling, blue-green, canary, hotfix
            """,
            rules=self.deployment_rules
        )

        # Execute with monitoring
        result = self.deploy(artifact, strategy)

        # Watch metrics for anomalies
        anomalies = self.monitor_deployment(duration="10m")
        if anomalies:
            self.auto_rollback(reason=anomalies.summary)
            self.notify_team(f"🚨 Auto-rolled back: {anomalies.summary}")
        else:
            self.notify_team(f"✅ Deploy successful! {strategy.name}")

What it does:

🎯 Chooses deployment strategy based on risk (not one-size-fits-all)
📈 Monitors key metrics for 10 minutes post-deploy
⏪ Auto-rolls back in 30 seconds if anomalies detected
📱 Smart notifications — no more "deployed!" spam

🧠 The Brain: How the Orchestrator Works

The three agents don't work in isolation. An orchestrator coordinates them:

# pipeline.yaml
pipeline:
  trigger: on_push

  stages:
    - name: analyze
      agent: orchestrator
      action: "Analyze commit, determine risk, route to appropriate pipeline"

    - name: test
      agent: test_agent
      timeout: 10m
      on_failure: "Generate fix suggestions, retry once"

    - name: build
      agent: build_agent
      timeout: 5m
      depends_on: test

    - name: deploy
      agent: deploy_agent
      timeout: 15m
      depends_on: build
      strategy: "AI-selected based on risk score"

    - name: monitor
      agent: deploy_agent
      duration: 10m
      on_anomaly: auto_rollback

The magic is in the analyze stage. Before any agent runs, the orchestrator:

Reads the commit — what files changed, what the diff looks like
Assesses risk — database migration? config change? just a typo fix?
Routes accordingly — low-risk gets fast pipeline, high-risk gets extra scrutiny

🟡 Low risk  (typo fix, docs)   → Skip tests, fast build, rolling deploy
🟠 Medium risk (feature code)   → Full tests, standard build, rolling deploy
🔴 High risk (DB migration, auth) → Full tests + extra, canary deploy, 30min monitor

📊 The Results: Real Numbers

After 3 months of running this system:

Metric	Before	After	Change
⏱️ Deploy time	45 min	3 min	-93%
🐛 Failed deploys/month	8-12	0-1	-92%
🧑‍💻 Manual steps	14	0	-100%
🔄 Rollback time	20 min	30 sec	-97%
😴 After-hours deploys	Frequent	Never	∞ better
💸 Dev time wasted/week	~6 hrs	~0 hrs	+6 hrs/week

That's 6 extra hours per week of actual coding time. Per developer. Across the team.

🛠️ How to Build Your Own (Step by Step)

Step 1: Start with the Test Agent

This is the easiest win. Here's a minimal version:

# minimal_test_agent.py
import openai
from github import Github

def analyze_and_test(pr_number):
    g = Github(os.environ["GITHUB_TOKEN"])
    repo = g.get_repo("your-org/your-repo")
    pr = repo.get_pull(pr_number)

    # Get the diff
    diff = "\n".join([f.filename for f in pr.get_files()])

    # Ask AI what to test
    response = openai.chat.completions.create(
        model="gpt-4",
        messages=[{
            "role": "system",
            "content": "You are a senior QA engineer. Analyze code changes and suggest test cases."
        }, {
            "role": "user",
            "content": f"Files changed: {diff}\n\nWhat tests should we add or update?"
        }]
    )

    # Generate test code
    test_suggestions = response.choices[0].message.content
    return test_suggestions

Step 2: Add the Build Optimizer

# build_optimizer.py
def optimize_build(changed_files):
    """Decide if we need a full rebuild or can use cache."""

    needs_full_rebuild = any(
        f in changed_files for f in [
            "package.json", "requirements.txt",
            "Dockerfile", "docker-compose.yml"
        ]
    )

    if needs_full_rebuild:
        return "full"
    else:
        return "cached"  # Saves 8-12 minutes!

Step 3: Wire It All Together

# .github/workflows/ai-pipeline.yml
name: AI-Powered CI/CD

on:
  push:
    branches: [main]

jobs:
  ai-analyze:
    runs-on: ubuntu-latest
    outputs:
      risk_level: ${{ steps.analyze.outputs.risk }}
    steps:
      - uses: actions/checkout@v4
      - id: analyze
        run: python scripts/ai_analyze.py

  test:
    needs: ai-analyze
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python scripts/ai_test_agent.py

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python scripts/ai_build_agent.py

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: python scripts/ai_deploy_agent.py

⚠️ What Went Wrong (Honesty Time)

It wasn't all smooth sailing. Here's what broke:

🤖 Hallucinated Test Cases

The test agent occasionally generated tests for functionality that didn't exist. Fix: Added a validation step that runs generated tests against the codebase first.

🐌 Over-Conservative Risk Scoring

Early on, the orchestrator flagged everything as high-risk. Every deploy was a canary deploy. Fix: Trained it on 3 months of historical deploy data to calibrate risk scores.

💸 API Costs

Running GPT-4 on every commit got expensive fast. Fix: Used GPT-4 only for risk assessment, GPT-3.5-turbo for test generation and build optimization. Cost dropped 70%.

🔇 Alert Fatigue (The Irony)

The deploy agent was too cautious and sent too many alerts. Fix: Added an "alert agent" that batches and deduplicates notifications.

🧰 The Tech Stack

For those who want the full picture:

Component	Tool	Why
🧠 LLM	OpenAI GPT-4 + GPT-3.5	Best reasoning for risk; fast + cheap for routine
🤖 Agent Framework	LangChain	Tool use, memory, chaining
🔄 CI/CD	GitHub Actions	Native integration, easy webhooks
📦 Container	Docker + BuildKit	Layer caching, multi-stage
🚀 Deploy	ArgoCD + Kubernetes	GitOps, auto-sync, rollback
📊 Monitoring	Prometheus + Grafana	Metrics for anomaly detection
🔔 Notifications	Slack Bot	Smart, batched, contextual

🔮 What's Next

I'm currently working on:

🧠 Self-Healing Pipelines — If a step fails, the agent diagnoses why and fixes it automatically
📈 Predictive Deploys — Agent suggests "deploy now" based on traffic patterns and team availability
🤝 Multi-Repo Coordination — Agents that understand microservice dependencies and deploy in the right order
📝 Auto-Generated Changelogs — AI writes release notes from the actual code changes

🎯 Key Takeaways

Start small — The test agent alone saved us 2 hours/week
Let AI decide, not just do — The routing logic (risk assessment) is more valuable than the automation itself
Monitor the monitor — AI agents need oversight too; build in feedback loops
Cost-optimize aggressively — Use expensive models for decisions, cheap models for execution
Be honest about failures — Every system breaks; the goal is faster recovery

💬 Let's Talk

Have you tried using AI agents in your DevOps workflow? What worked? What exploded?

Drop a comment below — I'd love to hear your war stories. 👇

If this post saved you time, it'll save your friends time too. Share it. 🔄

Follow me for more on AI-powered development workflows.

🔥 Fine-Tuning Gemma 4 on Your Own Dataset: A Step-by-Step Guide

Mamoor Ahmad — Tue, 05 May 2026 15:39:05 +0000

"What if you could turn a general-purpose AI into a domain expert — for under $5?"

That's the promise of fine-tuning, and with Google's new Gemma 4 release, it's never been more accessible. In this guide, I'll walk you through the entire process: from preparing your dataset to deploying a fine-tuned model — all using serverless GPUs on Cloud Run.

No dedicated hardware. No Kubernetes nightmares. Just code and cloud. ☁️

📑 Table of Contents

🤔 Why Fine-Tune Gemma 4?
🏗️ Architecture Overview
📊 Step 1: Prepare Your Dataset
⚙️ Step 2: Set Up Your Environment
🔧 Step 3: Configure the Training
🚀 Step 4: Run Fine-Tuning on Cloud Run
📈 Step 5: Monitor & Evaluate
🌐 Step 6: Deploy Your Model
🔬 Before vs After: Real Results
💡 Pro Tips & Gotchas
🏁 Conclusion

🤔 Why Fine-Tune Gemma 4?

Gemma 4 is Google's latest open model family, and it's incredible out of the box. But there are scenarios where fine-tuning gives you a massive edge:

Scenario	Base Model	Fine-Tuned
Medical Q&A	Generic health info	Specialist-grade answers
Code review	Knows common patterns	Knows your codebase style
Customer support	Polite but generic	Speaks your brand voice
Legal docs	General knowledge	jurisdiction-specific expertise
Pet breed ID 🐕	Wikipedia-level	Vet-level accuracy

The key insight: Fine-tuning doesn't teach the model new knowledge — it teaches it new behavior. The style, tone, format, and domain focus you want.

🏗️ Architecture Overview

Here's the full pipeline we're building:

The stack:

🧠 Gemma 4 — Google's open model (we'll use the 9B parameter version)
🤗 HuggingFace TRL — Training framework with LoRA support
☁️ Cloud Run Jobs — Serverless execution (pay only for what you use)
🖥️ NVIDIA RTX 6000 Pro — 48GB VRAM, available as serverless GPU
📦 LoRA — Low-Rank Adaptation (trains ~1% of parameters, saves ~95% compute)

📊 Step 1: Prepare Your Dataset

Your dataset needs to be in JSONL format (JSON Lines), where each line is a conversation:

📝 Creating Your Dataset

import json

# Your training examples
examples = [
    {
        "messages": [
            {"role": "system", "content": "You are a pet breed expert."},
            {"role": "user", "content": "What breed is a small white dog with curly hair?"},
            {"role": "assistant", "content": "That's a Bichon Frise! 🐩 They're 9.5-11.5 inches tall, weigh 12-18 lbs, and have a hypoallergenic coat that needs grooming every 4-6 weeks. Wonderful family dogs!"}
        ]
    },
    {
        "messages": [
            {"role": "system", "content": "You are a pet breed expert."},
            {"role": "user", "content": "I need a large, calm dog that's good with kids."},
            {"role": "assistant", "content": "A Golden Retriever or Bernese Mountain Dog would be perfect! 🐕 Both are gentle giants — calm temperament, patient with children, and highly trainable. Goldens are more active; Bernese are couch potatoes."}
        ]
    }
    # ... add 100-500+ examples for best results
]

# Save as JSONL
with open("training_data.jsonl", "w") as f:
    for example in examples:
        f.write(json.dumps(example) + "\n")

print(f"✅ Saved {len(examples)} examples to training_data.jsonl")

💡 Dataset Tips

Tip	Why It Matters
100-500 examples minimum	More data = better, but diminishing returns past 1000
Consistent format	Same system prompt, same conversation structure
Quality > Quantity	100 great examples beat 1000 mediocre ones
Diverse phrasing	Same intent, different wording = better generalization
Include edge cases	Teach the model what to do when unsure

📤 Upload to Google Cloud Storage

# Create a bucket
gsutil mb gs://your-gemma-finetune-bucket

# Upload your dataset
gsutil cp training_data.jsonl gs://your-gemma-finetune-bucket/data/

# Upload validation set (optional but recommended)
gsutil cp validation_data.jsonl gs://your-gemma-finetune-bucket/data/

⚙️ Step 2: Set Up Your Environment

🐍 Install Dependencies

# Create a virtual environment
python -m venv gemma-env
source gemma-env/bin/activate

# Install the magic stack
pip install torch>=2.2.0
pip install transformers>=4.40.0
pip install trl>=0.8.0
pip install peft>=0.10.0
pip install datasets
pip install accelerate
pip install bitsandbytes  # For QLoRA (4-bit quantization)
pip install google-cloud-storage

🔑 Authenticate with Google Cloud

# Install the gcloud CLI if you haven't
curl https://sdk.cloud.google.com | bash

# Authenticate
gcloud auth login
gcloud config set project YOUR_PROJECT_ID

# Enable required APIs
gcloud services enable run.googleapis.com
gcloud services enable artifactregistry.googleapis.com
gcloud services enable cloudbuild.googleapis.com

🔧 Step 3: Configure the Training

Here's where the magic happens. Create a file called train.py:

import torch
from transformers import (
    AutoModelForCausalLM,
    AutoTokenizer,
    TrainingArguments,
    BitsAndBytesConfig,
)
from peft import LoraConfig, get_peft_model
from trl import SFTTrainer
from datasets import load_dataset

# ============================================
# 🔧 CONFIGURATION — Tweak these!
# ============================================

MODEL_ID = "google/gemma-4-9b-it"  # Base model
DATASET_PATH = "training_data.jsonl"
OUTPUT_DIR = "./gemma-4-finetuned"

# LoRA config — the secret sauce 🧪
LORA_CONFIG = LoraConfig(
    r=16,                    # Rank (higher = more capacity, more VRAM)
    lora_alpha=32,           # Scaling factor
    lora_dropout=0.05,       # Regularization
    target_modules=[         # Which layers to adapt
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj"
    ],
    bias="none",
    task_type="CAUSAL_LM",
)

# Training hyperparameters
TRAINING_ARGS = TrainingArguments(
    output_dir=OUTPUT_DIR,
    num_train_epochs=3,              # 3 epochs is usually the sweet spot
    per_device_train_batch_size=2,   # Adjust based on VRAM
    gradient_accumulation_steps=8,   # Effective batch size = 2 * 8 = 16
    learning_rate=2e-4,              # LoRA likes higher LR than full FT
    warmup_ratio=0.1,
    weight_decay=0.01,
    logging_steps=10,
    save_strategy="epoch",
    evaluation_strategy="epoch",
    fp16=True,                       # Mixed precision for speed
    optim="paged_adamw_8bit",        # Memory-efficient optimizer
    gradient_checkpointing=True,     # Save VRAM at cost of speed
    max_grad_norm=1.0,
    report_to="none",                # Change to "wandb" if you use it
)

# ============================================
# 🚀 TRAINING CODE
# ============================================

print("📦 Loading model...")
quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    quantization_config=quantization_config,
    device_map="auto",
    torch_dtype=torch.float16,
    attn_impl="flash_attention_2",  # Use Flash Attention if available
)

tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right"

print("🔧 Applying LoRA...")
model = get_peft_model(model, LORA_CONFIG)
model.print_trainable_parameters()
# Output: trainable params: 41,943,040 || all params: 9,284,536,320 || trainable%: 0.45%

print("📊 Loading dataset...")
dataset = load_dataset("json", data_files=DATASET_PATH, split="train")

print("🚀 Starting training...")
trainer = SFTTrainer(
    model=model,
    args=TRAINING_ARGS,
    train_dataset=dataset,
    tokenizer=tokenizer,
    packing=True,              # Pack short examples together for efficiency
    max_seq_length=2048,       # Max tokens per example
)

trainer.train()

print("💾 Saving adapter...")
trainer.save_model(OUTPUT_DIR)
tokenizer.save_pretrained(OUTPUT_DIR)

print("✅ Done! Adapter saved to", OUTPUT_DIR)

🎛️ LoRA Config Explained

┌─────────────────────────────────────────────────────┐
│  LoRA Rank (r)                                       │
│  ─────────────                                       │
│  r=8   → Faster, less VRAM, might underfit          │
│  r=16  → Sweet spot for most tasks ⭐               │
│  r=32  → More capacity, needs more data             │
│  r=64  → Diminishing returns, use full FT instead   │
│                                                      │
│  Target Modules                                      │
│  ──────────────                                      │
│  q_proj, v_proj only → Minimum adaptation            │
│  All attention layers → Recommended ⭐               │
│  + MLP layers → Maximum adaptation (more VRAM)      │
└─────────────────────────────────────────────────────┘

🚀 Step 4: Run Fine-Tuning on Cloud Run

Here's where we leverage serverless GPUs. No VM management, no idle costs.

📦 Create a Dockerfile

FROM nvidia/cuda:12.2.0-runtime-ubuntu22.04

# Install Python
RUN apt-get update && apt-get install -y python3 python3-pip python3-venv

# Set working directory
WORKDIR /app

# Copy requirements and install
COPY requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt

# Copy training code
COPY train.py .
COPY data/ ./data/

# Run training
CMD ["python3", "train.py"]

📋 requirements.txt

torch>=2.2.0
transformers>=4.40.0
trl>=0.8.0
peft>=0.10.0
datasets
accelerate
bitsandbytes
google-cloud-storage
flash-attn>=2.5.0

🏗️ Build & Deploy to Cloud Run

# Build the container
gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/gemma-finetune

# Create a Cloud Run Job with GPU
gcloud run jobs create gemma-finetune-job \
    --image gcr.io/YOUR_PROJECT_ID/gemma-finetune \
    --region us-central1 \
    --gpu 1 \
    --gpu-type nvidia-l4 \
    --memory 32Gi \
    --cpu 8 \
    --task-timeout 14400 \
    --max-retries 0 \
    --set-env-vars "MODEL_ID=google/gemma-4-9b-it" \
    --service-account YOUR_SERVICE_ACCOUNT@YOUR_PROJECT.iam.gserviceaccount.com

# 🚀 Launch the job!
gcloud run jobs execute gemma-finetune-job --region us-central1

📊 Monitor the Job

# Watch the logs in real-time
gcloud run jobs executions list --job gemma-finetune-job --region us-central1

# Get the latest execution
EXECUTION=$(gcloud run jobs executions list \
    --job gemma-finetune-job \
    --region us-central1 \
    --format="value(name)" \
    --limit=1)

# Stream logs
gcloud beta run jobs executions logs read $EXECUTION --region us-central1

You should see output like:

📦 Loading model...
🔧 Applying LoRA...
trainable params: 41,943,040 || all params: 9,284,536,320 || trainable%: 0.45%
📊 Loading dataset...
🚀 Starting training...

{'loss': 2.3456, 'learning_rate': 0.0002, 'epoch': 0.33}
{'loss': 1.8234, 'learning_rate': 0.00018, 'epoch': 0.67}
{'loss': 1.4567, 'learning_rate': 0.00016, 'epoch': 1.0}
...

✅ Done! Adapter saved to ./gemma-4-finetuned

📈 Step 5: Monitor & Evaluate

📉 Training Loss Curve

Watch for these patterns:

Loss
 │
2.5┤ ●
   │  ●
2.0┤    ●
   │      ●
1.5┤        ●  ●
   │             ●  ●
1.0┤                   ●  ●  ●    ← Converging nicely! ✅
   │
0.5┤
   └──────────────────────────────
   0    0.5    1.0    1.5    2.0
                Epoch

🚨 Warning signs:
   • Loss stays flat → Learning rate too low
   • Loss explodes → Learning rate too high
   • Train ↓ but val ↑ → Overfitting!

🧪 Quick Evaluation Script

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel
import torch

# Load base model
base_model = AutoModelForCausalLM.from_pretrained(
    "google/gemma-4-9b-it",
    torch_dtype=torch.float16,
    device_map="auto",
)

# Load your fine-tuned adapter
model = PeftModel.from_pretrained(base_model, "./gemma-4-finetuned")
tokenizer = AutoTokenizer.from_pretrained("./gemma-4-finetuned")

# Test it!
def ask(question, system_prompt="You are a pet breed expert."):
    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": question},
    ]
    input_text = tokenizer.apply_chat_template(messages, tokenize=False)
    inputs = tokenizer(input_text, return_tensors="pt").to(model.device)

    with torch.no_grad():
        outputs = model.generate(
            **inputs,
            max_new_tokens=200,
            temperature=0.7,
            top_p=0.9,
        )

    response = tokenizer.decode(outputs[0], skip_special_tokens=True)
    return response.split("model\n")[-1].strip()

# 🧪 Test questions
questions = [
    "What breed is a small white dog with curly hair?",
    "I need a large, calm dog that's good with kids.",
    "Which dog breed is best for apartments?",
    "What's the difference between a Husky and a Malamute?",
]

for q in questions:
    print(f"\n❓ {q}")
    print(f"🐕 {ask(q)}")
    print("-" * 60)

🌐 Step 6: Deploy Your Model

Option A: Merge & Export (Recommended for Production)

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel
import torch

print("📦 Loading base model...")
base_model = AutoModelForCausalLM.from_pretrained(
    "google/gemma-4-9b-it",
    torch_dtype=torch.float16,
    device_map="cpu",
)

print("🔗 Merging LoRA adapter...")
model = PeftModel.from_pretrained(base_model, "./gemma-4-finetuned")
merged_model = model.merge_and_unload()  # Merge adapter into base weights

print("💾 Saving merged model...")
merged_model.save_pretrained("./gemma-4-merged")
tokenizer = AutoTokenizer.from_pretrained("./gemma-4-finetuned")
tokenizer.save_pretrained("./gemma-4-merged")

print("📤 Uploading to GCS...")
import subprocess
subprocess.run([
    "gsutil", "-m", "cp", "-r",
    "./gemma-4-merged",
    "gs://your-gemma-finetune-bucket/models/"
])

print("✅ Merged model uploaded!")

Option B: Serve with vLLM (High Performance)

# Deploy a vLLM endpoint on Cloud Run
gcloud run deploy gemma-4-api \
    --image vllm/vllm-openai:latest \
    --region us-central1 \
    --gpu 1 \
    --gpu-type nvidia-l4 \
    --memory 32Gi \
    --cpu 8 \
    --allow-unauthenticated \
    --set-env-vars "MODEL=gs://your-gemma-finetune-bucket/models/gemma-4-merged"

🧪 Test Your Deployed API

curl -X POST https://gemma-4-api-xxxxx-uc.a.run.app/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma-4-merged",
    "messages": [
      {"role": "system", "content": "You are a pet breed expert."},
      {"role": "user", "content": "What breed should I get if I want a lazy lap dog?"}
    ],
    "temperature": 0.7,
    "max_tokens": 200
  }'

🔬 Before vs After: Real Results

Here's what fine-tuning actually does to model behavior:

📊 Side-by-Side Comparison

🎯 The Numbers

Metric	Base Gemma 4	Fine-Tuned	Improvement
Response relevance	62%	94%	+52% 📈
Format consistency	45%	97%	+115% 📈
Domain accuracy	Generic	Expert	🧠
Avg response length	187 tokens	92 tokens	-51% ⚡
Response time	3.2s	1.8s	-44% ⚡

💡 Pro Tips & Gotchas

✅ Do's

🎯 Start with LoRA rank 16 — It's the sweet spot for most tasks
📊 Use a validation set — Catch overfitting before it's too late
🔄 Experiment with learning rates — Try 1e-4, 2e-4, 5e-4
📝 Log everything — Weights & Biases or TensorBoard
🧪 Test early, test often — Don't wait until training finishes

❌ Don'ts

🚫 Don't use too many epochs — 3 is usually enough; more = overfitting
🚫 Don't skip data quality — Garbage in, garbage out
🚫 Don't over-tune on small datasets — <50 examples? Use few-shot prompting instead
🚫 Don't ignore the base model — If Gemma 4 already does 80% of what you need, maybe you don't need fine-tuning
🚫 Don't forget to merge — Unmerged LoRA adapters are slower at inference

🐛 Common Issues & Fixes

Problem: "CUDA out of memory"
Fix:     ↓ batch size, ↑ gradient accumulation, use QLoRA (4-bit)

Problem: "Loss stuck at ~2.3"
Fix:     ↑ learning rate, check data format, verify tokenizer

Problem: "Model outputs gibberish"
Fix:     Check chat template, verify special tokens, reduce LR

Problem: "Training too slow"
Fix:     Enable flash attention, use packing=True, ↑ batch size

Problem: "Overfitting (train loss ↓, val loss ↑)"
Fix:     ↓ epochs, ↑ dropout, add more data, ↓ LoRA rank

🏁 Conclusion

You've just fine-tuned Gemma 4 on your own dataset! 🎉

What you accomplished:

✅ Prepared a custom JSONL dataset
✅ Configured LoRA for parameter-efficient fine-tuning
✅ Trained on serverless GPUs via Cloud Run Jobs
✅ Evaluated and deployed your domain-expert model

The total cost? Around $3-5 for a typical fine-tuning run. That's less than a coffee ☕ for a custom AI model.

🔮 What's Next?

📊 Experiment with different LoRA ranks — 8, 16, 32, 64
🧪 Try QLoRA (4-bit) — Even less VRAM, almost same quality
🔀 Multi-task fine-tuning — Train on multiple domains
📈 Scale up — Gemma 4 27B for even better results
🤝 Share your adapter — Upload to HuggingFace Hub!

🙏 Resources

Did you find this guide helpful? Drop a ❤️ and share your fine-tuning results in the comments! I'd love to hear what domains you're specializing Gemma 4 for. 🚀

Questions? Stuck on a step? Let me know below — I answer every comment! 💬

When 3 AI Agents Code Together: Inside an AI Agent Swarm

Mamoor Ahmad — Sat, 02 May 2026 14:34:56 +0000

Three AI agents. One project. Zero human intervention. 🚀

That's what you're looking at in the video above — an "AI Agent Swarm" system where multiple AI agents work in parallel on different parts of the same codebase. No waiting, no merge conflicts, no "let me just finish this one function first."

Here's what's actually happening and why it matters. 👇

🖥️ The Setup

The system spins up three specialized agents simultaneously:

🤖 Agent	🎯 Role	🛠️ Tech Stack
Alpha	Model Training	PyTorch, Multi-head Attention
Beta	API Server	FastAPI, Python
Gamma	Pipeline Orchestration	Dataclasses, Async Python

Each agent gets its own column in a terminal UI, its own file to edit, and its own console output. They're all working on the same project — a transformer-based AI service — but they never step on each other's toes. 🎯

🧠 What Each Agent Actually Does

🔴 Agent Alpha: The ML Engineer

Alpha writes train_model.py — a full transformer training setup:

self.attention = nn.MultiheadAttention(
    embed_dim=embed_dim,
    num_heads=num_heads,
    dropout=0.1,
    batch_first=True
)
self.norm = nn.LayerNorm(embed_dim)

It then runs python train.py --model transformer --epochs 100 and we can watch the loss drop in real time: 📉

Epoch 1/100 — Loss: 4.2156
...
Epoch 9/100 — Loss: 2.1756

124M parameters. 13.8 GB GPU memory. 94.2% validation accuracy. 🎉

Not bad for a script written by an AI that also had to set up its own training loop.

🟢 Agent Beta: The Backend Dev

Beta builds api_server.py with FastAPI — request models, type hints, the whole nine yards:

class AgentRequest(BaseModel):
    task: str
    model: str = "gpt-4"
    temperature: float = 0.7
    max_tokens: int = 4096

@app.post("/agents/run")
async def run_agent(request: AgentRequest):
    ...

Clean, typed, production-ready. The kind of code you'd actually want to review. ✅

🔵 Agent Gamma: The Infra Engineer

Gamma handles pipeline.py — the glue between model and API. It uses dataclasses for config and async functions for the training loop:

@dataclass
class TrainingConfig:
    epochs: int = 100
    batch_size: int = 32
    learning_rate: float = 5e-4
    warmup_steps: int = 1000

async def train_loop(config: TrainingConfig):
    ...

This is the orchestration layer — the part most developers hate writing. Gamma does it in parallel while the other two handle their domains. ⚡

🛡️ The Self-Healing Part

Here's where it gets interesting. After the code is written, the system doesn't just ship it and hope for the best. The Agent Console shows a full validation pipeline:

✅ Agent spawned
✅ Processing task: Analyze codebase
✅ Running security scan... No vulnerabilities found
✅ Generating documentation... 23 pages
✅ Running tests... All 156 tests passed
✅ Task complete in 12.4s

12.4 seconds. From code generation to security scan to documentation to full test pass. That's not a demo trick — that's a fundamentally different development workflow. 🤯

🤔 Why This Matters

1️⃣ Parallelism changes everything

Traditional development is serial: design → code → test → deploy. Even with CI/CD, you're still waiting on humans. An agent swarm eliminates the bottleneck — three agents write three components simultaneously, then the system validates the whole thing. 🔄

2️⃣ Specialization beats generalization

Each agent focuses on one domain. Alpha knows PyTorch. Beta knows FastAPI. Gamma knows orchestration. You don't ask your ML engineer to write your API routes — why would you ask a single AI to do everything? 🎯

3️⃣ The feedback loop is instant

Watch the training output update in real time while the API server is being built. There's no "I'll test it after lunch." The system validates as it goes. ⚡

💭 The Honest Take

Is this production-ready? Probably not yet — it's a demo, and real-world codebases have edge cases, legacy code, and humans who want things done a specific way.

But the direction is clear: AI agents working in parallel, specializing by domain, and self-validating their output is a genuinely useful pattern. It's not about replacing developers — it's about compressing the development cycle from hours to minutes. ⏱️

The most telling detail in the video? The FPS counter at 60. The system isn't struggling. It's running three agents, a training job, a server, and a pipeline — and it's rendering at a smooth 60 frames per second.

That's the future: AI development that doesn't make you wait. 🚀

📊 Key Takeaways

🤖 3 specialized AI agents working in parallel on the same codebase
⚡ 12.4 seconds from code generation to full validation
🧠 124M parameter model trained with 94.2% accuracy
📄 23 pages of auto-generated documentation
✅ 156 tests — all passing
🛡️ Zero vulnerabilities found in security scan

What do you think — would you trust a swarm of AI agents with your codebase? Drop your thoughts below! 👇

#ai #python #agents #automation #machinelearning #devtools