How do developers use AI to write software?

How do developers use AI to write software?

Developers use AI through tools that sit beside the code while they work: autocomplete that suggests the next lines, chat that answers questions about the codebase, and agents that plan and make changes across many files while a developer reviews the result. By 2026 nearly every professional developer works this way. The tools changed how fast code gets written, and they changed what a developer spends the day doing, because reviewing and directing machine-produced work is now a large share of the job.

That shift is why this module exists. A resume written in 2026 names these tools, a candidate describing their week describes working with them, and an engineering team explaining its process explains where the machines stop and the people begin. Each of those conversations goes better with the vocabulary in place.

Earlier modules covered how software gets built and what the AI words mean. This module joins the two: the same models that power chat products now sit inside the daily workflow of an engineering team. The lessons ahead cover the tools by name, how much an agent does without a person watching, what feeds an agent, what the automated reviewer catches, and how AI-shaped work reads in a codebase. This guide walks the same ground once, in order, and links each lesson where it goes deep.

What are the AI coding tools, and how do they differ?

Three names cover most of what appears on resumes: Cursor, GitHub Copilot, and Claude Code. Cursor is a code editor with AI built through it. GitHub Copilot plugs into an editor the developer already uses, and it launched in 2021 as autocomplete before growing chat and agent modes. Claude Code runs in the terminal, the text window developers type commands into, and works as an agent on a whole project. Each one wraps a model made by an AI lab; the tool and the model carry similar names while being different things, which is why Claude and Claude Code appear side by side and mean a model and a tool built on it.

All three sit on the same shelf as the editor in the shelves sense: a developer uses them while writing code, and none of them ships inside the product. That placement carries a hiring fact. A framework choice binds a codebase for years, while a tool choice binds a developer for about a week, so the tool name on a resume describes a preference. Switching between these tools takes days. The full landscape, including vibe coding, the practice of accepting AI output without reading it closely, lives in What are Cursor, Copilot, and Claude Code?

How much does a coding agent do on its own?

A coding agent is the step past autocomplete: a tool that plans a change across many files, edits them, runs the code, reads what happened, and adjusts. How much it does alone runs on a ladder. At the bottom, autocomplete suggests a line and the developer accepts or ignores it. In the middle, a supervised agent works while the developer watches, approving each meaningful step. At the top, a background agent takes a ticket, works unattended, and returns a finished change as a pull request for review.

The place where a person approves the work is called human in the loop, and teams position that checkpoint by what a mistake would cost. A first draft of a test can be generated freely. A change to a payment system keeps a person on every step. One consequence matters for reading a team: when several background agents run at once, review becomes the limit on how fast the team ships, and the engineers spend their day specifying tasks and judging results. The same tool serves every rung, so the rung a developer works at says more about their work than the tool name does. The ladder gets its own lesson in What is a coding agent, and how much does it do on its own?

What are context, skills, and MCP servers?

An agent is only as good as what it can see and touch, and three words describe that supply line. Context is everything the model is shown before it works: the relevant code, the instructions, the results of earlier steps. A model knows nothing outside its context window, and stuffing that window makes answers worse and costs more, so choosing what to include and what to leave out is a craft. Developers call the craft context engineering, and during 2025 the phrase largely replaced prompt engineering.

A skill is a packaged set of written instructions an agent loads for a certain kind of task, such as how this team deploys. Skills are text files stored with the project, so they get reviewed and versioned like code. An MCP server is the socket between an agent and a real system. MCP, the Model Context Protocol, is an open standard Anthropic introduced in November 2024 that gives any agent one common way to reach outside tools: a database, a browser, a calendar, a ticket tracker. Before it, every agent-to-tool connection was custom work rebuilt per pairing. An MCP server contains no model. It is plumbing built with ordinary backend skills, part of the new plumbing around models, and any MCP experience on a resume dates from late 2024 at the earliest. All three terms get their full treatment in What do developers mean by context, skills, and MCP servers?

Can AI review code?

Yes, for part of the job. AI code review reads a pull request and comments on it before a person does, and what it catches is consistent: known bug patterns, style drift, and a real share of common security mistakes. What it misses is also consistent: whether the change was the right thing to build, whether the design will hold as the codebase grows, and security holes nobody has documented before. The pattern follows from what a model is. It has seen millions of past mistakes and none of this team's future.

It helps to keep three jobs separate here, because they blur in conversation. Security review looks for ways the change could be attacked. Debugging finds why a live system is misbehaving. Architecture review judges whether the design will survive the next year of changes. Automation has moved furthest into the first job and least into the third.

So teams run the automated reviewer as a first pass and keep people on architecture, intent, and product judgment. That split is useful when a candidate describes their team, because a team that names its automated layer has also described what its human reviewers own. Code review itself, the practice of a teammate reading a change before it merges, came up in from laptop to customer; the automated version and its limits are the subject of Can AI review code, and should it be the only reviewer?

Does AI-written code look different?

Often, yes. Heavy AI assistance leaves traces: comments that restate what the code plainly does, boilerplate repeated across unrelated files, large commits of uniform size and phrasing, and tests that mirror the code instead of challenging it. A developer who edits carefully removes most of these, and a hurried one leaves them in.

The same caution applies to the phrase AI-assisted on a resume. Nearly every professional developer used the tools by 2026, so the phrase describes the era rather than the person, the way "uses email" would have in 2005. The signal moved into the judgment visible in the output. There is also a live argument about whether the tools erode skill, with serious engineers on both sides, and the honest state of that argument sits in Does AI-written code look different, and can you tell?

Will AI replace software developers?

It has not, and the shape of what changed explains why. AI compressed the writing of code, and writing code was never most of the job. Deciding what to build, debugging live systems, and judging what the tools produce did not compress. Junior-shaped work compressed first, because a well-specified task with a known answer is what the tools do best, and that shifted what teams look for rather than shrinking the field to zero. Some companies cut engineering headcount and others hired more, and the difference tracks how much work each had queued.

Reviewing what an agent produced requires knowing what good looks like, which raised the value of judgment and lowered the value of typing speed. The gap between lab claims and team experience, covered in is AI overhyped, runs through this question too: labs describe the best case on a clean problem, and shipping teams describe the average case in a codebase with ten years of history. The full argument, including which tasks compressed and what a developer still owns, closes the module in Will AI replace software developers?

Read the six lessons in order and the module's promise holds: you can name the tools and tell them apart, place agent work on its ladder, say what feeds an agent, say what the automated reviewer catches and misses, read the traces in a codebase for what they are, and give an honest answer to the replacement question.