Почему людям кажется, что они помнят всё, и почему SDLC Memory доказывает обратное

Author: Yauheni Kurbayeu
Published: Feb 22, 2026
LinkedIn

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

• Мы верим, что помним, почему выбрали именно эту архитектуру.
• Почему существует это ограничение.
• Почему этот инцидент на самом деле произошёл.
• Почему мы разделили логику EU и US.
• Почему мы отложили эту миграцию.

Но когнитивная наука говорит нечто очень неприятное.

Согласно исследованиям когнитивной психологии о ёмкости рабочей памяти, наша активная рабочая память обычно может удерживать примерно четыре значимых фрагмента информации в любой момент времени. Не сорок. Не четыреста. Четыре. Всё остальное реконструируется из фрагментов, привычек и повествовательного клея. И если мы не повторяем информацию и не выносим её во внешние системы, она быстро распадается. Это не недостаток лидерства. Это биология.

А теперь сравним это с современными AI-агентами. Claude может работать с 200K токенов, а иногда даже с 1M. Codex поддерживает 400K. Это звучит огромно по сравнению с человеческим мозгом, который жонглирует четырьмя активными ограничениями.

Но вот в чём поворот.

Даже этого недостаточно для живого SDLC.

Масштаб реальной delivery memory

Возьмём очень обычную конфигурацию: три команды, пятнадцать инженеров, двухнедельные спринты. Ничего экстремального. Никакой hyperscale-сложности. Просто здоровый SaaS-продукт, который развивается в production.

Если сжать работу до summary уровня решений, например tickets, сведённые к намерению, PRs, суммированные по их impact, ADRs, зафиксированные вместе с альтернативами, incidents, структурированные по причинам и mitigations, — даже тогда вы всё равно генерируете удивительно большой объём структурированного reasoning-материала.

На практике это означает примерно 150 tickets в месяц по всем командам. Около 200–250 pull requests. Несколько ADRs и архитектурных обсуждений. Пару production incidents. Результаты sprint planning. Review decisions. Принятия рисков.

Когда вы конденсируете всё это в канонические, структурированные артефакты — не сырой шум Slack, не logs, а memory, готовую к reasoning, — вы выходите примерно на 200 000 токенов в месяц.

Не теоретических токенов. Реальной delivery memory.

В enterprise-масштабе, с 80 инженерами и постоянным межкомандным архитектурным churn, это число вырастает до от одного до полутора миллионов токенов в месяц.

Теперь сравните это с context windows.

Двести тысяч токенов едва помещаются в некоторые современные модели. Четыреста тысяч дают больше пространства для дыхания. Один миллион выглядит щедро.

Но вот структурная реальность: всего один квартал delivery memory уже превышает то, что комфортно помещается в одно session window. А sessions сбрасываются.

Окно в 400K покупает вам время. Оно не покупает вам непрерывность.

Это то же самое ограничение, с которым сталкиваются люди, только в другом масштабе.

Реальная проблема — не в storage

Что интересно, storage — вещь тривиальная.

При вашем текущем масштабе полный год curated SDLC memory, включая embeddings и graph relationships, может занимать меньше 70 MB. Даже в enterprise-масштабе вы всё равно комфортно остаетесь ниже половины гигабайта для структурированной памяти.

Стоимость инфраструктуры пренебрежимо мала.

Дорого обходится когнитивная непрерывность.

Когда память живёт только в головах людей, каждая смена директора сбрасывает контекст. Каждый инцидент повторяет прошлые ошибки. Каждый архитектурный спор заново проигрывает аргументы, которые уже были закрыты шесть месяцев назад. Команды заново открывают ограничения так, будто это новые инсайты.

Проблема с памятью у вас не потому, что вам не хватает документации.

Проблема с памятью у вас потому, что вам не хватает структурированной, queryable и причинно-связанной памяти.*

Почему большие context windows нас не спасут

Увеличение context windows ощущается как прогресс. И это действительно прогресс. Но это горизонтальное масштабирование не того слоя.

Большое context window всё ещё привязано к session. Оно всё ещё transient. Оно всё ещё сбрасывается.

Без долговечной структуры агент забывает после завершения session. Без долговечной структуры люди реконструируют всё из фрагментов.

Мы продолжаем пытаться решать проблему непрерывности за счёт более крупных prompts.

На самом деле нам нужна layered memory.

Hot / Warm / Cold SDLC Brain

Если относиться к SDLC как к живой системе, память должна вести себя как нервная система.

Hot memory — это то, что происходит прямо сейчас.

• Текущий sprint.
• Открытые incidents.
• Активные risks.
• Нерешённые questions.
• Она текучая, обновляется ежедневно и достаточно мала, чтобы её можно было инжектить в session агента.
• Это ваш operational working set.

Warm memory — это эволюционирующий мозг продукта.

• Архитектурные decisions.
• Trade-offs. Postmortems.
• Compliance constraints.
• Ownership boundaries.
• Канонические артефакты, такие как Decisions, Questions, Risks, Actions, ADRs, и связи между ними.

Этот слой охватывает месяцы. Он эволюционирует, но не исчезает. Он не инжектится целиком; он извлекается выборочно.

Cold memory — это evidence.

• Сырые Jira threads.
• Slack transcripts.
• PR diffs.
• Recordings.
• Logs.
• Неизменяемое доказательство того, что произошло и почему.
• Редко инжектится напрямую, но всегда связано ссылками.

Ключевой insight прост.

Hot движется. Warm стабилизирует. Cold сохраняет.

