Здарова, работяги!

Раньше я, как и все, искал одну лучшую модель. Выходит новая — в чатиках вопрос «что сейчас топ». Одна шкала: от «тупее» к «умнее».

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

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

Две оси вместо рейтинга

Я развёл выбор на две вещи.

Первая — характер задачи: аккуратно сделать по плану, самому достроить решение или поработать с визуалом.

Вторая — масштаб и автономия: сколько шагов, сколько надо думать, насколько без присмотра.

Рейтинг «кто умнее» пытается свести эти оси в одно число. Мне всё чаще не хватало ответа «бери вот эту модель»: без роли и масштаба он мало говорит.

Характер задачи → семейство

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

— Claude-like модели (Claude Sonnet, Opus, Haiku, Kimi, GLM) — аккуратные исполнители. Хорошо держат план, чеклист и явный формат вывода.
— GPT-like модели (GPT-5 mini, GPT-5, GPT-5.5, DeepSeek) — про автономное рассуждение. Лучше держатся там, где план ещё надо достроить: выбрать подход и не развалиться без маршрута на каждый шаг.
— Gemini-like модели (Gemini Flash, Gemini Pro, Qwen) — сильны в визуале. Я беру их туда, где есть UI, скриншоты, макеты и визуальные баги.

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

Масштаб задачи → размер модели

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

— Утилиты: найти файл, суммаризировать, сделать простую правку. Тут важнее скорость, цена и стабильный минимум качества. Примеры: Haiku, GPT nano / mini-fast, Gemini Flash, MiniMax highspeed.
— Рабочая лошадка: обычная фича, ревью, средний рефактор. Примеры: Sonnet, GPT mini, GLM, Kimi.
— Глубокая автономная работа: архитектура, оркестрация, многошаговая задача, где план уточняется по дороге. Примеры: Opus, старший GPT-5, Gemini Pro.

В промпт-левел оркестрации это превращается в простое правило:

explore: утилита → gpt-5-mini-fast → minimax-highspeed
deep: глубокая работа → gpt-5.5 → opus → gemini-pro

Сначала роль, потом масштаб, потом конкретные модели. У поиска задача короткая, поэтому туда идут быстрые модели. У deep-агента работа длинная, поэтому цепочка начинается с флагманов.

Частые ошибки

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

Важные уточнения

Первое: флагманы почти универсальны. Не хочешь возиться с осями — поставь Opus или старший GPT-5 на всё, и оно поедет. Эта классификация про эффективность: деньги, скорость и стабильность на потоке.

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

Третье: модель редко работает сама по себе. На результат влияет харнес: Cursor, Claude Code, omo и тд; промпты, инструменты, контекст. В хорошем харнесе модель попроще часто обходит флагман в голом чате.

Резюме

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

Здарова, работяги!

Прошлые два поста были про сдвиг в голове: React всё меньше про «сравни деревья», всё больше про «какую работу и когда делать». Три поста на одной философии — перебор, так что ныряем под капот.

Начну с фундамента: с чем React вообще работает, когда рендерит. Звучит занудно, но пока тут чёрный ящик, советы про memo и colocation остаются заклинаниями: делай так, а почему — непонятно.

JSX — это объект-описание

<ChildVerySlow /> сам по себе ничего не рисует. Это сахар над вызовом функции, которая возвращает обычный объект:

<ChildVerySlow color="red" />
// превращается примерно в:
{ type: ChildVerySlow, props: { color: "red" }, key: null }

Чертёж: какой компонент и с какими пропсами показать. Эти объекты одноразовые — на каждом рендере создаются заново и выбрасываются. Хранить в них что-либо нельзя, да и негде.

Файбер — рабочая память React

А жить-то где-то надо. На каждый узел дерева — компонент, div, даже кусок текста — React заводит файбер: объект, который переживает рендеры.

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

Деревьев из файберов два: текущее, по которому построен экран, и рабочее (work-in-progress из старой лекции), которое React собирает под обновление. В коммите React переключает указатель: достроенное рабочее дерево становится текущим. Старые файберы не выбрасываются — из них, переписав поля, React соберёт следующее рабочее дерево.

