1. Courses
  2. Developer Foundations
  3. Ship a Project End to End
  4. Stop 3

30 minIntermediate

Working with AI coding assistants

AI assistants now write a real share of the code in many teams, from one-line completions to whole pull requests. They are fast and tireless, and they are confidently wrong often enough that the team's habits matter more than the tool. This lesson explains how they work in plain words and gives you the instruction file, prompt, review checklist and CI check that keep them useful and safe.

By the end you can

  • Explain the three ways assistants work (completion, chat, agents) and what each sees
  • Say what assistants are good and bad at, with concrete examples of how they fail
  • Write a project instruction file and a reusable prompt for a feature, test first
  • Review an AI-written PR with a checklist, and know where to be strictest
  • Add a CI step that blocks merges when code changes come without tests

The everyday picture

Imagine a new hire at Mangrove Market's head office who has read every retail manual ever printed, types faster than anyone, and never gets tired. On day one you ask for a stock report by store. In ten minutes you get a neat spreadsheet. Two columns are right. One uses last year's store list. One total is made up, because the source file was missing and the new hire did not want to say "I don't know".

You would not fire this person, and you would not let them post a delivery record unchecked either. You would give them the store list and the rules in writing, ask them to show their working, check the important numbers, and give them more freedom as they earn it. That is exactly how to work with an AI coding assistant: clear instructions, tests as proof, and review by a person who owns the result.

How assistants work, in plain words

Underneath every assistant is a (LLM). It does one thing: given some text, predict the most likely continuation, one small piece (a ) at a time. It does not run your code or look anything up unless a tool does that for it. What it can see is called its : your instruction, some files, instruction files and earlier messages. Anything outside the context, such as your other repos, today's library versions or your team's unwritten rules, it does not know.

Tools wrap the model in three main ways:

  • Inline completion. As you type in VS Code, the assistant suggests the rest of the line or function in grey text, and Tab accepts it. Context: mostly the current file and a few nearby ones. Fast and low risk, because you see every suggestion before it exists.
  • Chat. You ask a question or for a change in a side panel, and attach files or a selection. The assistant explains code, proposes an edit, or writes a test. You apply the result.
  • Agents. You give a task; the assistant plans, edits several files, runs commands such as tests, reads the output and tries again, all inside your editor, a terminal or a cloud environment. Some open a pull request on GitHub by themselves. This is the most powerful mode and needs the most guard rails, because it acts before you look.

Examples of tools, as of this writing: GitHub Copilot in VS Code and on GitHub, Claude Code, OpenAI Codex, Cursor, Gemini Code Assist, and JetBrains AI Assistant. They change quickly; read each tool's own documentation for what it can access and what data it keeps. Everything in this lesson applies to all of them. If you came here from Designing AI features, the model underneath is the same kind you met there, and an agent is the same tool-calling loop, pointed at your files and terminal instead of a store's database.

Quick check

Which way of working changes your files and runs commands before you have looked at anything?

Loading the rest of the lesson…