Giving an AI coding agent access to a repository is not one decision. It is a bundle of decisions about what the agent may change, how much evidence it must produce, who absorbs the review cost, and when it must stop. Treating all of that as “repository access” is how a useful tool becomes an unbounded experiment.

A change budget makes the authority explicit. It defines a small unit of work an agent may perform before it needs a human decision: one package, a narrow behavior, a limited number of files, or a known test target. The budget is not a quota for generating code. It is a safety and reviewability boundary.

Start with the smallest useful authority

An initial budget should match work whose failure mode is easy to contain. That usually means a change with an existing owner, a clear test path, and no surprising side effects.

Budget dimension	Early default	Why it matters
Change surface	One package or clearly bounded directory	Keeps review and rollback local
Behavior	One stated outcome and one preserved boundary	Prevents adjacent cleanup from becoming the task
Files	A modest, explainable limit	Makes expansion visible instead of accidental
Evidence	Focused test plus required local checks	Connects the patch to its proof
Risk	No credentials, migrations, permissions, or production configuration	Keeps consequential decisions with accountable humans

For example, an agent might add a regression test and repair the retry classification that test demonstrates in one service. It is not thereby authorized to update shared retry policy, regenerate a client library, rename surrounding abstractions, and reorganize the package. Those may be reasonable later tasks. They are separate decisions.

This is why a pull request needs a coherent shape. How To Keep AI Coding Agent Changes Small Enough To Review makes the practical case: a small change is easier to verify, discuss, revert, and learn from.

Write the budget into the task

Do not make the agent infer its limits from a ticket title. State the work, the proof, and the stop conditions in the request. A useful contract might say:

Update the transient-timeout classifier in payments/retries. Add a focused regression test and run the package checks. Do not change retry behavior for writes, shared client policy, generated files, dependencies, or configuration. Stop and explain if the fix requires any of those.

That is not prompt decoration. It gives the agent a definition of done that is smaller than “make the problem disappear.” It also gives the reviewer a fast way to see whether the patch stayed inside its authority.

The task should answer four questions:

• What observable behavior should change?
• What must not change?
• Which commands or tests count as evidence?
• Which conditions require escalation rather than a workaround?

The last question matters most. An agent that can stop cleanly is safer and more useful than one that keeps trying increasingly broad fixes. A Safe Developer Feedback Loop for AI Agents explains why the local test and CI contract are part of the interface, not an afterthought.

Escalate on a change of risk, not a change of confidence

Agents can sound confident while encountering a situation that deserves a different owner. Escalation should be driven by the type of work, not whether the agent can propose a plausible patch.

Require a human decision when the work touches:

• Authentication, authorization, secrets, or privacy-sensitive data.
• Schema migrations, destructive data repair, or backfills.
• Public APIs, compatibility commitments, or versioned clients.
• Dependency, lockfile, generated-code, or build-tool changes outside the stated task.
• Production configuration, infrastructure policy, release controls, or cost limits.
• More files, packages, or behavior than the original budget allows.

Escalation is not a failure. It is the agent returning useful information: what it inspected, what it tried, what it observed, and exactly which boundary blocks a safe next step. That handoff is more valuable than an expansive patch that forces a reviewer to rediscover the problem from scratch.

Spend budgets deliberately

The budget can grow, but only after the team sees evidence that the current level works. Keep a lightweight record for a class of tasks: how often the agent stayed in scope, whether reviewers found the evidence sufficient, how often it escalated appropriately, and whether the change created rework or regressions.

Then expand one dimension at a time. A team might move from one file to one package, or from a focused test to a package suite, while leaving production configuration out of bounds. Expanding every dimension together makes it impossible to learn which guardrail mattered.

This is particularly useful for platform teams. A recurring escalation around a slow test, undocumented local command, or ambiguous ownership boundary is not evidence that the agent is weak. It is a visible seam in the developer experience. Fixing that seam helps humans too.

Keep humans accountable for the decision

A change budget is not a replacement for code review, service ownership, or release discipline. The person approving a change still needs to understand its intent, evidence, residual uncertainty, and rollout path. The agent can make that work faster by producing a smaller, better-explained patch; it cannot assume the accountability.

The useful leadership question is not “Which repositories can the agent access?” It is “What authority can we grant that a reviewer can still evaluate honestly?” Start there, make the budget explicit, and earn the next increment with evidence.

For more engineering leadership and practical AI workflow guidance, visit Slaptijack.