AI right in your editor: Copilot and friends for developers

In just a few years, end-of-line autocomplete has turned into a tool that writes an entire function, explains an unfamiliar module, proposes a refactor, or goes through a repository on its own and opens a pull request. The leap is real, and it's the biggest one in a decade. And yet the one thing that has always decided this profession hasn't changed: only code you'd put your name on goes into the repository. It doesn't matter who wrote it — your name is on the commit, and it's you who gets paged at three in the morning.

This guide is about getting the most out of an assistant without paying for it in quality. We'll go through the three levels of assistance and when each one makes sense, how to set up context so generated code looks like the rest of the project instead of a documentation sample, how to review code you didn't write, and how to run agent mode without it rewriting half your repository. Every phase comes with ready-made prompts.

One rule runs through the whole text: code you don't understand isn't done. Not “it's missing tests”, not “I'll polish it later” — it isn't done. Understanding a generated suggestion is part of the work, not a bonus, and it's the only defense against the silent technical debt that piles up faster than before in repositories with AI assistants.

A typical scenario

Simona, a developer, joins a team maintaining an eight-year-old order service. A hundred fifty thousand lines of code, documentation that hasn't been updated in three years, the original authors long gone elsewhere. Her first task: fix a bug in the discount calculation that nobody can reliably reproduce.

The classic approach would be a week spent reading code blind. Instead, she has the relevant module explained to her — and above all, the path the data takes, from request to database write. In two hours she has a map that would otherwise have taken her three days. Then she has tests written for the existing function: not to confirm it's correct, but to capture how it actually behaves right now. Two of the nine tests fail immediately, and one of them is exactly the reported bug.

She writes the fix herself, since it's a three-line decision about rounding. AI writes the regression test that catches the bug, adds a docstring, and proposes a commit message. In the draft, Simona rejects two things: a test that locked in an implementation detail instead of behavior, and a comment that described the code instead of the reason for it. She opens the pull request after two days instead of a week — and the difference isn't the tool, it's what she used it for. A year earlier she would have taken the first generated draft that “passed” and added yet another layer to the module that nobody understands.

Phase 1: the three levels of assistance, and when to use which

Most disappointment with AI in the editor comes from using the wrong level for the task at hand. There are three levels, and they differ in how much context they see and how much autonomy they have.

Level 1: inline autocomplete

Fills in code as you type, usually based on the current file and a handful of open tabs. You accept a suggestion with Tab. Latency in tenths of a second, small context, zero autonomy.

When it's best: repetitive patterns (DTO mapping, type conversions, constructors), boilerplate you know by heart and don't want to type, filling in a pattern you've just started — you write the first three cases of a switch and it correctly fills in the rest. It also works great as improved documentation: you start typing a library call and the autocomplete shows you how it's used.

When it hurts: in places where a decision matters. Autocomplete is conformist by nature — it continues whatever pattern it sees, even when that pattern is wrong. If your file has five spots with the same bug, it'll happily give you a sixth. And two suggestions accepted “because they looked reasonable” add up to a function nobody actually intended.

Practical tip: turn it off wherever you're actually thinking through a design. A running stream of suggestions pulls you out of that thinking before you finish it, and you accept the first acceptable option instead of the correct one.

Level 2: chat with project context

A conversation alongside your editor, to which you show specific files, a code selection, or a whole directory. You phrase the request, it returns a proposal, you incorporate it. Medium context, zero autonomy — nothing runs and nothing gets written without you.

When it's best: anything where the value is in the explanation, not the lines written — understanding an unfamiliar module, proposing how to split something up, dissecting an error message, comparing two approaches. Also tests, documentation, format conversions, and one-off scripts that sit outside the main codebase.

When it hurts: tasks that require going through fifteen files and keeping them consistent with each other. Manually copying context into the chat isn't just tedious — it's unreliable, since you'll forget to show it exactly the one file where the answer is.

Level 3: agent mode

The tool sees the repository, reads and writes files, runs commands, reads test output, fixes itself based on it, and works in cycles. This is where Claude Code belongs, working directly with files, scripts, and git inside the project, and in desktop form, Claude Cowork, built around a folder. Large context, large autonomy — and so, the highest risk too.

