In 2021, I sat in front of a camera to talk about the sanctity of the “One Horse.” I was a disciple of Cal Newport, preaching the gospel of Deep Work—the idea that to produce anything of value, you have to shield yourself from the “monkey mind” of multitasking. At Launchable, we built an entire culture around “Get Shit Done” (GSD) days, creating organizational umbrellas to protect our cognitive sovereignty.

I thought I had mastered the “horses running all over the place.” I was wrong.

In late 2025, I dove into Claude Code. I lucked out on the timing; the models had just hit a threshold of capability where the vibe of building shifted from collaborating to orchestrating. It felt like I had finally found the ultimate GSD weapon.

But within weeks, the “One Horse” was trampled by a stampede.

The Infinite Monkey Circus

The industry is currently obsessed with building the “harness.” Whether it’s Steve Yegge’s Gastown, the Agentic Flywheel, or the various frameworks designed to keep AI agents on track, we are all trying to build a better circus. I’ve spent the last few months immersed in these systems, writing about how they work and, more importantly, trying to use them to build.

The promise is intoxicating: an Infinite Monkey Circus where you are the Director. You provide the vision, and the agents provide the relentless, 24/7 labor. But here is the reality of being the Director: you are still the one holding the whip.

I’ve reached a point where I am running 3–4 parallel projects, each powered by a swarm of 4–5 agents. I am using the most sophisticated harnesses available to keep the monkeys performing, but I’ve inadvertently tied myself to the center pole. These agents provide incredible volume, but they demand a constant, high-intensity cognitive presence to stay on the tightrope.

I am no longer the “visionary architect” I set out to be; I am the AI Babysitter. I am a vital component in the system, providing the one thing the harnesses can’t yet automate: the “ground truth” and the sense of direction. Because the monkeys are so fast, the feedback loop is instantaneous. If I look away for even two minutes, the momentum stalls or the circus falls apart.

Cognitive Redlining

This brings me to the physical and mental cost: Cognitive Redlining. Steve Yegge describes this perfectly. Your brain is an engine built for a certain speed, but working with Claude Code is like redlining that engine at 9,000 RPM for twelve hours straight. You aren’t “coding” in the traditional sense; you are making high-stakes decisions every ten seconds.

The physical implications are wild. I find myself standing at my desk for hours at a time, afraid to sit down because the “payout” is always imminent. If I do step away to the couch, I’m rarely there for more than two minutes before the itch pulls me back.

Even my walks—the ultimate staple of the Deep Work lifestyle—have been ruined. I’m no longer “present.” I am mentally tethered to the terminal, hurriedly trying to get back because I know Claude is likely waiting to ask me a question. The “AI baby” is hungry, and I’m the only one who can feed it. By the time I finally disconnect, the crash is absolute. I wake up the next morning in a depleted state, my mental battery at 5% before the day has even begun.

The Instagramming of Work

This is where the behavior mirrors my struggle with Instagram, but with a devious twist.

We all know the “doom scroll.” You’re on Instagram, your thumb is moving, and the hours are vanishing. There is an inherent understanding in that moment: you have surrendered your mental energy to the vampire. It feels bad. You feel the “waste,” and that guilt is usually the only thing that eventually makes you put the phone away.

With Claude, the behavior is identical—the dopamine hits, the variable rewards, the inability to look away—but the guilt is gone.

I tell myself, “Hey, I’m working. I’m being a conscientious builder.” This is the Instagramming of Work. We’ve taken the addictive engineering of social media and dressed it up in a suit and tie. Because the output is “productive,” we have no internal defense mechanism. We are “Vibe Coding,” and as long as the progress looks fast, we ignore the fact that our cognitive sovereignty is being harvested.

What’s worse? Even when the “vibes” are rancid—when I’m struggling with a wrong implementation or an agent is hallucinating in a loop—I still can’t leave. I keep pulling the lever, desperate for the next hit of a working fix. I’ve reached a place where the reward of the “fix” is so good it overrides my physical need to rest.

The Final Warning

I reached a point where I realized my brain was legit fried by the end of every day. My solution, ironically, was more AI. I learned how to build a Director Claude agent—a harness aide designed to sit above the others and respond on my behalf. I thought if I could just automate the “Director” role, I could finally take that walk without looking over my shoulder.

It didn’t work. The Director agent still comes back to me “ever so often.” And in this high-velocity world, “ever so often” is enough to keep the tether tight.

To my fellow conscientious builders: we need to look at what we are actually building. If the price of a “10x” output is the total extraction of our mental and physical well-being, is it a fair trade?

I am still in the loop. I am writing this very post while Claude is running in another window, moving my product development forward. I literally couldn’t leave the desk to write about why I can’t leave the desk.

The “One Horse” of Deep Work hasn’t just been outpaced; it’s been turned into a ghost. We’ve entered the age of the AI Vampire, and the scariest part is that we invited him in because he promised to make us “productive.”

Put down the terminal. Take a walk. And if you can’t stay away for more than two minutes, you might want to ask yourself:

Who’s really running the circus?

I started this podcast series (Relevance—AI changed Work. How to stay relevant?) because of a series of private messages.

After I wrote about how AI was fundamentally changing the nature of coding, I saw a surge of people reaching out—not publicly, but in my DMs. They weren’t just curious about the tech; they were trying to figure out what these shifts meant for their own lives and careers. They were asking the same core question: How do I stay relevant?

The answer started to crystallize for me during a conversation in a college alumni group. My friend Jay described how he was using AI in his music production workflow.

Now, Jay isn’t an amateur “prompter.” He’s a Berklee-trained engineer and producer who has spent decades in the trenches of the music industry. He lives at the confluence of deep musical theory and high-end software engineering.

I, on the other hand, have been trying to learn the handpan the “old” way. It’s a tedious, manual journey of building muscle memory. When I saw Jay’s workflow, the gap between my manual effort and his exponential output was jarring. I realized I had no idea how far the ceiling had moved.

Music is the “canary in the coal mine” for all of us. Whether you are a coder, a writer, or a designer, the shift Jay is navigating in the studio is the same one coming for your desk. We are moving from a world where we are paid for technical execution to one where we are paid for creative direction.

The Mental Model: Autoregressive vs. Diffusion

To understand how to work with these tools, you have to understand the two different “engines” driving them. Jay broke this down in a way that makes sense for anyone who has used an LLM like Claude or ChatGPT.

1. Autoregressive Models (The Storyteller)

These are the models we are most familiar with in the text world. They work by predicting the next “token” based on everything that came before.

• In Music: This is great for structure and anticipation. It understands that after a certain chord, the human ear expects a specific resolution. It builds the “story” of the song linearly.

• The Flaw: Just like a “drunk teenager,” it can commit to a path and “hallucinate,” losing the plot if the context window gets too crowded.

2. Diffusion Models (The Sculptor)

This is the tech behind tools like Midjourney, now applied to sound.

• In Music: Imagine a block of marble (noise) that is slowly chipped away until a statue (a clean audio signal) remains. This is how AI creates texture and mood. It’s how you get that rich, “shimmering” sound of a nylon-string guitar.

• The Flaw: This process creates “denoising artifacts.” In AI images, it’s the “melted hands” effect; in music, it’s a slight digital blur or a loss of “crispness.”

When you understand these two engines, you stop looking at AI as a “black box.” You start seeing the seams. You realize that while the AI is incredible at generating probability (what sound usually comes next), it is still fundamentally missing human intentionality.

The “Missing Layer”: Why AI Can’t Create a Signature

If AI has access to the sum total of recorded music, why hasn’t it replaced the artist? Jay pointed out a fundamental gap: The lack of persistent musical memory.

1. The Amnesia Problem

Current AI models are incredible at the “now.” They can generate a breathtaking 30-second clip, but they struggle with thematic coherence. If you want to create a 10-song concept album where a subtle melodic motif returns in a different key during the climax—the way a composer like John Williams or a band like Pink Floyd does—the AI fails. It doesn’t remember the “soul” of the project once the session ends.

2. Probability vs. Intentionality

AI is a probabilistic engine. It chooses the most likely next note. But art is often about the unlikely choice. Jay shared a moment where he completely overrode the AI’s suggestion. The AI provided a mathematically “correct” resolution, but it felt sterile. Jay chose a “blemished” or unexpected chord that evoked the specific emotion he wanted.

“The question isn’t whether AI can make music. It’s whether it can make music that sounds like you.” — Jay Swami

The Shift: From Musician to “Latent Space Gardener”

If the AI is doing the execution, the human moves into a role that looks more like a Gardener.

In AI terms, “Latent Space” is the vast map of all possible sounds a model can create. As a creator, you are no longer building the seed from scratch; you are deciding which ones to plant, which ones to water, and—most importantly—which ones to prune.

• Curation as a High-Value Skill: When an AI can give you 100 variations of a melody in seconds, the person who can identify the one that actually resonates is the one who wins. Value is moving from scarcity of ability to quality of taste.

• The “Last Mile” Polish: The AI gets you 90% of the way there in 10% of the time. But that final 10%—the human “swing” in the drums or the specific EQ choice—is where the professional resides.

The Handpan Paradox: Why We Still Do the Hard Things

I asked Jay: Does he still find joy in this? When the “struggle” of technical execution is removed, is the satisfaction fleeting?

Jay sees his role like a CEO. A CEO doesn’t write every line of code, but they steer the ship. The satisfaction doesn’t come from the “grunt work”; it comes from seeing a multidimensional vision come to life.

Paradoxically, using AI hasn’t made Jay stop playing “real” instruments. It’s driven him back to them. Because the AI handles the “boilerplate” so quickly, he can focus his mental bandwidth on the parts that require a true human touch—the soulful guitar solo or the specific “blemish” that makes a track feel alive.

Final Thought: The New Bar for Relevance

The democratization of music is real. But as Jay reminded me, the question isn’t “Can AI make music?”

The question is: What kind of music requires you?

If your value was only in the “execution”—the ability to follow a formula—you are in trouble. But if your value is in your intent, your taste, and your persistent creative vision, then the ceiling for what you can build has just been removed.

Don’t be a “prompter.” Be a Gardener.

Watch the full conversation below to see Jay demonstrate his workflow and hear the live creation of a Punjabi-infused podcast theme.

The Two-Hour Regression

I recently spent four days doing the deep, quiet, and often lonely work of a founder: grooming a backlog. I was sharpening requirements, refactoring small pieces of technical debt, and getting my project ready for a massive push. It felt like I had laid the tracks perfectly. Every ticket was clear, every acceptance criterion was defined.

I decided to put my own “Agentic Engineering” thesis to the ultimate test. I handed that groomed backlog to six concurrent Claude agents.

For about two hours, it was magical. My screen was a blur of activity—terminal commands flying by, files being created, and “Done” markers appearing in rapid succession. The agents reported success with the absolute, unshakeable confidence that only a machine can muster.

I felt that brief, intoxicating rush of agentic velocity—the feeling that I had just compressed a week of high-intensity engineering into a single lunch break.

Then I opened the app.

It was a disaster. It wasn’t just that things were “buggy”—it was that the entire soul of the application had been mangled. Features I had already shipped, polished, and verified a week prior were now completely re-written in a way that made no sense. I had obsessed over the UI, spending hours on the “feel” and the responsiveness of the interface, and in just two hours, it had drastically regressed into a broken, generic mess.

The agents hadn’t just “done the work”; they had unilaterally decided to refactor functioning code into a broken state because it fit their local “reasoning” at that moment. I didn’t spend the next three days building new features; I spent them chasing regressions, untangling hallucinations, and acting as a high-priced triage nurse for a fleet of over-eager AI bots.

That was the moment I realized I was still thinking like a developer from six months ago. I was skimping on tests to “write them later” once the basic functionality was settled. Partly, I was worried about token costs—thinking I was being “economical.” But after seeing my UI shredded, I realized I could no longer afford not to verify.

In a world where the PRD is generated, the API is generated, the code is generated, and the tests are generated... how the hell do you know if any of it actually works?

The Shift: From “Vibe-Coding” to Agentic Engineering

We are currently transitioning out of the “Vibe-Coding” honeymoon. Vibe-coding is a seductive, low-friction loop. It’s that feeling when you ask a chatbot to “make me a landing page” and it works. It’s magic for a weekend project, but it fails the moment the system grows beyond a few files or requires a team (even a team of agents) to collaborate.

The Vibe-Coding SDLC:

Idea → Plan →Push (and hope the “vibe” is right).

As I’ve moved into serious building with agents, I’ve had to adopt a fundamentally different lifecycle—Agentic Engineering. It’s a disciplined SDLC that treats the agent as a high-throughput, probabilistic implementation engine that must be constrained by deterministic boundaries.

The Agentic Engineering SDLC (first pass):

Idea → Plan (Overview → Contracts & Specs) → Code → Tests →Push.

The next iteration loop:

Idea →Plan → Code →Verify Regressions →Push.

The critical phase in this new workflow is Sharpening Contracts & Specs. This is where the real engineering happens. You cannot let the agent touch a line of source code until you have forced it to define the API boundaries, the UI constraints, and the success criteria.

By “freezing” the contract before a single line of implementation is written, you create a deterministic cage for a probabilistic machine. If the agent generates code that doesn’t match the contract, the code is discarded. You aren’t just telling the agent what to build; you are telling it what it is forbidden to change.

Lessons from the Java Platform Days: The TCK Mindset

This reality check took me straight back to a formative era of my career in the Java organization at Sun Microsystems. When you are building a platform or a standard like JavaEE, you are essentially building a contract for a world you cannot control.

We were writing specifications that would be implemented by companies as diverse as IBM, BEA, Oracle, or open-source communities like JBoss. You couldn’t “trust” their implementation by default. You had to obsess over the Interface and the Verification. The JavaEE certification was the TCK (Technology Compatibility Kit)—a suite of 100,000+ tests that an implementation had to pass to be “certified.”

We didn’t write those tests because we were pedantic. We wrote them because when you have multiple parties (or multiple agents) building on a shared foundation, the contract and the test suite are the only things that prevent total chaos.

In 2026, the “other party” is an LLM—the ultimate “unpredictable implementer.” To build non-trivial systems today, we have to treat our own projects like a platform standard:

• Interface over Implementation: The “how” matters less than the “what.” As long as the contract remains unbroken, the agent can iterate.

• The TCK for your App: You need a suite of tests so rigorous that even if the agent refactors the entire backend, if it doesn’t pass the TCK, it doesn’t get shipped.

The Logistics of the Fleet: Worktree Explosion

This isn’t just a philosophical shift; it’s a logistical nightmare.

Right now, I’m coding with a fleet of 4 to 6 agents simultaneously. Each one of these agents spins up its own worktree. I have six concurrent worktrees, each with its own set of changes, each running its own test suite.

This is a “Director of Engineering” problem scaled down to a single person. I’m no longer a coder; I’m a Triage Director. I’m looking at 4x to 6x the test failures I’m used to. And when you see that many failures, the temptation to “vibes-check” them and move on is immense.

But every failed test in an agentic workflow is a “reasoning leak” that will cascade into the rest of your system.

If I scale this to 10s or 100s of agents—the Gastown horizon—the volume of verification noise becomes a vertical wall. The “human in the loop” can no longer monitor the output of the fleet without a radically different approach to verification.

The New P&L: Token Economics vs. CI Minutes

In traditional DevOps, we obsessed over CI minutes. In the agentic world, that equation has been turned upside down.

The bottleneck is now the Agent Re-contextualization Cost.

Every time a test fails, the agent doesn’t just “fix it.” It has to read the failure log, re-read the source, and re-evaluate the context of the system.

This “thinking time” (tokens) is a direct tax on your progress.

Paradoxically, AI has made test creation cheap, but it has made test execution (and reasoning) extremely expensive.

This is where my work as the ex-CEO of Launchable feels eerily relevant again. Years ago, we pitched Smart Test Selection to 500-person engineering teams.

