Усталость от ИИ — это реальность, и никто об этом не говорит

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

Я зарабатываю на жизнь созданием инфраструктуры для ИИ-агентов. Я один из основных разработчиков OpenFGA (CNCF Incubating), я создал agentic-authz для авторизации агентов, Distill для дедупликации контекста, я выпустил MCP-серверы. Я не просто занимаюсь ИИ в свободное время. Я глубоко погружен в эту тему. Я создаю инструменты, которые другие инженеры используют для запуска ИИ-агентов в продакшене.

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

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

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

Парадокс, о котором нас никто не предупреждал

Вот что меня на некоторое время поразило: ИИ действительно ускоряет выполнение отдельных задач. Это не ложь. То, на что раньше у меня уходило 3 часа, теперь занимает 45 минут. Составление проектной документации, разработка нового сервиса, написание тестовых сценариев, исследование незнакомого API — всё быстрее.

Но мои дни стали сложнее. Не проще. Сложнее.

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

До появления ИИ я мог потратить целый день на одну проектную задачу. Я делал наброски на бумаге, думал в душе, шёл на прогулку, возвращался с ясностью. Темп был медленным, но когнитивная нагрузка была управляемой. Одна проблема. Один день. Глубокая концентрация.

А сейчас? Я могу решить шесть разных проблем за день. Каждая из них «занимает всего час с ИИ». Но переключение между шестью проблемами обходится человеческому мозгу невероятно дорого. ИИ не устает между проблемами. Устаю я.

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

Вы стали ревьювером, хотя и не хотели этого

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

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

Это принципиально другой вид работы. Создание заряжает энергией. Рецензирование истощает. Есть исследования на эту тему — психологическая разница между генеративными и оценочными задачами. Генеративная работа даёт состояние потока. Оценочная работа вызывает усталость от принятия решений.

Я впервые заметил это на неделе, когда активно использовал ИИ для нового микросервиса. К среде я уже не мог принимать простые решения. Как назвать эту функцию? Мне было всё равно. Где должна храниться эта конфигурация? Мне было все равно. Мой мозг был переполнен. Не написанием кода, а его проверкой. Сотни мелких проверок, целый день, каждый день.

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

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

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

Проблема недетерминизма

Инженеры обучаются детерминизму. Одинаковые входные данные, одинаковые выходные данные. Это контракт. Именно это делает возможной отладку. Именно это делает возможным рассуждение о системах.

ИИ нарушил этот контракт.

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

Почему? Без объяснений. Вернее, без объяснений, к которым я мог бы получить доступ. Нет трассировки стека для «модель решила пойти в другом направлении сегодня». Нет лога, который бы говорил, что «температурный семплинг выбрал путь B вместо пути A». Просто… всё произошло по-другому.

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

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

Именно это разочарование привело меня к созданию Distill — детерминированной дедупликации контекста для LLM. Никаких вызовов LLM, никаких эмбеддингов, никаких вероятностных эвристик. Чистые алгоритмы, которые очищают ваш контекст примерно за 12 мс. Я хотел, чтобы хотя бы одна часть конвейера ИИ была чем-то, что я мог бы анализировать, отлаживать и чему мог бы доверять. Если выходные данные модели будут недетерминированными, то, по крайней мере, я могу убедиться, что входные данные чистые и предсказуемые.

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

Беговая дорожка FOMO

Сделайте вдох и попробуйте угнаться за событиями последних нескольких месяцев. Claude Code выпускает суб-агентов, затем навыки, затем SDK для агентов, затем Claude Cowork. OpenAI запускает Codex CLI, затем GPT-5.3-Codex — модель, которая буквально помогла программировать саму себя. Новые агенты для программирования объявляют о фоновом режиме с сотнями одновременных автономных сессий. Google выпускает Gemini CLI. GitHub добавляет MCP Registry. Приобретения происходят еженедельно. Amazon Q Developer получает обновления для агентов. CrewAI, AutoGen, LangGraph, MetaGPT — выбирайте свой фреймворк для агентов, каждую неделю появляется новый. Google анонсирует A2A (протокол «агент-агент»), чтобы конкурировать с MCP от Anthropic. OpenAI выпускает собственный фреймворк Swarm. Выходит Kimi K2.5 с архитектурой роя агентов, управляющей 100 параллельными агентами. Вайб-кодинг становится популярным. OpenClaw запускает рынок навыков, и в течение недели исследователи обнаруживают более 400 вредоносных агентов, загруженных на ClawHub. И где-то посреди всего этого кто-то в LinkedIn пишет: «Если вы не используете ИИ-агентов с оркестровкой подагентов в 2026 году, вы уже устарели».

Это не год. Это несколько месяцев. И я многое упускаю.

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

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

Умножьте это на все категории — помощники по программированию, чат-интерфейсы, фреймворки агентов, платформы оркестрации многоагентных систем, MCP серверы, инструменты управления контекстом, библиотеки промптов, архитектуры роевых систем, маркетплейсы навыков — и вы получите человека, который постоянно изучает новые инструменты и никогда не углубляется ни в один из них. Одна только главная страница Hacker News способна вызвать головокружение. Сегодня это «Show HN: Автономный исследовательский рой», а завтра — «Ask HN: Как координируются ИИ роевые системы?» Никто не знает. Все так и работают.

