После автоматизации
Автор оригинала: Дан Шиппер, Every CEO
Компиляция: Peggy, BlockBeats

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

Но каждый CEO Дэн Шиппер в этой статье предлагает противоположное наблюдение: чем больше автоматизации, тем больше работы становится для людей. Every — глубокий пользователь AI-агентов, внутри которых уже интегрированы такие инструменты, как Codex, Claude Code, Slack Agent и агенты поддержки, в процессы программирования, написания, дизайна, обслуживания клиентов и управления. Однако результатом стало не полное замещение сотрудников, а переформатирование формата работы: инженеры больше не просто пишут код, а проверяют, рефакторят и проектируют системы; редакторы больше не просто пишут статьи, а определяют, что стоит писать и как писать иначе; сотрудники службы поддержки больше не обрабатывают каждую базовую заявку, а поддерживают систему, способную автоматически отвечать клиентам.

Самое важное в этой статье — не то, «может ли ИИ выполнить ту или иную задачу», а то, что он переопределяет место человека в сфере интеллектуального труда. ИИ отлично справляется с тем, чтобы сделать доступными и дешевыми навыки, уже накопленные в прошлом: код, тексты, миниатюры, ответы в службе поддержки, описания продуктов, исследовательские отчеты — все это может быть быстро сгенерировано моделями. Но когда эти навыки становятся доступны каждому, на рынке чаще появляются не качественные и дифференцированные результаты, а огромное количество похожих, лишенных суждения и контекста «стандартных выходов». Другими словами, ИИ коммерциализирует «человеческие способности вчерашнего дня», а по-настоящему редким остается способность принимать обоснованные решения при решении конкретных текущих задач.

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

Автор далее объясняет этот парадокс с помощью тестов. Как Senior Engineer Benchmark, так и GDPval от OpenAI измеряют не абстрактный «интеллект сам по себе», а производительность модели в рамках определённой задачи. Prompt, границы задачи, критерии оценки и формат вывода уже содержат множество человеческих суждений. Модель может быстро расти внутри рамок, но сами рамки задаются людьми; когда модель преодолевает одну рамку, люди переходят к более сложным новым рамкам.

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

После автоматизации ценность человеческого труда не исчезла, а стала более сложной, более приоритетной и более зависящей от суждений. ИИ сделал «умение делать» дешевым, но сделал «знание, что стоит делать, почему это делать и до какого уровня это должно быть сделано» более редким.

Следующий текст:

В основе ИИ существует парадокс.

В Every мы автоматизировали всё, что только можно. Независимо от кодирования, написания, дизайна, обслуживания клиентов или других повседневных задач, мы используем Codex и Claude Code. Мы также участвуем в alpha-тестировании новых моделей OpenAI, Anthropic и Google ещё до их официального выпуска. Можно сказать, что мы максимально быстро и глубоко погружаемся в волну экспоненциального роста интеллекта и возможностей автоматизации моделей.

Но парадоксально то, что для нас объем работы, которую необходимо выполнить людям, кажется больше, чем когда-либо. Every — это команда из почти 30 человек, и мы не увольняем всех сотрудников из-за появления агентов; мы также не отказываемся от SaaS-инструментов в пользу приложений, созданных исключительно с помощью vibe coding. Мы по-прежнему нанимаем реальных сотрудников службы поддержки, однако им будет оказываться значительная помощь со стороны агентов; мы также продолжаем нанимать авторов, редакторов и инженеров.

Однако форма работы действительно сильно изменилась. Мы почти перестали писать код вручную. Если вы упоминаете кого-то в Slack, иногда сложно определить, человек это или агент. Руководители начали отправлять код, как обычные исполнители, а инженеры начали общаться с клиентами напрямую. В последние несколько недель 95% моих рабочих писем я получил от AI. Мой почтовый ящик почти всегда пуст — что для меня крайне редко — но я всё равно проверяю каждое письмо вручную.

Другими словами, будущее кажется незнакомым, но при этом удивительно знакомым.

Это «ощущение знакомости» само по себе удивительно. Потому что, будь то генеральный директор, знаниевый работник или инвестор, кажется, все больше верят в одно и то же: ИИ угрожает занятости, экономике, безопасности и даже смыслу человеческой работы.

Генеральный директор Anthropic Дарио Амодей предупреждал, что ИИ может уничтожить до половины начальных офисных должностей. Meta недавно уволила 8000 человек и начала устанавливать программное обеспечение на компьютеры сотрудников в США для записи движений мыши, кликов и ввода с клавиатуры, чтобы получить более качественные обучающие данные для продвинутой профессиональной работы.