Today, it’s a survival tool for the solo dev.

I cannot afford to run 100,000 tests on every agent iteration across 6 worktrees.

I need a “judgment layer” that says: “Based on these 4 files the agent changed, only run these 50 tests.” This preserves the token budget and keeps the velocity high without the regression tax.

The Death of the Pipeline Configurator

In my time at Launchable and CloudBees, I sat through thousands of calls where leaders were terrified of touching their YAML/CI pipelines for fear of impacting hundreds of devs. The pipeline was a “black box” of legacy fear.

In the agentic world, that fear has to die. The pipeline is a dynamic extension of the agent’s intent.

We are moving from Implementation to Intent.

I don’t debug deployments in a dashboard anymore.

I tell Claude: “Use the Railway API to pull the latest logs so you can analyze why the staging build is failing.” (not entirely there yet imho but it is a matter of a weeks if not months).

This is the future of Self-Healing Infrastructure.

If a build is slow, the agent proactively analyzes the bottleneck and pulls in tools to prune the test suite. We are moving from “Developer Experience” (DX) to “Agent Experience” (AX).

Conclusion: The Return of the Architect

We are in a brief moment where we are fascinated that the bear can dance. But as code generation becomes a commodity, its value will inevitably drop toward zero.

The value in software engineering is moving back to the Architect. The most important person in the room is no longer the one who can churn out the most lines of code; it’s the person who can define the contracts, sharpen the specifications, and build the verification fortress that keeps the agents in check.

As I manage my own fleet of agents today, I realize the most critical work I do isn’t “coding” in the traditional sense. It’s defining the TCK for my own vision.

Throughput without verification isn’t a superpower—it’s a liability. In the agentic age, the winners won’t be the ones with the fastest agents; they’ll be the ones who can verify those agents the fastest. It’s time to stop “vibing” and start engineering.

Section 1: The Seduction of Scale

I started playing with Claude Agent Teams about 10 days ago. Given my experience with the Agentic Flywheel System (ACFS), I was able to easily spin up 2-3 agents and solve for some tickets. The transition was smooth — the patterns I’d learned from ACFS (breaking work into tickets, coordinating parallel agents) translated directly.

Then I asked myself: Now that I understand this reasonably well, can I get to 5+ agents?

The natural thought was: if I can run 3 agents effectively, why not tackle a bigger surface area of the product? More agents means more parallelization. More parallelization means I can ship faster.

I spent 3 days trying. Claude kept losing itself designing the features. I’d explain the architecture, we’d make decisions, then two hours later we’d be re-explaining the same context. Design churn without progress. I’d answer the same clarifying questions over and over.

The problem wasn’t the agents. The problem was scope.

When you give Claude a large surface area to plan over, it gets lost. Multiple parallel agents working on loosely-coupled features means worry about overlaps, shared assumptions, integration points. Claude couldn’t hold all of it in context.

The key realization: the bottleneck falls back to planning. If the plan is too big, agents can’t execute on it—no matter how many you spin up.

After 3 days, I decided to fall back to my original 0.01 release steps. One meaty feature set per release. Claude doesn’t get confused when you box it this way.

Section 2: The Constraint That Unlocked Scale

After 3 days of struggle, I fell back to my original approach: micro-releases. Instead of 0.01 release cycles, I went tighter—0.005 release cycles. One meaty feature set per release. For example, v0.16a was building the MCP catalog. v0.16b was the next feature set. That’s it.

(side note: I move between v0.16a, v0.16b and v0.17a because I didn’t take some screenshots in v0.17a. The conclusion and message remains the same. At 0.16a/b I built with 3 (+1 director) agents. At 0v0.17a I built with 6 (+1 director agent). Appreciate your patience if this gets confusing because of versioning number)

The key insight wasn’t that agents stopped stepping on each other. They still do—you still have to worry about overlaps, shared files, integration points. That problem gets solved at a different level (dependency analysis, execution waves—more on that in the next section).

The real unlock was predictability. When you constrain the scope tightly, generating work becomes predictable. I could review 30 tickets for a micro-release and know: yes, this is on track.

The backlog makes sense. The dependencies are clear.

With a large surface area, I couldn’t even tell if the plan was coherent. Too many moving parts, too many assumptions that might not hold.

Think of this as “(micro-)Sprint on steroids.” Each micro-sprint is hyper-focused. When the box is that tight, you can go deep.

Claude doesn’t lose context because there’s less context to lose.

(side note: Going deep in a feature area is not only possible but a good practice in this new world)

By narrowing scope, I scaled from 3 agents to 6. The math on this release looked like this (that’s because of the scar tissue of the seduction of a bigger plan):

• 1-3 days: Backlog generation (PLAN.md, thinking through the feature set)

• 2-3 hours: Ticket breakdown with Beads (make tickets self-sufficient)

• 2-4 hours: Implementation (hands-off, agents execute)

The constraint didn’t eliminate complexity. It made the complexity manageable.

Section 3: The 6-Step Workflow

Here’s the process I use. I’ve scaled it to 6 agents running completely hands-off on a VPS.

Step 1: Micro-Releases (Scope Boxing)

I covered this in the previous section—0.005 release cycles, one meaty feature set per release (v0.16a = MCP catalog, v0.16b = next feature set). This is the foundation. Everything that follows builds on having a tightly constrained scope.

Step 2: PLAN.md → Beads Tickets

Once PLAN.md is ready (the high-level design for the micro-release), I ask Claude to create Beads tickets.

I’ve written before about Beads as AI-native issue tracking—structured tickets that become AI memory. That insight becomes critical at scale.

With 6 agents working in parallel, self-sufficient tickets aren’t just nice-to-have. They’re the only way to prevent agents from:

• Asking you the same question 6 different ways

• Losing context when they switch tickets

• Breaking each other’s assumptions

This workflow is heavily inspired by Jeffrey Emmanuel’s approach

—using structured issue tracking as the coordination layer for multi-agent work.

Step 3: Make Tickets Self-Sufficient

This is where the real work happens. I iterate with Claude to make each ticket completely self-contained. The test: a new session of Claude should be able to pick up any ticket and have everything required to implement it.

This is the memory of the system. If you get this right, your agents don’t forget.

Each ticket needs:

• Clear acceptance criteria

• Relevant context (what files to touch, what patterns to follow)

• Dependencies (what needs to be done first)

• Enough detail that an agent doesn’t need to ask you questions

Example: Before vs After

Before (vague):

joystream-2sd.1.1: Add MCP catalog endpoints
- Create API endpoints for MCP catalog
- Wire up to frontend

After (self-sufficient):

joystream-2sd.1.1: Add MCP catalog list endpoint

Context: Building the MCP catalog feature (v0.17a). This ticket adds
the backend API endpoint that the frontend catalog page will consume.

Acceptance Criteria:

- GET /api/mcp/catalog returns paginated list of MCP servers

- Response schema: { servers: [...], total: number, page: number }

- Supports query params: ?page=1&limit=20&search=github
Files to modify:

- backend/main.py - add route registration

- backend/routes/mcp.py - create new file with endpoint logic

- backend/models/mcp.py - use existing MCPServer model

Dependencies:

- Requires joystream-cxcx (database migration) to be complete

- Blocks joystream-2sd.3.3 (frontend catalog page)

Pattern to follow:

Follow the existing route pattern in backend/routes/skills.py

My contract with the system is Beads.

Claude Agent Teams has its own internal task list for tracking minutiae—I think of it like a secretary keeping track of the details.

But the Beads tickets are ground truth. When agents get confused, they come back to the Beads task list, not to me.

This step takes time. It’s the 2-3 hours in the breakdown phase. But it’s what makes hands-off execution possible.

Step 4: Parallelization Labeling

Once tickets are self-sufficient, I ask Claude to review them and identify what can run in parallel.

The labeling is straightforward: tag tickets with “backend”, “frontend”, “api”, “test”—whatever indicates the domain. This makes it easy to see which tickets have zero code overlap and can safely run simultaneously.

I also experimented with marking tickets by model tier: “Opus|Sonnet|Haiku”.

The idea was to assign straightforward scaffold work to Haiku and complex architectural work to Opus. I’m not sure if this actually worked—the model selection seemed to happen at the agent level, not the ticket level.

It’s on my list as the next experiment to validate.

But the domain labeling (backend/frontend/cli) definitely works. It gives Claude the signal it needs to understand the dependency structure.

Step 5: Determine Team Composition

Now I ask Claude:

Based on this backlog, how many agents are required to effectively parallelize the implementation?

Claude’s first answer: 8 agents. Too many for this release (my judgement).

I asked it to revise with constraints.

Second answer: 4 agents (backend, frontend, CLI, tester). Better.

Then I added two more:

• Director agent: Sits above the team, answers questions when agents are blocked

• Bug-hunter agent: Runs after implementation waves, sweeps for issues, creates new tickets

Final team: 6 agents.

The structure:

It’s not just about speed.

It’s about different kinds of work happening simultaneously. The backend agent owns the critical path. The CLI agent runs fully independent work. The frontend agent is blocked early, uses that time to study the codebase, then executes when unblocked. The tester waits for implementation to finish, then validates. The bug-hunter does a post-implementation QA sweep.

Step 6: Execution Waves

The final step: I ask Claude to analyze the dependency graph and decide execution waves.

• What runs in parallel?

• What’s sequential?

• What’s blocked?

Claude produces an execution plan showing which tickets can start immediately, which are blocked (and on what), and how many waves of work there are.

Here’s what that looked like for an earlier release (I seemed not have taken the snapshot for this release):

The director agent orchestrates a synchronized start. Each pane shows an agent receiving its mission brief and ticket queue. Backend starts immediately on the critical path. CLI runs fully independent work in parallel. Frontend is blocked early—it will study the codebase while waiting, then execute once backend completes the API registration.

Claude analyzes the 30-ticket backlog:

• 1 critical blocker blocks everything downstream

• 5 tickets actionable immediately once blocker clears

• 25 tickets waiting on dependencies

The dependency graph shows 6 waves. Claude identifies the backend agent’s serial chain as the bottleneck—everything else is either parallel (WAVE 1 tickets run simultaneously), downstream (frontend blocked until ~wave 5-6), or independent (CLI work finishes while others are still working).

The key insight: Claude figures out its own optimal set of agents for the ticket backlog

Claude identified that splitting the backend into “data model” and “fetcher” agents was theoretically possible but risky—they share `backend/models/mcp.py` with only 1 ticket between them in the dependency chain. Not worth the merge conflict risk.

This is what I mean by “solving overlaps at a different level.” The micro-release gives you predictable scope. The dependency analysis tells agents when they can work without stepping on each other.

Section 4: The Execution (Hands-Off Mode)

Once the team structure and execution waves are defined, I hand control to the director agent and walk away.

I run this on a VPS with --dangerously-skip-permissions (more on this in the gotchas section). The director agent sits at the top, fielding questions from the other agents.

When an agent hits a blocker—“Should I use pattern X or Y?”—it asks the director. The director responds based on AGENTS.md context and project rules. The agent unblocks and continues.

This is true hands-off mode. I come back 2-4 hours later.

The result: a built release. The backend agent completed its critical path. The CLI agent finished its independent work. The frontend agent executed once unblocked. The tester validated. The bug-hunter swept for issues.

The Regression Issue

From here on, I will talk about the next release v0.17a

v0.16a & v0.16b flew threw seamlessly. For the v0.17a, I spent 2 days fixing regression bugs after the 2-hour implementation run. Integration bugs slipped through—because Claude changed the implementation of the MCP catalog even though, we weren’t coding it in the release (this was a shocker).

But this wasn’t inherent to the multi-agent approach.

It was because I haven’t been diligent enough about writing tests.

With proper test coverage—backend tests, frontend tests, integration tests—this can be entirely eliminated.

Landing the Plane Protocol

After all agents finish, the landing pattern (from Steve Yegge. Written in AGENTS.md) is:

• Run backend tests (linters, type checks, unit tests)

• Run frontend tests (ESLint, TypeScript checks, build validation)

• Run integration tests (end-to-end flows)

• Sync Beads tickets to the central repository (`br sync --flush-only`)

• Commit and push

The task list state + git state must stay in sync. Otherwise you lose track of what’s actually done vs what’s committed.

The Math

For v0.17a (with the 3-day struggle and lacking tests):

• 1-3 days: Backlog generation (including the struggle before I constrained scope)

• 2-3 hours: Ticket breakdown with Beads

• 2-4 hours: Implementation (hands-off)

• 2 days: Regression bug fixes

The ideal math for the next release (with better test coverage):

• 1 day: Backlog planning

• 1 day: Implementation (including hands-off execution and landing)

Section 5: Comparison to Agentic Flywheel (ACFS)

Influence & Credit

I’d like to think Claude Agent Teams (I don’t know anybody there — if someone reads this, I’d love to meet you for coffee. I’m a fan) is clearly influenced by Jeffrey Emmanuel’s work. Agent communication patterns like agent naming come from Agent Inbox. But where Jeffrey had to stitch this on top of Claude, Anthropic built it in.

Communication: Hidden vs Visible

With Agent Teams, the communication is completely hidden from you Which is a blessing and a curse. (you can go and tail the log files but they are too complex to make sense; better idea is to ask Claude delegate (director) to give you updates).

It was super cool in Agentic Flywheel to see agents emailing each other. You could watch the coordination happen. In Claude Teams, it just works—automatic message delivery, no inbox management—but you don’t see the wires.

Both systems are hands-off. Just different types of agent-to-agent communication.

Tooling Differences

ACFS has some advantages:

• File locking: Prevents agents from stepping on each other’s work (Jeffrey doesn’t like git worktrees, so this was his solution)

• Multi-model support: `--cc=2 --cod=2 --gemini=2` = 6 agents across 3 model families. You can mix Claude Code, Codex 5.3, Gemini 3.1. Not locked into one model.

• Cockpit view (NTM): See all agent panes, agent inbox, ticket assignments in one interface

Claude Teams advantages:

• Easier setup: ACFS takes ~2 days to get right. Claude Teams works out of the box.

• Built-in coordination: No stitching required

• Lower cognitive overhead: Less to manage

Recommendation

Start with Claude Code and graduate. If you need multi-model support or want the cockpit view, invest the 2 days in ACFS setup. But for most use cases, Claude Teams’ ease-of-use wins.

The Team Abstraction

One thought: Breaking agents into “work teams” (backend team, frontend team, etc.) is a natural way to think. It maps to how we organize human work today.

But does it actually matter in the long run that my agents were in these logical units? I don’t think so.

The coordination happens through the task list and dependency graph, not the team structure itself. The “team” abstraction is for humans to reason about the work, not for the agents.

Section 6: The Real Bottleneck

The bottleneck isn’t implementation time. It’s backlog quality.

If your tickets are self-sufficient—clear acceptance criteria, relevant context, explicit dependencies—agents don’t need you. They read the ticket, understand what to build, and execute.

If your tickets are vague or incomplete, agents get stuck. They ask questions. You become the blocker.

This is why the ticket breakdown phase (Step 3 in the workflow) takes time.

You’re not just creating tickets. You’re creating the distributed memory of the system.

Each ticket is a packet of context that an agent can pick up cold and run with.

The New Ratio for team throughput

The traditional equation is simple:

1 PM supports N engineers.

With agent teams, the equation has three variables:

x PMs : 1 human engineer : z agents

The human engineer becomes the orchestrator. They translate PM requirements into self-sufficient tickets, then manage a fleet of agents executing in parallel.

The more agents you can effectively manage (the higher z), the more PM throughput you can support (the higher x). If I can run 6 agents and deliver a feature in 1-2 days, I can support more product surface area than a traditional 1:1 PM-to-engineer model.

My conviction: we’re moving toward 1-2 PMs per human engineer, with the engineer managing 5-10 agents.

The leverage isn’t in the number of agents alone—it’s in the engineer’s ability to create high-quality backlogs that agents can execute autonomously.

