The Future of AI Coding: When Your Agent Builds Its Own Tools
I've been using Pi for the past few days, and it's already changed how I think about where AI coding tools are heading. Not because Pi does more than other tools. Because it does less—and then builds what it needs.
If you've read my previous posts, you know I'm skeptical of "vibe coding" and believe software engineering principles matter more than ever in the agentic era. Pi crystallizes that belief into a tool.
The Plugin Marketplace Problem
Every coding agent I've used—Cursor, Claude Code, Codex—has the same pattern: core features plus an ecosystem. Need GitHub integration? Download an MCP server. Need web search? Find a plugin. Need a specific workflow? Hope someone built it, or fork and modify.
This creates a dependency chain. You're waiting for someone else to build what you need, then hoping they maintain it, then configuring it to work with your setup.
Pi flips this entirely.
Four Tools, Self-Extending
Pi ships with four tools: Read, Write, Edit, Bash.
That's not a limitation. That's the foundation.
But here's what makes Pi different: Pi ships with its own documentation, and the agent can read it.
When you ask Pi to extend itself, it:
- Reads the extension docs at
docs/extensions.md - Looks at examples in
examples/extensions/ - Writes TypeScript that hooks into Pi's event system
- Hot-reloads so you can test immediately
- Iterates until it works
This isn't "here are some cool plugins." This is the agent building its own capabilities on demand.
Capabilities That Spread Across Sessions
Here's what clicked for me recently.
I have Session 1 open, working on a backend service. I need a specific way to format database migrations. I describe what I want, Pi writes a skill—a markdown file with a name and description—and saves it to ~/.pi/agent/skills/.
---
name: db-migrations
description: Use when creating or modifying database migrations
---
# Database Migration Style
...
Meanwhile, Session 2 is open in another terminal, working on a different project. S2 needs to create a migration, checks ~/.pi/agent/skills/, and discovers the skill S1 created an hour ago. It reads the skill and uses it.
Session 1: "I need a skill for X"
↓
Pi writes skill with description: "Use when doing X"
↓
Session 2 needs capability X
↓
S2 checks ~/.pi/agent/skills/ → "oh, this already exists"
↓
S2 reads it → uses it (or adapts it)
The key behavior: before creating a skill, the agent checks if one already exists. It can read the skills directory anytime—it's just files. Over time, you build up a library of capabilities that any session can discover and use.
Skills That Evolve
Skills aren't static. They improve through use.
User-driven evolution: I use the commit-style skill for a week. Then I say "actually, always include the ticket number at the end." The agent reads the existing skill, updates it, writes it back. Next session gets the improved version.
Cross-session learning: Session 5 hits an edge case—the migration skill doesn't handle rollbacks well. The agent updates the skill with rollback instructions. Session 6 never hits that edge case because the skill already covers it.
External knowledge: The agent can search the web. "Check what the current best practices are for conventional commits and update the skill." The agent searches, finds the latest spec, updates your skill. Your capabilities stay fresh without you tracking every change in the ecosystem.
Here's a real example from writing this very post—I noticed too much bold, Pi asked if it should update the writing skill, I said yes:

The skill now says "bold sparingly—only for 2-3 key insights per post." Next blog post gets that rule automatically.
And because skills are just markdown files, they're readable, editable, shareable, and versionable. Put them in git.

The Minimal Core Enables This
This only works because Pi's core is minimal. The agent can understand the entire extension API. It can read all the examples. The surface area is small enough that the model can reason about it completely.
A 430,000-line codebase can't be self-extended this way. The context window would be exhausted just understanding the system. But a minimal core plus a clean extension API? The agent can hold that in its head and build on top of it.
Minimal core → understandable system → agent can extend it → capabilities spread across sessions.
The Compression Continues
In my post about AI coding tools, I talked about non-lossy compression—going from 10 people doing 10 steps to 3 people doing 3 steps while preserving best practices.
Pi represents the next compression: from plugin ecosystems to self-extending agents.
What gets eliminated: plugin marketplaces (the agent builds what you need), configuration hell (the agent writes code that does exactly what you described), session isolation (capabilities persist and spread), and starting from scratch (every session inherits what previous sessions built).
What's Coming
Based on using Pi daily, here's where I think this goes:
Every developer gets a personalized agent. Not through fine-tuning, but through skills the agent wrote specifically for them. Session 1 learns your testing patterns, writes a skill. Session 2 learns your API conventions, writes another. Session 47 has deep accumulated knowledge of how you work.
Teams share agent capabilities. Put skills in your repo's .pi/skills/ folder. Everyone's agent knows your team's conventions. Your ~/.pi/agent/skills/ folder becomes a library of everything your agent has learned. Portable. Transferable. Yours.
How Other Tools Compare
Cursor has .cursorrules. Static file. You write it, agent reads it. No evolution.
Codex has AGENTS.md. Same pattern. Static, user-written.
Claude Code is closer. It has CLAUDE.md that the agent can update, custom commands it can write, memory files it maintains. Self-extension exists, but it's one feature among many.
Pi made self-extension the architecture itself.
The Bottom Line
The question isn't which tool has the most features. It's which tool gets smarter the more you use it.
What's next for me? I'm building mission control with nanobot, a dashboard to orchestrate multiple agents, track tasks, see live activity. Think kanban board where the workers are AI agents. More on that soon.
Hat tip to Tobi for pointing me to Pi, and Bhanu Teja for the mission control idea.
Written with Pi using the pavan-writing-style skill it created while writing this post.