В формирующейся парадигме «Водопад 2.0» разработка программного обеспечения становится более структурированной и фазово-управляемой. Каждая фаза стабильна и четко определена — почти как производственная линия или сборочная линия — но общий процесс остается итеративным. Большие языковые модели (LLM) теперь выступают в качестве автоматизированных «членов команды» в этом процессе, помогая экспертам в предметной области на каждом этапе. В результате традиционные артефакты — записи архитектурных решений (ADR), руководства по коду/стилю, документы для новых сотрудников, планы тестирования, конфигурации CI/CD, спецификации API, контрольные списки безопасности и т. д. — должны эволюционировать. В этом рабочем процессе, дополненном ИИ, эти документы становятся как входными данными, так и выходными данными ИИ, помогая направлять генерацию и сохранение знаний. Лучшая практика — хранить их как контролируемые версии, читаемые человеком файлы (например, Markdown в основном репозитории), позволяя ИИ помогать создавать и поддерживать их контент.
Записи архитектурных решений (ADR)
ADR фиксируют «контекст, решение и последствия» для каждого важного архитектурного выбора. В рабочем процессе Waterfall 2.0 ADR остаются критически важными — они обеспечивают прозрачность и долгосрочную прослеживаемость, — но LLM могут значительно упростить их создание. На практике команды часто используют итеративный процесс на основе подсказок для составления ADR с помощью ИИ. Например:
Предоставьте контекст и параметры: архитектор предоставляет подробный контекст проекта и просит LLM (например, GPT-4) перечислить несколько приемлемых вариантов решения с плюсами и минусами.
Выберите и уточните решение: после того, как команда (или ведущий разработчик) выберет лучший вариант, они предлагают LLM написать четкое решение и обоснование.
Опишите последствия: затем LLM просят перечислить последствия (что становится проще или сложнее, требуемые изменения), часто форматируемые в виде маркеров для ясности.
Финальная проверка работоспособности: Наконец, «перепроверка» - запрос к LLM перепроверить, нет ли лучшей альтернативы, чтобы убедиться, что ничего не упущено.
Этот цикл очень быстро выдает отполированный черновик ADR. Практикующие специалисты сообщают, что ИИ может справиться с утомительными частями (грамматикой, согласованностью, форматированием), позволяя архитекторам сосредоточиться на стратегии. Как описывает один блог, генеративный ИИ «быстро создает начальные черновики ADR, позволяя нам больше сосредоточиться на стратегическом мышлении, а не на ручной документации». По сути, LLM обеспечивает ясность и согласованность во всех ADR, уменьшая неоднозначность.
Тем не менее, человеческий надзор необходим. LLM зависят от качества входного контекста и могут галлюцинировать детали, поэтому архитекторы должны проверять и исправлять по мере необходимости. Эмпирические исследования подтверждают это: недавнее исследование показало, что GPT-4 может генерировать релевантные и точные проектные решения для ADR навскидку, хотя он «не дотягивает до производительности человеческого уровня». Другими словами, LLM вполне способны создать содержание ADR, но архитекторы должны проверить результат. В целом, роль артефакта ADR меняется: вместо того, чтобы быть написанным вручную с нуля, он часто создается совместно человеком и ИИ, а окончательная версия хранится (обычно в Markdown) под контролем версий.
Руководства по стилю кода и линтеру
Руководства по стилю для всей команды (соглашения по именованию, правила форматирования, передовые практики) обеспечивают согласованность кода. В рабочем процессе с использованием ИИ эти руководства предназначены для двух аудиторий: разработчиков-людей и LLM, генерирующих код. Лучшая практика — формализовать правила стиля в машиночитаемой форме и проверять их автоматически. Например, инструмент с открытым исходным кодом GPTLint демонстрирует этот подход: правила стиля пишутся в Markdown и используются линтером ИИ. В списке его функций с гордостью отмечается поддержка «простого формата markdown для правил» и простая настройка соглашений о кодировании, специфичных для проекта. Это означает, что команды могут кодифицировать передовые практики высокого уровня (например, «без глобальных переменных», «использовать snake_case для имен файлов») в простых файлах Markdown, а GPTLint предложит LLM отметить нарушения или даже предложить исправления.
На практике команда будет хранить свое руководство по стилю (и любые конфигурации ESLint/Prettier) в репозитории, рассматривая их как код. LLM (или инструменты вроде Copilot) могут быть приглашены следовать этим правилам при генерации кода, а скрипты CI могут запускать линтеры на основе ИИ для новых коммитов. Это дополняет традиционный статический анализ: в то время как ESLint или clang-format обрабатывают синтаксис, инструменты ИИ могут обеспечивать дух руководства (шаблоны более высокого уровня, архитектурные соглашения). Независимо от этого, применяется философия docs-as-code: руководства по стилю должны находиться в системе управления версиями как Markdown (например, STYLEGUIDE.md), чтобы все — и люди, и ИИ — видели один и тот же источник истины. Использование форматов открытого текста также упрощает включение этих правил в подсказки LLM или базы знаний, если это необходимо.
Документация по адаптации и разработчикам
Документация по адаптации (обзоры проектов, руководства по настройке, архитектурная документация) традиционно помогает новым членам команды освоиться. В небольшой команде + ИИ, роль документации по адаптации меняется, но она остается важной. Вместо статического руководства, которое человек читает от корки до корки, представьте себе интерактивного помощника по адаптации, управляемого ИИ. ИИ может автоматически обновлять и персонализировать контент для адаптации. Например, в одном из отраслевых обсуждений подчеркивается, что инструменты ИИ могут анализировать, какие вопросы по документации возникают (например, через форумы или системы отслеживания ошибок) и поддерживать актуальность документов. На практике:
Автоматические обновления: агент ИИ может сканировать часто задаваемые вопросы по проекту и изменения кода, чтобы отмечать устаревшие инструкции и даже восстанавливать разделы документов. Это гарантирует, что «отсутствующая документация будет оперативно выявлена и обновлена», поэтому новые сотрудники всегда будут видеть точную информацию.
Персонализированные пути обучения: оценивая опыт разработчика и конкретные требования проекта, ИИ может курировать индивидуальный контрольный список адаптации. Например, он может пропустить разделы о технологиях, которые разработчик уже знает, и вместо этого сосредоточиться на соответствующих компонентах.
Преимущества очевидны: онбординг с использованием ИИ обещает сокращение времени наращивания и более высокую удовлетворенность. На практике команда должна по-прежнему поддерживать базовый README или wiki (в Markdown), описывающий настройку, архитектуру и рабочие процессы — это «основная правда», передаваемая ИИ. Но рутинные обновления и вопросы и ответы могут обрабатываться напарником ИИ. Подводя итог, онбординговые документы становятся живой базой знаний, которую агенты ИИ могут запрашивать и дополнять, а не статичной папкой на полке.
Стратегии тестирования и автоматическая генерация тестов
Традиционный документ стратегии тестирования описывает, что тестировать (модуль против интеграции против E2E), цели тестового покрытия и процессы. В мире Waterfall 2.0 характер тестирования меняется: LLM могут автоматически генерировать тестовые случаи. Несколько инструментов уже иллюстрируют это:
Генерация модульных тестов на основе ИИ: плагин TestSpark от JetBrains (для IntelliJ) объединяет несколько методов генерации тестов, включая LLM. Он «отправляет запросы разным LLM» (OpenAI, Google и т. д.) для создания модульных тестов для кода Java/Kotlin и автоматически проверяет, являются ли тесты допустимыми, прежде чем показывать их пользователю. По сути, ИИ составляет черновики модульных тестов, которые просматривает разработчик.
Инструменты автоматизированного покрытия: Cover-Agent от CodiumAI — это инструмент CLI с открытым исходным кодом, который использует ИИ для написания модульных тестов и повышения покрытия кода. В его описании прямо указано, что он «автоматически генерирует квалифицированные тесты для улучшения существующих тестовых наборов». На практике вы указываете Cover-Agent на исходные файлы, и он создает тестовые файлы, нацеленные на желаемое покрытие.
Эти примеры показывают, что LLM могут брать на себя повторяющиеся хлопоты по тестированию. В результате документ стратегии тестирования может сместить фокус. Вместо перечисления каждого тестового случая он может указывать цели высокого уровня (например, «тестировать модули X, Y, Z для граничных условий, имитировать внешние вызовы API, достичь покрытия ≥80%»). Подробные реализации тестов часто генерируются ИИ на лету. Тем не менее, разумно хранить вашу стратегию и планы (в Markdown) в репозитории. Это гарантирует, что тесты, сгенерированные ИИ, можно будет отследить до задокументированного требования, и что процесс проверки человеком в рабочем процессе будет понятным.
Конвейеры и конфигурации CI/CD
Конфигурации CI/CD (Jenkinsfiles, GitHub Actions/YAML, Dockerfiles и т. д.) уже являются артефактами «кода» и должны продолжать существовать в репозитории. LLM могут помочь в написании или улучшении этих конвейеров. Например, вы можете попросить ИИ сгенерировать новый рабочий процесс GitHub Actions с учетом типа проекта, а затем вручную его доработать. Что еще важнее, ИИ может быть встроен в сам процесс CI/CD. Инструменты на основе ИИ могут анализировать каждый коммит или запрос на извлечение:
Сканирование качества кода: инструменты ИИ (например, анализаторы машинного обучения SonarQube, DeepCode или AWS CodeGuru) могут обнаруживать ошибки, проблемы безопасности или производительности в рамках сборки. Эти шаги «автоматизированной оценки качества кода» используют машинное обучение для выявления проблем, которые могут пропустить простые линтеры на основе регулярных выражений.
Умный выбор тестов: модели ИИ могут оптимизировать наборы тестов — например, выбирая наиболее важные тесты для измененного кода, сокращая время выполнения конвейера.
В medium были описаны эти варианты использования ИИ CI/CD, отметив, что ИИ может определять «ошибки, уязвимости и узкие места производительности» и может «выбирать и расставлять приоритеты тестовых случаев». На практике держите свои сценарии CI/CD под контролем версий (в YAML, Dockerfiles и т. д.), как всегда. Отличие Waterfall 2.0 в том, что вы также можете поддерживать «шаги ИИ» в конвейере (например, фазу проверки ChatGPT или инструмент анализа безопасности). Но по сути эти определения конвейера — это всего лишь артефакты кода в репозитории, просматриваемые с помощью коммитов и PR, как и любые другие.
Спецификации и документация API
API обычно документируются с помощью спецификаций OpenAPI/Swagger/Protobuf или подобных. LLM могут помочь здесь, создавая или обновляя спецификации API. Например, один разработчик продемонстрировал подачу существующей документации разработчика в модель в стиле GPT для создания полной спецификации OpenAPI JSON для эндпоинта API. Идея состоит в том, чтобы запросить LLM с соответствующим содержимым документа и шаблоном, и он выдаст действительный файл Swagger/YAML. Это может изменить правила игры, когда Swagger API еще не написан: ИИ выводит конечные точки, параметры и ответы из комментариев или примеров.
На практике продолжайте хранить ваши официальные файлы спецификаций API (YAML/JSON) в репозитории под контролем версий, в идеале вместе с кодом или в папке docs. LLM можно использовать для повторной генерации или сравнения спецификации при изменении кода. Например, у вас может быть шаг, который просит ИИ просмотреть пулл реквест и обновить файл OpenAPI, если он обнаружит новый ендпоинт. Аналогично, вы можете использовать «вызов функций» LLM (поддерживаемый некоторыми моделями) для сопоставления функций кода с определениями API. Но всегда проверяйте вывод ИИ.
Контрольные списки безопасности и анализ
Артефакты безопасности — контрольные списки, модели угроз, конфигурации сканирования уязвимостей — также адаптируются в рабочем процессе, управляемом ИИ. LLM могут помочь в проверках безопасности, выявляя распространенные уязвимости. Например, GitHub Copilot Chat может анализировать код и отмечать такие проблемы, как XSS, SQL-инъекции и CSRF, и даже предлагать исправления. Это означает, что LLM может выступать в качестве автоматизированного рецензента вашего контрольного списка безопасности.
Команды по-прежнему должны поддерживать основной контрольный список безопасности (например, OWASP Top 10, политика обновления зависимостей) в форме разметки и версионировать его. Однако инструменты ИИ могут помочь поддерживать его в актуальном состоянии. Задайте LLM вопрос «Учитывая эту новую библиотеку, есть ли в ней какие-либо известные уязвимости?» или «Предложить обновления для нашего контрольного списка на основе OWASP 2025» и соответствующим образом его уточнить. В CI вы можете запускать сканеры секретов или анализаторы на базе ИИ (например, CodeQL с машинным обучением) для каждого коммита. Итог: документы по безопасности становятся живыми знаниями для ИИ, и ИИ помогает обеспечивать их соблюдение.
Управление и хранение артефактов (Docs-as-Code)
Независимо от участия ИИ, лучшей практикой является рассмотрение всех артефактов команды как кода. Это означает хранение их в текстовых форматах (Markdown, YAML, JSON) под контролем версий вместе с исходным кодом. Философия docs-as-code (теперь основная в DevOps) применяется напрямую. Например, у вас может быть папка /docs или выделенный ARCHITECTURE.md, STYLEGUIDE.md, ONBOARDING.md, TESTING.md и т. д. Это гарантирует, что изменения в документах будут отслеживаться с помощью коммитов/PR, и их можно будет предварительно просматривать с помощью статических инструментов сайта.
Markdown особенно универсален: его легко редактировать людям и усваивать LLM. Агенту ИИ можно предоставить ваши файлы разметки в качестве контекста (через Retrieval-Augmented Generation или путем разделения на подсказки), чтобы модель «знала» ваши правила и историю. Некоторые проекты даже индексируют документы в векторной базе данных, чтобы LLM мог запрашивать их по требованию. Но даже без причудливых инструментов основная идея заключается в том, чтобы сохранить единый источник истины для каждого артефакта в коде. Руководства по стилю и шаблоны ADR (как часто рекомендуется) уже обычно хранятся как разметка в репозиториях. Продолжайте эту практику: она оптимизирует совместную работу, поддерживает точность и интегрируется с вашим рабочим процессом Git.
Артефакты в рабочем процессе небольшой команды + ИИ
Когда один разработчик или очень маленькая команда работает с агентами ИИ, цель артефактов меняется. В больших командах эти документы в первую очередь передают знания между людьми. В сценарии «один человек + ИИ» артефакты становятся частью базы знаний ИИ и контрольного журнала. Например, руководство по стилю больше не является просто PDF-файлом для разработчиков — это директива, которой ИИ должен следовать при генерации кода. ADR становятся подсказываемой историей: разработчик может спросить ИИ: «Основываясь на наших ADR, как нам расширить архитектуру для этой функции?» ИИ может извлекать соответствующие записи и рассуждения.
На практике это означает постоянное обновление документов до или во время изменений кода. Каждый артефакт (ADR, политика, план тестирования и т. д.) можно рассматривать как подсказку для LLM. Разработчик может подсказать LLM: «Вот наш контрольный список безопасности и новый код; соответствует ли он требованиям?» или «Создайте модульные тесты для этой функции в соответствии с нашей стратегией тестирования». Выходные данные ИИ (сгенерированный код, тесты, даже предложения) затем возвращаются в репозиторий.
Таким образом, даже при сокращении команд артефакты не исчезают — они становятся более важными как опорные точки для ИИ. Роль разработчика включает управление этими артефактами и руководство ИИ с их помощью. Например, вы можете встроить указатель на STYLEGUIDE.md в начало подсказки, чтобы ИИ знал, каким соглашениям кодирования нужно следовать. «Роль» ИИ фактически расширяет команду, и она полагается на эти артефакты так же, как это делал бы новый человек.
Заключение
ИИ не устраняет эти артефакты — он трансформирует их использование. Они остаются единственным источником истины и документации, но модель взаимодействия меняется. Артефакты становятся подсказками и контекстом для ИИ, а ИИ помогает генерировать и обновлять их. Это делает рабочий процесс настоящим циклом обратной связи: люди пишут и версионируют политики (в Markdown), ИИ читает и применяет или обогащает их, а люди просматривают вклад ИИ. На протяжении всего времени храните все артефакты в главном репозитории (или связанном репозитории документации) с использованием обычного текста. Это обеспечивает прослеживаемость и то, что ИИ и люди всегда «на одной странице».
Благодарности
PS. Спасибо мои друзьям и коллегам подтолкнувшим меня к компиляции в цикл статей наших разговоров на "перекурах". И конечно же ChatGPT "помогший" оформить тезисы в текст, насытив примерами и скорректировавший форматирование.
PPS. Оригинальный текст был размещён на линкед-ин
Waterfall 2.0 серия статей включает: