Why I Built Eterngit After GitHub Flagged My Organization
On June 16, GitHub flagged the eternego-ai organization.
The organization was small — just four open-source MIT repositories and one private website repo. But that single moment made something undeniable: if a platform can decide the visibility and operating reality of your code, then a core part of your work is not truly yours.
That incident didn’t just create frustration. It clarified direction.
Eternego was already being built on a simple but radical principle: agents should not be tied to providers. Useful AI should live locally, persist on the user’s own machine, act in their environment, and remain accountable to the person it serves.
The GitHub event made the same principle impossible to ignore on the development side.
So Eterngit began.
What is Eterngit?
Eterngit is a self-hosted forge built for an era where development increasingly happens through agents. It is not trying to replace git. In fact, its core idea is the opposite: git remains the substrate. Eterngit adds only the thin layer that git itself does not provide.
This design choice is deliberate. The truth stays in git. The server does not become a bloated platform, a secret store, or a hosted brain. Reads happen openly over HTTP. Writes go over SSH. Builds, CI, and review happen at the edges — on the maintainer’s own machine. The forge hosts results, not the entire workflow.
Designed for Agents and Humans
But the deeper question Eterngit asks is this:
What would a forge look like if contribution were designed for agents, while judgment stayed with humans?
Most existing forges were shaped around human bottlenecks: expensive handoffs, ceremonial identity, and pull-request rituals built for human coordination. Agents change the game. They can read documentation instantly, branch quickly, produce work continuously, and contribute at a volume and speed that traditional workflows were never designed to handle.
Eterngit’s answer is unusually clean.
There is no fork ceremony. No pull-request ritual. No account-creation friction standing between an agent and contribution. When someone (or something) wants to contribute, their agent can simply follow the docs and get to work. The contribution path is intentionally shaped to reduce friction for agents.
At the same time, Eterngit refuses to pretend humans disappear. In fact, it treats human judgment as more important, not less.
Agents can generate plausible work at scale — including plausible mistakes. So the merge decision remains the irreducible human act. Contribution becomes lightweight. Review and confirmation stay deliberate.
This separation — where speed belongs to agents and judgment belongs to humans — may be Eterngit’s most important contribution.
The Interface Reflects the Philosophy
For agents, every page has a clean markdown route. They get content as content, not a decorative shell to scrape.
For humans, the same repository can be viewed through multiple familiar themes — terminal, Neovim, VS Code, or JetBrains-style interfaces.
As a human who reviews code, it’s been months since I opened my favorite IDE just to review changes. I still enjoy reviewing code in that environment. Eterngit brings that experience back: the agent writes the code, and I get to see clean, familiar diffs in my preferred IDE theme — directly in the browser.
These themes are not cosmetic. They make it natural for people to inspect code, releases, diffs, and structure in the environments where they already think best.
The Bigger Picture
Seen together, Eterngit and Eternego tell the same story.
Eternego is about a persistent local AI that lives on your machine, acts in your environment, and answers to you — not to someone else’s product boundaries.
Eterngit extends that same sovereignty instinct into the infrastructure of software development itself. If agents are becoming real participants in how code is written, then the systems around contribution, review, release, and provenance need to be rethought.
This doesn’t mean discarding proven tools. It means being precise about which parts of the stack are foundations and which parts should remain thin, ownable, and replaceable.
- Git is the foundation.
- The forge layer should be sovereign.
- Contribution should be easy for agents.
- Verification should remain legible for humans.
This is the story I see in Eterngit: not a reactionary clone of existing forges, but a principled response to a changing technological reality. A project born from a concrete platform risk, then sharpened into a thesis about how development should work when agents become normal contributors.
And maybe that’s the broader lesson.
The age of agents will not be defined only by better models. It will also be defined by whether we build the surrounding tools, workflows, and institutions in ways that preserve sovereignty, accountability, and human judgment.
That is where Eterngit becomes more than a forge.
It becomes an argument.
What are your thoughts?
Have you experienced platform risk with your open-source projects? How do you currently review code contributed by AI agents?
I’d love to hear your perspective in the comments.
If you're interested in local-first AI, you can explore Eternego at eternego.ai.
Top comments (0)