One sentence can decide whether an AI coding agent makes a clean port or creates a confusing mess:

Copy the behavior, not the identity.

That is the phrase I want to remember.

When I say, “I like this tool in one place; can we copy it somewhere else?”, I do not always mean “merge these systems.” I usually mean: take the useful idea, the workflow, the UI pattern, or the command behavior, then rebuild it under the target project’s own name, structure, and deployment rules.

That distinction matters more than it sounds.

The quiet danger

Modern coding agents are good at finding working examples. Sometimes too good.

If one tool works in Project A, an agent may copy more than the logic. It may also copy the project identity around that logic:

  • manifest names
  • assembly names
  • package names
  • namespaces
  • unique IDs
  • startup classes
  • deployment folders
  • routes, tabs, or entrypoints
  • branding and ownership labels

That can make the target project appear to work for a moment while quietly depending on the wrong loader, wrong config, or wrong deployment path.

The feature moved, but the identity came with it.

That is how independent tools become cross-wired.

The better instruction

The clearer request is:

Port the behavior into the target project, but preserve independent identity and deployment boundaries.

For a coding agent, that sentence carries a lot of useful constraints.

It says:

  • keep the source project buildable
  • keep the target project buildable
  • do not rename the target after the source
  • do not reuse source-specific IDs unless they are intentionally shared
  • do not make one project own another project’s entrypoint
  • do not let one deployment script overwrite another project’s files
  • verify both sides still load independently

That is a better direction than “copy this over.”

A reusable checklist

Before porting a tool from one project to another, I want the agent to identify three things.

First: the source.

Where does the desired behavior currently work? What files, commands, UI, tests, or deployment artifacts prove it?

Second: the target.

Where should the behavior live after the port? What conventions does that project already use?

Third: the boundary.

What must remain unique to each side? This includes names, IDs, namespaces, manifests, folders, configs, routes, tabs, package names, startup classes, and publishing paths.

That boundary is the guardrail.

The agent can still be creative inside it.

What I want Codex to learn

I want this to become a general skill:

When copying, porting, adapting, or mirroring functionality between two projects, copy the behavior and UI pattern, not the source project’s identity.

The default should be independence.

If I actually want to merge two systems, I can say that clearly. Otherwise, keep them separate.

The prompt I will reuse

Here is the version I like:

Port the useful behavior and UI pattern from the source project into the target project, but preserve independent identity and deployment boundaries.

Do not reuse or rename source-specific manifests, package names, assembly names, namespaces, unique IDs, deployment folders, startup classes, routes, tabs, branding, or ownership labels unless I explicitly ask for a merge.

The source should keep loading and deploying as itself. The target should keep loading and deploying as itself. Rebuild and verify both sides independently after the change.

That is a small prompt, but it protects a lot of work.

Stay healthy.