Take Over an Existing App Before Your Agent Changes It

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Take over an existing app by establishing what runs before asking an agent to improve it. Name the repository, tracked branch, public entry points, backing services, owners, and one small change that can be tested. That map protects the undocumented behaviour a plausible agent patch can erase.

You do not need to read every file before you move. You need enough evidence to predict the consequences of one change. Start from the request a user makes, trace the code and services it touches, and write down surprises while they are still visible.

Start with the running path

Production is the source of truth when the README, repository, and deployment settings disagree. Find the public address, then follow one ordinary user request through the application. Record the route, process, database tables, third-party calls, scheduled jobs, and values that the path requires.

This approach produces facts that a new maintainer can verify. Reading folders in alphabetical order produces impressions. Inheriting a codebase you did not write gives the broader mapping method; the short brief below turns it into a first work session.

If you are bringing in a provider, use the rewrite proposal brief to agree on discovery, acceptance, and handover evidence.

When the app still runs on a VPS, use the VPS cutover sheet to plan data transfer, domain switching, and recovery.

Ask the agent for evidence, not repairs

An unfamiliar repository invites a vague request such as "clean this up". That request encourages an agent to choose a design before it knows which behaviour customers depend on. Ask for callers, writes, failure paths, and configuration sources first. Then inspect the answer against code, logs, and a live request.

Give the agent a bounded task. It may identify an unused route or a missing value; it must stop before changing credentials, schema, or deployment settings without approval. Who reviews the code the agent wrote? explains why fluent output still needs a checkable reason.

Make one small release do the learning

Choose a user-visible change that does not alter the system's shape: fix one label, add one validation rule, or improve one error message. Take that change through the real build and release path. It reveals the branch that actually deploys, the health check that decides success, and the step nobody has run for months.

Avoid a rewrite on the first week. A rewrite discards the inconvenient behaviour you have not discovered yet. Move a legacy app without a rewrite shows how to make one deployable work before you split it or replace it.

A codebase takeover brief

Keep this brief in the issue that authorises the first change. Update it when evidence disproves an assumption.

CODEBASE TAKEOVER BRIEF
Repository and tracked branch:
Person responsible for the next release:
Public entry points and known users:
One request traced from browser to data:
Processes, jobs, and third-party services it touches:
Values and credentials by owner, never by value:
Build command, port, health path, and current address:
One small change approved for the first release:
Rollback condition and the person who decides it:
Unknowns that require a stop before changes:

FAQ

How much of an unfamiliar codebase should I understand before changing it? Understand one user path well enough to say which process, data, and external services it uses, then make a small change through the real release path. You learn more from that controlled release than from a week of unguided reading.

Can an agent map an existing application safely? Yes, when it is asked questions with evidence: which code calls a function, where a record is written, which value a process reads, and what the log says after a failure. Do not ask it to redesign the system before it can answer those questions.

Why should the first release be small? A small release tests the branch, build, runtime, and review process without combining that discovery with a schema rewrite or architectural change. When it fails, the team can isolate the cause and reverse one decision.

How does aidrop.it support a takeover? A Project keeps the repository, build history, address, runtime settings, and names of required values together. A later agent session can inspect those records before it changes code, while the repository and Git history remain under the team's control.