How We Shipped git-flow-next 1.0 Almost Entirely with AI | git-flow-next<br>Table of Contents<br>Phase 1: Vibe Coding with Cursor (March 2025)<br>Phase 2: Building the System (May–August 2025)<br>Phase 3: The Turning Point (September 2025)<br>Phase 4: The Models Catch Up (October–November 2025)<br>Phase 5: Filling Out the Workflow (December 2025–January 2026)<br>Phase 6: v1.0.0 and the Skill System (February 2026)<br>Phase 7: What AI Code Review Actually Looks Like (February–April 2026)<br>The Workflow Today<br>What the Role Actually Became<br>What’s Still Hard<br>The Real Product

How We Shipped git-flow-next 1.0 Almost Entirely with AI<br>Written by: Alexander Rinass Published on June 9, 2026

In our 1.0 announcement, we mentioned that git-flow-next has also been an experiment “to see how far we could push today’s AI capabilities on an open-source project of this scope.”

We promised more on that journey in a future post. This is it.

First, here are some numbers:

13 months

10 releases

14 Claude Code skills

8 guideline documents

Approximately 392 commits

Approximately 29,000 lines of Go code

We did all of this on the side, alongside our regular work — which is worth keeping in mind before reading too much into the timeline.

Most of the code was written by AI. While we’re experienced developers, we’re not proficient in Go. So we provided the architecture, specifications, and guidance; the AI was the hands on the keyboard.

Two things motivated the project:

We wanted an open-source tool that would need little ongoing maintenance from us.

We wanted to experiment with something that’s more or less a black box to us — we’re not familiar with the tech stack — to see how building with AI holds up under those conditions, both for us specifically and as a more general question.

If you’re in a hurry and are just looking for the tl;dr, here is the one lesson we’d carry to the next project: AI development isn’t “telling AI what to build.” It’s “building the system that tells AI what and how to build.”

The code is the output. The guidelines, skills, review criteria, and architectural docs are the actual product.

This is how we got there.

Phase 1: Vibe Coding with Cursor (March 2025)

The first phase was all about getting our feet wet: minimal instructions, all in one file, just to explore what AI could accomplish.

The pace was remarkable. In about two weeks, Cursor produced all of git-flow-next’s core commands — start, finish, list, overview, update, delete, rename, checkout — at roughly one new command every day or two.

The pace was also misleading.

Up close, the project wasn’t really a project. It was a collection of individually-generated files that happened to share a directory. There was no clear separation between the CLI layer, business logic, and Git operations — every command did things its own way. Patterns were duplicated across files in slightly different shapes, often subtly enough that asking AI to find duplicates would surface one and quietly miss the others. Git configuration was loaded on every operation instead of once at startup — performance regressions by design, not by accident.

We tried to refactor our way out of it. With Cursor, with Claude, with detailed instructions. It didn’t work. Functions were duplicated, code didn’t compile, proposed refactorings were over-engineered with the wrong abstractions.

We even tried full rewrites from scratch. Those failed, too.

What eventually worked was the opposite of speed: tiny incremental steps. Create empty command files first. Add one piece of logic. Run the tests. Move on. And more importantly, we realized we had to define a development philosophy ourselves — explicitly, in writing — before AI could help us clean anything up.

You can’t evaluate an AI’s proposal if you don’t already know what you want. That was the first time we understood the shape of the real problem.

Phase 2: Building the System (May–August 2025)

On day one with Claude Code, we let it analyze the project and write a CLAUDE.md file. It got some things wrong — inconsistent config keys, for one — but accuracy wasn’t really the point.

The point was to give AI a place to start understanding the project before writing code.

That set off a pattern. Every time AI failed in a recognizable way, the answer was a new guideline. Over a few months, eight of them accumulated:

CLAUDE.md — The entry point for any AI agent working on this codebase. Project overview, build and test commands, where things live. Without it, every session starts from zero.

CODING_GUIDELINES.md — A pragmatic, anti-over-engineering philosophy, plus a hard rule that the manpages in docs/ must be updated whenever a command or its behavior changes. Documentation stays current because the guideline says it must.

TESTING_GUIDELINES.md — Test naming conventions and a mandatory comment pattern — description, numbered steps, expected outcomes — so every test is self-explanatory at a glance.

GIT_TEST_SCENARIOS.md — Patterns for spinning up...