But before I get into my take, some background: we have been using agentic IDEs for a hot minute (copilot then cursor then claude-code). The move to claude-code (CC) was the real game-changer for us. I remember that first command-line boot sequence of CC fondly because we gossiped like giddy teenagers about how magical it was. The phrase we kept coming back to was that it felt like the “iPhone moment” for agentic development — where our roles had fundamentally shifted from being “main-loop engineers” to that of mere copilots.

But after the first week or so, we realized that making CC a truly 10X tool necessitated adapting our workflows and building abstractions to have it produce valuable outputs (not just AI slop).

The key discovery we made was that writing good requirements documents was crucial to having claude-code produce useful outputs without constant back-and-forth.

So, when Kiro was revealed, architected entirely around addressing the challenge of producing crisp and precise design documents before a code generation handoff, we immediately imagined that it would be even better than claude-code.

Putting Kiro through its paces

To see how it would compare to my current development workflow with Claude-Code, I put Kiro to the test by tasking it to develop a new feature from soup-to-nuts for an opensource MCP server we released named mcping-mcp — an MCP that lets a client call a tool that sends desktop push notifications on OSX.

Goal: add a “schedule notifications” to have the MCP store and send desktop notifications for an arbitrary date-time in the future.

Phase 1: setting up the kitchen

To get Kiro rolling, it required the generation of Steering Documents — a product spec, a tech stack doc, and a structure doc. Think of these as a “split-up” CLAUDE.md that you might generate. The purpose of these artifacts is to give Kiro a guide on how to traverse and understand the major components of the project.

• Product document → defines the product spec and “what it even is.”

• Tech document → captures stack, libraries, SDKs, etc.

• Structure document → outlines project structure and overall architecture pattern.

While this is a nice, polished workflow to scaffold context, it’s not revolutionary. In CC, we produce similar steering documents by having CC generate its own CLAUDE.md or by using tools like superclaude to generate structured document types like an ARCHITECTURE.md.

Recently, we’ve been using our own home-grown “steering framework” — more on this in a future post.

By default, these steering documents get injected into every Kiro model call unless you spend time crafting matcher rules for when a steering document should get pulled into a context. That means unless you proactively maintain a complex ruleset, you’re effectively dragging the entire bundle of product/tech/structure context into every generation. The cost is twofold: context pollution (irrelevant details bleeding into the context window) and token exhaustion (larger projects chewing through capacity fast).

The result of this design choice is that scoping is structural and not persona-driven. Rather than having persona-specific subagents — like a “QA engineer” or a “DevOps engineer” with fresh, clean contexts as Claude Code offers — Kiro defaults to an “omnipotent” agent that is expected to know every operating context.

takeaway: Kiro’s steering document generation is a nice polished IDE experience but its structural rather than persona-driven context approach is limiting and will lead to context pollution and poor generation.

Phase 2: let’s get cooking

Ok enough about steering documents. I was excited to get into seeing how it took requirements, came up with a design, and started biting away at the tasks.

I began by handing it off the simple goal we outlined earlier: “add a “schedule notifications” to have the MCP store and send desktop notifications for an arbitrary date-time in the future.”

What I expect to happen at this point was for Kiro to go through a “20-questions” briefing with me to extract out the key elements of my requirements. Instead, it went immediately into generation mode without any further inputs.

In the span of a few seconds, it generated a massive requirements document in a monolithic generation adding user stories, edge-cases, and acceptance criteria. At the end of the generation, it immediately began prompting me to move onto the “design” phase. This eagerness to dive into the next phase made me feel like requirements gathering were being treated as a checkbox, rather than a critical phase.

This was probably the most disappointing interaction in my Kiro experience so far.

Kiro was supposed to be a better way to generate requirements. I fully expected it to be a conversational, socratic experience — like a white-boarding session with a teammate to come up with a draft. Instead, it ran with a “one-line vibe” and dove immediately into design and task generation.

