Recently a friend asked me whether it makes sense to put agent-generated code in Git.
It’s a great question and he knew full well why he was asking me – I was always strongly against committing “machine-generated files” into the source control. My reasoning for that was simple: if a file can be produced from a source of truth, committing it is redundancy at best and confusion at worst. It blurs the line between what you author and what you merely build.
But is this still the case?
Agent output is not “compiled code.” It is non-deterministic.
You can run the same prompt tomorrow and get a different result, even if you think you kept everything the same. In an agentic world, the old rule still holds – don’t commit deterministic build outputs. Since agent output is not deterministic, this expands our source concept to encompass more than just human-originated files.
Git should track anything you can’t deterministically recreate. In practice, that means all human-authored artifacts, and most agent-authored artifacts, belong in source control.
Meanwhile, deterministically generated artifacts – object files, executables, build outputs – still must never enter Git.
Here is a more powerful way of putting it: treat your AI peers as you would your human peers, and expect the same rules of conduct, source management included.
1. Define “source” by determinism, not by file type
We tend to treat “source” as synonymous with code.
That was never fully true. It just didn’t matter as much when only humans were authoring the important inputs.
In reality, source is the minimal set of inputs required to reproduce a release. The reason Git matters operationally isn’t that it stores text files. It’s that it gives you a time machine: diffs, blame, rollback, branching, review.
So here’s the rule that scales in 2026:
- Deterministic pipeline: same inputs → same output (within practical tolerance).
- Non-deterministic pipeline: same inputs → potentially different output.
If something is deterministic, you can always rebuild it. Committing it is noise.
If something is non-deterministic, “just regenerate it” is not a plan. It’s wishful thinking.
A simple litmus test:
- If you rerun this tomorrow, will you get the same file?
- If yes: treat it as a build artifact.
- If no: treat it as source (or figure out what you missed)
This is why compiled binaries don’t belong in Git, while design assets do. It is also why agent-authored results should be in Git.
2. Treat agent output as authored work, not as “generated code”
The phrase “generated code” is doing a lot of damage.
It suggests that an agent is a compiler: you feed it source, it produces output, and the output can be reproduced whenever you need it.
That is not what’s happening.
An agent is effectively another engineer, authoring their own changes to the source as they see fit in the moment. You can ask again and get something different. Sometimes better, sometimes worse, sometimes subtly incompatible with what you already shipped.
Operationally, that means agent output has the same properties as human output:
- It needs review.
- It needs diffs.
- It needs accountability.
- It needs rollback.
And it needs those things even if the agent produced it in 30 seconds.
If you don’t commit the agent’s result, you are choosing to lose the single most useful debugging tool you have when things go sideways: “what changed?”
When production behaves differently from what you expected, you don’t want a philosophical debate about whether the code is “real.” You want a commit hash.
So yes: agent-created artifacts that are meant to be maintained should be committed.
Not because Git is a storage bucket.
Because Git is the collaboration protocol your team already trusts.
3. Keep the hard rule: deterministic build outputs never enter Git
None of this is a license to start committing everything.
The classic rule is still correct:
- Object files
- Executables
- Minified bundles
- Artifacts generated deterministically from versioned inputs (e.g.,generate code, rendered docs, compiled bundles)
- Build caches
These should not be in Git.
Not because they’re “ugly” – because they are fully reproducible, thus adding 0 new information.
Committing deterministic outputs causes predictable pain:
- Huge diffs that hide real changes
- Merge conflicts in files nobody should edit
- Repo bloat
- Confusion about what matters
In a healthy setup, deterministic outputs go to the right place:
- Container images to a registry
- Packages to a package registry
- Build artifacts to an artifact repository
And Git holds the recipe and intent.
4. Put product intent in Git: specs, requirements, and feature definitions
Here’s the bigger shift most teams still underestimate.
In an agentic workflow, written intent becomes a primary input.
Agents don’t just transform code. They transform requirements into code. They transform feature descriptions into tests. They transform acceptance criteria into implementation plans.
If you keep the intent in a Word document that lives in someone’s email thread, you’re effectively hiding source from your system.
This is why “all human-created artifacts should be in source control” is not a slogan. It’s an engineering requirement.
Specifically, track:
- Product specifications
- Feature descriptions
- Detailed requirements
- Acceptance criteria
- Test scenarios and test cases
- Rollout plans and risk notes
The move from binary documents (Word, PDF) to text-based specs (Markdown) makes this easier than ever. Markdown is diffable, reviewable, linkable, and easy to automate.
Treat specs like code:
- Pull requests for changes
- CODEOWNERS to enforce ownership (product + engineering)
- A template that forces clarity
A simple template goes a long way:
- Problem statement
- Non-goals
- Proposed behavior
- Edge cases
- Observability expectations
- Rollout and rollback plan
When an incident happens, you should be able to diff not only the code but the intent that led to said code. That’s how you avoid shipping surprises.
5. The Dark Factory
At the frontier of agent-driven software development, some companies are explicitly chasing what’s been nicknamed the Dark Factory: a fully agentic development process where humans don’t write code – and don’t even review it.
That sounds provocative, but it’s also a useful forcing function. It makes you ask the uncomfortable question: if humans aren’t the reviewers, what becomes the system of accountability?
Historically, source control was one of the main enablers for scaling software teams. It gave you a shared substrate for parallel work: branching, review, controlled merging, and the ability to reconstruct “what happened” when production broke.
In a Dark Factory setup, Git becomes even more central – not just as a human collaboration tool, but as a coordination layer for agents.
A few concrete examples:
- Branching as parallelism: multiple agents can take separate branches, explore solutions, and converge without stepping on each other.
- Controlled merging at scale: merge conflicts and integration risk don’t disappear – so you need a disciplined flow that makes integration explicit and testable.
- GitOps-driven environments: dynamic test environments become a natural extension of the repo. Change a branch, get an environment, run scenario tests, promote by merge.
The punchline isn’t “remove humans.” The punchline is that if you do push autonomy this far, Git is one of the few mature mechanisms you have for maintaining continuity: history, diffs, rollback, and traceable state. And since agent-only teams are both much faster and much bigger this is key.
Which leads to the next required input: versioning the agent itself.
6. Version the agent’s “mind”: prompts, configs, tools, and skills
If agent output is non-deterministic, the agent’s configuration is part of your build system.
And unversioned build systems are how teams end up with spooky action at a distance.
You’ll often have key files beyond project source code:
- Agent configurations
- Tool manifests and permissions
- Skill definitions / playbooks
- Guardrails and policies
- Prompt templates
These influence outcomes as strongly as compiler flags influence binaries.
If you can’t answer “which agent configuration produced this change,” you will eventually be unable to reproduce your own decisions.
Keep these in source control.
If you centralize them in a separate repo, pin versions. If they live alongside the code, treat them as first-class.
The goal is not perfect reproducibility.
The goal is traceability.
7. Make traceability a release requirement
Whether you prefer a mono-repo or a set of interconnected repos is largely a workflow choice.
But traceability is not.
In any topology, you must ensure:
- Every release maps to specific commits
- The source code that led to the release is recoverable
- The specs and configurations that influenced the release are recoverable
This matters more with agents because the number of inputs grows:
- Code
- Specs
- Agent config
- Tooling versions
- Policies
If you don’t tie these together, you’ll end up with a release you can’t explain.
A practical habit: create a release manifest as a text file in Git.
It can be simple:
- Release version
- Commit hash(es)
- Agent config version
- Spec version or link
The point is to make “what did we ship?” a deterministic question, even if parts of the process weren’t deterministic.
8. Use Git as the collaboration bus for humans and agents
The most practical reason to commit agent-produced artifacts is that it allows agents to work the way humans already do.
If agent work is outside Git:
- It can’t be diffed.
- It can’t be reviewed.
- It can’t be rolled back.
- It can’t be merged cleanly.
Once it’s in Git, you unlock the mature workflow we already know:
- Branches for experiments
- Pull requests for review
- CI gates for quality
- History for debugging
Even small conventions help:
- Label PRs that are agent-authored
- Require tests and lint
- Require a human reviewer (or strict automated policies)
- Keep commits structured: intent, scope, risk
The goal isn’t to “trust the agent.”
The goal is to keep your engineering system trustworthy.
Conclusion
So, should you put agent-generated code in Git?
Short answer: Yes. Definitely.
Why? It turns out that the old rule was never “don’t commit generated things.” It was: don’t commit what you can deterministically regenerate.
In the AI age, the boundary moved. Agents don’t compile. They author.
Git remains our system of record and central infrastructure for effectively scaling the development team, and agents are becoming its key contributors.
