AI Coding Assistants: Modes, Strengths and Your Responsibility

Every developer who has used a coding assistant has had both experiences. The one where a tedious twenty-line function appears fully formed, correct on the first run, and you feel a little giddy. And the one where a function appears fully formed, compiles, passes the one test you wrote, and ships a bug that surfaces three weeks later at an awkward time.

The tool is the same in both cases. What differs is what the developer did before and after the suggestion appeared. This module is about that "before and after".

• The main modes of coding assistants and what each is for.
• How to give them the context they need.
• What research says about speed and security, and what it does not say.
• The responsibilities that stay with you.
• A responsible, repeatable workflow.

Products change their names and bundle features differently, so think in modes. GitHub's documentation for Copilot gives a representative list: suggestions as you type, answering questions about code, editing or refactoring on request, reviewing code and pull requests, and an agent mode in which you describe a goal and the tool works through multiple steps. Other assistants offer the same ideas in other packages.

A rough rule: the more autonomous the mode, the more you must constrain it and the more you must review. Agents are covered conceptually in Module 8. In coding they appear as agent modes, which can edit files and run commands, so the permissions you give them matter.

A coding assistant can only work from what it sees. GitHub's own prompting advice amounts to a list of context habits:

• Start with the broad goal, then list specific requirements.
• Provide examples, such as sample inputs and outputs, or unit tests, which GitHub notes work well as concrete targets.
• Break large tasks into smaller steps.
• Be specific. Refer to a function by its name instead of "this".
• Supply relevant context, such as keeping pertinent files open and selecting the code in question.
• Iterate, treating an unhelpful answer as a starting point.
• Keep your code clean. Clear names and comments help the tool as much as they help people.

Turn that into a prompt:

Context: a Python 3.11 Flask app. The function parse_due_date(text) inutils/dates.py turns user input into a date.Task: extend it to also accept "tomorrow" and "next friday", keeping existingformats working.Constraints: no new dependencies; do not change function signatures; do notedit any other file; follow the existing naming style.Examples: "2026-10-05" -> 2026-10-05; "tomorrow" (today is 2026-10-05) ->2026-10-06; "someday" -> raise ValueError.First, list the edge cases you think matter and any questions. Then give thechange as a diff.

It is the same four-element brief as in article 6, with code-specific context: language version, files, signatures, constraints and examples. "List edge cases and questions first" invites the assistant to expose its assumptions before writing code.

Two kinds of claims dominate discussions: that AI makes developers faster, and that it makes code worse. Both deserve a careful reading of what was actually measured.

A 2025 randomised controlled trial by METR studied 16 experienced open-source developers working on 246 tasks in repositories they knew well, with and without AI tools available (mostly Cursor Pro with Claude 3.5 and 3.7 Sonnet at the time). The authors reported that allowing AI increased completion time by 19 percent, while the developers had expected a 20 percent speed-up. They list caveats, including a small sample, a specific setting (experienced developers on mature projects they knew well) and that experimental artefacts cannot be ruled out.

What you can fairly conclude is limited. It does not show that AI slows down everyone, or that it will do so with today's tools. It does show that feeling faster is not the same as being faster, and that benefits depend on the person, the task and the codebase. Beginners learning a new framework, or developers writing boilerplate, are different situations. The honest approach is to measure: time a few comparable tasks with and without assistance.

Two studies, both from earlier versions of these tools:

• "Asleep at the Keyboard?" (Pearce et al.) tested GitHub Copilot across 89 scenarios involving well-known high-risk weakness categories, producing 1,689 programs, and found that approximately 40 percent were vulnerable.
• "Do Users Write More Insecure Code with AI Assistants?" (Perry et al.) found that participants with an AI assistant wrote significantly less secure code than those without, yet were more likely to believe their code was secure. Participants who trusted the assistant less and engaged more with the prompts produced fewer security flaws.

Tools have changed since these were run, so do not quote the numbers as current. Still, the two lessons have held up well in practice: plausible code can be insecure, and confidence rises faster than correctness. Article 21 covers this in depth.

GitHub's documentation reflects this: it describes reviewing and applying suggestions as the developer's role, and says that for agent work you remain responsible for reviewing and approving.

1. Understand the task first. Write the acceptance criteria in one or two sentences before you prompt. If you cannot, the assistant cannot either.
2. Work in small steps. One function, one change, one test.
3. Provide context and constraints, as above, including what not to change.
4. Ask for assumptions and edge cases before the code, not after.
5. Read every line you accept. If you cannot explain it, do not commit it. Simon Willison's rule of thumb is that he does not commit code to his repository if he could not explain exactly what it does to somebody else.
6. Run it. Tests, linters, type checks and a manual try-out.
7. Review the diff as if a stranger wrote it, because in effect one did.
8. Commit in small units, with messages that describe what you understand the change to do.
9. Note what the assistant got wrong. That tells you where to be careful next time.

• If you are learning, the attempt-first rules of Module 3 apply strongly. Writing code yourself is how you learn to read it. How to Learn Programming When AI Can Already Write Code discusses the balance.
• If you are experienced, your strongest contribution is in specification, review and architecture. Delegate the boilerplate and keep the judgment.
• If you lead a team, agree on a policy: which tools are approved, what may be pasted, how AI-assisted code is reviewed and how it is disclosed, if at all.

• Accepting suggestions because they compile.
• Prompting vaguely ("fix this") and letting the tool choose the approach.
• Letting an agent loose on a whole repository without version control, small steps or review.
• Believing you are faster without measuring.
• Pasting secrets, tokens or proprietary code into unapproved tools.
• Using AI-written tests as proof that the AI-written code is right (article 20).
• Not telling anyone, when your team expects disclosure.

Context: a Node.js Express app. POST /login takes about 800 ms. Profiling showsmost of it is a database query in auth/findUser.js that scans the users table byemail. The email column has no index.Task: suggest how to make the lookup faster.Constraints: PostgreSQL 15; no new dependencies; do not change the API response;migration must be reversible.Examples: the query currently is SELECT * FROM users WHERE email = $1.First, tell me what other things could make login slow that I should rule out,and which assumptions you are making. Then propose the change.

• Next: Use AI to Understand Code, Codebases, APIs and Documentation uses assistants for reading, which is often safer and more valuable than writing.
• For debugging, go to How to Use AI to Debug Code Safely.
• For security, see Security and Licensing Risks of AI-Generated Code.