Drafting requirements before moving onto design is the single-most leveraged part of agentic flow — if you get this wrong, every downstream step devolves into AI slop (design —> task generation —> code generation).

Looking deeper into the requirements document that was generated, I also noticed that it followed the same rigid structure pattern that the steering docs had done.

The risk with this rigid structure (like the steering documents) is that it relies on a single, omniscient reader to carry forward everything. There is no native persona-specific drafting. It would’ve been cool to see the requirements broken apart or built upon by a series of experts such as a “product manager” and a “software architect”.

This was becoming a recurring theme — which I will now refer to as “one persona to rule them all” or (OPTRTA) — or perhaps “Saurona” would be more memorable.

I was about to give up and move onto design when one last tantalizing feature caught my eye: a shiny REFINE button on the top of the requirements file. I hoped it might go through an interrogation or reflection flow. Instead, it just linted the doc ensuring that the WHEN/THEN/SHALL keyword format was respected.

Phase 3: design — it can draw some nice boxes!

After requirements, Kiro marches straight into the design phase. Requirements, Design, and Tasks (the final phase), are treated like bolted on additions on a conveyer belt.

In one shot, Kiro generated an architecture diagram, a data-flow section, and outlined components and interfaces. This was impressive, but again the lack of a back-and-forth diminished the value of the final product. Where was the reasoning? The back-and-forth? If this were an engineer I was working with, I would expect them to suggest a variety of options, discuss tradeoffs, define responsibility boundaries of components, etc.

Kiro does give the option to “Follow Along” as it generates these artifacts but watching it do this is the equivalent of watching a printer spool rather than watching an intelligent engineer employ their faculties of reason and experience. This was probably the last place one could catch a shaky requirement or false assumption.

In a greenfield or toy project this kind of yolo design could work. However, yolo design in brownfield projects will necessarily compound technical debt.

Phase 3: task flow - ok this part was cool

One of the biggest challenges with requirements → design → tasks in claude-code is that there is no in-built framework for orchestrating a DAG (directed acyclic graph — basically a dependency graph) between tasks. In vanilla claude-code, the best it can do is have a “todo list” which is serially executed.

To get around this, we have used several frameworks such as claude-task-master. As I alluded earlier, we’ve moved onto using an internal task-orchestration tool that we’ll share more about in the future.

In contrast to claude-code, complex task orchestration a first class feature in Kiro. Finally, something it excels at. From the requirements and design artifacts, Kiro generates a series of tasks, visible to you in markdown and internally manages them with a dependency system.

Once these tasks are generated, Kiro can automatically start implementing them. It will stop and ask you for permissions to run bash commands, make tool calls, or call MCPs — the typical permission flow that we’ve experienced in IDEs and claude-code.

TLDR; Kiro does a good job of task generation, task-dependency management, and task execution.

Caveat: code-generation based on tasks is only as good as the context they were generated from — the artifacts of the previous phases. So while this execution is sleek, it inherits shaky foundations.

Models & Pricing — the final nails in the coffin

Even if you can forgive the rigid workflows and the “one persona to rule them all” mentality, Kiro still falls short on two fronts that matter most in practice: models and pricing.

First, the models.

Kiro only supports Claude Sonnet 3.7 and Sonnet 4.0— not Opus nor any OpenAI models such as GPT5.

This is a serious handicap. The whole premise of agentic workflows is that they depend on reasoning quality. If Amazon (sorry I meant Kiro) doesn’t have access to these frontier models, it will never be able to keep pace with claude-code or Codex.

Second, the pricing. A universally derided shortcoming of Kiro. Kiro charges on “spec” and “vibe” requests with a usage-based overage model. The delineation between these two types of requests is fragile. I mean what is a “spec” request? What if my spec is tiny and I have 500 spec requests which in actuality only use 30k tokens and 100 vibe requests which use 10k tokens? What if I had 1000 tiny vibe requests that only used 5k tokens? I would get penalized on a per-request basis rather than on model usage.