When it's best: changes that cut across many files (renaming a concept throughout a module, switching to a different library API, adding missing error handling everywhere it's absent), tasks with fast feedback loops (tests run, the agent iterates on its own), migrations, and routine maintenance. And exploring a large codebase, where the tool finds what it needs on its own.

When it hurts: design decisions. An agent finishes the task — always. When the request is wrong, you get a wrong solution, delivered fast and reliably, and scattered across twelve files besides. And a big change made all at once produces a diff nobody actually reviews properly, so it just gets rubber-stamped.

Choosing by task

A simple rule of thumb that works: the more expensive a wrong answer is, the lower the level you should use. Boilerplate in a test file can tolerate autocomplete. A change to authentication calls for chat, where you have the implications explained and then write it by hand. Migrating three hundred calls to a new API is a job for an agent — but broken into stages, each with its own commit and review.

When you're not sure how to break down a task, have it proposed before you start writing:

I'm about to start this task in our project:
[task description, e.g. add support for partial refunds to the
order module]

Stack: [language, framework, version]. Project size: [rough order of
magnitude].
Tests: [unit yes, integration partial, coverage about 40%].
Deadline: [2 days].

Don't write any code yet. Break the task into steps and for each
one write:
1. what needs to be done, one sentence,
2. whether it's a decision (I need to make it) or mechanics (AI can
   write it and I'll review it),
3. what needs to be verified before moving on,
4. what this step could break elsewhere in the system.

At the end, list three questions I should answer before I start, and
one thing about this request you think is underspecified.

You'll get a plan that makes clear what's worth delegating and what isn't — point 2 is the whole core of it. Take the last line seriously: models tend to just accept a request as given, so explicitly asking to hear what's wrong with it gets you an answer you wouldn't otherwise get.

Phase 2: context, so generated code looks like yours

The most common complaint about AI assistants is “it generates code I have to rewrite entirely”. In most cases the cause is that the tool doesn't know how code is written in this particular project. Without context, it reaches for the most common pattern on the whole internet — which is almost never your pattern.

A file of project rules

The single highest-return investment in this whole guide is an hour spent writing the project's conventions into a file the assistant reads. Agentic tools read such a file at the repository root on their own; for chat, you paste it into the conversation once.

Go through this project and write me a draft rules file for the AI
assistant that will work in it. Base it on what you actually see in
the code, not on general recommendations.

Include:
- language, version, package manager, how the project is run and
  tested
- directory layout and what belongs where
- naming conventions actually followed in the code (even where they
  differ from the usual recommendations for this language)
- how the project handles errors, logging, and configuration
- what a typical test looks like and which libraries are used
- what is NOT done in this project (banned libraries, patterns we
  got rid of and don't want back)
- areas where nothing may change without consultation
  (authentication, payments, database migrations)

For each point, cite the file you derived it from.
Where you see two different styles in the project, list both and
flag it as a decision to be made — don't choose for me.

You'll get a draft to review and adjust; the last paragraph matters because every older project has two styles somewhere, and the model would quietly pick one. Trim the finished file afterward — rules nobody follows only dilute it. There's a separate tip on working with context in general; for context that persists across conversations, Projects is the right fit.

An example instead of a description

The second thing that improves results immediately: attach an example instead of describing the style. A model is a pattern machine, so give it a pattern — for a new class, find the closest existing equivalent in the project, attach it in full, and say “same structure, same layering, same error handling, just for domain X”. It works an order of magnitude better than three paragraphs about preferences, and it saves a whole round of stylistic review comments.

Phase 3: an unfamiliar codebase and getting oriented fast

This is the area where the payoff is biggest and the risk smallest — nothing changes, it's all explanation. And for a newcomer to a project (or for you, in a module you haven't touched in two years), it shrinks a week down to an afternoon.

Explain this module to me

Explain this module to me. I'm an experienced developer, but I'm
seeing this project for the first time.

I don't want the code retold line by line. I want:
1. What the module is for and what problem it solves — 3 sentences.
2. Public interface: what other parts of the system call here and
   what they expect back.
3. Data flow: what comes in, how it changes step by step, what goes
   out and where.
4. State and side effects: what it remembers, what it writes to the
   database, what it sends to other services.
5. Three spots where the logic is most tangled, and why — file and
   line numbers for each.
6. Assumptions the code silently makes (what has to be true about
   the inputs for it to work) — especially ones that are never
   checked anywhere.
