AI Works Best When Engineers Lead

A developer asks an AI agent to implement a change. Minutes later, it produces a coherent-looking diff and the tests pass. It is an impressive result. It is not a finished act of engineering.

Someone still has to decide whether the change solves the right problem, whether the tests prove enough, whose needs were missed, which risks are acceptable, and what to do when the software meets the world. Those are not chores left over after the agent has done the important work. They are the important work.

Leaders often answer with one of two slogans. “AI will replace people who do not use AI” treats fear as a performance problem. “AI is just another tool” understates a real shift in how software gets made. Neither answer helps someone asking a reasonable question: If it can do that, what exactly am I here for?

The answer is not that humans must race machines at producing text. Engineers are here to understand people’s needs, turn ambiguity into choices, bring experience to unfamiliar situations, notice when the premise is wrong, and take responsibility for consequences. AI can extend that work. It cannot care whether the work was worth doing or stand beside the people affected by it.

The purpose of AI in engineering is to extend human agency, not to erase the human from the work.

Fluent output is not human understanding

An AI agent generates a response by predicting what should come next from statistical relationships learned during training and from the context we give it. The sophistication and usefulness of that process are real. So is its derivative nature in this specific sense: its output depends on prior material. It does not arise from firsthand experience, an intention to help, or a stake in the result.

Fluency can make the distinction easy to forget. An agent can write an empathetic explanation without caring about the reader. It can propose a tradeoff without bearing either consequence. It can produce a confident plan without wanting the outcome or knowing a colleague will be paged if it fails. Whether or not we call that behavior intelligent, it is not human responsibility.

That is why the engineer does not become less valuable as the output becomes more convincing. The more an agent can produce, the more important it is to have a person who can choose a direction, challenge the result, connect it to lived needs, and own what happens next.

Begin with human purpose

Start with a need, not with the availability of a tool. What is difficult for people today? Which part of that difficulty is valuable learning or judgment? Which part is repetition, waiting, or translation that an agent might reduce? Who benefits if the workflow changes, and who takes on new risk?

People, process, tools—in that order—is a useful discipline here. Engineering has absorbed many changes in how software is designed, built, tested, and operated. Some transformed the industry; others improved one part of the work. The durable lesson is that a tool does not supply a purpose or create a healthy way of working. People decide what matters. They shape a process that makes responsibility and feedback clear. Then they choose tools that support it.

The order does not mean delaying useful technology until every process is perfect. It means judging the technology by how well it serves people and the work. If an AI agent makes an unhealthy process move faster, the result is a faster unhealthy process. If it obscures ownership, weakens learning, or shifts risk onto people who had no voice in the decision, its apparent efficiency is not a success.

A developer may use AI to understand an unfamiliar module. A team may use it for tests and routine maintenance. An organization handling sensitive data may require additional review before generated code can enter a repository. In each case, the people doing and receiving the work should help set the boundaries. They know where the friction lives and what a plausible-looking mistake would cost.

Look for work where assistance could remove effort without concealing important decisions. Examples include:

• small API maintenance changes
• test fixture and migration scaffolding
• routine dependency updates
• internal documentation backed by reviewed code
• bounded refactors with strong existing tests

Use more care around an authorization redesign, destructive data migration, or a new system whose requirements are still disputed. In those cases, the cost of a plausible but wrong answer is high, and the important work is often deciding what should happen rather than producing code.

Before changing a workflow, agree on what you hope will improve and what must not get worse. Use evidence the team already relies on, such as:

• time from accepted work to verified production behavior
• review time and change size
• defects, rollbacks, and support load
• time spent on setup or repetitive edits
• developer confidence in explaining and changing the result
• opportunities for pairing, design work, and deliberate practice

Do not turn this list into a dashboard for judging individuals. These signals help a team examine a workflow. They need context: slower delivery may be worthwhile while people improve weak tests, and a faster merge is not an improvement if it produces more support work or leaves nobody confident changing the result.

In a 2025 randomized study, METR found experienced open-source developers took 19 percent longer on the tasks studied with early-2025 AI tools, while the developers believed they had moved faster. That result does not predict what will happen on every team or with later tools. It is a useful warning that perceived speed and observed results can differ. Ask what changed in the work instead of assuming that AI use is automatically a gain.

Keep decisions with the people who own the consequences

