By Sahar Carmel
December 2025

I always have 4 Claude Code terminals open on my machine. One writes code. Three don’t touch code at all.

When people see this setup, the first question is always: “Why do you need 4? Isn’t one enough?”

The answer took me a while to figure out myself. And it’s connected to something I think most developers working with AI are missing.

The first stage is tactical: actually letting AI write the code. Not touching it. Reading, reviewing, pushing to production.

This is the foundational skill every developer needs to acquire. Many developers aren’t there yet — they still “fix” the AI’s code, still write themselves and use AI only for autocomplete. Those who’ve crossed this threshold feel the productivity jump.

But there’s a second stage that many miss, and it’s no less significant than the code writing itself.

The moment I understood the second stage was a few months ago. I had a bug in production. I did what we all do — opened the logging platform, searched for the error, copy-pasted to Claude.

Then I stopped.

What did I actually do here? I searched through logs. Read stack traces. Understood the context. Identified the relevant lines. And only then passed that information to the AI.

All that work — the searching, reading, understanding, filtering — is exactly what language models know how to do. And sometimes better than me. They don’t get tired, don’t miss lines, don’t jump to conclusions.

Now, every time I approach a task, I ask myself: How much of the information I need can the agent access on its own?

Not out of laziness. Because I understand that if the agent understands the essence behind the request — the planning will be better, edge cases will be covered, tests will be relevant.

This isn’t about prompting better. It’s about information architecture. It’s about restructuring your entire development environment so that your AI agent sees the same world you see.

Before diving into the practical side, it’s worth understanding why this matters at a deeper level.

Anthropic introduced the Model Context Protocol (MCP) in November 2024 to solve what they call the “M×N problem” — the combinatorial difficulty of integrating M different AI models with N different tools and data sources. Every new pairing traditionally required custom code, making it difficult to scale AI systems in real-world applications.

As the MCP documentation puts it: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.”

By February 2025, developers had already created over 1,000 MCP servers — connectors for various data sources and services. The ecosystem is growing because the insight is correct: an AI agent is only as good as the context it can access.

I started connecting all the information sources I encounter in my day-to-day work:

Each of these connections — whether through MCP, CLI, API, or Skills — the “how” doesn’t matter. What matters is that the agent writing my code sees the same world I see.

There are several ways to give your AI agent access to external information:

MCP (Model Context Protocol)
The standardized approach. Pre-built servers exist for Google Drive, Slack, GitHub, Git, Postgres, and more. You can also build custom MCP servers for proprietary systems. Since December 2025, MCP has been donated to the Linux Foundation’s Agentic AI Foundation, with backing from Anthropic, OpenAI, Google, Microsoft, AWS, and others.

Agent Skills
Introduced by Anthropic in October 2025, Skills are folders containing instructions, scripts, and resources that Claude loads dynamically when relevant. Unlike MCP which connects to external systems, Skills package expertise and workflows. They can include executable code for tasks where traditional programming is more reliable than token generation.

As Anthropic’s engineering blog explains: “Skills extend Claude’s capabilities by packaging your expertise into composable resources for Claude, transforming general-purpose agents into specialized agents that fit your needs.”

CLI Tools
Simple but effective. If you can run it from command line, your agent can too. heroku logs --tail, aws logs, psql queries — these are immediately available.

Direct API Access
For services without MCP servers, direct API calls work. The agent can hit REST endpoints, parse responses, and use the data.

So why 4 terminals?

One writes code. Three do enrichment work on tasks.

Here’s how it works: I throw three tasks from Linear into three terminals. Three agents work in parallel — asking questions, understanding context, searching existing code, checking logs. They enrich the task until it’s completely clear, asking me questions until it’s understood what needs to be done.

Then the fourth agent — the one that writes code — receives a prepared task. With all the context. With edge cases identified. With an understanding of why.

The coding agent never rests. It always has enriched work waiting.

This isn’t just a productivity hack. There’s solid research on why context matters for LLM performance.

IBM Research found that “the quality of the examples matters” when working with extended context windows. Making context windows infinitely longer may be counterproductive at a certain point. What matters is relevant context, not just more context.

Recent research on “context rot” from Chroma Research demonstrates that even frontier models show performance degradation as input length increases, often in surprising and non-uniform ways. The solution isn’t just bigger context windows — it’s smarter context management.

A study published in Towards Data Science found that “for many problems with complex context, the LLM’s effective working memory can get overloaded with relatively small inputs — far before we hit context window limits.”

This explains why my 4-terminal approach works: instead of stuffing everything into one context window, I’m using specialized agents with focused context. Each enrichment agent works with relevant information for its specific task, then passes a distilled summary to the coding agent.

Most people think of AI coding as “an assistant that writes code.”

I’m starting to think of it differently: a system connected to all my information sources, that understands context like I do, and where code writing is just the final output of all that understanding.

The code isn’t the main thing. The understanding is the main thing.

There’s another layer I want to explore — what happens when you connect this to product work and testing?

When the agent can give feedback on task difficulty before you start? When you can generate a test suite before QA even begins working?

Imagine this workflow:

1. Product creates a requirement in Linear
2. An enrichment agent analyzes it — asks clarifying questions, identifies technical challenges, estimates complexity
3. Before a single line of code is written, you have feedback on what edge cases to expect, what needs product decisions
4. After implementation, another agent generates test cases based on the full context — the requirement, the code, the discussions
5. QA receives a test suite to validate, not create from scratch

This closes loops that currently take days or weeks. Product gets faster feedback. Engineering starts with clarity. QA validates rather than discovers.

I’ll dive deep into this in the next post.

If you want to experiment with this approach:

1. Start with one integration. Pick the tool you check most often during debugging — logs, error tracking, whatever. Connect it first.
2. Ask the right question. Before every task: “What information am I manually gathering that the agent could access directly?”
3. Separate concerns. Don’t use the same agent for research and implementation. Let specialized agents do focused work.
4. Build progressively. Each integration you add makes the system more capable. Over time, your agent sees more of your world.

• Introducing the Model Context Protocol — Anthropic’s original MCP announcement
• MCP Documentation — Official docs with integration guides
• Equipping Agents for the Real World with Agent Skills — Deep dive into Skills architecture
• Building Skills for Claude Code — Practical guide to creating custom Skills
• Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research on context window limitations
• Code Execution with MCP — Advanced patterns for efficient context management

I share these insights and more in the Squid Club community — a Hebrew-speaking group of practitioners navigating AI-first development together.

Join Squid Club →

Thanks for reading. If this shifted how you think about AI development, share it with someone who’s still copy-pasting errors into Claude.

— Sahar