7. What I'd break if I changed something here.

Where you're not sure, say so instead of guessing. Don't claim
anything about code you can't see.

[attach the module or directory]

You'll get an orientation map you can actually work from. Points 6 and 7 are the valuable ones — unwritten assumptions are exactly what a person reading the code doesn't see, and what later costs them a production incident. Spot-check two claims against the actual code: models will happily describe behavior they've inferred from a function's name alone.

Where a specific request flows through the system

Even more useful than a module description is tracing the whole path. This is a job for agent mode — the tool finds the files it passes through on its own.

Go through this repository and describe the whole path
[a specific request takes through the system, e.g. an order, from
form submission to the confirmation email].

For each step, give me:
- the file and function where it happens,
- what happens to the data at that step,
- where a branch is decided (validation, authorization, a feature
  flag),
- where it can fail, and what happens to the in-progress state then.

At the end, tell me:
- which steps aren't covered by tests,
- where this path differs from what I'd expect based on the file
  names,
- three spots where I'd most likely break something if I touched
  this.

I want concrete file-and-line references, not a general
architecture description.

You'll get a route that would take you half a day to piece together by hand. One thing to watch: the agent describes what it found, and when the path is scattered across configuration, events, or dynamic calls, part of it will slip past. Follow up with “where did you lose the trail, and why”.

Archaeology: why it's like this

Code answers “what”, history answers “why”. When an agentic tool has access to git, it can ask both — and it's the fastest way to discover that the odd condition you want to delete is actually handling a real incident. The request goes: “find the commit that introduced this condition, show me its message and what else it changed, find the tests and comments that reference this case, and tell me whether it looks like it's solving a specific problem or is a leftover from a refactor; don't change anything, this is investigation only”. The last sentence is there on purpose — agentic tools have a strong tendency to go straight from investigating to fixing.

Phase 4: tests and refactoring

Tests for existing code

The most common and most rewarding use case. But it holds a trap worth naming: tests generated from an existing function verify how that function behaves, not how it's supposed to behave. When the function has a bug, you get a test that locks it in.

So tests get generated in a specific order: you describe the expected behavior first, and only then do you have them written.

Here's the function [name] I need tests for:
[paste the function and related types]

Its intended behavior, per the business logic:
[3-6 sentences in your own words, including what it should do in
edge cases — empty input, a negative amount, a missing value]

Write tests in [framework], in the style we use here:
[attach one existing test file as a sample]

Rules:
- test the behavior described above, not what you see in the
  implementation,
- for each test, one sentence on what it verifies and why it
  matters,
- cover edge cases: boundaries, empty and missing values, error
  states — for each one, write why that particular case is
  interesting,
- don't mock the internals of the function under test, only its
  external dependencies,
- at the end, list separately: cases where the intended behavior per
  the description DIVERGES from what the implementation actually
  does.

That last list is the most important part for me — don't leave it out.

You'll get a test suite plus a list of discrepancies — and that list is exactly why the prompt is shaped this way. Every discrepancy is either a bug in the code or a gap in your understanding of the spec, and you want to know either one now, not in production. Then review the tests: the most common flaw in generated tests is locking in implementation details (checking that a specific private method got called), which blocks every future refactor.

A regression test before the fix

When you find a bug, the order is: first a test that catches it, then the fix. AI does this quickly, and more honestly than a tired person on a Friday.

I found a bug: [description of what happens and what should happen
instead].
Reproduction: [steps or input that triggers it].
Suspected location: [file, function].

Write me one test that catches this bug — a test that MUST fail
right now and pass once it's fixed.

- name it so the name makes clear which case it's guarding,
- add a comment linking to the report and briefly what it was about,
- use only the data that's essential to the bug, no random filler,
- don't fix the code yet — I want to see the test fail first.

Once the test fails, only then propose a fix — and along with it,
explain why the bug happened and what else could have been affected
by the same root cause.

You'll get a test that genuinely fails, and that's the entire point. The last question — what else the same root cause could have affected — is usually the answer that gets you fixing three spots instead of one.

Refactoring that comes with an explanation

With refactoring, half the value is in the new code and half is in understanding why it's better. Without the second half, you've just traded one piece of code you don't understand for another.

This function has grown beyond me:
[paste the code]

