{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/en/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"An AI coding assistant can write a working function in seconds. It explains confusing error messages, suggests tests and renames a variable across a whole project. The same assistant can also call a function that does not exist, pick a library version that is years old or leave a door open for attackers. And it does all of this in code that looks clean and confident.\n\nThis is part 5 of Level 0 in our AI Development learning path. You will learn the three main forms of coding assistants, the tasks where they save real time, the mistakes they typically make and why the review always stays with you. You do not need to program: a short code example shows the typical mistakes, and the text explains them in plain words.\n\n## Three forms: from autocomplete to agent\n\nAn **AI coding assistant** is a tool that uses a large language model (LLM) to suggest, explain or change program code. The model has learned from huge amounts of public code and text. It predicts which code most likely fits your request. It does not know whether that code is correct. [Part 1 of this level](/en/ai-development/learn/what-is-ai-development/) introduced the three forms. Here is what each one does in practice:\n\n- **Autocomplete.** While you type in your code editor, the assistant suggests the next line or a whole block in light gray text. You accept it with one key or simply keep typing.\n- **Chat.** You ask questions in a chat window next to your code or in the browser: \"What does this function do?\" or \"Write a function that checks an email address.\" You copy the answer into your project yourself.\n- **Agents.** You describe a task, for example \"add a search field to the product page\". The agent plans the steps, reads and edits several files, runs commands and tests, and shows you the result as a **diff**: a list of every line it added, changed or deleted. Some agents work in your editor or terminal. Others work in the cloud and deliver a **pull request**, a proposed change that a person reviews before it becomes part of the project.\n\n![Staircase with four steps: autocomplete, chat, agent in the editor and agent in the cloud; above each step what you review at once, from a line or two to a whole pull request](/images/learn/en/what-ai-coding-assistants-do-levels.webp \"The more an assistant does on its own, the more you have to review at once.\")\n\nMany products offer several of these forms, and the borders blur. The key difference is how much the assistant does before you look at the result: with autocomplete, you check a line or two; with an agent, changes in many files at once.\n\n## Where assistants save real time\n\nAssistants work best on tasks with a clear pattern, where you can quickly see whether the result is right. Two terms come up often. **Boilerplate** is standard code that looks almost the same in every project, such as the settings for a web form. A **unit test** is a small program that checks one function automatically, for example whether a price calculation still returns the right total.\n\n| Task | How the assistant helps | What you still check |\n|---|---|---|\n| Boilerplate | Writes settings files, forms and routine database queries | That it follows your project's style and rules |\n| Tests | Suggests unit tests and unusual cases for existing functions | That each test checks the right thing, not just that it passes |\n| Explanations | Explains unfamiliar code and error messages line by line | Important claims against the official documentation |\n| Small changes | Renames, splits or converts code; writes comments and documentation | The diff, line by line |\n| Prototypes | Builds a first working version of an idea in minutes | Everything, before the prototype turns into a product |\n\nExplanations are useful even if you never write code yourself. Before you change or run a program, ask the assistant what it does, line by line. It is a fast way to learn a new programming language or to find your way around an unfamiliar project.\n\nPrototypes are where *vibe coding* shines: you describe an idea, the AI writes the code, and you test and correct it. Our [VibeCoding article](/en/ai-development/vibecoding-faster-experiments-ai-development/) shows how we use this approach for experiments, and for which kinds of code we do not use it.\n\n## Typical mistakes and why they happen\n\nAn assistant does not look anything up while it writes, unless the tool gives it a web search or the documentation. It produces code that looks right, based on patterns it has learned. Most of the time, that works. But some mistakes come up again and again. The example below shows three kinds of them in ten lines of code.\n\n![Python code in an editor window with four marked problems: an old library version, a secret key in the code, a switched-off security check and a method that does not exist](/images/learn/en/what-ai-coding-assistants-do-mistakes.webp \"An illustrative AI suggestion: it looks clean, but a reviewer should catch four problems.\")\n\n- **Invented functions and packages.** The model writes a name that sounds right but does not exist, like `json_list()` in the example. This is a **hallucination**, the code version of an invented quote. It can also happen with whole packages: the assistant suggests installing a library that was never published. Security researchers warn that attackers can publish harmful code under such invented names (Source: Spracklen et al., \"We Have a Package for You!\", USENIX Security 2025, usenix.org).\n- **Outdated libraries.** A model learns from code up to a cutoff date, and much of that code is older. So it may pin an old version of a library or use a function that was removed long ago. The version in the example dates from 2018, and newer releases fix known security flaws.\n- **Security bugs.** Public code contains insecure patterns, and models repeat them. Typical examples are an **API key** (a secret code that gives access to a paid service) written into the code, a security check switched off, or user input passed on without checks. A Stanford study found that people with an AI assistant wrote less secure code than people without one, and were more likely to believe their code was secure (Source: Perry et al., \"Do Users Write More Insecure Code with AI Assistants?\", ACM CCS 2023, arxiv.org).\n- **Plausible but wrong logic.** The code runs, but it does the wrong thing: it forgets an edge case, rounds a price the wrong way or fails on an empty list. Tests that the same assistant wrote may share the same misunderstanding.\n- **Missing context.** The assistant sees only what the tool gives it: often the open file, sometimes more of the project. It does not know your team's rules, why old code looks the way it does or what your customer really asked for.\n\nAgents add risks of their own, because they act instead of only suggesting. An agent may change files you did not mention, or make failing tests pass by changing the tests instead of the code. It can also be misled by instructions hidden in the content it reads, such as a web page or a code comment. This is called **prompt injection**. Give agents only the access they need, and let them ask before they run commands. Our [AI Security](/en/ai-security/) section explains these risks in more depth.\n\n{{\u003c callout type=\"warning\" \u003e}}\nNever paste passwords, API keys or customer data into a coding assistant. Do not let an agent work with access to live systems or real customer data: give it test data and a separate test environment instead.\n{{\u003c /callout \u003e}}\n\n## How good are coding assistants? A look at the data\n\nResearchers compare models with **benchmarks**: fixed sets of test tasks with a clear score. For coding, one of the best known is SWE-bench Verified. It uses real problems from open-source Python projects, whose code anyone can read, and the model has to change the code until the project's own tests pass. These are the leaders in our LLM data:\n\n{{\u003c llm-top bench=\"swe-bench-verified\" n=\"5\" \u003e}}\n\nTwo notes help you read the table. First, these are Epoch AI's own runs with one fixed setup; vendors often report higher numbers with their own tooling. Second, not every new model has been tested on every benchmark yet, so some of the newest models in our [LLM database](/en/llm/) may be missing here.\n\n![Two grids of 100 squares for SWE-bench Verified, one for the earliest and one for the best result in our data; the filled squares show the share of solved tasks](/images/learn/en/what-ai-coding-assistants-do-progress.webp \"Earliest and best result on SWE-bench Verified in our LLM database. Data: Epoch AI, CC BY 4.0.\")\n\nThe figure puts the scores in perspective. Coding models have improved fast. But the benchmark consists of small, well-described fixes that people screened in advance. Your own project is messier: other languages, unwritten rules, unclear requirements. A high score tells you that a model is worth trying, not that its code is right. Level 4 explains [how coding benchmarks work](/en/ai-development/learn/coding-benchmarks-explained/) and where they can mislead, for example through flawed tests.\n\n## You are the reviewer\n\nWhoever accepts the code is responsible for it, not the assistant. Treat AI code like code from a new colleague who is fast and well read but sometimes wrong without noticing. How closely you check depends on two questions: what breaks if the code is wrong, and how well do you understand it?\n\nThe more you trust the tool, the harder this gets. In a 2025 survey of 319 knowledge workers by Microsoft Research and Carnegie Mellon University, people with more confidence in generative AI reported less critical thinking, while people with more confidence in their own skills reported more (Source: Lee et al., CHI 2025). For code, this means: the moment an assistant starts to feel reliable is the moment to keep reading.\n\n![Two-by-two grid with the axes \"how new the code is to you\" and \"what breaks if it is wrong\"; the four fields range from a quick check to an expert review, each with an example](/images/learn/en/what-ai-coding-assistants-do-review.webp \"How closely to check AI code: the higher the stakes and the newer the code is to you, the more care it needs.\")\n\nFive habits cover most situations:\n\n1. **Work in small steps.** Ask for one function or one change at a time. A small diff is easy to read; a huge one tempts you to skim.\n2. **Ask before you accept.** Let the assistant explain its code and list its assumptions. If the explanation does not match the code, something is wrong.\n3. **Run it and test it.** Run the code and the tests, and read the tests, too.\n4. **Check every new package.** Does it exist, is it the one you meant, and is the version current?\n5. **Get a second reviewer** for code that handles logins, payments or personal data.\n\nTools can take over part of the checking. According to the vendor, TestDriver.ai writes and runs tests for pull requests and reports errors before a change is merged. App builders sit at the other end. According to the vendors, Emergent builds web and mobile apps from a plain-language description, and Devs.ai lets teams build apps and agents on their own data. The less code you write yourself, the more your checks matter. We have not tested these tools.\n\n{{\u003c tools \"emergent devs-ai testdriver-ai\" \u003e}}\n\nLevel 2 turns these habits into [a complete coding workflow with checkpoints](/en/ai-development/learn/ai-assisted-coding-workflow/).\n\n## Checklist: before you accept AI-written code\n\nGo through these questions whenever an assistant hands you code, whether it is one line or a whole pull request:\n\n| Question | Why it matters |\n|---|---|\n| Can I explain what each line does? | Code you do not understand, you cannot fix or maintain |\n| Does it run, and do the tests pass? Have I read the tests? | Passing tests only help if they check the right thing |\n| Do all functions and packages exist, in a current version? | Invented and outdated code is a common mistake |\n| Is a password, key or other secret in the code? | Anyone who can see the code can use it |\n| Is a security check switched off, or is user input used unchecked? | Such gaps work fine until someone attacks them |\n| Did the change touch anything I did not ask for? | Agents sometimes edit other files, settings or tests |\n\n{{\u003c callout type=\"try\" \u003e}}\nDo a small review exercise with any chat assistant:\n\n1. Ask: *\"Write a Python function that calculates the total of a shopping cart with an optional discount in percent. Add three tests.\"*\n2. Then ask: *\"Explain each line. Which inputs could break the function, and which of them do the tests cover?\"*\n3. Compare the answer with the checklist. Did it think of an empty cart, a negative quantity or a discount above 100 percent? If not, ask about them yourself.\n\nYou do not need to run the code to learn from this. Finding the gaps is the core skill of every reviewer.\n{{\u003c /callout \u003e}}","text":"An AI coding assistant can write a working function in seconds. It explains confusing error messages, suggests tests and renames a variable across a whole project. The same assistant can also call a function that does not exist, pick a library version that is years old or leave a door open for attackers. And it does all of this in code that looks clean and confident.\nThis is part 5 of Level 0 in our AI Development learning path. You will learn the three main forms of coding assistants, the tasks where they save real time, the mistakes they typically make and why the review always stays with you. You do not need to program: a short code example shows the typical mistakes, and the text explains them in plain words.\nThree forms: from autocomplete to agent An AI coding assistant is a tool that uses a large language model (LLM) to suggest, explain or change program code. The model has learned from huge amounts of public code and text. It predicts which code most likely fits your request. It does not know whether that code is correct. Part 1 of this level introduced the three forms. Here is what each one does in practice:\nAutocomplete. While you type in your code editor, the assistant suggests the next line or a whole block in light gray text. You accept it with one key or simply keep typing. Chat. You ask questions in a chat window next to your code or in the browser: \u0026ldquo;What does this function do?\u0026rdquo; or \u0026ldquo;Write a function that checks an email address.\u0026rdquo; You copy the answer into your project yourself. Agents. You describe a task, for example \u0026ldquo;add a search field to the product page\u0026rdquo;. The agent plans the steps, reads and edits several files, runs commands and tests, and shows you the result as a diff: a list of every line it added, changed or deleted. Some agents work in your editor or terminal. Others work in the cloud and deliver a pull request, a proposed change that a person reviews before it becomes part of the project. The more an assistant does on its own, the more you have to review at once. Many products offer several of these forms, and the borders blur. The key difference is how much the assistant does before you look at the result: with autocomplete, you check a line or two; with an agent, changes in many files at once.\nWhere assistants save real time Assistants work best on tasks with a clear pattern, where you can quickly see whether the result is right. Two terms come up often. Boilerplate is standard code that looks almost the same in every project, such as the settings for a web form. A unit test is a small program that checks one function automatically, for example whether a price calculation still returns the right total.\nWhat AI Coding Assistants Do (and Where They Fail) Task How the assistant helps What you still check Boilerplate Writes settings files, forms and routine database queries That it follows your project\u0026rsquo;s style and rules Tests Suggests unit tests and unusual cases for existing functions That each test checks the right thing, not just that it passes Explanations Explains unfamiliar code and error messages line by line Important claims against the official documentation Small changes Renames, splits or converts code; writes comments and documentation The diff, line by line Prototypes Builds a first working version of an idea in minutes Everything, before the prototype turns into a product Explanations are useful even if you never write code yourself. Before you change or run a program, ask the assistant what it does, line by line. It is a fast way to learn a new programming language or to find your way around an unfamiliar project.\nPrototypes are where vibe coding shines: you describe an idea, the AI writes the code, and you test and correct it. Our VibeCoding article shows how we use this approach for experiments, and for which kinds of code we do not use it.\nTypical mistakes and why they happen An assistant does not look anything up while it writes, unless the tool gives it a web search or the documentation. It produces code that looks right, based on patterns it has learned. Most of the time, that works. But some mistakes come up again and again. The example below shows three kinds of them in ten lines of code.\nAn illustrative AI suggestion: it looks clean, but a reviewer should catch four problems. Invented functions and packages. The model writes a name that sounds right but does not exist, like json_list() in the example. This is a hallucination, the code version of an invented quote. It can also happen with whole packages: the assistant suggests installing a library that was never published. Security researchers warn that attackers can publish harmful code under such invented names (Source: Spracklen et al., \u0026ldquo;We Have a Package for You!\u0026rdquo;, USENIX Security 2025, usenix.org). Outdated libraries. A model learns from code up to a cutoff date, and much of that code is older. So it may pin an old version of a library or use a function that was removed long ago. The version in the example dates from 2018, and newer releases fix known security flaws. Security bugs. Public code contains insecure patterns, and models repeat them. Typical examples are an API key (a secret code that gives access to a paid service) written into the code, a security check switched off, or user input passed on without checks. A Stanford study found that people with an AI assistant wrote less secure code than people without one, and were more likely to believe their code was secure (Source: Perry et al., \u0026ldquo;Do Users Write More Insecure Code with AI Assistants?\u0026rdquo;, ACM CCS 2023, arxiv.org). Plausible but wrong logic. The code runs, but it does the wrong thing: it forgets an edge case, rounds a price the wrong way or fails on an empty list. Tests that the same assistant wrote may share the same misunderstanding. Missing context. The assistant sees only what the tool gives it: often the open file, sometimes more of the project. It does not know your team\u0026rsquo;s rules, why old code looks the way it does or what your customer really asked for. Agents add risks of their own, because they act instead of only suggesting. An agent may change files you did not mention, or make failing tests pass by changing the tests instead of the code. It can also be misled by instructions hidden in the content it reads, such as a web page or a code comment. This is called prompt injection. Give agents only the access they need, and let them ask before they run commands. Our AI Security section explains these risks in more depth.\n!Watch out\nNever paste passwords, API keys or customer data into a coding assistant. Do not let an agent work with access to live systems or real customer data: give it test data and a separate test environment instead.\nHow good are coding assistants? A look at the data Researchers compare models with benchmarks: fixed sets of test tasks with a clear score. For coding, one of the best known is SWE-bench Verified. It uses real problems from open-source Python projects, whose code anyone can read, and the model has to change the code until the project\u0026rsquo;s own tests pass. These are the leaders in our LLM data:\nSWE-bench Verified: the top 5 models #ModelReleasedResult 1Claude Opus 4.7 (max) AnthropicApr 16, 202683.5% 2GPT-5.5 (xhigh) OpenAIApr 23, 202680.6% 3Gemini 3.5 Flash Google DeepMindMay 19, 202679.3% 4Claude Opus 4.6 (no thinking) AnthropicFeb 5, 202678.7% 5GLM-5.2 Z.ai (Zhipu AI)Jun 16, 202678.7% 500 real issues from open-source Python projects, checked by humans. The model has to change the code so that the project\u0026#39;s tests pass. Data: Epoch AI, retrieved on October 17, 2026, licensed CC BY 4.0. All models: LLM database.\nTwo notes help you read the table. First, these are Epoch AI\u0026rsquo;s own runs with one fixed setup; vendors often report higher numbers with their own tooling. Second, not every new model has been tested on every benchmark yet, so some of the newest models in our LLM database may be missing here.\nEarliest and best result on SWE-bench Verified in our LLM database. Data: Epoch AI, CC BY 4.0. The figure puts the scores in perspective. Coding models have improved fast. But the benchmark consists of small, well-described fixes that people screened in advance. Your own project is messier: other languages, unwritten rules, unclear requirements. A high score tells you that a model is worth trying, not that its code is right. Level 4 explains how coding benchmarks work and where they can mislead, for example through flawed tests.\nYou are the reviewer Whoever accepts the code is responsible for it, not the assistant. Treat AI code like code from a new colleague who is fast and well read but sometimes wrong without noticing. How closely you check depends on two questions: what breaks if the code is wrong, and how well do you understand it?\nThe more you trust the tool, the harder this gets. In a 2025 survey of 319 knowledge workers by Microsoft Research and Carnegie Mellon University, people with more confidence in generative AI reported less critical thinking, while people with more confidence in their own skills reported more (Source: Lee et al., CHI 2025). For code, this means: the moment an assistant starts to feel reliable is the moment to keep reading.\nHow closely to check AI code: the higher the stakes and the newer the code is to you, the more care it needs. Five habits cover most situations:\nWork in small steps. Ask for one function or one change at a time. A small diff is easy to read; a huge one tempts you to skim. Ask before you accept. Let the assistant explain its code and list its assumptions. If the explanation does not match the code, something is wrong. Run it and test it. Run the code and the tests, and read the tests, too. Check every new package. Does it exist, is it the one you meant, and is the version current? Get a second reviewer for code that handles logins, payments or personal data. Tools can take over part of the checking. According to the vendor, TestDriver.ai writes and runs tests for pull requests and reports errors before a change is merged. App builders sit at the other end. According to the vendors, Emergent builds web and mobile apps from a plain-language description, and Devs.ai lets teams build apps and agents on their own data. The less code you write yourself, the more your checks matter. We have not tested these tools.\nEmergentApp Building \u0026amp; Testing · AI at the coreBuilds web and mobile apps from a plain-language description. Devs.aiApp Building \u0026amp; Testing · AI at the corePlatform where teams build and run AI applications and custom agents on their own data. TestDriver.aiApp Building \u0026amp; Testing · AI at the coreRuns pull requests in a desktop sandbox, finds bugs and builds regression tests. Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.\nLevel 2 turns these habits into a complete coding workflow with checkpoints.\nChecklist: before you accept AI-written code Go through these questions whenever an assistant hands you code, whether it is one line or a whole pull request:\nWhat AI Coding Assistants Do (and Where They Fail) (2) Question Why it matters Can I explain what each line does? Code you do not understand, you cannot fix or maintain Does it run, and do the tests pass? Have I read the tests? Passing tests only help if they check the right thing Do all functions and packages exist, in a current version? Invented and outdated code is a common mistake Is a password, key or other secret in the code? Anyone who can see the code can use it Is a security check switched off, or is user input used unchecked? Such gaps work fine until someone attacks them Did the change touch anything I did not ask for? Agents sometimes edit other files, settings or tests ▸Try it\nDo a small review exercise with any chat assistant:\nAsk: \u0026ldquo;Write a Python function that calculates the total of a shopping cart with an optional discount in percent. Add three tests.\u0026rdquo; Then ask: \u0026ldquo;Explain each line. Which inputs could break the function, and which of them do the tests cover?\u0026rdquo; Compare the answer with the checklist. Did it think of an empty cart, a negative quantity or a discount above 100 percent? If not, ask about them yourself. You do not need to run the code to learn from this. Finding the gaps is the core skill of every reviewer.\n","words":2156},"date":"2026-10-14","description":"Autocomplete, chat and agents: what AI coding assistants do well, which mistakes they typically make, and why you still review every change.","image":"https://abxk.ai/images/cover/what-ai-coding-assistants-do.webp","json":"https://abxk.ai/en/ai-development/learn/what-ai-coding-assistants-do/index.json","kind":"page","language":"en","learning_path":{"category":"ai-development","level":0,"level_name":"Start here"},"modified":"2026-10-14","related_tools":["Emergent","Devs.ai","TestDriver.ai"],"section":"ai-development","tags":["ai-coding","coding-assistants","code-review","beginner","ai-development"],"title":"What AI Coding Assistants Do (and Where They Fail)","translations":[{"json":"https://abxk.ai/de/ai-development/learn/what-ai-coding-assistants-do/index.json","language":"de","url":"https://abxk.ai/de/ai-development/learn/what-ai-coding-assistants-do/"}],"url":"https://abxk.ai/en/ai-development/learn/what-ai-coding-assistants-do/"}