How do you take over a project with little or no documentation?

Write characterization tests around important existing behavior before changing it. Focus first on API boundaries, data flow, integrations, and edge cases. The tests can record what the system currently does, giving you a safety net and a more reliable form of documentation than somebody’s memory.

AI tools can help explain unfamiliar code or summarize a large repository, but treat their output as a hypothesis. They cannot know undocumented business decisions, so verify everything against the running application and the people who understand the business.

Start by arranging a proper handover with the tech lead before they leave. Ask them to walk through the architecture, important workflows, deployment process, known risks, and the business rules behind the most active parts of the system. Record the decisions in a shared place and make sure your manager knows what is still unknown or blocked.

After that, document things incrementally while you work. Don’t try to create a giant manual—capture useful runbooks, API contracts, diagrams, setup instructions, and the reasoning behind unusual behavior. Documentation only stays useful if updating it becomes part of the normal development process.

A lack of documentation is common, but it isn’t a healthy excuse for keeping everything in people’s heads. The code is evidence of current behavior, not necessarily the specification. If the organization won’t make time for handover, requirements, tests, or documentation, that is a management and process problem—not simply a personal failure on your part.

Do what you reasonably can, communicate risks early, and avoid silently carrying the entire project’s missing knowledge. If leadership refuses to acknowledge the situation or keeps assigning work with no usable requirements, consider whether the environment is sustainable.

Treat the existing system as something you have to reverse-engineer. Start with one ticket or user workflow, run the application, and trace it through the debugger from the entry point to the database and external services. Inspect the inputs, outputs, SQL, and side effects. Git history, tests, logs, old tickets, and deployment configuration can also reveal a lot.

Keep a list of assumptions and unanswered questions instead of trying to understand the entire codebase at once. Then ask specific people to confirm the business rules. What the software actually does may be very different from what everyone thinks it does.

Ask clarifying questions as soon as a ticket is ambiguous. You can phrase them constructively: “My current understanding is that this should work like X, but I don’t want to implement an assumption. Which behavior is expected for these cases?” Put the question and the resulting decision somewhere visible, and let your manager know when missing information is blocking progress.

You’re not expected to invent requirements. Make it clear that you’re ready to do the work, but that someone needs to confirm the intended behavior. This also protects you from being blamed later for decisions nobody communicated.