This feels like a deja vu of Cursor’s failed experiments which resulted in community outrage. Engineers don’t want to count tokens every time they hit “generate” — a claude-code like cool-down with resets of token allocation would’ve been preferable.

Which leads to the obvious question: why would anyone bet their daily workflow on a tool that’s underpowered, overpriced, and outgunned

Parting thoughts

I was looking for that same “iPhone moment” when I booted Kiro. Instead, it felt like unwrapping a birthday gift at twelve only to find a book when you were hoping for the videogame you’d pined for all summer.

The one thing Kiro did clarify for me is that context engineering is the whole game. Without it, no agentic IDE will scale. And right now, Anthropic is the only one of the “big three” (Anthropic, OpenAI, Cursor) shipping tools that make context engineering truly usable for developers.

At toolprint.ai we’re committed to pushing this further — building tools that improve your context and reduce pollution. Explore what we’re building on GitHub, or take a look at hypertool-mcp, our MIT-licensed project for giving your apps the right mcp tools without the baggage.

This wasn’t me being reckless. I wasn’t trying to push the limits… much. I was just tired.

I’ve been preparing to write a series of posts outlining all of the iterations of “vibe-coding” developer environments I’ve experimented with and how I’ve been able to effectively utilize $5k+ in Anthropic token usage in a 30-day period, but given this situation I figured a cautionary tale is more helpful to share.

I was building yet another Rust MCP server idea I wanted to experiment with and Claude had made a small mistake while working on the final touches of an elegant solution getting ready to be pushed to Github — it had created a directory called ~ inside the project repo, like ./~/.cargo. Harmless enough. I could have deleted the directory myself easily but I’ve gotten so used to staying in the agent chat that I asked Claude to do it instead. Permission system worked just fine, as Claude asked if I wanted to delete ~/ , which seemed right in the moment because most of the time relative paths proposed are based on the project directory, so my fingers almost immediately with muscle-memory hit Enter to approve.

Yup, I just approved Claude to run “rm -rf ~/” — delete my entire home directory.

That one missing ./ was the difference between cleaning up a local project junk folder and wiping every file that wasn’t protected by some sort of additional UNIX settings permissions.

It only took a second to question myself and realize that probably wasn’t smart. I hit Ctrl-C. Some folders were still there… okay, maybe it only got a few folders and I stopped it in time. I could still see some directories.

Then things started changing:

• An IDE refreshed it’s view to show absolutely nothing in it’s workspace.

• Terminal commands I had aliased in ZSH started failing.

• Screenshots and other icons on my Desktop vanished.

Took a full two minutes until things seemed to stabilize. Claude must have still had a background thread running the deletion and I didn’t think quick enough to know how to stop it in time.

Knowing that if anything was to be recovered using the fact that filesystems simply mark file blocks for eventual garbage collection. I researched recovery options. Disk Drill looked promising and I tried it on the maximum full-disk settings, but after some research I realized that SSD TRIM had already done its work — deleted blocks were gone for good pretty quickly.

At that point, I started to try and inventory what would have been lost. Time Machine in the upper right said the last backup was three days ago. Maybe I’d just lost that MCP server I’d been working on and I’d be able to restore to that point.

Except it wasn’t. It was three days and two years ago — when I’d first bought the laptop.

Why? Because I’d turned backups off while in SF for the YC W24 batch and never turned them back on (I back up to my NAS at home and the latency was pretty bad).

That’s when it hit me: I hadn’t just lost recent code. I’d lost everything.

Root Cause Analysis

I worked on the internal incident management systems at AWS for 4 years — SWIM Team (for you Amazonians) — so it’s only fitting I write up my own RCA. Don’t worry, it won’t be as long and detailed as a real one:

T-00:00 — Approval
Agent asks to delete ~. I read it as ./~. Approved.

T-00:01 — Deletion starts
Claude kicks off a background rm -rf of my home directory.

T-00:05 — Realized what I’d just done
I hit Ctrl-C, thinking maybe I caught it in time.