Хуже всего — это утрата знаний. В начале 2025 года я потратил две недели на разработку сложного рабочего процесса для создания промптов. Тщательно продуманные системные промпты, примеры с небольшим количеством кода, шаблоны для построения логической цепочки мыслей. Всё работало хорошо. Три месяца спустя модель обновилась, лучшие практики создания подсказок изменились, и половина моих шаблонов дала результаты хуже, чем простая однострочная подсказка. Эти две недели пропали зря. Не вложены. Потрачены. То же самое произошло с моей настройкой сервера MCP — я создал пять пользовательских серверов (издатель Dev.to, интеграция с Apple Notes, песочницы Python и TypeScript и многое другое), затем протокол эволюционировал, потом на GitHub был запущен реестр MCP, и внезапно появились тысячи готовых решений. Часть моей собственной работы в одночасье стала лишней.

Смена фреймворков для агентов ещё хуже. Я наблюдал, как команды за год перешли от LangChain к CrewAI, затем к AutoGen и, наконец, к собственной оркестровке. Каждая миграция означала переписывание интеграций, переосмысление API, перестройку рабочих процессов. Те, кто ждал и ничего не делал, часто оказывались в лучшем положении, чем те, кто внедрил новые решения на раннем этапе и был вынужден мигрировать дважды.

С тех пор я перешёл на другой подход. Вместо того чтобы гнаться за каждым новым инструментом, я углубляюсь в инфраструктурный уровень, лежащий в их основе. Инструменты приходят и уходят. Проблемы, которые они решают, остаются. Эффективность контекста, авторизация агентов, журналы аудита, безопасность рантайма — это устойчивые проблемы независимо от того, какой фреймворк популярен в этом месяце. Именно поэтому я создал agentic-authz на OpenFGA, а не привязывал его к какому-либо конкретному фреймворку для агентов. Вот почему Distill работает на уровне контекста, а не на уровне подсказки. Стройте на том уровне, который не меняется.

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

Ловушка «ещё один промпт»

Это коварная ловушка. Вы пытаетесь заставить ИИ сгенерировать что-то конкретное. Первый результат на 70% верен. Поэтому вы уточняете свою подсказку. Второй результат на 75% верен, но сломал то, что было правильно в первом варианте. Третья попытка: на 80% верен, но теперь структура другая. Четвёртая попытка: вы занимаетесь этим 45 минут, а могли бы написать всё с нуля за 20.

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

Спираль подсказок особенно опасна, потому что она кажется продуктивной. Вы повторяете шаги. Вы приближаетесь к цели. Каждая попытка немного лучше. Но предельная отдача быстро уменьшается, и вы упускаете из виду тот факт, что целью никогда не было «заставить ИИ выдавать идеальный результат». Целью было внедрение функции.

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

Перфекционизм встречается с вероятностным выводом

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

Результаты работы ИИ никогда не бывают идеальными. Они всегда «довольно хороши». 70-80% успеха. Имена переменных немного неточны. Обработка ошибок неполная. Краевые случаи игнорируются. Абстракция не подходит для вашего кода. Он работает, но не идеален.

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

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

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

Атрофия мышления

Вот что меня пугает больше всего.

Я заметил это во время совещания с обзором проекта. Кто-то попросил меня проработать на доске задачу параллельного выполнения. Никакого ноутбука. Никакого ИИ. Только я и маркер. И мне было трудно. Не потому, что я не знал концепций — знал. А потому, что я не тренировал этот навык месяцами. Я так долго перекладывал свои первые черновые расчеты на ИИ, что моя способность мыслить с нуля деградировала.

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

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

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

Ловушка сравнения

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

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

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

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

Что действительно помогло

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

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

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

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

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

Я веду учет того, где ИИ помогает, а где нет. В течение двух недель я вел простой журнал: задача, использование ИИ (да/нет), затраченное время, удовлетворенность результатом. Данные оказались показательными. ИИ сэкономил мне значительное время на шаблонном коде, документации и генерации тестов. Он отнимал время на архитектурные решения, сложную отладку и все, что требовало глубокого понимания контекста моего кода. Теперь я знаю, когда стоит его использовать, а когда нет.

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

Вопрос устойчивого развития

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

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

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

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

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

По иронии судьбы, именно в период выгорания я создал некоторые из своих лучших работ. Когда я перестал пытаться использовать каждый инструмент ИИ и начал думать о том, что на самом деле не работает, я впервые ясно увидел проблемы. Контекстные окна, заполняющиеся мусором — это стало Distill. Агенты с доступом к API-ключу по принципу «всё или ничего» — это стало agentic-authz. Невозможность проверить, что именно делал агент — это стало AgentTrace. Усталость заставила меня перестать потреблять и начать создавать. Не создавать больше функций быстрее, а целенаправленно создавать правильные вещи.

Настоящее мастерство

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

Это знание, когда нужно остановиться.

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

Мы оптимизируем системы под устойчивость. Добавляем circuit breaker’ы. Реализуем backpressure. Проектируем graceful degradation. Нам стоит делать то же самое и по отношению к самим себе.

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

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

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

Берегите свой мозг. Он единственный, который у вас есть, и никакой ИИ не сможет его заменить.

Источник