Заменит ли ИИ программистов: честный разбор на практике

Тема «ИИ заменит программистов» живёт в заголовках уже несколько лет. Каждые несколько месяцев появляется новая модель, и волна тревоги поднимается заново. На практике картина спокойнее и сложнее одновременно: ИИ действительно забрал часть работы, которую раньше выполняли разработчики, но профессия не исчезает - она расслаивается.

Рутина (типовые формы, простые скрипты, шаблонный код) всё чаще пишется агентом за минуты. За человеком остаются понимание настоящей задачи, выбор архитектуры, договорённость со смежными системами и ответственность, когда что-то идёт не так. Разберём, что именно изменилось и что это значит для компании и для разработчика.

Вайбкодинг - это подход, при котором код создаётся через диалог с ИИ-агентом на естественном языке, без ручного написания; подробнее о нём читайте в материале «Вайбкодинг простыми словами».

Что ИИ уже делает сам

Перечислим то, что агент закрывает без человека или с минимальным участием:

• Типовые формы и справочники. Стандартная форма ввода данных, карточка сущности, выпадающие списки - агент собирает их по описанию за несколько минут.
• Дашборды и отчёты. Простой сводный экран по данным из готового API - это задача на один диалог. На демонстрациях Битрикс24 такой дашборд собирали примерно за 11-15 минут.
• Разовые скрипты и парсеры. Конвертировать файл, пройтись по списку, собрать данные с внешнего источника - агент пишет рабочий черновик быстро.
• Обвязка чужого API по документации. Если документация читаемая, агент составит функцию вызова и обработку ответа самостоятельно. Проблемы начинаются там, где документация устарела или неполна.
• Черновик интерфейса. Вёрстка экрана по словесному описанию или даже по картинке-схеме - рабочий сценарий. Агент выбирает стек, создаёт компоненты, запускает dev-сервер.
• Объяснение незнакомого кода. Задача «объясни, что делает этот файл» решается хорошо. Особенно полезно при входе в чужой проект.
• Генерация тестовых данных. Заполнить базу реалистичными тестовыми записями - стандартный запрос.
• Разбивка задачи на план. Агент со скиллом spec-driven development сначала пишет спецификацию в .md-файле, затем план работ с этапами - и делает это быстрее, чем большинство людей вручную.

Всё это не «замена программиста» в полном смысле - это снятие с него той части работы, которая раньше съедала время, но не требовала глубокого мышления.

Где ломается

ИИ-агент ошибается системно, и важно знать, в каких точках:

• Уверенный неверный ответ (галлюцинация). Модель генерирует ответ пословно, выбирая наиболее вероятное следующее слово. Это значит, что галлюцинации неустранимы по природе - они управляемы, но не исключаемы полностью. Агент может назвать несуществующий метод API, описать поведение, которого нет, или сослаться на параметр, который он придумал.
• Зацикливание на одной ошибке. Агент пытается исправить баг одним и тем же способом несколько раз подряд. Три неудачных захода подряд - сигнал менять подход или переформулировать задачу, а не повторять тот же запрос.
• Потеря контекста в большом проекте. Контекстное окно ограничено. В длинной сессии агент начинает «забывать» детали, принятые в начале. Частичное решение - фиксировать промежуточные результаты в отдельные файлы, к которым агент может возвращаться.
• Работает на демо и падает на реальных данных. Агент тестирует сам себя на тестовых записях, которые он же и создал. Реальные данные содержат граничные случаи: пустые поля, нестандартные символы, дубли.
• Выдуманные методы API. Особенно актуально для платформ с нишевой документацией или частыми обновлениями. Агент уверенно называет метод, которого не существует в текущей версии.
• Доступы и безопасность - слепое пятно. Агент не знает вашу политику доступа, не понимает, какие данные чувствительные, и по умолчанию решает задачу кратчайшим путём - часто без должных проверок прав.
• Непонимание, зачем это бизнесу. Агент решает техническую задачу в формулировке, которую ему дали. Если формулировка неточная или не отражает реальную цель, результат будет технически корректным, но бесполезным для бизнеса.

Почему код - это не вся работа программиста

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

• Понять настоящую задачу. Заказчик формулирует запрос как симптом, а не как причину. Найти корень и предложить решение - это аналитическая и коммуникационная работа.
• Выбрать архитектуру. Как организовать данные, как разделить модули, как обеспечить масштабирование - решения, которые влияют на годы поддержки.
• Договориться со смежными системами. Интеграция с учётной системой, телефонией или внешним сервисом - это переговоры о формате данных, порядке обработки ошибок и поведении при недоступности одной из сторон.
• Предусмотреть отказ. Что происходит, когда внешний сервис не отвечает? Когда пользователь сделал что-то неожиданное? Обработка исключений - часть профессии, которую агент системно недооценивает.
• Поддерживать годами. Код живёт дольше, чем сессия с агентом. Кто разберётся через два года, что здесь происходит?
• Отвечать за инцидент. Когда что-то ломается в продакшне - нужен человек, который понимает систему целиком и берёт ответственность за восстановление.

Цена ошибки: что можно отдать модели, а что нет

Принцип простой: рутину доверяем, критичное проверяем. Глубина проверки должна соответствовать цене ошибки.

Зоны, где проверка человеком обязательна:

Глубина проверки зависит от цены ошибки. На вебинарах Битрикс24 это объясняли сравнением рекламного объявления в Яндекс.Директ и записи на визу: в первом случае неточность стоит недорого, во втором отменяет поездку. Так же и с проверкой ИИ-результатов.

