Kobezzza. База в программировании

> часто ttfб упирается не в бандл и не в ssr, а в один медленный запрос к бд на первом рендере. пока его не найдёшь, любые оптимизации фронта мимо кассы

Очень справедливое замечание. Действительно, частая проблема любого BFF — это не столько его собственные проблемы, сколько то, как организована работа с данными.

Но тут тоже есть нюансы.

Во-первых, мы живём в эпоху микросервисов. А значит, среднестатистический BFF может делать не один и не два запроса за данными, а десятки. Очень важно, чтобы запросы не только стартовали настолько рано, насколько это возможно, и не только чтобы были организованы рациональные слои кэширования. Важно ещё и то, насколько они конкурентны. Если запросы обрабатываются быстро, но выстраиваются в один критический путь, — это всё равно может тормозить.

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

Но как понять, что и как загружается и тормозит?

А тут нужно смотреть трассы (trace). Сначала завернуть все запросы в специальный фреймворк, а потом смотреть мониторинги и уже на этих данных строить выводы: что тормозит, а что нет. Иначе можно попасть в интересную ситуацию: оптимизировал запрос к БД, а он не самый долгий и выполняется конкурентно с другими — значит, эффект от такой оптимизации заметить куда сложнее.

Сейчас стандартом для такой трассировки стал OpenTelemetry — открытый стандарт и набор инструментов для сбора трейсов, метрик и логов.

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

Как это работает на практике. Вы инструментируете свой BFF через OpenTelemetry. Каждый входящий запрос получает trace ID. Все downstream-вызовы — к БД, к другим сервисам, к внешним API — становятся спанами внутри этого трейса. Каждый спан показывает: когда начался, сколько длился, что делал, с каким результатом завершился.

Потом вы открываете Jaeger и видите диаграмму, где наглядно показано, какие вызовы шли параллельно, какие последовательно, и какой из них съел больше всего времени. Именно там становится видно: «Ага, вот этот запрос к БД на 800 мс — он и есть узкое место». Или наоборот: «Этот запрос долгий, но он выполняется параллельно с другими, так что не он определяет TTFB».

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

📚Если хотите копнуть глубже в Web performance, то уже завтра стартует наш новый трехдневный интенсив.

ПРОКАЧАТЬ WEB PERFORMANCE

💿Запись - 1 год.
🎓Ваш преподаватель - Дима Холстинин (автор наших курсов по Сборке и Инфраструктуре, ведущий разработчик в core команде Т-банк)

Почему ваш сервер может быть быстрее, чем кажется. Часть 2

HDA (Hypermedia-Driven Applications) — другой подход. Сервер остаётся единственным источником состояния и логики. Клиент не оживляет страницу целиком — он получает от сервера готовые фрагменты HTML и вставляет их в нужные места. Интерактивность — через обмен гипермедиа: клик; запрос; сервер вернул HTML; он заменил часть страницы.

Разница принципиальная. При обычном SSR браузер получает HTML, а потом повторно выполняет ту же работу, чтобы восстановить состояние. При HDA сервер отдаёт HTML, и он сразу финальный. Никакой гидратации, никакого повторного выполнения.

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

Память и сборщик мусора

JS хранит объекты в куче, причём делает это, используя разные поколенческие модели. Сборщик мусора периодически её очищает — и на время очистки останавливает выполнение. И если очистка молодого поколения может происходить очень быстро, то очистка старого уже может вызывать значительные проблемы. Хорошая стратегия — не уничтожать, а переиспользовать объекты. Но в контексте асинхронного конкурентного программирования тут нужно быть очень аккуратным.

Потребление памяти и OOM-ошибки: неконтролируемые кэши, утечки через подписки и таймеры, замыкания, которые держат ссылки дольше, чем нужно.

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

Почему это важно

Производительность сервера — это то, сколько пользователь ждёт, прежде чем увидит хоть что-то. Если сервер тормозит, никакая клиентская оптимизация не спасёт (обратное тоже справедливо).

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

Оптимизация без измерения — это гадание

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

Разобраться с web performance на интенсиве 2-4 октября

