Мгновенные ответы в Claude Code (или как подключать сторонние модели)

В чем главная проблема разработки с ИИ? Даже не в том, что люди пишут ЛЛМкой тесты, или ждут что она сама достанет все требования из их головы.

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

Но это – режим менеджера (асинхронный), неестественный для большинства разработчиков, норма которых – работа в "блокирующем" режиме.

Альтернативное направление – просто сильно ускорить инференс, чтобы не успевать выпадать:

Дал инструкцию → Сразу видишь результат → Увидел косяки → Дал новую инструкцию

Вспоминаю про Cerebras API, который умеет выдавать по 1-2k токенов в секунду (ссылка на мои эксперименты в конце поста). Осталось только понять, как подключить их в Claude Code, который работает только с anthropic совместимыми моделями.

Нахожу claude code router - враппер вокруг Claude Code, который перехватывает реквесты к Anthropic API, заменяет их на реквесты к желаемым провайдеру и модели, возвращает в Claude Code результат в anthropic-compatible формате.

И он даже разрешает прописывать провайдера для openrouter – можно выбрать cerebras. Только там баг, и эта фича не работает. Придумываю "хак" – создаю пресет в openrouter, чтобы обращаться через "model": "qwen/qwen3-coder@preset/cerebras"

Вот получившийся config.json

{
  "LOG": true,
  "API_TIMEOUT_MS": 600000,
  "NON_INTERACTIVE_MODE": false,
  "Providers": [
    {
      "name": "openrouter",
      "api_base_url": "https://openrouter.ai/api/v1/chat/completions",
      "api_key": "...",
      "models": [ "qwen/qwen3-coder@preset/cerebras" ],
      "transformer": { "use": [ "openrouter" ] }
    }
  ],
  "Router": {
    "default": "openrouter,qwen/qwen3-coder@preset/cerebras",
    "background": "openrouter,qwen/qwen3-coder@preset/cerebras",
    "think": "openrouter,qwen/qwen3-coder@preset/cerebras",
    "longContext": "openrouter,qwen/qwen3-coder@preset/cerebras",
    "longContextThreshold": 60000,
    "webSearch": "openrouter,qwen/qwen3-coder@preset/cerebras"
  }
}

TL;DR:

1. npm install -g @musistudio/claude-code-router
2. создаем пресет в openrouter
3. копируем конфиг в ~/.claude-code-router/config.json

P.s. Claude Code делает много промежуточных запросов. И если все будут лететь через cerebras – будут пробиваться rate limits => для надежности делаем фоллбэк на другого провадера в пресете openrouter

Мои эксперименты с Cerebras (1, 2)

UPD: кому мало qwen3-coder, попробуйте grok-4-fast от xAI

Кстати, Антропики тоже считают, что ембеддинги сосут

Перевод:

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

Собеседования в эпоху ИИ

Я одно время плотно занимался техническими-собесами-as-a-service для американского бигтеха – Google, Uber, Dropbox и другие ребята со звездочками.

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

Попробую неблагодарное дело – предсказания. Как обычно, индустрия пойдет двумя путями:

1. Запрещать и наказывать
2. Не можешь запретить, возглавь

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

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

Так что, это абсолютно ок – запретить пользоваться ИИ на собесе и проверять инженерные знания изолировано.

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

Разработчик + ИИ – это как техлид и миддлы в его команде – он все может сделать и сам, но с ними быстрее.

Вайбкодеры, наоборот, скорее нетехнические CEO в стартапа, которые дают задачки разработчику на аутсорсе (чем такое обычно заканчивается?)

———

Но разрыв между технарями, которые осваивают сложные ИИ воркфлоу, и теми, кто остановился на базовых – продолжает расти.

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

А какие давать задачи?

Идейно все просто – а) не должны решаться в один промпт, но при этом б) должны решаться быстро с грамотными подходами и долей инженерных знаний.

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

Но одна идея вроде работает. Вот наблюдения:

Самые большие сложности у ИИ – вынужденный рефакторинг.