Для работы с ИИ в Битрикс24 Вайбкод позволяет выдать ключ только на чтение данных, и тогда попытка «оптимизировать воронку» с удалением сделок не пройдёт по правам. Но по умолчанию ключ работает от имени владельца со всеми его правами: режим только на чтение задаёте вы сами, а администратор может сделать его политикой по умолчанию.

Что мы видим на своих проектах

Без лишнего пафоса - несколько наблюдений из реальной работы.

Приложение на вайбкоде собирается быстро. Агент создаёт Git-репозиторий, проходит по задачам, покрывает фичи тестами, делает commit. Отчёт «14 тестов зелёные, production build собирается без ошибок» - звучит убедительно. Но, как оговариваются сами спикеры на вебинарах Битрикс24: «это обычно ничего не значит - ошибки всё равно есть». Приёмка занимает сопоставимое с разработкой время.

Чаще всего при приёмке мы дорабатываем:

• Права доступа - агент не знал политику, открыл лишнее.
• Обработку ошибок - при «нормальном» сценарии всё работает, при граничных случаях приложение падает молча.
• Поведение при повторном запуске - повторная инициализация создаёт дубли или перезаписывает данные.
• Ситуацию «автор ушёл» - приложение работает, но никто в команде не понимает, как оно устроено и что делать, если что-то сломается.

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

Кто нужен рядом с ИИ

Три роли, которые никуда не делись:

1. Постановщик задачи. Формулирует задачу как тимлид, а не как исполнитель. Описывает желаемый результат, границы («что делать» и «чего НЕ делать»), критерии приёмки. Без этого агент додумывает сам - и додумывает не всегда в нужную сторону. Одно предложение сработает, но результат будет «не совсем тем».

2. Проверяющий. Тестирует на реальных данных, а не на тестовых. Смотрит граничные случаи. Оценивает, решена ли настоящая задача, а не только та, что была сформулирована.

3. Владелец решения после запуска. Человек, который понимает, как приложение работает, что делать при инциденте и кто отвечает за поддержку. Если этой роли нет - приложение становится «чёрным ящиком» и рано или поздно создаёт проблему.

О том, как правильно ставить задачи ИИ-агенту и работать с ним как тимлид, читайте в разборе приёмов вайбкодинга.

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

flowchart TD
    A[Постановщик задачи] -->|ТЗ на естественном языке| B[ИИ-агент]
    B -->|Спецификация + код| C[Проверяющий]
    C -->|Замечания| B
    C -->|Принято| D[Владелец решения]
    D -->|Поддержка и развитие| E[Боевая эксплуатация]

Как меняется вход в профессию

Несколько вещей, которые потеряли прежнюю ценность:

• Заучивание синтаксиса и API наизусть. Агент справляется с этим быстрее и без ошибок. Знать, что существует нужный инструмент, важнее, чем помнить его синтаксис.
• Написание шаблонного кода вручную. Формы, CRUD-операции, типовые обработчики - это агентская работа.

Что стало важнее:

• Чтение чужого кода. Понять, что делает готовое решение, найти в нём ошибку, объяснить коллеге.
• Отладка на реальных данных. Агент тестирует сам себя на придуманных сценариях. Человек проверяет на реальных.
• Умение формулировать требования. Чем точнее техническое задание, тем ближе результат к нужному. Это навык, который раньше считался «мягким», теперь он ключевой.
• Архитектурное мышление. Как организованы данные и модули, как система ведёт себя при росте нагрузки или при сбое - это по-прежнему человеческая работа.

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

Что делать компании прямо сейчас

Практический план без лишних обещаний:

1. Разрешите эксперименты в песочнице. Отдельный тестовый портал или окружение, где сотрудники пробуют собирать приложения. Без риска для боевых данных.
2. Введите приёмку перед боевым запуском. Любое приложение, собранное с помощью ИИ, проходит проверку: права доступа, обработка ошибок, поведение на реальных данных. Это не бюрократия - это защита от инцидентов.
3. Ведите реестр приложений. Что собрано, кто автор, где хранится код, на каком сервере работает. Без реестра компания быстро теряет контроль над тем, что вообще существует. Подробнее о том, как навести порядок, если приложений уже много, - в материале про хаос вайбкод-приложений.
4. Назначьте владельцев. У каждого приложения должен быть конкретный человек, который понимает его и отвечает за поддержку.
5. Заранее решите, кто поддерживает. Если автор приложения уволился или перешёл в другой отдел - кто разберётся? Этот вопрос нужно решить до, а не после инцидента.
6. Выбирайте решение под задачу осознанно. Не всё стоит собирать на вайбкоде - некоторые задачи требуют готового продукта или классической разработки. О том, как выбрать, читайте в разборе подходов к разработке приложений на Вайбкоде.

Если хотите обсудить, как выстроить этот процесс в вашей компании - напишите на sales@acp-24.ru или позвоните +7 495 414-48-49. АС Проект - платиновый партнёр Битрикс24.

Хотите так же? АС Проект - платиновый партнёр Битрикс24: подключаем и настраиваем ИИ-инструменты под процессы компании. Речевая аналитика и разбор звонков - отдельная услуга, обучение команды работе с ИИ - корпоративная программа, нетиповые сценарии собираем приложением на Вайбкоде.

Частые вопросы