How can engineers use AI for coding without weakening quality?

AI can produce code quickly. That speed is useful only if the resulting change is correct, secure, maintainable and aligned with the product and architecture. A team that generates faster than it can understand and verify may increase inventory rather than delivery capacity.

Quality does not require treating AI output as uniquely untrustworthy or automatically reliable. It requires a disciplined path from intent to evidence, with people accountable for accepting the result.

Frame a bounded engineering task

Give the tool the problem, expected behaviour, relevant constraints and clear boundaries. Identify the files or components in scope, established patterns, compatibility requirements and tests that must pass. For an agent, define what it may read, modify and execute and what requires approval.

Avoid using a long prompt to disguise an unresolved product or architectural decision. If engineers cannot explain what good looks like, generated detail will not create clarity. Separate exploration from implementation: ask for options and risks before committing to a design when uncertainty is material.

Smaller changes are easier to inspect, test and reverse. They also make it clearer whether the tool understood the task or happened to produce plausible output.

Provide context without exposing inappropriate data

AI performs better when it can see relevant code, interfaces, conventions and documentation. Curate that context. Outdated instructions, contradictory examples and unrelated files can mislead a model just as they mislead a new team member.

Know what information the tool receives, where it is processed, how it is retained and which organisational policies apply. Do not place secrets, personal data, client material or proprietary code into an unapproved service. Repository access should follow least privilege, particularly where agents can call tools or connect to external systems.

Maintain concise engineering guidance in the repository. Context written only for an AI tool should still make sense to the humans who own the system.

Verify behaviour and engineering fitness

Read the change and be able to explain it. Check error paths, data handling, dependencies, concurrency, performance, accessibility and operational behaviour as relevant. Run automated tests and static or security analysis, but examine whether those controls cover the actual risk.

AI may generate both implementation and tests from the same faulty assumption. Use requirements, examples, property checks, manual exploration or independently written tests where appropriate. Review newly introduced dependencies and licences. Generated code must meet the same definition of done and architecture expectations as other code.

GitHub's current responsible-use guidance warns that generated code may be inaccurate or insecure and recommends rigorous testing, code review, IP scanning and vulnerability checks. The precise controls should still be proportionate to the change.

Preserve ownership and learn from outcomes

The engineer accepting the change owns the professional decision to integrate it. “The model wrote it” is not an operational explanation. Record material design choices and ensure the team can maintain the result without reproducing the original conversation.

Measure more than completion time. Track review effort, rework, defects, security findings, readability, change lead time and production behaviour. Watch whether larger volumes of generated code make review superficial or increase cognitive load.

Use recurring findings to improve prompts, repository guidance, tests and task selection. Some work should move back towards human-led implementation when the verification cost or uncertainty remains high. AI assistance should strengthen the engineering system, not create a second, less accountable route into production.

Example

An engineer asks an AI assistant to add a retry mechanism to a payment integration. Instead of accepting a broad patch, they specify the idempotency rule, error classes, retry limit, logging requirement and components in scope. The assistant first proposes options, and the engineer selects one consistent with the existing architecture.

The generated change is small. The engineer adds an independent test for duplicate payment prevention, runs security and integration checks, and records the operational decision. Review finds an excessive log field containing customer data, which is removed before merge. The team retains the speed benefit without lowering its standard.

FAQs

• Must engineers disclose that AI helped write code?

  Follow organisational policy, contractual obligations and the terms of the chosen tool. Regardless of disclosure format, teams need enough traceability to review, assure and maintain the change responsibly.

• Is AI-generated code less secure than human-written code?

  Security varies by task, model, context and process. Neither origin guarantees safety. Apply secure design, review, testing and vulnerability controls according to the risk, and measure actual findings rather than assuming equivalence.

• Can an engineer merge code they do not fully understand if tests pass?

  They should understand the change well enough to judge its behaviour, risks and maintainability. Passing tests provide evidence within their coverage; they do not transfer accountability or prove every relevant property.