Ever shipped changes and wondered what the hell just happened?
That is the moment gitwell is being built for.
Agent-written code moves fast. Sometimes too fast. You ask for one change, and ten files later you are staring at a diff you did not fully write, trying to decide whether it is safe to commit.
If you cannot explain the change, you probably should not commit it yet.
gitwell is a small pre-commit review surface for that moment. It is not there to approve the change. It is there to make the change explain itself before you approve it.
It is still in development, so this page is a build note, not a launch announcement.
This is what happens when review collapses into whatever sentence is fastest to type.
TODO add image: cropped GitHub commit history showing the slide from useful messages into boh, f2, as, and waa. Keep it narrow and tall, like a receipt of regret. The point is "you really will not remember what this meant".
Future-you will not remember what waa meant.
The problem is not the message. It is the review.
A bad commit message is often a symptom. The real problem is that the diff became too large, too fast, and you no longer have a clean explanation for it.
That happens constantly with coding agents. You prompt for one thing. The agent changes layout, state, helper functions, tests, names, and files you forgot existed.
Now Git is asking you for a summary.
But the summary is not just metadata. It is the moment where you check whether the change still matches the thing you thought you built.
The diff should make sense before the commit message sounds good.
The pre-commit review surface
gitwell sits in the small gap between "the agent changed the code" and "this should become history".
You add a project, review the working changes, choose which files belong together, preview token and cost estimates, generate a summary and description, inspect the result, edit it, and copy it into your Git client.
Readable commit messages are the output. Understanding the change is the point.
TODO add image: future Gitwell UI screenshot, not the current commit-message-only surface. Show selected files on the left, a review explanation in the middle (What changed, Review notes, maybe This looks like more than one commit), and the editable commit message as the final artifact.
The important part is not that AI writes the first draft.
The important part is that you get another explanation before the change becomes history.
If the summary feels wrong, that is signal too.
Keep the review pause small
You still need to review the change. gitwell does not remove that responsibility.
It makes the review pause small enough that you do not lose the flow of the current agent conversation. Select the files, ask what changed, inspect the draft, edit the message, copy it, and keep moving.
What gitwell does not do
gitwell does not commit.
It does not stage files, unstage files, push, amend, rebase, rewrite history, or approve the change for you. The file checkboxes only decide what context the model sees.
That restraint is the product.
No magic commit button. No hidden Git state. Just text you can read, edit, copy, or ignore before it becomes history.
Why AI fits here
The model is not being asked to approve code, make architectural decisions, or understand the soul of the project.
It receives selected diffs and produces a second explanation of what changed.
That explanation is useful because it gives you something to argue with before the commit exists.
The model can be wrong. That is fine. A wrong explanation is still useful if it makes you stop and ask why the diff does not match the story.
What I want next
The current app drafts a commit summary and description. The product direction is more review-shaped than that.
The next version should make the change explain itself in three parts:
- what changed;
- what looks important or surprising;
- the commit message that should survive in history.
I also want gitwell to notice when a diff looks too broad for one commit.
This looks like more than one commit.That warning does not need to be perfect. Even a cautious nudge is useful when an agent has touched UI, state, tests, config, and docs in the same pass.
TODO add image: mockup of a Gitwell warning state that says This looks like more than one commit, with grouped file areas or a simple "consider splitting" note. Ugly is fine for now; the point is to capture the product idea.
The cost shows up later
A vague commit feels cheap today.
Months later, it becomes a tax. You open your own change, recognize the code, and still cannot remember what problem it was solving.
Readable commits are how you re-enter a codebase without opening every old diff.
What exists now
gitwell is still in development.
The current build is a Rust desktop app with an egui interface, project registry, working changes view, token and cost preview, Gemini generation, streaming output, editable summary and description, and per-project local history.
It is early, but the shape is already there.
Local first-ish, with caveats
The app keeps config and history locally under %APPDATA%\gitwell. The API key is stored locally in config.toml, and generated history is stored in history.json.
The selected diff payload is sent to the configured AI provider. Right now, the real provider is Gemini.
That is not a privacy slogan. It is just the contract the tool should make visible.
The test
Success is not engagement.
Success is opening git log --oneline six months from now and understanding what happened without opening every diff.