Git для решений нужен мозг. Но какой?
Author: Yauheni Kurbayeu
Published: Mar 4, 2026
LinkedIn
В последние несколько месяцев я строил нечто, что началось как мысленный эксперимент и постепенно превратилось в реальную систему. Я называю её SDLC Memory. Идея, лежащая в её основе, проста — почти неловко очевидна, когда произносишь её вслух: у программных организаций нет памяти.
У нас есть Git для кода. У нас есть Jira для задач. У нас есть системы документации, полные объяснений, написанных постфактум.
Но реальная логика и причины, стоящие за инженерными решениями, почти всегда исчезают.
Через несколько месяцев в команду приходит новый человек, открывает репозиторий, смотрит на странный фрагмент архитектуры и задаёт неизбежный вопрос:
«Почему мы построили это именно так?»
Обычно ответ представляет собой смесь догадок и смутных воспоминаний. Кто-то помнит инцидент в продакшене. Кто-то думает, что это было связано с масштабированием. Третий человек смутно вспоминает разговор о compliance. Ни одно из этих объяснений не является неправильным, но ни одно из них нельзя назвать действительно надёжным.
Именно здесь родилась идея Git for Decisions.
Представьте, если бы каждое важное обсуждение, заметка со встречи или архитектурный разговор могли быть переведены в структурированные артефакты. Узел решения, объясняющий, что было выбрано. Узел риска, описывающий, что может пойти не так. Узел предположений, фиксирующий, во что все верили на тот момент. Вопросы, которые оставались открытыми. Action items, которые следовали после этого.
Вместо того чтобы существовать внутри Slack-тредов и записей встреч, эти артефакты образовывали бы граф. Со временем система накапливала бы живую карту инженерного мышления. Когда появляется новое решение, система могла бы сравнить его с историческими и сказать, например:
«Два месяца назад команда решила отложить запуск в ЕС, потому что нестабильность инфраструктуры создавала операционный риск. Сегодня новое решение предлагает снова отложить запуск из-за изменений в интерпретации GDPR. Эти решения могут быть связаны.»
Чем глубже я исследовал эту идею, тем более технически реализуемой она казалась. Современные LLM удивительно хорошо извлекают структурированный смысл из хаотичных разговоров. Графовые базы данных отлично связывают сущности и отношения. Векторный поиск хорошо работает для обнаружения семантически похожих решений во времени.
Архитектура начала складываться почти сама собой: принять текст, извлечь артефакты, разрешить идентичности, связать их с существующим графом, обнаружить противоречия и зафиксировать обновление как новую транзакцию.
Но затем я столкнулся с проблемой, которую не ожидал.
Настоящая сложность заключалась не в извлечении знаний.
Настоящая сложность заключалась в том, как должен мыслить сам этот системный механизм.
Существует по крайней мере три фундаментально разных способа спроектировать поведение такой системы во время выполнения, и каждый из них ведёт к совершенно разной философии того, как ИИ должен работать внутри процессов разработки программного обеспечения.
Подход 1: агентный runtime-поток (LLM как контроллер)
Первый подход — это то, что обычно называют agentic architecture.
В этой модели система ведёт себя почти как следователь. Процесс начинается, когда новые заметки со встреч или архитектурные обсуждения попадают в pipeline. Агент читает текст и извлекает потенциальные решения и вопросы. Затем он смотрит на существующий граф и решает, какие его части могут быть релевантны.
Предположим, система читает заметку:
«Нам следует отложить выпуск EU-инстанса, потому что новые разъяснения GDPR создают риски compliance.»
Агентная система могла бы отреагировать, исследуя граф. Она могла бы найти предыдущие решения, связанные с инфраструктурой ЕС, извлечь решение о задержке rollout из-за нестабильности инфраструктуры, изучить связанные риски и просмотреть хронологию решений вокруг этого релиза.
В какой-то момент система может решить, что у неё достаточно доказательств, и предложить обновление:
«Новое решение, по-видимому, противоречит предыдущему обязательству о том, что EU-инстанс должен быть запущен до Q2.»
Красота этого подхода в том, что система ведёт себя почти как любопытный инженер. Она следует за подсказками, исследует контекст и иногда обнаруживает связи, которые разработчики сами никогда явно не закладывали в workflow.
Но эта гибкость сопровождается неприятным осознанием. В агентной системе именно ИИ решает, что исследовать и когда прекратить исследование. Это может быть вполне приемлемо для ассистента или исследовательского инструмента, но когда задача системы — поддерживать авторитетную память инженерных решений, непредсказуемость становится серьёзной проблемой.
Поэтому вторая архитектурная философия идёт в противоположном направлении.
Подход 2: Python контролирует поток, а LLM и embedding-модели выступают лишь трансформаторами
Вместо того чтобы рассматривать модель как автономного агента, мы рассматриваем её лишь как преобразователь данных. Интеллект системы переносится в детерминированные части кода.
В этой версии Python оркестрирует весь pipeline под строгим контролем. Когда поступает новый текст, runtime выполняет фиксированную последовательность операций. Сначала он извлекает потенциальные узлы-кандидаты из графа с помощью векторного сходства. Затем получает их контекст из Neo4j. Только после того как необходимые данные собраны, система вызывает языковую модель.
В этот момент модель получает тщательно подготовленный набор информации и очень конкретный вопрос: учитывая эти артефакты и кандидаты, определить, представляют ли они одно и то же решение, связанное решение или совершенно новый узел.
Модель выдаёт структурированный результат — и ничего больше. Она не может исследовать граф. Она не может запрашивать дополнительную информацию. Она не может решить выполнить новый поиск. Она просто преобразует входные данные в структурированный вывод.
С точки зрения инженерии программного обеспечения этот подход кажется чрезвычайно комфортным. Каждый шаг детерминирован. Каждый графовый запрос контролируется. Система ведёт себя скорее как pipeline компилятора, чем как AI-агент.
Но возникает и неудобный вопрос. Если мы сводим модель к роли простого трансформатора, не используем ли мы недостаточно её способности к рассуждению — той самой способности, которая делает такие модели мощными? Ведь часть обещания ИИ заключается в том, что он может замечать связи, которые наши вручную написанные правила могут пропустить.
Это приводит к третьему подходу, который пытается объединить оба мира.
Подход 3: гибридная модель — использовать ИИ как трансформатор, но позволять Python управлять ветвлением на основе сигналов уверенности
Гибридная модель начинается с детерминированного pipeline, но позволяет системе проявлять больше любопытства, когда появляется неопределённость. Runtime по-прежнему контролирует основной workflow. Он по-прежнему извлекает кандидатов и формирует пакеты доказательств перед тем, как передать их модели для анализа.
Однако когда модель сообщает о низкой уверенности или неоднозначных совпадениях, pipeline расширяет пространство поиска. Система может извлечь больше потенциальных решений, исследовать соседство графа вокруг связанного узла или расширить временное окно, чтобы включить более старые архитектурные обсуждения.
Другими словами, система остаётся управляемой кодом, но ей позволяется копать глубже, когда ситуация этого требует.
Практический пример может выглядеть так. Система читает обсуждение, предлагающее отложить развертывание в ЕС из-за изменения юридических требований. Детерминированный pipeline извлекает наиболее похожие исторические решения. Модель анализирует их, но возвращает низкую уверенность, потому что доказательства неубедительны.
В этот момент runtime расширяет поиск, извлекая решения, связанные как с compliance, так и со стабильностью инфраструктуры, и снова предоставляет модели расширенный контекст. Только после этого система определяет, что новое предложение пересекается сразу с двумя предыдущими решениями, которые имели разные мотивы.
Этот подход кажется менее жёстким, чем модель трансформатора, но гораздо более контролируемым, чем агентный.
И именно здесь находится моя текущая дилемма.
Каждый раз, когда я смотрю на проблему через призму governance и аудируемости, детерминированный transformer-pipeline кажется ответственным инженерным выбором. Система, управляющая организационной памятью, должна быть предсказуемой, тестируемой и воспроизводимой.
Но каждый раз, когда я думаю о потенциальном интеллекте системы, агентная архитектура становится невероятно привлекательной. Способность динамически исследовать контекст могла бы обнаруживать связи в истории решений, которые ни одно детерминированное правило поиска никогда не выявило бы.
Гибридная модель находится где-то посередине, но даже этот компромисс скрывает сложные trade-offs.
Какие поведения должны быть детерминированными? Какие — адаптивными? Где провести границу между исследованием и контролем?
Именно к этому вопросу я постоянно возвращаюсь, пока строю Git for Decisions.
Если мы хотим создать систему, которая помнит причины архитектурных решений в программном обеспечении, сколько рассуждения мы должны позволить самой системе выполнять?
Должна ли она вести себя как автономный исследователь, изучающий граф решений, пока не сформирует гипотезу?
Должна ли она вести себя как дисциплинированный pipeline компилятора, обрабатывающий входные данные строго контролируемым образом?
Или ей следует попытаться найти осторожный компромисс между любопытством и governance?
Прямо сейчас я, честно говоря, ещё не определился.
И поскольку многие из самых интересных идей об архитектуре программного обеспечения рождаются из коллективного обсуждения, а не из одиночных размышлений, мне любопытно, как другие подошли бы к этому вопросу.
Если бы вы проектировали систему, которая станет долгосрочной памятью инженерных решений, какой архитектуре вы бы доверяли больше?