AI for Technical Leads & Architects

The Role Shifts

When a single developer uses AI, the calculus is simple: they write code faster, they review what AI produces, they own the output. The skills are mostly personal. The feedback loop is tight.

When a team of developers uses AI, the tech lead's job changes in ways that aren't obvious at first. Code volume increases. Review queues grow. Standards drift faster because AI confidently produces code in whatever style it was trained on — which may or may not be your style. Architectural decisions that used to take days of discussion can now be prototyped and rationalized in hours, which is both powerful and dangerous.

The core shift is this: your job moves from producing to directing. You spend less time writing code and more time setting the context that makes AI-generated code good. You write the shared rules files, the prompt library, the review checklists. You define what "correct" looks like so that when eight developers each ask AI to solve the same category of problem, they get consistent answers.

Part 1: Code Review in an AI-First Team

AI-generated code looks clean. It's formatted consistently, the variable names are reasonable, the comments are present. This is the problem. The signals you've trained yourself to use when reviewing human-written code — hesitant variable names, missing comments, suspicious TODOs — are gone. AI code looks finished whether it's correct or not.

The review burden also increases. Developers produce more PRs, faster. Code that used to take a day takes an hour. The surface area of what lands in review balloons. You cannot respond by reading more carefully at the same pace — you have to review differently.

What to Look For That AI Misses

AI is excellent at local correctness — making a function behave according to its signature. It is poor at global correctness — ensuring that function fits correctly into the system it's part of. Your review should focus on the seams:

• Invented APIs — Does this library actually have this method? Hallucinated API calls look identical to real ones. If the import is unfamiliar, verify against the package documentation.
• Missing error propagation — AI often handles the happy path completely and the error path partially. Check that errors are caught, logged, and surfaced correctly at every layer.
• Auth and authorization gaps — AI generates authentication checks but frequently omits authorization logic. "Is the user logged in?" and "does this user have access to this resource?" are different questions.
• Architectural drift — Does this solution fit the existing patterns in the codebase, or does it introduce a parallel pattern? AI doesn't know your established conventions unless you tell it.
• Transaction boundaries — Multi-step database operations generated by AI often lack transaction wrapping. Ask: what happens if step 2 fails after step 1 succeeds?
• Stale dependencies — AI may reference packages, APIs, or approaches from its training data that are now deprecated or replaced. Check version-specific behavior.

Using AI to Review AI Code

One of the most effective review techniques is asking a separate AI session — with no prior context — to critique the PR. The key is adversarial framing. Don't ask AI to review positively; ask it to find problems:

This produces different output than "review this code." The adversarial framing makes AI look harder for failure modes rather than confirming what looks right.

Structuring the PR Process for AI-Generated Code

The traditional PR template was designed for human-written code, where the author understands every line they wrote. For AI-assisted PRs, you need additional fields:

## What this does
[one paragraph plain-language description]

## AI assistance used
- [ ] Generated from scratch by AI
- [ ] AI-suggested approach, human-written code
- [ ] AI-written with significant human modification
- [ ] Human-written with AI review/polish only

## Verification steps taken
- [ ] Verified all imported APIs against official documentation
- [ ] Manually tested error paths
- [ ] Checked authorization (not just authentication)
- [ ] Reviewed DB operations for transaction safety
- [ ] Security considerations noted below

## Areas of uncertainty
[What parts are you least confident about? Where should the reviewer look hardest?]

The "areas of uncertainty" field is particularly valuable. Developers who used AI heavily often have genuine uncertainty about parts of the generated code. Making that uncertainty explicit directs reviewer attention efficiently.

Tiered Review Based on Risk

Not every AI-generated PR needs the same depth of review. Define tiers explicitly so that reviewers know where to spend their time:

• Tier 1 — Deep review: Auth changes, database schema changes, security-sensitive code, payment flows, data export, admin functionality. Require two reviewers, manual testing of edge cases.
• Tier 2 — Standard review: New features, API endpoints, significant business logic. One thorough reviewer, happy and unhappy path testing.
• Tier 3 — Light review: Tests, documentation, configuration, UI-only changes with no business logic. Spot-check for obvious issues.

Classify PRs at creation time. The PR template can include a self-declared tier that reviewers can override.

Part 2: Team Workflows