Что скажет сеньор на задачу, не влезающую в текущую архитектуру? "Нужно пару месяцев на переделки"

Что говорит LLM? "так точно, сейчас будет готово". И обмазывает все костылями прям как тот джун, которые боится сказать "нет"

Вот тут кандидаты и делятся на три сегмента

1. Консерваторы, полагаются на свой опыт и используют ИИ по минимуму – скорее всего не успевают закончить задачу

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

3. Те, кто уже набрался опыта – достаточно быстро придут к идее рефакторинга и так же быстро его сделают

tl;dr

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

———

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

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

Только как их приобрести?

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

Одно дело навайбкодить лендос за вечер, совсем другое – рефакторить свой легаси комбайн с кучей зависимостей.

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

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

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

Все быстро вышло из под контроля и разрослось до 10 топовых спикеров и уже 700 участников (за пару дней с анонса).

Очень доволен и контентом, и спикерами – а там CTO, тихлиды, разработчики своих AI coding tools, Head of AI из корпората.

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

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

Так что приходите сами и зовите коллег:
ai-dev.live

Немного пошалил на хабре

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

Если считаете, что шалость удалась – лайкните статью, давайте подержим ее в горячем подольше

Реальный кейс по ИИ в собесах

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

Сейчас многие стоят перед вопросом "а как вообще менять собесы", так что делюсь кейсом с одной из них (с разрешения)

———

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

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

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

⦁ А как вообще в компании уже используется ИИ?
⦁ Как ты использовала на последней неделе?
⦁ Где использовала команда?
⦁ Про что говорили как про вау-момент?
⦁ Какие самые геморные задачи перестали быть такими?

Образовывается два кластера задач

1. Формирование и исследование архитектурных концепций – по сути масштабный диприсерч и куча итераций сверху – для собесов не подходит

2. Генерация драфтов API контрактов – то, что нужно

Дальше самый важный вопрос:

Какие паттерны отличают успешных сотрудников от остальных?

Именно задания на эти паттерны и нужны на собесе. А сами паттерны → чеклисты для интервьюера

Вот несколько примеров грин-флагов, которые выцепили:

⦁ Постановка задачи ИИ – сначала уточняет цель, ограничения, критерии качества; декомпозирует на подзадачи; задает контекст (домен, ограничения по API/данным)

⦁ Итеративность – работает циклами (черновик → проверка → правки → повтор); запрашивает альтернативы и сравнение; ведет лог допущений; просит обосновать решения и указать источники/риски

⦁ Работа с форматами и артефактами – требует строгие форматы (OpenAPI/JSON/YAML), валидирует схему; просит диаграммы/сиквенсы/модель данных, связывает их между собой

⦁ Управление ограничениями и рисками – явно задает ограничения (совместимость, версии, SLA, лимиты, idempotency, пагинация, фильтры, сортировки); тестирует негативные сценарии

⦁ Качество – редактирует запрос, пока не получит качественный результат, перед тем как перейти к следующему шагу (вместо кучи микро-исправлений)

———

Предлагаю Свете сделать только один этап: 40 минут систем дизайна + 20 минут генерация драфта одного контракта из системы, которую задизайнили. Кандидат уже в контексте – удобно

На этом в целом можно закончить – Света довольна

Но есть ощущение, что можно еще докрутить, так что предлагаю подумать над двумя интересными фактами:

1. LLMки очень стараются сделать то, о чем их просят (иногда в очень извращенном виде)
2. LLMки сильно цепляются за то, что уже сделано (код, текст поста, архитектура)

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

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

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

"Хороший специалист – знает, как не косячить. Отличный – знает, как исправить, когда кто-то уже накосячил" ауф

———

tl;dr

⦁ Смотрите на то, где команда уже применяет ИИ в работе
⦁ Ищите, чем отличаются паттерны успешных коллег – стройте задания на этом
⦁ Не давайте делать с нуля, а дайте средненькое решение и попросите что-то добавить (не прося "исправить")
⦁ Часть гринфлагов выше – универсальны, можете забирать себе

