AI Assistant

An AI assistant is a tool built on a large language model that helps you with work you would otherwise do by hand. Some only talk: they explain, suggest and draft. Others can act, reading your project, creating files and running commands, and knowing which kind you are using changes how much you should trust it and how you check its work.

Assistants that help you think, and assistants that act

The first wave of AI assistants were chat assistants. You paste in an error or a question, and the model answers with text: an explanation, a suggestion, a snippet of code. Everything it produces goes through you. You decide what to copy, where to put it and whether to run it.

A coding agent goes a step further. It is still a language model underneath, but it is connected to tools: a way to read and write files in your project, and a way to run commands in a terminal. Instead of telling you what to do, it can do the work itself and show you the result.

The difference is not intelligence, it is reach:

Neither replaces you. A chat assistant saves you searching and reading. An agent saves you the repetitive typing between decisions: creating the boilerplate file, running the tests, reading the output, trying again.

How an agent gets things done

An agent works in a loop. You give it a goal in plain language, and it repeats a few steps until the goal is met or it gets stuck:

1. Look. Read the files that seem relevant, search the project, check the configuration.
2. Plan. Decide on the next small step.
3. Act. Edit a file, create one, or run a command.
4. Observe. Read what came back: the test output, the compiler error, the new file.

The observe step is what makes an agent more than a fast typist. When a command fails, the agent sees the same error you would and can adjust. A chat assistant has to guess whether its suggestion works; an agent can find out.

That loop is also where the risk lives. Every 'act' step changes something real, and every extra turn is another chance for an early mistake to carry forward. The rest of this page is mostly about keeping that loop useful and safe.

A worked example: one failing test

Say you have a small Python function that averages a list of scores:

def average(scores):
    return sum(scores) / len(scores)

A teammate adds a test for an empty list, and the test run breaks:

$ pytest
FAILED test_stats.py::test_empty_list
ZeroDivisionError: division by zero

With a chat assistant, you paste the error and ask what it means. It tells you that len(scores) is zero for an empty list, and dividing by zero raises an error in Python. That is useful: you now understand the bug. You still write the fix, run the tests and check the result yourself.

With a coding agent, you describe the goal instead: 'make the failing test pass'. Here is how that plays out:

The change it proposes might look like this:

def average(scores):
    if not scores:
        return 0.0
    return sum(scores) / len(scores)

Notice what the agent did and did not decide. It found the file, ran the tests and confirmed the fix. But is 0.0 the right answer for no scores at all? Maybe your app should raise a clear error, or show 'no scores yet'. That is a product decision, and the test only passed because someone wrote it to expect one answer. Your job moves from typing the fix to judging it.

Where Junie fits

The video uses Junie, the coding agent from JetBrains, as its example. Junie runs in the terminal as Junie CLI, and inside JetBrains IDEs. In a project folder it can do the agent work described above: inspect the code, create and edit files, and run commands, while you watch and approve.

A few of its features map directly onto the good habits below. Its documentation describes:

• Approval for sensitive actions, such as running a shell command, unless you have added that action to an allowlist.
• A plan mode that analyses the codebase with read-only operations and writes a plan before it changes anything.
• Project guidelines read from an AGENTS.md file, so your conventions go into every task without repeating them.

Other coding agents work in a similar way. The ideas on this page apply whichever one you pick.

Staying in control

An agent that can run commands can run the wrong one. A few habits keep the benefit without the surprises:

• Work in version control. Start from a clean Git state, so every change the agent makes shows up in git diff and can be undone in one step.
• Read before you approve. When the agent asks to run a command, read it. Deleting files, installing packages, pushing code or touching a database deserve a second look.
• Plan first for bigger tasks. Ask for a plan, check it, then let it act. Fixing a wrong plan costs a minute; unpicking a wrong implementation costs much more.
• Keep secrets out of reach. Don't paste API keys into prompts, and be careful about letting an agent read files that hold credentials.
• Let the tests judge. An agent that can run your test suite can check its own work. With no tests, you are the only check.

Some agent setups also add a fast, automatic check before each command runs. The Jev video covers a model built for that kind of quick decision.

Giving it good context

An agent only knows what it can read. Two things make a large difference:

• Specific goals. 'Make the empty-list test pass without changing the test' beats 'fix the stats code'. Say what done looks like and what must not change.
• Project guidelines. A short AGENTS.md at the root of the project, listing how to run the tests, the coding style and anything it must never touch, saves you repeating yourself in every prompt.

# AGENTS.md
- Run tests with: pytest
- Use type hints on new functions
- Never edit files in migrations/

When to use one, and when not

Agents shine on work that is clear to describe and easy to check: adding a file that follows an existing pattern, fixing a bug with a failing test, renaming something across a project, writing the first draft of tests, or chasing a build error through several files.

They are a poorer fit when the hard part is deciding what to build, when there is no way to check the result, or when a mistake is expensive and hard to undo, such as changing production data. Reach for a chat assistant, or your own head, when you want to understand something rather than change it.

Common mistakes

• Accepting changes unread. Passing tests prove the tests pass, not that the change is what you wanted.
• Vague prompts. A broad request gets a broad change, often touching files you did not expect.
• Approving every command on autopilot. The approval prompt is only a safeguard if you read it.
• Skipping the explanation. When the agent fixes something you don't understand, ask it why. Otherwise you learn nothing, and the next bug is just as hard.
• Treating it as a replacement. It handles the repetitive steps. You still own the design, the trade-offs and the final call.

Key takeaways

• A chat assistant answers with text; a coding agent can also read files, write files and run commands.
• Agents work in a loop of look, plan, act and observe, which lets them check their own work.
• The agent saves you the repetitive steps, but deciding whether a change is right stays with you.
• Version control, approvals, plans and tests keep an agent's changes safe to accept.
• Clear goals and a project AGENTS.md file make its work far more accurate.