T-05:00 — Attempted recovery
Research, install recovery tools, run deep scan in kernel extension mode. No recoverable files — TRIM has already zeroed freed blocks.

T-30:00 — False hope
After concluding data was unrecoverable, checked Time Machine detail window (not just hovered over the icon) — no backups since Aug 2023.

Outcome: total loss of home directory — personal files, work projects, SSH keys, dotfiles, etc.

Root Cause: Human Error

5 Whys: (I won’t really need 5.)

• Why did I approve it? — I was tired and vibe-coding 4 things at once.

• Why didn’t I have backups? — I always thought I was too busy and I’ll get to when I have time.

Guardrails: Incident Management at Scale

If there’s one piece of wisdom I’d like you to take away from this article it’s this:

Mistakes are inevitable. The goal is to make them inconveniences, not catastrophes.

Your responsibility is to make sure that one mistake can’t take the whole system down.

In practice, that means:

• Guardrails, not guidelines — “Be careful” doesn’t scale. Habituation is real.

• Approvals for judgment calls only — If it’s obviously safe, automate it. Humans should only handle the really ambiguous cases.

• Block unsafe by default — Destructive ops should require explicit opt-in and extra checks.

For agent-first workflows, we can translate that to:

1. Pre-execution sanity checks — MCP hooks that parse and flag risky commands.

2. Soft deletes by default — Route destructive actions through a “time-delay” delete.

3. Sandbox isolation — Don’t let agents near your host OS unless necessary.

4. Out-of-band oversight — A second set of “eyes” adds redundancy.

This isn’t about slowing down — it’s about not betting your entire environment on you spotting one missing ./ after a 14-hour day.

Post-Incident Action Items

Yes, of course I need to set up Time-Machine backups, but I don’t think that’s really enough. Even a Time Machine snapshot from five minutes ago can still miss a significant amount of vibe-coded changes and it’s quite common to exclude git workspaces from it due to the massive number of small files to track.

Layered safeguards are the only real defense:

• Push to remote often — Public or private repo, branch hygiene or not. Anything is safer off your local disk. Write a Claude Code Slash Command to commit and push if it helps. I’m going to add a feature to vibe-workspace that automatically pushes repos with dirty branches after a set time of inactivity for safety.

• Separate design docs from code — PRDs, diagrams, prompts… keep them somewhere the AI can access later. I’m looking forward to more tools storing these in a way that’s accessible for the Agent, but not tied to your local in-progress code. If you have them backed up you can re-create code pretty quickly.

• Develop in sandboxes — Containers or VMs keep some types of accidents contained. I personally avoided it a bit because trying to load each project in VSCode with a dev-container felt slow and doesn’t always let you test multiple projects working together easily, but with new tools like VibeKit, it’s nearly frictionless to launch Claude Code within a local sandbox, so I have no excuse.

• Use safety guardrails — Bash safety wrappers like trash-cli, pre-tool hooks, anything that gives you one level of “undo” on dangerous operations. I would strongly advise putting in your agent’s memory: “You MUST provide absolute paths for any destructive command”.

• Reduce approval-fatigue —I’ve recently released superego-mcp specifically for this purpose. Claude should always get second opinion before proposing a dangerous call (even if it’s from itself). If those eyes are always you, approvals are frequent, and the approval rate is over 90%, you will train yourself to approve without thinking critically. Spread the repetitive approval load back to other agents such that if an approval comes your way it MUST be a pretty tough call as to whether it’s a good idea or not.

Incident Review

Once I realized what had happened, I actually didn’t panic. Instead I thought:
This is the kind of mistake you read about — whether or not the cause was human error, it’s 100% my fault for not using enough guardrails and having backups.

TRIM meant there’d be no magic recovery. My backups were years out of date.
But after some time to reflect I took another inventory: most of what mattered was safe — code repos mostly in Github, personal stuff on Google Drive or my NAS, old SSH keys happened to be on another laptop. I’d survive.