Агенты делают query по всем уровням. Люди рассуждают через все уровни. Ни те ни другие не должны полагаться только на recall.

Отсутствующий слой: Provenance

Настоящая сила приходит не только из vector search.

Она приходит из отношений.

Многие команды предполагают, что RAG решает проблему непрерывности. Он помогает, но similarity — это не объяснение. Найти “похожий ticket” — не то же самое, что понять, почему существует ограничение.

Каждое значимое решение должно знать:

• Кто его принял.
• Когда.
• На основе каких evidence.
• Какие alternatives были отвергнуты.
• На что оно влияет.
• Какие risks оно mitigates.
• К каким incidents оно позже привело.
• Заменило ли оно предыдущее решение.

Вот где graph structure становится критически важной.

• Vector database помогает находить “похожие идеи”.
• Graph database помогает отвечать на вопрос “почему это существует?”

Vector search извлекает relevance. Graph traversal реконструирует causality.

Когда вы объединяете оба подхода, вы перестаёте искать текст и начинаете traversing reasoning.

Именно тогда SDLC становится traceable.

Что происходит, когда команды смещаются в сторону AI-агентов?

Теперь представьте будущее, которое не является гипотетическим, — близкое будущее, которое многие лидеры уже чувствуют. По мере того как AI-агенты становятся всё более способными, опросы показывают, что значительная доля разработчиков и инженерных команд уже опирается на AI в повседневных workflows, а некоторые оценки говорят, что более 80% инженеров регулярно используют AI tools для помощи в coding и development tasks.

Есть даже мнения, что через несколько лет многие традиционные задачи software engineering будут в основном автоматизированы агентами, а люди будут сосредоточены больше на planning, design и oversight, а не на том, чтобы самим писать код.

В этом сценарии, где 50–80% повседневной работы по coding и execution выполняется AI-агентами, проблема provenance становится драматически более острой. Когда инженеры-люди пишут меньше строк кода и тратят больше времени на управление автономными агентами, контекст решения и его rationale становятся ещё важнее:

• Сам work product перестаёт быть основным артефактом.
• Важно становится, почему и как агент выбрал конкретную implementation, а не только то, что он произвёл.

Даже исследования, которые показывают, что AI tools повышают индивидуальную или командную productivity (часто в диапазоне примерно 20–60% и более), также подчёркивают, что разработчики в итоге тратят больше времени на oversight работы, validation outputs и исправление agent-generated issues — то есть на тот вид reasoning более высокого порядка, который сам по себе не может быть автоматизирован без памяти о предыдущем контексте.

AI-агенты могут распознавать паттерны и писать код, но они не несут в себе автоматически организационные цели, продуктовую стратегию или trade-offs прошлых решений, если это явно не закодировано в структурированном слое provenance.

Этот сдвиг усиливает необходимость Warm Provenance tier:

• Когда агенты создают код автономно, вы должны знать, что привело к этому решению, столь же хорошо, как и то, что этот код делает.
• Когда агенты заменяют повторяющиеся задачи, людям остаются exception handling, strategy и orchestration — аспекты, которые труднее всего вспомнить без структурированной памяти.
• Когда продукту нужно доказать compliance, объяснить risk mitigation или реконструировать intent через месяцы, provenance graph становится единственной надёжной записью.

Без этого организации рискуют строить непрозрачные системы, которые даже их создатели не смогут полностью обосновать.

Почему это ещё важнее в AI era?

По мере того как AI снижает стоимость execution, скорость delivery начинает выравниваться между организациями. Code generation улучшается везде. Test creation ускоряется везде. Documentation пишет себя сама.

Не выравнивается только memory discipline.

• Команды без структурированной SDLC memory заново обсуждают старые решения.
• Они повторно вводят уже mitigated risks.
• Они повторяют архитектурные ошибки.
• Они теряют контекст каждый раз, когда меняется leadership или уходит ключевой инженер.

Команды с layered provenance объясняют решения под давлением. Они onboardят инженеров и AI-агентов в reasoning, а не в folklore. Они позволяют AI-агентам работать внутри реального исторического grounding. Они сохраняют governance continuity даже тогда, когда люди меняются.

Разница не в tooling.

Разница — в structural memory.

Почему это важно для лидеров

Если вы управляете несколькими командами, особенно в compliance-heavy SaaS environment, вы уже симулируете эту систему у себя в голове.

Вы помните, какая dependency хрупкая. Вы помните, какой agent workflow привёл к проблемному release. Вы помните, почему EU logic вела себя иначе при последнем rollout.

Но ваш мозг — это не durable store. Это reasoning engine с крошечным активным окном.

Та когнитивная нагрузка, которую вы ощущаете, — не слабость.

Это структурная перегрузка.

Вы удерживаете примерно 200 000 токенов в месяц в четырёх-chunk processor.

В будущем, где AI-агенты выполняют половину или больше execution work, эта memory burden не исчезает. Она смещается — от запоминания кода к запоминанию intent, causality и justification.

Финальная мысль

Люди не могут помнить всё. Агенты не могут помнить всё. Даже миллионные token windows — это не continuity.

Но организации могут помнить всё, если будут относиться к memory как к infrastructure, а не как к documentation.

Execution становится дешевле. Memory становится differentiator.

В AI-accelerated мире команды с самой сильной структурированной памятью будут не просто двигаться быстрее.

Они будут двигаться последовательно и ответственно. Это будут команды, которые смогут объяснить не только что было сделано, но и почему это было сделано, ещё долго после того, как код был написан.