Code with an AI assistant and keep control
AI can write code faster than you can review it. Here’s a workflow that keeps you in charge, and the security habits that stop a helpful assistant becoming a liability.
Video transcript
AI assistants can write code faster than you can read it. That’s the opportunity, and the risk. Here’s how to stay in charge.
You can work with an assistant in your editor, like Cursor or GitHub Copilot, in a chat window, or as an agent that edits many files and runs commands.
The workflow is the same for all three. Give it one small task with a clear spec, add tests first or alongside, and read every change before you accept it.
Use version control. Commit before the assistant starts and after each working step, so you can always roll back to the last good version.
Check every package it suggests. In one 2025 study, about a fifth of the packages recommended by AI models didn’t exist, and attackers can register names like those.
Never paste passwords or keys into a prompt. Mind the licence on code it borrows. And watch for prompt injection: instructions hidden in files or web pages, aimed at your assistant.
Finally, use it to learn. Ask it to explain code before you accept it. If you can’t explain what you’re shipping, you can’t maintain it.
Read the full guide below for a task spec and a code review prompt you can copy.
In 30 seconds
- Work in small, well-specified tasks with tests, and read every change before you accept it.
- Commit often with Jargon busterVersion control: A system, such as Git, that records every change to your code, so you can see what changed and go back to any earlier version., so anything the assistant changes can be undone.
- Never paste secrets, check every new Jargon busterDependency: A package of someone else’s code that your project relies on, usually installed from a public registry such as npm or PyPI. is real and trusted, and watch for Jargon busterPrompt injection: Hidden instructions in a web page or document that try to trick an AI into doing something you didn’t ask..
AI coding assistants can scaffold a feature in minutes, explain unfamiliar code and write the tests you’ve been putting off. They can also produce plausible code that’s subtly wrong, insecure or borrowed. The skill now is less about typing and more about directing and reviewing.
This guide is for people who can read code. If you’d rather describe an app and let AI build all of it, start with build an app with AI.
Three ways to work
- In your editorCursor and GitHub Copilot suggest code as you type and answer questions about your project.
- In a chatPaste in a function or an error message and ask what’s wrong. Good for explanations, small scripts and second opinions.
- As an agentAn Jargon busterAI agent: An AI that carries out a task in several steps, such as searching, clicking and filling in forms, rather than just replying. plans a change, edits many files and runs commands. It saves the most time, and needs the firmest limits.
Agents carry the most risk, because one instruction can touch dozens of files. The workflow below works for all three.
A workflow that keeps you in control
- Start cleanCommit your work with Jargon busterVersion control: A system, such as Git, that records every change to your code, so you can see what changed and go back to any earlier version. first, ideally on a new branch, so you can throw away anything you don’t like.
- Write a clear specSay what to change, where, and what done looks like. Name the files, the constraints and what it mustn’t touch.
- Keep tasks smallOne function, one bug or one screen at a time. Small changes get reviewed properly; huge ones get waved through.
- Tests first, or alongsideWrite or ask for Jargon busterAutomated test: A small piece of code that checks other code does what it should. You can rerun hundreds of them in seconds after every change. that pin down the behaviour. Check they fail before the change and pass after it.
- Read every changeReview every changed line before you accept it. If you can’t explain what a line does, ask, or reject it.
- Run it yourselfRun the tests and the app. Code that reads well can still fail.
- Commit each stepCommit every working step with a clear message, so you can roll back to the last good version.
Task: [one specific change, such as adding a ‘forgot password’ link to the sign-in page]. Context: [language, framework and the relevant files]. Constraints: change only [these files], follow the existing style, and don’t add any new dependencies without asking. Done means: [the behaviour you expect, and the tests that should pass]. First, explain your plan and list the files you’ll change. Then wait for my go-ahead before editing anything.
Security habits that matter
of the packages that 16 AI models recommended, across 576,000 code samples, didn’t exist.
Source: USENIX Security Symposium (the authors’ repository), We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, 2025- Never paste secrets. Keep passwords and Jargon busterAPI key: A code that lets software use an online service on your account. Secret keys must stay private: anyone who has one can use the service as you. out of prompts, code and version control, and if one leaks, revoke it straight away. At work, check your employer allows its code in the tool.
- Check every new dependency. Assistants sometimes suggest packages that don’t exist, and attackers can register those names with malicious code. Before you install a Jargon busterDependency: A package of someone else’s code that your project relies on, usually installed from a public registry such as npm or PyPI., check it exists, is the one you meant and is actively maintained.
- Mind the licence. Suggestions can match public code that comes with licence conditions. GitHub Copilot, for example, can block matching suggestions or show where the code came from.
- Watch for [[prompt injection]]. A README, web page or code comment can carry instructions aimed at your assistant. Don’t let an agent run commands or browse unattended in projects or on pages you don’t trust.
- Review for vulnerabilities. Check that inputs are validated, database queries are parameterised and permissions are checked on the server. Keep your usual security scanners and code review in place.
Use it to learn, not just to ship
The most valuable habit is asking why. Ask the assistant to explain code before you accept it, to compare two approaches, or to review your own code like a demanding senior colleague. If you can’t explain what you’re shipping, you can’t maintain it.
Review this [language] code as a strict senior developer: [paste code]. Look for bugs, security problems (unvalidated input, injection, exposed secrets, missing permission checks) and confusing names. For each issue, explain why it matters and suggest a fix, but don’t rewrite the whole thing. Finish with two questions that test whether I understand the code.
Check yourself
3 quick questions nothing is savedTools in this guide
Sources (3)
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMsUSENIX Security Symposium (the authors’ repository), 2025
- LLM01:2025 Prompt InjectionOWASP Top 10 for LLM Applications, 2025
- GitHub Copilot code referencingGitHub Docs
Spotted a mistake? Tell us and an editor will check it.