Почему ваш сервер может быть быстрее, чем кажется

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

Вот простой пример. Страница грузится три секунды. Мы смотрим в Network, видим большой бандл, кидаемся его оптимизировать. А задержка возникла раньше — пока сервер собирал HTML и ждал ответы от API. Мы оптимизируем не то место, потому что не понимаем, где именно теряется время.

И вот тут начинается самое интересное.

Откуда берётся HTML

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

SSG — собирается заранее, сервер отдаёт готовый файл. Быстро, но контент фиксирован.

SSR — генерируется на каждый запрос. Актуально и персонализировано, но каждый запрос — это работа: сбор данных, рендер, сериализация.

ISR — гибрид: статика, которая периодически пересобирается в фоне.

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

Что происходит внутри Node.js

В основе Node.js — Event Loop. Пока он свободен, запросы обрабатываются быстро. Стоит появиться CPU-bound вычислению — и всё встаёт в очередь.

Вот вам пример: JSON.parse(огромнаяСтрока). Синхронная операция. Пока она выполняется, Event Loop занят. Если таких запросов много, они выстраиваются в очередь. Пользователи ждут.

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

Что с этим делать? Выносить тяжёлое в worker_threads или отдельные процессы. Но тут есть нюансы.

Worker threads могут показаться хорошей идеей, но у них своя специфика. По моему опыту, потоки в Node.js куда лучше подходят для задач разделения решения одной задачи, а не для обслуживания множества параллельных независимых задач.

С другой стороны, есть процессы — они полностью изолированы, у каждого своя память и своя сборка мусора. Это снимает часть проблем с GC, но добавляет другие: межпроцессное взаимодействие дороже (сериализация через IPC), нужно управлять жизненным циклом процессов.

И главное — все нужно измерять. Event Loop Lag, latency, p95 и p99 — именно хвосты распределения показывают, где болит.

Как сервер получает данные

До того как сервер отдаст HTML, он должен собрать данные. И это часто самый долгий этап.

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

Второй враг — N+1. Сто записей — сто один запрос. Решение: объединять запросы в батчи или продумывать архитектуру БД, чтобы такой проблемы не было.

Третий — медленные downstream-сервисы. Если ваш API зависит от сервиса, который отвечает три секунды, вы не можете быть быстрее.

Как находить? Через трассировку. Смотрите тайминги каждого вызова, ищите, где время теряется.

Серверный рендеринг

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

И тут на сцену выходит Streaming SSR. Зачем ждать, пока весь HTML будет готов, если можно отдавать его по частям? Браузер получает разметку, пока сервер досчитывает остальное. Пользователь видит первую часть страницы раньше.

Это не ускоряет сам рендер, но ускоряет восприятие.

Гидратация и её альтернатива: HDA

Обычный SSR с гидратацией работает так: сервер отдаёт HTML, браузер его показывает, а потом загружается JavaScript и гидрирует страницу — «оживляет» её, навешивая обработчики и восстанавливая состояние. Пока гидратация не завершилась, страница выглядит готовой, но по факту является муляжем. Пользователь видит кнопку, жмёт — ничего не происходит.

Я не читаю больше код

Это тренд, который последний год распространяется со страшной силой. Мотивация такая: эффективность с ИИ выше, если отпустить процесс и перейти на тщательное покрытие тестами и спецификацией. Лично я отношусь к такому тренду очень скептически, но, как говорится, поживём — увидим. Пока могу сказать то, что вижу массово на практике.

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

Я сам сейчас на работе сталкиваюсь с таким постоянно. Буквально на днях агент, решавший автономно одну из моих задачек, представил удивительное решение — правку на 90 файлов и кучу тестов. Я удивился, почему задача потребовала столько правок, взглянул в код и обнаружил суперстранный момент: героическое решение проблемы, которой просто не было. Я сказал, что не вижу смысла в этих действиях, и попросил объяснить. Он ответил: «Да, я перегнул». И откатил до трёх файлов и короткого фикса.

Предвосхищаю вопросы: «А какая модель?» (GPT-6 Astra) — «Просто нужно было использовать XXX». Нет, дорогие мои, просто нужно оставаться профессионалом, читать код и задавать вопросы.

