DEV Community: Mamoor Ahmad

Enigma's Echo — AI-Powered Cryptanalysis Console (Bletchley Park)

Mamoor Ahmad — Wed, 10 Jun 2026 08:24:01 +0000

Enigma's Echo 🕵️‍♂️📟

What I Built 🛠️

Enigma's Echo is an interactive, browser-based cryptanalysis simulation game set in the historic Bletchley Park (Hut 8) in 1941. The player acts as a codebreaker tasked with decrypting intercepted German transmissions. Instead of writing code or manually shifting letters, you configure the decryption machine using natural language commands which are compiled in real-time using Google's Gemini API.

The console interface mimics a vintage CRT monitor, complete with scanline filters, flickering glow effects, mechanical rotor dial animations, and dynamically synthesized typewriter sounds.

As a spiritual successor to my previous Bletchley-themed rhythm game, Turing's Frequency, this project pushes the boundaries of automated cryptanalysis. Furthermore, following my work on Planetary Pulse, I wanted to focus on creating an asset-free, purely synthesized audio and visual experience.

Connection to Theme 🌅

The game embraces the core themes of the June Solstice Game Jam:

The June Solstice (Light vs. Dark) ☀️: Puzzles revolve around balancing "daylight" and "shadows." Decrypting ciphers prevents the shadows from taking over, aligning with the Solstice's celebration of peak light.
Pride & Alan Turing's Birthday 🏳️‍🌈: The game is a direct tribute to Alan Turing, Bletchley Park, and the birth of modern computing.
Alan Turing Legacy 🧠: Level 4 simulates a dual-rotor Enigma configuration, requiring players to set the rotor starting positions to the initials of the June Solstice (J and S for June/Solstice, representing positions 9 and 18) to decode the target ciphertext.

Demo ⚡

Playable Game Link: https://mamoor123.github.io/enigmas-echo/
Automated Demo Link: https://mamoor123.github.io/enigmas-echo/demo.html
Demo Video (YouTube): https://www.youtube.com/watch?v=uLoC8HF9cY4

Here is a look at the Bombe Co-Processor Logs in action during automated simulation:

Journey 🚀

How I Built It 🧰

I wanted to build a game that had zero heavy assets—no loading screens, no heavy images, and no downloaded audio files.

Integrating Google Gemini as an agent-like co-processor builds on my recent experiences working with autonomous coding workflows. In my posts I Sent One Message and 5 AI Agents Built, Audited, Tested & Deployed a Full App and AI Agents Replaced My Dev Workflow — Here's What Broke, I explored the practical limits of AI delegation. Enigma's Echo shows how natural language can serve as an elegant, immediate interface for direct human-agent collaboration in high-stakes environments like decryption grids.

Visuals: Rendered entirely using lightweight vanilla HTML/CSS. I used HSL-tailored matrix-green themes, glowing text-shadows, radial gradients, and linear scanlines to simulate a vintage CRT screen.
Web Audio API Synthesis 🎵: Rather than loading MP3 sound files, the game utilizes the browser's native Web Audio API to dynamically synthesize typewriter clicks (a noise burst + fast lowpass decay), rotor dial whirs (sawtooth frequency sweeps), and success arpeggios (C major chord progression).
AI Integration (Gemini 1.5 Flash) 🤖: The core mechanic uses Google Gemini API as a natural language compiler. When the user types an instruction like "reverse the text, shift left by 3 and swap the case", the app sends it to Gemini, which returns a clean JSON instruction array: [{"type": "reverse"}, {"type": "caesar", "shift": -3}, {"type": "swapcase"}] The game's engine then processes these steps on the ciphertext, accompanied by mechanical rotor dial rotation animations.
Local Simulation Fallback 🔒: If the player does not have a Gemini API key configured, the game falls back to a regex-based pattern matching compiler. This allows the game to remain 100% playable offline or key-free while showcasing the API benefits.

Special Category Submissions 🏆

Best Ode to Alan Turing: Dedicated levels representing historical ciphers (Caesar, Vigenère) culminating in a simulated two-rotor Enigma machine deciphering "TURING TEST".
Best Google AI Usage: The project uses the Gemini API as a functional compiler, showing how large language models can translate unstructured human phrasing directly into executable mechanical pipelines.

Link to Source Code 📂

Repository: https://github.com/mamoor123/enigmas-echo

📖 Check out my other articles:

🎮 Turing's Frequency — A Rhythm Game Where You Decrypt the Voices of History

Mamoor Ahmad — Tue, 09 Jun 2026 09:50:49 +0000

