GitHub Copilot for JetBrains 1.18: What Changed?

Developers using IntelliJ IDEA, PyCharm, WebStorm, Rider, and other JetBrains IDEs increasingly use AI assistance as part of everyday development. The challenge is no longer simply generating code. Developers also need AI tools that understand the current project, work safely with files and commands, and fit naturally into an existing IDE workflow.

GitHub Copilot's JetBrains integration continues to evolve in that direction. Version 1.18 introduced changes around agentic development, tool execution, approvals, model interaction, and project-aware workflows.

For developers, the important question is not just what was added to the extension. It is how these changes affect the way Copilot can be used inside a JetBrains IDE.

What Is GitHub Copilot for JetBrains?

GitHub Copilot integrates with JetBrains IDEs through an IDE plugin.

Depending on the IDE and enabled Copilot capabilities, developers can use AI assistance for tasks such as:

• Code completion

• Code explanation

• Code generation

• Refactoring assistance

• Test generation

• Chat-based development

• Agentic coding workflows

• Repository-aware tasks

The plugin operates inside the developer's existing environment rather than requiring a separate editor.

This is particularly useful for developers already working with IDE features such as:

• Project navigation

• Debugging

• Version control

• Refactoring

• Static analysis

• Build tools

• Integrated terminals

The AI layer can therefore complement existing JetBrains functionality.

What Changed in Copilot for JetBrains 1.18?

The most notable changes are related to how Copilot operates as an agent rather than only as a code-completion assistant.

The evolution can be summarized as:

The important change is the shift from "generate code" toward "help complete a task."

That distinction affects both productivity and security.

Agentic Development Inside the IDE

Traditional Copilot assistance usually looks like this:

Developer
   |
   v
Write Prompt
   |
   v
Copilot
   |
   v
Generate Code
   |
   v
Developer Reviews

An agentic workflow can be broader:

Developer
   |
   v
Describe Task
   |
   v
Agent
   |
   +--> Inspect Files
   |
   +--> Analyze Code
   |
   +--> Modify Files
   |
   +--> Run Tools
   |
   +--> Review Results
   |
   v
Developer Approval

This can be useful for tasks such as:

Add validation to the registration API,
update the related tests, and fix any failing
tests caused by the change.

The task involves multiple operations.

A coding assistant that only generates one snippet cannot handle the entire workflow efficiently.

Why Tool Approvals Matter

Agentic systems can perform actions beyond generating text.

For example, an agent might need to:

• Read a file

• Modify a file

• Search the project

• Execute a command

• Run tests

• Inspect command output

These actions have different levels of risk.

Reading a source file is generally different from executing a shell command.

That is why explicit approval controls are important.

A simplified model is:

Agent
  |
  v
Tool Request
  |
  +---- Safe / Allowed ----> Execute
  |
  +---- Approval Required -> Ask Developer

This allows the developer to remain in control of operations that could have significant effects on the local environment.

How Tool Approval Changes the Developer Workflow

Without explicit controls, an agent might attempt several operations in sequence.

With approval controls, the developer gets opportunities to inspect what the agent wants to do.

For example:

Agent:
I need to run the test suite.

Developer:
Approve

Then:

Agent:
I need to modify UserService.cs.

Developer:
Approve

The exact behavior depends on the configured policies and tool capabilities, but the general idea is to make potentially sensitive operations visible.

This is particularly important when an agent can operate on a project rather than simply return text.

Why JetBrains Developers Should Care

JetBrains IDEs already provide strong project-aware tooling.

For example, Rider can understand a .NET solution, IntelliJ IDEA can understand Java and Kotlin projects, and PyCharm provides Python-specific project analysis.

AI assistance becomes more useful when it works alongside that existing context.

Instead of copying code into a chat interface, the developer can work directly inside the project.

Consider a C# application:

Solution
├── API
├── Services
├── Data
├── Tests
└── Infrastructure

A developer can ask Copilot to investigate a change that crosses several projects.

The IDE remains the primary environment while Copilot assists with the development task.

Multi-File Changes

Many real development tasks are not limited to one file.

For example:

