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.
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.
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? |
| 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.
To tell whether AI tools are actually helping, see measuring engineering work.
Last reviewed 2026-09-17