🏆 This is a submission for the June Solstice Game Jam

🎯 What I Built

Turing's Frequency is a browser-based rhythm game where you decrypt encrypted radio signals by listening to musical patterns and recreating them. Each signal carries a message from a historical figure who changed the world — voices that were silenced, ignored, or forgotten, now restored through your rhythm.

🎮 👉 PLAY THE GAME LIVE 👈

📖 The Story

The game is set in 1954, on the desk of Alan Turing at the University of Manchester. A radio crackles with fragmented transmissions — encrypted messages carrying words of Pride, resistance, and identity.

You are a student who has found Turing's last notebook, and with it, the key to decrypting these signals.

🌅 The connection to the June solstice: As you decrypt each signal, the screen literally brightens — from near-darkness to a flood of golden light. The solstice is the moment light and dark trade places, and this game makes that transition tangible.

🎬 Video Demo

👆 Watch the full gameplay loop: title → story → rhythm gameplay → decrypted messages → victory screen with solstice light effect.

🕹️ How to Play

Key	Action
`1` `2` `3` `4`	Play notes
`↑` `↓` `←` `→`	Arrow keys (alternative)
`Space` / `Enter`	Advance screens

🎧 Listen to the signal pattern
🎹 Repeat the notes in order
🔓 Decrypt the message
🌅 Restore the voice

💻 The Code

The entire game is a single HTML file (~32KB) with zero external dependencies. No frameworks, no libraries, no asset files (similar to how I built my npm package with zero dependencies) — just HTML, CSS, and vanilla JavaScript.

mamoor123 / turings-frequency

Turing's Frequency - A Rhythm of Light. June Solstice Game Jam 2026 entry.

⚡ Key Technical Decisions

🔊 Web Audio API for all sound:
Every tone is synthesized in real-time using oscillators. The game uses a pentatonic scale (C4, E4, G4, C5) so every combination of notes sounds pleasant. No audio files needed.

function playTone(freq, duration = 0.3, type = 'sine', volume = 0.3) {
  const osc = audioCtx.createOscillator();
  const gain = audioCtx.createGain();
  osc.type = type;
  osc.frequency.setValueAtTime(freq, audioCtx.currentTime);
  gain.gain.setValueAtTime(volume, audioCtx.currentTime);
  gain.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime + duration);
  osc.connect(gain);
  gain.connect(audioCtx.destination);
  osc.start();
  osc.stop(audioCtx.currentTime + duration);
}

📺 CRT aesthetic with pure CSS:
Scanlines, flicker, and glow effects are all CSS — no canvas rendering needed.

🌅 Progressive brightness:
A radial gradient overlay transitions from 0% to 12% opacity gold as you progress through levels, creating the solstice "longest day" effect.

🤖 Auto-demo mode:
Adding ?demo to the URL triggers an automated playthrough — perfect for recording videos or showing judges the full experience.

🎵 The Five Signals

Level	Historical Figure	Pattern	Theme	Quote
1️⃣	Alan Turing	C-E-G-E-C	🔢 Mathematical precision	"Sometimes it is the people no one imagines anything of..."
2️⃣	Marsha P. Johnson	C-G-E-C-G-C	✊ Joyful resistance	"You never completely have your rights..."
3️⃣	Bayard Rustin	E-C-C-G-E-G-C	🤫 Quiet power	"We need, in every community, a group of angelic troublemakers."
4️⃣	Audre Lorde	C-G-E-C-C-E-G-C	📝 Poetry as revolution	"It is not our differences that divide us..."
5️⃣	The Solstice	C-E-G-C-C-G-E-C-E-C	🌅 All voices together	"We are all infinite when we choose to be seen."

🧠 Why Rhythm?

Most June Solstice Game Jam submissions are visual — platformers, puzzles, cipher games. I wanted to make something auditory.

A rhythm game where the mechanic itself is "listening and repeating" felt like the right metaphor for amplifying voices that deserve to be heard.

💡 "The best games are the ones where the mechanic IS the message."

🏆 Prize Categories

🎖️ Best Ode to Alan Turing

This game is directly inspired by Alan Turing's life and legacy:

🏛️ The setting: 1954, Turing's final year at Manchester
🔐 The mechanic: Decrypting signals mirrors Turing's work at Bletchley Park
🏳️‍🌈 The metaphor: Turing was persecuted for being gay — this game restores voices of Pride
1️⃣ Level 1 is dedicated to Turing himself

🤖 Best Google AI Usage

