Разобрал доклад Anthropic «Prompting 101» и собрал из него рабочую схему сборки промптов. С веб-сервисом и готовым Project для Claude.ai

Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас

Да и вообще всем, кто хочет разбираться в современных AI инструментах, будет полезно

Разбираемся

1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним

Сууупер длинная статья

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

Эта статья — про неожиданные находки. Не про «как я выбрал стек» (скучно) и не про «туториал по WebRTC» (и без меня есть). Это пять ситуаций, в которых я споткнулся, обнаружил что-то интересное, и подумал «об этом стоит рассказать — другим пригодится».

Поехали.

Самый просто способ запустить локальную LLM - это установить ollama или LM Studio. Это быстро и просто, но вы теряете и в скорости, и в качестве. Почему UD_Q4_K_XL лучше при том же размере, почему квант Q3 может быть медленнее чем Q4. Хорошая ли идея взять REAP для вырезания ненужных экспертов из MoE. Кто быстрее, Linux или Windows. В общем как выжать больше из локальных LLM на домашнем железе.

Всем привет! Музыку я люблю всю жизнь. Сам всегда хотел научиться играть на каком‑нибудь инструменте — пробовал гитару, клавиши, даже барабаны — освоил в итоге только варган. Зато с генерацией музыки нейросетями дело у меня пошло сразу. Написал в своё время один из первых на русском гайдов по Udio, недавно собрал платформу для лайвкодинга музыки с ИИ‑агентом. За опенсорсом в этой теме тоже слежу — щупаю каждый раз как что‑то новое появляется. Но после Suno слушать их обычно невозможно. Уровень «ну ок, оно звуки издаёт, и это тоже достижение».

В конце марта, когда на одном из моих стримов мы смотрели обзоры на свежую тогда ACE‑Step 1.5 — опенсорсную модель от команды StepFun. Посмотрели примеры, послушали что люди нагенерировали — и я решил что это хрень не достойная внимания. Вокал мычит, куплет примерно похож на куплет, по качеству — где‑то уровень Suno v3.5, то есть позапрошлогодний Suno. Даже скачивать не стал. Подумал: ну опенсорс и опенсорс, подождём когда научится.

И оно научилось! Уже через пару недель ACE‑Step выкатили версию XL.

Нужен был реестр артефактов. Показать студентам цепочку поставки софта: сборка, тесты, push в реестр, деплой. Стандартная задача, казалось бы. "Вошли и вышли, приключение на 20 минут."

Растянулось на несколько месяцев.

В итоге написал свой реестр. Один бинарник. 7 форматов. 12 МБ RAM. Без базы данных.

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

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

Всем привет! Меня зовут Иван Семенихин и я руковожу командой ИТ-подбора в SENSE. Сразу оговорюсь: это не материал про очередной «взлом системы найма». Скорее желание помочь опытным специалистам адаптироваться к новым условиям рынка и упростить путь к заветному офферу.

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

В Островке мы используем ИИ в разных задачах — от автоматизации внутренних процессов до продуктовых сценариев — и периодически рассказываем об этом на Хабре. Например, как строим вспомогательные системы на базе LLM и RAG или применяем ML в продукте.

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

Ниже мы перевели и адаптировали материал Алекса Эверлёфа — инженера, который систематизировал подходы к проектированию ИИ-систем за последние несколько лет.

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

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

Примечание. Часть текста была подготовлена с помощью Gemini 3 Pro, но финальную версию автор полностью вычитал, проверил и отредактировал, чтобы она точно отражала его опыт и выводы.

Всем привет! Меня зовут Наталья, я инженер машинного обучения в ЮMoney. Мы уже писали о том, как транскрибируем аудио с внутренних созвонов в текст. Прошёл год, и задача выросла: помимо созвонов мы решили транскрибировать все звонки службы поддержки, а также создать удобный интерфейс для работы с аудио и текстом. В этой статье расскажу, как нам удалось реализовать всё это, и при этом повысить качество распознавания и сохранить процесс внутри корпоративного контура. Мы протестировали различные решения и теперь делимся опытом, чтобы другие команды могли быстрее внедрять проверенные подходы и избегать распространённых ошибок.

Привет! Миша Васильев на связи, разработчик в команде AI Битрикс24. 

Недавно я написал статью про MCP — протокол для стандартизации работы LLM с внешними инструментами. Там мы разобрали, как это всё устроено, какие возможности даёт и почему это круто.

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

В этой статье я собрал семь основных проблем, с которыми мы столкнулись при разработке MCP-серверов, и объясню, как их избежать (или хотя бы постараться это сделать).

О чем эта статья

«Как дела? Не могу говорить, все горит!»

