Хвост инженера

Автор: Асхат Уразбаев · Организованное программирование | Кирилл Мокевнин

Асхат Уразбаев — один из наиболее известных Agile-консультантов в России, основатель ScrumTrek, более двадцати лет внедрял Agile в крупнейших российских компаниях. В этом выпуске подкаста «Организованное программирование» (1:53:26) он говорит не о том, как «правильно внедрять Scrum», а о том, что произошло с Agile за двадцать лет — и куда это движение привело.

Центральный вопрос разговора: почему Scrum победил XP? Ответ неочевидный — не потому что лучше технически, а потому что церемонии, роли и сертификации проще продавать. XP требовал технической дисциплины: TDD, парного программирования, непрерывной интеграции. Scrum предлагал процесс, который мог вести не инженер, а специально нанятый Scrum Master. Это решило задачу менеджмента — и убило технические практики.

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

Из этого можно взять в работу: спросить себя — Continuous Delivery в вашей команде есть, или только спринты? По словам Уразбаева, именно отсутствие CD при наличии Scrum-церемоний — самый частый симптом того, что «Agile» внедрён, а ценностей нет.

Автор: Антон Алексеев · HighLoad++ 2024

Доклад с HighLoad++ 2024 о том, как Selectel собирал инференс-платформу на базе open source-сервера NVIDIA Triton и Kubernetes. Triton решает базовую задачу: позволяет обслуживать ML-модели в продакшне без написания отдельного сервиса для каждой модели с нуля.

Сценарий типичный: модель сначала заворачивают в FastAPI, а затем обвязка постепенно обрастает batching, управлением инстансами, распределением GPU-ресурсов, обновлением версий и маршрутизацией трафика. Triton закрывает существенную часть этой базовой работы: умеет динамический batching, поддерживает модели в форматах PyTorch, TensorFlow, ONNX и TensorRT, а ensemble позволяет собрать цепочку моделей внутри одной ноды с одной GPU.

Но production-инференс начинается там, где заканчивается сам сервер моделей. Канареечное распределение трафика в платформе сделано через Istio, графы моделей на нескольких нодах — через Ray, а автоскейлинг GPU-ресурсов — средствами Kubernetes и дополнительными компонентами. Важная деталь: на момент доклада платформа Selectel ещё находилась в beta, поэтому это не история про «готовое решение из одной коробки», а разбор того, как такую систему собирают на практике.

Кому смотреть: ML-инженерам, MLOps- и DevOps-командам, которые обслуживают несколько моделей на GPU и хотят понять границу между возможностями inference-сервера и задачами всей платформы.

Из этого можно взять в работу: при внедрении Triton заранее разделите требования на две группы — что должен делать сам сервер моделей, а что потребует Kubernetes, service mesh, автоскейлинга, GPU-оператора или отдельного control plane.

Автор: Екатерина Давыдова · AvitoTech

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

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

Формат — не история успеха, а производственный разбор. Что делать на каждом шаге, какие этапы выпадают при планировании и потом больно бьют, и почему «80% компаний сказали что начали что-то внедрять, но только 10% смогли объяснить — что именно».

Кому смотреть: продуктовым лидерам, которым пришла задача «запустить что-то на GenAI» — и которые хотят понять, с чего начинать и где обычно закапываются.

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

Автор: Егор Заплатин · Яндекс Вертикали

Егор Заплатин — фронтенд тимлид в Яндекс Вертикалях (Путешествия, Аренда, Авто.ру). Доклад на Vertis JS 2026: полгода работы с AI-агентами в реальных задачах, выводы о том, что нужно сделать, чтобы они работали предсказуемо.

AI-агент не замещает инженера — он меняет то, на что инженер тратит время. Заплатин это понимает, хотя в докладе использует популярную аналогию «прокачать до мидла» — скорее как метафору для аудитории, а не буквальное сравнение. Содержательная часть, если убрать маркетинговую рамку, прикладная и по делу.

Центральная мысль: если ваш агент работает — это ещё ничего не значит. Надёжная работа в production требует инженерии. Заплатин разбирает четыре конкретные практики: правильно выстроенный контекст (что агент видит и в каком виде), feedback loop (как агент получает сигнал об ошибке и исправляет курс до конца задачи), MCP-интеграции (реальные инструменты вместо угадывания по обучающим данным), и скиллы — описания того, как решать конкретные задачи в конкретной кодовой базе. Примеры из продуктовых и технических задач на реальных проектах. Отдельно — задачи за пределами кода и масштабирование на команду.

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

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

Автор: Иван Ямщиков · Podlodka Podcast

Иван Ямщиков работает в Pleias — компании, которая строит открытые языковые модели. Во время записи выпуска Podlodka #468 вышла новость о партнёрстве Pleias с Nvidia в рамках проекта Nemotron. Это не случайный контекст: Ямщиков находится внутри процесса, а не смотрит на него снаружи.

Центральный вопрос выпуска — не технический, а стратегический: что произойдёт, если весь рынок AI окончательно сконцентрируется вокруг нескольких закрытых облачных провайдеров? Ямщиков формулирует это как инженерную проблему: зависимость от GPT-4 API — это зависимость от одного вендора с непрозрачной политикой изменений, ценообразования и доступа к данным. Маленькие открытые модели — это не «дешёвая альтернатива большим», это инструмент сохранения контроля над инфраструктурой. Модель на 7 миллиардов параметров, которая умещается на одной GPU и работает локально, даёт то, что никакое API не даёт: полную воспроизводимость, отсутствие утечки данных и независимость от апстрима.

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

Из этого можно взять в работу: если вы сейчас используете закрытый API для задачи, которая не требует GPT-4-уровня рассуждений (классификация, извлечение структуры, генерация по шаблону) — попробуйте запустить Mistral 7B или Phi-3 локально на той же задаче. Разрыв в качестве окажется меньше, чем вы ожидаете.

Автор: Владислав Танков · Podlodka Podcast

Владислав Танков — директор по AI в JetBrains. Это второй его выпуск на Podlodka (#452): первый (#444) был про внутреннее устройство LLM на уровне трансформеров и аттеншенов. Этот — про то, что происходит, когда модель нужно не просто запустить, а запустить в продакшне под реальной нагрузкой.

Большинство разговоров про LLM в продакшне сводятся к «берём OpenAI API и готово». Танков рассказывает про другой класс задач: когда API не подходит — из-за данных, задержки, стоимости или политики безопасности — и нужно думать об инфраструктуре самому. Локальный инференс vs облачный — это не просто вопрос цены, это вопрос контроля над latency, privacy и зависимостью от внешнего провайдера. В JetBrains этот выбор делается для каждого продукта отдельно, и критерии нетривиальны.

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

Из этого можно взять в работу: если вы сейчас используете LLM только через API — составьте список требований к задержке, приватности данных и стоимости для вашего конкретного use case. Это займёт час, но может изменить архитектурное решение.