Стейт — связный список хуков

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

// fiber.memoizedState, упрощённо:
hook1 = { memoizedState: 'Тёма', next: hook2 }
hook2 = { memoizedState: 29,     next: null  }

Имён у звеньев нет. На новом рендере React идёт по списку заново: первый вызов хука получает первое звено, второй — второе. Всё сопоставление держится на порядке вызовов. Поэтому хукам нельзя жить в условиях:

function Profile({ isEditing }) {
  const [name, setName] = useState('Тёма');
  if (isEditing) {
    const [draft, setDraft] = useState(name); // хук под условием
  }
  const [age, setAge] = useState(29);
}

Пока isEditing выключен, в списке те самые два звена. Включился — вызовов стало три. draft молча заберёт второе звено и получит 29 — чужой стейт age. А третий вызов упрётся в конец списка, и React упадёт с той самой «Rendered more hooks than during the previous render».

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

Зачем дерево распилено на файберы

До Fiber React рендерил рекурсией: зашёл в корень и спустился до самых листьев. Из середины рекурсии не выйти — стек вызовов на паузу не поставишь.

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

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

Резюме

— JSX-элемент — одноразовое описание { type, props, key }: создаётся на каждом рендере и выбрасывается;
— файбер — объект, который переживает рендеры: прошлые пропсы, ссылки по дереву, список хуков;
— хуки сопоставляются со звеньями списка только по порядку вызова, поэтому им нельзя жить в условиях;
— дерево обходится по одному файберу за шаг, между шагами React может прерваться — на этом стоит управляемая срочность.

Здарова, работяги!

Я уже рассказывал вам про скиллы: зачем они и как их писать.

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

Что там уже есть:

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

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

— challenge-talk — используется во флоу prep-talk, я использую и отдельно для челенджинга идей докладов. Он хорошо позволяет подготовиться к встрече с ПК конференции.

— fact-check — тоже входит в prep-talk. Проверяет утверждения, цифры и факты. Советую запускать на сильной модели.

— content-review — тоже из prep-talk. Проверяет ваш доклад на всякие водянистые фразы, пыль, пустые обещания и иишные фразочки. Лучше на сильной модели.

Велком! Буду рад вашим комментам по опыту использования.

стартуем

Здарова, работяги!

Сейчас я много думаю про AI-native команды и внедрение ИИ в разработку. Речь не про «выдали всем доступ к Claude — теперь мы AI-native», а про то, как меняется сам процесс разработки: какие практики приживаются и где всё это ломается. Тут особенно интересен опыт из первых уст: что другие команды уже попробовали, что у них сработало и от чего пришлось отказаться.

Поэтому мне и интересна Avito.Tech.Conf. Это конференция для лидов, а в программе кроме докладов будут воркшопы и мастермайнды. Можно будет пообщаться с коллегами и расспросить, как они перестраивают работу своих команд.

Мероприятие пройдёт 26 сентября в Москве, в AG Loft. Для тех, кто не сможет быть очно, будет онлайн-трансляция. Зарегистрироваться можно по ссылке

До конференции Avito.Tech вместе с Buenos Padel ВДНХ организовали бесплатные игры в падел. Поиграть можно с 20 августа до 13 сентября.

Я играю в большой теннис, а падел ещё ни разу не пробовал. Тут соблазнился и записался на 23 августа в 19:00. Посмотрим, насколько этот опыт пригодится. Если тоже хотели попробовать или хотите поиграть вместе — регистрируйтесь на конференцию и приходите на падел, на этот слот ещё есть места.

Здарова, работяги!

Совсем скоро осень, а значит, начинается сезон конференций.

Про Avito.Tech.Conf я уже рассказывал. В октябре поеду в Санкт-Петербург на HolyJS уже в роли спикера — про доклад и подготовку напишу отдельно. А 5 сентября пройдёт Deep Tech Night — о ней сегодня и расскажу.

Мне Deep Tech Night особенно интересна: AI-агенты сейчас напрямую связаны с моими проектами и ежедневными задачами.

