Agentic coding workspace
How to use
Qoder.
Delegating spec-driven development in isolated worktrees, reviewing autonomous changes, and using repository knowledge or expert agents for complex engineering tasks.
Qoder is a agentic coding platform with editor, Quest, CLI, repository knowledge, and multi-agent workflows. Delegating spec-driven development in isolated worktrees, reviewing autonomous changes, and using repository knowledge or expert agents for complex engineering tasks. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to Qoder
Get into the official Qoder experience with the right account and a setup you understand.
- 01
Start at https://qoder.com/ and confirm the domain before entering account or payment information.
- 02
Availability: Qoder is available as a desktop coding environment, JetBrains plugin, CLI, and GitHub Action, with Editor and Quest workspaces, Repo Wiki, rules, memory, Agent mode, and Experts mode.
- 03
A Qoder account, a supported local development environment, an authorized repository, and approval for code context, indexing, memory, plugins, commands, model providers, and remote services.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful Qoder session
Learn the interaction loop using a small task with a clear outcome.
- 01
Install Qoder and open a clean Git repository without exposed credentials.
- 02
Create a Quest in a worktree and use Spec-driven Agent mode for one well-defined feature.
- 03
Review the generated plan, knowledge sources, rules, commands, and any sandbox escalation before execution.
- 04
Inspect every file and test, reject or revert unsound changes, and submit only through normal peer review.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of Qoder output
Turn generated code into a change you would put your name on in review.
- 01
Restate the intended behaviour and the acceptance criteria before reading a single generated line.
- 02
Read the diff rather than the chat summary; the summary describes intent, the diff describes what actually changed.
- 03
Run the test suite, then write a test that would fail if the change were wrong, and confirm it passes for the right reason.
- 04
Check the edges the model tends to skip: error paths, null and empty cases, concurrency, and migration or rollback behaviour.
- 05
Trace every new dependency, network call, and file write, and confirm each one is genuinely required.
- Review the diff, never the description of the diff.
- A passing test suite proves the tests pass, not that the change is correct.
- Keep changes small enough that a human can actually review them.
Privacy & permissions
Use Qoder safely
Give the tool enough repository access to help, and no more than that.
- 01
Decide what the tool may read and what it may write before connecting a repository.
- 02
Scope tokens and integrations to the narrowest repository, branch, and permission set that still works.
- 03
Keep secrets out of the context window: use environment variables and secret stores, never inline credentials.
- 04
Require review before generated code touches authentication, payments, permissions, migrations, or deletion paths.
- 05
Audit what the integration retained after the session, and revoke access that is no longer needed.
- Qoder can index repository knowledge, retain memory, execute commands, use browser and plugins, coordinate agents, and offer commit or push actions. Use worktrees for autonomous tasks, minimize indexed and attached context, review current privacy terms and providers, restrict plugins and MCP, reject unnecessary sandbox escalation, treat generated scans and tests as supporting evidence only, and keep credentials, merges, pushes, deployments, and production systems outside agent authority.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use Qoder for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Use Spec-driven Agent mode and worktree isolation to delegate a feature without disturbing the main checkout.
↓ 02 WorkflowGovern repository knowledge and rules in QoderMake Repo Wiki, memory, and rules useful without indexing excessive data or preserving stale and sensitive context.
↓Workflow 01
Deliver a feature through a Qoder worktree Quest
Use Spec-driven Agent mode and worktree isolation to delegate a feature without disturbing the main checkout.
Outcome: Produce a reviewed feature whose implementation, tests, and changes trace back to an accepted specification.
- 01
Define the user outcome, acceptance criteria, architecture constraints, privacy boundary, non-goals, and trusted validation commands.
- 02
Create a new Quest in a Git worktree, select Agent and Spec-driven mode, and attach only the files and repository knowledge needed.
- 03
Review the generated Spec, plan, rules, memory, skills, plugins, and proposed tools, resolving product and security decisions before execution.
- 04
Monitor steps and terminal output, reject unnecessary sandbox escalation, and inspect or reject each changed file in the Review panel.
- 05
Run the real project checks independently, compare behavior with every requirement, and open a peer-reviewed change without granting autonomous push or deploy authority.
What good use looks like
- Use worktrees for autonomous tasks.
- Review the Spec before execution.
- Reject unnecessary sandbox escalation.
Workflow 02
Govern repository knowledge and rules in Qoder
Make Repo Wiki, memory, and rules useful without indexing excessive data or preserving stale and sensitive context.
Outcome: Give Qoder accurate project context with clear ownership, access, freshness, and deletion behavior.
- 01
Inventory repositories, sensitive paths, data owners, permitted users, retention, required knowledge, and questions the context should answer.
- 02
Enable only approved repository knowledge, exclude secrets and generated data, and write short scoped rules linked to canonical documentation.
- 03
Inspect generated Repo Wiki and memory for accuracy, sensitive content, stale branches, unsupported inference, and conflicts with current source code.
- 04
Test retrieval and agent behavior with known answers, missing context, renamed components, hostile documentation, unauthorized questions, and deleted files.
- 05
Assign owners, review access and freshness regularly, correct or remove stale knowledge, and confirm deletion and provider handling when a repository leaves scope.
What good use looks like
- Index the minimum useful context.
- Treat source code as more authoritative than generated wiki.
- Audit memory and deletion behavior.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.
- Qoder documentation ↗
- Qoder Quest Agent mode ↗
- Qoder execution environments ↗
- Qoder terminal and sandbox ↗