Реальность B2B SaaS (как и в большинстве направлений разработки) последние пару лет — это перманентный пожар. Заказчик просыпается с новыми вводными, рынок штормит, приоритеты меняются быстрее, чем успеваешь обновить Jira.

Десять лет в девопсе. Десять. И я гуглю tar -xzf. Не раз в год — раз в неделю. Ну, может раз в десять дней, если повезёт. Открываю хром, набираю «tar extract gz linux», пролистываю три рекламы, нахожу ответ на SO, копирую, вставляю, закрываю вкладку. Через неделю — по новой.

Я не идиот. Точнее, может и идиот, но не поэтому. Просто tar — это такой синтаксис, который у меня физически отказывается залезать в долговременную память. Там дефис или нет? xzf или xfz? Или zxf? Вроде порядок не важен? Или важен?..

Короче. Месяц назад я написал скрипт, который это решил. А потом скрипт решил больше, чем я хотел.

Каждый, кто хоть раз разбирался в три часа ночи с упавшим продом, знает: большинство катастроф в базах данных это не сбой железа и не космические лучи. Это решения, принятые на этапе проектирования схемы. «Потом поправим», «в приложении проверим», «а зачем тут индекс?» каждая из этих фраз обходилась командам в часы даунтайма и миллионы потерянных строк.

Ниже 25 правил, которые я собрал из опыта работы с высоконагруженными системами. Это не теория из учебника — это грабли, на которые уже наступили до вас. Каждое правило сопровождается примером «как надо» и «как не надо», чтобы разница была наглядной.

В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).

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

Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:

Markdown — популярный и удобный язык разметки, но это также и очень ограниченный формат. Поэтому задача написания в Markdown сложной технической документации по ГОСТ, научной статьи с автоматической настройкой оформления для заданного издательства или хорошо оформленного онлайн-учебника может показаться неосуществимой. В этой статье рассмотрим способ работы над научно-техническими статьями и книгами в формате Markdown на основе подхода Docs as Code с учётом строгих ограничений на оформление, используемый Петром Советовым и мной при подготовке учебных материалов в РТУ МИРЭА.

Способ заключается в применении утилиты pandoc для построения дерева абстрактного синтаксиса (AST) Markdown-документа с последующим переписыванием AST набором фильтров на Lua и трансляцией AST в форматы docx и pdf, соответствующие ГОСТ, а также в диалект markdown, совместимый с mdBook, для генерации онлайн-учебника.

Онлайн-версии книг, написанных с использованием описанного подхода, и репозитории с исходным кодом книг опубликованы на GitHub и GitHub Pages: книга по конфигурационному управлению, книга по разработке кроссплатформенных программмных систем.

Привет, Хабр!

Знаете, что общего между документацией Rust и советами бабушки? И то, и другое звучит разумно, пока не начнёшь применять буквально ко всему. «Используй дженерики для переиспользования кода», «оборачивай общие данные в Arc<Mutex>», «создавай типизированные ошибки» — всё это написано в книгах, статьях и туториалах. И всё это может превратить ваш проект в нечто, от чего хочется плакать.

Данные реальных логов за 7 месяцев на 527 человек — что люди делают с LLM на работе и что с ними не так

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

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

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

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

Якоб Нильсен проводил исследование, что только 20% населения могут нормально сформулировать промпт. Пробуют пару раз и уходят.

Короче, за 7 месяцев с июня по декабрь 2025:

416 пользователей из 527 хоть раз потыкались

122346 запросов (в среднем 42 запроса на пользователя в месяц)

6851 доллар расходов (535 тысяч рублей, 184 руб/месяц на активного юзера)

Если бы они брали 20-долларовые подписки GPT, то получили бы то же самое в 8,5 раз дороже.

При этом мы внедряли агрегатор нейросетей, и там были картинки. 64% бюджета — генерация картинок.

Если только LLM, включая SOTA-модели вроде Gemini 3 Pro Preview, последние GPT, Gemini, последние Антропики — то было бы всего 62 рубля в месяц на пользователя.

Те, кто понял, зачем ему модель, возвращался постоянно.

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

Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.

Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».

Еще одна статья про whisper + pyannote для транскрибации совещаний?

Да, но нет.

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

Как говорят у меня на родине: корпоративная жадность — двигатель миграций. И именно это мы сейчас можем наблюдать на примере MinIO — некогда любимого инструмента DevOps-инженеров для развёртывания S3-совместимого хранилища. В 2021 году они втихушку сменили лицензию на AGPL v3, а в 2025 году и вовсе выпилили веб-интерфейс из бесплатной версии. Ну и, наверное, можно подумать, что за такой удобный инструмент можно и заплатить. Но тогда встаёт вопрос: какова цена коммерческой лицензии? От $96 000 в год)

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