И вот в вопросах производительности такая беспечность может быть критической. Нельзя просто сказать «исследуй проблемы и сделай хорошо». Всё ещё крайне важно понимать, что исследовать и как исследовать. Если у вас тормозит гидратация из-за перегруженного стартового бандла, то вы хоть обоптимизируйтесь свой BFF — лучше не станет. А может, вашему сервису вообще не нужна связка SSR и гидратации.

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

А для этого нужны знания: чем больше в голове контекста, тем лучше вы будете работать с инструментами. Но, к сожалению, эта мысль сейчас очень непопулярна. Всех, кто считает, что роль «кожаных» становится не меньше, а НАОБОРОТ БОЛЬШЕ, записывают в отрицатели и динозавры. Главное — повесить ярлык, а там трава не расти.

Здесь вообще не стоит вопрос про ИИ — это удивительный инструмент и отрицать его глупо. Здесь стоит вопрос про то, что нельзя все свои навыки сложить к одной прикладной стороне вопроса использования LLM. Если разница между джуном и мидлом стирается, то разница между джуном и сеньером становится бесконечной. Так что поверьте, стоит не только ждать апдейтов моделей и харнесов от вендоров, но и не забывать свою модель в голове — тогда они будут работать параллельно в тандеме. Закон Амдала еще никто не отменил.

Мы делаем свои интенсивы точечными и сфокусированными, чтобы закрывать конкретный вопрос, который часто «болит прямо сейчас». Перформанс как раз один из таких.

✍️ Записаться на интенсив WEB PERFORMANCE

🚀 Стартуем уже через неделю — 2-3-4 октября в 19:00 по МСК.

Производительность: от первого пикселя до интерактивного приложения

Удивительно, но понятие «производительность» в контексте фронтенда — это весьма сложная штука. Всё дело в специфике клиент-серверной архитектуры: мы оцениваем не только то, как быстро работает код, но и то, как быстро он может быть загружен и обработан. Сюда же — архитектура современных фреймворков с их SSR и BFF, куча нюансов на уровне сетевого стека (кэширование, сжатие) и производительность на уровне UI/UX. Ведь если интерфейс не отзывчивый, то даже при быстрой работе сервиса он может визуально тормозить.

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

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

🔥И мы попытались выделить самое основное и важное, ёмко упаковав это в новый трёхдневный интенсив от Димы Холстинина. Думаю, многие из вас знакомы с его продуктами по инфраструктуре, сборке и SSR. Дима — инженер, который умеет объяснять сложное без магии.

Сам интенсив построен вокруг жизненного цикла веб-приложения:

1. Запрос пользователя

2. Получение и загрузка ресурсов

3. Генерация HTML на сервере

4. Первый рендер

5. Загрузка и выполнение JavaScript

6. Гидрация

7. Интерактивное приложение

И каждую тему разбираем по одной и той же схеме:

Как работает? 👉 Почему бывает медленно? 👉 Как измерить? 👉 Как оптимизировать?

Потому что оптимизация без измерения — это гадание. А оптимизация без понимания — это карго-культ.

❓Что будет на интенсиве

Лекция 1. От URL до первого пикселя

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

Лекция 2. Производительность сервера и генерация HTML

Разберём, откуда появляется HTML и как сервер влияет на скорость загрузки: архитектура генерации (SSG, ISR, SSR, Edge), Event Loop в Node.js, получение данных, серверный рендеринг, стриминг и память процесса. Отдельно — про то, как не убить сервер сборщиком мусора и неконтролируемыми кэшами.

Лекция 3. От HTML к интерактивному приложению

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

Когда: 2-4 октября в 19:00 по МСК
Формат: Live + запись на 1 год.
Три лекции по 1,5–2 часа. Живое общение, разбор реальных кейсов, ответы на вопросы.


ПРИНЯТЬ УЧАСТИЕ В ИНТЕНСИВЕ

Этот интенсив о том как думать о производительности системно — чтобы потом уметь находить и чинить узкие места в любом стеке.

