A junior developer’s first agent-assisted bug fix

Agents at the terminalEN2026-10-26

For a junior developer’s first coding-agent session, choose one small bug in a familiar repository. Sit together for the first pass. The goal is not simply a working patch: it is a change the developer can explain, test, and confidently submit for review.

Establish the working relationship first. Claude Code, for example, can read files, edit code, and run commands. Treat it as an active contributor whose actions need boundaries, not merely a chat window that suggests snippets. ([anthropic.com](https://www.anthropic.com/engineering/claude-code-best-practices))

§ Step 1: Choose a task with a visible finish

Use a concrete exercise: a product-search function treats a query containing only spaces as a real search. The expected behavior is to return an empty result without calling the search backend. Keep ordinary searches unchanged.

Before opening the agent, ask the junior developer to write three acceptance criteria:

An empty query returns an empty result.
A whitespace-only query does not call the backend.
A nonempty query follows the existing search behavior.

Leave broader input normalization outside this exercise. In particular, do not silently decide that every nonempty query should be trimmed.

§ Step 2: Prepare the workspace and connection

Create a dedicated branch and inspect the working tree together. Preserve any existing uncommitted work. Run the relevant tests once, so you have a baseline before the agent changes anything.

If the team uses Vana API, keep that connection setup separate from the lesson itself. Its shared API address supports different client paths: OpenAI-compatible SDKs use the /v1 base path, while native Gemini requests use /v1beta. Follow the configuration for the chosen client rather than assuming every tool expects an identical URL. ([vanaapi.com](https://vanaapi.com/))

Create a Vana API account if you want to use it for these practice sessions. Keep credentials outside tracked files, and use a practice repository without production secrets or customer data. Require approval before dependency installation, external network access, or destructive commands.

§ Step 3: Ask for inspection before implementation

Separate exploration from editing. Anthropic’s guidance recommends understanding the relevant code and planning before implementation when the approach is uncertain. ([anthropic.com](https://www.anthropic.com/engineering/claude-code-best-practices))

Give the agent this instruction: “Find the product-search function and its tests. Explain how empty queries are handled. Identify the smallest likely change, but do not edit files yet.”

Have the junior developer open the named files and verify the explanation. Ask them to trace one whitespace-only query through the function. Resolve disagreements by reading the code, not by asking the agent to sound more certain.

§ Step 4: Give a bounded implementation request

Specific files, constraints, and examples make an actionable prompt. This matches the documented recommendation to supply concrete context and existing patterns. ([anthropic.com](https://www.anthropic.com/engineering/claude-code-best-practices))

Now ask: “Add a regression test for a whitespace-only query. Verify that it returns an empty result without calling the backend. Run it before changing the implementation. Then make the smallest fix. Preserve nonempty-query behavior, add no dependencies, and avoid unrelated refactoring.”

Before approving edits, ask the junior developer which assertion proves the backend was not called. If they cannot identify it, pause and inspect the proposed test together.

§ Step 5: Require evidence, then review the diff

Give the agent an executable check and request its output. Tests and build results provide verification signals beyond the agent’s own claim that the task is complete. ([anthropic.com](https://www.anthropic.com/engineering/claude-code-best-practices))

Confirm that the regression test fails for the intended reason before the fix and passes afterward. Then run the surrounding tests and the repository’s relevant checks.

Review every changed line together. Did the agent weaken an assertion, alter an unrelated fixture, or change how nonempty queries are passed downstream? Ask the junior developer to explain the patch without repeating the agent’s summary.

§ Step 6: Close with a short teach-back

Before committing, have the junior developer describe the original failure, the chosen boundary, and the evidence supporting the fix. Record any checks that could not run and why.

For the next session, choose a similarly small task and let them write the prompt independently. Keep the same checkpoints: define the behavior, inspect the code, constrain the edit, verify the result, and explain the diff. Increase autonomy when those habits become reliable, not merely when patches arrive faster.