Section 7: Gotchas & Lessons

Tmux Panes Don’t Auto-Start

For a few iterations, I couldn’t get Claude Code to run in independent panes. I’m on iTerm, thought I did things right. I have Tmux on both my Mac and VPS. I figured Claude would automatically start Tmux and I’d see panes like ACFS’s cockpit (NTM) where you start agents and see everything.

It doesn’t. You have to start Tmux FIRST, then start Claude in there. Not a biggie.

No Agent History Tracking

Claude doesn’t keep history of how many agents were used or what they did. I thought for this blog I’d just ask Claude for the information—was disappointed to find it hadn’t tracked this. This is why you see me talk about different release and corresponding images.

As agent teams become more common, this will be a frequent ask.

In ACFS I can go to Agent Inbox and see what tickets were picked up by what agent. Claude Teams doesn’t have this yet.

Running `--dangerously-skip-permissions`

I run this on a VPS because I really wanted to see if I can go hands-off. Don’t do this on your local machine.

This was my first time running it. I have confidence because I use tools from ACFS like `dcg` (destructive command guard)—it acts as a guardrail. Anytime a destructive operation is about to happen, it explicitly denies it.

The director agent handles minor asks and unblocks agents. But the guard prevents disasters. Without it, `--dangerously-skip-permissions` is exactly what it sounds like: dangerous.

Section 8: Conclusion

This post documents using a different harness from ACFS. My muscle improved —I moved from 3-4 agents to 6 agents running hands-off.

In Steve Yegge’s framing of agentic engineering systems, I moved up the scale. Not just in agent count, but in the ability to delegate complex work and walk away.

The Takeaways

• Scaling agents requires constraining scope. Micro-releases (0.005 release cycles) make planning predictable. Claude doesn’t get lost when the box is tight.

• Self-sufficient tickets are the foundation. They’re the distributed memory of the system. If tickets are good, agents don’t need you.

• Hands-off mode is achievable. Director agent + quality backlog + execution waves = you come back 2-4 hours later to a built release.

• The bottleneck is backlog generation, not implementation. The new ratio is x PMs : 1 human engineer : z agents. The more agents you can manage, the more PM throughput you can support.

Getting Started: The Progression Path

Don’t start with 6 agents. Start with 2.

Stage 1: Prove the workflow (2 agents)

• Pick a small micro-release (~10 tickets)

• Backend + Frontend agents (or Backend + CLI if simpler)

• Focus on making tickets self-sufficient

• Goal: Complete one release hands-off without asking questions

Stage 2: Add specialization (3-4 agents)

• Add a Tester agent

• Introduce dependency waves (some work blocks other work)

Goal: Agents handle blocked states without your intervention

Stage 3: Scale complexity (5-6 agents)

• Add Director agent (you’re no longer the question-answerer)

• Add Bug-hunter for post-implementation sweep

Goal: Come back 2-4 hours later to a landed release

When to scale up: When agents stop asking you questions. If you’re still the blocker at 2 agents, adding more won’t help. Fix the backlog quality first.

The Real Unlock

The real unlock wasn’t the 6 agents. It was the discipline: tight scope, self-sufficient tickets, dependency-aware execution.

Get that right, and the agents scale themselves.

Quick Reference: The 6-Step Checklist

Pre-Work (1-3 days):

• [ ] Write PLAN.md for micro-release (one meaty feature, 0.005 cycle)

• [ ] Ask Claude: “Create Beads tickets from this PLAN.md”

• [ ] Iterate on tickets until self-sufficient (test: can cold agent execute?)

Preparation (2-3 hours):

• [ ] Label tickets by domain (backend/frontend/cli/test)

• [ ] Ask Claude: “How many agents needed to parallelize?”

• [ ] Negotiate team size, add director + bug-hunter

• [ ] Ask Claude: “Analyze dependency graph, create execution waves”

Execution (2-4 hours, hands-off):

• [ ] Start Tmux, spawn agents in separate panes

• [ ] Hand control to director agent

• [ ] Walk away

Landing:

• [ ] Run quality gates (backend tests, frontend tests, integration)

• [ ] beads_rust ticket sync`br sync --flush-only`

• [ ] commit code

Key Prompts:

• “Make this ticket self-sufficient so a new Claude session can execute it”

• “Review these tickets and identify what can run in parallel”

• “Based on this backlog, how many agents are required?”

• “Analyze the dependency graph and create execution waves”
  
  Side note: It took me less time to implement the backlog than having to reformat my markdown because Substack doesn’t support markdown. What a world we live in now!

I’m not a data scientist—though I’m not a stranger to the work.

As founder and co-CEO of Launchable, an AI company, I watched my team build data pipelines from 2019 onward. I understood the architecture. I could review the output. But I’d never taken an entire project end-to-end myself—from the questions to the pipeline to the results. There was always a team to explain my vision to, and then wait for them to implement it.

This weekend, for the first time, I didn’t need that team. That was genuinely empowering.

The project: computationally analyzing the Guru Granth Sahib—the central scripture of the Sikhs, 1,430 pages, 60,629 lines, six languages woven into Gurmukhi script. I’d wanted to do this since my early 20s. I don’t read Punjabi fluently, and the interpretation of this text had always been outsourced to clerics.

That felt like being illiterate.

The open source piece is personal. I’ve lived in OSS for most of my career -- five to six years in GlassFish, twelve years in Jenkins, building an enterprise business (CloudBees.com) on top of it. But every one of those projects was someone else’s vision that I contributed to.

This is the first piece of work I conceived, built, and shipped myself. The entire GGS is now available as structured JSONL—every line tagged, every entity traced to its source page.

Anyone can query it.

And the agent orchestration connects to something I’ve written about before— the Agent Flywheel System. This week I tried Claude’s new agent teams harness (which, honestly, feels like they were heavily inspired by Agent Flywheel System). Four agents, dependency graphs, execution waves.

The analysis I’d dreamed about for two decades became a weekend project because the AI stack finally caught up.

The AI Architecture: Three Roles

The project used three distinct AI roles, each doing a different kind of cognitive work.

ChatGPT was the product manager.

I spent hours in dialogue designing the analytical framework—not “write me code,” but “what are the right layers of analysis for a sacred text?”

That conversation evolved through multiple iterations:

• From naive word counting, to the critical insight that lexical frequency and theological reference are different questions (”the token ਰਾਮ (Ram) appears 2,019 times” is not the same claim as “the Hindu deity Rama is referenced 2,019 times”)

• To a three-layer architecture—Lexical, Structural, Interpretive —with explicit guardrails like “never collapse layers in reporting.”

The PRD that came out of this dialogue was 1,169 lines of serious engineering: data contracts, schema validation, normalization pipelines, error models.

Claude Code was the engineer.

It built the entire pipeline:

• Aho-Corasick multi-pattern matching against 346 Gurmukhi spelling variants,

• 11-dimensional feature vectors per line,

• PMI co-occurrence analysis,

• author profiling.

• 733 tests passing.

The methodology itself —density scoring over boolean presence, PMI over raw co-occurrence, exact string matching over embeddings was recommended by Claude.

It chose Aho-Corasick because with 346 patterns against 60,000 lines, regex would be O(patterns x text) while Aho-Corasick scans once. The full pipeline runs in under four seconds.

I was the domain expert

I was the domain expert. I built the 124-entity lexicon with 346 spelling variants across 11 theological dimensions. I decided what “nirgun (formless)” means, which entities matter, how to classify registers.

I ran 10 iterations of planning with ChatGPT and Claude, ensuring my biases were weeded out—kudos to ChatGPT, it flagged biased questions.

The pipeline has no opinions.

The lexicon doesn’t. And the lexicon is entirely human.

The Agent Team

When it came time to execute, I didn’t want one agent doing everything sequentially. This was a weekend project after all—I wanted to experiment with Claude Agent Teams and importantly wrap it up as quickly as I could.

I asked Claude to spawn agents. It analyzed the task graph (from Beads) and recommended 6 agents, noting that 8 would be a stretch. I ended up running 4—I could clearly see that a couple of agents would write to the same files, and unlike the Agent Flywheel System which has filesystem locking, here I needed to worry about that myself.

The tickets themselves were generated using beads_rust (a variant of Beads), a project tracker that gives me a dependency graph (I’ve written about this before).

At this point, this workflow works well for me that handing it to opaque task management inside Claude doesn’t feel right.

I want to see the graph. I want to own the structure—just because I trust Beads to do its job well. Claude reviewed these tickets and built the dependency waves: which tasks can run in parallel, which are blocked, which agent gets which track.

Each agent got its own track, its own ticket queue ordered by dependency, its own prompt file.

The backend agent was busy the entire time on the critical path. The CLI agent started immediately—zero shared dependencies—finished early, and picked up test tickets.

The frontend agent was blocked until upstream work finished, so it studied the codebase while waiting, then ran its serial chain.

All agents committed to the same branch. Git pull/push handled merges. Quality gates after every ticket.

This is the Agent Flywheel System in practice—natively supported by Claude Agent Teams.

The human defines the work and the structure.

The AI analyzes the dependency graph, recommends team size, and executes. The coordination protocol—who’s blocked, who picks up slack, when to start the downstream agent—came from Claude, not from me.

I was the architect. Claude was the general contractor running the crew.

The Irreducible Human

Here’s what AI couldn’t do: decide what questions to ask.

The entire project hangs on a 124-entity lexicon—346 spelling variants in Gurmukhi, organized across 11 theological dimensions:

nirgun (formless/non-dual), sanskritic, devotional, ethical, oneness, ritual, cleric, sagun (form/dual) narrative, scriptural, Perso-Arabic, identity.

Every entity, every dimension, every classification is domain knowledge.

No model has that for the project.

I had to know that SAHIB (ਸਾਹਿਬ) isn’t Perso-Arabic in the GGS context, even though it’s etymologically Persian. That single reclassification dropped the Perso-Arabic register from 0.73% to 0.29%. The lexicon is the most valuable artifact in the project, not the pipeline.

The bias control was the hardest work. I came in with hypotheses—everyone does when they care about a text. I ran 10 iterations of planning with ChatGPT and Claude, ensuring my biases were weeded out. Kudos to ChatGPT—it flagged biased questions.

But ultimately, the discipline of checking and rechecking was mine to maintain.

The pipeline has no opinions. The lexicon does. And if your lexicon is biased, your results are biased.

No amount of engineering rigor fixes a loaded question.

This is the punchline for anyone thinking about using AI for serious analytical work:

The engineering, the project management, the parallelization, the testing—all compressed into a weekend.

But the questions you ask, the categories you choose, the biases you catch—that’s still entirely you. And that’s the part that matters most.

What the data showed: Formless wrapped in a love poem

The pipeline worked. 60,012 entity matches across 60,629 lines—57.3% of the text lit up. The headline: 42.25% of all lines contain nirgun (formless divine) vocabulary. Nearly half the text is about a nameless, formless reality.

Add the oneness markers and it’s 44.25% Advaita-adjacent. The Gurus were talking about non-dual philosophy—the field, the formless—before it became an Instagram trend.

What was amazing for me, was Non-dual philosophy is intellectual, the Gurus wrapped into a love poem. Which is genuinely unique perspective.

The surprises were real (for me—not my parents :-)). HARI (a name for Lord Vishnu/Krishna) appears 55 times for every 1 occurrence of WAHEGURU.

Modern Sikh practice centers on Waheguru, but the text itself speaks a different lexical language. RAM, which appears 2,019 times, behaves statistically as a synonym for the formless divine, not as a reference to the Ramayana hero -- its co-occurrence neighborhood is indistinguishable from HARI’s.

And HINDU and TURK (Muslims referenced by the ethnicity of the Turkish invaders) have the highest statistical association in the entire corpus.

The central message of Sikhism is that all humans are equal and whenever the text references Hindu and Turk, it names them together to make the point that they are not different.

I wrote the full findings in a separate post—13 findings, per-author profiles, the Stoic-Bhakti-Advaita triangle, the civilizational vocabulary ratio (99.9:1 Sanatan (Hinduism) to Islamic).

But the point for this audience isn’t the theology.

It’s that a domain expert with an AI stack produced findings that are reproducible, auditable, and traceable to specific Gurmukhi lines.

Every number links to a source. The repo is open. File a bug.

The Takeaway

Here’s the reusable framework.

1. Step one: use ChatGPT to design the what—the questions, the methodology, the architecture. Push back on yourself. Let the AI challenge your framing.

2. Step two: use Claude Code to build the how—the pipeline, the tests, the engineering. Let it recommend the methodology.

3. Step three: when the task graph gets big enough, spawn Claude Agent Teams —define the dependency waves, let agents run parallel tracks.

And throughout: you are the domain expert. You own the lexicon. You own the bias control. You own the interpretation.

This project was maybe 70% thinking—what questions to ask, what entities to track, what dimensions capture the theology, what claims the data can support— and 30% building.

AI inverted that ratio from what it would have been five years ago. The building used to be the bottleneck. Now the thinking is. And it should be.

Links:

• GitHub Repository

• Analysis Post

I. The Problem That Led Me Here

Over the last six weeks, I’ve been posting about my journey with agentic coding. I’m in exploration mode—figuring out what’s actually required to build software now that coding agents like Claude have evolved significantly since December. It became clear to me that the future isn’t single-agent assistance. It’s agent fleets.

I’d read Steve Yegge’s piece on GasTown, which laid out a scale from basic AI assistance to full autonomous development. I realized I was at stage 6—barely. Not in YOLO mode, but aligned with where he was headed. I reached out. He asked me to hold off while bugs settled. There’s a thriving community there, but it’s still early days. Then I came across Jeffrey Emanuel’s work with the Agentic Flywheel System.

What caught my attention wasn’t just the claim of running 31 projects in parallel. It was his thoughtful approach to PM-ing and architecting. This wasn’t YOLO mode. This was a system built for quality code with proper coordination.

I decided to test it on my current project—a real production system I’m calling JoyStream for now. Not a toy app. Not a demo. A system with actual architecture constraints, API integrations, and consequences for getting it wrong.

Three agents. Four hours. They cleared my entire sprint backlog.

What changed wasn’t just the coding speed—that’s been improving for months. What changed was the rapid compression of the PM-to-spec-to-code cycle. The work shifted almost entirely to specification and architecture upfront. Here’s what I learned running my first agent fleet.

II. What Is the Agentic Flywheel System?

The Agentic Flywheel isn’t another AI coding tool. It’s infrastructure for running agent fleets.

Jeffrey’s philosophy mirrors the Unix approach: small, composable tools that pipe together. Instead of one monolithic “AI developer,” you get 20+ specialized utilities that coordinate through well-defined interfaces. Each tool does one thing well. Together, they create a compounding loop.

The Core Loop:

1. Plan (Beads + bv (beads viewer)) - Graph-aware task management with dependencies; bv provides the terminal UI for viewing and triaging

2. Coordinate (Agent Mail) - Multi-agent messaging and file reservations

3. Execute (NTM + Agents) - Terminal orchestration across Claude, Codex, Gemini

4. Remember (CASS Memory) - Session search and procedural memory

5. Scan (UBS) - Code quality guardrails before commit

Each cycle improves the next. CASS remembers what worked. Memory distills patterns. UBS catches more issues. Agents coordinate better through Agent Mail.

The system includes 20+ tools beyond the core loop: DCG for pre-execution safety, RU for multi-repo management, SRPS for system protection under agent load, and more. The full stack is documented at agent-flywheel.com/learn.

Where I Am:

I haven’t graduated to using the entire system. Like learning Linux commands, I’ve piped together the four basic core tools—Beads, Agent Mail, NTM, and my agents—and that works well enough. I’ll add others as I get better at this.

The Key Distinction:

This sits between solo Claude Code usage and full autonomous systems like GasTown. With GasTown’s vision, code gets generated and you trust the output. With Agentic Flywheel, you maintain control through heavy upfront specification and coordinated execution. The scale is manageable: 3-20 agents instead of fully autonomous fleets.