“Human in the loop” is too vague. A person approving every command may add friction without exercising meaningful judgment. What matters is human direction and ownership: a named person understands the goal, can challenge the approach, has the authority to stop, and remains responsible for the result. An agent can assist that person; it cannot accept accountability in their place.

For any AI-assisted workflow, write down who does what and how the result will be checked:

The categories are not permanent. Tools and safeguards will improve. But increasing automation does not transfer responsibility to the system. When a decision affects safety, rights, livelihoods, private information, or changes that are hard to reverse, people should have more authority and better information, not merely a final approval button.

Match human care to the consequences

Human direction belongs in every AI-assisted workflow, but it does not need to look identical in every workflow. Requiring the same ceremony for a local test fixture and a production authorization change wastes attention that should be concentrated where it matters most.

Choose the level of review and control by asking concrete questions:

• How many people could be affected, and how seriously?
• Can the result be reversed quickly and completely?
• Will a mistake be visible before it causes harm?
• Does the work touch private data, money, access, safety, or people’s rights?
• How well do we understand the problem, the system, and the agent’s likely failure modes?

A small, reversible change in a well-tested area may need an engineer to inspect the diff and run the established checks. A customer-facing change with a wider blast radius may need peer review, staged release, monitoring, and a tested rollback. Work involving security boundaries, sensitive data, financial consequences, safety, or people’s rights may also require an accountable domain owner, independent review, explicit authorization, and a safe fallback before the system acts.

These are not levels of permission granted to the agent. They are levels of care chosen by people. At every level, a human sets the intent and the acceptable boundaries. As consequences grow or errors become harder to detect and reverse, human scrutiny, expertise, and authority should grow with them.

Responsibility also includes how the tool is used. Give people short, usable answers to questions they will encounter during the work:

• Which source code, customer information, credentials, and incident data may be sent to the tool?
• Which tools and account settings has the organization approved, and what do they retain?
• When must generated work receive peer, security, legal, or product review?
• How should someone record or disclose AI assistance when its origin matters?
• Where can a person report a bad result or an unsafe workflow without being blamed for finding it?

A policy nobody can apply during an ordinary workday is not much protection. Build these rules with security, legal, product, and engineering input, explain the reason for each boundary, and give people a clear place to ask when the rule does not fit the situation.

Build the harness around human intent

The emerging practice of harness engineering gives teams a useful way to think about everything surrounding the model. In Birgitta Böckeler’s framing, a coding agent is not just a model. Its outer harness includes the instructions, tools, constraints, and feedback that help it work within a particular codebase.

The harness provides guidance before the agent acts and feedback after it acts. Repository conventions, architectural guidance, examples, and task-specific instructions can point it in a better direction. Tests, type checks, linters, structural rules, browser checks, and production telemetry can expose mistakes and allow another attempt before a person reviews the work. When a failure repeats, engineers can improve the guidance or add a check so the system learns from the failure operationally, even though the model itself has not acquired human experience.

This is good engineering. It turns expectations that may exist only in an experienced developer’s head into shared, executable knowledge. It can reduce repetitive review and make useful autonomy safer. It can also improve the development environment for humans: clear boundaries, fast tests, helpful errors, and current documentation benefit everyone who works in the codebase.

But a harness can only regulate what people have made visible enough to guide or sense. A type checker can reject an invalid type. A structural test can protect a module boundary. Neither can tell us that we solved the wrong customer problem. An AI reviewer may notice semantic concerns that deterministic checks cannot, but it remains another probabilistic system, not independent human judgment. Green tests written alongside generated code do not prove that the requirements were right or complete.

Harnesses are also uneven. A well-structured codebase with explicit boundaries and fast, reliable tests offers strong signals. A legacy system with hidden assumptions and weak feedback offers far fewer. That is often where assistance is most attractive and confidence is hardest to earn. More agent activity does not repair that gap by itself.

Treat the harness as a first-class engineering system:

• give its instructions, checks, tools, and permissions clear human owners
• prefer fast, deterministic checks where they can express the requirement
• test and review changes to the harness instead of letting it grow invisibly
• scope credentials and tool permissions to the work the agent is allowed to perform
• turn recurring failures into better guidance, checks, architecture, or process
• examine whether a passing result is actually valuable, maintainable, and safe

This returns us to people, process, and tools. People define the desired state and the consequences that matter. Process makes those intentions reviewable and turns failures into learning. Tools help execute and enforce what can be expressed. The harness strengthens that arrangement; it should not invert it.

