Here, reverse engineering means understanding software from its available implementation and observed behavior. Work with code you own or are authorized to inspect. The goal is a useful technical map, not a claim that an AI can recover any hidden system.
1. Define the question before reading the repository
Choose one outcome: understand sign-in, locate invoice generation, explain a scheduled import, or identify what must change before a migration. Asking for “everything about this application” often produces a broad summary that is hard to verify.
Agree on the review boundary: which repository and commit, which folders, which environment, and whether the task is read-only. Keep credentials and real customer data outside the initial material. Access to source code does not automatically authorize production queries or external service calls.
Separate four kinds of evidence: source files, configuration examples, tests, and observed runtime behavior. A README may describe an older deployment, while a test may cover only one path. Record which source supports each conclusion.
2. Inventory the project with read-only commands
Open a terminal in the repository root. Git must be installed. These commands describe the current revision and tracked files; they do not start the application, install packages, or change the working tree.
git status --short
git log -5 --oneline
git ls-filesRead the README and the tracked manifests that actually exist: for example package.json, pyproject.toml, or a framework-specific module manifest. Identify the documented runtime and package manager before suggesting setup commands. A lockfile can help establish dependency resolution, but it does not prove a deployed server uses those exact versions.
git grep -n -E 'router|route|controller|endpoint' -- '*.py' '*.js' '*.ts' '*.tsx'This search is a starting point, not a universal framework detector. No matches can simply mean the project uses different naming or file types. Inspect the inventory and adjust the query. Review the output before sharing it; tracked files can still contain sensitive material.
3. Ask for a map with evidence and unknowns
Review the README, project manifests, source, and tests in this workspace. Do not read .env files or credentials. Do not install dependencies, run project scripts, or edit files.
Return:
1. Languages and frameworks supported by the files.
2. Application, worker, and scheduled-job entry points.
3. Routing, business logic, persistence, and integration boundaries.
4. One file path and function/class reference for every important claim.
5. Unknowns that need runtime evidence or a maintainer answer.Inspect the referenced paths yourself. If the assistant says a service calls a payment API, find the client construction and the actual call site. A package name in a dependency list only shows that a library is available; it does not prove the current code uses it.
Keep the first map short enough to review. Mark a connection as a hypothesis when configuration, generated code, or another repository is missing. A diagram is useful only when its arrows correspond to an identifiable call, message, query, or documented interface.
4. Trace one complete feature
Pick a feature with a clear start and finish. For an order-status request, follow the route, authentication, request validation, business logic, data lookup, response formatting, and relevant error paths. For a background import, start with its trigger and follow record matching, writes, retries, and completion reporting.
On small screens, scroll the table sideways to see every column.
| Stage | Evidence to collect |
|---|---|
| Entry | Route, command, event handler, or scheduled job and its input. |
| Identity and validation | Where the caller is established and input is checked. |
| Business operation | The function that decides the result or next action. |
| Persistence or API | Actual query/write/call and its transaction or failure behavior. |
| Output and errors | Response, job state, logs, exceptions, and retry decisions. |
| Verification | Tests and a representative input with an expected outcome. |
Trace the order-status feature from its real entry point to the returned response. For each step, cite a file and function. Identify authorization, database access, external calls, and failure handling. Separate behavior proven by code from assumptions about the deployed environment. Do not change the implementation.Use the real feature name in your repository. If the feature is absent, the correct answer is that it was not found. Avoid asking the model to fill missing architecture with a plausible implementation.
5. Verify behavior in a suitable test environment
Read setup and test scripts before running them. Dependency installation and application startup can execute repository code, run migrations, or contact external services. Use an isolated development environment with sample data and an agreed configuration, rather than pointing a local copy at production.
Run the relevant documented tests and compare a normal case, a missing-record case, and a denied-access case where those apply. Capture the exact revision, test command, and outcome. When a test fails before the feature runs, distinguish an environment/setup problem from evidence of application behavior.
Runtime traces can resolve questions the source alone cannot answer: which configuration is selected, which integration endpoint is used, and whether a scheduled task is enabled. Use logs with sensitive values removed. A successful process startup is not proof that an entire workflow works.
6. Turn the investigation into a useful handover
## Review scope
Repository, commit, reviewed folders, and environment.
## Confirmed architecture
Entry points, modules, storage, integrations, and file references.
## One verified feature flow
Input -> validation -> business operation -> data/API -> output.
## Checks run
Exact command, sample conditions, outcome, and remaining gaps.
## Unknowns and next steps
Questions, missing repositories/configuration, and proposed follow-up.Store the reviewed map with the project documentation if that is part of the task. Keep proposed refactors separate from observations so a future maintainer can tell what already exists. A mapping skill can make the format repeatable, while the evidence still needs to be checked for each repository.
This workflow is useful for onboarding, migrations, integration planning, and debugging. It does not establish the source code of a service you cannot access, or guarantee that a model has found every dependency.
7. Frequently asked questions
Can AI recover the original backend from a public website?
A public page can reveal observable behavior and frontend resources, but it does not expose every server-side implementation, database, secret, or business rule. Source inspection or authorized runtime access is needed to establish those details.
Do I need to upload the entire repository?
No. Start with the relevant manifests, entry points, source folders, and tests using the access method your AI tool supports. Limit the material to the task and review what data the chosen product sends or retains.
What should I do when AI gives conflicting explanations?
Ask for file and function evidence, inspect the referenced code, and test a small representative path in a suitable environment. Record unresolved questions instead of treating the more confident explanation as correct.
Explore free planning tools or Discuss an existing application.