Add a CreatedAt property to the User entity,
update the database model, expose it through
the API response, and update the tests.

The change may require:

User.cs
UserConfiguration.cs
UserDto.cs
UserController.cs
UserService.cs
UserTests.cs

An agentic workflow can help coordinate those changes.

The developer should still review the final diff rather than assuming that every generated modification is correct.

This is especially important for database models and API contracts, where a seemingly small change can have broader consequences.

Working With Existing Project Conventions

One advantage of running an AI assistant inside an IDE is that it can work with the surrounding project rather than a detached code snippet.

Suppose an existing Java project consistently uses:

Optional<User>

instead of returning null.

If you ask for a new method, the desired implementation should follow the existing project convention.

Similarly, a .NET project may use:

Result<T>

for application-level errors rather than exceptions.

Good AI-assisted development should preserve those patterns instead of introducing unrelated styles.

The developer should verify this by reviewing the generated diff.

Testing as Part of the Agent Workflow

Testing becomes especially important when the agent can modify multiple files.

Consider a task:

Add validation for invalid email addresses.

A complete workflow could be:

Understand Existing Validation
          |
          v
Modify Validation Logic
          |
          v
Update or Add Tests
          |
          v
Run Tests
          |
          v
Inspect Failures
          |
          v
Make Corrections

The agent can assist with several steps, but tests provide an independent validation mechanism.

A good workflow therefore does not stop when code is generated.

It stops when the change has been reviewed and validated.

A Practical Example

Suppose a Spring Boot application contains:

public User createUser(CreateUserRequest request) {
    User user = new User();
    user.setName(request.name());
    user.setEmail(request.email());

    return repository.save(user);
}

A developer might ask:

Add email validation to user creation and update
the relevant unit tests.

A useful agent workflow could involve:

1. Locate the user service.

2. Identify existing validation patterns.

3. Inspect the request model.

4. Check existing tests.

5. Add validation.

6. Update tests.

7. Run the relevant test suite.

8. Inspect failures.

9. Present the changes for review.

The advantage is not simply that the agent writes the validation expression.

The value is that it can help coordinate the related work.

The Importance of Review

Agentic development increases the number of actions an AI system can take.

That makes review more important.

A developer should inspect:

• Files changed

• Lines added or removed

• New dependencies

• Configuration changes

• Build changes

• Test modifications

• Generated files

• Command execution

• Unexpected side effects

Version control makes this easier.

For example:

git diff

can provide a quick review of modifications.

For a larger change:

git status

can help identify unexpected files.

The exact commands depend on the project's workflow, but the principle is consistent: review the resulting state, not just the agent's explanation.

Security Considerations

Agentic coding introduces security questions that are less important for simple code completion.

An agent operating inside a developer environment may have access to:

• Source code

• Local files

• Environment configuration

• Build tools

• Terminals

• Development credentials

• Package managers

• Network-enabled commands

This makes permissions and approvals important.

Developers should avoid giving unnecessary access to sensitive resources.

A useful principle is:

Minimum Required Access
          +
Explicit Approval
          +
Human Review
          =
Safer Agentic Workflow

The exact controls available depend on the IDE integration, account configuration, organization policies, and enabled Copilot features.

Tool Calls and the Principle of Least Privilege

A coding agent does not necessarily need unrestricted access to everything on a developer's machine.

For example, a task involving:

Update unit tests

does not automatically require access to unrelated directories or production credentials.

Teams should configure development environments so that sensitive resources are separated from ordinary project operations.

This reduces the potential impact of an incorrect or unexpected tool action.

Common Mistakes When Using Agentic Coding

Giving Extremely Broad Instructions

A request such as:

Improve this entire application.

is difficult to validate.

A better task is bounded:

Update authentication error handling in the API
and add tests for expired and invalid tokens.

Skipping the Diff Review

Generated changes can contain unnecessary modifications.

Always inspect the final diff.

Asking the Agent to Change Tests Without Checking Behavior

Tests can be changed incorrectly to match an implementation rather than the intended behavior.

Ignoring Existing Architecture

The agent may produce technically valid code that does not fit the project's established patterns.

