Leading with AI
Leading engineers who build with AI
AI assistants and agents can draft code, tests and documents in seconds. A team that uses them well ships more and learns faster. A team that uses them carelessly ships more of what it doesn't understand. The difference is leadership.
Principle 1: a person owns every change
Whoever merges a change owns it: they must be able to explain what it does, why it is correct, and how it fails. "The assistant wrote it" is never an answer in a review or an incident. Make this explicit in your team's working agreement, and model it yourself. Put it in writing as part of your AI coding assistant policy.
Principle 2: keep changes reviewable
- Set a practical size limit for pull requests. AI makes large changes easy to generate and hard to review.
- Ask for the intent in the description: what problem, what approach, what was considered and rejected.
- Require tests that demonstrate the behavior, and check the tests themselves. Generated tests can assert the wrong thing confidently.
- Review generated code more slowly, not faster. Plausible-looking code is exactly where subtle errors hide.
A step-by-step checklist is in reviewing AI-generated code.
Principle 3: set guardrails before rollout
| Decision | Questions to answer |
|---|---|
| Approved tools | Which assistants and agents? Under which accounts and contracts? |
| Data boundaries | What code, customer data, secrets or controlled technical data may each tool see? |
| Agent permissions | What can an agent do without a person approving it: run commands, open pull requests, touch production? See AI agents in the software lifecycle. |
| Licensing and provenance | How are you checking that generated code doesn't bring in licensing problems? |
| Security | How are dependencies suggested by AI checked? How are secrets kept out of prompts? |
| Records | In regulated work, how are AI-assisted changes recorded and reviewed? See regulated engineering. |
Principle 4: design for learning
Engineers early in their careers can now produce working code before they understand it. That is not a reason to ban the tools. It is a reason to build understanding on purpose:
- Explain-back in review. Ask the author to walk through the change and its failure modes.
- Debugging rotations. Diagnosing real incidents builds the mental models that generation skips.
- Design before prompting. For non-trivial work, a short written design comes first, and the tool helps implement it.
- Pairing across levels, including on how senior engineers direct, question and correct AI output.
Principle 5: decide what never gets delegated
Some decisions stay with people regardless of tooling: architecture that is expensive to reverse, security-sensitive changes, anything touching safety, and the call to ship. Write the list down. Teams move faster when the boundaries are clear than when they are guessed.
Common failure patterns
- Review theater: approvals that don't read the change. Watch for fast approvals on large diffs.
- Duplicate logic: the tool writes a new helper instead of finding the existing one.
- Confident tests: tests that pass because they assert what the code does, not what it should do.
- Silent scope creep: agents changing files beyond the task.
Principle 6: make the stance clear
DORA's 2025 AI Capabilities Model names a "clear and communicated AI stance" among the capabilities that shape whether AI adoption helps teams, alongside practices such as working in small batches and strong version control. When engineers have to guess what is allowed, some avoid useful tools and others take risks they don't see. Say plainly which tools are approved, for what, and with which data, and revisit it as tools change.
Running a team retrospective on AI use
Every few months, spend one retrospective on the tools themselves:
- Where did AI tools save real time? Where did they create rework?
- Which incidents or bugs involved generated code or agent actions, and what would have caught them?
- Is review keeping up with the volume of change?
- Are newer engineers building understanding, or only output?
- What should change in the team's policy or working agreement?
To tell whether AI tools are actually helping, see measuring engineering work.
Common questions
Should engineering leads require AI tools?
Making approved tools available and teaching good use tends to work better than mandates. Judge the results by outcomes such as delivery and quality, not by usage.
How do junior engineers learn if AI writes the code?
By explaining their changes, debugging real problems, writing designs before prompting, and pairing with senior engineers. Career ladders can make these expectations explicit; see engineering career ladders.
What should never be delegated to AI?
Decisions that are expensive to reverse, security-sensitive and safety-related changes, and the decision to ship. Write the list down for your team.
Last reviewed 2026-09-17