The_Specification_Paradox_Rethinking_Requirements_Engineering_in.pdf
The Specification Paradox: Rethinking Requirements Engineering in the Age of AI
Простая для восприятия статья поразмышлять о требованиях, но в которой есть несколько интересных моментов.
Думать все равно приходится:
Это то, с чем я вчера столкнулся, когда попытался быстро сделать скрипт для работы с метаданными репозитория, – 70GB памяти на обработку репозитория из 1000 коммитов, при этом функционально все отработало корректно. Проблема была в хранении всех данных всех диффов в памяти с последующим их копированием в последующие модули, при этом сами данные не нужны, нужны высчитанные на их основе значения. Важно то, что когда я спросил агента зачем ему столько памяти, он обоснованно ответил (но сразу стало понятно, что так делать не надо), когда же попросил его исправить, он исправил только в одном месте. В итоге понадобилось ему подробно объяснить алгоритм работы, буквально дизайн и тогда он все исправил, но при этом пришлось походить по коду, чтобы объяснить ему в терминах кода что и где менять, а была надежда на то, что в год залезать не придется.
В выводах то, вокруг чего сейчас много холиваров:
Таких ситуаций было значительно больше – пишешь требование, но агент понимает его по-своему, откатываешь изменения, исправляешь требования – он снова понимает немного не так, ограничиваешь, добавляешь деталей и так, пока не получишь нужный результат. У агента при этом есть память, но чтобы она работала на развитие навыка, нужно не откатывать и писать заново, а использовать roll-forward, – добиваться нужного результата через Change Request’ы, что безумно утомительно. Однако, в большей степени зависит от механизма накопления знаний, но цикл в любом случае должен замкнуться каким-то подкреплением.
Если выйти за пределы статьи, то для себя сделал чуть более широкий вывод, что узкое место – не просто качество изначальных требований, но и стоимость превращения обнаруженной ошибки в устойчивое ограничение для следующих итераций.
Простая для восприятия статья поразмышлять о требованиях, но в которой есть несколько интересных моментов.
Думать все равно приходится:
The distribution of human effort also changes. Using eye tracking and interaction monitoring, [13] found that developers working with LLM-generated code devote substantial cognitive effort to understanding, inspecting, validating, and correcting generated solutions. Automatic generation therefore does not eliminate human work; it shifts part of that work from implementation toward supervision and evaluation.
Это то, с чем я вчера столкнулся, когда попытался быстро сделать скрипт для работы с метаданными репозитория, – 70GB памяти на обработку репозитория из 1000 коммитов, при этом функционально все отработало корректно. Проблема была в хранении всех данных всех диффов в памяти с последующим их копированием в последующие модули, при этом сами данные не нужны, нужны высчитанные на их основе значения. Важно то, что когда я спросил агента зачем ему столько памяти, он обоснованно ответил (но сразу стало понятно, что так делать не надо), когда же попросил его исправить, он исправил только в одном месте. В итоге понадобилось ему подробно объяснить алгоритм работы, буквально дизайн и тогда он все исправил, но при этом пришлось походить по коду, чтобы объяснить ему в терминах кода что и где менять, а была надежда на то, что в год залезать не придется.
В выводах то, вокруг чего сейчас много холиваров:
Generative artificial intelligence is transforming Software Engineering by automating the generation of code and other software artifacts. Yet it does not eliminate the essential complexity described by [3]; rather, it redistributes engineering effort from implementation toward domain understanding, specification, validation, and software evolution.
This shift underlies the Specification Paradox: the more capable AI systems become at generating software, the greater the dependence on high-quality
human-produced specifications. As specifications increasingly guide automated generation, their quality directly affects the reliability and alignment of generated artifacts. Rather than diminishing RE, AI may therefore strengthen its strategic role.
Таких ситуаций было значительно больше – пишешь требование, но агент понимает его по-своему, откатываешь изменения, исправляешь требования – он снова понимает немного не так, ограничиваешь, добавляешь деталей и так, пока не получишь нужный результат. У агента при этом есть память, но чтобы она работала на развитие навыка, нужно не откатывать и писать заново, а использовать roll-forward, – добиваться нужного результата через Change Request’ы, что безумно утомительно. Однако, в большей степени зависит от механизма накопления знаний, но цикл в любом случае должен замкнуться каким-то подкреплением.
Если выйти за пределы статьи, то для себя сделал чуть более широкий вывод, что узкое место – не просто качество изначальных требований, но и стоимость превращения обнаруженной ошибки в устойчивое ограничение для следующих итераций.