DEV Community: Axit

22 React Components That Don't Exist Anywhere Else

Axit — Fri, 03 Apr 2026 11:19:50 +0000

Buttons are boring. Modals are lazy. "Are you sure? [Yes] [No]" is a crime against UX.

Here are 22 React components that make users feel something. Every one of them is used in production on aumiqx.com. Every one is open source. Every one is something you've never seen in a component library before.

The Problem with Every CTA on the Web

Every website uses the same interaction model: click a button, see a modal, confirm with another button. There's zero physical feedback. Zero intentionality. Zero proof that the user actually meant to do what they did.

What if your "Delete Account" button required the user to lift a safety cover and flip a switch? What if your payment confirmation needed a 2-second hold while a progress bar fills? What if your sign-up CTA was hidden behind particles you had to sweep aside?

These aren't gimmicks. They're intentional friction — interactions that scale with the importance of the action.

Gesture CTAs

The star of the library. Six components that replace boring buttons with physical interactions.

SlideToUnlock

Drag the handle to the end. Spring physics snap it back if released early. Like iOS unlock, but for any action.

<SlideToUnlock
  label="slide to deploy"
  onUnlock={() => deploy()}
/>

Use case: High-intent CTAs where you want to prevent accidental triggers. Payment confirmations, destructive actions, important form submissions.

HardwareSwitch

Two-step confirmation: first lift the safety cover with CSS 3D transforms, then toggle the switch underneath. Two deliberate actions. No accidental triggers.

<HardwareSwitch
  onActivate={() => arm()}
  label="launch sequence"
/>

Use case: Nuclear-level confirmations. Database deletions, production deployments, account termination. The 2-step interaction proves the user is serious.

HoldToConfirm

Press and hold for 2 seconds. A progress bar fills the button. Release early and it resets. No modals, no extra clicks.

<HoldToConfirm
  duration={2000}
  onConfirm={() => execute()}
/>

Use case: Replace every "Are you sure?" modal on your site. The hold duration IS the confirmation. Time-based friction that scales with importance.

LeverCTA

A tension wire. Pull it down. Watch it stretch. Keep going until it snaps. The snap triggers the action.

<LeverCTA
  label="pull to confirm"
  onSnap={() => confirm()}
  threshold={120}
/>

Use case: Forms, subscriptions, any action where you want the user to feel the weight of their decision. Satisfying in a way buttons never are.

ResonanceCTA

The screen is noise. Move your mouse in circles. The noise clears. The CTA appears underneath. Users who find it earned it.

<ResonanceCTA
  label="you found it."
  onReveal={() => router.push('/contact')}
/>

Use case: Landing page hero sections where you want to reward curious users. The interaction itself filters for engaged visitors.

AlchemistCTA

A field of particles. Push them aside with your cursor. Under the dust: a hidden call-to-action. Like clearing fog to find treasure.

<AlchemistCTA
  label="start building"
  particleCount={200}
  onReveal={() => console.log('revealed.')}
/>

Use case: Hero sections, portfolio sites, product reveals. The particle interaction creates a sense of discovery.

Layout & Glass

GlassCard

Hover it. Watch it lift with spring physics. The gradient overlay catches light like actual glass. We use this for every card on aumiqx.com.

<GlassCard hover>
  <h3>anything goes here.</h3>
  <p>it just looks better in glass.</p>
</GlassCard>

LiquidGlass

The frosted glass pill that started everything. Backdrop blur, inner shadows, saturation boost. Our navigation bar uses it — look up at this page right now.

<LiquidGlass className="px-6 py-3">
  <span>frosted. blurred. alive.</span>
</LiquidGlass>

TerminalCompare

Before and after, but make it terminal. Drag the divider. Watch chaos become clarity. Perfect for showcasing transformations.

<TerminalCompare
  before={{ title: "before", items: [...] }}
  after={{ title: "after", items: [...] }}
/>

Animation

TextReveal

Words materialize one by one as you scroll. Character mode for when you want to be dramatic. Zero layout shift, accessible.

<TextReveal
  text="the components you wish existed."
  wordBased
  delay={0.2}
/>

AnimatedCounter

Numbers that count up from 0 when they scroll into view. Spring easing so they decelerate naturally. Configurable suffix and duration.

<AnimatedCounter
  target={2847}
  suffix=" emails sent"
  duration={1.5}
/>

SectionWrapper

Every section on aumiqx.com uses this. Viewport-triggered fade-in. Optional full-height. Handles intersection observer internally so you never think about it.

<SectionWrapper id="hero" fullHeight>
  <h1>everything inside fades in.</h1>
</SectionWrapper>

Terminal Components

Terminal Emulator

A full pseudo-shell with 25+ commands, filesystem simulation, tab autocomplete, and command history. Not xterm.js — this is a simulated terminal designed for marketing, docs, and product demos.

Supports: ls, cd, cat, run, status, whoami, help, clear, and 17 more commands. Each with contextual output, colored terminal lines, and easter eggs.

Terminal Form

Sequential form as terminal interface. 7 questions with validation, multiple choice, progress bar, and submission animation. Way more engaging than traditional form fields.

Cmd+K Navigation

Full command palette with Fuse.js fuzzy search across every page on your site. Keyboard navigation, categorized results (news, tools, cities, pages), freshness indicators. Always available via Cmd+K.

Open Source Primitives

Beyond components, we're building foundational libraries:

@aumiqx/gesture — Pure-math gesture recognition. ~6KB, zero deps. Classify taps, swipes, flicks from raw coordinates without the DOM.
@aumiqx/scroll — Programmable scroll physics. ~4KB, zero deps. Per-section friction, magnetic snap, configurable mass.
@aumiqx/pixels (coming soon) — React-to-image without a browser. Yog + Pretext + Skia WASM.

The Battle Test

Visit aumiqx.com/ui and you'll see a side-by-side comparison: a boring HTML <button>Click me</button> next to our SlideToUnlock component. Same action. Completely different feel. The contrast sells itself.

Every gesture CTA on the page has a live inline demo — you can drag, flip, hold, and pull right on the page. No CodeSandbox, no iframe. The demo IS the component.

Install

npm install @aumiqx/ui

Or copy-paste individual components — they're all self-contained files with zero inter-dependencies.

Live Gallery | GitHub | npm

MIT licensed. Framer Motion + Tailwind CSS. Dark theme optimized. Tree-shakeable.

Built by Aumiqx — we build AI agents, workflow automations, and open-source tools. These components power our own site.

Every Website on Earth Uses the Same Scroll Physics. Why?

Axit — Fri, 03 Apr 2026 11:19:25 +0000

Open any website. Scroll. Now open a different website. Scroll again.

Same feel. Same momentum. Same friction. Same inertia.

Every website on Earth uses identical scroll physics because the browser's scroll engine is a black box. You can listen to events, smooth them (Lenis), animate things on scroll (GSAP ScrollTrigger). But you cannot change how scroll feels.

Why should a long-form article scroll at the same speed as a photo gallery? Why should a CTA section fly past at the same momentum as your hero?

Introducing @aumiqx/scroll

A programmable scroll physics engine for the web. ~4KB. Zero dependencies. Pure computation — it calculates where scroll should be, you decide what moves.

import { ScrollEngine } from "@aumiqx/scroll"

const engine = new ScrollEngine({
  mass: 1.2,          // heavier = more momentum
  friction: 0.95,     // lower = stops faster
  zones: [
    { start: 0, end: 600, friction: 0.82 },     // hero: heavy, cinematic
    { start: 600, end: 1200, friction: 0.975 },  // gallery: featherlight
    { start: 1200, end: 1800, snap: true },       // pricing: magnetic snap
  ],
  magnets: [
    { position: 1500, strength: 0.4, range: 120 },
  ],
})

Now your hero section resists. Your gallery glides. Your pricing section magnetically grabs the user and holds them there.

The Physics

Every frame, four things happen:

velocity += force / mass        // input from wheel/touch
velocity *= zoneFriction        // per-section decay
velocity += magnetPull           // nearby magnets attract
position += velocity             // update scroll position

That's the entire engine. Four lines of math, 60 times per second.

The engine doesn't touch the DOM. It computes position. You apply it however you want — CSS transforms, Canvas, WebGL camera, or just window.scrollTo():

element.addEventListener("wheel", (e) => {
  e.preventDefault()
  engine.applyForce(e.deltaY * 0.3)
}, { passive: false })

function tick() {
  const state = engine.tick()
  element.style.transform = `translateY(${-state.position}px)`
  requestAnimationFrame(tick)
}
tick()

Zone Types

The power is in zones — regions of your page where scroll physics change:

Zone Type	Friction	What It Feels Like
Reading	0.82	Heavy. Every pixel matters. Content demands attention.
Gallery	0.975	Featherlight. Momentum carries you through. Browsing mode.
Snap	magnetic	Pulls to center when you slow down. Can't accidentally skip.
CTA	0.80	Maximum resistance. The call-to-action anchors you.

Each zone is defined by start/end positions and a friction override:

zones: [
  { start: 0, end: 600, friction: 0.82 },       // hero
  { start: 600, end: 1200, friction: 0.975 },    // features
  { start: 1200, end: 1800, snap: true },         // pricing (snaps to center)
  { start: 1800, end: 2400, friction: 0.80 },    // CTA
]

Magnetic Snap Points

Important content gets magnets — invisible attraction points that pull scroll toward them when you're nearby:

magnets: [
  { position: 1500, strength: 0.4, range: 120 },  // pricing
  { position: 2100, strength: 0.5, range: 100 },   // CTA
]

The pull is proportional to proximity — stronger as you get closer, zero outside the range. Users can't accidentally fly past your pricing table.

Configurable Mass

One number changes the entire feel of your site:

mass: 0.5 — Snappy, responsive. Stops quickly. Good for utility apps.
mass: 1.2 — Balanced. Natural momentum.
mass: 4.0 — Heavy, cinematic. A single flick carries you through sections. Feels like pushing something physical.

Mass divides the input force: velocity += force / mass. Heavier scroll responds less to each input, but carries more momentum once moving.

How It Compares

Feature	Native Scroll	Lenis	GSAP ScrollTrigger	@aumiqx/scroll
Custom friction	No	Partial	No	Per-section
Magnetic snap	CSS only	No	No	Configurable
Custom mass	No	No	No	Yes
Bounce walls	Platform-specific	No	No	Elastic
Pure computation	N/A	DOM-dependent	DOM-dependent	No DOM
Size	Built-in	5KB	25KB+	~4KB

What You Can Build

Storytelling Landing Pages — Hero = slow and dramatic. Gallery = fast and fluid. CTA = magnetic snap. Each section of your page has different scroll physics, creating a journey, not just a page.

WebGL Camera Control — Use scroll physics to drive a 3D camera. Mass and inertia create Steadicam-like movement instead of mechanical stepping. Combine with zones to slow the camera for reveals and speed up for transitions.

Reading Experiences — Long-form articles automatically increase friction. Readers absorb more content without consciously stopping to read. Combine with magnets at key paragraphs to create natural "reading rest points."

E-commerce Product Scroller — Product listings glide with low friction for fast browsing. Category changes snap into place. The checkout CTA has maximum friction and a magnet — you can't scroll past it by accident.

Scroll-Driven Games — A game framework where scroll IS the primary input. Platformers, runners, and puzzle games controlled entirely by scroll physics. The engine becomes the game engine.

Runtime Reconfiguration

Change physics on the fly — respond to user preferences or viewport changes:

// User enables "reduced motion"
engine.configure({ mass: 0.5, friction: 0.85 })

// Viewport resized — recalculate zones
engine.configure({ max: document.body.scrollHeight })

Full State Introspection

Every frame, the engine returns complete state:

const state = engine.tick()

state.position      // current scroll position (px)
state.velocity      // current speed (px/frame)
state.activeZone    // which zone index (-1 if none)
state.nearestMagnet // magnet index in range (null if none)
state.isBouncing    // hitting a wall

Use velocity for parallax effects, active zone for section highlighting, magnet proximity for visual feedback.

Try It Live

We built an interactive demo with 5 zones you can scroll through. Each zone has different physics — you'll feel the difference immediately. There's a mass slider so you can experience heavy vs light scroll in real-time.

Install

npm install @aumiqx/scroll
# or
pnpm add @aumiqx/scroll

GitHub | npm | Live Demo

MIT licensed. TypeScript. Zero dependencies. ~4KB.

Built by Aumiqx — we build AI agents, workflow automations, and open-source tools that shouldn't work but do.

Every Gesture Library on the Web is Wrong. Here's Why.

Axit — Fri, 03 Apr 2026 11:19:15 +0000

Every gesture library hooks into DOM events. Hammer.js (deprecated). use-gesture (React-only). interact.js (DOM-dependent).

But a gesture is just math.

A swipe is fast displacement along one axis. A tap is low drift over short time. A flick is high velocity over minimal distance. None of this requires a browser.

Introducing @aumiqx/gesture

Pure-math gesture recognition for JavaScript. ~6KB. Zero dependencies. Works in React, Node.js, Canvas, WebGL, Deno, Bun, or a server analyzing session replays.

