Відкрийте репозиторій через шість місяців після випуску функції — і ви зможете відновити багато чого. Можна простежити архітектуру, перевірити схему, прочитати тести й точно побачити, які рядки змінилися.
Чого зазвичай не вдається відновити, так це розмови, яка зробила ці рядки необхідними.
Код не скаже вам, що правило валідації існує тому, що один клієнт надсилає некоректні експорти. Він не пояснить, що дивна політика повторних спроб запобігає дублюванню транзакцій у нижчестоящій системі. Він не покаже, що чистіший інтерфейс відхилили після тесту на доступність, або що межа сервісу відображає контрактне обмеження, а не інженерну перевагу.
Git чудово зберігає історію коду. Намір він зберігає лише тоді, коли команда свідомо фіксує його письмово й підтримує його зв’язок із реалізацією.
Цей розрив завжди був частиною програмної інженерії. Інструменти ШІ для написання коду роблять його помітнішим. Система може прочитати кожен файл у репозиторії, простежити кожен символ і згенерувати технічно переконливий патч, але все одно розв’язувати не ту проблему.
Проблема не в тому, що код вводить в оману. Код відповідає на вужче запитання.
П’ять шарів інженерної правди
Більшість значущих змін у програмному забезпеченні залежать від п’яти різних шарів доказів.
- Намір — Якого результату хоче користувач, клієнт або бізнес? Це може бути зафіксовано у специфікації, тікеті, розмові зі службою підтримки або нотатці із зустрічі.
- Обмеження — Що не повинно зламатися? Обіцянки сумісності, межі безпеки, регуляторні вимоги, контракти, бюджети й дедлайни часто існують поза репозиторієм.
- Реалізація — Як система працює сьогодні? Код, тести, схеми, залежності та конфігурація розгортання формують цей шар.
- Робочі дані — Що відбувається в реальній системі? Логи, трейси, метрики, production-дані та звіти про інциденти можуть суперечити припущенням, які в коді виглядають цілком розумними.
- Історія рішень — Чому було обрано поточний підхід? Відповідь зберігається в pull request’ах, дизайн-обговореннях, відхилених альтернативах і попередніх інцидентах.
Репозиторій найсильніший у третьому шарі. Він містить частини інших, але рідко настільки повно, щоб представляти їх цілком.
Це важливо, тому що збої в програмному забезпеченні часто виникають на межах між шарами. Реалізація відповідає застарілій специфікації. Виправлення закриває тікет, але порушує операційне обмеження. Тести проходять, бо кодують учорашні припущення. Код внутрішньо узгоджений, тоді як production-дані йдуть за шаблоном, який ніхто не задокументував.
Локально коректний патч усе одно може виявитися неправильною зміною.
На які запитання репозиторій сам по собі не може відповісти
Уявімо користувача, який редагує документ, а потім шукає оновлене речення, але в результатах бачить стару версію. «Зробіть так, щоб пошук оновлювався негайно» звучить як цілком чіткий запит. Репозиторій показує кілька можливих точок, з яких можна почати, але сам по собі не може визначити правильне виправлення.
| Питання | Ймовірне джерело |
|---|---|
| Яка версія документа є авторитетною? | Вихідний документ та історія змін |
| Де саме залишається старий текст? | Журнали синхронізації, результат екстракції, пошуковий індекс або кеш |
| Що означає «негайно» для цього продукту? | Обіцянка продукту або цільовий рівень сервісу |
| Чи змінилися дозволи документа разом із його вмістом? | Вихідні дозволи та історія аудиту |
| Чи обмежується застарілий результат одним користувачем, джерелом або регіоном? | Траси запитів і метрики production |
Код пошуку може пояснити, як повертаються результати. Але він не скаже, чи справжня проблема полягає в затримці синхронізації, застарілій екстракції, інвалідації кешу, поширенні дозволів або в очікуванні, яке продукт узагалі ніколи не визначав.
У зрілих системах ця відмінність стає ще важливішою. Поле, яке виглядає застарілим, може й далі підтримувати legacy-клієнт. Сервіс, що здається дублем, може розділяти дані з різними вимогами до дозволів. Перевірка, яка на перший погляд видається надмірною, може бути єдиним слідом на рівні коду від інциденту в production, якого нинішня команда ніколи не бачила.
Прибирати складність — цінно. Прибирати історію, замасковану під складність, — дорого.
Більше контексту теж може дати хибну відповідь
Очевидне рішення — дати ШІ більше матеріалу: увесь репозиторій, кожен тікет, кожен документ, кожне повідомлення і кожен лог.
Це створює доступ, а не розуміння.
Джерела можуть бути застарілими, суперечливими, спекулятивними або написаними для різних аудиторій. Результати брейншторму не повинні мати вищий пріоритет, ніж затверджена специфікація. Вимога шестимісячної давності не повинна мовчки перекривати вчорашнє продуктове рішення. Лог production має бути прив’язаний до релізу, середовища та шляху коду, які його породили. Запит клієнта не слід вважати універсальною вимогою без перевірки його меж застосування.
Тому серйозній системі контексту потрібно більше, ніж просто retrieval. Їй потрібен спосіб міркувати про таке:
- Авторитетність: Яке джерело має право визначати вимогу?
- Актуальність: Яка інформація є поточною, а що вже втратило чинність?
- Походження: Звідки взялося кожне твердження, обмеження або висновок?
- Зв’язки: Які issue, release, customer, dataset і code path належать одне до одного?
- Дозволи: Які джерела можна використовувати для цього завдання і показувати цій людині?
Контекст — це не купа токенів. Це граф із часом, авторитетністю та межами.
Більше контексту має давати більше доказів, а не більше впевненості без доказів.
Справжня одиниця роботи — це зміна
Редактори й інструменти для програмування організовані навколо файлів, бо саме файли ми змінюємо. Інженерні команди організовані навколо змін.
Зміна починається з причини. Вона перетворюється на вимогу, зачіпає код і дані, проходить рев’ю, потрапляє в production і створює нові докази. Якщо ці етапи залишаються роз’єднаними, кожне майбутнє завдання починається з нового раунду археології.
Система ШІ, що працює з реальним програмним забезпеченням, має слідувати цьому життєвому циклу.
До реалізації вона має визначити запит, релевантні обмеження та будь-які суперечливі джерела. Вона має розуміти, чи виправляє дефект, чи змінює очікувану поведінку, чи запроваджує новий контракт.
Під час реалізації вона має пов’язувати кожне значуще рішення з доказами. Чому саме цей модуль? Чому саме така стратегія міграції? Чому зберегти саме цю гілку? Пояснення має жити довше, ніж чат, у якому було створено код.
Після впровадження вона має прикріплювати до зміни результати перевірки, рішення рев’ю та нововиявлені обмеження. Інакше наступній людині — або наступній AI-сесії — доведеться знову їх відтворювати.
У цьому й полягає різниця між інструментом, який може редагувати репозиторій, і системою, здатною брати участь в інженерній роботі.
AI має зменшувати потребу у відновленні контексту, а не усувати потребу в судженні
Кращий контекст іноді подають як шлях до автономної розробки програмного забезпечення. Його безпосередня цінність менш драматична, зате корисніша: зменшення вартості відновлення реальності перед внесенням змін.
AI може піднести початкову вимогу до релевантного коду. Він може показати інцидент, який пояснює незвичний запобіжний механізм. Він може пов’язати метрику, що погіршилася, з релізом, який її змінив. Він може показати, що два авторитетні джерела суперечать одне одному ще до початку впровадження.
Ці можливості не усувають потреби в інженерному судженні. Вони роблять його більш поінформованим.
Людина все одно має вирішити, який компроміс є прийнятним, чи є вимога повною і який рівень ризику може нести реліз. Система має робити докази видимими, а міркування — придатними до перевірки. Вона не повинна приховувати невизначеність за відполірованим патчем.
Критерій не в тому, «чи може вона генерувати код?»
Критерій у тому, «чи може вона пояснити, чому саме зараз це правильна зміна?»
Від обізнаності про репозиторій до обізнаності про роботу
Асистенти для кодування вперше стали корисними тоді, коли навчилися розуміти файл перед розробником. Обізнаність про репозиторій стала наступним великим кроком: пошук пов’язаного коду, відстеження символів і внесення змін у межах усього проєкту.
Наступний крок — це обізнаність про роботу навколо репозиторію.
Це означає пов’язувати код зі специфікацією, яка його запитувала, з розмовою, яка її уточнила, з продакшн-свідченнями, які поставили її під сумнів, і з рішенням, яке потім слід пам’ятати. Це також означає відсікати контекст, який є нерелевантним, застарілим або виходить за межі дозволів користувача.
Під час створення Dvina ми постійно повертаємося до цієї ідеї. Робота не відбувається всередині одного файлу, застосунку чи розмови. Сенс живе у зв’язках між ними та в тому, як ці зв’язки змінюються з часом.
Репозиторій залишається критично важливим. Це виконуване джерело істини про поведінку системи. Просто він не є повним джерелом істини щодо продуктового задуму, операційної реальності чи організаційної пам’яті.
Повна картина змінює те, що саме буде створено
Коли є лише код, природне запитання таке:
Яка зміна пасує цій системі?
За ширшого контексту запитання стає таким:
Яка зміна пасує цій системі, цій вимозі, цій історії та цьому моменту?
Саме це друге запитання дає змогу виявити обмеження ще до того, як вони перетворяться на регресії. Воно дає рев’юерам розуміння логіки, що стоїть за реалізацією. Воно допомагає новим учасникам команди зрозуміти, чому система має саме такий вигляд. Воно відводить AI обґрунтовану роль: не оракула всередині редактора, а учасника, який може зібрати докази з усього масиву роботи.
Ваш репозиторій ніколи не був усією історією.
Можливість полягає в тому, щоб будувати системи, здатні прочитати решту цієї історії — і показати хід своєї роботи.
