I've noticed a trend at my company where we're leaning heavily into agentic workflows, but we're hitting walls with "vendor-granted" extension points. Whether it's Claude Code or various open-source wrappers, there's a massive difference between using a plugin and owning the logic. An API lets you do what the vendor imagined; a fork lets you do what you actually need.
The shift in AI workflow #
We've moved from the "Workbench" era—where tweaking your .vimrc
was a rite of passage—into a "Harness" era. Most high-end AI coding tools are becoming closed products or "open-core" where the most valuable interface logic is proprietary.
Even with great ecosystems like MCP (Model Context Protocol) or custom skills, you're still playing in someone else's sandbox. You can add a tool, but you can't change the core orchestration logic, the context compaction strategy, or how the agent handles a malformed tool call during a midnight deployment.
Making the jump to a custom fork #
For those looking for a practical tutorial on how to approach this without drowning in technical debt, here is the mindset shift I'm implementing with my team:
-
Identify the "Friction Point": Find the specific behavior in your AI agent that drives you crazy but isn't exposed via a config file.
-
Leverage the Agent to Maintain the Fork: This is the secret. Use the LLM to write the patches and, more importantly, use it to merge upstream changes. The "labor" of maintaining a fork is now a prompt.
-
Prioritize "Useless" Features: Some of the best productivity gains come from features that would be rejected by a maintainer for being "too niche," but are essential for your specific enterprise codebase.
The goal isn't necessarily to create a new global standard; it's to optimize the tool for the person using it. When the cost of modifying code drops to near zero, the most logical deployment strategy is to stop asking for permission and just take the code.
Next Claude Code: Improving Team LLM Efficiency →