Заменит ли ИИ людей в IT? Что важно знать заказчику

ИИ может написать код, предложить оформление страницы и помочь найти ошибку. Поэтому вопрос «нужны ли теперь разработчики?» вполне понятен. Особенно когда небольшой сайт или первый вариант приложения удаётся собрать очень быстро.

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

Нельзя уверенно обещать, что ИИ никогда не заменит никакие профессии: инструменты и роли меняются. Полезнее разобраться, какую работу можно поручить ИИ уже сейчас и где проекту нужны человеческие решения. Рассмотрим это на понятных примерах из разработки сайтов.

1. Что ИИ можно поручить в разработке

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

Некоторые инструменты умеют не только отвечать в чате, но и менять файлы проекта, запускать проверки и предлагать исправления. Поэтому утверждение «ИИ не может проверять код» уже слишком грубое. Вопрос в другом: что именно было проверено и достаточно ли этого для вашего проекта.

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

2. Сначала нужно понять, что требуется бизнесу

Запрос «сделай онлайн-запись» звучит просто. Но для работающей системы нужно ответить на несколько вопросов: можно ли записаться к любому мастеру, требуется ли предоплата, кто подтверждает время и что происходит при отмене?

Хорошее описание задачи экономит время независимо от того, кто пишет код. Укажите цель, пользователей, ограничения и признаки готовности. Для подготовки такого описания пригодится статья о техническом задании на разработку сайта.

3. Убедительный ответ тоже нужно проверять

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

GitHub прямо рекомендует проверять и тестировать код, созданный с помощью Copilot, особенно в задачах, связанных с безопасностью. Это описано в документации GitHub о применении Copilot.

Проверка — это не только вопрос «открывается ли страница?». Для формы заявки стоит проверить обязательные поля, неправильный адрес почты, повторное нажатие, потерю соединения и получение заявки сотрудником.

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

4. Красивый прототип и работающий сайт — разные этапы

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

Перед запуском коммерческого сайта появляются другие вопросы. Работает ли он с телефона? Можно ли пройти форму с клавиатуры? Понятно ли сообщение об ошибке? Получает ли менеджер заявку? Удобно ли сотруднику менять цены?

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

5. Доступы и изменения должны быть под контролем

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

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

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

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

6. ИИ может предлагать идеи — выбирать нужно по задаче

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

Но количество вариантов не равно качеству выбора. Красивое оформление может затруднять чтение, а эффектная функция — усложнять запись. Идею нужно оценивать по тому, помогает ли она вашим пользователям.

Например, вместо длинной формы можно предложить короткую. Затем выяснить, хватает ли сотруднику полученных данных для ответа клиенту. Решение принимается с учётом обеих сторон: удобства посетителя и работы компании.

Если основная проблема сайта — люди не понимают, куда нажать и как оформить запрос, полезнее заняться удобством интерфейса и UX/UI-дизайном, чем добавлять новые функции ради самих функций.

7. Что спросить у команды, которая использует ИИ

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

• Что входит в результат? Только макет или готовый сайт с формами, настройками и передачей доступов?
• Какие проверки проводятся? Попросите назвать конкретные сценарии, а не просто сказать «всё протестировано».
• Что будет с данными? Уточните, какие сведения передаются внешним инструментам и зачем.
• Кто исправит проблему? Договоритесь о поддержке и порядке работы после запуска.
• Можно ли развивать сайт дальше? Убедитесь, что проект, доступы и документация будут доступны вашей компании.

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