Eight developers each using AI individually, each in their own way, produces eight parallel sets of habits, patterns, and anti-patterns. Some will use AI for everything and trust it completely. Some will use it reluctantly and override it constantly. The output will be inconsistent in ways that compound over time.

Standardization is the tech lead's lever. Not control — standardization. You're not deciding whether each developer uses AI or how often. You're defining the shared context that makes AI work consistently across the team.

The Team Context File

Every major AI coding tool supports a project-level rules file: CLAUDE.md for Claude Code, .cursorrules or .cursor/rules/ for Cursor, .github/copilot-instructions.md for Copilot. This file is your most powerful standardization tool.

A well-written team context file tells AI:

• What stack you're on and what versions matter
• What patterns to follow and which to avoid
• What files or directories are off-limits for modification
• How error handling works in your codebase
• What logging and observability patterns to use
• What the testing conventions are
• Security-relevant constraints (never log PII, always validate external input)

# Team Context

## Stack
- TypeScript 5.x, Node.js 20+, Express 4.x
- PostgreSQL 16 via Kysely (NOT TypeORM, NOT raw SQL except in migrations)
- Zod for all input validation — validate at every API boundary
- Vitest for unit tests, Supertest for integration tests

## Patterns to follow
- All route handlers are in `src/routes/`, thin handlers only
- Business logic lives in `src/services/`, never in routes
- Database queries in `src/db/queries/`, never inline in services
- Use Result types (ok/err) for operations that can fail — don't throw from services

## Patterns to avoid
- Do NOT use `any` in TypeScript — use `unknown` and narrow
- Do NOT put business logic in middleware
- Do NOT use `console.log` — use the logger in `src/lib/logger.ts`
- Do NOT access `process.env` directly — use `src/config.ts`

## Security rules (non-negotiable)
- Never log request bodies that may contain passwords or tokens
- All external input must pass Zod validation before use
- Use parameterized queries — never string-concatenate SQL
- Auth middleware is in `src/middleware/auth.ts` — always apply to protected routes

## Testing
- Every service function needs a unit test
- Every API endpoint needs an integration test against a real test DB
- Test file lives next to the file it tests: `foo.ts` → `foo.test.ts`

This file lives in the repository root, committed alongside the code. Every developer's AI sessions inherit these rules automatically. When your conventions change, updating one file updates the behavior of AI for the whole team.

Onboarding Developers to an AI-Augmented Workflow

New developers joining an AI-first team face a novel problem: they need to learn the codebase, learn the AI tools, and learn how the team uses AI — simultaneously. Without guidance, they often use AI in ways that conflict with team conventions, or they use it too little and fall behind on velocity expectations.

Build an explicit AI onboarding session into your process. It should cover:

• Which tools the team uses and how they're configured
• Where the team context file is and what it says
• What AI is trusted to do autonomously vs. where to verify carefully
• How the PR template works and what the uncertainty field is for
• Two or three canonical examples of good AI use in your codebase (real PRs)
• Two or three examples of AI failures caught in review (what to watch for)

The canonical examples are the most valuable part. Developers learn by seeing real cases from their actual codebase, not abstract principles.

Sprint Planning and Estimation

Estimation breaks in interesting ways when the team uses AI. Tasks that used to take three days take one. Tasks involving novel architectural decisions still take three days. Teams that estimated collectively before AI often underestimate the variance: AI makes the easy work much faster, and the hard work only slightly faster.

Use AI to improve planning, not just execution:

The "flag where AI will produce poor output" prompt component is key. It surfaces the tasks where velocity assumptions break down — usually anything involving pagination of large datasets, complex authorization logic, or interactions between multiple services.

Team AI Retrospectives

Add an AI-specific retrospective question to your regular sprint retros. Not "did we use AI?" but pattern-focused questions:

• What AI-generated code did we find problems with this sprint? What category of problem was it?
• Were there tasks where AI slowed us down rather than sped us up? Why?
• What prompt or pattern worked well that we should add to the team library?
• Did AI introduce any inconsistency with existing codebase patterns? How did we catch it?

These questions generate institutional knowledge: the team's collective learning about where AI works in their specific codebase. Feed the findings back into the context file and prompt library.

Part 3: Building an Organizational Prompt Library

Every developer on your team is solving overlapping problems with AI every day. They write prompts to generate tests, review security, document functions, debug errors, and plan features. Most of those prompts are written from scratch each time — inconsistent in quality, incomplete in context, and invisible to the rest of the team.