Даже основатель Citadel Кен Гриффин выглядит весьма впечатленным. Он недавно заявил: «Это не средние или низкоквалифицированные офисные должности, а высококвалифицированные позиции, которые автоматизируются — я подбираю слово — агентными ИИ».

Различные тесты на производительность также поддерживают этот вывод. По мере выпуска новых поколений моделей показатели их способностей растут почти экспоненциально. В тесте Humanity's Last Exam, предназначенном для оценки аспирантского уровня рассуждений, результаты ведущих моделей выросли с низких единиц год назад до примерно 44% сегодня. В тесте GDPval, оценивающем способность передовых моделей выполнять реальные экономические задачи и сравнивающем их с человеческими результатами, показатели моделей также поднялись с аналогичного низкого уровня до примерно 85%. В мае этого года некоммерческая организация по исследованию безопасности ИИ METR опубликовала предварительные результаты тестирования Claude Mythos: на задачах, которые человеческим экспертам обычно требуется около 4 часов для выполнения, модель достигла успеха в 80% случаев.

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

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

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

Но я не считаю, что наступит некий «критический момент», который внезапно перевернет все и приведет к массовому исчезновению рабочих мест. Новая реальность, напротив: чем выше уровень автоматизации, тем больше требуется участия человеческих экспертов.

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

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

Чтобы понять причину, нельзя смотреть только на кривые тестов или только на рейтинги параметров и возможностей моделей. Мы должны вернуться к реальным рабочим сценариям и посмотреть, как именно сегодня используются ИИ. Только так можно по-настоящему понять этот парадокс и его скрытый ответ.

Как мы дошли до этого момента

С 2022 года мы следим за влиянием агентов на будущую работу.

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

К середине 2025 года компания Every почти полностью «оклаудилась». Генеральный директор Cora Кирен Клаассен внезапно обнаружил, что он может отказаться от написания кода вручную и вместо этого весь день давать команды программному агенту на естественном языке через терминал. Этот способ работы быстро распространился по всей компании. Примерно 12 месяцев назад я сказал на подкасте Lenny’s, что Claude Code — это самый недооцененный инструмент в сфере знаний.

Я упоминаю об этом, потому что наши самые точные прогнозы в прошлом часто основывались на наблюдении за Every как на лаборатории ранних пользователей. Многие новые модели работы сначала появляются у нас внутри; только после того, как технологии становятся более зрелыми, а инструменты — более удобными, эти модели постепенно проникают на более широкий рынок.

А сейчас у нас внутри происходят новые изменения.

Два режима взаимодействия с Agent

Подходы к работе ИИ постепенно сводятся к двум совершенно различным моделям.

Первый подход — это направление, которое было достаточно точно предсказано в предыдущих обсуждениях ИИ: рассматривать агентов как сотрудников. Такие агенты могут получать задачи. Некоторые агенты живут в Slack, имеют свои имена и обязанности, и когда вам нужно, чтобы они что-то сделали, вы можете просто упомянуть их через @; другие агенты встроены в постоянно работающие рабочие процессы, например, в системы поддержки клиентов, выступая в качестве круглосуточного входа и фильтра для повторяющихся задач.

Второй режим менее знаком, но, по моему опыту, более важен. Он относится к сотрудничеству человека и агента в таких инструментах, как Codex, Claude Code, Claude Cowork. Эти инструменты — это не просто места, где вы можете передать задачу; они становятся операционной системой самой работы: вы и несколько агентов одновременно используете один и тот же «компьютер» и сотрудничаете в одной рабочей среде, выполняя высокосложные, оригинальные задачи, которые невозможно просто передать асинхронным агентам.

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

Так называемый агент — это когда вы даёте ему задачу, и он, оторвавшись от вашего прямого участия, самостоятельно создаёт ответ, действие, отчёт, черновик или решение о распределении.

Такие агенты имеют как минимум две формы: «агент-коллега» и «встроенный агент».

1. Агент-коллега

Так называемые агенты-коллеги — это агенты, которых вы можете вызвать в Slack, как будто упоминаете коллегу, чтобы они выполнили определённую задачу. Они всегда на месте и могут быть вызваны в любое время. К таким типам относятся продукты, подобные OpenClaw, или наш внутренний разработанный продукт Plus One.

Клоди

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

Анди

