How Software Engineering Changes in the Age of AI Agents

Ask an AI agent to “add audit logging to the existing API.” Minutes later, it has changed several files and added tests. Work that once took half a day is already waiting for review.

Then you open the diff and realize the job is not finished. Could the logs contain personal data? Are failures recorded? Will retries create duplicate entries? Is the change backward-compatible with existing clients? Why was this design chosen in the first place?

When implementation becomes automated, what remains for the software engineer?

The answer is not merely “writing prompts.” AI agents reduce implementation costs, but they do not remove responsibility for building the right software correctly. The center of value shifts from entering code to deciding what should be built, what must remain true, and what evidence is sufficient to call the result correct.

AI First Reduces the Cost of Implementation

AI agents can accelerate boilerplate, changes that follow an established pattern, mechanical edits across files, first drafts of tests, API research, and proposed fixes derived from error messages. Modern coding agents can inspect repositories, edit files, and run commands and tests, as described in the official documentation from OpenAI and GitHub.

But software delivery consists of much more than implementation.

Problem discovery
→ Requirements
→ Constraints
→ Design
→ Implementation
→ Review
→ Testing
→ Release
→ Observability
→ Improvement

AI compresses the middle of this flow most strongly: implementation and some adjacent research and test creation. If requirements are ambiguous, an agent does not eliminate that ambiguity; it fills the gaps with assumptions. If review and verification cannot keep up, faster generation simply creates a larger queue of unreviewed changes. If release and observability practices are weak, the team may only ship defects faster.

That is why “time to generate a change” and “time to deliver value safely to users” must be treated as different measures. Local implementation speed can improve while the bottleneck moves to requirement clarification, review, test environments, approval, or deployment. The delivery system does not become equally fast just because one stage does.

From “How Much Code?” to “Which Decisions?”

Writing code has historically been expensive. The ability to implement complex behavior accurately under time pressure had obvious scarcity value. As generation becomes cheaper, however, code volume becomes an even weaker proxy for outcomes.

Cheap generation makes it easier to produce unnecessary abstractions, duplicate implementations, oversized changes, and code that conflicts with the system’s existing design. An agent may create code that works in the happy path without accounting for operational failure, migration, compatibility, or ownership. The dangerous outcome is a change nobody can explain, accepted solely because its tests passed.

Engineering value therefore moves toward decisions such as:

• Separating the problem worth solving from work that is out of scope
• Limiting the blast radius of a change
• Making preserved behavior and nonfunctional requirements explicit
• Choosing and explaining design tradeoffs
• Finding failure paths in generated diffs
• Producing evidence that the change is safe in production

This does not make implementation skill worthless. If you cannot understand the code, you cannot judge the diff or verify the explanation behind it. What changes is the unit of value: less emphasis on typing volume, more on turning technical knowledge into sound decisions.

Critical Work 1: Designing Constraints

An instruction to an AI agent looks like a natural-language task, but production work should treat it as a small specification and a set of guardrails. It should define not only what to build, but also what must not change, which properties must be preserved, and what completion means.

For example, a request to fix payment webhook handling might look like this:

Goal:
Finalize an order exactly once even if the same event is delivered multiple times.

Constraints:
- Do not change the public API or database schema
- Do not add external dependencies
- Use the existing authentication and authorization path
- Preserve idempotency under concurrency and after retries
- Do not write sensitive data to logs
- Explain the need before changing anything outside the webhook module

Completion criteria:
- Test duplicates, reversed delivery order, and redelivery after timeout
- Pass the regression suite, type checks, and static analysis
- Explain the chosen design and any remaining risks

The value here is not clever phrasing. It is the conversion of an ambiguous request into observable, testable properties.

In human teams, an experienced engineer may remember a previous incident or an informal agreement and silently infer that a certain area must not be touched. An agent does not know facts that are absent from its repository and input. It can return a plausible implementation for an underspecified request, but plausibility is not evidence of correct understanding.

Engineers will increasingly need to translate requirements not only into code, but into invariants, boundaries, failure behavior, and acceptance criteria. A good prompt is not a magic incantation. It is good engineering judgment made explicit.

Critical Work 2: Building Useful Context

The same model can produce very different results depending on what it can learn about the system. In an environment where the agent must repeatedly guess, teams spend their time correcting its output. What looks like a model-performance problem is often an organizational-knowledge access problem.

Useful context includes:

• System architecture and module responsibilities
• Coding conventions and representative implementation patterns
• Commands for builds, tests, type checks, and static analysis
• Definitions of domain terms, APIs, and data models
• Architectural decisions and reasons alternatives were rejected
• Known constraints, technical debt, and protected areas
• Deployment, rollback, and incident-recovery procedures

READMEs, architecture decision records, tests, code comments, and agent instruction files become both human documentation and machine-usable organizational memory. More documentation is not automatically better, however. Stale guidance can produce confident mistakes. Teams need owners, update triggers, and a clear source of truth; whenever possible, executable knowledge should also be encoded in tests and automated policies.

For example, “user deletion must always create an audit record” should not live only in a design document. It can also become an acceptance test. When the explanation an agent reads matches the rule CI enforces, the team depends less on oral history.

Context work is not documentation busywork. It is infrastructure that lowers the cost of future changes. Once established, it can be reused by the entire team, new hires, and multiple agents—not just by one experienced engineer.

Critical Work 3: Reviewing Assumptions, Not Just Code