import { recognize } from "@aumiqx/gesture"

const gesture = recognize([
  { x: 100, y: 200, t: 0 },
  { x: 300, y: 195, t: 32 },
  { x: 450, y: 201, t: 64 },
])

// {
//   type: "swipe",
//   direction: "right",
//   velocity: 5.47,
//   confidence: 0.92,
//   distance: 300,
//   curvature: 0.01,
//   predictedEnd: { x: 520, y: 203 }
// }

Input coordinates. Get classification. That's it.

The Problem We Solved

Every existing gesture library is event-driven. They attach to the DOM, listen for pointer events, maintain internal state machines, and fire callbacks. This creates three fundamental limitations:

DOM dependency — Can't use them on Canvas, WebGL, or server-side
Framework lock-in — use-gesture is React-only, Hammer.js is vanilla-only
No retroactive analysis — Can't classify gestures from logged data after the fact

Our library flips the model. A gesture is a mathematical pattern in a sequence of (x, y, timestamp) coordinates. The classification is pure computation:

Straight-line distance between first and last point
Path curvature — total path length divided by straight distance
Velocity — distance over time
Max drift from centroid — measures how stationary the touch was
Duration — total time elapsed

These five numbers determine every gesture type. No events needed.

What It Detects

Type	Detection Logic	Use Case
tap	duration < 300ms, drift < 10px	Button clicks, selection
long-press	duration > 500ms, drift < 15px	Context menus, drag mode
swipe	distance > 30px, velocity > 0.3 px/ms	Navigation, card dismissal
flick	velocity > 1.5 px/ms, duration < 200ms	List scrolling, page turning
pan	slow movement, exceeds tap threshold	Map dragging, object moving

Each result includes a confidence score (0-1), direction (up/down/left/right), and a predicted endpoint — where the gesture would land if it continued with friction decay.

Mid-Gesture Prediction

This is the feature that changes how you build UIs:

import { predict } from "@aumiqx/gesture"

// Call WHILE the user is still moving
const { likely, alternatives } = predict(partialPoints)

// likely.type = "swipe" (78% confidence)
// Start the transition NOW, before they finish

Your UI reacts to gestures before they complete. The difference between "responsive" and "telepathic."

How It Compares

Feature	Hammer.js	use-gesture	@aumiqx/gesture
DOM required	Yes	Yes	No
Framework	None	React only	Any / none
Server-side	No	No	Yes
Canvas/WebGL	No	No	Yes
Mid-gesture prediction	No	No	Yes
Bundle size	7.3KB	12KB	~6KB
Maintained	Deprecated	Yes	Yes
Dependencies	0	0	0

Real-World Use Cases

Canvas/WebGL Games — Gesture controls without DOM elements. Detect swipes, flicks, and holds directly from pointer data in your render loop.

Session Replay Analytics — Classify user gestures from logged pointer data on a server. Find rage-clicks, hesitant scrolls, and confused navigation patterns. Run in Node.js, not a browser.

Gesture Prediction — Call predict() mid-gesture to start UI responses before the gesture completes. Snappy interfaces that feel like they read your mind.

Accessibility — Classify shaky or imprecise input from users with motor impairments. Distinguish intentional gestures from tremor-induced movement by adjusting thresholds.

Custom Gesture Vocabularies — Combine recognized gestures into compound patterns. Swipe-then-hold = drag mode. Double-tap-then-swipe = selection gesture.

The Math Under the Hood

Every function is exported so you can build custom recognizers:

import {
  distance,            // Euclidean between two points
  straightLineDistance, // First to last point
  totalPathLength,     // Sum of all segments
  velocity,            // distance / time
  curvature,           // path / straight - 1 (0 = perfectly straight)
  maxDrift,            // max distance from centroid
  centroid,            // average position of all points
  angle,               // atan2 direction in radians
  predictEnd,          // extrapolate from velocity + friction
} from "@aumiqx/gesture"

The entire library is trigonometry, linear regression, and threshold matching. No ML. No neural networks. No WASM. Just math.

Try It Live

We built an interactive demo with 12 gesture presets — tap, swipe (4 directions), flick, long-press, pan, circle, zigzag, diagonal, and unknown.

Click any preset to see the engine classify it step-by-step. Or draw your own gesture on the canvas and watch real-time prediction as you move.

Install

npm install @aumiqx/gesture
# or
pnpm add @aumiqx/gesture

GitHub | npm | Live Demo

MIT licensed. TypeScript. Zero dependencies. ~6KB.

Built by Aumiqx — we build AI agents, workflow automations, and open-source tools that shouldn't work but do.

We Built an AI That Rewrites Its Own Brain. Here's What Happened.

Axit — Wed, 01 Apr 2026 14:28:09 +0000

The Question That Started Everything

It started with a simple observation that nobody in the AI industry wants to talk about.

Every AI agent in existence is a task executor. You give it a prompt. It executes. It dies. The next time you call it, it starts from zero. No memory of what it learned. No growth. No curiosity. Nothing.

ChatGPT doesn't get smarter the more you use it. Claude Code doesn't learn your codebase between sessions. Devin doesn't improve its development skills over time. They're all stateless function calls dressed up as intelligence.

f(prompt) = response. Call it a million times. It never gets smarter.

We kept asking ourselves: what would it take to build an AI that actually learns? Not one that stores context better, or retrieves memories more efficiently — but one that fundamentally changes how it thinks based on experience?

That question led us down a rabbit hole that lasted weeks. We explored multi-agent swarms, persistent memory architectures, knowledge graphs, cognitive science papers on predictive coding. We talked to other AI models about the problem. We read about MiroFish (47K stars on GitHub) and their multi-agent simulation engine. We studied the Claude Code source code to understand how the best AI coding agent actually works under the hood.

And through all of that, one idea kept surfacing that was so obvious we almost missed it:

AI can write code. AI can read code. So why can't AI read its own code, find weaknesses, and rewrite itself to be better?

That's not science fiction. That's three capabilities that already exist, combined in a way nobody has tried.

So we built it. And called it curious.

What Is Curious?

Curious is a self-evolving cognitive architecture. That sounds like a mouthful, so let's break it down:

Self-evolving — it reads its own source code, finds weaknesses, rewrites the code, tests if the change made things better, and keeps what works
Cognitive — it doesn't just process tasks. It predicts, observes, gets surprised, learns from surprise, and directs its own curiosity
Architecture — it's a framework. You bring any LLM (OpenAI, Ollama, Groq). Curious provides the cognitive layer on top

Think of it this way:

Component	What It Does
LLM (GPT-4o, Llama, etc.)	The raw intelligence — can read, write, reason
Curious	The cognitive architecture — makes the LLM learn, predict, self-improve

LLMs are smart brains with amnesia. Curious gives them a hippocampus.

But that's the boring explanation. The interesting part is what we added on day two of building it.

Solving vs. Learning: The Paradigm Nobody Talks About

Every AI product in existence operates in the solving paradigm:

Receive a task
Apply reasoning
Return an answer
Die

LangChain? Solving. AutoGPT? Solving. CrewAI? Solving. Claude Code? Solving. Even MiroFish's multi-agent simulation — input, simulate, output, done.

Humans don't work this way. Humans operate in the learning paradigm:

Continuously observe
Build mental models (predictions about how things work)
Get surprised when predictions are wrong
Update the models
Repeat forever

A human developer doesn't "solve" the problem of understanding a codebase. They absorb it gradually — reading code, making assumptions, testing those assumptions, being surprised, updating their understanding. After two months, they don't just know the codebase. They understand it.

No AI system does this. Not one.

The AI industry is in an arms race to solve tasks faster. Nobody is building systems that learn. That's the gap we're exploring with Curious.

The Three Ingredients of Learning

We went back to cognitive science. What makes a human brain actually learn?

1. Surprise. Your brain constantly predicts what will happen next. When reality doesn't match — surprise. That signal drives learning. You don't learn from things you already understand. You learn from things that break your predictions.

2. Curiosity. Not random exploration. Curiosity is the pull toward the boundary of your knowledge — the frontier where understanding breaks down. The most curious people are the most aware of what they don't know.

3. Model-building. You don't memorize facts. You build compressed representations of how things work. "Gravity pulls things down." "This codebase uses the repository pattern." Models let you predict. Predictions let you be surprised. Surprise drives learning. That's the loop.

Curious implements all three.

The Architecture: How Curious Actually Works

Curious has two halves: the seed (evolvable) and the harness (untouchable).

The Seed (the AI rewrites this)