Context: [what it's for, how often it's called, what calls it].
Tests: [exist / don't exist]. Performance is [/isn't] critical.

Don't write the result yet. First give me:
1. What's specifically wrong with this function — a numbered list of
   problems, and for each, why it hurts in practice (readability,
   testability, risk of bugs), not a reference to a general
   principle.
2. Three different refactoring options, from smallest to most
   radical. For each: what improves, what gets worse, how many files
   it touches, and whether it changes the public interface.
3. Which one you'd pick, and why — given [the context above].

I'll choose, and only then write me the code. Behavior must not
change; where it would have to, flag that in advance.

You'll get an analysis with options instead of a finished rewritten function. The decision stays yours — AI proposes, a human approves applies here too, because only you know whether that module gets thrown away next month or you'll spend another two years in it. And the basic condition of refactoring doesn't change: no refactoring without tests, no matter who's writing the code.

Phase 5: reviewing code you didn't write

This is the most important phase in the whole guide. Generating code is fast; what determines the quality of the repository is what you let through.

Why reviewing AI code is harder than reviewing a coworker's

Code from a junior developer carries traces of uncertainty — inconsistent naming, missing cases, comments like “probably”. Generated code is confident, consistent, and fluent, even when it's entirely wrong, so you read it less carefully. Exactly the opposite of what would be correct. And on top of that, you didn't watch it get written: with your own code you remember why that condition is there; with someone else's — or something else's — proposal, you have nothing until you ask.

Typical defects to prioritize hunting for in generated code: invented APIs (a library method that sounds plausible and doesn't exist, or existed in an older version), unhandled edge cases (an empty list, null, timezones, concurrency), a silent behavior change during a refactor, unnecessary abstraction built for generality nobody needs, and security carelessness — building queries by string concatenation, missing authorization checks, a secret hardcoded into the code.

A prompt for self-review before committing

Here's the diff I'm about to commit. Part of the code was written
with AI's help, and I want it reviewed as if someone else had
written it.

Context: [what the change does and why]. Project: [stack].

Go through the diff and return findings sorted into groups:
1. BUGS: what's wrong and will show up (incorrect behavior, an
   unhandled edge case, a behavior change compared to the original
   code).
2. SECURITY: unvalidated input, missing authorization checks,
   handling of secrets, injection risk, logging of sensitive data.
3. NONEXISTENT API: calls to functions, methods, or parameters that
   may not exist in the stated library versions — list them so I can
   verify them in the docs.
4. EXTRA: code that solves a problem I don't have — abstractions,
   parameters, and branches nobody calls.
5. MISMATCH WITH THE PROJECT: where this diverges from the
   conventions in the attached rules file.

For each finding: file, line, what to do about it. Don't fix
anything yourself.
At the end, write three questions I should be able to answer when
defending this change.

You'll get a structured list to work through. Always resolve point 3 by hand in the documentation — the model invented the nonexistent method, and it'll confirm just as confidently that it exists. The final three questions are a litmus test: if you can't answer one of them, you don't yet own that part of the change.

A second model as opponent

For bigger changes, it pays to run the review with a different tool from the one that wrote the code. An author is lenient toward their own draft — and that goes for models too. The approach is described in the AI as opponent tip; for code, it's enough to say: “this code was written by a different AI assistant, find the three most serious problems in it, and for each explain how it'll show up in production”. The phrasing “written by a different assistant” is deliberate; without it you get a more polite review.

Where review isn't enough, and you have to write it by hand

There are spots where reading someone else's proposal costs more than writing your own: authentication and authorization, payment handling, cryptography, database migrations, anything that deletes data. Here, treat generated code only as a first draft, and make the decisions yourself, line by line.

And a rule that can't be worked around: access keys, passwords, production customer data, and internal secrets don't belong in prompts or context. When you need to show a config file, replace the values with made-up ones. Handle anything more sensitive only in a paid account with contractual data protection — and check in advance what your company's rules are for sharing source code with external tools. That's not something you find out after the incident.

Phase 6: documentation, commit messages, and pull requests

Writing about code is work most developers put off, and AI does it well — under one condition: it has to describe why, not what. A comment that just retells the line below it is worse than no comment at all.

Commit messages

Here's the diff of my commit:
[paste the diff]