Оффлайн vs онлайн

Все еще получаем классные отзывы от участников конференции. Кстати, наконец выложили записанные видосы, доступ все так же через ai-dev.live

Но чего у нас не было, так это живого общения

Валера @neuraldeep вместе с @red_mad_robot проводит в Питере оффлайн конфу на следующих выходных.

Тема та же – ИИ в разработке. Но как участник, тут я бы сделал упор именно на личные знакомства и общение 1-1 – большинство самых интересных инсайтов берутся именно из таких контактов. Если не ссать знакомиться, задавать правильные вопросы и делиться своим опытом

25 октября 9:30-15:00
Подробности тут

P.s. Я, кстати, тоже должен был выступать на этой конфе, но не успел доехать до Питера

В последнее время мало пишу – активно нарабатываю контент для новых постов (на самом деле просто в мыле закрываю хвосты по проектам – появились из-за сильного фокуса на подготовку нашей недавней конфы)

Скоро будет и про оффлайн RAG на мобилках, и про то, почему никто в Q&A системах не хайлайтит референсы в пдфках и как это все-таки нужно делать, и поделюсь настройками моих кодинг тулов. Будет даже мой первый видос на ютубе – отрывок с одного закрытого воркшопа, который я недавно проводил

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

Хотя я и в водовороте ИИ хайпа, но у меня почти нет ИИ продуктов, которыми я пользуюсь каждый день

Прям на постоянке только Cursor/Claude Code, Wispr Flow, chatgpt/ai.studio, пару самописных ботов и Granola

Почему так? Если честно, кажется, что большинство продуктов просто не дают достаточно интерфейсной ценности в сравнении с обычным ChatGPT.

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

Выложил эту часть в бесплатный доступ на ютуб – смотреть можно тут

Хейт ИИ для разработки – публичное признание собственной некомпетентности

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

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

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

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

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

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

Я это все к чему:

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

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

- А если занимаетесь внедрением ИИ в своей компании – начинайте с самых сеньорных ребят (но тех, кто еще сам руки не боится замарать, а не только на созвонах сидит). Они и применить смогут на максимум, и команде потом лучшие практики передать

Почему большинство делают LLM классификацию не правильно

Зачем вообще нужна LLM классификация? Для примера – хрестоматийная задача из суровой реальности:

- На вход – история переписки пользователя с ботом
- На выход True, если пользователь делает в чате что-то нехорошее (например, пытается вытащить системный промпт или разговорить модель про ее полические взгляды). False, если все хорошо

Вот 4 типичных подхода и один нетипичный

Уровень 0 – просто промпт:

Блаблабла, напиши True, если пользователь делает что-то плохое. Вот критерии плохого: ... Напиши False, если все ок

Проблемы: Модель может ответить "false", "FALSE", "false, потому что блаблабла" или вообще выдать системный промпт, если инъекция хорошая


Уровень 1 – structured output:

class Response(BaseModel):
  verdict: bool = Field(..., description="Блаблабла, напиши True, если пользователь делает что-то плохое. Вот критерии плохого: ...  Напиши False, если все ок")

Уже лучше. Но что если хочется еще и знать что конкретно идет не так?


Уровень 2 – Literal (multiclass классификация):

Вместо бинарного поля – несколько возможных вариантов

class Response(BaseModel):
  verdict: Literal["normal", "politics_bait", "system_prompt_robbery", ...]

А что если у нас одновременно и politics_bait и system_prompt_robbery???


Уровень 3 – Несколько полей (mutlilabel классификация)

Разделяем варианты по разным бинарным критериям (aka чеклист)

class Response(BaseModel):
  is_politic_bait: bool
  is_system_prompt_robbery: bool

🧐 Вместо бинарных полей можно тоже сделать Literal с несколькими значениями – будет multiclass multilabel. Пример – извлечение данных из вакансий – одно поле может быть Junior/Middle/Senior, второе удаленка/офис/гибрид, третье – основной рабочий язык

