AI engineering culture: 6 принципов

1. Культура живёт в стандартных реакциях

Когда говорят слово «культура», очень легко представить себе постер на стене, документ на двадцать страниц или торжественную речь тимлида на созвоне. На деле всё куда прозаичнее и поэтому важнее. Культура — не то, что команда декларирует, а как вы себя ведёте, когда сроки жмут, тест упал, Claude уверенно сказал «готово», а мозг хочет ему поверить и пойти пить чай.

Если policy — это правило, а gate — точка контроля, то culture — это стандартная реакция. Именно она решает, что вы делаете первым делом. Открываете diff или сразу пишете «LGTM»? Ищете root cause или добавляете ещё один if, чтобы ошибка исчезла с экрана? Обновляете CLAUDE.md или ограничиваетесь сообщением «коллеги, будьте внимательнее»? Такие сообщения живут примерно столько же, сколько печенье на общей кухне.

В AI-assisted разработке это заметнее всего: Claude Code сильно вас ускоряет, а вместе со скоростью приносит соблазн — раз всё делается быстро, значит и проверять можно быстрее. Вот здесь культура и становится каркасом, который не даёт workflow расползтись обратно в vibe coding, только теперь уже в пиджаке и с корпоративным логотипом.

Ниже шесть принципов, которые превращают набор инструментов в профессиональную идентичность. Не мотивационные цитаты — инженерные привычки, видимые в вашем diff, в PR, в AI_CODING_POLICY.md, в CLAUDE.md и в том, как вы объясняете команде решение.

2. Принцип 1. Разработчик отвечает за результат

Первый принцип кажется очевидным, но именно он ломается чаще всего — особенно после удачной сессии с Claude Code. Он красиво исследовал проект, предложил план, внёс изменения, написал тесты, составил PR description — и возникает ощущение, что работа сделалась сама. А на самом деле она только дошла до главного: до вашей ответственности.

Фраза «Claude помог сделать изменение» — нормальная и честная. А вот «это не я, это Claude так написал» — уже тревожный звоночек. В Commerce OS, если меняется логика refund flow, ветка принадлежит не Claude, а вам. Это вы решаете, укладывается ли изменение в scope, не задет ли public API, хватает ли evidence, можно ли мержить и какие риски открыты.

Хорошая команда обычно закрепляет это коротко и очень приземлённо — прямо в CLAUDE.md или в policy:

# AI engineering culture
- Разработчик отвечает за финальный diff.
- Claude предлагает изменение, но не принимает решение о merge.
- Для multi-file change сначала план, потом правка.
- В PR всегда указываем проверки и оставшиеся риски.

Это не философия ради философии. Такой блок влияет на поведение Claude, но сильнее — на ваше собственное мышление: результат перестаёт быть «сгенерированным кодом» и становится инженерным предложением, которое надо принять или отклонить.

На практике проверить себя очень просто. Если в PR нет объяснения, что изменилось и какие ограничения остались, — значит owner результата ещё не проявился. Если вы не можете за две минуты объяснить, откуда в diff вообще взялся новый helper-класс, — значит ответственность формально ваша, но фактически вы её не удержали.

И здесь хорошая новость для тех, кто пока не чувствует себя очень уверенно в коде: быть owner результата — не значит знать наизусть весь Spring Boot. Это значит уметь задавать правильные вопросы и не отдавать финальное решение на аутсорс модели. Даже начинающий разработчик может профессионально сказать: «Покажи changed files, перечисли проверки, объясни, почему тронул именно эти классы, и не меняй public API без отдельного согласования».

3. Принцип 2. Читайте diff

После принципа ответственности почти автоматически приходит второй. Если результат ваш — значит, вы обязаны видеть, что именно попадает в репозиторий. А увидеть это можно не по красивому summary, не по уверенной формулировке в чате и не по ощущению «ну вроде логично». Увидеть это можно только в diff.

Проверка diff — это момент, когда AI и человек наконец говорят на одном языке: Claude формулирует намерение, diff показывает фактическое изменение. И вот тут очень быстро выясняется, держал ли он scope или протащил в коммит ещё три «полезных улучшения» сверху. AI очень любит быть полезным. Иногда настолько, что начинает спасать мир за пределами вашего тикета.

Посмотрите на такой короткий пример из рабочего цикла Commerce OS:

git diff --stat
# src/main/java/.../RefundQueueService.java      | 12 ++++++------
# src/test/java/.../RefundQueueServiceTest.java  | 18 ++++++++++++++++++
# 2 files changed, 24 insertions(+), 6 deletions(-)

Вот такой diff читается: его можно понять, проверить, обсудить с reviewer’ом и при случае откатить без драмы. А теперь представьте, что вместо этого вы видите 17 файлов, две «мелкие» правки в конфиге, случайный рефакторинг нейминга и форматирование половины пакета. Такой diff уже не reviewable. Он не инженерный — он литературный. Его хочется не проверять, а экранизировать.