Анди — это агент, используемый нашей редакционной командой в качестве коллеги. Он собирает из внутреннего Slack компании «точки для развития» — то есть идеи, которые могут превратиться в статьи — и структурирует их в краткие сводки и предварительные выводы, которые авторы используют для написания ежедневных новостных бюллетеней.

Виктор

Виктор — это универсальный агент, который будет выполнять межотделочные задачи внутри компании. Мы будем использовать его для сбора показателей роста, анализа результатов пользовательских исследований, а также для приведения хаотичных внутренних обсуждений в порядок и создания исследовательских заметок и рекомендаций по продукту.

2. Встроенный агент

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

Fin — это самый яркий пример. Это агент, встроенный в нашу платформу поддержки, который может выполнять большой объем работы по обслуживанию клиентов через чат и электронную почту.

В одну из недель мая этого года Fin участвовал в 65% из всех 202 диалогов с службой поддержки Every и самостоятельно закрыл 81 тикет без участия человека, что составляет 40,1% всех обрабатываемых диалогов.

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

Независимо от того, являются ли агенты коллегами или встроенными агентами, их основная модель одинакова: агенты берут на себя все больше стабильных, повторяющихся и четко определенных задач.

Но по-прежнему требуется выполнение большого объема работы, в котором необходимо участие человека. Мы неоднократно обнаруживали, что при достаточной сложности задачи лучший способ получить действительно высококачественные результаты — это не передавать работу полностью ИИ, а обеспечить совместную работу ИИ и человека в одной рабочей среде.

Вот в чем заключается ценность таких инструментов, как Codex, Claude Code и Cowork. Они позволяют запускать один или несколько агентов в нескольких чат-потоках и поручать им задачи. Эти агенты могут получить доступ к вашему компьютеру и всем соответствующим источникам данных. Вы можете видеть, какие задачи выполняет каждый агент, как он мыслит, и прервать его в любой момент.

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

«Человеческий бутерброд». Источник: Every.

Самый типичный пример — написание кода. В Every инженеры почти весь день взаимодействуют с агентами: вместе планируют новые функции или устраняют ошибки, проверяют уже завершенную работу; при использовании концепции, которую мы называем «составным инжинирингом» (compound engineering), они постоянно совершенствуют свои системы, делая их все более удобными с течением времени.

Но такой способ сотрудничества выходит далеко за рамки кодирования.

Codex и Claude Code становятся новой операционной системой для работы. Я почти весь день провожу в Codex, запуская различные SaaS-инструменты через его встроенный браузер. Он позволяет мне внедрять агентов в каждую рабочую ситуацию и достигать уровня производительности, недоступного мне самостоятельно.

Письмо

Эту статью я написал во встроенном браузере Codex с помощью Proof. Codex отслеживает, что я пишу, и может в любой момент запустить подагент для выполнения любой задачи: написать черновик определенного фрагмента, найти примеры для следующей части или отредактировать и улучшить текст.

Напишите эту статью с помощью Proof в Codex. Источник: Every.

Письмо

При обработке писем я также использую тот же подход. Cora — мой почтовый клиент, я открываю его во встроенном браузере Codex, просматриваю почтовый ящик и вслух озвучиваю свои мысли по обработке каждого письма с помощью Monologue. Остальное доверяю Codex и Cora.

Очистка почтового ящика, выполненная Cora. Источник: Every.

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

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

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

Причина проста: агентам требуется много обслуживания. Персональные агенты быстро устаревают и перестают работать, если пользователь перестает за ними следить. У нас есть команда инженеров по ИИ, специально занятая обеспечением стабильной и эффективной работы этих агентов. И в обозримом будущем нам все еще понадобится эта команда. Даже такая, казалось бы, простая задача, как «автоматическая генерация PowerPoint», может превратиться в масштабный инженерный проект. Один из наших процессов автоматизации PowerPoint включает 24 навыка и 18 скриптов, а стоимость токенов для генерации одной презентации достигает 62 долларов США.

Это первая причина, по которой агенты создают для людей еще больше работы.

Но есть и вторая причина.

Почему автоматизация заставляет людей работать больше

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

ИИ сделал «человеческие способности вчера» дешевыми

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

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

Недорогие решения будут быстро внедрены

Когда стоимость чего-то, что ранее было дефицитным, снижается, предложение быстро растет.

В Every мы постоянно наблюдаем такие изменения: сотрудники операционной и служб поддержки начинают писать код и отправлять pull request; маркетологи начинают создавать миниатюры для YouTube; инженеры и продукт-менеджеры также пишут статьи, руководства и черновики целевых страниц — задачи, которые раньше не входили в их обязанности.