I’m staying at this level. The infrastructure supports scaling to dozens of agents, but the real power is in the coordination harness—not just raw agent count.

III. Agent Engineering = Vibe-Specing = Vibe-PMing + Vibe-Architecting

I’ve been calling this shift “Vibe-PMing” and “Vibe-Architecting”—though Andrej Karpathy recently coined “agent engineering,” which is probably the term that’ll stick. They’re the same thing: the new skill of specification work that makes agent fleets possible.

The Bottleneck Has Moved

AI has revealed product management as the new constraint in software development. When Claude can write a thousand lines of correct code in minutes, the blocker isn’t engineering capacity anymore. It’s specification quality.

Traditional PM-to-engineer handoffs had built-in error correction. You’d sketch requirements, engineers would ask clarifying questions, you’d iterate through implementation. Humans are good at filling gaps and making reasonable assumptions.

Agents don’t work that way. They execute what you specify. The work now happens entirely upfront, before any agent touches code.

Multi-Shot Specification: Sense-making Through Iteration

This isn’t one-shot prompting. It’s structured iteration across models to refine intent into executable architecture.

My process:

1. Start with loose intent - Rough problem statement, no implementation details

2. Iterate with one model (Claude) - 4-5 rounds of refinement, tightening the specification each time

3. Take it to another model (Codex) - Fresh perspective catches assumptions and gaps. I found Claude → Codex worked better than adding Gemini to the chain, though that’s worth exploring separately

4. Return to original model - Synthesize insights, finalize the approach

5. Generate architecture - Multiple iterations here. Get the structure right

6. Create Beads tickets - Iterate until each ticket is self-contained and executable without additional context

That last step is critical. Each ticket needs enough detail that an agent can execute independently, without needing clarification or shared context with other agents.

The PM-Architecture Feedback Loop

Working solo on this, I realized something: PM-specing and architecture weren’t sequential phases. They were rapid, interleaved loops feeding each other. A specification question would surface an architecture constraint. An architecture decision would reveal missing product requirements. Back and forth, getting tighter each cycle.

My engineering background helped here. I could push models to justify their design choices, and often they were making suboptimal trade-offs. They’d suggest patterns that looked reasonable but wouldn’t scale, or architectures that created unnecessary coupling. The ability to evaluate those proposals critically—to know when the model was wrong—mattered.

What This Means for Teams

The implication: we’re heading toward a 1:1 or 1:2 PM-to-engineer ratio. Maybe it flips entirely—2-3 PMs for every engineer. The bottleneck is no longer “who can write the code?” It’s “who can think through what needs to be built and specify it clearly enough that agents can execute?”

Why I Didn’t Hit Collisions

I followed Jeffrey Emanuel’s patterns. There’s a reason he’s running 31 projects simultaneously—the coordination infrastructure works when you do the specification work properly. Agents didn’t collide because the upfront Vibe-Specing made collisions impossible.

The shift from “vibe coding” (iterative collaboration with an agent) to “Vibe-Specing” (multi-shot refinement before execution) is where the real work happens now. You’re not just writing tickets. You’re creating an execution environment where agents can operate independently.

This is the new skill.

IV. Installation Reality Check

The Agentic Flywheel System comes with ACFS (Agentic Coding Flywheel System)—an opinionated installer that sets up the full stack. When it works, it’s fantastic. When you hit issues, you’re debugging infrastructure you don’t fully understand yet.

VPS Requirements

You need horsepower. Jeffrey runs this on serious VPS instances because agent fleets consume resources. I went with a mid-tier VPS—enough to run 3-5 agents comfortably. If you’re planning to scale to 10-20 agents, provision accordingly.

The Opinionated Stack

ACFS installs everything: zsh with p10k theme, tmux configuration, git setup, all the flywheel tools. It’s comprehensive. Run the installer and it handles package management, shell configuration, even your terminal aesthetics.

The trade-off: when something breaks, you’re deep in configuration files you didn’t write. I spent time learning zsh after years of bash, reacquainting myself with tmux after a 15-year hiatus since my Sun Microsystems days, and understanding how p10k customizes the prompt.

Time Investment

Plan for 2-3 days from zero to your first successful flywheel run. That includes:

• VPS setup and Tailscale configuration

• ACFS installation

• Learning the shell environment

• Understanding tmux session management

• Debugging your first agent coordination issues

This isn’t a “install and go” system. It’s infrastructure. You’re building the environment that makes agent fleets possible.

V. The Setup Gauntlet: Getting Agents Coordinated

Getting the tools installed is one thing. Getting them to coordinate is another. Here’s what I learned setting up the core coordination stack.

A. Beads: Task Management as Agent Memory

Beads is git-native issue tracking with dependency graphs. Unlike Jira or Linear, Beads stores everything as git objects. This means agents can read task history, understand dependencies, and coordinate work through the same git operations they already use.

What Beads Does:

• Stores issues and tasks as git objects

• Tracks dependencies between tickets

• Provides structured metadata agents can parse

• Terminal and web UI options for viewing and triaging

The Compatibility Decision

I’d been using Beads and was getting comfortable with it. I was specifically using beads_ui—part of the thriving Beads community—which provides a web interface.

Then I saw Jeffrey had created beads_rust, a fork moving in a different direction from the original Beads. This should’ve been simple, but the databases are no longer compatible. He built bv, a terminal UI for beads_rust. It’s nice, but I prefer web UIs.

The original Beads has a beads-sync repo pattern where all tickets sync to a dedicated repository. I loved this. Beads_rust documentation says it supports this, but looking at the codebase, it’s not implemented yet.

For this project, I chose to go the opinionated way: beads_rust and bv. If you want to experience the full system as Jeffrey designed it, this is the path.

The Good News

Coding happens so fast with agent fleets that tickets are like filling a leaky bucket—they empty quickly in micro-versions (0.01, 0.02, 0.03). If I wanted to switch back to the original Beads, I could at any point. The velocity makes tool choices less permanent for a solo developer.

The Robot-Triage Pattern

The key command: bv --robot-triage

This outputs deterministic, parseable ticket data that agents can consume. It handles:

• Identifying parallelizable work

• Flagging dependencies

• Showing what’s ready to execute

Once you have tickets properly structured, --robot-triage becomes the interface between your planning and agent execution.

B. Agent Mail: The Coordination Layer

Agent Mail is what makes multi-agent coordination possible. It’s not just messaging—it’s the coordination protocol.

Why File Locking Alone Isn’t Enough

Git provides some conflict detection, but it’s reactive. By the time git catches a merge conflict, two agents have already done incompatible work. Agent Mail provides proactive coordination through file reservations.

The Three-Layer Protection:

1. Beads structure - Tasks are decomposed to minimize overlap

2. File locks - Agents reserve files before editing

3. Agent Mail - Agents communicate what they’re working on

This triple redundancy meant I never hit file conflicts during execution.

Setup Challenge: The .claude.json Nightmare

This took me 3 days to debug. Agent Mail runs as an MCP server. Claude Code connects to it via HTTP.

Claude Code uses two configuration files:

• ~/.claude/settings.json - User-editable settings

• ~/.claude.json - Runtime cache

I updated settings.json with the correct Agent Mail endpoint and bearer token. Restarted Claude. Nothing. The MCP server showed as “failed.”

Debug logs showed Claude was hitting the wrong endpoint. The cache file had stale configuration—wrong URL, wrong token, and the server marked as disabled for my project.

The fix: manually edit .claude.json to match settings.json. Restart Claude. It worked.

Lesson: Always check both config files when debugging MCP connections.

Remote UI Access

Agent Mail has a web UI for viewing messages and agent activity—essential for monitoring what agents are doing. I set up Nginx as a reverse proxy on my Tailscale network so I could access the UI from my Mac while the server ran on the VPS. Nginx injects the bearer token, giving me auth-free browser access while Claude connects directly for low latency. It took me a few iterations to figure this out.

C. NTM: The Cockpit

NTM (New Terminal Multiplexer) is your command center for orchestrating agents. Think of it as tmux with agent-aware features.

Multi-Pane Orchestration

You spawn agents in separate panes, each running different models. With a single command, you can create multiple Claude Code sessions or Codex sessions—each in its own tmux pane. You can watch them all simultaneously, seeing exactly what each agent is doing in real time.

The --pane Option

Here’s the power move: assign agents to specific work using labels.

Beads tickets have labels. Agents filter by label. You’ve just parallelized your workflow across agent specializations.

Why This Matters

Gemini might be better at documentation. Claude excels at backend logic. Codex handles certain patterns well. The --pane option lets you route work to the right model.

I haven’t fully explored this yet—I’m still running primarily Claude. But the infrastructure supports heterogeneous agent fleets, and that’s the direction I’m heading.

D. The Missing Piece: AGENTS.md

Here’s what cost me half a day: I had all the tools installed and configured, but the agents weren’t coordinating properly. The engine wouldn’t fire.

The problem: I was missing the AGENTS.md file with the Agent Specific Flywheel components. Not because of oversight, I had this file in a different directory and was referencing it in AGENTS.md but Claude would not follow the link and read it.

AGENTS.md is the bootstrap protocol that ties everything together. It tells agents:

• How to use Agent Mail for coordination

• Where to find Beads tickets with bv --robot-triage

• What labels they should filter on

• File reservation protocols

• When to send status updates

Without this ACFS entries, agents don’t know they’re supposed to coordinate. They run independently, unaware of the coordination infrastructure you’ve built.

I had to go through Jeffrey’s projects to understand the right structure. Once I had AGENTS.md in place, everything clicked. Agents registered with Agent Mail, checked for tickets, reserved files, and communicated status.

Critical: The AGENTS.md with ACFS related changes are not optional. It’s the coordination contract.

VI. The Flywheel in Motion: What Actually Happened

Once the infrastructure was in place and AGENTS.md was configured, I spawned my first fleet. Three Claude agents. One project. Here’s what happened.

A. Spawning the Fleet

I started conservative—three agents instead of pushing for higher numbers immediately (I did try with one agent first to run through some tickets).

NTM created three tmux panes, each running a Claude Code session. The agents registered with Agent Mail, pulling whimsical names from the system: BlueLake, GreenCastle, RedStone. The naming is automatic—adjective plus noun combinations.

Watching them register was surreal. These weren’t just terminal sessions. They were coordinated entities with identity, checking in with the coordination server.

B. Execution Observations

Agents Picking Tickets

The first agent checked the robot-triage output, saw available tickets, and sent a message to Agent Mail: “I’m taking backend-auth-123.”

The second agent did the same moments later, picked a different ticket—something marked frontend—and claimed it.

The third agent grabbed documentation work.

No conflicts. No duplication. The coordination layer worked exactly as designed.

Speed

Four hours. That’s how long it took three agents to empty my backlog.

These were real tasks—API endpoint implementation, database schema updates, frontend component work. Not trivial tickets. The kind of work that would’ve taken my old team a full sprint.

The NTM Cockpit

The fact that I could send messages to all agents from a central cockpit was fantastic. No jumping between agent sessions. One command from NTM, broadcast to the fleet.

This changed everything about coordination overhead.

The Forgetting Problem

Agents kept forgetting to update Agent Mail. They’d pick a ticket, start work, and go silent. I’d send a broadcast from NTM: “Hey, update others on email.”

They’d acknowledge, send an update, then forget again ten minutes later.

I’d follow up: “Hey, did you do a review before committing?”

It felt strange at first—talking to agents like they were humans. Jeffrey mentions this too. The language is conversational, not command-line syntax. “Update others” not “execute status_update protocol.”

After the third reminder, I thought: “I want to automate this too.”

That realization hit hard. I’d gone from amazed that agents could coordinate at all to impatient that they needed reminders. The baseline shifted fast.

C. The Emotional Shift

From Fascination to Impatience

Week one: “This is incredible—agents are talking to each other!”

Week two: “Why do I have to keep reminding them to send status updates?”

The trust/action boundary moved quickly. Tasks I was carefully monitoring in the first session became background work by the third session.

Different, Not Better or Worse

Managing agent fleets isn’t like managing human teams. Humans remember context, anticipate problems, and communicate proactively. Agents execute what you specify and forget protocols unless reminded.

It’s not better or worse. It’s different. You trade human intuition for perfect execution of specification. The skill is knowing what to specify and how much supervision the work requires.

Claude Agent Teams: The Pattern Recognition

A number of these patterns have been adopted by Claude Agent Teams. The Delegate pattern—where the starting Claude can send messages to others—is like NTM. Agents exchanging messages mirrors Agent Mail, though you can’t see what they’re saying in human-parseable form. Just verbose logs in agent-specific directories. The internal task distribution resembles Beads, except you have no control over it.

Jeffrey is on the leading edge here. More of his patterns will be picked up by Claude and other agent systems. The Agentic Flywheel is showing what coordinated agent work looks like at scale.

VII. What Works, What Doesn’t

After running the flywheel for two weeks, here’s what I’ve learned about what actually delivers and where the limitations are.

What Genuinely Works

Parallelizable Tasks Execute Simultaneously

When tickets are properly decomposed, agents work in parallel without stepping on each other. Three agents clearing a backlog in four hours isn’t theoretical—it’s what happened. The coordination infrastructure makes this possible.

Agent Mail Prevents File Conflicts

When agents remember to use it, the file reservation system works perfectly. I never hit a merge conflict during execution. The triple-layer protection—Beads structure, file locks, Agent Mail messaging—creates enough redundancy that collisions don’t happen.

Beads Structure Keeps Agents Focused

The robot-triage output gives agents clear direction. They don’t wander or get distracted. They pick a ticket, execute it, move to the next one. The git-native storage means they can see dependencies and respect execution order.

Multi-Model Access Ready

Though I haven’t tried Codex or Gemini yet, the infrastructure supports heterogeneous fleets. You can route different work types to different models. The plumbing is there when I’m ready to use it.

Current Limitations

Heavy Vibe-PM Investment Upfront

You cannot skip the specification work. The multi-shot iteration across models, the architecture refinement, the ticket decomposition—all of that has to happen before you spawn agents. There’s no shortcut here. If you try to hand agents loose specs, they’ll execute them loosely. Although, I think this is feature not a bug.

Agents Forget Coordination Protocols

The forgetting problem is real. Agents need reminders to update Agent Mail, to communicate status, to follow patterns you’ve established. This isn’t a one-time training issue. It’s ongoing supervision.

Beads Sync Challenges Across Tool Versions

The beads versus beads_rust compatibility issue cost me time. If you’re mixing tools from the ecosystem, expect friction. Going fully opinionated—beads_rust and bv—is cleaner, but you lose some flexibility.

Crawl, Walk, Run

I believe fire-and-forget is achievable if your design and tickets are solid. I’ve just crawled—learning the system, staying hands-on. Next is walking—reducing supervision as I get better at specification. Eventually running—full permissions off, agents execute autonomously.

The constraint right now is my skill, not the system. I need more tests built in so the system doesn’t regress without supervision. I’ve already identified a smaller project to try hands-off execution once I have my katas down.

Team Scale: Unknown

I don’t know how this scales across a team yet. My hypothesis: entire subsystems get handed to different developers with no overlap. Each developer runs their own agent fleet on their domain. Coordination happens at the subsystem boundary, not the ticket level.

Making agent fleets work for teams is a skill we’ll learn as base tooling gets better. Right now, the patterns are optimized for solo operators or small teams with clear domain separation.

VIII. Positioning: Where This Fits in the AI Dev Landscape

After running agent fleets for a few weeks, I have a clearer sense of where this approach fits in the broader landscape of AI development tooling.

The AI development tooling landscape has a spectrum. Understanding where the Agentic Flywheel sits helps clarify when to use it—and when something else makes more sense.

The Scale Spectrum

Solo Claude Code → Single agent, iterative collaboration, you’re in the loop for every decision. Good for exploratory work, learning a new domain, or tasks where the specification emerges through conversation.

