In this article I’m going to present you with something I’ve been working on personally for almost two years now (on and off), and it’s a topic close to my heart.
GitGrit – my open source, MIT licensed, engineering standards platform.
What the heck is an engineering standards platform? why do you even need it? Give me five minutes of your time to convince you it’s exactly what you’ve been missing.
Self Introduction
Before we go on, let me introduce myself – I’m Kfir Zvi, an Israeli Software Engineer for the past decade. I’ve worked in many organizations and setups all the way from a founding member at a startup to big corps with tons of bureaucracy and infra to handle.
I specialize in backend development, designing highly scalable systems, and transforming messy, hard-to-understand systems and workflows to simpler, easier-to-maintain concepts that fit the human brain. I also enjoy DevOps and like to see how and where my code runs.
Today I’m running KfirZvi.com, the software studio behind GitGrit and hopefully soon enough behind more great products.
The Problem
Engineering can, and should, be simpler.
Here is the specific way it stops being simple: A team grows. Repositories multiply. The way you build, the standards, the conventions, the lessons you paid for in outages, ends up living in three places at once: in a few senior people’s heads, in a wiki nobody opens, and, in theory, in the code itself. The moment you look away, those three drift apart.
What is left is a gap between how you think your teams build and how they actually build. Nobody is at fault. Everyone is busy shipping. But the gap is where the pain hides: the forced migration nobody saw coming, the service with no owner, the best practice we all agreed on that only half the repos ever adopted. And when someone asks a simple question, are we consistent, are we current, the honest answer is “we would have to go check, repo by repo.”
GitGrit is my attempt to close that gap: to spread engineering knowledge across an organization, make technical complexity visible, and give leaders an honest answer at any moment, without turning their engineers into a compliance chore.
The Solution
As promised, an engineering standards platform – It is a single place that knows every standard you care about, checks them against every repository you own, continuously, and tells you at any moment exactly where you stand. Not a document describing how you would like to build. A living system that watches how you actually build, and closes the gap between the two.
GitGrit is fundamentally built on your git repositories. Why? because anything related to your production code should exist in a git repository (or other version control systems). Modern DevOps practices also dictate the use of IaC tools and the GitOps method. That means that your infra setup should exist in a git repository as well.
How it actually works, and this is the whole model:
1. Connect your Git host. GitHub, GitLab. GitGrit watches the repos you point it at and notices every time one changes.
2. Add projects, group them into stacks. A stack is just the set of repos that make up one real application: your microservices, your app together with its infrastructure. It is how you already think about your systems, so it is how GitGrit organizes them.
3. Define your standards as policies. Install them from the marketplace, or write your own.
4. That is it. Now you have a live view. Every push, pull request, and tag checks the repo again against your standards. At any moment you can see where each project stands, and why.
Policies In Detail
How They Are Built
A policy is just a Python function. It receives a Project context, the files, the languages, the members, branch protection settings, commit history, and returns pass or fail, with a message and a score. That is the whole contract. No DSL, no config language, no plugin API. If you can write a Python if, you can write a policy. And because it is real code, there is no ceiling on what a standard can be. You express it the way you would explain it to a new hire, and then it runs itself, forever.
Here is one I learned the hard way. It is 2am, production is down, and the fix is a one line change. You go to ship it and find the service is pinned to a Python version that went end of life months ago. The patch you need depends on something that version cannot run, so now you are doing an unplanned runtime upgrade in the middle of an incident, at the worst possible time to do it. The policy that prevents this is boring and about ten lines long: read the Python version the repo declares, compare it against the known end of life dates, fail if it is past. It ships with the real end of life dates built in. The upgrade never gets scheduled until it hurts. This just moves the hurt to a Tuesday afternoon instead of 2am.
Using LLMs
Here is where it gets interesting. Because a policy is just code, a policy can call a language model. That opens up a whole class of standards that were impossible to check before: the subjective ones. A linter can tell you a README exists. It cannot tell you it is any good.
A policy that hands the file to an LLM can: does this README actually explain how to run the project, or is it a title and a TODO? The model runs inside the same sandbox, you bring your own key and model, and its verdict comes back as pass or fail like any other check. This is the part I am most excited about. It is the jump from “does it exist” to “is it any good”, which is the whole difference between a checklist and a standard.
Here is a higher stakes one. AI assistants are brilliant at generating a LICENSE file, and also brilliant at stitching together fragments of licenses that were never meant to sit together: an MIT header over a block of GPL text, a copyright line naming a company nobody at yours has ever heard of. To a human skimming a pull request it still looks like a license. Legally it can be a landmine, and license problems tend to surface during an acquisition or a funding round, again at the worst possible moment. No linter flags this, because nothing is syntactically wrong. An LLM policy can: hand it the LICENSE file and ask, is this one coherent, real license, or a Frankenstein of several stitched together? That is the difference between checking a box and actually protecting the company.
Architecture Map
There is one more piece that is not about pass or fail at all. Once GitGrit knows your projects and how you have grouped them into stacks, it draws them: an automatically generated map of your systems, how they depend on each other, and where they reach out to external services. It regenerates as your repos change, so it never goes stale the way the architecture diagram in a slide deck always does. This is the “map technical complexity” part: the picture a new hire wishes existed on day one, and the one a leader needs before deciding where to invest.
Haven’t we solved this already?
If you have been doing this a while, you are already thinking of the usual answers. I tried all of them. Here is why each one leaks, and what GitGrit does instead.
Project templates.
You spin up a golden template so every new repo starts right. Great on day one. But a template only applies at creation. Update it later and nothing flows back to the repos already out there, and they start drifting immediately. GitGrit is living: it checks every repo on every change, not once at birth.
Uniform CI/CD pipelines.
You push the standard into a shared pipeline. Now it is real, but it is also buried in YAML across dozens of repos, invisible unless you go digging, and painful to change everywhere at once. GitGrit is visible: one dashboard shows where every repo stands, and the standard lives in one place instead of scattered through pipeline files.
Wikis and docs.
You write it all down. Nobody reads it, it is hard to keep accurate, and it can never tell you the actual status right now. GitGrit is executable: the standard is code that runs itself, so “are we following it” is always a live answer, not an archaeology project.
Linters and security scanners.
These are great, and GitGrit does not replace them. But they work one repo at a time, and they only check what is mechanically present. They cannot tell you which of your two hundred repos even has a linter configured, and they cannot judge whether something is any good. GitGrit works across the whole fleet, checks that those tools are even in place, and with LLM policies can grade quality, not just existence.
If you have read this far, thank you. GitGrit is open source under MIT. You can host it yourself anywhere, or use the hosted version at app.gitgrit.dev.
- ⭐ Star it on GitHub
- 🐛 Open an issue: a policy you wish existed, a standard you cannot currently express, a rough edge. I read every one.
- ✉️ Or just reach out. I built this because it is close to my heart, and I would love to hear how you keep your standards from rotting.
This is early, and it is built in the open, on purpose. Come build it with me.
답글 남기기