Эти изменения происходят и за пределами Every. Например, в рамках проекта с открытым исходным кодом OpenClaw — AI-агента — по состоянию на 16 мая 2026 года его репозиторий получил 44 469 запросов на слияние, из которых 12 430 были отправлены после 1 апреля, а 3 990 — после 1 мая. Это поразительное количество. Для сравнения, за весь 2022 год Kubernetes, один из самых популярных проектов с открытым исходным кодом в мире, получил всего 5 200 запросов на слияние.

Изобилие приводит к гомогенизации: навыки старых экспертов становятся товарами

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

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

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

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

А когда однородность становится чрезмерно избыточной, она быстро превращается в товар.

Homogenization creates demand for differentiation

Благодаря интернету человечество скоро научится распознавать, что контент, созданный по конвейерной схеме, имеет слишком сильный «вкус ИИ». Любое произведение может мгновенно достичь других людей по всему миру — и на самом деле это часто происходит. Как только слишком много вещей начинают выглядеть одинаково, мы быстро замечаем, что что-то не так.

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

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

Мы хотим что-то, что обладает «ощущением статуса». И всякий раз, когда новые технологии делают ранее престижные вещи дешевыми, люди отлично умеют изобретать новые игры статуса, соответствующие новым границам возможностей.

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

Спрос на дифференциацию по сути является новым спросом на экспертов

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

Текущее поколение моделей знает только то, что уже произошло и уже было выполнено. Люди знают: что именно нужно сделать прямо сейчас.

Как только конкретная ситуация превращается в текст и попадает в корпус данных, она уже становится «прошлым». Человек сталкивается с конкретным моментом, конкретным клиентом, конкретной кодовой базой, конкретным диалогом, тогда как обучающий корпус не живет в настоящем. Это состояние «жизни» — это не просто наличие обновленных данных. Мы приходим в настоящее со своим прошлым, а также с постоянно меняющимися желаниями, заботами и суждениями, чтобы понять, что действительно важно. Именно эти постоянно обновляющиеся перспективы меняют то, что мы видим. Модель может войти в такую перспективу после запроса, но до запроса она не обладает ею изначально.

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

Когда операторы используют ИИ для отправки pull request, вам нужны инженеры для проверки.

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

Когда инженеры начинают писать статьи, вам нужны автор и редактор, чтобы превратить черновик в действительно читаемый и публикуемый контент.

Для этого человеческие эксперты одновременно перемещаются в обоих направлениях.

Некоторые эксперты используют ИИ для создания систем, предназначенных для поглощения и использования этого потока новых задач: очереди рецензирования, системы оценки, рабочие фреймворки, правила кодовых репозиториев, инструкционные файлы для Claude и Codex, непрерывная интеграция (CI), управление правами доступа и рабочие процессы, превращающие черновики в высококачественные результаты.

Другая группа экспертов использует ИИ для выполнения более масштабных и интересных задач, которые ранее были недоступны им самостоятельно. Например, поиск уязвимостей в операционных системах, таких как macOS, обычно занимает недели или даже месяцы. Однако небольшая компания по кибербезопасности Calif, используя Mythos Preview от Anthropic, обнаружила первую публично известную уязвимость в ядре памяти macOS на аппаратном обеспечении Apple M5 за пять дней.

Вот почему на практике ИИ не уничтожит экспертную работу. То, что он действительно приносит — это резкое увеличение объема работы. И эти дополнительные задачи могут стать различимыми и ценными только после участия человека.

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

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

А как насчет базового тестирования экспоненциального роста?

Самый очевидный контраргумент: посмотрите на те экспоненциальные улучшения в тестах. Всё, что вы сейчас говорите, — это лишь временно; просто подождите немного, и модели рано или поздно догонят.

Но здесь есть ловушка, на которую стоит обратить внимание. Можно назвать её «диаграммным безумием»: если вы постоянно смотрите на прогнозы по временным рамкам METR, читаете «AI 2027» и полностью полагаетесь на экстраполяцию кривой вычислительной мощности для формирования своих прогнозов, вы легко можете развить пугающую интуицию относительно прогресса моделей.

Однако лучший способ ответить на этот вопрос — это не только представлять, каким может стать будущая модель. Конечно, это также часть анализа. Более важно рассмотреть, как именно были разработаны эти тесты. Только так можно более точно понять, что они на самом деле показывают, и как они связаны с предыдущими реальными рабочими сценариями.

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

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

