Казалось бы, инструменты настроены, Дирижёр готов. Но на этапе масштабирования — когда в ход идут рои агентов, десятки навыков (Skills) и модные MCP-сервера — нас ждёт новая ловушка - «Бюрократический ИИ» 🧐

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

Тут срабатывает фундаментальный «Баг простоты»: чем сложнее и длиннее мы объясняем инфу, тем хуже нейронка её усваивает. Это прямая отсылка к нашей магии 40 токенов — ИИ лучше всего работает с короткими, атомарными и понятными блоками данных.

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

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

Схема промпта-шаблона для ваших задач:

«У меня есть [ОБЪЕКТ/ЗАДАЧА] для [ЦЕЛЬ/СФЕРА ДЕЯТЕЛЬНОСТИ]. Твоя задача – помочь мне улучшить [ЧТО ИМЕННО УЛУЧШАЕМ]. Для этого разбей задачу на [ПЕРЕЧЕНЬ ЭТАПОВ АНАЛИЗА, например: источники, извлечение факторов, синтез] и действуй по алгоритму ниже.

В первом ответе ты запросишь мой [ИСХОДНЫЙ МАТЕРИАЛ: вопрос, текст или идею]. Получив его, помоги:

Сформулировать [КОЛИЧЕСТВО] главную цель и [КОЛИЧЕСТВО] уточняющих [ВОПРОСА / ГИПОТЕЗЫ / ПОДЗАДАЧИ].

Указать, какие [РЕСУРСЫ / ДАННЫЕ / КРИТЕРИИ] считать допустимыми доказательствами или базой.

Провести Double-check: дать правила для верификации и «красные флаги» (чего избегать).»

Объяснение промт-шаблона выше:

Этот шаблон в квадратных скобках — это на самом деле не «просьба», это пример процедурного контракта.

• Вы не просите его «быть кем-то». Вы задаёте ему алгоритм работы: «Сначала спроси данные -> потом выдели цели -> потом определи критерии».
• Это по сути Мета-контракт. Мы заставляем ИИ сначала построить «рельсы» для самого себя (сформулировать контракт задачи), а уже потом ехать по ним. В этом нет противоречия, если объяснить, что мы заменяем «литературщину» на «протокол».

Этот метод принудительно выводит модель из режима «статистического угадывания» в режим анализа. Мы сначала фиксируем «рельсы» задачи, и только потом жмём на газ.

Кот в Коде|@kot_research_bot

главное, что работает ч.2 😂

Старые знакомые повержены в расплох

В прошлом году у меня была проблема в работе с SD-картой (то самое эхо прошлого).

После того, как я смог реализовать работу с метеостанцией и датчиком ветра, научрук мне говорит:
- Что ж, раз у тебя получилось сделать эти задачи и ты можешь записывать данные в Thonny… Пора вспомнить о задаче с SD-картой 🙂

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

Так что получается, проблему решил за одну пятницу, что поменялось?

Поменялось следующее:

1️⃣ Я поменял прошивку. Да, рабочая 1.26.0 прошивка служила мне верностью и стабильной работой на всех этапах работы, вплоть от инициализации модема и работы с сервером и до каши из подключенных станции и дачтиков… Но всё хорошее приходится отпускать и идти дальше. Так я нашёл 1.27.0 (в прошлом году она ещё была на этапе preview) и там не сказать, что что-то сильно поменялось, но в комментах оставлю разницу прошивок.

Press F 1.26.0...

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

Надо было просто посмотреть в прошивку на Arduino (которую используют другие прогеры… и я получил при работе со станцией ☹️)… и там были рабочие пины инициализации – по сути самое важное.

Ну решил ты эту проблему, плохо что ли?

Не плохо. Но и не хорошо.

Я думал, что раз мне дали задачу поиска рабочего способа реализации записи данных на SD-карту, то я сам должен разобраться во всех камнях… а по итогу мне просто дали прошивку и такие «на, разберись чё там, и используй эту инфу». Т.е. сразу дали решение, просто надо было по сути переписать с C-языка на Python всю работу с SD-картой. И тут пропала некоторая детская познавательная составляющая, что нужно всё самому найти, разобраться и постараться сделать так, чтобы ничего не взорвалось. Но по итогу, мне сразу сказали код от бомбы и дифьюзы.

