Institutional knowledge — why systems work the way they do, what was tried and failed, the constraints nobody wrote down — is what makes teams resilient. AI can help retrieve it but can't replace it. How AI-first teams protect institutional memory.
Onboarding in an AI-first team is different from traditional onboarding in specific, important ways. What changes, what the risks are, and how to structure onboarding so new engineers learn the codebase rather than just navigating it with AI.
AI can reason about architecture, but architectural decisions require context, constraints, and judgment that AI doesn't have by default. How AI-first teams use AI in design reviews without outsourcing the judgment.
The honest answer: AI makes documentation happen more often, but it can make documentation less useful if you're not careful. The documentation culture patterns that work in AI-first teams, and the failure modes to watch.
CI/CD pipelines enforce quality automatically. AI can extend what's enforceable — from security scanning to semantic code review. Where AI-powered gates add real value in the pipeline and where they add noise.
AI can write tests faster than any engineer. The question isn't whether to use AI for tests — it's whether the tests AI writes are testing the right things. The trust and verification problem in AI-first testing.
AI tools can generate PR descriptions and commit messages, but without intentional norms they produce noise instead of signal. What good AI-assisted PR hygiene looks like and the practices that make git history useful rather than polluted.
Code review was designed for humans writing code. When AI writes a significant portion of a PR, the review process needs to change — what to focus on, how to annotate AI-assisted sections, and the failure modes that AI introduces.
Pair programming changes when AI is the third party in the room. How AI-first teams structure collaborative coding, what norms work, and the question of ownership when AI writes the code.
Sprint planning in an AI-first team looks different — estimation changes, task decomposition changes, and the relationship between a ticket and its implementation changes. What actually works and what to watch out for.