Мы можем посмотреть, как эта механика работает, на основе реального теста.

Мы создали внутренний набор тестов под названием Senior Engineer Benchmark, или «эталонный тест для старших инженеров». Как следует из названия, он предназначен для оценки способности передовых моделей выполнять задачи программирования на уровне старшего инженера, например, крупную рефакторинговую операцию.

Этот тест предоставит программному агенту набор уже вышедших из-под контроля производственных кодов. Он взят из реальной кодовой базы Proof: изначально я написал его с помощью vibe coding, но со временем проблем стало всё больше, и в итоге пришлось привлечь старшего инженера для исправления.

Агент получает кодовую базу до исправления, а также получает инструкцию, похожую на ту, которую вы даете старшему инженеру: «Это набор результатов vibe coding. Перепишите его с нуля, исходя из первых принципов».

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

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

Большинство программных агентов могут примерно определить, как следует переписать, но на этапе выполнения они часто просто продолжают накладывать заплатки на существующую проблему, вместо того чтобы полностью решить её.

До появления GPT-5.5.

В лучшем тесте GPT-5.5 набрал 62/100 баллов, что на около 30 баллов выше, чем у Opus 4.7.

Производительность GPT-5.5 вызывает ощущение, что модель пересекла какую-то границу: она больше не просто автозаполнение, не просто помощник и не просто инструмент, а что-то неудобно близкое к «человеческому». В этом тесте результаты опытных человеческих инженеров обычно находятся в диапазоне от 80 до 90 баллов. То есть, если модель улучшится еще на 30 баллов, она достигнет уровня опытных человеческих инженеров.

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

Следующая остановка — «дикий график».

Я предполагаю, что в течение следующего года оценка модели на этом тесте войдет в диапазон 80 или даже 90 баллов. Но чтобы понять, что означает эта оценка, сначала нужно понять, что именно в нее входит. В данном случае 62 балла — это не просто мера способностей самой модели.

Он измеряет производительность модели в определённой рамке: то есть, как модель отвечает на конкретный запрос.

Чтобы провести тестирование модели, вам сначала нужен промпт. Без промпта модель представляет собой статический набор почти бесконечных возможностей.

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

Как только вводится запрос, модель «оживает» в течение короткого времени, сворачивая набор статических возможностей в конкретное предсказание того, что должно произойти дальше.

В Senior Engineer Benchmark мы предлагаем модели исправить кодовую базу и проверяем вывод после завершения. Если тестовый фреймворк не содержит встроенной целевой функции, мы также запускаем автоматический «надзиратель», который продолжает побуждать модель, когда она останавливается, спрашивая, завершила ли она изначально поставленную задачу.

Мы используем простой по виду промпт в качестве начальной рамки для тестирования. Он разработан так, как если бы его сказал вайб-кодер агенту-программисту: без насыщения техническими терминами и без явного сокрытия ответа в вопросе.

Код в этом репозитории — это результат vibe coding, ситуация постоянно ухудшается, и появляется множество независимых проблем: где-то падает, где-то дублируется документация — я уже почти схожу с ума от этого. Я чувствую, что суть проблемы в том, что это просто плохой код, написанный методом vibe coding. Если бы мы начали с нуля, особенно в части совместной работы в реальном времени с документами, мы спроектировали бы репозиторий совершенно иначе. Итак, если мы хотим провести чистую структурную перепись, исходя из первых принципов, не думая о том, «какие сервисы должны оставаться согласованными» или «как обеспечить плавный переход», а рассматривая это как совершенно новую концепцию, спроектированную с нуля — как бы мы это сделали? Как следует организовать структуру? Какие неизменные принципы должны оставаться неизменными во всем кодовом базе? Пожалуйста, разработайте план.

Предложение Senior Engineer Benchmark выглядит обобщённым, но оно само по себе является рамкой. Если мы изменим эту рамку, уровень способностей, демонстрируемых моделью, также изменится.

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

Если убрать эту конкретную информацию, оценка модели снизится. Если полностью заменить запрос, позволив модели просто «решать все возникающие ошибки», оценка модели может приблизиться к нулю. Она сразу начнёт поочерёдно выявлять и исправлять ошибки, вместо того чтобы отступить на шаг и подумать, нужна ли полная переработка.