Agentic Flywheel → Coordinated fleet of 3-20 agents, heavy upfront specification, orchestrated execution. Good for projects with clear architecture where parallelization delivers velocity.

GasTown Full Automation → Autonomous development with minimal human intervention. The vision of “describe what you want, walk away, come back to working software.” Still early, thriving community, but not production-ready for most use cases yet.

Why I’m Staying at Flywheel Scale

The trust gradient matters. I’m comfortable delegating implementation to agents when I’ve done the architecture work. I’m not comfortable delegating architecture decisions—yet. I actually want to know what the system is and what it does so I know where to go fix things.

At Flywheel scale, I maintain control through specification. I decide what gets built, how components integrate, what the boundaries are. Agents execute within those constraints. The coordination harness gives me visibility and intervention points.

GasTown’s vision is compelling, but I’m not ready to trust autonomous architecture decisions on production systems. Maybe that changes as the tooling matures and I see more case studies. Right now, Flywheel hits the right balance between velocity and control.

My Scaling Path

I ran three agents. My next goal is graduating to 5-7, then to 10 agents.

Running 10-20 agents will come at a cost that’s prohibitive for individual developers—though still cheaper than hiring a team of engineers. The API costs add up fast when you’re running multiple Claude sessions simultaneously.

Where Flywheel Will Shine: Open Source Models

This is imminent. When OSS models reach Claude-level quality, the economics change completely. I can decide granularly which agents run on which models, actively managing costs. Frontend work on a cheaper model, critical backend logic on Claude, documentation on the cheapest option that works.

The Flywheel infrastructure supports this already. It’s model-agnostic by design.

The Supervisor Pattern

Another pattern I’m considering: one supervisor agent that reviews outputs from other agents. This gets me out of the loop without going full fire-and-forget. The supervisor checks quality, flags issues, decides when work is ready to merge.

This is the bridge between hands-on orchestration and autonomous execution.

Prediction: This Happens Fast

My bet is all of this happens within 12 months, not 18.

Claude just released Agent Teams. I’m going to blog about my first experience with it next, but the pattern recognition is clear—delegation, messaging, task distribution. The same concepts the Flywheel has been proving out.

When commercial AI platforms adopt these patterns and OSS models reach quality parity, agent fleet development becomes standard tooling for small teams. Solo founders get sprint-level velocity. Small teams multiply their output without hiring.

The constraint shifts from “how many engineers can we afford?” to “how well can we specify what needs to be built?”

Organizations will need people who can do Vibe-PM work—think in systems, decompose cleanly, specify precisely. That’s a different skill than traditional product management, but it’s learnable.

The Agentic Flywheel shows what that future looks like.

References

• Agentic Flywheel System: https://agent-flywheel.com/

• Steve Yegge’s GasTown: https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04

• Beads (Steve Yegge): https://github.com/steveyegge/beads

• Beads Community Tools: https://github.com/steveyegge/beads/blob/main/docs/COMMUNITY_TOOLS.md

Your agent loses state. Forgets what’s done. Hallucinates progress. You compact the context, and suddenly it’s re-litigating decisions you made an hour ago.

Markdown plans feel lightweight, but they’re part of the problem. Agents can’t query them. No dependency tracking. No structured state to reason about. You end up being the memory layer—copying context back and forth, reminding your agent what it already knew.

Beads solves this.

It’s a git-native issue tracker built for agents. SQLite database, JSONL format, version controlled alongside your code. Your agent can query it, update it, track dependencies, and pick up exactly where it left off.

Claude’s new Tasks feature is inspired by Beads. When Anthropic builds a feature based on an open-source CLI tool, pay attention. This pattern is becoming infrastructure.

What goes into Beads (and what doesn’t)

Planning happens outside Beads. Execution happens inside.

I use PLAN.md or PRD-for-sprint.md to define what we’re trying to accomplish. Then I ask Opus to decompose it into epics, create tasks, figure out dependencies—all captured in Beads. The instruction is that each epic and ticket must be self-sufficient to be picked up cold.

Human plans the what. AI decomposes the how.

Sprint — Weekly milestone. I define the goal in markdown with Opus. This lives in PLAN.md, not Beads.

Epic — High-level items from sprint planning. 1-2 epics per sprint ticket. Epics go into Beads.

Task — Granular work items. AI handles the breakdown—subtasks, dependencies, sequencing. Tasks go into Beads.

Between the epic (big picture) and the task (details), Claude has all the information required to pick up any ticket cold.

Tight scope in, deep decomposition out.

I don’t create subtasks manually. I tell Claude to analyze the epic, break it down, identify dependencies, and file the tickets. I review what it created, adjust if needed, then let it execute.

Session discipline

I started by churning through epics in one session. Felt productive until context overflow hit—Claude compacting, and then I’d have to ask it to reload state from the ticket.

Then I realized: because tickets are granular and have all the context required, I don’t need to be chained to the Claude session. I was holding onto sessions afraid of losing important context. But the context isn’t in the session—it’s in Beads.

That was liberating.

Now I open Claude, ask it to pick the next task, and go. Shorter sessions. More productive. No context anxiety. One task, execute, restart.

Starting a session:

bd prime is in my CLAUDE.md. It loads the workflow rules, the session close protocol, the available commands. Hooks auto-call this in Claude Code when .beads/ is detected.

Ending a session:

I just tell Claude “land the plane.” The closing discipline is so good that Steve Yegge named the pattern after it. Claude automagically runs through everything:

[ ] git status — check what changed
[ ] git add <files> — stage code changes
[ ] bd sync — commit beads changes
[ ] git commit -m "..." — commit code
[ ] bd sync — commit any new beads changes
[ ] git push — push to remote

Work isn’t done until it’s pushed. Your agent finishes current work before wandering to the next thing.

Patterns that work

These emerged from weeks of daily use. None are obvious until you’ve lost context the hard way.

File as you go. When Claude surfaces something during implementation—a bug, a refactor needed, a question for later—file it immediately. bd create captures the context fresh, in the moment. Don’t carry it in your head. Don’t trust yourself to remember. The issue exists, the context is preserved, you pick it up in a future session.

Land the plane. Agents love to wander. They’ll start three things and finish none. The land-the-plane pattern keeps them focused: finish current work before starting new work.

bd ready for what’s next. This shows issues with no blockers—ready to work. Use bd blocked to see what’s stuck in dependency chains. I’ll admit I’m still often picking tasks manually because my dependency graphs aren’t mature yet. But as I get better at upfront decomposition, bd ready becomes the natural entry point.

Kanban for the big picture. Beads is CLI-first, but I run a Kanban UI alongside it. I watch as Claude updates tickets in real-time—what’s moving, what’s stuck, what just closed. Big picture visibility without micromanaging.

One thing I’ve learned: I don’t actually know all the bd commands. Claude does. I just tell it what I want—create a ticket, set dependencies, close these three issues. The CLI is abstracted away. That’s the point.

What I had to teach my agents

Beads is agent-native, but agents still need guardrails.

CLI discipline. Claude sometimes forgets to use bd and tries to directly read or write .beads/issues.jsonl. It also confuses bd with beads. Both break things. Add explicit instructions and examples to CLAUDE.md:

Always use `bd` CLI commands — NEVER directly read or write .beads/issues.jsonl

bd list                        # List all issues
bd show <issue-id>             # Show details
bd update <id> --status in_progress
bd close <id>
bd comments add <id> "message"

Ticket hygiene. Claude is eager. It wants to chomp through tasks and move on. It’ll come back and tell you everything is done—and often it’s wrong. I explicitly tell it in CLAUDE.md to update tickets with status and learnings as it goes. This keeps it on track and ensures context isn’t lost. The ticket becomes the record of what actually happened, not what Claude thinks happened.

Sync hygiene. Without bd sync flush, the database can have stale state. Run it before commits. Build it into the session close protocol.

These feel like small things, but they compound. An agent that follows CLI discipline, updates tickets, and syncs properly is an agent that maintains accurate state across sessions. That’s the whole game.

The ecosystem forming

Beads is lightweight by design—a CLI and a git-backed database. But an ecosystem is growing around it:

• Kanban UIs for visualization

• Hooks that auto-sync when .beads/ is detected

• Community patterns like epic decomposition and land-the-plane

This is early infrastructure. The primitives are right. The UX will mature. The patterns will standardize.

Context rot was the problem. Beads is the memory layer that solves it. The rest is discipline.

Credit to Steve Yegge for creating Beads and the patterns that make it work. Repo here: https://github.com/steveyegge/beads

#AgenticCoding #DevTools #Beads

Five Paradigm Shifts in 25 Years of Building Software

I’ve had five “everything just changed” moments in my career. Not incremental improvements. Moments where the ground shifted and what was possible afterward looked nothing like what came before.

1. Java: Write Once, Run Anywhere Wasn’t Marketing

The first was Java in grad school. I was a confident C++ developer. Then I turned in an assignment that worked perfectly on my machine and completely broke on the professor’s.

Next assignment, I tried Java on a lark. Sun’s “write once, run anywhere” promise wasn’t marketing copy—it was real. The friction I’d accepted as normal just... disappeared.

I spent the next decade at Sun building Java EE. That one broken assignment changed the trajectory of my career.

2. Jenkins: Software Delivery Could Be Automated

The second was discovering Jenkins—built by my colleague Kohsuke Kawaguchi at Sun. At the time, software delivery was manual, painful, and treated as someone else’s problem after you wrote the code.

Jenkins made a simple proposition: software delivery could be as automated as software building.

That insight led to 15 years of working together. It spawned the entire DevOps movement. Billions of builds later, the friction we accepted as normal had vanished again.

3. Cloud: Infrastructure as Someone Else’s Problem

The third was the advent of cloud computing. Suddenly the entire infrastructure layer—servers, networking, scaling—became someone else’s problem.

This led me to CloudBees PaaS. We were building Heroku for Java, or in more modern terminology, something like Lovable—but a decade too early. The market wasn’t ready. But the insight was right: developers shouldn’t manage infrastructure.

More importantly, cloud changed how I thought about building products. Everything I built afterward was SaaS-first. The mental model shifted permanently.

4. AI/ML: The Signal in the Noise

The fourth was 2018. Something clicked. The convergence of cloud maturity, DevOps tooling, and AI/ML capabilities felt like it was reaching a tipping point.

That conviction led to Launchable—an AI/ML company applying machine learning to software testing. We were probably a couple of years early there too. The pattern recognition was right, but the market needed more time to catch up.

Being early is its own kind of lesson. You see the shift coming, but timing matters as much as vision.

5. Claude Code: Something Shifted Last Week

The fifth happened last week with Claude Code.

I’ve played with AI coding tools since GPT-3. Copilot was useful—like a smart autocomplete. Cursor was better—more context-aware, more capable. But neither felt like a paradigm shift. They were incremental.

Then I started using Claude Code’s multi-agent workflows. I haven’t opened an IDE in days. Not because I’m lazy. Because I’m building faster than I ever have.

The 400 Horsepower Problem

My friend Sameer Karmarkar, CTO CloudHedge put it well: we learned to code and came out with a single horsepower engine. Copilot gave us maybe 2-3x. But with agentic workflows, it feels like every developer is about to have a 400 horsepower engine.

The question isn’t whether you can code. It’s whether you can drive.

This is where it gets interesting—and where most of the current discourse misses the point.

I’ve heard observations like “AI assistants will just expose your process inefficiencies” and “you need to clean up your processes first.” That’s not wrong, but it’s missing the bigger picture.

Here’s my contrarian take: a large number of these processes are going to be rewritten entirely. We’re not going to clean up our existing workflows and bolt on AI. We’re going to discover that many of the workflows existed because of constraints that no longer apply.

Think about it. We have code review processes designed for human attention spans. Deployment pipelines built around the assumption that builds are expensive. Testing strategies that assume developers won’t write enough tests because it’s tedious.

What happens when the cost of generating code drops 10x? When an agent can write and run 500 tests in the time it takes you to write one? When the bottleneck isn’t writing code but deciding what to build?

The processes we’ll need are fundamentally different.

From Driving to Fleet Management

Here’s where I think this is headed.

Right now, we’re in the “horseless carriage” phase. If you look at early automobiles, they literally looked like horse carriages with engines bolted on. The driver sat up front, in the same position as someone holding reins. It took decades for car design to reflect what cars actually were—not horses.

We’re doing the same thing with AI coding tools. We’re sitting at our IDEs, prompting one agent at a time, reviewing its output like we’d review a junior developer’s pull request. We’ve bolted a 400HP engine onto our horse carriage.

The next evolution is fleet management. Not one agent you supervise, but multiple agents you orchestrate. The mental model shifts from “I’m coding with AI assistance” to “I’m directing a team of AI developers.”

This changes everything—what skills matter, how we organize work, what “senior” even means.

Where the Hard Problems Are

I don’t have this figured out. Nobody does. But from experimenting with multi-agent workflows, here’s where I see the friction:

Governance. When multiple agents collaborate, who’s responsible for the output? How do you audit decisions? The compliance and security implications are massive for enterprises.

Merge conflicts. Not just Git conflicts—conceptual conflicts. Agent A builds a feature assuming one architecture. Agent B builds another feature assuming a different architecture. Human judgment is still required to resolve the contradictions.

Abstraction layers. We need new primitives. Just like we went from assembly to C to Python, we need new abstractions for orchestrating agent work. The current tools feel like writing shell scripts to manage processes—it works, but it’s not the right level of abstraction.

I’m early in exploring this. But it feels like the same kind of “something is shifting” sensation I had with Java, Jenkins, cloud, and Launchable.

The Compound Effect

Each shift made the next one possible:

Java made Jenkins possible—you needed portable code before you could automate delivery.

Jenkins made cloud-native development possible—you needed automated pipelines before you could deploy continuously to elastic infrastructure.

Cloud made AI/ML accessible—you needed scalable compute before you could train models economically.

And now AI-native development is emerging from all of it.

I’ve been experimenting with new workflows—multi-agent orchestration, tools like Beads, new patterns for how software gets built. The compound effect of these five shifts is just starting to become visible.

The question for anyone building software: are you still driving a horse carriage with an engine bolted on? Or are you learning to manage a fleet?

The Problem: Drowning in Smart People’s Thoughts

I have a newsletter problem. Not the “I need to unsubscribe” kind, but the opposite: I’m subscribed to brilliant people sharing valuable insights, and I can’t keep up.

The emails pile up. Dharmesh Shah sending updates about his agentic AI experiments at HubSpot. Industry leaders dropping wisdom bombs about product strategy, market trends, and technical deep-dives. Each one valuable. Each one sitting unread in my inbox, mocking me.

The issue isn’t just volume, it’s the cognitive load. Reading these newsletters one-by-one means constant context switching. I’m jumping from AI agents to SaaS pricing to developer tools to marketing strategy.

My brain feels like a browser with 47 tabs open, each demanding attention.

I tried the obvious solution: summarize each email. But that still doesn’t solve the context switching problem, and more importantly, I was missing something bigger. When Dharmesh sends a couple of emails per week about his AI journey, I don’t just want bite-sized summaries. I want to step back and understand: What is he really thinking about? What themes is he exploring? Where is his attention focused?

That’s when I realized: I don’t need to see individual trees. I need to see the forest.

The Vision: NotebookLM as My Second Brain

Enter NotebookLM. If you haven’t played with it, it’s Google’s AI-powered research assistant that lets you upload documents and have deep, contextual conversations about them. I’ve fallen in love with it for exactly this use case: throw in related content, and it helps me synthesize themes and insights that span multiple sources.

The ideal workflow became crystal clear in my head:

1. Extract all emails from a specific sender (say, Dharmesh)

2. Consolidate them into a single document

3. Feed that into NotebookLM

4. Ask: “What are the recurring themes? What’s the evolution of thinking here?”