По-моему, спор «AI — это рабочая технология или очередной хайп» уже немного протух. В исследовании DORA за 2025 год 90% опрошенных технических специалистов использовали AI в работе, больше 80% говорили о росте продуктивности. Но важнее главный вывод самого исследования: AI работает как усилитель. Он усиливает уже существующие сильные стороны и дисфункции организации. В хорошем процессе буст превращается в результат для команды, а в слабом его съедают узкие места и быстрее растёт техдолг.

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

AI всё-таки не новая библиотека. React может заметно изменить архитектуру фронтенда. А AI влияет на весь цикл разработки — от идеи до её релиза в прод.

Поэтому меняется весь SDLC. Кто готовит контекст для агента? Что ему можно делегировать? Где нужен человек? Как проверять результат и чем вообще измерять эффект?

И это не только мои вопросы. В Яндексе уже ставят конкретные цели по встраиванию AI в разработку. Например, запустили программу 75/75/75: к концу 2026 года не менее 75% разработчиков должны регулярно использовать AI, он должен участвовать не менее чем в 75% изменений и генерировать не менее 75% кода в каждом из них.

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

Больше всего я хочу послушать Андрея Попова с докладом «AI и продуктивность в Яндексе: что реально заработало». Ребята год измеряли влияние AI на работу разработчиков. Мне интересно, что именно измеряли, с чем сравнивали и какие практики в итоге дали результат.

Но мне важно не только разобраться с текущими процессами, но и понять, как AI будет менять разработку дальше. Поэтому хочу послушать Мо Гавдата, ex-Chief Business Officer Google X, с докладом «За пределами LLM: что дальше после первого поколения AI-систем» — как раз о том, что ждёт нас после первого поколения AI-систем.

Если тема вам близка — залетайте в онлайн: там будут трансляции докладов и Q&A со спикерами. Программа и регистрация — по ссылке.

Здарова, работяги!

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

Обновление идёт в две фазы

Render-фаза: React идёт по файберам, зовёт функции компонентов и сверяет свежие элементы с прошлыми. Весь код из тела компонента крутится здесь, чистый JS. Commit-фаза: разница применяется к DOM, тут же бегут useLayoutEffect. Разницы нет — DOM не трогается.

У браузера свой рендер — раскладка и пиксели, и он нужен, только если коммит реально тронул DOM.

Отсюда тезис: вызов функции копеечный, дорого то, что в её теле.

Пример

function Search({ products }) {
  const [query, setQuery] = useState('');

  return <>
    <input value={query} onChange={e => setQuery(e.target.value)} />
    <Results products={products} query={query} />
  </>;
}

function Results({ products, query }) {
  console.count('Results render');

  const rows = rankProducts(products, query); // тяжёлый расчёт
  return <Table rows={rows} />;
}

Вводим текст, счётчик растёт. Легко решить: Results ререндерится слишком часто, срочно в memo.

Но memo здесь даже не поможет: query меняется с каждым символом, а с ним и пропсы Results.

Счётчик отвечает не на тот вопрос

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

Один вызов функции не равен одному изменению экрана. Под <StrictMode> в dev счётчик удваивается сам по себе. С транзишенами (`startTransition`, `useDeferredValue`) React может прервать или выбросить начатый проход: лог остался, результата нет. В примере их нет — ввод срочный и рендерится синхронно.

Бывает и наоборот: Results вызвался один раз, но rankProducts занял столько, что ввод стал дёрганым. По счётчику эти случаи не различить.

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

Что я измеряю вместо этого

Открываю Performance в Chrome, запись, один символ в поле, стоп после обновления таблицы. Трейс ровно того сценария, который тормозит.

На dev-сборке React 19.2+ там сами появляются React Performance tracks, без расширения. Scheduler показывает, срочное обновление или фоновое, и сколько заняли Render, Commit и эффекты; Components — сколько заняли конкретные компоненты и их эффекты. Рядом — обычный JS, layout и paint браузера.

На React до 19.2 — вкладка Profiler в React DevTools: flamegraph по коммитам плюс настройка «Record why each component rendered».

На моём демо к посту один символ — это «+2» в консоли и около четверти секунды на каждый вызов Results на треке. Первое ни о чём, второе — уже диагноз.

Что делать дальше, трек тоже подсказывает:

