What is AI Software Engineering?

AI software engineering is the discipline of building, evolving, and operating software systems when AI agents handle a meaningful share of the work — writing code, running tests, reviewing diffs, triaging bugs, generating documentation. It is the new craft of software engineering once agents are first-class collaborators, not just typing assistants.

It is not the same as an AI software developer (which is the agent itself — Claude Code, Devin, Cursor agent mode), and it is broader than agentic coding (the inner-loop activity of writing code with an agent). AI software engineering is the surrounding practice: how a team plans, builds, ships, and operates software when those agents are doing a real fraction of the engineering.

Three eras, each redefining what an engineer's day looks like:

The shift from era 2 to era 3 is the one worth naming carefully. In era 2 the engineer is still in the loop on every diff — Copilot proposes, the engineer accepts or edits. In era 3 the engineer is in the loop on the task: they write a spec, an agent attempts the task end-to-end, and the engineer reviews the resulting commit. The agent's loop runs without supervision; the engineer's loop is at the task boundary.

That is a different job. It looks less like typing and more like reviewing pull requests, writing requirements that survive contact with a literal-minded executor, and operating the system that the agents work in.

A unit of AI software engineering work now moves through four phases, and each one is a first-class artifact you can review independently:

The phase that changes the most is Intent. In traditional engineering, the spec lived in someone's head or in a half-written ticket; the real specification was the code itself, written iteratively. With an agent in the loop, the spec has to be explicit enough that a literal-minded executor can act on it without you sitting next to them. Acceptance criteria become tests; success conditions become evals. Engineering teams that adopt AI software engineering quickly discover that writing good intent is the rate-limiting step, not writing code.

The phase that gets more attention, not less, is Review. An agent will produce a working-looking diff in minutes. Whether that diff is correct, scoped, secure, and aligned with the codebase's conventions is now the question. Review is no longer the cheap step at the end; it is the moment where most of the human judgment happens.

Six practices distinguish AI software engineering from traditional or merely AI-assisted engineering. None of them are optional once agents are doing real work; teams that skip them tend to ship faster for a quarter, then accumulate enough untraceable agent-generated code that velocity collapses.

The thread running through all six is the same: when an agent is producing artifacts, the things around the artifact — the spec, the eval, the context, the log, the review, the boundary — have to be more rigorous than they were when a human typed every line. The agent's productivity is real, but its accountability is not free; you build it.

A working AI software engineering stack has four layers. Most teams start with one or two and add the rest as the pain becomes visible.

• Agent runtimes — the agents themselves. Claude Code, Cursor agent mode, Devin, Codex CLI, Aider. Each has different defaults for tool access, autonomy, and where the loop runs (your laptop, your repo, a hosted VM).
• LLM gateway — the proxy in front of every model call. Centralized auth, rate limits, cost attribution, prompt and response logging, content filtering. The first governance layer most teams add.
• Work and context system — where tasks live, where context lives, where the audit trail lives. Tracked work items, durable project context, per-task worktrees, structured execution logs. This is where decisions about who-did-what get answered.
• Evaluation and observability — how you know whether the agent is getting better or worse over time. Eval suites for the kinds of tasks you give agents, dashboards for agent activity, and alerting when an agent's success rate slips.

The exact products you pick matter less than that every layer has an owner. The most common failure mode is a team adopting an agent runtime without an LLM gateway, a context system, or an evaluation discipline — at which point the agent's productivity becomes the team's untraceable technical debt.

The job descriptions on an AI software engineering team shift in three ways. None of them retire the engineer; all of them change what the engineer spends time on.

Two patterns to avoid. First: appointing an "AI lead" who is the only person allowed to use agents — this concentrates the productivity in one person and recreates the bottleneck the team was trying to remove. Second: declaring that every engineer should "just use AI" with no shared evals, contexts, or governance — this distributes the productivity but also distributes the failure modes.

AI software engineering puts pressure on five governance questions that pre-AI engineering could mostly handle implicitly:

• Attribution — who (or what) wrote which line of code, when, with which model. Required for IP, licensing, and incident response. Implicit in pre-AI engineering because a commit = a human; explicit and audited now.
• Authorization — what an agent is allowed to do unsupervised. Maximum diff size, file allowlists, no migrations, no production credentials. Lifted as track record warrants it.
• Data flow — what code, secrets, and customer data the agent saw, and whether the model provider retains any of it. Affects regulated industries the most; matters everywhere as an IP question.
• Reproducibility — given a spec, a model version, and a context bundle, can you re-run the task and get a comparable result? Critical for compliance audits.
• Reversibility — when an agent makes a bad change, how fast and cleanly can the team back it out. Worktree isolation and per-task branches buy you almost all of this for free.

The compliance frameworks that already apply — SOC 2, ISO 27001, GDPR, HIPAA in regulated sectors — have not added "AI software engineering" as a section, but their existing controls (access logging, change management, data classification) all bind to it. The work is mostly mapping existing requirements onto the new artifacts, not inventing a new compliance posture from scratch.

Teams that successfully move into AI software engineering tend to follow a similar arc, even when they didn't plan it:

1. Pilot — one engineer, one agent, one repo. They learn what the agent is good at and what it ruins. This phase is mostly about calibration and is best done with no organizational pressure.
2. Adopt — a handful of engineers using one or two agents on bounded task types (bug fixes, tests, refactors). Governance is bolted on: an LLM gateway, a tracked work-item system, per-task branches.
3. Standardize — the practices that worked become defaults. Specs are written in a shared format. Evals exist for the major task types. The team's onboarding doc explains the agent stack alongside the codebase.
4. Mainstream — agents are part of the normal workflow for most engineering work. The questions become organizational: which teams are getting good leverage, which are not, and what is the gap.

The mistake worth flagging is skipping adopt and jumping from pilot straight to standardize. Standardization requires evidence of what works; pilots produce stories, not evidence. Teams that mandate agent-based development before they have a track record tend to mandate the wrong things.

Five failure modes show up repeatedly. They are not specific to one agent or one stack; they are properties of the practice itself.

Most of what makes AI software engineering hard is not picking the right agent. It is building the surrounding infrastructure: the work-item system, the durable context, the audit trail, the worktree isolation, the human-review gate. That infrastructure is what turns "we let an engineer use Claude Code" into "we operate AI software engineering as a discipline."