В Яндексе предлагают смотреть на разработку с ИИ без старого фетиша вокруг «идеального промпта». Сергей Бережной, директор по взаимодействию с разработчиками в Яндексе, пишет, что хороший результат с большими языковыми моделями почти никогда не появляется после одного запроса, а выигрывают те, кто умеет выстроить цепочку шагов: анализ, план, реализация, проверка.
Этот тезис Бережной изложил в авторской колонке, сообщает Habr / Карьера. Повод формально образовательный: материал опубликован на фоне приёмной кампании в онлайн-магистратуру ИТМО и Яндекс Практикума «Фронтенд-, бэкенд-разработка и ИИ-решения». Но сам текст интересен не рекламным контекстом, а довольно трезвым описанием того, как меняется практическая разработка с ИИ внутри профессии.
Главная мысль простая: если модель выдаёт слабый результат, проблема часто не в том, что пользователь не нашёл магическую формулировку. Проблема в том, что задача поставлена как одноразовый запрос там, где нужен процесс. Бережной разбирает типичный пример: нужно добавить новый механизм авторизации в существующий сервис. Попытка впихнуть всё в один большой промпт обычно заканчивается знакомым набором сюрпризов: модель игнорирует архитектурные ограничения, дублирует уже существующую логику или предлагает изменения, которые потом трудно встроить в проект без побочных эффектов.
Вместо этого он предлагает разложить работу на этапы. Сначала попросить модель разобраться в структуре проекта и найти точки изменений. Затем оценить риски, продумать тестовые сценарии, сохранить промежуточные результаты и только после этого переходить к коду. По сути речь уже не о prompt engineering в классическом стиле, а о проектировании маршрута, по которому ИИ проходит задачу вместе с разработчиком. Для индустрии это важный сдвиг: ценность смещается от красивой формулировки запроса к умению организовать исполнение.
Тот же принцип, по словам Бережного, работает и за пределами кода. На текстах быстро выясняется, что один промпт редко даёт результат, который можно без стыда публиковать или отправлять клиенту. Зато начинают работать связки из нескольких шагов: описание Tone of Voice, примеры, затем последовательность агентов или ролей, которые проверяют и рецензируют работу друг друга. В разработке картина похожая. Если отдать модели сразу большой функциональный блок, на выходе легко получить сырое решение, которое не уважает соглашения проекта, ломает архитектуру и зачем-то переписывает полрепозитория.
От промпта к оркестрации
На этом фоне особенно любопытно звучит его вывод про обучение. В модуле по работе с ИИ для совместной онлайн-магистратуры ИТМО и Яндекс Практикума, как пишет Бережной, довольно быстро отказались от идеи учить «правильным промптам». Причина практическая: конкретные техники меняются слишком быстро. Намного устойчивее навыки другого типа: декомпозиция задач, проектирование процесса, проверка результата и понимание того, на каком этапе модель полезна, а где её лучше придержать. Для рынка образования это тоже показатель. Школы и вузы, которые продолжают продавать «секретные промпты», рискуют обучать ремеслу с очень коротким сроком годности.
Отсюда вытекает второй тезис статьи: в работе с LLM эмпирика важнее списка лучших практик. Бережной прямо пишет, что в такой быстро меняющейся области нельзя всерьёз рассчитывать на маленький стабильный учебник с готовыми ответами. Инструменты обновляются быстрее, чем успевают затвердеть правила их применения. Поэтому он рекомендует почти на каждую рабочую задачу задавать себе вопрос: можно ли решить её с помощью ИИ-инструментов? Даже если ответ окажется отрицательным, разработчик всё равно точнее поймёт границы модели. И это, пожалуй, одна из самых приземлённых рекомендаций во всём тексте: не поклоняться технологии и не списывать её со счетов, а методично собирать собственную статистику удачных и провальных кейсов.
Для русскоязычного ИТ-рынка в этом есть отдельный нерв. Последние два года разговор про ИИ в командах часто сводился либо к восторгу по поводу скорости генерации, либо к раздражению из-за галлюцинаций и кривого кода. Позиция Бережного лежит посередине и потому выглядит взрослой: модель не заменяет инженерное мышление, а, наоборот, делает его ценнее. Чем сложнее становятся инструменты, тем важнее опыт человека, который понимает этапы решения задачи, умеет разделить работу между «исполнителями» и знает, где нужна дополнительная проверка. В статье это сформулировано почти как управленческий сдвиг: работа с ИИ начинает напоминать управление собственной мини-командой, где у разных агентов разные сильные стороны, но ответственность за итог всё равно остаётся у разработчика.
Это неприятная новость для мифа о том, что ИИ быстро уравняет junior и senior. По логике Бережного, преимущество получают не те, кто эффектнее всех пишет запросы, а те, кто лучше понимает архитектуру, ограничения, порядок действий и критерии качества. Иными словами, разработка с ИИ делает опыт не менее важным, а в ряде сценариев даже более важным, чем раньше. Если этот подход закрепится, рынок будет выше ценить не «промпт-инженеров» как отдельную экзотику, а сильных разработчиков, которые умеют встраивать LLM в рабочий контур без магического мышления и без лишнего героизма.
Открытый вопрос теперь не в том, исчезнет ли мода на промпты. Она уже начинает уходить из центра обсуждения. Интереснее другое: насколько быстро компании перестроят найм, обучение и внутренние процессы под новую норму, где ключевой навык — не спросить у модели покрасивее, а собрать из неё управляемый и проверяемый инструмент.