Ищут это в основном разработчики — и им выдача даёт что нужно: обзоры инструментов, сравнения, инструкции. Но есть вторая аудитория, которой в выдаче нет ничего: люди, которые разработку заказывают. Им важно не какой инструмент лучше, а как это влияет на срок, цену, качество и риски их проекта.
Дальше — обе стороны, но с упором на вторую. Что такие агенты реально делают, где ускоряют, где создают долг и о чём говорить с подрядчиком.
Чем агент отличается от подсказок
Три ступени, которые часто называют одним словом «ИИ в разработке».
Автодополнение. Дописывает строку или блок в открытом файле. Работает как очень умная подсказка, ошибается безобидно — предложение просто не принимают.
Чат-помощник. Объясняет код, предлагает решение, пишет функцию по описанию. Человек копирует результат к себе и отвечает за него.
Агент. Получает задачу и работает сам: ищет нужные файлы, вносит связанные изменения в нескольких местах, запускает тесты, читает ошибки, исправляет и повторяет. Разница принципиальная: у него есть право действия — он меняет проект, а не предлагает текст.
Устроено это не так, как кажется со стороны: сама модель ничего не выполняет. Она возвращает команду с параметрами, а запускает её обвязка вокруг модели — и именно обвязка решает, что агенту позволено. Для заказчика отсюда следует простое: безопасность агента определяется не выбранной моделью, а списком действий, которые ему открыли.
Это то же различие, что между чат-ботом и агентом в бизнес-задачах, и оно разобрано в статье чем ИИ-агент отличается от чат-бота. Право действия даёт скорость и создаёт риск — здесь по тем же правилам, что и везде.
Где ускорение реальное
Честный список задач, где инструмент даёт заметный выигрыш.
Типовой код. Формы, обработчики, преобразование данных, интеграция с внешним интерфейсом по документации. Работа предсказуемая, проверяемая и скучная — идеальное сочетание.
Тесты. Написание проверок для существующего кода — задача, которую откладывают всегда. Агент делает её за часы, а результат сразу видно: тест либо проходит, либо нет.
Разбор незнакомого проекта. Программисту, впервые открывшему чужой код, агент за минуты объясняет структуру и находит нужное место. Для заказчика это означает, что смена подрядчика стала дешевле, чем была.
Переносы и обновления. Перевод кода на новую версию библиотеки, массовые однотипные правки. Скучно, объёмно, механически проверяемо.
Черновик решения. Первый работающий вариант, от которого дальше отталкивается человек. Часто быстрее, чем начинать с чистого листа.
Общее у всех пяти: результат можно проверить быстро и объективно. Там, где проверка дешёвая, инструмент безопасен и полезен.
Где выигрыша нет
Обратный список, и он объясняет, почему сроки проектов сократились не так, как обещали.
Выяснение требований. Главное узкое место любого проекта. Пока непонятно, что должно получиться, скорость написания кода не имеет значения — быстрее сделаем не то.
Архитектурные решения. Как разложить систему, где границы, что будет при росте нагрузки, как это поддерживать через два года. Здесь нужен опыт и ответственность, а не генерация вариантов.
Работа с данными. Схема базы, миграции на живых данных, всё, что нельзя откатить. Цена ошибки высокая, проверка дорогая — сочетание, обратное безопасному.
Отладка редких ошибок. Проблема, которая воспроизводится раз в неделю на одном сервере. Требует понимания системы целиком и терпения.
Всё, где важен контекст бизнеса. Почему скидка считается именно так, а не иначе, знает заказчик, и в коде этого нет.
- Типовой код по понятным правилам
- Тесты для существующего кода
- Разбор незнакомого проекта
- Массовые однотипные правки
- Черновик, который правит человек
- Проектирование системы
- Схема данных и миграции
- Редкие плавающие ошибки
- Логика, известная только заказчику
- Всё необратимое без отката
Долг, который создаётся незаметно
Главный риск не в качестве кода, а в его количестве.
Когда код появляется быстрее, чем его успевают читать, в проект попадает то, что никто не понимает целиком. Через полгода это обнаруживается самым неприятным способом: нужно изменить поведение, а никто не знает, что сломается.
Три конкретных проявления.
Код, который никто не читал. Работает — значит принят. До первого нестандартного случая.
Разные решения одной задачи в одном проекте. Агент не знает ваших договорённостей, если они нигде не записаны, и каждый раз делает по-своему. Через сотню правок проект выглядит написанным пятью разными людьми.
Тесты, написанные под существующее поведение. Если код содержал ошибку, тест закрепит её как правильную. Проверять тесты нужно так же, как код.
Лечится это не отказом от инструмента, а дисциплиной, которая и так должна быть: правило, что весь код читается человеком перед приёмкой, и автоматические проверки, которые ловят очевидное. Разница только в том, что при быстром темпе отсутствие дисциплины проявляется не через год, а через месяц.
Что это значит для заказчика
Практическая часть — как это меняет разговор с исполнителем.
Сроки сокращаются, но не пропорционально обещаниям. Ускоряется написание, а не выяснение требований и согласование. Если ваше техническое задание рождается по ходу, узкое место не сдвинулось.
Прототип стал дешевле. Проверить идею на работающем черновике теперь реально быстро и недорого. Это меняет порядок работы: имеет смысл сначала сделать простую версию и посмотреть на неё, а не проектировать всё на бумаге.
Смена подрядчика подешевела. Новой команде проще разобраться в чужом коде. Соответственно, снизилась и зависимость от конкретного исполнителя — если код и документация у вас на руках.
Требования к приёмке выросли. Раз код пишется быстрее, проверять его надо системнее. Вопросы про тесты и ревью перестали быть занудством.
Появился вопрос о данных. Если подрядчик использует внешние сервисы, ваш код и, возможно, ваши данные куда-то отправляются. Для чувствительных проектов это отдельная тема — вплоть до требования работать на локальных моделях.
Какие бывают инструменты
Разделение полезно, потому что за одним словом «агент» скрываются вещи разного уровня риска.
| Тип | Что делает | Где живёт | Риск |
|---|---|---|---|
| Дополнение в редакторе | подсказывает строки и блоки | у разработчика | низкий |
| Чат рядом с кодом | объясняет, предлагает решения | у разработчика | низкий |
| Агент в редакторе | правит несколько файлов по задаче | у разработчика | средний |
| Агент в терминале | работает с проектом целиком, запускает команды | у разработчика | средний |
| Автономный агент в сборке | берёт задачу из трекера, делает и предлагает изменения | на сервере | высокий |
Чем дальше вниз по таблице, тем больше самостоятельности и тем важнее ограничения: что агенту разрешено запускать, к каким системам он имеет доступ, кто утверждает результат. Это ровно та же логика, что для бизнес-агентов, — право действия требует белого списка и подтверждений.
Для заказчика практический смысл таблицы один: если подрядчик использует нижние строки, вопросы про проверку и доступы становятся обязательными. Если верхние — это просто удобный редактор, и беспокоиться не о чем.
Код, данные и права
Тема, которую в технических обзорах обходят, а для владельца продукта она существенна.
Куда уходит код. При работе с облачными сервисами фрагменты вашего проекта отправляются наружу. Для большинства бизнесов это приемлемо, для проектов с чувствительной логикой или данными — нет. Вопрос решается либо договорённостями с поставщиком, либо локальными моделями.
Данные в тестах. Отдельная и частая беда: чтобы что-то проверить, в примеры попадают реальные клиентские данные. Это уже не вопрос ИИ, а обычной гигиены, но при быстром темпе про неё забывают чаще.
Кому принадлежит результат. Код, написанный с помощью инструмента, принадлежит вам на тех же основаниях, что и любой другой по договору. Важно, чтобы в договоре это было прописано явно — как и то, что подрядчик передаёт вам исходники и документацию.
Чужие фрагменты. Модель может воспроизвести известный фрагмент из открытых источников. Для типового кода это несущественно, для продукта, который вы собираетесь лицензировать, стоит держать в голове и проверять зависимости.
Простое правило для заказчика: всё, что вы требовали от подрядчика до появления таких инструментов, требовать не перестали. Договор, исходники, документация, конфиденциальность — прежний набор, просто теперь к нему добавился вопрос про внешние сервисы.
Что спросить у подрядчика
Пять вопросов, которые отделяют осмысленную работу от быстрой сдачи непроверенного.
«Кто читает код перед сдачей?» Должно быть имя и процедура, а не «мы всё проверяем».
«Есть ли автоматические тесты и что они покрывают?» Наличие тестов — единственная защита от того, что правка в одном месте ломает другое.
«Что происходит с нашим кодом и данными?» Какие сервисы используются, что им отправляется, есть ли договорённости о конфиденциальности.
«Как вы фиксируете договорённости о том, как писать?» Единый стиль и решения должны быть где-то записаны, иначе проект расползётся.
«Что будет, если мы захотим передать проект другой команде?» Ответ покажет, есть ли документация и насколько код понятен снаружи.
Хороший признак: подрядчик сам поднимает эти темы и говорит, где применяет инструменты, а где сознательно нет. Тревожный: ИИ подаётся как главное преимущество и обоснование скидки, а про проверку результата разговора не заходит.
Как это выглядит в работе
- 1Постановка задачичеловек описывает, что должно получиться
- 2Работа агентаправки в файлах, запуск тестов, исправления
- 3Чтение результатачеловек проверяет логику и стиль
- 4Проверкитесты, линтеры, ручной прогон сценария
- 5Приёмкаответственность на человеке, а не на инструменте
Ключевое здесь — первый и последний шаги. Качество постановки определяет качество результата даже сильнее, чем при работе с людьми: агент не переспросит из вежливости и не скажет «слушай, а ты уверен, что так надо».
По этой же причине лучше всего инструмент работает у опытных разработчиков: они точно формулируют, что нужно, и мгновенно видят, что результат не годится. У начинающих эффект обратный — код появляется, ошибки в нём не видны, и обнаруживаются они на клиентах.
Что изменилось в сроках на практике
Полезно разложить типовой проект по этапам и посмотреть, где ускорение есть, а где его нет вовсе.
| Этап проекта | Доля времени раньше | Что изменилось |
|---|---|---|
| Выяснение требований | значительная | почти ничего |
| Проектирование | заметная | немного быстрее за счёт вариантов |
| Написание кода | значительная | ускорилось сильнее всего |
| Тестирование | заметная | ускорилось заметно |
| Исправления после показа | значительная | почти ничего |
| Запуск и поддержка | постоянная | без изменений |
Из таблицы видно главное: ускорились две строки из шести. Причём именно те, которые никогда не были самой трудной частью. Строки «выяснение требований» и «исправления после показа» — это работа с людьми, и она осталась ровно такой же.
Отсюда реалистичное ожидание для заказчика: срок сокращается ощутимо, но не втрое. И сокращается он сильнее там, где задача описана хорошо. Проект с внятным описанием получает от инструментов заметно больше, чем проект в стиле «сделайте, а мы по ходу посмотрим», — и это ещё один довод потратить время на постановку задачи.
Есть и обратный эффект, о котором стоит знать. Когда написание кода становится дешёвым, возникает соблазн переделывать вместо того, чтобы думать: не получилось — сгенерируем ещё раз. На мелочах это работает, на архитектуре приводит к системе, которую переписывали пять раз и ни разу не спроектировали.
Как это связано с вашим продуктом
Если вы не пишете код, а заказываете продукт, практический вывод простой.
Скорость проверки идей выросла. Черновик, на который раньше уходил месяц, делается за недели. Значит, разумнее начинать с малого и смотреть на реакцию людей, а не проектировать всё сразу. Тот же принцип, что в разговоре про минимально жизнеспособный продукт.
Требования всё равно на вас. Никакой инструмент не угадает, как считается ваша скидка и что делать с частичным возвратом. Время, потраченное на внятное описание, окупается сильнее, чем раньше.
Проверка стала важнее. Раз объём кода растёт, спрашивайте про тесты и ревью не из вежливости.
И главное: инструмент не меняет природу разработки. Продукт по-прежнему получается хорошим, когда кто-то понимает, зачем он нужен и как им будут пользоваться. Ускорилась часть, где печатают код, — и это полезно, но именно эта часть никогда не была самой трудной.
Что из этого применимо к вашей задаче и во что она реально обойдётся — разбираем на странице про разработку ИИ-агентов и на первой консультации.
