Outside technical leadership for one repo and many assistants

Why one repo gets messy fast

A single repo looks simple at first. Then the team adds two or three coding assistants, each developer keeps their own prompts, and the code starts drifting into little islands. One assistant creates services/, another prefers lib/, and a third drops the same logic into utils/. Nobody plans a mess, but the repo gets one anyway.

The bigger issue is not style. It is coordination. Prompts drift, expectations change, and the code stops feeling like it came from one team. One developer asks for strict TypeScript and small functions. Another pushes for speed and gets large files with mixed concerns. A week later, both versions work, but they do not fit together. The team burns time renaming folders, moving files, and fixing patterns that should have matched from the start.

Tests make the problem sharper. In a shared repo, a small edit in one file can break something far away. A helper changes shape, a shared type gets looser, or an assistant rewrites a query that looked harmless. The person who made the edit may never see the weak spot because the failure appears somewhere else in the product.

Human review often breaks down at the same time. Teams know some changes need close attention, but they rarely agree on which ones. Then they fall into familiar habits: everything waits for review and shipping slows down, or almost nothing gets real review and risky changes slip through. Reviewers end up commenting on naming and formatting because deeper checks take more time, and developers start treating review comments as background noise.

A small product team feels this fast. Picture four developers in one repo with three assistants. By Friday, the login flow still works, but the test suite is flaky, the API layer has three patterns, and nobody is sure whether a migration script needed a second set of eyes.

This is where outside technical leadership helps. An experienced fractional CTO or advisor usually spots the pattern early. The repo does not have a code problem first. It has a coordination problem. Until someone sets shared rules for structure, prompts, and review lanes, the team keeps repairing avoidable damage instead of building product work.

What goes in a context pack

A good context pack answers the questions every developer and coding assistant asks in the first ten minutes. If those answers live in one short document, people stop guessing. They stop putting code in random places, and reviews stop bouncing back for basic cleanup.

This is often easier for an external CTO or advisor to write. Someone outside the day-to-day habits can put the rules in plain language and spot missing pieces quickly, especially when several people and several assistants touch the same repo.

A useful pack usually has five things. Start with a short product summary: what the product does, who it helps, and what the team is trying to improve right now. Add a folder map that shows where new code belongs. If UI code goes in one place, background jobs in another, and shared types in a third, say that directly.

Then set naming rules for files, functions, components, and branches. These sound small, but they save a lot of review time because people stop inventing their own patterns. After that, include a pre-review test list. Tell people what to run before they ask for review, whether that is unit tests, linting, type checks, or one manual check in the product.

The last part is command rules. List what people can run and what they must not run. Allow read-only inspection commands and normal test commands. Block risky actions such as database wipes, force pushes to protected branches, and broad search-and-replace scripts.

Keep the pack short. If it takes 20 minutes to read, people will skip it. Two or three pages usually work better than a handbook nobody opens. Write the rules like instructions, not policy text.

Command rules keep output consistent

A good lead turns team habits into a short command sheet. That matters even more when several assistants touch one repo. If each assistant invents its own way to test, format, build, or start services, the code drifts fast and people stop trusting the output.

The fix is simple: give one approved command for each routine job. One way to run tests. One way to format code. One way to start the app and its local services. Clear rules leave less room for guessing.

A small rule sheet often beats a long policy doc. Five or six commands are enough for daily work. Put them where people already look, such as the main README and the repo root, and write them so anyone can copy and paste them without editing.

# local setup
docker compose up -d

# start app
make dev

# format code
make fmt

# run checks
make test
make lint

Safe local commands should cover normal work only. People need to install dependencies, start services, run tests, check logs, and seed local data. They do not need commands that can damage shared work or erase data. Spell out the blocked actions in plain language.

A short list is usually enough:

• Do not use git push --force on shared branches
• Do not run git reset --hard unless you are on your own branch and know why
• Do not run delete commands against shared databases
• Do not stop or remove shared containers from remote environments
• Do not change migration history by hand

That last point matters more than teams expect. Many assistant mistakes come from valid commands used in the wrong place. Good rules make the boundary clear: what is safe on a laptop and what is never safe outside it.

Keep the wording tight. If people cannot remember the rules after a day or two, the list is too long. The best command rules feel boring, obvious, and easy to repeat. That is exactly why they work.

Review lanes catch problems early

Most teams get stuck when every change goes through the same queue. A docs edit, a CSS cleanup, and a billing change do not carry the same risk. Treat them the same, and people either wait too long or rush the wrong thing.

