Сегодня продолжим говорить про ИИ, постепенно разгребаю свои заметки после конференций.

1️⃣** Управление контекстом**

Вторая идея, вокруг которой всё крутится после продуктовых инженеров, — управление контекстом. ИИ нужен доступ к:

• требованиям;
• договорённостям;
• истории решений.

Значит, контекст нужно собирать в одном месте:

• либо переносить всё в Markdown;
• либо настраивать интеграции через MCP со всеми возможными системами.

Перед работой над задачей я иногда запускаю поиск по имейлам или перепискам в Teams, чтобы собрать дополнительный контекст. Сюда же мой прошлый пост про выгрузку всех созвонов. Требования можно хранить прямо в репозитории или дать ИИ доступ через MCP к Jira, Confluence и другим системам.

Иначе ИИ может покрыть код тестами, но не увидеть оригинальные требования — и покрыть даже невалидный сценарий.

2️⃣** Знания остаются в головах**

Собирать контекст в одном месте — хорошо, но MCP для доступа к нашему мозгу, к счастью, ещё не придумали 🧠

В головах всё ещё хранится куча неочевидного контекста. Например:

• почему какое-то решение приняли несколько лет назад;
• какие есть негласные требования: например, что для системы оплаты даже минимальный регресс производительности недопустим.

Яндекс активно работает над этим направлением и складывает знания по проекту в RAG. Если запустили фичу, а она не взлетела, это тоже может попасть в базу знаний, чтобы ИИ учёл этот опыт в будущем.

Меня всё мучает мысль — написание кода обесценилось, а теперь нам нужно ещё и выгрузить знания из головы, чтобы нас было совсем легко заменить 😅.

Получается новый уровень job security: раньше можно было писать менее понятный код, а теперь — саботировать передачу неочевидных знаний ИИ.

3️⃣** Не всех нужно пересаживать на Git**

Когда мы говорим, что весь контекст должен храниться в одном месте, хочется сразу дать всем Git и заставить писать Markdown. И мне кажется, это неплохая идея.

Но в Яндексе был отдельный доклад про то, что для базы знаний нужна прослойка, чтобы не обучать всех Markdown и Git. Продакты должны писать требования в удобной для них среде.

Интересная фраза из доклада:

Не нужно сажать космонавтов на трактора и трактористов на космолёт, а потом ждать, что все быстро разберутся.

Кажется, эту проблему должен закрыть docs as code, но я пока не изучал этот вопрос. А вообще ещё нужен автоматический аудит, чтобы требования не устаревали относительно кода.

В следующем посте поговорим о том, как ИИ меняет code review

А у вас в компании как с контекстом для ИИ? 🔥 — активно передаём контекст ИИ 👀 — худо бедно, что-то делаем 🤷‍♂️ — пытаюсь быть незаменимым