GitButler frames Grit as deliberately picking Git because its byte-level specification, oracle implementation, and universal test corpus eliminate ambiguity about correctness. The real bet isn't on Rust or performance — it's on whether current agents can ship load-bearing systems code when there's nowhere to bluff.
Argues the technical novelty of 'Git in Rust' is zero in 2026 given gitoxide and libgit2. The interesting variable is the authorship model — GitButler is running an industrial trial of agentic development against a target with an unambiguous correctness oracle.
A substantial portion of the 144-comment thread welcomes the prospect of a Rust-native Git library that isn't libgit2, viewing the embeddability and language-native ergonomics as a real gap GitButler could fill regardless of the agent angle.
Skeptical commenters argue that no matter how well Grit benchmarks on day one, an LLM-authored reimplementation of Git's plumbing carries hidden correctness and maintenance risk. Passing tests against real git isn't the same as being trustworthy enough to hold someone's source history.
GitButler — the Tauri-based Git client that pitches itself as a friendlier alternative to the porcelain shipped with `git` — has published a deep post on a side project called Grit: a from-scratch rewrite of Git's plumbing in Rust, authored primarily by AI coding agents under human supervision. The team frames it as both a product bet (their client needs a faster, embeddable Git library) and an experiment in how far current-generation agents can push on a hard, well-specified systems target.
The pitch is unusually concrete. Git is one of the most-specified pieces of software in existence: object formats, pack files, the index, refs, and the wire protocol are all documented down to the byte. That makes it an almost perfect benchmark for agentic coding — there's an oracle (real `git`), there's a test corpus (every repo on Earth), and there's no ambiguity about what "correct" means. Grit is less a Git rewrite and more a public, falsifiable experiment in whether LLM agents can ship byte-compatible systems code against a known-good reference.
The HackerNews thread (106 points) is doing what HN does with this kind of post: half the comments are excited about the Rust ecosystem finally getting a maintained, embeddable Git library that isn't libgit2; the other half are skeptical that an agent-written reimplementation of something this load-bearing is a good idea regardless of how well it benchmarks on day one.
There are already serious Rust Git implementations. `gitoxide` has been grinding on this for years and is genuinely good. libgit2 exists and has bindings everywhere. So the technical novelty of "Git, but in Rust" is roughly zero in 2026. The interesting variable in Grit isn't the language. It's the authorship model.
GitButler is essentially running an industrial trial of agent-driven development on a target where you cannot bluff. Most agent demos live in the soft middle of the stack — CRUD endpoints, React components, glue scripts — where "works on my machine" and "the tests pass" are nearly the same thing. Git plumbing is the opposite environment. A bug in pack file delta resolution doesn't throw an exception; it silently corrupts history on someone's laptop six months from now. The cost function for being subtly wrong is enormous, and LLMs are notoriously good at being subtly wrong with confidence.
That's why the workflow matters more than the artifact. The post describes a loop where agents propose implementations, then get hammered against the real `git` binary as the oracle — running both implementations on identical inputs and diffing the byte output. Using the reference implementation as a differential fuzzer is the single most important design decision in the project, and it's the one other teams trying agent-written systems code should be stealing immediately. Without that loop, you're just trusting vibes and unit tests written by the same model that wrote the code.
The community reaction reflects two real debates. The first is whether "agents wrote it" is a meaningful claim or marketing — given how much scaffolding, review, and rejection happens between a model output and a merged commit, the honest description is closer to "a human-led team using agents as very fast junior engineers." The second is the maintenance question: what happens in year three, when the original humans rotate off and the codebase has to be debugged by someone who didn't supervise its creation? gitoxide's value isn't just its current correctness; it's that Sebastian Thiel has been holding the whole model in his head for years. Agent-authored code optimizes for being written, not for being inherited.
There's also a quietly interesting business story here. GitButler shipping Grit means their client stops being a thin wrapper over `git` shell-outs and becomes a Rust binary with Git baked in. That's a performance story (no fork/exec per status call), a portability story (one binary, no system Git dependency), and a moat story (their plumbing diverges from upstream where it helps their UX). The real product Grit unlocks isn't a faster `git status` — it's UX features that vanilla Git's data model can't express, like virtual branches that actually work.
If you maintain a tool that shells out to `git` today, the near-term implication is: watch this. An embeddable, MIT-or-Apache-licensed, agent-maintained Rust Git library that's actually byte-compatible would be genuinely useful for editor plugins, CI runners, and anything doing repo analysis at scale. The performance wins from skipping process spawn alone are non-trivial — every IDE that polls `git status` on file save is leaving real latency on the table.
If you're a team lead thinking about adopting agent-driven development for your own infrastructure work, Grit is the case study to actually read end-to-end when it's further along. The questions to ask aren't "did the agents write good code" — that's the wrong frame. The questions are: how much human time went into the differential test harness versus the implementation, what's the defect rate caught by the oracle versus what slipped through to integration, and what does the agent-authored code look like when a human has to debug it a year later with no model context. Those numbers, if GitButler publishes them, are worth more than any benchmark.
The immediate practical advice: don't rip out libgit2 or gitoxide for this. Treat Grit as a research artifact until at least one non-GitButler project has run it in production for six months without history corruption incidents. Git is the worst possible place to be an early adopter.
The Grit bet is really a bet on whether 2026-era agents have crossed the threshold from "productive on greenfield" to "productive on load-bearing reimplementation." If the answer is yes, the next 18 months get weird fast — every widely-deployed C codebase becomes a candidate for an agent-led Rust port, and the bottleneck shifts from engineering capacity to test oracle quality. If the answer is no, Grit becomes the clearest public postmortem we have of where the line actually is. Either outcome is more useful than another benchmark blog post.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.