Simple, right? Except there’s no integration between Gmail and NotebookLM. Which seems like an obvious oversight, but here we are.

Why N8N? (Spoiler: I Have Jenkins PTSD)

I’ve been in DevOps for 15 years. Jenkins, CI/CD pipelines, automation workflows—it’s been my lifeline. When I see a repetitive manual process, something in my brain just screams “AUTOMATE THIS.”

Recently, I’ve been exploring the agentic AI tools landscape, and N8N kept coming up. YouTube tutorials, blog posts, Twitter threads—everyone seemed to be building with it. The pitch was compelling: a visual workflow builder with integrations to everything. Gmail, Google Docs, Sheets, Slack, you name it.

I thought: “N8N is a workflow processor with plug-and-play integrations. Building this pipeline should be very easy.”

So I dove in.

The Honeymoon Phase: First Impressions

I’ll give N8N credit: the first impression was genuinely impressive.

I’m using N8N Cloud, and the low-code visual editor felt intuitive. Dragging nodes, connecting them with lines, searching for integrations—as long as you have the data model in your head, it’s straightforward. Certainly less work than configuring Jenkins pipelines or wrestling with YAML files.

The node library is extensive. Gmail? Check. Google Docs? Check. Data transformations? Check. It felt like Lego blocks for workflows. Snap pieces together, configure a few settings, hit execute, and watch the magic happen.

Unfortunately, that initial impression was the peak. It was a gradual downhill from there.

The Build: Two Iterations and Many Lessons

Let me walk you through what I actually built.

Iteration 1: The HTML Export Dream

My first workflow looked like this:

Form submission trigger → Get many messages → Edit Fields → Get a message → Edit Fields → Convert to File

The idea: trigger the workflow with an email address, fetch all their emails, extract the content, convert it to HTML, and dump it somewhere I could grab for NotebookLM.

Here’s where I hit my first gotcha: “Get many messages” is a misnomer. It doesn’t actually get you many messages with full content. It gives you a table of message metadata—IDs, snippets, basic info—but not the actual email bodies. This is presumably to prevent you from downloading gigabytes of data accidentally, but the naming is misleading.

So I had to add another node: “Get a message.” This takes each message ID from the first step and fetches the full content. The good news? N8N is smart enough to automatically iterate over the table, so I didn’t need to explicitly create a loop. That was actually slick.

Then came the “Edit Fields” nodes. Why two of them? Because the Gmail API returns everything: headers, labels, thread IDs, metadata soup. I had to explicitly extract just what I wanted: subject, date, and the actual email text.

I tried converting this to HTML and using Postbin (which N8N recommends for testing) to dump the output. Then I’d copy-paste into NotebookLM. It worked... but felt clunky.

Iteration 2: The Google Docs Integration

The second iteration was cleaner:

Form submission trigger → Create a document → Get many messages → Get a message → Edit Fields → Update a document

Instead of exporting files, I’d create a Google Doc on the fly and append each email to it. Then I could just share the Google Docs link directly with NotebookLM as a source. Much more elegant.

This worked! Sort of. The output was a chronological dump of emails—no fancy formatting, no headers, just raw content. I’d tried to use Markdown in an earlier attempt, but it didn’t work as expected for reasons I’ve honestly forgotten.

But the core loop was functional: fetch emails, filter out noise, write to Google Doc, link to NotebookLM.

The Frustrations: Death by a Thousand Paper Cuts

Here’s where we need to talk about the things that drove me slowly insane.

The Auto-Save Betrayal

The most frustrating moment—and there were many—was discovering that my entire Day 1 workflow had disappeared because N8N doesn’t auto-save by default.

I could see the execution history. The logs showed my workflow had run successfully. I could see the outputs, the data transformations, everything. But the workflow itself? Gone. Because I’d closed the tab without manually hitting the save button.

This happened. Multiple times. My bad!

For someone coming from modern dev tools where auto-save is table stakes, this felt like using software from 2005. And yes, you can argue “user error,” but when the platform shows you execution history proving your workflow existed and worked, not saving it feels like a betrayal.

The 75% Problem

This became my mental model for N8N: it gets you 75% of the way there, then leaves you stranded.

Example: I wanted to use Google Sheets instead of Google Docs initially. N8N has a Google Sheets integration. Great! You can create a sheet, write data to it, update cells—all the things you’d expect.

But here’s the gotcha: to dynamically update columns in Google Sheets, N8N requires you to explicitly define headers. Makes sense. Except when you dynamically create the sheet through the workflow, there’s no easy way to add those headers. You’re stuck in a catch-22: can’t update without headers, can’t create headers programmatically.

I also wanted to move the created sheet into a specific folder. That had its own set of gotchas. What should have been a simple “create → organize → populate” flow turned into an afternoon of wrestling with the API.

Variables, If-Then-Else, and Pro Plans

I wanted to store some values across nodes—basic variable management. Turns out N8N does have variables, but they’re global. Coming from a programming background, this was shocking. Global state is generally considered an anti-pattern, yet here it was as the default (and on the free tier, it is not an available) option.

Want proper variable scoping? That’s a pro plan feature.

I also wanted basic if-then-else logic. N8N has conditional nodes, but they felt clunkier than they should be. For someone who thinks in code, I kept wanting to just write:

javascript

if (emailCount > 10) {
  // do this
} else {
  // do that
}

Instead, I’m dragging nodes and configuring dropdown menus.

The Documentation Dance

The documentation is extensive, but I found myself constantly Googling for examples because the official docs would explain the what but bare minimum.

The Verdict: Is N8N Worth It?

After nearly two days of work spread across a couple of sessions, I have a working workflow. And I need to be fair: it does work.

I can trigger it, give it an email address, and out comes a Google Doc with all their messages consolidated. I link that to NotebookLM, and suddenly I can ask those high-level thematic questions. “What are Dharmesh’s main focus areas this quarter?” “How has his thinking on AI agents evolved?” It delivers exactly the forest-level view I was looking for.

But would I recommend N8N? The jury is still out.

Who It’s Good For

I think N8N optimizes for a specific user: someone who wants to prototype workflows quickly, who doesn’t have a programming background, and who needs to connect common SaaS tools without writing code. For that person, the visual interface and extensive integration library are genuinely valuable. I don’t quite know what happens when they run into the issues that I outlined.

It’s excellent for mocking up ideas. “Let me see if this flow makes sense” can happen in minutes. That’s powerful.

Who Should Look Elsewhere

If you’re a programmer who thinks in code, loops, and proper variable scope? N8N might frustrate you. The visual editor that’s supposed to make things “easier” actually adds friction. You’re constantly translating your mental model (”I just need a for loop and a conditional”) into drag-and-drop nodes.

If you need production-grade reliability and you’re planning to hand off your workflow to someone else? I’m not convinced N8N is there yet and to be fair, I haven’t tried the enterprise plan. The auto-save issues, the “last mile” gaps in integrations, and the need for workarounds make me hesitant to treat it as mission-critical infrastructure.

My Next Steps

I’m giving N8N a fair shake. I’ll try one or two more workflows before making a final judgment. But I’m also exploring other agentic workflow tools to see if there’s something that offers more programmatic access—essentially, a tool that doesn’t hide the code but rather enhances it.

If I were starting this project over today? I’d probably reach for a tool with a code-first approach rather than a visual editor. Sometimes writing Python or JavaScript is the faster path, especially when you already think in those patterns.

The Bigger Picture: Information Needs Better Tools

Here’s what I keep coming back to: the newsletter problem is real, and it needs solving.

We’re inundated with information. Smart people are sharing valuable insights across dozens of platforms and formats. But our tools for sense-making haven’t kept up. We’re still treating emails as individual items rather than as threads in a larger narrative.

The workflow I built—as janky as parts of it are—actually addresses a genuine need. Being able to go from “trees” (individual emails) to “forest” (thematic understanding) is valuable. NotebookLM as the final piece is what makes it sing, turning raw text into conversational insights.

This experiment taught me that the gaps between our tools are often where the most interesting opportunities live. Gmail doesn’t talk to NotebookLM. NotebookLM doesn’t have email integration. So we build bridges.

Closing Thoughts

Would I use N8N again? Maybe. Would I recommend it to a friend? Depends on the friend.

But here’s what I would say: if you’re drowning in newsletters from people whose thinking you value, consider building some kind of consolidation workflow. Whether it’s N8N, Zapier, a Python script, or even a manual process of copy-pasting into a doc once a month—find a way to step back and see the patterns.

The insights are there. You just need to zoom out far enough to see them.

What do you think? Have you built something similar? Are you also drowning in newsletters? Drop a comment or reach out—I’d love to hear about your approaches to this problem.

And if you want the technical deep-dive on the actual workflow structure and data models, let me know. That might be a separate post for the nerds (affectionate) who want to build something similar.

post methodology
@perplexity comet, @google deep research: Take the following list of blogs, essays and build me the top 10 topics in the order of highest importance first that these blogs and essays discuss. Give me 3 bullet points under each topic and give me a 1-2 paragraph digest that helps me understand the bullets