What I lost were the small, untracked things: downloads, screenshots, local configs. As for everything else? I had a sudden realization: I could recreate most within a day.

For the recent projects I had asked Claude to code it from scratch and that was only about 12 hours of total wall-clock time. I’ve already re-implemented all the code I lost that was truly important. To be honest: it actually might even be better than before. I was able to take the lessons I learned from the first iteration and write it again from scratch without any tech-debt.

You Only Lose Output

I fully support YOLO — just not the acronym you’re thinking of.
For me, YOLO now means You Only Lose Output.

You still move fast. You still experiment. But you build your workflow so the worst case is losing artifacts — never the ideas, architecture, or ability to rebuild.

If you keep the concepts and context intact — and you have the right tools — the rest is reconstruction. In my case, I was lucky that what I lost was code and I was able to have AI rebuild a day’s worth of work in a day. That’s a loss I can walk away from.

And that’s one aspect we focus on at Toolprint.ai: building systems for agents that make it possible to provide a goal and the right tools to generate the desired outcome quickly. You should only need to focus on providing what’s most important: the input.

Move fast. Break things. — but only the things you can rebuild by tomorrow.

Don’t get me wrong, Cursor is a great product and it was a step-function above using early versions of Github Co-Pilot in VS-Code, but recently I’ve gone entirely back to the terminal. The IDE was just becoming memory overhead and I couldn’t have more than a few instances open at once without my laptop complaining about running out of memory. I’ve already been convinced we’re undergoing a transformational shift in software development for a few years now, but something uniquely changed once I started using Claude Code and forcing myself to try “vibe-coding” (despite my initial aversion to the term itself).

What really cemented the notion that we have transitioned past the event-horizon of moving into this new paradigm was some statements made by the team at OpenAI during the GPT-5 announcement livestream. They said they wanted GPT-5 to be “the ideal pair-programmer to work with.” They were demoing inside Cursor, but they barely used the screen — just a small panel showing what the model was already implementing on its own.

That’s the wrong interface.

When the agent is doing nearly all the work, you aren’t driving — you’re the co-pilot.

The job isn’t to live inside a code editor; it’s to guide and approve what’s being built. And for that, the bloated, human-centric interface of an IDE becomes a bottleneck, not a boost.

This isn’t the first time developers have gone through an interface inversion. My father — also a software engineer — still remembers moving from punch cards to terminals. He’d carry stacks of punched paper to the ‘input window’, hand them to an operator, and wait until the next day to find out if his program even compiled. The shift to terminals was a revolution: instant feedback, interactive workflows, a drastically tighter development loop.

But the human was still in the driver’s seat. You wrote the code. The computer executed it. Now, with agent-first development, that relationship is flipping entirely.

The Three Phases of AI-Assisted Coding

The move toward agent-based development isn’t binary — it’s a spectrum:

🚘 Phase 1: You’re Driving
The GitHub Copilot era. You type the code, the AI fills in small gaps. Autocomplete with flair, but you’re firmly in control.

🤝 Phase 2: You’re Pair Programming
We’re here now. Models like GPT-4o and Claude Sonnet 4 can reason deeply about architecture and implementation. You delegate entire functions, services, and refactors. We currently call it vibe coding — watching and tweaking while the agent does the heavy lifting — but we should really come up with a better term.

👨🏼‍✈️ Phase 3: You’re the Co-Pilot
The inversion. The agent is now the primary developer. You set goals, review diffs, and approve features like a tech lead at a big company. Models like GPT-5 and Claude Opus 4.1, especially when paired with agentic coding frameworks, push us past this threshold — they can operate autonomously within constraints and coordinate complex systems.

You’re no longer the driver. You’re the navigator. The co-pilot.

The only issue? You’re still sitting there gripping a steering wheel. What you really need is a map. A steering wheel keeps your eyes on the short-term; a map lets you chart the entire course ahead.

Where We’re Going, We Don’t Need IDEs

