- BrainTools - https://www.braintools.ru -
Представьте себе два разговора.
В первом – два ценителя сравнивают картины. Один говорит: «вот эта лучше – у нее диагональ 80 см, а у той только 50». Второй смотрит на него и не знает, как отвечать.
Во втором – два инженера обсуждают компьютеры. Один говорит: «вот этот производительнее – у него корпус серебристый, а у того черный». Второй тоже не знает, как отвечать.
Абсурд узнается мгновенно.
А теперь – руководитель регионального подразделения смотрит на результат работы, сделанной экспертом с помощью AI, и спрашивает: «А сколько здесь твоими ручками?»
Тем же тоном, каким ценитель говорил про диагональ, а инженер – про цвет корпуса.
Только этот абсурд мы пока не узнаем – потому что не научились слышать его в собственном языке.
Про новую профессиональную грамотность, которая возникла раньше языка ее описания.
Про измерители, которых еще нет.
Про категорию профессионалов, для которой стандартные метрики дают систематически неверный ответ – не потому что метрики плохие, а потому что применяются не к тому объекту.
Про разрыв на десятилетия между тем, как работа теперь устроена, и тем, как ее принято измерять и оценивать.
Начнем с того, из чего эта работа реально складывается.
Работа с AI как с партнером имеет очень специфическую хронологию – и она не похожа на «сел и написал».
Если замерить типичный рабочий цикл эксперта, работающего с AI на системной основе, то распределение выглядит примерно так:
~65% времени – формирование контекста и подготовка ТЗ: исследование вопроса, поиск аналогов, чтение прежних артефактов, спецификаций, сравнение подходов, фиксация ограничений из смежных проектов, обсуждение возможностей и рисков с AI, систематизация аргументации и формирование рамки, подготовка стартовой версии wiki, формирование первого варианта ТЗ с повторным прохождением цикла обсуждения-аргументации, доуточнения уже поставленных задач, выделение слепых зон и их последующее покрытие новыми задачами, подготовка критериев оценки и пула тестов.
~5% времени – AI формирует код на основе ТЗ (или текст, или структуру, или запрос к данным).
~30% времени – проверка результата на реальных данных и правки: смотришь глазами, сверяешь, ловишь несостыковки. Каждая правка – это не «покажи, где нажать». Это диалог: сформулировать проблему, выделить причину, по которой она проявилась, дать нужный контекст и аргументировать, чтобы исправление кода было хирургически точным. Без целостной картины в голове эксперта, без знания предметной области и нюансов AI правильную правку не сделает. Возвращаешься к контексту, уточняешь, снова смотришь.
Итого: 95% работы делает человек. Головой, а не ручками.
Дальше – как оценить эти 95%.
За три недели в июне 2026 года собрана мультиклиентская аналитическая архитектура – единая система живых отчетов, которая сейчас работает у пяти клиентов в двух странах. Каждый отчет – самостоятельное веб-приложение с дашбордом и диалоговым интерфейсом, AI-ассистентом, которому можно задать любой вопрос о данных компании на естественном языке – «когда выйдем в прибыль?», «где видишь риски?», «почему такая цифра и как она получилась?».
Что попало в артефакты: 46 KB архитектурного документа, 115 KB плана проверки данных (включая анализ аномалий) в аналитической платформе, пакеты данных по каждому клиенту, промты для фронтенд-генератора плюс запросы к источникам данных. Соотношение по времени примерно то же: около 65% на контекст и подготовку ТЗ, 5% на сам код, 30% на тестирование.
Что именно делает эта аналитика и почему ее принцип – отдельный сдвиг в способе работы с данными – предмет отдельной публикации. Здесь важен один срез: как эту работу измерить?
Простой на первый взгляд вопрос. При попытке ответить он распадается на три взаимосвязанные проблемы. Три пласта, в каждом из которых стандартные инструменты оценки не дают правильного ответа.
Первая сцена – самая простая. Вопрос: «Что было сделано?»
Инструменты дают конкретные ответы:
Файловая система скажет: «1 документ, 46 KB»
Git скажет: «N коммитов»
Календарь скажет: «в календаре встречи не стоят, значит человек был свободен»
Все это – верхушка айсберга. Финальные артефакты, видимые снаружи. То, что за ними стоит – непрерывная работа над контекстом, сверка с ограничениями смежных проектов, проверка гипотез, взаимодействие с AI, построение мысленной модели и параллельное документирование – ни один инструмент не показывает.
Метрика «время в контекстной работе» – отсутствует.
Вторая сцена – еще интереснее. Один из клиентских отчетов дал аномалию: показатель экономии по клиенту оказался значительно выше, чем по остальным. На такую аномалию можно отреагировать двумя способами.
Первый: пожать плечами и оставить как есть. «У этого клиента показатель – 40%. Красиво».
Второй: разобрать и понять, нужны ли исправления. AI в одиночку с задачей справиться не может. AI может найти «подозрительное» место в данных, но разбор – на человеке. Например, на одну и ту же позицию два поставщика подали предложения, которые различаются в 1500 раз. Какое из поданных предложений аномальное? Какое следует отсечь как ошибку [1] ввода, а какое пометить как намеренное занижение (outlier)? Как детектировать признаки аномалий в зависимости от категории тендера? И это только часть вопросов, на которые нужно дать четкие, однозначные ответы, чтобы система корректно распознавала каждую ситуацию.
Первый вариант – 15 минут. Второй – от одного до трех дней. Результат внешне одинаковый: график с цифрой. Разница – только в том, отвечает ли эта цифра реальности.
Стандартной метрики для «качества аналитического рассуждения» – нет.
И самое неприятное: эта работа исчезает, если ее не сделать. Никто не увидит разницы между отчетом, построенным первым способом, и отчетом, построенным вторым – до момента, когда клиент не начнет принимать решения на основе неверных цифр. А это уже не техническая проблема.
Третья сцена – про то, чем конкретно занимается «эксперт + AI». Как этот тип работы называется в HR-номенклатуре?
Product Manager? Не совсем – Product Manager обычно не собирает живые дашборды и не разбирает аномалии данных.
Аналитик? Тоже не полностью – аналитик обычно не создает архитектуру передачи данных между источниками и не пишет инструкции деплоя.
Исследователь данных? Ближе, но исследователь данных обычно работает с одной моделью, а не с корпусом из пяти клиентов и двух стран.
Специалист по продуктовому маркетингу? Внутренний консультант? Solutions Architect?
Ни в одну из существующих категорий эта работа целиком не помещается. Всегда попадает частями – с искажением, всегда с потерей. Из HR-описания уходит либо архитектура, либо разбор аномалий, либо диалоговый интерфейс, либо связь с бизнес-целями клиента. Всегда – то, что и делает эту работу той, какая она есть.
Категории «эксперт + AI» – нет. В штатных расписаниях ее нет. В KPI-шаблонах – нет. В вопросах ассессмент-центров – нет. В названиях вакансий – нет.
Четвертая сцена – про экономику. Стандартный вопрос: «Сколько времени ты сэкономила?»
Расчет на пальцах: чтобы сделать эту же работу в старой парадигме, нужна была бы команда минимум из трех человек. Сроки – 3 месяца.
Один человек за три недели закрыл эту работу.
Формально это около 8 сэкономленных человеко-месяцев. Плюс отсутствие затрат на межличностные коммуникации между тремя ролями. Плюс отсутствие «испорченного телефона» между этапами. Это одна половина истории – видимый и измеримый эффект.
Вторая половина сильнее. В реальности альтернативы «сделать эту работу командой» часто не существовало: команды загружены другими задачами, их бы на этот проект просто не выделили. Значит, работа в старой парадигме не появилась бы никогда. Это не сэкономленные восемь месяцев – это результат, которого без «эксперта + AI» не было бы вовсе.
Ни одна из этих цифр не отразится в отчетах. Их место – под графой «время, которого не было».
Стандартной метрики для «сжатия человеко-месяцев одним человеком» – нет. Стандартной метрики для «работы, которой альтернативно не было бы» – тоже нет.
Возвращаемся к самому началу. К картине и компьютеру.
Если сравнивать две картины по размеру диагонали – метрика формально существует, она дает число. Проблема не в метрике. Проблема в том, что размер диагонали не имеет отношения к тому, чем одна картина отличается от другой.
Если сравнивать два компьютера по цвету корпуса – то же самое. Метрика формально валидна, ответ формально получен. Только он не про производительность.
Метрика «сколько здесь ручками» – из того же ряда. Она формально существует и дает число. Раньше это число совпадало с ответом на вопрос «сколько человек сделал». Работа состояла в основном из «ручного» труда – все, что делается ручками, это и есть работа.
С AI это перестало быть правдой.
Один и тот же инструмент – например, Claude – у двух разных людей дает совершенно разный результат. Не разный на 10–20%. Разный качественно. Один получит поверхностный текст из общих мест. Другой – точную архитектурную рекомендацию под конкретную ситуацию.
Разница – не в AI. Разница в том, насколько человек владеет инструментом.
И вот здесь появляется пятая сцена – про ответственность. Если код написал AI, а результат передан клиенту – кто несет ответственность за качество?
В старой модели ответ прост: тот, кто напечатал код. Прямая связь между действием и ответственностью.
В новой модели ответственность не убирается. Она смещается: теперь ее несет тот, кто задавал контекст, кто проверял результат, кто принимал решение, что этот результат достаточно хорош для передачи клиенту. Инструмент – не субъект ответственности. Субъектом остается человек.
Но эта ответственность невидима, потому что кода мало. Со стороны кажется, что если кода мало, то и ответственности мало. Это не так. Ответственность за качество мультиклиентской архитектуры, работающей у пяти реальных компаний, – не меньше ответственности человека, делавшего тот же продукт в старой парадигме силами команды из четырех ролей. Даже больше – потому что в одиночку.
Стандартной метрики для «ответственности за результат в комбинации человек + AI» – нет.
Реальная метрика новой профессиональной категории – это качество владения инструментом. Насколько точно человек задает контекст. Насколько тонко чувствует, где AI ошибается. Насколько строго проверяет результат. Насколько глубоко понимает, где начинается его собственная ответственность, а где – ограничения инструмента.
Это и есть новая грамотность.
У этой новой грамотности пока нет ни собственного языка описания, ни системы подтверждения. Несколько вопросов, на которые ответа сейчас нет.
1. Что считать «качеством владения инструментом»?
Прошел курс по промт-инжинирингу – это подтверждение? Не совсем: курс даст базовые правила, но не гарантирует, что человек умеет применять их к сложной задаче.
Сделал продукт за 5 дней – это подтверждение? Тоже не совсем. Может быть, этот продукт можно было сделать за один день. Или он не такой сложный. Или он не работает.
Продукт работает на реальных пользователях и решает их задачу – ближе. Но и здесь неочевидно: что значит «работает»? Какое качество считать достаточным? Насколько устойчиво к нестандартным случаям?
2. Как измерять эффективность и оптимальность работы?
Одинаковый результат может быть достигнут очень по-разному. Быстрее или медленнее. С большими или меньшими затратами на инструмент. С большей или меньшей устойчивостью к следующему изменению задачи. С разной способностью передать работу другому человеку.
Что здесь мерить в первую очередь? Скорость? Стоимость вызовов инструмента? Точность? Способность переиспользовать наработанный контекст в следующей задаче? Стандартной методики оценки эффективности работы в связке с AI пока не сложилось.
3. Где брать точки сравнения?
Два человека называют себя «эксперт + AI». Как сравнить их уровень? Даже если оба справятся с одной задачей, разница может быть в подходе, устойчивости, стоимости достижения результата, скорости, глубине проработки. Ни одна из этих величин не имеет общей шкалы.
4. Нужно ли вообще подтверждать этот навык?
Может быть, вся система «дипломов, сертификатов, подтверждений» – артефакт индустриальной эпохи? А в мире, где инструменты усиливают эксперта в разы, единственный настоящий измеритель – это результат, показанный на реальных задачах, и все остальное – производные величины?
Ответа сейчас нет. Ни у HR-департаментов, ни у консалтингов, ни у самих носителей этой новой грамотности. Это вопрос, над которым индустрия только начинает думать.
29 июня 2026 года Boris Cherny, создатель Claude Code в Anthropic, опубликовал в X пост о пяти архетипах ролей будущего – Prototyper, Builder, Sweeper, Grower, Maintainer (ссылка на пост [2]). 2.6M просмотров за сутки.
Boris прямо пишет: эти архетипы не привязаны к профессии. В его команде дизайнеры, инженеры, продакт-менеджеры и data scientists распределены по разным архетипам вперемешку. Границы старых профессий размываются, и на их место приходит новая типология – независимая от того, «кто ты по диплому».
А значит: работа с AI перестала быть отличительным признаком отдельной роли. Она стала общим слоем – подразумевается по умолчанию во всех пяти архетипах.
Работа профессионала-с-AI уже существует. И для нее уже есть типологии – которые пишутся не в HR-департаментах и не в консалтинговых компаниях, а внутри компаний, делающих сами инструменты.
Языка ее оценки – еще нет.
Между этими двумя реальностями – не месяцы отставания. Возможно, десятилетие. И этот разрыв пройдет не тогда, когда LLM станут еще умнее, а тогда, когда система измерения работы догонит саму работу.
Это вызов не к инструменту. Это вызов к тому, что в наших головах давно устоялось, а сейчас требует переосмысления.
Метрика не при чем. При чем – то, к чему ее применяют.
Впервые опубликовано 4 июля 2026 года на VC.ru [3]: vc.ru/ai/3011579-kak-otsenit-rabotu-s-ai [4]
Автор: OlgaZhulikova
Источник [5]
Сайт-источник BrainTools: https://www.braintools.ru
Путь до страницы источника: https://www.braintools.ru/article/32796
URLs in this post:
[1] ошибку: http://www.braintools.ru/article/4192
[2] ссылка на пост: https://x.com/bcherny/status/2071379474277613732
[3] VC.ru: http://VC.ru
[4] vc.ru/ai/3011579-kak-otsenit-rabotu-s-ai: https://vc.ru/ai/3011579-kak-otsenit-rabotu-s-ai
[5] Источник: https://habr.com/ru/articles/1056872/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1056872
Нажмите здесь для печати.