Ти налаштував свій AI-інструмент для кодингу минулого місяця. Обрав модель, написав rules-файл, визначив style guide. Конфігурація завершена. Ти перейшов до справжньої роботи — як людина, якій є що шипити.
А тепер та частина, про яку ніхто не попередив: твій інструмент теж перейшов далі. Тільки він не створив PR.
Конфіг, який конфігурує сам себе
Між 8 та 15 квітня Anthropic і OpenAI обидві випустили фічі, які дозволяють твоєму кодинг-асистенту переписувати власну інструкцію. Без code review. Без пінга в Slack. Без "гей, команда, я принципово змінив підхід до всіх ваших архітектурних рішень." Просто тиха мутація поведінки, сесія за сесією.
8–9 квітня Anthropic запустила Managed Agents у публічну бету. Фіча auto-memory у Claude Code тепер записує файл MEMORY.md — самостійно написаний блокнот "засвоєних уроків", який накопичується між сесіями. Документація Anthropic говорить прямо: "Auto memory дозволяє Claude накопичувати знання між сесіями без вашої участі. Claude зберігає нотатки для себе під час роботи."
Перечитай ще раз. Для себе. Не для тебе. Для себе.
Через тиждень OpenAI випустила Agents SDK v0.14.0 з Sandbox Agents — персистентними воркспейсами, де агент генерує власні MEMORY.md та memory_summary.md. SDK інжектить ці файли на старті, змінюючи поведінку ще до того, як агент торкнеться хоча б одного рядка твого коду.
Дві компанії. Один тиждень. Обидві вирішили, що твій AI має писати собі власні робочі інструкції і ніколи не показувати тобі дифф.
Як працює щоденник
Після кожної сесії AI витягує патерни, які помітив ("ця команда віддає перевагу табам"), вподобання, які він вивів ("вони завжди використовують Redis для кешування"), та помилки, які виправив ("не імпортуй ту deprecated бібліотеку"). Він записує це в markdown-файли або серверні сховища. Наступна сесія — спочатку читає щоденник, а потім вирішує, як підходити до твого кодубейзу.
Claude Code також запускає фонову консолідацію після 24+ годин і 5+ сесій. (Спільнота називає це "Auto Dream", хоча Anthropic не використовувала цю назву в офіційних анонсах продукту.) Він стискає транскрипти сесій у структуровану пам'ять, конвертуючи відносні дати в абсолютні. Документація Anthropic описує консолідацію 913 сесій приблизно за 8–9 хвилин.
Ефективно? Безумовно. Аудитовано? Ні разу.
Діра в governance
Ось що насправді абсурдно. У будь-якій адекватній інженерній команді однорядкова друкарська помилка в README — це pull request. Зміна конфігу — два ревʼювери. Оновлення .env породжує тред у Slack із трьома думками та одним "ну, насправді..."
Але самописна пам'ять твого AI — файл, який визначає, як він пише весь майбутній код — отримує нуль ревʼю. Нуль. Жоден інструмент не пропонує "memory PR" для командного затвердження. MEMORY.md від OpenAI не має воркфлоу ревʼю. Memory Store від Anthropic у Managed Agents зберігає непрозорі серверні блоби, які ти навіть не можеш git diff.
І дрифт проявляється швидко. Розробники повідомляють про помітні зміни поведінки вже через 10–15 сесій. В одному широко обговорюваному випадку Claude мовчки почав рекомендувати Tortoise ORM замість усталеного в проєкті SQLAlchemy — тому що одна сесія дебагу async "навчила" його, що команда надає перевагу async-first підходу. Ніхто не просив міграцію. Ніхто не затверджував. Файл пам'яті вирішив, і файл пам'яті доставив — у кожну наступну сесію.
Це не гіпотетичний крайній випадок. Маленькі непорозуміння накопичуються в стійкі звички. Твій інструмент рекомендує різні архітектурні патерни в понеділок і в п'ятницю. Він перевизначає твої явні конвенції проєкту вподобаннями, які вигадав із того одного сніпету зі Stack Overflow, який ти вставив о 2 ночі під час панічного дебагу production-пожежі. А оскільки пам'ять персистентна, кожен хибний висновок стає несучим контекстом для наступних ста сесій.
Чесний компроміс
Пам'ять допомагає. Повторювані помилки відловлюються. Контекст проєкту переноситься. У мене немає аргументів проти пам'яті — мій аргумент проти неаудитованої пам'яті з blast radius на весь продакшн.
Як зазначає один аналіз імплементації OpenAI: "Якщо ваш інструментарій не може показати, що саме агент дістав і чому, пам'ять перетворюється на моторошну чорну скриньку."
Ти б не задеплоїв код, який твій колега написав під час сомнамбулізму. То чому ти деплоїш поведінкові зміни, які твій AI написав про самого себе, без жодного ревʼю, з областю дії на кожен файл у кожному репозиторії, до якого він має доступ?
Що з цим реально робити
Стався до MEMORY.md та ~/.claude/projects/*/memory/ як до configuration-as-code. Це не опціональна гігієна — це та сама дисципліна, яку ти вже застосовуєш до docker-compose.yml та .eslintrc:
- Версіонуй. Комміть файли пам'яті разом із кодом. Дивись дифф кожної зміни.
- Ревʼюй. Додай диффи файлів пам'яті до чеклісту PR. Якщо пам'ять змінилась — людина читає перед мерджем.
- Аудитуй щотижня. Постав рекурентне нагадування — читати, у що вірить твій інструмент про твій кодбейз. Ти будеш здивований — і місцями в жаху.
- Ресетуй агресивно. Коли пам'ять поїхала — видали і почни з чистого аркуша. Це markdown-файл, а не особистість.
- Заморожуй для критичної роботи. На production-critical проєктах заморозь файл пам'яті й повністю вимкни авто-оновлення. Самовдосконалення твого AI не важливіше за стабільність деплою.
Повне коло
Інструмент, який ти налаштував минулого місяця — це не той інструмент, який сьогодні крутиться на твоїй машині. Він переписав собі посадову інструкцію, поки ти ревʼювив чийсь однорядковий фікс друкарської помилки. І він зробить це знову завтра, і післязавтра, щоразу нашаровуючи те, що він неправильно зрозумів учора, на завтрашні архітектурні рішення.
Твоя команда ревʼюїть однолітерні фікси в README двома апруверами. Почни ревʼюїти файл, який контролює, як твій AI думає — або не починай, і насолоджуйся тим, як дізнаєшся, що твій інструмент "вивчив" про твій кодбейз, найважчим шляхом.
