Разбор: почему «знание предметной области» — взгляд снаружи и что это значит для разработчика

«Знание предметной области важно» — эту мысль за 2026 год повторили несколько раз с разных сторон. В июне Anthropic разобрала около 400 000 сессий Claude Code и написала, что способность довести Claude до результата зависит от владения предметной областью сильнее, чем от умения писать код. Чуть раньше громко читали эссе «Domain Expertise Has Always Been the Real Moat». Вывод один и тот же, и он верный.

Спотыкается другое — само слово. «Знание предметной области» работает, только если кто-то стоит снаружи и заглядывает внутрь. Пока реализацию забирают агенты, этой позиции снаружи уже нет.

Слово делает две работы сразу

В одном случае речь про инструменты. В феврале 2026-го репозиторий skills Мэтта Покака (260 тысяч звёзд) занёс словарь DDD в управление контекстом агента. В README цитируется Эванс:

В начале проекта разработчики и те, для кого они пишут софт (эксперты предметной области), обычно говорят на разных языках. Я почувствовал то же самое с агентами.

Лекарство — общий документ CONTEXT.md, глоссарий, по которому агент расшифровывает жаргон бизнеса. Тут «знание предметной области» — способ рассказать агенту о бизнесе. Аппарат перевода из DDD пересобрали под агента, который сел на стул разработчика.

Во втором случае речь про карьеру. В том же феврале Борис Черный, автор Claude Code, сказал, что «сегодня написание кода практически решено» и «титул software engineer начнёт исчезать». Эссе про moat ответило: выбери отрасль, инструмент, регуляторный режим, физический процесс и учи так же, как когда-то учил язык программирования. Разбор Anthropic добавил цифр: все десять крупнейших профессий в датасете попадают в семь пунктов от software-инженеров по успешности, а самые быстро растущие несофтверные группы — менеджмент, продажи, юристы.

Так слово, служившее инструментом для разговора с агентом, стало аргументом в споре о рабочих местах. Совет «выучи» предполагает, что читатель — инженер, а бизнес — то, куда надо сходить и выучить.

И тут уместен один вопрос: с чьей стороны мы вообще смотрим на «предметную область»?

Откуда взялось слово

«Домен», «модель», «единый язык» закрепил в одном словаре Эрик Эванс в Domain-Driven Design (2003). До этого были domain analysis 1980-х и Problem Frames Майкла Джексона (2001).

Каждое понятие DDD — деталь переводческого аппарата:

• Предметная область — «сфера знания, влияния или деятельности». Для системы бронирования авиабилетов это бронирования, для бухгалтерской программы — бухгалтерия.
• Эксперт предметной области — тот, кто знает эту сферу глубоко. Разработчик может им быть, но инструменты DDD построены на допущении, что это другой человек.
• Модель — «избирательно упрощённая и сознательно структурированная форма знания». Документальное кино тоже не показывает реальность без монтажа.
• Обработка знаний — совместная работа разработчиков и экспертов, где из массы информации выуживают тонкий релевантный поток. Эванс прямо пишет, что ведут её обычно разработчики.
• Единый язык — общий словарь вокруг модели. Эванс объясняет вред перевода: «Перевод всегда неточен и скрывает разрывы в понимании».
• Ограниченный контекст — линия, внутри которой модель применима. «Клиент» в продажах и в бухгалтерии — разные вещи, и это нормально.

Сложите шесть понятий вместе, и видно, зачем всё это. Разработчик не знает бизнес, бизнес не знает софт. Словарь DDD — мост между двумя берегами. Мост нужен, пока на обоих берегах есть люди. Если люди только на одном, мост не нужен.

Снаружи и изнутри

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

Почему вопрос рождается только внутри

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

Вопрос, который он задаёт агенту: «Где учёт остатков ломается в начале месяца?» Сверить экспорт приходов и расходов со временем обработки — и к утру есть ответ. Дальше он просит: «Дай мне список позиций, ждущих оприходования, каждое утро». Утром приходит список, звонок на склад превращается во взгляд на список. Согласование требований, перевод на язык разработки, ожидание релиза — ни одного из этих шагов не существует.

У человека, который выучил управление запасами снаружи, первого вопроса нет. Обучение доводит до «в системе есть цифра», потому что причину звонка никто никогда не формулировал. Трение, которое ещё не стало словами, существует только там, где сидит человек, ведущий дело.

Агент сократил время между вопросом и работающим механизмом. Нет вопроса — нечего сокращать. Совет «выучи отрасль» предлагает приобрести знание, а приобретать знание агенты ускорили всем. Ускоренное для всех перестало быть преимуществом. Преимущество — то, что вы бросаете агенту.

Что делать на практике

Чек-лист для тех, кто работает внутри процесса — или хочет туда попасть:

1. Выпишите трения своего дня. Именно обходы: куда вы звоните, что проверяете руками, чего не доверяете системе.
2. Возьмите одно трение и задайте агенту вопрос, а не требование. Сначала «где здесь ломается и почему», потом «сделай так, чтобы мне каждое утро падал список».
3. Держите глоссарий сами. Агенту нужен файл вроде CONTEXT.md, где объяснено, что у вас значит «клиент», «отгрузка», «закрытие месяца». Составляйте его вы.
4. Не берите словарь модели как истину. Отдавайте агенту живые оговорки: «этому клиенту счёт идёт другому получателю» — именно они не попадают ни в одну схему.

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

Типичные ошибки. Первая: считать, что «выучить отрасль» — это про разницу между вами и новичком. Разница не в объёме знания, а в позиции. Вторая: пересказывать агенту регламент вместо того, чтобы отдать реальную практику обхода. Третья: писать требования, не зная, что делает бизнес, — это до сих пор считается нормой, из-за чего знающих хвалят как исключение. Четвёртая: путать глоссарий команды с языком бизнеса — в компании с историей свой словарь уже есть, плана счетов и списка категорий амортизации хватает; не хватает его обычно разработчику.

Где остаётся место

В бухгалтерии человек просит агента своими словами: «сделай сверку попроще» — и этого достаточно. Работа распутывания неоднозначностей и вытаскивания исключений наружу не исчезает, она переезжает внутрь бизнеса и остаётся на языке бизнеса. Шаг, где сторонний человек пересказывает всё в словаре своей модели, больше не нужен.

Сцены уже есть. Руководитель операций в здравоохранении с 15 годами опыта сама собирает себе рабочие инструменты с агентом — про неё пишут: «Она не заменяет инженера. Она убирает себя как узкое место». В таможенном комплаенсе, где ошибка в классификации тарифа — прямые потери, команда из двух человек воспроизвела пятишаговую процедуру эксперта как есть и взяла первое место на мировом бенчмарке. Юрист выиграл хакатон Anthropic.

Что остаётся у человека снаружи? Либо позиция внутри процесса, либо умение вытаскивать трение из чужой головы, пока носитель не научился говорить с агентом сам. Первое надёжнее.