Отсюда рождается очень практическая привычка. Если diff стал слишком большим, дело почти никогда не в том, что вы «плохо читаете diff»: обычно задача взята слишком крупно или Claude вышел за change boundary. Не надо героически дочитывать всё с глазами как у совы в два часа ночи — остановитесь, разбейте работу на части, верните управление себе. Маленький diff полезен и вам через неделю: всплывёт regression или спор — быстро поймёте, что произошло. Одно понятное изменение, одна проверка, один смысловой шаг.

4. Принципы 3 и 4. Доказательство и root cause

Эти два принципа удобно обсуждать вместе, потому что в реальной работе они почти всегда идут парой. Как только вы перестаёте слепо верить AI, вы начинаете искать доказательство. А как только начинаете искать, очень быстро понимаете, что симптом и root cause — не одно и то же.

Claude Code умеет отлично предлагать правдоподобные исправления. Проблема в том, что правдоподобное исправление и корректное исправление — это, увы, разные вещи. Самоуверенный тон модели — встроенная бесплатная опция, но гарантия правильности в комплект не входит. Поэтому тесты появляются не «после того как код уже написан», а как способ доказать, что вы исправили нужное поведение.

Возьмём простой пример маленького regression test для Commerce OS:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;

@Test
void shouldKeepRefundStatusWhenCommentAdded() {
    Order order = new Order("REFUND_REQUESTED");
    order.addComment("Проверить вручную");
    assertEquals("REFUND_REQUESTED", order.getStatus()); // статус не меняется
}

Тест крошечный, но делает очень важную вещь: фиксирует наблюдаемое поведение. Предложит Claude «оптимизацию», после которой addComment() вдруг начнёт менять статус заказа, — поймаете локально, а не глазами в продакшене.

А теперь посмотрите на ещё более приземлённую часть доказательства:

./gradlew test
# 24 tests completed, 0 failed
# BUILD SUCCESSFUL

Да, это скучно. Да, магии ноль. И именно поэтому это работает. Проверка создаёт evidence, а не настроение. Когда разработчик говорит «у меня всё прошло», он опирается не на интуицию, а на конкретный сигнал.

Теперь про root cause. Очень частый анти-паттерн в AI-assisted разработке выглядит так: вы видите ошибку, Claude предлагает патч, ошибка исчезает, все счастливы — а через два дня всё ломается в другом месте. Почему? Потому что модель лечила симптом. Контроллер падает на null — можно быстро добавить if (x == null) return .... Но если настоящий дефект выше по цепочке, где теряется обязательное поле заказа, вы не исправили систему — вы просто заткнули ей рот.

Профессиональный подход выглядит медленнее, но на самом деле он дешевле. Сначала вопросы: что воспроизводится, в каком сценарии, где evidence, какой минимальный тест падает, какая гипотеза вероятнее. И только потом просите AI исправить. Если после двух-трёх попыток Claude патчит рядом с проблемой, а не в ней — это повод не писать промпт пожёстче, а вернуться к диагностике.

Именно здесь культура проявляется особенно ярко. Без неё легко начать «договариваться» с ошибкой: лишь бы красная лампочка погасла. С культурой — ищешь причину и требуешь доказательства. Это уже не вопрос синтаксиса и не вопрос фреймворка. Это профессиональный рефлекс.

5. Принцип 5. Документация должна совпадать с кодом

Про документацию многие вспоминают в двух состояниях: либо когда надо срочно закрыть PR, либо когда всё сломалось и никто не понимает, как это запускать. В AI-assisted разработке чуть опаснее: Claude пишет гладкий, убедительный и подозрительно красивый текст. А красивый текст, оторванный от реального проекта, — просто особенно вежливая форма дезинформации.

Если README говорит одно, а репозиторий живёт по другим правилам, доверие вы теряете быстрее, чем кажется. Представьте: в Workflow Kit или Commerce OS обновили в PR build-пайплайн, а документацию не тронули. Новый человек делает всё «по инструкции» и получает ошибку. Код формально правильный, но инженерная система уже дала трещину.

Нормальная документация выглядит так:

## Локальный запуск
./gradlew bootRun   # запускает backend
npm run dev         # запускает frontend

Секрет здесь в том, что эти строки должны быть проверены. Не «примерно совпадать с реальностью», не «были актуальны месяц назад», не «Claude написал по аналогии». Буквально: команда запускается, приложение поднимается, шаг воспроизводим.

Этот принцип шире, чем README. Он про PR description, release notes, onboarding-заметки, AI-assisted workflow notes и даже комментарии в коде. В PR «изменение только в refund queue», а diff тронул ещё и auth-конфиг — документация уже не совпадает с кодом. В release note «safe refactor without behavior change», а поменялись статусы ответа API — то же нарушение.

