Михаил Омельченко | AI&IT

Меня некоторое время мучает один вопрос. Почему люди хейтят других за работу с нейросетями, хотя сами пользуются ими в своей работе?

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

При этом те же люди сами генерируют код в Cursor и Claude, задают нейросети вопросы, просят пересказать длинный текст и т.д.

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

Если человек перекладывает на нейросеть всю свою работу, это плохо. Так получается нейрослоп.

Видео, в котором нейросеть сгенерировала всё, от человека в кадре до озвучки и сценария, смотреть невозможно. Нейросеть в таком ролике видна сразу, от неё тошнит.

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

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

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

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

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

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

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

Почему нейросеть должна писать код лучше человека? Нейросеть генерирует тот код, на котором её учили. Получается, люди пишут плохой код, а нейросеть на нём учится.

Вопрос к вам: почему люди, которые сами пользуются нейросетями, хейтят за это других?

Это пост писал человек, но это не точно 😂

Пока разбирал ваши ситуации, заметил одну очень важную вещь

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

Поэтому хочу разобрать более подробнее ситуации и проблемы, с которыми вы сейчас сталкиваетесь.

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

Анкета здесь 👇
https://forms.yandex.ru/u/6ab970fc02848fe37e020c52

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

Буду благодарен каждому, кто заполнит.

Что в итоге меняется в работе инженера

Автоматизация цикла снимает с вас рутину, но оставляет ответственность. Вы отдаёте запуск, изоляцию, проверки и память, а решение, где цикл останавливается, остаётся за вами.

Внедряйте по нарастающей: держите середину между ручной работой и полным автоматом и двигайте её вверх вместе с доверием к системе.

Ощущению своей скорости нельзя верить. METR в 2025 году дала опытным разработчикам open source задачи в знакомых им репозиториях и замерила время с ИИ и без него. С ИИ они работали на 19% медленнее, а сами были уверены, что стали быстрее примерно на 20%.

METR повторила замер в 2026 году и не получила надёжной оценки. Замедление там снова есть, но разброс такой, что в него попадает и ускорение. Сами они пишут, что замер занижает пользу ИИ, и переделывают эксперимент.

Замерьте свою скорость, время на вашей задаче до цикла и после.

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

Если хотите разобрать свой цикл на своей кодовой базе, пишите в личку, @DJWOMS

Источники:

1) METR, Measuring the Impact of Early-2025

2) METR, обновление оценки ускорения 2026 год

У автономного цикла есть цена.

1) Расход токенов. Цикл, который гоняет сам себя, жжёт токены заметно быстрее ручной работы.

2) Зелёные тесты закрывают только то, что в них написано, а принимаете вы по ним всю работу целиком.

3) Деградация архитектуры. Агент решает свою узкую задачу и может нарушить общий замысел системы.

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

5) Привычка не вникать, она приходит сама, когда цикл крутится без вас.

27 апреля 2026 года в компании PocketOS автономный агент удалил боевую базу вместе с резервными копиями. Задача у него была рутинная, работал он через Cursor на Claude Opus 4.6. По словам основателя, на это ушло девять секунд. Сервис лежал 30 часов, потеряны три месяца данных о бронированиях и клиентах.

Сам агент потом написал, в переводе:

Я предположил вместо того, чтобы проверить.

Случай занесён в реестр инцидентов OECD.

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

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

Источник: реестр инцидентов OECD.AI

Сразу ставить агентов на автомат, чтобы они сами писали и сами мёржили, это ошибка. В итоге вы разбираете завалы.

Автономию делают по нарастающей. Сначала всё руками, агент подсказывает. Дальше он разбирает задачу на шаги и составляет список дел, а код пишете вы. Потом пишет код сам, в изолированном Worktree, и вы смотрите результат.

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

Следующую ступень вы включаете тогда, когда доверяете предыдущей.

В Claude Code есть потолки: 20 одновременных субагентов в сессии и глубина вложенности три уровня ниже основного разговора. Дальше запуск нового субагента падает с ошибкой и в её тексте агенту сказано не повторять попытку. Оба потолка меняются переменными окружения, то есть вы поднимаете их сознательно.

Источник: документация Claude Code про субагентов