Если вы устали от советов «просто включите lazy loading» и хотите понять, как это работает на самом деле, — приходите.

Чем же я занимаюсь?

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

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

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

А какие примеры технических задач продукта? Сейчас у меня фоновая работа по миграции текущей компонентной базы на актуальный API Svelte 5 — и эта задачка пока на 95% делается фоном агентом в топологическом порядке (от простейших миграций к более сложным).

А еще большая задачка по перфомансу нашего сервиса. И перфоманс — это такая обширная тема, где просто нельзя всё свести к одному вопросу, вроде «уменьшить бандл» или «ускорить работу BFF». Нет, здесь всё работает в тандеме: нужно учитывать производительность как на клиенте (размер бандла, скорость гидратации, скорость от интерактивности до отрисовки, UI/UX), так и производительность сервера (критический путь рендера, стриминг, SSE и многое другое). Добавьте к этому ещё кучу нюансов вроде эффективного кэширования статики, использования наиболее подходящих форматов, балансирования между «немедленным» и «ленивым» отображением.

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

Степень использования LLM напрямую зависит от того, что конкретно я делаю. Разумеется, тупую техническую работу вроде миграции с одного API на другой гораздо эффективнее делать руками модели. Есть и задачки, которые в принципе делаются фоном, а есть, где LLM выступает в роли консультанта-ревьювера, но основную работу делаю именно я. Могу отметить, что такое балансирование даёт эффект «работы в команде», хотя по факту сейчас у нас нет какой-то кор-команды и я работаю один.

В целом могу сказать, что мне все нравиться и чувствую себя на своём месте ✊🏻

TS7 и семикратное ускорение!

На прошлой неделе перевёл тайпчекинг на работе на TS7 — и, должен сказать, результат меня действительно впечатлил. Нет, я знал, что новый компилятор на Go стал куда быстрее, и ожидал, что разница будет в 2, а может, и в 3 раза. Но в итоге она оказалась семикратной! При этом сам процесс миграции в нашем случае оказался не очень сложным.

Так что если вы ещё не сделали этого — возможно, пора! 🚀

Вся эта истерия про ИИ, который убьет человечество - это какая-то лютая разводка.

Очень похоже на «Проблему 2000». Олды помнят, как тогда айти-гиганты неплохо наварили на срочном и крайне необходимом обновлении всех компьютерных систем.

Я пока не понимаю, что мутят эти ИИшники, разгоняя галиматью про смертельную опасность. Может хотят «закрыться» об государство. Не понятно, скоро узнаем.

Но уверяю вас - всех спасут, но будет дорого.

Ну и как оно?

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

Вот и пробежали полтора месяца. Вроде полёт нормальный: я чувствую себя на своём месте и занимаюсь тем, что у меня хорошо получается. Я пишу код — и сам, и с агентом. Этот факт меня очень радует: я не разделяю восторгов от того, что у меня забирают необходимость писать код. Но не могу не отметить удобство использования ИИ в рутинных задачах: пробежаться по десяткам файлов и проверить, что ничего не сломал, или сделать рефакторинг со старого API на новое, которое я только что написал. Получается такое вот парное программирование. И, как по мне, оно весьма удобно и не отменяет моих личных скиллов, а наоборот — дополняет их.

Однако помимо работы в найме у меня фоном идёт CS и другие запуски. И вот тут, чёрт возьми, мне приходится напрягаться. Признаюсь, за полтора года вне найма я уже забыл, что значит вставать в 6 утра, чтобы подготовиться к лекции, потом отработать полный рабочий день, а после этого ещё прочитать двухчасовую лекцию. Тяжело, чего уж говорить.

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

Но что поделать, времена сейчас нестабильные, и, похоже, пик кризиса ещё только впереди. Но мы не выбираем эпохи, в которые живём — мы выбираем, как на них отвечать. А значит, остаётся одно: адаптироваться, не опускать руки и продолжать делать своё дело. Как говорил Рокки Бальбоа: «Важно не то как сильно ты бьёшь, а то, какой удар ты можешь выдержать». Будем держать.

1 сентября

