Через полгода вы открываете свой же модуль и видите обходной путь, который выглядит как ошибка. Убираете — ломается сборка на одной из платформ. Возвращаете. Через год повторяете тот же цикл, потому что снова забыли, зачем это было нужно.
Копилот в редакторе здесь не помогает и не может помочь: он видит код, а не причину, по которой код такой. Причина не записана нигде.
#Зачем это нужно и когда не нужно
Нужно, если вы работаете над одним проектом дольше нескольких месяцев или ведёте несколько проектов параллельно. Не нужно, если вы пишете короткоживущий код или работаете в команде, где решения уже документируются формально — тогда личный слой дублирует существующий процесс.
#Что понадобится
- Ассистент с памятью, куда можно класть текст и потом искать по смыслу.
- Привычка записывать решение в момент, когда оно принято. Это единственная затратная часть.
- Пять минут на решение. Больше — и вы бросите на второй неделе.
#Копилот и личный ИИ: разные роли
Таблица по шести типовым задачам. Смысл не в том, что один лучше, а в том, что они не пересекаются.
| Задача | Копилот в редакторе | Личный ИИ с памятью |
|---|---|---|
| Дописать функцию по сигнатуре | да, это его работа | нет, он не в редакторе |
| Объяснить незнакомый кусок кода | да, по тексту файла | частично, без контекста проекта |
| Вспомнить, почему выбран этот подход | нет | да, если решение записано |
| Восстановить контекст после перерыва | нет | да |
| Не наступить на грабли повторно | нет | да |
| Сравнить с тем, как вы решали похожее раньше | нет | да |
Первые две строки — зона копилота, и он там силён. Четыре остальные он не закрывает не по слабости, а по устройству: у него нет вашей истории, и он видит только открытые файлы.
Это же объясняет, почему «копилот с большим контекстом» не заменяет память: больше контекста — это больше кода в окне, а не знание о том, что вы обсуждали в марте.
#Шаг 1. Заведите формат записи решения
Один короткий формат, который вы будете заполнять за пять минут. Проверенная структура — сокращённая запись архитектурного решения:
# Решение: кэшируем результат парсинга конфига в памяти процесса
Дата: 2026-08-26
Статус: принято
Контекст.
Парсинг конфига занимает заметное время на старте, а вызывается он из
шаблонов на каждый запрос. Профилирование показало, что это верхняя
строка в списке накладных расходов.
Варианты.
1. Кэш в памяти процесса — просто, но требует перезапуска при правке.
2. Кэш с проверкой времени изменения файла — сложнее, лишний вызов ФС.
3. Не кэшировать — оставить как есть.
Решение.
Вариант 1. Конфиг меняется редко и вручную, перезапуск при правке
приемлем.
Последствия.
Правка конфига без перезапуска не подхватывается. Если это станет
мешать — переходим к варианту 2, код изолирован в одной функции.
Пять полей: контекст, варианты, решение, последствия, дата. Ключевое здесь — «варианты» и «последствия». Через полгода вам понадобится не то, что вы выбрали (это видно в коде), а то, что вы отвергли и почему.
Поле «последствия» решает вторую половину задачи: оно заранее описывает, при каком условии решение стоит пересмотреть. Без него любая запись выглядит как догма.
#Шаг 2. Кладите записи туда, где потом сможете найти
Файлы в репозитории работают, пока их немного. Дальше начинается проблема поиска: вы не помните, что решение записано, и не знаете, по какому слову его искать.
Здесь и нужна память ассистента с поиском по смыслу: вы спрашиваете «почему мы не используем проверку времени изменения для конфига», а не подбираете точное слово из заголовка файла. Если ваши решения ещё и связаны между собой — «это следствие вон того», — полезно смотреть на них как на граф, а не список; как это устроено, разобрано в статье про граф памяти.
#Шаг 3. Спрашивайте перед тем, как менять
Дисциплина, ради которой всё делалось. Перед тем как трогать код, который выглядит странно, задайте один вопрос: «что известно про этот модуль». Если решение записано — вы сэкономите цикл «убрал, сломалось, вернул».
Это единственный шаг, где привычка формируется трудно: соблазн просто поправить всегда сильнее.
#Шаг 4. Разделите контексты проектов
Если проектов несколько, память должна знать, о каком идёт речь. Иначе решение из одного проекта всплывёт в ответе про другой — и это хуже отсутствия памяти, потому что выглядит достоверно.
Практический минимум — помечать записи проектом и явно указывать проект в вопросе.
#Шаг 5. Осторожно с доступом к файлам и командам
Ассистент, читающий ваш репозиторий, полезен: он отвечает с учётом реального кода, а не вашего пересказа. Как настроить такой доступ и на что смотреть при выборе разрешённых папок — в разборе агента с доступом к файлам.
Отдельно про выполнение команд: разница между «читать файлы» и «выполнять команды» — это разница между обратимым и необратимым. Почему второе не стоит включать по умолчанию, разобрано в статье почему агенту нельзя давать оболочку.
#Проверка результата
Система работает, если через месяц выполняются три условия:
- Вы хотя бы раз нашли своё решение вопросом, а не поиском по файлам.
- Записи содержат отвергнутые варианты, а не только выбранный. Если только выбранный — вы записываете код словами, а это бесполезно.
- Вы хотя бы раз не стали трогать странный код, потому что вспомнили причину.
Если ни одно из трёх не выполнилось — привычка не сформировалась, и честнее остановиться, чем поддерживать мёртвый архив.
#Что может пойти не так
- Запись превращается в документацию проекта. Формат разрастается, заполнение занимает полчаса, вы бросаете. Пять полей и пять минут — потолок.
- Записываются только успешные решения. Отвергнутые варианты и неудачные подходы полезнее: они экономят повторный эксперимент.
- Память смешивает проекты. Помечайте проект в записи и в вопросе.
- Ассистент уверенно пересказывает устаревшее решение. Записи стареют вместе с кодом. Помечайте пересмотренные как заменённые, а не удаляйте: история изменения решения ценнее его текущей версии.
- Вы ждёте, что ассистент напишет код лучше копилота. Не напишет: качество генерации кода определяется моделью. Какие модели годятся для кода и чем они отличаются — в обзоре моделей для кода.
- Компактная локальная модель не тянет сложные вопросы по коду. Так и есть: она объективно слабее топовой облачной в сложных рассуждениях. Для разбора архитектуры держите рядом сильную модель, для поиска по своим записям хватает и компактной.
#Частые вопросы
#Это не заменяет копилот?
Не заменяет и не пересекается. Копилот работает в редакторе с текущим файлом, личный ИИ — с вашей историей решений. Разумно пользоваться обоими: первым при написании кода, вторым перед тем, как менять чужое (или своё полугодичной давности) решение.
#Сколько времени занимает ведение таких записей?
Пять минут на решение, и записывать стоит не всё подряд, а то, что через полгода будет выглядеть странно. Практически это две-три записи в неделю на активном проекте. Если получается больше десяти — вы записываете слишком мелкие вещи.
#Чем это отличается от комментариев в коде?
Масштабом и судьбой. Комментарий объясняет строку и живёт рядом с ней; запись решения объясняет выбор между вариантами и переживает рефакторинг, который эту строку удалит. Отвергнутые варианты в комментарий не поместятся.
#Можно ли отдать ассистенту доступ к репозиторию целиком?
Технически да, и на чтение это оправданно. Но помните, что содержимое уходит в модель: при облачной модели текст запросов уходит провайдеру. Для рабочего кода под договором это отдельное решение, которое стоит согласовать, а не принимать самому.
#Ассистент может сам вести эти записи?
Черновик — да: попросите его сформулировать решение после обсуждения. Но проверять и дополнять придётся вам, потому что половина причины обычно не проговаривается вслух и живёт только у вас в голове. Общая рамка того, что даёт ассистент с памятью, — в разборе что такое личный ИИ.
#Вывод
Копилот закрывает написание кода, и делает это хорошо. Вторая половина работы разработчика — помнить, почему код такой, — не закрыта ни одним копилотом, потому что причина решения нигде не записана.
Записывайте решения в пяти полях по пять минут, обязательно с отвергнутыми вариантами, и складывайте туда, где сможете найти вопросом, а не поиском по имени файла. Через полгода это окупится первым же случаем, когда вы не полезли править странный код.