Modern IDEs were built for human perception — syntax highlighting, file trees, lint warnings — everything assumes you’re the one typing. As we keep moving into this new paradigm we can no longer assume this is the case. The agent is doing all the work while you’ve probably already switched to another window approving the plan of a different agent.

Now it’s waiting for you. You’re the bottleneck now.

The agent is in the race-car ready to get back on the track, but pit crew is waiting on you as the crew chief to manually check everyone’s work and give the go-ahead.

As the excellent ClaudeLog post You Are the Main Thread points out:

Before, being “unproductive” meant wasting just your own time: opportunity cost × 1.
But with AI agents, every idle moment also wastes all the parallel processes you could have initiated: (opportunity cost × 1) + (opportunity cost × N).

That’s why heavy GUI-based workflows feel mismatched. You don’t need to see the whole file — you need the diff, the intent, and the “why,” in whatever format makes approval fastest.

Right now, the terminal is making a comeback because it strips away the overhead. Commands are structured, outputs are parseable, and agents can work inside it without the clumsy mouse-and-menu dance of an IDE. But this is a bridge, not the destination.

The future is not a terminal — it’s a high-level orchestration layer that routes tasks to the right agents, equips them with the right tools, and surfaces only the decisions you need to make. The faster you unblock them, the faster the system builds itself.

You’re Not the Smartest in the Room Anymore

Engineers love puzzles. That dopamine hit from solving a gnarly bug or finally cracking a tricky algorithm is part of why we got into this work. For decades, being the person who could write the cleanest, most efficient code was how you proved your value.

But in the age of agent-first development, you’re not the fastest or most precise coder in the room anymore — not even close. Models like GPT-5 and Claude Opus 4.1 are already outclassing humans at low-level implementation, and they’re only getting faster.

That doesn’t mean you’re obsolete. It means your job is moving up the stack:

• Deciding which problems to solve first

• Choosing the right approach and tools

• Setting constraints and quality bars

• Coordinating work across multiple agents (and eventually, agent teams)

It’s the same shift that happens when a senior engineer becomes a tech lead at a FAANG company. You stop coding every line yourself and start directing the work of others — approving pull requests, reviewing architecture docs, ensuring the system as a whole works as intended.

That’s the mindset shift every developer will need to make:

• From “I write the code”

• To “I orchestrate the code being written”

And orchestration at scale is not something you can do manually. When you have 5, 10, or 50 agents working on different parts of a system, you need tooling to manage workflows, surface the important decisions, and make approvals painless.

Tooling for the New Hierarchy

In an agent-first workflow, there are two very different audiences for tools:

For AI Agents
Agents need tools they can call autonomously — APIs, execution environments, and specialized functions. These tools must be machine-native: predictable inputs, structured outputs, and no wasted rendering for human eyes. Think external APIs, CLI tools, and automation frameworks.

For You (the Co-Pilot)
Your tools aren’t about doing the work — they’re about directing it. You need interfaces for orchestration, approvals, and strategy. These must be human-native: visual summaries, diff views, dependency graphs, and dashboards that surface only the decisions that matter. Examples include approval dashboards, agent orchestration panels, and system architecture viewers.

The tricky part: you have to manage both layers at once.

If you’re leading multiple agents, each using a rotating set of tools, you need a system that dynamically routes the right tools to the right agents, minimizes context-switching, surfaces blockers early, and keeps everything auditable.

Your job as the co-pilot isn’t to hover over the agent’s shoulder — it’s to design and manage the ecosystem they operate in.

Conclusion: Embrace the Inversion

The history of software development is a series of interface shifts:

• Punch cards → terminals

• Terminals → IDEs

• IDEs → ???

Each shift changed how we interact with machines, but until now, the human has always been the driver. That era is over.

We’ve crossed the midpoint of a three-phase transformation:

1. You’re driving – AI helps occasionally

2. You’re pair programming – you and the agent are equals in the IDE

3. You’re the co-pilot – the agent drives, you direct, approve, and scale the work