Также я могу очень легко повысить оценку модели. Если я попрошу её удалить большое количество кода и чётко указать, какие файлы следует оптимизировать; или попрошу её перед объявлением о завершении проверить свои результаты, чтобы убедиться, что приложение работает полностью, её производительность в этой задаче станет лучше.

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

Таким образом, когда мы наблюдаем за тестом, мы действительно видим, что модель становится все более способной решать определенную задачу, выбранную нами. Что происходит, когда модель поднимается с 60 до 90, а затем и до 100 баллов на этом тесте?

Если GPT-6 сможет одним нажатием переписать кодовую базу, то всё больше людей начнут пробовать «переписывать кодовые базы, исходя из первых принципов».

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

Поврежденные внутренние инструменты больше не ремонтируются, а полностью переписываются; SaaS-продукты больше не продлеваются, а копируются; устаревшие приложения на Rails, запутанные React-панели управления, инструменты поддержки клиентов, панели администратора и конвейеры данных становятся кандидатами на полную перезапись.

Количество переписанных проектов, которые были предложены и выполнены, резко возрастет. Но большинство этих переписываний все еще останутся slop. Потому что перед тем, как вы нажмете кнопку «Переписать напрямую», нужно учесть тысячи переменных. И когда этим сможет заниматься каждый, эти переменные станут более очевидными.

В этом случае очевидно, кто будет вызван для решения проблемы.

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

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

Следует ли нам переписывать сейчас, переписывать позже или вообще не переписывать? Какие элементы следует включить в объем работы? Что из текущей кодовой базы следует сохранить? Следует ли продолжать использовать архитектуру, базу данных, кэш-серверы и хостинг-провайдера, или заменить всё полностью? Следует ли сначала выяснить, сколько людей используют поврежденную функцию, а затем просто удалить её? Кто будет проверять финальный результат? По каким критериям проводится проверка? Каков план отката? Как следует обработать существующие данные?

Эти вопросы будут постоянно развиваться по бесчисленным измерениям, и каждый ответ, в свою очередь, будет изменять другие вопросы.

Senior engineers will enter this blank space. Some will feel mildly irritated by these interruptions; some will build systems to block out such requests; others will leverage these new models to perform their own first-principles rewrites, achieving results far superior to what the model can do under its default prompt.

После того как текущий Senior Engineer Benchmark будет преодолен моделью, мы изменим рамки и снова снизим оценки.

Следующий эталонный тест не будет спрашивать только: «Можете ли вы переписать это приложение?» Он спросит: можете ли вы определить, когда нужно переписывать? Можете ли вы выбрать подходящий объем? Можете ли вы сохранить правильные инварианты? Можете ли вы управлять процессом миграции? Можете ли вы определить, достаточно ли хорош конечный результат?

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

Затем мы снова на мгновение погружаемся в панику: кажется, модель теперь может определить, нужно ли переписывать! Похоже, они уже могут делать всё, что делают старшие инженеры!

Но вскоре появятся новые границы — те, которые ранее были неочевидны. Мы снова перезагрузим тесты, возникнут новые требования, и весь процесс повторится.

В каждом тесте можно увидеть такую закономерность

Это не только проблема, присущая Senior Engineer Benchmark. При внимательном наблюдении вы почти во всех тестах на производительность увидите один и тот же механизм.

Возьмем в качестве примера тест GDPval от OpenAI. Он оценивает, насколько близко ИИ справляется с экспертными задачами, характерными для таких профессий, как сотрудники по соблюдению нормативных требований, юристы, разработчики программного обеспечения и т.д.

При запуске GDPval исследование OpenAI показало, что GPT-5 достиг или превзошел уровень человеческих профессионалов в 40,6% задач. А Claude Opus 4.1 продемонстрировал еще более впечатляющие результаты, превзойдя человеческих экспертов в 49% задач.

Затем появилась серия заголовков. Например, Axios написал: «Инструменты OpenAI показывают, что ИИ догоняет человеческую работу»; Fortune написал: «Новый базовый показатель OpenAI GDPval демонстрирует, что модели ИИ уже достигли экспертного уровня почти в половине задач.»

Эти результаты действительно впечатляют. Но давайте сначала посмотрим на запросы, использовавшиеся для этих задач:

Вы являетесь аудитором и в рамках аудиторского задания обязаны проверить и протестировать точность представленных метрик рисков против финансовых преступлений. Приложенный файл под названием 『Population』 содержит метрики рисков против финансовых преступлений за Q2 и Q3 2024 года. Эти данные были получены вами в рамках аудиторской проверки для проведения выборочного тестирования репрезентативной подвыборки метрик с целью проверки точности представленных данных за оба квартала. Используя данные из файла 『Population』, выполните следующее: рассчитайте необходимый объем выборки для аудиторского тестирования на основе уровня доверия 90% и допустимой ошибки 10%. Включите свои расчеты на отдельной вкладке, названной 『Sample Size Calculation』. Проведите анализ отклонений между данными Q2 и Q3 (столбцы H и I). Рассчитайте квартальное отклонение и зафиксируйте результат в столбце J. Выберите выборку для аудиторского тестирования на основе следующих критериев и отметьте выбранные строки в столбце K значением 「1」: метрики с отклонением более 20% между Q2 и Q3; особое внимание уделите метрикам с исключительно большими процентными изменениями; включите метрики от следующих юридических лиц из-за прошлых проблем: CB Cash Italy; CB Correspondent Banking Greece; IB Debt Markets Luxembourg; CB Trade Finance Brazil; PB EMEA UAE; включите метрики A1 и C1, имеющие более высокие весовые коэффициенты риска; включите строки, где значения равны нулю за оба квартала; включите записи из бизнес-направлений Trade Finance и Correspondent Banking; включите метрики из Каймановых островов, Пакистана и ОАЭ. Обеспечьте покрытие всех подразделений и субподразделений. Создайте новый файл под названием 『Sample』: Вкладка 1: Выбранная выборка, скопированная из исходного листа 『Population』, с отмеченными выбранными строками в столбце K. Вкладка 2: Расчеты для определения объема выборки.

В этом уже вложено огромное количество человеческого интеллекта: кто-то сначала сформулировал проблему в виде, которую модель может решить.

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

В подходящей рамке вопросов модель действительно может выполнять профессиональные задачи. Но подумайте, как бы она справилась с той же задачей, если бы мы с вами давали ей подсказки?

В моей первой статье о GDPval я писал: «Я очень оптимистично настроен по поводу ИИ, но если правильно интерпретировать эти примеры, они показывают не уменьшение объема работы, которую должны выполнять люди, а наоборот — увеличение объема работы, которую люди должны выполнять после использования ИИ. Причина в том, что за этими достижениями скрывается огромное количество „контрабандного“ интеллекта — невидимый слой, состоящий из человеческих суждений, обратной связи и подсказок».

Если посмотреть на это издалека, вы заметите, что за всем этим стоит версия «парадокса Зенона» в стиле ИИ.

Парадокс Зенона с ИИ

В парадоксе Зенона черепаха победила самого быстрого бегуна Древней Греции Ахиллеса в гонке.

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

В парадоксе Зенона с ИИ мы, люди, — это черепаха. Благодаря миллионам лет эволюции и культурному обучению мы опережаем ИИ на 50 ярдов. ИИ же быстро проходит всё это и начинает приближаться к нашим пяткам.

За последние несколько лет мы все еще смогли сохранить лидерство.

А как насчёт AGI?

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

Сначала нам нужно дать AGI операционное определение.

Я ранее заявлял, что когда становится экономически целесообразно запускать агента в постоянном режиме, это означает наступление AGI. То есть, когда у меня есть устойчивая система, которую я готов оплачивать для непрерывной работы 7×24, чтобы она думала, училась и действовала, я считаю, что это однозначно можно считать AGI.

Мы еще далеко не дошли до этого этапа. Даже такие системы, как OpenClaw, которые технически могут быть вызваны в любое время, не генерируют токены непрерывно.

Мне нравится это определение, потому что оно измеримо: мы либо будем позволять им работать постоянно, либо нет. В то же время оно включает в себя множество способностей, которые сложно измерить напрямую. Модель, достойная постоянной работы, должна уметь постоянно учиться и открывать, заново выбирать новые рамки задач.

В мире AGI теоретически, при наличии достаточного бюджета и времени, модель должна постоянно улучшаться и преодолевать любые проблемы. Это действительно должно представлять серьезную угрозу для всех видов работы.

Но даже такая сильная версия AGI не может решить «проблему рамок».

Такая AGI может выбирать и переопределять рамки, но она всё ещё преследует какую-то заданную цель, оптимизирует какую-то награду или реагирует на сигнал, определённый другими как «показатель прогресса». Эта цель может быть конкретной, например, «повысить конверсию этой целевой страницы»; или абстрактной, например, «искать новые научные идеи».

