Современные ИИ-инструменты не отменили разработку программного обеспечения. Они изменили то, на что разработчик тратит время: рутинную реализацию всё чаще берет на себя ИИ, а человеку остается больше проектирования, исследований и контроля.
Как ИИ изменил работу разработчика
Работа программиста не сводилась только к сложным архитектурным решениям. Время тратилось на типовые задачи: написание похожего кода и тестов, подготовка конфигураций, изучение документации, рефакторинг и поиск ошибок.
Теперь часть этой работы можно передать ИИ. Разработчик описывает задачу, предоставляет правила проекта и примеры, получает реализацию и проверяет результат. Само написание кода занимает меньше времени, поэтому больше внимания можно уделять решениям до и после него.
Чем проще становится создать код, тем нужнее правильно определить, какой код нужен и подходит ли получившееся решение проекту.
Меньше времени уходит на типовой код
В каждом проекте встречаются задачи, которые требуют времени, но не требуют новых инженерных решений. Например, панели администратора, миграции, API-ресурсы, однотипные тесты или классы, построенные по уже принятому шаблону.
Раньше разработчик писал такую реализацию вручную. Теперь он определяет структуру решения, дать агенту примеры и описать ограничения проекта.
Рабочий цикл сокращается до нескольких этапов:
поставить задачу → получить реализацию → проверить → скорректировать.
Это не значит, что разработчику больше не нужно понимать код. Наоборот, быстро проверить результат можно только тогда, когда инженер представляет правильное решение и способен заметить ошибку.
Освободившееся время можно потратить на модель данных, границы компонентов, права доступа, интеграции, отказоустойчивость и дальнейшее развитие проекта.
ИИ снизил стоимость написания кода. Поэтому от проектирования и проверки кода в разработке итоговое качество программы стало зависеть куда больше.
Больше времени можно уделить проектированию
Неправильно спроектированная программа редко ломается сразу. Первые функции могут работать нормально, а проблемы появляются по мере развития проекта.
Новое требование начинает затрагивать разбросанные по проекту несвязные участки кода. Структура данных не поддерживает нужный сценарий. Права доступа не согласованы между собой. Изменение в пару строк ломает уже работающую функциональность.
ИИ сам по себе эту проблему не решает. Напротив, поставленная на конвейер генерация кода ускоряет и накопление неудачных решений.
Поэтому перед реализацией функции мы стараемся заранее определить сущности предметной области и связи между ними, ограничения, права доступа, состояния системы и поведение при ошибках.
После этого у агента остается меньше пространства для догадок, а результат проще проверить.
ИИ не уменьшил значение проектирования. Он сделал последствия неправильного проектирования заметнее, потому что реализацию теперь можно наращивать гораздо быстрее.
Проще исследовать альтернативные технологии
У любой команды есть знакомые и проверенные инструменты. Это снижает риски: разработчики знают их ограничения, умеют поддерживать инфраструктуру и быстрее решают возникающие проблемы.
Но выбор нового инструмента раньше стоил дорого. Нужно было изучить документацию, сравнить несколько решений, проверить нужные возможности и собрать прототип. Поэтому знакомая технология нередко побеждала только потому, что её уже знала команда.
ИИ сократил стоимость такого исследования.
Теперь можно быстрее сравнить несколько технологий, найти ограничения, изучить примеры конфигураций и подготовить небольшие прототипы. Это позволяет раньше заметить детали, которые в будущем могли бы привести к обходным решениям или дополнительным затратам.
При этом выбор технологии по-прежнему остается инженерной задачей. ИИ может предложить Kafka, RabbitMQ, NATS или Redis, но не несёт ответственности за стоимость инфраструктуры, сложность эксплуатации и соответствие конкретному проекту.
Изменилось не то, кто принимает решение, а количество вариантов, которые можно проверить до его принятия.
Автотесты стали дешевле
Написание большого набора автоматических тестов всегда требовало времени. Поэтому командам приходилось выбирать, какие сценарии стоит покрывать подробно, а какие — нет.
ИИ справляется с механической частью этой работы. Если разработчик определил нужные проверки, агент может создать тестовые данные, написать несколько похожих сценариев, подготовить имитацию внешнего сервиса и дополнить существующий набор тестов.
Это позволяет покрывать автоматическими проверками больше случаев без пропорционального роста трудозатрат.
Но остаётся более сложная задача: определить, что нужно проверить.
Например, для оплаты недостаточно убедиться, что платёж проходит корректно. Нужно проверить повторный запрос, ошибку внешней системы, недостаточный баланс, конкурентные операции и другие пограничные состояния.
Если разработчик не предусмотрел эти сценарии, ИИ не обязан самостоятельно восстановить все требования бизнеса.
Поэтому нейросеть помогает писать тесты, но проектирование тестирования остаётся задачей инженера.
Код-ревью стало ещё важнее
Работающая функция и пройденные без ошибок тесты ещё не означают, что решение подходит проекту.
Одну задачу можно решить несколькими строками понятного кода или большой собственной абстракцией. Можно использовать штатный механизм фреймворка или создать новый слой, который придётся поддерживать. Можно выполнить текущее требование и одновременно нарушить архитектурные правила системы.
ИИ работает с тем контекстом, который ему предоставили. Разработчик дополнительно оценивает результат с точки зрения всего проекта.
Поэтому при ревью важно проверить не только работоспособность, но и соответствие архитектуре, принятым подходам, требованиям безопасности и дальнейшему развитию продукта.
Часть контроля можно автоматизировать с помощью тестов, статического анализа, линтеров и правил CI/CD. Но итоговое инженерное решение всё равно принимает человек.
ИИ меняет распределение работы, а не отменяет разработку
Главное изменение связано не с количеством строк кода, которые можно написать за день. Меняется распределение времени внутри разработки.
Часть реализации, поиска информации и подготовки тестов можно поручить ИИ. Разработчик получает больше времени на проектирование, сравнение решений и проверку результата.
Поэтому мы не рассматриваем нейросеть как самостоятельного разработчика, которому можно передать весь проект. Для нас это инструмент повышения производительности инженера.
Человек определяет требования, архитектуру, ограничения и критерии правильности. ИИ помогает исследовать варианты и быстрее выполнять реализацию. Затем результат возвращается инженеру для проверки.
Такой подход позволяет получить главное преимущество ИИ — скорость — без отказа от контроля, который делает программный продукт надёжным и пригодным для дальнейшего развития.