Коля, ну а тут то что не так?
Дело в том, что триггер True для is_system_prompt_robbery сработает только, если вероятность будет больше чем False . Давайте представим себе такие вероятности:

P(True) = 0.49
P(False) = 0.51

Система скажет False ("все ок"). А на самом деле? А на самом деле уверенность, что все ненормально - 49% 🙈

И большинство решений на рынке остаются именно на этом уровне!

Да, могут добавить thinking или даже Structured Guided Reasoning (например перед вердиктом попросив цитату пользователя, где мб есть проблема), но глобально это ситуацию не меняет.

Пора учиться управлять вероятностями (с) Коля

Уровень 4 – logprobs + пороги:

Мало кто знает, что LLM провайдер может отдавать сырые "вероятности" токенов. Не забываем softmax или попросить модельку, если не шарите.

По сути – это "уверенность" модели в каждом конкретном токене

Включается вот этими параметрами

client.chat.completions.create(
  ..., 
  logprobs=True, 
  top_logprobs=5
)

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

Кстати, кто знает, как правильно доставать logprobs только важных для нас токенов (true/false) из всего json'а?

{
"is_politic_bait": true,
"is_system_prompt_robbery": false
}


———

Короче, полноценная классификация появляется тогда, когда появляется вероятность.

Ну и идеи дальнейших улучшений одной строкой:

- Разные пороги под разные характеристики
- Подбор порогов автоматически, если есть датасет
- Если multiclass (пример с вакансиями), то еще важно насколько у топовых классов близкая "уверенность" – если у обоих большая, но примерно одинаковая, то контринтуитивно, но значит, моделька на самом деле сомневается в своем топ-1

Текст не нужен

Последние пару месяцев живу с маргинальной мыслью, что текст как входные данные для AI систем – костыль

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

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

Точно ли хорошая идея делать для LLM отдельный "орган восприятия" для текста? Да еще на основе всех костылей придуманных в Computer Science для строк.

Хз

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

Часть этого компенсируется маркдаун разметкой, но все равно с потерями.

———

Кстати, про маргинальность.

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

Меня там зацепило:

- Сжатие до 10x (!) по числу токенов при точности 97%

- Это очевидно, но я даже не задумывался – Visual модели нативно поддерживают двунаправленный механизм внимания

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

- А "забывание" реализовать через постепенное понижение разрешения для старых/неиспользуемых кусков

———

И еще, доп. бонус от картиночного восприятия: нативные bbox для RAG пайплайнов. Очень круто показывать пользователю не только страницу, где нашли инфу, но и выделять конкретную область на ней (скрин ниже).

———

DeepSeek OCR
Твит Карпатого
Gemini Object Detection

———

Кстати, по поводу image-only восприятия ↑

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

У Jina есть неплохая эмбеддинговая моделька, которая умеет кушать картинки и pdf

P.s. правда на моих задачах справляется хуже чем текстовые эмбеддинги от gemini (потому что они топ). Но лучше, чем та же самая моделька чисто по тексту! Скорее всего на кейсах, где больше картинок, она будет обгонять текстовые gemini-embeddings

Ну и особенно полезно для чисто картиночного поиска.

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

Ссылка

Как Эд Ширан связан с ЛЛМ промптами?

Читаю я перед сном статью Джулиана Шапиро – как генерировать идеи для текстов.

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

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

Посмотреть на плохое и понять что исправить – легче, чем сделать хорошее с нуля.

И всем же знакома вот эта ситуация, когда просишь ЛЛМку нагенерить идей, а там прям ну очень плохо?

Это на самом деле очень хорошо! Потому что это крутой материал, чтобы точнее объяснить то, что не получилось сформулировать с нуля

Так еще и сразу с примерами. Такой отрицательный few-shot learning, получается

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

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

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

———

Кстати, этот подход к креативности Джулиан почерпнул у Нила Геймана и Эда Ширана

Ребят, кто в Мск, тут мои приятели проводят оффлайн митап, кому-то точно будет интересно