А вы что думаете?
Надо было сразу узнать за всё на свете, чтобы было всё на блюдечке с голубой каёмочкой?
Или всё-таки самому искать инфу, но при этом вся ответственность за реализацию лежит на тебе (и при этом у тебя есть антураж самому всё попробовать и использовать)?

😎 - попробовать самому, зато за результат будешь больше рад
😱 - да ладно, всё ж работает, и не важно, откуда нашёл инфу

Кот в Коде|@kot_research_bot

главное, что работает ч.3 😂

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

В прошлых постах я упоминал методологию GRACE как некий святой грааль для работы с ИИ. Но когда я решил провести глубокий дебаг этого термина, оказалось, что в мире научных работ (косвенно схожей с постов эта работа, есть ещё здесь и здесь) под аббревиатурой GRACE прячутся заумные алгоритмы для автоматической правки кода или RAG-системы* на графах. Короче - софт для софта.

А то, что делаю я в Thonny это не скрипт. Это человеческая архитектурная интуиция, адаптированная под мозги трансформеров.

Мой «лже-GRACE» на самом деле - это старая добрая инженерная школа:

1️⃣Top-down мышление: Сначала смотрим на систему сверху, а не втыкаем в одну строчку кода.
2️⃣ Data Flow: Прорисовываем путь байта от железки до экрана.
3️⃣Architecture-in-code: Замысел и «рельсы» живут прямо в комментариях.

Почему всё работало? Потому что я разложил логику по стрелочкам:
Hardware (плата + трансивер) -> Firmware (MicroPython + регистры) -> Host (PuTTY на ноуте).

Я не использовал никакие внешние «приблуды» или RAG-поиск. Я просто создал для ИИ контекстную карту еще до того, как попросил его написать первую функцию. Это фактически Literate Programming (грамотное программирование): мы пишем код не для машины, а создаем «сценарий» для нейросетевого переводчика.

Углубившись в PDF-статьях с arXiv, я не пренебрёг основной сути. Лучший экзоскелет - это умение декомпозировать задачу «от железа к софту» и фиксировать это в иерархии.

* RAG - генерация с дополненным контекстом

Кот в Коде|@kot_research_bot

Теперь про датасеты

Датасеты типа HumanEval — это специальные бенчмарк, которые используются для оценки способности LLM (большие языковые модели) генерировать рабочий код по описанию задачи на естественном языке.

Самый известный и классический — это именно HumanEval (2021 год, от OpenAI). Почти все современные модели (GPT-4o, Claude 3.5/4, Gemini, Llama 3.1/4, Qwen2.5-Coder, DeepSeek-Coder и т.д.) сравнивают именно по нему и похожим датасетам.

Что такое HumanEval конкретно:

• 164 задачи (hand-written, т.е. написаны людьми специально, чтобы не было в обучающих данных)
• Каждая задача — это:
1️⃣сигнатура функции (def some_func(...))
2️⃣ docstring (описание на английском, что должна делать функция)
3️⃣ несколько unit-тестов (в среднем ~7–8 тестов на задачу)

• Модель должна дописать тело функции, чтобы оно прошло все тесты (functional correctness);
• Основная метрика — Pass@1 (процент задач, где первое сгенерированное решение проходит все тесты) и Pass@10 / Pass@100 (если модель генерирует несколько вариантов)

По состоянию на февраль 2026 топ-модели уже достигают 85–95% Pass@1 на HumanEval, поэтому его считают почти «насыщенным».

Приведу примеры похожих датасетов:

MBPP (Более простые задачи, crowd-sourced, 3 теста на задачу)
HumanEval-X (Мультиязычная версия HumanEval)
MultiPL-E (Автоматический перевод HumanEval и MBPP на другие языки)
BigCodeBench (Реальные библиотеки (pandas, numpy, requests и т.д.), сложные вызовы API)
LiveCodeBench (Свежие задачи из LeetCode / AtCoder / CodeForces (обновляется постоянно))
SWE-Bench ( Реальные issue → bug-fix в GitHub-репозиториях (очень близко к реальной работе))