У этого принципа есть ещё одна важная сторона: честность в формулировках. Решение demo-ready — не называйте его production-ready. Не проверяли performance — не пишите «оптимизировано». Осталось ограничение — обозначьте его. Преувеличение соблазнительно, потому что модель любит «завершать повествование красиво». Ваша задача — завершать его правдиво.

6. Принцип 6. Повторяющиеся ошибки чинят workflow

Вот здесь AI engineering culture становится особенно интересной. Обычная команда после повторяющейся проблемы часто реагирует эмоционально: «давайте просто внимательнее», «в следующий раз не забудьте», «ну это частный случай». AI-native команда смотрит на тот же эпизод иначе: ошибка повторяется — сломан не только конкретный PR, но и сама система работы.

Допустим, reviewer-skill в Workflow Kit второй раз подряд даёт ложное high-risk предупреждение на безопасный diff в Commerce OS. Можно каждый раз вручную отмахиваться: «ну этот skill иногда странный». А можно сделать взрослую вещь — признать, что repeated failure это входной сигнал на изменение артефакта.

Такой мини-postmortem может выглядеть так:

# Postmortem: PR #482 false-positive review
- Symptom: reviewer-skill flagged safe diff as high-risk.
- Root cause: outdated rule about SQL strings.
- Action: update reviewer/SKILL.md (owner: @anna).
- Cultural takeaway: repeated failure → update workflow asset.

Документ очень короткий, но в нём уже есть зрелая культура. Нет поиска виноватого, нет сакрального «ну просто запомните на будущее». Есть симптом, причина, действие и owner. И главное — действие направлено не на память людей, а на изменение системы: reviewer/SKILL.md, hook, policy, protected path, шаблон PR, CLAUDE.md, quality gate.

В этом месте многие команды делают типичную ошибку: ограничиваются разговором. Но разговор не workflow asset. Сообщение в Slack не защищает следующий PR, комментарий «обратите внимание» не заставит Claude вести себя иначе. А изменение в CLAUDE.md, дополнительный check в reviewer skill или обновлённый шаблон handoff note — защитит.

И это очень важная часть профессиональной идентичности. Хороший AI-native разработчик не просто пользуется набором инструментов — он замечает, где набор надо улучшить. Он не только consumer workflow, но и engineer workflow.

7. Шесть принципов как профессиональная идентичность

Когда шесть принципов лежат по отдельности, они ещё выглядят как хороший, но немного суховатый список. Когда вы начинаете видеть их в одном цикле, появляется та самая профессиональная идентичность, о которой много говорят и редко нормально объясняют. AI-native developer — не тот, кто быстрее всех пишет промпты, а тот, у кого процесс остаётся контролируемым, понятным и проверяемым, даже когда половину механической работы делает AI.

Посмотрите, как это проявляется в артефактах, которые вы уже собирали по Commerce OS и Workflow Kit:

Если свернуть всё это в одну схему, получится очень узнаваемый цикл:

flowchart TD
    A[Задача] --> B[План и границы]
    B --> C[Небольшой diff]
    C --> D[Проверки и evidence]
    D --> E[Review и решение человека]
    E --> F[Документация и traceability]
    F --> G[Улучшение CLAUDE.md / skills / gates]

Вот почему culture нельзя заменить одной policy. Policy запретит force push, hook заблокирует правку .env, quality gate остановит merge без тестов. Но ни один механизм не заставит вас по-настоящему читать diff, искать root cause и честно писать ограничения решения. Это внутренняя инженерная дисциплина.

К этому моменту у вас на руках уже не просто набор файлов: task spec, evidence, tests, quality gates, risk classification, policy, traceability, shared workflow assets. Но настоящая ценность не в самих файлах — она в том, что за ними начинает читаться ваш способ думать. Reviewer, ментор или teammate видит на PR маленький diff, понятную проверку, честные notes, адекватную реакцию на риск и улучшение workflow после ошибки — и видит не «человека, который пользуется Claude Code», а разработчика, которому можно доверить инженерную работу.

Именно в этом месте AI-native developer перестаёт быть модным ярлыком и становится нормальной профессиональной ролью. Вы не снимаете с себя ответственность и не выигрываете у процесса скоростью — вы выстраиваете контролируемый workflow: понятная задача, релевантный контекст, безопасные границы, небольшой diff, проверка, review, traceability и ответственное решение. Дальше это становится привычкой — той, что срабатывает, даже когда никто не напоминает «почитайте diff ещё раз».

И такая привычка особенно нужна там, где кодовая база уже старая, чувствительная и полна скрытого поведения: без traceability, risk discipline и аккуратных shared rules AI ускоряет не только работу, но и хаос.