The Commit Graph Escapes Engineering
What happens when every function starts working in repo-shaped systems?
I have a finance repo.
I have a marketing repo.
That would have sounded strange a few years ago. GitHub was where code lived. Engineering work went into repositories. Everything else lived in Google Docs, Notion, spreadsheets, Slack threads, decks, and the hazy memory of whoever happened to be closest to the work.
But that is not really how I am running Alma anymore.
Alma is a small company, so the operating system has to be lightweight. I do not want a giant process layer. I do not want every idea to become a meeting. I want the company to be able to think, ship, measure, and adjust quickly.
Increasingly, that means turning more work into artifacts that can be created, edited, reviewed, versioned, and reused by AI agents.
The marketing repo can hold campaign briefs, ad variants, landing page copy, experiment readouts, lifecycle emails, creative concepts, and positioning notes. The finance repo can hold investor updates, scenario models, pricing analysis, monthly metrics, fundraising narratives, and board materials. The product repo can hold specs, research summaries, rollout plans, and feature decisions.
Some of this still ends up in apps. A spreadsheet may become an .xlsx. A landing page may become React. A campaign may go live in Meta. But the working layer is increasingly file-shaped.
And once work becomes file-shaped, it starts to behave more like software.
It has history. It has authorship. It has diffs. It has branches. It can be reviewed. It can be reverted. It can be connected to what shipped.
That is the part I cannot stop thinking about.
GitHub as a Productivity Proxy
The GitHub contribution graph is imperfect, but it reveals something real.
If someone is deep in the weeds of building, the graph usually shows it. Not because every commit is valuable. Not because more green squares automatically means better work. But because sustained contact with the system leaves traces.
Commits show cadence. Pull requests show collaboration. Diffs show what changed. Issues show what got noticed. Deploys show what made it into the world.
In an AI coding world, this becomes even more important. If a builder is using Claude Code, Codex, Cursor, or whatever comes next, the output still has to land somewhere. The agent can write code, but the repo records what changed.
The contribution graph becomes a rough proxy for something deeper:
Are you repeatedly changing reality?
That question is not just for engineers.
The Marketing Commit
Imagine a marketer working in the same kind of loop.
Not “I made some posts.”
More like:
drafted 20 ad hooks for a protein campaign
launched 4 landing page variants
rewrote the onboarding email sequence
created a new creator outreach list
shipped a testimonial campaign
wrote the readout on what converted
killed the losing angles
doubled down on the winning one
Each of those can be an artifact. Each artifact can live in a repo. Each change can have a commit.
The point is not that GitHub is magically the right interface for marketers. Maybe the better version is Notion with real diffs. Maybe it is Linear. Maybe it is a new tool that looks more like an operating system for AI-assisted work.
The important idea is repo-like work:
The work is durable.
The work has history.
Changes have authors.
The reasoning is inspectable.
Artifacts connect to outcomes.
That last part matters most. AI will make artifact creation cheap. The scarce thing will be closed loops.
The future marketing graph should not measure how much content someone generated. That will be too easy. It should measure how often they moved an idea through the full cycle:
hypothesis -> artifact -> launch -> measurement -> learning -> iteration
That is the marketing equivalent of a commit that matters.
The Finance Commit
Finance has the same pattern.
A finance repo sounds odd until you realize how much finance work is versioned reasoning.
What changed in the forecast? Why did the runway assumption move? Which pricing scenario did we believe last month? What did we tell investors in March? How did the board narrative evolve? Which model drove the hiring decision?
In most companies, the answer is scattered across spreadsheet copies and Slack messages.
In a repo-shaped system, the finance work has a trail:
models/may-runway-scenario.xlsxpricing/annual-plan-sensitivity.mdinvestor-updates/2026-05.mdboard/series-a-narrative.mdmetrics/revenuecat-april-summary.md
The value is not that everything becomes public. The value is that the company can see how its own thinking changed.
That becomes especially important when AI is helping generate the first draft of the model, summarize metrics, write the investor update, or compare scenarios. The agent accelerates the work. The repo preserves the judgment.
The Consequences
If this pattern spreads, it changes how we understand productivity.
The old proxy for knowledge work was presence. Meetings attended. Slack responsiveness. Docs created. Decks delivered. A lot of it was hard to inspect from the outside.
The new proxy might be artifact movement.
What did you create? What changed because of it? Did it ship? Did it teach us something? Did it compound? Can someone else build on it next week?
That is a better question than “were you busy?”
It also has risks.
A contribution graph can become theater. People can optimize for visible activity instead of meaningful progress. Managers can confuse commits with impact. Teams can accidentally create surveillance systems and call them operating systems.
So the point is not to count green squares.
The point is that AI-assisted work needs a memory layer. As output volume goes up, the need for traceability goes up too. You need to know what was generated, what was selected, what was shipped, what worked, and what was abandoned.
The repo becomes less like a folder and more like a record of decisions.
A Possible Future
Maybe every serious function ends up with a repo, even if it is not literally GitHub.
Engineering already has one.
Marketing gets one.
Finance gets one.
Product gets one.
Recruiting gets one.
Design gets one.
Not because everyone needs to become an engineer, but because AI makes more work legible as versioned artifacts.
The interesting future is not that every employee has a GitHub streak. That would be a shallow version of the idea.
The interesting future is that companies get a clearer view of how work actually moves:
drafted -> reviewed -> shipped -> measured -> iterated -> archived
That graph may matter more than the org chart.
Because in an AI-assisted company, the question is not who can produce the most stuff. Everyone will be able to produce more stuff.
The question is who can turn judgment into shipped artifacts, and shipped artifacts into learning.
GitHub gave engineering a way to see that motion.
Now the commit graph may be escaping engineering.