I used Google Gemini to assist with (see my full Google I/O 2026 tools review for more AI tools):

📚 Research and quote verification
🎵 Pentatonic scale design for pleasant sounds
🐛 Debugging the auto-demo mode
✍️ Crafting the narrative framing

🛠️ Tech Stack

Technology	Usage
HTML5	Structure
CSS3	CRT effects, animations, glow
Vanilla JavaScript	Game logic
Web Audio API	Sound synthesis
GitHub Pages	Hosting

No frameworks. No libraries. No build tools. Just web. (If you're interested in AI agents, check out my Hermes Agent vs LangGraph vs AutoGen comparison)

🔗 Links

💬 What Do You Think?

I'd love to hear your feedback! (For more on AI and development, read my take on Vibe Coding is Fun Until You Hit Production)

🎵 Did the rhythm mechanic feel satisfying?
🌅 Did you notice the brightness increasing?
💡 Any ideas for new levels or historical figures?

Drop a comment below! 👇

🏳️‍🌈 Built with Web Audio API, vanilla JavaScript, and a lot of respect for the voices in this game.

Happy Pride Month. Happy Solstice. Happy Birthday, Alan. 🌅

📚 Related Resources

Web Audio API Documentation — Learn how to synthesize sound in the browser
How to Build Games with JavaScript — Community for HTML5 game developers
GitHub Pages Deployment Guide — Host your own games for free
Alan Turing's Legacy — Learn about the father of computer science
Stonewall Riots History — The history of Pride
CSS Tricks: Animations — Create CRT effects like mine

What did you think of this post? Let me know in the comments! 👇

📚 My Other Posts You Might Enjoy

If you liked this post, check out my other work on dev.to:

🚀 I Revived My Abandoned Python Script Into a Published npm Package — How GitHub Copilot helped me ship
⚔️ Hermes Agent vs LangGraph vs AutoGen — What Actually Happened — AI agents comparison
🔒 I Replaced ChatGPT with Gemma 4 Running Locally — Local AI for privacy
🔥 Every Google I/O 2026 Developer Tool — What Actually Works — Hands-on tool review
💣 10 Microservices Concepts Every Developer Should Know — Architecture essentials
🎓 Junior Devs in 2026: What Bootcamps Won't Tell You — Career advice
🎵 Vibe Coding is Fun Until You Hit Production — AI coding reality check
🤖 AI Agents Replaced My Dev Workflow — Here's What Broke — Productivity lessons

👆 Follow me @mamoor_ahmad for more posts on AI, game development, and web tech!

I Revived My Abandoned 200-Line Python Script Into a Published npm Package — Here's How GitHub Copilot Made It Happen 🚀

Mamoor Ahmad — Mon, 01 Jun 2026 16:06:45 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

🎯 The TL;DR

Last October, I built a scrappy 200-line Python script during a hackathon that analyzed Git commit history. It worked — barely. Then I abandoned it.

Eight months later, I picked it back up, rewrote it from scratch in Node.js, and turned it into RepoLens — a published CLI tool with 6 analysis engines, 36 automated tests, and CI/CD.

🤖 GitHub Copilot was my pair programmer through every line.

Here's the full comeback story. 👇

📦 What I Built

RepoLens is a codebase intelligence tool that extracts hidden insights from your Git history. Think of it as an MRI scan for your codebase.

🧠 What It Does

Command	What It Analyzes
`repolens analyze .`	🔍 Full codebase analysis (all engines)
`repolens ownership .`	👥 Who owns what files, bus factor risk
`repolens complexity .`	📈 Complexity trends over time
`repolens bugs .`	🐛 Bug hotspot detection from commit messages
`repolens deadcode .`	💀 Potentially unused files (12+ months idle)

⚡ Quick Start

# Install from GitHub
npm install -g github:mamoor123/repolens

# Analyze any Git repository
repolens analyze /path/to/your/repo

# Or skip AI briefing for fast results
repolens analyze . --no-ai

# Export as JSON for pipelines
repolens analyze . --json --output report.json

🎬 Live Demo

Here's RepoLens analyzing its own codebase:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🔍 RepoLens Report: repolens
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 Overview
┌──────────────┬──────────────┐
│ Repository   │ repolens     │
│ Total Commits│ 5            │
│ Total Files  │ 21           │
│ Contributors │ 3            │
│ Timespan     │ Less than 1 week │
└──────────────┴──────────────┘

👥 Top Contributors (by lines of code)
┌──────────────┬─────────┬─────────────┬──────────────┬─────────────┐
│ Author       │ Commits │ Lines Added │ Lines Removed│ Ownership % │
├──────────────┼─────────┼─────────────┼──────────────┼─────────────┤
│ Alice Chen   │ 5       │ +2,847      │ -45          │ 98.4%       │
│ Copilot Bot  │ 2       │ +312        │ -0           │ 10.8%       │
│ Test Runner  │ 1       │ +85         │ -0           │ 2.9%        │
└──────────────┴─────────┴─────────────┴──────────────┴─────────────┘

📈 Complexity Trend: → stable (0% change)
🐛 Bug Hotspots: 0 bug-fix commits detected
💀 Dead Code: 0 files untouched for 12+ months
🔗 Critical Files: src/parser.js (risk score: 45.2)

👉 Try it on your own repo

🎬 Demo

📸 Screenshots

Full Analysis Report:

The analyze command runs all 6 engines and produces a beautiful terminal report with color-coded tables, trend indicators, and actionable insights.

Individual Analysis Commands:

Each engine can be run independently for focused deep-dives:

# Check who owns each file (bus factor analysis)
repolens ownership ./my-project

# Track complexity trends
repolens complexity ./my-project

# Find bug hotspots
repolens bugs ./my-project

# Detect dead code
repolens deadcode ./my-project

JSON Output for CI/CD Pipelines:

repolens analyze . --json --output report.json

Perfect for integrating into your GitHub Actions workflow or pre-commit hooks.

🔗 GitHub Repository | 📦 npm Package

📖 The Comeback Story

Chapter 1: The Hackathon (October 2025) 🏚️

It was 2 AM at a local hackathon. I needed a way to understand a messy codebase I'd inherited. So I threw together a Python script:

# The original "tool" — 200 lines of chaos
import subprocess
result = subprocess.run(['git', 'log', '--oneline'], capture_output=True, text=True)
# ... 198 more lines of regex and tears

It kinda worked. It printed some commit stats. I presented it, got a few nods, and never touched it again.

For 8 months, it sat in a forgotten folder on my laptop, collecting digital dust.

Chapter 2: The Resurrection (May 2026) 🔥

When I saw the GitHub Finish-Up-A-Thon Challenge, I knew exactly what to revive.

But here's the thing — the original script was unfixable. The architecture was wrong. The parsing was fragile. There were zero tests.

So I made a bold decision: rewrite everything from scratch in Node.js.

Why Node.js?

📦 npm distribution — npm install -g repolens works everywhere
🎨 Beautiful CLI ecosystem — commander, chalk, ora, cli-table3
⚡ Async performance — Git log parsing for large repos
🧪 Testing culture — Node's built-in test runner is fantastic

Chapter 3: Building With Copilot 🤖

This is where GitHub Copilot changed the game.

🧩 The Parser Problem

The hardest part was parsing Git's output format. Copilot suggested using a custom boundary marker approach:

// Copilot suggested this pattern — it's brilliant
const COMMIT_MARKER = '§COMMIT_BOUNDARY§';

const format = [
  COMMIT_MARKER,
  '%H',   // Full hash
  '%h',   // Short hash
  '%an',  // Author name
  '%ae',  // Author email
  '%ai',  // Author date (ISO)
  '%s',   // Subject
  '%b'    // Body
].join('%x00');

// Parse using the boundary marker
const rawParts = output.split(COMMIT_MARKER);
for (const rawPart of rawParts) {
  const parts = rawPart.split('\x00');
  const hash = parts[0]?.trim();
  if (!hash) continue;
  // ... extract fields
}

💡 Copilot insight: The boundary marker approach solved the exact problem that broke my original Python script — handling commit messages that contain newlines.

🔬 The Bug Archaeology Engine

For detecting bug-fix commits, Copilot helped me build a 13-pattern regex system that catches everything from fix: login bug to SECURITY: XSS vulnerability patched:

const BUG_PATTERNS = [
  /\bfix(?:ed|es|ing)?\b/i,
  /\bbug\s*fix\b/i,
  /\bhotfix\b/i,
  /\bpatch(?:ed|ing)?\b/i,
  /\bsecurity\b/i,
  /\bCVE-\d+/i,
  /\bvulnerability\b/i,
  // ... 6 more patterns
];

Copilot didn't just suggest the patterns — it explained why each one catches different commit styles. Some developers write fix:, others write bug fix, others write patched. The 13 patterns cover them all.

🧪 Test Generation

Here's where Copilot really shined. For each analyzer, I'd write one test as a template, and Copilot would suggest the remaining test cases — including edge cases I hadn't thought of:

// I wrote this one
test('should detect bug-fix commits', () => {
  const commits = [{ subject: 'fix: login page crash', files: [] }];
  // ...
});

// Copilot suggested these edge cases
test('should handle empty commit list', () => { ... });
test('should detect CVE references', () => { ... });
test('should not false-positive on "prefix" in subject', () => { ... });
test('should handle binary files (dash stats)', () => { ... });

Result: 36 tests, all passing. Most of the edge cases were Copilot's ideas.

Chapter 4: The Numbers 📊

Metric	Before (Oct 2025)	After (June 2026)
Language	Python	Node.js
Lines of Code	~200	~1,500
Tests	0	36 ✅
CI/CD	None	GitHub Actions (Node 18/20/22)
Analysis Engines	1 (basic stats)	6 (ownership, complexity, bugs, dead code, dependencies, AI)
Distribution	Copy-paste script	npm package
Error Handling	None	Graceful with spinners
Documentation	None	Full README with examples

🤖 My Experience with GitHub Copilot

I've been using GitHub Copilot for over a year now, but this project made me appreciate it on a different level. Here's what changed:

🏆 Where Copilot Excelled

1. Algorithm Design 🧠

The co-change analysis for dependency mapping was the most complex algorithm. Copilot didn't just autocomplete — it reasoned about the approach:

"If file A and file B frequently change in the same commit, they're coupled. Use a co-change matrix with a threshold of 3+ co-changes to identify tight coupling."

That's exactly what I built. The coupling cluster detection uses an expanding flood-fill algorithm that Copilot helped me design.

2. Regex Pattern Generation 🎯

Writing 13 bug-detection regex patterns by hand would have taken hours. Copilot generated them in minutes, and each one was correct on the first try.

3. Test Case Ideation 🧪

Copilot suggested edge cases I would have missed:

Commits with no files
Binary files showing - in line counts
Empty git log output
NUL byte handling in commit metadata

💡 What I Learned

Copilot is best as a thinking partner, not a code generator. I'd describe what I wanted in comments, and Copilot would suggest implementations — but I always reviewed and adapted them.
The chat feature is underrated. For complex problems, I'd use Copilot Chat to reason through architecture decisions before writing code.
It's especially good at Node.js patterns. The npm ecosystem has strong conventions, and Copilot knows them well.

🏗️ Architecture Deep Dive

For those interested in how RepoLens works under the hood:

repolens/
├── bin/repolens.js          # CLI entry point (commander)
├── src/
│   ├── parser.js            # Git log parser with boundary markers
│   ├── analyzers/
│   │   ├── ownership.js     # File ownership + bus factor
│   │   ├── complexity.js    # Complexity timeline + churn
│   │   ├── bugs.js          # Bug archaeology (13 regex patterns)
│   │   ├── deadcode.js      # Dead code detection
│   │   └── dependencies.js  # Co-change coupling analysis
│   ├── ai/
│   │   └── briefing.js      # AI codebase briefing (template + LLM)
│   └── utils/
│       └── format.js        # Output formatting
├── test/                    # 36 tests across 7 suites
└── .github/workflows/ci.yml # CI on Node 18/20/22

🔑 Key Design Decisions

Zero runtime dependencies for the core — The analysis engines use only Node.js built-ins
Boundary marker parsing — Solves the newline-in-commit-message problem
Co-change coupling — Inspired by research on software evolution
Template + LLM AI briefing — Works without an API key, but upgrades when one is available

🔮 What's Next

RepoLens is just getting started. Here's what I'm planning:

[ ] 📦 Publish to npm for global installation
[ ] 🌐 Web dashboard with D3.js visualizations
[ ] 🔄 GitHub Action for automated PR analysis
[ ] 📊 SonarQube-compatible output format
[ ] 🐍 Python SDK for programmatic access
[ ] 🤖 Enhanced AI briefing with GitHub Models

🙏 Acknowledgments

GitHub Copilot — For being the best pair programmer I've ever had
DEV Community — For hosting this amazing challenge
GitHub — For the platform that makes all of this possible
The open-source ecosystem: commander, chalk, ora, cli-table3

🔗 Links

🌐 Live Web Demo
📂 Source Code
🐛 Report Issues
⭐ Star on GitHub

Built with ❤️ and a lot of ☕ for the GitHub Finish-Up-A-Thon Challenge

What abandoned project are YOU going to revive? Drop a comment below! 👇

⚔️ 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!