Несмотря на то, что я уже 19 лет как окончил школу, этот день календаря помню хорошо. Линейка, я в форме, куча людей, гладиолусы, а у меня в голове только одно: жаль, не успел пройти… Может, сегодня успею? Домашки то ещё не будет 😏

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

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

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

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

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

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

Знание сила! Всех с праздником ✊🏻

P.S. Ну а тем у кого еще и дети в школе, вам большущего терпения! Нам еще 2 года до школы, поэтому пока наслаждаемся моментом 😅

Что почитать по AI?

Сергей Кобец:

Я бы рекомендовал ничего не читать, в режиме "читать чтобы читать" 🙂 в любой отрасли человеческих знаний, есть 2 состояния:

1. это интересно специалистам - об этом пишут специалисты для специалистов

2. это что-то про обещание заработать 100 млн в секунду и хайп - об этом пишут все, на всех заборах и не всегда понимают, что пишут

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

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

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

Но если все равно очень хочется что-то почитать, то у Сергея на Habr вышла первая часть из цикла статей - Инженерия качества: Как перестать надеяться на удачу и начать измерять своих ИИ-агентов [Часть 1]

Что по железу для локальной LLM?
"Мне для учёбы надо!" 🙂

Сергей Кобец:

Не могу представить, зачем для игр может потребоваться 5090, а вот для вайб-кодинга — очень даже да, и лучше взять не одну, а поставить 2 штуки. Я даже сломал уже одну: 7 месяцев под нагрузкой, и недавно отправил в гарантийный ремонт (благо гарантия 3 года). Но тут надо считать свою экономику.

Я, скажем, собрал рабочую станцию под контракт, и под контракт она отбилась за 2 месяца. А до этого арендовал виртуалку в внешнем облаке, но, опять же, я не покупал модель в режиме SaaS с оплатой за токены, а купил виртуалку с выделенной видеокартой и на ней руками развернул всё: от операционки до vLLM. Экономия очень значительная. Ты можешь платить условно за агентский движок + сервис-фасад до LLM + саму LLM и инфраструктуру, поднятую кем-то; в итоге с тебя 3–4 юрлица возьмут свою норму прибыли за комфорт.

А можно агентский движок собрать самостоятельно на своем компьютере, причем так, чтобы его признала ваша IDE, для LLM взять в аренду голую железку, развернуть всё руками и платить в 2–3 раза меньше. То, что предлагают по умолчанию в каком-нибудь Cursor, на самом деле максимально неоптимальный путь: дорогой и не с лучшим качеством.

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

В целом, если есть видеокарта хотя бы на 16 гигов, то уже можно вайб-кодить локально, не платя за облако; я покажу, как это делать правильно 🙂 А если есть что-то с 30+ гигами на борту, платить за облако вообще не очень разумно.

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

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

Вышло так, что я профессиональный разработчик, пишу код уже лет 15 и делать это руками еще умею, при этом я не в найме, а в бизнесе, причем в консалтинге, причем в консалтинге про ИИ, и если 23-24 год в этой нише астрологи объявляли период RAG-а, то 25й и 26й идут явно под знаком начинания, давайте оптимизируем свои команды, повыгоняем людей с застарелым мышлением и максимум работы будем делать ИИшкой. Таких начинаний сейчас полно и да, у многих директоров по ИИ или технических директоров сейчас действительно стоят КПИ на сокращения ФОТ-а, массовое внедрение агентов и техник вайб-кодинга. Боюсь у современных разработчиков просто нет выбора, кроме как адаптироваться к этим условиям.

Сразу хочу заметить, что постановка вопроса «нужны ли обычные разработчики», заведомо идиотская, люди отвечающие нет, в реальных ИТ проектах, обслуживающих реальных людей, так считающие - систематически огребают, и уже создали целый рынок нового консалтинга, когда такие целиком вайбкодинговые продукты, приходится немыслимыми усилиями за весьма приличные деньги спасать, что меня как специалиста с этого зарабатывающего конечно не может не радовать :)

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

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

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

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

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

🗓Когда: 21-23 августа в 19:00 по МСК (Live+запись на 1 год)

