Chapter C74 · Interactive Course
Start one small task in another tool
The same four checks in five unfamiliar products, and what makes a comparison between them fair.
Core Learning Concept
Apply the same bounded repair workflow in the supplied product scenarios. Confirm context and provider, state the task, inspect the proposed or returned edit, and compare relevant checks. Keep the starting state and evaluation consistent enough to learn from the comparison. No real installation or account change is required by this practice.
What You’ll Learn in This Chapter
-
Gemini CLI: verify project context
Plan a first source-backed repository question.
Before a Gemini CLI task, confirm the project folder, repository state, applicable guidance, and configured access. Ask a focused source-backed question to establish orientation. Those checks reduce accidental work in the wrong location and expose missing requirements before an edit or command is attempted.
-
Cursor: review one local edit
Plan a bounded edit in the selected editor mode.
For a local Cursor edit, select the intended context and describe a small observable change. Review the actual diff in its surrounding code, then run a check that exercises the behavior. Do not equate an accepted suggestion with a verified repair; acceptance changes the file, while validation checks the outcome.
-
Copilot cloud agent: define the issue
Provide enough repository context for a delegated task.
A Copilot cloud task needs an issue that can stand on its own. Include expected behavior, reproduction, scope, and validation requirements, plus an appropriate repository environment. Review the returned pull request and evidence. An issue assignment begins delegated work; it does not automatically complete or merge the repair.
-
OpenCode: confirm the active provider
Verify model access separately from workspace access.
In OpenCode, confirm the active provider and model as well as project context and permissions. The client’s appearance may stay the same when the backend changes. If results differ, compare configuration and inputs before attributing the difference to the task or code. Keep credentials out of the task description.
-
Aider: select files and inspect history
Plan an edit with explicit file context and recoverability.
In Aider, select relevant files explicitly and inspect the Git status before prompting. Review proposed diffs and auto-generated commits carefully under the workflow. File selection keeps context clean, but test verification alone establishes correctness.
-
Compare using the same starting point
Control task and repository state across tool trials.
A useful comparison starts from equivalent code and task inputs with a shared success criterion. Record meaningful differences in tools, settings, or environment. Include review and repair effort in the outcome. If conditions differ, describe a workflow comparison instead of claiming the model alone caused the difference.
-
Try the transferable workflow
Apply workspace, scope, verification and recovery checks to a storyboard from an unfamiliar product, without installing it.