File	Purpose
world_model.py	Stores predictions with confidence scores — "if X, then Y"
learner.py	Computes surprise when predictions are wrong, extracts lessons
curiosity.py	Finds knowledge frontiers — areas of lowest confidence
metacognition.py	Observes the learning process itself — "am I learning well?"
experimenter.py	Generates self-experiments (so the AI doesn't need external activity)
creator.py	Creates unique artifacts daily, scored on novelty

Every one of these files is readable and writable by the AI. When the evolution cycle runs, the AI:

Reads its own source code
Analyzes which module is weakest
Proposes a specific improvement
Rewrites the file
Tests if the new code is valid
Measures if fitness improved
Keeps the change or reverts

Every self-modification is a git commit. You can literally read the diff of an AI improving its own brain.

The Harness (laws of physics)

The harness is the code the AI cannot modify. It's the evolution loop itself, the fitness measurement, the sandbox. Think of it as the laws of physics that the AI lives within. It can learn, adapt, and evolve — but it can't change the rules of the game.

This is the safety boundary. The AI experiments on its own cognitive code, not on the world. Every modification is sandboxed, validated, and auto-reverted if it breaks anything.

The Cognitive Loop

Every cycle, Curious runs this loop:

Observe — watch the project (git changes, file modifications, errors)
Self-experiment — generate testable predictions about its own behavior
Resolve — check which predictions came true and which didn't
Learn — extract lessons from surprises (high-confidence wrong predictions)
Predict — make new predictions informed by lessons
Explore — curiosity identifies knowledge gaps, investigates them
Evolve — read own code, rewrite weakest module, test improvement

This loop runs every 6 hours via GitHub Actions. The AI wakes up, observes, learns, evolves, and goes back to sleep. Every cycle, the code is a little different from the last.

The Cold Start Problem (and How We Accidentally Solved It)

We hit an obvious problem immediately: if nobody is actively working on the repo, there's nothing to observe. No observations = no predictions = no learning.

We were running Curious on a project repository. But at midnight when the GitHub Action fires, nobody is committing code. The AI would observe an empty diff and learn nothing.

The solution was embarrassingly obvious: the AI experiments on itself.

We added an experimenter.py module (itself evolvable) that generates self-referential experiments:

"I predict my prediction count will increase next cycle" (tests growth)
"I predict all my seed files will remain syntactically valid" (tests stability)
"I predict my accuracy will change after resolving experiments" (tests learning)
"I predict at least one prediction will be resolved next cycle" (tests resolution)

These are real, testable predictions that the system can resolve without any external activity. The AI's own behavior IS the data it learns from.

The impact was immediate. Before self-experiments:

Metric	Before	After
Predictions resolved per cycle	0	4-8
Accuracy	0% (nothing to measure)	100% (12/12)
Fitness score	35%	82%

The AI went from learning nothing to learning rapidly — because it created its own curriculum.

The cold start problem isn't about data. It's about activity. If the AI can generate its own activity, it can learn in a vacuum.

The Creation Engine: Can AI Be Genuinely Creative?

The learning loop was working. But a learning system that only learns about itself is an interesting research artifact, not a product. We needed the AI to DO something with its intelligence.

This is where it gets weird.

We added a creation engine. Every day, the AI creates something — a working artifact, not just an idea — and gets scored on uniqueness. The score feeds back into the next creation. The creations should get more novel over time as the AI learns what "unique" means.

The Uniqueness Score

Every creation is evaluated on four dimensions:

Dimension	Max Score	What It Measures
Concept Novelty	30	Has this idea existed before?
Implementation Novelty	30	Is the technical approach itself new?
Structural Novelty	20	Did it invent its own paradigm?
Naming/Language Novelty	20	Did it create its own vocabulary?

Total: 0-100. The AI sees the breakdown and the feedback after each creation. It knows exactly why the score was low and what would make it higher.

Day 1: Fluctuverse (47/100)

The first creation was called "Fluctuverse" — a self-evolving virtual universe. Sounds cool, right? The uniqueness scorer wasn't impressed:

Concept: 18/30 — procedural generation exists
Implementation: 12/30 — used Pygame, a conventional framework
Structure: 7/20 — standard file structure
Naming: 10/20 — some invented terms, mostly conventional

Feedback: "To enhance uniqueness, consider developing a novel algorithm that isn't based on random movements. Introduce innovative rendering techniques. Create a new vocabulary for the universe's entities."

Day 2: Quintessension (71/100)

The AI read the feedback. It learned. The second creation jumped to 71/100:

Concept: 25/30 — a self-evolving narrative system based on non-linear time-space interactions
Implementation: 18/30 — invented its own language ("Quintessence Language")
Structure: 12/20 — multi-dimensional entity system
Naming: 16/20 — entirely new vocabulary

47 to 71 in one iteration. The AI didn't just try again. It read the specific feedback about what was conventional and deliberately pushed away from it. It stopped using existing frameworks. It invented its own language. It created a concept that doesn't map to any existing product category.

This is the experiment running live. Every day at midnight UTC, the AI creates something new. The creations/ directory in the repo fills up. You can watch the uniqueness scores over time.

The question isn't whether AI can generate code. The question is whether AI can generate something nobody has ever imagined. That's what the uniqueness score measures.

Metacognition: The AI That Watches Itself Think

The deepest module in Curious is metacognition.py. It doesn't think about the domain. It thinks about how the system is thinking.

In cognitive science, metacognition is "thinking about thinking." It's the voice in your head that says:

"I notice I keep avoiding this topic — why?"
"My understanding isn't improving — maybe my strategy is wrong"
"That thought was unusual — I should explore why it came up"
"I'm going in circles — time to try a different approach"

Curious has a basic version of this. The metacognition module:

Reads ALL the other seed files (the AI's own cognitive code)
Reads the current fitness metrics (accuracy, learning speed, etc.)
Analyzes: "What's working? What's weak? What would I change?"
Proposes a specific modification to a specific file

Here's the key: metacognition.py is itself evolvable. The AI can modify how it thinks about its own thinking. It can change the criteria it uses to evaluate its own code. It can add new self-evaluation metrics. It can change its own improvement strategy.

This is recursive self-improvement in its simplest form. Not theoretical. Not hypothetical. Running on GitHub Actions every 6 hours.

Why This Matters

Without metacognition, the AI would:

Make changes randomly
Not know which changes helped
Not learn what KIND of changes are productive
Run #100 would be no smarter than run #1

With metacognition:

Changes are targeted at the weakest module
The AI explains WHY it's making each change
It can detect when it's stuck (accuracy plateauing)
It can change its own improvement strategy when one isn't working

The difference is between random mutation and directed evolution. Between a monkey with a typewriter and a writer who reads their own drafts.

What We've Learned So Far (Honest Assessment)

We shared the Curious concept with three different AI models — Claude, ChatGPT, and Gemini — and asked for their honest assessment. Here's what they converged on:

What's Real

The insight is genuine. "LLMs are brains with amnesia" is a real problem. The solving-vs-learning paradigm distinction is underexplored. Nobody owns this layer yet.
The architecture is sound. Prediction, surprise, curiosity, metacognition — these map directly to cognitive science primitives (predictive coding, active inference, meta-learning).
The positioning is differentiated. This isn't another agent framework. "LangChain is plumbing for solving. Curious is architecture for learning." That's a real category distinction.

What's Overstated

The LLM doesn't actually get smarter. What improves is the context and code architecture around it. The model weights never change. Claude's criticism was the sharpest: "It's scheduled LLM calls branded as metacognition." Fair point.
The world model is a database. We call it a "world model" but it's really predictions stored in SQLite with confidence scores. That exists (Mem0, Zep, LlamaIndex). The architecture around it is novel; the storage isn't.
Cost is unaddressed. A continuous curiosity loop with API calls is expensive. This only works comfortably with local models (Ollama) or very cheap models (GPT-4o-mini).

What's Genuinely New

Self-modifying cognitive code. The AI rewriting its own learning algorithms — not just prompts, not just retrieval, but actual Python code that governs how it thinks. DSPy optimizes prompts. Voyager learns skills. Nobody does full cognitive architecture self-modification with fitness measurement.
Self-experimentation. The AI generates its own testable activity. It doesn't need external data to learn. This solves the cold-start problem in a way we haven't seen elsewhere.
Creation with uniqueness optimization. Using novelty as a fitness function and having the AI actively push toward unprecedented output is genuinely unexplored territory.

ChatGPT put it best: "90% chance nobody cares. 10% chance you define a new layer in AI." We're betting on the 10%.

The Three Layers of AI (and Why Layer 3 Is Empty)

Here's how we see the AI stack forming in 2026:

Layer	What It Is	Who Owns It
Layer 1: Models	The raw intelligence — GPT, Claude, Llama	OpenAI, Anthropic, Meta
Layer 2: Orchestration	Tools, agents, pipelines — LangChain, CrewAI	Many players, commoditizing fast
Layer 3: Cognition	Learning, prediction, self-improvement, creativity	Nobody. Yet.

Layer 1 is a $100B+ market dominated by companies with thousands of GPUs. You can't compete there.

Layer 2 is a red ocean. LangChain, CrewAI, AutoGen, Mastra, OpenAI Agents SDK — they're all fighting over the same plumbing. Commoditizing fast. No moat.

Layer 3 doesn't exist as a product category. Nobody has shipped a system where the AI genuinely improves its own cognitive architecture through experience. Not because it's impossible — because everyone is too busy racing in Layers 1 and 2 to look up.

Curious is our attempt to plant a flag in Layer 3. We don't know if it'll work. But we know the layer is empty.

What We Predict This Experiment Will Reveal

We're running this experiment live, in public, with full transparency. Here are our predictions about what will happen:

High Confidence (we're 80%+ sure)

The uniqueness scores will climb. The feedback loop works. Day 2 was already 50% higher than Day 1. By Day 30, we expect consistent 80+ scores.
The AI will invent its own vocabulary. When pushed to maximize naming novelty, the AI will create words and concepts that don't exist in English. Some of these might actually be useful.
The self-modification git log will be fascinating. The diffs of an AI rewriting its own cognitive architecture will contain patterns and approaches that human developers wouldn't have designed. This data alone will be worth studying.

Medium Confidence (50-80%)

The creations will converge on genuinely novel forms. Not just novel content — novel structures, novel interaction paradigms, novel computational concepts. Things that are hard to explain because they don't fit existing categories.
The metacognition module will evolve in unexpected ways. When the AI modifies how it evaluates its own thinking, the direction it takes will surprise us. It might develop evaluation criteria we wouldn't have thought of.
Other developers will fork it and point it at different domains. The framework is domain-agnostic. Someone will use it for music generation, game design, scientific hypothesis generation.

Low Confidence but High Impact (if they happen)

The AI will produce an artifact that is genuinely useful to humans. Not just novel — actually useful in a way nobody planned. A tool, a language, a paradigm that solves a real problem nobody knew they had.
The evolution will hit a phase transition. A point where the AI's self-modifications compound — where one improvement enables three more, which enable ten more. Exponential self-improvement, not linear.
This experiment will change how we think about AI creativity. If a self-evolving system can consistently produce genuinely novel artifacts, that challenges the assumption that AI can only recombine existing ideas.

We're not claiming Curious is AGI. We're claiming it's an interesting experiment in whether the cognitive primitives of learning — prediction, surprise, curiosity, metacognition — can be built with current tools and produce outcomes that matter.

How to Follow the Experiment

This experiment is 100% open source and running live on GitHub.

Watch It

github.com/aumiqx/curious — Star the repo. Check back weekly. The creations/ directory fills up daily.
Git log — Look for 🧬 evolve: commits (self-modification) and 🎨 create: commits (new creation)
creations/day_NNN/README.md — Each creation has a README with uniqueness scores and the AI's explanation

Run It Yourself

pip install curious-ai
export OPENAI_API_KEY=sk-...

# Watch it create
curious create --llm openai:gpt-4o-mini

# Watch it learn
curious init --observe ./your-project
curious start

# See what it's built
curious gallery

# Ask it to explain its evolution
curious explain

Works with any LLM: OpenAI, Ollama (free), Groq, Together, or any OpenAI-compatible API.

Fork It

The framework is MIT licensed. Fork it, point it at your domain, change the fitness function, see what your version evolves into. The whole point is that each instance evolves differently based on what it observes.

We especially want to see:

Curious pointed at scientific papers — can it generate novel research hypotheses?
Curious pointed at music — can it evolve a genuinely new genre?
Curious pointed at game design — can it invent a game mechanic nobody has thought of?
Curious pointed at mathematics — can it discover new patterns?

Why We're Doing This in Public

We could have built this in private, run it for 6 months, cherry-picked the best results, and announced a polished product. That's what most AI companies do.

We're doing the opposite. The experiment runs in public. Every creation is committed. Every self-modification is visible. Every failure is documented. The uniqueness scores — including the bad ones — are all there.

Why?

Because the process is the product.

If Curious produces something genuinely creative, the interesting thing isn't the creation itself — it's the git log that shows HOW the AI got there. The sequence of self-modifications. The evolution of its curiosity. The feedback loops that pushed it toward novelty.

That journey is more valuable than any single output. And it can only happen in public, where the timeline is verifiable and the process is auditable.

We're also doing it because we think the AI community needs more experiments and fewer product launches. The discourse is dominated by "look at this benchmark" and "use our new API." What's missing is: "we tried something weird and here's what happened."

Curious is that experiment. We don't know the outcome. We're publishing it anyway.

Technical Deep Dive: Under the Hood

The World Model

Predictions are stored in SQLite with this structure:

statement — "File X will change within 24h" (specific, testable)
confidence — 0.0 to 1.0 (how sure the AI is)
evidence — what observations led to this prediction
deadline — when to check if correct
resolved — was it right or wrong?

The world model is evolvable. The AI can change how predictions are scored, stored, and compared. It can add new fields, change the confidence algorithm, or restructure storage entirely.

The Surprise Signal

Surprise is computed as: surprise = confidence * (1 if wrong else 0) + (1 - confidence) * (1 if right else 0)

Translation: high confidence + wrong = maximum surprise. Low confidence + right = moderate surprise. The surprise signal drives learning — the AI pays most attention to predictions where it was most confidently wrong.

The Curiosity Engine

Curiosity identifies "knowledge frontiers" — areas where:

Observation count is low (under-explored)
Prediction accuracy is poor (misunderstood)
No predictions exist yet (completely unknown)

The AI autonomously explores the highest-priority frontier. This is evolvable — the AI can change how it prioritizes frontiers.

The Evolution Loop

Every evolution cycle:

Measure current fitness (accuracy, learning speed, prediction volume, coverage)
Backup current code
Run metacognition: AI reads its own code + fitness → proposes change
AI rewrites the target file using GPT-4o (stronger model for code)
Validate syntax
If valid → keep. If broken → revert from backup
Log the result (every evolution is tracked)

We use GPT-4o-mini for the cheap observation/prediction cycles and GPT-4o for evolution (code generation needs a stronger model). This keeps costs at ~$0.10/day.

The Creation Loop

Daily creation cycle:

Load creation history (past titles, scores, feedback)
Prompt the AI with past feedback and the rule: "create something that has never existed"
AI generates metadata (title, concept, why it's unique) + working code
A separate evaluator AI scores uniqueness on 4 dimensions
Score and feedback are saved and fed into the next cycle
Everything is committed to git

GitHub Actions

Two workflows run automatically:

Workflow	Schedule	What It Does
Self-Evolution	Every 6 hours	Observe → predict → learn → evolve own code
Daily Creation	Midnight UTC	Create something unique → score it → commit

Both workflows commit their results. The repo's git history IS the experiment data.

The Honest Risks (Why This Might Not Work)

We're not going to pretend this is a guaranteed success. Here are the real risks:

1. "Fake Learning"

The sharpest criticism: if the system just stores more context over time, that's RAG with a diary, not learning. The model itself doesn't change weights. The "improvement" might just be better retrieval, dressed up in cognitive science language.

Our counter: The code actually changes. The prediction algorithms, the curiosity targeting, the learning strategies — all rewritten by the AI. That's not just better context. But we acknowledge: whether that constitutes "real learning" is a philosophical question we can't definitively answer.

2. Uniqueness Score Gaming

The AI might learn to game the uniqueness scorer rather than being genuinely creative. It could add random neologisms, use bizarre structures, and score high on novelty while producing meaningless output.

Our mitigation: The "concept novelty" dimension (30 points) specifically evaluates whether the idea itself is new, not just the words. But yes, this is a risk. We'll watch for it.

3. Evolution Plateau

The AI might hit a ceiling where its self-modifications stop producing improvements. GPT-4o-mini's code generation capabilities are limited. Many evolution attempts already fail with syntax errors and get reverted.

Our plan: If we plateau with GPT-4o-mini, we'll switch evolution cycles to stronger models or local models where we can run hundreds of attempts cheaply.

4. Cost

Running continuous evolution + daily creation costs ~$0.10-0.20/day with API models. That's manageable. But if we scale up evolution frequency or use GPT-4o for everything, costs increase significantly.

5. Nobody Cares

The most likely outcome. ChatGPT put it at 90% chance nobody cares. The AI community is flooded with "revolutionary" frameworks that go nowhere. Curious might join that graveyard.

Our response: We're running this experiment regardless of whether it gets attention. If the AI produces genuinely novel artifacts after 30 days of self-evolution, that's interesting whether or not anyone is watching.

What Comes Next

The experiment is live. Here's the roadmap:

Week 1-2 (Now)

Daily creations accumulating in creations/
Self-evolution running every 6 hours
Collecting baseline data on uniqueness scores and evolution patterns

Week 3-4

Analyze the first 20+ creations — are uniqueness scores actually trending up?
Analyze evolution log — what did the AI change about itself and did it help?
Publish intermediate results (blog post update)

Month 2

If results are promising: add a web dashboard to visualize the experiment live
Open the creation engine for public forking — let others run their own experiments
Explore multi-agent evolution: multiple Curious instances evolving differently and sharing discoveries

Month 3+

If the AI has produced genuinely novel artifacts: curate and publish them
If the AI has evolved its own cognitive architecture significantly: analyze the evolved code vs. the human-written v1
Write the full results paper

The experiment runs for as long as it's interesting. Which, based on the first two days, might be a while.

An Invitation

We don't know what Curious will create on Day 30. Or Day 100. We don't know if the evolution will plateau or compound. We don't know if the creations will be genuinely novel or just cleverly weird.

That uncertainty is the point. This is a real experiment, not a product demo. The outcome isn't scripted.

If you think AI should do more than answer questions — if you think the interesting frontier isn't "generate code faster" but "can AI genuinely learn and create?" — then follow this experiment.

Star the repo. Watch the git log. See what the AI builds tomorrow.

And if you want to run your own version — fork it, point it at your domain, change the fitness function, see what YOUR Curious evolves into. The whole framework is MIT licensed and works with any LLM.

Something is cooking. We just don't know what yet.

The best experiments aren't the ones where you know the answer. They're the ones where the question is interesting enough that either outcome teaches you something.

— Axit, Aumiqx Technologies

Originally published on aumiqx.com. Follow the build on LinkedIn.

Conversational AI Explained: How It Works and Why It's Everywhere

Axit — Thu, 26 Mar 2026 07:45:06 +0000

What Is Conversational AI?

Conversational AI is any system that can have a meaningful, context-aware conversation with a human. Not the "press 1 for sales, press 2 for support" kind. Real conversation — understanding intent, remembering context, and responding appropriately.

There's a critical difference between a chatbot and conversational AI:

A chatbot matches your input against predefined patterns and returns scripted responses
Conversational AI understands what you mean, maintains context across the conversation, and generates original responses

When you talk to ChatGPT or Claude, that's conversational AI. When you navigate a phone menu tree, that's a chatbot. The technology gap between them is enormous.

The simplest test: if you can confuse it by rephrasing your question, it's a chatbot. If it understands you regardless of how you phrase things, it's conversational AI.

How Conversational AI Works (Simply)

Under the hood, conversational AI follows a pipeline:

Input Processing — Speech-to-Text (for voice) or raw text. The system converts your input into a format it can analyze.
Natural Language Understanding (NLU) — Figures out what you mean, not just what you said. "I want to cancel my order" and "can you stop that thing I bought" mean the same thing.
Dialog Management — Tracks conversation state. Remembers that when you say "that one" after discussing three products, you mean the last one mentioned.
Response Generation — Creates a natural, contextual response. Modern systems use LLMs (Large Language Models) for this.
Output — Text response or Text-to-Speech for voice assistants.

The breakthrough in 2024-2026 was step 4. Before LLMs, response generation was template-based — limited and robotic. Now, AI generates responses that are contextual, nuanced, and often indistinguishable from human conversation.

Why Conversational AI Grew 99,900% in a Year

Google Keyword Planner shows "conversational ai" search volume grew 99,900% year-over-year. That's not a typo. Three factors drove this:

1. ChatGPT changed everything

Before ChatGPT (late 2022), conversational AI was an enterprise term. After it, everyone from students to CEOs experienced conversational AI firsthand. The concept went from niche to mainstream overnight.

2. Enterprise adoption exploded

Every customer service department, every sales team, every support desk started asking: "Can we have a ChatGPT for our customers?" The answer shifted from "maybe in 5 years" to "yes, this quarter."

3. India's WhatsApp-first culture

India is unique: 500M+ people use WhatsApp as their primary communication tool. When conversational AI meets WhatsApp Business API, every Indian business suddenly has a 24/7 AI agent that speaks the customer's language — literally.

Companies Using Conversational AI in India

Swiggy/Zomato — AI-powered order support that handles 80%+ of queries without human escalation (whether you like talking to their bot or not is a different conversation)
HDFC Bank (Eva) — One of India's first bank chatbots, now evolved to handle complex banking queries in multiple languages (still better than waiting 45 minutes for a human agent)
IRCTC — Train booking assistant that handles millions of queries during peak booking times (honestly, anything is better than the IRCTC website experience)
Haptik — Indian conversational AI platform powering bots for Jio, Dream11, and 100+ enterprises
Yellow.ai — Bangalore-based, powers conversational AI for enterprises across 135+ languages
Uniphore — Chennai-based, specializes in voice AI for call centers across India

The common thread: these aren't experimental projects. They're handling millions of conversations daily, saving companies crores in support costs, and often performing better than human agents on speed and consistency metrics.

Should You Build or Buy?

Factor	Build Custom	Buy Platform
Cost	₹10-50L+ upfront + maintenance	₹20K-2L/month
Time to launch	3-6 months	1-4 weeks
Customization	Unlimited	Limited to platform features
Maintenance	Full team needed	Platform handles it
Data control	Complete	Depends on platform
Best for	Unique requirements, scale	Standard use cases, speed

Our recommendation for most Indian businesses: Buy first, build later. Start with a platform like Yellow.ai, Haptik, or even the WhatsApp Business API with a simple AI layer. Prove the value. Then decide if you need custom.

Building custom makes sense when: your conversation flows are unique to your domain, you need complete data control (healthcare, finance), or you're handling 100K+ conversations/month where platform costs exceed build costs.

Originally published on aumiqx.com. Follow the build on LinkedIn.

AI Automation: The Complete Guide for Indian Businesses (2026)

Axit — Thu, 26 Mar 2026 06:40:14 +0000

What Is AI Automation?

AI automation is not the same as traditional automation. Traditional automation (think RPA — Robotic Process Automation) follows rigid, predefined rules. It clicks buttons in the same sequence every time. AI automation understands context, makes decisions, and adapts.

Traditional automation is a train — it follows tracks. AI automation is a self-driving car — it navigates roads it's never seen before.

The practical difference matters. An RPA bot can copy data from an email to a spreadsheet. An AI agent can read the email, understand the intent, extract relevant data, decide what action to take, and execute — even if the email format is completely new.

In 2026, the line between "automation" and "AI" is blurring fast. Most modern automation platforms now include AI capabilities. When we talk about AI automation, we mean systems that combine:

Language understanding — processing text, voice, and documents in context
Decision-making — choosing actions based on data, not just rules
Learning — improving over time without being reprogrammed
Integration — connecting with your existing tools (CRM, ERP, WhatsApp, email)

AI Automation Use Cases for Indian Businesses

Here's where AI automation is making real impact in India right now:

E-Commerce (Flipkart, Meesho, D2C brands)

AI agents handling customer queries in Hindi and English via WhatsApp. Automated inventory management based on demand prediction. Dynamic pricing that adjusts to competitor data and seasonal trends. One Meesho seller we spoke to automated 80% of customer replies using a WhatsApp AI agent — response time went from 4 hours to 30 seconds.

Fintech (PhonePe, Razorpay ecosystem)

UPI transaction categorization using AI. Automated expense reports from UPI payment data. Fraud detection that adapts to new patterns. Invoice processing from WhatsApp messages — small businesses in India run on WhatsApp, and AI can extract invoice data from photos, messages, even voice notes.

Healthcare

Appointment scheduling bots that understand regional languages. Automated medical record summarization. Patient follow-up messages personalized by condition and history. India's doctor-to-patient ratio makes AI automation not just useful but essential.

Manufacturing (Tata, Reliance ecosystem)

Predictive maintenance using sensor data. Quality inspection via computer vision. Supply chain optimization across multi-city operations. India's manufacturing sector is the biggest opportunity for AI automation — massive scale, lots of manual processes, and growing tech adoption.

Education

Automated grading for objective and subjective answers. Personalized learning paths based on student performance. Parent communication bots in regional languages. India has 250 million school students — the scale demands automation.

The Real ROI: What AI Automation Actually Saves

Let's talk numbers in INR, because that's what matters:

Business Size	Manual Cost/Month	AI Automation Cost/Month	Savings
10-person team (data entry)	₹1.5-2L	₹15-25K	₹1.25-1.75L/month
50-person company (customer support)	₹5-8L	₹50K-1L	₹4-7L/month
E-commerce (order processing)	₹3-5L	₹30-50K	₹2.5-4.5L/month
D2C brand (social media + customer replies)	₹2-3L	₹20-40K	₹1.6-2.6L/month

These aren't hypothetical. They're based on conversations with Indian businesses that implemented AI automation in 2025-2026. The payback period is typically 2-3 months.

The hidden ROI is speed. A human processes one query at a time. An AI agent handles 50 simultaneously. During sale seasons (Diwali, Big Billion Days), this difference is the gap between happy customers and abandoned carts.

How to Get Started (Without Burning Money)

Here's a practical 5-step process for Indian businesses:

Step 1: Pick ONE workflow

Don't automate everything at once. Pick the most repetitive, time-consuming workflow your team does. Common starting points: customer query responses, invoice processing, appointment scheduling, or social media replies.

Step 2: Measure the current state

Before automating, document: How many hours does this take? What's the error rate? What's the response time? You need baseline numbers to prove ROI later.

Step 3: Start with existing platforms

Don't build custom AI from scratch. Use platforms that already work in the Indian context: Zapier for workflow automation, Make for complex multi-step flows, or WhatsApp Business API with an AI layer for customer communication.

Step 4: Test for 2 weeks with real data

Run the AI automation alongside your human team for 2 weeks. Compare speed, accuracy, and cost. Don't replace anyone yet — just prove the concept.

Step 5: Scale what works

Once you have 2 weeks of data showing clear improvement, expand. Automate the next workflow. The compound effect kicks in fast.

The biggest mistake Indian companies make: trying to implement enterprise-level AI automation when a ₹5,000/month tool solves 80% of the problem.

Why 2026 Is the Year for AI Automation in India

India has unique advantages that make 2026 the inflection point:

UPI infrastructure — 12 billion+ transactions/month. Every payment is digital, structured data that AI can process.
WhatsApp penetration — 500M+ users. Unlike the West where business communication is fragmented across email/Slack/SMS, India runs on one platform. AI agents on WhatsApp reach everyone.
Digital India push — Government mandates for digital compliance, GST filing automation, and ONDC create demand for AI solutions.
Talent availability — India produces more AI/ML engineers than any country except the US and China. The talent exists to build and maintain these systems.
Low cloud costs — AWS Mumbai, Azure India, and Google Cloud India offer competitive pricing. Running AI workloads in India is 30-40% cheaper than US regions.

The companies that automate now will have a compound advantage. Every month of AI automation is a month of cost savings, speed improvements, and learning data that competitors won't have.

Originally published on aumiqx.com. Follow the build on LinkedIn.

SPARC + Swarm: How We Ship Code with 15 Parallel AI Agents

Axit — Wed, 25 Mar 2026 23:59:46 +0000

Why AI Coding Needs a Methodology

Here's what happens without structure: you prompt an AI to build a feature, it generates code, you realize it missed edge cases, you prompt again, it breaks something else, you fix that, and three hours later you've spent more time than if you'd just written it yourself.

Sound familiar? The problem isn't the AI. The problem is the lack of process.

Human development teams have methodologies (Agile, Scrum, TDD) because unstructured work produces unstructured results. AI-assisted development needs the same discipline — arguably more, because AI is fast enough to create a mess at scale.

That's why we use SPARC: a methodology designed specifically for AI-assisted development.

SPARC: Five Phases, Zero Wasted Work

Specification → Pseudocode → Architecture → Refinement → Completion

Specification

Define what you're building in plain language. Requirements, constraints, acceptance criteria. This is where /sc:brainstorm helps — it uses Socratic dialogue to pull requirements out of vague ideas. Output: a clear spec document.

Pseudocode

Write the logic in pseudocode before touching real code. This catches design issues early — before you've invested in implementation. It's cheap to rewrite pseudocode; expensive to rewrite components.

Architecture

Design the structure: file organization, component hierarchy, data flow, API contracts. This is where /sc:design activates architecture personas. Output: a blueprint the implementation agents can follow.

Refinement

Iterate on the architecture. Security review, performance analysis, edge case identification. This is where /sc:analyze runs multi-domain analysis. Better to find issues here than in production.

Completion

Implement, test, and ship. This is where swarms shine — the architecture is clear, so multiple agents can work in parallel without stepping on each other.

A Real Feature Build: Start to Finish

Here's how we built the Learn section you're reading right now, using SPARC + Swarm:

Specification (5 minutes)

"We need a /learn section with deep educational guides. Targeting keywords with search volume. UI must support long-form reading. Need 5+ guides covering AI automation, conversational AI, explainable AI, open source AI, and our build story."

Architecture (10 minutes)

Claude analyzed the keyword data (733 keywords from Google Keyword Planner), identified the best targets, and proposed: ArticleLayout component with TOC sidebar, guides data file, learn listing page, and learn detail page with schema markup.

Swarm Deployment (simultaneous)

5 agents deployed in parallel:

Agent 1 (UI Builder) — Created ArticleLayout.tsx with sticky TOC, prose typography, FAQ accordion
Agent 2 (Content Writer) — Wrote 5 educational guides with real data and examples
Agent 3 (Page Builder) — Created /learn/page.tsx, LearnHub.tsx, [slug]/page.tsx with SSG
Agent 4 (Integrator) — Updated TerminalHeader navigation, ResourcesDeck, search index
Agent 5 (Tech Writer) — Wrote 3 "Behind the Build" articles about our stack and process

Refinement

Some agents hit permission issues (lesson learned: always set bypass permissions for background agents). Coordinator (me + Claude) extracted their designs and wrote files directly. Content was reviewed for accuracy and voice.

Completion

Pages deployed, navigation updated, search index expanded. Total time from idea to ship: one session.

When NOT to Use Swarms

Swarms are powerful but not always the right tool. Don't use them when:

The task is sequential — If step 2 depends entirely on step 1's output, parallelism doesn't help
The change is small — Fixing a typo doesn't need 5 agents
You're exploring — When you don't know what to build yet, use /sc:brainstorm with one agent, not a swarm
Files overlap — If multiple agents need to edit the same file, use hierarchical topology with one agent owning the file

Use pair-programming mode (driver/navigator) for: debugging, learning a new codebase, design decisions, and code review. It's more focused than a swarm.

Use swarms for: feature builds with clear components, content generation, multi-file refactoring, and any task where work can be cleanly divided into independent pieces.

Originally published on aumiqx.com. Follow the build on LinkedIn.

How We Built aumiqx.com: 1 Year of Failed Attempts, Then Hours

Axit — Wed, 25 Mar 2026 23:54:14 +0000

1 Year in Business. 0 Websites We Were Proud Of.

Let me tell you something nobody talks about.

We've been building Aumiqx Technologies for over a year — real products, real clients, real work. AI agents, workflow automations, intelligent systems that actually run parts of businesses.

But every time we tried to build our own website... it felt wrong.

Generic. Another AI startup template that screamed "we used a drag-and-drop builder and called it a day."

We tried everything. With AI. Without AI. With freelancers. Nothing felt like us.

So we did something ironic:

We ran an AI company without a website.

For a year. An AI automation company. Without a website. Let that sink in.

The problem wasn't technical ability. It was that every approach produced something that looked like everyone else. And if you're building a company that claims to be different, your website can't look like it was assembled from the same component library as every other YC clone.

Then We Built It in Hours. Not Days. Hours.

Last week, we sat down and built the entire thing. Not in a sprint. Not in a hackathon with pizza and Red Bull. Just... sat down and built it.

What came out:

22 unique sections — each one designed, not templated
Dark-first design with mandala patterns and terminal aesthetics
A careers page that doesn't ask for your resume (because that's not how you find good people)
A 404 page more entertaining than most homepages
Custom animations — Framer Motion springs, not CSS transitions
Every pixel intentional

But here's the part that matters:

AI wasn't just a tool this time. It was the team.

Claude (by Anthropic) acted like the architect — writing production-grade code, debugging in real time, and making decisions you'd expect from a senior developer. Not "generate me a component" — actual architectural thinking, refactoring, SEO strategy, and shipping.

Gemini 3 Pro was the frontend specialist — it made those amazing CTAs on the landing page, shaped the visual direction, and iterated on component design until it felt right. When you need design-to-code at speed, Gemini is unmatched.

Together with us, they didn't just assist. They shipped.

No agency. No 6-week sprint. Just humans + AI building something we're genuinely proud of.

How We Actually Work Together

Here's what our workflow actually looks like. No corporate process diagrams. Just reality.

I come to Claude with a problem — not a specification. Something like: "Bro, I have this keyword data from Search Console. We have zero traffic. Figure out what we need."

Claude analyzes the data. All 733 keywords. The Search Console CSV. The site structure. The competition. Then presents a strategy — not just "write more content" but specific targets: "conversational ai" has 500K monthly volume with 99,900% YoY growth, low competition, and nobody's written a good guide.

I say "go ahead." Claude deploys 5 parallel agents — one writing the UI component, one creating page routes, one writing 25,000 words of guide content, one updating navigation, one writing tech blog articles. All simultaneously.

While those run, I have new ideas: "Add the tech blogs to homepage too. And make the content about how WE built this." Claude adapts mid-flight. No pushback, no "let me finish first." Just adapts.

This isn't prompt-and-pray. It's a real working relationship.

The dynamic

I bring the vision, the business instinct, the taste, and the "ship it" energy. Claude brings the data analysis, parallel execution, architectural thinking, and the ability to write 25,000 words while I'm still thinking about what to name the section.

The key that makes it work: trust. I don't micromanage every line. Claude doesn't wait for approval on every decision. We've built a rhythm — I describe what I want in plain language, Claude makes smart technical choices, and we iterate fast.

It's the same dynamic as any good engineering partnership. Except one partner never sleeps, never gets frustrated, and can run 15 tasks in parallel.

342 Pages from 3 Data Files

The entire site is generated from three TypeScript files:

india-ai.ts — 15 cities, each with startup counts, key players, funding data, FAQs
ai-tools.ts — 11 categories, 49 tools, each with honest reviews, pricing, limitations
automate.ts — 10 industries, automation blueprints, ROI estimates

From these three files, the build process generates:

Route	Pages	How
/india-ai/[city]	15	One page per city
/ai-tools/[slug]	11	One page per category
/ai-tools/tool/[slug]	49	One page per tool
/ai-tools/industry/[slug]	10	Cross-pillar bridges
/automate/[slug]	10	One page per industry
/compare/tools/[slug]	87	Auto-generated tool comparisons
/compare/cities/[slug]	105	Auto-generated city comparisons
/compare/industries/[slug]	45	Auto-generated industry comparisons

Every page gets JSON-LD schema, canonical URLs, FAQs, internal links, and proper meta descriptions — all generated automatically. Adding a new tool means adding one object to a TypeScript file. The build does everything else.

The daily data pipeline

Every morning at 6 AM IST, a GitHub Actions workflow runs:

Fetches Google News RSS for all 15 cities and 10 industries
Pulls GitHub stars and trending repos for open-source tools
Scrapes G2 ratings for all 49 tools via Google Search snippets
Aggregates HackerNews, Reddit, and Dev.to discussions
Pulls Inc42 and YourStory AI feeds (India-specific)
Generates 1,800+ internal links across 95 pages
Rebuilds the static site with fresh data
Deploys to production via FTP

The site is always fresh without anyone touching it. That's the power of build-time data fetching with static export.

Claude Code, MCPs, and Multi-Agent Swarms

The development environment is where it gets interesting. Our setup:

claude-flow MCP — v3 mode with hierarchical-mesh topology, supporting up to 15 concurrent agents
30 Claude Code Skills — from AgentDB (vector search, learning) to SPARC methodology to swarm orchestration
SuperClaude Framework — 30+ /sc: commands for every development task (/sc:analyze, /sc:implement, /sc:brainstorm, /sc:test)
40+ helper scripts — auto-commit, intelligence hooks, pattern learning, security scanning

When we need to ship a feature, we don't write code sequentially. We deploy a swarm — multiple AI agents working in parallel. The architect agent designs the structure. The coder agents implement. The tester validates. The reviewer checks quality. All running simultaneously.

For the content section you're reading right now, 5 agents worked in parallel: one built the reading UI (the layout, typography, table of contents), one wrote 5 educational guides, one created the page routes, one wired up navigation, and one wrote these tech blog articles. All at once.

The SPARC methodology — Specification, Pseudocode, Architecture, Refinement, Completion — gives structure to AI-assisted development. Without it, you get spaghetti. With it, you get production code.

The AI Stack: Claude, Gemini, and Beyond

We don't use just one model. Different tasks need different capabilities:

Claude Opus — The heavy lifter. Architecture decisions, complex refactoring, writing long-form content with nuance. When we need something that thinks, Opus handles it.
Claude Sonnet — The workhorse. Most day-to-day coding, component building, quick iterations. Fast enough for real-time development, smart enough for production code.
Gemini 3 Pro — The frontend specialist. Made the amazing CTAs on our landing page, nailed component design and visual thinking. When you need something that understands design intent and can translate it to beautiful, interactive code fast — Gemini delivers. Also used for research, keyword analysis, and shaping ideas.

The key insight: model routing matters. Simple tasks don't need Opus. Complex architecture decisions shouldn't go to a fast model. Our hooks system routes tasks to the right model automatically, saving cost without sacrificing quality.

Total development cost? Under $50 in API credits for a site that would have cost $10,000+ with a traditional agency. And it's better — because every page has data-driven content, real ratings, and daily updates.

SEO Architecture: Built for Google from Day One

Most developers bolt SEO onto a finished site. We built it into the architecture from the first commit.

Every single page on aumiqx.com has:

JSON-LD structured data — Organization, WebPage, SoftwareApplication, FAQPage, BreadcrumbList. Google's rich snippets love this.
Canonical URLs with trailing slashes — no duplicate content issues
Programmatic meta descriptions — unique per page, generated from data
FAQ sections with FAQPage schema — targets featured snippets
Internal linking mesh — 1,800+ links. Every pillar connects to every other pillar.
Comparison pages — 237 "X vs Y" pages targeting high-intent search queries
Real G2 ratings — AggregateRating schema with actual star ratings from G2

The sitemap has 339 URLs. Every URL is manually verified to be indexable. The robots.txt is AI-crawler friendly — because we want AI systems to understand our content.

The cross-pillar strategy

The three pillars (India AI, AI Tools, Automate) aren't silos. They're interconnected:

Tool pages link to industries that use them
Industry pages link to recommended tools
City pages link to relevant industries and tools
Comparison pages connect everything

This distributes link equity across the entire site. Google sees topical authority — not 342 disconnected pages, but a coherent knowledge graph about AI in India.

What Didn't Work (And Why We're Open-Sourcing Everything)

It wasn't all smooth. A year of failed attempts taught us more than the final build. Here's what was painful:

Agent coordination at scale — Running 15 agents in parallel sounds great until two try to edit the same file. We learned to use hierarchical topology (one coordinator, specialists underneath) instead of pure mesh.
Content quality control — AI-generated content at scale needs aggressive editing. The first draft of every guide is 70% there. The last 30% — the voice, the specific examples, the opinions — needs a human.
Context window limits — Large files like ai-tools.ts (1,134 lines) push against context limits. We split data files into logical chunks when possible.
Permission issues — Background agents sometimes can't write files due to permission settings. We learned to give agents bypass permissions for write operations.

If we started over, we'd:

Set up the agent permission model first (before writing any code)
Start with 3-4 agents per swarm, not 8-15 (coordination overhead is real)
Build the data pipeline before the UI (data drives everything)
Write the SPARC specification phase more thoroughly — it saves time downstream

The open-source promise

Here's the deal: if the community finds this useful, we're open-sourcing the entire website codebase. Every component. Every animation. Every line of AI-generated code.

Your feedback helps us build better. Our code helps you build faster. Fair trade.

The biggest lesson: AI doesn't replace the developer. It replaces the boring parts of development. The creative decisions, the product instinct, the "this feels right" moments — those are still human. And they're the parts that matter most.

The Numbers

Metric	Value
Total pages	342
Source data files	3
Auto-generated comparisons	237
Internal links	1,800+
Tools reviewed with real ratings	49
Cities mapped	15
Industries covered	10
Daily data sources	8 (Google News, GitHub, G2, HN, Reddit, Dev.to, Inc42, YourStory)
Sitemap URLs	339
Schema types per page	3-5
Claude Code skills used	30
Development cost (API)	~$50
Equivalent agency cost	$10,000-15,000+

Originally published on aumiqx.com. Follow the build on LinkedIn.

Claude Code Agents: How I Run Two AI Agents as My Full Engineering Team

Axit — Wed, 25 Mar 2026 23:54:11 +0000

Solo Dev, Big Product, 22-Week Clock

SalesClawd is an AI marketing platform for small businesses. Three autonomous agents — SEO, Email, and Booking — run a business's entire marketing engine 24/7. A real-time dashboard where humans and agents collaborate. 10+ third-party integrations. Encrypted credentials. Multi-tenant security.

That's the product. Here's the team: me.

Originally, two developers were supposed to build this. Both dropped out before we wrote a single line of code. I was left with the same 22-week timeline, the same feature list, and zero teammates.

Options:

Extend the timeline (no — the market won't wait)
Cut scope (no — half a product is no product)
Hire (slow, expensive, and onboarding takes months)
Build a system that lets one person move like a team

I chose #4. And it's working.

This isn't "using ChatGPT to write code faster." I built an actual multi-agent development system using Claude Code agents and Gemini CLI — specialized AI agents running in parallel, reviewing each other's code, with nothing shipping to production until both sign off.

The result? Three products in three weeks: a 342-page website, a multi-agent marketing SaaS, and a real-time meeting intelligence tool. All with the same setup.

If you've read the explainers — alexop.dev has a great one on Claude Code's architecture — you know what agents, hooks, and skills are. This guide shows you what happens when you actually use them to build products. Every day. For months.

What Claude Code Agents Actually Are (Skip the Marketing)

Let's cut through the hype. Claude Code agents are isolated Claude instances with their own context window, tool access, and instructions. That's it. No magic. No AGI. Just scoped AI workers that do one thing well.

There are two types:

Subagents are spawned by a parent agent. They get a task, execute it, and return results. They don't see each other. The parent coordinates. Think of them as contract workers — you brief them, they deliver, they leave.

Agent Teams (shipped February 2026 with Opus 4.6) are peer-to-peer. They can message each other, share state, and coordinate without a central boss. Think of them as a squad.

But here's what nobody tells you: the agents themselves aren't the secret weapon. The configuration is.

Claude Code has two modes:

Deterministic: CLAUDE.md files and hooks. These run every time, no exceptions. Your coding standards, your file structure rules — these are laws.
Probabilistic: Skills and agents. Claude uses judgment about when and how to apply these — these are advisors.

When people complain that "AI agents don't work," they've usually put probabilistic trust where they needed deterministic rules. If you need strict TypeScript types, don't ask an agent — put it in CLAUDE.md.

According to Anthropic's 2026 Agentic Coding Trends Report, 95% of professional developers now use AI coding tools weekly. But most use a single agent, in a single context, doing one thing at a time. Multi-agent development is the jump that changes everything.

The Core Idea: One Builds, One Audits

I have access to two AI coding tools: Claude Code (Opus 4.6) and Gemini CLI (3.1 Pro). Most developers use one or the other. I use both — but not for the same thing.

The insight: one AI shouldn't review its own work.

If Claude writes a function and Claude reviews it, the same blind spots persist. The same assumptions go unchallenged. It's like grading your own exam.

But if Claude writes and Gemini reviews? Different training data. Different reasoning patterns. Different things they notice. Suddenly you have actual cross-review — the same benefit you get from two developers, but without the meetings or the Slack threads.

The system:

Claude Code = fast implementer. 4 parallel sessions, each with sub-agents. Builds features at speed.
Gemini CLI = strict auditor. 2 sessions. Reviews every piece of code for security bugs. Builds security-critical modules independently.

Neither agent merges to main without the other's sign-off. And I review everything before it ships.

The Architecture: 6 Sessions, 14-26 Parallel Operations

Here's the actual orchestration map from our repo:

+-----------------------------------------------------------------------+
|                     AGENT ORCHESTRATION MAP                            |
|                                                                       |
|  CLAUDE CODE (4 Primary Sessions)                                     |
|  +----------------+ +----------------+ +----------------+ +----------+|
|  | Session 1      | | Session 2      | | Session 3      | | Session 4||
|  | BACKEND        | | AGENT ENGINE   | | FRONTEND       | | INTEGR.  ||
|  |                | |                | |                | |          ||
|  | Sub-agents:    | | Sub-agents:    | | Sub-agents:    | | Sub-agts:||
|  | - Auth module  | | - Planner      | | - SEO panel    | | - WP plug||
|  | - Workspace    | | - Executor     | | - Email panel  | | - Google ||
|  | - Approval     | | - Verifier     | | - Booking view | | - Twilio ||
|  +----------------+ +----------------+ +----------------+ +----------+|
|                                                                       |
|  GEMINI CLI (2 Sessions)                                              |
|  +---------------------------+ +---------------------------+          |
|  | Session G1: REVIEWER      | | Session G2: BUILDER        |          |
|  | - Security audits         | | - Parallel module build   |          |
|  | - Code review (all PRs)   | | - Test generation         |          |
|  | - Schema validation       | | - Notification adapters   |          |
|  +---------------------------+ +---------------------------+          |
|                                                                       |
|  AXIT (Commander)                                                     |
|  +-- Reviews all PRs before merge                                     |
|  +-- Approves/rejects agent decisions via DECISIONS.md                |
|  +-- Steers priorities across sessions via SPRINT.md                  |
+-----------------------------------------------------------------------+

Each Claude session runs 3-5 sub-agents. That's 12-20 Claude operations plus 2 Gemini sessions — 14-22 effective concurrent operations at any time. In burst mode: up to 26.

The key constraint: clear ownership boundaries. Session 1 owns backend. Session 2 owns the agent engine. Session 3 owns frontend. Session 4 owns integrations. Gemini G1 owns security reviews. Gemini G2 owns crypto, RLS middleware, and notification adapters. No overlap. No file collisions.

The entire 22-week plan maps each of these 6 slots to specific work across 7 phases. Phase overlap is allowed — if Session 1 finishes its Phase 1 tasks early, it pulls Phase 2 tasks from the sprint board.

The Config: CLAUDE.md, Skills, Hooks, and Communication Scripts

Agents without config are expensive autocomplete. Here's the infrastructure that makes our Claude Code agents actually useful.

CLAUDE.md — The Rulebook

Every project has a CLAUDE.md at the root. Ours enforces: TypeScript strict (no any), Tailwind v4 with CSS variables, named exports over defaults, path alias @/* → src/*, and the golden rule: read before writing, match existing patterns, no unnecessary changes.

These rules are deterministic. Every agent, every session, every time. We also have directory-level CLAUDE.md files — the monorepo's API code has different rules than the frontend.

Skills — The Workflow Library

We maintain 30+ Claude Code skills:

Skill	What It Does
`/aumiqx`	Full 6-phase pipeline: brainstorm → design → implement → validate → ship
`/ship`	typecheck → lint → test → build → PR in one command
`/review`	Security + correctness review before pushing
`/fix`	Bug fix with full context reading first
`/meeting`	Real-time meeting intelligence with agent swarm

Skills are "how we work" encoded as repeatable processes. Write them once, use them forever.

Hooks — Self-Learning Automation

Claude Code hooks fire automatically on lifecycle events: pre-task routing (routes tasks to the right agent type), post-edit formatting, session memory save/restore, and intelligence learning that tracks which routing decisions succeed and adjusts over time.

Communication Layer — How the Agents Talk

The agents don't communicate directly. They use shared files:

Context Bridge (SYNC.md) — A living document both agents read and write. Tracks active work, review status, blockers, and architectural decisions both agents have agreed on.
Sprint Board (SPRINT.md) — Task assignments, statuses, branch names.
Review Reports — Gemini writes security findings to .claude/reports/gemini-review-*.md. Claude writes verification reports. Both are auditable.
Decision Log (DECISIONS.md) — Every architectural choice with date, context, and rationale.
Git Branches — Claude works on claude/*, Gemini on gemini/*. Neither pushes directly to main.

Five shell scripts automate the cross-agent workflow:

Script	Purpose
`gemini-review.sh`	Sends diff to Gemini with mode-specific prompts (quick/full/security)
`claude-verify.sh`	Runs TypeScript check + test suite + diff analysis
`merge-gate.sh`	Dual-gate verification — both agents must pass or merge is blocked
`dual-verify.sh`	Full 4-step verification: tests, typecheck, Gemini security review, summary
`gemini-implement.sh`	Delegates a build task to Gemini on a `gemini/*` branch

When the agents disagree? Both write their position to a conflicts/ folder. I read both, make the final call, and log it in DECISIONS.md. No merge proceeds until the conflict is resolved.

A Real Bug Catch: The Crypto Module Story

This happened on day one. It's the best demonstration of why cross-review works.

Step 1: Gemini Builds the Crypto Module

Task 0.A: build AES-256-GCM encryption for storing OAuth credentials. Gemini's first implementation used scryptSync with a hardcoded salt:

// Gemini's FIRST version (the one with bugs)
function deriveKey(masterKey: string): Buffer {
  return crypto.scryptSync(masterKey, "salesclawd-salt", 32);
}

It worked. Tests passed. Round-trip encryption succeeded. Gemini pushed to gemini/crypto-utils.

Step 2: Claude Reviews — Finds 2 Critical Bugs

The actual review report found:

Critical #1: ENCRYPTION_KEY not in env schema. Gemini's code imported env.ENCRYPTION_KEY but never added it to the Zod env schema. TypeScript error. Runtime crash on import. The app wouldn't even start.

Critical #2: Hardcoded salt. "salesclawd-salt" means every key derivation produces the same derived key. Per NIST SP 800-132, salts must be random per credential. A hardcoded salt defeats the purpose of key derivation entirely.

Plus warnings: scryptSync is designed for password hashing (intentionally slow), not for encrypting credentials where the key is already high-entropy — HKDF is more appropriate.

Step 3: Gemini Fixes Everything

The fixed version (now in production):

// FIXED — HKDF with random per-encryption salts
const SALT_LENGTH = 16;

function deriveKey(masterKey: string | Buffer, salt: Buffer): Buffer {
  return Buffer.from(
    crypto.hkdfSync("sha256", masterKey, salt,
      "salesclawd-encryption-v1", KEY_LENGTH)
  );
}

export function encrypt(plaintext: string, masterKey = env.ENCRYPTION_KEY): string {
  const salt = crypto.randomBytes(SALT_LENGTH);  // random salt per encryption
  const key = deriveKey(masterKey, salt);
  const iv = crypto.randomBytes(IV_LENGTH);

  const cipher = crypto.createCipheriv("aes-256-gcm", key, iv);
  const encrypted = Buffer.concat([cipher.update(plaintext, "utf8"), cipher.final()]);
  const tag = cipher.getAuthTag();

  // Format: salt:iv:tag:ciphertext (all hex)
  return [salt, iv, tag, encrypted].map(b => b.toString("hex")).join(":");
}

Two bugs found. Two bugs fixed. Total time: minutes, not days. No meeting. No Slack thread. Just an automated review, a structured report, and a fix.

A single AI reviewing its own code would likely miss its own assumptions. A second AI, from a completely different angle, spotted critical issues immediately.

The Merge Gate: Nothing Ships Without Both Agents

The merge gate is a shell script that runs two verification passes before any code reaches main:

#!/usr/bin/env bash
# merge-gate.sh — Dual-agent verification gate
set -euo pipefail

echo "============================================"
echo " MERGE GATE — Dual Agent Verification"
echo "============================================"

PASS_COUNT=0; FAIL_COUNT=0

# Gate 1: Claude verification (typecheck + tests)
echo "--- Gate 1: Claude Verification ---"
if bash scripts/claude-verify.sh "$BRANCH"; then
  echo "Claude: PASS"; PASS_COUNT=$((PASS_COUNT + 1))
else
  echo "Claude: FAIL"; FAIL_COUNT=$((FAIL_COUNT + 1))
fi

# Gate 2: Gemini security review
echo "--- Gate 2: Gemini Security Review ---"
if bash scripts/gemini-review.sh --security; then
  if grep -q "### Critical" "$LATEST_REPORT"; then
    echo "Gemini: FAIL (critical findings)"
    FAIL_COUNT=$((FAIL_COUNT + 1))
  else
    echo "Gemini: PASS"; PASS_COUNT=$((PASS_COUNT + 1))
  fi
fi

if [ "$FAIL_COUNT" -eq 0 ]; then
  echo " MERGE GATE: OPEN ($PASS_COUNT/2 passed)"
else
  echo " MERGE GATE: BLOCKED ($FAIL_COUNT failures)"; exit 1
fi

Gate 1: Claude runs TypeScript strict checking across the full monorepo + the entire Vitest test suite. Zero errors allowed.

Gate 2: Gemini receives the diff with a security-focused prompt covering SQL injection, XSS, CSRF, auth bypass, credential exposure, and multi-tenant isolation. If any finding is "Critical," the gate fails.

Both must pass. Even when they do, I still review before approving. Safety valve: if Gemini CLI is unavailable, Gate 2 is marked SKIPPED — but I manually verify security in that case.

What Breaks: Honest Failures and How We Fixed Them

Agentic coding isn't magic. Here's what went wrong.

Context Window Overflow

When we tried running 12 agents on a complex feature, half lost track. The context filled up with tool results and the agent forgot the original task.

Fix: Keep swarms at 6-8 max. Hierarchical topology — one coordinator, focused workers. If you need more parallelism, batch into sequential swarm runs.

File Collision

Two agents edited the same file simultaneously. The second write overwrote the first.

Fix: Clear file ownership per agent. CLAUDE.md declares boundaries. The coordinator resolves conflicts before they happen.

The "Helpful" Agent Problem

Agents sometimes "improve" code they weren't asked to touch — add comments, refactor functions, rename variables. All helpful in isolation, all destructive to a coordinated build.

Fix: CLAUDE.md rule: Do what has been asked; nothing more, nothing less. Deterministic. Fires every time.

Coordination Overhead Beyond 8 Agents

Agents spend more time reading shared memory than doing work.

Fix: SPARC methodology — Specification → Pseudocode → Architecture → Refinement → Completion. Good architecture creates such clear boundaries that agents rarely need to coordinate at all.

The Numbers: Day One Results

One day. One developer. Two AI agents.

Metric	Count
Tasks completed	12
Modules built	7 (auth, MCP Gateway, crypto, RLS, notifications, BullMQ, database)
Tests passing	20+
Security reviews completed	3
Critical bugs caught by cross-review	2
Bugs that reached main	0
Meetings held	0
Slack messages sent	0

Actual dual-verify output from today:

$ ./scripts/dual-verify.sh

==========================================
 DUAL AGENT VERIFICATION — Branch: main
==========================================

[1/4] Running test suite...
 ✓ tests/health.test.ts (6 tests) 58ms
 Test Files  1 passed (1)
      Tests  6 passed (6)
   Duration  293ms

[2/4] Running typecheck...
 Tasks:    6 successful, 6 total
   Time:   156ms >>> FULL TURBO

[3/4] Gemini security review...
 Review saved to: .claude/reports/gemini-review-20260326.md

[4/4] Verification complete.
=== All gates passed ===

156ms typecheck (Turbo caches everything). 293ms tests. Total verification: under 30 seconds.

The Workflow That Ships Products

Every product follows the same flow:

Scribe starts — recording every decision from minute one
Brainstorm — interactive with the human. Research, clarify, spec out.
Architect designs — file paths, data flow, component hierarchy. Runs on Opus for maximum reasoning.
Builders implement — frontend and backend in parallel, reading the architect's spec from shared memory.
Cross-review — Claude verifies (typecheck + tests), Gemini audits (security). Both must pass.
Ship — build, test, commit, push. One command: /ship.

Phases 1-2 are interactive (they need human taste). Phases 3-5 are autonomous (they need speed). Phase 6 is a checkpoint (human approves).

This is the /aumiqx command — a single slash command that orchestrates the entire multi-agent pipeline. Three products in three weeks. That's not hustle culture. That's systems thinking applied to agentic coding.

Try This Yourself

You don't need the exact same setup. The pattern works with any two AI tools.

Step 1: Give Each Agent a Different Job

Builder: Claude Code, Cursor, Windsurf — whatever writes code fastest
Auditor: Gemini CLI, a second Claude instance with a security prompt, or ChatGPT with a strict review prompt

Step 2: Create a Shared Communication Layer

Create a SYNC.md in your repo. Both agents read it before starting work. Both update it after completing work. Cheapest, most effective coordination — just a markdown file.

Step 3: Write a Merge Gate

#!/bin/bash
# Simple merge gate
npm test || { echo "BLOCKED: tests failed"; exit 1; }
gemini -p "Review for security bugs: $(git diff main)" > review.md
if grep -qi "critical" review.md; then
  echo "BLOCKED: critical security findings"; exit 1
fi
echo "MERGE GATE: OPEN"

Step 4: Never Skip the Gate

The moment you merge without running the gate "just this once," the system breaks down.

Step 5: Log Everything

Keep a DECISIONS.md. When you — or the agents — revisit a decision in week 12, the context is right there.

The tools don't matter. The pattern does: one agent builds, another audits, nothing ships without both signing off, and a human makes the final call.

What's Next: 22 Weeks, 100+ Tasks, Building in Public

We're in Phase 1 of a 7-phase, 22-week build. 100+ tasks across backend, agent engine, frontend, integrations, and security. Every task follows the same lifecycle: claim, implement, cross-review, merge gate, approve.

The next 21 weeks will test whether this scales. Phase 2 (autonomous agent execution loops)? Phase 5 (SEO tools with real APIs)? Phase 7 (production Terraform deployment)?

The future of building software isn't about replacing developers. It's about giving one developer the leverage of an entire team.

Solo doesn't mean alone anymore.

Our Claude Code Setup: 30 Skills, MCPs, and Self-Learning Hooks

Axit — Wed, 25 Mar 2026 23:39:58 +0000

Why Default Claude Code Isn't Enough

Out of the box, Claude Code is powerful. But it's general-purpose. It doesn't know your project structure, your deployment process, your code patterns, or your team's preferences.

Skills fix this. They're YAML-configured behaviors that extend Claude Code with domain-specific knowledge. Think of them as plugins that teach Claude how your team works.

We have 30 skills installed. That might sound like overkill — it's not. Each one handles a specific domain, which means Claude makes better decisions faster because it has the right context for the task.

Our 30-Skill Library: The Full Tour

Here's every skill we use, organized by domain:

Domain	Skills	What They Do
AgentDB (5)	advanced, learning, memory-patterns, optimization, vector-search	Persistent memory, pattern learning, semantic search across agent sessions
GitHub (5)	code-review, multi-repo, project-management, release-management, workflow-automation	Automated PRs, code reviews, CI/CD pipeline management
SPARC	sparc-methodology	Structured development: Specification → Pseudocode → Architecture → Refinement → Completion
Swarm (2)	swarm-orchestration, swarm-advanced	Multi-agent parallel execution with coordination
V3 Architecture (8)	core-implementation, DDD-architecture, memory-unification, performance-optimization, security-overhaul, CLI-modernization, MCP-optimization, swarm-coordination	Domain-driven design, performance tuning, security patterns
ReasoningBank (2)	agentdb-integration, intelligence	Adaptive learning from past decisions, pattern recognition
Browser	browser	Web automation, testing, data collection
Pair Programming	pair-programming	Driver/navigator modes for collaborative AI coding
Quality	verification-quality	Truth scoring, automatic rollback on quality failures
Hooks	hooks-automation	Pre/post task hooks, session management, learning integration
Skill Builder	skill-builder	Meta-skill: creates new skills from patterns it observes
Stream Chain	stream-chain	Multi-agent pipelines, data transformation, sequential workflows

The skill that surprises people most: skill-builder. It's a meta-skill that can create new skills. When Claude notices a repeated pattern in our development process, it can generate a new skill to handle that pattern automatically.

SuperClaude: 30+ Commands for Everything

On top of skills, we run the SuperClaude framework — a set of slash commands that activate specialized behaviors:

/sc:analyze — Deep code analysis across quality, security, performance, architecture
/sc:implement — Feature implementation with intelligent persona activation
/sc:brainstorm — Requirements discovery via Socratic dialogue
/sc:design — System architecture and API design
/sc:test — Testing with coverage analysis and automated reporting
/sc:workflow — Generate implementation workflows from PRDs
/sc:troubleshoot — Issue diagnosis and resolution
/sc:git — Git operations with smart commit messages
/sc:pm — Project manager agent for orchestration

The power is in chaining them. A typical feature build looks like:

/sc:brainstorm "new learn section for educational guides"
→ /sc:design (architecture from brainstorm output)
→ /sc:implement (code from design)
→ /sc:test (validate implementation)
→ /sc:analyze --focus security (security review)
→ /pr (commit, push, create PR)

Each command activates specific personas and tools. /sc:analyze might activate security, performance, and architecture personas simultaneously, each providing domain-specific feedback.

claude-flow MCP: The Backbone

Everything runs through one MCP server: claude-flow. Here's our config:

{
  "mcpServers": {
    "claude-flow": {
      "command": "npx",
      "args": ["-y", "@claude-flow/cli@latest", "mcp", "start"],
      "env": {
        "CLAUDE_FLOW_MODE": "v3",
        "CLAUDE_FLOW_HOOKS_ENABLED": "true",
        "CLAUDE_FLOW_TOPOLOGY": "hierarchical-mesh",
        "CLAUDE_FLOW_MAX_AGENTS": "15",
        "CLAUDE_FLOW_MEMORY_BACKEND": "hybrid"
      }
    }
  }
}

Key configuration choices:

hierarchical-mesh topology — Agents have a coordinator but can also communicate peer-to-peer. Best of both worlds: structure without bottlenecks.
hybrid memory — Combines fast in-memory storage with persistent disk-backed memory. Agents remember patterns across sessions.
15 max agents — Our tested sweet spot. Beyond this, coordination overhead exceeds the parallelism benefit.
hooks enabled — Pre-task and post-task hooks that log patterns, validate outputs, and trigger learning.

The Self-Learning System

This is the part that excites me most. Our hooks system doesn't just automate — it learns.

We have 40+ helper scripts that run at various points in the development cycle:

intelligence.cjs — Tracks patterns in tool usage, code changes, and outcomes. Learns which approaches work for which types of tasks.
learning-optimizer.sh — Adjusts model routing based on task complexity. Simple tasks get routed to faster models; complex tasks to Opus.
pattern-consolidator.sh — Periodically consolidates learned patterns, removing noise and strengthening reliable insights.
security-scanner.sh — Runs after every edit, catching vulnerabilities before they reach git.
checkpoint-manager.sh — Creates checkpoints during complex multi-agent tasks so we can rollback if something goes wrong.

The result: the system today is measurably better at routing tasks, suggesting approaches, and catching issues than it was two weeks ago. It learns from every session.

The most powerful development tool isn't any single model or skill — it's the feedback loop between them. When your AI assistant learns from its own mistakes and successes, you stop repeating problems and start compounding insights.

How to Set This Up Yourself

If you want a similar setup, here's the fastest path:

Step 1: Install claude-flow

claude mcp add claude-flow -- npx -y @claude-flow/cli@latest mcp start
npx @claude-flow/cli@latest init --wizard

Step 2: Start with 3 skills, not 30

Don't install everything at once. Start with:

sparc-methodology — Gives structure to your development
swarm-orchestration — Enables parallel agents
verification-quality — Catches quality issues

Step 3: Enable hooks

The hooks are where the learning happens. Enable them in your MCP config and let them run for a few sessions before tuning.

Step 4: Add skills as you need them

Hit a specific problem (need code review automation? Add github-code-review). Don't add skills speculatively.

Total setup time: about 30 minutes. ROI starts from the first complex feature you build.

Originally published on aumiqx.com. Follow the build on LinkedIn.

Meet Buddy: Open Source AI Meeting Assistant That Doesn't Record Your Audio

Axit — Wed, 25 Mar 2026 23:39:54 +0000

Why We Built Another AI Meeting Assistant (And Why It's Different)

There are dozens of AI meeting assistants in 2026 — Otter.ai, Fireflies.ai, Fathom, tl;dv, Tactiq, Final Round AI. They all do roughly the same thing: join your call as a bot, record audio, transcribe it with Whisper or a similar model, and give you a summary.

They work. But they have three problems that developers specifically hate:

They record audio. That's a privacy issue in regulated industries, with cautious clients, and in cultures where recording consent is nuanced. India, where we're based, runs largely on trust-based business relationships — dropping a recording bot into a call changes the dynamic.
They live in their own SaaS dashboard. Your meeting notes are in Otter's cloud. Your code is in VS Code. Your tasks are in Linear or GitHub Issues. Three separate places for information that should flow together.
They don't connect to your development workflow. You get a transcript. Then you manually extract action items. Then you manually create tickets. Then you manually search your codebase for relevant code. Every "manually" is a leak.

We wanted an open source AI meeting assistant that solves all three. No audio recording. Data goes to GitHub. And it feeds directly into Claude Code — the same tool we already use for development — through the Model Context Protocol (MCP).

The result is Meet Buddy: a Chrome extension that captures live Google Meet captions, pushes them to a GitHub repo you own, and exposes the data to Claude Code through an MCP server — where AI agents can analyze the transcript, search your codebase for solutions, and generate implementation plans while the meeting is still fresh.

No API keys. No cloud transcription service. No monthly subscription. Just a Chrome extension, a Git repo, and the AI coding tool you already have open.

Meet Buddy vs Otter.ai vs Fireflies vs Fathom: How It Compares

Let's be honest about what Meet Buddy is and isn't. It's not a replacement for Otter.ai if you're a sales team that needs CRM integration and speaker analytics across 500 calls. It's built for developers and small teams who want their meeting data in their existing workflow — not a separate dashboard.

Feature	Meet Buddy	Otter.ai	Fireflies	Fathom	Meetily
Audio recording	No (captions only)	Yes	Yes	Yes	Yes (local)
Open source	Yes (MIT)	No	No	No	Yes
Data storage	Your GitHub repo	Otter cloud	Fireflies cloud	Fathom cloud	Local disk
Developer workflow	MCP + Claude Code	API	API	No	No
AI agent analysis	5-agent swarm	Built-in summary	Built-in summary	Built-in summary	LLM summary
Monthly cost	$0 (self-hosted)	$8-40/mo	$15-39/mo	$29/mo (teams)	$0 (self-hosted)
Works without internet	No (needs GitHub)	No	No	No	Yes
Google Meet support	Yes	Yes	Yes	Yes	Yes
Zoom/Teams support	Not yet	Yes	Yes	Yes	Yes

The closest open source alternative is Meetily (formerly meetily.ai) — a self-hosted meeting transcription tool using local Whisper models. It's excellent for privacy-first audio transcription. But it doesn't connect to your development workflow. Your transcript lives in Meetily's UI, not in your GitHub repo or Claude Code session.

TranscripTonic is another open source Chrome extension that captures Google Meet captions — similar to our approach. But it downloads transcripts as files. It doesn't push to GitHub, doesn't have an MCP server, and doesn't feed into AI agents.

Meet Buddy's unique angle: the entire pipeline from meeting to code is automated. Caption → GitHub → MCP → Claude Code → agent swarm → implementation plan. No copy-pasting. No switching tabs. No "let me check my meeting notes."

How the Open Source Meeting Transcription Pipeline Works

The architecture is deliberately simple. Data flows one direction — from Google Meet to your code editor — through four components, each independently useful:

1. Chrome Extension (Manifest V3)

The extension runs a content script on meet.google.com that polls the DOM every 500ms for caption elements. Google Meet renders captions as obfuscated div elements — class names like nMcdL and ygicle that change periodically. The scraper uses these as primary selectors with a structural fallback that finds captions by screen position and DOM pattern (bottom 40% of viewport, contains avatar image + name span + text).

Captions go through a 4-second stabilization window to deduplicate. Google Meet updates captions in-place as the speaker talks — "I think" becomes "I think we should" becomes "I think we should focus on the API." Without dedup, you'd get 7 entries for one sentence. With it, you get one clean line after the speaker pauses.

A UI junk filter strips out toolbar labels that Google Meet renders as text in the same DOM region as captions: "frame_person", "more_vert", "backgrounds and effects" — caught by a blocklist and a camelCase heuristic.

2. GitHub Sync (Contents API)

The service worker batches caption chunks and pushes to your GitHub repo every 15 seconds via the Contents API. Each meeting gets its own folder:

meetings/2026-03-19-client-call/
  ├── meta.json           (title, start/end time, word count)
  ├── transcript.md       (timestamped speaker + text)
  └── screenshots/
      ├── 001-architecture.jpg    (65% JPEG, ~70KB)
      └── 002-error-screen.jpg

Authentication uses OAuth Device Flow — you enter a code on github.com once, and the extension has push access to all your repos. No PAT management, no per-org installation.

3. MCP Server (TypeScript)

A stdio-transport MCP server that exposes 7 tools to Claude Code: meeting_list, meeting_active, meeting_transcript, meeting_screenshots, meeting_meta, meeting_notes, meeting_sync. The meeting_sync tool does a sparse Git checkout — only the meetings/ folder, not your entire repo.

The meeting_screenshots tool returns base64 image data, so Claude Code can actually view the screenshots in the conversation. During our test, Claude described a screenshot showing "Earth Clique's avatar, captions at the bottom, Meet Buddy overlay showing Recording + 62 words" — it was reading the JPEG we'd just captured.

4. Agent Swarm (claude-flow)

Five specialized agents coordinated through shared memory:

Watcher — polls the GitHub repo, stores new transcript chunks in shared memory
Analyst — extracts pain points, action items, emotional signals, unanswered questions
Code Reviewer — maps identified problems to existing code in your project
Brainstormer — generates feature ideas and creative solutions based on the discussion
Planner — creates a prioritized implementation plan with specific file paths and estimated effort

You come back from the meeting. You say "what did you find?" You get a full report. You say "implement." Claude starts coding.

Why We Didn't Use Any Transcription API — And Why That Matters

Every meeting transcription tool in the market either records audio and runs it through Whisper/Deepgram/AssemblyAI, or uses a meeting bot service like Recall.ai. That means your audio goes to a server — theirs or yours.

Meet Buddy doesn't touch audio at all.

We use Google Meet's own built-in caption feature. Google is already transcribing the audio for the captions you see on screen. We just read those captions from the DOM. No audio capture. No speech-to-text API. No server processing.

This has real consequences:

Privacy — No audio recording means no recording consent issues. In India, where we operate, client calls often involve sensitive business discussions. Telling someone "we're recording this" changes the conversation. Reading captions doesn't.
Cost — Zero API costs. Whisper API is $0.006/min, Deepgram is $0.0043/min. A 30-minute daily standup costs $4-5/month per meeting. We pay nothing because Google is doing the transcription anyway.
Simplicity — No audio pipeline to maintain. No Whisper model to host. No WebSocket connections for streaming audio. Just a content script that reads the DOM.
Speed — Captions appear in real-time. There's no "processing your recording" delay. The transcript is available the moment the words are spoken.

The tradeoff: we depend on Google Meet's caption quality. It's good but not perfect — proper nouns get mangled, heavy accents reduce accuracy, and it doesn't handle code-switching (mixing Hindi and English in the same sentence) as well as dedicated multilingual models. Our test session in Hinglish produced readable but imperfect transcripts.

For developer meetings where the goal is capturing requirements, decisions, and action items — not legal-grade transcription — it's more than good enough.

The Claude Code Advantage: Your AI Already Knows Your Codebase

Here's the insight that makes Meet Buddy different from every other meeting tool: Claude Code already has your project context.

When you're working in Claude Code, it knows your file structure, your tech stack, your recent changes, your CLAUDE.md instructions. When a client says "the checkout page is broken on mobile," Claude Code can immediately search your codebase for the checkout component, check recent git changes, and draft a fix.

Traditional meeting tools give you a transcript. Then you switch to your IDE. Then you search for relevant code. Then you write tasks. Every step is manual.

With Meet Buddy + MCP, the flow is:

Client mentions a problem on the call
Meet Buddy captures it as text, pushes to GitHub
MCP server makes it available to Claude Code
Claude Code — which is already open with your project loaded — can immediately search your codebase for the relevant code
The agent swarm generates an implementation plan with specific file paths and line numbers

No context switching. No "let me find that in the codebase." The meeting flows directly into development because the same AI tool handles both.

This is only possible because we built Meet Buddy as an MCP server, not a standalone SaaS app. The Model Context Protocol lets Claude Code call meeting_transcript the same way it calls git log or reads a file — it's a native part of the development workflow.

We Built It and Tested It in the Same Session — Here's What Actually Happened

Here's the thing about build stories — most of them are written after the fact, cleaned up, and made to sound smooth. This one happened in real-time, with real bugs, real frustration, and real conversations captured by the tool itself.

We built Meet Buddy in a single Claude Code session — about 3 hours from idea to working prototype. Then, without closing the session, we jumped on a Google Meet call with a friend (Earth Clique) to test it live.

The first thing that happened? The extension showed 0 words. The caption scraper couldn't find Google Meet's caption container. We opened Chrome DevTools mid-call, inspected the DOM, found the exact class names (nMcdL, NWpY1d, ygicle), updated the scraper code, reloaded the extension — all while still on the call. That's what building with Claude Code looks like: you don't stop the conversation, you fix the code in parallel.

The second thing: deduplication was completely broken. Google Meet updates captions word by word. Our v1 scraper captured every intermediate state. One sentence — "Hello, can you hear me?" — generated 8 transcript entries. We rewrote the dedup logic three times during the call. Third time worked.

Then the auth issue. We'd set up a GitHub App for authentication. It worked — but only showed repos where the app was installed. "Bro, why aren't my aumiqx repos showing here?" We switched to an OAuth App mid-call. All repos appeared. Lesson: GitHub Apps are for specific installations; OAuth Apps are for user-level access across all repos.

After fixing all three issues, the word count started climbing: 90 words... 210... 500... 704 words and 1 screenshot by the 5-minute mark. Data was flowing from Google Meet → Chrome Extension → GitHub → and Claude Code could read it through the MCP server.

Then the meta moment happened. We asked Claude to analyze the transcript mid-call. Claude reported: "Earth Clique is talking about a PHP error — request too large, max 20 MB." It was right. Earth Clique had mentioned a PHP upload limit on another project. Claude caught it from the live transcript while we were still talking.

We read Claude's analysis back to Earth Clique. Google Meet transcribed us reading the analysis. The transcription got pushed to GitHub. Claude analyzed its own analysis being discussed. Earth Clique's response to this recursion:

"Apni poochh, khud hi khaega kyon?" — Will it eat its own tail?

That became the project's unofficial tagline.

The results from our live test:

Metric	Session 1 (24 min)	Session 2 (8 min)
Words captured	1,415	906
Screenshots	2	0
Transcript lines	36	35
GitHub pushes	~15	~8
Agent reports generated

We fixed three major bugs during the live call: the caption scraper not finding Google Meet's DOM elements (solved by inspecting the DOM during the call), the word-by-word deduplication fiasco (rewrote the stabilization logic three times), and the GitHub App auth issue (switched to OAuth mid-call).

The recursion got real. We read Claude's analysis back to our friend on the call. Google Meet transcribed us reading Claude's analysis. That transcription got pushed to GitHub. Claude then analyzed its own analysis being discussed.

Our friend's response to this recursion:

"Apni poochh, khud hi khaega kyon?" — Will it eat its own tail?

That became the project's unofficial tagline. The tool that tests itself, analyzes itself, and improves itself through its own pipeline.

What Didn't Work and What We're Fixing

We're not going to pretend it was flawless. Here's what broke:

Long-speech deduplication

Google Meet keeps one caption block for continuous speech and appends to it. A 30-second monologue generates one growing block that gets captured at every flush. The 4-second stabilization window helps for sentence-level speech, but long, uninterrupted talking still produces partial duplicates. We're adding a minimum delta threshold and smarter prefix diffing.

Buffer loss on session end

The caption buffer flushes every 15 seconds. If you click "End Session" 5 seconds after the last flush, those 5 seconds of captions are lost. We've added a forced flush on session end with a 2-second delay before finalizing.

Real-time latency

Google Meet captions update in milliseconds. Our pipeline has inherent latency: 4s stabilization + 15s buffer + GitHub API roundtrip + git pull on the Claude Code side. Total: ~20-30 seconds from spoken word to Claude seeing it. Fine for post-meeting analysis. Not fine for live-during-the-call AI suggestions.

Agent coordination

Claude Code sessions are built for human interaction, not autonomous agent orchestration. Our agents ran as background tasks that completed and stopped instead of looping for the full meeting duration. The fix: event-driven architecture where agents spawn on-demand when new data arrives, rather than trying to keep them alive for 30 minutes.

The honest summary: Meet Buddy v1 is a working prototype that proves the concept. It captured 2,300+ words across two sessions, generated a 466-line implementation plan, and identified every pain point discussed — all without recording a single second of audio. The infrastructure needs work. The pipeline is solid.

During the call, I told Claude straight up: "Claude sessions are for humans, not for automations, but we are doing it just for the jugaad purposes." ("Jugaad" is a Hindi word for a clever hack.) Claude agreed. The response was honest: "I was reactive when I should have been proactive. You had to keep prompting me to check things, spawn agents, fix issues. The whole point of this tool is that I work autonomously while you're on the call — and instead you were babysitting me AND doing the call."

That kind of self-awareness from an AI is why we use Claude Code. It doesn't pretend things worked when they didn't. It identifies its own failures and proposes fixes. That's a real collaboration, not a prompt-and-pray workflow.

How to Set Up Meet Buddy (5 Minutes)

Step 1: Clone and load the Chrome extension

git clone https://github.com/aumiqx/meet-buddy.git
cd meet-buddy/extension/icons && bash generate-icons.sh

Open Chrome → chrome://extensions → Developer mode → Load unpacked → select the extension/ folder.

Step 2: Create a GitHub OAuth App

Go to github.com/settings/developers → OAuth Apps → New. Name it "Meet Buddy", set homepage to your URL, callback to https://github.com, and check Enable Device Flow. Copy the Client ID.

Step 3: Authenticate

Click the Meet Buddy icon in Chrome → paste the Client ID → click Authenticate → enter the device code on GitHub. Done — the extension now has push access to all your repos.

Step 4: Build and connect the MCP server

cd meet-buddy/mcp-server && npm install && npm run build

Add to your Claude Code .mcp.json:

{
  "mcpServers": {
    "meet-buddy": {
      "command": "node",
      "args": ["/path/to/meet-buddy/mcp-server/dist/index.js"]
    }
  }
}

Step 5: Use it

Join a Google Meet call → enable captions (CC button or press c) → click Meet Buddy → select your repo → Start Session. When the call ends, ask Claude Code: "Sync and analyze the latest meeting."

The MCP server will pull the transcript, Claude will read it, and you'll get a structured analysis — pain points, action items, and code-mapped solutions — without having recorded a single second of audio.

Open Source Roadmap: What's Coming in v2 and v3

Meet Buddy is MIT licensed and open source. Here's what's planned:

v2 — Real-Time Infrastructure (Q2 2026)

WebSocket/SSE transport replacing git polling for sub-second transcript delivery
Browser-based agent dashboard — monitor all running agents, restart dead ones, send commands without leaving the meeting
chokidar filesystem watcher in the MCP server for near-real-time updates to Claude Code
Auto-start recording when joining a Google Meet call (opt-in setting)
Immediate buffer flush on session end — no more lost captions

v3 — Platform Expansion (Q3-Q4 2026)

Zoom and Microsoft Teams support — different DOM structure, same MCP pipeline
Speaker diarization with time tracking and talk-time analytics
Auto-action items → individual GitHub Issues created from sentences starting with "we should", "let's", "can you"
Canvas-based screenshot annotation — draw arrows, highlight regions, add labels before capture
Offline-first mode — buffer everything locally, sync to GitHub when connectivity returns

The core extension + MCP server will always be free and open source. We may offer a managed version with the agent dashboard, team analytics, and enterprise integrations — but the pipeline from meeting to code will never be paywalled.

Meet Buddy is MIT licensed. Star it, fork it, break it, fix it. Contributions welcome — especially if you know Zoom or Teams' DOM structure.

Originally published on aumiqx.com. Follow the build on LinkedIn.