GET
ANGRY.

The time has come for our SDLC to evolve, and meet the challenges of today. GitFury is that evolution.

Motivation

Software Development looks absolutely nothing like it did five years ago. The tools and processes of the trade cling to a past that no longer makes sense, vestigial artifacts of a gone era. They aren't evolving. Editors pretend you are still writing code. GitHub, GitLab and BitBucket pretend you are still the author that knows the code changes intimately, and reviewers are still diligent. We all pretend the process decimates knowledge and protects the codebase from decay. These are all lies.

It is time to stop lying to ourselves, wasting cycles on performative rituals that are little more than religious pageantry, and evolve our process to match the needs of agentic software development. Then we need tools that fully support the evolved process, instead of hammering it into an obsolete shape. GitFury is about this.

Definitions

Agentic Software Development: code change authoring via a semi-autonomous AI Agent. The level of autonomy may vary, but the key elements are that the AI can execute tools to edit code and perform terminal actions, and the agent functions on a turn loop greater than one. Copilot and auto-complete IDEs are not Agentic Software Development. The development process supported by Claude Code, Codex and OpenCode are Agentic Software Development.

What An SDLC Should Do

Before tools or process, we need to understand what constitutes a healthy development ecosystem. What things should our system make true?

• It should be as fast as possible. Only as much friction as is needed to attain the other goals of the system.
• It should be as automated as possible. Only involve a human when the value outweighs the benefit of not doing so.
• It should prevent bad things from happening to the codebase. Bugs, regressions, eroding architecture, conflicting design patterns, and the propagation of spaghetti all count.
• It should proliferate human understanding of the codebase. More team members should understand how the code works, its history, reasoning, and intended future.
• It should encourage diverse human viewpoints. Multiple human inputs on the same work is better than a single human input.
• It should account for Juniors. The system must develop human talent while enabling Junior Software Engineers to create more value than they cost.
• It should have an airtight audit trail. Every change must have a clear chain of custody, approval process, and accountable human beings.

GitFury Principles

• Decouple writing code from humans. Focus on what humans actually contribute: direction, review, and understanding.
• Commoditize the tools. Treat hardware and inference as commodities, not identity, so they may scale based on the available human capacity of the team.
• Communize the work. Providing direction to agents, reviewing code, and understanding the codebase are naturally communal activities. Lean into this with multiplayer-first process and interface.
• Get it merged. Embrace true Continuous Integration and aggressively introduce new code back into main as soon as conditions are met.
• Elevate understanding. Make ubiquitous human understanding of the codebase and the impact of proposed changes a first class citizen.

GitFury Process

This is how the principles play out in action, starting with a git init.

Setting Up

1. The first team member spins up a GitFury server, installs and authenticates the GitFury CLI.
2. They create a project in the web UI, invite the team, and make tickets for environment setup, CI checks, and deployment.

Getting to Work

1. Any team member starts a ticket by looping in the agent in the timeline with "@agent let's get started."
2. The ticket timeline is the live chat: the agent suggests merge checks and teammates discuss the work in context.

In The Code

1. As the agent writes, the diff becomes available in the file explorer in both CLI and web UI.
2. Teammates comment on lines, invite each other into review, and suggested changes are sent to the agent's next turn.

Understanding

1. "What's the story" opens a narration panel explaining what is changing and why while the code viewer follows along.
2. Clicking a module switches the narration to a deep dive on what it is, how it functions, and where it fits.

Sanity-Checking

A teammate types /url in the CLI and a browser opens a unique container subdomain with the work front and center.

Shipping

1. The agent runs CI to get passing state on the current git SHA.
2. Humans approve in the CLI or web UI.
3. When defined checks pass and required human approvals exist, the work is merged into main.

Deploying

1. Admins add deployment-only environment variables via web UI or CLI.
2. The team confirms readiness, then a teammate runs /deploy and accepts the suggested version and notes.
3. The team watches deployment turn green. The project is live.

What's Different?

• Truly coin-operated development scale. Scale to as many branches/tickets/agents as the team can collectively handle; we call this pool of live work the Fury. The scale is limited not by laptop CPU, but by human cycles - dozens, hundreds, even thousands of agents, matching the speed of the team.
• Meat proxies are no more. When commits don't count, moochers get exposed for what they really are.
• No human writes the code, or pretends to. Code writing is automated, leaving 100% of human cycles to review and instruction.
• The whole ticket lineage is self-contained. Anyone can jump in at any time with 100% of the available background and context. Hand-offs and pairing are natural, painless.
• Dual-key safety is almost free. If the team is effectively collaborating on work, there is no seperate "review" process, no hunting down PR rubberstamps. When the code is ready, you just merge it.
• Juniors add value again. Seniors can guide and supervise while delegating work safely, giving Juniors time to develop while delivering immediate value.