AI in software development

This page is an overview of how AI is used to write, review, and maintain software. It describes the kinds of tools rather than comparing products, and it covers the effect on the work itself: what gets faster, what gets riskier, and what developers still have to do themselves.

Why code suits AI

Code is one of the areas where language models are strongest, for several reasons. Public repositories provide an enormous amount of training data. Code follows strict rules and recurring patterns. And code can be checked automatically: it compiles or it does not, and tests pass or fail. That last property matters most, because it lets both the training process and the developer verify the model’s work, which is much harder for an essay or a legal opinion.

From autocomplete to agents

AI support for programmers developed in clear stages, and each stage is still in use:

Stage	What the tool does	Developer’s role
Code completion	Suggests the rest of a line or a whole function while you type	Accepts or ignores suggestions
Chat in the editor	Answers questions, explains code, writes snippets on request	Asks, copies, and adapts
Edits across files	Applies a requested change to several files at once	Describes the change and reviews the result
Coding agents	Reads the codebase, edits, runs commands and tests, iterates until done	Sets the task, reviews, and decides
Background agents	Work on a task in a cloud environment and open a pull request	Assigns tasks and reviews pull requests

GitHub Copilot, previewed in 2021, brought AI code completion to millions of developers. Chat assistants followed in 2023. From 2024, AI-focused editors such as Cursor and agent tools that run in the terminal, such as Claude Code and OpenAI’s Codex, let the model work on whole tasks. By 2025, assigning an issue to an agent and receiving a pull request had become an everyday workflow in many teams.

What AI does well

Boilerplate and routine code: configuration, data models, API clients, form validation.
Working in unfamiliar territory: a new language, framework, or library, with explanations along the way.
Understanding existing code: summarizing what a module does, tracing where a value comes from, explaining an old function nobody remembers.
Tests: writing unit tests for existing code and finding edge cases.
Debugging: reading an error message and a stack trace together with the code and proposing a cause.
Migrations and refactoring: repetitive changes across many files, such as updating an API or renaming a concept.
Code review: a first pass over a pull request that points out likely bugs and inconsistencies before a person reviews it.
Prototypes: building a working first version of an idea in hours instead of days.

Building software by describing it in plain language and accepting the result largely unread became known as vibe coding, a term Andrej Karpathy used in early 2025. It works for prototypes and personal tools. For software other people depend on, the code still needs to be understood.

Where it fails

Plausible but wrong code. Generated code can look correct and still contain logic errors, especially at edge cases. The more convincing it looks, the easier it is to approve without reading.
Invented APIs and packages. Models sometimes call functions or import packages that do not exist. Attackers register such package names with malicious code, a practice called slopsquatting.
Security weaknesses. Generated code can repeat insecure patterns from its training data, such as missing input validation or secrets in code.
Missing context. The model does not know unwritten team conventions, the reasons behind past decisions, or the business rules nobody wrote down.
Large changes. The bigger the change, the harder it is to review, and the more likely that small errors slip through.

The effect on productivity

Productivity gains are real but uneven. Developers report large speedups for routine tasks, prototypes, and unfamiliar code. Controlled studies are more mixed. A 2025 study by the research group METR found that experienced open-source developers working on their own large projects were slower with AI tools, although they believed they were faster. Time saved on writing code can be spent again on prompting, waiting, and reviewing.

The gains tend to be largest when tasks are well defined, the codebase has good tests, and the developer can quickly judge whether the output is right.

Working well with AI

The habits that make AI-assisted development reliable are mostly good engineering habits:

Give context. Point the tool at the relevant files, describe the goal and constraints, and keep project conventions in a file the agent reads, such as AGENTS.md.
Work in small steps. A small, focused change is easier to check than a large one.
Let tests decide. A good test suite turns “looks right” into “is right”. Ask the agent to run the tests and to add new ones.
Read what you merge. You remain responsible for the code. Review AI-written code at least as carefully as a colleague’s.
Check dependencies. Verify that every new package exists, is maintained, and is the one you meant.
Limit permissions. Run agents in a sandbox or a separate environment, without production credentials, and approve commands that change systems.

How the role changes

AI shifts the work of a developer from typing code toward deciding what to build, describing it precisely, reviewing results, and designing systems that are easy to test and change. Knowledge of fundamentals matters more, not less, because judging generated code requires understanding it.

There are open questions. If junior developers let AI write most of their code, they may learn less. Teams have to decide how they review AI-written code, who is accountable for it, and how much autonomy agents get in their repositories.