A good technical lead fixes this by splitting work into review lanes. The idea is plain: docs, copy edits, and small style fixes go into one lane, while production code goes into another. That cuts noise almost immediately.

A practical split

Low-risk changes can move with light checks. If an assistant fixes typos in setup docs or cleans up spacing in a component without changing behavior, the team can approve that work quickly. The queue stays short, and people keep moving.

Production code needs a stricter lane. Any change that touches auth, billing, stored data, or data structure rules should stop for human review. The same goes for permission logic, migrations, and anything that could break user access or money flow. Assistants are useful here, but they should not be the last reviewer.

A short checklist keeps the split clear:

• Does this change behavior or only text and style?
• Does it touch auth, billing, or stored data?
• Can we roll it back in a few minutes?
• Did tests pass, and is the diff small enough to review quickly?

This does two jobs. It catches risky changes early, and it stops endless debate about where a pull request belongs.

One person should own exceptions. Pick a founder, engineering lead, or fractional CTO and let that person decide when a change falls into a gray area. If nobody owns exceptions, every unusual pull request turns into a group argument.

The logic is simple. A wrong comma in docs is annoying. A wrong condition in billing code can create refunds, support tickets, and hours of cleanup. Review lanes should reflect that difference before the damage spreads.

Roll this out in one week

One week is enough if the scope stays tight. Start with cleanup, not a pile of new rules.

On day one, map what already touches the repo. Write down every assistant, plugin, script, prompt template, and local helper the team uses. Include who uses each one, what it changes, and where its instructions live. Most teams find overlap quickly, and that overlap is where mixed habits start.

Day two is for one context pack for the repo that matters most. Keep it short enough that people will actually read it. Include the stack, folder structure, naming rules, test commands, files that need extra care, and a plain definition of done. If a new developer or assistant still cannot work from that document, it is too vague.

Day three is where many rollouts fail. Add command rules, then retire the old notes scattered across chats, docs, and saved prompts. One source of truth beats five almost-correct ones. Simple rules work best: change only listed files, ask before touching schema or auth, run the agreed checks, and explain any guess instead of hiding it.

Day four, set review lanes by risk. Do not sort them by seniority or status. A text fix or small style change can move through a light lane. Business logic, billing, permissions, infrastructure, and data changes need a stricter lane with human review. People follow review rules when the effort matches the risk.

Day five, test the setup on one small feature. Pick something real but contained, like adding a settings field or adjusting an admin screen with one small backend change. Watch where the assistant drifts, where the context pack stays silent, and where review takes too long. Fix those weak spots the same day.

This kind of rollout works well with a fractional CTO because they are not busy defending old habits. Oleg Sotnikov does this sort of practical setup around AI coding workflows and review process design, then leaves teams with rules they can keep using after the first week.

A simple example from a small product team

A four-person product team has one shared repo, and three developers use different assistants. One leans on Claude for backend work, another uses GPT to clean up tests, and the third works inside an editor agent that happily renames files when it thinks the code will read better.

On Monday, they all touch the same feature. The first developer adds a new endpoint for customer exports. The second asks GPT to rewrite the test suite around that area because the old tests feel messy. The third spots inconsistent names and lets the editor agent rename files and update imports.

By Tuesday, the branch is bigger than the feature. The endpoint works, but it lands in the wrong folder. The tests pass, but they use a different style from the rest of the repo. The renames are technically fine, yet they make the diff harder to review and raise the chance of merge conflicts.

A short context pack prevents most of this before the branch spreads. It tells every assistant where API endpoints go, how handlers are named, when tests can be rewritten, and when file renames are off limits unless the task calls for them. It can also include plain rules such as "keep existing test style" and "do not move files during feature work."

This is where outside technical leadership earns its keep. Someone outside the daily rush can write rules the team will actually use because they match the repo instead of some generic template.

The team also sets review lanes. Any change that touches database fields, migrations, or payload shape goes to the senior reviewer first. Test-only edits go through the normal lane. In this example, the export endpoint includes a data change, so that part gets checked early before the rest of the branch grows around it.

The result is boring in the best way. The team ships one clean change set instead of a feature plus two rounds of repair work. That usually saves more time than adding another assistant.

Why teams ignore the rules

Most teams do not reject rules because they dislike standards. They reject rules when the rules waste time, clash with daily work, or change so often that nobody trusts them.

