Когато изкуственият интелект пише код: Спецификациите се нуждаят от стратегия за изход
Изображение: Svetni.me / ИИ генерирано изображение
Според публикация на Маркус Айзеле в блога му The Main Thread [1], препубликувана и разширена от O'Reilly Radar [2], екипите, разработващи софтуер с ИИ агенти, се изправят пред нов сериозен проблем. Отворите ли едно софтуерно хранилище след шест месеца активна разработка, базирана на спецификации, е много вероятно да откриете паралелна система от документи, разположена непосредствено до кода [1, 2]. Тя включва изисквания, бележки от изследвания, дизайни от високо и ниско ниво, планове за изпълнение, списъци със задачи и доклади от прегледи – огромно количество Markdown файлове, описващи кода [1].
Основното предизвикателство в този подход е бързото остаряване на документацията: кодът се променя непрекъснато, но документите до него остават статични [1, 2]. Тъй като автономните агенти генерират софтуер с изключително висока скорост, инженерите се опитват да изместят мисловния процес пред самото внедряване [1]. Това обаче бързо се превръща в тромав работен процес с десетки етапи и прекомерно количество генериран текст, който запълва по-голямата част от контекстния прозорец на модела, преди той изобщо да е прочел съответния софтуерен клас [1, 2].
Изображение: Svetni.me / ИИ генерирана инфографика
Подобна документация на естествен език е слаба система за синхронизиране на кодова база [2]. Без допълнително внимание и старание, софтуерните агенти бързо пренасочват вниманието си от текстовите изисквания към по-силните сигнали в самия код, като в крайна сметка спират да обновяват спецификацията [2]. Грешката е в разглеждането на спецификацията като постоянна текстова версия на софтуера [1]. Полезната спецификация описва следващата промяна, разкрива важните решения и дава повърхност за проверка, но след като промяната бъде внедрена, по-голямата част от нея трябва да изчезне [1, 2].
Кодът е реалността
Програмният код представлява действителното поведение на системата [1, 2]. След като това поведение достигне до реална експлоатация, потребителите и свързаните системи започват да зависят от него [1]. Всяка техническа грешка може да се превърне в наблюдаван договор, просто защото е работила по този начин в продължение на три години [1, 2]. Когато възникне срив, поведението на работещата система има много по-голямо значение от дизайна, който е описвал нещо съвсем различно [1].
Разбира се, съществуващият код сам по себе си не може да определи какво трябва да прави следващата версия на софтуера [1, 2]. Той не съдържа информация кои политики са променени, кои регулаторни изисквания (например седемгодишно съхранение на данни) трябва да се приложат или защо определен експорт се изпълнява всяка вечер за конкретен клиент [1, 2]. Този контекст трябва да дойде от външен източник [1]. Това обаче не изисква поддържането на постоянна проза за цялата система, а само достатъчно контекст, за да дефинираме разликата (делтата) между настоящото и бъдещото състояние [1, 2].
Спецификации само за промяната
Временната спецификация, която е по-подходящо да се нарича „описание на промяната“ (change brief), оправдава своите разходи, когато помага на екипа да дефинира и прегледа тази делта [2]. Тя трябва да съдържа целевия резултат, не-целите, ограниченията, които се различават от текущото поведение, известните неизвестни и нужните доказателства за приемане [1, 2]. Техническият дизайн има място там само ако промяната пресича архитектурни граници или съдържа решения, които ще бъдат скъпи за отмяна [1, 2].
Опитът с изчерпателните спецификации в миналото – чрез папки с документация за изискванията, архитектурата и дизайна – демонстрира същите негативни ефекти, които виждаме и днес при работата с ИИ агенти [2]. Този подход на проектиране тип „водопад“ създава пълна в административно отношение документация, която е практически безполезна за инженерните нужди [2]. Когато ИИ агентите се сблъскат с прекомерно количество текстови документи, те лесно възпроизвеждат същите хаотични резултати [2].
Особено голям риск възниква, когато екипите позволяват на самите агенти да генерират първоначалната версия на спецификацията [2]. Дългите автоматизирани процеси създават огромно количество материали за преглед и одобрение, които трудно се поддържат кохерентни [2]. Тъй като за моделите все още е трудно да извлекат реална последователност от хаоса, те могат да фокусират вниманието си върху повтарящи се думи, което увеличава тежестта върху човека, извършващ прегледа на кода [2]. Допълнителна проза под формата на бележки от изследвания и прототипи трябва да се добавя само когато несигурността го налага, но не и като задължителен етап за всяка заявка за сливане (pull request) [2].
Дълготрайни факти в техния естествен формат
Преобразуването на всяко решение в Markdown файл води до същия проблем с остарялата документация [2]. Софтуерното инженерство вече разполага с по-ефективни формати за поддържане на трайните факти [1, 2]:
API съвместимостта и формата принадлежат на OpenAPI, AsyncAPI, схеми за протоколи, типове и тестове за съвместимост.
Инвариантите на данните принадлежат на типовете системи, ограниченията в базите данни (database constraints) и проверките при миграция.
Правилата за сигурност принадлежат на политиките за достъп, статичния анализ, политиките за зависимости и рантайм защитите.
Архитектурните граници принадлежат на модулната структура, правилата за зависимости и специализираните архитектурни тестове.
Изискванията за надеждност принадлежат на тестовете за натоварване, SLOs, телеметрията и алармите.
Правилата за пускане на версии принадлежат на процесите за непрекъсната интеграция и политиките за внедряване.
Тези артефакти са естествена част от софтуерната доставка [2]. Счупена схема или задействана аларма изискват незабавно поправяне от екипа, докато неточен абзац в стара папка с документация лесно може да бъде пренебрегнат [2]. Естественият език има своето място главно за бизнес политики и архитектурни обосновки (като архитектурните решения – ADR), разположени близо до съответния код [2]. Записването на всяко локално техническо решение само скрива важните избори и обърква агентите, които трябва да изграждат софтуера [2].
Съобразяване на процеса с риска
Опитите за контрол на качеството чрез налагане на еднакъв тежък процес за всяка промяна – независимо дали става дума за корекция на текст или промяна в платежния поток – са неефективни [2]. По-добрият подход е на агента да се даде крайният резултат и той сам да прецени колко процес изисква съответната задача [2]. ИИ агентите трябва да работят в рамките на ясни граници: дефинирани от екипа цели, ограничения за безопасност, собственост и правила за приемане на резултатите [2].
Спрямо този модел софтуерният процес се адаптира според риска на задачата [2]:
Малка и позната промяна: преминава директно от кратко описание към внедряване и ревю на код.
Непознат код: изисква предварително проучване на кодовата база и зареждане на контекст за агента.
Неясен потребителски интерфейс: налага създаването на евтини прототипи за сравнение и потребителско изследване.
Архитектурна промяна: изисква изрично съгласуване и одобрение от инженерите в екипа.
Промяна с критични последствия (например финанси или сигурност): изисква независими доказателства, adversarial преглед и изрично човешко одобрение.
Контекстният прозорец като бюджет
Големите спецификации имат и друга скрита цена – те се конкурират с реалния код и доказателствата, от които агентът се нуждае за текущото решение [2]. Всяко допълнително изискване или дизайн бележка консумира част от ограничения контекстен прозорец на модела [1, 2]. Това води до загуба на моделно внимание и затруднява спазването на важните правила, когато те са заобиколени от стара или дублирана информация [2].
Решението е прогресивното разкриване на информация [2]. Екипите трябва да предоставят на агента малка карта с общи правила и насоки за дълбоко проучване [2]. Например, кратък файл AGENTS.md може да документира командите за компилация и архитектурните граници, без да дублира API документацията [2].
Практиката с процесите от типа „Проучване-Планиране-Изпълнение“ (Research-Plan-Implement) показва, че когато плановете достигнат хиляда реда, инженерите започват да преглеждат плановете, а генерирания код приемат сляпо [2]. Тъй като реалното изпълнение често се отклонява от одобрения план, разработчиците в крайна сметка трябва да реконструират решенията директно от кода [2]. Преминаването към по-малки контексти за проучване, дизайн, изпълнение и ревю дава много по-висока сигурност и контрол върху генерирания софтуер [2].
Модернизацията изважда това на преден план
Всяко софтуерно приложение съдържа наслоявания от различни периоди: трайна бизнес логика, остарели технически ограничения, минали корекции на инциденти и дори дефекти, които с времето са започнали да изглеждат като умишлено поведение [2]. Ако ИИ агентът третира целия заварен код като целева спецификация, той вярно ще пренесе всички тези дефекти и остарели подходи в новата архитектура [2].
Оценката на наследени проекти (brownfield) изисква класифициране на поведението [2]:
Запазване на трайните бизнес инварианти и външно изискваните интерфейси.
Проверка на активно поведение, което няма ясна собственост или тестове.
Редизайн на логика, обвързана с остарели архитектурни ограничения.
Премахване на мъртъв код, дублирана логика и потвърдени дефекти.
В тази фаза статичният анализ и покритието на кода не са достатъчни [2]. Препоръчително е използването на мутационно тестване (например PIT) за откриване на скрити предположения, както и анализирането на реални данни от телеметрията и експлоатационния контекст [2].
Малките спецификации все пак изискват реални доказателства
Преминаването към по-леки спецификации не означава завръщане към неясни инструкции и „код по усет“ (vibe coding) [2]. Изследванията показват, че директното изискване от моделите да разрешават неясноти в изискванията често води до непоследователни резултати [2]. Фокусираното изчистване на неясноти около конкретни дефекти (change brief) подобрява резултатите с приблизително 31% [2].
Проучванията със SWE-Bench показват, че когато един софтуерен агент генерира промяна, а друг има за задача да създаде тестове, които да я отхвърлят, прецизността на поправката се удвоява [2]. В същото време опитите за автоматично превеждане на естествен език във формални спецификации (като TLA+) дават едва 27% синтактична и 9% семантична коректност, което показва, че формалната нотация помага за откриване на грешки, но не гарантира точност [2]. Силата на доказателствата трябва да съответства на последствията от евентуална грешка, като се изисква разделение на отговорностите при промени с високи рискове [2].
Ефективният модел на работа се състои от пет прости стъпки [2]:
Стартирайте от съществуващия код и оперативните доказателства в работещата система.
Дефинирайте желания делта резултат, важните граници и известните неизвестни.
Добавете проучвания, прототипи или по-строги проверки само ако рискът го изисква.
Четете и преглеждайте реалното изпълнение на кода, а не само предварителния план.
При внедряване изхвърлете временните разсъждения и запазете фактите в техните естествени технически формати.
Тази структура предпазва екипите от създаването на текстови реплики на софтуера, които бързо се превръщат в технически дълг [2]. Истинската гъвкавост при работа с ИИ агенти идва от избирателността – да дефинираме какво трябва да се реши, да открием какво софтуерът може да отговори сам, да тестваме рисковете и да позволим на временното планиране да изчезне [2].
Източници:
[1]: Spec-Driven Development Needs an Exit Strategy - The Main Thread
[2]: When AI Writes the Code, Specifications Need an Exit Strategy - O'Reilly Radar