Fork, Don't Build: How We Modified Gitea, Pi, and Godot Instead of Starting from Scratch
The AI developer tools space is full of people building new things. New agents, new IDEs, new platforms, new wrappers. Meanwhile, the tools that actually run the world — git servers, game engines, CI runners — sit there unchanged, waiting for someone to open them up and let AI agents in.
We forked three of them. Gitea for git hosting. Pi for coding agents. Godot for the game engine. Combined changes: less than 0.5% of upstream code. Here's why, how, and what we learned.
The 0.5% Rule
We're four people. We can't build a git platform, a coding agent, or a game engine from scratch. Nobody can — not in a timeframe measured in months.
But we can take something that already works — something with years of battle-testing and thousands of contributors — and change the last half-percent that makes it ours. The pattern:
1. Find open-source tool that does 95% of what you need
2. Fork it
3. Add the 5% (really, 0.5%)
4. Stay close to upstream so their fixes are your fixes
Across three forks, we've never touched more than 0.5% of upstream code. If your fork hits 1%, you're doing too much — either the upstream tool is wrong for the job, or you're not trusting it enough.
Fork 1: Gitea → Tinqs Studio
Gitea is a self-hosted git server. Single Go binary, MIT license, 45k GitHub stars. We used GitHub for two years. It was fine for docs. For the game repo — 12GB in LFS, growing weekly — it was untenable. LFS bandwidth limits, slow clones, $5/50GB pricing. And nobody on the team could see what changed. A PR modifying a .glb file showed a binary diff. No preview. The artist pushed, the developer approved blindly, and three days later someone noticed the normals were inverted.
We forked Gitea and built Tinqs Studio. Our changes:
3D asset preview. Click a .glb, .gltf, or .fbx file in a PR and rotate the model in your browser. 22 formats supported via O3DV. This alone transformed our review process — the artist pushes, the lead inspects, nobody downloads anything.
HTML file preview. Sandboxed iframe rendering. Our internal docs and game design pages look like websites, not raw source.
Agent API. Six REST endpoints that let AI agents submit tasks, push code, check CI status, and open PRs. Agents are first-class users of the git platform, not bolt-on tools.
LFS-first workflows. Auto-tracking on repo creation. Game file extensions (.fbx, .glb, .png, .wav) tracked by default. Storage dashboard per repo. Clone times went from 45 minutes to 3 minutes.
OAuth2 SSO. One login for git, the game tools, and the team dashboard.
Total lines changed: about 2,000 out of Gitea's 500,000. We modify templates, add Go modules, tweak CSS. We never touch the database schema — upstream owns that, and we ride their migrations.
The alternative was building a git platform from scratch. Multi-year project, multi-million dollar budget. Or using GitHub/GitLab and accepting their limitations. Neither gives you the ability to embed agents directly into the platform.
Fork 2: Pi → Agent Runtime with Game Tools
Pi is an open-source coding agent by Mario Zechner. MIT license, TypeScript, minimal by design — four core tools (read, write, edit, bash) and an extension system. 51k stars.
We forked it and added four extensions, each a single TypeScript file:
- tinqs-provider — routes inference through our DeepSeek V4 proxy ($0.28/MTok vs Opus at $15/MTok)
- tinqs-tools — Gitea REST API, fal.ai image generation, vision model access
- tinqs-ci — reads CI pipeline status, fetches build logs, polls for completion
- tinqs-guardrail — 29 safety patterns blocking dangerous commands
The core Pi code is untouched — 900 lines of extensions added to a 15,000-line codebase. Agents get Gitea-native tools without a fork of the entire agent ecosystem.
The alternative: building our own agent from scratch — tool-calling logic, context management, streaming, retry handling, conversation threading. Months of work to reinvent what Pi already does.
Fork 3: Godot → Agent-Aware Game Engine
Godot is the open-source game engine powering our survival colony sim. We forked 4.6.2 and added nine C++ modules that give agents direct access to the running game:
- agent_api — HTTP server inside the engine so agents can query game state
- agent_vision — screenshot capture for AI vision pipelines
- agent_console — programmatic console access
- agent_replay — record and replay game sessions for testing
These compile into the engine binary. A vanilla Godot user never sees them. An agent connects over HTTP, takes a screenshot, reads the scene tree, executes a console command — all without touching the editor UI.
2,000 lines added to a 2-million-line engine. The alternative: building our own engine, or worse, writing a renderer instead of making a game.
Why forking beats building
You inherit decades of work, for free. Gitea has handled millions of git pushes. Godot renders millions of frames. Pi has processed millions of LLM tokens. That battle-testing is yours when you fork. When you build from scratch, year one is spent rediscovering bugs fixed upstream in 2019.
You get free maintenance. Every upstream release brings security patches, performance improvements, and new features — written by hundreds of contributors you don't pay. Your job is to rebase, resolve conflicts, and test. An afternoon, not a quarter.
You stay focused. Building a git server means worrying about pack-file format, SSH key management, webhook delivery. Forking means you only think about the 0.5% that matters to you. The other 99.5% is someone else's problem.
Agents work better on real platforms. An agent pushing to a real Gitea instance — with real CI, real code review, real permissions — produces work humans can actually review and ship. An agent pushing to a toy demo platform produces demos.
What we're not building
We're not building a new IDE (Cursor and Claude Code exist). Not a new LLM (DeepSeek and Claude exist). Not a new cloud platform (AWS exists).
We're building the layer that connects them. The git server that speaks agent. The coding agent that speaks Gitea. The game engine that speaks HTTP. Each fork is a bridge between an existing tool and the agentic future — not a replacement for either.
The age of agents doesn't need more agents. It needs better platforms. Platforms that already exist as open-source projects. They just need someone to fork them and add the wiring.
Tinqs Studio is our Gitea fork, open for game teams. Ariki is the game we're building with every tool described here.