The short answer
AI for software engineers in November 2026 means working with coding agents: Cursor, GitHub Copilot and Claude Code (included from Claude Pro) plan changes, edit files, run terminal commands and tests, and GitHub Copilot's cloud agent opens pull requests in the background. Hand over features from a clear spec, tests, debugging, codebase explanations and first-pass reviews. Keep architecture, security-sensitive code and merge decisions human. Copilot Free, Pro, Pro+ and Max can train on your interaction data since 24 April 2026 unless you opt out.
| Agent in your editor | Cursor, GitHub Copilot agent mode (all plans), Claude Code (Claude Pro and above) |
|---|---|
| Background agents | GitHub Copilot cloud agent (Student and paid plans), Cursor Cloud Agents (Premium and above) |
| AI code review | Copilot code review, Cursor Bugbot (Premium and above) |
| Billing | GitHub Copilot bills by AI credits since 1 June 2026; completions do not use credits |
| Training defaults | Copilot Free to Max: on unless you opt out; Business and Enterprise: off; Cursor: off with Privacy Mode |
How software engineers use AI in 2026
Autocomplete was the first wave. In 2026 the default is an agent: you describe the change, it searches the codebase, plans, edits several files, runs the tests and either shows you a diff or opens a pull request. Cursor (made by Anysphere, a SpaceX subsidiary since 14 August 2026), GitHub Copilot from GitHub, and Claude Code from Anthropic are the three most engineers choose between. ChatGPT's Codex is in the same space and is included in limited form even on ChatGPT Free.
The skill that matters has shifted from typing code to specifying and reviewing it. A vague request gets a confident, plausible and subtly wrong change. A precise one, with the constraints and the test that proves it works, gets something you can merge after a careful read. Our best AI for coding page and Cursor vs GitHub Copilot compare the tools.
The 7 engineering tasks worth handing to AI
1. Features from a clear spec (Cursor, Copilot agent mode or Claude Code)
Write the spec first: the behaviour, the files likely involved, constraints and the acceptance test. In Cursor, Plan Mode (Shift+Tab in the chat input) researches the code, asks clarifying questions and writes an editable plan before coding. Approve the plan, then let the agent work.
2. Explaining an unfamiliar codebase (any of the three)
Ask the agent to trace a request from the entry point to the database and list every file it touches. It is the fastest onboarding there is, as long as you verify the path in the code.
3. Writing tests (Cursor, Copilot or Claude Code)
Ask for tests that cover edge cases and failure paths for a function, then run them. Tell the agent it may not change the code under test, otherwise it will sometimes "fix" the code to match a wrong test.
4. Debugging from a stack trace or failing test (any)
Paste the error, the failing test and what you expected. Ask for the three most likely causes ranked, with how to confirm each, before any fix. That keeps the agent from patching symptoms.
5. Background tasks while you work on something else (GitHub Copilot cloud agent or Cursor Cloud Agents)
GitHub Copilot's cloud agent researches a repository, plans and implements changes in a cloud environment, runs tests and linters and opens a pull request, on Copilot Student and paid plans. Cursor's Cloud Agents (Premium and above) can hold a long-running goal and react to pull requests, Slack threads or schedules. Good candidates: dependency upgrades, small bugs with a clear reproduction, test coverage gaps.
6. First-pass pull request review (Copilot code review or Cursor Bugbot)
Copilot code review uses the Balanced effort by default since 28 September 2026, and a Max effort is in public preview. Cursor's Bugbot is on Premium and above, and Security Review on Teams and Enterprise posts one comment per pull request about exploitable bugs. Treat these as a second pair of eyes, not the approver.
7. Design docs, migration plans and runbooks (Claude)
Claude is strong on long, structured writing. Give it the current design, the goal and the constraints and ask for options with trade-offs, a rollout plan and a rollback plan. Then decide yourself.
What software engineers should keep human
- Architecture and data models. Decisions that are expensive to reverse stay with people who will maintain them.
- Security-sensitive code. Authentication, authorisation, cryptography, payments and anything handling personal data get a careful human review, whatever the AI reviewer says.
- The merge decision. Someone who understands the change approves it. "The agent wrote it and the tests pass" is not a review.
- Incidents. Use AI to search logs and draft the timeline. A person runs the incident and talks to customers.
- Secrets. Never paste keys or credentials into prompts, and keep them out of files agents can read where possible.
A starter AI stack for software engineers
| Need | Tool | Plan | Notes |
|---|---|---|---|
| Agent in the editor | Cursor | Premium for Claude, GPT or Gemini models | Included usage covers Grok and Cursor's own models; third-party models are billed at API list price |
| GitHub-centred teams | GitHub Copilot | Pro, or Business for teams | Business data is not used for training; billing by AI credits |
| Terminal agent and writing | Claude (Claude Code) | Pro and above | Claude Code included from Pro; Team for work data |
| Second opinion | ChatGPT (Codex) | Free to try, Plus for more | Limited Codex on Free |
The "Ship a feature with AI pair-coding" stack on /stacks shows Claude for the spec, v0 for the interface, Cursor to wire it in and GitHub Copilot to review. More in our Cursor guide and GitHub Copilot guide.
A 30-day AI rollout plan for an engineering team
- Days 1 to 3: privacy and policy. On GitHub Copilot Free, Pro, Pro+ and Max, open your profile picture, Copilot settings, and set Allow GitHub to use my data for AI model training to Disabled. In Cursor, turn on Privacy Mode (team admins can enforce it from the team dashboard). Agree which repositories agents may touch.
- Days 4 to 10: one agent, small tasks. Each engineer uses one tool for tests and small bug fixes only. Add a rules file (Cursor reads .mdc files in .cursor/rules and AGENTS.md) with your conventions.
- Days 11 to 17: specs first. Try one real feature with a written spec and Plan Mode or an equivalent plan step. Note how much review it needed.
- Days 18 to 24: background work. Give the cloud agent a list of small, well-defined issues. Review every pull request as if a new hire wrote it.
- Days 25 to 30: measure and set budgets. Look at credit or token spend per merged change, review time and escaped bugs. Set spending limits before usage grows.
The risks for software engineers, and how to manage them
- Plausible wrong code. Agents produce changes that compile, pass weak tests and are still wrong. Strong tests and real review are the defence.
- Training on your code. Copilot's individual plans train on interaction data unless you opt out; with Cursor's Privacy Mode off, Cursor may use and store codebase data, prompts and code snippets to improve its AI and train its models.
- Cost surprises. Since 1 June 2026 every Copilot chat and agent run spends AI credits priced by tokens, and there is no fallback to a cheaper model when credits run out. In Cursor, Claude or GPT models cost per token on top of the plan.
- Prompt injection. Agents that read issues, web pages or dependencies can be steered by text hidden in them. Limit what agents can run and approve terminal commands. Read what prompt injection is.
- Skill fade. Junior engineers who never write the hard parts do not learn them. Pair on the reviews and ask "why" about every agent change.
Copy-ready prompts are in prompts for coding. If you are choosing between a chat assistant and an editor, read Claude vs Cursor.
Prompts for the 7 engineering tasks
One prompt per task. Replace the square brackets.
Prompts to copy
1. Plan before you code
Before writing any code, read the relevant parts of this repo and write a plan for: [feature]. Include the files you will change, the approach, edge cases, and the test that will prove it works. Ask me up to three questions if anything is unclear. Do not edit files until I approve the plan.
You get: A reviewable plan instead of a surprise diff
2. Trace a request through the codebase
Trace what happens when a user [action], from the entry point to the database and back. List every file and function involved in order, with one line on what each does. Mark anything you are unsure about.
You get: A map of the code path you can verify
3. Tests without touching the code
Write tests for [function or module] covering normal cases, edge cases ([list any you know]) and failure paths. Use our existing test style in [file]. Do not change the code under test. Run the tests and report which fail and why.
You get: Tests that check the code rather than bend to it
4. Diagnose before fixing
Here is the error and the failing test: [paste]. Expected behaviour: [describe]. List the three most likely causes, ranked, and how to confirm each one. Do not propose a fix until we have confirmed the cause.
You get: Root causes instead of patched symptoms
5. A task for the cloud agent
Upgrade [dependency] from [version] to [version]. Read the changelog, update call sites that use removed or changed APIs, run the full test suite and linters, and open a pull request that lists every breaking change you handled and anything you could not resolve.
You get: A pull request with a clear list of what changed
6. A focused review of a pull request
Review this diff: [paste or link]. Focus on correctness, security (input validation, authorisation, secrets) and missing tests. For each issue give the file and line, why it matters and a suggested change. Skip style comments.
You get: Review comments worth reading
7. A migration plan with rollback
We need to migrate [system] from [current] to [target]. Constraints: [downtime limits, data size, team size]. Give two or three approaches with trade-offs, a step-by-step rollout plan, how we verify each step, and a rollback plan for every step.
You get: Options and a plan you can take to the design review