I'm building FuncHole, an open-source, self-hosted function composition platform designed with coding agents as first-class users.
The idea is simple: instead of agents only generating code, I want them to be able to take a requirement and actually build, deploy, test, and iterate on an application through FuncHole.
Today I tested that idea using MiMo V2.5 through OpenCode Go.
The task was to build and deploy LinkPocket, a small bookmark manager. I intentionally gave it an end-user-level requirement without explaining how FuncHole's internal tools should be used.
The result wasn't what I expected — but the failure was useful.
The agent struggled with several parts of our MCP interface:
- Some tool descriptions weren't clear enough.
- It tried falling back to shell commands where we lacked proper guardrails.
- We hadn't provided good examples of the expected Function structure.
- Static/frontend Functions were particularly difficult to reason about.
It eventually deployed a working application, but the path exposed an important lesson:
Exposing tools to an agent isn't the same as designing a good interface for an agent.
Clear contracts, examples, constraints, actionable errors, and guardrails are all part of the agent developer experience.
So instead of blaming the model, we came away with a pretty useful list of things to improve in FuncHole.
That's what I'm working on next, and then I'll run the experiment again.
Top comments (0)