Разработчик совместно работает с репозиторием через IDE и AI-ассистента для кода

За последние два года у AI-инструментов для кода ясная линия борьбы: точнее автодополнение, длиннее контекст, смелее агенты на несколько файлов, плотнее интеграция с IDE. Cursor, GitHub Copilot, Windsurf и Claude Code сделали «от чата к правкам в репозитории» нормой.

К середине 2026 года у многих команд ощущение такое: одна сессия — восторг, неделя — те же грабли. Вчера вы договорились с AI о стиле имён, сегодня новый Composer снова пишет по-своему. На прошлой неделе разобрали подпись в CI — на этой в PR опять та же ошибка. Модель не «поглупела»; AI-программирование уходит от «умного помощника без состояния» к «партнёру по работе во времени» — и эта линия фронта только начинается.

1. Длинный контекст ≠ память: мы смешали разные способности

В рекламе «200K / 1M context» уже стандарт. Инженеры быстро видят: то, что помещается в окно, не гарантирует, что это правильно используют в следующий раз.

Аспект Длинное контекстное окно Устойчивая память
Где работает Текущий диалог / задача Между сессиями, ветками, (в идеале) проектами
Откуда данные Файлы с @, автоподстановка open files Прошлые решения, предпочтения, инциденты, договорённости
Стоимость Токены на каждый запрос, длиннее — дороже Запись раз, при поиске — немного
Как ломается Закрыли сессию, сменили модель, обрезали по лимиту Ошибка, протухло, конфликт, неверное слияние
Аналогия Огромная доска Блокнот с указателем + обновляемые стикеры

Длинный контекст отвечает на «видно ли сейчас»; устойчивая память — на «вспомнит ли потом». Индекс среднего monorepo плюс обсуждение PR легко забьёт окно. Даже с запасом тащить всю переписку в prompt — не инженерное решение: шум давит сигнал, модель качается между противоречивыми старыми указаниями.

Контрпример: если правите 2–3 файла и правила уже в lint и CI, от сверхдлинного контекста быстро падает отдача. Сначала переносите состояние в исполняемые проверки, а не наращивайте токены.

2. Программирование «голодно» по памяти

В письмах и саммари цена забывчивости — повторить контекст. В софте это измеримые инциденты.

  • У архитектурных решений есть период полураспада: «почему worktree, а не clone на job», «почему keychain изолирован по runner» — редко в README, чаще в чате или review.
  • Договорённости неявные: обработка ошибок, структура тестов, формат commit, каталоги без авто-правок AI — в .cursor/rules, AGENTS.md и устных легендах.
  • Отладка эпизодическая: «TestFlight упал из‑за прав ASC API key» лучше хранить как эпизод, чем каждый раз кормить 200 строк лога.
  • Границы плавают: личные предпочтения, ограничения проекта и комплаенс в одном пуле — либо утечка, либо загрязнение.

В материале про корпоративный Mac CI и выбор worktree мы писали: «почему так настроено» живёт в runbook и операционной памяти, не в коде. AI-программирование раздувает это до десятков мелких решений на разработчика в день.

3. Пять слоёв памяти: от продукта к инфраструктуре

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

  • L5 организация: командные правила, комплаенс, общие runbook, постмортемы
  • L4 проект: ADR, границы модулей, грабли CI, политика обновления зависимостей
  • L3 личное: стиль кода, любимые команды, что AI делать не должен
  • L2 сессия: цель задачи, изменённые файлы, промежуточные выводы (летучие)
  • L1 мгновенное: открытые файлы, курсор, git diff (миллисекунды)

У большинства продуктов сильны L1–L2; ставка на L3–L5. Следующее отличие — пять экранов настроек или один конвейер с поиском, версиями и откатом.

Это созвучно OpenHuman и личным агентам с долгой памятью: фокус с «чей базовый модель больше» смещается к «кто стабильнее понимает пользователя и репозиторий» — в AI-коде поле боя это репозиторий и pipeline.

4. Технические маршруты: память — не «склад чатов»