ПОЛУЧИТЬ AI ПРОШИВКУ ДЛЯ ИНЖЕНЕРА

Текст написал - Сергей Кобец. Автор и преподаватель интенсива «AI прошивка для инженера». Стиль и подача автора сохранены без изменений 😅

AI прошивка для инженеров
(Продолжение поста)

🔹ДЕНЬ 3: Архитектура собственной AI-среды

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

• On-Premise vs Cloud: Как развернуть LLM локально и когда облако все еще выигрывает.
• Экономика токенов: Оптимизация затрат на инференс
Протоколы связности: MCP, ACP и SKILLS
• Интеграция: Современные стандарты общения агентов с внешним миром и друг другом.
• Skill-манифесты: Проектирование контекстных навыков и специализированных профилей для ИИ.
 
2. Безопасность и контроль: Human-in-the-Loop

• Guardrails и Savepoints: Техники защиты от генерации «отравленного» кода и некорректных данных.
• Decision Points: Критические точки процесса, где человек обязан вернуться в цепочку принятия решений.
 
3. Оркестрация систем: LangChain, LangGraph и альтернативы

• Языковой барьер: Почему Python стал стандартом для AI-агентов и как уйти от него в TS/Go/Java, если необходимо.
• Параллельные графы: Связывание сложных цепочек зависимостей для нелинейной работы агентов.

21-23 августа в 19:00 по МСК
Запись - на 1 год

ПОЛУЧИТЬ ПРОШИВКУ AI

🔥Огонь? Не то слово! Чего греха таить, я сам пойду на интенсив.

Ух, ребят, у меня для вас очень крутые новости!🤩

Но прежде чем рассказать — дам немного контекста.

Я из инженерной семьи: программисты, химики — кого там только нет. Дедушка, кстати, был хирургом (это не инженерная профессия, но всё равно конструкторское мышление). У меня есть брат Сергей — он тоже программист, только если я пошёл во фронтенд, то он стал бэкендером, а затем увлёкся ML (ещё задолго до появления повсеместных LLM). Он работал большим начальником в самых разных бигтехах — от Сбера до МТС. А сейчас у него свой бизнес по консалтингу в области ИИ: он помогает крупнейшим компаниям страны внедрять ИИ и не потерять от этого внедрения последние трусы.

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

Мне хотелось, чтобы это не было долгим размусоливанием «от того да потому». А короткий патч, прошивка по AI для действующего инженера. И мы сделали такой интенсив!

⚡️И вотсегодня мы готовы его презентовать!

Программа рассчитана на 3 дня:

🔹ДЕНЬ 1: Фундамент и демистификация

Главная цель: Отсеять маркетинговый хайп, разобраться в реальной механике LLM и заложить основу для создания предсказуемых систем.
 
1. Анатомия LLM: почему ИИ «лжет» и ломается

• Механика контекста: Токенизация, скрытые лимиты и эффект Lost in the Middle.
• Иллюзия работы: Почему приложения, созданные быстрым «вайб-кодингом», почти всегда ломаются в продакшене.
• Смена парадигмы: Эпоха одноразового софта
 
2. Топологии генерации: от примитивных промптов к инженерии

• Промпт-тупик: Почему запрос «напиши XXX по-братски» — это путь в никуда.
• Анатомия агентов: Что скрывается за термином Agentic AI на самом деле.
• Алгоритмы в ИИ: Применение графов и динамического программирования внутри агентов, разбор паттернов ReAct, ToT, LATS и PAL.
 
3. Инструментарий Vibe Coding: вскрытие

• Под капотом: Анализ архитектуры популярных ИИ-плагинов и автономных агентов.
• Ловушка простоты: Как инструменты для «любителей» разрушают профессиональный стек разработки.
• Осознанный выбор: Критерии подбора инструментов под реальную сложность задачи, а не под тренды.
 
4. Психология разработчика: угроза или эволюция?

• ИИ как рычаг: Как превратить нейросети из конкурента в генератор личной эффективности и освободить время.
• Трезвый взгляд: Правда ли, что программисты больше не нужны, и кто выживет на рынке труда.
 
