Как нейросеть усложняет разработку, или Почему кнопки «Сделай красиво» всё ещё нет

Я занимаюсь веб-разработкой уже очень давно, и чем активнее использую нейросети в работе, тем чаще ловлю себя на одной мысли: а что было бы, если бы я не понимала, что именно мне сейчас предлагают?

Потому что нейросеть может написать за тебя код. Но она не гарантирует, что этот код вообще стоило писать.

Сейчас мы тут всё автоматизируем. И ещё немножко доавтоматизируем

В последнее время я собираю собственную систему для управления авторскими проектами. Там аналитика, интеграции, агенты, сборщики данных и прочие радости человека, который когда-то просто хотел писать книжки.

В какой-то момент мне понадобилось организовать безопасный механизм обновления одного из сервисов.

Задача довольно конкретная: сервис получает запрос на обновление, а дальше запускается заранее определённая процедура. Без свободного доступа к серверу, без произвольных команд и без выдачи агенту лишних полномочий.

Я описала задачу нейросети. И нейросеть принялась проектировать.

SSH, ключи, механизмы запуска, дополнительные проверки, изменения в коде управления развёртыванием…

Всё выглядело технически убедительно. Более того, некоторые предложенные элементы действительно могли работать.

Но в какой-то момент у меня возник вопрос: а зачем нам вообще вся эта конструкция?

Почему бы не создать обычный файл-флаг, который cron будет проверять раз в минуту? Если флаг появился — запускается заранее разрешённая команда. Всё.

Я предложила этот вариант.

И нейросеть ответила примерно следующее:

«Да! Это гораздо проще!»

Спасибо, конечно. А нельзя было начать с этого?

И нет, это была не какая-нибудь слабенькая модель

Самое забавное, что речь шла о GPT-6 на высоком уровне рассуждений.

То есть у модели было достаточно возможностей, чтобы разбирать сложные технические задачи. Она могла анализировать ограничения, писать код, выстраивать последовательность действий.

И всё равно сначала повела решение по более сложному пути.

Здесь важный нюанс: я не утверждаю, что cron всегда лучше SSH. Это разные инструменты, и безопасность зависит от конкретной реализации. Для других задач подобная схема могла бы быть вполне оправданной.

Но в моём конкретном случае уже существовали нужные серверные механизмы, а задача сводилась к запуску строго определённого действия. Дополнительная конструкция не давала той пользы, которая оправдывала бы её сложность.

И этот момент нейросеть сама не отловила, хотя имела доступ ко всей архитектуре.

Рабочий код ≠ хорошее решение

В разработке есть неприятная штука: можно написать абсолютно рабочую систему, которая решает задачу значительно сложнее, чем требуется. Она проходит тесты, не падает. В ней красивые классы, продуманные интерфейсы и даже документация имеется.

А потом выясняется, что всю её функциональность закрывает один небольшой скрипт.

С человеком-разработчиком такое тоже случается. Мы все иногда увлекаемся архитектурой, абстракциями и желанием предусмотреть абсолютно всё.

Только у нейросети есть дополнительное преимущество: ей не жалко писать код.

Попросишь — напишет ещё три класса. Потом тесты к ним. Потом слой совместимости. Потом механизм восстановления, журналирования и управления всем этим добром.

И предложит добавить мониторинг мониторинга.

И всё это — с такой уверенностью, что неопытному пользователю может показаться: ну раз настолько подробно расписано, значит, наверное, так и надо.

Тут-то и зарыта главная проблема.

Опыт нужен не только для того, чтобы писать код

Когда обсуждают ИИ в разработке, часто спрашивают: а зачем теперь программист, если нейросеть сама всё напишет?

Но написание кода — лишь часть работы.

Ещё нужно понимать, правильно ли сформулирована задача. Действительно ли требуется новая архитектура. Какие ограничения существенны, а какие модель придумала по дороге. И почему решение из двадцати файлов не обязательно лучше решения из двух.

В моём примере я смогла возразить нейросети только потому, что знала о существовании более простого варианта.

А если бы не знала?

С большой вероятностью получила бы дополнительный слой инфраструктуры. Возможно, даже вполне рабочий. И потом ещё потратила бы время на его поддержку.

В этом и заключается неприятный парадокс: нейросети особенно полезны тем, кто уже способен критически оценивать их предложения. А человеку без опыта зачастую трудно даже понять, какой вопрос нужно задать, чтобы получить более простое решение.

Значит, ИИ бесполезен?

Да нет, конечно.

Я продолжаю активно использовать его в разработке. Он снимает огромный объём рутинной работы, помогает быстрее разбираться с незнакомыми участками кода, искать ошибки, писать проверки и реализовывать идеи.

Я совершенно не хочу возвращаться к временам, когда всё это приходилось делать исключительно вручную.

Но теперь всё чаще задаю ему дополнительный вопрос:

«А можно решить эту задачу проще?»

И иногда оказывается, что можно. Причём значительно.

Тут, конечно, возникает закономерная претензия: а почему я вообще должна об этом спрашивать?

Потому что инструменты становятся мощнее, но автоматически не приобретают инженерный здравый смысл. Модель может отлично выполнить сложную задачу и при этом не усомниться, нужна ли была сама сложность.

А человеку всё ещё приходится быть тем самым занудой, который спрашивает: «Зачем?»

Так где там кнопка «Сделай красиво»?

Её пока нет.

Есть инструменты, которые способны сократить часы работы до минут. Есть модели, которые пишут вполне приличный код. Есть возможность собрать проект, на который раньше ушло бы гораздо больше времени.

Но между «нейросеть сделала» и «задача решена хорошо» всё ещё лежит большая работа.

И чем убедительнее становятся ответы ИИ, тем важнее не забывать проверять не только код, но и саму идею решения.

Зато, кажется, другая кнопка уже отлично работает.

«Усложни мне жизнь».

Вот она практически безотказная.