Культура AI-інжинірингу проявляється в діях
AI engineering culture — це не декларація, а типові дії команди під тиском: як вона реагує на помилки, широкий diff і впевнені відповіді AI. Відповідальність за межі задачі, ризик і merge залишається за розробником.
Практичний цикл виглядає так: задача → план і межі → невелика зміна → перевірки → людський review → документація → покращення workflow.
Шість принципів команди
| Принцип | Практична поведінка |
|---|---|
| Відповідальність людини | Людина визначає межі, ризик і рішення про merge |
| Фактичний diff | Summary AI не замінює перегляд файлів, scope і конфігурації |
| Спочатку докази | Тести, smoke-checks, CI та logs важливіші за впевнений тон |
| Першопричина | Відтворення та гіпотеза важливіші за patch, що приховує симптом |
| Docs відповідають коду | README, runbook і release notes перевіряються фактичним запуском |
| Збій змінює процес | Повторна проблема покращує policy, skill, hook, gate або template |
Перевірка фактичного diff і причин
- порівняйте кількість файлів із початковим scope;
- знайдіть сторонній refactor, форматування та зміни конфігурації;
- відтворіть баг мінімальним тестом або сценарієм;
- перевірте, що regression test фіксує конкретну поведінку;
- якщо AI кілька разів лікує сусідній симптом, поверніться до discovery;
- не називайте performance або production readiness без відповідного вимірювання.
Документація як частина якості
README, runbook, PR description і release notes мають відповідати поточній поведінці системи. Команди запуску потрібно реально виконувати, а не переносити за аналогією з іншого проєкту.
Для змін із повторюваними наслідками корисні AI_CODING_POLICY.md, CLAUDE.md, REVIEW_CHECKLIST.md, EVIDENCE_LOG.md, SKILL.md, CI logs і postmortem. Вони мають пояснювати не лише результат, а й межі та залишкові ризики.
Що робити після повторного збою
- Зафіксуйте симптом і контекст, у якому він повторюється.
- Знайдіть першопричину та відокремте її від поверхневого workaround.
- Назвіть workflow-артефакт, який має змінитися: policy, skill, hook, gate або PR template.
- Призначте owner і додайте спосіб перевірити, що зміна допомогла.
- Оновіть документацію та залиште короткий postmortem.
- Перевірте, що нове правило не створило надмірних false positives.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush