Using an AI Coding Agent on a Repo You Don't Own

The technique does not change much when the repository belongs to someone else. The constraints do. You are accountable for code you did not write, in a codebase whose conventions you did not choose, and you may be sending someone else's source to a vendor without having asked. That last one ends contracts.

This is the working process for three situations that share the same shape: contract work in a client's repo, contributing to an open source project, and your first weeks at a new job.

Before the agent touches anything, settle permission

Not a formality. Client agreements increasingly name AI tools explicitly, and the clause is often in the master services agreement rather than the statement of work you actually read.

• Client repos: check the contract for AI, machine learning, or third-party processing language. If it is silent, ask in writing. A one-line email saying which tool you use and whether it retains data is cheap insurance.

• Open source: check for a contributor licence agreement and whether the project has a policy on AI-assisted contributions. Several large projects now require disclosure, and a few decline such contributions entirely. The Apache CLA is the template most projects work from.

• New job: your employer's policy exists even if nobody mentioned it in onboarding. Ask your lead which tools are approved before you point one at the monorepo.

If the answer is no, that is a real answer and it is survivable. Working slower is better than an avoidable breach conversation. Should I tell clients I use AI covers how to raise it without making it sound like a confession.

Establish what leaves the building

An agent reads far more than it edits. Whatever your tool's retention policy says, assume every file it opens has been transmitted, and audit accordingly.

1. Scan for secrets before you start, not after. Gitleaks over the full history takes a minute and regularly finds a key in a commit from 2023 that nobody remembers.

2. Check fixtures and seed data for real customer records. Test files are where production data goes to hide, and they are exactly what an agent reads to understand your schema.

3. Put a deny list in the agent's config for .env, credential directories, customer data dumps and anything under a legal hold. which files your AI coding agent should never write has a starting list.

4. Confirm where the vendor processes and stores context. If you cannot answer that question for your client, you cannot get permission from them honestly.

Spend the first session reading, not writing

The temptation in an unfamiliar repo is to fix something immediately to prove you can. Resist it. An agent is significantly more useful as a guide than as a contributor in week one, and a wrong first pull request costs more trust than a slow one.

Useful opening prompts, none of which modify anything:

• Trace the path from the main entry point to where a request is handled. Name the files in order.

• Find the three files changed most often in the last year and explain what each is responsible for.

• Show me how this project does error handling, with two real examples from the code.

• What conventions does this codebase follow that are not written down anywhere?

That last question is the valuable one. Every codebase has unwritten rules, and breaking them is how an outsider's patch gets rejected on style rather than substance. How to get an AI coding agent to explain a legacy codebase goes deeper on the reading phase.

Fence the agent tighter than you would at home

In your own repository, a sprawling change is an inconvenience. In someone else's, it is a review burden you are imposing on a person who did not ask for it.

Most agents support a project-level instruction file. Write these constraints into it in the first hour rather than repeating them per prompt. How to write an AGENTS.md file covers the format, and the rest of our AI coding tools coverage covers the tooling around it.

Make the agent copy their style, not yours

An agent left to its own preferences writes generic, modern, opinionated code. In a codebase with ten years of accumulated decisions, generic and modern reads as foreign, and foreign gets rejected.

The technique that works is grounding rather than instruction. Instead of describing the style you want, hand the agent two or three real files near the code you are changing and tell it to match them, including the parts it would prefer to improve. Naming, error handling, test structure, comment density, how they organise imports.

Then read the diff for the tells. The commonest are: a helper function introduced where the codebase has an existing utility for exactly that, a different assertion library in a new test, and a defensive null check the surrounding code does not bother with. Each one is a small signal that an outsider wrote this.

Own the diff before you send it

This is the part that separates a contributor from a liability. Whatever produced the change, your name is on it, and "the agent wrote that" is not a defence anyone accepts.

1. Read every line. If the diff is too big to read carefully, it is too big to submit. Split it.

2. Be able to explain any line without looking it up. A maintainer asking why you did something and getting a shrug is the end of the review.

3. Delete what the task did not require. Improvements nobody asked for are a cost to the reviewer, not a gift.

4. Write the pull request description yourself. It is short, it is where you demonstrate you understood the problem, and it is the one artefact a maintainer reads before anything else.

5. Check the licence implications if any code looks like it came from somewhere specific, particularly a distinctive algorithm or a block that carries its own comment style.

Aim for a smaller change than you think is impressive. A reviewer who can hold your whole diff in their head approves it today. One who cannot puts it off until Thursday.

FAQ

Do I have to tell the client I used an AI coding agent?

If the contract requires it, obviously. If it is silent, tell them anyway. It takes one sentence, it is increasingly expected, and finding out later from someone else is the version that damages the relationship.

Can I use an agent on a private client repo at all?

Usually yes, with permission and with the deny list in place. The blockers are specific: an explicit contractual prohibition, regulated data in the repository, or a client whose own customers have restricted onward processing. Ask, do not assume either way.

What about open source projects that ban AI contributions?

Respect it without arguing. Projects taking that position generally have a provenance or licensing reason behind it, and a contributor who ignores the policy gets their patches reverted and their reputation attached to the incident.

Is it different for a codebase I have just inherited at a new job?

The permission question is easier and the style question is harder, because you will live with the result. Weight the reading phase heavily. An agent that explains the codebase well in week one is worth more than one that ships a feature in week one.

Who owns the code the agent produced in someone else's repo?

Whatever the contract or licence says, which is almost always the repository owner. The agent does not change the answer, though it can complicate the provenance question. Who owns AI generated code covers the current position.