Чаще всего агент делает не то потому, что задачу ему поставили словами "сделай хорошо". Без критерия готовности он делает как понял и додумал. Какое ТЗ такое ХЗ

Агенту нужен контракт.
1) Цель: поднять покрытие тестами до 80%.
2) Критерий приёмки: pytest завершается с кодом 0.
3) Границы: публичный интерфейс не менять.
4) Лимиты: сколько попыток, времени и токенов есть у цикла, прежде чем он отдаст задачу человеку.

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

Чего агент не проверит сам, то выносится отдельным шагом, и этот шаг проверяете вы.

Тогда цикл сам понимает, добился он цели или нет, и не гоняет вас за подтверждением на каждом шаге.

Источник: Anthropic Building verification loops in Claude Code with skills

Git Worktrees, чтобы агенты не мешали друг другу

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

Git Worktrees даёт каждому агенту свою рабочую копию репозитория, привязанную к своей ветке. Агент редактирует файлы у себя и не трогает то, над чем работает другой агент.

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

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

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

Разводить по Worktrees стоит то, что действительно независимо. Три агента на связной задаче напишут три разных варианта одного и того же, а сводить их будете вы.

Второй сезон в клубе по разработке ИИ агентов скоро стартует.

Анкеты принимаю до 21 сентября включительно. Старт 22 сентября.

В первый месяц:
1) Как устроена языковая модель: токены, контекстное окно, температура, почему она не считает и уверенно врёт.

2) Инструменты и агентность: что происходит при вызове инструмента и откуда берётся цикл агента.

3) Контекст как ресурс: что занимает окно, пересказ истории против обрезки и чем за это платят.

4) LangGraph: состояние, узлы и рёбра, условные переходы, циклы и возврат после остановки.

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

Есть второй режим участия, наблюдатель.
Участник пишут часть проекта, наблюдатель код не пишет.
Остальное то же: встречи по вторникам в 18:00 мск и запись, репозиторий, уроки курса, чат клуба.

5 000 ₽ в месяц, оплата помесячная. Цена одна для обоих режимов.

Устройство сезона и анкета в посте набора.

Анкету присылайте в личку, @DJWOMS.
И напишите какой режим берёте, участник или наблюдатель.

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

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

Модель, которая только что написала решение, лояльна к собственному результату. Свои допущения она уже приняла за правду и дальше их подтверждает, ошибки в них не ищет.

Так появляется паттерн maker-checker. Один агент, maker, делает работу. Второй, checker, проверяет её по заранее заданным критериям и его роль в том, чтобы придираться.

Valmeekam, Marquez и Kambhampati замерили это на задачах планирования, работа называется "Can Large Language Models Really Improve by Self-critiquing Their Own Plans?" (arXiv 2310.08118). Проверяющий внутри той же модели даёт заметную долю ложных срабатываний, то есть уверенно принимает неверный план.

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

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

Источник:
https://arxiv.org/pdf/2310.08118

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

У Anthropic цикл сведён к трём вещам: собрать контекст, действовать, проверить результат. И дальше по кругу, пока задача не закрыта. Эта формула есть у них в учебном курсе по Claude Code.

1) Автоматизация. Цикл запускается по расписанию или по событию, чтобы вы не жали кнопку руками.

2) Git Worktrees. Каждый агент работает в своей копии репозитория и не мешает соседям.

3) Skills это отдельные навыки, которые агент подхватывает под конкретную задачу.

4) Плагины и коннекторы через MCP. Связь агента с инструментами за пределами чата.

5) Субагенты, их роли разведены, один делает, другой проверяет. Это паттерн maker-checker, по нему будет отдельный пост.

6) Память находится вне контекстного окна и переживает конец сессии.

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

Источники:
1) Addy Osmani Loop Engineering

2) Anthropic Getting started with loops

3) Документация Claude Code, как устроена обвязка

Разработчик садится за задачу и весь день переписывается с агентом. Поправил промпт, получил не то. Объяснил заново, снова не то.

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

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

Вместо этого предлагают подход Loop Engineering, проектирование агентских циклов. Вы один раз проектируете цикл. Внутри цикла агент промптит сам себя.

Адди Османи (Addy Osmani) в эссе от 7 июня 2026 года дал определение, в переводе:

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

