A task in an unfamiliar repository often starts with “where does this behavior live?” yCode helps build an evidence-backed map before editing. It is beta; mutation quality and broader real-repository acceptance still need work.
Read before changing
Ask a behavior question: “Which function checks export permission?” Request files, symbols and exact source locations. Open the references and verify branch and version. yCode Help explains the workspace.
Plan, then review
Ask for a minimal plan: target files, tests and adjacent-module risks. A reviewer checks the diff and test output before integration. Isolated runs and editing require an eligible plan and configured guarded environment; weak actions can fail closed. The run-lifecycle Wiki describes approvals.
Authorize the repository
When configured, GitHub connection uses authorization and repository selection. Grant minimal scope, inspect what is accessible and revoke access after a trial. GitLab is not a generally available live integration claim.
How to start
Open yCode with a read-only question. Verify two file references, then review a change plan with an engineer. The earlier AI code-review guide helps at the next step.
FAQ. Can yCode help without editing? Yes, within available read-only access. Is editing always available? No; plan and configuration matter. Should suggested code merge automatically? No; review and tests remain necessary.