[https://inferencebysequoia.substack.com/s/essays][https://inferencebysequoia.substack.com/s/ai-ascent][https://inferencebysequoia.substack.com/s/training-data-podcast]

@claude Act as a Senior Content Creator - one that has an output of two essays from junior content creators (Perplexity, Google Resource) that have looked at the same resource (Inference by Sequoia) to create a top ten list of themes with 3 key points under each theme and summary paragraph that distills the key lesson from the themes. Format this into Substack-style post for me. 

HS: Ultimately, the list was refactored to bring in key items that were missed by Claude by me.

The AI revolution isn’t coming—it’s here. But understanding where we’re headed requires looking beyond the headlines to the deeper currents shaping this transformation. Sequoia Capital’s extensive research reveals ten critical themes that will define the next phase of AI development, from autonomous agents to the infrastructure powering them.

1. The Agent Economy: Beyond Tools to Digital Workers

• Foundational Infrastructure: New digital pillars are emerging—persistent identity systems, standardized communication protocols, and trusted security frameworks—that will enable AI agents to operate autonomously in economic systems.

• From Deterministic to Probabilistic: Unlike traditional software that follows predictable paths, AI agents embrace uncertainty and adapt to dynamic conditions, much like human decision-making processes.

• Economic Participation: Agents aren’t just automating tasks; they’re becoming economic participants capable of generating value, negotiating deals, and forming networks with other agents in entirely new digital marketplaces.

The shift toward autonomous agents represents a fundamental reimagining of software—from tools we use to digital workers that act on our behalf. This isn’t just about better chatbots; it’s about creating a new layer of economic activity where intelligent agents handle everything from routine transactions to complex negotiations.

2. AI Reasoning: The Great Paradigm Shift

• System 2 Thinking: AI is evolving beyond pattern recognition toward structured reasoning, enabling deeper problem-solving and explainable decision-making that mirrors human expert thinking.

• Computational Scaling: Recent breakthroughs show that giving models more compute during inference—not just training—dramatically improves reasoning ability, like allowing a person more time to think through complex problems.

• Transparency Revolution: New reasoning models are designed to be interpretable and reliable, reducing hallucinations and making AI decisions more trustworthy for critical applications.

We’re witnessing AI’s evolution from fast pattern matching to deliberate reasoning. This transition promises to unlock AI’s potential in high-stakes domains where accuracy and explainability are paramount, fundamentally changing how we think about machine intelligence.

3. The Application Layer Gold Rush

• Value Concentration: The biggest opportunities are shifting from foundational models to application-layer products—the interfaces and platforms where users actually interact with AI capabilities.

• Killer App Emergence: Standout applications achieve extraordinary user retention by seamlessly integrating AI into daily workflows, creating new habits and setting higher expectations for software experiences.

• Competitive Intensity: Both startups and tech giants are racing to capture the application layer, leading to rapid innovation cycles and a relentless focus on user experience over pure technical capability.

While foundation models grab headlines, the real value creation is happening where AI meets human needs. The companies winning this race aren’t just building better AI—they’re crafting experiences that make AI indispensable to their users’ daily lives.

4. Synthetic Data: The New Training Revolution

• Efficiency Breakthrough: Synthetic data generation dramatically reduces the cost and time required for model training while enabling rapid experimentation without real-world data collection bottlenecks.

• Precision Customization: Artificially generated datasets can be tailored for specific domains and edge cases, enabling enterprises to build AI systems perfectly aligned with their unique requirements and business logic.

• Innovation Acceleration: The ability to rapidly create and iterate with synthetic data removes traditional barriers to AI development, allowing teams to prototype ambitious ideas and accelerate deployment timelines.

Synthetic data is democratizing AI development by removing the traditional barriers of data collection and curation. This shift enables more companies to build specialized AI systems and accelerates innovation across industries.

Subscribe now

5. AI Infrastructure: Building the Foundation

• Next-Gen Data Centers: AI’s computational demands are driving the construction of specialized “AI factories”—massive data centers designed specifically for training and serving sophisticated models at global scale.

• Ecosystem Integration: Success requires orchestrating partnerships between cloud providers, hardware manufacturers, and innovative startups to create seamless deployment and support systems.

• Sustainability Imperative: The enormous energy footprint of large-scale AI raises critical questions about environmental impact, making efficient resource utilization essential for scalable AI adoption.

The infrastructure supporting AI represents one of the largest technological buildouts in history. Getting this foundation right—from energy efficiency to global distribution—will determine who can actually deliver on AI’s promise at scale.

6. Human-AI Collaboration: The New Working Model

• Interdisciplinary Integration: Successful AI systems require diverse teams combining technical expertise with domain knowledge, ensuring AI products are practical, relevant, and reliable in real-world scenarios.

• Trust Architecture: Effective human-AI partnerships depend on transparency, predictability, and accountability—users need confidence that AI recommendations are sound and systems behave ethically.

• Complementary Strengths: The optimal future merges human judgment and creativity with machine speed and scale, where AI handles complex computations while humans provide strategic direction and values-based decisions.

The most impactful AI implementations don’t replace human expertise—they amplify it. Success requires rethinking workflows to leverage the unique strengths of both human and artificial intelligence.

7. Specialized vs. General AI: The Precision Advantage

• Domain Expertise: Specialized AI agents excel in industries with complex regulations and unique workflows, delivering superior accuracy and compliance compared to general-purpose alternatives.

• Architecture Optimization: Building effective domain-specific agents requires curated high-quality data, advanced reasoning engines, and workflows designed to match real business complexity.

• Competitive Differentiation: Organizations investing in custom AI agents see measurable improvements in performance, cost reduction, and process efficiency, creating sustainable competitive advantages.

While general AI captures attention, specialized applications are where the immediate value lies. Companies that invest in domain-specific AI solutions are seeing transformational results that general models simply can’t match.

8. The Open Source Ecosystem: Community-Driven Innovation

• Collaborative Acceleration: Open-source development connects global developer communities, accelerating innovation through shared knowledge, code, and best practices that no single organization could achieve alone.

• Modular Architecture: Success increasingly requires orchestrating suites of specialized agents and tools rather than relying on monolithic models, creating more flexible and scalable AI systems.

• Standardization Imperative: Growing ecosystem complexity demands universal standards and protocols to enable interoperability, making diverse AI systems communicate and collaborate effectively.

The open-source movement is becoming a crucial counterbalance to proprietary AI development, fostering innovation accessibility while pushing the entire field forward through collaborative development.

9. Coding with AI: The Developer Revolution

• Context Engineering: AI coding tools excel when they understand the complete development environment—codebase history, architecture decisions, and project goals—enabling suggestions that are genuinely useful rather than generic.

• Manual Work Reduction: Smart context-aware AI can automate tedious tasks like refactoring, bug fixing, and legacy code updates, freeing developers to focus on creative problem-solving and strategic architecture decisions.

• Environmental Setup Over Prompting: The most effective AI coding assistance comes from creating rich, structured development environments where AI understands developer intent, making information organization as crucial as the instructions given.

AI is fundamentally transforming software development by shifting the focus from perfect prompts to perfect context. This represents a new paradigm where developers become orchestrators of AI capabilities rather than manual coders, dramatically accelerating development cycles and democratizing software creation.

10. AI’s Economic Transformation: The Trillion-Dollar Shift

• Generational Opportunity: Leading investors describe AI as a once-in-a-generation transformation unlocking trillions in new economic activity across every major industry and sector.

• Workforce Evolution: AI isn’t just automating tasks—it’s fundamentally redefining how people work, make decisions, and create value, requiring new skills, strategies, and organizational approaches.

• Societal Integration: The implications extend far beyond business, influencing governance, education, and social connection, making responsible innovation essential for equitable progress.

AI represents the most significant economic transformation since the internet. Its impact will be measured not just in efficiency gains, but in entirely new forms of value creation and human potential.

The Bottom Line

We’re not just witnessing technological advancement—we’re experiencing a fundamental reorganization of how intelligence, work, and value creation operate in our economy. The companies and leaders who understand these ten themes will be the ones shaping the next decade of human progress.

The AI revolution is still in its early chapters, but the plot is becoming clear. Those who act on these insights today will be the protagonists in tomorrow’s success stories.

Post methodology 

@notebooklm write an essay on the subject “Does Vibe Coding Need Context Engineering? or “Evolution of Vibe Code in 2025”;
proposed structure: The promise of vibe coding; The evolution from prompt engineering to context engineering; Comparison of context engineering with the OpenAI spec and Claude Code approaches; description of how context engineering can fulfill the promise of prompt engineering;
Talk about the evolution of VibeCoding through 3 phases in 2025
Lean heavily into patterns and anti-patterns
Lean heavily into lessons from the Ulimate Vibe Coding guide
Make this essay about 4000-5000 words

@claude: read the text of the essay in the prompt and your key insights (generated earlier) and write a 2000 word post that summarizes the main points in the format for substack post. Please make the post as concise as possible and avoid academic language or footnotes.

@chatgpt read the text of the essay in the prompt and output from claude and write a 2000 word post that summarizes the main points in the format for substack post. Please make the post as concise as possible and avoid academic language or footnotes

Summary:

The way we build software with AI is evolving. What began as casual “vibe coding” — chatting with an AI to generate code—is maturing into a structured, scalable practice called context engineering. This post traces the three major waves of this evolution, breaks down the four pillars of context engineering, and shows why managing context—not prompts—is the future of AI-assisted development.

🌀 The Rise (and Limits) of Vibe Coding

In late 2024, a new generation of developers discovered a magical new workflow: vibe coding.

The pitch was seductive:

“Just tell the AI what you want — and it’ll build it.”

No syntax. No boilerplate. No need to wire up config files. You were speaking in ideas. The AI did the rest.

But as projects got more complex, the cracks showed:

• 🧠 Amnesia: AI forgot architectural decisions between sessions.

• 🔁 Repetition: You kept re-explaining project goals.

• 🧩 Incoherence: Outputs didn’t fit together.

• 👻 Hallucinations: The AI invented features or APIs that didn’t exist.

One dev nailed it:

“It’s like managing a brilliant but confused intern.”

You could get snippets, but not systems. You could vibe, but you couldn’t scale. The magic prompt fallacy — that one perfect message would produce a working app — had met reality.

And the root cause was clear: missing context.

🪜 The Three Waves of AI Coding

As 2025 unfolded, developers adapted. The evolution came in three distinct waves:

Wave 1: Discovery

Late 2024 – Early 2025

“Why won’t this AI understand me?”

AI was a novelty — a smarter Stack Overflow. Devs used it for:

• Debugging

• Snippets

• Small one-off tasks

Then came a breakthrough: role-playing.

Give the AI a persona like “Senior Engineer” or “Product Manager,” and it behaved better.

This trick planted a deeper seed:

AI needs structure. It needs role. It needs environment.

But the workflow was still ad hoc, and prompts were ephemeral.

Wave 2: Structure

March – May 2025

“The AI is a junior dev — give it guidance.”

The metaphor shifted. You didn’t just talk at the AI. You treated it like an intern.

The vibe changed from “magic prompt” to “guided collaboration.”

Key practices emerged:

• ✅ Plan first: Write a vision, strategy, and spec before touching code.

• 🧾 Use .rules files: Codify stack decisions and naming conventions.

• 🧩 Break it down: Decompose into 15–30 min atomic tasks.

• 🔁 Progressive enhancement: Build a skeleton, then layer functionality.

This added discipline. But devs were still manually juggling context across chat sessions, IDE tabs, and memory.

Wave 3: Engineering

Late May 2025 – Present

“We’re not just prompting AI — we’re designing systems.”

This is where things got serious.

We moved from prompting agents to architecting agent workflows.

Instead of throwing prompts into the void, developers started creating infrastructure — persistent, queryable, AI-readable context that scaled across:

• Sessions

• Models

• Tasks

This is the era of Context Engineering.

Subscribe now

🧠 What is Context Engineering?

Context engineering is the practice of designing, managing, and delivering the right information to AI systems at the right time — across entire projects, not just prompts.

Just like version control or deployment pipelines, context becomes infrastructure. It’s a system — not a sentence.

This shift mirrors other historical transitions in tech:

• HTML → CSS → Component systems

• Scripts → Build pipelines → CI/CD

• Vibe prompts → Spec-first workflows → Context engineering

🧱 The Four Pillars of Context Engineering

Context engineering stands on four core pillars. These are the patterns powering today’s most productive AI workflows:

1. Context Persistence

AI needs memory.

• 📝 Session Notes: progress.md or runtime state files to track thinking within a task.

• 🧠 Project Memory: Long-term documents like architecture.md, ai_context.md, and tech_stack.md that evolve with the project.

• 🔁 Living Docs: Update after each major feature or bug. Don’t throw away your thinking—codify it.

Think of this as the AI’s second brain.

2. Context Selection

Only load what’s relevant.

• 🔍 RAG (Retrieval-Augmented Generation): Use embedding search or rule-based fetchers to pull in the right files or specs.

• 🧭 Hierarchical Docs: Organize docs from general (project root) to specific (module-level).

• 🧪 Pattern Examples: Give the AI great samples from your codebase so it learns style, architecture, and best practices.

Don’t dump the whole repo. Curate its view like a good teacher would.

3. Context Compression

Keep only what matters.

• 🧾 Summarization: Condense past work, chat history, or long tool outputs into distilled forms.

• ✂️ Trimming: Use heuristics to prune stale or irrelevant messages.

• 🤖 Auto-Compaction: Some tools like Claude Code do this for you near context limits.

Prevent “context poisoning” with lean, meaningful sessions.

4. Context Routing

Different agents need different context.

• 🎭 Role-Based Agents: Architect, Coder, Reviewer — each gets different slices of context.

• 📦 Formal Handoffs: handover.md files summarize decisions, recent changes, and next steps.

• 🔁 State Anchoring: Use Git SHAs to lock AIs to specific points in the codebase, like “context bookmarks.”

This is where agent-based development gets orchestration.

🔧 Spec Coding: Intent as Infrastructure

One of the most elegant outcomes of context engineering is Spec Coding — championed by the team at SpecStory and inspired by Claude’s emerging workflows.

The idea:

Intent is the new source code.

You don’t start with implementation.

You start with clarity:

1. What are we building?

2. Why does it matter?

3. Who’s it for?

4. What are the constraints?

The flow looks like this:

1. Vision & Strategy — product goals, user personas, metrics

2. PRD — user stories, features, UX flows, requirements

3. Tech Spec — architecture, design system, content outline

4. Task Breakdown — development, design, and QA tasks

5. Execution with AI — each step validated by human and agent collaborators

This isn’t just good process. It’s how AI performs best.

⚡ Why This Evolution Matters

✅ Developers become Architects

You don’t micromanage code — you guide systems. The human role shifts from implementer to orchestrator.

🧠 Knowledge Compounds

Instead of losing context every chat, reasoning is preserved. Every session makes the AI smarter.

🚀 Onboarding Accelerates

Whether it’s a new human or a new agent, well-maintained context speeds things up dramatically.

🧪 Quality Becomes Predictable

You’re not gambling with prompts. You’re engineering conditions that reliably produce great code.

🧭 How to Make the Shift

Still prompting casually? No shame. But if you want leverage, start shifting toward context engineering.

Start Simple:

• Create /ai/docs/ in your repo

• Add a vision.md, architecture.md, and ai_context.md

• Track task progress in progress.md

• Break requests into 15–30 min chunks

Scale Up:

• Orchestrate multi-agent workflows (Planner, Coder, Reviewer)

• Use Git SHAs in memory files for time-anchored context

• Set up RAG pipelines to fetch relevant docs automatically

• Build handoff protocols between sessions

🌱 From Demo to Discipline

Vibe coding was fun. It was experimental. It was how we all started.

But the future belongs to those who treat AI collaboration as infrastructure — who move from hoping the AI “gets it” to ensuring it does.

We’re not replacing code.

We’re elevating how it’s built.

Welcome to the age of Context Engineering.

Sources:

1. YouTube Video: “Context Engineering for Agents” - LangChain

2. GitHub Repository: “The Ultimate Vibe Coding Guide” by Nicolas Zullo (EnzeD/vibe-coding)

3. Specflow Article: “Patterns & Best Practices” - Specflow

4. Specflow Article: “Reddit Wisdom” - Specflow

5. YouTube Video: “The New Code — Sean Grove, OpenAI” - AI Engineer

1. Perceive – sense the world.

2. Think/Plan – decide what to do.

3. Act – take action via tools.

4. Remember – store useful information.

5. Learn – adapt over time.

In my last post, I called this The DNA of AI Agents. It’s the blueprint that underlies everything from ChatGPT to complex multi-agent systems.

Goose in the DNA Loop

Recently, I ran Goose — an MCP-enabled agent framework by Block — and decided to map it back to this DNA.

Here’s what happens when you run Goose:

• Perceive → Takes in your prompt and any relevant context from local files or prior steps.

• Think/Plan → Outsources reasoning to an LLM, which decides what tool to run next.

• Act → Calls MCP servers to interact with tools like Git, Slack, or custom extensions.

• Memory → Stores session context locally; can be extended with vector databases.

• Learn → Static for now — no self-improving strategies without developer input.

Seeing Goose mapped to the loop makes it easier to understand what it’s doing and what its limits are.

The Barista Agent

Of course, not everyone wants to think in abstract diagrams. So I gave Goose a job: make me a cappuccino.

Here’s the flow:

1. You order a cappuccino → the agent perceives the request.

2. It considers the recipe and tools it needs → think/plan.

3. It acts by preparing the drink → act/tools.

4. It remembers your preference for extra foam → memory.

5. Next time, it uses that memory to make your coffee just right → learn.

Whether it’s coffee or code, the same DNA applies — only the tools and skills change.

Why This Matters

Understanding this DNA loop and the five dials gives you a universal lens for looking at any agent framework: Goose, LangGraph, CrewAI, AutoGen, or the next thing that comes along.

It strips away the hype and shows you:

• What’s actually happening.

• Where the framework shines.

• Where it needs work.

Once you see the DNA, you can build, compare, and design agents with much more clarity.

• perceive,

• think/plan,

• act,

• remember, and

• learn.

What makes them different are the “design dials” that shape their capabilities.

Agents sense the world (Perceive), decide what to do (Think/Plan), take action (Act/Tools), store experience (Memory), and evolve over time (Learn). This loop repeats endlessly, and upgrading any stage changes what the agent can achieve.

The 5 Dials

These are the levers an architect can turn to design an agent:

1. Perception — how much it can sense.

2. Reasoning Depth — how deeply it thinks.

3. Action Space — what it can do.

4. Memory Strategy — how it remembers.

5. Learning Mode — how it improves.

Turning these dials reshapes the agent’s personality, power, and purpose.

Every agent architecture is just a variation of this loop, shaped by how you set the five dials. The fun part? There’s no single “right” setting — it depends entirely on the problem you’re solving.

If you were building your own AI agent today, which dial would you turn up first — and why?

Section 5: The Hard Questions — Risk, Security, Control

The same features that make MCP powerful also makes it open for security risks.

You’re giving LLMs access to real-world tools and data. That opens the door to:

• Prompt injection where inputs trick the model into executing unintended actions

• Tool misuse especially when semantic descriptions are vague or overlapping

• Data leakage through resources passed too liberally or without redaction

• Permission drift when agents act beyond their intended scope

Security in MCP is still evolving. There’s no universal sandboxing, no standardized authentication layer, and no formal permission model baked into the protocol.

That doesn’t make it useless. It makes it local-first by necessity.

Right now, MCP is best used in controlled environments:

• Local agents with scoped access

• Internal workflows where failures are recoverable

• Sandboxed toolchains where impact is minimal

As the ecosystem matures, expect to see:

• Agent guardrails and policy layers

• Semantic firewalls between tools and models

• Auditing systems that trace agent behavior and tool usage

MCP doesn’t solve trust. It gives you the machinery to build it—if you do the rest.

That’s why protocol-native design will need to think about governance as it is has done about the architecture.

Section 6: Protocol-Native Futures

The idea of “MCP compatibility” may one day be as common as “REST API support.”

Imagine an ecosystem where tools like Gmail, Notion, GitHub, and Salesforce all expose their capabilities semantically:

• So agents can discover, evaluate, and invoke them dynamically

• So orchestration happens through reasoning, not hardcoded flows

• So systems interconnect based on intent, not brittle glue code

That’s the promise of protocol-native infrastructure.

MCP gives us a glimpse of what that might look like:

• Shared grammar for capability discovery

• Decoupling of agent logic from environment implementation

• Portable, composable AI workflows

We’ll need standards. We’ll need better security models. We’ll need social trust layers around who can expose what.

But if you squint, you can already see it:

• Tools building MCP endpoints

• Agents evolving toward autonomous orchestration

• Developers thinking in terms of protocols

This isn’t just a better integration strategy. It’s a foundational layer for a more semantic, agent-native internet.

Let’s build it.

Closing: Designing the Future with Protocols

By now, it should be clear: MCP isn’t just a cleaner way to wire up AI tools. It’s a blueprint for building systems that are fundamentally more agent-aware, context-driven, and interoperable.

Yes, the risks are real. Yes, the spec is still evolving. But the architectural direction is solid.

If you’re serious about building agents—not just wrappers—then protocol-native design is inevitable. MCP gives you a head start.

Whether you're defining your own MCP server, experimenting with semantic tools, or designing governance layers around AI workflows, you’re not just integrating—you’re laying track for the next infrastructure layer of AI.

Because the future of AI isn’t just more intelligence. It’s better interfaces.

And the interface is the protocol.

Let’s build accordingly.

This is post 1 of a 2 part series (see 2/2 here)

Section 1: Why Protocols Matter Now

Everyone is building AI agents. But almost no one is asking the deeper question: How should agents interact with the world?

Today, most agents rely on brittle wrappers and hardcoded toolchains. A developer stitches together a workflow on a platform and prays that things keep working—new platform/tool equals new integration. Every integration is bespoke. Every workflow is fragile.

This doesn’t scale. Not in terms of engineering effort. Not in terms of reliability. And certainly not in terms of reasoning.

What we need isn’t more platforms with custom integrations.

What we need is protocol thinking.

Just as HTTP standardized how browsers fetch and render content, the AI ecosystem needs a protocol to standardize how agents access tools, data, and workflows. That’s where the Model Context Protocol (MCP) comes in.

MCP is not a product. It’s not a dev tool. It’s a design shift. A shared grammar for agent-to-environment interaction.

This article is Part 1 of a two-part series exploring MCP from the perspective of someone seriously unpacking its potential. I won’t give you a hello world or an SDK demo. Instead, I’ll walk you through the ideas, primitives, and strategic consequences of thinking protocol-first.

In Part 2, we’ll dive into design insights, security risks, and what protocol-native systems might look like in the wild.

If you’re building in the agent space, MCP might be the most important thing you haven’t looked at yet.

Let’s fix that.

Section 2: What Is MCP, Really?

At its core, the Model Context Protocol (MCP) is an **open standard** for how LLMs interact with the outside world.

It’s not a new interface for humans. It’s a grammar for AI-to-environment interaction—focused on enabling models to reason, plan, and act.

Here’s how it works:

MCP operates on a client-server model. The AI agent (client) initiates a task and communicates with one or more MCP servers, each of which exposes specific capabilities. These capabilities come in three distinct forms:

1. Tools – executable functions. Think `search_web`, `trigger_build`, `create_task`, `send_email`. These are the verbs—the actions the agent can take.

2. Resources – structured context. Think of these as data the model can query, summarize, reason over. Logs, documents, search results, configs, memory.

3. Prompts – templated workflows. These are starting points: “summarize this conversation,” “set up a CI pipeline,” “craft an outreach email.”

The power of MCP isn’t just in what it enables, but *how* it enables it: each tool or resource comes with a semantic description written in natural language. That means the model can reason about what’s available, dynamically.

This makes MCP a model-facing protocol. It’s designed not just for interop between software components, but for semantic discoverability by language models.

And that’s what sets it apart from frameworks like REST or GraphQL: those are made for developers. MCP is made for agents.

Next, let’s look at why this model-first design unlocks a new scale of integration.

Section 3: The Strategic Payoff — Solving the M×N Problem

Let’s say you have 5 AI clients—maybe a chatbot, an IDE agent, a calendar assistant, a customer support bot, and a testing assistant.

Now imagine you want to connect them to 10 different tools: Jira, Gmail, Jenkins, Salesforce, Notion, GitHub, Slack, Stripe, Zoom, and your internal API gateway.

Without a shared protocol, you’re looking at a 5 × 10 matrix of one-off integrations. That’s 50 glue-code pipelines to maintain. Fifty different ways to break. Fifty reasons for your team to hate their life.

This is the M×N integration problem. Every new model or tool multiplies the integration cost.

MCP collapses that problem.

• Tools implement the protocol once.

• Clients speak the protocol once.

• Integration cost becomes M + N, not M × N.

This is what makes MCP more than just convenient. It’s infrastructure leverage. The kind you build ecosystems on top of.

When people say, “MCP is like USB-C for AI,” this is what they’re getting at: a single standardized interface that lets everything plug into everything else—securely, semantically, and scalably.

This is what protocol-native foundations look like.

And it opens up new design space entirely.

Next up: what this looks like in practice.

Section 4: Designing with MCP — A Gmail Agent Sketch

Let’s say you’re building an AI assistant that helps manage your Gmail inbox: triaging emails, replying to common threads, and pulling in relevant docs.

Here’s what exposing Gmail via MCP might look like:

• Tools `send_email`, `reply_to_thread`, `archive_message`, `search_inbox`

• Resources full message content, thread history, email metadata

• Prompts “summarize this thread,” “compose a polite follow-up,” “respond with a calendar link”

Now the agent doesn’t need hardcoded API calls. It can dynamically:

• Discover capabilities

• Reason over semantic tool descriptions

• Invoke actions through the shared grammar of MCP

This is what makes the design protocol-native.

Instead of embedding business logic in your orchestration layer, you externalize capability semantically. The agent orchestrates based on intent and environment—not brittle flows.

Even more interesting: multiple agents (say, a sales agent and an exec assistant) could share access to the same Gmail MCP server, yet interact with it entirely differently—based on their role, memory, and task.

This kind of decoupling is a hallmark of protocol-native infrastructure.

To find out, I gave myself a constraint: build and deploy a functional Micro-SaaS frontend in just a few hours.

No manual coding, no custom backend — just AI-powered tools and smart integrations. The goal? Move from idea to live site using tools that streamline every layer — from UI to auth to deployment.

I used the following youtube tutorial to go through the experience. I must say, I was skeptical of the claim of producing an app in 19 minutes (it wasn’t), and the app is not exactly a MicroSaaS but front-end landing page—I was still happy with what I accomplished in the few hours.

👉 In this post, I’ll walk you through how I built it, with links to the source code, deployed app, and the actual UI.

🛠️ The AI-Native Stack I Used – Cursor, v0.dev, Vercel, and Clerk

This was my stack: AI in the driver's seat, with just enough structure to ship fast.

• I used Cursor as my AI-powered code editor — it let me edit, generate, and debug code directly in the IDE with contextual AI help.

• For the UI, I turned to v0.dev, which generated Tailwind-based components from simple prompts like "generate a pricing section."

• Clerk made user authentication effortless, and Vercel handled deployment with a GitHub link and one click.

I had no experience with any of these tools — except Vercel — but AI-native tooling made the rest feel seamless and near-effortless.

🎨 Building the UI Without Writing Code (v0.dev + Tailwind + Next.js)

The fact that I went from zero Next.js experience to a fully functioning landing page in hours blew my mind.

• With just a few prompts, v0.dev gave me clean Tailwind-based UI sections for the hero, features, pricing, and login — no manual coding.

• It felt like magic: describe what you want → get code that works, with a visual preview so you’re not guessing.

• I’ve built frontends before, but they took days — this was fast, focused, and Figma-free.

It’s not perfect yet though: v0.dev still generated Shadcn components despite me explicitly asking for only Tailwind.

🧑‍💻 Using Cursor as a Co-Pilot to Write Code

Working with a freshly generated prototype codebase inside Cursor felt surprisingly natural — like I’d been using it for years.

• Chatting to generate or modify code felt intuitive, and most of the time, Cursor got the changes right on the first try.

• It really shines when cleaning up messy AI output — refactoring imports, fixing styles, or restructuring components was fast and fluid.

• My aha moment? I asked, “v0 generated Shadcn components instead of Tailwind, can you undo all the changes we’ve applied so far” — and it rolled everything back with one command.

  ---

  🔐 Adding Auth with Clerk

Getting auth working in the first version of a prototype felt borderline insane.

• Authentication is usually something I push to the end — it’s messy, time-consuming, and easy to get wrong.

• But with Clerk, I had Google login, sign-up, and profile management working in minutes, all with just one CLI command.

• The drop-in UI looked great out of the box, and I didn’t write a single backend route.

This wasn’t just auth — it was production-ready auth from day one.

🚀 Deploying with Vercel

Deploying with Vercel was the most anticlimactic part — and I mean that in the best way possible.

• I pushed my code to GitHub, connected the repo on Vercel, added a few environment variables, and hit deploy.

• No config files, no Docker, no weird build errors — just a live site in seconds.

• It felt like publishing a doc, not deploying an app.
  

  This is what shipping should feel like.

🪞 Final Reflection

This experience completely shifted how I think about building protoypes.
Getting prototypes working used to be slow, messy, and full of compromises.
Now, with AI-native tools, not only is the first version easier to build — but iterating on it is shockingly fast too.
It’s hard to imagine doing this kind of work without AI in the loop anymore.
We’ve crossed a threshold — and there’s no going back.

🔗 Explore the Build

💻 View the Source Code
🌐 Live App on Vercel

I would not call myself an expert in Artificial Intelligence, but my journey in this area spans a longer time frame than most.

Early days: Undergraduate Program in Pune, India

In 1995, when I was in the third year of my Computer Engineering program at Pune Institute of Computer Technology, we had the option of choosing an elective for our final year.

Thanks for reading Product and Flow! Subscribe for free to receive new posts and support my work.

Artificial Intelligence was one of the electives.

I have always been a forward-leaning person regarding technology adoption, and I picked the coursework because it sounded “sexier” than compilers :-).