Context that isn't visible from the diff:
[why I'm doing this, the ticket number, what led up to it]

Write a commit message following [e.g. Conventional Commits]
convention, in [English / your language] per the repository's
habits:
- first line under 72 characters, imperative mood, no period,
- a blank line,
- body: WHY this change exists and what alternatives it had, not a
  retold list of changed files,
- if behavior or an interface changes, state it explicitly,
- a ticket reference at the end.

If you see two unrelated changes in the diff, don't fold them into
one message — tell me where to split it into separate commits.

You'll get a message that usually only needs minor tweaks. The last paragraph is unexpectedly useful: the model reliably notices when you've bundled a whole-file reformat in with a bug fix commit. More detail in the tip on commit messages.

A pull request description for the human who'll read it

Draft a pull request description from this diff and these commits:
[paste the diff and the list of commits]

Context: [ticket, the requirements, what we agreed on].

Structure:
- What's changing and why — 3 sentences, clear even for a coworker
  on another team.
- How I approached it, and what alternatives I considered and
  rejected.
- What the reviewer should look at carefully, and why that
  specifically.
- How to test it manually — concrete steps, not “run the app”.
- Risks, and what to do if this needs to be rolled back.
- What is deliberately NOT part of this change.

Write it briefly, no marketing language. Where information is
missing, write FILL IN: [what] instead of making it up.

You'll get a description that saves the reviewer half an hour. The FILL IN markers are there so the model doesn't invent the motivation for the change — without them, it'll make up a reason and it'll sound convincing.

Documentation that doesn't go stale in a month

Documentation follows the opposite rule from code: less is more. Have documentation written for the public interface (what it does, what it expects as input, what it returns, what errors it throws) and for decisions that aren't obvious from the code. Don't document the internal implementation — that will change next week, and the documentation will end up lying.

A practical prompt: “write documentation comments for this class's public methods; describe the contract and error states, not the implementation; where the code makes a non-obvious decision, add one sentence on why, and where you can't tell the reason from the code, write a question for me instead”. Answer those questions yourself afterward — they're exactly the spots where the knowledge exists only in your head.

Phase 7: agent mode with guardrails

The agent is the most powerful and most dangerous level. The difference between “it saved me a day” and “I had to throw the whole thing away” is in the request.

What a good agent request looks like

Four things it must include: scope (which files and directories, and what's off-limits), the definition of done (what has to pass for the work to be considered finished), a staged process with checkpoints where it waits for you, and prohibitions — what must never happen, no matter what.

Work in this repository.

TASK: [e.g. replace deprecated calls to library X with the new API
across the project — there are about 40 of them].

SCOPE: only the [src/, tests/] directories. Don't touch
[migrations/, infra/, deployment configuration] or dependencies in
the manifest.

PROCESS, stop after each step and wait for my approval:
1. Find every affected spot and list it in a table: file, line, type
   of usage. Sort them into straightforward cases and ones that
   require a decision.
2. For the three most complex cases, show me the proposed change and
   explain it.
3. Make the change in one file, run the tests, show me the diff.
4. Only after approval, process the rest of the straightforward
   cases, in two batches, each with its own commit.
5. Leave the cases requiring a decision unchanged and list them for
   me at the end with your recommendation.

DONE MEANS: all existing tests pass, behavior doesn't change, the
diff contains no unrelated formatting changes.

PROHIBITIONS: don't delete tests, don't modify them except for the
changed interface, don't update dependency versions, don't rewrite
code unrelated to the task, don't commit without my approval.

You'll get the work broken into checkable pieces. Without the “stop and wait” part, you get one diff across forty files that nobody properly reviews — and that's the fastest way for a change nobody understands to end up in the repository. The ban on modifying tests is there for a specific reason: when tests fail, a test is the easiest obstacle for an agent to remove.

Safety habits around an agent

• Always in a branch, never directly on main. That way an agent's work can be discarded with a single command.
• A clean working tree before you start it. Otherwise you can't tell what it changed and what you had in progress.
• Small commits per stage, not one at the end — you can roll back piece by piece.
• Tests as a guardrail: when the agent has them on hand and runs them, it fixes itself and you get less nonsense. A project with no tests is the worst candidate for agent mode, not the best.
• Read the whole diff. If it's too big to read, the request was wrong, not the review.

Subagents and delegating larger chunks of work

For larger tasks, it pays to split the work across several parallel runs — one maps the codebase, another writes tests, a third makes the change. Claude Code has subagents for this, described in a separate tip. A practical rule: delegate tasks whose result you can check faster than you could have produced it yourself. When checking takes longer than doing the work, delegating doesn't make sense.

Through connectors and MCP servers, you can also hook up other sources — an issue tracker, documentation, internal services — so the agent works with the context the team actually has on hand; there's a tip on MCP for that. Routine runs like “every morning go through new errors in the log and prepare a summary” can be run on a schedule with scheduled tasks. But it still holds that irreversible steps — merging, deploying, deleting data, sending communications — are approved by a human.

Common mistakes

• Accepting code you don't understand. The most expensive mistake of all, because it doesn't show up right away. Six months later you have a module nobody can change, and during an incident you're reading your own repository like a stranger's. The rule is simple: what you can't explain to a coworker, you don't commit.
• Letting AI generate tests from the implementation. A test written from existing code verifies a bug just as faithfully as correct behavior. Describe the intended behavior in your own words first, and only then have it written.
• Turning an agent loose on a big change all at once. A diff across forty files doesn't get reviewed, just rubber-stamped. Stages, separate commits, checkpoints.
• Trusting that a called method exists. Models invent APIs that sound exactly like what the name should be — especially for libraries that have changed between versions. Compilation only catches this some of the time; open the documentation.
• Using autocomplete while designing. A constant stream of ready-made suggestions cuts off your thinking before you reach a decision. Turn it off wherever structure is being decided.
• Sending keys, production data, or internal code into a prompt without thinking it through. Replace secrets with made-up values, handle sensitive matters only in a paid account with contractual data protection, and check your company's rules for sharing code first.
• Letting the assistant write without knowledge of the project. Without a conventions file and an attached example, you get code from the internet's average, which you then rewrite to match the rest of the repository — and then claim AI doesn't work.

The best tools

• GitHub Copilot — the most widely used inline autocomplete right in the editor (VS Code, JetBrains, and others); strongest at completing repetitive patterns on the fly and at boilerplate.
• Claude Code — agentic work across the whole repository: reads and changes files, runs tests and commands, works with git, and can delegate parts of a task to subagents; this is where migrations, codebase exploration, and multi-file changes belong.
• Claude Cowork — a desktop mode built around a project folder, useful when you're dealing with supporting material, documentation, and other files around the code, not just the code itself.
• Cursor — an editor built around AI from the ground up, for anyone who wants assistance deep inside their whole coding workflow.
• AI assistants built into JetBrains IDEs — an alternative for a team already living in IntelliJ or PyCharm that doesn't want to add another extension.
• A second tool as reviewer — a model that didn't write the code finds more in a proposal than its author did; deploy it on bigger changes and security-sensitive parts.
• MCP and connectors — hooking the assistant up to an issue tracker, documentation, or internal services, so it works with the context the team actually has available.

What you get out of it

• Time: a conservative estimate of roughly an hour a day on the routine part of the work — tests, boilerplate, documentation, commit messages, getting oriented in unfamiliar code. For migrations and bulk changes, the savings jump much higher; for design decisions, they're practically zero.
• Money: shorter onboarding into an unfamiliar codebase (days instead of weeks) is the most measurable team-level benefit; on top of that, fewer bugs caught only in production, because tests now get written even where there previously wasn't time for them.
• Peace of mind: an unfamiliar module stops being a threat. Before you touch it, you have a map of the data flow, a list of unwritten assumptions, and tests that catch it if you break something.
• Quality: higher test coverage, more honest commit messages, and documentation that actually exists — plus the habit of having every change explained, which improves even the code you write entirely yourself.

Pro tip

An advanced trick worth adopting as a team: have the assistant write not code, but a checklist for your own change. Before opening a pull request, feed it the diff and ask for five questions you'll need to be able to answer when defending it. It takes a minute and reliably surfaces spots where you accepted a proposal without actually thinking it through — long before a reviewer or production finds them for you.

And the closing rule that will outlive any generation of tools: AI proposes, a human approves. A tool may write ninety percent of the lines, but responsibility for what's on the main branch can't be delegated. Code you don't understand doesn't belong in the repository — no matter how confident it looks.