Why Anthropic’s Shift Back to Code Execution Validates the AiPy Python‑Use Paradigm

Anthropic released two engineering posts in November 2025: “Code execution with MCP” and “Introducing advanced tool use on the Claude Developer Platform”. The latter coined the term “Programmatic Tool Calling” (PTC) and sparked discussion about the future of LLM agents.

Anthropic’s roadmap

The author visualizes the progression as:

MCP → Code execution with MCP → Programmatic Tool Calling

According to the author, this evolution attempts to solve the “context explosion” problem that arises when many MCP‑based tools are combined, a challenge that belongs to the broader field of “context engineering”.

Python‑use (AiPy) versus Anthropic’s approach

The author’s “Python‑use” paradigm, embodied in the AiPy project, directly executes Python code generated by the LLM instead of relying on JSON‑based tool calls. This is presented as a more “first‑principles” solution, avoiding the layered complexity of MCP → PTC.

Key differences highlighted:

Anthropic’s PTC still uses JSON payloads inherited from MCP, whereas Python‑use generates and runs native Python functions.

Python‑use combines API calling, Python package calling, and an embedded interpreter, described as “万物互联 + 万物编程 + 万境直通”.

CodeAct and related research

The CodeAct paper (arXiv 2402.01030v4) argues that “code as actions” outperforms traditional JSON/Text tool calling. The author notes that CodeAct’s approach aligns with the Python‑use idea that “code is the agent”.

CodeAct’s repository is referenced:

https://github.com/xingyaoww/code-act

Practical implementation in AiPy

The AiPy runtime exposes a global runtime object. Example of installing packages:

if runtime.install_packages('httpx', 'requests>=2.25'):
    import datasets

The “Python Function Calling (PFC)” mechanism extends this by allowing users to register custom functions in the /plugins directory. A snippet of the plugin list output shows two example plugins:

>> /plugin
Available Plugins
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━┓
┃ Name       ┃ Description                                            ┃ Type ┃ Version ┃ Author      ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━┩
│ web_tools  │ Web Tools – provides web page scraping, URL analysis, │ TASK │ 1.0.0   │ AiPy Team   │
│ image_tool  │ Image Tool – provides image recognition and analysis   │ TASK │ 1.0.0   │ AiPy Team   │
└────────────┴───────────────────────────────────────────────────────┴──────┴─────────┴───────────┘

Custom commands are defined in markdown files under ~/.aipyapp/commands/. An example system_info.md command demonstrates Jinja2 templating, conditional blocks, and embedded Python code that prints system details and task statistics.

---
name: "sysinfo"
description: "Display comprehensive system information"
modes: ["main"]
arguments:
  - name: "--detail"
    type: "flag"
    help: "Show detailed information"
---
# System Information
## Current Configuration
- **Working Directory**: {{ctx.tm.get_status().workdir}}
- **Current LLM**: {{ctx.tm.get_status().client}}
- **Current Role**: {{ctx.tm.get_status().role}}
- **Display Style**: {{ctx.tm.get_status().display}}
{% if detail %}
## Detailed System Status
````python
import sys, os
from pathlib import Path
print("## System Details")
print(f"- Python Version: {sys.version}")
print(f"- Platform: {sys.platform}")
print(f"- Current User: {os.getenv('USER', 'unknown')}")
print(f"- Current Directory: {Path.cwd()}")
print(f"- Home Directory: {Path.home()}")
tasks = ctx.tm.get_tasks()
print(f"- Total Tasks: {len(tasks)}")
````
{% endif %}
---
*Use `--detail` flag for comprehensive system information*

Running /sysinfo --detail in the AiPy CLI produces a formatted table with system info and task statistics, illustrating the seamless integration of code execution within the command framework.

Limitations and trade‑offs

The author acknowledges that Python‑use’s flexibility can lead to instability when the LLM repeatedly generates different code for similar simple tasks (e.g., querying weather for different cities), causing token waste and reliability concerns. Conversely, this “uncertainty” is framed as a strength because it enables richer interaction with the environment.

All tool‑calling approaches—MCP, PTC, and CodeAct—share the requirement that developers must pre‑define functions or tools; without such definitions, the model cannot act on user requests.

Broader context

The discussion touches on Anthropic’s later “skills” feature (Nov 2025) that bundles preset code in a folder, similar to Claude Code’s custom slash commands ( https://code.claude.com/docs/en/slash-commands). The author argues that both “skills” and “commands” are essentially prompt‑engineering techniques rather than fundamentally new execution models.

Finally, the article references related work such as the X‑Master project (SciMaster arXiv 2507.05241) and notes that code‑centric agents can reduce hallucinations in data‑heavy tasks compared to pure language‑only pipelines.