Загружаем знания в ИИ
Сегодня продолжим говорить про ИИ, постепенно разгребаю свои заметки после конференций.
1️⃣ Управление контекстом
Вторая идея, вокруг которой всё крутится после продуктовых инженеров, — управление контекстом. ИИ нужен доступ к: - требованиям; - договорённостям; - истории решений.
Значит, контекст нужно собирать в одном месте: - либо переносить всё в Markdown; - либо настраивать интеграции через MCP со всеми возможными системами.
Перед работой над задачей я иногда запускаю поиск по имейлам или перепискам в Teams, чтобы собрать дополнительный контекст. Сюда же мой прошлый пост про выгрузку всех созвонов. Требования можно хранить прямо в репозитории или дать ИИ доступ через MCP к Jira, Confluence и другим системам.
Иначе ИИ может покрыть код тестами, но не увидеть оригинальные требования — и покрыть даже невалидный сценарий.
2️⃣ Знания остаются в головах
Собирать контекст в одном месте — хорошо, но MCP для доступа к нашему мозгу, к счастью, ещё не придумали 🧠
В головах всё ещё хранится куча неочевидного контекста. Например: - почему какое-то решение приняли несколько лет назад; - какие есть негласные требования: например, что для системы оплаты даже минимальный регресс производительности недопустим.
Яндекс активно работает над этим направлением и складывает знания по проекту в RAG. Если запустили фичу, а она не взлетела, это тоже может попасть в базу знаний, чтобы ИИ учёл этот опыт в будущем.
Меня всё мучает мысль — написание кода обесценилось, а теперь нам нужно ещё и выгрузить знания из головы, чтобы нас было совсем легко заменить 😅.
Получается новый уровень job security: раньше можно было писать менее понятный код, а теперь — саботировать передачу неочевидных знаний ИИ.
3️⃣ Не всех нужно пересаживать на Git
Когда мы говорим, что весь контекст должен храниться в одном месте, хочется сразу дать всем Git и заставить писать Markdown. И мне кажется, это неплохая идея.
Но в Яндексе был отдельный доклад про то, что для базы знаний нужна прослойка, чтобы не обучать всех Markdown и Git. Продакты должны писать требования в удобной для них среде.
Интересная фраза из доклада: Не нужно сажать космонавтов на трактора и трактористов на космолёт, а потом ждать, что все быстро разберутся.
Кажется, эту проблему должен закрыть docs as code, но я пока не изучал этот вопрос. А вообще ещё нужен автоматический аудит, чтобы требования не устаревали относительно кода.
В следующем посте поговорим о том, как ИИ меняет code review
А у вас в компании как с контекстом для ИИ? 💜 — активно передаёт контекст ИИ 🍾— пытаюсь быть незаменимым