Откройте репозиторий через полгода после выпуска функции — и вы сможете восстановить многое. Можно проследить архитектуру, изучить схему, прочитать тесты и точно увидеть, какие строки изменились.
Но обычно нельзя восстановить разговор, из-за которого эти строки вообще понадобились.
Код не скажет вам, что правило валидации существует потому, что один клиент отправляет некорректные выгрузки. Он не объяснит, что странная политика повторных попыток предотвращает дублирование транзакций в нижестоящей системе. Он не покажет, что более чистый интерфейс отклонили после теста на доступность, или что граница сервиса отражает контрактное ограничение, а не инженерное предпочтение.
Git отлично сохраняет историю кода. Намерение он сохраняет только тогда, когда команда сознательно фиксирует это намерение и поддерживает его связь с реализацией.
Этот разрыв всегда был частью разработки ПО. Инструменты ИИ для программирования делают его заметнее. Система может прочитать каждый файл в репозитории, проследить каждый символ и сгенерировать технически убедительный патч, но при этом решать не ту задачу.
Проблема не в том, что код вводит в заблуждение. Код просто отвечает на более узкий вопрос.
Пять уровней инженерной правды
Большинство значимых изменений в ПО зависят от пяти разных уровней свидетельств.
- Намерение — Какого результата просит пользователь, клиент или бизнес? Это может быть зафиксировано в спецификации, тикете, разговоре с поддержкой или заметке со встречи.
- Ограничения — Что не должно сломаться? Обязательства по совместимости, границы безопасности, регуляторные требования, контракты, бюджеты и сроки часто находятся вне репозитория.
- Реализация — Как система работает сегодня? Этот уровень дают код, тесты, схемы, зависимости и конфигурация развертывания.
- Свидетельства времени выполнения — Что происходит в реальной системе? Логи, трассировки, метрики, данные из production и отчеты об инцидентах могут противоречить предположениям, которые в коде выглядят разумными.
- История решений — Почему был выбран текущий подход? Ответ хранят pull request’ы, обсуждения дизайна, отвергнутые альтернативы и предыдущие инциденты.
Репозиторий сильнее всего в третьем уровне. Он содержит части остальных, но редко в объеме, достаточном для их полного представления.
Это важно, потому что сбои в ПО часто проявляются на границах между уровнями. Реализация соответствует устаревшей спецификации. Исправление закрывает тикет, но нарушает операционное ограничение. Тесты проходят, потому что в них зашиты вчерашние предположения. Код внутренне согласован, тогда как данные в production следуют шаблону, который никто не задокументировал.
Локально корректный патч все равно может оказаться неправильным изменением.
На какие вопросы репозиторий сам по себе ответить не может
Представьте пользователя, который редактирует документ, а затем ищет обновлённое предложение, но в результатах видит старую версию. «Сделайте так, чтобы поиск обновлялся сразу» звучит как вполне понятный запрос. Репозиторий показывает несколько возможных точек, с которых можно начать, но сам по себе не может определить, какое исправление будет правильным.
| Вопрос | Вероятный источник |
|---|---|
| Какая версия документа является авторитетной? | Исходный документ и история изменений |
| Где остаётся старый текст? | Логи синхронизации, результат извлечения, поисковый индекс или кэш |
| Что означает «сразу» для этого продукта? | Обещание продукта или целевой уровень сервиса |
| Изменились ли права доступа к документу вместе с его содержимым? | Исходные права доступа и история аудита |
| Ограничивается ли устаревший результат одним пользователем, источником или регионом? | Трассировки запросов и метрики production |
Код поиска может объяснить, как возвращаются результаты. Но он не скажет, в чём на самом деле проблема: в задержке синхронизации, устаревшем извлечении, инвалидации кэша, распространении прав доступа или в ожидании, которое продукт вообще никогда не определял.
В зрелых системах это различие становится ещё важнее. Поле, которое выглядит устаревшим, всё ещё может поддерживать legacy-клиент. Сервис, похожий на дубликат, может разделять данные с разными требованиями к правам доступа. Проверка, которая кажется избыточной, может быть единственным следом на уровне кода от инцидента в production, которого текущая команда никогда не видела.
Убирать сложность — ценно. Убирать историю, замаскированную под сложность, — дорого.
Даже больше контекста всё равно может привести к неправильному ответу
Очевидное решение — дать ИИ больше материала: весь репозиторий, каждый тикет, каждый документ, каждое сообщение и каждый лог.
Это даёт доступ, а не понимание.
Источники могут быть устаревшими, противоречивыми, спекулятивными или написанными для разных аудиторий. Результаты брейншторма не должны иметь больший вес, чем утверждённая спецификация. Требование шестимесячной давности не должно молча отменять вчерашнее решение по продукту. Лог production должен быть привязан к релизу, окружению и пути кода, который его породил. Запрос клиента не следует считать универсальным требованием без проверки его области действия.
Поэтому серьёзной системе контекста нужно нечто большее, чем просто retrieval. Ей нужен способ рассуждать о следующем:
- Авторитетность: Какому источнику разрешено определять требование?
- Актуальность: Какая информация является текущей, а что уже заменено?
- Происхождение: Откуда взялось каждое утверждение, ограничение или вывод?
- Связи: Какие issue, релиз, клиент, набор данных и путь кода относятся друг к другу?
- Права доступа: Какие источники можно использовать для этой задачи и показывать этому человеку?
Контекст — это не куча токенов. Это граф со временем, авторитетностью и границами.
Больше контекста должно давать больше подтверждений, а не больше уверенности без подтверждений.
Настоящая единица работы — это изменение
Редакторы и инструменты для программирования организованы вокруг файлов, потому что именно файлы мы изменяем. Инженерные команды организованы вокруг изменений.
Изменение начинается с причины. Затем оно превращается в требование, затрагивает код и данные, проходит ревью, попадает в production и создаёт новые свидетельства. Если эти этапы остаются разрозненными, каждая будущая задача начинается с очередного раунда археологии.
Система ИИ, работающая с реальным программным обеспечением, должна следовать этому жизненному циклу.
До реализации она должна определить запрос, релевантные ограничения и любые конфликтующие источники. Она должна понимать, исправляет ли она дефект, меняет ожидаемое поведение или вводит новый контракт.
Во время реализации она должна связывать каждый значимый выбор с подтверждающими данными. Почему этот модуль? Почему эта стратегия миграции? Почему нужно сохранить эту ветку? Объяснение должно пережить чат, в котором был создан код.
После внедрения система должна прикреплять к изменению результаты проверки, решения по ревью и вновь выявленные ограничения. Иначе следующему человеку — или следующей сессии AI — придется заново их восстанавливать.
В этом и состоит разница между инструментом, который умеет редактировать репозиторий, и системой, способной участвовать в инженерной работе.
AI должен сокращать объем реконструкции, а не устранять необходимость в суждении
Более качественный контекст иногда преподносят как путь к автономной разработке ПО. Но его непосредственная ценность менее драматична и гораздо полезнее: он снижает стоимость восстановления реальной картины перед внесением изменений.
AI может вывести исходное требование рядом с релевантным кодом. Он может показать инцидент, который объясняет необычную защитную меру. Он может связать падающую метрику с релизом, который ее изменил. Он может еще до начала реализации показать, что два авторитетных источника противоречат друг другу.
Эти возможности не устраняют необходимость в инженерном суждении. Они делают его более обоснованным.
Человек по-прежнему должен решать, какой компромисс приемлем, является ли требование полным и какой уровень риска может нести релиз. Система должна делать доказательную базу видимой, а ход рассуждений — проверяемым. Она не должна скрывать неопределенность за отполированным патчем.
Критерий не в том, «умеет ли это генерировать код?»
Критерий в том, «может ли это объяснить, почему именно это изменение правильно сейчас?»
От понимания репозитория к пониманию работы
Помощники для программирования впервые стали полезными, когда научились понимать файл, открытый перед разработчиком. Следующим крупным шагом стало понимание репозитория: поиск связанного кода, отслеживание символов и внесение изменений по всему проекту.
Следующий шаг — понимание работы вокруг репозитория.
Это означает связывать код со спецификацией, которая его запросила, с обсуждением, которое ее уточнило, с производственными данными, которые поставили ее под сомнение, и с решением, которое затем следует сохранить в памяти. Это также означает исключать контекст, который не относится к делу, устарел или находится вне пользовательских прав доступа.
Пока мы создаем Dvina, это одна из идей, к которым мы постоянно возвращаемся. Работа не происходит внутри одного файла, приложения или разговора. Смысл живет в связях между ними и в том, как эти связи меняются со временем.
Репозиторий по-прежнему остается критически важным. Это исполняемый источник истины о поведении системы. Просто он не является полным источником истины о замысле продукта, операционной реальности или организационной памяти.
Полная картина меняет то, что в итоге создается
Когда есть только код, естественный вопрос звучит так:
Какое изменение подходит этой системе?
При более широком контексте вопрос становится таким:
Какое изменение подходит этой системе, этому требованию, этой истории и этому моменту?
Этот второй вопрос помогает выявить ограничения до того, как они обернутся регрессиями. Он дает ревьюерам понимание логики, стоящей за реализацией. Он помогает новым участникам команды понять, почему система устроена именно так. Он отводит ИИ обоснованную роль: не оракул внутри редактора, а участник, способный собирать подтверждения по всей работе.
Ваш репозиторий никогда не был всей историей.
Возможность в том, чтобы строить системы, способные прочитать все остальное — и показать ход своей работы.
