Which engineering work is suitable for AI-enabled delivery?

“Can AI do our engineering?” is too broad to support a safe decision. A codebase contains many kinds of work, from repetitive test updates to architectural change across sensitive systems. AI capability also varies by tool, model, context and time.

The practical question is where AI can add useful capacity now, under what controls and with how much human engineering judgement. That requires an assessment of both the task and the environment into which its output will be delivered.

Look for bounded work with clear evidence of correctness

Suitable work has a comprehensible objective, explicit boundaries and enough relevant context. The expected behaviour can be demonstrated through automated tests, static checks, review or another reliable oracle. Failures are likely to be detected quickly and corrected without disproportionate harm.

Examples may include explaining familiar code, drafting documentation, generating test cases for understood behaviour, routine refactoring with strong regression coverage or implementing a small change that follows established patterns. These are candidates for assessment, not a universal safe list. A “simple” task in a poorly understood legacy system can carry hidden consequences.

Repeated work may be attractive, but frequency alone is insufficient. Check whether automating the task preserves meaning and whether the review burden is lower than completing it another way.

Increase human involvement as uncertainty and impact rise

Novel architecture, ambiguous product intent, complex integrations and weakly documented systems demand more experienced judgement. So does work involving sensitive data, security boundaries, safety, regulated decisions or substantial financial and customer impact. Low reversibility and a wide blast radius increase the need for human design, review and approval.

AI output can appear plausible while being incorrect or incomplete. GitHub's responsible-use guidance advises review and testing and notes that generated code may not fit larger architectural concerns. Human oversight is therefore an active engineering activity, not a final glance at a finished answer.

Classify risks explicitly. Ask what could fail, who would be affected, how the failure would be detected, whether the change can be rolled back and which accountable specialist must decide. If those questions cannot be answered, improve understanding before expanding AI autonomy.

Assess whether the environment can support AI safely

An AI-capable task can still fail in an unsuitable environment. Useful context must be accessible and current: repository conventions, architecture decisions, interfaces, product intent and constraints. The team needs fast feedback through builds, tests, security analysis and observable runtime behaviour.

Permissions should match the task. An assistant suggesting code in an editor has a different risk boundary from an agent able to modify several repositories, execute commands or deploy. Limit access, separate environments and require approval at consequential steps. Protect confidential information and understand how the chosen tool handles data.

Technical health matters because AI amplifies its environment. Inconsistent patterns, flaky tests and slow review make generated changes harder to judge. Improving those foundations creates capacity for human engineers as well as safer conditions for AI.

Run a controlled trial and expand by evidence

Choose representative, real work with a known baseline. Define the delivery outcome, quality requirements, human roles, permissions, review points and stop conditions. Record total elapsed time and human effort, including prompting, context preparation, review, correction and operational follow-up.

Measure defects, rework, security or control exceptions, maintainability and developer experience alongside flow. Compare with an appropriate existing approach, acknowledging learning effects and small samples. A successful demonstration does not prove suitability for a different system or risk class.

Decide whether to continue, adapt or stop. Expand to adjacent work only when the evidence and controls remain relevant. Reassess as tools, models, codebases and risks change. The goal is useful engineering capacity, not the maximum possible amount of AI-generated output.

Example

A team considers an agent for both routine API test maintenance and changes to payment authorisation. The tests have clear patterns, isolated permissions, fast automated feedback and easy rollback. Payment changes cross security and regulatory boundaries and depend on several poorly documented services.

The team trials the agent on test maintenance with mandatory review and measures total effort, escaped defects and maintainability. It uses AI only for analysis and option exploration on payment work, retaining human-led design and implementation. The boundary reflects evidence and impact rather than enthusiasm for one tool.

FAQs

• Is greenfield work more suitable for AI than legacy work?

  Not automatically. Greenfield work may offer clear patterns but involves architectural choices and unknowns. Legacy work may be well understood and well tested, or it may conceal dependencies. Assess context, feedback, risk and reversibility in either case.

• Does good test coverage make a task safe for autonomous AI delivery?

  No. Tests are valuable evidence but may omit important behaviour, security, usability or operational consequences. Review the quality and scope of the tests and retain controls appropriate to the impact.

• How often should AI suitability be reassessed?

  Reassess when the work type, system, model, tool, permissions or risk changes, and review operational evidence regularly. Capability can improve, but new integrations or broader autonomy can also increase exposure.