# Промпт-инжиниринг мёртв. Я им никогда и не занимался. Два года индустрия искала волшебные слова, которые надо прошептать модели. Теперь она тихо хоронит «промпт-инжиниринг» и заменяет его context engineering и harness engineering. Но вот в чём фокус: это не новые трюки — это просто инженерия, та самая работа, которую системщики делали всё это время. Почему слова никогда не были сутью и что на самом деле заставляет агента работать. - **Author:** Фёдор Чищин - **Published:** 2026-06-03 - **Tags:** agents, methodology, ai-native - **Source:** https://fedorthinks.com/ru/blog/prompt-engineering-is-dead --- Где-то два года интернет был полон заклинаний. «Действуй как senior-инженер». «Сделай глубокий вдох и иди шаг за шагом». «Дам $200 чаевых за ответ получше». Люди обменивались этими заклинаниями, как чит-кодами, будто модель — джинн, а правильная формулировка — то самое секретное слово, отпирающее спрятанный внутри хороший ответ. Под это была даже целая должность — _промпт-инженер_. Посылка была в том, что навыком эпохи ИИ станет формулировка — поиск волшебной фразы. Эта эпоха кончается, и стоит понять почему, потому что приходит на смену не заклинание получше. Приходит осознание, что заклинания не было вовсе. ## Индустрия тихо хоронит сам термин В середине 2025 CEO Shopify Тоби Лютке [написал](https://x.com/tobi/status/1935533422589399127) то, что многие уже чувствовали: > Мне куда больше нравится термин «context engineering», чем «prompt > engineering». Он точнее описывает основной навык: искусство предоставить > весь контекст, чтобы задача стала правдоподобно решаемой для LLM. Через неделю Андрей Карпатый [поддержал это](https://simonwillison.net/2025/Jun/27/context-engineering/) и добавил метафору, от которой всё встаёт на места: LLM — это процессор, а окно контекста — его оперативная память. Твоя задача — не прошептать правильные слова, а загрузить в память нужное до того, как модель запустится. К 2026-му это затвердело в общепризнанный навык. Как сформулировал один популярный гайд, **формулировка — это лишь около 10% задачи.** Остальные 90% — за context engineering: какую информацию модель видит, в каком виде, в какой момент — память, найденные документы, выводы инструментов, состояние — и что _выбросить_, пока окно заполняется. Переосмысление верное. Но заметь, что это на самом деле: отрасль посмотрела на «поиск волшебных слов», решила, что настоящей работой это никогда не было, и переименовала дисциплину в честь того, что всегда имело значение, — инженерии входных данных. ## Слова никогда не были сутью Вот почему промпт-инжиниринг был обречён умереть: промпт-трюк привязан к конкретной модели в конкретный день. Хитрая формулировка, выжавшая ответ получше из одной модели, бесполезна — или прямо вредна — на следующей. Ты строил на песке. Каждый релиз модели смывал твои заклинания, и ты шёл искать новые. _Система_ так не гниёт. Если твой агент даёт хороший ответ потому, что ты скормил ему правильные факты, правильные инструменты и ясную задачу, то модель получше делает его _лучше_, а не ломает. Ты никогда не опирался на волшебную фразу — ты опирался на хорошие входные данные. Хорошие входные данные переживают апгрейд модели. Волшебные фразы — нет. В этом вся разница между трюком и инженерной практикой. Трюк — то, что ты находишь и прячешь про запас. Инженерная практика — то, о чём можно рассуждать, что можно тестировать и на что можно полагаться сквозь изменения. Промптинг был первым, прикидывающимся вторым. ## Что на самом деле ломает агента (и это не формулировка) Понаблюдай, как настоящий агент падает в проде, — и почти никогда не увидишь «промпт был плохо сформулирован». Увидишь нечто куда более скучное и структурное. Увидишь **context rot** — деградацию контекста: [инженерная команда Anthropic](https://www.anthropic.com/engineering/harness-design-long-running-apps) описывает, как модель всё хуже рассуждает по мере того, как окно контекста заполняется устаревшей, шумной историей. Увидишь, как агент сходит с рельсов после пятидесяти шагов, теряет нить исходной задачи, вызывает инструмент с неправильной структурой или действует по состоянию, которое уже неверно. Один разбор сбоев корпоративного ИИ возвёл [**65% из них к «дефектам harness»**](https://atlan.com/know/what-is-harness-engineering/) — дрейф контекста, рассинхрон схем, деградация состояния — а не к модели и не к промпту. Есть фраза из той работы, которую я постоянно повторяю людям: **улучшение на бенчмарке на один процент не значит ничего, если агент сходит с рельсов после пятидесяти шагов.** Никакая формулировка промпта это не чинит. Это не проблема слов. Это проблема системы — что агенту позволено видеть, держать, делать и забывать на протяжении долгой задачи. Это и есть слой, который индустрия теперь называет **harness engineering**: среда вокруг модели — её инструменты, её память, её ограничения, её петли обратной связи, когда сжать контекст и переинъецировать цель. Промпт — крошечная часть этого. Harness — всё остальное. ## Это всегда было просто инженерией Сними новую лексику — и посмотри, что context engineering и harness engineering на деле просят тебя сделать: - Решить, **какие входные данные** получает система — из доверенных источников, в чистой форме. - Управлять **состоянием** во времени — что держать, что выбросить, что сохранить вне модели. - Задать **границы** — какие инструменты, что им позволено, каковы контракты. - Построить **петли обратной связи** — проверки, evals, восстановление, когда что-то поплыло. Это не новая ИИ-дисциплина. Это _инженерия_. Входы, состояние, границы, обратная связь — работа та же, неважно, что в середине: функция, сервис или языковая модель. Модель необычна в одном (это недетерминированный угадыватель — именно поэтому её [заземляют](/work/astrolinkers)), но всё _вокруг_ неё — обычная системная работа. Так что когда меня спрашивают, что я делаю с промптами, честный ответ: как можно меньше. У меня никогда не было фазы промпт-инжиниринга. Работой всегда было построение системы — детерминированные источники, которые модель не может переопределить, типизированные контракты на краях, задача, зафиксированная [в спеке, а не в промпте](/blog/specs-are-the-artifact), [evals, чтобы я знал, если что-то регрессировало](/blog/evals-or-it-didnt-ship). Промпт был наименее интересной частью, и я хотел, чтобы он таким и остался. Чем сильнее результат зависит от точной формулировки, тем он хрупче. ## Почему это хорошая новость Соблазнительно прочесть «промпт-инжиниринг мёртв» как «земля снова уходит из-под ног»: ещё один навык устарел, учи новое. Всё наоборот. Смерть промпт-инжиниринга — это признание ИИ-отрасли, что долговечным навыком никогда не был мешок модель-специфичных трюков. Это всегда была инженерия — а её не смывает следующим релизом. Рассуждения о входах, состоянии и границах, которые ты делаешь сегодня, остаются верными, когда модель под капотом станет вдвое умнее. Волшебные слова никогда не работали так, как все надеялись. Система вокруг модели — работала всегда. Промпт-инжиниринг мёртв не потому, что мы нашли заклинания получше, — он мёртв потому, что мы наконец признали: заклинания не было, была лишь инженерия, которой стоило заниматься с самого начала.