AI can produce code faster than a team can understand it. That is not the same as delivering faster.
AI is now part of how many engineering teams explore ideas, draft code and share knowledge. Used well, it improves understanding, quality and delivery. Used poorly, it maximises generated output while quietly eroding craft, review and accountability. The useful question is not whether to adopt AI. It is whether the team is using it to think more clearly — or to ship more text with less ownership.
Where AI helps today
The strongest uses are usually the least theatrical. AI can accelerate documentation, help someone orient in an unfamiliar area of a codebase, suggest test cases, surface alternative approaches in a review, and turn tacit knowledge into something a team can find again. It is also useful for first-pass exploration: sketching an approach, listing edge cases, or translating a dense module into a plain-language explanation someone can challenge.
In each of those cases the engineer still owns the outcome: what to keep, what to discard, and what “done” means. That ownership is the point. AI is most useful when its output can be challenged by someone with enough context to recognise a weak answer. It can also accelerate learning for less experienced engineers, but only when feedback, review and safe opportunities to verify are part of the workflow. It becomes dangerous when fluency is assumed rather than developed.
Knowledge sharing is a good example. An assistant can draft a runbook or a design note from a conversation, but the team still has to decide what is true in production, what is provisional, and what needs verification. The value is speed to a reviewable artefact — not automatic truth.
Where it creates risk
Confident wrongness travels quickly. A polished pull request can hide shallow understanding, invented APIs, brittle edge cases or dependencies nobody intended to introduce. Security and licensing issues do not announce themselves politely. Accessibility and performance regressions can look “fine” in a demo and fail under real traffic, real devices and real assistive technology.
Shallow PRs are a cultural failure as much as a tooling one. If reviewers skim generated diffs because they look complete, the team optimises for appearance. If authors cannot explain why a change exists, what it touches, and how it was verified, the merge button becomes a gamble. Volume without comprehension is deferred incident response.
There is also a quieter risk: teams that stop practising the craft. If every hard path is delegated without verification, the ability to spot weak assumptions fades. Debugging becomes harder because fewer people have built the mental models that make odd behaviour legible. Leadership then inherits a culture that ships volume and struggles to explain systems.
A leadership angle
Practical AI in engineering is a standards and expectations problem as much as a tooling problem. Teams need clarity on what “good” looks like when AI is involved: who reviews, what must be verified, which contexts are sensitive, and how to talk about uncertainty without theatre. Silence on those points invites inconsistent practice — some people careful, others fast and opaque.
DORA’s 2025 research describes AI as an amplifier of an organisation’s existing strengths and weaknesses. That is a useful way to frame the leadership challenge: the tools magnify the engineering system around them.
Sensitive contexts need the same concrete care. Secrets, credentials, customer data, production logs and proprietary code must not be shared with AI tools unless approved configurations, retention terms and access controls permit it. Speed is not a reason to paste a stack trace or a customer record into a prompt.
Review culture matters more, not less. If the bar for merging drops because something was generated quickly, AI becomes a delivery shortcut that stores risk for later. If the bar stays grounded — readable intent, tested behaviour, accountable authorship — AI can increase pace without pretending craft is optional. Leaders set that tone in how they praise work, how they ask questions in review, and what they refuse to rubber-stamp.
Expectations should be explicit: use assistants to accelerate exploration and drafting; do not use them as a reason to skip understanding, tests or security thinking. That is not anti-AI. It is pro-accountability — the same standard good engineering leadership needs when tools change faster than judgment.
Leaders should not measure AI adoption through prompt counts, generated lines or pull-request volume. Those numbers reward output, not outcomes. Watch review time, rework, escaped defects and change-failure rate — and whether cycle time improves without quality deteriorating. If the metrics that matter get worse while the dashboards look busier, the organisation is amplifying the wrong habits.
Ecommerce and frontend realities
Commerce and frontend work punish vague answers. Platform constraints, checkout edge cases, accessibility requirements and performance budgets are not optional flavour. An assistant can draft a component or migration note; it does not carry the operational consequences of a slow product page or a subtle regression in a payment path. Catalogue complexity, promotions, localisation and third-party scripts create failure modes that only show up when someone who knows the system looks carefully.
Human judgment remains the control system: knowing when generated code fits the architecture, when a “simple” change is not simple on the live catalogue, and when documentation needs a person who has actually operated the system. Frontend quality is still measured in performance, keyboard paths, screen-reader behaviour and operational resilience — none of which improve automatically because a model wrote the first draft.
A practical checklist
A short operating list beats a vague AI policy. Treat each item as something you should be able to evidence before merge:
- The author can explain the change’s intent, assumptions and architecture
- Tests and static analysis have been run and the results reviewed
- New dependencies have been checked for provenance, maintenance, security and licensing
- Accessibility and performance have been validated where relevant
- The change is small enough to review properly
- The team remains accountable for what ships
Judgment over volume
AI should improve how engineering teams think and deliver — not simply how much text they can produce. The teams that get lasting value treat assistants as leverage for judgment: faster exploration, clearer drafts, sharper questions — with humans still accountable for what ships. The practical response is the same one that strengthens technical leadership elsewhere: stay close to the craft, create clarity for teams, and use new tools with judgment.