As risk increases, do not rely only on a larger stack of automated or AI-based checks. Add the independent evidence, domain expertise, human review, and authority appropriate to the consequence. The purpose of a strong harness is not to push people out of the system. It is to focus human attention where human judgment contributes the most.

Use new capacity to strengthen people and the system

Do not assume that using AI saves time. Sometimes it does; sometimes prompting, checking, and correcting the result costs more than doing the work directly. When the team does gain capacity, turning every minute into a higher delivery expectation tells engineers that the reward for becoming more capable is more pressure. It also leaves little room to learn or make the system safer.

Use some of that capacity for work that delivery pressure usually squeezes out:

• faster and more focused tests
• clearer repository boundaries
• reproducible local environments
• useful telemetry and failure injection
• smaller reviewable changes
• current examples and runbooks
• security and dependency maintenance

This is part of making AI-assisted work dependable, not a perk offered in exchange for higher output. DORA’s 2025 research on AI-assisted development describes AI as an amplifier of the surrounding organization. The practical implication is straightforward: generated output is easier to trust when people have fast feedback, clear boundaries, and reliable ways to test and release it. Weak feedback makes errors harder to see, regardless of who or what wrote the code.

Protect the craft of becoming an engineer

Engineering judgment is earned through work that resists us: tracing a request, debugging a failure, choosing between imperfect designs, and seeing what happens in production. This is especially important for people who have not yet encountered the same pattern many times. If an agent handles every hard part, it can remove the experience that would have taught the lesson.

Simply banning AI does not create those learning experiences. Give developers work that uses the tool and still requires understanding:

1. Predict two failure modes before asking the agent to implement anything.
2. Ask for two designs, then choose one and explain the tradeoff to a peer.
3. Review a plausible implementation with a planted flaw.
4. Write acceptance examples before generating the code.
5. Diagnose a failing test or staged incident without asking the creating agent for the answer.
6. Remove an unnecessary abstraction from a generated change.

Experienced engineers can help by making their reasoning visible. Pair on problem framing. Explain why one boundary matters and another does not. Ask a developing engineer to lead the walkthrough instead of presenting the answer yourself. This takes time, and leaders need to treat that time as part of delivery rather than invisible extra work.

Ownership is not typing every line. It is being able to explain, challenge, operate, and improve the change.

Learn from real changes

Talk regularly with the people doing the work and the people affected by it. A team making frequent AI-assisted changes may need a weekly conversation. Occasional users may only need to reflect after a meaningful change or incident. The point is to look at actual work while people still remember what happened, not to satisfy a fixed ceremony.

Ask five questions:

1. Where did the agent reduce drudgery without reducing anyone’s understanding?
2. Where did it hide an assumption or increase review effort?
3. Which check gave us real confidence?
4. Did anyone become less able to explain or change the system?
5. What should we change in the environment before increasing autonomy?

Commits, generated lines, closed tickets, and documentation volume are weak measures because an agent can produce them in quantity. Pay attention to verified outcomes, review burden, escaped defects, recovery, and shared ownership.

Use what you learn to make an honest adjustment:

• use AI for more of this kind of work because outcomes and ownership improved
• keep the current boundary while the team strengthens feedback and guidance
• narrow the use case because review or support cost increased
• stop using it for this work because it does not help under the current conditions

Stopping one use case is not rejecting AI. It is a responsible response to what people learned.

AI works best when engineers lead

Developers may reasonably worry about being responsible for more code while understanding less of it, or wonder whether every gain will become a higher quota. Do not dismiss those concerns as resistance to change. They are questions about dignity, workload, competence, and accountability that the organization has to answer through its decisions.

The way through is practical. Show where human decisions matter. Protect time to learn. Measure the whole delivery system. Improve the environment. Increase autonomy only when the team can still own the result.

People should not have to prove their worth by competing with AI at generating output. An engineer’s value is not the number of keystrokes an agent can imitate. It is the human ability to understand needs, set purpose, recognize bad assumptions, weigh consequences, create with others, teach, care, and take responsibility for what the software does.

Used well, AI gives engineers more reach. It can help us explore, explain, automate, and build. But the responsible use of that power begins and ends with people: people decide what deserves to be built, people direct the work, people judge the result, and people remain answerable to one another.

That is not a temporary limitation to overcome. It is the reason engineering matters.