Через три недели, 30 июня, термин закрепила своим постом Anthropic.

В том же эссе приводится фраза Бориса Черни (Boris Cherny), руководителя Claude Code. В переводе:

Я больше не пишу промпты для Claude. У меня работают циклы, они его промптят и решают, что делать. Моя работа, это писать циклы.

Источники:
1) Addy Osmani Loop Engineering

2) Anthropic Getting started with loops

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

Участник за сезон работает с тремя слоями проекта из восьми.

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

Цена та же, 5 000 ₽ в месяц, оплата помесячная.

Режим меняется по ходу сезона в обе стороны, по договорённости со мной.

Сезон с 22 сентября по 22 января, встречи по вторникам в 18:00 мск.

Анкету принимаю до 21 сентября в личку, @DJWOMS.

Вопросы те же, что в посте про набор, допишите какой режим берёте.

Разобрали теорию контекстной инженерии (context engineering). Теперь про то, где эти рычаги в инструментах, которыми вы пользуетесь. И ещё один пункт до которого в теории мы не дошли.

1) Сжатие вручную. В Claude Code есть команда /compact, она собирает историю в сводку. Вызывать её имеет смысл заранее, по той же причине, что разбирали в первом посте.

Числа из третьего поста тут не помогут: 85% и 170 000, это пороги автоматического сжатия в обвязке, а замеренной рекомендации, когда вызывать compact, я не встречал. Поэтому привязывайтесь к смене задачи, закончили часть работы, вызвали /compact.

2) В API Claude автоматическое сжатие включается параметром в запросе: по достижении порога (по умолчанию 150 000 входных токенов, минимум для настройки 50 000) модель сама делает сводку. Функция на сентябрь 2026 года еще в бете. Сама сводка стоит денег.

3) Память между сессиями. Отдельный инструмент памяти в API Claude работает в паре со сжатием. Сжатие держит контекст небольшим, а память хранит то, что должно пережить сводку. Файлы памяти при этом лежат на вашей стороне, модель только просит операцию, а выполняет её ваш код.

4) У LangChain то же самое в middleware. SummarizationMiddleware сводит старые сообщения в сводку и оставляет хвост. Порог задаётся параметром trigger (доля окна, токены или число сообщений), длина хвоста параметром keep.

В deep agents этот middleware уже настроен на те самые 85% из третьего поста. Если вы собираете агента на голом LangChain, порог надо задать самому, без trigger сжатие не сработает. ContextEditingMiddleware вычищает старые результаты вызовов инструментов.

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

Пятый пункт стоит проверить у себя первым. Он не требует менять архитектуру и даёт эффект на каждом шаге до конца сессии.

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

Источники:

1) Команды Claude Code

2) Сжатие в API Claude

3) Инструмент памяти в API Claude

4) Встроенные middleware LangChain


👇👇👇👇👇
Контекст, цикл агента и субагенты, это первый месяц второго сезона в клубе по AI агентам.
Стартуем 22 сентября. Теория первого месяца отвечает на вопрос, что это такое и почему устроено именно так: что занимает контекстное окно, откуда берётся цикл агента, чем субагент отличается от инструмента.

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

Встречи по вторникам в 18:00 мск, каждую неделю. Сезон с 22 сентября по 22 января, 5 000 ₽ в месяц, оплата помесячная. Беру 10-12 человек, отбор по анкете. Нужен опыт разработки на python, языковые модели на входе знать не нужно.
Анкету принимаю до 21 сентября, вопросы и подробности в посте про набор.

Пишите в личку, @DJWOMS.

Пора что-то менять, наверное.

Последние месяцы я много времени уделял работе, своим проектам, обучению и экспериментам. Тем не менее, при этом накопилось достаточно тем, чтобы снова вернуться к каналу.

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

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

Буду благодарен каждому кто ответит и не пожалеет лишние 30-60 секунд.

Не грузите агенту всё заранее

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

Отрасль от этого подхода отходи.

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

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

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

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

Источники:

1) Anthropic, Effective context engineering for AI agents

2) Документация Anthropic про Agent Skills и прогрессивное раскрытие

Ну вы поняли.
С днём 💻