The first mistake is writing a guide so long that nobody can use it under pressure. If the repo has a 40-page handbook, developers will skim the first section, copy an old prompt, and move on. A short context pack works better: project goals, repo map, coding limits, common commands, and a few real examples.

Another common mistake is changing the rules every week. People need some stability before a habit forms. If command names, review steps, or prompt templates keep shifting, developers save their own versions and assistants drift in different directions. Freeze the core rules for a while, then change them only when reviews keep finding the same bug or a real risk shows up.

Teams also lose patience when they mix style rules with product decisions. "Use this folder structure" is a repo rule. "Do not build this feature yet because pricing may change" is a product call. When both live in the same document, nobody knows what is permanent and what is temporary.

A shared repo also gets harder to manage when each tool invents its own command list. If one assistant uses /plan, another uses /spec, and a third writes its own format, developers stop memorizing any of it. Pick one shared command set and make every assistant follow it. An external lead is often most useful here because they can cut duplicate rules without defending old habits.

New hires and contractors need onboarding, even if the rules look obvious to the people who wrote them. A 30-minute walkthrough saves days of cleanup later. Show them the context pack, run one command flow together, and explain how review lanes work in practice.

You can usually spot rule fatigue early. People ask the same setup questions, pull requests all look different, and reviewers repeat the same comments. That is rarely a discipline problem. Usually, the system is harder to follow than the work itself.

Small startups do better with fewer rules that stay put, one command language across assistants, and a short onboarding routine that every new person gets on day one.

Checks before adding another assistant

A new assistant can save time, or it can add a second set of habits to the repo. Trouble starts when one tool writes code from shared team rules and another works from its own hidden prompt. The split shows up quickly in naming, tests, folder structure, and review noise.

Start with shared context. If the assistant cannot read the same context pack your team uses, it will guess. Those guesses create a pile of small messes: a handler in the wrong layer, a test style nobody asked for, a migration that ignores local rules.

Then check how the tool follows commands. Some assistants only behave after a stack of private prompt hacks, browser extensions, or local wrappers. That usually breaks as soon as one developer updates their setup. If the approved commands work for the team, they should work for the assistant too. If they do not, the tool is a special case, and special cases rarely stay tidy.

Every change also needs a clear trail. You should know who started the task, what the assistant touched, and who reviewed the result before merge. If that trail lives in three chat windows and one local terminal, you do not have accountability. You have folklore. Two weeks later, when something odd lands in the repo, nobody can explain it.

Keep the first rollout narrow. A brand new assistant should not edit production paths, touch live data, or rewrite customer-facing content on day one. Give it low-risk work first: test fixes, refactors in one module, or docs that stay inside the repo. Trust grows from boring, repeatable output, not broad access.

One more check gets skipped all the time: who can turn it off fast? Pick one owner. Give that person the right to block the assistant, revoke tokens, or remove it from the workflow the same day. Small teams need this more than big ones. If a tool starts creating bad pull requests on Tuesday morning, waiting until next sprint is too slow.

A simple rule works well: no new assistant enters the repo unless it shares context, obeys the same commands, leaves a clean audit trail, starts with limited access, and has a named shutdown owner. That sounds strict, but it is still cheaper than cleaning up six weeks of confident nonsense.

What to do next

Pick one repository and use it as the trial run. Do not spread new rules across every project at once. One context pack, one short command file, and two review lanes are enough to show what works.

Choose the failure that wastes the most time today. Maybe assistants keep changing files outside the task, skipping tests, or inventing patterns that do not match the repo. Write one rule for that problem first. If a developer can read it in ten seconds and apply it without guessing, people will follow it.

For example, if an assistant keeps editing billing code during a simple UI ticket, make the rule plain: stay inside the listed folders unless the prompt names a dependency change. One sentence like that can prevent hours of cleanup.

A lean starting setup is enough:

• a context pack with product goals, stack, folder map, and no-go areas
• a command rule file with naming, testing, and scope limits
• one fast review lane for style and repo rules
• one deeper review lane for architecture, security, and database changes

Run that setup for two weeks and watch behavior, not opinions. Which rules stop real mistakes? Which ones do people skip or forget? Cut the rules nobody uses. Keep the ones that reduce rework, shorten reviews, or prevent risky edits.

If you need help setting this up, Oleg Sotnikov covers this kind of AI-first engineering work on oleg.is and works with startups and small teams as a fractional CTO. The goal is simple: a repo where assistants stay in bounds, reviews get shorter, and fewer mistakes reach production.