— широкий Render в Results, а пропсы реально поменялись: memo не спасёт, лечу сам расчёт;
— React отработал быстро, а дальше тянутся layout и paint: ререндеры ни при чём, смотрю, что коммит сделал с DOM;
— Results дёргается часто, но копейками: оставляю в покое.

Где это ломается

Dev-сборка медленнее боевой: проверки, двойной рендер Strict Mode, инструментация. Трейс тут ищет подозрительное место, а не точные цифры — за ними в профилировочную сборку.

И трейс — про одно взаимодействие. Копеечный рендер на каждый скролл в нём выглядит невинно, а в сумме уже нет. Если поддерево от изменившегося стейта не зависит, его render лучше не запускать вовсе — это про структуру дерева и colocation, следующий пост.

Резюме

— render — чистый JS, DOM меняется в коммите, браузер рисует, только если коммит что-то тронул;
— количество вызовов не показывает задержку: вызов копеечный, дорого то, что внутри;
— сначала записать одно тормозящее взаимодействие и найти дорогой этап, потом оптимизировать;
— счётчик остаётся для вопроса «рендерится ли вообще» — с него начнётся пост про colocation.

Здарова, работяги!

Приезжает коробка. Внутри бейдж на Avito.Tech.Conf и часы «Ракета».😳

И тут я немного завис)) Такие посты я раньше видел у айтишных блогеров: курьер, коробка, распаковка. А себя блогером никогда не считал и не собираюсь. Канал у меня чисто для души и мыслей: пишу про то, что делаю на работе, во что упёрся, что по дороге понял. Ни контент-плана, ни «прогревов», ни курсов «войти в айти» (или что там сейчас в моде — «войти в ИИ»). И вот коробка приехала ко мне. Ладно, приятно.

Разбор часов от меня не ждите. Я в них не разбираюсь, на руке у меня годами только Garmin да Whoop: пульс, сон, восстановление — вот это мне важно, а не красивые циферблаты, истории и статус. Но подарок приятный и неожиданный: такого приглашения на конфу мне ещё не присылали (да будем честны, вообще никаких ещё не присылали🤣). Кому интересна история самих часов — коллеги по каналам уже расписали, я лучше про конференцию.

Про Avito.Tech.Conf я уже писал: 26 сентября, Москва, AG Loft, есть онлайн. Это конфа для лидов и менеджеров. В этом году кроме обычных докладов ребята добавили игровые форматы: рабочие кейсы разбирают за покерным столом, нетворкинг — за бильярдом. Звучит странно, но, кажется, именно так и разговорятся те, кто на обычном нетворкинге стоит у стены с кофе.

Регистрация по ссылке. Кто собирается — напишите, найдёмся на месте.

Зачем ты пишешь?

Здарова, работяги!

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

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

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

Но самое страшное тут ещё и то, что желание скипнуть чтение подкрепляется ещё и ленью. Я сразу вспоминаю всякие лицензионные соглашения и подобное — ты, значится, собрался поиграть в игру, которую долго ждал, а тебе тут пихают кучу страниц текста. Что за чёрт?! Окаем и погнали!

Можно сказать, что я использую плохие модели... Фейбл, Астра, Опус, ГПТ Сол... Ну хз тогда, какие хорошие. Можно сказать, что я не умею их использовать... Ну мб)

Хочу ли я сказать, что ИИ — ерунда? Точно нет. ИИшка отлично умеет писать и лаконичные, продуманные короткие решения.

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

Вот такие вечерние мысли... Всем доброй ночи!

Здарова, работяги!

Кто собирается на Avito.Tech.Conf 26 сентября?

Я уже рассказывал про конфу. Напомню, что мне самому особенно интересно в программе: AI в SDLC, настройка процессов и управление командой.

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

Рядом доклад «Как реально меняется PDLC или почему вы ускоряете не то, что нужно». Уже по названию хочется послушать. С моим интересом к канбан-методу и теории ограничений пройти мимо сложно.

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

Конфа пройдёт в Москве, будет и онлайн. Программа и регистрация — здесь.

Кто идёт — пишите в комментариях. Если собирались, но не с кем, можно найти компанию прямо тут.