AI changes in a monorepo: shared packages and affected behavior

Map packages to consumers

Map applications, shared packages, configuration and generated files, then identify callers of the target behavior. A workspace configuration does not necessarily reveal every business dependency or execution requirement. In a hypothetical repository, both a public app and an admin app use a shared amount formatter. Inspect their expectations before editing the formatter in isolation. Similar function names do not establish identical semantics. First determine whether consumers rely on the same contract. This turns the repository structure into a change boundary rather than assuming every package under one root should be modernized in the same patch.

Separate investigation and edit scope

Reading a consumer to understand a contract does not authorize rewriting that consumer. Investigate the function, types, callers and tests, then ask for a concise edit plan. A workflow might use Cursor or Claude Code for discovery and a known-file Aider edit, but no product name itself proves the scope is enforced. Inspect the actual Git diff and separate unrelated formatting or dependency upgrades. The goal is not to appear narrow by omitting evidence. Understand the affected boundary, then limit the change deliberately so a reviewer can explain both the edited files and the consumers left untouched.

• Minimizing repository context supplied to AI

Plan compatibility across consumers

For a new required field in a shared type, identify when each application releases. Do not assume simultaneous cutover. Consider addition, consumer changes and cleanup as separate stages. If a planning tool such as Kiro is used, concurrency must follow real dependencies rather than a preference to run more tasks at once. Check absent values and older stored data as well as compilation. One consumer adopting a new implementation does not establish that another consumer no longer needs the old contract. Preserve that transitional condition explicitly in the implementation and release plan.

Hypothetical task: an optional formatting rule

For a hypothetical shared formatter, add an optional rule controlling trailing decimals. Without the option, preserve prior output; with it, return independently agreed examples. Prepare existing inputs from both public and admin apps so a patch cannot pass only one consumer’s assumptions. A responsible owner, not the agent, should establish currency and rounding semantics. This is not a measured product test. It exercises the explanation of a small shared change across both consumers, connecting the source diff to the behavior each application must preserve rather than accepting a locally passing function test alone.

• Using AI for refactoring without changing behavior

Connect affected scope to checks

Include consumer type checks and necessary builds as well as the shared package’s tests. npm documents workspace-targeted execution, but inspect what the repository scripts actually verify. Ignoring a missing script is not evidence that its behavior passed. If the lockfile changes, explain why and inspect unnecessary shared dependency movement. Record executed and untested targets explicitly. A successful check in one package should not be described as verification of every consumer. This makes selective testing reviewable and prevents a scope-saving decision from silently dropping the application behavior the shared change can affect.

Coordinate work and preserve ownership

When several agents are involved, assign one owner for a shared file or lockfile. Independent edits still need verification in the integrated result. Before buying more capacity, inspect duplicated ownership and repeated whole-repository investigation. Handoff should contain the relevant dependency map, rationale, required ordering, checks and remaining compatibility conditions. Keep the project maintainable with ordinary Git and tests after the model arrangement changes. The next maintainer should be able to plan the follow-up without reconstructing the original conversation or assuming a collection of individually successful patches is automatically a valid combined release.

• Investigating regressions after dependency upgrades with AI