A shared prompt library changes this. Instead of each developer reinventing prompts individually, the team accumulates battle-tested prompts that are specific to your stack, your conventions, and the problems you actually encounter.

What Belongs in an Organizational Prompt Library

Individual prompts belong in individual workflows. Team prompts belong in the library. The distinction is whether the prompt depends on team-specific context — your stack, your conventions, your codebase patterns — or whether it's generic enough to work anywhere.

Good candidates for a team prompt library:

• Code review prompts that reference your specific security requirements
• Test generation prompts that follow your testing conventions
• Debugging prompts tuned to your logging format
• PR description generation prompts matching your template
• Documentation prompts that follow your doc style
• Architecture review prompts that reference your existing patterns
• Onboarding prompts for understanding unfamiliar parts of the codebase

Prompt Structure for Reuse

A prompt that works once in your own session often fails when a teammate uses it without the surrounding context you had. Reusable prompts need explicit structure:

# [Category]: [Purpose]
## When to use
[One sentence: what situation this prompt is for]

## Context to provide
- [What to paste or describe before using this prompt]
- [What information AI needs that isn't in the prompt itself]

## The prompt
[Prompt text with [PLACEHOLDER] markers for variable parts]

## Expected output
[What good output looks like — helps developers know when to regenerate]

## Known limitations
[Where this prompt fails or produces poor output — so teammates don't waste time]

The "known limitations" section is what separates a real team asset from a prompt someone wrote once and thought was good. Honest documentation of where a prompt fails saves teammates from discovering the same failure the hard way.

Example: Security Review Prompt

# Security: Pre-merge Security Review

## When to use
Before merging any PR that touches authentication, authorization,
data access, external API calls, or user input handling.

## Context to provide
Paste the full diff of the PR being reviewed.

## The prompt
You are performing a security review of this code change for a
[Node.js/TypeScript/Express] application.

Check specifically for:
1. SQL injection — are all queries parameterized? (We use Kysely — raw
   strings in .raw() calls are suspicious)
2. Authorization gaps — code may authenticate (check JWT) but skip
   authorization (check that this user can access this resource)
3. Sensitive data in logs — we never log passwords, tokens, or PII
4. Input validation — all external input must pass Zod validation before use
5. Path traversal — any use of user-supplied strings in file paths
6. Mass assignment — are we accidentally exposing fields the user shouldn't set?
7. Timing attacks — auth comparisons should use constant-time functions

For each issue found: location, severity (critical/high/medium/low),
description, and suggested fix. If no issues, say so explicitly.

[PASTE DIFF HERE]

## Expected output
A numbered list of findings, or "No security issues found." Do not
explain what you checked — only report what you found.

## Known limitations
- AI misses business-logic authorization errors where the check
  exists but applies the wrong rules
- Does not catch issues in dependencies — only the code in the diff
- May produce false positives for Kysely's .ref() calls, which are safe

Maintaining the Library

A prompt library that isn't maintained becomes a liability: developers discover the prompts are outdated but don't know which ones to trust, so they stop using it. Maintenance doesn't require much — it requires a clear owner and a clear update trigger.

• Own it like code: The prompt library lives in the repository. Changes go through PR review. Version controlled, not shared in a Notion doc.
• Update triggers: When a dependency major-versions, review relevant prompts. When the retrospective surfaces a prompt failure, update it. When a new pattern is established, add a prompt for it.
• Quarterly audit: Once a quarter, run through each prompt. Test it against a current problem. Either validate that it still works or update/deprecate it.
• Contribution path: Every developer can submit a prompt. Prompts go through one review cycle before landing. The bar is: does it work consistently, does it have context documented, does it have known limitations noted?

Part 4: Architecture Decisions with AI

Architecture decisions are high-stakes, high-ambiguity problems. The right answer depends on your specific constraints — team size, existing system, performance requirements, organizational politics, budget. AI doesn't know any of these unless you provide them, and providing them takes deliberate effort.

The risk of using AI poorly in architecture is not that it gives bad advice — it's that it gives plausible-sounding advice that fits a different system than yours. AI has read every architecture post on the internet. It knows what decisions other teams made for other systems. It will confidently recommend microservices to a three-person startup or a monolith to a team that has already deployed twelve services.

The key is to make AI your adversary in the evaluation process, not your validator.

Exploring Options Before Deciding

When you already have a preference, AI will usually agree with it. Confirmation bias is built into the interaction: if you say "I'm thinking of using event sourcing for our audit log," AI will explain why event sourcing is good. If you say "I'm skeptical of event sourcing," AI will explain why your skepticism is warranted.

Break this by asking for a structured comparison before revealing your preference:

The "do not recommend one" instruction is not politeness — it forces AI to give you genuine options instead of presenting two strawmen and one winner. After you read all three, you can ask follow-up questions about the specific tradeoffs that matter for your context.

Challenging Your Own Decisions

When you've already made a tentative decision, use AI to stress-test it before you commit:

The "only the problems" constraint matters. Without it, AI generates a balanced essay. With it, AI focuses. You'll hear about table growth, query performance on wide JSON columns, the coupling between application transaction and audit write, the difficulty of replaying history, the schema-less nature of old/new JSON becoming unmaintainable over time. Some of these will matter for your system. Some won't. But you'll have thought about them before building.

Architecture Decision Records with AI

An Architecture Decision Record (ADR) documents why a decision was made — not just what the decision is. This is exactly the kind of information AI can help structure, because the structure is consistent and the thinking has usually already happened in conversation.

AI drafts the ADR from the reasoning you've provided. You review it for accuracy and nuance — the AI won't know the full organizational context, the specific conversation you had with your team, or the regulatory constraint that made one option unacceptable. Add those details. The AI gives you 80% of the document in 30 seconds; your edits make it accurate.

Evaluating Third-Party Libraries and Services

Choosing a dependency is an architectural decision with a long tail. AI can help structure the evaluation, but its training data has a cutoff — library ecosystems change, companies get acquired, open-source projects go unmaintained.

The explicit "I'll verify independently" note is important. It tells AI you know its limitations here and will fact-check — which tends to produce more hedged, honest output rather than confident claims about things that may have changed.

Part 5: Governance, Standards, and Quality

Governance is the word teams reach for when informal coordination stops working. With AI in the picture, informal coordination breaks faster: eight developers generating code independently, each using AI differently, can diverge significantly in a single sprint.

Governance doesn't require bureaucracy. It requires clarity: what decisions are made once and shared, what decisions each developer makes individually, and what happens when something goes wrong.

Coding Standards That Work with AI

Traditional coding standards documents are long, rarely read, and not enforced by the tools developers actually use. AI changes this. If your coding standards are written in a format that AI understands — specifically, your team context file — they become enforced automatically on every session.

This means the most effective coding standard is one that lives in CLAUDE.md or equivalent, stated as instructions AI follows rather than guidelines developers should follow. The difference:

// Traditional coding standards document:
// "Prefer functional components and hooks in React.
//  Avoid class components except in legacy code."

// CLAUDE.md — the same standard as an AI instruction:
// Do NOT generate React class components. All React code uses
// functional components and hooks. If asked to modify existing
// class components, convert them to functional components first.

The instruction form produces consistent enforcement without developer discipline. The documentation form requires every developer to remember and apply it.

Managing Technical Debt from AI

AI generates working code faster than teams can understand it. This creates a new category of technical debt: code that is correct but whose rationale is unclear to the developers who maintain it. Nobody wrote it with deliberate intent — it was generated, it passed tests, it was merged.

Address this proactively:

• Require understanding before merging: Developers should be able to explain any AI-generated code in their PR. "AI wrote it and it works" is not sufficient. If they can't explain it, they need to dig in before merging.
• Tag AI-generated sections: Some teams annotate heavily AI-generated files or sections. This isn't shame — it's metadata that tells future maintainers the code may need extra review when refactoring.
• Debt sprint regularly: Schedule explicit time to revisit and understand AI-generated code that was merged under time pressure. This is maintenance, not cleanup — treat it accordingly.
• Prefer readable over clever: Instruct AI toward readability explicitly. AI defaults to concise. Your codebase benefits from obvious over clever, especially in AI-generated code where no human author will champion it when a future maintainer is confused.

CI Integration for AI-Generated Code Quality

Your CI pipeline is the last line of defense before merge. For AI-assisted teams, expand what CI catches:

• Type checking at strict mode: TypeScript strict mode catches many hallucinated API shapes at compile time. If you're not running strict: true, AI-generated any types and incorrect generics will slip through.
• Dependency audits: AI sometimes introduces new dependencies or suggests package imports from packages not yet in your lockfile. Automated audit catches unexpected additions.
• License compliance: AI may suggest libraries with licenses incompatible with your project. Automated license checking prevents unwanted GPL or AGPL dependencies from appearing.
• Security scanning: Run SAST tools (ESLint security plugins, Semgrep) on every PR. AI-generated code is no safer than human code from a security standpoint — it's trained on public code that includes public vulnerabilities.
• Test coverage thresholds: AI generates tests if prompted, but not if it's not. Coverage thresholds in CI ensure that new code — however generated — arrives with tests.

Measuring Impact Without Measuring Output

Tracking developer productivity by lines of code written or PRs merged was always a bad idea. With AI, it becomes actively harmful: AI generates lines of code trivially, so raw volume metrics are meaningless or worse — they incentivize accepting AI output without review.

What to measure instead:

• Defect rate per feature: Are features shipping with fewer production bugs than before? This is the real quality signal.
• Time from spec to working feature: Measure the full cycle, not just the coding phase. AI speeds coding but sometimes slows review if quality is poor.
• Review revision rounds: If PRs routinely need multiple rounds of revisions, that's a signal of poor initial quality — from AI or from insufficient human review before submission.
• Escaped defects: Bugs that make it to production are expensive. Track them by type. If AI-related failures (hallucinated APIs, missing error handling) appear repeatedly, update your review process and context file.

Security Governance for AI-Assisted Teams

AI introduces specific security governance questions that didn't exist before:

• What goes into the AI context? Developers pasting sensitive data — customer PII, production credentials, internal architecture details — into an AI session that may be logged by the provider is a data governance risk. Define what's safe to share and what's not.
• Which AI providers are approved? Different providers have different data retention and training policies. Establish an approved list and a process for evaluating new tools before developers adopt them.
• How is AI-generated code reviewed for security? Use the security review prompt from your team library on every security-sensitive PR. Don't rely on AI code being inherently safer than human code — it isn't.
• Dependency vetting: AI suggests dependencies. Developers sometimes accept them without the vetting they'd apply to a dependency they chose themselves. Establish the same vetting process for both.

Part 6: The Technical Lead's Own Workflow

Everything above is about what you set up for your team. This section is about your own work — the places where AI changes how a technical lead or architect spends their time.

Unblocking Developers Faster

One of a tech lead's highest-leverage activities is unblocking developers who are stuck. With AI, you can often unblock asynchronously and faster:

You can answer a developer's Slack message with a structured investigation path in minutes rather than waiting until you're free to pair-debug. For complex issues, AI often surfaces the diagnostic steps you'd walk through anyway — you're just accelerating the hand-off.

Reading Unfamiliar Code Quickly

Technical leads frequently need to understand code they didn't write, in a part of the system they haven't touched recently. AI dramatically speeds this up:

The "non-obvious behavior" clause is the valuable part. AI will flag side effects, hidden state, temporal coupling, and order-dependent operations that you'd spend 20 minutes finding by reading carefully.

Writing Technical Documents

Technical leads write a lot: ADRs, RFCs, post-mortems, onboarding docs, runbooks. These documents share a structure — context, decision or incident, analysis, outcome — that AI handles well once you provide the substance.

The pattern that works: talk through the problem conversationally, then ask AI to structure it into a document. Don't try to write the document prompt directly — have the conversation first:

AI structures the post-mortem. You review it for accuracy, add the specific names and times, and adjust the action items to match what your team can actually commit to. The draft takes 30 seconds; your editing takes 10 minutes. The alternative is 45 minutes of writing.

Staying Technically Sharp

Technical leads who stop writing code gradually lose the intuition that makes their judgment valuable. AI can be a tool for staying sharp without requiring large blocks of focused implementation time:

• Prototype architectural ideas in an afternoon rather than delegating a spike to a developer
• Dig into unfamiliar corners of the codebase conversationally: "explain this module to me as if I've never seen it, then tell me what its tests are missing"
• Stay current with new library versions by asking AI to summarize major changes and their implications for your codebase
• Use AI to draft code that you then read and critique — reading AI code with critical eyes develops intuition for what it does well and where it needs help

Related Guides