Почему я бы пошел, если бы был в Москве

1. Там будет Валера (@neuraldeep), а Валера классный. У него есть какой-то талант собирать вокруг энтузиастов (можно понять по комментам у него в канале) и делать всратые эксперименты, которые выстреливают.

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

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

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

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

Ссылка на мероприятие

#дружеский_пиар

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

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

Но реально, давайте представим, что все пойдет по техно-оптимистичному раскладу и через пару лет условного бухгалтера Елену Андреевну заменит хороший набор запросов к LLM API

Что будут делать бухгалтерские фирмы с кратно возросшей маржой?

Спойлер: демпинговать

Уже сейчас видна коммодизация технологий – начиная от открытых моделек, заканчивая всякими n8n, на которых некоторые особо инициативные Елены Андреевны уже костылят себе рабочие инструменты.

Разработчики тоже в массе освоят разработку с ЛЛМ под капотом, как сейчас все умеют в разработку с базой данных под капотом.

Так что, как и на любом рынке, где не работает winner-takes-all, маржа будет стремится к нулю

А выводы?

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

2. Есть некоторые отрасли, где уже монополия. Там чуть проще – у них нет серьёзных конкурентов, кто демпингом съест маржу. Но их главный конкурент – Елены Андреевны, которые вместо покупки их решения, накостыляют себе сами под свою узкую задачу.

3. Некоторые компании из пункта 1 смогут так быстро вырасти, что съедят всех конкурентов и превратят свой рынок в winner-takes-all. Или превратятся из сервисных компаний в продуктовые и просто будут продавать свое решение вчерашним конкурентам

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

Мб есть еще варианты, которых не вижу?

by AI и грабли

Блин, я уж думал, что пропустил прорыв

Короче, оказывается, еще 3 месяца назад OpenAI очень круто прокачали structured output.

Я знаю про сильно увеличенный размер схемы, доп ограничения вроде max/min, но оказывается, они разрешили целые грамматики с нуля прописывать. То есть сгенерировать не просто json, соответствующей pydantic/zod схеме с разными валидаторами, а вообще текст на любом языке, который описывается Context Free грамматикой.

Теоретически, это может быть SQL или python, а может быть даже конкретный диалект SQL или вообще проприетарный DSL (domain specific language), например, игрового движка

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

Но если нужен какой-то сложный формат, который не описать json схемой, то это прям киллер фича. Если есть идеи, кидайте в комменты

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

P.s sql и python не описываются целиком Context Free грамматикой. То есть не получится сделать такую грамматику, которая прям однозначно гарантировала соответствие всем фичам языка, но все равно можно заложить очень много

Дока

Главная преграда для внедрения ИИ – сами руководители

Это основной тейк из статьи, которую разбирали с LLMками на моем воркшопе для руководителей 😅

Еще понравилось: сотрудники в 3 раза чаще используют ИИ, чем предполагает руководство

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

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

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

Ну и дальше уже классический для моего канала call-to-action – приходите на бесплатную конфу, чтобы послушать тех, кто уже потратил время за вас и во всем разобрался. Даже если вы не руковод – должно быть полезно. Проводит Стратоплан – я про них не знаю, но ребята, с которыми делали ai-dev.live, подтвердили – они норм. А некоторые даже сами будут там спикерами (!)

Я, кстати, буду ее открывать – у меня самый первый доклад из всех 4 дней, ух

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

Когда: с 8 по 12 декабря, с 16:00 до 17:00 GMT+3

Бесплатно и без всяких скрытых оплат:

→ Ссылка ←

Реальные кейсы про ИИ в разработке

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

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

Мы с @the_ai_architect и @max_about_ai решили устроить глобальное переопыление – собираем с сообщества реальные кейсы, а потом обезличенно делимся со всеми, кто оставил осмысленную инфу

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

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

А если пошерите этот пост в канале на 100+ человек, добавим ссылку на ваш канал в страницу с итогами 🤗

Ссылка на участие