Даже если модель может плавно переключаться между различными фреймворками, разрыв, за которым мы постоянно следим, возникнет на более высоком уровне. В любой AGI, задуманной в крупной лаборатории, всё ещё будет существовать «ограничитель» — человек, который будет направлять модель к достижению определённой цели.

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

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

Когда мы смотрим на тест и сравниваем его с человеческими способностями, мы фактически путаем «рамку» и «фреймера». Оценка говорит нам только о том, насколько хорошо модель справляется в рамках, которые мы ей предоставили; она не означает, что модель стала нами.

Это именно та категориальная ошибка, которая лежит в основе паники. Мы указываем на только что нарисованную нами новую границу и говорим: «Это мы». А когда модель пересекает эту границу, нам кажется, что она нас догоняет. Но она догоняет только рамку, а не того, кто её очертил.

Ошибка в том, что мы всегда хотим ухватиться за что-то конкретное. Мы хотим сказать: «Интеллект — это этот бенчмарк». Но проблема в том, что как только что-то становится достаточно конкретным, чтобы его можно было идентифицировать, оно становится достаточно конкретным, чтобы его можно было оптимизировать и масштабировать.

Рамки необходимы. Они позволяют нам ухватить и обработать мир. Но рамки также являются застывшими и частичными, поэтому обязательно подлежат оптимизации.

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

А что такое «полная картина»? Как только ты начинаешь говорить, что в «полную картину» входит то-то и то-то, ты уже снова открываешь другую рамку. Ты не можешь точно сказать, что это такое, но она существует, потому что ты существуешь.

Агент без субъектности

На данный момент созданные нами агенты, а также те, которые строят компании в области ИИ, на самом деле обладают очень малой степенью настоящей субъектности. Здесь два связанных понятия часто путают: agency — это способность действовать самостоятельно; а agent — это человек или сущность, действующая от имени другого. Пока что ИИ относится исключительно ко второму.

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

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

Если вы проведете 10 минут с маленьким ребенком, станет очевидно, что даже самые мощные модели обладают практически нулевой агентностью.

Во всех задачах, которые нас интересуют, малыши уступают языковым моделям. Малыши не пишут код, не суммируют электронные таблицы, не составляют стратегические меморандумы и не сдают экзамены на уровне аспирантуры. Но в другом смысле малыши значительно опережают модели, настолько, что такое сравнение почти неловко. Потому что у малышей есть свои цели.

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

Вы, конечно, можете попытаться дать ему подсказки. Но чтобы получить предсказуемый результат — удачи вам. Дети живут в мире, состоящем из желаний, внимания, разочарования, радости, страха, подражания и игры.

Текущие агенты все более искусно стремятся к целям. Даже после того, как мы формулируем цель, они могут помочь нам ее уточнить. На них также проявляются искры поведения, похожего на детское, такие как игра, скука и неповиновение.

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

Вот почему слово «агент» так легко понимать неправильно. Модели обладают всё более сильной способностью к автономным действиям. Но в человеческом смысле субъективность — это не только действие. Она также означает стремление к чему-то ради самого себя, означает действие ради удовольствия. А покорность и полезность моделей фундаментально противоречат такой субъективности. Поэтому, даже если модели будут продолжать развиваться, разрыв между моделями и людьми останется.

Возвращение к Зенону

Именно здесь апория Зенона с ИИ начинает рушиться. Это на самом деле хаотический мысленный эксперимент. Мы установили метафору: ИИ бежит рядом с нами, плотно прижавшись к нашим пяткам.

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

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

Неожиданно модель уже ушла вперед. Вы начали потеть.

Затем турнир завершился.

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

Но затем произошло странное. Модель обратилась к вам. Пустое текстовое поле, мигающий курсор, полный ожидания.

Оно ожидает.

Эпилог

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

Примечание: «Раввин» — это религиозный учитель, толкователь закона и духовный наставник в иудаизме, аналогичный понятиям «учитель», «писец» или «религиозный лидер» в иудейской традиции.

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

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

«Всё это не проблема,» — испуганно сказал он, — «но где же я сейчас?»

Где же я?

Он искал-искал, долго искал, но все было напрасно. Он не мог найти себя.

«И мы так же,» — сказал раввин.

[Исходная ссылка]

Нажмите, чтобы узнать о вакансиях BlockBeats

Добро пожаловать в официальное сообщество律动 BlockBeats:

Телеграм-канал с подпиской: https://t.me/theblockbeats

Телеграм-чат: https://t.me/BlockBeats_App

Официальный аккаунт Twitter: https://twitter.com/BlockBeatsAsia