За полгода активного использования Cursor IDE я была поражена тем, насколько этот инструмент изменил мой подход к работе. Разработка превратилась в удовольствие: поэтапное планирование, реализация, умные подсказки – агент выполняет задачи активно, быстро и, что самое главное, практически именно так, как я хочу.

Конечно, всегда есть к чему придраться, но существенных минусов становилось все меньше. Cursor-подобные IDE и LLM постоянно развиваются: с переходом на последние модели и увеличением контекстного окна, мощь инструмента достигла такого уровня, что повседневные задачи решаются за минуты, и я уже практически не задумываюсь о технической рутине.

Казалось бы, недостатков почти нет. Однако, всякий раз, приступая к новой задаче, я начинала новый чат. Мне не хотелось перечитывать свои диалоги недельной давности, искать там контекст. Но настоящая проблема возникает, когда задача переходит ко мне от другого разработчика. У меня нет доступа к его диалогу с чатом. Я не знаю, почему он принял те или иные решения, какие варианты он и AI отбросили. Мне приходится заново вводить Cursor в суть задачи, тратя время на объяснение того, что AI-агент моего коллеги уже знал.

Еще одной проблемой всегда остается отсутствие наглядного понимания хода проекта. Глядя на код, я вижу результат, но не процесс. Я не вижу, как менялась логика принятия решений и куда движется архитектура. Git Log дает мне сухие факты ("изменен файл X"), но не дает ментальной модели.

Получается парадокс: наши локальные AI-агенты умнеют с каждым днем, но как команда мы страдаем от "коллективной амнезии" и отсутствия единой картины мира. Именно это натолкнуло меня на идею Когнитивного слоя проекта (Project Cognition Layer). Если у нас уже есть инструмент, который идеально хранит историю всех изменений (Git), почему бы не "накинуть" на него когнитивный слой, понятный и человеку, и AI?

Решение: Git-Native подход

Если проблема заключается в разрыве контекста между сессиями и людьми, нам нужен механизм, который сделает этот контекст общим, сохраняемым и отчуждаемым. И вместо того чтобы прикручивать сложные внешние базы данных, мы используем инструмент, который уже является стандартом для командной работы – Git.

Концепция «Обогащенных Коммитов»

В классическом процессе мы коммитим только код и скупое сообщение (git commit -m "fix Component.vue: исправлено то-то и то-то").

В подходе Project Cognition Layer каждый коммит сопровождается обновлением Когнитивного Слоя.

Как это работает:

1. Изменение: Разработчик меняет строки в src/views/UserProfile.vue (добавляет валидацию).

2. Генерация Смысла: Перед коммитом AI-агент анализирует diff, понимает суть изменений и генерирует файл .context/evolution/profile_refactor.md.

3. Атомарная Связка: Файл описания (.md) и измененный файл кода (.vue) попадают в один и тот же коммит.

4. Извлечение: В будущем, когда нам нужно понять контекст, мы не ищем "похожий код" по всей базе. Мы берем этот коммит и говорим: "Покажи мне конкретные строки кода, которые были изменены вместе с этим описанием".

Мы получаем "теневой репозиторий" смыслов, где каждое слово описания жестко привязано к конкретным строкам кода через хэш коммита.

Почему это делает эмбеддинги ненужными?

Чтобы понять разницу, давайте посмотрим, как работает поиск контекста в Cursor:

1. Индексация: Cursor разбивает наш код на мелкие фрагменты (чанки) и пропускает их через нейронку, превращая код в числовые векторы.

2. Поиск: Когда мы спрашиваем "Как работает валидация?", наш запрос тоже превращается в вектор.

3. Сравнение: База данных ищет векторы, которые математически ближе всего к вектору запроса. Чем ближе значения эмбеддингов друг к другу, тем более семантически близок код.

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

В предлагаемом мной Git-Native подходе мы можем создавать жесткую связь Описание решения задачи <==> Измененные строки кода. Когда нам нужно найти код, относящийся к "Валидации формы", мы не ищем сходства. Мы находим соотвествующие коммиты, где была описана эта задача. Это превращает историю проекта в базу данных с хорошей ссылочной целостностью. Нам не нужно гадать, какой код относится к документации – Git хранит эту связь на уровне своей файловой системы.

