Explore an unfamiliar codebase with Autohand Code

Autohand Code can help you understand an unfamiliar repository by reading its instructions, tracing a specific execution path, and linking findings to source files. Begin with one question and use plan mode for exploration before authorizing edits. A useful result is a verified map you can use to make a change.

Start with a concrete question

Open the repository root in your terminal and check its current state:

git status --short
autohand

Inside the session, enable plan mode:

/plan on
/plan status

Ask a question that names an observable behavior. Replace the example endpoint with one that exists in your project:

Trace how GET /api/tasks reaches storage and returns a response.
Read AGENTS.md and the relevant route, service, and test files.
Do not modify files. For each step, cite the file and symbol.
Separate source-confirmed behavior from assumptions.

Build a map you can verify

Ask for a small table with these columns: entry point, responsibility, next call, and relevant test. Open the cited files yourself. A file name alone is insufficient evidence: the named symbol should perform the responsibility described, and the cited test should exercise the behavior.

Question	Evidence to ask for	What to check
Where does a request enter?	Route registration and handler	The registered path and HTTP method match
How is input validated?	Schema or validation function	Rejected and accepted inputs have explicit behavior
Where is state changed?	Storage operation or service call	The write belongs to this request path
What proves the behavior?	Test name and test command	The assertion covers the actual result

If the agent cannot find an entry point, ask it to show the search terms and directories it inspected. Configuration, generated routes, and framework conventions can change where a route is registered.

Move from exploration to a scoped plan

Based on the verified request path, plan how to reject a blank task title.
List the affected files, expected response, regression test, and validation command.
Do not implement yet. Flag any behavior that needs a product decision.

Review the plan, then use /plan off when ready to allow implementation. State the chosen behavior and the files in scope. Re-check git diff afterward to confirm the change stayed within the plan.

Troubleshooting

If the answer lists too many files, narrow to one request, screen, or failing test. If it invents a framework convention, ask for the registration code. If a test command is uncertain, read the repository's package scripts or build instructions before running it. Do not infer successful execution from a suggested command.

Completion checkpoint

You can explain one end-to-end path, open each cited file, and name the test that would detect a regression. Continue with writing effective task prompts or practice in the first lab.

Frequently asked question

How do I explore without editing files?

Enable /plan on in an interactive Autohand Code session, confirm the status, and ask for a source-backed trace of one behavior. Check the Git diff afterward to verify that exploration left tracked files unchanged.