In the future, your value isn’t in how fast you type — it’s in how well you orchestrate. You’re no longer the person at the keyboard. You’re the architect, the lead, the one keeping the system aligned with the vision. The agents are your team.

That requires a new class of tooling — not just for coding, but for coordination. Tools that give agents the capabilities they need without drowning them in irrelevant options. Tools that surface only the decisions you need to make, when you need to make them. Tools that keep you out of the critical path so the system can keep moving at full speed.

That’s exactly the kind of philosophy we have at Toolprint.

We recently released HyperTool-MCP, which lets you dynamically select which tools to expose from your MCP Servers, making sure agents always have the right set of tools at the right time — without waiting on you to configure them manually. It’s a first step toward the orchestration layer that will let one human direct hundreds of agents across thousands of tools.

The shift is happening whether you like it or not. Those who adapt will 10× their output. Those who cling to old workflows will be left behind.

It’s time to switch seats. Now you are the co-pilot.

What I came to realize halfway through was that it’s not that companies or their AI Agents that are using MCP but actually humans at those companies using MCP. They are trying to make MCP useful internally for their human teams and externally for their human customers.

TL;DR — humans use MCP not agents. For now (06/27/2025).

Where and how are humans using MCP?

Obviously, MCP, like any other machine protocol, is designed for computer/agent use. Humans are not designed to read JSON-RPC. To bridge the protocol <> human divide, engineers at these companies are connecting MCP servers to their agentic IDEs (like Cursor or Windsurf) and AI Apps like Claude. And then every internal API is wrapped with an MCP to make it available for use.

Now an engineer can pop open their IDE copilot and “chat” with an internal API they use to practically test how to interface with it before they build anything.

Ex. explore how to use the Products API or exploring the schema of a DB before writing any SQL.

If you can do this type of exploration and use, obviously Cursor can generate better code interfacing with it in the same way. Makes total sense. This is the productivity ladder for engineers within these companies.

So what does this mean for the rest of us? Well if you’re an engineer inside a company that hasn’t yet experimented with “AI”, writing an MCP server for an API that you interface with could be a great way to speed yourself up and use it practically. And the best part is when you decide to build an agent to do things for you, it can use the same rails.

So when does AI use MCP?

Putting aside all the hype of MCPs and agents, we should consider where we are in reality. The best way to figure this out (in my humble opinion) is to consider where we are in the adoption curve (in terms of which companies/users are using it). Thanks to ChatGPT I could draw this out in a few seconds:

The dream of AI is getting to a world of unsupervised agents doing productive work for us in the background and I do believe MCP will be a large part of facilitating this but we aren’t there yet. I’m going to propose another adoption curve. This one shows how MCP is being used and where it can go.

Humans will need to be front-and-center to build the tools to get us all the way to the far end of the adoption curve. We need better authorization for MCPs, guardrails for tool-use, better tool-selection to reduce hallucinations, and more. The dream of unsupervised agents is attainable but it will require some practical solutions first.

I’m a human. How do I get started?

For the absolute beginners

1. Skim the spec: https://modelcontextprotocol.io/introduction

2. Try out an MCP in your agentic IDE. I’d recommend the following ones to get started:

   1. Context7

   2. Linear

3. Proxy the MCP transport to these servers using mcp-remote and add it to your IDE’s mcp.json configuration.

4. Open copilot chat and start asking it to use tools!

If you want to try out MCPs immediately without setup

1. Join the free toolprint.ai sandbox which exposes 71 tools across 8 MCPs and start using it in Cursor. Start crafting “toolprints” (workflows that use these mcp tools across servers) — in 2025’s newest programming language: English.

(as one of toolprint’s authors, I’m not at all suggesting that it may be the easiest option here — that would be atrocious!)

I’ll leave you with an idea that Andrej Karpathy proposed in his latest talk — LLMs are like “people spirits”. We have designed them to mimic human behavior. If we can use MCPs today to make ourselves more productive, it is inevitable that the “people spirits” will use them similarly to usher in a world of productivity we could only dream of.