Engineering with AI in 2026: practical disciplines that still matter

The practical difficulty in engineering with AI is often knowing what the tool has actually established. An agent can read source, modify several layers, produce a convincing interface and report success. Each of those actions is useful. None, on its own, proves that the intended system works.

My approach is to make the important boundaries explicit: the state of the repository, the meaning of the requirement, the authority granted to the tool and the evidence needed to accept the result. Those boundaries are familiar engineering concerns. AI makes them easier to overlook because so much activity can happen between two human reviews.

The following disciplines form a working method for 2026.

1. Establish the baseline before accepting the narrative

An earlier conversation, task brief or handover may describe a repository state that has since changed. Check the actual branch, revision, uncommitted work and running environment before deciding what remains to be done.

This matters when several sessions touch the same project. A correct instruction against yesterday's baseline can be wrong against today's files. An agent should recognise existing changes and incorporate them without silently discarding work it did not create.

The same principle applies to product documentation. For version-sensitive APIs, inspect the installed package and the relevant official documentation. A fluent answer from memory can be technically outdated while sounding entirely current. Record the version when it affects a design decision or verification result.

2. Give the tool the outcome and the limits

State the user-visible behaviour, constraints and completion evidence. Specify the decisions already made and those open to proposal. That lets the agent make routine implementation choices without repeatedly asking about details that do not change the outcome.

A useful task might describe how a user selects, processes and verifies a work item, including error handling and persistence. It should also identify the existing behaviour that must survive. “Make it production-ready” leaves too much room for incompatible interpretations.

The acceptance-contract article develops that method in detail. In daily use, the practical lesson is to spend the first few minutes removing consequential ambiguity. That is often a better investment than asking the agent to generate more code and hoping review will settle the requirement later.

3. Work in complete, reviewable increments

Choose an increment that demonstrates useful behaviour across the necessary layers. Avoid accumulating disconnected pieces that all pass local checks but have never been exercised together.

A complete increment can include interface, API and persistence changes. Its size should be limited by the engineer's ability to understand the result and verify its boundaries, rather than by how quickly the model can edit files.

When the scope changes, update the completion criteria and handover. Old descriptions can become misleading after several corrections. The final account should describe what now exists, including remaining limitations, rather than narrate an obsolete plan.

4. Verify the journey the user will take

Inspect the real interaction. Can the user find the action, understand the result and recover from an error? Does a refresh preserve the expected state? Does another authorised user see the correct result? Can an unauthorised user reach the underlying operation?

Passing unit tests should support that inspection, not replace it. A polished screenshot can hide a broken data path. A working backend can still present the result in a confusing or inaccessible interface.

Use a small number of deliberate end-to-end checks, with independent expected outcomes for consequential logic. Independent verification is particularly important when an agent has generated the implementation and its tests in the same session.

5. Keep permissions aligned with the task

An agent that only needs to edit and test locally should not inherit authority to change production. Review accessible credentials, network destinations and file paths separately from repository isolation.

Claude Code's security guidance describes permission controls, sandboxing and prompt-injection protections. Their practical value depends on the actual configuration. A reassuring tool name does not establish that a session is isolated or that a command cannot reach an external system.

Treat issue text, source comments and retrieved pages as evidence rather than unquestioned instructions. If they ask the agent to expand access, remove a check or transmit data, evaluate that action against the human-authorised task.

The goal is enough autonomy to complete understood work, with the authority for consequential actions remaining explicit. Constant prompts about routine edits can impede delivery; unrestricted authority can make an avoidable mistake much larger.

6. Make uncertainty visible in the handover

Ask for a clear distinction between observed results and inferred conclusions. “The build passed” is an observation. “The deployment is healthy” needs evidence from the deployment. “The feature is secure” is too broad unless its assurance scope is defined.

A handover should name what changed, why it changed, which revision was checked and how the important behaviour was verified. It should disclose unavailable checks and unresolved dependencies in direct language.

Keep useful evidence with the work. That can include representative test results, a recovery rehearsal or a short record of a design decision. It should help another engineer reproduce the conclusion without depending on the original conversation remaining available.

7. Invest in the environment around the model

Repository instructions, fixtures, meaningful tests and reliable development setup improve the work an agent can do. They also improve the work a human can do. If every session spends time rediscovering local conventions, the delivery system needs attention.

Maintain concise guidance that describes the current architecture and working checks. Remove stale commands and contradictions. Use examples where they clarify a boundary, but avoid turning guidance into a second, drifting copy of the entire codebase.

Evaluate improvements through accepted work and review effort. As METR's early-2025 study illustrates in its specific setting, the feeling of productivity and measured completion can differ. The right response is to examine the actual delivery loop, including corrections and unsuccessful attempts.

AI-assisted engineering becomes useful when the tool can carry bounded work through to a verifiable result. The engineer's contribution is to establish the contract, understand the system and decide whether the evidence supports delivery. Better tools increase the amount of work that can be attempted. Those disciplines decide how much of it can be trusted.