Reviewing AI-generated code for syntax, naming, and formatting is not enough. An agent infers missing information and then hardens those assumptions into code. The central review target is the set of premises under which the diff would be correct.

Start by asking for a summary of the change, its design rationale, alternatives considered, and unresolved risks. Then inspect questions such as:

• Has the requirement been interpreted too narrowly or too broadly?
• Does the implementation handle failure, timeout, and partial success?
• Does it violate existing responsibility or trust boundaries?
• Is the diff larger than necessary?
• Did it remove apparently redundant behavior without learning why it existed?
• Can concurrency, duplication, reordering, or retries create inconsistent state?
• Could logs or exceptions expose sensitive data?
• Does the implementation rely on real library and API behavior?

Suppose an agent adds logic to send a notification after saving data. The code may look clean, yet notifying before the transaction commits can announce data that never becomes durable. Sending synchronously after commit may instead make a notification outage fail the user’s request. The important questions concern the consistency model, retry strategy, and ownership of failure—not variable names.

GitHub explicitly warns that coding-agent output can contain mistakes or vulnerabilities and should be reviewed and tested by humans. As its responsible-use documentation for Copilot Agents makes clear, confident output and correct output are not the same.

As more code can be generated in less time, reading skill becomes more valuable. Programming and design knowledge are needed not only to author every line, but to audit a high density of technical decisions.

Critical Work 4: Verifying “Correct,” Not Merely “Working”

An agent can run tests after implementation and report that they passed. A passing test suite is useful evidence, but it is only part of the case for correctness. When the same agent writes both the implementation and its tests, the same misunderstanding can enter both, producing code and tests that agree with each other but not with the actual requirement.

The evidence should be designed before implementation begins. Depending on risk, it may include:

• Tests derived independently from acceptance criteria
• Boundary, failure, authorization, duplicate, and concurrency cases
• Regression tests for existing behavior
• Type checks, static analysis, dependency checks, and vulnerability scanning
• Performance comparison and, where justified, load testing
• Integration checks in a production-like environment
• Canary or progressive delivery
• Metrics, logs, traces, and alerts
• Confirmed rollback and data-repair procedures

Not every change needs the maximum verification burden. The key is proportionality. A copy edit and an authorization change should not require the same evidence. Changes involving data loss, privilege escalation, billing, or irreversible migration deserve stronger independent tests, progressive rollout, and human approval.

Also verify more than the phrase “tests passed.” Record which commands ran, in which environment, with what result, and what was not run. If an external service or credential was unavailable to the agent, that surface remains unverified. Separating success from unknowns is the beginning of accountability.

The question is not how many tests AI wrote. It is: what evidence would justify shipping this change? Designing verifiability up front lets teams judge output through reproducible results instead of fluency or intuition.

Rebuilding the Development Flow Around AI Agents

AI adoption should not stop at inserting a tool into the implementation stage of an existing process. Teams need a repeatable loop in which findings from research, implementation, verification, and operations improve the next input.

1. Define the problem to solve
2. State the change boundary and constraints
3. Decide completion criteria and verification methods first
4. Have the agent investigate; review its plan and assumptions
5. Implement in small, reviewable increments
6. Review the diff, rationale, and unresolved risks
7. Run independent automated checks and human review
8. Release progressively and observe production outcomes
9. Feed new knowledge back into documentation, tests, and rules

Small, verifiable increments expose misunderstandings earlier and are easier to revert than a single oversized request. During investigation, ask the agent to identify existing patterns and affected areas, then challenge its assumptions before implementation. Afterward, do not rely only on the agent’s own explanation; connect the work to CI, independent review, and production signals.

The engineer’s role expands from manually entering every line to designing an environment in which agents can iterate safely. Humans do not give up responsibility. They encode it into constraints, permissions, checks, approvals, and observability.

Evaluation Must Shift from Output Volume to Safe Outcomes

Treating commits, changed lines, feature counts, or coding hours as primary productivity measures can reward the creation of unnecessary code. As generation becomes cheaper, volume metrics drift further away from value.

More useful questions include:

• Did the engineer reduce requirement ambiguity or major risk before implementation?
• Did lead time improve without increasing incidents or regressions?
• Is the change observable and safely reversible?
• Are test and verification results reproducible?
• Are documentation, environments, and rules reused across the team?
• Did the work reduce agent rework and human review burden?
• Did it increase the team’s safe delivery capacity, not just one person’s output?

This balance between speed, failed changes, and recovery aligns with DORA’s software delivery performance metrics. These measures should not become one mechanical ranking score, however. Optimizing only for fewer incidents can make “never release” look ideal. Teams need a balanced view of speed, quality, recoverability, and learning.

Recognition will move away from the person who alone types fastest and toward the person who helps the whole team—and its agents—move quickly without losing control.

Coding Skill Is Not Disappearing; Its Purpose Is Changing

AI agents will reduce the time engineers spend manually writing code. That does not make programming, databases, networking, distributed systems, or security knowledge obsolete. Without those foundations, an engineer cannot evaluate an agent’s assumptions, race conditions, privilege boundaries, or failure behavior.

Junior engineers should not skip the fundamentals. Writing small programs, using a debugger, reading SQL execution plans, and tracing network failures build the mental models needed to diagnose generated systems. Experienced engineers, meanwhile, must move beyond “I can write it faster myself” and convert tacit knowledge into constraints, documentation, tests, and observability.

The strongest engineer in the age of AI agents is not the person who writes the most code. It is the person who defines what should be built, establishes what must remain true, verifies the generated result, and can deliver it to production with confidence.