На той неделе Андрей Карпаты плюсанул и перепостил пост CEO Shopify Tobi Lutke о замене термина prompt engineer на context engineer, сопроводив его своим пояснением, этот репост получил широкую поддержку в профессиональной среде. Действительно, промпт это лишь малая часть взаимодействия с LLM: краткая инструкция, команда или запрос. А вот построение контекста, в который этот промпт попадает, уже куда более сложная инженерная задача.

Андрей Карпаты словацко-канадский учёный в области AI/ML/DL. Бывший Head AI в Tesla, был в ранней команде основателей Open AI. Получил докторскую степень в Стэнфорде (Калифорния). Одним из направлений его исследований было пересечение обработки естественного языка и компьютерного зрения, с использованием DL. Он был автором и основным преподавателем первого курса по DL в Стэнфорде с 2015 по 2017 гг.

Когда погружаешься в такие проекты, понимаешь, мы проектируем не просто контексты, мы проектируем мышление. Поэтому правильнее называть это направление когнитивной инженерией (cognitive engineering), а не просто context engineering. Сейчас поясню эту мысль.

Почему «prompt engineering» уже не работает

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

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

Почему «context engineering» уже ближе, но всё ещё недостаточно

Андрей Карпаты в своём посте точно подметил, что ключевая инженерная работа это не написание промпта, а наполнение контекстного окна нужной, релевантной, и хорошо структурированной информацией.

С этим сложно спорить. В хорошей системе context engineering включает:

• task decomposition

• RAG (retrieval-augmented generation)

• memory/state management

• compact representations of prior history

• few-shot examples and tool definitions

• alignment with agent state and system goals

И всё это действительно похоже на работу инженера по контексту. Но, тут есть несколько «но».

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

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

В этом различии и лежит ключ к пониманию роли когнитивного инженера.
Context engineering отвечает за конфигурацию среды.
Cognitive engineering — за проектирование всего когнитивного цикла: архитектуры мышления, управляющих стратегий и динамики взаимодействий в системе.

Именно поэтому разработка эффективных систем требует перехода от инжиниринга входных данных к инжинирингу процессов рассуждения и собственно мышления.

Почему «cognitive engineering» более точный термин

Если мы проектируем не просто окружение, а процесс мышления ИИ, то и инженерия должна называться соответствующе. Именно это мы и делаем:

Мы создаём условия, в которых ИИ думает правильно, эффективно, в нужных нам координатах.

В этом процессе есть:

• проектирование структуры рассуждения (reasoning scaffolds)

• управление вниманием модели (attention shaping)

• формирование когнитивных задач (subgoal prompting)

• внедрение проверок, саморефлексии, дебагинга (reflexion, self-consistency)

• управление агентной архитектурой и ролями (role-based cognition)

• настройка памяти и обучения на ходу (dynamic memory shaping)

• проектирование distributed cognition в MAS-среде

Это уже не просто «наполнение окна» контекстом это конструирование мышления как системы. Именно это и определяет новую роль когнитивного инженера. Я рассматриваю context engineering как лишь один из слоев более сложной системы — когнитивной архитектуры.

Если context engineering отвечает за упаковку входных данных, то cognitive engineering за проектирование самого процесса мышления: стратегий рассуждения, мета-контроля, самопроверок, фрейм-менеджмента, и взаимодействия агентов.

Чем же занимается когнитивный инженер?

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

В его зоне ответственности не только внутренняя логика reasoning-процессов, но и UX мышления, то, как система взаимодействует с пользователем в процессе размышлений: как объясняет свои шаги, как вовлекает в диалог, как позволяет влиять на ход рассуждения. Кроме того, когнитивный инженер связывает этот слой с остальной системой: через API, retrieval, инструменты и управляющие интерфейсы.

Когнитивный Инженер не занимается инфраструктурой, не реализует бизнес-логику и не отвечает за DevOps, но именно он делает возможным то, ради чего и создаются интеллектуальные системы: мыслящее поведение в автономном режиме, доступное для взаимодействия и управления человеком.

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

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

Cognitive engineering включает в себя:

Архитектуру мышления

• Построение когнитивных пайплайнов (reasoning pipelines)

• Проектирование архитектур MAS (multi-agent systems) как систем командного мышления

• Настройка ментальных моделей и форматов мышления LLM (Tree of Thought, ReAct, Self-Consistency)

Управление когнитивным процессом

• Управление когнитивными циклами: наблюдение → интерпретация → решение → действие → анализ

• Интеграция памяти, инструментов и ролей агентов

Взаимодействие и верификацию

Интеграция UX-слоя (диалоги, интерфейсы взаимодействия), механизмов верификации и ревью, а также человеческого участия (HITL и другие формы обратной связи) как неотъемлемых частей когнитивного цикла.

Почему это важно?

Смена названия это не попытка косметического ремонта. Фактически это про смену карты мышления всей индустрии.

Если мы продолжаем говорить промпт, мы ограничиваемся тем, что было.
Если мы говорим «context», то мы говорим о форме, а не о функции.
Но если мы говорим «cognitive» — мы выходим в пространство, где можно проектировать мышление как систему.

А значит, создавать не просто LLM-утилиты, а умную среду, мультиагентные системы и продукты нового поколения.

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

Буду рад вашим мыслям в комментариях.

***

В этом году у меня выходит серия книг под общим названием «Когнитивный пайплайн», в формате инженерного сборника из 150+ продвинутых техник диалога, архитектуры ИИ-агентов, настройки памяти, управления когнитивным фреймом, ролевой динамики и оркестрации мультиагентных систем. 

Книги спроектированы как рабочие инструменты, практические мануалы для тех, кто строит на их основе новые продукты и когнитивные системы. В них подробно разобраны уже известные, такие как Tree of Thought, Reflexion, Self-Consistency, так и менее известные, но весьма полезные техники, а также архитектурные паттерны мультиагентного взаимодействия. Первая книга, с 33 техниками, уже вышла в начале апреля.

***

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

Мой блог про новые бизнес-модели: Айвентор и Фред