A repository canary to remind everyone who decides
The systemd project has added a simple but revealing rule to its AGENTS.md file: when an AI agent modifies source files, it must first add a warning to the README asking the human author to confirm that they have reviewed the pull request. The agent must not remove that line. It should disappear only when a person deliberately removes it after review. The detail may look small, but it captures a major shift in AI-assisted software development: the issue is no longer whether agents can write useful code. The issue is how a team proves that someone is actually responsible for it.
Coding agents now read repositories, follow instructions, edit multiple files, write tests, and prepare pull requests. That capability changes the pace of production. It also makes a very human mistake easier: confusing a plausible change with an understood change. The systemd canary does not ban AI. It does not stigmatize a tool. It adds deliberate friction in the right place: just before the change is presented as ready for review.
For product teams, the gesture is useful because it moves the conversation away from abstraction. This is not a vague policy about AI. It is a visible mechanism inside the workflow. While the marker remains, the contribution signals that it still needs a human act. When it disappears, the author accepts explicit responsibility: I have read this, I understand it, and I am willing to submit it.
Transparency is not enough without responsibility
Many organizations start by asking developers to disclose whether a contribution was generated with AI. That is understandable, but it is not always the right control layer. A statement about origin does not tell you whether the code is correct, tested, maintainable, or aligned with the architecture. A human-written patch can be dangerous; an AI-assisted patch can be excellent. The operational question is therefore less “who typed the characters?” and more “who verified the result, and under which rules?”
The systemd decision illustrates that nuance. The project had already relaxed a broad disclosure requirement and emphasized contribution quality rather than the tool used. The canary adds a second layer: if an agent follows the repository instructions, it leaves a trace that forces the human to intervene before final submission. This is lightweight governance, but it is robust. It does not slow every line of code; it protects the moment when a modification becomes a request sent to maintainers.
The distinction matters inside companies. A policy focused only on disclosure can create surface compliance: a checked box, a pull request comment, and then a quick review. A policy focused on responsibility forces teams to define the expected steps: reading the diff, running tests, checking dependencies, validating roadmap fit, reviewing security, confirming observability, and knowing how to roll back if the change reaches production.
Instructions are becoming a management interface
AGENTS.md files, pull request templates, CI rules, and contribution guides are no longer just documentation. They are becoming a management interface for agents. If a team wants AI to respect its constraints, it has to write those constraints where the agent will read them and where the pipeline can verify them. The repository becomes an operational contract: this is what the agent may do, this is what it must produce, and this is what it may not decide.
Within that contract, some tasks are well suited to delegation: reproducing a bug, proposing a narrow fix, adding a regression test, migrating a repetitive API, improving documentation, or analyzing a lint failure. Others should stay under human control: product trade-offs, risk acceptance, architectural change, permission changes, sensitive data handling, critical dependency choices, and the decision to deploy.
The README marker makes that boundary concrete. The agent can prepare the work, but it cannot erase the signal that asks for review. It resembles a separation-of-duties control: the machine produces, the human validates, and the repository keeps a simple proof that those two roles were not merged into one.
What teams can apply now
An organization does not need to wait for a large transformation program to learn from this model. It can start with three practical decisions. First, write explicit instructions for agents: authorized scope, test commands, branch conventions, commit style, security requirements, and situations in which the agent must stop. Second, add review signals to AI-assisted pull requests: context, tests run, known risks, manual verification points, and a checklist that the author must complete. Third, enforce as much as possible through the pipeline: required tests, secret scanning, dependency checks, human approvals, and blocking rules for sensitive changes.
- For developers, the goal is to save time without losing understanding of the diff.
- For tech leads, the challenge is to turn implicit rules into visible guardrails.
- For product owners, the priority is to know which decisions remain human before release.
- For security teams, the key is to avoid an agent fixing one issue while introducing another, less visible risk.
These practices are modest, but they change the dynamic. AI is no longer an invisible colleague pushing code. It becomes a tool contained by a review system that everyone can read.
Good autonomy is bounded autonomy
The signal from systemd is valuable because it avoids both fear and naive enthusiasm. Yes, agents are becoming good enough to contribute to serious projects. No, that capability does not replace maintainer judgment. The more AI accelerates the production of changes, the more teams need to strengthen the moments of validation. The bottleneck moves: it is no longer only in writing code, but in proving that the code deserves to be integrated.
For OrkestrAI, this is the core lesson: delegate execution, not command. An agent can propose, implement, test, and document. It can even help review. But the decision to submit, merge, and release must remain attributable to a clearly identified person or team. The systemd canary is a small line in a README; its lesson is much larger. The future of AI-assisted development will not be only about more powerful models. It will depend on workflows where humans keep control precisely at the moment when responsibility begins.
