A junior developer’s first coding-agent session

Agents at the terminalEN2026-10-29

For a junior developer’s first session with a coding agent, choose a task they can understand without the agent. Fixing an unclear error message or adding a missing test is enough. The aim is not to produce a large change quickly. It is to learn how to give instructions, inspect the result, and decide whether the work is correct.

§ Explain what the agent can do

A coding agent is a tool that uses an AI model to work on programming tasks. Depending on its permissions, it may read project files, suggest a plan, edit code, run commands, and respond to test failures. Claude Code, Codex, and Gemini CLI are examples of tools that support this kind of workflow.

That makes an agent different from autocomplete, but it does not make it a reliable authority. It can misunderstand a requirement, invent a library method, or change unrelated code. Teach the junior developer to treat its output as a proposed contribution that needs review.

§ Prepare a small, safe workspace

Start in a repository with working setup instructions and a known test command. Use a separate branch and check for existing uncommitted changes. Run the relevant tests before asking the agent to edit anything, so existing failures are not confused with new ones.

Keep credentials, production data, and private customer information out of prompts.
Check which files the tool can access and which commands require approval.
Do not give the agent production access for a beginner exercise.
Agree on a small scope, such as one behavior change and its tests.

Explain that approval prompts are checkpoints, not interruptions to dismiss automatically. Before approving a command, the developer should understand what it reads, changes, installs, or deletes.

§ Give the task a clear boundary

A useful first request describes the current behavior, the desired behavior, and the limits. For example: “The signup form accepts an address containing only spaces. Find the validation code and explain it before editing. Then reject whitespace-only addresses, add a regression test, and leave other validation behavior unchanged.”

Ask the junior developer to read the agent’s explanation and open the relevant files themselves. If the explanation does not match the code, stop and clarify. This builds the habit of checking evidence rather than accepting a confident summary.

For the first few tasks, separate planning from editing. A short plan gives the developer a chance to spot an unnecessary dependency, a broad rewrite, or an assumption that should be checked with a teammate.

§ Review the change before the summary

Once the agent has edited the code, inspect the diff together. Ask the junior developer to explain each changed block in ordinary language. If they cannot explain a section, investigate it before accepting the change.

Does the implementation solve the stated problem?
Does the test cover the failure that motivated the task?
Were unrelated files or dependencies changed?
Are error handling and existing behavior preserved?

Run the relevant tests and confirm the results directly. An agent saying “tests pass” is not a substitute for checking which command ran and what it reported. If tests could not run, record that limitation rather than treating the task as verified.

§ Keep access and spending understandable

The agent is the working tool; the model is the service it calls. Vana API provides one endpoint at https://api.vanaapi.com, supporting OpenAI-compatible requests, Anthropic Messages, and Gemini native protocols. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs. Follow the chosen tool’s configuration instructions, and keep API keys out of source control.

Vana API bills per real token with no monthly fee. Long conversations, repeated file reads, and retries can increase usage, so begin with bounded tasks and review spending. To try this setup, create a Vana API account and connect one tool first.

§ Finish with a short explanation

Before committing, ask the junior developer to summarize the problem, the change, the checks performed, and anything still uncertain. The useful outcome is not merely a patch. It is a developer who can explain why that patch belongs in the project.