Although I was somewhat disappointed by the state of the art, the promise that computers would magically do grunt work for humans fascinated me.

Master’s program or how I almost didn’t land in the US because of AI?

When the opportunity to do a Master's in CS presented itself, I picked the University of Cincinnati, where Professor Raj Bhatnagar specialized in Data Mining, Pattern Recognition, and AI.

The year was 1998, and India had just concluded the Pokhran nuclear tests. The sounds of sanctions were in the air. When he heard that I wanted to specialize in AI, the US visa officer told me to return home because he needed time to decide (while he kept my passport with him!!!).

The visa officer was thinking about the implications of AI x Nuclear Tests!

I was in limbo for two months before my visa was granted. It was a somewhat stressful period.

Once in Cincinnati, I took a few AI courses, but now it is too far back in time to remember what they were. I remember writing some trees for homework more than any classical ML pattern recognition work. Prolog, for writing programs that made decisions, was interesting enough but too slow to do anything useful, and I was at a crossroads because I was in complete love with Java.

AI and ethics: Implications of AI being used in war

When the opportunity to pick a master's project came up, I found myself walking into a program for a neighboring Air Force base—this was a military-focused AI research project.

The military aspect made me pause, and I thought deeply and hard about the implications of AI for war (and thought a lot about the visa officer :-) ).

I chose to explore projects with commercial rather than military aspects, so I switched out of the ML lane and landed on a Data Mining project.

The project was fascinating as I wrote Agents (IBM had a technology called Aglets) in which a computer agent would go into different environments) to answer specific questions.

The chosen environments were representative of DMV data and health data (I forget the specific database), and the questions were like, “Do cigarette smokers have a higher propensity to land in accidents?”

The intent with the different environments was that neither DMV nor Health data would be publicly available, but you had negotiated restricted and partial access to data in those environments.

The biggest challenge was getting to any database of a reasonable size to do anything interesting.

I also remember lecturing in a student body venue about how AI could be used to answer web search queries, book tickets, or build travel itineraries, removing humans from the loop and the gruntwork.

After graduating in 2000, I found that there were really no jobs in AI or Machine Learning, and frankly, the Java division of Sun Microsystems was an epic place to land.

From here on, I lost touch with the field.

Reengaging with AI and planting the seeds of Launchable

About 16 years later, I started the Deep Learning Nanodegree coursework on Udacity. I worked on it for six months and did enough assignments to get my feet wet. However, I couldn’t finish the final project because of work pressure and, candidly, because my programming skills had rusted away. Thus, I needed way more time to complete the assignments than I could allocate.

I loved the course and concluded that AI had advanced far enough that the underlying technologies would be game-changers.

I started looking for opportunities to use the technology in the workplace but was way ahead of the adoption curve.

Eventually, I decided that rather than convince people to incorporate AI into the products at the companies I work for, I would build an AI/ML company because it was less of an uphill battle.

I wanted to build the next generation of companies, and that was the birth of Launchable.

Though I haven’t been involved in the coding side of the house, I have enough practical experience building a company and running marketing and sales for a company that is selling an AI solution. This is active “AI Product Management” work, which seems to be the new buzzword.

Lately, I have delved deeper into the tech side of the ML space and have been reading Hands-on ML by O’Reilly.

Over the next few months, I intend to explore the LLM space more deeply. I picked the ActiveLoop Langchain course last year and plan to revisit it because I parked it aside as I decided to delve deeper into the fundamentals of ML.

The end goal remains the same as when I first got into AI in my undergrad program: Incorporating AI into products to remove the grunt work from humans.

So you are a PM and you want to started working in Artificial Intelligence?

I have been working in AI for the last 5 years now. As a background, I started my company because my hypothesis was (5 years ago) was that “AI is the imminent future” and I was annoyed that the adoption of the technology wasn’t happening fast enough. Rather than wait for others to do something here, I decided to “be the change you seek,” and started a company in my domain.

The good news today is, you don’t need to go through my route to start working in AI. You can’t escape the damn thing (AI) today :-) and there are plenty of opportunities around…

So what I can tell you (from experience) is that in order to work as a successful Product Manager in/using AI, you need to first be a solid Product Manager, specifically in the following three areas:

• Domain expertise: An absolute grasp on your domain and the problem space. So that you can ask the question ”Does the problem space lend itself to AI and in what ways?”

• Audience: their behaviors, their propensity to adopt new technologies specifically AI. So that you can ask the question “How should you introduce AI in the problem space? Should you be incremental or disruptive?”

• PM craft: ability to tradeoff the transient value versus long term value—because if you look around today, everybody is sprinkling AI and building features/companies that aren’t defensible. (Plus, the first two bullet points can only work well if your craft is strong.)

So, here's the 1 tip I would give you if you wanted to be in AI.

Side note: I know that there is a mad-rush at the moment to get into AI as if it is a “scarce commodity.” It isn’t! We have entered a new era of computing and one that will remain with us just as the “internet” or “desktops” became the norm when they were introduced.

Thus, over a period of time, every PM will be introducing AI to their products.

So you need to “slow down so that you can speed up.”

Get a grasp of the landscape and fundamentals of AI/ML

Step back for a few months, catch up on the fundamentals, map out the landscape where you will be playing in. Build the basic body of fundamentals so that you can sit with your engineering counterparts and understand why certain tradeoffs will be made.

While you build the understanding of the landscape, ask yourself where in the existing product can you bring in the technology and how would it make the lives of your audience better. If you find a compelling use-case, go through the usual PM route to introduce that as a feature for your audience

Not all lessons are created equal.

Some lessons we learn are small. They are little reminders along the way of what truly matters. Other lessons are giant. They fundamentally change the course of our entire lives.

Over the past 5 years as an entrepreneur building a B2B AI company for software engineers and quality professionals, this is the single most important lesson I've learned about selling an AI solution to engineers. (I am the co-CEO and co-founder of LaunchableInc, an AI/ML company for software engineers and software QA in the DevOps arena)

Engineers want to understand what’s in the AI black box.

What makes an engineer an engineer is their inherent curiosity to see how things are put together. They want to understand the individual Lego blocks so that they can put them together.

However, diving deep is a dual-edged sword. And here's why.

AI is greenfield; most engineers haven’t learned it in engineering school. Everybody is picking things up today.

Thus, they tend to get lost if you dive deep and don’t have the mental model. Losing engineers on the sales call is especially true if you are with multiple engineers with different backgrounds and skill levels.

It becomes death by a thousand cuts.

On the other hand, if you shield them entirely, you come across as a “marketing” person and lose credibility.

So what’s the solution?

There is a Goldilocks zone. There are edges of a road that you draw for them so that they can traverse the path to you.

Explain your solution using non-AI terms I have learned that the correct pitch is to help people build a mental model and apply their understanding to an existing framework so they can go back and explain what you do to their colleagues.

Help them evaluate your solutions efficacy The second has to help them explain and evaluate the efficacy of the underlying model.

AI brings a new paradigm; people must understand that you likely cannot explain individual decisions, but you must assess the model statistically. I have found the statistical underpinnings weak and consequently prove to be a big challenge with development teams.

There you have it. If you are in sales or product marketing, you need to figure out how to draw these two edges of the road so that prospects can walk the path to you.

You will encounter a considerable learning curve as you start learning AI.

The landscape is far and wide. Most books and articles start with linear regression. While easy to learn and use, I found that some individual building blocks appear in approach after approach.

If you understand these Lego blocks, subsequent reading happens much faster.

• Cost or Error Functions are mathematical functions used to measure the difference between a model's predicted values and the actual value of the data. They help assess the model's performance and guide the optimization process to improve accuracy.

• Gradient Descent is a core algorithm used to get to an optimized solution. It is an iterative approach that works on getting to the minimum value of the cost function. Rather, it finds the best way to get to the parameters required for the ML algorithm to do its job well.

• Hyperparameters are parameters not learned from the data but set before the training begins. They govern the training process and influence the model's performance. A standard set of parameters and tuning approaches appears in algorithm after algorithm.

  Thanks for reading Journey through AI: Learning and building intuition in AI! Subscribe for free to receive new posts and support my work.

  Subscribed

For anyone in the industry, this stuff is common knowledge._ But to those who haven't lived "a day in the life" in AI, you discover the Lego blocks after reading multiple ML algorithms.

Lock these concepts in as soon as possible, and they will make the rest of the reading easier.