4.1 RAG

Нарезать прошлые диалоги, ADR, review на chunks, embedding, искать по задаче. Плюс — масштаб и аудит источника. Минус — промах опаснее отсутствия памяти; нужны metadata: repo, ветка, время, признак устаревания.

4.2 Структурированная память

Например: «пароль codesign / match в vault X 1Password / confidence 0.9». Для инженерных фактов, удобно править вручную; с вольным текстом решений — другая логика слияния.

4.3 Сжатие сессии (compaction)

В конце длинной задачи — структурированное резюме на следующий раз. Быстро внедрить, но детали теряются; ошибочное резюме закрепляется навсегда — compounding error, нужна выборочная проверка.

4.4 Репозиторий как память

То, что нужно помнить — в AGENTS.md, комментарии, lint, исполняемый doctor; AI только предлагает patch. Самый дешёвый и review-friendly L4 — как «шаги воспроизведения в repo» в наших Mac CI материалах.

4.5 Local-first vs облачная память

Локальный индекс на Apple Silicon — про приватность; облако — про устройства и команду. Напряжение 2026: человек хочет «чтобы AI понимал меня», компания — «чтобы не понимал лишнего»; оба в одной фирме.

Для Mac-разработчика это одна доска с локальным inference на unified memory и приватным AI-кластером Mac Mini M4: индекс памяти и кода можно держать на одном постоянном узле, а не в SaaS целиком.

5. Три ближайших боя

Бой 1: личное vs командное. Без приоритетов агент случайно выбирает сторону в конфликте правил. Победит тот, у кого явные scope (user / project / org) и видна цепочка «откуда правило».

Бой 2: доверие. Автопамять экономит время и превращает одну галлюцинацию в долгий bias. Победит подтверждение записи или PR, отрицательная память, TTL, диагностика вроде doctor memory.

Бой 3: граница с безопасностью. Помимо утечки repo — «клиент на следующей неделе», «неисправленный CVE» из межпроектного поиска. Победит изоляция tenant, фильтр сущностей, аудируемый экспорт.

Вместе это толкает AI-код из «личного ускорителя» в инфраструктуру с platform engineering — как корпоративный Mac CI прошёл путь от «лишь бы собиралось» к пулам, изоляции и комплаенсу (FAQ по codesign и keychain).

6. Практика сейчас: собрать стек памяти до стандарта

Продукты ещё в перестрелке, но команда может сегодня снизить зависимость от чёрного ящика «Memory»:

  • В корне repo — AGENTS.md или .cursor/rules: границы модулей, запретные пути, обязательные проверки.
  • Грабли — в make doctor и шаги CI, не только в чате.
  • Разделяйте «факт» и «предпочтение»: факты в доку, предпочтения в user rules.
  • В конце большой задачи — фиксированный handoff: цель / сделано / не сделано / ограничения / не трогать — в issue или PR.
  • Файлы правил тоже рефакторьте, когда сотни строк — как dead code.
  • Ключи, имена клиентов, неопубликованные CVE — не в облачную память; только secret store и права issue.
На практике: если гоняете агента через шлюз OpenClaw + удалённый Mac, «вынесенную память» держите в том же Git, что конфиг шлюза и mount — при смене машины или откате контекст не пропадёт.

7. Итог: следующий рубеж — не «красивее говорить», а «помнить и не ошибаться»

Устойчивая память — не украшение, а порог перехода AI-программирования от демо-скорости к продакшен-совместной работе. Длинный контекст поднял потолок, но не решил накопление состояния во времени.

Базовые модели commoditize, интеграция IDE сходится. Сложно копировать накопленную в repo память с возможностью исправления, организационные границы в policy и CI с локальным inference на одной доверенной инфраструктуре.

Краткосрочно разумно не ставить всё на один переключатель «Memory» — документы, правила, скрипты и привычки repo с аудитом дают запасной выход от одного вендора. Когда L3–L5 стабилизируются, разрыв в ощущениях даст не +5% IQ модели, а можно ли доверять слою памяти.