🔹ДЕНЬ 2: Инженерия процесса

Главная цель: Выстроить эффективный цикл сотворчества с ИИ, внедрить автоматический контроль качества и научиться масштабировать код через спецификации.
 
1. Симбиоз человека и LLM: баланс ролей

• Оптимальный пайплайн: Что инженеру делать руками, а что полностью делегировать генерации.
• Точки контроля: когда и как разумно проверять результаты генерации
 
2. ИИ в смежных задачах

• Архитектура: Генерация технического дизайна и функциональных требований.
• AI в DevOps и QA: Автоматизация тест-кейсов, мониторинг и конфигурация деплоя через промпты.
• Менеджмент: Применение LLM для планирования задач и управления командой.
 
3. Проектирование через спецификации (Spec-to-Code)

• Масштабирование: Единственный жизнеспособный способ «вайб-кодить» крупные корпоративные проекты.
• Передача контекста: Как заставить LLM понимать сложные доменные знания и легаси-код старых репозиториев.
 
4. Петля обратной связи: строим автопилот

• Метрики качества: Оценка компилируемости, производительности кода и продуктовых метрик (NPS, Retention).
• Самокоррекция: Создание автономных агентов, способных самостоятельно находить ошибки в логах и исправлять свой код.

Продолжение тут

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

Если вы давно собирались устроить книжный шопинг, то сейчас самое время 😏 В честь 35-летия издательства «Питер» на Wildberries и Ozon действуют специальные цены 😏

🛍 Вб | 🛍 Озон

Ребят, зацените какая годнота! До конца августа можно как следует закупиться книгами от легендарного «Питера» 🚀

Кажется настало время дополнить свою коллекцию по CS ❤️

Привет, ребят! Простите, что пропал с радаров. Просто не хватает времени и сил на блог, так как у меня и адаптация на работе, и курс читаю по Computer Science, а в эти выходные я еще буду проводить Live-интенсив «Vue под капотом», поэтому работа и подготовка к лекциям занимает все мое время сейчас. С семьей вижусь исключительно когда ем, благо работаю из дома. Я не жалуюсь, но объективно, времени в обрез.

Еще, пользуясь эфиром, хочу напомнить тем, кто ко мне идет на Vue - не забудьте добавиться в чатик! Ссылка на него есть у вас в письме после покупки и завтра с утра еще продублируем на почту и в бот школы.
Встречаемся в 19:00 по Мск.

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

В общем, до встречи завтра! Обещаю, будет как всегда глубоко и интересно!

Крафтовая разработка

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

Знаете, сегодняшние изменения в процессах и подходах к разработке с появлением AI-инструментов разделили разработчиков на две группы (и нет, я сейчас не про «свидетелей могучего» и «динозавров-отрицателей»): тех, кто любит программирование, и тех, для кого это просто процесс достижения личных целей — работа, зарплата и так далее.

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

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

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

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

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

Но кому, вы скажете, теперь нужны такие специалисты? И вот тут всё видится мне достаточно прямолинейным:

1. Вы продолжаете делать то, что любите и умеете. AI-инструменты могут помочь вам не только писать код, но и убирать то, что замедляло вас всё это время. Вы блестящий специалист, обладающий силой создавать новое там, где большинству кажется это бессмысленным. Пользуйтесь этим — делайте свои проекты, которые станут и вашим любимым делом, и тем, что принесёт вам деньги.

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

3. Вы не одиноки. За последние 1–2 года явно видна тенденция: опенсорсные проекты либо сильно ограничивают возможности применения AI, либо вводят правила их запрета, вплоть до отказа в принятии PR от людей не из команды без предварительного экзамена на адекватность. Появляются пометки «No AI» и прочее. И дело не в отрицании, а в том, что зачастую такие проекты развиваются теми, кто любит своё дело, и им больно смотреть, как их порядок тонет под напором бездумных, бессмысленных и безжалостных правок AI.

Всё это я бы назвал сейчас крафтовой разработкой. Разработка в руках экспертов, которые могут, хотят и любят. И это — самое главное.