Визуализация: От diff-ов к когнитивным акцентам

Имея такую структуру данных, мы можем дать разработчику совершенно новый способ просмотра истории проекта.

1. Семантическая летопись

Никто не любит читать историю коммитов. Но представьте, что вы открываете окно, где вместо списка файлов видите таймлайн решений:

• Вчера, Спринт 42:

• Feat (UserProfile): Добавлено поле "О себе" с счетчиком символов. (Связанные файлы: UserProfile.vue, UiTextarea.vue)

• Refactor (Composables): Логика форматирования дат вынесена из компонента в useDateFormat.ts.

• Fix (Avatar): Исправлена ошибка в загрузке фото пользователя в UserAvatar.vue.

  Вы кликаете на Refactor и видите объяснение агента: "Логика форматирования дублировалась в 3-х компонентах, поэтому я вынес её в отдельный composable для переиспользования" – и ссылку на конкретный diff выноса кода.

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

2. Когнитивные Акценты

Агент может подсвечивать "Горячие точки смысла".

Если файл useUserAuth.ts меняется в каждом втором "Обогащенном Коммите" и в описаниях часто встречаются слова "токен", "рефреш" – агент помечает этот модуль на карте проекта как "Требует внимания".

Мы получаем карту проекта, раскрашенную не по типам файлов, а по концентрации смысла и проблем.

Техническая реализация:

Вся когнитивная система живет в скрытой папке .context/ внутри нашего репозитория. Это позволяет реализовать три ключевых механизма на базе стандартных команд Git:

1. Тепловая карта "Незнания"

Агент не должен галлюцинировать по устаревшему коду. Мы вводим метрику Confidence Score, основанную на истории изменений.

• Механика: Агент хранит хэш коммита последнего анализа (last_scan_hash).

• Проверка: При старте выполняется проверка изменений.

• Результат: Агент мгновенно видит список файлов, которые изменились, пока он "спал". Знания по этим файлам помечаются как недостоверные (Confidence 0%), и агент честно предупреждает об этом перед ответом.

2. Context Evolution Tracker

Это журнал архитектурных решений, который ведется параллельно с кодом.

• Хранение: JSON или Markdown файлы в .context/evolution/.

• Связь: Каждая запись содержит описание бизнес-задачи и ссылки на конкретные файлы.

• Польза: Это позволяет отвечать на вопросы "Почему?", которые невозможны для обычного статического анализатора кода.

3. Динамический граф знаний

Вместо плоского списка файлов мы строим ориентированный граф понятий в knowledge_map.json.

• Структура: Узлы – это модули или фичи (например, "AuthSystem"), ребра – зависимости.

• Обновление: Граф перестраивается инкрементально. Используя Heatmap, агент сканирует только изменившиеся файлы и обновляет связи только для затронутых узлов, что экономит ресурсы и время.

Синхронизация команды

Самое необходимое улучшение в этом подходе – командная работа.

1. Саша реализовала загрузку фото пользователя и сгенерировала для нее контекст.

2. Закоммитила изменения, используя агента для добавления контекстной информации о внесенных изменениях.

3. 3люша подгрузил изменения к себе.

4. Агент Илюши мгновенно узнал всё, что знал агент Саши о логике последней работы.

Заключение

Мы привыкли использовать Git как хранилище для истории кода. Но он способен быть хранилищем понимания.

Добавив простой когнитивный слой, репозиторий превращается в живую базу знаний. Становится возможным отказаться от черного ящика (отсутствие видимости того, что именно агент знает о проекте на текущий момент) в пользу прозрачных, читаемых файлов, жестко привязанных к коду через механизм коммитов.

На данный момент Project Cognition Layer существует как концепция и набор прототипов. Хотелось бы услышать ваше мнение относительно предложенного решения, его жизнеспособности и полезности. Спасибо!