Approving Every Tool Request Automatically

Tool approvals exist to give developers visibility into actions.

Do not treat approval as a formality.

Troubleshooting Agentic Changes

When an agent produces an unexpected result, start by narrowing the problem.

Check the Requested Scope

Was the task specific enough?

Review the Plan

If the agent describes several planned steps, check whether they actually match the intended change.

Inspect the Diff

Look for unrelated file modifications.

Run Targeted Tests

Do not immediately rely only on the entire test suite.

For example:

dotnet test --filter FullyQualifiedName~UserServiceTests

or:

mvn test -Dtest=UserServiceTest

depending on the project.

Check Tool Actions

If the result depends on a command or external operation, inspect what was executed and whether it produced the expected output.

When Agentic Mode Is Useful

Agentic workflows are particularly useful for tasks involving multiple related steps.

Examples include:

• Adding a feature and its tests

• Refactoring a component

• Updating several related files

• Investigating a failing test

• Migrating APIs

• Updating repetitive code

• Generating test coverage

• Performing repository-wide changes

They are less suitable for changes where every operation has a high external impact and requires manual control.

For those cases, smaller and more explicit steps are easier to validate.

Copilot Chat vs Agentic Workflow

The distinction can be summarized as follows:

The agentic approach does not eliminate developer involvement.

It changes where that involvement happens.

Instead of manually performing every small operation, the developer increasingly defines the task, reviews the plan and changes, and validates the result.

Advantages

Better Multi-Step Workflows

The agent can assist with a complete development task rather than a single code fragment.

Less Context Switching

Developers can remain inside their JetBrains IDE.

Better Project Awareness

The assistant can work with project files and existing conventions.

Faster Repetitive Changes

Multi-file modifications can be completed more efficiently.

Integrated Validation

Testing and tool execution can become part of the same workflow.

Disadvantages and Trade-Offs

More Powerful Actions Mean More Risk

An agent that can modify files or execute tools has greater potential impact than autocomplete.

Generated Changes Still Need Review

AI can make incorrect assumptions about project architecture.

Large Tasks Can Become Hard to Validate

The broader the requested task, the harder it becomes to identify unintended changes.

Tool Approvals Add Interaction

Approval prompts can slow down workflows, particularly when many actions require confirmation.

Project Context Is Not Perfect

The agent can misunderstand build configurations, generated files, or undocumented behavior.

Best Practices

Give the Agent a Bounded Task

Describe what should change and what should remain unchanged.

Ask for Existing Patterns First

Before introducing a new approach, let the assistant inspect how the project already solves similar problems.

Keep Changes Reviewable

Prefer several small tasks over one massive request.

Review Every Important File

Do not rely solely on the summary produced by the agent.

Run Tests After Changes

Code that looks correct can still break integration behavior.

Use Version Control

Keep changes easy to inspect and revert.

Be Careful With Sensitive Operations

Do not approve commands or file access without understanding their purpose.

Treat AI as a Development Tool

The developer remains responsible for the final code, architecture, security, and behavior.

What Developers Should Take Away From Version 1.18

The larger trend behind Copilot's JetBrains evolution is the move from passive code assistance toward active development workflows.

That transition changes the questions developers should ask.

Instead of:

What code should I write?

the workflow increasingly becomes:

What needs to change?
What files are involved?
What tools are required?
What could be affected?
How should the change be tested?

The AI can help with those steps, but the developer still controls the engineering outcome.

For JetBrains users, this makes Copilot more closely integrated with the way modern software projects are actually developed: across multiple files, tools, tests, and project components.

Summary

GitHub Copilot for JetBrains 1.18 reflects the broader shift from traditional AI code completion toward agentic software development.

The important changes are less about generating individual snippets and more about enabling Copilot to participate in multi-step development tasks, work across project files, use development tools, and operate within explicit approval boundaries.

For developers, the best approach is to use these capabilities with clear task boundaries, careful tool approvals, normal version-control practices, and strong test coverage.

The key principle is simple: the more actions an AI coding assistant can perform, the more important it becomes to define the task clearly, control access, review the resulting changes, and validate the final behavior.