What Engineers Contribute When AI Writes the Code

In my current workflow, agents write and modify almost all code. My work concentrates on the decisions around implementation: what outcome matters, which assumptions carry risk, what evidence would justify trust and what should be preserved for the next change.

The same model can produce very different results in the hands of two engineers. One delegates an ambiguous ticket, accepts a plausible implementation and relies on reviewers to find the gaps. Another clarifies the goal, exposes relevant context, challenges assumptions and makes the agent verify the result against realistic behavior.

AI makes differences in engineering agency and judgment more visible.

I use “high agency” and “low agency” to describe behavior, not permanent categories of people. The same engineer may show high agency in a familiar domain and low agency when blindly accepting unfamiliar output. Experience, context, access and team support all affect that behavior.

Agency is therefore both an individual skill and a team capability. Engineers can improve how they frame problems, test assumptions and evaluate evidence. Engineering leaders can create the context, incentives and feedback that make those behaviors teachable and sustainable rather than dependent on a few experienced individuals.

Same agent, different outcome #

Consider a request to add a CSV export for a customer-facing dataset.

A low-agency approach hands the request to an agent and accepts an endpoint that builds the entire file in memory. Unit tests with a small fixture pass and the implementation looks reasonable. Nobody establishes the expected data size, memory limit, permission behavior or what happens when a request times out and is retried.

A high-agency approach starts with the customer workflow and the constraints that affect the design. The engineer asks the agent to surface risky assumptions, inspect relevant patterns and test against representative data. The agent can compare direct streaming with a background export, profile memory use and exercise permission and retry behavior. The engineer decides which evidence matters, chooses the design and owns the remaining risk.

High agency allows broad delegation. It keeps direction and judgment with the engineer even when the agent performs the investigation, implementation and verification.

A practical spectrum of agency #

I see five useful levels in AI-assisted engineering:

Different tasks justify different depth. A small, reversible change that follows an established pattern does not need competing implementations and a benchmark. An irreversible migration, unfamiliar integration or concurrency-sensitive workflow deserves stronger evidence. Agency shows in choosing that depth deliberately.

The final level also depends on organizational support. In Building the Systems That Produce Software, I describe the context, safe system access and verification infrastructure that let engineers and agents work through this loop reliably.

What the engineer contributes #

In my workflow, agents can participate in every part of engineering work. I see human contribution concentrating in four areas.

Problem and domain judgment: The engineer connects a request to customer behavior, business constraints and the direction of the product. They resolve ambiguity, define useful non-goals and recognize when the requested implementation does not address the underlying problem.

Risk and evidence judgment: The engineer identifies assumptions that could make a plausible solution fail. They decide whether success requires a regression test, representative workflow, benchmark, failure simulation or evidence from a deployed environment. Tests and measurements can encode the wrong assumptions, so interpreting their relevance remains part of the decision.

System judgment: A locally correct implementation still has to fit architecture, data ownership, deployment behavior, security boundaries and operational constraints. The engineer considers reversibility and long-term consistency while the agent investigates those concerns in detail.

Learning and stewardship: Useful work leaves something behind. Engineers decide which regression tests, fixtures, instructions, runbooks and architecture decisions will help future changes. They also keep those assets current instead of allowing outdated context to mislead the next agent.

These decisions should become visible during review. From Code Review to Evidence Review describes how intent, assumptions and evidence can accompany a change so reviewers can spend their attention on judgment rather than reconstructing the work from code.

What becomes more differentiating #

This is my directional model based on personal observation, not a measured ranking:

Less differentiation does not mean less importance. Technical foundations set the limit of an engineer’s judgment. Evaluating locking semantics, query plans, migration safety or failure handling requires enough understanding to challenge the agent and recognize when its explanation is incomplete.

The visible output changes. Manually recalling an API or typing its integration matters less when an agent can retrieve and implement it. Knowing whether that API fits the system, how it fails and how to verify the integration still matters.

How engineers can develop agency #

This shift is not only relevant to senior engineers or managers. A mid-level engineer can develop these skills by taking ownership of a bounded problem-solving loop: clarify the desired outcome, identify the assumptions most likely to fail, define useful evidence before implementation and explain the final decision in terms of observed behavior.

The goal is not to delegate larger tasks as quickly as possible. It is to increase the scope an engineer can own without weakening their understanding of the system or the evidence behind a change. Repeated practice turns these decisions into engineering judgment, while preserving the resulting tests, fixtures and explanations makes that judgment available to the rest of the team.

Implications for engineering leaders #

Agentic development can let smaller teams own broader product scope. But treating that gain as a fixed staffing ratio makes it look more predictable than it is. Implementation capacity can increase much faster than product discovery, incident response, cross-team coordination, domain ownership and on-call resilience. A claim such as three engineers doing the work of ten only means something when the work, quality and operational load are defined.

Leaders can make the shift concrete in three places.

Hiring: Give candidates an ambiguous but realistic problem and access to an agent. Observe which questions they ask, which assumptions they make explicit, how they select evidence and whether they challenge plausible output. Prompt style matters less than the quality of the resulting decision.

Performance: Reward reliable outcomes, stronger verification, useful shared context and well-explained decisions. Code volume, ticket count and visible agent activity are weak signals when implementation is cheap.

Team design: Measure delivery time, escaped defects, operational load and breadth of sustainable ownership before changing team size. Preserve enough domain coverage and redundancy to handle incidents, review risky decisions and let people take time away.

Agency also depends on the environment leaders create. Engineers working in an unfamiliar system need current context, safe access to runtime evidence, usable verification and people who can challenge their assumptions. Leaders should give developing engineers opportunities to own complete but bounded problems and evaluate the quality of their reasoning, not only the speed of their output. Broad ownership should not become unlimited scope or reliance on individual heroes.

Engineering value moves toward decisions #

My observation is that implementation in my own workflow is already almost entirely automated. Agents write the code and can perform much of the investigation and verification around it.

My interpretation is that engineers increasingly create value by directing that capability: defining the right outcome, identifying dangerous assumptions, choosing relevant evidence, interpreting the results and preserving validated learning. Those activities keep delivery fast without allowing quality to depend on the agent’s first plausible answer.

My prediction is that access to capable models will become less important as a differentiator between teams. Performance will diverge based on how consistently engineers exercise agency and how well leaders support it. Strong engineering work will leave behind a sound decision, a verified outcome and a system better prepared for the next change.