Почему их называют «типа HumanEval»?

Все они проверяют code generation (генерацию кода по описанию)
Используют unit-тесты для автоматической проверки (не сравнение строк, а «работает ли код»)
Метрика Pass@k почти везде одинаковая.

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

Оказывается, хотя современные модели и щеголяют контекстными окнами в миллионы токенов, самый мощный обучающий сигнал их веса получали на крошечных примерах в 40 токенов. Это всего 3–5 строчек текста. Когда сигнал об ошибке при обучении находится внутри огромного блока в 4000 токенов, он «размывается». Но на 40 токенах связь между условием в docstring и итоговым байтом становится максимально эффективной.

Поэтому комментарий-контракт должен стоять СТРОГО ДО блока кода. Трансформеры — это каузальные модели, они читают и пишут строго слева направо. Если вы даёте описание после реализации — магия SFT не сработает, поезд уже ушёл. Но если контракт идёт первым, ИИ воспринимает его как «микро-ТЗ» и просто компилирует его в реализацию, используя свой самый отточенный навык.

Короче, HumanEval и его «родственники» - это основной способ в 2025–2026 годах понять, насколько хорошо модель пишет код «с нуля» по текстовому описанию. Для embedded/реального firmware они не очень подходят (там важнее архитектура, hardware, потоки данных), но для чистой алгоритмики и скриптов — золотой стандарт.

Кот в Коде|@kot_research_bot

«Маркетинг VS Реальность». Исследование 2

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

Почему?

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

Правда нужно пару моментов уточнить на берегу:

1️⃣Не все 19 версий моделей смог исследовать. На lmarena была glm-4.7 и glm-4.7-flash. Так вот, с обычной версией не получилось провести конечное исследование, потому что она только рассуждала в режиме thinking, но дальше рассуждений никуда не шла – ответов не было. А значит из списка пришлось убрать.

Похожая ситуация произошла с deepseek-v3.2-thinking – после 5 задачи нейронка перестала мне отвечать (несмотря на то, что пару раз менял чаты с ней). Возможно, проблемы были больше со стороны lmarena, так как на официальном сайте, возможно, всё бы работало, как часы. Но тут же исследование не про то, кто выкрутиться из ситуации лучше соперников, а про то, как в одной песочнице покажут себя претенденты на статус лучшей версии нейронки. Так что частично пришлось дисквалифицировать и этк версию.

А с gpt-5.3-codex вообще ситуация смешная: 5 февраля в один день в разрез пару часов вышли claude-opus-4.6 и codex (при чём Альтман решил релизнуть свою версию, как удар перчаткой Дарио – чтоб позлить оппонента и показать, что «у меня нейронка лучше» - мерилами решили помериться) … но смешное тут не то, что codex «лучше», а что проверкой на человеческий фактор opus смог выйти в lmarena, а codex – нет 😏

2️⃣ Частично я опоздал со своим исследованием. Да, как бы это не звучало странно, но сука не успеваю просто пощупать одну нейронку, как появляются в инфополе и на релизах ещё пару штук (Лернейская гидра, все дела).

Так вот, не получилось мне потестить вышеупомянутую gpt-5.3-codex (а на прошлой неделе релизнулась ещё и версия spark), также новоиспеченную minimax-m2.5 и в скором времени пребывающую deepseek-v4 (ориентировочно, 18 февраля).

Предупреждён – значит вооружен как говорится. А пока что введу вас в курс дела, освежим память того, что было в прошлый раз + дополнения для session 2.

Далеко не уходите, на этой неделе будет очень много инфы!

Кот в Коде|@kot_research_bot

Вышел Qwen 3.5. Всё, исследование не актуально 🫠

Запустился тест Grok 4.2 с поддержкой мультиэкспертов. Не жизнь, а сказка - похоже, что на следующей неделе нужно будет продолжать исследование исходя из выхода новых нейронок 😞