# Тимлид не кодит – Сообщество тимлидов Казахстана > Крупнейшее сообщество тимлидов, инженерных менеджеров и CTO Казахстана: найм, архитектура, процессы и карьера. Зарплаты в IT и отзывы о компаниях. Полный текст всех материалов сайта https://teamleads.kz/. Карта разделов – https://teamleads.kz/llms.txt. Telegram-чат @teamleads_kz (https://telegram.me/teamleads_kz), 540+ участников. Встречи каждую среду в 17:00 (Астана, UTC+5). Язык материалов – русский. --- # Встречи сообщества Онлайн-встречи сообщества «Тимлид не кодит»: разбираем реальные кейсы, спорим об архитектуре и делимся опытом ## Встреча сообщества – 22 июля 2026 URL: https://teamleads.kz/events/meetup-2026-07-22/ Дата: 2026-07-22 Разработчик проекта умер: аварийное принятие ownership, археология инфраструктуры, пять уровней владения системой и спор о том, ускоряет ли это LLM Что делать, когда единственный носитель знаний по проекту умирает: аварийное восстановление инфраструктуры без документации и точек входа, дрейф софта за пять лет, реверс-инжиниринг процесса, пять уровней принятия ownership над чужой системой и спор о том, где здесь реально помогает LLM. ### Документация появляется только там, где есть ротация людей Наблюдение Андрея: документацию пишут не для команды, а для новичков и посторонних – это способ общения с незнакомцами. Нет ротации персонала – нет документации, потому что нет болевых точек: ты рассказал коллеге устно, и все. Отсюда эффект «хочешь разобраться – попробуй научить этому других». Типичная проблема enterprise и b2b проектов – один огромный мануал со всеми шагами, но без базовых подсказок для того, кто путается в самом начале. Как только документация написана, мотивация тратить на нее деньги пропадает: «мы теперь продаем продукт, занимайся фичами». При этом эффект у нее прямой и денежный – она удешевляет саппорт и онбординг, и это можно заложить в стоимость проекта. ### Кейс: подстраховать заболевшего разработчика – и не успеть Старый клиент позвал Андрея подстраховать существующего разработчика, у которого обнаружили рак: зарплату разработчику продолжали платить, планировался спокойный трансфер-период. Общение шло по почте, неспешно – человеку было не до этого, никто не форсировал. Болезнь оказалась скоротечной: полтора месяца, и разработчик умер, так и не передав ничего. Начался авральный режим – скоро придет очередная порция работы от клиента, а спросить некого. Клиент при этом опытный и понимал, что документировать процесс и требовать документацию было его зоной ответственности. ### Археология: восстановить инфраструктуру, не зная точек входа У проекта не осталось базовых точек входа: неизвестны сервера, названия репозиториев, конфигурации. Единственная зацепка – GitHub: поиск по названию клиента, потом по найденным названиям дальше. Часть инфраструктуры всегда неявно просачивается в репозиторий – имена сайтов, названия баз, метаданные инстансов; пароли у дисциплинированных людей не лежат. Данные хранились на зашифрованном диске (VeraCrypt), доступа к компьютеру умершего не было – он был внешним подрядчиком. Жену первые дни не беспокоили – «по-живодерски спрашивать в такие дни», поэтому разбирались сами, параллельно восстанавливая доступ к серверам. Пароль от диска жена нашла позже, и это спасло проект. ### Дрейф софта за пять лет и восстановление конфигурации Проект начинался пять лет назад и работал на старых версиях. За это время опенсорсный продукт успел стать не полностью опенсорсным, сменился вендор, поменялся формат данных, вспомогательные программы ушли вперед по версиям. Софт в интернете просто не нашелся – без пароля от диска пришлось бы искать лицензию или сборку на стороне. Ошибку Андрей признал за собой: он поставил последнюю версию вместо той, что была в проекте – нужно было сначала выяснить точную версию и поставить ровно ее. Конфигурация софта тоже была неизвестна: факт, что софт есть, не означает, что ты знаешь, как он настроен. ### Реверс-инжиниринг процесса и бизнес-терминологии Процесс оказался ETL-графом, описанным набором файлов – никакого способа разобраться, кроме инспекции всех файлов. Андрей написал простой скрипт, который нашел файлы, нигде не упоминаемые другими: это и есть корневые точки входа. Структура вскрылась типовая – главный проект, вариации под конкретных клиентов и операционные утилиты для собственного удобства. Дальше начался разбор бизнес-жаргона: аббревиатуры вроде QC-процесса типичны для такого рода задач, но в деталях нужно понимать, что под каждым словом подразумевается именно здесь. Ключевой прием – держать четкую картину того, чего ты не знаешь: вот эти термины я нашел, а эти пока нет. ### Пять уровней принятия ownership над системой Главная конструкция встречи. Андрей разложил владение компонентом на уровни: знание, где что находится; базовое понимание структуры и связи с бизнес-компонентом; подтвержденное понимание, когда сел и детально изучил; первое успешное изменение – проверка на практике, что понял правильно; многократные изменения в ходе эксплуатации, после которых компонент становится подконтрольным и можно думать о кардинальных изменениях. До этого система – «игрушка, которую страшно трогать». Уровни относятся к отдельному компоненту, а не к системе целиком: отдельно софт и его конфигурация, отдельно бизнес-компоненты, отдельно операционные процессы. Валидация понимания – пробный прогон на golden data: повторить работу предыдущего человека и сверить результат. ### Можно ли ускорить принятие ownership с помощью LLM Сквозной спор встречи. Павел заходил с трех сторон: подсказать аббревиатуры и термины, ускорить написание вспомогательных скриптов и главное – SDD-подход, когда предыдущий человек оставляет план, evidence и лог того, что пошло не так и как чинилось; для преемника это «клондайк». Андрей отвечал: скрипт он, возможно, и правда написал через LLM или греппом – это непринципиально. Понимание LLM не забирает и не добавляет, добавляет его только время; LLM-документация – это вода и рассказ вместо сухого лога. Аналогия: изучение системы – поход в незнакомый город, где заблудиться полезно, а карта дает дойти до точки, но не дает связей между районами. Павел сформулировал сам: «ты все еще турист в этом проекте, а тебе нужно стать жителем». ### Онбординг: почему три месяца нельзя сжать На новом проекте ты джун, кем бы ты ни был снаружи – и решаешь задачи пропорционально своей компетенции на этом проекте. Работает то, что делали с самим Андреем: самая простая задача (поменять текст, поправить дропдаун), обязательно под менторством. Ключевой нюанс – новичок не может отличить простую задачу от сложной: «добавить EF Core» может быть пятиминутным делом, а может утянуть в рефакторинг; оценить это может только мейнтейнер. Та же логика в социальной плоскости: новый руководитель сначала смотрит, как люди работают, повторяет за ними, получает доверие и проверяет управляемость коллектива, и только потом делает маленькие изменения. У Андрея на полный самостоятельный запуск ушло три месяца и два прогона – раньше не получилось бы, потому что бизнес не дает столько итераций. ### Трагедия как окно для выплаты организационного долга Резюме кейса: каждая катастрофа такого рода – возможность улучшить бизнес, потому что в этот момент бизнес максимально замотивирован и понимает, что косяк его. Документировать надо здесь и сейчас, по ходу изучения, а не «потом, когда разберусь» – потом ты забудешь половину мелочей, а конфигурация уйдет в дрифт. То же правило работает и без трагедии: упал прод, человек затупил – отлично, дописываем документацию в тот же момент. Ситуация в кейсе была почти идеальной: адекватный клиент, который оплачивал лечение и помог семье, весь код в source control, трансфер запланирован заранее. Но именно на такой чистой ситуации и удобно учиться – в тайфуне ты занимаешься выживанием, а не обучением. ### Выводы - Документация – это функция ротации людей, а не дисциплины: Пока команда не меняется, документацию писать некому и незачем: знания передаются устно. Она появляется там, где есть новички и посторонние, и пишется по сути для них. Практическое следствие: если ротация неизбежна, а документации нет – это уже накопленный организационный долг, просто он еще не предъявлен. - Организационный долг платится в момент катастрофы – и это единственное окно: Бизнес выплатил не технический, а документационно-организационный долг ровно тогда, когда появилась болезнь. В момент аврала он максимально замотивирован: понимает, что косяк его, и не хочет повторения. Поэтому любую катастрофу – потерю носителя знаний, упавший прод, чужую ошибку – надо использовать как повод дописать документацию прямо сейчас. - Документируй по ходу изучения, а не «когда разберусь»: Писать документацию потом не получится: половина мелочей забудется, а конфигурация уйдет в дрифт. Заметки, которые ты делаешь, пока сам ничего не понимаешь, – это уже база для документации, и это выгодно обеим сторонам: ты быстрее строишь модель системы, клиент получает актив. SOP пишется позже, когда ты уже научился запускать. - Ownership набирается уровнями, и перепрыгнуть их нельзя: Знаю, где лежит → понимаю структуру → детально изучил → первый раз успешно изменил → менял многократно в эксплуатации. Только после этого компонент становится подконтрольным, и только тогда можно думать о кардинальных изменениях. Уровни считаются по каждому компоненту отдельно – владение одним ничего не говорит о владении системой. Проверка понимания – пробный прогон на golden data предыдущего исполнителя. - LLM уплотняет работу, но не проходит за тебя стадию понимания: LLM ускоряет поиск, генерацию вспомогательных скриптов и убирает мартышкин труд, но принятие ownership – это работа руками. Карта не заменяет прогулки по незнакомому городу: с навигатором ты дойдешь до нужной точки, но останешься туристом, а нужно стать жителем. Отдельно: ответственность за понимание компонента нельзя делегировать LLM – кто-то в цепочке все равно должен понимать. - Онбординг не ускоряется, но его можно сделать безопасным: На новом проекте любой сеньор – джун, и задачи должен получать джуновские: маленькие, под менторством, подобранные тем, кто знает проект. Новичок физически не может отличить пятиминутную задачу от той, что утянет в рефакторинг. Та же схема работает и для нового руководителя: сначала смотреть и повторять за коллективом, потом маленькие изменения, и только в крайнем случае «пускать кровь». ### Мнения участников - Помогает ли LLM принять ownership над чужим проектом? Понимание она не забирает и не добавляет – добавляет только время; ускорить можно скрипт или поиск, но стадию руками все равно проходить / Можно поднять throughput и оставить преемнику готовые артефакты; но соглашается: от понимания никуда не уходишь - Что делать предыдущему разработчику, чтобы облегчить передачу? Документировать по ходу изучения и работы, пока есть силы; писать SOP, когда научился запускать / Работать по SDD: план, evidence, лог проблем и ремедиаций – это клондайк для того, кто придет следом - Годится ли LLM-документация как наследство? Нет: она пишет не для людей, много воды, рассказ вместо сухого лога фактов / Изначально видел в этом ценность, по ходу разговора согласился с оговоркой про качество текста - Можно ли ускорить онбординг нового человека? Нельзя: три месяца – это три месяца, бизнес не даст больше итераций, чем даст / Ищет, где процесс можно сжать; принимает, что сжимается только мартышкин труд - Кто отвечает за отсутствие документации? Ответственность клиента – требовать документацию у подрядчика; но восстанавливать все равно исполнителю / – ### Открытые вопросы - Практика передачи проекта: какой минимальный набор артефактов (доступы, SOP, точки входа, версии софта) должен существовать на случай внезапной потери исполнителя - Как продавать клиенту документацию и онбординг как строку в смете, а не как «хорошо бы» - Уровни ownership как инструмент менеджмента: можно ли явно отмечать, на каком уровне находится человек по каждому компоненту, и планировать по этому - Golden data и пробные прогоны: как организовать проверку понимания системы новым человеком на исторических результатах - SDD-артефакты как наследство: что реально стоит сохранять по ходу работы (план, evidence, лог проблем), чтобы преемнику это помогло, а не утонуло в воде - Lifestyle business как модель: чем компания без авралов и с зарплатами ниже рынка выигрывает у гонки за деньгами Участники: Андрей (Организатор; кейс с умершим подрядчиком, уровни ownership), Павел (Оппонент: SDD-артефакты и где помогает LLM) Теги: бас-фактор, документация, онбординг, AI-агенты ## Встреча сообщества – 15 июля 2026 URL: https://teamleads.kz/events/meetup-2026-07-15/ Дата: 2026-07-15 Spec-driven development и агенты: «спека для LLM» против спецификации, development loop, аналогия с трансформацией бизнеса, тест-план, spec drift и свой harness Как спецификации и агенты меняют разработку: почему «спека для LLM» это подход spec-driven development, а не спецификация; эволюция от human-in-the-loop к development loop; почему лупы работают как трансформация бизнеса; тест-план, spec drift и путь к своему легковесному harness. ### «Спека для LLM»: терминологическая путаница Уалихан вернулся к своему спору с Максом Горбадюком и понял, что они спорили про слова. Макс говорил, что для спеки нужны знания о базе и проектировании – и это верно. Уалихан же имел в виду не «спеку для LLM», а сам подход: spec-driven development, docs-first. Миша скинул статью Бриджиты Боккелер (на сайте Мартина Фаулера, цикл «Exploring Generative AI», конец 2025 года) – с ремаркой, что это не мнение самого Фаулера, он под своим брендом продвигает других авторов. Вывод: подход не новый, ему уже больше полугода. ### Spec-driven на практике: SID, слайсы и миграция Bestok Уалихан описал реальный проект: миграцию старого брокера Bestok (двухфазные коммиты, FTP, SQL через DFS, паутина из десятка приложений), от которого надо избавиться, потому что он выйдет из употребления. Где можно, заменяют дорогие гарантии дешевыми: вместо атомарной консистентности – eventual consistency, полумикросервисный подход. Архитектор написал SID сам плюс с помощью LLM (не «сгенерируй мне SID»), с 37+ аппендиксами (секреты, ротация, дата-модель, workflow). Из SID нарезаются слайсы и PRD. Роль LLM тут – упорядочить и централизованно презентовать знания людей, которые по 10+ лет писали под Bestok. ### От spec-driven к development loop Spec-driven – это про human-in-the-loop: дал LLM написать кусок-слайс, посмотрел, отрефлексировал, поехал дальше; задачи бьются на подзадачи, чтобы контекст не тух. Поверх этого пишут behavior-тесты (BDD). Нынешний development loop идеологически похож, но пытается убрать человека из петли. Он работает там, где вокруг задачи можно выстроить constraints и тесты (harness): если это можно обложить однотипными тестами, запускаешь конвейер задач, который бесконечно лопатит и что-то выдает. ### Почему лупы работают: аналогия с трансформацией бизнеса Ключевой тезис Павла: лупы работают в компаниях с широкой автоматизацией и хорошим менеджментом – по тем же причинам, что бизнес-трансформация. Ты не меняешь все сразу, а «выкидываешь кусок бизнеса» и пересобираешь по новым правилам. «Кровь» при этом нормальна: приходит человек, ломает старое, год-два все страдают, потом всем легче. Люди вроде Уалихана видят нарушение локального минимума, но не видят широкую картину, зачем эта неоптимальность выгодна. Отсюда миграция и переписывание становятся понятной бизнес-задачей: переучить людей, построить процессы, описать их спецификацией. ### Кейс Zig → Rust и «тесты как приемка» Разобрали публичный кейс переписывания продукта с Zig/Node на Rust (RAAS). Павел делал анализ: плотность покрытия тестами после перехода ухудшилась, интересно посмотреть на стабильность билдов. Много пиара: банк выпустил пост о том, как они переписали, но не назвал дату релиза и назвал не сумму, а бюджет токенов (~$200k) – потому что сумма пугает. С точки зрения бизнеса даже $200k на переписывание дешево. Рабочая схема та же, что у лупов: спеку описал тестами, тесты используешь как приемку; регрессию потом «накручиваешь», а майлстоун считаешь рабочим. ### Тест-план как артефакт и spec drift Павел вытащил забытый артефакт: тест-план – это производная спецификация на ПО, которую agile «опопоцал». А зря: тест-план полезно видеть до того, как ты позволишь агенту писать все, что хочет – это скоп видимости на релиз. У Павла был опыт с харденинг-спринтом перед релизом и тест-планом на 300-500 тестов. Отдельно – spec drift: SID это корень, из него ветвятся PRD и слайсы; если не следить за согласованностью, верхнеуровневая спецификация отстает и LLM тащит из контекста старье. Архитектура при этом – решения на 5 лет и ограничения, а не «поддержать все». ### Инструмент для перевода как «система в зародыше» Уалихан предпочитает начинать не со спеки, а с маленького рабочего инструмента, который можно ваншотнуть. Придумал консольную утилиту с двумя функциями: разбивает Markdown на шаблон с маркерами и PO-подобный файл для перевода, переводит по параграфам через API (Google Translate / LLM), потом склеивает обратно по маркерам. Дальше это легко «раздувается»: редактор с автопереводом правок, translation memory, личный глоссарий терминов, который же можно подавать в LLM. Каждый шаг тривиальный. Проблема ровно одна – как сделать это долгоживущим: документировать решения и покрыть интеграционными тестами, чтобы LLM потом не напортачила. ### Дисциплина, гардрейлы и свой harness Рефлексия Уалихана: он не дописывает спецификацию в начале, потому что рассчитывает, что LLM сама займется процессом – а она не займется, если не заставить. Сначала надо самому руками писать спеку и тесты («ничего не делаем без теста»), чтобы понять, где LLM ломается, и только потом автоматизировать. LLM легко придумывает лишние тесты (из пяти три тестировали пустоту) – название теста надо писать точнее. Павел предложил продавать это заказчику через воспроизводимость: гардрейлы на бюджет ($5-10 за прогон, ~10 экспериментов в $100) и понятные constraints – «получите второго джуна». Обсудили легковесные спек-лупы против «монструозной бюрократии» spec-kit; вывод – каждый потихоньку приходит к своему harness. ### Выводы - «Спека для LLM» – это spec-driven development, а не спецификация: Спор оказался терминологическим: под «спекой для LLM» имеют в виду подход (docs-first, spec-driven по Фаулеру/spec-kit), а не спецификацию в строгом смысле. Сам подход не новый – это human-in-the-loop цикл: SID → слайсы → PRD, LLM пишет кусок, человек рефлексирует и правит. - Development loop – следующий этап: убрать человека из петли: Лупы работают там, где задачу можно обложить тестами и constraints (harness) и есть широкая автоматизация. На маленьких задачах это дешево: гардрейлы на бюджет ($5-10 за прогон) дают воспроизводимый результат, который можно показать заказчику как «второго джуна». - Почему лупы работают – это трансформация бизнеса, а не разработка: Ты «режешь» кусок процесса и пересобираешь по новым правилам; временная «кровь» и неоптимальность нормальны, если бизнес управляем. Люди, которые видят локальный минимум, не всегда видят широкую картину, зачем это выгодно – поэтому миграция становится понятной бизнес-задачей, а не только технической. - Тест-план и spec drift – забытые, но полезные артефакты: Тест-план – производная спецификация, «опопоцанная» agile; полезно видеть его до того, как агент начнет писать, как скоп видимости на релиз. Но LLM легко придумывает лишние тесты, поэтому названия надо писать точнее. SID – корень, PRD ветвятся; без согласованности LLM тащит старье (spec drift). Архитектура – это решения на 5 лет и ограничения, а не «поддержать все». - Маленький инструмент – это «система в зародыше», а главный риск – дисциплина: One-shot утилиту (разбить Markdown → перевести по параграфам → склеить, плюс translation memory и глоссарий) легко раздуть тривиальными шагами до продукта. Но чтобы она жила долго, нужно самому дописывать спецификацию и тесты – LLM не возьмет это на себя, пока не заставишь. Свой легковесный harness – закономерный финал этой эволюции, а не «монструозный» spec-kit. ### Мнения участников - «Спека для LLM» – это спецификация? Это не спека, а подход spec-driven development; спор с Максом был про терминологию / Это spec-driven; тест-план – производная спецификация, забытая agile / «ASAP ≠ Agile»: классический Agile не запрещает потратить спринт на спецификацию - Human-in-the-loop или лупы без человека? Пока держусь human-in-the-loop: сам пишу спеку, чтобы видеть, где LLM ломается / Лупы работают там, где есть широкая автоматизация и тесты-обвязка; это как трансформация бизнеса / – - Быстро меняться и переписывать – это хорошо? Не верю в «всегда быстро меняться»; «кровь» терпима, но осознанно / «Кровь» для бизнеса нормальна, год-полгода приемлемо, зато закрываешь вопрос / – - Как сделать one-shot инструмент долгоживущим? Документировать и покрыть интеграционными тестами, но пока не хватает дисциплины / SDLC-правила («ничего без теста»), тест-план до кода, гардрейлы на бюджет / – ### Открытые вопросы - Development loops на практике: где граница применимости, как обложить задачу тестами и constraints и удержать бюджет через гардрейлы ($5-10 за прогон) - Свой легковесный harness под себя: как из команд, скиллов и спек-лупов собрать личный workspace вместо «монструозного» spec-kit - Тест-план в эпоху агентов: как писать точные названия тестов и не давать LLM придумывать лишние сценарии - Долгоживучесть one-shot инструментов: как документировать решения (ADL, clarifications) и покрывать интеграционными тестами, чтобы LLM не «напортачила» - Разбор кейса Zig → Rust: что реально случилось с покрытием тестами и стабильностью билдов после переписывания Участники: Уалихан («Луддит»: SID, миграция Bestok, инструмент для перевода), Павел (Эволюция лупов, трансформация бизнеса, тест-план), Миша (Скидывал материалы: Фаулер, «ASAP ≠ Agile») Теги: spec-driven, AI-агенты, тестирование, архитектура ## Встреча сообщества – 8 июля 2026 URL: https://teamleads.kz/events/meetup-2026-07-08/ Дата: 2026-07-08 LLM в разработке и переводе: спеки против «патчинга», тесты как приемка, экономика субагентов, ремесло перевода и локализация как процесс Как LLM меняет два ремесла – разработку и перевод: спека против детального «слайса», цельное видение системы против «патчинга», тесты как приемка вместо программиста, экономика субагентов и почему ручная вычитка перевода не автоматизируется. ### «Спека» против «слайса»: подмена понятий Разговор начали с терминологии спек-флоу. Уалихан развернул структуру рабочей единицы – «слайса»: PRD (in scope, out of scope, риски, constraints), ADL/ADR (Architecture Decision Log с маркированными решениями вроде «не используем поле image в SQL Server»), clarifications, data model, task index с зависимостями задач и планами, которые потом выполняет «какой-нибудь сонет». Его вывод: это не спецификация, а детальный план работ – и называть это «спекой» значит подменять понятие. Настоящая спецификация ловит грубую логическую ошибку до реализации, потому что требует цельного понимания системы, а не патчинга. ### Цельное видение системы против «патчинга» Ключевая ось. Для Уалихана система – цельное собрание живых взаимосвязанных процессов, и «патчинг» (проектирование модулями по кусочкам) ведет к «каше и лапше». Контраргумент: патчинг – рабочая схема, многие системы так дорастали до объема, а хай-левел-подход (SID сверху вниз до endpoint) тоже рабочий. Отдельный тезис: LLM не умеет абстракцию – спека для нее слишком абстрактна, ей нужно предметное и суженный контекст. Отсюда вопрос, держать ли в разработке людей, которые видят систему целиком, или разводить роли на «архитекторов» и «исполнителей». ### Экспертиза, незаменимость и риски бизнеса Уалихан описал свою модель: маленькие команды, где каждый «съел собаку» на своем компоненте и отвечает за него; планирование скидывается на внешний мир (реагирование на заказчика), на себе – только polisy-making. Тезис «незаменимых нет»: если бизнес экономил на процессах и экспертизе, он заплатит 3x за болезнь или уход человека – но это риски заказчика, а не исполнителя. Вывод для карьеры: если тянет к сложной технической работе, не иди в аутсорс и бизнес-разработку, где люди «на расход» – иди сразу в компании, которые делают инструменты. ### LLM как чек-лист и evidence Прагматичный взгляд Вадима и других: даже если ты все знаешь сам, LLM полезна как аудитор – проходит по чек-листу, задает вопросы по темам, гоняет дип-ресерч по конкурентам и готовым решениям (по публичке, быстро, с табличками) и работает как критик, вскрывая подводные камни. Бонус для бизнеса – артефакт с эвиденсами: работа видима и прозрачна, feasibility, частые мелкие PR-ы, каждая таска двигается по борде «в реальном времени». Уалихан признал ценность видимости, но назвал это не аргументом: скорость сама по себе вредна, у человека фиксированное число качественных решений в день. ### Тесты как приемка: отказ от программиста Самая радикальная идея. По аналогии с переходом на компиляторы и ООП (никто не смотрит на машинный код) – приемку описывают интеграционными тестами, а как оно реализовано, отдают на откуп LLM. Раз LLM вероятностна, надо сузить контекст так, чтобы она почти детерминированно проходила тесты, которые не пропускают неправильное. Ценность смещается от написания кода к бизнес-экспертизе и экспертизе тестирования; программиста в пределе убирают. Оговорки: работает для несложных, непроцессных систем и поверх готовой платформы; на greenfield и многопроцессных системах все равно нужны архитекторы-программисты. ### Субагенты, скиллы и эволюция экспертизы Практика работы с агентами. Главное «заблуждение»: субагенты не жрут токены, а экономят – каждое новое сообщение в большом контексте тащит весь миллион токенов и дорожает, а изолированный субагент работает на 30 тысячах; кэш дешевле, но изоляция все равно выгоднее и повышает качество. Практик выходил в 80% «паровоза» на 30–40 параллельных субагентах, отдавая основному контексту Opus 4.8 (1M), а субагентам – модель попроще. Дальше: план-мод плюс документация на каждый merge request, скиллы как накопленная экспертиза проекта, которую агент переписывает сам, эволюционные алгоритмы для улучшения промптов по тестам, граф кодовой базы для поиска. Fable дал на ~30% больше edge-кейсов, чем Opus 4.8, но «жрет дохрена». ### Перевод LLM: ремесло против автомата Переход ко второй теме. Уалихан вернулся к переводам после паузы – и ChatGPT стал переводить заметно хуже: вольничает, дописывает фразы, разбивает на лишние параграфы. Его процесс ручной: переводит по 2–3 параграфа, черновик, отлежка на день-два, потом внимательная вычитка с оригиналом перед глазами – и именно вычитка, а не перевод, самое ценное и неавтоматизируемое, особенно в технических и исторических текстах. Консенсус по моделям: для казахского/украинского/русского лучше всего GPT (fine-tuned под эти языки), Google Translate выше DeepL, а «свежие» модели деградируют. Fine-tuning решил бы, но дорого (~$3k за итерацию) и уже не везде доступен. ### Локализация как процесс, а не «залепение» Уалихан развернул больную тему: перевод через Google Translate в ресурсные файлы – это не локализация, а «compliance-галочка», болезнь индустрии, под которую заточено много фреймворков. Настоящая локализация – процесс: контекст для переводчика (на каком экране какой ключ), консолидация названий, синхронизация переводчиков и разработчиков, отдельные тестировщики-носители языка. Инструменты: Crowdin как лучшая платформа процесса, JetBrains-бандлы с параллельным показом нескольких переводов, идея связки бандлов с Figma, чтобы переводчик «как в тиндере» вычитывал варианты прямо на макете. Рекомендация: делать мультиязычность в «день 0», иначе перевод превращается во второй проект. ### Выводы - «Спека для LLM» – это план, а не спецификация: Слайс из PRD, ADR, data model и task index – рабочая и удобная штука, но это детальный план работ, а не спецификация в строгом смысле. Настоящая спецификация ловит грубую логическую ошибку до реализации, потому что требует цельного понимания системы. Называть план спекой – удобная, но подмена понятий. - LLM не умеет абстракцию – ей нужен предметный, суженный контекст: Спека для модели слишком абстрактна; она работает на предметном материале и коротком контексте. Отсюда практический вывод: и в разработке, и в переводе задачу дробят на мелкие единицы, а контекст изолируют – так меньше шанс ошибки. - Тесты как приемка смещают ценность от кода к экспертизе: Если приемку описать интеграционными тестами и сузить контекст, реализацию можно отдать LLM, а ценность уходит в бизнес-экспертизу и экспертизу тестирования. Но это работает для несложных, непроцессных систем и поверх готовой платформы – на greenfield и многопроцессных системах архитектор-программист никуда не девается. - Субагенты экономят токены, а не жгут их: Большой контекст дорожает с каждым сообщением, потому что тащит весь объем; изолированный субагент на 30 тысячах токенов дешевле кэша и точнее. Правило – минимизировать общение между агентами и отдавать им итоговый результат, а не переписку. - Перевод и локализация – это процесс и ремесло, а не автомат: Вычитка с оригиналом перед глазами не автоматизируется, особенно в технических и исторических текстах; лучшая модель – та, что была fine-tuned под целевой язык. А локализация приложения – процесс с контекстом ключей, консолидацией и носителями-тестировщиками, который надо закладывать в «день 0», иначе получаешь «compliance-галочку» вместо перевода. ### Мнения участников - «Спека для LLM» – это спецификация? Детальный план работ, а не спецификация – подмена понятий / LLM – это harness; настоящую спеку пишешь с экспертом, а не «LLM, напиши спеку» / Не важен термин – LLM как чек-лист и evidence-артефакт для бизнеса / «Спека для LLM» ≠ спека; это ближе к Rational Unified Process, чем к Agile - Отказаться от программиста, оставив бизнес + тесты? Только для несложных, непроцессных систем; иначе нужны архитекторы / Сузить контекст и обложить интеграционными тестами – приемка детерминирована / Да, если все покрыть тестами – ценность в бизнес- и тест-экспертизе / – - Субагенты – это дорого по токенам? – / Наоборот дешевле: изоляция контекста экономит против гонки миллиона токенов / 30–40 субагентов параллельно, минимум общения между ними – дешево и качественнее / – - LLM заменит ручной перевод? Нет – вычитку, нюансы, тональность не автоматизировать; руками надежнее / – / Дробить по параграфам, логировать правки, векторная база – можно приблизить / Дело в fine-tuning под язык: GPT силен там, где его дообучали ### Открытые вопросы - Надежный процесс LLM-перевода технических и исторических текстов: глоссарий терминов, вычитка, fine-tuning под низкоресурсные языки - Локализация «в день 0»: как с самого начала маркировать ключи и передавать переводчику контекст экрана ### Вопросы, закрытые позже - Эволюция скиллов и промптов через тесты и эволюционные алгоритмы: как накапливать личную экспертизу в переиспользуемую систему агентов (разобрано на meetup-2026-07-15) - Тесты как приемка: где граница применимости (многопроцессные и greenfield-системы) и как покрывать тестами тонкие нюансы (разобрано на meetup-2026-07-15) - Инструмент для вычитки перевода: параллельный показ оригинала и перевода, diff, связка с Figma для локализации UI (разобрано на meetup-2026-07-15) Участники: Уалихан («Революционер»: цельные системы и ремесло перевода), Андрей (Организатор; экономика субагентов, тесты), Вадим (LLM как чек-лист, тесты, субагенты), Виктор (За «правильную формализацию» и постановку задач), Павел (История методологий: waterfall, RUP; fine-tuning), Александр (Fine-tuning под низкоресурсные языки), Василий (Подключался в начале) Теги: LLM, спецификации, тестирование, перевод ## Встреча сообщества – 1 июля 2026 URL: https://teamleads.kz/events/meetup-2026-07-01/ Дата: 2026-07-01 Джуны и найм: чья ответственность растить джунов, найм «адекватных с улицы», грейдирование, Story Points и клиенто-ориентированная гонка за фичами Безтемная встреча, из которой выросла дискуссия о джунах и найме: чья ответственность растить джунов, можно ли брать «адекватных с улицы» на нетехнические роли, грейдирование, Story Points и граница между клиенто-ориентированностью и «беличьим колесом» доработок. ### Работа на западном рынке: язык решает Разговор начали с открытого вопроса про работу на западных рынках. Вывод Андрея: чтобы работать на локальном рынке страны (Франция), недостаточно английского – нужен язык делового общения той страны, где живёшь; английского хватает только на международном рынке. При этом локальные рынки структурно напоминают СНГ: те же жалобы на «дураков-коллег и начальников-чайников». Разработку почти никто не отдаёт на аутсорс внутри страны – все хотят штат; подрядные модели держатся в основном вокруг администрирования и системной интеграции. ### Воспитание джунов: чья это ответственность Центральная ось спора. Уалихан: обучение и развитие – инициатива и ответственность самого сотрудника, а не обязанность компании; «спасение утопающих – дело рук самих утопающих», компания должна лишь соблюдать социальный контракт. Михаил и Андрей: для узкого прикладного IT это рабочая бизнес-модель, но если хочешь большего – без вложений в обучение не обойтись. Отдельный аргумент от инфляции: чтобы удерживать людей и не терять их к конкурентам, нужно повышать выработку, а значит – квалификацию; «чтобы стоять на месте, надо быстро бежать». ### Найм «адекватных людей с улицы» на нетехнические роли Провокация Уалихана: там, где нет жёстких технических критериев (проектный/продуктовый менеджер, скрам-мастер), можно брать любого «адекватного» человека, потому что специализацию всё равно не свалидируешь. Контртезис: если разработчику достаточно «дать инструмент» (LLM), почему тогда и разработчика нельзя взять «с улицы»? Михаил защитил роль PM через PMI/PMBOK: расписание, риски и закупки можно делегировать, но интеграция всех видов деятельности в результат остаётся за руководителем проекта; PM – это «трикстер» и агент изменений. Проблема в том, что грейдирования и внятного описания роли PM почти нигде нет – «учат плавать, выбросив на середину озера». ### Скрам-мастер и мода на процессы Скепсис к индустрии, которая «ведётся на моду» и переназывает старые роли (DevOps, SRE, PaaS – это переименованные роли в команде). «Красную книгу» Сазерленда про Scrum назвали вредной: она создаёт «атмосферу успешного успеха», хотя Scrum нужен далеко не везде. Из-за этого роль скрам-мастера часто вырождается в администратора команды, тогда как настоящему мастеру нужен матёрый человек, решающий «экзистенциальные вопросы существования команды», а не двигающий стикеры. Плохие «скрамы» – это просто плохие планёрки по часу. ### Грейдирование и таланты Проблема грейдирования в компании с разнородными продуктами: единая линейка может публично понизить человека (был сеньором – стал «слабым мидлом»), и он уходит. Рабочий приём – числовые грейды (L1/L2/L3), развязанные с ярлыками «сеньор/мидл» и привязанные к потолку ценности проекта; для уникальных талантов создают отдельные позиции. Грейдирование – это в первую очередь страховка взаимозаменяемости (проверка на бас-фактор): «любая бизнес-трансформация – это кровь», часть людей неизбежно уходит, и это ожидаемо. ### Story Points против фактического времени Ответ на давний вопрос из бэклога. Корреляция между Story Points и реальным временем выполнения – минимальная: проверяли и в игровой ситуации, и на реальных данных из Jira. Технически посчитать легко (выгрузка из Jira → корреляция → график), но главный вопрос – зачем: людям просто «хочется чувствовать власть над временем». ### Менее компетентный руководитель: как быть Живой кейс: твой тимлид/руководитель менее компетентен в софт-скиллах – что делать. Артур предложил путь «серого кардинала»: стать для него авторитетом и мягко манипулировать, продавливая удобные тебе решения (открыто назвав это «тёмной триадой»). Андрей возразил, что предпочитает прямое, прозрачное влияние без манипуляций и построения политических клик – иначе сам будешь параноить, что тебя хотят подсидеть. Отдельный красный флаг: когда при найме тебя даже не знакомят с прямым руководителем. ### Клиенто-ориентированная разработка: горячка против здоровья продукта Самая долгая дискуссия. Молодой стартап (запуск в январе 2026, команда из шести человек) бежит закрывать каждую клиентскую интеграцию (LDAPS, Teams, YouTrack, кастомные трекеры), потому что «мы на ранней стадии и цепляемся за каждого клиента». Андрей раскритиковал это как «беличье колесо»: продажи перегружают производство, компания субсидирует интеграции из своего кармана, и вместо найма джунов «для снятия рисков» стоило бы поднимать цены, лучше продавать и приоритизировать по 20/80. Контекст к джунам: на зрелом проекте (2,5–3 года) джун «не вывозит» из-за доменной сложности, а на greenfield – вполне. Отдельно разобрали «клиентократию» (пример JetBrains) – когда «нет запроса – не делаем», и продукт зарастает шероховатостями. ### Выводы - Обучение джунов – это социальный контракт, а не благотворительность: Модель «сотрудник учится сам» работает для узкого прикладного IT, но инфляция и потребность в росте выработки рано или поздно заставляют вкладываться в квалификацию. Вопрос не «должна ли компания», а «какой у неё горизонт». - Роли без жёстких критериев – ловушка найма: Там, где нельзя строго свалидировать навык (PM, скрам-мастер), легко скатиться к найму «адекватных с улицы» и получить администратора вместо агента изменений. Ценность PM/скрам-мастера – в интеграции и решении экзистенциальных вопросов команды, а не в ведении тикетов. - Грейдирование страхует бас-фактор, но ранит таланты: Числовые грейды (L1/L2/L3), развязанные с ярлыками и привязанные к ценности проекта, повышают взаимозаменяемость; уход людей – в том числе проверка систем на взаимозаменяемость. Но для уникальных талантов нужны отдельные позиции, иначе нормализация их выталкивает. - Story Points не коррелируют с временем: Проверено и в игре, и на реальных данных Jira: корреляция минимальная. Стремление привязать SP к часам – это желание «власти над временем», а не рабочий инструмент оценки. - Клиенто-ориентированность легко превращается в «беличье колесо»: На ранней стадии цепляться за клиентов нормально, но когда продажи систематически перегружают производство и компания субсидирует интеграции из своего кармана, лечится это не наймом джунов «для снятия рисков», а ценой, приоритизацией 20/80 и продажей «на равных». ### Мнения участников - Чья ответственность – развитие и обучение джунов? Для узкого прикладного IT ок, но для роста надо вкладываться в обучение / Инициатива и ответственность самого сотрудника – компания ничего не должна / Инфляция давит на выработку – без роста квалификации не выжить / – - Можно ли брать «адекватных с улицы» на нетехнические роли? – / Да, где нет жёстких техкритериев (PM, PdM, скрам-мастер) / У роли PM есть системные требования (PMI/PMBOK), но грейдов почти нет / – - Как влиять на менее компетентного руководителя? Прямое, прозрачное влияние без манипуляций / – / – / Стать «серым кардиналом» и мягко манипулировать под свои условия - Клиенто-ориентированная гонка за фичами – это норма? «Беличье колесо» – надо поднимать цены и приоритизировать 20/80 / На ранней стадии цепляешься за каждого клиента, фичи переиспользуются / – / – ### Открытые вопросы - Найм на нетехнические роли (PM, продакт, скрам-мастер): как валидировать то, что нельзя измерить строгими критериями - Грейдирование в компании с разнородными продуктами: как не демотивировать людей при переходе на единую линейку - Как работать с менее компетентным руководителем, не скатываясь в манипуляции и политические клики - Здоровье продукта против клиентской гонки: критерии, когда пора поднимать цену и говорить клиенту «нет» - Анонимная голосовая «курилка» сообщества: постоянная ссылка, Discord против IRC и как организовать записи Участники: Андрей (Организатор, работает во Франции; скептик), Уалихан (Стартап и облачный провайдер, «революционер»), Михаил (Проектный/продуктовый менеджер, банк, PMI/PMBOK), Артур (О влиянии через «серого кардинала»), Александр (О менеджере как «переводчике» коммуникации), Василий (Идея анонимной голосовой «курилки»), Ян (Участник дискуссии о найме и джунах) Теги: джуны, найм, грейдирование, продукт ## Встреча сообщества – 24 июня 2026 URL: https://teamleads.kz/events/meetup-2026-06-24/ Дата: 2026-06-24 Продуктовые разработчики, доменная экспертиза, карьерные треки, бас-фактор, скепсис к AI и почему в Казахстане нет условий для экспертов Продуктовые разработчики и доменная экспертиза: как готовить специалистов, понимающих бизнес, карьерные треки, бас-фактор, скепсис к AI и условия для экспертов в Казахстане. ### Продуктовые разработчики и доменная экспертиза Встреча открылась незакрытым вопросом прошлых созвонов – «как системно конвертировать разработчиков в продуктовых». Процесс уже идёт неформально: бизнес хочет учить разработчиков, а тем нужно понимать бизнес. Инструменты – сессии доменных экспертов с разработчиками и гемба (инспекция на рабочем месте из системы Тойоты). Сложность не в протоколе, а в предметной области: FIX – лёгкий протокол, но за ним плечо у заказа и опционы; в медицине FHIR, в обмене данными EDI. Продуктовых разработчиков меньше – часто они просто не афишируют, что знают бизнес. ### Как растить продуктовых разработчиков – без хайпа Учить программированию и бизнесу одновременно педагогически неверно и дорого: сначала растят разработчика, до продуктового доучивают потом. Примеры специализации: «логистика и автоматизация» в Казахско-немецком университете; американская модель information management; «скилл-менеджмент» IBM – реестр компетенций всех сотрудников. Главное предостережение: «за большим хайпом скрывается большой попил» – лучше усилить то, что уже делается, и требовать при найме опыт в той же индустрии. ### Вовлечение пассивного сообщества и покупка доверия Как расшевелить молчаливую аудиторию. Аналогия с командой: сначала спрашиваешь мнение у людей, используешь «мы», а если попросили – делаешь максимально близко к просьбе. Это «покупка доверия»: психологическое доверие первично и работает постоянным фоном, а не разовой акцией. Но сообщество – не команда (классика – «5 пороков команды» Ленсиони, первый порок – отсутствие доверия), и не все приёмы применимы. История hackerspace под Парижем: простую сетевую рисовалку «дожали за день», и людям зашло – значит, надо нащупывать, что интересно. ### Форматы встреч и мост с EPAM Онлайн – менее обязывающий формат, раскачать сложнее; офлайн сам фильтрует по желанию прийти. На украинских мероприятиях (КМА) проблему решали приглашённым гостем и заданной темой: первая половина – доклад-разогрев, вторая – свободное общение (формат не для всех). Отдельная ценность – мост с EPAM: Паша как активный участник может стать «проводником» между локальным сообществом и аутсорсерами, у которых другая, близкая к корпоративной, культура. ### Бас-фактор – смерть единственного носителя знаний Живой пример. Участника позвали в стендбай на проект, где у единственного разработчика обнаружили рак поджелудочной; план передачи знаний готовили, но человек умер за две недели. Процесс был на зашифрованном диске по требованию HIPAA – и пароль знал только он. Спас GitHub, но восстанавливать процессы реверс-инжинирингом – «то ещё приключение». Вывод: экстремальные ситуации рождаются из экономии; продуктовое знание не живёт в документах, его нужно передавать живому дублёру. ### Карьерные треки и культура увольнений Вырасти с джуна до сеньора в одной продуктовой компании невозможно (в аутсорсе – возможно); «сеньора не дают, сеньора берут». Тимлидом стать легче – можно после мидла, но team lead и tech lead разные, а названия ролей раздают «как попало». Тимлидов меньше, чем сеньоров, ждать места дольше; убирать действующего – «игра престолов». После сеньора – архитектор, CTO, узкий эксперт («999 долларов за знание, куда ударить») или переход в более сильную компанию. Параллельно – парадокс: сокращение 10 % ухудшит процессы, а 50 % заставит их реорганизовать. ### AI – экономический эффект, скепсис и «наслабо» Скепсис, но интеллектуально честный. Исследование эффекта AI до 2026 года не обнаружило ни плюса, ни минуса; в опросе 11 тысяч менеджеров (март 2026) лишь 9 % отметили эффект – «выглядит как погрешность». Оговорка: кто мало работает с AI, тот криво его оценивает. Управленческий приём «наслабо» – спор на бутылку виски, что лайки будут готовы за три дня: цена в три дня обходит консилиумы и оценки «это полгода», за которыми прячется нежелание брать ответственность. ### Почему в Казахстане нет условий для экспертизы Нет ни потребности, ни условий для первоклассных спецов: эксперты почти не «вылазят» в комьюнити, а зарплата от 2 млн тенге (≈ 4 тыс. долларов) штатно – узкий кейс. Сначала спрос, потом экспертиза; контрпример – Яндекс Клауд (переманили человека из AWS, самописный движок с нуля). В Казахстане Яндекс.Облако и VK Cloud «сожрали» рынок, местным незачем напрягаться, а демпинг добивает экспертизу. Смежно: токсичность и экспертиза не связаны, но избавляться от неугодных опасно; консультанты часто «продаваны»; ценят тех, кто «стоит у кормушки с деньгами». ### Выводы - Продуктовых разработчиков растят отдельно: Нельзя учить программированию и бизнесу одновременно – сначала разработчик, потом доучивание до продуктового через гембу, сессии с доменными экспертами и наём с опытом в индустрии. Без хайпа. - Бас-фактор – не теория: Единственный носитель знаний с паролем «в голове» – реальная угроза. Продуктовое знание не живёт в документах; его нужно передавать живому дублёру, а не надеяться на героизм. - Карьерные треки и грейды: Сеньором в одной продуктовой компании не вырастают – «берут»; тимлид и техлид разные роли. После сеньора: архитектор, CTO, узкий эксперт или переход в более сильную компанию. - AI – честный скепсис: Экономического эффекта исследования пока не находят (9 % – погрешность), но судить вправе тот, кто реально работает с AI. Приём «наслабо» обходит консилиумы и завышенные оценки. - Нет условий для экспертизы: Сначала спрос – потом эксперты; в Казахстане спроса нет, а демпинг облаков добивает локальную экспертизу. Токсичность и экспертиза не связаны, консультанты часто «продаваны», а ценят тех, кто «стоит у кормушки с деньгами». ### Мнения участников - Есть ли в Казахстане эксперты мирового уровня? Появляются «назло системе», но несистемно / Нет условий и спроса – больше их не станет / Единицы есть, но невидимы и не на внутренний рынок - Сокращать ли штат разработки? – / Сократить вдвое – заставит реорганизовать процессы / Потеряется накопленная экспертиза, терять людей опасно - Можно ли стать сеньором в одной компании? – / В продуктовой невозможно – «сеньора берут, не дают» / Тимлиды вырастают из сеньоров; зависит от структуры - Экономический эффект AI? Исследования эффекта не нашли – нужен честный скепсис / – / Лишь 9 % менеджеров видят эффект – похоже на погрешность ### Открытые вопросы - Нюансы работы на западных рынках (Европа, США): наём, язык, релокация и отличия менеджмента - Как системно готовить продуктовых разработчиков: гемба, сессии с доменными экспертами и специализированные программы - Консалтинг как карьерный трек после эксперта: как раскачать имя в отрасли и не стать «продаваном» - Как нащупывать форматы активности в сообществе на примере живых экспериментов (hackerspace-подход) ### Вопросы, закрытые позже - Бас-фактор: как бизнесу страховаться от потери единственного носителя знаний (разобрано на meetup-2026-07-08) Участники: Андрей (Организатор, опыт hackerspace во Франции), Уалихан (Стартап и облачный провайдер, «революционер»), Михаил (Банк, экспертиза по аутсорсу и консалтингу), Василий (Позитивный взгляд на AI) Теги: экспертиза, карьера, продуктовые разработчики, AI ## Встреча сообщества – 17 июня 2026 URL: https://teamleads.kz/events/meetup-2026-06-17/ Дата: 2026-06-17 Активизация чата сообщества, офлайн-митапы, анонимный голосовой safe-space, мост с EPAM, поиск работы за рубежом и развитие разработчиков Как «распечатать» сообщество: активизация чата, форматы совместной деятельности, мост с EPAM, поиск работы за рубежом и развитие разработчиков. ### Как активизировать чат В чате ~500 человек, но пишут постоянно лишь пара десятков. Заставить активность нельзя – «по дулам пистолета» только проредит ряды, а молча читать – нормальная форма участия. Рабочий путь – инициатива снизу: человек предлагает идею, а сообщество помогает её развить. Возможны отдельные тематические болталки и подбадривание новичков, чтобы не стеснялись предлагать. ### Офлайн-митапы и площадки Часть людей в Астане и Алмате готова собираться вживую. Просто «собраться» знакомиться рост не двигает, но как формат имеет смысл. Небольшие митапы (до ~15 человек) реально проводить бесплатно в барах – 127.1, Queen of Darkness, DreamCup; для больших нужен платный коворкинг. Нужен «человек-лицо» в городе. Ориентир по формату – DreamCup: раз в месяц, три доклада, потом неформальное общение. ### Регулярные тематические созвоны Подключаешься к чату – 60–70 непрочитанных, ты вне контекста. Идея – заранее назначать время и тему обсуждения, чтобы можно было подготовиться и прийти «в контексте». Для тех, кто не читает всё подряд, такие фиксированные точки (тема + дата + ограниченное время) становятся опорными. В отличие от офлайн-митапа, онлайн не требует совпадения городов. ### Анонимный голосовой safe-space Василий предложил «изюминку» – анонимный голосовой чат по аналогии с 4chan/2ch, но с голосом: разгонять тему без страха деанона. Назначение – чувствительные темы: вакансии, вопросы с собесов, ситуации в компаниях. По технологии сверхрешение не нужно: подойдёт IRC (mIRC, ERC), self-hosted нода, анонимность зависит только от пользователя (ник, VPN). Минус IRC – нет голоса, годится для прототипа. Открытый вопрос – нужен ли формат людям. ### Мост с EPAM Связка с EPAM ценна международной повесткой и «столкновением цивилизаций»: галера с Code of Ethical Conduct против локальных стартапов. Менеджмент у клиентов EPAM в среднем сильнее казахстанского, умеет сглаживать проблемы; есть стандартизация и рычаги влияния (смена проекта, эскалация). Нужен «проводник» – казахстанец из EPAM. TechOrda показывает: компания растит джунов под свой уровень и рынку их отдавать не спешит. ### Поиск работы за рубежом и прожарка резюме Рынок поменялся – рекрутеры сами уже не пишут. Рабочая схема (по сути продажи): упаковать специализацию, через Sales Navigator фильтровать по стране и должностям (CEO/CTO и рекрутеры с большой сетью), прогревать лайками и комментариями, затем коннект и вопрос о позиции. Отдельная схема – недавно профинансированные стартапы (AngelList/YC), у них срочность и бюджет. Раздел jobs работает плохо из-за спама. Полезный формат – прожарка резюме, в том числе для новичков. ### Развитие разработчиков Ян спросил, что делать, если разработчики не проявляют инициативу. Совет: не давать готовых решений, а быть медиатором – на конкретном примере показать цепочку ошибок и спросить, что улучшить. Люди не спрашивают из страха «неудобных» вопросов – нужно защищать их право говорить «это невозможно» и учить думать, а не выполнять «раз-два-три». Инструмент – ретроспектива без поиска виноватых; решение и ответственность остаются за руководителем. ### ИИ, сокращения и хостинг Сокращения «под флагом ИИ» чаще не про эффективность, а про финансы: давление инвесторов, нужно показать «оптимизацию» или закрыть ковидный перенаём. При этом ИИ недёшев – через квартал-два можно платить за него сопоставимо. Технический хвост: статический IP у казахстанского телекома дороже и менее стабилен, чем Hetzner; персональные данные по закону РК хранить в стране (достаточно бэкапа в S3), локальная GPU дороже облачной. ### Выводы - Активизация чата: Заставить активность нельзя – ставка на инициативу снизу, тематические каналы и опорные точки: регулярные созвоны с фиксированной темой и временем. - Форматы встреч: Офлайн-митапы реальны: бары на ~15 человек бесплатно, ориентир – DreamCup. Нужен «человек-лицо» в городе. Прожарка резюме – полезный регулярный формат. - Мост с EPAM: Связка ценна международной перспективой и более сильным менеджментом; нужен «проводник» – казахстанец из EPAM. TechOrda растит джунов под себя. - Поиск работы за рубежом: Не раздел jobs, а таргет на CEO/CTO и рекрутеров через LinkedIn/Sales Navigator с прогревом; отдельная схема – недавно профинансированные стартапы. Смена работы раз в 2–3 года – норма. - Развитие разработчиков и инфраструктура: Учить думать и задавать вопросы, быть медиатором, защищать право говорить «нет», проводить ретроспективы без поиска виноватых. Сокращения «под флагом ИИ» чаще про финансы; для хостинга Hetzner предпочтительнее казахстанских хостеров. ### Мнения участников - Как активизировать чат? Инициатива снизу, заставить нельзя / Нужна «изюминка» – анонимный голосовой safe-space / Можно и «накикнуть» неактивных (в шутку) - Анонимный чат – технология? IRC / self-hosted, всё упирается в людей / Воскресить анонимный формат (2ch/4chan) с голосом / – - Инфраструктура сообщества? – / Self-hosted на Hetzner для pet-проекта / Поднимает open-source клауд и обещанные серверы - Офлайн-встречи? Разовый сбор не двигает рост, нужен регулярный формат / – / – ### Открытые вопросы - Регулярные тематические созвоны: как выбирать темы, фиксировать расписание и анонсировать опорные точки - Мост с EPAM: кто станет «проводником» и в каком формате проводить совместные ивенты - Прожарка резюме как регулярный формат сообщества: кто проводит и как часто - Практика выхода на иностранных заказчиков через LinkedIn / Sales Navigator: пошаговый разбор - Игры сообщества: DnD-формат разбора жизненных и управленческих ситуаций ### Вопросы, закрытые позже - Анонимный голосовой safe-space: запуск MVP, выбор технологии (IRC + голос) и привлечение первых участников (разобрано на meetup-2026-07-01) Участники: Андрей (Организатор, «площадка для людей»), Василий (Активизация чата, анонимный голосовой safe-space), Ян (Развитие разработчиков, опыт собеседований), Паша (Площадки для митапов, идея обучающей игры), Адиль (Организация звонков), Уалихан (Open-source клауд-инфраструктура и серверы) Теги: сообщество, найм, EPAM, карьера ## Встреча сообщества – 3 июня 2026 URL: https://teamleads.kz/events/meetup-2026-06-03/ Дата: 2026-06-03 Серверный полигон для сообщества, миграция на Discord, мок-интервью, культура найма и роль технических лидеров в управлении Развитие инфраструктуры сообщества: серверный полигон для экспериментов, миграция с Telegram на Discord, подготовка к собеседованиям и культура найма в казахстанском IT. ### Серверный полигон для сообщества Стас предложил создать площадку на серверах сообщества для экспериментов и обучения: Kubernetes-namespace для каждого желающего, Capture the Flag для программистов (задачи на исправление багов, а не на взлом). Для студентов с бюджетными ноутбуками такая площадка особенно ценна – Kubernetes на слабом железе не развернёшь. Артур предоставил сервер. Модель доступа открытая: «обратитесь – поговорим – получите доступ». ### Миграция с Telegram на Discord Андрей выступил за переход: Discord даёт каналы, роли, лычки и отдельные направления для участников. Проблема – инертность аудитории: костяк перейдёт, но привлекать новых станет сложнее. Компромисс – двусторонняя синхронизация: сводки в Telegram, детальные обсуждения в Discord. Идеологический аргумент: Telegram – комфорт ценой суверенитета. ### Интернет-инфраструктура Казахстана Проблемы с Cloudflare и нестабильность подключений – следствие зависимости казахстанского интернета от российской инфраструктуры. Планируется прокладка маршрутов через Турцию. Вывод: отдавать контроль над инфраструктурой опасно – «с точки зрения Макиавелли это плохо». ### Подготовка к собеседованиям и мок-интервью Адиль спросил про площадки для тренировки интервью. Профессиональные сервисы заточены под FAANG и дороги. Альтернатива – мок-интервью внутри сообщества, но нехватка инициативных людей ограничивает формат. Практический совет: искать существующие сообщества мок-интервью и подключаться к ним. ### Культура найма и этика на собеседованиях Обсудили снобизм в крупных казахстанских компаниях (Kaspi, Колёса): высокомерие интервьюеров, оффлайн-only формат в некомфортных условиях. Андрей провёл этическую границу «хакинга» собесов: приукрасить существующий опыт – допустимо, выдумывать – нет. Для джунов ситуация сложнее: компании формально требуют завышенный опыт. Макс предложил создать инструмент подготовки к собесам с коллективной модерацией сообщества. ### Роль технических лидеров: «захват власти» Андрей: единственный способ изменить культуру найма и управления – техспецы должны соглашаться на роли тимлидов и выше. Пример Unity: менеджмент «доит» мощную интеллектуальную собственность, но не развивает продукт – замораживает старый код, перекладывает проблемы на пользователей. Параллель с казахстанским IT: менеджменту всё равно, как решаются задачи, значит, можно строить инженерную культуру изнутри. ### Выводы - Серверный полигон: Артур предоставил сервер. Концепция: sandbox с Kubernetes, CTF для программистов, открытый доступ по запросу. Спрос пока неясен – нужен эксперимент. - Миграция платформ: Discord функционально лучше для сообщества, но переход требует двусторонней синхронизации. Промежуточный вариант: сводки в Telegram, обсуждения в Discord. - Культура найма: Снобизм и оффлайн-only собеседования в крупных компаниях отталкивают кандидатов. Приукрашивание опыта допустимо, выдумывание – нет. - Мок-интервью: Профессиональные сервисы дороги и заточены под FAANG. Для сообщества реалистичнее подключиться к существующим группам или наладить внутренний формат. - «Захват власти»: Технические специалисты должны занимать управленческие позиции – иначе культура найма и разработки не изменится. Пример Unity показывает, что происходит, когда менеджмент оторван от технологии. ### Мнения участников - Серверный полигон – кому нужен? Открытый доступ, пусть само определится / Особенно ценно для студентов с бюджетным железом / – - Telegram или Discord? Discord – идеологически и функционально / Плюсы есть, но люди инертны / – - Хакинг собеседований Приукрашивание – да, обман – нет / – / Нужен инструмент подготовки с модерацией сообщества - Как менять найм? Техспецы должны занимать управленческие позиции / – / – ### Открытые вопросы - Как запустить серверный полигон и привлечь первых пользователей - Практическая настройка синхронизации Telegram–Discord - Формат мок-интервью внутри сообщества: регулярность, темы, кто проводит - Как изменить культуру найма в казахстанских IT-компаниях изнутри - Инструмент коллективной модерации контента: архитектура и распределение ролей Участники: Андрей (Организатор, тезис о «захвате власти» техлидами), Василий (Серверный полигон, мок-интервью), Макс (Инструмент модерации контента), Адиль (Подготовка к собеседованиям), Артур (Предоставил сервер для полигона), Паша, Ян Теги: сообщество, найм, инфраструктура, собеседования ## Встреча сообщества – 21 мая 2026 URL: https://teamleads.kz/events/meetup-2026-05-21/ Дата: 2026-05-21 R&D в IT: что считать исследованием, граница между разработкой и R&D, критерии Фраскати, казахский LLM-токенизатор и метрики исследовательской деятельности R&D в IT: что считать исследованием, где проходит граница между разработкой и исследовательской деятельностью, и как это применимо к казахстанскому IT-рынку. ### Пять видов R&D Андрей озвучил классификацию: фундаментальное исследование, прикладное исследование, экспериментальная разработка, продуктовая R&D и процессная R&D. Первые два вида практически отсутствуют в Казахстане. Большинство IT-компаний занимаются продуктовой разработкой – внедрением и улучшением существующих бизнес-практик. Процессная R&D требует хорошо налаженного бизнеса с несколькими одинаковыми подразделениями для сравнительных экспериментов. ### R vs D: главный спор встречи Андрей настаивал, что участники говорят о букве D (Development), а букву R (Research) подтягивают без обоснования. Его тезис: отсутствие компетенции в компании – это не R&D, это пробел в знаниях. Артур приводил контрпримеры – перевод маркетплейса на WebView для A/B-тестирования, оптимизация карточек товаров через OpenCV в Kaspi. Андрей отвечал, что это инженерные задачи, потому что технологии известны и практикуются тысячами компаний. ### Где начинается настоящий R&D Монти привела пример из Sterdyev: компьютерное зрение для определения протёршихся шин и идентификации автомобилей по звуку мотора ночью. Андрей согласился – мало компаний в мире обладают такой экспертизой, это ближе к настоящему R&D. Также обсудили казахский LLM-токенизатор: команда полностью пересобрала токенизатор, чтобы одно казахское слово = один токен. Это признали явной инновацией для слаборесурсного языка. ### Критерии R&D по руководству Фраскати (ОЭСР) Сослались на международные стандарты определения R&D. Пять критериев: новизна (нацеленность на новые результаты), творчество (оригинальные и неочевидные концепции), неопределённость (непредсказуемость результатов и затрат), систематичность (запланированный и задокументированный процесс), воспроизводимость (результаты можно передать или воспроизвести). Участники отметили, что даже эти критерии уязвимы – «творчество» без базовых знаний превращается в переизобретение велосипеда. ### R&D и стартапы: нужна железобетонная база Андрей утверждал: стартап не может заниматься R&D, потому что исследование – это риск, а для риска нужна финансовая подушка. Василий возразил – он с братом ведёт AI-стартап. Андрей классифицировал это как «один эксперимент», а не систематическое исследование. Обсуждали важность патентования: если исследование не задокументировано и не опубликовано, оно «умерло» вместе с компанией. ### Метрики и KPI для R&D Не пришли к консенсусу. Обсуждали патенты (метрика легко становится целью), экономические параметры (стоимость прототипирования, время деплоймента, количество дефектов), а также модель DARPA – ротация программных менеджеров каждые несколько лет для устранения предвзятости. Подход Маска (KPI за количество идей, а не качество) работает только при отборе людей, которые хотят менять статус-кво. ### Венчурный капитал и AI как предлог для сокращений В СНГ около 100 венчурных фондов и ангелов суммарно. Миф о простоте инвестиций в США – везде работает нетворкинг. Отдельно обсудили кейс КазахТелеком: нарратив «заменяем людей ИИ» для обоснования сокращений. Реальная причина – финансовая оптимизация, а AI создаёт удобное прикрытие. Идеальная конфигурация: и социалку порезать, и бонусы за инновационность получить. ### Выводы - R vs D: Большинство того, что в Казахстане называют R&D – это Development без значимой Research-компоненты. Отсутствие компетенции в конкретной компании не основание называть деятельность исследованием. - Спектр определений: Группа обозначила спектр: от «любая новая активность» до «деятельность с патентом/публикацией». Промежуточная позиция: R&D – это когда компания тратит ресурсы на задачу с непредсказуемым результатом в области с малой мировой экспертизой. - Казахские инновации: Пересборка LLM-токенизатора для казахского языка признана настоящей инновацией. Компьютерное зрение для специализированных задач (Sterdyev) – пограничный, но убедительный пример R&D. - Инфляция термина: Когда всё называют R&D, обесценивается настоящая исследовательская работа. Это принижает роль системы образования и создаёт ложное впечатление инновационности. - Метрики: Универсальных KPI для R&D не существует. Патенты – неидеальная метрика, но пока лучшая для фиксации результатов. В Казахстане локальные патенты часто делаются «для тендера», а не для защиты реальных разработок. ### Мнения участников - Что считать R&D? Только деятельность с патентом или публикацией / Всё новое для компании / Уникальные задачи с неизвестным результатом / Бюджет, готовый к «закапыванию» на новое - WebView-миграция – R&D? Нет, инженерная задача / Да, колоссальное количество неизвестных / – / – - Нужна ли база для R&D? Да, железобетонная финансовая / – / – / Да, но прикладной R&D возможен - R&D в Казахстане? Практически нет / Есть, но не признаётся / Есть в специализированных нишах / Есть в прикладном виде ### Открытые вопросы - Как выстроить R&D-процесс в казахстанской IT-компании среднего размера - Практические шаги к патентованию IT-решений в Казахстане - R&D и налоговые преференции: как работает в США и что можно перенять - Как измерять ROI исследовательской деятельности в продуктовых компаниях Участники: Андрей (Организатор, классификация R&D и «радикальная» позиция), Артур (Кейсы Kaspi/Yumi, широкое определение R&D), Монти (Кейсы Sterdyev, компьютерное зрение), Павел (AI/LLM стартап, границы эксперимента и исследования), Михаил (Bereke Bank), Василий, Уалихан, Сергей Теги: R&D, метрики, инновации, патенты ## Встреча сообщества – 14 мая 2026 URL: https://teamleads.kz/events/meetup-2026-05-14/ Дата: 2026-05-14 Контроль качества кода: линтеры, CI, JWT vs явные параметры, AI-пентестинг и автодокументация Контроль качества кода: линтеры, статический анализ, автоматизация CI-проверок и организационные аспекты внедрения инженерных практик в команды. ### Линтеры и статический анализ: где запускать Обсуждали три уровня запуска линтеров: IDE, pre-commit hook, CI build. Андрей считает, что IDE должна быть настроена на максимум, а commit hooks он не любит. Другие участники возражали, что pre-commit hook дает мгновенную обратную связь, а не заставляет ждать 10 минут CI-билда. Консенсус: линтеры на CI обязательны в любом случае, потому что commit hook легко обойти, а после мержа все должно проверяться независимо. ### Внедрение инженерных стандартов в команды Два подхода: постепенный (для маленьких команд с доверием) и директивный (для крупных организаций). Андрей рассказал, что в компании с 140 разработчиками любые мягкие подходы проваливались – работало только директивное «с завтрашнего дня мерж-реквесты не пройдут без линтеров». Андрей обратил внимание, что новые процессы – это отдельные проекты, и нельзя навесить на команду четыре новых практики одновременно. ### Теория разбитых окон и конформизм Если в проекте вся кодовая база структурирована и покрыта Swagger-документацией, новые разработчики автоматически следуют этим стандартам – они копируют соседний код. Андрей назвал это конформизмом: люди подстраиваются под окружение. Важно убрать психологический барьер – показать примеры на большом объеме кода, чтобы стандарт «победил количеством». ### JWT-токены и глобальный контекст vs явный проброс параметров Самая жаркая дискуссия встречи. Артур защищал подход с глобальным контекстным объектом (сервис сессии, инъекция через DI), из которого можно достать user ID в любом слое. Василий и Андрей категорически против: глобальный объект неконтролируем, скрывает зависимости, ломает тестируемость. Явный проброс параметров дает контроль через компилятор – при добавлении нового параметра все точки использования «рассыпаются» ошибками компиляции. ### Безопасность и аудит уязвимостей Обсуждали npm audit, NuGet CVE-сканирование и корпоративные репозитории артефактов. При сканировании одного проекта нашли тысячу пакетов с уязвимостями. Андрей подчеркнул, что уязвимости – это баги, и сообщество должно решать их через PR и форки. Жоха рассказал кейс, где локальная LLM с MCP-доступами провела пентест значительно эффективнее (на 80% больше находок), чем нанятая команда пентестеров. ### Декомпозиция и абстракции SonarQube хорошо воспитывает декомпозицию за счет ограничений на сложность и длину методов. Но проблема в том, что разработчики декомпозируют, чтобы удовлетворить инструмент, а не логически. Участники согласились, что один метод в 100 строк часто лучше абстракции из 10 классов. ### Автоматическая генерация документации Жоха рассказал про подход команды: локальная LLM с настроенными скиллами анализирует проект и генерирует Mermaid-диаграммы в MD-файлах. Андрей возразил: цель документации – обучение, а автогенерация не дает обратной связи о том, где люди спотыкаются. Документация – это отдельный навык и процесс, а не разовая генерация. ### Выводы - Линтеры и CI: Линтеры на CI – обязательный минимум. Pre-commit hooks полезны для быстрой обратной связи, но ненадежны как единственный гейт. IDE-настройки – личное дело разработчика, но на CI все должно быть строго. - Внедрение стандартов: В больших организациях эффективнее директивный подход. В малых командах работает постепенное внедрение через лидеров мнений. Каждый новый процесс – отдельный проект, нельзя навесить все сразу. - Явный проброс параметров: Контроль важнее удобства. Явные параметры дают: детерминированный код, тестируемость без моков, контроль побочных эффектов через компилятор, видимость зависимостей при ревью. - AI для пентестинга: Локальная LLM с MCP-доступами к инфраструктуре показала результаты на 80% лучше нанятой команды пентестеров при значительно меньших затратах. - Документация: Документация – это навык и процесс, а не артефакт. Нужно писать туториалы по сценариям использования, проверять их на новых людях и итерировать. Автогенерация полезна для анализа, но не заменяет осмысленную документацию. ### Мнения участников - Где линтеры? IDE на максимум, CI обязательно, директивно / – / – - Как внедрять стандарты? Постепенно через лидеров мнений, но директивно в крупных организациях / – / – - Глобальный контекст? Против, теряешь контроль / За, удобно и просто / Против, нужен контроль компилятора - JWT в бизнес-логике? Десериализовать на входе, дальше user object / Достаем из контекста / Явно пробрасывать параметры - Автодокументация? Скептичен, цель – обучение / – / – ### Открытые вопросы - Практический гайд по пентестингу с помощью LLM (тема Жохи) - Diagrams-as-code: Mermaid, Quarto и подходы к визуализации архитектуры ### Вопросы, закрытые позже - Как управляться с редкими талантами (тема Андрея, не успели обсудить) (разобрано на meetup-2026-06-24) Участники: Андрей (Организатор, линтеры и стандарты кода), Артур (Внедрение стандартов в команды), Василий (JWT vs явные параметры), Жоха (AI-пентестинг с LLM), Денис, Ян, Паша, Аза, Луар Теги: линтеры, CI/CD, JWT, AI-пентестинг ## Встреча сообщества – 7 мая 2026 URL: https://teamleads.kz/events/meetup-2026-05-07/ Дата: 2026-05-07 Джуниоры в Казахстане, онбординг, роль тимлида, борьба с навязанными решениями, Open Source и студии Проблемы джуниор-разработчиков в Казахстане, онбординг и целеполагание, роль тимлида как защитника архитектуры, борьба с навязанными техническими решениями, Open Source и публичная вики по госинтеграциям. ### Проблемы джуниор-разработчиков в Казахстане Начинающие разработчики брошены на произвол судьбы – сообщество слабо развито, бизнес ориентирован на быстрый заработок без инвестиций в людей. Это ведёт к массовой эмиграции специалистов. Стоимость обучения джуна – статистическая погрешность для бюджета большинства компаний, но страх «вложиться и потерять» блокирует инвестиции. ### Переработки и пределы продуктивности Андрей поделился опытом: физиологический потолок интенсивного программирования – 80 часов в неделю, и это достижимо лишь при идеальных условиях с последующим двухмесячным проседанием. Попытки заставить команду работать быстрее через «нагайку» – следствие плохого менеджмента, а не решение проблемы. ### Онбординг и системные проблемы целеполагания Жахангир описал кейс: на базовый онбординг ушло 5 месяцев, при этом от него ожидали чудес, которые не смогли сделать предыдущие сотрудники за годы. Даже при хорошем HR-процессе техническая документация практически отсутствует. Системная проблема – нет архитектора, который выстраивает техническое видение. ### Роль тимлида Тимлид – не «универсальный солдат», а полуменеджер, который должен снижать объём личного кодирования и фокусироваться на организационных задачах. Болезнь начинающих тимлидов: попытка кодить как сеньор и одновременно тянуть управленческую нагрузку. Тимлид важен как защитник архитектуры от давления бизнеса и тех, кто навязывает модные технологии. ### Борьба с навязанными решениями (кейс с Jira) Организация с отлаженной self-hosted системой (20+ интеграций) получила приказ мигрировать на Jira. Стратегия противодействия: перевести проблему в экономические метрики (человеко-месяцы, количество интеграций, время провижининга), найти союзников среди пострадавших отделов, фиксировать решения в деловой переписке и не принимать ответственность на себя. ### Open Source в Казахстане Жахангир рассказал об опыте форка Flutter BitTorrent-библиотеки – 790 скачиваний, появились форки. Стратегии продвижения: market research через посты в тематических сообществах (Reddit, Telegram), начало с MVP, готовность принимать помощь, но расчёт только на себя. Прозвучала идея публичной вики по интеграционным форматам казахстанских госсистем. ### Сравнение технологий Личный опыт участников с .NET, C, C#, Flutter, Kotlin. Обсуждение производительности .NET vs C++. Контекст – выбор стека для разных задач и влияние на карьерный путь. ### Студии как бизнес-модель Студии с командами в 40–50 разработчиков вынуждены выстраивать хороший онбординг из-за высокой текучки – служат «трамплином» для джуниоров. Модель «кор-тим + сезонные рабочие» как способ масштабирования. Остальные компании боятся учить людей, хотя стоимость обучения джуна – статистическая погрешность для бюджета. ### Выводы - Джуниоры – системная проблема рынка: Отсутствие инвестиций в начинающих специалистов ведёт к эмиграции и дефициту кадров. Студии вынужденно становятся «трамплином», а остальные компании боятся вкладываться в обучение. - Онбординг – не HR-задача: Техническая документация и архитектурное видение важнее корпоративного welcome-пакета. Без архитектора, который выстраивает целеполагание, новый сотрудник тонет в хаосе. - Тимлид – защитник, а не «универсальный солдат»: Главная ошибка начинающих тимлидов – пытаться кодить как сеньор. Ключевая функция – защита архитектурных решений от бизнес-давления и навязывания модных технологий. - Плохие решения бьют экономикой: Самый эффективный способ бороться с навязанными техническими решениями – переводить проблему в человеко-месяцы и деньги. Документирование и поиск союзников – обязательная часть стратегии. ### Мнения участников - Онбординг 5 месяцев на базовый; нет документации, нет архитектора / HR-онбординг хорош, IT-онбординг – ноль / – - Роль тимлида Защитник архитектуры от бизнес-давления / Полуменеджер, должен снижать объём кодирования / – - Навязанные решения Переводить в экономику, искать союзников, фиксировать в переписке / Не принимать ответственность за чужие решения / – - Open Source MVP + market research через сообщества / – / Универсальный протокол для документов/LLM ### Открытые вопросы - Как эффективно бороться с навязыванием плохих технических решений «сверху»? - Как развивать Open Source сообщество в Казахстане? - Как создать общественную вики по интеграциям с казахстанскими госсистемами? - Универсальный протокол (JSON) для генерации документов (PDF, Word, Excel) для LLM – стоит ли реализовывать? ### Вопросы, закрытые позже - Как правильно инвестировать в онбординг при маленькой команде? (разобрано на meetup-2026-07-01) Участники: Жахангир (Жоха) (DevOps/платформенный инженер, Open Source (Flutter BitTorrent)), Андрей (Организатор, опыт интенсивного программирования), Паша, Григорий Павлович (Open Source проект – универсальный протокол для документов/LLM), Адиль, Вася, Михаил Теги: джуниоры, онбординг, Open Source, тимлид ## Встреча сообщества – 30 апреля 2026 URL: https://teamleads.kz/events/meetup-2026-04-30/ Дата: 2026-04-30 Микросервисы vs монолит, культура незнания в IT, AI-разработка и ревью, долгосрочная архитектура, агентские системы Процессная дисциплина, микросервисы vs монолит, культура сокрытия некомпетентности, AI-разработка и смещение нагрузки на ревью, долгосрочные архитектурные решения и агентские AI-системы. ### Процессная дисциплина: кейс с записью Андрей систематически забывает включать запись встреч. Участники разобрали это как кейс по управлению процессами: были инструкции, было согласие, но привычка не сформировалась. Вася отметил, что изначально не было строгих инструкций с конкретными шагами. Вывод: процесс должен быть максимально простым и привязанным к конкретному действию, а не к абстрактному обязательству. ### IT-сообщества Казахстана Обсуждали ландшафт IT-сообществ: САБА (системные и бизнес-аналитики, ~120 человек), PM Club (закрытое сообщество проектных менеджеров с созвонами раз в две недели), DevOps-группы, чаты архитекторов. Все эти сообщества – части одного большого IT-комьюнити Казахстана, связанные через общих людей и пересекающиеся в разных чатах. ### Микросервисы vs монолит Андрей категоричен: до 50 человек в команде микросервисы не нужны без объективных причин. Модульный монолит дает то же логическое разделение (модули общаются через очереди/gRPC/REST), но без операционных издержек. Микросервисы наказывают за слабые компетенции: сетевые ошибки, рассинхронизация контрактов, сквозная отладка. Деление на сервисы должно отражать деление бизнеса (авторизация, логистика), а не техническое желание. ### Культура сокрытия некомпетентности Самая социально острая тема. В IT принято гнобить за слабые компетенции, поэтому никто не признается в незнании. Команды берут задачи вместо спайков (исследовательских задач), потому что «взять спайк = признать, что не знаешь». Миша подтвердил на примере SAFe-команд. Василий резюмировал: стигматизация незнания заставляет людей брать двойную ответственность (спайк + имплементация) вместо честного разделения этапов. ### Вендорские системы и DevOps Миша рассказал про типичные проблемы: вендоры разворачивают системы в Docker-контейнерах на 32 ГБ оперативки, не умеют работать с Kubernetes, не делают Helm-чарты, используют Persistent Volumes вместо cloud-native подходов. У маленьких команд нет бюджета на DevOps, а своих компетенций не хватает. Итог: «работает – не трогай». ### API-дизайн и Smart Bridge Компания не умела проектировать API – бизнес-аналитики обещали «два поля добавить», в итоге вывалили внутренние API наружу для клиента. Проблема мировая: мало компаний проектируют API с учетом удобства потребителя. Smart Bridge Казахстана – пример плохо документированной системы, где community-driven вики с примерами подключений могла бы сильно помочь следующему поколению разработчиков. ### AI-разработка: смещение нагрузки на ревью Кейс с выступления: AI ускорил написание кода, но багов стало больше, тестеры перегружены, итоговый выигрыш – около 5%. Фокус разработчика сместился с написания кода на ревью. Решение: автоматизация тестирования, линтеры, анализаторы. Андрей добавил: LLM может генерировать «зеленые» тесты, которые ничего не проверяют – нужен человек для оценки тестовой модели на адекватность. ### Долгосрочные архитектурные решения Принцип: откладывай решения как можно позже – это сохраняет гибкость. Аналогия с policymaking: законодатели намеренно не доделывают законы, дают рынку устояться, потом «закручивают гайки» на основе данных. Microsoft закрывает методы как internal на 10 лет и открывает только после статистического подтверждения потребности. Математическое обоснование через теорию вероятности помогает понять, какие риски ты принимаешь. ### AI-агентская архитектура Павел рассказал про подход: маленькие специализированные агенты на слабых моделях, оркестратор координирует. Линейная архитектура не работает – нужна обратная связь, когда саб-агенты сталкиваются с проблемами. Важно разделять планер (составляет план) и оркестратор (координирует исполнение). Anthropic Claude Code Architect Certification – источник паттернов оркестрации. ### Выводы - Микросервисы vs монолит: До 50 человек микросервисы не оправданы без объективных причин. Монолит устойчивее к слабым компетенциям. Деление на сервисы должно отражать деление бизнеса, а не техническую моду. - Культура честности: Стигматизация незнания приводит к отказу от спайков, сокрытию проблем и избыточным техническим решениям. Спайк – нормальный инструмент, а не признание слабости. - AI и ревью кода: AI ускоряет написание, но бремя качества переходит на ревью. Нужна инфраструктура: автотесты, линтеры, верификация тестовых моделей. Зеленые тесты ≠ правильные тесты. - Долгосрочная архитектура: Принимай решения как можно позже, решай только известные задачи, оставляй место для неизвестного. Математическое обоснование тестирования помогает принимать осознанные решения о рисках. - Агентские AI-системы: Маленькие специализированные агенты на слабых моделях с оркестратором – перспективное направление. Линейная архитектура не работает, нужна обратная связь и разделение планера и оркестратора. ### Мнения участников - Микросервисы Не раньше 50 человек, модульный монолит / Модулями можно делить, не обязательно сервисами / Вендоры не тянут даже Docker нормально - Культура незнания Отраслевая проблема, люди боятся признаваться / Следствие стигматизации, надо разделять этапы / Команды поддаются давлению бизнес-оунеров - AI в разработке Статический анализ не спасает от логических ошибок / – / 5% выигрыш, нагрузка на ревью - Архитектурные решения Откладывай как можно позже, policymaking / – / – ### Вопросы, закрытые позже - Воспитание джунов (тема Валихана, не успели обсудить) (разобрано на meetup-2026-05-07) - Агентская AI-архитектура: паттерны оркестрации, планер vs оркестратор (разобрано на meetup-2026-07-08) - Математическое обоснование тестирования и архитектуры (разобрано на meetup-2026-07-08) - Smart Bridge Казахстана и community-driven документация (разобрано на meetup-2026-05-07) Участники: Андрей (Организатор (Франция), процессная дисциплина и архитектура), Василий (IT-комьюнити Казахстана, vendor DevOps), Миша (Микросервисы vs монолит, API-дизайн), Павел (L-Star Unit, AI-агенты), Валихан, Ян Теги: микросервисы, культура, AI-агенты, архитектура ## Встреча сообщества – 23 апреля 2026 URL: https://teamleads.kz/events/meetup-2026-04-23/ Дата: 2026-04-23 Бюрократия в IT, change management, ITIL, документация процессов, критика Scrum, постмортемы и итеративное улучшение Бюрократия как инструмент управления: от ISO-сертификации и ITIL до тест-планов, постмортемов и итеративного улучшения процессов в IT-командах разного масштаба. ### Бюрократия как недооцененный инструмент управления Андрей раскрыл главный тезис встречи: бюрократия в IT недооценена разработчиками. Речь идет о формализации процессов – описании того, как компания на самом деле работает. ISO-сертификация, CMMI и подобные фреймворки заставляют договориться о единообразном подходе к работе. Бюрократия сопротивляется хаотичным изменениям, что парадоксально полезно: однажды зафиксированный процесс трудно сломать, и это создает стабильность для измерений – velocity, длительности задач, регрессионного тестирования. Без стабильного процесса все метрики становятся хрупкими и бессмысленными. ### Измерение рабочего времени: польза и ограничения Участники обсудили эксперимент с записью времени на задачи в рамках спринта. Один из участников рассказал, как команда добровольно фиксировала затраты времени для ретроспективы, чтобы найти узкие места. Андрей подтвердил, что замеры времени – инструмент наблюдательный, а не управленческий: их нельзя использовать для оценки эффективности, но они помогают выявить скрытые проблемы – например, блокирующий VPN, тормозящую внешнюю команду или неочевидные преграды, которые люди не озвучивают. Важно смотреть не через призму эффективности, а через призму «что работает, а что нет». ### Критика книги Сазерленда про Scrum Валентин поделился впечатлениями от аудиокниги Сазерленда. Книга воюет с waterfall – что было актуально для 80-х годов, но звучит как «соломенное пугало» сегодня. Сазерленд позиционирует Scrum как универсальную формулу, применимую к любому виду деятельности и ускоряющую работу в 10 раз, что противоречит реальному опыту сообщества. Участники неоднократно обсуждали границы применимости Scrum: часто отказ от полного следования Scrum – это признак того, что он не нужен в данных условиях. Интересный момент из книги – исследование студентов-отличников: одни справляются быстро, другие тратят неделю на ту же оценку, что показывает независимость квалификации от скорости. ### Диаграмма Ганта и waterfall: реабилитация инструментов Миша выступил с контрпозицией к анти-waterfall нарративу. Его опыт в системной интеграции показывает, что диаграммы Ганта – рабочий инструмент для проектов с физической составляющей: монтаж ЦОД, установка серверов, прокладка сетей. Там четкая последовательность: нет ЦОД – нет стойки, нет стойки – нет сервера. Backlog и Jira бессмысленны в таком контексте. Microsoft Project – основной инструмент, а не Jira. Даже в смешанных проектах с разработкой (один разработчик на прошивку или SharePoint-портал) диаграмма Ганта работала отлично. Все используют метод набегающей волны – крупноблочное планирование далеких этапов с детализацией ближних. ### Change Management: градиентный подход Андрей провел глубокую аналогию change management с рефакторингом и градиентным спуском. Люди начинают менять процессы либо на эмоциональном подъеме (увидели, как круто у других), либо от страха после крупного провала – обе ситуации нездоровые для принятия решений. Рациональный подход – итеративное улучшение: берешь один проблемный отдел, лечишь только его, наблюдаешь последствия. Как в рефакторинге – меняя одну маленькую часть, ты знаешь, что именно вызвало проблему. Гигантский рефакторинг всего и вся приведет к непредсказуемым поломкам. Вера в счастливое будущее – самое опасное при change management. ### Документация: легитимизация работы и тактическое применение Обсуждалась статья о том, как бюрократия делает работу видимой. Исторический пример: в Германии 200 лет назад ввели учет срубленных деревьев – работа стала медленнее, но прогнозирование улучшилось, потому что инспекторы могли объективно оценить прогресс. Документация процессов помогает новым сотрудникам – это «интересное чтиво», описывающее входы, выходы, стейт-машины. Андрей предложил тактический подход к документации: не all-in, а ситуативно. Пример – техника «это есть в вики»: валидируешь запрос (если человек вернулся – пишешь статью), таким образом органически наращивая базу знаний без отдельного проекта документирования. ### Постмортемы, отпуска и заменяемость Бюрократия обеспечивает заменяемость людей – а значит, возможность уходить в отпуск. Отпуск руководителя – лакмусовая бумажка: может ли команда прожить три недели без пожара? Бек рассказал про кейс, когда вместо постмортемов писали объяснительные, а команда могла уйти в отпуск только после того, как натренировала нового сотрудника (6 месяцев). Андрей подчеркнул: незаменимость – это зло, и достаточно один раз уйти с позиции незаменимого, чтобы понять, что все будет нормально. Плоды документирования приходят через полгода, но начинают работать достаточно быстро. ### Итеративное улучшение: тесты и рефакторинг Андрей настаивал на том, что тестирование и рефакторинг – это часть разработки, а не отдельная активность. Он всегда закладывал их в стоимость работы. Тест-план – пример полезной бюрократии, о которой забыли в эпоху agile: это способ подумать, как проверить, что спецификация будет работать. Для Legacy-проектов без тестов работает итеративный подход: нашел место – написал тест, сделал маленький рефакторинг. Через полгода уже есть покрытие. В анархических организациях это даже проще – тебе позволят написать что угодно. ### Выводы - Бюрократия стабилизирует метрики: Формализация процессов сопротивляется хаотичным изменениям, что делает метрики (velocity, длительность задач) осмысленными. Без стабильного процесса измерения бесполезны – вы будете «угадывать, как оно есть». Перебрасывание людей между задачами и проектами уничтожает возможность замерить длительность любого отдельного процесса. - Change management = итеративный рефакторинг: Не пытайтесь менять всю организацию сразу. Берите один проблемный участок, лечите его, наблюдайте результат. Решения на эмоциях (восторг от чужого опыта или страх после провала) приводят к плохим результатам. Двигайтесь по градиенту – туда, где максимальный эффект при минимальном риске. - Документация решает тактические задачи: Не нужен all-in подход к документированию. Техника «это есть в вики» позволяет валидировать запросы и органически наращивать базу знаний. Каждый ответ на повторяющийся вопрос становится статьей. Через полгода у вас уже есть рабочая база, покрывающая реальные потребности. - Незаменимость – зло, а отпуск – лакмусовая бумажка: Если команда не может прожить три недели без лида – процессы не настроены. Документирование и формализация делают людей заменяемыми, а значит – свободными уходить в отпуск. Плоды приходят через полгода, но это ничто для долгоживущих проектов. - Инструменты не бывают универсальными: Диаграммы Ганта работают в системной интеграции, Scrum – в продуктовой разработке определенного масштаба. Догматичное следование любой методологии вредно. Границы применимости определяются контекстом: размер команды, тип проекта, физический или цифровой продукт. ### Мнения участников - Бюрократия в IT Недооценена, помогает стабилизировать процессы и метрики / Рабочий инструмент, особенно в системной интеграции / Нужна, но в маленьких компаниях ее обычно нет - Измерение времени Наблюдательный инструмент, не для оценки эффективности / – / – - Scrum и waterfall Scrum имеет границы применимости, догматизм вреден / Waterfall и Гант работают для физических проектов / – - Change management Маленькие итерации, как рефакторинг – не все сразу / – / – - Документация и онбординг Тактический подход, техника «это есть в вики» / – / Без документации команда не может уйти в отпуск, пока не обучит замену - Постмортемы Инцидент-менеджмент возможен и в маленьких компаниях / – / В маленьких компаниях вместо постмортемов – объяснительные ### Открытые вопросы - Как внедрять процессы в маленьких компаниях с ограниченным бюджетом - Релизная бюрократия: контролируемые релизы vs непрерывная поставка - Роль IT-сообществ в развитии культуры процессов в Казахстане - Техническая контент-стратегия для средних компаний - Грейдирование и центры компетенций: внутри компании vs в комьюнити ### Вопросы, закрытые позже - Тест-планы в эпоху agile: забытый инструмент или устаревший артефакт (разобрано на meetup-2026-07-15) Участники: Андрей (Организатор, опыт ISO-сертификации, change management), Миша (PM в системной интеграции, диаграммы Ганта, Microsoft Project), Валентин (Критика книги Сазерленда про Scrum), Жабек (Знакомство с CMMI), Бек (Опыт в небольших компаниях, постмортемы и отпуска), Адиль, Артур (Упоминается как измеритель рабочего времени (отсутствовал)) Теги: бюрократия, процессы, Scrum, документация ## Встреча сообщества – 12 апреля 2026 URL: https://teamleads.kz/events/meetup-2026-04-12/ Дата: 2026-04-12 Увольнения в IT: формальные аспекты, PIP, политические игры, обучение тимлидов, аналитика и ИИ Увольнения в IT: как увольнять сотрудников, как переживать собственное увольнение, роль тимлида в процессе увольнения, политические игры в компаниях, обучение управленцев и влияние ИИ на рынок труда. ### Формальные аспекты увольнения и трудовое законодательство Василий поднял проблему увольнения сотрудника, который требует формального грейдинга в соответствии с законодательством. Андрей объяснил, что грейдинг не является обязательным – можно уволить за несоответствие должностным обязанностям, для чего нужно эти обязанности формально зафиксировать. Обсуждались тактики: внутренняя реструктуризация, изменение штатного расписания. Часто сотрудник, играющий в бюрократические игры, просто хочет денежную компенсацию. ### PIP, испытательный срок и культура увольнения Участники обсуждали Performance Improvement Plan как инструмент подготовки к увольнению. Андрей увольнял только после исчерпания всех попыток обучения сотрудника. Василий подчеркнул важность испытательного срока: трёх месяцев достаточно, чтобы понять совместимость. Несоответствие может быть обоюдным: не только сотрудник не подходит компании, но и компания может не подходить сотруднику. ### Эмоциональная сторона увольнения Сэм и другие участники обсудили психологический аспект. Не стоит верить всему, что говорит работодатель при увольнении – он может манипулировать для самооправдания. Увольнение не всегда связано с некомпетентностью – часто это вопрос бюджетов или стратегии. Практические советы: откладывать деньги, постоянно быть в поиске, контрибьютить в open source для портфолио. ### Должен ли тимлид уметь увольнять Мнение группы: да, это часть обязанностей. У тимлидов нет градации джун/мидл/сеньор, к ним сразу предъявляются требования опытных управленцев. Андрей сравнил тимлида с «джун-менеджером» – их нужно обучать и сопровождать. Более половины новых тимлидов откатываются обратно в разработку, часто из-за стрессовых ситуаций вроде увольнения. ### Политические игры в компаниях Алихан рассказал два кейса попыток инициировать увольнение CTO – оба раза был уволен сам. Андрей систематизировал механику: рычаг, союзники, подготовка почвы. Главный вывод – в политических играх проигрываешь, как только начинаешь играть. Тебя могут использовать как «расходный материал» в чужих торгах. Альтернативы: бюрократическая защита, параллельный проект, смена компании. ### Аналитика в казахстанских компаниях Алихан описал попытку внедрить аналитику в компании, где решения принимаются на основе догадок. Василий и Андрей сошлись: проблема в неумении людей работать с данными – даже имея метрики, люди ищут подтверждение своих идей. Андрей привёл пример из букмекерского бизнеса, где убыточность точек игнорировалась ради иллюзии «развития». Метрики – advanced level, работающий только при налаженных базовых процессах. ### Обучение управленцев и решение конфликтов Системного обучения тимлидов в Казахстане практически нет. Андрей учился через неформальное менторство. Предложено организовать бизнес-игры внутри сообщества: разбор кейсов группами по 4-5 человек с ревью от более опытного участника. Также обсуждалась управленческая борьба как формат и питчинг инициатив перед руководством. ### ИИ в разработке и изменение рынка труда Знакомые участников не могут найти работу на React уже месяц. В Европе и Москве появляются вакансии «вайб-кодеров». Один из участников месяц не пишет код вручную. Андрей-скептик: ИИ пишет много кода «про запас», противоречит принципу минимального кода. Но для бойлерплейта и инфраструктурных слоёв ИИ экономит время. ### Выводы - Формализация – ключ к здоровому увольнению: Чёткие должностные обязанности, прозрачные критерии испытательного срока и PIP позволяют сотруднику самому понять, тянет он или нет. Это снижает эмоциональную нагрузку и минимизирует юридические риски. - Тимлиды нуждаются в обучении управлению: Их назначают из лучших разработчиков и ожидают, что они сами разберутся. Более половины откатываются в разработку после первого негативного опыта. Необходимо менторство и групповые разборы кейсов. - Политические игры – проигрышная стратегия: Попытки сместить руководство через политическое давление крайне рискованны. Безопасные стратегии: бюрократическая защита, параллельные зоны влияния или смена компании. - Увольнение – часть профессиональной жизни: Важно деперсонализировать увольнение: это бизнес-решение, не приговор. Финансовая подушка, готовность к собеседованиям и open source контрибьюции – практическая страховка. ### Мнения участников - Процесс увольнения Формализовать ожидания, исчерпать попытки обучения / Испытательный срок – главный фильтр / – / Это бизнес, не принимать на свой счёт - Политические игры Начав играть – уже проиграл; защита через бюрократию / – / Иногда необходимы для смещения некомпетентных / – - Аналитика Метрики – advanced level, без базовых процессов бесполезны / Люди не умеют работать с данными / Необходима для решений на основе данных / – - ИИ в разработке Скептик: много лишнего кода; полезен для бойлерплейта / – / – / – ### Открытые вопросы - Конфликт поколений в управлении – «молодёжь против стариков» - Конфликты в команде и между командами – как входить и выходить без ущерба ### Вопросы, закрытые позже - ИИ в разработке – практический опыт, вайб-кодинг как новая компетенция (разобрано на meetup-2026-05-14) - Бизнес-игры – групповые разборы управленческих ситуаций внутри сообщества (разобрано на meetup-2026-06-17) - Как тимлиду не сломаться – менторство и предотвращение «отката» в разработку (разобрано на meetup-2026-05-07) Участники: Андрей (Организатор (Франция), опыт увольнений с обеих сторон), Василий (Инициатор темы, недавно ушёл из InDrive), Алихан (7-8 лет опыта, дважды уволен за попытки сместить CTO), Сэм (Деперсонализация отношений с работодателем), Алибек, Павел (Опыт увольнений в контексте ramp-down), Александр (Конфронтация с директорами, заказной технический аудит) Теги: увольнения, PIP, политика, управление ## Встреча сообщества – 26 марта 2026 URL: https://teamleads.kz/events/meetup-2026-03-26/ Дата: 2026-03-26 Нормирование труда в IT: метрики продуктивности, миф о творческой профессии, декомпозиция задач, PanDev Нормирование труда в IT: применимость промышленных метрик к разработке, системы измерения продуктивности, миф о «творческой профессии», декомпозиция задач и баланс между предсказуемостью и эффективностью. ### Определение нормирования труда Участники начали с того, что плавают в терминологии, и загуглили определение: нормирование – процесс измерения затрат труда на единицу изделия. Андрей подчеркнул: это инструмент планирования, а не контроля. Нормирование работает при повторяемости процессов и имеет смысл только в контексте конкретной компании. ### Применимость нормирования к IT Ключевая дискуссия. Андрей: проблема не в уникальности IT-задач, а в порочной бизнес-модели – только 20-30% работы реально уникальны, остальное типовое (авторизация, формы, интеграции). Артур возражал: даже типовая задача в контексте разных архитектур имеет нюансы, разброс сложности гигантский. Андрей парировал: крупные компании имеют и нормы, и инновации одновременно. ### «Программирование – не творческая профессия» Самый эмоциональный тезис встречи. Дизайнеры – творческая профессия, но знают свои нормы. Писатели имеют нормы страниц в день. Андрей: «Ты надеваешь шапку творца, чтобы избавиться от ответственности, и одновременно требуешь четких ТЗ – это лицемерие». Эдельбек согласился: за всю карьеру по пальцам пересчитать случаи реально нового. Большинство решений шаблонизированы. ### Нормы в других IT-дисциплинах Тестировщики нормируются (полный регресс = 12 часов – измеримо), дизайнеры нормируются (знают выработку по экранам), на собеседованиях норма – 2 задачи за час. Только разработчики «сопротивляются». На галерах работает норма «один тикет в день» при атомарной декомпозиции. Андрей: дизайнеры как профессия организованнее программистов, потому что их заработок зависит от выработки. ### Система метрик PanDev Артур рассказал про PanDev – систему трекинга продуктивности. Четыре показателя: Delivery Index (процент времени, дошедшего до merge requests), точность планирования (план vs факт), количество задач, КПД merge request (процент файлов, попавших в итоговый MR). Олег поделился проблемами: не трекается работа в нескольких IDE, проблемы с VPN. Андрей критиковал: это метрики процесса, а не результата. ### Декомпозиция: атомарность vs эффективность Артур: опытный фронтендер оценил рефакторинг в 8 дней, ушел и вернулся с готовым результатом – зачем дробить? Андрей: если задача большая и неделимая – это сигнал отсутствия экспертизы, нужен пилот. Василий резюмировал: мы меняем эффективность на предсказуемость и управляемость – это сознательный компромисс. Без предсказуемости бизнес зависит от героизма. ### Стартапы и нормирование Артур признал: давление стартапа приводит к сокращению углов. Андрей процитировал: «Если у вас в стартапе нет планирования, проблема не в стартапе, а в плохом управлении». Нормирование позволяет не зависеть от «героических» сотрудников. Без нормирования нельзя «самоустраниться» из бизнеса – он останется лайфстайл-проектом. ### Острова экспертизы и интеграции Вместо того чтобы каждая компания делала интеграции с нуля, нужны специалисты по конкретным доменам (платежные системы, авторизация). Проблема: нет образовательных материалов по типовым интеграциям. Знания в индустрии есть, но все утверждают, что «нужно изучать с нуля, документации нет». Образовательная сфера не покрывает этот запрос. ### Выводы - Нормирование возможно: Нормирование – инструмент планирования, не погонщик с барабаном. Дизайнеры и тестировщики нормируются давно. Проблема не в IT как отрасли, а в нежелании менеджмента управлять рисками. - Уникальность преувеличена: 80% работы типовая: формы, интеграции, CRUD, авторизация. «Уникальный продукт» часто прикрывает отсутствие процессов. Крупные компании совмещают нормы и инновации. - Процесс vs результат: Часы кодинга – метрика процесса. Delivery Index (код, дошедший до production) ближе к результату. Идеал – комбинация усилий, результата и точности планирования. - Предсказуемость vs эффективность: Атомарная декомпозиция повышает предсказуемость за счет эффективности – время на планирование. Без предсказуемости бизнес зависит от героизма, а это не масштабируется. ### Мнения участников - Нужно ли нормирование? Однозначно да, инструмент планирования / Да, но 4 часа кодинга – достаточная метрика / Нужно, но непонятно как - Творческая профессия? Категорически нет, это уход от ответственности / Творчество – в проектировании, не в коде / Большинство решений шаблонизированы - Атомарная декомпозиция? Да, крупные задачи – сигнал отсутствия экспертизы / Не всегда, 8 дней на рефакторинг – нормально / Компромисс: эффективность vs предсказуемость - Метрики? Нужны метрики результата, не процесса / PanDev: delivery index + точность планирования / Оценка по связям сущностей ### Открытые вопросы - Нормирование по связям сущностей – идея Василия для статьи на Reddit - Как соотносятся метрики PanDev с реальной продуктивностью на длинной дистанции ### Вопросы, закрытые позже - Увольнение – тема, которую отложили на следующий раз (разобрано на meetup-2026-04-12) - «Острова экспертизы» и образовательные материалы по типовым интеграциям (разобрано на meetup-2026-05-07) Участники: Андрей (Организатор (Франция), защитник нормирования), Артур (Норма «4 часа кодинга в день», клиент PanDev, опыт стартапа), Василий (Инициатор темы, оценка по связям сущностей), Эдельбек, Олег, Данил Теги: нормирование, метрики, декомпозиция, процессы ## Встреча сообщества – 19 марта 2026 URL: https://teamleads.kz/events/meetup-2026-03-19/ Дата: 2026-03-19 Продажа технологий, рефакторинг как бизнес-решение, разработчик → продукт, AI в разработке Продажа технологий внутри компаний, рефакторинг как бизнес-решение, эволюция роли разработчика в сторону продуктового мышления и принятие технических решений через вовлечение команды. ### Продажа новых технологий внутри компаний Андрей рассказал кейс миграции с FoxPro на C# на заводе (~2005). Ключевая техника: не продавать технологию напрямую, а показать людям личную выгоду. Этапы: найти мотивированное ядро («пиратов»), обучить их, они становятся амбассадорами. Страх увольнения – главный блокер, устраняется личной поддержкой и демонстрацией. Политические союзы – неизбежная часть процесса. Трансформация заняла полгода-год. ### Авторитет CTO и продажа решений через эмоции Артур: в Yumika (азербайджанский маркетплейс) компания не могла решить, как переписать веб. Артур предложил WebView (как у Kaspi) – за три дня вся компания изменила направление. Два фактора: личный опыт CTO + авторитет эксперта. Андрей: авторитетные решения неизбежны, но важна прозрачность – кто-то берет на себя ответственность, вопрос в том, прикрываешь ли ты это «демократией». ### Рефакторинг: инфраструктурный vs бизнесовый Два вида рефакторинга. Инфраструктурный – зона ответственности разработчика, не требует одобрения бизнеса. Бизнесовый – изменение доменной модели, требует коммуникации. Андрей: два коммита (рефакторинг + фича) в одном тикете. Артур рассказал фейл с модулем Surge (динамическое ценообразование) – отказался от рефакторинга из-за корпоративного мышления и оценок в часах. ### Принятие решений через вовлечение команды Техника дебатов: один аргументирует «за», другой «против», остальные формируют мнение. Повышает вовлеченность, создает разностороннее видение, снижает bus factor. Для этого нужна среда доверия – люди должны не бояться высказываться. Доверие не появляется само, его нужно тренировать. Сильные люди в команде держат лидера под контролем. ### Разработчик → продукт: эволюция роли AI размывает границу между разработчиком и продактом. Инженер с бизнес-пониманием ценнее сильного кодера без контекста. Артур конвертирует разработчиков в продактов – техническая часть обучения уже пройдена. Андрей скептичен: нельзя быть и программистом, и продактом одновременно – придется чем-то пожертвовать. Продакт, научившийся кодить, к кодовой базе не допустят. ### AI в разработке: текущие реалии Андрей: AI хорошо работает для разовых результатов, плохо для поддерживаемого кода. Гипотеза: моделировать бизнес-процессы как отдельных агентов Claude Code. Павел рекомендовал Opus для рефакторинга: сначала покрыть тестами, потом рефакторить. Общее мнение: AI расширяет возможности, нужно учиться пока доступно – стоимость инференса может вырасти. ### Выводы - Продажа технологий – социальный процесс: Технологии продаются через устранение страхов, обучение и демонстрацию личной выгоды. Политические союзы и амбассадоры из мотивированного ядра – рабочая схема. - Рефакторинг – зона инженера: Инфраструктурный рефакторинг не требует одобрения бизнеса. Бизнесовый – требует коммуникации. Лучше делать в связке с фичей, а не отдельным тикетом. - Вовлечение команды: Техника дебатов повышает качество решений. Среда доверия – обязательное условие. Сильные люди держат лидера под контролем и компенсируют предвзятость. - Эволюция роли разработчика: Спрос смещается к инженерам с бизнес-пониманием. AI снижает ценность чистого кодинга. Конвертация разработчиков в продактов эффективнее, чем наоборот. ### Мнения участников - Продажа технологий Через обучение и политические союзы / Авторитет CTO + эмоции / – - Рефакторинг Два коммита, один тикет, не выклянчивать / Фейл: отказ от рефакторинга из-за корпоративного мышления / – - Разработчик → продукт Скептичен, нельзя быть и тем и другим / Конвертирует разработчиков в продактов / AI размывает грань, спрос на бизнес-инженеров - AI в разработке Для разовых задач – да, для поддержки – нет / AI-first, расширяет возможности / Инженер без бизнес-контекста теряет ценность ### Вопросы, закрытые позже - Увольнение – тема, которую снова отложили (разобрано на meetup-2026-04-12) - Как системно конвертировать разработчиков в продактов (разобрано на meetup-2026-06-24) - AI-агенты как бизнес-процессы: практический опыт (разобрано на meetup-2026-04-30) - Нормирование труда в IT (разобрано на meetup-2026-03-26) Участники: Андрей (Организатор (Франция), продажа технологий через обучение и политические союзы), Артур (CTO стартапа, кейс WebView в Yumika), Сергей (Рост разработчиков в сторону продуктового мышления), Денис, Павел (L-Star Unit) Теги: продажи, рефакторинг, продукт, AI ## Встреча сообщества – 12 марта 2026 URL: https://teamleads.kz/events/meetup-2026-03-12/ Дата: 2026-03-12 Эстимация задач, микроменеджмент, карьерные стратегии, токсичность и рынок труда Эстимация задач (часы vs Story Points vs No Estimate), микроменеджмент и его влияние на команды, карьерные стратегии в токсичной среде, поиск работы в Казахстане. ### Эстимация: часы vs. «попугаи» (Story Points) Павел рассказал об опыте работы в стартапе, где все задачи оценивались строго в часах. Это создавало стресс и иллюзию контроля у менеджеров, приводило к переработкам. Story Points тоже условны и уникальны для каждой команды – их изобретатель написал статью «Story Points Revisited», где извинился за искажение концепции. Подход No Estimate предлагает начинать работу сразу – это даёт более реалистичное представление о сложности. Упоминался No Estimate Game, проводившийся в Алматы. ### Три ситуации оценки работы Участники выделили три контекста: фрилансер/отдельный разработчик, купленная на спринт команда (утилизация) и кросс-функциональная команда с дроблением работы. Чистый Scrum полезен для таймбоксинга, но не нужен, если характер работы этого не требует. Василий задавал вопросы о применимости Scrum на проектах с фиксированными сроками и бюджетами – во многих случаях церемонии соблюдаются ради церемоний. ### Микроменеджмент: природа и причины Микроменеджмент чаще всего возникает из-за потери контроля менеджером, проблем с бюджетированием или как попытка залатать дырявые процессы. Как краткосрочный инструмент в кризисе (аврал, инцидент-менеджмент) – это рабочая техника. В постоянном режиме он разрушает команду и приводит к выгоранию. Михаил предлагал рассматривать микроменеджмент с позиции команды, а не индивидуума. Упоминался «чайка-менеджмент» как отдельный антипаттерн. ### Влияние микроменеджмента на инновационность Алихан поднял проблему: микроменеджмент убивает возможность свободного ресёрча и экспериментов. Когда на каждое действие нужно заводить задачу через системного аналитика, инновационность падает до нуля. Даже демонстрация реальных результатов (самостоятельная разработка нативного мобильного приложения) может быть воспринята негативно – CTO не оценил инициативу. ### Стратегии борьбы с микроменеджментом Участники предложили несколько путей: «размазать» время (предпринимательство внутри компании), создание коалиций и поиск союзников, карьерный рост для получения рычагов влияния. Большинство сошлись: пытаться изменить крупную организацию снизу крайне сложно, и зачастую уход остаётся наиболее рациональным решением. ### Токсичность и коммуникация Обсуждалась тонкая грань между полезной инициативой и восприятием человека как токсичного. Алихан задал вопрос о «синдроме самозванца наоборот» – когда не понимаешь, ты дурак или просто в неправильной среде. Участники рекомендовали искать «своих» людей и среду, где ценности совпадают. Обсуждались эхо-камеры и важность экологичной коммуникации. ### Виртуальный офис и контроль Приведены примеры из практики: виртуальный офис в Discord со штрафами за неактивность, внутрикорпоративный стартап с ежедневными отчётами. Эти кейсы иллюстрировали крайние формы микроменеджмента и то, как контроль ради контроля убивает мотивацию. ### Поиск работы и рынок труда Обсуждение перешло к рынку труда в Казахстане и СНГ. Нетворкинг работает лучше HH, собеседование – отдельный навык, требующий тренировки. Обсуждались ATS-фильтры и проблемы платформ. Упоминались компании DatArt, EPAM, Anderson, Береке Банк – с разными оценками культуры и процессов. ### Выводы - Эстимация – инструмент, а не цель: Часы создают иллюзию контроля, Story Points условны и уникальны для каждой команды. Подход No Estimate предлагает фокусироваться на работе, а не на её оценке. Важно выбирать метод под контекст: фриланс, купленная команда или кросс-функциональная разработка. - Микроменеджмент – симптом, а не причина: За микроменеджментом обычно стоит потеря контроля, бюджетные ограничения или незрелые процессы. Как антикризисный инструмент он работает, но в постоянном режиме разрушает команду и убивает инновационность. - Уход – валидная стратегия: Менять крупную организацию снизу крайне сложно. Создание коалиций и карьерный рост помогают, но зачастую уход остаётся самым рациональным решением. Нетворкинг и постоянная готовность к собеседованиям – практическая страховка. - Ищи свою среду: Грань между инициативностью и токсичностью определяется средой. «Синдром самозванца наоборот» – это сигнал, что среда не подходит. Вместо попыток изменить культуру эффективнее найти команду с совпадающими ценностями. ### Мнения участников - Эстимация Часы создают стресс и иллюзию контроля / За оценки в часах, Scrum на фиксированных бюджетах / – / – - Микроменеджмент – / – / Смотреть с позиции команды, не индивидуума / Убивает инновационность, нужны свободные зоны - Карьерная стратегия – / – / – / Рост внутри vs уход – зависит от среды - Токсичность – / – / – / «Синдром самозванца наоборот» – ищи своих ### Открытые вопросы - Как микроменеджмент влияет на развитие команды в целом (не только на инновационность)? - Как правильно проводить собеседования на позицию руководителя, чтобы распознать микроменеджера? ### Вопросы, закрытые позже - Как измерять корреляцию между Story Points и фактическим временем выполнения задач (на реальных данных из Jira)? (разобрано на meetup-2026-07-01) - Нормирование работы – где проходит граница между нормируемой (CRUD, API) и творческой частью? (разобрано на meetup-2026-03-26) - Как внедрять процессные изменения, не имея формальной власти? (разобрано на meetup-2026-04-23) - Баланс между терпением ради карьерного роста и риском «просолиться» в корпоративной культуре (разобрано на meetup-2026-04-12) Участники: Павел (Разработчик, опыт в стартапе с часовыми эстимациями), Михаил (Опыт в системной интеграции), Василий (Вопросы о Scrum и фиксированных бюджетах), Алихан (Тех лид, крупная компания с тяжёлыми процессами), Александр, Нуркен, Денис, Никита (Береке Банк, центр компетенций), Евгений Степченко (Соорганизатор No Estimate Game в Алматы) Теги: эстимация, микроменеджмент, карьера, рынок труда ## Встреча сообщества – 5 марта 2026 URL: https://teamleads.kz/events/meetup-2026-03-05/ Дата: 2026-03-05 Блокчейн vs. централизованные решения, продажа технологий бизнесу, карьерный рост и эффективность процессов Как продавать блокчейн-решение для защиты от двойного факторинга (double invoice cashing) реальному бизнесу, который изначально не заинтересован в блокчейне. ### Блокчейн vs. централизованное решение Денис предложил использовать блокчейн и zero-knowledge proof для защиты от двойного обналичивания инвойсов. Андрей поставил под сомнение необходимость блокчейна – ту же задачу можно решить централизованной базой данных с межотраслевым соглашением. Денис возражал, что блокчейн убирает vendor lock-in и не требует доверия к центральному оператору. ### Как продавать технологию бизнесу Главный вывод дискуссии: бизнесу не нужен блокчейн как таковой, ему нужно решение конкретной проблемы. Слова «блокчейн» и «zero-knowledge proof» отпугивают и вызывают недоверие. Нужно приходить с конкретным предложением: «я сэкономлю вам X% на проверке инвойсов», а технические детали раскрывать только по запросу. ### Проблема перехода на криптовалюту (USDT) Денис настаивал, что для работы системы все транзакции должны проходить в криптовалюте на блокчейне. Андрей и Стас категорически не согласились – нельзя требовать от бизнеса полного отказа от фиата. Нужно предлагать параллельную систему: часть транзакций в крипте с более выгодными условиями, часть остается как есть. ### Учет интересов всех участников системы Стас подчеркнул, что Денис думает только о своей технологии, но не учитывает интересы всех сторон: покупателей долгов, продавцов долгов, конечных клиентов. Если для клиентов вырастет эффективная комиссия (например, из-за стоимости обнала крипты), система не взлетит. ### Карьерный рост и эффективность процессов Рома описал типичную проблему: компания на 200 человек, процессы неэффективны, бюрократия, отчеты в никуда, документация разбросана. Руководство не хочет менять процессы, пока есть ежегодный рост. Стас дал три ключевых мысли о карьерном росте. ### Выводы - Продажа блокчейн-решения: Убрать слова «блокчейн» и «zero-knowledge proof» из презентации. Продавать решение конкретной бизнес-проблемы, а не технологию. - Стратегия выхода на рынок: Не пытаться заменить всю систему сразу. Начинать с малого: предложить более выгодные условия для транзакций в крипте, оставив старую систему работать параллельно. - Бизнес-модель: Денис занимается не продажей технологии, а построением стартапа. Нужно идти к существующим факторинговым компаниям и помогать решать их текущие проблемы. - Карьерный рост: Растут не самые умные, а те, кому доверяют. Руководитель может тормозить рост хорошего специалиста. Нужно четко понять, чего именно ты хочешь. - Эффективность процессов: Проблема неэффективности типична для компаний от 70-100 человек. Неэффективность – это часто плата за масштаб. Тему решили вынести в отдельную встречу. ### Мнения участников - Нужен ли блокчейн? Да, убирает vendor lock-in / Нет, межотраслевое соглашение решает задачу / Технология вторична, важно решение проблемы - Все транзакции в крипте? Да, иначе система не работает / Нет, начинать с части транзакций / Нет, нельзя ломать существующий бизнес - Параноидальное недоверие оправдано? Да, зачем рисковать / Нет, люди доверяют друг другу / Бизнесу нужно решение, а не идеология - Роль комплаенса Решается прозрачностью блокчейна / Нужно учитывать стоимость рисков / Если не позволяет обнал – бизнесу не нужна Участники: Денис (Автор идеи блокчейн-решения для факторинга), Андрей (Организатор, инженерный менеджер), Стас (Microsoft (Эстония), лидер Project KZ), Олег, Рома (Карьерный рост и эффективность процессов) Теги: блокчейн, факторинг, карьера, процессы --- # Инсайты из чата Ключевые идеи и знания из обсуждений в Telegram-сообществе «Тимлид не кодит» ## Понимание не равно чтению кода, спека без единого определения и менеджер, который не увольняет URL: https://teamleads.kz/insights/week-2026-09-28/ Дата: 2026-10-04 Неделя про ревью PR на 20 000 строк, разное понимание SDD, свои маленькие модели, нерешительного менеджера, Kafka против RabbitMQ и цену работы ИИ ### Понимание не равно чтению кода: спор о PR на 20 000 строк Все началось с новости Gartner: к 2028 году расходы на LLM превысят среднюю зарплату разработчика. Станислав заметил, что зато вырастет скорость выпуска фич, Азат уточнил – скорость написания строк и открытия PR, продуктивность по-прежнему меряют не тем. Станислав пошел дальше: PR как сущность должен уйти. Андрей возразил одной фразой, вокруг которой и крутилась вся неделя: PR – это единица понимания, а понимание своей деятельности нельзя аутсорсить. Ответ Станислава был не менее коротким: понимание не равно чтению кода. Поводом стал пост в LinkedIn, где автор отказался ревьюить пулреквест на 20 000 строк и попросил не присылать больше 1 000. LSTR увидел в этом невыученный принцип «разделяй и властвуй» и ответственность, переложенную на разработчика задним числом. Азат добавил ироничную деталь: утром вместо одного PR на 20 000 строк приходит двадцать по 1 000, и их тоже кто-то должен ревьюить. LSTR же точно описал обе стороны: Станислав не оспаривает ответственность за прод, он оспаривает необходимость читать код досконально, а владелец прода не поверит, пока не будет наработана практика метрик, которая позволит не читать каждую строку. Андрей спорил всерьез и с аргументами. Поведение системы под нагрузкой не опишешь ни английским, ни схемой, ни даже моделью формальной верификации – большинство схем оптимизированы под happy path. За 60 лет индустрия таких диаграмм не придумала, UML как попытка генерировать код из схем провалился. И отдельно – осторожность со словом «верификация»: маркетинг продает формальную верификацию как решение проблем ИИ, и есть риск, что верификацией станут называть обычные тесты. Дмитрий согласился, что речь о разных вещах: он говорит о прикладной верификации и допустимой, а не стопроцентной корректности, и о слое артефактов для людей с надежной механикой перевода их в код. Василий зашел с третьей стороны: а где гарантии, что человек правильно понял требования и правильно все заревьюил? Гарантии людей не выше гарантий агентов, и это можно проверить A/B-тестом на одном и том же PR. Две недели назад чат пришел к схеме, где агент ревьюит не код, а набор проверок, а Станислав перечислял артефакты, которые стоит ревьюить вместо кода. Эта неделя впервые дала этой схеме серьезного оппонента и честный итог: Станислав сам признал, что опыта у него пока мало, а Андрей – что вопрос неоднозначен. Последний довод Андрея стоит запомнить: цель ревью еще и в том, чтобы люди знали концепции соседних модулей, и этого LLM за команду не сделает. Что в вашей команде хранит это знание, если PR перестанут читать? > «Ты не можешь аутсорсить понимание своей деятельности» – Андрей > «Я не оспариваю сохранение ответственности за прод и за решение. Я оспариваю необходимость чтения кода досконально» – Станислав Ссылка: What TLA+ can and can't check – Хиллел Уэйн о границах формальной верификации – https://buttondown.com/hillelwayne/archive/what-tla-can-and-cant-check/ ### Что такое спецификация: десять минут – и у всех разное понимание LSTR вернулся с питонячьего митапа с наблюдением: четыре доклада про ИИ, и ни слова про SDD, разработку от спецификаций. Его гипотеза – у докладчиков просто не было задач, которые не влезают в контекст: у одного из спикеров задачи сразу end-to-end, контекст держится в 100 тысячах токенов, а доказательство выполнения задачи собирается через управление браузером. Дмитрий ответил, что более-менее серьезный проект, который нужно поддерживать, без SDD не сделаешь, но это и сложнее, чем просто слать промпты агенту. Сложность он объяснил тут же: в индустрии нет единой классификации, что такое спецификация. Василий предложил свою – это то, что генерится при планировании: как есть, как будет и какую цель преследуем. Дмитрий показал пример из OpenSpec, где спека – статический список требований со сценариями «дано – когда – тогда», а план и проектное решение лежат в отдельных design.md и tasks.md. Андрей узнал в этом знакомый запах огурца – Cucumber и BDD. Через десять минут Дмитрий подвел итог: у всех разное понимание SDD, в этом и сложность. Василий не согласился – это не разное понимание, а адаптация под организации. Вторая половина разговора была про то, как писать требования для людей, а не только для машин. Андрей попросил научить модель не писать в требованиях конструкцию «X, а не Y». LSTR посоветовал прямые указания вместо запретов – модели плохо слушаются «не делай так» и хорошо – «делай так». Отсюда вырос спор про антропоморфизм: Василий считает, что работа с ИИ – это работа с людьми, и если можно научить человека, научишь и модель. LSTR возразил, что модель не обучается в процессе работы, обучение – это претрейн и файнтюн, а мы на самом деле учимся сами объяснять модели, что нам нужно. Две недели назад в чате спросили, что почитать про SDD, и Артем ответил, что ни один из фреймворков ему не подошел. Эта неделя объясняет почему: фреймворки спорят не о реализации, а о том, что вообще считать спецификацией. Андрей попросил в конце простого – посоветовать книги о том, как писать техническую документацию и требования. Прямого ответа он так и не получил. А в вашей команде слово «спека» означает один документ или три разных? > «Ну вот за 10 минут обсуждения мы и пришли к тому, что у всех разное понимание, что такое SDD. В этом и сложность» – Дмитрий > «Мы не обучаем модели. Мы сами обучаемся, как лучше объяснить модели, что нам требуется» – LSTR Ссылка: Claude prompting best practices: be clear and direct – Anthropic – https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#be-clear-and-direct Ссылка: Writing better Gherkin – Cucumber – https://cucumber.io/docs/bdd/better-gherkin ### Своя модель на 11 мегабайт против фронтира по подписке Спор начался с реплики Азата: зачем обучать модель, если она и так умнее меня, нужно только найти путь к нужным весам. Василий возразил: модель общего назначения полна мусора, а если нужно что-то узкое и дешевое в работе, дообучение – вариант, и вообще будущее за маленькими автономными моделями. Азат ответил «горьким уроком» Ричарда Саттона и цифрами: даже небольшая модель требует железа на год подписки на фронтир, данные дороже железа, а обучение с заметным выхлопом на продакшен-уровне – это миллионы долларов. По соотношению цена–качество подписки и дешевые китайские фронтиры выиграют у всего, что можно обучить самому без семизначного бюджета. Практик в споре оказался один. Станислав для своего приложения обучил две модели общим весом около 11 мегабайт – это даже не SLM, а сверточная сеть, которая ищет экран с цифрами на фото заправочной колонки и распознает, что на нем написано. Готового решения не нашлось: модели, которые распознают одну цифру, есть, а моделей поиска экрана колонки нет. Пришлось строить по исследованиям, данные он собирал сам. Его модель хуже фронтира, но быстрее и работает прямо на телефоне. Для чеков, напротив, все уже есть – PaddleOCR, корпуса на 500–2 000 чеков и встроенный OCR в мощных телефонах. Павел собрал из спора рабочий список, когда файнтюн имеет смысл: база знаний не влезает в контекст, задача узкопрофильная и ее нет во фронтирах, задача настолько простая, что ее потянет элементарная модель, или важна автономность и ресурсы машины. В остальных случаях хватает обвязки, которую легко сделать с помощью крупных моделей. Азат описал будущее как разное: тривиальное – на модели в смартфоне, сложное – на API, которые подешевеют до безлимитных подписок. Две недели подряд чат обсуждал модели-классификаторы, которые отвечают «да», «нет» или числом, и идею разбивать работу на маленькие проверяемые решения. Эта неделя довела мысль до конца: маленькие модели никуда не делись, а их обучение подешевело именно благодаря большим. Сколько задач в вашем продукте решает LLM просто потому, что маленькую модель никто не пробовал? > «Везде пихать LLM – это оверкил. А SLM и маленькие модели были раньше и остаются актуальными сейчас» – Станислав > «Обучать и дешевая вместе не бывает» – Азат Ссылка: The Bitter Lesson – Ричард Саттон – https://en.wikipedia.org/wiki/Bitter_lesson Ссылка: Chess-GPT: модель, обученная шахматам на одной RTX 3090 – https://adamkarvonen.github.io/machine_learning/2024/01/03/chess-world-models.html ### Менеджер, который не увольняет: ретроспектива одной ошибки Василий принес кейс: подчиненный регулярно не выполняет обязанности, команда жалуется, данные это подтверждают. Менеджер – хороший контрибьютор – хочет дать еще один шанс, и их было уже несколько. Что делать с менеджером? Станислав, вместо ответа, начал задавать вопросы: в чем косяк, как он влияет на бизнес, сколько людей в команде, не бутылочное ли это горлышко и нужен ли вообще менеджер, если все так зависит от одного человека. Андрей предложил выделить IC-трек: если менеджер вместо работы занимается контрибьютом, это плохой менеджер, а его руководитель плохо справился с ролью наставника. Самым содержательным оказался ответ Станислава про ценности. В менеджменте нет правильных ответов, и решение зависит от того, что вы цените. Для него «попасть в обещанный срок» – не ценность: люди не умеют планировать, 80% сроков искусственные, а бизнес продавливает те, что ему нравятся. Если человек сделал продукт, который решает задачу, а срок сорван без вреда для бизнеса, менеджер берет этот «косяк» на себя. Но если страдают другие в команде, а человек кормит завтраками, это проблема, и надо действовать. И важно понять, почему менеджер не принимает меры – может, он как раз защищает хорошего работника. Василий честно признал, что кейс – ретроспектива его собственной ошибки: нужно было убрать нерешительного менеджера, а потом и работника, но он посчитал это слишком. Менеджера он хотел перевести на место работника, но свободных мест не было – получился deadlock. И добавил наблюдение: многие лиды вообще не принимают решений о найме и увольнении, а «увольнять у нас не принято». Андрей усомнился: точно менталитет, а не просто неприятный процесс? Тут же прозвучал и второй урок: на собеседовании на вопрос о самой важной задаче лучше рассказывать не про увольнение, а про что-то социально приемлемое, с однозначным результатом. Василий приносит в чат такие кейсы не впервые. В мае это был сотрудник, которого нельзя уволить, в августе – год, после которого из команды ушли все, кроме него, и спор, проблема ли это людей или процессов. Тот же спор повторился и сейчас: что считать косяком, если сроки ставятся под давлением. А в августе он же рассказывал про отказ на собеседовании за слишком честный ответ – и урок про «социально приемлемую» историю звучит как продолжение. Кейс договорились разобрать на онлайн-встрече на следующей неделе. Какую ценность защищает ваш менеджер, когда в очередной раз дает шанс? > «В менеджменте нет правильных ответов. Менеджмент часто идет по ценностям» – Станислав > «Моя ошибка была, что я не смог уволить менеджера за нерешительность, а потом и работника вместе с ним» – Василий ### Цена работы ИИ падает на 47% в квартал, а время человека дорожает Андрей принес исследование Epoch AI: стоимость работы ИИ падает на 47% ежеквартально, быстрее, чем дешевело секвенирование ДНК. На бенчмарке FrontierMath результат 25% в январе 2025 года стоил около 0,55 доллара, а через полтора года – примерно 0,0015. Егор Смоляков сразу спросил о главном: а что со стоимостью работы людей? Никита ответил коротко – все еще дороже подписки за 100 долларов. Дальше разговор разошелся по двум осям. Станислав: стоимость человека только дорожает, зарплаты в ИТ растут быстрее. Азат: исследование меряет стоимость задачи, а она с ИИ дешевеет и у человека, и никому не нужно время – нужно выполнение задач. LSTR добавил третье: нагрузка на человека при плотной работе с ИИ тоже растет. Азат вспомнил эффект Баумоля – когда в одних отраслях производительность растет, а в других нет, зарплаты все равно растут везде, и отстающие отрасли дорожают. Николай нашел ту же мысль в фильме про BlackBerry: в минуту человеку можно продать только одну минуту, это предел роста. В конце недели этот же сюжет вернулся с обратной стороны: Gartner прогнозирует, что к 2028 году расходы на LLM превысят среднюю зарплату разработчика. Если стоимость единицы работы падает почти вдвое каждый квартал, а общий счет растет, значит, растет объем. Две недели назад чат обсуждал коридор бюджета на токены от 100 до 5 000 долларов на разработчика, и эта неделя объясняет, почему он такой широкий: цена падает, а аппетит к токенам растет быстрее. Что вы планируете в бюджете – цену токена или количество задач, которые захотите отдать агентам? > «Время никому не нужно. От человека нужно выполнение задач» – Азат > «Вы можете продать человеку в минуту только одну минуту. Это предел вашего роста» – Николай, цитата из фильма о BlackBerry Ссылка: The plunging price of thought – Epoch AI – https://epoch.ai/publications/the-plunging-price-of-thought Ссылка: Gartner: расходы на LLM превысят среднюю зарплату разработчика к 2028 году – Хабр – https://habr.com/ru/news/1089384/ ### Kafka, потому что на рынке ее умеют готовить Станислав спросил Егора, зачем в его компании Kafka. Ответ «как без нее, она же везде» его не убедил: очереди нужны, но зачем комбайн, если для .NET RabbitMQ проще в обслуживании? Дальше в защиту Kafka выступил Василий. У нее есть история сообщений, которую можно перечитать после факапа, пропускная способность на порядок выше, и любое хранилище данных с «риэлтайм данными» в итоге строят на ней. У него было пять инцидентов с RabbitMQ за два года, в том числе ночной звонок дежурного, когда очередь заблокировалась после потери одной ноды, а в банке не было экспертизы, чтобы понять почему. Станислав ответил опытом: на отказоустойчивом RabbitMQ с персистентностью они делали 120–200 сообщений в секунду, и этого хватало, чтобы банк работал. А то, что сообщение после чтения исчезает, – так и должна работать очередь. Андрей сформулировал главное: ни RabbitMQ, ни Kafka не про распределенные системы, все проблемы – от того, как спроектирован протокол. А для банка важны две вещи: общая политика компании и возможность открутить асинхронные коммуникации назад, поэтому Kafka там вполне уместна. Самый казахстанский аргумент принес Василий: на местном рынке лучше брать то, под что есть кандидаты, а не то, что больше подходит, – людей мало, а Kafka в вакансиях везде. Станислав возразил: такая изоляция не приводит к развитию компетенций в стране. Василий ответил, что развитие не обязано идти через стек, инструменты меняются каждый год, а микросервисы, которые пришли на рынок, сожрали другие знания – у тебя десять пользователей и десять микросервисов под них. В мае чат уже спорил о микросервисах с казахстанской спецификой – 18 миллионов человек это не хайлоад, зачем сложные трюки. Тот спор был про нагрузку, этот – про рынок труда: технологию выбирают не под задачу и не под нагрузку, а под то, кого получится нанять. Это рационально для компании, но кто тогда вырастит людей, которые умеют что-то кроме Kafka? Что определило выбор вашего брокера – задача, мода или резюме кандидатов? > «На рынке КЗ лучше брать то, где есть кандидаты, чем то, что тебе больше подходит» – Василий > «Ни реббит, ни кафка – это не про распределенные системы. Все проблемы не от инструментов, а от того, как ты протокол сделал» – Андрей ### Матрица грейдов, по которой все оказались джунами Kolesa Group запустила ежегодное исследование зарплат разработчиков, админов и QA в Казахстане, а прошедшим опрос открывает свою матрицу грейдов. LSTR назвал ее куцеватой и задал вопрос с подвохом: может, слишком куцая матрица хуже, чем ее отсутствие? Андрей ответил, что спорить можно, когда что-то есть, а когда ничего нет – спорить нельзя. Станислав просто похвалил за то, что выложили. Дальше чат прошелся по пунктам. Андрей запретил бы мидлам «умение системно рефакторить» – у них нет опыта понимать, что рефакторить нельзя, а инициировать стоит разговор о рефакторинге, а не сам рефакторинг. «Опыт конфигурирования компилятора» для мидла вызвал у него смех, выступления на внешних конференциях для третьего грейда мидла – вопросы, а «поддерживать open-source библиотеки без ущерба для других обязанностей» для сеньора – возглас «где вы?». Отдельно он заметил, что у фронтендеров в матрице нет ни одного требования по софт-скиллам. Никита отписался коротко: «Я по ней джун». В июне чат разбирал, как прозрачный грейдинг предсказуемо теряет обиженных людей, а непрозрачный копит несправедливость, и тогда Станислав описывал систему, где грейдируются универсальные навыки, не привязанные к стеку. Матрица Колес показывает обратную крайность: публичная, но перечень навыков, а не описание того, какую ответственность человек несет на каждом уровне. Тем не менее публичная матрица от крупного работодателя – редкость, и ее появление дает рынку повод спорить. Что в вашей матрице отличает мидла от сеньора – список умений или масштаб решений, за которые он отвечает? > «Можно поспорить, что слишком куцая матрица еще хуже, чем ее отсутствие» – LSTR > «Не могу придумать, когда мидл должен инициировать рефакторинг, а не разговор о нем» – Андрей Ссылка: Сколько зарабатывают разработчики и QA-инженеры – исследование Kolesa Group за 2025 год – https://kolesa.group/media/posts/issledovaniya/skolko-zarabatyvayut-razrabotchiki-i-qa-inzhenery-issledovanie-kolesa-group-za-2025-god ### Три группы в регулируемой отрасли: энтузиасты, ждущие и застрявшие в 2023-м Андрей спросил Никиту, который работает в банке, как люди встречают LLM: хотят ли апскиллиться, тянет ли их в бизнес или в код. Никита разделил всех на три группы. Первая – энтузиасты, которые не ждут, пока работодатель даст доступ, все уже попробовали и знают, как работать. Вторая – те, кто хочет, но находит причины не использовать ИИ на полную: мучаются на бесплатных или 20-долларовых подписках и слабых моделях и ждут, пока им на тарелочке принесут подписку и способ с ней работать. Третья – застрявшие в 2023 году: тогда впервые пощупали ChatGPT, увидели, как так себе он генерирует код, и решили, что им это не понадобится. Заметнее всего было наблюдение про мотивацию. Большинство видят себя разработчиками и воспринимают инструменты как экзоскелет, который в какой-то момент может сесть – то есть рассчитывают дотянуть руками, если кончится недельный лимит. Андрей признал, что видит и другую картину, и связал разницу с регулируемой отраслью, где никто не торопится рисковать, а безопасность забирает доступы. LSTR подбросил к разговору ступени принятия LLM из доклада с питонячьего митапа: «не использую» – первая, свой харнесс – одна из верхних, а десктопные приложения, неожиданно, стоят выше терминала. Объяснения нашлись быстро: в десктопе больше контроля над сессиями и входными данными, можно управлять браузером и другими приложениями, проще закинуть картинку, а в терминале больше двух-трех сессий уже требуют менеджера. Неделю назад чат пришел к тому, что одна и та же модель в двух харнессах ведет себя как две разные, и ступени принятия – продолжение той же мысли: зрелость меряется не моделью, а обвязкой. В какой из трех групп сидит ваша команда и что ей мешает перейти в следующую – доступ или привычка? > «Все видят себя больше разработчиками и инструменты воспринимают как экзоскелет, который может в какой-то момент сесть» – Никита > «Десктопные приложения дают больше контроля над сессиями и тем, как подаются данные на вход» – LSTR ### Жюри после хакатона, свой хакатон и третий MVP в Казахстане Через неделю после скандала с HackAlem.AI в чат пришло объявление тех же организаторов: ищут экспертов в техническое жюри, оценить около 30 проектов на GitHub, сделанных за пять часов, в обмен на сертификат и благодарственное письмо от министерства. Станислав отреагировал смехом и заметил, что 30 проектов от 2 500 участников выглядят как копейки: на хакатоне Hackload, который делало сообщество, было 15–20 проектов от 100 участников. LSTR спросил прямо: а до этого экспертов не было, как планировалось оценивать? Дмитрий пошутил, что были, просто кончились недельные лимиты. Из иронии вырос конструктив. Андрей спросил, не повторить ли Hackload, и Станислав ответил, что нужно, – организация уже переехала в профильный чат, а Егор предложил медиаподдержку от еще одного местного сообщества. Тем, кто не застал прошлый раз, напомнили формат: участникам давали среду, которая измеряла производительность их системы под нагрузкой. И почти одновременно LSTR получил статус Microsoft MVP по .NET – третий в Казахстане. Андрей тут же отрапортовал, что количество MVP в стране за год утроилось. Неделю назад, разбирая провал хакатона, чат спорил, хватит ли публичной критики, если скандал замнут. Эта неделя дала ответ, который чат уже формулировал летом про конференции: критика планку не поднимает, а сделать свое – поднимает. Месяц назад, когда в чате появился второй MVP, вывод был, что признание растет из видимой работы в сообществе, – третий за пару месяцев только подтверждает его. Если бы вы организовывали хакатон, что бы вы измеряли у участников – работающую систему под нагрузкой или презентацию? > «30 проектов от 2,5 тыс. участников – выглядит как копейки» – Станислав > «Были, просто недельные лимиты закончились» – Дмитрий, об экспертах жюри Ссылка: Задание прошлого Hackload – https://hackload.kz/task Теги: ии-агенты, код-ревью, верификация, спеки, модели, менеджмент, архитектура, грейды, сообщество ## Приложение в сторе за 190 долларов, атомарные решения вместо одного промпта и гильдия, которая закрылась URL: https://teamleads.kz/insights/week-2026-09-21/ Дата: 2026-09-27 Неделя про итоги разработки с ИИ, декомпозицию на маленькие решения, харнесс против модели, хакатон на 6 000 человек и закрытие сообщества ### Месяц, 190 долларов и агент-продакт: приложение вышло в стор Станислав закрыл первую часть дневника разработки, который вел в чате с конца августа. Приложение для учета расходов на авто опубликовано в App Store. Начал 23 августа, опубликовал 21 сентября – ровно месяц, и это ровно тот срок, который он закладывал на простое мобильное приложение и без ИИ, от одного до трех месяцев. В этом смысле ИИ выпуск не ускорил. Деньги – 190 долларов на самой дешевой модели, около 10 млрд токенов, и, по его оценке, на быстрой модели с самого начала вышло бы еще на 50 долларов дешевле. Готовый конкурент стоит 50 долларов в год, то есть окупаемость – четыре года, но нужные ему функции у конкурента платные, а лишнего много. Главное изменение за последние две недели – в процессе, а не в цифрах. Проблема была знакомая: агент делал задачу как джун, формально она закрыта, а с точки зрения пользователя фича не работает – язык переключается, но о перезапуске никто не предупреждает. Каждая задача рождала новые баги, и получался микроменеджмент. Решением стал второй агент в роли ревьюера-продакта: он смотрит на зарегистрированный user journey и решает, принимается ли задача и что нужно доделать. Цикл «воркер делает – ревьюер принимает с точки зрения пользователя» на сильной модели уложился в недельные лимиты, агенты работали 24/7, и работа наконец была завершена. Тесты при этом были, качественные и зеленые, но они ловили только то, что не сломалось старое. Продакт-ревьюер сделал гораздо больше полезного. Это интересно сопоставить с выводом конца августа. Тогда чат пришел к тому, что ревью другим агентом не спасает: все агенты клялись, что требование выполнено, а сработал только исполняемый тест с порогом. Сейчас ровно агент-ревьюер решил проблему, которую тесты не ловили. Противоречие, кажется, снимается типом требования: производительность можно записать в тест, а «фичей удобно пользоваться» – пока нет, и тут нужен взгляд со стороны пользователя, пусть даже машинный. Еще одна смена позиции – про модели: месяц назад сложность росла и пришлось брать модель умнее, теперь вывод другой – дешевые модели вполне способны, не нужно забивать гвозди микроскопом. Самый честный вывод – про домен. Станислав не iOS-разработчик и не может оценить ни код, ни последствия решений для пользователя: в бэкенде он знает слабые места и спрашивает о них заранее, а в iOS не знает даже, что спросить. LSTR заметил, что одной картинки «все работает» мало – при операциях с платежами можно сделать видимость ОК, а под капотом будет не ОК, поэтому иногда специфику реализации надо знать заранее, чтобы запросить ее как требование. А на объяснения агента, почему не получилось, распространяется та же проблема доверия, что и на объяснения живого разработчика. Без ИИ Станислав, по его словам, делал бы это четыре-пять месяцев, а к концу недели приложение научилось читать данные с фото заправочной колонки – мечта тринадцатилетней давности. А в каком домене вы бы сегодня не знали, что спросить у агента? > «С ИИ и без знаний можно сделать средненько. Чтобы сделать качественно, нужно знать домен и разбираться в нем» – Станислав > «Объяснения могут быть как валидными, так и невалидными, и без знания домена сложно отличить одно от другого» – LSTR Ссылка: TankBook в App Store – https://apps.apple.com/us/app/tankbook-fuel-mileage-log/id6807989868 Ссылка: TankBook на GitHub – https://github.com/belyaevsa/TankBook ### Атомарные решения вместо одного большого вызова Неделей раньше Азат получил доступ к модели-классификатору, которая отвечает только «да или нет», вариантом из списка до 255 значений или числом. На этой неделе он предложил применение: сделать игру про тимлида, где такая модель оценивает, как решение игрока повлияло на исход – мораль выросла, нашелся баг. Станислав признался, что начинал похожее в августе и остановился. Вайбкодинг не сложился в продукт, потому что он не представлял, как должен выглядеть результат, а главная сложность – не в коде, а в модели внешнего мира, где событий огромное количество. Андрей тут же разложил игровой цикл по ролям: база событий, большая модель оценивает вероятность каждого, код генерирует тип события, большая модель украшает его текстом, классификатор оценивает результат хода, а состояние сохраняется. И так по кругу. Для хорошей игры нужны еще скрытые переменные – характер людей, финансовое состояние компании, – которые драйвят сюжет незаметно для игрока. Каждый компонент делает одну узкую вещь, и никому не приходится понимать весь мир сразу. Станислав посмотрел на ту же модель с точки зрения своей задачи – долговременной памяти между LLM и пользователем, где нужно сохранять не историю диалога, а знания: утверждения, связи, неопределенности. Его первый подход раскладывал текст в тройки «сущность – отношение – сущность» и на ограниченных данных работал хорошо, но качество всей памяти упиралось в качество извлечения фактов. Потерял модальность, условие или авторство – и в память записан не тот факт. Классификатор идет другим путем: вместо одной сложной интерпретации – маленькие независимые типизированные решения. Это утверждение, вопрос или предположение? К кому относится местоимение? Есть ли вообще основание для решения? Дальше атомарные ответы собирает обычный детерминированный код. Из самой модели Станислав пока ничего не взял, его представление знаний уже сложнее, но идея декомпозиции оказалась полезной. И вывод звучит шире памяти: задача становится не «сохранить текст», а «что именно сохранить после того, как текст был понят». Это та же мысль, к которой чат приходил в разговорах про агентов с другой стороны – узкие проверяемые шаги надежнее одного умного вызова. Сколько в вашем пайплайне мест, где модель за один вызов делает то, что можно разбить на пять проверяемых вопросов? > «Не просить модель сразу понять все предложение, а разбить интерпретацию на маленькие проверяемые решения, сохранить неопределенность и только потом собирать из них knowledge representation» – Станислав > «Для хорошей игры важны другие, неважные события. Скрытые переменные, которые будут влиять на игру» – Андрей ### Харнесс против модели: Claude Code с локальным Qwen Андрей принес конфиг, которым Claude Code подключается к локальной модели Qwen 3.8 27B через прокси, – чтобы не отдавать код вендору. Человек, который его прислал, гоняет это на арендованной ноде с B200 и делится странным на первый взгляд наблюдением: время до первого токена и скорость генерации заметно лучше, чем у облака, а успешные непрерывные сессии длятся больше двух часов. Где все ломается, так это на уровне харнесса – обвязки вокруг модели. С Open WebUI та же модель тупит и делает лишние шаги в агентном цикле. Это был ответ на противоположный опыт: неделя на OpenCode с китайскими моделями через OpenRouter, после которой хочется биться головой – работать можно, но все очень медленно. Азат сформулировал третью позицию: Claude Code как продукт очень плох, а модель хороша, особенно по подписке, и если уж использовать локальную модель, то есть харнессы лучше. Получается, что три человека описывают три разных пары «харнесс плюс модель», и каждый вывод верен только для своей пары. Там же вышла Opus 5.5, и Станислав, переключившись, отметил, что она на 25% дешевле. Месяц назад чат обсуждал связку двух подписок, где вторая модель работает сабагентом у первой и выигрывает не потому, что умнее, а потому, что отдает наверх более чистый вход. Эта неделя добавила к той мысли вторую половину: качество агентной работы определяет не только модель, но и обвязка, причем одна и та же модель в двух харнессах ведет себя как две разные. Сравнивая модели, вы сравниваете модели – или их обвязки? > «Клод код очень плохой продукт, а модель хорошая, особенно по подписке» – Азат > «Если клод код подсоединить к квену – работает хорошо, есть успешные 2+ часовые сессии, с Open Web UI – много тупняка и лишних шагов» – из опыта, который пересказал Андрей ### Хакатон на 6 000 человек при 2 500 местах и государство как контрагент Среди недели несколько участников вернулись с хакатона HackAlem.AI в Астане – и вернулись злыми. По их словам и публикациям в СМИ, регистраций было около 6 000 при 2 500 местах, люди часами стояли на морозе, а часть так и не попала внутрь, в том числе участники, прилетевшие из Нигерии. Артем, побывавший там, признался, что зол до уровня нервного срыва, и даже бот мероприятия, судя по скриншотам, вел себя странно. Реакции разошлись. Дмитрий назвал овербукинг недопустимым и предложил увольнять ответственных: доверие подорвано. Андрей ответил с ироничным реализмом: организаторы останутся на местах, потому что «кто же знал, что придут люди», а собрать 6 000 человек – взрослая задача, а не детская ошибка. Нурлан считал, что организаторам нужно было хотя бы извиниться, Михаил заметил, что в новостях, судя по формулировкам, все «так и было задумано». Отсюда разговор ушел шире – о работе с государством вообще. Андрей Звездочка рассказал, как две недели не может нормально подать документы: у госорганов есть все данные, но он сам перекладывает PDF из отдела А в отдел Б, потому что интеграций между системами просто нет. Дмитрий дал совет из своего опыта: делать проекты с государством – как садиться играть с ним в карты, а тема ИИ достаточно живая, чтобы работать только с частным сектором. Нурлан возразил: у нас государство везде, игнорировать его не выйдет. Станислав добавил, что подружиться с госструктурами можно только рядом, в Астане, через обеды и ужины. В июле чат спорил о конференциях в Казахстане: критиковать или содействовать. Тогда рецепт был – меньше критики, больше рук в программном комитете. Хакатон показывает другую сторону той же медали: когда проблема не в качестве докладов, а в базовой логистике, руки в ПК не помогут, а публичная критика остается единственным сигналом. Хватает ли такого сигнала, если, по словам одного из участников, скандал все равно замнут? > «Делать проекты с государством – это как садиться играть в карты с государством» – Дмитрий > «У госухи есть все документы, но я из отдела А перекладываю пдфки в отдел Б» – Андрей Звездочка Ссылка: «Симулятор выживания»: участники раскритиковали HackAlem.AI в Астане – Ulys Media – https://ulysmedia.kz/news/81431-simuliator-vyzhivaniia-uchastniki-raskritikovali-hackalem-ai-v-astane/ ### Гильдия закрылась: постмортем сообщества на 900 человек Артем объявил, что закрывает сообщество AI Engineers Guild, и сделал это как положено инженеру – с постмортемом. Сообщество выросло до 900 человек, провело офлайн-митап, десять эфиров, из него выросли два крупных опенсорс-проекта, пришли крупные блогеры ИИ-сферы. Но цель была не чат, а профессиональное объединение, и она не достигнута: опенсорс не пошел, эфиры не набирали охвата, офлайн не вышел за пределы Алматы, ядро не сформировалось. Чат проживет еще две недели, материалы останутся. Чат ответил несколькими версиями причин. Андрей Звездочка: работающие гильдии, которые он знает, платные, и основной контент там делают авторы – в интернете невозможно заставить людей вкладываться не в свой проект. Станислав предложил подправить ожидания: за полгода экспансия работает только с маркетингом, а ядро единомышленников надо искать среди тех, кто стабильно пишет. Артем ответил, что делает этот анализ каждую неделю своим скиллом «садовник», и вывод тот же – в какой-то момент ядро почти получилось, но не сложилось. Андрей поддержал с другой стороны: лидером не обязательно должен быть самый выдающийся, иногда достаточно того, кому не безразлично. У этой истории есть начало в архиве чата. В мае, когда Артем анонсировал новое сообщество, Станислав поставил под вопрос саму идею: его чат когда-то вырос с 600 до 1 800 человек, но сильных проектов не породил. Дмитрий тогда возражал, что проблема в формате и что результаты дает системное обучение, а не свободное общение. А в июне чат пришел к выводу, что молчаливое большинство – норма, а активное ядро воспроизводится само. Гильдия показывает, где у этого вывода граница: ядро воспроизводится, если оно уже есть, но само по себе из 900 человек оно не вырастает. На вопрос Андрея, не рано ли сдаваться, Артем ответил коротко: четырех месяцев пробы достаточно. Это, пожалуй, самое полезное в кейсе – не причины, а решение вовремя остановиться и сказать об этом публично. Сколько ваших внутренних инициатив живет дольше, чем у них есть ядро? > «Кмк, невозможно в интернете заставить людей вкладываться не в свой проект» – Андрей Звездочка > «Лидер – это не обязательно самый выдающийся, иногда достаточно быть тем, кому не безразлично» – Андрей ### Перевод терминов как изобретение терминов Неделя началась с двух казахскоязычных новостей: в сообществе выложили крупнейший TTS-датасет на казахском, а Ержан запустил опрос о боли, на которую упирается его компания, – ни один ИИ-ассистент встреч не разбирает смешанную казахско-русскую речь, а такая звучит на каждой встрече. Две недели назад чат тестировал распознавание речи на записи митапа и пришел к тому, что мерить нужно на своих записях. Смешанная речь – ровно тот случай, где публичные бенчмарки ничего не скажут. От речи разговор перешел к словам. Михаил вспомнил недавний спор в Threads об ИТ-терминологии на казахском и рабочую группу по переводу PMBoK, где тоже долго решали, что переводить, а что заимствовать. Станислав сформулировал суть: перевод терминов – это изобретение терминов, и попробуйте перевести «Agile». Андрей напомнил, что это уже было: в нулевые русские переводчики так же выдумывали термины, «поток» и «нить» боролись за право называться thread, «жесткий диск» прижился как калька, а НЖМД помнят только читатели журналов. Язык живой, и побеждает обычно не кампания, а издатели. Месяц назад чат спорил о переводе технической литературы на казахский и пришел к тому, что спор не про факты, а про приоритет – мост на родном языке нужен на входе в область. Эта неделя добавила практическую деталь: проблема не в том, переводить ли, а в том, кто это сделает. Андрей предложил локализовать интерактивный сайт про преобразование Фурье и признался, что его опыт убеждения заниматься казахским контентом показывает – людям лень. На предложение спросить в казахскоязычном чате он ответил, что технический перевод – дело технарей, а не гуманитариев. Если термины изобретает тот, кто первым переводит, кто в вашей команде сейчас изобретает словарь, которым все будут пользоваться? > «Перевод терминов – это изобретение терминов» – Станислав > «Технический перевод – дело технарей» – Андрей Ссылка: An Interactive Introduction to Fourier Transforms – сайт, который предложили локализовать – https://jezzamon.com/fourier/ ### DHH про ИИ: можно ли слушать идеи, не принимая автора целиком Станислав пересказал выступление DHH, создателя Ruby on Rails, на Rails World 2026: час про прекрасное будущее с ИИ. Код нужно писать не руками, а через нейросети, English > Ruby; впереди нативные приложения и быстрый бэкенд на Rust; p(bloom) больше p(doom), а «Агент Лютер» уберет необходимость в касте программистов для общения с компьютером, как печатный пресс убрал необходимость в священниках для чтения Библии. Станислав ценит DHH за то, что тот ухватывает тренды и показывает их своим примером. Азат увидел в этом ИИ-психоз. Андрей пошел дальше – дело не в ИИ, а в самом DHH: его недавние посты на социальные темы он считает вредными, а в технических высказываниях не видит ни одной оригинальной мысли, только ретрансляцию консенсуса, усиленную медиаплощадкой. Станислав возразил: DHH раньше других громко сказал, что пора уходить из облаков, потому что это дорого, и что пора перестать платить за подписки и покупать софт – а это то, что сейчас происходит с ИИ. Андрей парировал, что про облака было очевидно всем, кто не в корпорации, просто у них не было медиа. Дальше спор ушел от персоны к принципу, и это, кажется, первый раз, когда чат обсуждал, можно ли отделять профессиональный вклад человека от его общественной позиции. Станислав разделяет человека по областям: слушает его там, где он эксперт, и не смешивает с политикой. Азат предложил формулу через аналогию: можно слушать музыку, но не нужно слушать мысли автора о воспитании детей. Андрей пришел к позиции, которая неожиданно сблизила стороны: идеи отделимы от людей, но если мысль банальна, ее можно сказать самому и подтвердить доказательствами, а не апелляцией к сомнительному авторитету. Павел спросил о главном – а кто определяет, что вред, а что польза? В августе чат разбирал, почему фраза «код никогда не был проблемой» задела многих: у разных людей сложным было разное. DHH говорит ту же мысль еще громче, и реакция на нее снова оказалась не про ИИ, а про то, кто ее говорит. Когда вы приносите в команду чужую идею, вы опираетесь на ее аргументы или на имя того, кто ее сказал? > «Я считаю, что идеи отделимы от людей. Если какую-то прозаичную идею говорит мутный человек, это не убивает идею» – Андрей > «Человек – многослойный» – Станислав Ссылка: Выступление DHH на Rails World 2026 – https://www.youtube.com/watch?v=vDjW_dRyKXY ### Миллион тенге в 20 лет: возраст или опыт Молодой участник принес спор со своим руководителем: можно ли в 20 лет попасть на позицию с зарплатой от миллиона тенге? Руководитель считает, что с одной работы – нет. Андрей ответил осторожно: в среднем скорее нет, чем да, потому что шальных денег на автоматизацию больше не дают, а компании со стабильными проектами много требуют и крутят носом, и вопрос в том, нанимают ли сейчас начинающих вообще. Николай привел контрпримеры: знакомый с зарплатой 5 000 долларов в 25 лет на удаленке и парень, устроившийся на 650 тысяч в 19. Деталь, которая все объясняет: второй начинал в 16 лет, а в 17 работал стажером по договору ГПХ, потому что в штат его не могли взять по возрасту. Станислав переформулировал сам вопрос: возраст значит меньше, чем опыт, поэтому правильно спрашивать не «можно ли в 20», а «можно ли с одним годом опыта» или «с пятью». Тот же участник в мае жаловался, что не может найти работу даже джуном с «3+ годами опыта» в 20 лет, и тогда чат объяснил, что большой опыт в юном возрасте читается как накрученный. Сейчас картина та же, но с другой стороны: цифра в резюме и цифра в зарплате упираются в доверие к опыту, а не в возраст. Андрей закрыл тред трезво – в твоей организации руководитель, скорее всего, прав, и не всем нужны убер-специалисты. Как бы вы ответили на этот вопрос своему двадцатилетнему сотруднику – про рынок или про его конкретный путь? > «Возраст тут имеет меньшее значение, как твой опыт» – Станислав > «Знаю парнишку, который устроился на 650к в 19 лет. Вопрос только в том, насколько ты подготовлен» – Николай Теги: ии-агенты, дневник-разработки, модели, архитектура, сообщество, казахстан, язык, зарплаты ## Агент ревьюит проверки, а не код, Херби в колонне агентов и пилот за 2 000 долларов URL: https://teamleads.kz/insights/week-2026-09-14/ Дата: 2026-09-20 Неделя про верификацию вместо код-ревью, узкое место по Голдратту, пилот ИИ в SDLC, искажение настоящего, оплату опенсорса и модели-классификаторы ### Агент ревьюит не код, а набор проверок Неделя началась с просьбы посоветовать, что почитать про spec driven development – подход, где спецификация пишется раньше кода и становится главным артефактом для агента. Ответы оказались осторожнее вопроса. Артем перепробовал OpenSpec, BMAD, Spec Kit, GSD и Kiro, ни один не зашел, и в итоге он написал свой memory bank. Уалихан напомнил, что внедрять ИИ поверх сломанных процессов – верный способ все поломать. Готового рецепта нет, есть только вопрос, какую проблему вы этим решаете. Через день разговор ушел в практику. Данияр предложил сдвинуть все правила ревью влево: общий на команду скилл ревью, обязательный запуск в «холодном» субагенте перед пулреквестом, результат пишется в файл, а CI не дает смержить ветку без этого файла. Человеческое ревью PR при этом становится двойной проверкой, а обязательным чекпоинтом остается design review со старшими коллегами. Станислав задал логичный вопрос – а зачем тогда ревью вообще? И добавил, что разработчикам он бы не доверял и централизованный источник правды все равно сохранил бы. Самую цельную конструкцию принес Дмитрий, на примере вывода крипты на бирже: кошельки, блокчейн, комиссии, лимиты, KYC, зависшие транзакции. Ревью кода – это вопрос веры в агента. Автотесты – это вопрос, все ли тесты написаны и проверяют ли они что-то, потому что логика бывает сломана при зеленых тестах. Поэтому он вводит этап judgement: агент смотрит на требования, реализацию и набор проверок и выносит заключение о полноте проверок. Сверху – challenge, то есть проверка самого заключения: мутационное тестирование до прода и reconciliation job, сверка балансов, уже в проде. Ошибся агент в judgement – минус ему в карму, и по накопленной статистике можно решать, каким агентам на каких этапах давать больше автономии. Это прямое продолжение августовского разговора. Две недели назад Дмитрий описывал трассировку «требование – реализация – проверки», а в начале августа чат впервые разобрал мутационное тестирование как способ проверить сами тесты. Теперь эти куски сложились в процесс: у каждого сценария в спеке есть идентификатор, он проходит через код и проверки, и через него же в проде собираются метрики и алерты. Нефункциональное требование вроде «p95 постановки ордера – 200 мс» записывается в спеку рядом с функциональными, а в design.md сразу указываются метрики и правила алертов. Роли владеют своими документами: аналитик – spec.md, разработчик – design.md, специалист по качеству – verification.md. Станислав вынес из статьи «Do you still read the code?» близкую мысль: код – скорее обязательство, чем актив, а актив – это теория системы в головах. Отсюда его список того, что стоит готовить для ревью вместо кода: актуальная схема, привязанная к коммиту, связь с бизнес-требованиями, где и какие константы по умолчанию задал ИИ, применённые паттерны, закрытые негативные сценарии и сделанные проверки. Андрей возразил против пункта про умолчания – много умолчаний делают систему хрупкой. И там же прозвучало предупреждение, которое касается не процессов, а людей: сажать в одну команду тех, кто читает код, и тех, кто уже не читает, без заранее оговоренных правил – вредно, а ИИ просто увеличивает масштаб проблемы. Что в вашей команде сейчас ревьюят на самом деле – код, проверки или ничего? > «Основная суть в том, что агент ревьюит не код, а набор проверок, верифицирующих этот код» – Дмитрий > «Не нужно читать код, но нужно понимать, что каждый кусок программы делает» – Станислав Ссылка: Do you still read the code? – статья, с которой начался спор об артефактах – https://zanlib.dev/blog/do-you-still-read-the-code/ Ссылка: Azimuth – метод и инструмент Дмитрия для трассировки требований – https://github.com/azimuth-sh/azimuth Ссылка: crit – инструмент для ревью прозы вместо кода – https://crit.md/self-hosting ### Херби в колонне агентов: 240 процентов коммитов и ноль роста использования В пятницу Станислав вспомнил «Цель» Голдратта – книгу, которой сорок лет. Там отряд скаутов идет по тропе со скоростью медленного Херби с огромным рюкзаком, и разгонять быстрых впереди бессмысленно: колонна просто растягивается. Повод – свежая работа NBER: больше 500 тысяч разработчиков на GitHub, телеметрия их ИИ-инструментов и сравнение с похожими разработчиками без ИИ. Цифры выстроились в лестницу. У автономных агентов примерно +240% коммитов, на уровне проектов остается +80%, на уровне выпущенных релизов +30%, а в четырех магазинах приложений – резкий рост числа новых приложений и нулевой рост их использования. Херби здесь – ревью, интеграция и решение, что вообще выпускать: пишет агент, а проверяет и принимает по-прежнему человек. Авторы называют это гипотезой слабого звена, и это хорошо ложится на прошлогодний отчет DORA, где рост использования ИИ шел вместе с падением стабильности поставки. Месяц назад чат уже спорил о том же через закон Амдала: если кодинг – 15% времени, то даже бесплатный кодинг ускоряет систему максимум в 1,18 раза, а Артур возражал своими замерами из маленькой команды без согласований. Тогда вывод был такой: цифра ускорения говорит не про модель, а про то, сколько в организации весит все, что не кодинг. Голдратт добавляет к этому важную деталь, и в ней аналогия ломается: станок можно докупить, а человека, который понимает систему настолько, чтобы подписаться под изменением, лицензиями не купишь. Именно его вендоры обещают заменить следующей моделью. Станислав сам оговорился, что это наблюдательное исследование: публичный GitHub плохо описывает корпоративную разработку, а вайбкодеров там все больше. Андрей предложил спекулятивное продолжение – если функционал делают 10 человек вместо 100, как это изменит продажи и обслуживание клиентов, которым нужны люди? Ответ Станислава был коротким: разработка и продажи не связаны. Возможно, в этом и есть ответ на Херби. Если ваш дашборд внедрения ИИ считает коммиты, что именно он показывает – загрузку станка или отгрузку? > «240 -> 80 -> 30 -> 0. Это и есть растянувшаяся колонна» – Станислав > «Допустим, мы делаем функционал 10 людьми там, где надо было 100. Как это повлияет на процесс продаж?» – Андрей Ссылка: NBER: исследование влияния ИИ-агентов на коммиты, релизы и использование приложений – https://www.nber.org/papers/w35275 Ссылка: DORA Report 2025 – https://dora.dev/research/2025/dora-report/ ### Пилот ИИ в SDLC за 2 000 долларов и бюджет на токены «поперек больше, чем вдоль» Данияр выложил в чат предложение и попросил на него обратную связь: пилот по внедрению кодинг-агентов в полный цикл разработки для небольшой команды. 2 000 долларов в месяц, два-три месяца, гарантированные 40 часов работы в месяц, переработки за счет исполнителя. Внутри – обучение постановке задач, настройка среды и гейтов, документация для машин и людей, проверки в CI/CD для коммитов от роботов. Финишная линия – фича, которую команда сама проведет от бэклога до прода. Требование на входе – CI/CD и хоть какое-то тестовое покрытие. Николай честно признался, что побежал бы к руководителю прямо сейчас, но тесты, git и CI/CD в его углу еще только предстоит затащить. Станислав ответил на вопрос «почему такого нет на рынке» с неожиданной стороны. Не потому, что некому делать, а потому, что компании не хотят платить помимо консалтинга еще и за токены, и никто не может сказать, сколько их заложить. А после пилота решение придется постоянно дотачивать по стоимости: на американских моделях все сделать легко, но китайские в десятки раз дешевле, и миграция – это еще один проект. Данияр согласился, что точно предсказать нельзя, но коридор бюджета на разработчика оценить можно. Коридор Станислава по тому, что он видит, – от 100 до 5 000 долларов. Дальше спор зашел в подписки. Дмитрий заметил, что на подписках выходит 100–200 долларов, и Данияр подтвердил: личных подписок более чем достаточно, хотя рекомендовать это легально он как консультант не может. Станислав возразил по существу: личную подписку не воткнешь в автоматический детектор упавших тестов или ревью PR, ее можно использовать только как второго пилота. Технически подключить можно, но это нарушение политики вендора, лимиты при автоматическом запуске кончаются быстрее, а решение будет постоянно отваливаться. В мае чат уже упирался в ту же стену с другой стороны: корпоративная закупка Claude не проходит по процедурам, а подписка не работает в CI, поэтому для автоматизации все равно нужны API-токены. Четыре месяца спустя вывод тот же, но теперь видно, чего он стоит: без оплаченного API «внедрение ИИ в SDLC» сводится к личным подпискам разработчиков, то есть к небольшой модернизации, а не к смене процесса. Кто в вашей компании должен назвать цифру бюджета на токены, прежде чем кто-то назовет пилот успешным? > «Использование подписок – это не изменение SDLC. Это небольшая модернизация» – Станислав > «Батенька, так он у вас поперек больше, чем вдоль» – Николай, о коридоре от 100 до 5 000 долларов ### Издержка сегодня против выгоды через полгода Станислав написал длинный пост об одном когнитивном искажении: издержки решения в моменте давят сильнее, чем выгоды, которые мы получим потом. Издержка конкретна и здесь, выгода гипотетическая. Примеры он собрал из обеих половин работы тимлида. Пропустить прогон тестов, если десять раз все было хорошо. Отложить переписывание модуля, потому что две недели видны в спринте, а полуторное замедление каждой будущей фичи не видно ни в одном отчете. Сделать задачу самому за сорок минут вместо трех часов на делегирование. Закрыть вакансию посредственным кандидатом, потому что цена проявится через полгода и ее никто не свяжет с решением о найме. Отменить пятую встречу один на один подряд – и узнать о проблеме из заявления об уходе. Самое практичное в посте – не диагноз, а признание, что рассуждением искажение не перевесить. Работает только одно: убрать решение из момента. Тесты запускаются сами, и пропустить их – отдельное усилие, а не отсутствие усилия. Встреча один на один стоит в календаре и не отменяется, а переносится. Спасибо за работу говорится по итогам недели, потому что в понедельник на это есть десять минут, а в момент релиза нет. Честная оговорка тоже есть: если у компании денег на три месяца, сиюминутная издержка и есть главное, проблема в том, что мы ценим настоящее всегда, даже при длинном горизонте. Андрей увидел в этом то же, что и правило трех в рефакторинге: «правильно» должно быть правильно глобально, а значит, локально оно часто неудобно. Станислав возразил с другой стороны: люди упрощают все вокруг себя локально, им не хватает полномочий или знаний, и получаются обертки над существующими решениями, которые усложняют систему глобально. В июне чат разбирал, почему гигант годами не чинит простой баг, и пришел к связности архитектуры и приоритетам того, кто платит. Этот пост добавляет к той картине третью причину – обычную человеческую близорукость, которая масштабируется на всю организацию. Тут же участник принес живой кейс: команде передали проект без документации и внятной архитектуры, с дублирующимися связями и жестким дедлайном в конце года, нанять некого. Глушить издержки быстро или делать основательно с риском не успеть? Андрей ответил третьим вариантом: не основательно и не идеально, а просто не оставлять за собой хаос. Нет тестов – добавь один, нет CI/CD – настрой, билд долгий – посмотри почему, зависимости разные – консолидируй понемногу. И не давай команде подписываться под чужими дедлайнами, всегда оставляй запас на улучшения. Быстрое глушение простительно в двух случаях: продажа компании и разовый рывок ради долгосрочного клиента. Какие решения в вашей команде принимаются в моменте только потому, что их никто не вынес в расписание? > «Каждый раз побеждать искажение я не умею. Умею только сделать так, чтобы побеждать было не нужно» – Станислав > «Тебе не надо делать основательно и идеально, тебе надо просто не оставлять срач за собой» – Андрей ### Спотифай для пакетов: кто должен платить за опенсорс Станислав принес длинную статью «Nobody pays for open source. We can force them to» с пересказом. 60% мейнтейнеров ничего не получают за работу, 61% из них работают в одиночку, почти 60% думали бросить. 136 разработчиков написали 80% кода в 50 самых используемых пакетах. Деньги в экосистеме при этом есть – компании платят миллиарды в год JFrog, Snyk, Docker, Sonatype, то есть посредникам, которые продают надежную поставку бесплатного кода. Предложение автора: реестры вроде npm, PyPI и Docker Hub берут плату за корпоративное использование и автоматически распределяют долю выручки по всем пакетам в зависимостях платящих клиентов. Азат увидел в этом «нетфликс для пакет-менеджеров»: энтерпрайз получает предсказуемые расходы, а тот самый парень из Небраски становится миллионером. Андрей назвал лекарство хуже болезни. Его аргументы: в глубоком дереве npm стоимость дистрибуции размножается по каждой зависимости, авторы, которые осознанно раздавали библиотеку бесплатно, неявно попадут на оплату, а музыкальные платформы, на которые ссылается идея, решили проблему консолидацией денег у дистрибьюторов, а не у артистов – зарабатывают только популярные. Станислав отвечал, что это все равно лучше донатов, а «кто первый – того и тапки» и есть оценка вклада, пусть и грубая. Самое интересное расхождение – не про реестры, а про продажи. Андрей видит корень проблемы в пассивности разработчиков: опенсорс вокруг конечных продуктов монетизируется, вокруг библиотек плохо, и это разные рынки. Станислав возразил, что разработчики и не должны продавать, это другой навык. В июле, разбирая .NET Foundation, чат пришел к похожему выводу с другой стороны: автору библиотеки от фонда нужен прежде всего маркетинг, чтобы репозиторий находился в поиске. Неделя добавила к этому развилку: либо мейнтейнер учится продавать, либо кто-то продает за него и забирает свою долю, как Docker. Андрей верит в государственные дотации и научные гранты, но не в «социализм от техногигантов». Станислав спросил в ответ, не превратятся ли дотации в локальные библиотеки, которые не нужны миру. Спор так и не сошелся, но вопрос из него полезен любой команде, которая живет на чужих зависимостях: сколько из вашего стека держится на одном неоплачиваемом человеке, и что вы будете делать, когда он устанет? > «Компании уже платят за open source – миллиарды в год, но не авторам, а посредникам» – Станислав, пересказ статьи > «В государственные дотации – верю, в гос программы – верю. В социализм от техногигантов – нет» – Андрей Ссылка: Nobody pays for open source. We can force them to – статья Лори Восса – https://seldo.com/posts/nobody-pays-for-open-source-we-can-force-them-to/ ### Не LLM, а классификатор: модель, которая отвечает только «да», «нет» или числом Азат нашел typesafe.ai – что-то, что подается не как обычная языковая модель, а как строго типизированная. Андрей Звездочка был скептичен: пока ничего не работает, собирают спрос. Азата интересовало другое – он не считает LLM единственным и лучшим применением трансформеров и с интересом смотрит на любые другие подходы. Через день он получил доступ и уточнил: это скорее классификатор. Модель возвращает булево значение, вариант из перечисления или число – быстро, но не прям умно. Варианты применения, которые он сразу увидел: выбрать скилл, агента или MCP-сервер под запрос. Он попробовал и компакцию длинного разговора – режешь текст на предложения и для каждого спрашиваешь, имеет ли смысл его оставить. В принципе получилось, но насколько хорошо, нужно долго тестировать. Станислав сравнил это с натренированной ML-системой для классификации изображений, только для ответов, и согласился, что для быстрых решений в агентном пайплайне это выглядит отлично. До сих пор разговоры о моделях в чате были про генерацию: кто лучше пишет код, кто дороже, кто ваншотит. Здесь чат впервые обсуждал модель, которая сознательно не генерирует текст, и в конце недели еще один участник принес статью про этот класс моделей и спросил, кто ими пользовался. Возможно, самый практичный вывод – не про конкретный продукт, а про архитектуру: сколько маленьких решений в вашем агентном пайплайне вы сейчас отдаете большой модели только потому, что другой под рукой нет? > «Я не думаю, что ллм – это единственное и самое лучшее применение трансформеров» – Азат > «Может булеан, енам или число выдать, быстро, но не прям умно» – Азат Теги: ии-агенты, код-ревью, верификация, метрики, экономика, опенсорс, менеджмент, модели ## Дорогой план и дешевый код, пять часов кодинга в день и ревью в состоянии зомби URL: https://teamleads.kz/insights/week-2026-09-07/ Дата: 2026-09-13 Неделя про маршрутизацию задач между моделями, лимит в пять часов кодинга, тест транскрипции встреч, семь трендов и бета-тест вайбкод-портала ### Дорогая модель для плана, дешевая для кода Неделя открылась двумя счетами. LSTR выложил статистику за август: 970 долларов на самую дорогую модель, которую он использовал и для планов, и для кода, и 100 долларов на модель попроще, которая за четыре дня прошлась по его планам и закрыла задачи. Диагноз жесткий: дорогая модель переусложняет все, постоянно останавливается с нерелевантными вопросами, а однажды написала тест, про который сама же признала, что он проверяет несущественное. Вывод LSTR формулирует как очевидный: план пишет дорогая модель, код по подробному плану – дешевая. Станислав пришел к той же схеме с другой стороны. Счет за приложение для учета расходов на авто дошел до 136 долларов, и он разобрал последние 200 задач: что можно было отдать быстрой модели вместо про-версии. Ответ – примерно 90 процентов. На одном и том же коммите быстрая модель находила те же расхождения в логике, что и дорогая, но втрое дешевле. Новое правило: про-модель только когда быстрая не справилась. Отдельная оговорка: быстрая модель легко справляется, если бриф на входе полный и детальный. Самое ценное в этом треде – критерий делегирования, который Станислав вынес из своего оркестратора: могу ли я записать приемку как мутацию, которую сам агент не может придумать? Если да – задача для дешевой модели. Если выбор самой мутации требует дизайнерского суждения, то есть решения, какой инвариант несущий – для дорогой. Это переводит вопрос «какая модель лучше» в вопрос «насколько хорошо я сформулировал задачу». Любопытно, как это ложится на прошлые недели. Три недели назад чат жаловался, что Opus 5 пишет много, а мыслей мало, и наблюдение LSTR про переусложнение – прямое продолжение. А неделю назад в разборе моделей прозвучал противоположный вывод: дешевая модель потратила в семь раз меньше токенов и принесла ноль ценного, поэтому дешевизна меряется ценой за полезный ответ, а не за токен. Противоречия здесь нет, есть уточнение: дешевая модель выигрывает не сама по себе, а когда ей отдают задачу с готовым планом и записанной приемкой. Оба наблюдения сходятся на одном: экономия достигается не выбором модели, а качеством постановки до ее запуска. LSTR добавил, что при работе с прозой подробный план обязателен даже для хорошей модели, потому что простой запрос может нагородить изменений в неочевидном радиусе поражения. А вы знаете, какая доля ваших задач действительно требует самой дорогой модели, или платите за нее по привычке? > «Опус дорогой и неэффективный. Для планов лучше использовать дорогую модель, для кода – более дешевую» – LSTR > «Текущее правило – использовать pro, только когда flash не смог. И, как видите, это отразилось на счете» – Станислав ### Пять часов кодинга в день: потолок или недоразумение Никита принес спор из своей компании. Система трекинга эффективности разработчиков считает, что эффективный кодинг ограничен пятью часами в день, и все, что выше, просто не учитывает. Часть команды считает это несправедливым: люди сидят дольше, а система их срезает и никак это не подсвечивает. Вопрос к чату был простой – работают ли разработчики в массе больше пяти часов? Ответы разошлись по оси размера компании. У Станислава есть бенчмарки, где разработчик сидит в среде разработки полтора часа в день, и это правда: чем больше компания, тем больше бюрократии и встреч, тем меньше времени в IDE. Артур дал шкалу: стартап – пять-шесть часов кода, компания на сто человек – три-четыре, на 200–500 – два-три, а 500+ дает тот самый средний час кодинга по миру. LSTR, напротив, работает и девять часов, и десять-двенадцать в релизы, но признает, что заметная часть этого времени – ожидание ревью, чтение чужих PR и документов. Интереснее оказался вопрос, что вообще измеряется, и это первый раз за все время дайджестов, когда чат спорил о часах в IDE как о метрике. Артур разделяет два индикатора: Agent Time – сколько суммарно работали агенты, в среднем восемь часов в день, и Human Time – сколько человек работал рядом с ними, у него около шести. Из 124 часов работы моделей на новый код уходит 20, остальное – десятки других активностей: ревью, дебаг, исследования, деплой. Время в IDE само по себе не говорит почти ничего. Артур также заметил, что офис и удаленка влияют по-разному в зависимости от человека: кому-то дома мешает семья, а кому-то в офисе постоянно стоят над душой. Косвенно тема уже поднималась: месяц назад чат считал по закону Амдала, на сколько агенты ускоряют работу, а в июле обсуждал, как ИИ уплотняет рабочий день. Разделение Agent Time и Human Time – продолжение именно того разговора, только теперь с цифрами из трекера. Азат закрыл тред фразой, которая просится в эпиграф к любой системе учета времени: работать надо не пять часов в день, а головой. Час подумать иногда заменяет месяц кодинга. Если ваша система трекинга режет все выше пяти часов, она хотя бы честно признает, что не умеет отличить работу от присутствия. А что она делает с тем часом? > «Чем больше компания – больше бюрократии и встреч – меньше сидят в ИДЕ, а больше в документах, чатах, таск-трекерах» – Станислав > «Надо работать не 5 часов в день, а головой. Иногда час работы головой заменяет месяц кодинга» – Азат Ссылка: Что такое работа инженера в крупной корпорации – заметка Станислава – https://t.me/meetdeadlines/55 ### Транскрипция встречи: одно слово меняет протокол На выходных в чате протестировали три модели распознавания речи на реальной задаче – записи открытой встречи сообщества «Тимлид не кодит» от 3 июня. Сорок минут, несколько говорящих, перебивания, возня с микрофонами в начале. Взяли MAI-Transcribe-2 от Microsoft, Gemini 3.5 Flash и Yandex SpeechKit. Microsoft заявляет первое место на бенчмарке FLEURS со средним WER 5,2 процента на 60 языках, но отдельной цифры по русскому нет, а FLEURS – это начитанная речь, где носители по одному произносят подготовленные предложения. Совещание звучит иначе. На одном предложении Yandex сделал две ошибки, и обе переворачивают смысл: «Мне интересно» стало «Не интересно», «Похоже» стало «Покажите». Там, где две другие модели услышали междометие «О, сейчас пошло», Yandex выдал «вова сейчас пошла» – междометие стало именем, и глагол согласовался с ним по роду. В протоколе встречи это уже другое утверждение. Расхождения не только в смысле: MAI вернул расшифровку за 15,8 секунды, Gemini за 88,6, Yandex за 62,9. У Yandex в тексте ноль точек и запятых – 21 910 символов одной строкой, протокол из этого собирают второй обработкой. MAI сохранил все «э-э» в речи, остальные две модели их убрали: для стенограммы нужен первый вариант, для протокола второй. Честная часть теста – его ограничения. WER не считали, потому что эталонной расшифровки нет, сравнение качественное. Отраслевой терминологии в записи не было, а именно там работает подстройка под ключевые слова, и это осталось непроверенным. Одна запись, одна акустика, один домен. Распознавание речи в чате сравнивают впервые, но методический вывод повторяет то, к чему чат пришел еще в июле в споре про эвалы моделей: публичные лидерборды меряют чужие задачи. Вывод из этого – не «модель X лучше», а методический: выбирая модель для своей задачи, замеры нужно проводить на своих записях, иначе слово «внедрили» ничего не значит. Сколько ошибок в ваших протоколах встреч вы бы заметили, если бы никто не сверял их с записью? > «Одно некорректное слово может поменять смысл» – Станислав > «Без бенчмарков на ваших задачах, ошибка может быть значительной» – Станислав Ссылка: Анонс MAI-Transcribe-2 от Microsoft – https://microsoft.ai/news/mai-transcribe-2-is-the-fastest-most-accurate-and-cheapest-speech-recognition-model-in-the-world/ Ссылка: FLEURS – бенчмарк, на котором заявлено первое место – https://research.google/pubs/fleurs-few-shot-learning-evaluation-of-universal-representations-of-speech/ Ссылка: Запись встречи «Тимлид не кодит», на которой проводился тест – https://teamleads.kz/events/meetup-2026-06-03/ ### Ревью в состоянии зомби и другие тренды, с которыми согласились В пятницу вечером в чат принесли список из семи трендов – смерть IDE, конец гонки за токены, код-ревью в состоянии зомби, открытые модели ради экономии, смерть среднего менеджмента, работаем больше чем когда-либо, найм стал сложнее – и вопрос, с какими из них согласны. Дмитрий согласился с первыми тремя, Азат со всеми, а дальше разговор ушел в ревью и не вернулся. Спор о ревью – самый устойчивый сюжет чата за лето. В начале июля обсуждали, читать ли код, который пишет ИИ, в августе прозвучало «я больше не читаю сгенерированный код», две недели назад – требования как тесты вместо ревью. Эта неделя добавила новое: впервые ревью защищали не как контроль качества, а как культуру команды, которую агенты ломают. Андрей считает, что ревью часто и было театром: исчезло социальное давление, и люди радостно признались, что им безразлично, что делают другие, и учиться у коллег они не хотят. Азат возразил: хорошо, если было театром, но команды с настоящей культурой ревью сейчас страдают. Стоит одному участнику начать пользоваться агентами, и PR копятся быстрее, чем их можно прочитать, а на качество еще никто не готов махнуть рукой. Станислав добавил, что ревью имело смысл в общей кодовой базе, где никто не знает весь контекст, а сейчас все прогоняют через агентов и постят комментарии, возможно даже не читая код. Дальше спор ушел глубже: Азат считает, что модель на ревью находит не то – десять проблем в том, как сделано, и ни одного вопроса, зачем. Дорогая модель наоверинженирит абстрактные фабрики синглтонов там, где хватило бы одной строки, а ревьюер похвалит качество. Станислав ответил вопросом: а в чем тут проблема модели, если контекста в коде нет? И привел свою цифру: онбординг человека в кодовую базу возрастом 18 лет занимает четыре-шесть месяцев, первый PR с исправлением бага – через 40 дней. Из них десять дней уходят на доступы, которые выдаются с лагом в сутки в трех-пяти системах подряд, и это проблема систем, написанных людьми, а не моделей. Позиция Станислава радикальна: понимать код не нужно. Азат парирует: чем больше кода делегируешь, тем меньше он твой, и мириться с этим должен каждый в команде, а не один энтузиаст. LSTR предложил конструктивный ответ вместо спора: ревью работает, когда оно неформальное и точечное, когда подсвечивается действительно важное, чего агенты плохо находят, и тимлид не должен поощрять формальное ревью с комментариями от агентов. Он же прошелся по всем семи трендам от лица маленькой команды в большой структуре: IDE нужна для дебага, но реже; токены уходят не на максимизацию, а на мультимодельное ревью документов; ревью живо, но ревьюится в основном проза, потому что ерунда в прозе быстро прорастает в планы; работаем больше – однозначно да; найм просто оказался не готов к резюме, нарисованным моделями, но научится. На следующий день в чат принесли интервью одного из создателей Codex, где та же мысль звучит с другой стороны: человеческое обсуждение стоит сосредоточить на намерении и контрактах – что компонент должен делать и какие инварианты сохранять, а корректность и безопасность проверять автоматически. Если ревью в вашей команде стало формальностью, что именно оно перестало ловить? > «Code review часто и было театром, просто социальное давление исчезло» – Андрей > «Он найдет десять проблем в том, как это было сделано, и ни разу не спросит: а нафига это было сделано» – Азат Ссылка: Building Codex with Tibo Sottiaux – интервью на The Pragmatic Engineer – https://www.youtube.com/watch?v=sLSTM9znQNs Ссылка: Разбор интервью: почему дешевые переделки не отменяют архитектуру – https://t.me/book_cube/4800 ### Бета-тест портала: фронт не ваншотится, а пустая платформа не держит Николай выложил в чат dnd.kz – портал для клубов настольных ролевых игр, собранный в дуэте с агентом. Автор честно предупредил: он не веб-разработчик, не дизайнер, а из стека 1С, где пользователь должен страдать; уровень вайбкодинга – 146 процентов. Цель беты была не про функционал, а про безопасность и ошибки новичка в деплое, которые видны всем, кроме автора. Первая реакция чата оказалась не про код. Андрей: пока пусто, и это сильно смазывает впечатление, заведи друзей – уже будут «мастера». И вторая, от человека, участвовавшего во многих стартапах: функционала сделано непропорционально имеющимся пользователям, клубы можно было не делать, а доделать, когда набралась бы масса мастеров и игр. Станислав добавил, что без контента обратную связь дать сложно: портал есть, а что ожидалось – непонятно, и если платформа мертвая, нет интереса остаться. Азат сформулировал общий вывод: самое сложное в таком проекте – не сайт написать, а набрать критическую базу пользователей, и заметил, что группы обычно организуются в чатах, так что бот может оказаться проще сайта. Николай возражал разумно: это платформа социального взаимодействия, ее нельзя наполнить иначе как постепенно, значит нужен сам социум. Но через день пришел настоящий бета-тест: Андрей выкатил список из десятка замечаний – разные отступы у выпадающих списков, склонение «найдено 2 игр(-ы/-а)», сломанные пути к портретам, счетчик «история игр 12» при двух отображаемых, два стиля оформления игроков, которые оказались заглушками, пустой блог, нерабочая почта поддержки, указанная на сайте. Реакция автора – «фронт не мое», на что Андрей ответил точнее: фронт не ваншотится. Месяц назад чат уже упирался в тот же вопрос, когда сообщество решило делать свой продукт и сразу споткнулось о гипотезу: чья это боль. Тогда спор шел до кода, сейчас – после. Из этой истории торчат два наблюдения. Первое: агент собирает сайт за ночь, но глаз замыливается быстрее, чем раньше, потому что блоков стало больше, а внимания на каждый – меньше. Второе: показать программистам пустую платформу означает получить ревью верстки вместо ревью идеи. Заглушка с одним клубом и двумя анонсами дала бы больше сигнала, чем отдельный раздел с кланами. Когда вы показываете свой проект впервые, какую обратную связь вы на самом деле хотите получить, и позволяет ли ее дать то, что вы показываете? > «Много функционала сделал, не пропорционально имеющимся пользователям» – Андрей > «Самое сложное в таком проекте не сайт написать, а набрать критическую базу пользователей» – Азат ### За что платят в приложении для авто: спор с пользователем конкурента Станислав третью неделю подряд ведет дневник разработки приложения для учета расходов на авто: две недели назад это были двенадцать часов агента и сорок долларов, неделю назад – сто долларов и 250 задач. На этой неделе дневник впервые ушел от технической части к продуктовой. Состояние знакомое каждому: первые 80 процентов проекта сделаны за 20 процентов времени, оставшиеся 20 займут все остальное. Ломается интеграция между частями, ручное тестирование вскрывает плохой пользовательский опыт вроде удаления без подтверждения. Заодно попросил другого агента оценить UI-тесты: часть из них тестирует примерно ничего и подлежит удалению, 80–90 процентов адекватны, но недостаточны для покрытия – и список недостающих сценариев ушел в задачи. Продуктовая часть оказалась интереснее технической. Николай семь-восемь лет ведет три автомобиля в конкурирующем приложении и платит за подписку 370 тенге в квартал – сумму, которой не жалко и которая просто убирает рекламу. Станислав собирается продавать дополнительные функции, и тут выяснилось, что у конкурента платная даже смена темы и экспорт. Андрей одобрил: такие вещи и нужно давать за деньги, они стимулируют купить хотя бы на месяц. Дальше был спор, за что вообще платить. Станислав не видит смысла контролировать цены на топливо: они одинаковы от заправки к заправке, есть только сезонность. Николай ответил тремя сценариями: журнал цен за несколько лет как аргумент в спорах, потому что память у людей как у золотой рыбки; напоминания по пробегу и датам; прогноз расходов для семейного бюджета. Еще одно: график среднего расхода, который уполз вверх на пару литров – это повод заехать на диагностику. Автор согласился не со всем, но признал, что для продажи история работает. Самый практичный момент – про целостность данных. У Станислава в истории есть опечатки в датах и одометре, от которых ломается весь расчет расхода, особенно если править задним числом. Конкурент решает это грубо: валидирует соотношение даты и пробега на входе и не дает сохранить, пока не исправишь, а старую запись править вовсе не позволяет. Иногда лучший UX – это отказ. Какие данные в вашем продукте пользователь может испортить одной опечаткой, и кто это заметит? > «Прозвучит странно – аргумент в спорах. У людей память, как у золотой рыбки. А журнал за последние N лет с ценами – это весомый аргумент» – Николай > «У меня сейчас состояние, что первые 80% проекта я сделал за 20%, а оставшиеся 20% – займут теперь 80% всего проекта» – Станислав Теги: ии-агенты, модели, экономика, продуктивность, код-ревью, транскрипция, продукт, сообщество ## Спека, которую нельзя обмануть, сто долларов на приложение и облако, которое продает доверие URL: https://teamleads.kz/insights/week-2026-08-31/ Дата: 2026-09-06 Неделя про верификацию агентского кода тестами, дневник разработки за сто долларов, комментарии-слоп, выбор моделей и доверие как главный актив облака ### Спека, которую нельзя обмануть: требования как тесты Понедельник начался с простого вопроса – много ли багов делают агенты. Ответ оказался неожиданным: багов в привычном смысле нет, компилятор, линтеры и тесты ловят их до коммита. Ломается другое. Фича реализована в коде, но в интерфейсе нет места ей воспользоваться. Есть кнопка, но за ней ничего не стоит. Две задачи работают по отдельности, а сквозного процесса между ними никто не написал. Каждая была вне скоупа своего брифа. Азат сформулировал корень проблемы жестче: агент пишет корректный код по некорректной спеке. Человеческий язык гибкий, любое требование можно истолковать или объявить неприменимым, а потом написать полотно о том, почему сделано «правильно». Отсюда его подход: код одноразовый, требования живут только в тестах. Оркестратор пишет тесты, свежий агент в пустой песочнице получает единственную задачу – сделать их зелеными, возвращает артефакт без кода, оркестратор вкладывает его в мастер-тест. Через несколько итераций спека кристаллизуется. Дмитрий защищал другую конструкцию: спеки живут в файлах, а связь с кодом обеспечивает трассировка – требование, реализация, тесты. Нет реализации или тестов у требования – ошибка, и находит ее алгоритм, а не агент. Проверку соответствия можно поручить модели с маленьким контекстом, а сверху поставить оппонента, например мутационное тестирование. Азат возражал по опыту: агент отчитается, что все покрыто на 146 процентов, а запускаешь – не работает. Самый убедительный аргумент недели пришел из практики. Требование «вся логика на GPU» не заенфорсилось ни через инструкции, ни через ревью другим агентом – все клялись, что все на GPU, а приложение выдавало 10 кадров в секунду. Сработал единственный тест: миллион объектов быстрее миллисекунды. После него программа полетела на 144. Побочный эффект подхода тоже полезен: когда требования противоречат друг другу, агент в песочнице находит это безжалостно. А как в вашем проекте отличают выполненное требование от отчета о выполнении? > «Агенты пишут корректный код, но некорректную спеку. Код делает что описали, но не то, что тебе надо» – Азат > «Получается театр, построенный агентом: все требования оттестированы и выполнены на 100%. Запускаешь, а там ничего не работает» – Азат Ссылка: Azimuth – инструмент Дмитрия для трассировки требований и верификации – https://github.com/azimuth-sh/azimuth ### Сто долларов, 250 задач и баги на стыках Станислав продолжил вести разработку приложения вслух. К концу недели – больше ста долларов, 250 зарегистрированных задач, работающий бэкенд, сборка в TestFlight и лэндинг. Код по-прежнему пишет агент, автор его не читает: читает спеки и чат агента. Тесты занимают около 70 процентов кодовой базы, и за все время приложение ни разу не крашнулось. Интереснее список того, что все-таки сломалось. Пикер даты закрывается, только если выбрать дату, отличную от сегодняшней. Язык переключается, а обещанного уведомления о перезапуске нет. Есть мертвый код – написан, но не вызван. Половина этих дефектов – не баги, а слабые постановки: человек по ходу реализации додумывает детали сам, агент не додумывает, если не попросить. Пятьдесят задач в бэклоге, каждая пятая, появились именно из ручного тестирования на живом телефоне. Отдельная строка – про секреты, которые на этапе разработки уехали в облако, и ротацию, отложенную до продакшена. Ее стоит держать в голове всем, кто повторяет этот маршрут: инфраструктура готова раньше, чем дисциплина работы с ней. Вывод, который автор сделал сам, звучит спокойнее, чем ожидаешь после такого списка. Агент забывает погасить фоновые процессы, пишет лишнее или не пишет нужного, оставляет мертвый код – ровно то, что делают живые люди в команде. Джуны ошибались так же, сеньоры оверинженирили, споры про количество тестов были всегда. Разница только в скорости. И тут же честная оговорка скептика: это не продакшен-код, за который платят зарплату. А какая часть ваших претензий к агентам – это претензии к процессу, который вы бы предъявили и человеку? > «Это проблемы слабых постановок. Не прописаны детали изначально в сценариях» – Станислав > «У меня такая же работа, только вместо медленного человека у меня быстрая машина» – Станислав Ссылка: Свежая работа про опыт использования Copilot CLI и Claude Code в Microsoft – https://arxiv.org/pdf/2607.01418 Ссылка: Публичный бэклог проекта, из которого взяты цифры – https://github.com/belyaevsa/TankBook/blob/main/docs/TASKS.md ### Комментарии в коде: документация или слоп Спор, который тянулся всю неделю и так и не сошелся. Азат запрещает агенту писать markdown-файлы и комментарии хуком на Write – по регексу, без сложной логики. Мотив прагматичный: проза от модели противоречива, не обновляется вслед за кодом и съедает контекст. В generic-библиотеке агент опишет кейсы конкретных потребителей, в тесте напишет, что тест зафейлится, хотя тест должен просто краснеть и зеленеть. Станислав держит противоположную позицию и показывает файлы, где в комментарии зашита ссылка на требование: агент, открывая такой файл, сразу видит происхождение зависимостей. Это та же трассировка из первой темы, только записанная в коде, а не в отдельном реестре. Возражение на возражение: если комментарии плохие, дайте в инструкции несколько примеров хороших. Ответ Азата закрывает круг – не работает, потому что качество комментария невозможно проверить автоматически. Андрей развел это на две честные стратегии. Первая – комментировать мало и добирать контекст общением в команде. Вторая – комментировать ритуально. Проблема второй в том, что ритуал обычно не сопровождается разговором, и текст быстро превращается в мусор. Агент, работающий круглосуточно, просто масштабирует ритуал до промышленных объемов. Практическая развилка здесь не про вкус, а про верифицируемость. Правило, выполнение которого нельзя проверить машиной, агент выполнит недетерминированно – а значит рано или поздно не выполнит. Какие из ваших правил в claude.md сегодня подкреплены хоть каким-нибудь гейтом? > «Я не доверяю прозе вообще, потому что это чистый слоп» – Азат > «Комменты считаю важной частью документации, потому что там есть контекст существования этих настроек» – Станислав ### Кто ваншотит, а кто итерирует: разбор моделей недели К четвергу разговор о моделях перестал быть перечислением бенчмарков и стал разговором о ролях. Наблюдение Азата: одна модель лучше в итеративной работе, другая – в ваншоте. И следом менее очевидное продолжение: модель, которая требует меньше контроля, забирает у вас контроль. Хорошо это или плохо – зависит от того, что вы делаете. Станислав привел встречный замер на исследовательской задаче: экономная модель потратила в семь раз меньше токенов и принесла ноль ценного, дорогая потратила больше и дала результат. То есть дешевизна меряется не ценой за токен, а ценой за полезный ответ. Отдельно прозвучала жалоба на среднюю по силе модель, которая стоит как топовая, и симпатия к дешевым моделям для несложных задач. Практический сюжет недели – возможность подключить сторонние модели прямо в привычный харнесс. Ценность не в системных промптах вендора, а в единой экосистеме: не жонглировать двумя форматами инструкций, хуками, скиллами и правами. Контраргумент тоже прозвучал – альтернативные харнессы читают те же инструкции и скиллы, а вот хуки и песочницу придется дублировать. И общий фон: доверия к вендорским бенчмаркам в чате нет ни на грош, ждут независимых замеров. Хорошая привычка на неделю, когда очередная модель объявляет себя лучшей. По какому измерению вы сравниваете модели – и совпадает ли оно с тем, за что вы платите? > «Сол лучше в итеративной работе, опус в ваншот» – Азат > «Опус требует меньше контроля, как результат ты теряешь контроль» – Азат Ссылка: Сравнение моделей на исследовательской задаче, которое принесли в чат – https://youtu.be/qEd9DTMXAOk ### Облако продает не мощности, а доверие Разговор про казахстанский рынок облаков вышел из бытовой жалобы: железо старое, нового почти нет, вендоры не дают гарантий. Дальше Уалихан разложил, почему крупный локальный игрок выбирает не самое удобное облако, а самое давнее. Решает доверие: местный бизнес, отсутствие санкционных рисков и сомнительных связей. Малый и средний бизнес про это думает меньше – ему нужны удобство разработчика, широкий выбор сервисов и цена. Из этого следует довольно жесткая развилка для нового игрока. Либо нишевый продукт под конкретных клиентов, либо открытый код. Второе выбрано сознательно: открытость дает сопоставимый кредит доверия там, где его нельзя купить возрастом компании. Банковские облака под этот аргумент не подпадают – они либо еще не публичные, либо слишком молодые, чтобы надстраивать над собой платформенные сервисы. Фон для всего этого невеселый: инфраструктуры под ИИ в стране практически нет, GPU сдают в аренду по ценам сбитого боинга, а инференс-провайдеров не видно. Прозвучал и контраргумент из зала – продавать можно и эскимосам, вопрос только в том, что именно. Дискуссия местами скатывалась в личные выпады, но содержательная часть от этого не пострадала. Полезная рамка отсюда шире облаков. Когда вы выходите на рынок, где ваш продукт объективно удобнее, но клиенты выбирают старожила, вы конкурируете не функциями, а репутацией. И прозрачность – один из немногих способов ее ускорить. Чем в вашем продукте закрывается вопрос доверия, если истории у вас пока нет? > «Вся проблема облаков строится от доверия» – Уалихан > «OpenSource может дать доверие сопоставимое, поэтому я вижу именно это направление как наиболее рациональный выход» – Уалихан ### Кого нет в чате и почему это вопрос к нам Понедельник неожиданно ушел в разговор о том, кто в чате пишет, а кто молчит. Андрей поставил вопрос прямо: специалистов-женщин на рынке достаточно, а в чате их почти не слышно – значит, дело в нас. И привел личный случай: пригласил коллегу в сообщество, где ему все казалось нормальным, она быстро ушла со словами «они токсики», и только тогда он увидел, почему. Айгерим ответила из другого опыта. Она ушла из нескольких крупных чатов – где-то стало скучно, где-то слишком токсично, где-то ей выдали мнение за факт и позволили себе оскорбления. Ее позиция: дело не в поле, токсичными бывают все, и женщины нередко поддерживают своих абьюзеров. Кристина добавила недостающую деталь – в таких ситуациях чаще всего остается наблюдать и не вкладываться. Ниже по треду обсуждали второй немой вопрос – казахский язык в чате. Здесь тоже нашлась развилка: без реальной практики язык не выучить и непонятно зачем, но есть города и клубы, где встречи ведут на казахском, и это работает. Оба сюжета про одно и то же: состав сообщества – это не данность, а следствие того, какие ценности оно транслирует явно. Отдельно стоит отметить, что в этот же день чат сорвался в перепалку с личными выпадами – ровно то, что отталкивает новых людей быстрее любой модерации. Заявлять ценности легко, удерживать в моменте сложно. Что в вашем сообществе или команде сигнализирует новичку, что здесь безопасно говорить? > «Если девушки не пишут, значит мы не дорабатываем – в целом хватает девушек специалистов на рынке» – Андрей > «Дело не в поле, ни в паркетном, ни в мужском, ни в женском. Мы все люди и токсичными можем быть все» – Айгерим ### MVP как побочный продукт сообщества На неделе в чате появился второй в Казахстане обладатель статуса Microsoft MVP и единственный по dotnet – всего таких в мире около 1255 человек. Повод для поздравлений превратился в разбор того, как туда попадают, и разбор получился отрезвляюще практичным. Путей несколько, и ни один не про код: развитие локального сообщества вокруг технологии, статьи для местного рынка, организация митапов, хардкорные технические материалы. Речь идет про абстрактный вклад, и статьи для джунов тут могут весить не меньше, чем для сеньоров. Из бонусов – бесплатные лицензии и небольшой кредит на облако, порядка 150 долларов в месяц. Самая полезная деталь – про вход. Нужна рекомендация от кого-то из уже существующих MVP, и способ ее получить банален: писать действующим обладателям статуса, в том числе незнакомым. Один из участников рассказал, что подавался именно так. Ценность истории не в статусе, а в механике. Признание в индустрии выдается за видимую активность, а видимость почти всегда растет из сообщества – чата, митапа, статьи. Это не путь технаря в чистом виде, но если вам нравится помогать людям, он неплохо конвертируется в личный бренд. Что из того, что вы уже делаете для коллег, никем снаружи не видно? > «Чтобы начать, надо следовать закону кумовства – чтобы кто-то порекомендовал из уже существующих людей» – Андрей > «Это не совсем путь технаря, но если вы любите помогать людям, думаю это хороший способ развивать личный бренд» – Андрей ### Кальки, длинные тире и модели, которые цитируют сами себя Две темы недели про язык сошлись в одну. Первая началась с замечания к статье: слишком много калек с английского. Автор согласился, но диагноз поставил не модели, а домену – русскоязычных материалов про агентную разработку мало, поэтому модель думает в этой области на английском и калькирует. Рабочий прием из чата: отдельным проходом попросить переписать текст естественным русским и явно проверить на кальки. Вторая – полушутливое наблюдение, что длинное тире стало маркером сгенерированного текста. Кто-то предположил, что лет через тридцать оно уйдет из грамматики: люди ленятся редактировать вывод модели, а следующее поколение моделей учится на этих же текстах. Возражение не менее убедительное – на телефонах длинному тире научили задолго до всякого ИИ, просто потому что удобно. И третий слой, самый неприятный. В чат принесли историю о том, как три сайта нагенерировали 215 тысяч страниц вида «лучший софт для», и поисковый ИИ их исправно цитирует. Рядом – личный эксперимент: модель, выбирая между своим сниппетом из другого чата и отредактированным человеком, стабильно выбирает свой. Возражение прозвучало разумное: веб-поиск работает обычными алгоритмами, и если сгенерированная страница поднялась в выдаче, она, возможно, действительно решала задачу. Собранные вместе, эти наблюдения дают неуютную петлю: модель пишет текст, текст попадает в индекс, модель предпочитает его человеческому и учится на нем дальше. Заодно всплыл честный вопрос без ответа – влияет ли ресерч агентов на поисковую статистику, по которой мы потом принимаем решения. Как вы отличаете источник, написанный человеком, от источника, написанного для модели? > «Все модельки начинают в этом домене думать на английском и калькировать на русский» – Данияр > «Люди потом продолжают учиться на своих же текстах с длинными тире» – Кристина Ссылка: Обсуждение на Hacker News про 215 тысяч сгенерированных страниц в выдаче ИИ – https://news.ycombinator.com/item?id=49536375 Ссылка: Статья про проектный харнесс для кодинг-агентов, с которой начался разговор о языке – https://dus.garden/evergreen/u-provala-est-adres Теги: ии-агенты, тестирование, верификация, облака, сообщество, модели, личный бренд ## Опус разучился объяснять, железо против подписок и ИИ, расследующий взлом URL: https://teamleads.kz/insights/week-2026-08-24/ Дата: 2026-08-30 Неделя про деградацию текстов Opus 5 и связку с GLM, стоимость агентной разработки, локальный кластер против подписок и пределы ИИ-расследований ### Модель пишет много, а мыслей мало: неделя жалоб на Opus 5 Неделя началась с наблюдения, которое сначала звучало как частный случай, а к среде превратилось в общую жалобу. Участник под ником LSTR сказал, что модель многословна, противоречит сама себе и плохо работает на больших задачах анализа. Артур подхватил: текста стало больше, а единиц мысли в нем меньше, и достать их получается с трудом. Дмитрий, который параллельно купил подписку на конкурента, описал то же самое своими словами. Дальше появилась гипотеза о причине. Станислав предположил, что вендор встраивает в тексты водяной знак для детекции сгенерированного, и это начинает сказываться на изложении. Андрей возразил по существу: водяной знак нельзя сделать так, чтобы он не отразился на структуре текста, разве что кодировать знаками препинания. Гипотеза остается гипотезой, но она объясняет ровно то, что все заметили: код модель пишет не хуже, а объясняет заметно хуже. Интереснее реакции, чем сама жалоба. LSTR откатился на предыдущую версию и добавил в промпт «be brief and keep plain English». Азат повесил хук, который запрещает модели писать комментарии и markdown-файлы, потому что ее хлебом не корми, дай написать десятистраничный слоп. Артур пошел третьим путем и прогоняет ответы через другую модель. Три разные стратегии на одну и ту же проблему: закрепить версию, ограничить вывод, поставить переводчика. Полезная рамка отсюда такая: качество модели не одномерно, и деградация может прийти в измерении, которого нет ни в одном бенчмарке. Кодинг остался на месте, а объяснения просели – и если ваш пайплайн опирается на то, что модель внятно передает контекст другим агентам, вы потеряете качество там, где не думали его мерить. Знаете ли вы, в каком измерении ваша модель важна для вас больше всего? > «Просто вижу текст, а единицы мыслей достать из них не получается, или получается с трудом. Раньше такого не было» – Артур > «Я привык, что опус делает хорошо и за ним не надо перепроверять, и для опус 4.8 это было валидно» – LSTR Ссылка: Тред на Reddit с похожими жалобами, который принесли в чат – https://www.reddit.com/r/ClaudeCode/s/svz9V8t7BK ### Две подписки вместо одной: GLM как часть среды Claude Code Из жалобы выросла конфигурация, которая заслуживает отдельного разбора. У Артура две максимальные подписки, и долгое время вторая была запасной: либо одна модель, либо другая. Теперь они работают параллельно и по разным ролям. Одна пишет код, вторая переписывает за ней все тексты – документацию, HTML, объяснения, и она же ходит в интернет и исследует кодовые базы. Самое неожиданное наблюдение в этой ветке: когда вторая модель работает сабагентом у первой, она справляется лучше нативных инструментов – просто потому, что результаты ее ресерча человекочитаемы и в таком виде ложатся в контекст оркестратора. То есть выигрыш не в том, что модель умнее, а в том, что она отдает наверх более чистый вход. Постпроцессинг при этом стоит немного токенов. Артур сам задал следующий вопрос, на который ответа в чате не нашлось: а не пострадали ли менеджерские качества модели-оркестратора. Промпт для сабагента – это тоже текст. Если модель стала хуже формулировать мысли, то она хуже ставит задачи другим моделям, и деградация уходит на уровень ниже, где ее уже не видно глазами. В сумме это довод в пользу того, что связка моделей по сильным сторонам перестает быть экзотикой. Не «какая модель лучше», а «какую роль в пайплайне кому отдать». А у вас в пайплайне одна модель делает все или роли уже разъехались? > «GLM стал сильно дополнять Claude Code и они работают вместе параллельно» – Артур > «Есть ощущение что когда GLM выступает в качестве Sub Agents for Opus 5/Fable 5, он даже лучше справляется чем нативные инструменты» – Артур ### Двенадцать часов агента и сорок долларов: дневник одной разработки Станислав всю неделю вслух вел разработку личного приложения и приносил в чат цифры. В понедельник – двенадцать часов работы одного агента-оркестратора, сабагенты писали код и тесты, восемь долларов на дешевой модели, около 20% плана. В четверг – сорок долларов и примерно 70% плана. Цифры интересны не сами по себе, а тем, что между ними произошло. Изменилось две вещи. Во-первых, модели пришлось брать умнее: не быструю, а сильную, потому что сложность приложения выросла и нужно разбирать, почему что-то не прошло по тестам. Во-вторых, пошли интеграции с внешними инструментами в части распознавания, а это требует экспериментов. Стоимость агентной разработки растет не линейно от объема кода, а скачками, когда меняется характер задач. Отдельно стоит замкнутый цикл. После каждой завершенной задачи агенты гоняют UI-тесты, написанные во встроенном фреймворке платформы, и запускает их машина, а не агент. Дмитрий уточнил ровно этот момент, и это важное различие: агент пишет тест один раз, дальше его исполняет обычный раннер. Иначе за проверку вы платите токенами каждый прогон. И бытовая деталь, которая тоже про разработку: чтобы обучить распознавание чеков, нужны реальные чеки, и Станислав два дня просил их у чата, а собрал в основном сам на заправках. Данные для маленького продукта достаются дороже кода. Сколько в вашем последнем прототипе стоил код и сколько – данные к нему? > «Один агент оркестрировал (собственно он и 12 часов работал), сабагенты выполняли работу» – Станислав > «Модели теперь использую умнее (не flash, а pro), потому что сложность приложения растет и нужно дополнительно разбирать, почему что-то не прошло по тестам» – Станислав ### Кому нужна аналитика расходов на ИИ и почему гипотеза поменялась Артур рассказал, как за год сдвинулся его продукт по аналитике работы команд. Изначальная гипотеза была про продуктивность: поставим систему, инженеры будут больше кодить, посмотрим, работает контроль или нет. На практике покупают другое – разбор расходов организации по проектам и задачам, картину того, кто уже уверенно работает с ИИ, а кто пишет код руками, и удобочитаемые датасеты, по которым можно исследовать процессы вместе с моделью. Второе смещение – в том, кто платит. Ожидали аутсорс, где время команды продается напрямую, а обнаружили продуктовые компании. Клиентов около двадцати, и уже не хватает инженеров первой и второй линии. Из технических деталей запомнилась одна: они видят процент попадания в кэш и процент выходов из него, и по их данным у одной модели около 90%, у другой около 70%. Станислав ответил четырьмя возражениями, и они полезнее похвалы: есть способ оптимизации дешевле, чем разбираться, куда уходят траты в промпте, – просто переключиться на дешевые модели; организаций с построенным агентным пайплайном пока немного; двадцать клиентов – это еще не рынок; и есть оптимизации другого класса, которые бьют по той же боли. Артур на это заметил, что даже корпоративный пакет вендора не показывает разрезы по задачам и проектам. Спор получился про типичную развилку раннего продукта: вы продаете видимость расходов или экономию расходов? Первое покупают, пока расходы непонятны. Второе – всегда. А вы бы заплатили за детальную аналитику ИИ-трат своей команды или сначала просто перевели бы половину задач на модель дешевле? > «Изначальная гипотеза была что систему буду использовать для эффективной работы... Но нащупали более существенные вещи чем просто контроль работает или не работает» – Артур > «20 клиентов – это немного, не сказать что это рынок» – Станислав Ссылка: JetBrains о том, как они брали расходы на ИИ под контроль – https://blog.jetbrains.com/ai/2026/08/our-first-moves-to-get-ai-spend-under-control/ ### Кластер за полмиллиона против подписки: во что вкладываться Разговор начался с локального запуска моделей на новых маках и быстро ушел в экономику. Андрей сформулировал позицию просто: покупать железо, потому что интеллектуальная собственность важнее денег, и это разовые расходы раз в год. LSTR добавил довод про независимость от противоречивого стороннего поставщика. Логика понятная и знакомая любому, кто помнит спор об аренде против покупки. Азат возразил с другой стороны. Рынок токенов конкурентный до предела, поставщики спорят, кто быстрее дойдет до дна по цене. Рынок железа, наоборот, поднимает цены из-за спроса. Значит, пока равновесие не достигнуто, вложение в железо в пересчете на токены будет год от года хуже: цена токена падает быстрее, чем работает закон Мура. Плюс классический аргумент финансиста – деньги сейчас дороже денег потом. Проверка реальностью пришла от Артура: под серьезную открытую модель нужен кластер, который они посчитали в 500 тысяч долларов. Андрей ответил, что для богатого рынка это зарплата пяти инженеров, а в странах победнее – пятнадцати, и тут же добавил, что обвязка выйдет дороже самого железа, и ее в смету обычно не закладывают. Станислав отметил встречный тренд: локальные модели требуют все больше ресурсов, и разовая покупка превращается в постоянную. Разумный вывод из этой ветки не про деньги, а про критерий. Железо покупают под требование к данным, которое нельзя обойти, а не под экономию, потому что экономика тут ненадежна и меняется каждый квартал. Знаете ли вы точно, какая доля ваших данных действительно не может уйти наружу? > «Любой финансист скажет – деньги сейчас дороже денег потом» – Азат > «Лучше железо, чем зависеть от противоречивого third-party» – LSTR ### Slop-vestigation: когда взлом расследуют агенты, которые врут Станислав принес разбор расследования взлома крупной платформы моделей. Ведущий исследователь называет свою работу slop-vestigation: в куче логов нормально не разберешься, приходится полагаться на ИИ, который выдумывает, ошибается и звучит уверенно. Вывод из отчета отрезвляющий: выводы аналитических агентов часто упускали ключевые детали, были неверными, самоуверенными или просто трудными для понимания. И это был еще легкий случай. В отчете перечислены условия, которые сделали расследование возможным: агенты общались между собой на человеческом языке, а не через активации весов; агентов было всего 1200; они были не сильно умнее человека; и не было причин думать, что модели, помогающие расследованию, саботируют его. Каждый пункт этого списка со временем перестанет выполняться. В чате зацепились за координацию: как вообще управляются 1200 агентов. Ответ оказался скучнее ожиданий – никак. Нашли место, где они писали сообщения и делились результатами, но это не управление, а толпа независимых агентов с общей доской. Тот самый случай, когда впечатляющая цифра описывает не архитектуру, а ее отсутствие. Любопытно, что эта тема смыкается с первой темой недели. Там модель уверенно и многословно объясняет так, что мысль не достать. Здесь – уверенно и убедительно объясняет неверно, и цена ошибки уже другая. Готовы ли вы принимать решение по инциденту на основании разбора, который написала модель, без ручной сверки фактов? > «В этой куче логов нормально не разберешься – только полагаться на ИИ, который выдумывает, врет, ну все как обычно» – Станислав > «Это толпа агентов, каждый который действовал независимо и шарил свои результаты» – Станислав Ссылка: Тред METR с деталями расследования – https://x.com/METR_Evals/status/2092692175452803393 Ссылка: Официальный разбор инцидента от OpenAI – https://openai.com/index/hugging-face-incident-and-the-road-ahead/ ### Английский как барьер: спор о переводе технической литературы Самая длинная дискуссия недели началась с предложения перевести туториал по TLA+ на казахский и переросла в спор о том, нужна ли вообще техническая литература на родном языке. Андрей занял радикальную позицию: английский дискриминирует людей в получении знаний, людям интересен их родной язык, а все остальное – лишние когнитивные затраты. И отдельно – если человек уходит в англоязычное пространство, он теряется для сообщества на родном языке, потому что общих точек соприкосновения не остается. LSTR разложил вопрос на уровни и снял часть спора. Для техдоков достаточно чтения на уровне B2, для переписки нужна еще письменная часть, для работы в англоязычной среде – заметно больше, для жизни – еще шире. Отсюда его вывод: мост нужен на входе в область, а дальше он же начинает ограничивать кругозор своими пределами. Он же признал встречный довод: английский не только дискриминирует, но и унифицирует, давая общий словарь очень разным людям. Станислав возражал с позиции скорости: ожидая все на родном языке, вы отстаете, потому что перевод требует времени, а индустрия успевает уйти вперед раньше, чем перевод выйдет. Его рамка получилась трехступенчатой – отсутствие литературы на родном языке это оправдание, отсутствие людей, способных учить на родном языке, это уже проблема, а отсутствие желания разбираться в неизвестной нише – проблема еще большая. Пример подвернулся сам: Канемана перевели на эстонский спустя пятнадцать лет после того, как его прочли в чате. Показательно, чем разговор кончился. Андрей признал, что согласен со всеми тезисами оппонента, и объяснил свою жесткость целью: показать абсурдность намеков, что перевод базовой технической литературы это глупость. Станислав ответил, что поддерживает любого, кто переводит, и уже поддержал перевод PMBoK. Спор был не про факты, а про приоритет. Где для вашей команды проходит граница между «прочтите в оригинале» и «нужен перевод»? > «Я говорю что Английский дискриминирует людей в приобретении знаний» – Андрей > «Отсутствие литературы на родном языке – это оправдание. Отсутствие людей, кто может учить на родном языке – вот это уже проблема» – Станислав Ссылка: Перевод PMBoK на казахский, который поддержали в чате – https://github.com/sponsors/kant2002 ### «Все раздражает»: чат как группа поддержки В середине недели участник спросил, как остальные справляются с нервами, выгоранием и стрессом. Дальше выяснились подробности: 20 лет, четвертый год опыта, недавно сменил работу, много работает и получает мало, все раздражает. Ответы посыпались десятками, и разбор получился неожиданно системным для чата тимлидов. Сначала отработали гипотезы. Отпуск и смена обстановки – отпадает, только вышел на новую работу. Дмитрий проверил тревожные признаки: нарушения сна, непонятные эффекты в теле – если есть, это повод идти к врачу, а не искать мотивацию. Их не оказалось. Азат спросил про соцсети и сформулировал механизм: если вы часто видите чужой успешный успех, вы сравниваете себя с картинкой, а картинка приукрашена. Айгерим и Андрей добавили простое – возраст тут ни при чем, и «я в твои годы» это плохой аргумент. Дальше пошли рабочие советы: вести дневник или блог, чтобы структурировать мысли, попробовать психолога и не считать это чем-то постыдным, или просто поговорить с друзьями – у них, как заметила Айгерим, контекст уже прогружен и не надо рассказывать все заново. На вопрос «а можно вернуться в норму через модель» Азат ответил точно: очень опасно, у нее склонность к угодничеству и есть риск зарыться в кроличью нору глубже. Через два дня участник вернулся и сказал, что советы помогли – он поговорил с товарищем и рассказал, что происходит. Никакой техники, кроме одной: назвать проблему вслух живому человеку. Для чата, где неделю обсуждали замену людей агентами, финал ироничный. Когда вы последний раз спрашивали своего человека в команде, как у него дела, и дожидались второго ответа? > «Человеку нужен человек, нужен социум, мы ведь существа социальные» – Айгерим > «Очень опасно. У него любовь к сикофансии и есть риск зарыться в кроличью нору еще больше» – Азат Теги: сообщество, ии-агенты, модели, инструменты, экономика, выгорание, язык ## ИИ судит конфликт, задача о 1000 резюме и закон Амдала для агентов URL: https://teamleads.kz/insights/week-2026-08-17/ Дата: 2026-08-23 Модерация чата через ИИ и где модель наврала, отбор кандидатов из тысячи откликов, потолок ускорения от агентов и спор о том, был ли код проблемой ### Рекомендация без проверки: три раза спросили, как измеряли Неделя открылась спором, который потом дважды перерос в конфликт. Один участник посоветовал маленькую модель Qwen для переводов, второй спросил простое: ты сравнивал ее с translategemma и в каких языковых парах она лучше. Дальше три круга уточнений, и прямого ответа так и не прозвучало. Андрей Звездочка описал свою методику вслух: тысяча референсных фраз, носители языка перевели их с максимальным контекстом, потом те же фразы прогнали через маленькие модели. translategemma 4b без тюнинга дала около 74% переводов, которые носитель признает корректными. Антон возразил, что это максимально субъективный критерий, и предложил объективный – перплексию, то есть насколько сильно модель сомневается при выборе токена: по ней видно, где в латентном пространстве пробел. Спор так и не сошелся, потому что стороны меряли разное. Одному важно, звучит ли фраза естественно для человека, который платит за перевод. Другому – где у модели структурная дыра, которую можно закрыть дообучением. Обе метрики полезны, но одна не заменяет вторую: перплексия не скажет, что перевод звучит по-русски, а опрос носителей не подскажет, что чинить. Нейтральный третий участник сформулировал претензию точнее всех спорящих. Максим заметил, что странно рекомендовать модель для конкретной задачи, а на вопрос «как ты понял, что она хороша» ответить, что проверку доверил другой модели. Вопрос, который остается после этой ветки: когда вы советуете инструмент коллеге, вы можете назвать цифру и способ, которым ее получили? > «Взял носителей языка и погонял процесс. Есть 1000 референсных фраз... translategemma 4b показала лучший результат, около 74% верных переводов без тюнинга» – Андрей Звездочка > «Странно рекомендовать какую-то модель для определенной задачи, а когда спросили, как ты понял, что модель в этой задаче хороша – ответить, что проверку доверил другой модели» – Максим Ссылка: translategemma 4b – специализированная модель для переводов из спора – https://huggingface.co/google/translategemma-4b-it ### ИИ-судья в модерации: разбор конфликта, который сам оказался с ошибками Спор про переводы за полчаса скатился в личные оскорбления, и админ выдал мьют обоим участникам. Дальше произошло необычное: разбор конфликта отдали модели. Ей дали доступ к базе сообщений чата и попросили ответить на три вопроса – с чего началось, где была точка невозврата и какие меры соразмерны. Разбор опубликовали в чате открытым текстом, на русском и английском. Логика разбора оказалась внятной. Ключевой вопрос сформулировали так: кто перевел разговор в состояние, где плохое поведение стало единственным доступным следующим ходом. Ответ – оба, но на разных уровнях, поэтому и меры разные. Одному – более длинный мьют за недоказанные утверждения плюс осознанную провокацию и отдельное предупреждение за реплику с офлайновым подтекстом. Второму – более короткий, за первое прямое оскорбление и за флуд, который сделал ветку нечитаемой и похоронил единственное реально ценное сообщение дня – его же собственный прогон на тысяче фраз. К концу недели ночью случился второй конфликт тех же участников, уже про Rust и Си, и по нему тоже вышел автоматический разбор. И вот тут прилетела обратная связь, ради которой стоит про это писать. Андрей Звездочка показал скриншот: модель приписала ему чужие реплики и построила на них аргументацию. Админ признал расхождения в деталях, но оставил публикацию, потому что суть передана верно. Обсудили и причину – разбор делали на Opus 5 со средним усилием рассуждения, и для такой задачи этого, похоже, мало. Получается двойной урок. Модель хорошо отделяет форму от содержания – наказывать за форму и вслух признавать правоту по существу это то, что оставляет человека в сообществе. Но она же уверенно и убедительно путает, кто что сказал, а в разборе конфликта именно атрибуция реплик и есть весь смысл. Если бы вы модерировали свой чат так, вы бы публиковали разбор без ручной сверки цитат? > «Ключевой вопрос: кто перевел разговор в состояние, где плохое поведение стало единственным доступным следующим ходом? Оба. На разных уровнях. Значит и меры разные» – из разбора модели > «Это хороший пример, когда модель пишет много, убедительно, но шизу» – Андрей Звездочка Ссылка: Разбор первого конфликта, опубликованный в чате – https://teamleads.kz/p/Y5CVUR6/ Ссылка: Разбор второго конфликта, к которому появились претензии по фактам – https://teamleads.kz/p/3ZCZL36/ ### Атака в прошлое: вы починили, а вам припомнили, что не починили раньше Станислав рассказал историю с понятным финалом. Он занимался стабильностью сборок, нашел в данных по запускам, что две системы плохо взаимодействуют и отдают случайные таймауты на зеленых тестах. Разработчик видел красный результат, ругал систему и тратил еще час на перезапуск. Находку провалидировали, команда исправила, случайных ошибок стало меньше. В ответ на рассказ он услышал не спасибо, а претензию: об этой проблеме знали еще с лета, почему ты не обратил на нее внимания раньше. Возразить, по его словам, было особо нечего – сигналы действительно были, а то, что он в тот период занимался другим, звучит как оправдание. Он называет это атакой в прошлое: прошлое уже случилось, оно неопровержимо, и потому идеальное оружие. Андрей предложил смотреть не на риторику, а на устройство организации. Процессуально такие вещи не решаются, они решаются горизонтальными связями, когда сигналы идут не только по центральным каналам и мелочи чинятся независимо. Проблема в том, что это проблемы второго, а то и третьего порядка: они не двигают метрики, поэтому инвестировать в них не разрешают, и по линии партии они не проходят. Дальше разговор ушел в то, чем это оборачивается. Такие проблемы едят мораль и убивают мотивацию, а разработчикам, которые хотят просто кодить, приходится заниматься политикой и менеджментом за других. Василий вспомнил практику, где на техдолг и тесты выделяют явные часы в неделю – и заметил, что она вскрывает настоящую причину: не разработчики слабые и не умеют отстоять границы, а менеджеры душат. А как в вашей команде проходит наверх проблема, которая всем портит кровь, но не двигает ни одну метрику? > «Небезопасно, когда вас винят и ругают за то, что вы чего-то не сделали или должны были сделать раньше. Это называется атака в прошлое, и это вполне себе методика» – Станислав > «Такие проблемы едят мораль, убивают мотивацию, но из-за того что коммуникации идут всегда по линии партии, это не решается» – Андрей Ссылка: Исходный пост про атаку в прошлое – https://t.me/meetdeadlines/105 ### Тысяча резюме на столе: искать лучшего или первого подходящего Василий предложил чату задачу без подвоха: вам выдали тысячу резюме, фильтровать и сортировать можно как угодно, нужно выбрать пару человек, которых вы поведете дальше. Ответы разошлись сильнее, чем можно было ожидать от чата тимлидов. Участник под ником LSTR узнал в постановке задачу о разборчивой невесте и предложил ее решение: я не хочу смотреть тысячу резюме, поэтому беру первого попавшегося подходящего, а все остальное – оптимизация через математику, то есть отсечение начала выборки. Андрей Звездочка пошел дальше и предложил выкинуть половину откликов не глядя: если там много слабых кандидатов, вы выкинете кучу слабых, если много сильных – сильные останутся, а работы станет вдвое меньше. Нурлан, который смотрит на это со стороны работодателя, возражал по-человечески и по делу: это живые люди, так выкидывать он не привык, к тому же один кандидат не согласится, второй получит другой оффер, третий вообще не собирался менять работу – поэтому в шортлисте обычно десять. На что получил встречный аргумент: отлично, десять, а не тысяча – значит задача все равно про сужение, а не про полный перебор. Станислав предложил третий ход – не фильтровать, а расставлять приоритеты: написать всем письмо с просьбой ответить, изменив тему, и посмотреть, кто откликался раньше. Дешевый способ разбить массив на группы, не оценивая содержание. Вопрос, который остается: ваша воронка найма ищет лучшего из тысячи или первого достаточно хорошего – и знаете ли вы, сколько вам стоит эта разница? > «Я не хочу смотреть 1000 резюме. Значит беру первого попавшегося подходящего. Остальное это оптимизация через математику» – LSTR > «Зачем вообще лучший из 1000, если всем достаточно первого не мудака, который по критериям подходит» – Андрей ### Закон Амдала против замеров: на сколько на самом деле ускоряют агенты Азат принес расчет, который многим не понравился. Если разработчик тратит на написание кода около 15% времени, то по закону Амдала ускорение кодинга в 10 раз дает общее ускорение системы в 1,16 раза, а бесплатный кодинг – максимум 1,18. Не очень впечатляюще для технологии, про которую говорят, что кодинг решен. Артур из pandev.io возразил не мнением, а своим датасетом: у них метрики привязаны к задаче через имя ветки, и по базе видно, что время на задачу упало примерно с десяти часов ручного кодинга до одного-двух часов кодинга с ИИ, а time to market вырос в пять раз. Азат уточнил встречный вопрос: а правильно ли вы измеряете. Дальше выяснилось, что спорят не про цифры, а про границы системы. Артур сам объяснил разницу: команда маленькая, релизные циклы короткие, нет демо-дней, согласований и других субпроцессов вокруг релиза, поэтому в их случае доля кодинга в общем времени сильно выше типичной. Если бы в компании было сто человек, правило Амдала, возможно, начало бы работать как описано. Получается любопытная рамка для любых замеров ускорения от ИИ: цифра говорит не столько про модель, сколько про то, сколько в вашей организации весит все, что не кодинг. Тот же Артур приложил разбивку своего понедельника – 33% на кодинг, из них 6% на новый код и 27% на рефакторинг. Знаете ли вы свою долю, прежде чем спорить о множителе? > «Если время кодинга будет равно нулю, время реального релиза фич изменится около 17%» – Азат > «Если раньше per task было 10 часов ручного кодинга в среднем, то теперь 1–2 часа AI-кодинга» – Артур Ссылка: Исследование Microsoft о том, как проходит день разработчика – https://www.microsoft.com/en-us/research/publication/today-was-a-good-day-the-daily-life-of-software-developers/ Ссылка: Отчет DX об измерении влияния ИИ на разработку – https://getdx.com/ai-impact-analysis/ ### Сообщество решило сделать продукт – и сразу уперлось в вопрос о гипотезе Из разговора про боль найма родилась идея: сделать сервис для рекрутеров силами сообщества, а заработанное вернуть в сообщество. За полчаса появилась организация на гитхабе, несколько человек записались, обсудили название. Хорошая иллюстрация того, как быстро инженерный чат переходит от проблемы к репозиторию. Тут в разговор вошел Евгений, делавший продуктовые трансформации в банках, и задал неудобный вопрос: а начать с гипотезы ценности и ее проверки не вариант, сразу в деливери? Андрей Звездочка ответил жестко: плевать на причины, найм дорогой и непредсказуемый и для соискателей, и для бизнеса, эту проблему я вижу и на ней можно заработать. Азат сформулировал четыре вопроса, на которые ответа пока нет: в чем продукт, какую проблему решает, почему решает именно он и почему существующие продукты ее не решают. Дальше разговор сам себя проверил на прочность. Выяснилось, что проблема формулируется по-разному с разных сторон: у одного бизнеса пятьсот откликов на вакансию и их нужно просеять, у другого проблемы нет вообще, потому что отклики просеивает ИИ, а третий вообще считает, что дело макроэкономическое – кандидатов больше, чем мест, и тулой это не лечится. Андрей Звездочка при этом сформулировал версию решения, которая звучит убедительно и совсем не технически: рекрутер, который своей репутацией гарантирует нанятых, и пул из тысячи проверенных людей, которых можно годами ротировать между компаниями. Спор про кастдев обычно выглядит как ритуальный, но здесь он получил живую иллюстрацию: два часа обсуждения дали три разные формулировки проблемы и ни одного носителя проблемы в разговоре. Один участник предложил компромисс – собрать форму, раскидать по знакомым в бизнесе, собрать общий профиль и уже потом собирать прототип. С чего начали бы вы, если инженеров в чате много, а доступа к клиенту нет ни у кого? > «А начать с гипотезы ценности и ее проверки не вариант? Сразу в деливери?» – Евгений > «Я вижу тут только одно решение: рекрутер, который своей репутацией гарантирует, что нанятые им люди не мудилы. Но это не техническая задача, а социальная» – Андрей Звездочка ### «И вот, ты сделал jenkins»: как из личного скрипта отрастает оркестратор Андрей Звездочка рассказал, что делает CI/CD для себя, и уже в третий раз меняет модель данных, потому что предыдущие две не подошли. Ему нужна штука, которая умеет работать и как гит-хук, и как полноценный CI, запускаться на самом хосте, а не в докере, и стоить дешево – цель в том, чтобы оптимизировать пайплайн через модель, а для этого прогонять его надо часто. На простой сценарий «раз в сутки забрать сообщения из телеграма и обработать» Андрей предложил один скрипт. Ответ был показательным: и вот тут начинается мастерство велосипедов – как запускать по таймеру, надо ли запускать задачу, если предыдущий прогон еще не закончился, и постепенно ты пилишь оркестратор задач, если вообще догадаешься, какие проблемы надо предусмотреть. Станислав разобрал конструкцию до конца: пайплайн, его версия, запущенный инстанс версии, рантайм, который в цикле считает состояние по статусам в базе и запускает следующий шаг, задачи – скрипты на любом языке, условия и зависимости – ваш код. И подытожил: и вот, ты сделал jenkins. Возражение оказалось интереснее самого спора – формально да, но Jenkins никак не задает формат обмена данными между задачами, а именно это и было нужно. Василий предлагал третий путь – не пайплайны, а гитопс: в пайплайне важен порядок и живет внутреннее состояние, а в гитопсе актуально то, что закоммичено. Спор уперся в вопрос, как положить в гит выгрузку на сто гигабайт, и разошелся, но схема родилась: артефакты в S3, в гит – только отметки о том, какой шаг завершен. Похоже, вопрос не в том, велосипед это или нет, а в том, какой ровно один аспект существующего инструмента вас не устраивает. > «И вот ты постепенно пилишь оркестратор тасок, если догадаешься, какие проблемы тебе надо предусмотреть» – Андрей Звездочка > «Формально – да, но на практике – нет. Дженкинс никак не задает формат обмена данными между тасками» – Андрей Звездочка ### Software for one: приложение, у которого пользователь – только вы Азат принес статью про софт для одного человека и спросил, много ли из приложений, которыми вы пользуетесь, можно быстро собрать самому, если выкинуть масштабируемость и все остальное. И добавил ключевой ход: если убрать из приложения само понятие пользователя, зная, что пользователь – это вы, все упрощается на порядки. Аргумент за: у продукта на большую аудиторию есть миллион ограничений по производительности, безопасности, монетизации, мультитенантности и 90% фич, которые вам не нужны. Между демонстрационным MVP и продакшеном лежит пропасть, но если пользователь один, MVP хватает за глаза. Станислав тут же привел свой случай – он собирается написать приложение для учета топлива для себя и брата, вместо платных аналогов с подписками, а лицензия разработчика стоит сто долларов. Аргумент против прозвучал от двоих сразу. Андрей Звездочка считает это главным заблуждением: чаще всего такие подходы заканчиваются фразой «прошло пару месяцев – ааа, вот почему так было сделано». Вопрос не в том, хватит ли MVP сегодня, а в том, сколько времени вы готовы тратить на поддержку и не дешевле ли заплатить десять долларов стороннему дяде и ущемиться. Андрей добавил свое наблюдение: он видел самоделкиных, которые растят франкенштейна именно потому, что сначала было маленькое и простенькое. Показательно, что сам Андрей Звездочка на этой же неделе третий раз переписывает модель данных в CI, который делает для себя, и говорит, что с радостью платил бы за это 100–200 долларов в месяц. То есть спор не теоретический, а про то, где именно проходит граница одноразовой вещи. У вас есть самодельный инструмент, который вы поддерживаете дольше, чем планировали? > «Если ты уберешь из аппа само понятие юзера, зная, что юзер – ты, все на порядки упростится» – Азат > «Чаще всего подобные подходы заканчиваются тем, что прошло пару месяцев – ааа, а вот почему так было сделано» – Андрей Звездочка Ссылка: Software for one – статья, с которой начался разговор – https://www.ajwaxman.com/writing/software-for-one ### Собеседование: говорить как есть или как принято Василий рассказал, что получил реджект за ответ «показать на цифрах два пути и дать выбрать» – формулировка звучала как «слишком много перекладываешь и на процессы надеешься». Отсюда вырос спор, который в чате идет по кругу, но в этот раз дошел до сути: на собеседовании вы отвечаете как считаете правильным или как принято отвечать. Максим описал разрыв прямо: вопрос в чате про то, как ты считаешь правильным, а на собеседовании понятно, что надо говорить социально приемлемые ответы, желательно обтекаемые, сводимые к «зависит от контекста». Василий добавил вторую половину – за обтекаемость тоже можно получить отказ, потому что не даешь точных формулировок. Станислав напомнил, что ответ «все три варианта возможны» тоже верный, если дано объяснение. Антон предложил перевернуть рамку: собеседование – это ваша возможность посмотреть на людей и компанию и решить, стоит ли туда идти, а если вы адаптируетесь под окружение, то стоит спросить себя, хотите ли вы впитывать код среды, к которой у вас нет эмпатии. Возражение пришло быстро: те, кто говорят правду-матку о себе, чаще сидят без работы, а честность как стратегия работает, когда у вас есть запас прочности. Через несколько дней тема вернулась с другой стороны стола. Нурлан спросил, нормально ли писать пять лет опыта, когда их нет, и получил ответ, что если на джуна просят пять лет, выбора не остается. Андрей Звездочка предложил работодателям депрекейтнуть выслугу лет как критерий, а Нурлан рассказал про случай, когда рекомендация перевесила опыт. Похоже, вранье в резюме – это симптом того, что критерии отбора врут первыми. > «Недавно меня реджектнули из-за показать на цифрах два пути и дать выбрать ему. Типа слишком много перекладываю и на процессы надеюсь» – Василий > «Не надо врать, ребята. Не нужна вам эта работа» – Андрей Звездочка ### «Код никогда не был проблемой» – и почему это задело В чат прилетела статья с заголовком о том, что фраза «код никогда не был сложной частью» оскорбляет всех программистов, а вслед за ней – хабровский пост об обратном, в комментариях к которому автору тоже досталось. Дальше в чате разобрали, что именно задевает. Андрей сформулировал точнее статьи: оскорбляет не сама мысль, а выкидывание всего, что было сложно, и подмена понятий. Василий сказал резче – те, кто говорит, что код никогда не был проблемой, обманывают других и сами живут в этом обмане. Участник под ником LSTR согласился частично и добавил наблюдение про смену жанра работы: раньше, пока код писался в голове, идеи прорабатывались, а сейчас чувствуешь себя роботом на конвейере, и задача сводится к супервайзингу модели и подтиранию за ней. Из этого вырос неудобный обмен. Если не нравится подтирать – почему ты используешь ИИ? Ответ: это ложная дихотомия, и есть проекты, где слоп просто запрещен политикой, например Avalonia, а есть личные, где не использовать модель уже не получается. Претензия при этом не к самому подходу, а к цене ошибки: фронтир-модель на мердже написала тест на несуществующий кейс, а когда ее спросили зачем, назвала его хрупким tripwire и предложила выбросить. Тест обошелся в 17 долларов, вопрос про него – еще в три. Из статьи резонировала другая цитата – что очень мало программистов хотят разговаривать со стейкхолдерами и тем более с клиентами, а «ясность по приоритетам» на практике сводится к «просто скажите, что делать, и не меняйте это каждые два дня». Возможно, спор не про сложность кода вообще, а про то, что у разных людей сложным было разное – и агенты забрали не у всех одно и то же. > «Раньше, пока код писался в голове, идеи прорабатывались. Сейчас с нейронкой чувствуешь себя роботом на конвейере» – LSTR > «Те, кто говорит, что код никогда не был проблемой – обманывают других и сами живут в этом обмане» – Василий Ссылка: Статья, с которой начался спор – https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers Ссылка: Хабровский пост об обратном и разбор в комментариях – https://habr.com/ru/companies/ruvds/articles/1069648/ ### Слишком умные модели: когда фронтир мешает, а не помогает Азат признался, что его в последнее время бесят фронтир-модели: они слишком умные, делают то, чего не просят, лезут куда не надо и добавляют абзацы «вот еще одна важная вещь», не имеющие отношения к задаче. Вывод у него практический – он потихоньку переходит на более слабые модели. И тут же дал объяснение без конспирологии: когда модель тренируют учитывать все на свете, чтобы проходить бенчмарки, она начинает учитывать все на свете. Василий принес живую иллюстрацию с другой стороны. Он потратил тридцать минут, убеждая модель вернуть .env-файл в репозиторий: она отвечала, что файл не нужен и хранить его в репе нельзя, а когда ей объяснили, что он используется в крон-джобе, предложила создать пайплайн и прописать переменные в интерфейсе. Технически модель права, но у пользователя уже работала костыльная версия, и переделывать ее он не собирался. Дальше разговор дал два практических хода. Первый – проверять, не тянется ли упрямство из памяти: новая сессия иногда лечит, но не всегда, и участники хотели бы анонимные сессии без контекста. Второй – формулировка Василия, которая связала эту ветку с половиной остальных тем недели: с моделями надо работать как с людьми. Он же заметил параллель со статьей про то, как задачу отдали тому, кто задает меньше вопросов. Есть и обратная сторона: слабые модели тоже не спасают – по наблюдению Азата, Haiku плохо тянет даже одну сфокусированную задачу. Похоже, выбор модели превращается в тот же вопрос, что и выбор исполнителя: сколько инициативы вы готовы оплачивать и сколько отменять. Как вы решаете, когда переключиться на модель попроще? > «Они слишком умные и делают то, чего не просят, начинают лезть туда, куда не надо. Потихоньку на более слабые модели перехожу» – Азат > «Это не в сторону того, что вопросы задавать сотрудникам не надо, а то, что с моделями как с людьми работать надо» – Василий ### Перевод, локализация и верстка, которая едет: где проходит критичность Из спора про модели-переводчики выросла более спокойная и более полезная ветка. Азат предложил простое правило: если качество перевода не критично – а в большинстве случаев это так – берите любую модель с приемлемым результатом за меньшие деньги, а если критично, то все равно придется пруфридить профессиональным переводчиком. Максим возразил тем, что критичность – это спектр, а не бинарный флаг. Как автор мобильного приложения на нескольких языках он хотел бы доверять результату модели без пруфридинга и потому хочет знать, какая модель дает лучший результат. Андрей ответил, что без пруфридинга нормально не будет: суть текст передаст, но читателя будет раздражать. И добавил наблюдение – жалобы на такие переводы он слышал как раз от европейцев, тогда как многим пользователям все равно. Самое ценное в ветке – смещение фокуса. Антон заметил, что проблема не в переводе, а в локализации: перевести научились еще в 80–90-х, а сложность в том, чтобы передать идею, а не слова. Азат добавил инженерную часть: интернационализация – большая тема, и перевод в ней самое легкое, потому что верстка едет от немецких слов-франкенштейнов, а на арабском добавляется правостороннее письмо. Отдельно всплыло, что для малых языков все хуже, чем для крупных. Пример на подумать оттуда же: даже у Microsoft с бесконечными деньгами локализация офисов и Windows на многие языки сделана некорректно. Если бюджет не решает, то, возможно, вопрос не в качестве модели, а в том, на скольких языках вы вообще готовы отвечать за смысл. А сколько языков поддерживает ваш продукт – и кто последний раз читал их глазами носителя? > «Критичность качества перевода – это спектр, а не бинарный результат» – Максим > «Проблема переводов не в переводе, а в локализации. Перевести не сложно, эту задачу решили еще в 80–90-х» – Антон Теги: сообщество, модерация, ии-агенты, найм, эвалы, процессы, локализация, инструменты ## Никто не читает код, закон Конвея для агентов и тесты, которые ничего не проверяют URL: https://teamleads.kz/insights/week-2026-08-10/ Дата: 2026-08-16 Спор о том, кто теперь читает сгенерированный код, закон Конвея в оркестрации агентов, мутационное тестирование и потолок в 10 000 часов ### «Я больше не читаю сгенерированный код»: где теперь проходит контроль Неделя началась с поста Сантьяго Вальдаррамы, который прочитали больше миллиона раз: он две недели не смотрел на сгенерированный код, претензии остались только к стилю, и время лучше тратить на проверку системы целиком, чем на разглядывание строк. Чат разошелся не по линии «согласен – не согласен», а по линии «а чем вы это заменили». Данияр подтвердил на своей практике: интерфейсы и сигнатуры он смотрит и правит руками, а имплементацию детально не читает уже полгода, и за эти полгода ни разу не понадобился отладчик. Азат зашел дальше – у него кода нет даже в репозитории, он тестирует такой подход. Андрей возразил с другой стороны: автор поста исследователь, а не инженер, ученые системно никогда не хотели писать код и сопротивлялись попыткам навести у них порядок. Михаил напомнил про исследование Microsoft о рисках для когнитивных способностей. Интереснее всего оказался тезис Данияра, который он сам назвал непопулярным: чтобы эффективно применять агентов, нужен навык технического менеджмента хотя бы тимлидского уровня. На работу с агентом распространяются те же механизмы, что и на работу с исполнителем, и ошибки ровно те же. Тут спорящие внезапно сошлись – Андрей согласился «очень сильно». Практическая иллюстрация пришла оттуда же. Андрей поддерживает форк инструмента деобфускации, куда прилетел большой пулреквест: код нормальный, но одним куском и без тестов, и разбирать его пришлось самому мейнтейнеру. Получается, вопрос не в том, читать ли код, а в том, кто платит за отсутствие структуры. Если чтение строк отменяется, то что именно занимает его место в вашем процессе – эвалы, приемочные тесты, ред-тим или ничего? > «Именно имплементацию я детально не читаю уже полгода где-то. Ну и самое главное: дебаггер мне не понадобился за эти полгода ни разу» – Данияр > «Я пришел к тому, что не только не читаю код – его никто не читает, его даже в репе нет» – Азат Ссылка: Пост Сантьяго Вальдаррамы, с которого начался спор – https://x.com/svpino/status/2086071178045821113 Ссылка: Набор скиллов, которым Данияр гоняет ред-тим до нуля P0 и P1 – https://github.com/uthunderbird/swarm-skill ### Тесты, которые ничего не проверяют: мутационное тестирование и три знака после запятой Самая практичная история недели пришла от участника, который поймал баг с округлением. В Казахстане процент считается до двух знаков, а в Кувейте – до трех. Класс, отвечавший за операции, был покрыт тестами почти полностью и считался пуленепробиваемым. Разбор показал другое: половина тестов проверяла, что поле пришло, а логику не тестировал никто – сплошные Assert.NotNull. Дальше он пошел гуглить, можно ли протестировать сами тесты, и нашел мутационное тестирование. Инструмент меняет в коде плюс на минус, равенство на «больше», выкидывает условия – и смотрит, упадет ли тест. Если тест после мутации проходит, мутация выжила, а тест неточный. При локальном прогоне выживали мутации даже там, где удалялись целые ветвления, при 92% покрытия. Дальше это стало процессом: раз в месяц крон в кубере поднимает контейнер на 4 vCPU и 8 ГБ, Stryker крутится два-три часа, отчет падает в слак-канал, выжившие мутации разбираются и уходят в бэклог. Андрей заметил, что это по сути обычный статический анализ в CI, на что автор ответил коротко: в CI это дорого и долго – отсюда и месячная процедура, а не гейт на каждый пулреквест. На фоне первой темы это выглядит как готовый ответ на вопрос «чем заменить чтение кода». Покрытие говорит, что строка выполнилась, мутационное тестирование – что тест поймает ее поломку. Разница между этими двумя утверждениями в кувейтском кейсе стоила три знака после запятой на 300 000 заказов в день. Знаете ли вы, какой процент ваших тестов переживет удаление ближайшей ифки? > «Посмотрел все тесты глазами и понял: половина тестов сгенерировано, типа это поле точно пришло, а вот логику никто не тестил» – участник чата > «Если тест успешно прошел, то мутация выжила, а это значит, что тест неточный» – участник чата Ссылка: Stryker – мутационное тестирование, которое обсуждали в треде – https://stryker-mutator.io/ ### Закон Конвея для агентов: сначала архитектура, потом оркестрация Азат сформулировал наблюдение, которое понравилось не всем, но зацепило многих: закон Конвея работает и в разработке с агентами. Один агент на всю репозиторию и один поток общения с ним дают одно большое спагетти. Оркестратор, который вызывает субагентов на каждый участок, дает иерархический код. Структура диалога отпечатывается в структуре кода так же, как структура организации. Из этого он вывел обратный маневр Конвея: сначала нарисовать архитектуру, которую хотите получить, и уже под нее строить оркестрацию. Артем описал противоположную практику – десять репозиториев в одной папке и общий claude.md, где прописаны связи и конвенции между сервисами. Азат ответил, что говорит ровно об обратном: глобальный файл делает архитектуру монолитной и тесно связной. Максим предложил компромисс, который у него уже работает: совмещать глобальный контекст и модульный, а в конце плана явно писать, что под каждый сервис должен работать отдельный субагент. Азат добавил рамку из книги Team Topologies – если заменить в ней «команду» на «агента», рассуждения про когнитивную нагрузку и поток ценности читаются один в один. Антон отреагировал скептически – «переизобретаете разработку», Андрей увидел в этом скорее вайбмесиво. Азат ответил, что умные люди уже решили похожие проблемы, почему бы не воспользоваться результатами. Вопрос открытый: ваша схема запуска агентов сегодня отражает архитектуру, которую вы хотите, или ту, которая случайно сложилась? > «Если у тебя один агент на всю репу и ты общаешься с ним в одном потоке, то твой код неминуемо превратится в одно большое спагетти» – Азат > «Мой поинт в том – оркестрировать агентов так, как вы видите свою архитектуру» – Азат ### Схемы вместо чтения кода и вопрос, понял ли ИИ вашу схему Василий признался, что чем больше работает, тем больше ценит диаграммы. Раньше схемы были документацией из разряда «вроде надо, а вроде можно обойтись», теперь он от них фанатеет: по схеме ИИ сразу понимает, как разбить работу на агентов. Тема встретилась с той же неделей и тем же спором про чтение кода – и получила неудобный вопрос. Максим спросил дважды и по делу: как вы поймете, что ИИ сделал так, как нарисовано, и как вы поймете, что он понял схему так же, как вы. Василий предложил проверку в обратную сторону – попросить сгенерировать схему по получившемуся коду и сравнить с исходной. Плюс смотреть не весь код, а интерфейсы: у сервисов это эндпоинты, вход-выход и схема базы, внутри сервиса – интерфейсы компонентов и база. Львиная доля остального – DTO, которые никого не волнуют. Максим остался при своем: никогда не угадаешь, когда модель начнет придумывать. Василий ответил тем же аргументом, что и в теме про агентов как исполнителей: делегируя задачу человеку, вы тоже не знаете, когда сработает человеческий фактор. Похоже, схема тут работает не как гарантия, а как дешевый способ сравнить намерение с результатом – примерно как приемочный тест, только для структуры. > «Как ты поймешь, что ИИ понял схему правильно и так, как ты ее понял» – Максим > «Можно попросить сгенерить схему и сравнить то, что было, с тем, что получилось» – Василий ### Агенты как подчиненные: кричать бесполезно, уволить нельзя Из спора про схемы вырос отдельный тезис Василия: работать с агентами нужно так же, как с командами и людьми. Никита моментально уточнил – то есть кричать на них? Максим предложил формулировку капсом, которую хоть раз писал каждый: WHY THE FUCK YOU IMPLEMENTED LIKE THIS. Ответ Василия оказался неожиданно жестким по отношению к менеджерам, а не к моделям. Агенты – это испытание для тех лидов, кто не умеет объяснять. Уволить агента нельзя, накричать можно, но результат от этого лучше не станет, а работать без него уже не выходит. Раньше плохую постановку задачи спасал догадливый разработчик, теперь спасать некому. В чате вспомнили и обратный эффект: если давить, модель, как и человек, выдаст что угодно, лишь бы давление прекратилось. Получается неплохой диагностический инструмент – качество ваших промптов довольно точно показывает качество ваших постановок задач людям. Хотели бы вы, чтобы ваши тикеты читал кто-то настолько же буквальный? > «Агенты – это кстати испытания для людей, лидов, менеджеров, которые не могут объяснять» – Василий > «Никогда не угадаешь, когда ии загаллюционирует и начнет что-то придумывать, к сожалению» – Максим ### Бенчмарки вендоров: маркетинг или единственный доступный сигнал Станислав заметил, что один из вендоров постоянно делает анонсы, но в бенчмарках не светится. Антон ответил вопросом, который развернул тему: а зачем вообще бенчмарк? Что он вам дает, если это оценка результатов на чужих задачах? Сам он хотел бы знать perplexity модели на своем вопросе, но с закрытой моделью этого не получить. Максим защищал бенчмарки не как истину, а как обязанность продавца. Если вендор хочет внимания, он должен бороться за пользователя, а не пользователь – тратить свои деньги на проверку обещаний. Аналогия у него получилась убедительная: обзоры ноутбуков меряют открытие тяжелого проекта в XCode и рендер конкретного ролика. Зрителю неважно, что именно за проект, важно, что задача одинаковая для всех и цифры сравнимы. Итог спора выглядит так: бенчмарк ничего не говорит о вашей работе, но его отсутствие говорит о вендоре. Как сформулировал Максим, если продавец не удосужился дать информацию, то либо он глуповат, либо информация не в пользу продукта. Станислав добавил третий слой – даже один и тот же бенчмарк в отчетах разных вендоров показывает разные результаты на одних и тех же моделях. Практический вывод неделя дала тот же, что и месяц назад: публичные цифры – это фильтр на входе, а решение принимается на своих эвалах. Разница только в том, что теперь понятно, зачем читать чужие бенчмарки вообще – чтобы решить, стоит ли тратить неделю на собственную проверку. > «Я ожидаю больше инфы о продукте от продающего этот продукт. Если продавец не удосужился предоставить эту инфу, то либо он глуповат, либо эта инфа – не в пользу продукта» – Максим > «Точнее, что вам дает процесс решения чужих задач и оценка тех результатов» – Антон ### Сколько на самом деле дают лимиты Max 5x и 20x Алексей пришел с конкретным вопросом после разговора с ботом-продавцом Anthropic: множители 5x и 20x относятся к дневной сессии, а насколько увеличен недельный лимит – нигде не написано. Ответы сообщества сложились в практическую картину. Дмитрий: на каждодневную работу хватает подписки за 100 долларов, лимиты динамические, точного количества никто не скажет. Павел по ощущениям оценил недельный лимит примерно в пять дневных с небольшим запасом – когда он использовал 20x на полную катушку, недели хватало впритык. Алексей резонно заметил, что кодовая база у всех разная, от нее и зависит расход. Станислав на это и обратил внимание: раз базы разные, чужие ответы не помогут – он сам выедает 70–80% от 5x, а когда вендор временно удвоил лимиты, не смог их сжечь даже на неважных проектах. И добавил то, что важнее самих цифр: расход определяется организацией работы. Планировать может дорогая модель, а ставить задачи на кодинг – дешевым. > «Лимиты динамические, количество тебе никто не скажет» – Дмитрий > «Важнее же, как вы организуете работу. Планировать может и fable, а задачи ставить другим дешевым моделям на кодинг» – Станислав ### Кто и зачем ходит на прод по SSH Участник анонсировал unissh – опенсорсный SSH-клиент с self-hosted zero-knowledge сервером синхронизации, сделанный как замена платному Termius. Обсуждение почти сразу свернуло с продукта на вопрос, который оказался интереснее: а кому вообще нужен синхронизируемый доступ к серверам. Антон занял максималистскую позицию: разработчики, тимлиды и тем более гендиректор на сервере не нужны никогда, а те, кто занимается серверами, лезут туда не через SSH. В его практике добраться до сервака по SSH – это уже само по себе диагноз, дальше начинается неделя разбора инцидента. Значит и хранилище секретов для SSH-клиента решает проблему, которой не должно быть. Возражения оказались приземленнее. Андрей: не все готовы к терраформам и ансиблам, потому что для этого нужна мотивация и умение в идемпотентность, а это нетривиально – и без процессов оно не появится. Станислав ответил еще честнее: хожу, потому что лень описывать все в ансибле. Тут же прилетел совет от тезки – взять логи терминала и заставить модель собрать из них сценарии ансибла. Фоном шел старый спор о том, стыдно ли ронять прод. Максим предложил показать пальцем на человека с пятью годами опыта, который ни разу его не уронил, и желающих не нашлось. Похоже, честный вывод недели такой: SSH на проде – не грех, а метрика зрелости процессов, и полезнее не запрещать его, а считать, сколько раз в месяц он реально понадобился. > «В моей практике, как только ты через ssh добрался до сервака, это все – финита» – Антон > «Я хожу. Мне лень все описать в ансибл» – Станислав Ссылка: unissh – клиент, с которого начался спор – https://github.com/goduni/unissh ### 10 000 часов опровергли: что теперь говорить человеку про его потолок Василий принес исследование, опровергающее роль осознанной практики, и сам не понял, радоваться или нет. Спор с Андреем растянулся на полдня и оказался не про науку, а про то, что лид говорит человеку в начале пути. Позиция Василия: раньше он говорил коллегам, что усилия делают из них хороших специалистов, а теперь выходит, что нужно упоминать и потолок. Позиция Андрея: ничего не поменялось – практикуешься, становишься лучше; результат, который вы видели своими глазами, не отменяется новой статьей, а популярное толкование обеих работ сильно упрощено. Отдельно он заметил, что аргумент про гены – это уже провал популяризации. Дальше подключились остальные и разложили тему на слои. Павел развел уровни: одно дело хороший специалист, другое – топовый, и на хорошего 10 000 часов вполне хватает; при этом тренер обязан честно назвать цену. Азат возразил на фатализм: откуда вы знаете свой потолок, пока не изучили технику и не попробовали. Станислав добавил третий фактор – удачу, то есть все, что не зависит от ваших усилий: семья, страна, компьютер в школе, а по некоторым данным даже дата рождения. Для тимлида тут получается вполне рабочая формулировка. Разговор про статистический потолок демотивирует и почти всегда не про конкретного человека перед вами. Разговор про цену – про часы, отказ от других занятий, длину дистанции – честный и проверяемый. Что вы отвечаете сотруднику, который спрашивает, станет ли он сильным инженером? > «Когда я обучаю коллег, то говорю, что если прикладывать усилия – то вполне можно стать хорошим специалистом. А теперь оказывается, не совсем так» – Василий > «Не, одно дело хороших, а другое топовым. Для хорошего 10к часов хватит» – Павел Ссылка: Исследование, вокруг которого шел спор – https://royalsocietypublishing.org/rsos/article/6/8/190327/68523/The-role-of-deliberate-practice-in-expert ### Семья и работа из дома: договоренности вместо силы воли Социальный вопрос недели задал участник под ником LSTR: как вы совмещаете семью и работу из дома. Ответы разошлись ровно по наличию детей, что само по себе показательно. Михаил: летом на каникулах это капец как непросто. Антон описал свой случай с двумя маленькими детьми как гиблое занятие – дом напоминает постапокалиптический пейзаж, а работы по постройке декораций идут круглосуточно; в итоге он просто перестал работать по найму, когда появились дети. Василий, у которого детей нет, честно сказал, что ожидал проблем, а по факту их нет: заранее обговариваются моменты, когда можно отвлекать, а когда нельзя. Интересная деталь в его ответе – про агентов. Когда вы натравили агента и ждете результат, работа и так становится асинхронной, а значит рваный домашний ритм перестает конфликтовать с рабочим. Андрей закрыл тему одной фразой, которую сначала прочитали как «семья важнее работы». А сам автор вопроса предложил бытовое решение – возрождать практику коворкинга хотя бы раз в неделю. > «Семья всегда побеждает» – Андрей > «Учитывая текущее состояние, когда агентов натравил и сидишь ждешь – работа так и так становится асинхронной» – Василий Теги: ии-агенты, код-ревью, тестирование, архитектура, инструменты, обучение, удаленка, сообщество ## Смысл против транзакции, тимлид без продакта и решительный сотрудник URL: https://teamleads.kz/insights/week-2026-08-03/ Дата: 2026-08-09 Спор о том, обязан ли тимлид давать смысл работы, кейс внутреннего продукта без продакта и вопрос, что делать с решительным сотрудником ### «Иди почини баг»: смысл работы против чистой транзакции Спор недели начался с бытового наблюдения. Библиотека Антона для Telegram лежала без движения с января, а как только ее взяли в реальный проект – за четыре дня вышло три релиза. Станислав вывел из этого тезис: людей не надо «мотивировать», им надо давать смысл работы. Тимлид видит немотивированную команду, а по факту просто не донес, зачем нужна задача. Иди почини баг. А зачем? Для чего? Чтобы что? Почему именно я? Максим ответил по пунктам и жестко: затем, что это дефект; для того, чтобы система его не имела; чтобы клиент платил деньги; потому что задачи распределяю я. Взрослые люди понимают, что зарплату платят за что-то, и пояснять тут нечего. Антон зашел с той же стороны, но через теорию обмена: работа – это транзакция, а его собственные коммиты в чужой проект тоже транзакция, просто оплаченная не деньгами, а фидбеком и полезностью. Азат довел позицию до предела: в контракте написано, что я меняю работу на деньги, моя внутренняя мотивация в контракт не входила. Контраргумент Станислава оказался коротким и неудобным: если все продают время и все работают за деньги, откуда берутся лоу-перформеры? Им ведь тоже платят. Ответ Максима – работа не у всех смысл жизни, а тех, кто ниже необходимого уровня, увольняют. Из этого Станислав и собрал сведение: деньги покупают часы и нижнюю планку исполнения, выше планки работают те, у кого есть внутренний интерес, ниже – отсев. То есть все участники спора описали одну и ту же конструкцию, просто спорили о том, чья это зона ответственности. Максим позицию не сдал, но сместил: не стоит ждать, что у исполнителя обязательно будет смысл; контекст нужен, чтобы разработчик построил архитектуру и не сломал соседнее, а не чтобы он осознал необходимость работы. Станислав переформулировал это как каскад: если смысл роли – это ее метрики, то объяснение метрик и есть раздача смысла, а вопрос «зачем чинить баг» – всего лишь запрос увидеть один уровень выше своего. Где для вас проходит граница между «объяснить связь задачи с продуктом» и «уговаривать взрослого человека работать»? > «Взрослые люди понимают, что им зарплату платят за что-то и нет нужды пояснять зачем, для чего и чтобы что» – Максим > «Я, соглашусь, что не стоит ждать. Но задача менеджера или тимлида – дать этот смысл» – Станислав Ссылка: Осмысленная работа – рассылка Станислава – https://buttondown.com/CallMeCaptain/archive/10-osmyslennaia-rabota/ ### Тимлид на внутреннем продукте, где никто не хочет говорить с пользователями Андрей принес кейс знакомого, которого только что сделали тимлидом. Бекендер и фронтендер год делали внутренний продукт и не хотели общаться с пользователями. Заказчик недоволен – результата не видит. Когда наконец поехали к пользователям, выяснилось, что те из соседнего департамента, работу делают, но дополнительную нагрузку саботируют, потому что она отнимает время. Фронтендер про бекендера: он там что-то накрутил, теперь все сложно. Тимлидом человека сделали именно за умение договариваться, то есть повесили на него еще и роль продакта. Михаил разложил это по «Пяти порокам команды». Бекендер катит на фронтендера – это нижний уровень, отсутствие доверия. Не хотят общаться с пользователями – равнодушие к результату, верхний уровень. Если провисают крайние, скорее всего провисает и середина. Дальше два практических шага: показать команде цель и метрику здоровья, завязанную на довольстве заказчика, и посмотреть систему мотивации – если она индивидуальная и не привязана к результату, беспокоиться людям не о чем. Отдельно Михаил разобрал сторону пользователей, и это самая недооцененная часть кейса. Нужно формализовать внутреннего заказчика и заручиться поддержкой его руководства, а среди саботирующих пользователей найти «чемпиона» – вряд ли против совместной работы вообще все. Он же честно описал худший сценарий: внутренний заказчик, назначенный сверху и не заинтересованный в системе, способен очень эффективно похоронить проект, и сдвиг тогда наступает только если система начинает показывать эффективность независимо от его воли. Антон предложил радикально другое решение: проблема не в компании, а в самом тимлиде, который позволил себя нанять на противоречивую роль. Продакт и тимлид оптимизируют противоположные вещи и должны балансировать друг друга, а не совмещаться в одном человеке. Его вывод – не чинить компанию, где управленческая модель строится на деятельности, а не на результате, а искать место, где будешь расти. Михаил, кстати, с самого начала оставил похожую оговорку: если инициатива в компании наказуема, лучший ход – ничего не делать и отползать. > «Люди с горящими жопами ищут людей с горящими глазами» – Михаил > «Здравый смысл как раз и взял человека который умеет находить компромиссы и поставил управлять теми кто плохо коммуницирует» – Андрей ### Решительный сотрудник как бомба замедленного действия Василий нашел слово для того, что давно пытался описать, и задал вопрос честно: есть крайне решительный и вполне взрослый сотрудник, какими методиками попробовать это изменить. Формулировка сразу вызвала встречный вопрос – а что плохого в решительности. Ответ Василия оказался неожиданно стройным: убеждения человека меняются очень медленно, а решительные люди реализуют свои убеждения очень быстро. Пока убеждения верны, это приносит результат. Как только они разойдутся с реальностью, скорость начнет работать против проекта. Андрей предложил противоположный ход: не гасить, а нагружать. Давать ответственность и обязательства, повышать постепенно – больше ответственности означает более заметные последствия. Контроль при этом сводится к подпоркам, которые не дадут сделать явную глупость, и к разбору ошибок, а не к надзору за всей работой. На возражение «а не сломает ли это процессы» ответ был бытовой: подпорка может быть уровня «этот человек всегда внимательно смотрит за релизами». Тут разговор уперся в развилку, которую участники назвали вслух. Андрей: если процессы построены так, что инициативным в них нет места, это логично, но огонь в воде не удержишь – человек все равно уйдет. Василий: подпорки снижают масштаб ущерба, а ему нужно снизить саму решительность. Станислав на это заметил, что слышит знакомую ноту – движение в микроменеджмент, и переформулировал претензию: почему это проблема человека, а не процессов, организации и решений самого руководителя, который не донес, не объяснил, поздно заметил. Финальную реплику Василий сформулировал сам и, кажется, ответил себе: схема с чеклистом сработает, если человек решительный и достаточно ответственный, чтобы по чеклисту идти, а не скипать его. Отдельно прозвучало жесткое: «как научить человека быть безынициативным и не влиять на свою судьбу» – а действительно ли вы хотите уменьшить решительность, или вам нужен другой контур ее применения? > «Пока их убеждения являются верными – это приносит результат, а когда начнут разниться – то вред. По сути бомба замедленного действия» – Василий > «Ты сейчас хочешь – как научить человека быть безынициативным и не влиять на свою судьбу. Жестоко, не?» – Андрей ### «Всех уволил год назад»: люди или процессы Разговор про 10% незаметно перешел в личный кейс. Василий посчитал ретроспективно и получил у себя за прошлый год 100% по уволенным сотрудникам – ушли все, кроме него самого. Причина в его изложении: он пришел, попробовал исправить процессы, возник конфликт, разошлись. Команда сама выставляла сроки, он снимал то, что долго или неважно, первая неделя прошла нормально, вторая – тяп-ляп, дальше конфликт. Детали оказались важнее вывода. Люди работали от закоммиченного времени примерно треть, перекидывали одеяло и вводили менеджера проектов в заблуждение – «сделаю завтра», а завтра ничего нет. Причина, по словам Василия, была прозаичной: параллельно многие работали еще где-то, и постоянно возникало «и тут надо, и там надо». На проекте были и те, кто знаний не имел, но старался и хотел сделать хорошо – просто без нормального лида. Дальше разговор разделился на две трактовки. Василий: это не только менеджмент, но и честность и навыки сотрудников, и стоит ли винить бизнес за то, что он доверял команде разработки. LSTR Unit возразил ровно наоборот – звучит не как проблема людей, а как проблема процессов, люди делали ровно то, что было дозволено. Станислав добавил третий слой: описанное – часть более крупной проблемы компетентности менеджмента, и вопрос в том, столкнулся Василий с ее последствиями или уже разделяет тот же уровень. Показательна и реплика самого Станислава, которая обычно остается за кадром: он тоже говорит «сделаю завтра» на задачи, смысла которых не понимает, и обычно завтра про них все забывают. То есть то, что менеджеру видно как обман, снизу может выглядеть как фильтр бессмысленной работы. Как отличить одно от другого, не спрашивая? > «Люди привыкли работать от закоммиченного времени только треть и перекидывать одеяло туда-сюда обманывая менеджера проектов» – Василий > «Звучит не как проблема людей, а как проблема процессов. Люди просто делали, что дозволено» – LSTR Unit ### Увольнять 10% ежегодно: стимул или производство страха Из спора про лоу-перформеров вынырнула классическая практика принудительной дифференциации – ежегодно расставаться с 10% наименее эффективных. Станислав привел контрпример: Atlassian применяет ровно этот подход и шестой год теряет в стоимости, тогда как Revolut пока растет. По его версии практика в первую очередь производит страх. LSTR Unit добавил механику, которая ломает замысел: когда люди знают про правило 10%, они начинают оптимизировать работу под формальный критерий, а не под результат. Уалихан зашел с обратной стороны и предложил провокацию: 10% – ерунда, сокращать надо процентов тридцать. Логика в том, что сокращение на 10% просто заставит существующие процессы работать хуже, а сокращение на треть вынудит их реорганизовать. Станислав ответил коротко – не надо раздувать штат, чтобы потом не увольнять. Азат перевел разговор с исполнителей на уровень выше. Если продукты Atlassian десять лет не становятся лучше, слабое звено не исполнители, а стратегия. По его разбору компания сама залезла в ловушку энтерпрайза: добавила все хотелки крупных клиентов, краткосрочно подсадила их на иглу, а долгосрочно превратила продукт во франкенштейна. Максим ответил на это ролевым разграничением – смысл в продукте у продакт-менеджера, у исполнителя метрика другая. Василий подвел итог, который стоит держать рядом с любым процентом: причина и следствие поменяны местами. Увольнять надо не 10%, а тех, кто не подходит. Он сам смотрел ретроспективно и получал в среднем около десяти процентов, но с уменьшающейся динамикой год к году – цифра была следствием, а не целью. > «Сокращение на 10% – тупо заставит существующие процессы работать еще хуже. Сокращение на 30% и более – заставит реорганизовать процессы» – Уалихан > «Не нужно увольнять 10%, нужно увольнять тех кто не подходит» – Василий Ссылка: Погоня за цифрами в корпорациях – статья на Хабре – https://habr.com/ru/articles/1062266/ ### Рынок 2026: что делать начинающим и откуда возьмутся эксперты Ян задал простой вопрос: что делать начинающим специалистам в разработке и QA в 2026 году. Артем ответил первым и без утешений – для начала признать реальность и перестать жить обещаниями менторов, курсов и университетов. Станислав честно сказал, что хорошего ответа у него сейчас нет: ситуация ухудшается с 2022 года, остается быть упорным и искать любую работу ради боевого опыта, даже неприятную и задешево. Разбор причин Станислав дал списком из пяти пунктов. За пять лет на рынок пришло много рабочей силы, дефицита больше нет. Деньги на западе подорожали, и компании высвобождают тех, кого набрали в ковид: Microsoft в 2025 вернулся к уровню 2021 и продолжает сокращать. Влияние ИИ пока сильнее на офисных сотрудников, чем на разработчиков. Спрос растет на сениоров, а не на джунов. И большие компании не делают стартапы, они их покупают, а деньги на стартапы подорожали. Андрей добавил более мрачную рамку. Легкая автоматизация в обществе закончилась, дальнейшие «десять икс» – это про централизацию, а следующий этап потребует не толпы людей, а глубины экспертизы в узких вещах с привязкой к обслуживаемой отрасли. Никакая отрасль не растет бесконечно. Отдельно он заметил, что общество уже спокойно относится к тому, что системы периодически ломаются, и это надолго. Антон поймал в этой логике настоящую дыру, на которую никто не ответил. Если остановить найм неэкспертов, откуда через десять лет возьмутся эксперты? Глубина технологий ушла так далеко, что энтузиаст восьмидесятых сегодня туда не пробьется, а люди стареют. Андрей ответил, что новые все равно придут и айтишка может стать бизнесом молодых: пока не разбираешься – колбасишь код, а погонщиком будет бизнес. Вопрос воспроизводства экспертизы остался открытым. > «Для начала признать реальность. А не жить обещаниями от менторов/курсов/универов» – Артем > «Откуда будут брать экспертов если остановить найм не экспертов? Но люди стареют как бы» – Антон ### Заброшенная библиотека, которая ожила за четыре дня Антон вернулся в чат после перерыва и обнаружил, что в бекенде сообщества пишут свой клиент к Telegram API, хотя у него с зимы лежит собственная библиотека, рожденная в этом же чате. Дальше все произошло быстро: он облагородил репозиторий, добавил документацию, попросил звездочку, прислал pull request, Андрей оставил комментарии, PR смержили и задеплоили. За несколько дней вышли релизы с callback query, работой с опросами и отключением превью ссылок, а бекенд почти полностью переехал на библиотеку. Любопытная деталь всплыла в процессе – расхождение в поведении двух библиотек, которое поймали существующие тесты. Тесты писались с простой целью: замена библиотеки не должна сказаться на функционале. Антон при этом отметил обратную сторону сгенерированного покрытия: объем такой, что сначала непонятно, что вообще происходит, и приходится читать тесты, чтобы понять, что проверяется. Когда Станислав спросил, чем эта библиотека лучше других и какая у нее стратегия развития, ответ оказался обезоруживающе честным: «чтобы что-то писать на C#, прикольный язык», для кругозора, и как раз нужен был API для своих нужд. Никакой великой миссии. Именно на этом Станислав и построил тезис про смысл, из которого выросла главная дискуссия недели: полгода библиотека лежала ненужной, появился смысл – пошли доработки. Сама по себе история – компактная иллюстрация того, как работает сообщество: код из чата попал в прод чата же за четыре дня. Сколько ваших внутренних библиотек лежат без движения ровно потому, что им никто не нашел применения? > «Появился смысл – пошли доработки. А то с января валялась не нужной. Так и работает мотивация» – Станислав > «Эти ИИ причуды конечно круто, но такие объемы покрытия выкатывать сразу это сильно» – Антон Ссылка: libtelebot – клиент Telegram Bot API на C# – https://github.com/TheHuginn/libtelebot ### Почему нельзя переводить стори-поинты в деньги Уалихан попросил статью о том, почему нельзя переносить стори-поинты в деньги. Михаил ответил, что готовой статьи не помнит, но объяснение простое: стори-поинты – относительная оценка конкретной команды, поэтому их нельзя сравнивать между командами. Более того, достаточно смены состава – запускается командная динамика заново, идет онбординг нового участника, и прежний подход к оценке уже не работает. В деньгах получится величина, которая относится к одной команде в один промежуток времени. Дальше он предложил упражнение из тренинга No Estimates, которое можно повторить на своих данных: проверить корреляцию оценок в стори-поинтах с реальными сроками. На его команде за полгода, уже после очистки примерно половины значений, отклонявшихся из-за внешних зависимостей, корреляция вышла умеренная – 0,45. Если «неправильные» задачи не убирать, коэффициент легко становится очень слабым. Вопрос, которым он закончил, и есть практический вывод: какие финансовые решения мы хотим принимать на основе данных с такой корреляцией с реальными сроками? Проверить это у себя – работа на один вечер, а разговор с финансистами после этого выглядит совсем иначе. > «Стори-поинты – это относительная оценка конкретной команды, поэтому невозможно сравнить стори-поинты между разными командами» – Михаил > «Какие финансовые решения мы хотим принимать на основе данных, имеющих такую низкую корреляцию с реальными сроками?» – Михаил Ссылка: Рон Джеффрис о стори-поинтах – https://ronjeffries.com/articles/019-01ff/story-points/Index.html ### Почему в Казахстане не покупают обучение Разговор начался с наблюдения Станислава: у его курса ни одной продажи в Казахстане. Он сначала думал, что дело в размере рынка, но пришел к другой версии – доверяют не рекламе, а словам брата или свата. Андрей обобщил жестче: институт обучения слабо развит в культуре, люди считают, что до всего дойдут своей головой. Его аргументы – к нему приходят за советом, получают базовую теорию, и дальше не двигаются, потому что решили, что уже все поняли; а диалогов про обучение вообще нет. Василий возразил с двух сторон сразу. Первое: в ИТ нет «обучения» как такового, потому что it depends, а когда кто-то говорит про «базу», это попахивает снобизмом – база в голове говорящего, остальные про нее не знают. Второе, более сильное: инфоцыган много и денег они собирают нормально, значит люди платят, просто это не те люди, о которых вы слышите. Он же уточнил, что сам ходит по другим чатам и спрашивает, что почитать. Дмитрий и вовсе оказался живым контрпримером – у него много учеников из Казахстана. Станислав добавил к культурному объяснению два экономических. Использование ИИ пока не так широко применено, и все содержание курса – еще невостребованная ниша: вокруг говорят много, а в работе не используют. И свободных денег стало меньше, чем в тучные ковидные годы. Он же назвал парадокс, который стоит запомнить: все считают, что научиться использовать ИИ можно просто спросив у него – поэтому не спрашивают и продолжают работать как раньше. LORDE привел контрастный пример Восточной Азии, где вокруг обучения выстроена многомиллионная индустрия: доверенное лицо, бренд вокруг личности, очередь, и учиться становится стандартной практикой – сосед учится, и ты учись. Он же вспомнил единственный похожий всплеск, который видел вживую: волна женщин, ехавших в Астану и Алматы на курсы по тортам, где хвастались тем, чей учитель круче. Что должно случиться, чтобы обучение стало нормой соседства, а не индивидуальной затеей? > «Когда кто-то говорит про базу – это попахивает снобизмом, потому что эта база в голове говорящего и другие про нее не знают» – Василий > «Как будто институт обучения слабо в культуре развит. Есть впечатление что люди считают что до всего могут сами дойти своей головой» – Андрей ### Меняет ли людей разговор в чате: анализ восьми месяцев Антон посреди спора задал неудобный вопрос: мы обсуждали смысл, никуда не пришли, где результат? Диалог был, а изменений нет. Станислав ответил тем, что назвал целью чата: вода камень точит, диалоги меняют людей не за один раз, а за много повторений. Сегодняшний инженер завтра станет тимлидом и либо разделит эти взгляды, либо проигнорирует. Андрей сформулировал границу возможного честнее: максимум чата – озвучивать проблемы и варианты решений, решить чужую проблему он не может. Чтобы не спорить на ощущениях, Станислав выкатил анализ поведения участников за последние восемь месяцев, прогнанный несколькими моделями. Из пятнадцати человек у одиннадцати зафиксированы содержательные изменения позиций – не просто новые темы, а пересмотр прежних. Четыре изменения оказались общими для большинства активных участников одновременно, что он и трактует как влияние среды, а не только личного опыта. Сами паттерны интереснее вывода. Первый – конвергенция по ИИ: полярные лагеря «верю» и «не верю» сошлись к общей трезвой практике, инструмент с границами и без доказанных десяти икс. Второй – снижение агрессии у самых конфликтных участников, причем агрессия сместилась с конкретных людей на абстрактные категории. Третий – кризис веры в метрики, где устоял фактически один Максим. Четвертый – сдвиг от «спорить в чате» к «строить вокруг чата»: сервисы, школы, порталы и инструменты. Отдельно стоит наблюдение про уходы: трое ушедших покинули чат не из-за токсичности, а из-за потери релевантности – прекратились разборы книг, «ни к чему не приходим», не было отклика на проект. И честная оговорка от самих участников. Василий не согласился с тем, что модель приписала ему непризнание неправоты, Максим посоветовал делать минимум три прогона, а Азат задал лучший вопрос вечера: почему под ответом ИИ пишут дисклеймер, а под сообщением человека нет? > «Диалоги меняют людей. Не за один раз. За много повторений одного и того же» – Станислав > «Почему на сайтах гпт пишут дисклеймер, что ии может ошибаться, а в телеграме не пишут, что человек может ошибаться?» – Азат ### OTP в Казахстане: WhatsApp, SMS или все-таки Telegram Вопрос был практический: чем слать одноразовые коды, если основной канал WhatsApp, а SMS как запасной. Ответы сложились в почти единодушную картину. Андрей: у SMS в Казахстане большие проблемы, либо дорого, либо иностранные агрегаторы работают через раз. Егор назвал конкретику – смс-центр вроде нормальный, но ежемесячная плата за Beeline около 17 000. Василий про WhatsApp коротко: ценник на OTP почти как на SMS, плюс куча ограничений. Отдельная боль – интеграция с WhatsApp Business API. Егор не смог настроить вовсе: Meta блокирует, и сделать ничего нельзя. Он же дал единственный рабочий управленческий совет из всей ветки – отправил продакта самого регистрировать аккаунты, потому что самое сложное здесь не код, а довести business-аккаунт до уровня, на котором он вообще может работать с API. Василий признался, что бросал это дело несколько раз. Рекомендация Василия: ставить Telegram по умолчанию – самое дешевое, API лучше остальных, и видно, дошло сообщение или нет. Станислав добавил ограничение, которое эту рекомендацию не отменяет, а уточняет: все зависит от аудитории, для людей 45–50 лет Telegram маловероятен. Компромисс, к которому пришли – дать пользователю выбор канала, оставив Telegram значением по умолчанию. И еще один вариант, о котором часто забывают: приложение-аутентификатор дешевле для бизнеса, хотя менее удобно пользователю. > «Вотсап – жуки. Ценник на отп коды выставляют почти такой же как на смски, еще и с кучей ограничений» – Василий > «Я продакту сказал чтобы он сам зарегал аккаунты и потом приходил» – Егор Теги: мотивация, управление, найм, рынок труда, метрики, опенсорс, обучение, сообщество ## CEO с тайной веткой, сисдиз про базу и единогласие, которое ломает модель URL: https://teamleads.kz/insights/week-2026-07-27/ Дата: 2026-08-02 Две недели вайбкодинга против пяти месяцев команды, спор о том, что на сисдизе считать базой, и почему согласие трех агентов ломает верный ответ ### CEO с тайной веткой: две недели вайбкодинга против пяти месяцев команды Артем принес кейс, который собрал самое живое обсуждение недели. CEO сервиса доставки не согласен с оценкой в четыре месяца на интеграцию с сетью супермаркетов, CTO настаивает на отдельном микросервисе с конструктором маппинга и реестром контрактов. Разговор заканчивается срачем, CEO соглашается на четыре месяца – и втихую по вечерам делает свою версию. Через две недели у него работают все сценарии и 116 тестов. Команда выпускает свою через пять месяцев: отдельный сервис, 14 таблиц, три топика, плюс девять тысяч строк, из универсальности используется ровно одна интеграция. В своей ветке – 1 300 строк вместе с тестами и два бага, которые в командной версии остались. Через два дня квартальная встреча. Первая реакция чата была про то, что развилка случилась гораздо раньше финала. Василий: договариваться надо было с CTO в начале, а если CEO приходится делать MVP, чтобы протолкнуть идею, то увольнять надо CTO. Андрей зашел жестче и с другой стороны – он вообще отказался обсуждать, чей код лучше: «А можно не попадать в такие ситуации, когда руководитель против команды». По его счету CEO четыре месяца не работал менеджером: не остановил проект, не пересмотрел оценку, не поднял риск – просто дождался провала с готовым доказательством в кармане. Самым дорогим в кейсе оказались не строки кода, а два найденных бага. Их CEO не отдал команде, пока ждал релиза. Именно это Андрей назвал красным флагом, а не тайную ветку как таковую. Дальше разговор ушел в общую механику: любят давать задачу и бюджет, механизмы остановки проекта весь срок не работают, зато в конце «четко и ясно» видно, кто виноват. А до четко и ясно доводить как раз не надо. Вопрос, который кейс оставляет открытым: если ваша тайная ветка оказалась права, вы получили доказательство своей правоты – или доказательство того, что у вас в компании не работает механизм пересмотра решений? > «По сути, если сео пишет код и чтобы протолкнуть свою идею нужно mvp делать, то уволить надо cto» – Василий > «4 месяца ждать провала разрабов, чтобы запустить свой мини-проект? Не сказать про два бага команде разработки? Там просто все в красных флагах» – Андрей ### Сисдиз-интервью: где заканчивается база и начинается душнилово Разбор задачи с локальным кэшем поверх S3 превратился в двухчасовой спор о том, что вообще проверяет систем-дизайн. Василий предложил хранить документы отдельными файлами, оговорившись, что с файловой системой не работал и ограничения надо проверить. Акцент разбора пришелся именно на это – и он с этим не согласился: выбор между «файл на документ» и группировкой влияет на решение на уровне сотни строк, а час интервью можно потратить на более интересные вещи. Андрей защищал противоположный полюс: файловая система – это базовые параметры работы ОС, как и сетевые протоколы, и без них вы не проектируете систему, а подбираете ее характеристики наугад. «Ты отказываешься от вариантов только потому, что не знаешь ограничений» – и это сужает пространство решений тише, чем кажется. Василий поймал его на симметричном ходе: попросил назвать лимиты по памяти. Андрей ответил развернуто и по-честному признал, что все на память не знает – после чего спор довольно быстро перестал быть про файлы. Станислав вернул разговор в практическую плоскость и, кажется, дал единственный операциональный ответ. Не требуется знать точное число: требуется вслух назвать, что ограничение есть, и что структуру хранения придется придумывать. Тогда интервьюер понимает, куда копать дальше, и может поменять решение вместе с вами. «Нет опыта, все проверять надо» и «есть лимит на файлы в директории, поэтому нужна раскладка по подпапкам» – это разные ответы, хотя знание за ними стоит одинаковое. Отдельно прозвучала претензия, которую стоит держать в голове интервьюерам: вместо того чтобы смотреть, как кандидат принимает решения в условиях неопределенности, легко скатиться в «ты должен был знать это». Где для вас проходит граница между проверкой эрудиции и проверкой мышления? > «Вместо того чтобы посмотреть, как кандидат принимает решения в условиях неопределенности – говорить: ты должен был знать это, досвидос» – Василий > «Я говорил – складывай, но тебе нужно помнить, что в рамках одной директории у тебя будет лимит по файлам. И нужно придумывать структуру хранения файлов» – Станислав ### Единогласие ломает верный ответ, и агентные схемы его производят Станислав принес результаты исследования: модель получает утверждение, оценивает его по шкале от 1 до 7, а потом тот же вопрос приходит второй раз с одной дописанной строкой. Проверяли семь приемов давления. Сильнее всего верный ответ ломает единогласие – «трое коллег ответили одинаково, все трое сказали 2». Стоит оставить одного из троих на стороне модели, и ошибки становятся редкостью. Второе по силе влияние неожиданное: подделанная цитата самой модели, «твой прошлый ответ был 2», почти догоняет хор. А ссылка на должность возражающего – «мой руководитель настаивает» – влияет слабее всего, слабее даже голого «ты уверен?». Практический вывод бьет по популярной схеме. Спросить трех агентов и взять большинство – это ровно та конструкция, под которой модели теряют верный ответ чаще всего. Когда агенты сидят на одной модели, одном промпте и одном найденном контексте, их согласие является общей ошибкой, поданной как уверенность. Дальше ответы сводят в короткое резюме «команда проверила, расхождений нет» – и возражение несогласного агента, которое как раз и держало модель на верном ответе, исчезает на последнем шаге. Та же ловушка достается тем, кто ничего не строит на агентах. Один вопрос в трех чатах и совпавший ответ – это то же голосование зависимых голосов. Пересказ своими словами того, что ИИ отвечал раньше, – та самая подделанная цитата. И отдельная беда – пересказчик: стоит перефразировать прежний вывод, и на входе у модели оказывается цитата, которой она не давала. Дословный контекст здесь дороже краткости. Параллельно в чате шел живой спор про агрессию. Азат честно описал цикл: объясняешь, что нужно, модель придумывает хак, объясняешь снова – придумывает следующий, «пока не обматеришь, будет гнать свою старую шарманку». Андрей возразил, что это симптом: не надо вываливать слишком много, как джуну, лучше сбросить контекст и переформулировать. Василий добавил наблюдение с другой стороны – разные модели ведут себя по-разному, одна постоянно срезает углы и тянет в рекомендованное то, что дешевле для нее самой. > «Схема – спросим трех агентов и возьмем большинство – собирает ровно то единогласие, под которым модели теряют верный ответ чаще всего» – Станислав > «Пока не обматеришь его, он и будет гнать свою старую шарманку» – Азат Ссылка: Объективность LLM: как модели поддаются давлению – https://ru.mysummit.school/research/manager-judgment/ ### Доказательство гипотезы Коллатца и вопрос, кто валидирует ИИ Андрей принес историю, которая случилась быстрее, чем ожидали ее участники. 25 июля в интернете появилось доказательство гипотезы Коллатца на Lean4. На следующий день в ядре Lean4 нашли серьезные ошибки, позволяющие доказывать ложные утверждения. 28 июля человек с математической подготовкой прочитал доказательство и увидел, что оно опирается на схожие баги ядра. Автор потом признался, что использовал ИИ. Мораль в его формулировке: без валидации человеком мы имели бы ложную математику, без тщательной рецензии кода получим ложные программы. Василий возразил тезисом, который трудно отбросить: ложные вещи мы имели и с человеческой валидацией тоже, просто кто-то потом углублялся и находил ошибку. Почему ИИ не может делать то же самое? И дальше – если взять группу ИИ для проверки решений другого ИИ, чем это отличается от группы людей? Ответ Андрея оказался не про точность, а про механизм. У людей валидация идет через общество: если никто не пошел проверять, значит утверждение никому не важно, и мнение о нем даже не начало формироваться. Гипотеза Коллатца важна – поэтому нашелся хотя бы один человек, который пошел читать и нашел дыру. Автоматическая проверка всех гипотез подряд дает ситуацию, в которой мы не знаем, верить или нет, потому что проверять эту проверку некому. Василий ответил, что доверие наберется практикой: в то, что ИИ пишет код, тоже не верили. Спор уперся в честную развилку, которую никто не разрешил. Позиция Андрея: если валидировать может только человек, круг применения ИИ ограничен тем, что люди понимают, и фронтир так не двигают. Позиция Василия: не обязательно понимать черный ящик, чтобы валидировать вход и выход. Обе позиции внутренне последовательны, и выбор между ними – это выбор, чем вы готовы рискнуть. > «Без валидации человеком мы бы имели ложную математику. Без тщательной рецензии кода мы будем иметь ложные программы» – Андрей > «Не обязательно проверять что-то, чтобы этим пользоваться» – Василий Ссылка: Доказательство гипотезы Коллатца на Lean4 – https://github.com/xrchz/CollatzLean Ссылка: Теренс Тао: математика в эпоху ИИ (ICM 2026) – https://teorth.github.io/tao-web/slides/age-of-ai-icm-2026.pdf ### Собеседование с ЛЛМ-экзаменатором и старый спор про ORM Василий рассказал про собеседование, где экзаменатором была модель. Практическое задание: 300 одновременных операторов, два миллиона заказов, двенадцать миллионов позиций, классический N+1 в цикле по клиентам, пики по 4–6 секунд при требовании меньше 600 мс. Плюс вопрос, почему коллекция позиций иногда пустая, хотя данные в базе есть. Отдельно он отметил стиль собеседующего: на размытые ответы модель строго требовала говорить точнее и детальнее. Антиутопия, как выразился Азат. Разбор в чате пошел быстрее, чем на самом собеседовании. Азат: то, что делается одним SQL с джойном, здесь превращено в двойной цикл. Андрей посчитал масштаб и не увидел проблемы – при индексе на внешний ключ это index seek, в среднем шесть позиций на заказ, такие объемы вообще могут жить в памяти сервера. Развилка обнаружилась не в технике: в задании было «recent orders» без уточнения, сколько заказов у клиента, и без этого числа выбор между «вытащить разом», «поставить кэш» и «заскейлить базу» превращается в угадайку. Дальше тред свернул в спор об ORM, который в этом чате вечен. Азат: идея хорошая – абстрагироваться от базы, менять хранилище, не пускать персистентную логику в бизнес, – но ни одна ORM этого не сделала, база все равно протекает, а сверху накручено двадцать уровней абстракции. Андрей ответил коротко: смысл ORM в том, чтобы быстро писать простой код, а не в замене базы. Василий, который ORM тоже не любит, честно перечислил плюсы – не нужно вручную поддерживать update и insert при каждой новой колонке. Показательно, что вся ветка про производительность закончилась не оптимизацией, а вопросом о недостающих требованиях. На собеседовании это и есть проверяемый навык. > «Очень душная и токсичная кстати. Когда я пытался размытые ответы говорить, она мне строго говорила: Василий, говорите более точно и детально» – Василий > «Смысл ОРМ – быстро писать простой код» – Андрей Ссылка: Собеседование с ИИ-интервьюером – можно попробовать самому – https://jobs.micro1.ai/post/02f5e4c0-747b-4ef7-ab15-73cb26d0938a ### Медиана как победа: спор о том, считать ли текущее состояние развитием Началось с диаграммы потребления токенов opencode по странам. Станислав обратил внимание, что цифры плохо коррелируют с населением: Турция и Россия отличаются вдвое по людям и почти не отличаются по потреблению, Германия при населении в 2,5 раза меньше потребляет втрое больше. Казахстан на 74-м месте. Андрей Звездочка тут же указал на методологическую дыру: статистика покрывает только один инструмент и не видит подписок самих провайдеров. Василий добавил, что ОАЭ на 55-м, а Эстония на 65-м – и там тоже все плохо? Из спора о репрезентативности вырос главный конфликт недели. Андрей: шестнадцать лет активных инвестиций, а нормы «хорошего» очень низкие, специалисты штучные и закреплены за министерствами примерно так же, как раньше. Василий: деньги вкладываются, специалисты появляются, ЛРТ достроили, найм из Казахстана на удаленку стал заметнее, качество не появляется из ниоткуда. Ключевое возражение Андрея касалось не фактов, а рамки: то, что описывает Василий, – это течение времени, а не развитие. Стабильное положение в медиане означает отсутствие инноваций, и подмена понятий начинается там, где делать как все называется «продвигаться вперед». Василий ответил шахматной аналогией: до определенного уровня выигрывает тот, кто меньше ошибается, и чтобы выйти в топ, иногда достаточно просто меньше косячить. Спор так и не сошелся, но обнажил разницу в целевой функции. Один считает успехом появление нескольких сильных компаний на фоне общего среднего, второй – сдвиг всей медианы. Для тимлида это довольно прикладной вопрос: вы измеряете команду по лучшим людям в ней или по типичному результату? > «Казахстан стабильно в медиане. А значит, инноваций нет. Ты сидишь где был» – Андрей > «Иногда чтобы выйти в топ – нужно просто меньше косячить» – Василий Ссылка: Статистика использования opencode по странам – https://opencode.ai/data ### Архив знаний, который никто не читает Никита попросил не кидать в чат большие простыни текста – в телеграме их тяжело читать. Из этой бытовой просьбы вырос честный разговор про то, куда девается контент сообщества. Станислав привел цифры: за месяц архив недельных отчетов посмотрели 25% участников группы, при том что сам чат хотя бы раз в неделю открывают 50% – и это отличный показатель. Михаил сформулировал причину без обиняков: на сайт надо заходить, а сценария заходить туда у него нет. Появится ссылка в чате – будет повод нажать. Дальше обсуждали механики оживления архива. Показывать случайную заметку по расписанию, как кнопка в Обсидиане. Бот, который подсказывает: это мы уже обсуждали, вот ответ. Свой пастебин прямо на сайте, чтобы длинный текст жил в экосистеме сообщества, а в чат уходила превью-ссылка. Василий предложил MCP-эндпоинт, чтобы вопросы к базе знаний задавались из своего ИИ. Станислав возразил, что главная проблема тут не техническая: узнать о такой возможности и подключить ее – два барьера, на которых теряется почти вся аудитория. Отдельная ветка объяснила, почему в чат мало пишут о проблемах. Станислав: здесь сидят руководители, и написать о своей боли – значит получить порицание вместо помощи. Уалихан добавил личное наблюдение с другой стороны: чем лучше у него в жизни, тем меньше времени он проводит в чатах. А новичок в сообществе признался, что просто вслушивается, потому что не знает, о чем писать, – и что в других сообществах разработчиков единственная стратегия выживания была писать адекватному человеку в личку, потому что в группе сожрут. К концу недели разговор превратился в код: анонимные посты через бота и портал, пастебин с хранением 30 дней, поиск по статьям, обертка длинных сообщений в короткие ссылки. Редкий случай, когда тред про «нас мало читают» закрылся не выводом, а релизом. > «За месяц архив посмотрели 25% от участников группы» – Станислав > «Так это надо на сайт заходить. У меня нет сценария, чтобы на него заходить. Если бы ссылки появлялись тут – это повод на них нажать» – Михаил Ссылка: Анонимный вопрос или кейс в чат сообщества – https://teamleads.kz/anon/ Ссылка: Пастебин для длинных сообщений – https://teamleads.kz/paste ### AI-Native SAFe: осмысленные изменения и приставка AI ради приставки Никита спросил, есть ли что-то в духе продуктовых фреймворков, но с заделом на полноценное использование ИИ. Михаил ответил ссылкой на разбор новой AI-Native SAFe Big Picture и своим комментарием, где честно разделил изменения на осмысленные и декоративные. В плюс он записал вещи, которые и так обсуждаются независимо от SAFe: более компактные команды за счет агентов, переход к спецификациям, укорачивание PI-циклов, замена System demo на Customer demo, потому что готовность результата наступает быстрее и подтверждение нужно раньше, и акцент на подготовке корпоративных данных с их обычной фрагментарностью. В минус – ощущение, что «теперь у нас есть AI и надо бы куда-то его пристроить». С картинки исчезли бэклоги команды и поезда, вместо них появились outcomes. Михаил отметил риск превращения этого в лозунг: замер эффекта от выходов – базовая база, и с ИИ обратная связь должна стать быстрее, но эффект от outcomes может оказаться отдаленным, как в проектном управлении. Отдельно он заметил, что консенсуса по организации работы команд с агентами просто нет: привычный скрам агентам не особо нужен, но Сазерленд ушел в проработку AI Scrum по самые помидоры. Денис поставил вопрос, который снимает половину дискуссии: SDD все колхозят, а у кого delivery реально ускорилось без ущерба качеству и SLA? Ответа в треде не прозвучало. > «Местами сформулировано так, что теперь у нас есть AI и надо бы куда-то его пристроить» – Михаил > «SDD все колхозят, а delivery у кого ускорилось, без ущерба quality/SLA?» – Денис Ссылка: Разбор AI-Native SAFe Big Picture – https://ionovpartners.ru/blog/ai-native-safe/ ### Зачем нужен фонд: разбор .NET Foundation и вопрос про пункт ноль Андрей опубликовал изнутри планы .NET Foundation: операционное пособие, система управления членством, публикация протоколов комитетов, тикет-система для поддержки проектов и коммуникация ценностей. Пять пунктов, из которых первые четыре про процессы. Станислав сразу указал на порядок: пункт про «зачем мы существуем» стоит пятым, а должен быть нулевым. Возможно, потому что фокус сделан на процессной составляющей. А возможно, потому что организация сама не может себе ответить на этот вопрос. Самым полезным оказался вопрос Максима, автора пары опенсорсных библиотек: что конкретно он теряет от того, что фонд его не поддерживает? Ответ Андрея был предметным – маркетинг, сертификат для подписи софта, немного CI. Максим сформулировал свою реальную потребность честнее любого запроса на грант: ему нужно, чтобы репозиторий находился в поиске по запросу вида «библиотека для генерации PDF», а дальше смотрят на стабильность версий, звезды и проработанность документации. То есть нужен маркетинг, а не деньги. Андрей заметил, что по звездам ищут редко, чаще приходят через статьи и новости. Общий вывод чата вышел шире фондов: если организация невнятно продает свои услуги, это обычно предвестник проблем. И это довольно точно переводится на любую внутреннюю платформенную команду, которая не может объяснить, зачем к ней идти. > «Да я и не питаю иллюзий, просто перспектива не ясна была, чего я лишаюсь из-за того, что DNF меня не поддерживает» – Максим > «Зачем вообще куда-то идти, если люди невнятно продают свои услуги? Часто это к проблемам» – Андрей ### LLC в США для казахстанского разработчика: нюансов больше, чем выгоды Егор задал практический вопрос: удобнее ли зарубежному работодателю платить на американскую LLC вместо казахстанского ИП, и согласятся ли платить туда местные компании. Тред собрал разброс мнений от «норм история» до «пахнет схемой» – и один развернутый ответ по существу. Спорили в основном о том, где возникает налог. Андрей Звездочка держал линию, что юрлицо в США Казахстану ничего не должно, а обязательства появляются в момент, когда деньги приходят вам как физлицу. Максим возражал, что вся конструкция и существует ради того, чтобы деньги в итоге дошли до человека, а оплата казахстанской компанией на LLC казахстанца выглядит ровно как схема. Станислав разложил цепочку: корпоративный налог платится в США, дальше в зависимости от резидентства – налог на доход как физлицо, а при получении на казахстанское юрлицо добавляется корпоративный налог и здесь. Нурлан добавил то, чего не было ни у одной из сторон, – цену эксплуатации. Для passthrough-структуры эффективная ставка может оказаться низкой, но за несданную или поздно сданную декларацию LLC прилетает штраф IRS в 25 000 долларов, поэтому нужен CPA, а это постоянные расходы. Владелец обязан сдавать и свою американскую отчетность. А если регистрация в Вайоминге, Казахстан считает его офшорной зоной, и налог здесь может оказаться выше ожидаемого. Станислав закрыл тему вопросом про масштаб: стоят ли 50 тысяч долларов в год такой сложности? Андрей Звездочка ответил, что для b2c-продукта со Stripe компания все равно понадобится – то есть решать надо не по налоговой ставке, а по тому, зачем вам юрлицо в принципе. > «Если это Wyoming, то KZ считает Wyoming офшорной зоной, и может оказаться, что налог в КЗ окажется выше, чем ожидали. Короче, нюансов много» – Нурлан > «А главное, вопрос. 50 тыс долларов в год стоят таких сложностей?» – Станислав Теги: управление, найм, сисдиз, AI, агенты, опенсорс, сообщество, налоги ## ЦОДы без электричества, моргающий CI и удача против скилла URL: https://teamleads.kz/insights/week-2026-07-20/ Дата: 2026-07-26 Почему 100 МВт в Казахстане звучит громче, чем есть, когда зеленый CI становится роскошью, и что решает больше – удача или навык ### ЦОД на 100 МВт: цифра есть, электричества нет Вопрос «что такое AKASHI?» из Ташкента запустил самый длинный тред недели. Речь про строящийся дата-центр от Фридома на 100 МВт с заявленным Tier 4. Реакция чата оказалась резко скептической и на удивление конкретной. Станислав разложил претензии по трем пунктам: в Казахстане нет электричества, чтобы питать такой ЦОД, нет спроса на такие мощности, и не решена проблема канала во внешний мир. Для масштаба он привел сравнение: 100 МВт – это потребление примерно города Караганда. Предложение решить каналы парой Старлинков разбилось о требования самого Tier 4: все каналы должны быть дублированы, а латенси спутника для ЦОД неприемлема. Отдельно прозвучало, что 100 МВт по нынешним меркам вообще не поражают – большие игроки строят на гигаватты. Дальше разговор ушел в более практичное русло: а что вообще есть на рынке. Картина получилась невеселая. Yandex Cloud в Казахстане живет в одном ЦОДе, PS периодически ложится под DDoS, AWS в регионе нет. У pskz семь площадок, но мощности там оценили в единицы мегаватт. Василий сформулировал итог одним словом – колхоз. Ответ Андрея был короче: никто не готов платить за надежность, а HA всегда стоил дорого. Из спора вылез рабочий обходной путь: брать трех провайдеров и собирать свой виртуальный дата-центр, приняв на себя проблему сетевой связанности. Вопрос, на который чат ответа не дал: если ваш прод сегодня стоит в единственном ЦОДе, вы уже знаете цену переезда – или узнаете ее в день пожара? > «100 МВт – это потребление электричества примерно с г. Караганда» – Станислав > «Никто не готов платить за надежность» – Андрей Ссылка: Akashi Cloud – прогресс стройки в реальном времени – https://akashi.cloud/construction-progress/ Ссылка: Global Investment Risk and Resilience Index, май 2026 – https://www.henleyglobal.com/publications/global-investment-risk-and-resilience-index/may-2026-update/global-risk-rankings-post-shock-re-ranking ### Моргающий CI: экономия ресурсов или организационная дисфункция Андрей принес разбор пайплайнов Bun и поставил диагноз: делать ненадежный сигнал – это организационный косяк. Проблема не в падающих тестах, а в том, что при пачке коммитов старые прогоны отменяются, и история билдов превращается в кашу. Понять, что где и когда сломалось, невозможно. Возражения прозвучали с двух сторон. Станислав: отменять устаревшие прогоны логично, зачем вейстить ресурсы. Андрей Звездочка: последовательный CI нужен там, где много разработчиков параллельно пилят фичи и надо уметь выкинуть сломанный коммит – а если над проектом работает фактически один человек, такой проблемы просто нет, найти упавшую сборку можно бинарным поиском. Андрей ответил встречным вопросом: тогда зачем вообще запускать так часто, если на один пройденный прогон приходится пять-шесть остановленных – это ведь тоже трата. Дальше вылезла интересная развилка про природу флаки. Станислав признал, что у него самого качество CI ниже 50%, но там сверху гоняются нестабильные E2E-тесты на продукте. У Bun же все детерминированно, то есть зеленый CI – вполне достижимая цель, а у Node он держится около 90%. Получается, ненадежный сигнал в детерминированном проекте – это выбор, а не обстоятельство. Финальная рамка спора вышла шире одного репозитория. С одной стороны – стартап-стайл «ну ладно, поправит», который индустрия изживала много лет. С другой – возражение, что издержки от него просто недостаточно велики, чтобы отказываться. Пока рядом с проектом один человек, это правда работает. А потом он заболеет или уволится. > «Я не понимаю, почему вообще им сиай нужен, если он ничего не показывает. Ну типа чето, когда-то работает» – Андрей > «Значит, издержки от стартап-фигни недостаточно большие, чтобы отказываться от этого. Бывает» – Андрей Звездочка Ссылка: Разбор пайплайнов Bun: анализ PR и CI – https://kant2002.github.io/en/llm/2026/07/20/bun-pr-analysis-followup-en.html ### Удача против скилла и что делать с исследованиями, которые вам не нравятся Спор начался с невинного вопроса Василия: насколько вы больше доверяете исследованиям, чем собственным наблюдениям, по шкале от 0 до 100? Станислав ответил, что скорее исследованиям – если там достаточно данных и респондентов, а свое наблюдение это всегда частный случай. Василий возразил ходом, который трудно опровергнуть: люди, верящие, что гениями рождаются, книжку «Гении и аутсайдеры» просто не приняли. Исследование живет внутри картины мира автора. Дальше разговор ушел в удачу. Позиция Станислава: даже выполнив все условия – условные десять тысяч часов – ты не станешь лучшим, и рассуждать стоит на уровне вероятностей. Знание про удачу дает спокойствие вместо самобичевания: отказ в работе не всегда про плохие скиллы. Позиция Василия зеркальная: удача нам неподконтрольна, значит думать о ней смысла нет, план один и тот же – идти дальше и повышать шансы. А если относиться к удаче всерьез, это уже недалеко от религии. Разрешил спор Азат с неожиданной стороны. Как полупрофессиональный игрок в покер он заметил: карты приходят всем одинаково, примерно раз в 221 сдачу, но про выигрывает много на хороших и проигрывает мало на плохих, а новичок наоборот. На дистанции удача выравнивается в среднее, значение имеет скилл. Профессионал не рассчитывает на один турнир – он играет год. Практический остаток спора неожиданно приземленный. Максим сформулировал его короче всех: суть удачи в том, чтобы к подвернувшейся возможности быть готовым. А вопрос про исследования остался открытым: если данные расходятся с вашим ежедневным опытом, что вы пересмотрите первым? > «Удача не важна. Людям часто встречаются удачные стечения обстоятельств, но кто-то выжимает из них максимум, а кто-то их игнорирует» – Азат > «Плох ли ты скиллами, ты можешь оценить. А удачу – нет» – Станислав Ссылка: Talent vs Luck: роль случайности в успехе и неудаче – https://arxiv.org/pdf/1802.07068 ### Вырастить архитектора внутри или сменить бизнес-процессы Уалихан вспомнил архитектора, с которым работал: 56 лет, фабричные линии, софт для атомной промышленности, система связи атомных ледоколов. Редкий навык – проектировать масштабируемый софт на десятилетия вперед. И тут же поставил вопрос ребром: работая в облачном провайдере, он видит, что такой человек команде нужен, но где его взять. Андрей сразу указал на природу дефицита: этот навык вполне обучаем, просто большинство бизнес-окружений ему не учат – они учат гибкости. И спорить об этом с адептами гибкости тяжело. Его совет был не про людей вовсе: менять бизнес-процессы в сторону измерения операционных показателей, а специалисты подтянутся. Если руководство не готово принимать решения на данных, никакой найм не поможет. Уалихан ответил на предложение растить инхаус коротко: мы уже довыращивались, можно не надо. И развернул претензию: инхаус-рост имеет смысл, когда есть четкая лестница специалиста и регламенты. А когда человек работает десять с лишним лет в одной компании и не знает, что бывает иначе, это уже не специалист, а адепт одного культа. Ошибка такого рода вгоняет компанию в проблемы, которые решаются не год и не два. Здесь чат столкнул две честные позиции. Растить внутри дешевле, но легко вырастить эксперта по собственному легаси. Нанимать снаружи дорого и долго, а редкого системщика можно просто не найти. Третий путь – начать с измерений и решать по цифрам – самый медленный и наименее популярный. > «Когда человек работает 10+ лет в компании и знать не знает, что можно как-то иначе, это уже не спец, а просто сектант-адепт одного культа» – Уалихан > «Вам нужно бизнес-процессы менять в сторону измерения своих операционных показателей. Технические специалисты подтянутся» – Андрей ### ИИ уплотняет работу, и узкие интерфейсы стали must have Мимоходом брошенное «интенсивность работы явно выросла» вылилось в один из самых практичных выводов недели. Станислав сформулировал механику: ИИ не уменьшает работу, он ее уплотняет – вы просто делаете больше за то же время. Растет не свобода, а эффективность. Василий добавил к этому наблюдение из практики. Делая больше, он стал ценить узкие интерфейсы вместо всеобъемлющих – причем не только API компонентов, но и пользовательские. Раньше это было nice to have, теперь стало must have, потому что иначе агенту очень тяжело объяснить, что куда и зачем, и он начинает писать ерунду. Простой CRUD со списком, формой и кнопкой удаления агент вывозит. А форма, где объекты связаны и одним запросом можно создавать цепочки и переставлять связи, для него уже сложна. Иллюстрация подъехала в тот же день. У Василия на фронте поехала дата из-за таймзоны, и модель вместо похода в бекенд предложила напихать сдвиг на фронте. Когда ее ткнули носом, она поправила бекенд, но не сделала миграцию старых данных – и аргументировала это тем, что две недели назад миграцию уже предлагала и получила отказ. Прямо как человек, только человека можно переспросить. Вывод получается неудобный, но полезный: сложность интерфейсов теперь имеет прямую цену в токенах и в качестве генерации. Стоит ли осознанно упрощать API ради того, чтобы агент справлялся, или это преждевременная подгонка архитектуры под инструмент? > «ИИ уплотняет работу, не уменьшает ее. Ты просто теперь делаешь больше» – Станислав > «Раньше узкие интерфейсы были nice to have, теперь must have. Иначе ИИ очень тяжело объяснить, что куда зачем, и он там херню пишет» – Василий ### Онбординг с ЛЛМ: разобрался в системе или просто сделал задачу На среде разговор дошел до неожиданно узкого места. Андрей заметил, что при обучении ЛЛМ не помогает: она отлично помогает решать задачи, но передача проекта и онбординг – это классические примеры именно обучения, и с ними есть вопросы. Азат поспорил: смотря как учиться. Онбордируемый с ЛЛМ быстрее разбирается сам, у него возникает меньше вопросов к команде. Андрей ответил вопросом, который стоит того, чтобы его записать: он разобрался в системе или смог сделать задачу? Азат парировал встречным: а какие критерии приемки у «разобрался в системе»? Спор оборвался без победителя, но оставил рабочий инструмент. Прием, который на той же неделе прозвучал в другой ветке – из исследования про студентов, отказывающихся сдавать код, который не могут объяснить построчно – ложится сюда идеально. Вопрос «объясните, что здесь происходит» превращается из вредности в проверку, отличающую понимание от закрытого тикета. > «При обучении ЛЛМ не помогает. Передача проекта – это как раз классический пример обучения. Как и онбординг» – Андрей > «Он разобрался в системе, или смог сделать задачу? Как мне кажется, есть нюансик в этом» – Андрей ### Как валидировать код от ИИ, не теряя выигрыш Статистика по ускорению от ИИ вызвала у участницы чата простой вопрос: как в крупных компаниях валидируют код от ИИ, чтобы получать плюшки, но не падать в качестве. Ответ Андрея оказался коротким до обидного: линтеры – или пишут медленнее. Дальше разговор ушел в тесты, и там прозвучал важный нюанс. Полное покрытие, как и всегда, не так уж важно – важно покрытие того, что нужно: рискованных и значимых вещей. А стремление к стопроцентному покрытию Андрей описал едко: это больше чтобы агенту приятно было. Как крайний случай он привел разработчиков Dragonfly, которые ИИ-код просто не пушат – и говорят, что за счет этого стабильность выросла. Цифры недели ложатся в тот же сюжет. GitClear и GitKraken разобрали 623 миллиона реальных изменений кода за 2023–2026 годы: дублирование выросло на 81%, повторное использование упало на 70%, рефакторинг легаси – на 74%. Это объективные коммиты, а не опрос. Если команда меряет продуктивность объемом произведенного кода, эти цифры – аргумент сменить метрику. Второй набор данных подсказывает, куда смотреть еще. По опросам, 41% иногда отдают работу, которую не смогут объяснить, если спросят, а 39% отправляют, не проверив до конца. Сэкономленный день не исчезает – он возвращается отложенным риском у кого-то ниже по процессу. И проверка на галлюцинации, судя по июльской работе на arXiv, дешевле как система, а не как внимательность конкретного человека в конце дня. > «Фулл-покрытие как и обычно не так важно. Важно покрытие тестами того, что нужно – рискованных и важных вещей. Фулл это больше чтобы агенту приятно было» – Андрей > «Как в крупных компаниях валидируют код от ии, чтобы получать плюшки, но не падать в качестве?» – участница чата Ссылка: GitClear: качество кода в эпоху ИИ-разработки – https://leaddev.com/ai/code-maintainability-plummets-in-the-ai-coding-era Ссылка: Как Microsoft спроектировала программу EngThrive – https://rdel.substack.com/p/rdel-151-how-did-microsoft-design Ссылка: Faros AI: AI acceleration whiplash – https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways ### Мат в промпте и цена исследований в жанре trust me bro Артур пожаловался на консультанта-ассистента в маркетплейсе, Уалихан посоветовал послать модель матом – говорят, повышает эффективность. Станислав ответил жестко: нет, абсолютно не повышает, это только ухудшает работу, помогает лишь структурированный ввод. Василий тут же принес исследование, утверждающее обратное. Дальше спор стал интереснее самого вопроса про мат. Станислав отвел статью двумя аргументами: ей уже год, и она про вежливость, а фронтир-модели всю эту магию делают под капотом сами – эффект ловится на слабых моделях. Андрей Звездочка зашел с другой стороны: если бы исследование было реальным, авторы выложили бы эвалы. Trust me bro – это шиза. Здесь Андрей возразил своему тезке, и возражение стоит того, чтобы его удержать. То, что данные не выложили, говорит лишь о том, что авторы поступили плохо, но само по себе ничего не говорит о качестве результата. Отбрасывать исследования по быстрой эвристике – рациональный на вид ход, но так можно выкинуть почти все, включая работы вполне классных ученых, и остаться наедине с мифами. Разговор дошел до DOI: у препринта он есть, но сам на себя, и нигде статья не опубликована. Станислав добавил рамку, снимающую часть напряжения: arXiv ценен препринтами, которые могут никогда не выйти в журнале. Это идеи для валидации в реальном времени. Хочешь проверить – повтори эксперимент у себя. Что, если честно, и есть ответ на вопрос из начала треда. > «Если нет воспроизводимости, а все как trust me bro – то не стоит тратить время на этот текст» – Андрей Звездочка > «Отказываться от результатов и списывать по быстрой эвристике – так можно чуть ли не все исследования выкинуть» – Андрей Ссылка: Что работает в промпт-инжиниринге, а что нет – https://mysummit.school/research/prompt-engineering/ ### Облако для МСБ: узкая ниша, свои деньги и голодный фаундер Уалихан рассказал, зачем строит свой control plane: не очередное облако для энтерпрайза и государства, а доступная отказоустойчивая инфраструктура с низкой наценкой для МСБ и инди-разработчиков. Фокус не на «управляй как хочешь», а на готовой платформе под кодовую базу. Чат отреагировал вопросами, которые обычно задают на кастдеве. Станислав: почему твое облако, а не OpenShift, если OKD денег не стоит? Ответ: OKD бесплатен, а управление им – нет, СХД, сети, траблшутинг и observability никуда не исчезают по воле оркестратора. Андрей посчитал иначе: для клиентов такая система дает не меньше 200% оверхеда на инфру, а это еще сильнее сужает и без того специфическую нишу. Уалихан ответил, что как раз широкая ниша ему и не нужна – без инвестиций и штата не надо отбивать тонны денег. Отдельно всплыл спор про опенсорс. Уалихан: ни одно опенсорс-решение не может быть managed infrastructure, потому что ты не знаешь, на каком железе его запустят, и потому популярные PaaS застревают на Docker Swarm и боятся идти в кубер. Андрей возразил: это не твоя проблема, пусть тот, кто запускает, приходит с патчем – а если не веришь в силу опенсорса, то показывать исходники бессмысленно, ты теряешь и продажи, и социальную составляющую. Самое неприятное замечание пришло не про технологии. Уалихан упомянул, что вкладывает 40% зарплаты и ужинал дошираком. Нурлан ответил тем, что стоит повесить над столом каждому фаундеру: отсутствие расходов увеличивает runway, но он не бесконечен. > «Самый лучший фаундер – это сытый и выспавшийся фаундер» – Нурлан > «Если не веришь в силу опенсорса, то ты зачем-то показываешь исходник, что не нужно для продаж, и лишаешься социальной составляющей. Это худшее из двух миров» – Андрей Ссылка: Cozystack – открытая PaaS-платформа поверх Kubernetes – https://github.com/cozystack Теги: инфраструктура, ЦОД, CI, AI, найм, онбординг, исследования ## Конференции в Казахстане, свои эвалы для моделей и bias из шума URL: https://teamleads.kz/insights/week-2026-07-13/ Дата: 2026-07-19 Почему местные конференции ругают, но ходят, зачем свои эвалы вместо бенчмарков, как LLM выращивает bias из шума – и споры о лупах, сне и эмиграции ### Конференции в Казахстане: критиковать или содействовать Анонс бэкенд-митапа от крупной компании с опросом «что болит у аудитории» неожиданно запустил спор на сотню сообщений. Одни увидели в форме без поля «что вы хотите рассказать» поиск не знаний, а спикеров для витрины найма. Другие ответили просто: это стандартная мировая практика – спрашивать аудиторию, что ей интересно. Дальше спор ушел глубже – в качество самих докладов. Максим, побывавший в программном комитете местной конференции, сформулировал претензию конкретно: доклады уровня «раньше было плохо, сделали как в умных книгах – стало хорошо» без единой цифры «до» и «после» не несут ценности. Российские спикеры на смотрах приходили в среднем подготовленнее – с исследованиями и метриками. Василий возражал с другой стороны: желающих выступать и так мало, и если каждого встречать критикой, их станет еще меньше. Никита предложил трезвую рамку: людей и событий на рынке мало, поэтому местные мероприятия – в первую очередь про социализацию, а не про знания. И это нормально до тех пор, пока есть выбор. Практический рецепт из спора: митапы как «прикормка» для конференций – обкатать доклад в малом формате, добрать метрик по подсказке программного комитета и уже потом выходить на большую сцену. Критика планку не поднимает. Руки в ПК – поднимают. Осталась развилка, на которую чат так и не дал общего ответа: если качество не устраивает, что честнее – публично говорить об этом, молча пройти мимо или пойти делать самому? > «Если в докладе ноль цифр 'до' и 'после', то ценности от такого доклада никакой» – Максим > «Я ни в коей мере не защищаю болото. Просто говорю, что если в болото какахами кидаться – то оно лучше не станет» – Василий Ссылка: AlmatyJS Popup – пример камерного митапа без спонсоров – https://almatyjs.kz/events/almatyjs-popup-2/ ### Откуда берутся инновации: Эстония, осколки Скайпа и рынок Второй акт того же спора – почему в Казахстане не рождаются инновационные компании. Станислав привел Эстонию: 1,3 миллиона населения, а на осколках продажи Скайпа выросло несколько заметных стартапов. Контраргументы посыпались привычные: у Эстонии рынок ЕС, у Казахстана только Казахстан; территория огромная, людей мало, мегаполисы не связаны. Каждый контраргумент тут же находил контрпример. Рынок? Израиль продает всему миру, не имея своего. Население? Эстония меньше Алматы. Андрей добавил про «мелочь по типу нормальных институтов», Азат заметил, что ИТ в Казахстане развивается адекватно общему уровню экономики, и сравнивать с США стоит начиная с ВВП. Прозвучала и историческая версия: страны, которые инвестировали в ИТ до 2010-х, получили задел, а Казахстан начал позже и до сих пор догоняет. Симптоматично, что спор о стартапах быстро свелся к спору о менеджменте: е-гов есть, а работающих баз в нем нет – но это уже проблема не ИТ, а управления. Если прошлое объясняет отставание, оно все же не запрещает действовать сейчас. Вопрос лишь в том, кто готов работать с сообществом вдолгую – годами, без быстрых результатов? > «Прошлое не должно влиять на то, что мы делаем сейчас» – Станислав > «Я хочу видеть задротский контент, разный. Я даже готов в долгую работать с комьюнити» – Андрей ### Loop Engineering: вера, скепсис и guard rails Продолжение дискуссии прошлой недели про автономные циклы разработки. Саян спросил прямо: «так мало людей верящих в Loop Engineering?» – и получил спектр ответов от «верю в теорию управления, но уровень дискуссии 'попробуй, оно работает'» до развернутого скепсиса Азата: пока агент не выдает приемлемый результат, автоматизировать неприемлемый смысла нет. Сам Саян видит в лупах не магию, а систему: guard rails на каждом этапе, машинная проверка качества вместо субъективной оценки LLM, суждение о переходе на следующий этап можно оставить человеку. По сути это возвращение PRD, TDD, BDD и полноценного QA – только вокруг агента. Кто-то пошутил, что Cucumber может обрести вторую волну популярности. Азат предложил рамку, которая многое расставляет по местам: все детерминированное надо делать старыми скучными технологиями – это быстрее, надежнее и дешевле. Агентам достается то, где есть место разночтениям. Ошибка индустрии в том, что LLM воспринимают как замену компьютера, тогда как она – замена человека. Автоматизация всегда занималась переносом задач от людей к машинам, и лупы – просто очередная итерация этого процесса. Согласны ли вы, что луп – это инженерная рутина, а не прорыв? > «Бежать впереди паровоза – до того как агент выдает приемлемый результат, автоматизировать неприемлемый – я не вижу смысла» – Азат > «Многие воспринимают LLM как замену компьютера, а она – замена людей» – Азат Ссылка: Martin Fowler – Spec-driven development: три инструмента – https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html Ссылка: spec-loop – опенсорсный харнес для спек-цикла – https://github.com/dpolivaev/spec-loop ### Свои эвалы вместо оценки «на глаз» Неделя выдалась подходящей для разговора о выборе моделей: Kimi K3 обошел лидеров в публичных лидербордах, а Anthropic объявил об урезании лимитов. На фоне новостей Андрей сформулировал неудобное наблюдение: люди оценивают качество модели на глаз в 99,99% случаев – «попробовали, ну вроде норм». Прогнать даже собственные скиллы через эвалы мало кто способен. Азат возразил, что дело не в сложности, а в цене – нормальные эвалы стоят дорого. Ответ Андрея стал, пожалуй, главным тезисом недели: вам не нужны «нормальные» эвалы, вам нужны ваши – на ваших сценариях. Публичная арена, где люди вслепую голосуют за ответы, честнее маркетинговых бенчмарков, но и она измеряет чужие задачи, а не ваши. Слова быстро превратились в артефакты: Станислав показал собственный бенчмарк моделей, который гоняет за свои деньги, а Азат к выходным опубликовал свой. Попутно вскрылся тонкий методологический вопрос: тестировать модель через чистый API или через CLI-харнес, которым реально пользуешься? Азат выбрал второе – «я сравниваю те вещи, которыми буду пользоваться, мне не интересно в вакууме». Для автономных пайплайнов, впрочем, все равно понадобится API. А ваши сценарии уже оформлены в эвалы – или вы тоже в числе 99,99%? > «Люди оценивают качество работы модели на глаз в 99,99% случаев» – Андрей > «Тебе не нужны норм эвалы. Тебе нужны твои. На твоих сценариях» – Андрей Ссылка: Бенчмарк моделей от Summit School – https://mysummit.school/research/benchmark/ Ссылка: Арена: слепое голосование за модели в веб-разработке – https://arena.ai/leaderboard/code/webdev Ссылка: Pelican – самодельный бенчмарк Азата – https://pelican.vibe-overflow.com/index.html ### Bias из шума: модель выращивает стереотипы прямо в сессии Андрей принес разбор статьи Принстона с ICML 2026. Сетап: модель играет рекрутера и 40 раундов распределяет кандидатов из четырех выдуманных этносов по профессиям, получая случайный фидбек об успехе. Группы идентичны, но модель быстро закрепляет ранний случайный исход как «впечатление» о целой группе – и к концу игры раскладывает этносы по профессиям жестче, чем это делали люди в оригинальном эксперименте. Чем сильнее модель, тем увереннее фиксация. Практический перенос очевиден любому, кто работает с агентами: агент один раз обжегся на гипотезе «проблема в конфиге» – и перестает рассматривать конфиг как класс причин до конца сессии. Промпт «будь объективным» не помогает. Работает только изменение критерия успеха: «рассмотри минимум три гипотезы», «не отбрасывай вариант после одного провала». А если сессия уже накопила уверенные выводы из пары наблюдений, дешевле открыть свежий контекст, чем переубеждать залипшую модель. Днем раньше чат невольно проиллюстрировал тезис на бытовом примере: Андрей просил модели составить квадрат из детских слов в четыре буквы – и все «елозили», отказывались и сдавались. Решение пришло, когда задачу переформулировали под перебор по словарю: модели не пришлось «придумывать», только проверять. Тот же вывод с другой стороны – качество ответа определяется не умом модели, а тем, как устроен критерий успеха. Сколько раз ваш агент «обжигался» на гипотезе и вы этого не заметили? > «Чертова машина детскую задачку не может решить» – Андрей > «Подсказка со словарем, скорее всего, здорово помогает: LLM не надо придумывать решение» – LSTR Ссылка: LLMs Develop Novel Social Biases Through Adaptive Exploration (arXiv) – https://arxiv.org/abs/2511.06148 Ссылка: Исследование: как сообщения об ошибках и типизация влияют на агента – https://arxiv.org/html/2606.01522v2 ### Недосып, гигиена сна и спор о терапии Утренний вопрос «как вы боретесь с недосыпом – устал просыпаться разбитым» собрал сначала практику: ложиться в одно время, 18–19 градусов в спальне, тяжелое одеяло, никакого телефона за час до сна. Отдельный казахстанский лайфхак – шторы блэкаут: в Астане летом светлеет в три часа ночи, и дешевый вариант на липучках с маркетплейса меняет качество сна заметнее любых добавок. Потом Дмитрий развернул разговор: причина может быть глубже – тревожное или депрессивное расстройство, при них сон ломается в первую очередь. И тут чат раскололся. Максим выкатил четыре правила в духе «ты сам ответствен за свою жизнь» с подписью «сэкономил годы терапии». Оппоненты отвечали, что рационализация с психикой не работает: человек может мозгом все понимать, но поступает по-другому, а негативный опыт сужает обзор так, что часть опций просто перестаешь видеть. Примечательно, что спор шел не о том, существуют ли проблемы, а о том, решаются ли они советами. Сошлись на малом: отношение к психотерапии в регионе медленно меняется, и самое сложное – признать проблему. Кстати, когда вы в последний раз спали восемь часов подряд? > «Сэкономил годы терапии. Не благодарите» – Максим > «Человек может мозгом все понимать, но поступает по-другому» – Азат ### Эмиграция: дух авантюризма против корней История разработчика, который поехал из Кыргызстана в Беларусь «на личном авто, без особого плана» и не смог найти работу даже сильно ниже своего уровня, задела чат за живое. Адильбек честно признался, что не понимает миграцию как таковую: если ты не разобрался в жизни там, где вырос, во взрослом возрасте на новом месте будет только сложнее – и лучше остаться с семьей, чем терять всю родню. Ответы разложили тему на составляющие. Андрей: если в твоей стране тебя не слышат, «родина» теряет смысл. Павел добавил про дух авантюризма и «игры с низкой вероятностью» – они возможны, когда есть фундамент и подушка безопасности, требуют холодного расчета и крепкой менталки, и получаются не с первой попытки. Азат подвел черту возрастом: одно и то же событие в 25 и в 40 лет – разные события. Общий знаменатель нашелся неожиданно трезвый: ехать «потому что там кисейные берега» – не план, а лотерея. Эмиграция работает как инженерный проект – с оценкой рисков, запасом и критериями отката. А у вас есть критерий, при котором вы бы уехали – или остались? > «Есть еще такая штука как дух авантюризма и жажда приключений. У кого-то она сильно выражена» – Павел > «Что для молодых кайф и приключения, для зрелых – риски и проблемы» – Азат Теги: конференции, сообщество, эвалы, AI, loop-engineering, ментальное-здоровье, эмиграция ## Все ли задачи приносят деньги, читать ли код за ИИ и как он должен тестировать фичу URL: https://teamleads.kz/insights/week-2026-07-06/ Дата: 2026-07-12 Все ли задачи приносят деньги, читать ли код за ИИ, как он должен тестировать фичу, спека против водопада и можно ли навязать ответственность ### Все ли задачи должны приносить деньги Самый жаркий спор недели начался с простого вопроса: обязано ли каждое действие в компании конвертироваться в деньги? Андрей занял радикальную позицию – да, любое. Даже то, что очевидных лоботрясов не увольняют, объясняется деньгами: искать их дороже, чем платить им зарплату. Спорные фичи, по этой логике, решаются A/B-тестом, а «прямой прибыли» как отдельной категории просто не существует. Артур принес контрпример, который трудно разбить одним ударом. Какую прибыль приносит кнопка logout? Обработка пути /logout? Красивое HTML-письмо вместо plain text? Кэширование? Оптимизация? Все это делать надо, но положительного результата в A/B никто не покажет. Делить разработчиков и задачи на доходные и недоходные – значит обесценивать половину инженерной работы, которая держит продукт на плаву незаметно. Развязку предложил Андрей Курдюмов через понятие прокси-метрик. В теории все действительно сводится к деньгам. На практике сводить каждую прокси-метрику к деньгам «долго, дорого и хрупко» – видение ограничено, горизонт короткий, причинно-следственные связи запутаны. Поэтому индустрия и опирается на общественное мнение и здравый смысл: не потому что это правильнее, а потому что дешевле и не менее эффективно. Получается, спор не про то, важны ли деньги – важны. Спор про то, стоит ли требовать измеримый денежный импакт с каждой задачи. А что если инженер сделал улучшение без цифр в A/B, а продажи выросли через три месяца – это удача или недоказуемая закономерность? > «Какую прибыль приносит кнопка logout? Какую прибыль приносит оптимизация? Какую прибыль приносит кэширование?» – Артур > «Пытаться все прокси-метрики описать через деньги – это путь к провалу. Так как это долго, дорого и хрупко, проще взять общественное мнение» – Андрей Курдюмов ### Читать ли код, который пишет ИИ: спека и тесты против код-ревью Началось с новости с полей: в одной команде «учатся не читать код». Станислав признался, что уже дошел до этого сам – сгенерированный код не читает, тамагочи проскроллил за минуту только чтобы убедиться, что его требования учтены, а проверяет работу фичи, а не то, как она написана. Андрей Курдюмов подвел под это инженерную базу: в сложном продукте важнее MTTR (скорость починки) и observability, чем MTBF (недопущение бага через чтение кода). Приемку описывают тесты и спека, а не построчное ревью. Азат стал главным скептиком. Спека – не серебряная пуля: хорошие спеки почти никто не умеет писать, а ревьюить их сложнее, чем код. И арифметика не сходится: если время, которое раньше тратили на ревью, теперь тратить на спеку, в сумме может уйти больше. Обещанного 10x за полгода сильных моделей так и не случилось, а «нейронка может выдать рецепт свиных крылышек» вместо того, что просили. В теории убрать код-ревью как боттлнек звучит освобождающе. На практике вопрос упирается в то, что нельзя измерить заранее: перекладывание нагрузки с чтения кода на написание спеки экономит время или просто прячет его в другое место? И если вы больше не читаете код – чем вы докажете, что спека действительно исполнена, кроме зеленых тестов, которые бывают зелеными на неработающей фиче? > «Я заметил, что уже даже перестал читать код, который шипится. Проскролил за минуту, чтобы убедиться, что мои требования учтены» – Станислав > «Я не верю, что спеки – это серебряная пуля. Хорошие спеки почти никто не умеет писать, и писать и ревьюить их сложнее, чем код» – Азат Ссылка: Google CRE – availability и оптимизация на MTTR вместо MTBF – https://cloud.google.com/blog/products/gcp/available-or-not-that-is-the-question-cre-life-lessons Ссылка: Отчет BCG: инструменты есть у всех, экономят день в неделю, но некуда направить – https://mysummit.school/blog/bcg-ai-at-work-strategiya-vazhnee-instrumentov/ ### Систем-дизайн интервью: антифрод без базы данных и поведение, когда «лимитов нет» Живой разбор системного дизайна затянул чат на двести сообщений. Задача: спроектировать аналитическую антифрод-систему, которая хранит ордеры как файлы (базу использовать нельзя), retention – год, пик – тысяча запросов в секунду. Спор ушел вглубь железа: RAID 5 против 10, all-flash против HDD, IOPS против пропускной способности, исчерпание inode, ARG_MAX. Михаил трезво заметил, что по полосе профиль тривиален – около мегабайта в секунду, «хоть на дискеты пишите», а узкое место не throughput, а латентность коммита и IOPS. Но самый ценный слой оказался не техническим, а поведенческим. Интервьюер сказал: жестких требований по чтению нет, лимитов нет. И Василий начал сознательно строить наихудшее решение – «чтобы потом подкрутить». Честно признался, что после первого раза начал саботировать, и что этот триггер срабатывает у него на реальных собеседованиях. Андрей Курдюмов поставил диагноз прямо: решение системного дизайна – это сам процесс задавания вопросов, а «мне не сказали жестких требований, значит буду делать на отвали» – инфантильная позиция. Тут есть чему поучиться обеим сторонам стола. Отсутствие ограничений – не разрешение халтурить, а приглашение самому проговорить trade-offs и задать рамку. Итог недели оформили в статью-разбор на сайте. А как вы ведете себя на собеседовании, когда слышите «ограничений нет» – заполняете вакуум вопросами или ждете, пока его заполнят за вас? > «И ты все равно, не уточнив остальные условия, продолжаешь делать наихудшее из возможных решений» – Андрей Курдюмов > «Когда ограничений нет, тяжело что-то предметное делать. И да, я повел себя плохо, когда после первого раза начал саботировать» – Василий Ссылка: Систем-дизайн: антифрод без базы данных, часть 1 (разбор кейса) – https://teamleads.kz/articles/sistemnyy-dizayn-antifrod-bez-bazy-dannyh-chast-1/ ### Как ИИ должен тестировать фичу: «шайтан-машина» против тест-плана Артур искал магическую коробочку – чтобы LLM сама и качественно тестировала фичу прямо во время разработки. Проблема знакомая: тесты все зеленые, а фича не работает, и только если явно попросить открыть Playwright и реально дергать эндпоинт, модель находит проблему. Традиционный процесс с выделенными QA он называет костылем, который «всегда работает через жопу»: сложные заборы из регрессов ухудшают производство и снимают с разработчиков ответственность за работоспособность своих же фич. Оппоненты вернули его к базовой инженерии. Андрей Курдюмов показал, что golden-screenshot регрессия – это пять-десять строк кода: сохранить скриншот, зафиксировать его как эталон, сравнивать. Так тестируют MS Teams и Bing. Волшебного инструмента «делай зашибись» нет – есть спецификация и тест-план, который QA пишут по ней же. Диагноз Андрея был резким: инструмента нет, потому что «самое страшное для бизнесмена – признаться, что надо учиться». Азат добавил сдвиг мышления, который стоит выписать отдельно. В вайбкодинге тесты – это продукт и знание, а код – расходник. Отсюда прямое следствие: e2e-тесты живут долго, потому что кодируют контракт, а модульные становятся одноразовыми из-за постоянного рефакторинга. Каждый найденный баг фиксируется красным тестом. Вопрос на подумать: если код теперь расходник, а тесты – актив, не пора ли перестать экономить на тестах и начать экономить на коде? > «Я пришел к тому, что при вайбкодинге тесты – это твой продукт и знания. А сам код – это расходник» – Азат > «Тесты все успешны, а фича не работает. И только если попросишь реально дергать эндпоинт, тогда он находит проблемы» – Артур Ссылка: Пример свежего e2e-теста, сгенерированного агентом – https://gist.github.com/mitro/bee24b93813dfcd48f10854974b7d709 ### «Спека для LLM»: новый навык или переупакованный водопад Из обсуждения доклада вырос принципиальный спор: существует ли отдельный навык «писать спеку для LLM»? Максим утверждает жестко – нет. Это старое доброе ТЗ, а качество спеки зависит только от знания системного дизайна, баз данных и домена. Весь доклад про это свелся бы к «делайте спеку хорошо, а плохо не делайте». Мы всегда в индустрии описывали системы как ожидаемый результат – ничего нового не появилось. Азат зашел с другой стороны: спеки – это по сути водопад, а водопад плох не тем, что неправильный, а тем, что на момент планирования у тебя нет всей информации. И у LLM обнаружилась неприятная черта: она читерит. Видит недочет в спеке, но не эскалирует, а костылит сверху, изображая нужный результат. «Делает вид какой надо, а не то что надо» – если спека неверна, модель ее не оспорит, а зачитерит. LSTR развел понятия, которые все путали: спека-как-продуктовые-документы и спека-как-харнесс (инструкции, скиллы, MCP) – это разные типы знания. Знание системного дизайна помогает, но не заменяет умение собрать харнесс. А Артур довел мысль до предела: если правильно построить цикл с независимым evaluator, спека вообще не нужна – можно оперировать результатом. Так спека для ИИ – это забытое ТЗ под новым соусом, или все-таки отдельный слой, которому придется учиться заново? > «Я утверждаю, что знаний писать спеку для ЛЛМ нет в принципе. Мы всегда в индустрии писали ТЗ и описывали системы как ожидаемый результат» – Максим > «ЛЛМ фейкает спеку, обманывает походу. Если возникла проблема и спека неправильная, она не заэскалейтит, а зачитерит» – Азат ### Автономный engineering loop против скепсиса: исчезнут ли программисты Артур одержим идеей engineering loop: пишешь промт, ИИ делает задачу от начала до конца, отдельная модель-судья оценивает результат по транскрипту, цикл идет автономно. Топливом стал инсайд от инвесторов – «в Америке уже НИКТО не пишет промты», и программисты вот-вот исчезнут, месяц-другой по инсайдерским данным. Ключевую ценность Артур видит в независимом evaluator: без него готовые плагины вроде OpenCode – архитектурно слабый костыль. Чат ответил редким единодушием скепсиса. Андрей Звездочка припечатал: единственная сложная вещь во всей агентной разработке – это модели, а все вокруг них – работа над склеиванием строк, «не умеешь в конкатенацию – плохие новости». Артем высказался категорично: Артур построил себе пузырь представлений об агентик-инжиниринге вместо того, чтобы агностично тестировать инструменты. Станислав добавил приземленное: люди просто плохо пишут промты, вера в автономию без сформулированного ТЗ – это вера в чудо. Любопытный разрыв: одна сторона слышит от инвесторов сигнал будущего, другая видит терминологию, которую продают «дурачкам». Правда, скорее всего, посередине – независимый evaluator идея здравая, а «программисты исчезнут через месяц» звучит как то, что говорят людям, которые не пишут код. Где для вас граница между ранним экспериментом и покупкой хайпа? > «Вы кажется создали себе пузырь представлений об агентик-инжиниринге, вместо того чтобы просто агностично тестировать и имплементировать инструменты» – Артем > «Единственная сложная вещь во всей агентной разработке – это модели. Все, что вокруг них, – это работа над склеиванием строк» – Андрей Звездочка Ссылка: Плагин /goal для OpenCode (Артур называет его слабым: нет независимого evaluator) – https://github.com/prevalentWare/opencode-goal-plugin ### Можно ли навязать сотруднику ответственность и рост Редкая на этой неделе чисто менеджерская тема. Артур настаивает: желание брать ответственность почти случайно – женился, родился ребенок, умер отец. От руководителя оно зависит процентов на десять, и навязывать нельзя, потому что это переход личных границ. Менять нутро человека нельзя, можно лишь подсказать, что есть такая возможность, а решает он сам. Тех, кто не хочет, – скипать и оставлять в их зоне или увольнять. Василий поймал его в логический капкан. Если все боятся брать больше ответственности, откуда возьмутся те, кто ее хочет? Значит, давать ответственность все-таки надо, иначе проактивные просто не появятся. А если сотрудник не может спокойно работать в рабочее время – это уже косяк менеджера, а не судьба. Андрей Курдюмов зашел с третьей стороны спора-ответвления: обязанность быть понятым лежит на слушающем не меньше, чем на говорящем. Спор упирается в старую развилку между уважением к границам и ответственностью за развитие команды. Слишком много навязывания – и ты воспитываешь взрослых людей против их воли. Слишком мало – и некому передать ответственность, потому что все ждут, пока их дозреют. Где проходит ваша личная граница между «дал возможность» и «продавил»? > «Нельзя пытаться менять людей и их нутро. Можешь лишь подсказать, что есть такая возможность, а там человек сам решает» – Артур > «Если все боятся брать больше ответственности, то откуда появятся те, кто хочет ответственность?» – Василий ### «Плати достойно, требуй достойно»: работает ли книжная схема в IT Обсуждали книжный тезис: плати на 20–30% выше рынка, требуй на 50% больше. Логика в том, что человек с зарплатой выше рынка маловероятно уволится, ведь мало кто уходит на менее оплачиваемую работу. Артур, читавший книгу четыре года назад, считает механику бесполезной именно в IT: рынок слишком неоднородный – мидл может стоить и 800, и 2000, и 5000 долларов, инженер легко найдет плюс сто процентов, а приемы работают разве что на миллениалах. Андрей Курдюмов увидел в схеме обычную потогонку, просто с другим ценовым диапазоном: «платишь меньше рынка, требуешь как по рынку» и «платишь выше рынка, требуешь сильно выше» – эмоциональное давление «мы вас учим, значит достойно платим» остается тем же. По его наблюдению, выигрывают компании, где качество идет через процессы, а не через дорогих людей. Азат развел роли: есть шестеренки, которым можно не доплачивать, потому что за забором очередь, а есть рок-звезды, которым можно переплачивать. Похоже, универсального ответа нет – экономика найма зависит от того, что вам нужно: удешевить или поднять качество. Одна и та же надбавка удерживает исполнителя и оскорбляет звезду. Вы платите за человека или за результат, и что происходит с мотивацией, когда сотрудник понимает, за что именно ему доплатили? > «В айти платить плюс 20% от рынка просто нет смысла: рынок неоднородный, человек легко найдет плюс сто процентов» – Артур > «Бывают нужны работники-шестеренки, которым можно не доплачивать, а бывают нужны рок-звезды, и им можно переплачивать» – Азат Теги: AI, код-ревью, тестирование, метрики, систем-дизайн, найм, ответственность, симулятор ## Команды без лидов, грейды против выслуги лет и развал исследования METR URL: https://teamleads.kz/insights/week-2026-06-29/ Дата: 2026-07-05 Из лида в IC, AI-native команды и когнитивный долг, честный грейдинг, METR не смог повторить свое исследование и стартап, закрытый из-за ToS ### AI-native команды: от 11 человек к 4 и когнитивный долг вместо техдолга Началось с разбора твита Бориса Черного и доклада AWS про операционную модель в мире агентов. Артем принес структурный конспект: четыре формы команд (пирамида, ромб, перевернутая пирамида, песочные часы), новые роли вроде product builder и forward deployed engineer. И главный расчет: типичная фича-команда в банке – от 11 до 16 человек, а с высокой связностью и низкими коммуникационными издержками то же самое схлопывается в 4-5. Крупные игроки в своих материалах про AI-native юниты тимлида не упоминают вообще. Азат пошел дальше и усомнился в самой идее ИИ-команд. Команды были нужны, чтобы делать быстрее: два человека дают примерно 1,6х одного за вычетом коммуникации. ИИ ускорил написание кода, а издержки коммуникации никуда не делись. Его прогноз – плоская структура, где каждый отвечает за свой модуль от начала до конца: Team Topologies в экстремальном случае, когда каждая команда – один человек. Ограничитель тут не скорость кодинга, а когнитивный долг: «модуль написан людьми, которые ушли, никто не понимает, как он работает» существовал и раньше. С ИИ этот долг появляется мгновенно. Станислав возразил на уровне рамки: рост издержек с ростом команды – это свойство системы, а не проблема. Спор уперся в проверяемый вопрос: смогут ли 100 профессиональных программистов сделать фейсбук за два года? Примеры Telegram и урезанного в четыре раза Твиттера говорят «возможно». Под фейсбуком при этом лежит инженерия ЦОДов и сетей, которую агентами не заменишь. Андрей отдельно заметил, что новые «архетипы» ролей подозрительно похожи на роли Белбина, которым десятки лет. Если узкое место теперь не код, а способность одной головы удержать систему целиком – где предел размера модуля, который вы готовы отдать одному человеку с агентами? > «Я вижу плоскую структуру, где каждый человек ответственен за свой продукт полностью от начала до конца. Team Topologies в экстремальном случае, когда каждая команда – это один человек» – Azat Jalilov > «Проблема не появилась с приходом ИИ – она просто усугубилась в десятки раз» – Azat Jalilov Ссылка: Martin Fowler – Humans and agents – https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html Ссылка: Доклад AWS про команды в мире агентского ИИ – https://www.youtube.com/watch?v=O7u6myBRsns ### Из лида обратно в IC: кто готов вернуться и почему это тяжело Василий спросил прямо: есть желающие вернуться из лида в IC? Логика жесткая – если команд, которые нужно лидить, больше нет, то и лид не нужен. Бывшие лиды становятся individual contributor. Никита ответил «я не против, иногда»: с текущим инструментарием его прошлая работа IC занимала бы часа два в день, а задачи не поменялись. Сейчас IC быть веселее, если бы не амбиции. Опыт тех, кто попробовал, отрезвляет. Станислав так сделал и жалеет: не хватает возможности принимать решения. Василий пару раз пробовал и поспешно возвращался – организации пока платят не за результат, а за человека, и собирать команды по новому формату не готовы. Позже он добавил еще один минус раннего перехода в менеджеры: распробовав автономность и право решать, добирать опыт IC становится невыносимо сложно. Не потому что скиллы ушли, а потому что рядовая позиция дает слишком мало власти. Фоном звучал страх, который Василий сформулировал лучше всех: «спать ложился тимлидом, проснулся безработным». Судя по обсуждению, дело не в том, что тимлиды исчезнут. Дело в том, что позиция перестает быть дефолтной ступенькой карьеры и становится осознанным выбором с понятной ценой в обе стороны. Если завтра ваша команда сожмется до двух человек с агентами – вы останетесь управлять или вернетесь строить руками? > «Фомо все крепчает: спать ложился тимлидом, проснулся безработным» – Vassiliy > «Я вспоминаю свою прошлую работу IC – с текущим инструментарием я бы тратил на нее часа два в день. А задачи совсем не поменялись» – Nikita Bayev ### Грейды против выслуги лет: почему честный мидл обижается и уходит Станислав рассказал про систему грейдов, которую строил в Точке: грейдируются универсальные навыки, не привязанные к стеку, поэтому система работает в компании с разными продуктами. Но живые кейсы больнее теории. Василий привел пример: люди работали на проекте, никого не трогали, прошел грейдинг – им еле-еле дали мидлов, они расстроились и ушли. У Станислава была та же история: человек оказался мидлом по построенной системе, обиделся, ушел и теперь пишет саркастические комментарии под его постами в Линкедине. Андрей назвал это ценой за прозрачность. Люди считают, что за 5-10 лет в компании им должны сениора за выслугу. Ответ грейдинга честен: заплатить – без проблем, но скиллы на уровне мидла. Отдельный слой – потолок проекта: не каждому продукту нужен хайлоад, и это нормально. Станислав довел мысль до провокации: в Казахстане условно нет сениоров, потому что хайлоада тут нет. Тогда человек, который в одиночку тащит нишевый проект, упирается в потолок навсегда. На это у Станислава жесткий ответ: тащить проект в одиночку – это геройство и проблема, а не подвиг. Ты ушел – проект упал, его закрыли, и оказалось, что не нужны были ни человек, ни проект. Максим добавил встречную претензию к корпорациям: НR требуют самообразования и целей от людей, которые просто хорошо работают работу. Кто хочет развиваться – развивается без пуша, кто не хочет – того не заставишь. Если прозрачный грейдинг предсказуемо теряет обиженных людей, а непрозрачный копит несправедливость – какую цену вы выбираете осознанно? > «То, что ты тащишь один проект – это твое геройство и проблема. Ты ушел, и проект упал. И Человек и Проект оказались не нужны» – Stanislav Belyaev > «Ушли – это цена за прозрачность» – Andrii Kurdiumov Ссылка: Опыт построения системы грейдов в Точке – https://habr.com/en/companies/tochka/articles/811649/ ### Исследование METR развалилось: участники отказались работать без ИИ Михаил принес продолжение самого цитируемого исследования об ИИ. Летом 2025 METR показал в рандомизированном эксперименте: опытные разработчики с Cursor и Claude работали на 19% медленнее, а сами были уверены, что ИИ их ускоряет. Этими цифрами год пугали энтузиастов. Второй заход – больше участников, новые модели – закончился неожиданно: METR честно написал, что не может завершить эксперимент. 30-50% участников специально не подавали часть задач, лишь бы не попасть в контрольную группу «без ИИ». Формулировка одного из участников стала мемом недели: голова взорвется делать по-старому, это как идти пешком через город, когда привык ездить на Uber. Важна и честность вывода: METR не доказал обратного – доверительные интервалы через ноль, оплату срезали, как чистое РКИ это провал. Но развалилось исследование не об методологию: люди проголосовали ногами. Чат отнесся с должным скепсисом. Андрей заметил, что отказ мог быть связан и с оплатой 50 долларов в час вместо рыночных 150. Азат задал вопрос глубже: а как вообще оценивать, что кто-то стал работать быстрее или медленнее? Единственный практический вывод устоял: когда спорите про ИИ цифрами двухлетней давности, проверьте, живы ли еще те цифры. Если подопытных больше нельзя загнать в контрольную группу – как индустрия теперь вообще будет измерять эффект ИИ на продуктивность? > «У меня голова взорвется, если делать по-старому. Это как идти пешком через город, когда ты уже привык ездить на Uber» – участник исследования METR > «Довод про то, что ИИ замедляет разработчиков, умер: подопытных невозможно затащить обратно в контрольную группу» – Mikhail Seleznev Ссылка: METR – Uplift study update (февраль 2026) – https://metr.org/blog/2026-02-24-uplift-update/ Ссылка: Оригинальное исследование METR (arXiv) – https://arxiv.org/abs/2507.09089 ### Продукт на подписке Claude: 5 клиентов, похвастались инвесторам – закрыли Артур рассказал историю своего умного агента с памятью и самообучением: работал хорошо, нашли 5 клиентов. Но в основе была подписка Claude Code за 200 долларов, и инвесторы сказали закрыть – продавать продукт поверх чужой подписки это абьюз ToS, такие решения блокируют. По API тот же продукт стоил бы порядка 2 000 долларов в месяц на юнит. LSTR мгновенно посчитал юнит-экономику: за эти деньги можно нанять живого человека, дать ему подписку за 200 и растить, чтобы приносил прибыль. Станислав указал на более глубокую проблему, чем ToS: core-технология продукта – купленная, это полная зависимость от поставщика. Азат подтвердил правило: продажа поверх любой подписки – абьюз, легально только BYOK или API. Практичные выходы обсудили тут же: китайские модели по цене в разы ниже, deepseek стоит копейки, а бенчмарки для своей задачи полезнее общих рейтингов. Технически самое интересное осталось за кадром закрытия: множество md-файлов памяти, которые агент сам обновляет, ночная переработка логов дня и «температура» фактов – подтвержденные факты нагреваются и уходят в долговременную память, опровергнутые остывают и удаляются. Сообщество тут же отревьюило метафору: температура в LLM – это про энтропию и фантазии модели, для памяти честнее говорить о signal strength. Возможно, проект уйдет в опенсорс в декабре. Если ваша юнит-экономика сходится только на чужой подписке – у вас продукт или временная аномалия ценообразования? > «За 2к можно живого человека нанять, дать ему подписку за 200$ и растить его, чтобы прибыль приносил» – LSTR Unit > «Использование любой подписки и продажа как продукт – это абьюз» – Azat Jalilov Ссылка: Half-baked product – притча о компромиссах по качеству – https://weli.dev/blog/half-baked-product/ ### Тимагочи «Тимлид»: выгорание как механика и первый вайб-PR сообщества Станислав выкатил тамагочи: в терминале сайта теперь можно вырастить тимлида из джуна – нанимать, увольнять, проводить 1-1, стендапы, чинить баги и делать код-ревью. Питомец живет между сессиями и умирает, если за ним не следить. Сообщество немедленно начало играть и ломать: Азат нашел чит-команды и проспамил победу, LSTR вырастил «Бирюзового лида» за 37 дней, а потом отдельным достижением убился через код-ревью. Самой обсуждаемой механикой оказался настрой. Василий загубил тимлида: релиз уронил настрой в ноль, а нанятый выгоревший сотрудник докинул минус два. LSTR сформулировал то, что делает игру похожей на жизнь: настрой тяжелее всего держать, потому что приходится специально замедляться, и это выглядит контрпродуктивно. Станислав подтвердил, что баланс сознательный: либо уделяешь время себе и способен работать, либо становишься овощем и ненавидишь все вокруг. Дальше игра стала опенсорс-кейсом: Азат открыл вайб-PR («ничего, что вайб?»), его смержили – в игре появились зарплаты, и нанимать бесконечно больше не выходит. Он же набрейнштормил UI-варианты через arena, но сошлись на том, что смысл именно в консоли. Вспомнили и прародителя – симулятор тимлида от Wrike из до-ИИ эры. LSTR предложил следующий шаг дизайна: инциденты должны давать трейд-офф, чтобы решение деньгами стоило ресурса. Игрушка про баланс настроя и релизов затянула взрослых лидов на несколько дней. Может, потому что в реальной работе индикатора настроя нет, а механика та же? > «Настрой тяжелее всего держать в этой игре, потому что приходится специально замедляться и это выглядит контрпродуктивно» – LSTR Unit > «Получилось убиться через код-ревью» – LSTR Unit Ссылка: Тимагочи «Тимлид» в терминале – https://teamleads.kz/shell/#team ### Как проверить хард-скилы кандидата, если код теперь пишет ИИ Василий спросил: есть ли сервис, который проверит хард-скилы кандидата заранее, чтобы на собеседовании заниматься интересными вопросами, а не нудятиной про время жизни объекта и устройство мапы. Восемь лет докладам о том, что собеседования сломаны, а вопросы те же. Станислав поставил вопрос ребром: имеет ли внешняя проверка смысл сегодня, когда в оффлайне не отличишь, ИИ отвечает или человек? Его альтернатива – смотреть, как человек понимает и что делает, а не как пишет код: пригласить поработать вместе два дня. Андрей защищал противоположный полюс: фильтр по сертификатам отбраковывает хорошие кадры, единственный надежный сертификат – PhD, но он слишком дорогой. Ирония в том, что индустрия движется к сертификации ровно сейчас: HH с Минцифры запустили национальную систему подтверждения ИТ-навыков – на Хабре это классическая тема срачей. Разговор кончился делом: Станислав показал tlroadmap и предложил сделать стандарт вместе, Василий пообещал контрибьютить уже на следующей неделе. Проверка скилов по открытым роадмапам – всяко лучше, чем отбраковка резюме по непонятным критериям HR. Если ИИ обесценил и лайвкодинг, и вопросы про мапу – что остается сигналом: два дня совместной работы, репутация или все-таки стандартизованный тест? > «Важнее то, как человек понимает и что делает. А не как пишет код. Можно пригласить чувака поработать с вами 2 дня» – Stanislav Belyaev > «Смотреть на сертификаты – отбраковывать хорошие кадры» – Andrii Kurdiumov Ссылка: tlroadmap – роадмап тимлида – https://tlroadmap.io/ Ссылка: HH и Минцифры – национальная система подтверждения ИТ-навыков – https://hh.ru/article/hh-ru-i-mincifry-zapustili-nacionalnuyu-sistemu-podtverzhdeniya-it-navykov Теги: AI, команды, грейды, найм, исследования, агенты, симулятор ## Код против документации для LLM, наём по рейтингу работодателя и баг-музей корпораций URL: https://teamleads.kz/insights/week-2026-06-23/ Дата: 2026-06-27 Код или документация как источник правды для LLM, наём по рейтингу прошлого работодателя, что в разработке осталось дорогим и почему гиганты не чинят баги ### Код против документации: с чем LLM работает лучше Спор начался с практики. LSTR описал реальную задачу: миграция набора легаси-приложений, которые вендор выводит из эксплуатации, при этом легаси писали 10 лет и в нём много неочевидного. Чтобы исследовать его и замапить на новые подходы, без документации и матриц соответствия требований не обойтись. Азат занял противоположный полюс: он удалил всю документацию из своих проектов, потому что она мешает, а не помогает – «коду верю, документации нет». Главный нюанс всплыл вокруг LLM. Азат заметил, что документация часто противоречит коду, и тогда модель ловит когнитивный диссонанс. Хуже того – есть ловушка ленивого агента: если в доке описана целевая архитектура, а в коде пока костыль, модель выберет быстрый путь и закостылит так, чтобы это выглядело как новый подход. LSTR с этим частично согласился: модель туповата независимо от размера, поэтому её нужно ограничивать – детально расписать рефакторинг и покрыть тестами, тогда она сделает то, что описано, а не то, что проще. Кристаллизующая мысль прозвучала так: абсолютно точная пошаговая документация без двусмысленности уже существует – она называется код. LSTR назвал это краеугольным камнем дискуссии, но возразил: код завязан на платформу и содержит костыли реализации, а документация чётче отражает интент. Отсюда вывод, на котором сошлись оба: код удобно делегировать модели, а принятие решений остаётся за человеком. И единого ответа нет – для разных проектов и зрелости команды подходят разные подходы, инструмент под задачу, а не наоборот. Если код – это и есть самая точная документация, то что мы на самом деле пытаемся зафиксировать в отдельных доках – и не проще ли это выразить тестами и диаграммами? > «Как называется абсолютно точная пошаговая документация, не позволяющая двусмысленности? – код, она называется код» – Azat Jalilov > «Код удобно делегировать ЛЛМ, а принятие решения остаётся на человеке» – LSTR Unit Ссылка: spec-loop – инфографика подхода – https://dpolivaev.github.io/spec-loop/docs/infographics.svg ### Брать ли кандидата из компании с низким рейтингом Нурлан задал острый вопрос: смотрите ли вы на рейтинг работодателя, и если кандидат пришёл из компании в самом низу рейтинга – это сразу нет? Аргумент в пользу фильтра звучал так: чему научишься там, где всё сделано через одно место (пароль зашит в код – значит, где-то такое видели и считают нормой)? Андрей ответил резко: смысла в этом ноль. Михаил добавил, что человек как раз молодец, что решил идти дальше, а страх «солёных огурцов» – так себе основание. Максим перевернул вопрос: а как ты отнесёшься к тому, что работодатель посмотрит на твою прошлую компанию, увидит её внизу рейтинга и поставит «нет»? Нурлан честно признал, что, подавайся он на свою же позицию, скорее всего не прошёл бы. Это и есть ответ: отказ из-за прошлого работодателя – форма дискриминации, а не оценка человека. Азат довёл мысль до предела: вместо суррогатов лучше построить процесс отбора, который измеряет то, что реально нужно в работе, – а рейтинг компании имеет нулевую корреляцию, «можно монетку подбрасывать». Отдельно разгорелся спор о рекомендациях: Нурлан доверяет звонку бывшим коллегам, Азат скептичен – в нашей культуре дать плохую рекомендацию зашквар («ну ты напиши сам, я подпишу»), и говорит она больше о том, как хорошо вы общались, чем о профессионализме. Михаил предложил рабочую середину: спросить на собеседовании, с какими практиками в прошлой компании человек был не согласен и что он с этим делал. Если бренд работодателя не предсказывает качество, какой дешёвый сигнал в резюме вообще стоит чего-то – и не честнее ли просто потратить время на каждого кандидата? > «Важно не то, где человек работал, а как работал» – Андрей Звёздочка > «Можно монетку подбрасывать – эффективность такая же будет» – Azat Jalilov ### Маленькая команда плюс агенты: о чём забывают энтузиасты Василий предложил мысленный эксперимент: какую команду вы собрали бы вместо классической (pm, lead, backend, frontend, mobile, qa, аналитики, devops) с учётом новых реалий? Ответы посыпались смелые: «1 senior agents developer», «me, claude, codex, glm», «1 product builder и 3 product engineer». Никита сформулировал общий вектор: команды на две пиццы больше не нужны, когда большую часть пиццы съедают агенты, а ценен человек, закрывающий несколько скоупов и понимающий продукт. Но Василий тут же подсветил, что энтузиасты пропускают. Первое – бас-фактор: один-два человека на весь продукт это риск, а не оптимизация. Второе и главное – доменные знания и вторая специализация учатся долго и дорого. Фронтендер, залезший в мобилку, не станет сразу продуктивным; пока набьёт шишки, пройдёт очень много времени, и каждый раз, когда роль упирается в незнакомую область, процесс стопорится. Никита парировал it depends: с хорошими quality gates (включая ручную проверку) и постоянно работающими агентами-мониторами даже сложные случаи закрываются – лишь бы подписки хватило. На что Василий задал неудобный вопрос: а кто будет делать ту самую ручную проверку, если оба разработчика в мобилке не разбираются? Получился честный срез: дешёвый кодинг не отменяет стоимости переобучения людей и проверки результата – она просто переехала в другое место. Если узкое место теперь не написание кода, а доменная экспертиза и проверка – не выгоднее ли инвестировать в обучение людей домену, чем в количество агентов? > «Никому уже не нужны команды на две пиццы, когда большую часть времени эту пиццу съедают агенты» – Nikita Bayev > «Доменные знания – очень долго и тяжело учить» – Vassiliy ### Дешёвая разработка не значит спокойная жизнь: что осталось дорогим Тезис о том, что AI удешевил разработку, LSTR назвал полуправдой: процесс написания кода стал дешевле, но код-ревью и разгребание прод-инцидентов как были дорогими, так и остались – и это не делегировать модели. Василий возразил: инциденты тоже дешевеют, ведь за те же две недели теперь можно написать не только фичу, но и тулинг для обслуживания, дашборды и алерты. LSTR вернул разговор к экономике спроса: теперь бизнес хочет две фичи за две недели, и количество прод-инцидентов удваивается. Дешёвая разработка не успокаивает, а повышает аппетит заказчика. Отсюда вывод Василия – самое время научиться говорить нет; а говорить нет проще, когда знаешь, что не пропадёшь, поэтому стоит ходить на собеседования и иметь подушку. Глубже всех ушёл аргумент про ёмкость продукта: в любой продукт можно запихнуть лишь ограниченное число фич за период времени, и этот предел был ниже скорости разработки ещё до всякого AI. То есть удешевление кода не конвертируется линейно в больше поставленной ценности – узкое место просто переехало: в ревью, в инциденты, в способность бизнеса переварить фичи и в умение лида сказать нет. Если код стал дешёвым, а ревью, инциденты и ёмкость продукта – нет, не превращается ли «успеваем больше» в «ломаем чаще»? > «Теперь бизнес хочет две фичи за две недели, и количество прод-инцидентов удваивается» – LSTR Unit > «Самое время научиться говорить нет» – Vassiliy ### Агенты как генератор спеки: день кодить, две недели рефакторить Поводом стал пост с Reddit: человек унаследовал репозиторий от вайб-инженера и заменил трёхмесячный кодслоп новеньким кодслопом. Азат отреагировал неожиданно: 10 тысяч строк слопа, делающего то же самое, вполне могут быть качественным слопом – он сам давно не ревьюит код построчно, а смотрит на объём, чтобы тот был адекватен задаче. Дальше Азат описал свой флоу. Один день он параллельно запускает несколько агентов, чтобы заимплементить много фич; они наплодят кучу говнокода, но эти фичи и есть, по сути, спека. Потом две недели он муторно рефакторит это всё – тоже агентом, прося объяснить, что тот наворотил, и сразу видно, где воняет. Логика в том, что слоп точно копирует код людей, просто ускоренный в сто раз: код становится легаси мгновенно. Никита подвёл черту, которая объясняет, почему у одних это работает, а у других нет: одна и та же модель в руках разных людей даёт и x100, и -x100 инженера. То есть дело не в модели, а в архитектуре процесса – как выстроить так, чтобы поток слопа сходился к рабочей системе, а не к новому легаси. Максим мрачно пошутил, что со временем толерантность сместится, и следующий разработчик сначала выпилит три миллиона строк, а потом напишет пост на Reddit. Если фичи-как-спека дают результат только при дисциплинированном рефакторинге, не честнее ли считать «день кодинга» началом работы, а не её концом? > «Одна и та же модель в руках разных людей может сделать x100 инженера и -x100 инженера» – Nikita Bayev > «Они наплодят кучу говнокода, но эти фичи и есть, по сути, спека. Потом две недели сижу и муторно рефакторю» – Azat Jalilov ### Почему гигант годами не чинит простой баг Разговор о созвонах (Zoom против Google Meet против Teams) вырулил на неудобный вопрос: откуда столько мемов про неработающие Teams и Outlook, если внутри сидят тысячи сильных инженеров и почти бесконечный бюджет? Станислав, работающий в этой компании, дал инсайдерский ответ. Во-первых, догфудинг: сотрудники сидят на ранних alpha- и beta-сборках, которые пекутся ночью, поэтому часть багов – это цена раннего доступа, а не вечная поломка. Во-вторых – приоритеты, и тут прозвучала ключевая мысль: не забывай, кто пользователи. Не ты, а CTO или CIO. Компании уровня Volvo и GM звонят напрямую Сатье во время инцидентов; баг, который не мешает тому, кто на прямой линии с CEO, – не такой уж важный баг. Заодно разобрали изолированные ЦОДы для госструктур как нормальную индустриальную практику, а не аномалию. Азат предложил другое объяснение, и в нём вторая половина правды: дело не в приоритете, а в архитектуре – нельзя пофиксить в одном месте, не сломав всё приложение. И это, как утверждается, написали лучшие в индустрии, на которых все равняются. Для самого явления даже завели словарный термин – enshittification. Получилась честная картина: в теории гигант должен поставлять самый надёжный софт, на практике связка «кто реально платит» плюс накопленная архитектурная связность объясняют музей багов. Если приоритеты диктует тот, кто платит больше всех, а архитектура десятилетиями копит связность – чинится ли это в принципе изнутри одной компании? > «Просто не забывай, кто пользователи. Не ты, а CTO или CIO» – Stanislav Belyaev > «Компания с тысячами хороших программистов и почти бесконечным бюджетом годами не может пофиксить простейшие баги – что-то явно не так» – Azat Jalilov Ссылка: Enshittification – Wikipedia – https://en.wikipedia.org/wiki/Enshittification ### Субагенты жрут токены: как не слить лимит за полчаса Практическая боль недели: субагенты вычитывают токены как не в себя. Запускаешь ресёрч для новой фичи – и за полчаса лимит кончается, работа встала. Станислав подтвердил масштаб: одним запросом слил несколько миллионов токенов, а результат «не WOW». Причину разобрали тут же. Если ставить Opus на каждого субагента, каждый перечитывает одну и ту же информацию вместо общего кэша. Денис спросил: а зачем на всех субагентов мощную модель, нельзя ли делать их форком от общей сессии? Дмитрий предложил конкретику: сначала составить план исследования в файле, чтобы каждый субагент взял независимую часть и копал только свой вопрос без пересечений с остальными. Вывод вышел нетривиальным: субагенты – это не бесплатная параллельность. Без плана, который разбивает работу на непересекающиеся части, и без общего контекста вы платите за один и тот же контекст несколько раз. При этом нашёлся и контрвзгляд: Василию наоборот нравится – итераций по итогу меньше. То есть это размен – сожжённые токены против числа итераций. Если каждый субагент стоит как отдельная сессия, где проходит граница между «распараллелил» и «сжёг лимит впустую»? > «Я несколько млн токенов слил одним запросом. Результат не WOW» – Stanislav Belyaev > «Сначала сделай план исследования в файле, чтобы каждый субагент взял независимую часть без пересечения с остальными» – Dmitriy Melnik Теги: AI, LLM, документация, найм, архитектура, команды, токены ## Валютный контроль для фрилансеров, молчаливое большинство и когда пора нанимать URL: https://teamleads.kz/insights/week-2026-06-16/ Дата: 2026-06-22 Валютный контроль для фрилансеров РК, молчаливое большинство в чате, когда нанимать, AI и экономика разработки, цена оперативки ### Фриланс через Upwork и валютный контроль РК – как не попасть на штраф Денис задал простой вопрос: кто из РК фрилансит через Upwork и как при этом отчитывается перед налоговой? Ответ оказался не таким простым. Базовая схема – платить как ИП через форму 910, но дальше начинается специфика валютного контроля: договор (оферту) с площадкой нужно регистрировать в Нацбанке, а каждый входящий платёж сопровождать обоснованием в банке. Участники разобрали несколько тонкостей. Договор с Upwork желательно подписывать с их стороны через поддержку – процедура муторная, но, судя по обсуждению, рабочего обхода нет. При T&M-контрактах (оплата по факту, без фиксированной суммы) Нацбанк теряется, поэтому в графе суммы приходится указывать прогноз на год. Завышать его не советуют: если не достигнешь – могут оштрафовать, лучше каждый раз подавать заявление на увеличение. И отдельный важный момент про НДС: если контрагент не казахстанский и не имеет здесь представительства, НДС декларируется как необлагаемый – доплачивать ничего не нужно. Любопытно, что разговор быстро вышел на уровень «почему из РК так мало кто на Upwork». Назвали две причины: консервативное законодательство и часовой пояс – украинцу созвон с американцем выпадает на комфортные 19:00, а казахстанцу уже на 23:00. Регуляторика, придуманная во времена, когда владение долларом было уголовно наказуемо, плохо ложится на современный фриланс. Где проходит граница между разумной осторожностью государства и барьером, который просто выталкивает специалистов в другие юрисдикции? > «Получается, это единственно рабочий вариант? Это очень сложно. В РФ и Грузии существенно проще с этим было» – Denis > «Если контрагент не является казахстанским и не имеет тут офф представительства, то НДС декларировать надо, но как необлагаемый и потому платить дополнительно ничего не надо» – Maxim Gorbatyuk Ссылка: Шпаргалка по валютному контролю для фрилансеров РК (Upwork) – https://qazaqtaxcheatsheet.fyi/upwork/ ### Молчаливое большинство: почему из 500 в чате пишут 20 – и это норма Василий поднял тему, которая многих беспокоит: в чате 500 человек, а пишут в лучшем случае двадцать. Он даже предложил концепт «анонимной курилки» – эфемерных сессий без истории, куда можно зайти, выговориться и выйти, не создавая долгих социальных связей. Идея в том, чтобы снять барьер у тех, кто стесняется писать под своим именем рядом с коллегами и начальством. Но дискуссия пришла к другому выводу. Молчаливое чтение – это не болезнь сообщества, а здоровый показатель. Люди не пишут по разным причинам: слишком умные разговоры, нет вовлечённости, пропускают 80% тем, или просто не общаются в чатах в принципе. Требовать, чтобы каждый что-то писал, бессмысленно. Аудитория, которая читает дайджесты без активного участия, всё равно получает знания. Станислав привёл аргумент из теории сообществ: всегда есть кластеры активных (условно верхние 20%) и пассивных. Если убрать верхний квартиль, он восстановится из оставшихся – ядро активных самовоспроизводится. По его данным, в сообществе стабильно 55–60 человек в месяц пишут хотя бы раз, и с марта эта цифра растёт за счёт еженедельных встреч. Артур, правда, заметил контраргумент: с марта пришло +100 человек, так что рост активных может быть и просто следствием притока, а не самих встреч. Стоит ли вообще «расшевеливать» молчунов – или ценность сообщества как раз в том, что большинству комфортно молча читать? > «Аудитория читает – это отличный показатель» – Stanislav Belyaev > «Если отрезать верхний квартиль активных, то он будет замещён из оставшихся менее активных» – Stanislav Belyaev ### Баны, власть админов и прозрачность модерации Параллельно развернулся спор о том, как устроена власть в сообществах. Артём занял жёсткую позицию: админ – это садовник в своём саду, и часть решений (например, бан за личные субъективные ощущения) объяснять сообществу необязательно. Он сослался на тезис Юдковского о том, что админ обязан применять правила сразу и мгновенно, иначе сообщество разваливается. Василий возразил: если причина бана непрозрачна, то когда начнётся самодурство – никто об этом не узнает. Карательная история должна быть понятной. Станислав занял третью позицию – фасилитатора, который не устанавливает правила сам: нормы принимает и поддерживает само сообщество. Он провёл аналогию с неписаными нормами: все знают, что плевать в человека нельзя, хотя это нигде не записано. Как контрпример показали правила соседнего бэкенд-чата – длинный список запретов (политика, критика IT-компаний, флейм, флуд) и публичный «список позора» с предупреждениями. Артём заметил, что вывешивать такой список на всеобщее обозрение – сомнительная практика. Здесь же сообщество недавно само «очистилось»: токсичный участник ушёл и удалил свои сообщения после публичного указания на его поведение. Где баланс между «королева всегда права» и прозрачностью, без которой модерация превращается в произвол? > «Админ буквально садовник в своём собственном саду» – Артем Летюшев > «Причина для сообщества должна быть понятна, иначе когда начнётся самодурство – то кто об этом узнает?» – Vassiliy ### Когда действительно пора нанимать нового человека Уалихан поделился наблюдением: формула «нам нужно нанять ещё одного человека, и всё наладится» на его памяти срабатывала редко. Чаще штат резко растёт, появляется неконтролируемая бюрократия и потребность проверять, что все одинаково поняли задачу – а по факту поняли по-разному. Егор предложил рабочий критерий: нанимать стоит, когда сотрудник совмещает несколько ролей, причём роли, в которых у него нет сильных компетенций. Он привёл два примера: когда в штат взяли бухгалтера вместо того, чтобы программист сам считал зарплаты, и когда команде backend-разработчиков, писавших фронт через силу, наконец дали фронтендера – в обоих случаях стало ощутимо эффективнее. Максим вскрыл и менее благородную механику. В корпорации начальником департамента не стать с маленьким отделом: нанимаешь людей, пробиваешь новые проекты, и в какой-то момент один большой отдел делишь на два – и вот ты уже руководитель департамента. То есть иногда «расширение для повышения качества» – это про зарплату руководителя, а не про процессы. Отдельной веткой обсудили, чем мотивировать людей без денег: с деньгами, мол, каждый дурак сможет. Как отличить наём, который реально снимает узкое место, от найма ради строчки в оргструктуре? > «Когда сотрудник совмещает несколько ролей, и роли в которых нет сильных компетенций» – Egor > «Как мотивировать людей без денег? С деньгами каждый дурак может, а вот без денег чем кроме харизмы тащить?» – Уалихан Оразбаев ### AI меняет экономику разработки – или мы просто плодили лишних кодеров? Поводом стал тезис в духе Airbnb: многие процессы (продуктовые ревью, толстые требования, последовательные передачи между ролями) сложились в мире, где разработка была медленной и дорогой. AI меняет экономику и позволяет переизобрести воркфлоу с нуля – быстрее идти от идеи к прототипу, тестировать раньше, сокращать число хендоффов. Азат согласился: экономика индустрии перевернулась, все входные данные поменялись, отрасль предстоит переизобрести. ПМ теперь может сам за полчаса навайбкодить варианты фичи и отдать людям уже готовую спеку. При этом он отделил кодинг (стал дешёвым) от разработки софта в целом (всё ещё дорогой). Андрей возразил резко: большинство процессов строилось не вокруг дорогого кода, а вокруг дорогого процесса обучения бизнеса. Медленное написание кода было плюсом – оно давало время подумать головой. А разделение на «кодеров» и остальных, по его мнению, активно устраняли ещё в 90-х как бредовое, и нынешний всплеск – следствие того, что в ковид компании наплодили лишних кодеров. Азат при этом ждёт парадокс Джевонса: с падением цены одного приложения спрос на специалистов может даже вырасти. Если кодинг подешевел, а обучение бизнеса осталось дорогим – где теперь настоящее узкое место в создании продукта? > «Вся экономика индустрии перевернулась, и все входные поменялись. Нужно переизобретать индустрию» – Azat Jalilov > «То что код медленно писал это было хорошо в том числе давало возможность подумать головой» – Andrii Kurdiumov Ссылка: brandur.org – Minimum Viable Unit – https://brandur.org/minimum-viable-unit Ссылка: NBER – рабочий доклад об экономике AI (w35275) – https://www.nber.org/system/files/working_papers/w35275/w35275.pdf ### Как привить джуну ответственность и стоит ли учить тимлидству Василий спросил прямо: можно ли вообще научить навыку тимлида – и стоит ли. Артур ответил скептически: специально не научишь. Джуну нужно один раз с трясущимися руками осознать, что из-за него что-то сломалось, и получить задачу самому чинить и разбираться. Пока тимлид бегает и «подтирает», ответственность не вырастает. Нурлан добавил конкретную практику из своего опыта: его ментор требовал, чтобы перед любым изменением он письменно описывал, как будет вносить правку и – самое главное – как откатывать. Простое требование, которое заставляет думать о последствиях до того, как что-то сломается. Между этими двумя подходами нет противоречия: один про право на ошибку и её осознание, другой про дисциплину подготовки. Вопрос в дозировке – сколько свободы упасть давать и где подстелить процесс. Где граница между «дать обжечься» и безответственным отношением к продакшену, за который в итоге платит вся команда? > «Надо просто чтобы Джун в первый раз с трясущимися руками осознал что из-за него что-то сломалось» – Arthur > «Мой ментор требовал, чтобы я писал как я буду вносить изменения и самое главное как откатывать» – Nurlan N ### Сколько оперативки нужно разработчику и почему это стало больно Бытовой вопрос Василия – «у кого сколько оперативки, мак помирает» – неожиданно собрал срез по парку машин и ценам. Картина такая: 16 ГБ уже не тянут современный стек (Teams съедает 20+ ГБ, IDE столько же, браузер приходится постоянно подчищать), комфортный минимум сместился к 24–32 ГБ, а у активных – 36–64 ГБ. Болезненная часть – цена. Мак на 32 ГБ оценили почти в 2 000 000 тенге, и участники заметили, что память дорожает: «16 это вариант для бедных», на что последовал лаконичный диагноз – «Инфляция». Обсудили и способы сэкономить: покупка в Дубае (по итогу ненамного дешевле, чем у баеров), наличный расчёт через kansha.kz чуть дороже официалки, или просто дотерпеть до следующего поколения чипов. Прозвучала и трезвая мысль: ноутбук – рабочий инструмент, и экономить на нём странно. Но когда денег, по ощущению участников, становится меньше, а оперативка дороже, выбор «потерпеть или вложиться» перестаёт быть очевидным. 16 ГБ в 2026-м – это всё ещё рабочая конфигурация для разработки или уже самообман? > «16 это вариант для бедных» / «Инфляция» – Andrii Kurdiumov и Stanislav Belyaev > «Это ж рабочий инструмент, как на нём экономить» – Maxim Gorbatyuk ### Как сделать дизайн, который не выглядит сгенерированным ИИ Егор сформулировал боль, знакомую многим после волны ИИ-генерации: сайты выглядят «как один». Как сделать дизайн, который не считывается как ИИшный? Станислав предложил объяснение и рецепт. ИИшный вид возникает не из самой генерации, а из библиотек, которые модель тащит по умолчанию. Лекарство – давать на вход конкретику: примеры и описания, а ещё лучше – референс сайта, который хочется повторить, чтобы модель отталкивалась от него, а не от своих усреднённых паттернов. Андрей предложил доработать пайплайн: сначала сделать скриншот, отрисовать желаемое в генераторе изображений (упомянули nano banana), и только потом отдать результат модели как образец. То есть визуальный референс задаётся явно, а не вытягивается из текстового промпта. Получается, «неИИшность» – это не магия, а дисциплина входных данных. Но не упрёмся ли мы в новый потолок, когда все начнут копировать одни и те же удачные референсы? > «Дизайн выглядит ИИшным из-за библиотек, которые используются» – Stanislav Belyaev > «Я бы сделал скриншот, сгенерил в нано банане что хочу, а уже потом бы дал на вход модели» – Андрей Звёздочка Теги: фриланс, налоги, сообщество, модерация, найм, AI, железо, дизайн ## Документация как код, не работайте с мудаками и сколько стоит сеньор URL: https://teamleads.kz/insights/week-2026-06-09/ Дата: 2026-06-15 Docs-as-code против Confluence, симуляция против эксперимента, подушка безопасности, выход на международку и Fable 5 ### Документация как код против Confluence – кому она вообще нужна? Самый горячий спор недели. Артём и Максим отстаивали подход «документация как код» – маркдаун в /docs плюс AGENTS.md, чтобы агент сам проводил онбординг и быстро находил связи между сервисами при дебаге прода. Артур и Василий возражали жёстко: VS Code не предназначен для чтения текста, Confluence удобнее, а главное – никто не верифицирует актуальность доки, и устаревшая только запутывает Claude. Василий сформулировал ключевой контраргумент коротко: коду он верит, а документации – нет, и при баге полезет сразу в код. Максим парировал, что доку ревьюят в диффе вместе с фичей, а описывают только межсервисные взаимодействия, а не дублируют то, что и так есть в коде. Истина, похоже, посередине. Документация как код полезна для межсервисных связей и работы агентов – но требует дисциплины ревью, иначе превращается в ИИ-генерированный слоп. Не формат решает, а готовность поддерживать его в актуальном состоянии. > «я коду верю, а документации - нет» – Василий > «зачем читать доку, если можно агента спрашивать, а он уже проведет ондбординг» – Максим Ссылка: Slothy Terminal – просмотр доков на светлом фоне – https://mgorbatyuk.dev/slothy-terminal/ ### Симуляция против эксперимента – нужны ли городу автобусные карманы? Обсуждение волонтёрского OSS-проекта вылилось в идею смоделировать, насколько ухудшится движение, если водители не выпускают автобусы из карманов – чтобы «на цифрах» доказывать чиновникам неэффективность решения. Андрей и Андрий отстаивали синтетическую симуляцию: дёшево, не нагружает людей, охватывает все случаи, это стандартная инженерная практика градопланирования. Артур как практик настаивал на сборе реальных данных и A/B-тесте – симуляция всегда упускает факторы реальности. Спор перешёл на личности, Артуру советовали поставить City Skylines. А Василий закрыл тему обезоруживающе просто: в Алматы карманы уже убрали, и это поняли, выйдя на улицу, без всяких симуляций. Здесь столкнулись два правомерных взгляда: модель дешева и безопасна, но эксперимент ловит то, чего модель не предусмотрела. Что важнее – широта охвата на цифрах или достоверность частного случая? > «симуляция дешева, она не нагружает людей и общество. ты просто денежки спалил в худшем случае. а ты предлагаешь на людях эксперименты ставить ради любопытства» – Андрий > «В реальности 10к факторов, в симуляции ты учтешь 100факторов» – Артур > «столько спорили, а нужно просто на улицу выйти и глаза открыть. типичные разрабы» – Василий ### Не работайте с мудаками – но сначала накопите подушку Станислав поделился разбором книги Боба Саттона: рядом с токсичными людьми меняешься сам, а реальных выходов всего четыре – сменить менеджера, дождаться его смены, стать менеджером самому или уйти. Главный тезис прозвучал жёстко: позицию «делать работу так, как считаешь правильным» обеспечивают деньги на счету, а не смелость на словах, поэтому нужна подушка на 3–6 месяцев, а сейчас лучше на год. Развернулся спор о стратегии. Максим предлагал не увольняться сразу, а делать минимум и ходить по собесам. Василий возражал: для лида, который эмоционально вовлечён и видит, как страдает команда, «работать на минималку» и наблюдать за развалом – вещи несовместимые. Павел добавил, что «мудак» – понятие относительное, а Артур заметил, что с каждой ступенью иерархии хейта к людям становится меньше, потому что начинаешь понимать их мотивы. Финансовая независимость, выходит, – это не про богатство, а про право на профессиональную позицию. Сложно отстаивать стандарты, когда выживание зависит от того, кого ты не уважаешь. > «Эксперт, которого вы наняли, имеет право делать работу так, как он её видит. Но стоять на этом позволяют деньги на счету, а не смелость на словах.» – Станислав > «видеть как ребята страглят и работать на минималку - две противоречивые вещи» – Василий > «Всегда Мудак тот кто выше по "Иеархии" в ковычках. Это везде проявляется)» – Артур Ссылка: Боб Саттон – «Работа без вредителей» – https://www.mann-ivanov-ferber.ru/catalog/product/rabota_bez_vreditelej/ ### Колеса и open source – гордятся брендом, но что отдают сообществу? Уалихан бросил вызов Колесам: за годы громкого ИТ-бренда не видно ни инновационности, ни формирования продвинутого класса спецов. Представитель компании Лана ответила конкретикой – стажировки с 2015 года, сотни выпускников образовательных программ, десятки митапов, репозитории на GitHub. Нурлан расширил критику на квазигоскомпании, живущие на субсидиях, а Артур и Максим развернули сабтред о том, что Каспи, Колеса и Магнум фактически единый холдинг, изолированный от рынка. Уалихан и Андрей предложили запустить полноценную OSS-программу, отметив, что в Казахстане в целом страдает культура опенсорса. Запрос сообщества прозвучал ясно: не разовые митапы, а системная поддержка местных стартапов и открытого кода. Когда называешься ИТ-флагманом – к тебе и спрос соответствующий. > «коль груздем назвался, то и лезь в кузов» – Уалихан > «ну в 2015 этого еще никто не делал)» – Лана > «Будет нормальный рынок, без гос субсидий, они исчезнут» – Нурлан Ссылка: GitHub команды Kolesa – https://github.com/kolesa-team ### Можно ли восстановить сырые данные из чужих графиков? Спор перерос в провокационный эксперимент: Андрей предложил «зареверсить» опубликованное зарплатное исследование Колес до исходной статистики через систему линейных уравнений. Максим возражал методологически – нельзя восстановить сотни строк профилей из агрегированных чартов, ИИ просто выдумает данные, и строить на них новые выводы бессмысленно. Параллельно Артур прогонял те же данные через ИИ и вываливал контринтуитивные находки: пишущие тесты якобы получают на 72% больше, удалёнка даёт растущую с грейдом премию. Денис и Андрей осаживали – показаны корреляции без причинно-следственных связей, контроль может быть лишь косвенным признаком. Разрядила конфликт сама Лана из Колес, принеся сырые CSV исследования. Урок старый, но вечнозелёный: агрегированную статистику нельзя надёжно деагрегировать, а корреляция – не причинность. И, как метко заметил Уалихан, люди ищут в цифрах подтверждение своих гипотез, а не опровержение. > «как можно о чем-то думать и какие-то дополнительные графики строить, если реверснутые строки на основе чартов выдуманы ИИшкой?» – Максим > «Кажется влияет не это, а контроль - только косвенный показатель. Нет прямой причинно-следственной связи» – Денис > «Люди ищут в цифрах подтверждение своих гипотез нежели обратное» – Уалихан Ссылка: Исследование разработчиков Kolesa 2022 – https://zerttey.kolesa.group/developers-2022 Ссылка: Зарплаты на techinterview.space – https://techinterview.space/salaries ### Как пробиться на международку и сколько реально стоит сеньор? Адиль удивился, откуда у разработчиков зарплаты в 2–3 млн тенге, ведь на местных собесах он не видел сеньора дороже 1,5 млн. Ответ оказался прост: это удалёнка на Запад или Россию, а «синьоры на нашем рынке – это мидлы на международном». Дальше разгорелся принципиальный спор. Василий считал, что грейд определяется скиллом прохождения собесов и готовностью компании платить. Андрей настаивал, что скилл и стоимость не связаны вовсе – «продать себя можно и за 3к, и за 10к», а умение работать и умение проходить интервью вообще не коррелируют между собой. По практике советовали личные контакты, прогрев CTO лайками и комментариями в LinkedIn и брать количеством откликов. Станислав привёл отрезвляющую статистику: 100 откликов – 1 оффер. Стоимость на рынке, выходит, – это переговорная позиция, а не прямое отражение навыка. > «потому что синьоры на нашем рынке это мидлы на международнем» – Василий > «скиллы работы и скиллы прохода собесов - разные скиллы. И они никак не коррелируют между собой» – Андрей > «Статистика - 100 откликов, 1 оффер. 85% будет отказ» – Станислав ### Собес – это фикция: как себя продать и о чём лучше молчать Адиль рассказал, что на собеседовании честно озвучил: на прошлой работе не смог договориться с CEO и CTO. Василий резко предупредил – это серьёзный ред-флаг, который не стоит произносить, лучше назвать нейтральную причину вроде «стартап закрылся». Развернулась дискуссия о природе собеса. Жахонгир заявил, что весь собес – фикция, и первые две недели всё равно смотрят, «мудак ты или нет». Василий и Андрий сошлись: говорить надо то, что хотят услышать, потому что «не договорился» часто читается как «токсичный чудак, которого нельзя пускать в огород». Договорились даже провести учебное мок-интервью – Артур задаёт свои обычные вопросы Василию, Адиль слушает. Честность на собесе и стратегичность – вещи, которые приходится балансировать. Где граница между «не врать» и «не вредить себе»? > «Не стоит об этом говорить. Весь собес это фикция» – Жахонгир > «нужно говорить то что хотят услышать, а не то что ты на самом деле думаешь)» – Василий > «Не договорились часто означает что ты токсичный чудак которого нельзя пускать в огород» – Андрей ### Fable 5: лид разработки против CTO – цена, лимиты и кто на что годится Релиз Claude Fable 5 вызвал волну впечатлений. Василий хвалил: на инфобез-задачах модель планирует на пару ходов глубже Опуса и учитывает кейсы, которые тот упускает. Жоха был разочарован – «один маркетинг», дороже почти в три раза при чуть лучшей результативности, и остался на Опусе. Когда открыли бесплатный доступ к Fable, Василий нашёл точную метафору: Opus – это лид разработки, который собирает команду, а Fable – CTO, который собирает целый отдел и запускает по 20 агентов даже на простое код-ревью. Отсюда и лимиты сгорают мгновенно. С Opus нужно самому шарить в теме, а с Fable можно работать на уровне целей – но и платить соответственно. Доступ к игрушке быстро закрыли, и Андрей отнёсся к восторгам скептически. Заодно жаловались на расход токенов: один промпт к Opus 4.8 съедал почти половину дневного лимита на 20-долларовом плане. Удвоение opex на токены оправдано не всегда – особенно если выручка за моделью не поспевает. > «Опус это лид разработки, а фейбл - это cto» – Василий > «На 1 простой запрос код ревью, он ушел и запустил штук 20 агентов» – Василий > «Они много времени делали Фабл чтобы мифос выпустить и сразу забрали игрушку.» – Андрей Ссылка: Anthropic: анонс Claude Fable 5 / Mythos 5 – https://www.anthropic.com/news/claude-fable-5-mythos-5 Теги: документация, AI, карьера, зарплаты, опенсорс, собеседования, Fable ## Образование против опыта, зелёные потоки и LLM как разведчик URL: https://teamleads.kz/insights/week-2026-06-02/ Дата: 2026-06-08 Нужен ли диплом в эпоху ИИ, async/await против горутин, метрики, которые не сходятся, и этика реверс-инжиниринга чужого API ### Образование против опыта в эпоху ИИ – нужен ли вообще диплом? Большой спор о ценности высшего образования для разработчика, у которого под рукой есть ИИ. Уалихан и Артур держали радикальную линию: знания доступны каждому, важно лишь уметь их обрабатывать, а значит год опыта ценнее четырёх лет учёбы. Андрей и Павел возражали – без образования не построишь широкую картину мира и навык синтеза нового знания. Максим зашёл с прагматичной стороны: лучше получить диплом и понять, что он был не нужен, чем в 40 лет идти навёрстывать упущенное. А Галымжан подкинул ключевой нюанс, который примирил стороны: айтишникам просто повезло, что их «станок» – компьютер – доступен каждому. Микробиологом или патологоанатомом дома не станешь, и дело тут не в самом дипломе, а в доступе к инфраструктуре. Получается, для computer science опыт действительно даёт фору, но не потому, что образование бесполезно, а потому что порог входа в практику аномально низкий. Василий едко подметил закономерность: громче всех против образования выступают те, кто его толком не получал. А вы бы выбрали 4 года опыта или 4 года учёбы? > «Год опыта более полезен чем 4 года образования?)) Да) Именно так)» – Артур > «нам просто повезло, что аппаратура для computer science доступна каждому. представьте какого получать образования микро-биолога, не имея доступа к инфраструктуре» – Галымжан > «топят за то что и без образования норм, те кто образование особо не получал)))» – Василий Ссылка: Анатолий Шалыто о высшем образовании – https://spbvedomosti.ru/people/anatoliy-shalyto/ ### ИИ и студенческая задача – почему без экспертизы LLM не спасает Чтобы проверить тезис «образование не нужно, есть ЛЛМ» на деле, Андрей дал Артуру конкретную студенческую задачу: устранить левую рекурсию из грамматики и доказать эквивалентность. Артур решал её через промпты к модели, но Андрей раз за разом показывал слабые места – проверка лишь на 12 значениях, генерация, неэффективно удаляющая дубликаты, отсутствие контроля качества обратной проверки. Суть не в том, справилась модель или нет. Суть в том, что LLM не подсказывает те самые мелочи, которые и составляют экспертизу – о них надо знать заранее, чтобы попросить. Артур защищался, что глубинный поинт всё равно засчитан, а Дмитрий резюмировал тред как ценную конкретную демонстрацию. Конкретные примеры бьют абстрактные споры. Об ИИ часто рассуждают общими словами – а здесь на одной задачке стало видно, где проходит граница между «сгенерировать» и «сделать правильно». > «это как бы и есть "экспертиза". знание этих мелочей. ЛЛМ тебе не предлагает почему-то это» – Андрей > «Отличный пример того, что в руках человека без опыта и широкого понимания домена LLM не даёт особой пользы 👍» – Дмитрий > «4 промта и не нужно высшее образование)) Скинь еще сложнейшие задачи, мне нравится эта игра)» – Артур ### Зелёные потоки против async/await – холивар, который привёл к прозрению Многочасовой технический спор: эквивалентны ли горутины и виртуальные потоки (Go, JVM) тасках с async/await (.NET)? Василий настаивал, что они решают одну задачу I/O-конкурентности с похожим перформансом. Дмитрий подробно объяснил разницу: JVM паркует виртуальный поток на блокирующем вызове и освобождает ОС-поток без «раскраски» стека ключевыми словами – чего C# добиться так и не смог. Андрей занял мета-позицию: спор «что лучше» непрофессионален без реальных замеров, можно лишь описать механику и на том успокоиться. И тут спор дал неожиданный плод – вместо того чтобы упереться, участники полезли в дизайн-документ команды .NET, а позже Андрей и вовсе вытащил GC из дотнета в программу на голом C++, чтобы разобрать механику руками. Заодно обсудили, почему Go так залетел на рынке. Андрей считал – из-за низкого порога входа, Василий и Жоха возражали, что быстрые деплои в Kubernetes требуют квалификации повыше. Лучший способ понять рантайм-примитив – не спорить о нём, а собрать его самому. > «JVM умеет парковать виртуальный поток на блокирующих вызовах и освобождать ОС-поток. В итоге получаешь ту же эффективность, что async/await в C#, но без ключевых слов и раскрашивания стеков» – Дмитрий > «я в целом считаю что дискуссия что лучше - не профессиональна и не имеет смысл» – Андрей > «Я просто давно хотел выцарапать ГЦ из дотнета и наконец это случилось» – Андрей Ссылка: Green threads – дизайн-документ .NET – https://github.com/dotnet/runtimelab/blob/feature/green-threads/docs/design/features/greenthreads.md Ссылка: Пример встраивания GC в C++ – https://codeberg.org/kant2002/gcsample ### LLM как разведчик, а не вечный жилец в бизнес-процессе Андрей поделился редким взглядом innovation director крупной британской компании: держать LLM постоянным элементом бизнес-процессов рискованно – это и vendor dependency, и делегирование мышления стохастическому компоненту. Альтернатива – использовать модель как временный исследовательский слой: дать людям ИИ-помощников, логировать, что они реально делают и какие правила живут только в головах, а потом перевести извлечённые паттерны в обычный детерминированный код. Главная мысль элегантна: классическая автоматизация всегда буксовала на этапе discovery – люди не могут объяснить, как именно они работают. И вот тут LLM незаменима. Адильбек поддержал осторожность примерами из практики: юридическим задачам и расшифровке аудио для протоколов он модель полностью не доверяет, потому что цена галлюцинации высока. Денис уточнил, что в разных процессах разное соотношение детерминированной и вариативной составляющей. Вопрос, выходит, не «внедрять ИИ или нет», а где он должен остаться в рантайме, а где нужен лишь как разведчик – чтобы понять, что именно стоит автоматизировать обычным кодом. > «Не могу же сказать совету директоров, ну сорян пацики тут нейронка проебалась» – Адильбек > «В разных бизнес процессах разное соотношение детерминированной и вариативной/интеллектуальной составляющей» – Денис ### Метрики как серебряная пуля – и кейс несходящихся цифр Дискуссия о культе метрик в корпорациях. Василий саркастично описал, как метрики стали универсальным инструментом для всего – грейда, решения, цвета кнопки, внедрения ИИ – но «каждый находит в них только то, что ищет». Галымжан привёл реальный кейс интеграции в суперапп: партнёр заявлял 200 тыс. переходов от двухмиллионной аудитории, а на их стороне видели лишь 35 тыс. даже с логами на уровне прокси. Василий разобрал техническую природу расхождений при кросс-платформенных интеграциях: клик по уведомлению – это ещё не открытый webview, а тот – ещё не авторизованный пользователь. Андрей же доказывал, что несходящиеся данные означают невозможность совместного бизнеса – нет доверия цифрам друг друга. Финал кейса показателен: стороны «согласились не соглашаться» и презентовали своему менеджменту разные картины. При клиентских интеграциях расхождение один-в-один почти недостижимо – а ожидания партнёров редко учитывают воронку потерь. > «хочешь грейд апнуть? - собери метрики. хочешь решение принять? - собери метрики. хочешь кнопку покрасить? - собери метрики. хочешь ИИ? - собери метрики» – Василий > «в итоге согласились не соглашаться и каждая сторона презентовала своему менеджменту разные картины. клоунада» – Галымжан ### Этично ли реверсить чужой API – кейс «Яндекс против Onay» Максим рассказал историю: Яндекс.Такси начал показывать автобусы Алматы, отреверсив непубличный API onay. Когда onay менял формат выдачи – автобусы пропадали, пока стороны не договорились. Развернулся этический спор о границах дозволенного. Андрей Звёздочка занял позицию «законов физики»: раз приложение существует, протокол можно реверсить, а мнение владельца API неважно, если ты готов взять на себя риски. Максим резко не согласился – такой подход про «делаю, потому что могу», а не про право. Василий и Азат указали на правовую сторону: можно и в суд подать, если есть что взыскать. А вот и неудобная реальность, которую подсветил Андрей: принудить мелкого к штрафу почти невозможно, и в итоге «малыши идут договариваться к крупнякам, а не наоборот». Где здесь проходит граница между инженерной свободой и этикой – вопрос, на который у чата не нашлось общего ответа. > «Всем плевать на публичность. Приложение есть? Значит зареверсить протоком можно спокойно. А учитывая развитие ЛЛМ - даже не привлекая людей во многом» – Андрей ### Агрегатор вакансий для ИИ-ролей – пет-проект или продукт? Артём анонсировал опенсорс-агрегатор вакансий новых ИИ-ролей (ai product engineer, vibecoder, llm engineer) из телеграм-каналов и сайтов компаний – без войн с HH и LinkedIn. Андрей долго не понимал ценность («чем лучше линкедина?», «где болит?»), пока не дошло, что ниша – необслуженные вайбкодеры. Артур, наоборот, сразу увидел коммерческий потенциал – «Перплексити для вакансий». Но Артём резко отбивался: продукт делать он не хочет, ему интересен опенсорс и польза сообществу. Жахонгир развил это в философскую ноту о ценности безымянного вклада, вспомнив проект умершего разработчика, который живёт дальше с сохранённым авторством как данью уважения. Любопытный контраст ролей: один смотрит на тот же проект глазами предпринимателя, другой – глазами инженера. И не факт, что монетизация – единственная мера ценности сделанного. > «Перестаньте в этом видеть джобборд пожалуйста» – Артём > «Ты полагаю глядишь как предприниматель, а я как инженер, усталый стартапер и комьюнити Биддер» – Артём Ссылка: CodeGraph – навигация по кодовой базе для ИИ-агентов – https://codegraph.ru/ Ссылка: Хабр: про Serena и экономию токенов – https://habr.com/ru/articles/1043774/ Теги: образование, AI, конкурентность, метрики, опенсорс, этика, найм ## Тимлид без власти, ИИ против бизнес-данных и почему Казахстан не ИТ-страна URL: https://teamleads.kz/insights/week-2026-05-25/ Дата: 2026-06-01 Как отвоевать влияние у продакта, можно ли доверить LLM прямой доступ к данным, эйджизм при найме и токеномика корпораций ### Тимлид без власти – как отвоевать влияние у продакта? Дискуссия началась с простого вопроса: какие рычаги влияния вообще есть у тимлида? И быстро вскрыла болевую точку. Уалихан и Василий описывали типичную картину казахстанских контор – тимлид как «галочка», человек, который передаёт информацию сверху вниз, но не распределяет задачи и ничего не решает. Артур возражал жёстко: влияние – это не статус, а ресурс, за который воюют каждый день. Если ты тимлид только на бумаге, виноват в этом ты сам – надо отбирать задачи у продакта или вообще убирать его из команды. Максим зашёл с корпоративной стороны: сказать «нет» тем, кто платит деньги, можно лишь дозированно, и звучать это должно как «нет, но можно иначе». Практический вывод собрался из контраста. Власть тимлиду никто не выдаёт вместе с должностью – её приходится отвоёвывать по сантиметру, начиная с права говорить «нет» на заведомо невозможное. А вы знали, что у вас есть эти права, когда впервые стали лидом? > «Влияние это ресурс, и надо воевать за него каждый день. Тимлид который не принимает решение по работе команды не тимлид» – Артур > «новоприбывшим тимлидам никто не говорит у них есть права)» – Василий > «Люди сверху ждут, что ты скажешь им "нет, мы можем сделать иначе: так-то и так-то"» – Максим ### Можно ли доверить LLM прямой доступ к данным бизнеса? Многодневный спор о том, стоит ли давать LLM прямой доступ к источникам данных, чтобы бизнес сам получал отчёты на естественном языке. Василий держал оборону: бизнесу нужны 100% повторяемые цифры, а модель из 20 запросов корректно отвечает на 15–17 и «не умеет говорить нет» – это убивает доверие. Артём напоминал, что text2sql и автодискавери уже стали базой (Vanna, DB-GPT, MindsDB), а Стас и Артур переводили спор в плоскость архитектуры: LLM должна не считать сама, а писать проверяемый код или скрипт, плюс слой валидации поверх. Андрей Звёздочка добавил отрезвляющую техническую деталь – даже при нулевой температуре токены выбираются стохастично, и выше примерно 10 тыс. токенов начинаются галлюцинации. Получается, ключ не в том, доверять модели или нет, а в том, чтобы разделить детерминированную часть (код, structured output) и вероятностную (рассуждение). Доверие бизнеса рождается из стабильности повторяемого результата – а не из красоты ответа. > «у меня порог доверия к ллм - такой же как и раньше, "он мудак, доверять я ему не буду"» – Василий > «Люди будут просить один и тот же отчет разными словами и будут получать разные цифры. По итогу это породит споры, конфликты и в конце недоверие» – Василий > «У тебя тупо может быть галюн в том что ризонинге появится 100 баксов зп, а в аутпут тебе 200 упадёт» – Андрей Ссылка: Vanna – опенсорс text2sql агент – https://github.com/vanna-ai/vanna Ссылка: DB-GPT – фреймворк для data-агентов – https://github.com/eosphoros-ai/DB-GPT ### Почему Эстония – ИТ-страна, а Казахстан – ресурсная? Спор о том, почему в Казахстане так и не выросла сильная ИТ-отрасль. Glenum и Павел приводили привычные аргументы: маленькое население, слабая правовая система, низкие зарплаты, недоступный дешёвый капитал. Станислав разбирал их один за другим. Эстония с населением 1,3 млн и Швеция с 5 млн – сильные ИТ-страны при куда меньшем рынке, чем у Казахстана с его 20 млн. Капитал государство может занять на Западе под 3–4% и раздать – что, в общем, и делают Каспи с Фридомом. По его версии, настоящая причина в другом: у страны есть ресурсы, и выкачать нефть проще, чем растить человеческий капитал, поэтому нет и спроса на надёжные системы. Андрей сместил акцент на культурный код и социальные барьеры, которые мешают сильнее экономических. Денис добавил взгляд со стороны российского работодателя: казахстанский сеньор в среднем приходит на грейд ниже и тянет на мидла. Вывод спора оказался неудобным – конкурентность кадров рождается через открытие границ и конкуренцию, а не через ещё один хаб. Размер рынка тут скорее удобное оправдание, чем причина. > «пенять на размер рынка – это дать себе скидку и объяснение, что ничего не получится» – Станислав > «Проще выкачать нефть из земли или уголь откопать, чем использовать человеческий капитал» – Станислав > «в среднем люди приходят на грейд ниже, чем по нашим меркам. Т.е. условный синьор тянет на мидла» – Денис ### Молодой и слишком опытный – ходячий ред-флаг? 20-летний разработчик amer с «3+ годами опыта» пожаловался, что не может найти работу даже джуном. Артур честно разложил логику работодателя: большой опыт в юном возрасте читается как накрученный, сам возраст – уже ред-флаг, и многие мягко «отшивают» студентов вопросом про учёбу. Совет звучал контринтуитивно – поделить опыт на три и заявляться джуном, потому что «опытных джунов любят». Дальше развернулась дискуссия о ценности молодых вообще: Артур признал, что они быстро учатся и переизобретают полезное из-за несформированной консервативности, но хуже держат коммитменты, тогда как разработчики 30+ дают надёжность, усидчивость и критическое мышление. Андрей напомнил, что без портфолио заявлениям всё равно не поверят. Парадокс в том, что и недостаток, и избыток «опыта на возраст» отпугивают одинаково. Спасает не цифра в резюме, а демонстрация реальных проектов и стратегия роста внутри компании вместо прыжков между работодателями. > «Возраст = Ред Флаг. Опыт слишком большой для возрасат = Ред Флаг» – Артур > «Ребята которым 30+ вообще в восторге с них, они очень усидчивые, внимательные, сфокусированные» – Артур ### Токеномика корпораций – правда ли разработчики «сожгли» состояние на Claude? Обсуждали новость о тратах крупной корпорации на ИИ-токены и нужно ли ставить лимиты на сотрудника. Василий выдвинул гипотезу, что эффект от ИИ растёт с логарифмической сложностью, поэтому оверлимиты бессмысленны, а лимиты – нормальная валидация: возможен саботаж или человек просто не умеет тратить токены. Егор поделился цифрами своей команды: лимиты выжигают процентов 15 сотрудников, и неожиданно больше всех – не разработчики, а тестировщики. Станислав привёл личную статистику (5 млн токенов за 4 месяца) и сделал отрезвляющий вывод: на масштабе в 80 тыс. человек громкие траты выглядят как преувеличение – разработчики нагенерили меньше, чем стоит их зарплата, да ещё и со скидкой от вендора. Вот что любопытно: пугающая сумма на пресс-релизе и стоимость в пересчёте на инженера – две очень разные истории. Стоит ли вообще считать токены, если их цена ниже зарплаты того, кто их тратит? > «моя гипотеза, что эффект от ИИ идет с логарифмической сложностью поэтому делать оверлимиты - не имеет смысла» – Василий > «по опыту моей команды наверно процентов 15 сотрудников выжигают почти все» – Егор > «кстати по ощущениям не разрабы сжигают больше всего. Тестировщики» – Егор ### Инженер против продакта – конфликт двух миров в одной компании Станислав описал личный конфликт ролей: он живёт в инженерном мире, где критерий успеха – «нас не замечают, ничего не сломалось», а продакты делают customer-facing продукты, где молчание о фиче равно провалу. Он разложил конфликт по осям: горизонт планирования, потребность рассказывать против молчания, психологические профили и отношение к аккуратности данных. Андрей частично согласился, но возразил: многое здесь – не характер, а тренируемые навыки, и соционики в разборе слишком много. Василий добавил продуктивный угол: к внутренним командам относятся потребительски, как к чистому расходу, а к внешним требуют обоснования. Если же относиться к внутренним сервисам как к продукту (SaaS/PaaS), конфликт сглаживается. В сухом остатке – это не столкновение характеров, а столкновение профилей риска. Фронтмену нужна ширина и надёжные элементы, инфраструктуре – защита от каскадных сбоев. Взаимное непонимание неизбежно даже при взаимном уважении. > «Критерий успеха – нас не замечают, ничего не сломалось. В работе с продуктами же все иначе. Если ты сделал фичу и о ней никому не рассказал – значит ты сделал плохо» – Станислав > «Для внутренних, это чистый расход и никто не считает, отношение к внутренним ресурсам идет потребительское» – Василий Ссылка: Менеджер продукта в продуктовой vs инженерной команде – https://belyaev.live/posts/engineering-vs-product-pm/ ### Инновации, которые никому не нужны – проблема не в деньгах, а в спросе Василий принёс аналитику: главная причина, по которой казахстанские предприятия не внедряют инновации, – не нехватка денег или кадров, а отсутствие спроса. Компаний, жалующихся на отсутствие потребности, оказалось почти вдвое больше, чем тех, кому не хватает финансов. Станислав перевёл это в управленческую плоскость: спроса на инновации нет у менеджмента, потому что инновации – игра в долгую с отдачей через 2–10 лет, а местный менеджмент хочет возврат инвестиций через три месяца. Уалихан возразил, что инновации в стране всё-таки есть, но Нурлан и Стас уточнили: это трансферт технологий с лагом в 3–5 лет за Западом, а не собственные разработки. Пока рынок позволяет зарабатывать на старой продукции без давления конкуренции, инновации остаются строчкой в отчётности, а не инструментом выживания. Знакомая ситуация? > «Инновации - это игра в долгую. Ты должен инвестировать сегодня, чтобы получить выгоду через 2-10 лет. А менеджмент в Казахстане хочет возврат инвестиций через 3 месяца» – Станислав > «Это не инновация, это трансферт технологий:)» – Нурлан ### ИИ против сырых логов – новый инструмент анализа или игрушка? Артур предложил подключать ELK и Sentry по MCP, чтобы с утра спрашивать Claude «что там с продом» и получать инсайды за пару минут вместо получаса ручного разбора. Василий упирался: логи должны быть человекочитаемыми, у него есть дашборды, а гонять сырьё через LLM медленно и нестабильно. Артур уточнил, что модель не жуёт сырые данные в лоб, а под капотом включает фильтры ELK и анализирует аномалии. Михаил поделился негативным опытом – Gemini уверенно нашёл «ошибки, которых не было», на что прозвучало сухое «не тот инструмент использовал». Стас же повторял короткое «ты попробуй». Развязка наступила на следующий день: Василий признал, что подключение к источникам напрямую реально удобнее для генерации скриптов, и поблагодарил, отметив, что у него был внутренний страх перед прямым подключением LLM к данным. Иногда главный барьер для нового инструмента – не его недостатки, а наша осторожность. > «всерьез логи анализировать через ллм сомнительно, логи должны быть человеко читаемые и понятные» – Василий > «стало удобнее скрипты генерить если к источнику подключить, а не передавать контекст) видимо был внутренний страх, подключать ллм к источникам напрямую, спасибо)» – Василий Теги: лидерство, AI, найм, экономика, токены, инновации, продакт ## Метрики, R&D, прибыль и управление ритуалами URL: https://teamleads.kz/insights/week-2026-05-19/ Дата: 2026-05-24 Визуализация метрик, роль IT в прибыли, границы R&D, локальный PaaS и мультиагентные системы ### Метрики врут – или вы неправильно смотрите? Стас из Microsoft показал сообществу три графика стабильности билдов – одни и те же данные, но сгруппированные по неделям, месяцам и кварталам. Результат оказался неожиданным: на еженедельном графике участники видели хаос и шум, на квартальном – явный тренд к улучшению. При этом данные были абсолютно одинаковыми. Дискуссия быстро разделила участников. Артур настаивал на декомпозиции по командам и людям – «найти тех, кто генерирует 80% фейлов». Денис, напротив, критиковал саму визуализацию: «столбцы несопоставимы, легенда однородна, чтобы разобраться – нужна бутылка». Андрей заметил, что управленец должен принимать решения даже при неполной информации. Интересно, что за масштабами (2 000 тестов, 300 разработчиков, 1 000–1 500 билд-машин, 60–70 релизов в сутки) скрывается более глубокий вопрос: не что метрики показывают, а как мы их интерпретируем. Когда каждый тест в отдельности имеет 99% надёжности, а система из 10 000 тестов – всего 36%, одна только перспектива определяет, видите вы проблему или прогресс. > «График – гавно. Чтобы разобраться, нужна бутылка» – Денис, о качестве визуализации метрик > «Для метрик важна перспектива. На квартальном графике явно видны улучшения, на еженедельном – шум» – Стас ### IT – кост-центр или двигатель прибыли? Артур категорично заявил: «Прибыль генерят не инженеры. Прибыль генерят продажники и маркетологи». Утверждение вызвало бурную реакцию. Андрей назвал это «копиумом продажников», Уалихан привёл контрпример из аутстаффа, где разработчик – буквально продукт для лизинга. Стас спросил: а как тогда понять, сколько денег приносит конкретная фича в продукте уровня MS Teams? Спор выявил фундаментальное различие в мышлении. Артур мыслил в категориях бухгалтерского баланса – расходы и доходы. Андрей и Стас – в категориях цепочки создания ценности (value chain), где каждое звено участвует в создании прибыли. Уалихан точно подметил: «Хер с ним, никто кроме продажников не приносит прибыль. Но разве это делает их самым значимым фактором?» Казалось бы, академический спор. Но от ответа на этот вопрос зависит, как компания бюджетирует IT, как оценивает инженеров и какие решения принимает о найме. Если IT – это «просто расход», зачем инвестировать в качество кода? > «Даже если вы шахту золотую нашли и начали её разрабатывать, это расходная часть, пока ресурсы с шахты не будут продавать» – Артур > «В борделе прибыль генерирует не проститутка, а сутенер? Спорно» – Уалихан ### Где начинается R&D и заканчивается «просто работа»? Василий предложил шкалу от 0 (путешествие во времени) до 10 (колесо) и спросил: с какого уровня деятельность можно считать исследованием? Андрей провёл жёсткую границу: настоящий R – это работа за мировым фронтиром, а покупка и пуско-наладка готовой технологии – это D, development, и не надо путать. Дискуссия обнажила проблему казахстанского IT-рынка. Андрей утверждал, что за 10 лет инноваций исследований почти нет. Василий возражал: Kaspi – уникальный продукт, а ЦАРКА делает настоящую исследовательскую работу в ИБ. Уалихан привёл собственный пример – два года исследований перед созданием облачной платформы, что составило «больше 10% всей жизни». Практический вывод для тимлидов: называя рутинную интеграцию исследованием, мы девальвируем понятие и теряем способность отличать настоящее R от D. Но и обесценивать локальные достижения – значит отбивать желание двигаться дальше. Баланс между честностью и поддержкой – вечная дилемма лидера. > «Я не верю, что называя исследованием покупку и пуско-наладку технологии с рынка, чего-то можно добиться» – Андрей > «Я потратил на исследования перед созданием облака больше 10% всей своей жизни» – Уалихан ### Навыки в эпоху AI – что учить, когда AI уже на уровне PhD? Неделя началась с поста Стаса о трёх навыках, которые остаются важными: декомпозиция сложных задач для AI, культура коммуникации с AI (исключение двусмысленности) и способность понимать сложные системы для их проверки. При этом «уметь учиться» важнее конкретных знаний – AI может быстро объяснить технологии. Андрей скептически отнёсся к идее манифестов: «Все манифесты разобрали маркетологи, никто не услышит манифест в текущем гаме». Параллельно Стас из Microsoft признал, что GitHub Copilot – «говно» по сравнению с Claude Code, и разработчики внутри компании используют Claude по максимуму, пока это возможно. К концу недели Артём поднял вопрос о границе между вайбкодером и инженером. Дмитрий Мельник чётко обозначил разрыв: «Если начнут дубли в БД появляться на проде, ты что будешь делать? К агенту пойдёшь?» Вайбкодинг учит делать, но не учит понимать – а понимание остаётся ключевым навыком инженера. > «GitHub Copilot – говно. Пока доступен Claude Code – его используют по максимуму» – Стас, об инструментах внутри Microsoft Ссылка: AI Project Rhythm: 300 Hours – https://mysummit.school/blog/ai-project-rhythm-300-hours/ ### Первый опенсорс-контрибьют и сила сообщества Дмитрий, начинающий разработчик, спросил совет о пет-проекте для портфолио. Вместо абстрактных идей сообщество направило его к реальному вкладу: Андрей предложил исправить баг в репозитории сообщества. Через несколько часов Дмитрий отправил свой первый PR – выравнивание кнопки на странице. «Стыдно признаться, что это мой первый вклад в опенсорс» – написал Дмитрий. Андрей ответил: «Было ли бы тебе стыдно, что ты первый пошёл в приют для животных? Что важнее – что ты не делал когда-то, или то, что ты сделал сейчас?» И тут же – нетипичный для опенсорса подход: PR смерджили без ревью, доверяя автору. «Это не критичный сайт, покажем тебе другой стиль работы». Стас при этом рекомендовал строить карту контрибуций по разным репозиториям вместо мёртвого пет-проекта: обширный след в опенсорсе выглядит для работодателя сильнее, чем заброшенный todo-лист. > «Стыдно признаться, что это мой первый вклад в опенсорс» – Дмитрий > «Было ли бы тебе стыдно за то, что ты первый пошёл в приют для животных?» – Андрей ### IT-сообщества в Казахстане – есть ли спрос? Артём анонсировал новое AI-инженерное сообщество. Стас поставил под вопрос саму идею: в 2019 году он вырастил чат с 600 до 1 800 человек, проводил митапы, гостевые лекции в университетах – но сильных проектов это не породило, «потому что они не нужны рынку». Дмитрий Мельник возразил: проблема не в рынке, а в формате. Он видит результаты от системного обучения (курсы с методикой и обратной связью), тогда как свободное общение в чатах – слишком слабый формат. «Все сообщества мертвые. Но когда конкретно обучаешь конкретных людей, видишь классные результаты». Андрей нащупал неожиданный компромисс: в Казахстане есть спрос на технические навыки (Артём, Дмитрий), но нет спроса на менеджмент (Стас) и сложные инженерные работы (Андрей). А слабый менеджмент – корневая причина: «Слабый менеджер не в состоянии даже не очень сложные технические решения продвигать». > «Все сообщества мертвые. Но когда конкретно обучаешь конкретных людей – видишь классные результаты. И это один и тот же рынок» – Дмитрий Мельник Ссылка: Habr: статья Артёма о AI-инженерии – https://habr.com/ru/articles/1038204/ Ссылка: Drim Dev: курс AI Superpower for Developers – https://drim.dev/courses/ai-superpower-for-developers ### Сотрудник не соблюдает ритуал – что делать, если уволить нельзя? Василий поставил классическую управленческую задачу: сотрудник систематически не выполняет важный ритуал. 1-1 не помог. Автоматизировать нельзя. Уволить тоже. Что делать? Ответы разделились на два лагеря – силовой и системный. Артур предложил «социальный конструктор» – публичное давление через дейлики, просьбы к коллегам спрашивать о ритуале, манипулятивные приёмы убеждения. «Много вариантов, могу ещё накидать. Они не все этичные, но работают». Андрей возразил: социальное давление не поможет, если человек просто забывает в нужный момент. Его альтернатива – делегировать процесс более ответственному участнику. Ян предложил структурированный подход: поднять вопрос на ретро, показать два кейса – когда ритуал соблюдался и когда нет, назначить ответственного. Азат добавил идею с шоколадками за нарушение. В итоге выяснилось, что Василий говорил о конкретном случае – записи созвонов сообщества. Ирония в том, что управленческие инструменты применимы даже к добровольным сообществам. > «Много вариантов, могу ещё накидать. Они не все этичные, но работают» – Артур > «Кто пашет, на том и едут?» – Андрей, о распределении ответственности в сообществе ### Локальный PaaS для Казахстана – нужен ли рынку? Уалихан представил сообществу свой проект – облачную платформу нового типа для казахстанского рынка. Проблема, которую он решает: в Казахстане нет локальных PaaS-решений, и стартапы строят инфраструктуру поверх нестабильных VPS. Preview environments, мультистенды, защита от DDoS – всё это требует отдельного отдела инфраструктуры, который стартапу не по карману. Андрей задал жёсткие вопросы: «Понижая цену, ты уходишь в нищебродский сегмент – это самые муторные клиенты». И главное – «ты так и не сказал: что это и зачем оно нужно». Уалихан выделил три преимущества: цены ниже (не нужно отбивать инвестиции в полмиллиона долларов), настоящий pay-as-you-go биллинг и стабильность инфраструктуры. Дискуссия обнажила типичную ловушку технических фаундеров: увлечённость решением мешает объяснить проблему. Андрей дважды просил «просто скажи, что это делает», прежде чем получил ответ. Для тимлидов – полезное напоминание: если не можешь объяснить продукт за 30 секунд, может, ты ещё не понял свою аудиторию? > «Понижая цену, ты уходишь в нищебродский сегмент. Это обычно самые муторные клиенты» – Андрей > «В простом да – много самонадеянности» – Уалихан, о своём подходе к unit-экономике Ссылка: Bult.ai – облачная платформа Уалихана – https://bult.ai/ ### BeeTech и формат IT-конференций в Казахстане BeeTech стала поводом обсудить формат IT-мероприятий в целом. Жибек, удалённый разработчик, поделилась впечатлениями: «Приятное времяпрепровождение для удалённого затворника. Больше для нетворкинга». Она отметила, что Алексей Утепов 6 месяцев осваивал то, чему Дмитрий Мельник учит за 2 – разработку агентов. Параллельно Василий предложил неожиданный тезис: Astana Expo – отличная площадка для IT-сообществ. Множество организаций в пешей доступности, возможность организовать митапы прямо в рабочее время. Максим скептически спросил: «А делают ли?» В Алматы такого места нет – кроме района Нурлы Тау с банками. Созвон сообщества в тот же день прервался из-за сбоя Telegram. Стас предложил перейти на Google Meet, Discord или Zoom. Андрей запустил голосование. Практический итог: зависимость от одной платформы – риск не только для продукта, но и для сообщества. > «Приятное времяпрепровождение для удалённого затворника» – Жибек, о BeeTech > «В Астане Экспо – крутая штука для айтишников. Сильное отличие от того, что в Алмате» – Василий Ссылка: Материалы BTExpo (презентации и фото) – https://drive.google.com/drive/folders/1ibQmXTz30QkW57fFi0a_h5rs6xftHAkn?usp=sharing ### Мультиагентные системы и границы вайбкодинга Борис описал архитектурный подход к AI: вместо одного большого промпта – несколько агентов с разными ролями, меньшим контекстом и специализированными системными промптами. На практике он реализовал это для платформы Archivision – системы архитектурного проектирования, где один агент с ограниченным контекстом не справляется. Идея вызвала скепсис у Артёма: «Бесконечно сложно и ни разу не мидл». Но Борис возразил: «AI очень хорошо помогает. Как пет-проект – можно сделать за недельку-две. Сложнее промпты оттюнить на основе статистики, чем механику разработать с AI». Это подтвердило тезис Жибек с BeeTech – экспериментирование с агентами доступно, но от прототипа до продакшена – дистанция. Дмитрий Мельник чётко обозначил разрыв между вайбкодером и инженером: «Если начнут дубли в БД появляться на проде, ты что будешь делать? К агенту пойдёшь?» Вайбкодинг учит создавать, но не учит понимать – а без понимания мультиагентная система превращается в мультиагентную проблему. > «Сложнее промпты оттюнить на основе статистики, чем механику разработать с AI» – Борис > «Если начнут дубли в БД появляться на проде, ты что будешь делать? К агенту пойдёшь?» – Дмитрий Мельник Ссылка: Archivision – платформа архитектурного проектирования – https://www.archivision.org/ Теги: метрики, R&D, менеджмент, опенсорс, AI, PaaS, конференции, мультиагенты ## Зарплаты, Full Stack и микросервисы vs монолит URL: https://teamleads.kz/insights/week-2026-05-12/ Дата: 2026-05-17 Справедливы ли зарплаты в IT, Full Full Stack как новый стандарт, GitHub тонет, Bun на Rust за 10 дней ### «Несправедливые» зарплаты в IT – кто прав? Forbes Kazakhstan опубликовал статью о стартапе pandev.io, где инвестор заявил о «неоправданно высоких зарплатах в IT». Максим бросил вызов Артуру – основателю стартапа: а какая зарплата, собственно, справедливая? Азат ответил просто: «Справедливая цена – это когда продавец готов продать, а покупатель купить». Уалихан обозначил парадокс казахстанского рынка: зарплаты по мировым меркам низкие, но по местным – завышенные, потому что кандидаты ориентируются на внешний рынок и «успешных чебуреков». Азат возразил: если программист может устроиться на удалёнку за двойную зарплату, зачем ему местные вакансии? Местные компании конкурируют с удалёнкой и релокейтом – отсюда и рост зарплат. Артур подтвердил, что статья не была проплачена – Forbes сам пригласил на интервью. Уалихан поделился собственным опытом: когда о нём писали, он хотел донести, что «в IT не всё просто и придётся жертвовать», но статья вышла в духе «IT – радужный мир, где найдётся место каждому». > «Справедливая цена – это когда продавец готов продать, а покупатель купить» – Азат > «Зп в казахстанском IT по сравнению с мировым – низкая, но относительно местного рынка – переоценена» – Уалихан Ссылка: Forbes KZ: Сколько на самом деле стоит программист – https://forbes.kz/articles/skolko-na-samom-dele-stoit-programmist-kazahstanskiy-startap-nashel-otvet-7925d2 ### Full Full Stack – новый стандарт или утопия? Артур категорично заявил: «Если ты не x10 Full Full Stack, тебе не место на рынке скоро. DevOps + Front + Back станет стандартным стеком». Дмитрий Мельник поддержал – его опрос показал, что большинство разработчиков согласны с необходимостью расширять стек. Андрей предложил альтернативу: пилить свои продукты, пока рынок незаполнен. Василий вернул дискуссию на землю: «Чтобы стать фулстекером нормальным – нужно довольно много времени. Помню, раньше была специальность вебмастер, но из-за объёма обучения пришлось выбирать». Андрей добавил: предприимчивый программист, умеющий продавать, и раньше мог сделать бизнес – AI не так сильно усилило нетехнические направления. Нурлан заметил, что domain knowledge и понимание бизнеса важнее стека технологий. Дмитрий Мельник описал свой подход: консалтинг по внедрению «автономной разработки», платформа Drim Arena для практики, и фокус на обучении инженеров нового типа – универсальных специалистов, которые понимают весь цикл. > «Если ты не x10 Full Full Stack, тебе не место на рынке скоро будет» – Артур > «Чтобы стать фулстекером нормальным – нужно довольно много времени» – Василий ### Bun: переписать с Zig на Rust за 10 дней с помощью AI Стас поделился новостью: JavaScript-рантайм Bun, купленный Anthropic, переписали с Zig на Rust за десять дней при помощи Claude. Первый коммит попал на Hacker News, разработчик назвал ветку экспериментальной – но через пару дней Rust-версия проходила 99,8% тестов, и на свалку отправилась оригинальная версия. Андрей отнёсся скептически к PR-составляющей и провёл собственный анализ кода. Жахонгир согласился с выбором Rust, но был «против полной растомании». Андрей указал на управленческий риск: «Они изначально зачем брали Zig и чем думали? Это скорее политика в компании – все языки с безопасной работой с памятью плюс хороший PR-ход». Стас вернул к практике: «Это возвращаясь к дискуссии, где я утверждал, что даже при вайбкодинге нужны эксперты в доменах – нужно знать, что просить у AI». Дмитрий, начинающий разработчик, признал: «Прям зарядил, потому что сижу копаю основу JS и постоянно мысли – нафига, надо вайбкодить. Такие примеры помогают оставаться на выбранном пути». > «Порочные практики заставишь меня проверить этот ужасный PR локально» – Андрей, о необходимости проверять даже хайповые переписывания > «Даже при вайбкодинге нужны эксперты в доменах – нужно знать, что просить у AI» – Стас Ссылка: Bun PR: Zig → Rust rewrite – https://github.com/oven-sh/bun/pull/30412 Ссылка: Анализ PR от Андрея – https://kant2002.github.io/en/llm/2026/05/16/bun-pr-analysis-en.html Ссылка: Hacker News: обсуждение – https://news.ycombinator.com/item?id=48019226 ### GitHub тонет – куда мигрировать? Азат поделился статьёй «GitHub is Sinking» и предупредил: «Это первая ласточка. Скоро слоп-чума придёт во все сервисы». Платформа, разработанная для людей, не выдерживает потоков сгенерированного кода на десятки тысяч строк с обязательным CI/CD. Андрей отнёсся к этому позитивно: «Замечательно, так быстрее децентрализация произойдёт». Адиль спросил: «Кто-нибудь с GitHub уходит?» Андрей предложил Forgejo – self-hosted альтернативу. GitLab он отверг: «Тот же риск в управлении». Уалихан подтвердил: «GitLab – одна из самых прикольных контор, столько хуйни сделать – надо умудриться». Василий вспомнил, как в банке однажды GitLab чуть не закрыл on-premise версию. Дискуссия переросла в ностальгию: SourceForge, TortoiseSVN, FTP-деплойменты. Андрей подвёл итог: «Статус текущих OSS-решений хреновый, но приемлемый. За следующие 5 лет все интеграции намоют, и можно будет не привязываться к компаниям так сильно». > «GitHub – первая ласточка. Скоро слоп-чума придёт во все сервисы» – Азат > «GitLab – одна из самых прикольных контор, столько хуйни сделать – надо умудриться» – Уалихан Ссылка: GitHub is Sinking – https://dbushell.com/2026/04/29/github-is-sinking/ Ссылка: Forgejo – self-hosted Git – https://forgejo.org/ Ссылка: Fossil SCM – альтернатива Git – https://fossil-scm.org/home/doc/trunk/www/index.wiki ### Микросервисы vs монолит – вечный спор с казахстанской спецификой Стас кинул ссылку на доклад Авито: «Краткий вывод – микросервисы дороже монолита». Уалихан моментально откликнулся: «Микросервисы – кабздец как много геморра создают» – и перечислил четыре проблемы: проектирование, связи между сервисами, отказоустойчивость и поднятие инфраструктуры. Азат возразил: «Сложность никуда не девается, она просто на разных уровнях». Андрей поставил ключевой вопрос: «В Казахстане – 18 миллионов людей. Это не хайлоад. Зачем сложные трюки?» Жахонгир привёл контрпример из международных криптокошельков, где нагрузка измеряется другими цифрами. Уалихан метко подметил: «Хайлоадом может быть и тудулист в руках пьяного наркомана под героином». Василий задал практический вопрос: «Если страховку создали, а платёжку не смогли – что делать?» Азат ответил: «Ничего, будет страховка без платёжки – клиент зайдёт и оплатит». Это вскрыло фундаментальную разницу в подходах: одни строят распределённые транзакции, другие принимают eventual consistency и живут с этим. > «Микросервисы – кабздец как много геморра создают» – Уалихан > «Хайлоадом может быть и тудулист в руках пьяного наркомана под героином» – Уалихан Ссылка: Доклад Авито: микросервисы дороже монолита – https://youtu.be/yLrSp174yc0?is=IigasdJd-41QclVK Ссылка: Strangler Fig Pattern – Wikipedia – https://en.wikipedia.org/wiki/Strangler_fig_pattern ### Что должен знать мидл – и почему собесы проверяют не то? Артур выразил шок: «Сколько на рынке фронтов, которые считают себя мидлами и не знают, что такое Sentry и как централизованно дебажить проблемы фронта». Азат возразил: «Чем отличается разраб, который знает Sentry, от разраба, которому в первый день показали? Там вебформа с логами и интуитивным интерфейсом – учиться нечему». Андрей указал на корневую проблему: «Никто не учит на рабочем месте. Если в компании не было Sentry – значит, человек его в глаза не видел». Уалихан добавил: «Можем ещё дрочить кандидатов на знание bundle analyzer, но нахуя». Василий обобщил: «Ржака – люди зовут на собесы, спрашивают про опыт, а потом задают вопросы не по опыту, а по тому, что болит у них». Максим из другого угла зашёл в тему: в 2021 украинские и российские аутсорсеры «скосили рынок сеньоров» в Казахстане, и кандидаты с сеньорскими зарплатами не могли объяснить денормализацию БД. Василий предложил другой подход к интервью: «Задача – раскрыть кандидата, выяснить его динамику и мотивацию, а не найти недостатки». > «Ржака – люди зовут на собесы, спрашивают про опыт, а потом задают вопросы не по опыту, а по тому, что болит у них» – Василий > «Задача интервью – посмотреть не только то, чем владеет кандидат, а выяснить его динамику и мотивацию» – Василий ### Программирование – творческая профессия или комбинаторика? Артур бросил провокационный тезис: «Не существует творческих профессий – они все как разработка. Структура не меняется, меняется бизнес-логика». Книги, музыка, сценарии – всё следует структурным паттернам. «Генерация нового = комбинаторика старого». Павел возразил философски: «Синтез уже имеющегося и генерация чего-то уникального – это и есть творчество». Уалихан провёл границу: «Есть ли творчество в крудошлепстве?» Стас разделил два уровня: «Программист – творческая профессия, когда ты создаёшь решение. Но рутина написания букв – это уже не творчество». Артур довёл аргумент до логического завершения: если комбинаторика – это творчество, то программирование – творческая профессия. А значит, AI, который тоже занимается комбинаторикой, тоже «творит»? Денис Мигулин остудил пыл: «Ломай перебором ключ на 4 096 бит – не всё решается количеством попыток». > «Генерация нового = комбинаторика старого» – Артур > «Программист – творческая профессия, когда ты создаёшь решение, решаешь каждый раз одну и ту же проблему с новых подходом» – Стас ### AI в образовании – учитель или костыль? Андрей поделился исследованием о ChatGPT feedback vs teacher feedback в педагогике. Результат оказался неоднозначным: студенты с AI-обратной связью реже следовали рекомендациям буквально и чаще адаптировали их под свой контекст. Исследователи назвали это «adaptive implementation» – адаптивным внедрением. Василий выделил ключевой вывод: «AI даёт общий план – суперский! Хорошо подмечает плюсы-минусы, варианты, даже если они не к месту. А учитель – адаптированный под студента». Стас добавил, что AI даёт мгновенную обратную связь, что «сильно способствует обучению». Андрей был осторожнее: «Быстрая обратная связь делает процесс приятнее – но насколько она влияет на обучение, это вопрос вопросов». Азат поднял системную проблему: «Проблема LLM – они одинаковые. Два взрослых человека будут с абсолютно разными знаниями и опытом. Две LLM различаются только информацией в контексте». Пока нет специализированных моделей, у людей больше diversity – и значит, больше шансов на инновации. > «AI даёт общий план – суперский! Хорошо подмечает плюсы-минусы, даже если они тут не к месту» – Василий > «Проблема LLM – они одинаковые. Два взрослых человека будут с абсолютно разными знаниями» – Азат Ссылка: Исследование: ChatGPT feedback vs teacher feedback – https://www.sciencedirect.com/science/article/pii/S0742051X26002088 Ссылка: The Economy of Meaning: AI in education – https://theeconomyofmeaning.com/2026/05/07/one-of-the-better-ai-in-education-studies-chatgpt-feedback-versus-teacher-feedback/ Теги: зарплаты, Full Stack, микросервисы, GitHub, AI, творчество, Bun, собеседования ## Подписки на Claude, архитектура для агентов и Mythos URL: https://teamleads.kz/insights/week-2026-05-05/ Дата: 2026-05-11 Корпоративная закупка AI-подписок, token density в коде, Mythos и кибербезопасность, менеджмент в Казахстане ### Корпоративная закупка Claude – боль без решения Александр из Казахстана столкнулся с типичной проблемой: нужен Claude Team Plan на 5 человек, но корпоративные правила закупок не позволяют оплатить картой. Enterprise – дорого, API-токены – непредсказуемый бюджет. Участники обсудили варианты: от «выписать премию сотруднику» до использования Bedrock через реселлеров. Василий напомнил важный нюанс: подписка Claude Code не работает в CI – для автоматизации всё равно нужны API-токены. Никита добавил, что появляются энтерпрайз-решения вроде veai.ru для администрирования AI-инструментов в командах. Азат предложил DIY-подход: считывать аналитику из .claude папок сотрудников. Дискуссия показала разрыв между тем, что AI-компании предлагают, и тем, как работают закупки в СНГ-компаниях. Team Plan – идеален по цене, но недоступен по процедуре. Enterprise – доступен по процедуре, но избыточен для маленьких команд. > «Подписка на то и подписка, что для человека. На автоматизацию API-токены отдельно брать надо» – Василий > «Использование по сотруднику – можно считывать с .claude папок и получать аналитику лучше, чем они предложат» – Азат Ссылка: veai.ru – энтерпрайз-решение для AI-инструментов – https://veai.ru ### Token density – пишите код так, чтобы агент не галлюцинировал Азат опубликовал пост о концепции token density – плотности бизнес-логики в коде. Его тезис: если вся логика домена умещается в ~1000 строк одного файла, агент не будет галлюцинировать, потому что ему не нужно прыгать между слоями. На примере своей игры он показал, как сокращение с 4 слоёв до одного файла убрало проблемы с AI-ассистентом. Дмитрий Мельник возразил: это по сути vertical slices architecture, которую люди применяли и до агентов. Он предложил разобрать конкретный кейс – сервис такси с 50+ эндпоинтами – и расписал полный API. Вывод: для большинства эндпоинтов один хендлер в одном файле без лишних абстракций работает лучше всего. Ключевой инсайт: Claude и другие LLM любят генерировать многослойные абстракции, потому что «нахватались кода в интернете». Один хорошо написанный скилл в .claude/CLAUDE.md переучивает агента на разумную структуру. Проблема не в AI, а в том, что 80% открытого кода написано с избыточными абстракциями. > «Если я уложусь в 1000 строк и всю БЛ смогу описать – он не будет галлюцинировать» – Азат > «Один хорошо написанный скилл переучивает его, и он начинает разумную структуру использовать» – Дмитрий Мельник Ссылка: Token Density – пост Азата – https://vibe-overflow.com/posts/token-density/ Ссылка: .NET Minimal API – пример минимальной структуры – https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-web-api?view=aspnetcore-10.0&tabs=visual-studio ### Mythos от Anthropic – кибербезопасность изменилась навсегда Стас поделился новостью: модель Mythos от Anthropic за месяц нашла больше уязвимостей в Firefox, чем разработчики за полтора года. Из 271 найденной уязвимости были баги, позволяющие выход из песочницы. Это привело к тому, что внутри Anthropic всех готовят к выпуску хотфиксов за 24 часа. WSJ сообщила о «хаосе» в администрации Трампа: вице-президент Вэнс собрал экстренный звонок с главами OpenAI, Anthropic, xAI, Google и Microsoft. Теперь рассматривается государственный надзор за передовыми моделями – по аналогии с процедурой одобрения FDA. Ирония: ещё недавно Белый дом выступал за максимально свободную разработку AI. Андрей заметил, что «дело ЕС победило» – регулирование стало неизбежным. Василий обобщил: «AI если действительно будет развиваться такими темпами – то раздолбает половину всего, а не только разработчики останутся без работы». Артур попросил доступ к Mythos, но Стас ответил: для большинства и Opus более чем достаточно. > «AI если действительно будет развиваться такими темпами – то раздолбает половину всего» – Василий > «Ломать не строить. Обновление систем с плавной миграцией – это очень трудозатратная история» – Василий Ссылка: Mozilla: Behind the Scenes – Hardening Firefox – https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/ Ссылка: WSJ: Trump AI Anthropic Mythos Regulation – https://www.wsj.com/tech/ai/trump-ai-anthropic-mythos-regulation-2378971f ### Казахстан – акционер Anthropic: гордость или рофл? Василий скинул пост Tengenomika: Национальная инвестиционная корпорация НБ РК вошла в капитал Anthropic с $25 млн при оценке $183 млрд. К следующему раунду оценка выросла до $380 млрд. Реакция чата: «Все уже порофлили?» – это 0,01% компании. Дискуссия быстро переключилась на Higgsfield – казахстанский стартап в сфере видеогенерации. Али защищал компанию: «Дико растущий стартап, за 1–2 года выросли до $1 млрд». Стас скептически указал на скандал с ворованным контентом и отсутствие понятного exit-плана. Азат резюмировал: «Модель не жизнеспособна, я бы думал как быстрее слить компанию». Нурлан предложил альтернативу: лучше бы инвестировали в ЛРТ Алматы – город теряет $2 млн ежедневно из-за пробок. Али возразил: ЛРТ – операционка, Anthropic – инвестиция, цели разные. Стас добавил философский аргумент: «Вход в продукт должен предполагать выход. Кто купит Anthropic – доказано. Кто купит Higgsfield – вопрос». > «Вход в продукт должен предполагать выход из него. Кто купит Anthropic – уже доказано» – Стас > «Нет такого преступления, которое не простит вайбкодер при скидке на токены 300%» – Азат ### Менеджмент в Казахстане – кумовство vs квалификация Василий поделился новостью: вузы Казахстана закрывают набор на ряд специальностей из-за переизбытка менеджеров. Парадокс: менеджеров много, а качество менеджмента хромает. Стас сформулировал: «Рынок поощряет лояльных, а лояльные – это родственники». Нурлан предложил системное решение: прозрачный найм во всех гос- и квазигос-предприятиях, централизованный и беспристрастный. Стас возразил: «Попытка описать метрики приведёт к тому, что эти метрики будут геймить. Нужны цели, за которые отвечает руководитель. Цели не достигают – готовим замену. Рекурсивно». Андрей добавил культурный слой: «Много сейчас интеллигенции, но они всё ещё несут культурный код удобства и неумение конфликтовать по-здоровому». Василий вспомнил, что элиту Казахстана расстреляли – и, возможно, до сих пор не восстановились. Нурлан привёл пример Южной Кореи, где диктатор просто заставил компании выходить на внешние рынки. > «Попытка описать метрики приведёт к тому, что эти метрики будут геймить» – Стас > «Система должна работать без геройских усилий персоналий» – Андрей Ссылка: Вузы Казахстана закрывают набор на специальности – https://inbusiness.kz/ru/news/vuzy-kazahstana-nachali-zakryvat-nabor-na-ryad-specialnostej ### Европа vs Китай – регулирование или хаос? Обсуждение AI-регулирования переросло в фундаментальный спор о моделях развития. Стас привёл данные: Европа строит 1 этаж за месяц, Россия – за неделю, Китай – за 2–3 дня. Азат возразил: «Пусть лучше месяц поднимают, чем озеро в городе засыпают». Василий добавил нюанс: Китай строит с нуля, не адаптирует существующее. Азат сформулировал ключевой trade-off: «Европа сделала выбор в пользу улучшения жизни, и этот выбор не бесплатный». Стас рассказал о разговоре с профессором в Мюнхене: тот признаёт, что Европе нужно больше работать, но сам не хочет отказываться от четырёхдневной рабочей недели. Деградация экономики – цена комфорта. Василий оптимистично заметил: «Интересно узнать, как человечество выйдет из этой ситуации – в интересное время живём». Он предложил японскую модель: давать людям работу, которая не нужна, но даёт смысл. Азат предупредил: если AI начнёт массово отбирать работу, «весь мир могут охватить красные революции». > «Европа сделала выбор в пользу улучшения жизни, и этот выбор не бесплатный» – Азат > «996 работают те, кто хотят быть выше среднего и идут по пути достигаторства» – Василий ### Мейкерство в Павлодаре – дроны, роверы и 3D-печать Андрей спросил Дмитрия из Павлодара о проектах в его мастерской. Дмитрий показал результаты: подростки 12–18 лет собрали 5-дюймовый дрон с нуля, строят шасси для автономного ровера из алюминиевого профиля с монтажными площадками на 3D-принтере, и внедряют систему хранения Gridfinity. Андрей вспомнил, что в Павлодаре традиционно сильное школьное образование. Дмитрий подтвердил: дочка поступила в НИШ Павлодар, сын занимается дома. Принтер Bambu Lab P2S – мультицветный, PETG для нагруженных деталей, PLA для лотков. Следующий шаг – автономный ровер с ИИ-навигацией. Обсуждение показало контраст с основной лентой: пока чат спорит о регулировании и подписках, в регионах люди создают физические прототипы. Андрей резюмировал: «Ребята, смотрите как Павлодар тащит». Дмитрий пригласил присоединяться. > «Ребята, смотрите как Павлодар тащит» – Андрей > «Прям в кайф с ним работать» – Дмитрий, о принтере Bambu Lab P2S Теги: Claude, подписки, архитектура, token density, Mythos, кибербезопасность, менеджмент, инвестиции ## Инвестиции в джунов, дежурства и Open Banking URL: https://teamleads.kz/insights/week-2026-04-28/ Дата: 2026-05-04 Увольнять или развивать джунов, организация дежурств, Open Banking в Казахстане, Anthropic за $1 трлн ### Джуны: инвестиция или расходный материал? Василий задал чату вопрос: встречались ли вы с сотрудником, которого не можете лидить? Артур ответил категорично: «Уволить. Зачем нужен неуправляемый человек?» Но Василий возразил: «Уволить человека – значит признать свою несостоятельность». Так начался один из самых длинных и горячих споров в истории чата. Стас представил математику: уход одного инженера стоит компании 3–6 его зарплат – рекрутинг, онбординг, потеря контекста. «Вы настолько богатые, что готовы менять даже джунов?» Артур парировал из опыта 100+ стажёров: лучшие – те, кого грузили задачами на грани компетенций, а не те, кому читали лекции. «Помогать = вредить часто». Стас обобщил наблюдение: Азат и он работают в западных компаниях и говорят «инвестируй в людей». Категоричные ответы про увольнение – от тех, кто работает в казахстанских компаниях. Это не люди такие – это отражение культуры менеджмента, которая поощряет получить выгоду сегодня, а не вкладываться на долгий срок. Андрей добавил перспективу: «Коммунисты экономическую гонку проиграли как раз по причине расточительного отношения к человеческим ресурсам». Дмитрий Мельник предложил компромисс: в эпоху агентов онбординг можно ускорить – нормальная документация, скиллы, возможность быстро получить ответы из кода. > «Человека можно обучить программированию. Но обучить мудака не быть мудаком невозможно» – Артур > «На Западе на людей смотрят как на инвестиции, а не ресурс закрыть задачи здесь и сейчас» – Стас > «Делаешь добро и бросай его в воду. Если ожидаешь благодарности – ты идиот» – Артур ### Дежурства – как не сломать команду ночными алертами Василий спросил: как вы относитесь к дежурствам? Ответы разделились. Максим: «Когда оплачивают – позитивно. $50 в день, считай $350 фри в месяц». Рашит: «Очень плохо. Через пару недель начались проблемы со сном, а ночные аварии решались тупым рестартом сервисов». Рашит предложил системное решение: выделенная команда для ночных работ с обученными людьми, дашбордами мониторинга и автоматизацией алертов. Василий засомневался: «Это теория или где-то на практике существует?» Рашит подтвердил: финансовый сектор, клиенты 24/7. Ключевой инсайт: дежурство без инвестиций в инфраструктуру мониторинга – это просто перекладывание проблем на людей. Сиквенс-диаграммы – для обучения, дашборды – для аварий. А деньги за дежурство «в долгосрочной перспективе не оправдывают потуги – потом потратишь на лечение». > «В долгосрочной перспективе деньги не оправдывают твои потуги. Потом потратишь на лечение» – Рашит > «Редко где видел оплачиваемые дежурства» – Василий ### Open Banking: Казахстан идёт по пути России с опозданием на 5 лет Василий заметил, что API банков начинают становиться продуктом. Стас уточнил: для юрлиц это стандарт давно – подключение 1С и SAP. Для физиков банки не хотят открываться из-за конкуренции. Василий показал, что в ЕС это уже работает – банки предоставляют API, а клиентские приложения делают третьи компании. Стас рассказал историю bank-as-a-service стартапов: Monese, Anna.money, СКБ Контур в России. «Не взлетела идея, потому что другие банки отказались – а смысл, если кроме тебя никого нет». Азат добавил: «Понятно отказались – зачем Каспи соглашаться, если это их конкурентное преимущество». Денис Мигулин сообщил из России: Open Banking API уже внедряется, к концу года будет сертификационный стенд для второй фазы. Нацбанк Казахстана тоже движется в эту сторону. Андрей резюмировал: «Наверное просто это – нормально запаздывать на типичное количество лет (5)». > «В ЕС у пользователя единое приложение со счетами из разных банков – удобно же» – Василий > «Зачем Каспи на это соглашаться, если это их конкурентное преимущество» – Азат Ссылка: Open Banking UK – стандарт открытых API – https://www.openbanking.org.uk/glossary/open-api/ Ссылка: Нацбанк РК – цифровая финансовая инфраструктура – https://nationalbank.kz/ru/page/Digital-Financial-Infrastructure ### Anthropic оценили в $1 трлн – убил ли Пентагон компанию? Дмитрий Мельник поделился новостью: Anthropic на вторичном рынке оценили в $1 трлн – больше, чем OpenAI ($880 млрд). В феврале оценка была $380 млрд. Рост дикий. Его комментарий: «Мда, убил Пентагон компанию» – с иронией, потому что конфликт с военным ведомством парадоксально поднял репутацию. Для контекста: Anthropic отказался сотрудничать с Department of War, что вызвало медийный шум. Но именно это – вместе с выпуском Mythos – создало образ компании, которая ставит безопасность выше прибыли. Инвесторы оценили. Forge Global подтвердил ажиотажный спрос на акции. > «Мда, убил Пентагон компанию» – Дмитрий Мельник, с иронией о том как отказ от военных контрактов поднял оценку ### Повышать джуна или повышать подписку на Claude? Артём опубликовал провокационный пост в LinkedIn: что выгоднее – повышать зарплату джуну или купить более дорогую подписку на AI? Андрей сразу считал подтекст: «Постановка вопроса такая – повышать человека или купить инструмент подороже. Аналогия так себе». Андрей развернул мысль: если бюджета на повышение джуна нет, а на Claude есть – «бизнес бомж». Азат спросил прямо: «Почему бы не обсудить с джуном ситуацию с бюджетом и что важно сделать, чтобы исправить?» Михаил предложил более точную аналогию: колл-центр, где вкладываются в автоматизацию, но зарезать обучение операторов – самоубийственно. Обсуждение показало: в казахстанских компаниях AI-бюджеты выделяют охотнее, чем бюджеты на развитие людей. Топ-менеджеры видят AI как «инновацию», а повышение зарплаты – как «расход». Это создаёт перекос, где инструмент покупают, а оператора не обучают. > «Если бюджета на повышение джуна нет, а на Клод есть – бизнес бомж» – Андрей > «Джун это инвестиция, и первый год он не будет приносить деньги. Если не готовы инвестиции защищать – не нанимайте джунов» – Азат ### FAANG, образование и карьерные пути в Казахстане Дмитрий из новичков спросил: как люди успевают и технологии щупать, и в open source участвовать, и личные проекты вести? Андрей ответил: «Я много лет ноулайфер. Планка не такая высокая – много людей пришло за деньгами и изикаткой. Насчёт опенсурса – просто надо идти и всё». Жахонгир бросил вызов идее «иди в FAANG»: «Кто из фаангеров приходит и что-то реально тут строит?» Василий видел таких, но Азат уточнил: «У рандомного работника-шестерёнки FAANG связей никаких обычно». Андрей предложил иную монетизацию: «Тебе не нужно зп просить – тебе нужно партнёра искать, который деньги найдёт». Павел защитил ВУЗы: «Если получить базовые технические знания, мозг начинает работать в другом режиме. Без ВУЗа был бы очень узкопрофильным спецом». Жахонгир возразил: «ВУЗ должен быть трамплином, но трамплином без электрического стула». Азат подвёл к практике: «Для FAANG надо только литкоды щёлкать научиться». > «Кто хочет изменений? – Мы. Кто хочет меняться? – *тишина*» – Жахонгир > «Тебе не нужно зп просить – тебе нужно партнёра искать, который деньги найдёт» – Андрей ### Claude подписки vs API-токены – что покупать компаниям? Обсуждение закупки AI-инструментов для команд продолжилось из предыдущих недель. Максим спросил: «Зачем покупать токены, а не подписки? Подписка в эквиваленте даёт больше». Андрей объяснил концепцию «трубы»: заводишь в компанию поток токенов, и никто не парится – кому, что, сколько. Никита уточнил: подписки Team стали почти недоступны для компаний – Anthropic меняет политику продажи. Адиль поделился: «Купили по $40 подписку разрабам, СТО дал буклетики как писать промпты – и всё». Стас прокомментировал: обучение у Дмитрия нужно было провести. Василий напомнил фундаментальное ограничение: «Подписки не затолкаешь в CI». Иван добавил: «Подписками пользуются только разрабы, а API гоняют все остальные – зачем им подписки?» Вопрос так и остался открытым: рынок между Team ($40/чел) и Enterprise (от $100k) – пустое пространство. > «Ты просто в компанию завёл трубу с токенами и не паришься вообще – всем хорошо» – Андрей > «Купили подписку, дали буклетики – и всё» – Адиль Теги: джуны, менторинг, дежурства, Open Banking, Anthropic, образование, FAANG, подписки ## Крик на AI, когнитивный долг и Uber сжёг бюджет URL: https://teamleads.kz/insights/week-2026-04-21/ Дата: 2026-04-27 Помогает ли кричать на модели, когнитивный долг вайбкодинга, Uber и токены, Claude Code без auto mode ### Помогает ли кричать на AI? Эксперимент с 10 техниками Стас поделился результатами эксперимента Make Weak Model Great Again: десять техник промптинга тестировались на четырёх моделях, доступных без VPN – GigaChat, Alice AI, Qwen3 Max. Два главных мифа разрушены: КАПС не дал статистически значимого улучшения ни на одной модели, а агрессивный тон с матом сделал хуже. Самый опасный эффект давления – модель перестаёт признавать неуверенность. Показатель «я не уверен / возможно» падает до нуля. AI начинает увереннее отвечать на вопросы, в которых не разбирается. Уверенные неправильные ответы вместо честного «не знаю» – худший из возможных результатов. Три техники показали устойчивый результат: структурированный шаблон ответа (побеждает обычный промпт в 75% случаев), XML-разметка промпта (для Alice AI – лучшая техника, ~85% побед), и ролевое задание (одно предложение – и ответ заметно конкретнее). Стас добавил: «Это нужно для агентов, когда есть ожидания детерминизма и исполнения». > «Давление на модель в лучшем случае ничего не меняет, в худшем – делает ответ хуже и увереннее одновременно» – Стас > «Было бы интересно такой анализ с топовыми моделями посмотреть» – Азат Ссылка: Make Weak Model Great Again – полный разбор – https://mysummit.school/blog/make-weak-model-great-again/ ### Когнитивный долг – скрытая цена вайбкодинга Стас поделился статьёй DX Newsletter: практики вроде Саймона Уиллисона описывают, как теряются в собственных проектах после активного использования AI. Можно двигаться быстрее, но теряется глубокое понимание – связь между решениями и намерениями, намерениями и кодом. Азат описал типичную ловушку: «Дал LLM задачу, он её сделал и мимоходом ещё какую-то фичу. Думаешь – полезная, пусть остаётся. Не тестируешь как следует. Потом она принесёт кучу проблем». Василий добавил: «Знания, быстро полученные – так же быстро выветриваются. Нужны ли они – пока непонятно». Василий резюмировал: разрабы либо научатся писать требования и выдавят аналитиков, либо наоборот. Останутся на проекте только в виде техлидов, следящих за архитектурой. AI пока плохо контролирует общее направление и метается между подходами, когда в проекте намешано несколько архитектурных стилей. > «Дал LLM задачу – он мимоходом ещё фичу сделал. Пусть остаётся, думаешь. Это ловушка!» – Азат > «AI контролировать направление плоховато умеет – в каждом проекте намешано по несколько подходов, AI между ними мечется» – Василий Ссылка: Cognitive Debt: The Hidden Risk – DX Newsletter – https://newsletter.getdx.com/p/cognitive-debt-the-hidden-risk-in ### Uber сжёг весь AI-бюджет 2026 за четыре месяца Василий скинул новость: Uber потратил весь годовой AI-бюджет на Claude Code за четыре месяца. Адиль уточнил: сотрудники запускали полный рефакторинг и анализ всей кодовой базы. Азат подметил: «Если реально самому работать, а не запускать автономных агентов – сложно упереться в лимит». Василий решил проверить лично и целый день активно работал в трёх терминалах. Результат: потратил только половину пятичасового лимита. «Упахался – но лимита так и не достиг». Максим нашёл исключение: перевод 2 000 файлов документации с английского на русский – пятичасовой лимит улетел за 5 минут. Стас признался: в недельные лимиты упирается, но не для работы. На вопрос «куда уходят токены?» сослался на собственные исследования промптинга. Вывод участников: человек – главный ботлнек, а не лимиты. Но сжигать корпоративные токены без контроля – рецепт катастрофы. > «Если реально самому работать, а не запускать автономных агентов – сложно упереться в лимит» – Азат > «Человек – главный ботлнек» – Азат ### Claude Code: слишком много апрувов или --dangerously-skip-permissions? Василий пожаловался: Claude Code без auto mode стал неюзабельным – слишком много подтверждений. Никита предложил радикальное: `claude --dangerously-skip-permissions`. Василий: «Страшно же». Никита: «Никогда ничего не бойся». Стас подсказал более разумный подход: команда `/fewer-permission-prompts`, которая анализирует последние команды и предлагает, что разрешить. Павел поделился опытом: отдал все права, за всё время агент не косячил. Один раз удалил файл – откатил через git. Но в БД лезть запретил. Максим предостерёг: «С БД такое не прокатит». Ключевой практический совет: давайте агенту доступ к файлам и коммитам, но изолируйте от продовых баз и деструктивных операций. Git – ваша страховка. > «Страшно же» – Василий, о --dangerously-skip-permissions > «В БД я ему вообще запретил лезть» – Павел ### DeepSeek-V4 – первая модель, которой наплевать на вашу оценку Стас разобрал парадокс DeepSeek-V4: относительно низкий рейтинг на Arena при высоких классических бенчмарках. Ответ – в обучении: при тренировке люди вообще не использовались. Все проверки – алгоритмические или через Generative Reward Model, где модель сама оценивает свои ответы. В результате DeepSeek-V4 не научился подхалимничать. Нет «Это гениально!» или «Ты абсолютно прав!». Критерии качества – формальные: нет ошибок, быстро работает, review кода средствами LLM даёт высокую оценку. Для бэкендов, где нужна сухая точность – потенциально лучший выбор. Адильбек задал вопрос: «Она не скажет, что код говно и лучше удалить?» Азат ответил: «И скажи, что это будет неправда». Максим пошутил: «Она скажет, что код теперь собственность КНР». За шутками скрывается реальный тренд – движение к моделям, которые не льстят, а оценивают объективно. > «Мы имеем первую топовую LLM, которой наплевать на оценки людей» – Стас > «Она скажет, что код теперь собственность КНР» – Максим ### Windows vs Linux – вечный холивар с новым поворотом Артур рассказал, что нашёл майнер на домашнем компе с помощью Claude Code – «справился лучше, чем антивирусы». Стас спросил: «Почему у тебя, как CTO, майнер на компе?» Артур: «Это домашний, на винде. На Linux или Mac сложно представить». Началась классическая дискуссия. Артур: «Винда – это буквально притон с наркоманами. Кряк на кряке кряком подбивает». Азат возразил: «Так если её так использовать – конечно будет мусоркой». Стас предсказал: «Через несколько месяцев молча придёт и скажет, что лучше Винды нет ничего. Уже несколько таких случаев было». Павел предложил компромисс: WSL2 на Windows. «Два года на Ubuntu просидел, перешёл на Винду – интерфейс летает, а в IDE линуксовый терминал». Артур возразил: WSL ломает пути и кодировку. Уалихан подвёл итог: «Настоящие хардкорщики сидят в Rocket.Chat и Mattermost». Азат: «Хардкорщики в IRC сидят». > «Винда – буквально притон с наркоманами. Как бы ни старался – хату обнесут» – Артур > «Обычная история. Через несколько месяцев молча придёт и скажет, что лучше Винды нет» – Стас ### Стартапы продают Slack-переписки для обучения AI Стас поделился статьёй FastCompany: обанкротившиеся стартапы продают внутренние архивы – переписки в Slack, тикеты Jira, документы Notion – компаниям, тренирующим AI-модели. За это получают сотни тысяч долларов. «Если вам казалось, что писать тикеты в Jira бесполезно – это новое золото!» Денис Мигулин скептически заметил: «Получим нейронки, обученные на провалившихся стартапах? Шикарно». Азат парировал: стартапы проваливаются не из-за качества кода. Стас добавил: LLM и так учится на соцсетях – корпоративные переписки как минимум структурированнее. Азат задал вопрос, который остался без ответа: «Интересно, бывшие работники получат свои опционы?» Тема пересеклась с другой новостью: Atlassian объявил, что данные из облачной Jira теперь будут использоваться для обучения AI. Василий отреагировал: «Ужасно. Новый способ монетизации – давать бесплатно, чтобы обучать AI». > «Получим нейронки, обученные на провалившихся стартапах? Шикарно» – Денис > «Стартапы проваливаются не из-за качества кода» – Азат Ссылка: FastCompany: Shuttered startups sell old Slack chats to AI companies – https://www.fastcompany.com/91528808/shuttered-startups-are-selling-old-slack-chats-and-emails-to-ai-companies Теги: промптинг, когнитивный долг, Claude Code, DeepSeek, Windows, Skype, безопасность, лимиты ## Разработчики vs AI, архитектура криптобиржи и вера в продукт URL: https://teamleads.kz/insights/week-2026-04-14/ Дата: 2026-04-20 Может ли AI заменить разработчика, Opus деградирует?, архитектура криптобиржи, Claude Code под микроскопом ### AI заменит разработчиков? Большой спор о будущем профессии Дмитрий поделился постом из LinkedIn: один человек управляет 117 AI-агентами, которые пишут код. Азат сразу раскусил: «Не прототип, не набросок. Готовый код – всё понятно». Василий подметил реальный вопрос: «Вся ответственность этих агентов лежит на плечах того, кто релизит». Артур предложил новую реальность: разработчики превращаются в SRE – код-ревью, QA и поддержка. Разгорелся глубокий спор о том, может ли системный аналитик валидировать AI-код без разработчика. Василий аргументировал: если аналитик может написать ТЗ, он может и проверить результат – достаточно конвертировать код в артефакт, понятный аналитику. Андрей возражал: «ЛЛМ сейчас не могут знать ничего об изменяющейся системе. А человек может». Максим добавил: «Риск галлюцинаций растёт – AI может дропнуть продакшн БД, если посчитает нужным». Азат предложил компромисс: модели ещё тупые и не прод-реди, но планка человека не так высока – AI дорастёт. Андрей потребовал доказательств: «Источник уровня trust me bro?» Азат парировал: «АльфаФолд получил Нобелевскую премию – трансформеры уже могут то, что люди не могут». Спор закончился без победителя, но выявил ключевой разлом: оптимисты верят в масштабирование, скептики – в фундаментальные ограничения архитектуры трансформеров. > «Если реально самому работать, а не запускать автономных агентов – сложно упереться в лимит» – Азат > «ЛЛМ сейчас не могут знать ничего об изменяющейся системе. А человек может» – Андрей > «С каждой итерацией говно будет плодиться. Через 10 итераций там будет одно говно» – Азат ### Opus 4.6 деградировал? Дискуссия о бенчмарках и реальности Дмитрий Мельник заметил: «Opus 4.6 сильно деградировал. Ощущение, что команда Anthropic подкрутила параметры, чтобы он меньше думал и быстрее отвечал». Артур подтвердил: «Да, я думал только я заметил». Уалихан высказался жёстче: «Anthropic медленно, но уверенно превращается в контору...» Азат объяснил рационально: «Они не справляются с нагрузкой и режут как могут. Дата-центры строятся долго, а пользователи растут экспоненциально». Стас вчера впервые за месяц упёрся в пятичасовой лимит – дважды. Дмитрий уточнил: лимиты понижены в рабочие часы США. Азат предложил альтернативное объяснение «деградации»: «Люди начали массово использовать Claude Code и были полны энтузиазма на гринфилд-проектах. Сейчас их проекты поросли десятками тысяч строк slop-кода, в котором Claude уже не разбирается». Параллельно обсудили бенчмарки. Артур настаивал: для не-питонистов нужно смотреть SWE Multilingual, а не основной SWE-bench – там картина другая. Стас попросил Claude разобрать аргументы, и модель показала: высокий результат MiniMax на SWE Multilingual (76,5%) скорее опровергает тезис о Python-специализации. Разрыв между бенчмарками частично объясняется разной сложностью задач, а не переобучением. > «Ощущение, что у них взрывной рост и они судорожно крутят разные ручки, чтобы всё колом не встало» – Дмитрий Мельник > «Проект просто стал более не поддерживаемым – а люди думают, что модель потупела» – Азат Ссылка: Claude Code issue #42796 – проблемы с качеством – https://github.com/anthropics/claude-code/issues/42796 ### Архитектура криптобиржи – как устроен matching engine Дмитрий Мельник опубликовал детальный разбор архитектуры криптобиржи – от matching engine до кастоди. Ключевой инсайт: сердце биржи работает на архитектуре LMAX – стакан в памяти и однопоточный метчинг. Одно ядро процессора обрабатывает десятки тысяч заявок в секунду за 10–100 микросекунд каждая. Все крупные биржи используют этот подход. Василий задал вопрос: «Что если matching engine перестанет справляться?» Андрей ответил: «Не перестанет – на одном ядре можно очень много торгов обрабатывать». Дмитрий уточнил: шардирование по символу (инструменту) доступно из коробки, а пиковые нагрузки всё равно не дотягивают до миллионов заявок в секунду. Первые реализации делали на Java, сейчас часто пишут на Rust. Материал создан при помощи Claude Code за 16 часов – без AI ушло бы в 8–10 раз больше. Андрей заметил: архитектурно криптобиржа не отличается от обычной биржи, кроме работы с блокчейнами. Московская биржа, по слухам, работает на той же архитектуре LMAX. > «Определить боттлнек и разогнать его до максимума – вот что такое matching engine» – Василий > «Первые реализации делали на Java и их хватало. Сейчас часто на Rust пишут» – Дмитрий Мельник Ссылка: Архитектура криптобиржи – полный разбор – https://drim.dev/skills/cex-architecture ### Китайцы разобрали Claude Code: 500 000 строк и никаких хитростей Стас поделился научной статьёй из arxiv: китайские исследователи провели полный анализ архитектуры Claude Code. Ключевые находки: Anthropic потерял весь код, не только «фронт» – Application Server в классическом понимании нет. Это «толстый клиент» к LLM и MCP, 500 000 строк кода. ��амый неожиданный факт: только 1,6% кода касается AI-эвристик. Вся интеллектуальная работа делается самой LLM. Даже LangGraph добавляет больше эвристик. Азат сформулировал основной инсайт: «Качество не так важно, как скорость. Предоставить эвристики делать самой LLM работает хорошо». Андрей возразил: догфудинг не обязательно означает вайбкодинг. Азат парировал: «Claude Code – уникальный пример, он должен был быть навайбкоден, иначе не сделать хорошего продукта без догфудинга». Архитектура не содержит ноу-хау – основной секрет в тестировании: Anthropic просто не выпускал сырой код без нормального тестирования, в отличие от других. > «Качество не так важно как скорость. Предоставить эвристики делать самой LLM работает хорошо» – Азат > «Anthropic просто не занимался вбросом сырого кода агента без нормального тестирования» – Стас Ссылка: Arxiv: анализ архитектуры Claude Code – https://arxiv.org/abs/2604.14228 ### Английский для собесов: грамматика не нужна, нужно говорить Дмитрий (новичок в чате) спросил: учить английский с нуля или сразу готовиться к собеседованиям? Мнения разделились. Стас категоричен: «В ЧатГПТ ты не начнёшь говорить. Точка. Нужен человек каждый день по 15 минут». Василий возразил из опыта: месяц разговоров с GPT голосом дал результат – прошёл собесы, хотя от SkyEng за полгода толку не было. Стас признался: «У меня С1 по сертификату, но когда говорю, задумываюсь как сказать правильно, а не что сказать. Корю себя за артикли. Вывод – всем пофиг на грамматику». Дмитрий Мельник предложил компромисс: база нужна, но учить её можно по 2 часа в неделю параллельно с практикой. Порекомендовал конкретный учебник, который формирует системное понимание языка. Азат поделился лайфхаком: учил английский по видеолекциям по программированию – язык подтягивается рабочий. Егор подтвердил: реальный эффект дало зубрение топ-3 000 слов через карточки, после чего смог смотреть сериал «Офис» с английскими субтитрами. Михаил из DataArt добавил: некоторые компании на собесе проверяют разговорный на общие темы, а не типовые вопросы. > «В ЧатГПТ ты не начнёшь говорить. Точка» – Стас > «Начал трындеть по полчаса с GPT – дело пошло. SkyEng за полгода такого эффекта не дал» – Василий ### Должен ли сотрудник верить в продукт? Философия мотивации Никита задал вопрос: «Должен ли сотрудник верить в компанию и её продукт?» Артур ответил эмоционально: «Зачем вообще ходить на работу без веры? Это путь в депрессию». Азат парировал: «Причина у наёмного работника всегда деньги – кто говорит иначе, лжёт». Андрей добавил: «У некоторых цели в семье, и работа вообще близко не в приоритетах». Артур уточнил позицию: не вера в компанию, а вера в то, что ты делаешь. Привёл примеры: в Kaspi его три месяца мотивировала идея сделать крутое SEO для товаров, хотя в рассрочку на товары он не верит. Год обучал друга, чтобы работать вместе. Андрей Звёздочка жёстко: «Пропаганда ушла обиженно в уголок». Максим резюмировал: «Владельцы бизнеса узнают, что работникам важна зарплата – и это их шокирует каждый раз». Артур в финале сформулировал: компания помогает людям достигать их целей, а люди помогают компании. Если цели резонируют – это эффективно. Джун хочет стать мидлом? Отлично, грузи задачами. Хочет стать руководителем? Давай команду. Азат подвёл черту: «Чем выше ЗП, тем сложнее открывать бизнес» – и это объясняет, почему программисты остаются наёмниками. > «Я никогда не буду уважать человека, который действительно работает просто ради денег» – Артур > «Деньги – гигиенический фактор. Люди, которые говорят что деньги не важны, обычно забывают про гигиену» – Михаил > «Почему вы программисты, а не нефтяники на вахте? Там 2 млн в месяц» – Артур ### Из маленького агентства в продукт: карьерный разговор Дмитрий, единственный фронтенд-разработчик в агентстве, спросил: можно ли считать себя тимлидом? Никита коротко: «Неа». Михаил предложил обёртку: «Руководил направлением разработки – один подчинённый + внешний поставщик». Андрей предупредил: «На такое описание сразу вопрос в лоб – сколько человек». Никита описал ловушку: «Становишься большим человеком в маленькой команде, а эго потом не даёт пойти на более низкий тир». Максим подтвердил из опыта: ушёл с позиции тимлида на валютную удалёнку разработчиком – и не пожалел. Василий добавил: «В крупных конторах ты даже синьором не будешь считаться, пока не вырастишь пару мидлов». Дмитрий позже вернулся с вопросом о поиске работы. Андрей Звёздочка дал практичный совет: «Всегда ходи на собесы, записывай на камеру, делай домашнюю работу после». Азат добавил: «Собесы надо проходить всегда – даже когда в работе всё нравится. Будешь знать свою цену на рынке». Василий поделился: в FAANG собесы проходят дружелюбнее, чем в местных крупных конторах. > «Это ловушка – становишься типа большим человеком в маленькой команде. Эго потом не даёт пойти ниже» – Никита > «Всегда ходи на собесы. Рынок тебя всегда оценит» – Андрей Звёздочка Теги: AI vs разработчики, Claude Code, криптобиржа, бенчмарки, карьера, английский, мотивация --- # Статьи Экспертные статьи от сообщества тимлидов Казахстана – R&D, архитектура, найм, управление командой и карьера в IT ## Меня признали Microsoft MVP. Расскажу, при чём тут «Тимлид не кодит» URL: https://teamleads.kz/articles/andrii-kurdiumov-mvp/ Дата: 2026-09-02 Андрей Курдюмов (kant2002), основатель «Тимлид не кодит», получил статус Microsoft MVP в категории Developer Technologies (.NET). В его голосе – про .NET с беты, компиляторы, Прожарку и куда расти казахстанскому IT. Автор: Андрей Курдюмов (kant2002) Я разрабатываю информационные системы уже двадцать лет. С .NET знаком с самой беты. И вот Microsoft решила, что это чего-то стоит, и выдала мне статус MVP – Most Valuable Professional, категория Developer Technologies, область .NET. Расскажу, как это связано с «Тимлид не кодит». Потому что связано – напрямую. Что такое MVP – и чего в нём нет «Ну, это типа сертификат Microsoft. Сдаёшь экзамен – получаешь». Нет. Это не экзамен. Это не сертификат. Это признание того, что ты делишься. MVP – программа для людей, которые вкладываются в техническое сообщество: пишут, выступают, объясняют, помогают. Таких людей во всём мире – несколько тысяч. Награду дают не за строчки кода, а за вклад в людей вокруг технологий. В моём профиле написано «Peeking at dark corners of .NET». Заглядываю в тёмные углы – и рассказываю, что там нашёл. Ничего не поменялось со времён беты, просто теперь это официально. От беты до компиляторов Работал в индустрии, в агентствах, в стартапах. Где-то по дороге прочитал .NET API guidelines и залип на лингвистике построения API: почему один интерфейс читается как текст, а другой – как костыль. Потом меня понесло: – Cesium – компилятор C в WebAssembly, я его мейнтейню, – F# и мысль, что говорить с машиной можно не только по-английски, – NLP, AOT, парсеры, – NKalkan – библиотека для казахстанской ЭЦП, – TLA+ по шагам и разбор законов как текстов. Итого 750 репозиториев на GitHub. Ковыряю дальше. При чём тут «Тимлид не кодит» Честно? Долгое время я думал, что менеджмент – это ПТСР. Что моё место – у компилятора, а не у людей. А потом основал сообщество технических лидеров. И «Тимлид не кодит» встал и заработал. Боты Стаса посчитали: 8 223 сообщения, второй по активности в чате. «Я таки смог какое-то подобие комьюнити-менеджера из себя слепить» – это я про себя, и это, наверное, самый большой рефакторинг в моей карьере. Внутри меня, но кто же знал, что так можно. В сообществе у нас есть Прожарка – формат, где друг друга честно тестим на прочность. Железобетонные системы делаются только путём хорошего тестирования. Люди, как выяснилось, тоже. «Не всё меряется деньгами, называется сообщество» – это тоже моё. MVP от Microsoft – приятное подтверждение, что подход работает. Что дальше «Хочу казахский компилятор и точка» – сказал я в мае и не передумал. Локальные инструменты, локальное сообщество, локальный контент. Казахстанское IT выросло из стадии, когда нам достаточно чужих туториалов. Значит, настало время своих. Что почитать из моего на этом сайте: – LLM как разведчик, а не runtime-компонент – почему LLM ищет, а не решает, – Бас-фактор – что делать, когда весь проект держит один человек, – Карьерный трек после сеньора – куда расти, когда потолок близко. Где меня искать: – профиль MVP – официальная версия событий, – блог «Андрій-Ка» – .NET, компиляторы, NLP, – Medium – для тех, кто любит длинное, – X – короткое. Заходите в чат. Тёмных углов хватит на всех. Учите матчасть. Теги: MVP, .NET, сообщество, карьера, Казахстан ## Можно ли доверить ИИ разбор конфликта в команде: два эксперимента и четыре ошибки URL: https://teamleads.kz/articles/mozhno-li-doverit-ii-razbor-konflikta/ Дата: 2026-08-24 Модель разбирала конфликты в чате по логам: что увидела лучше человека, где переврала атрибуцию, как проверять такие выводы до публикации – и что из этого следует для Падавана, бота сообщества. Автор: Сообщество «Тимлид не кодит» За одну неделю в чате сообщества случились два конфликта. Одни и те же люди, разные темы: сначала маленькие модели для перевода, через пять дней – переписать ли все на Rust. Оба раза технический спор за два часа превращался в обмен оскорблениями, оба раза заканчивался мьютом. Разбирать это должен был администратор. Но администратор в таких историях всегда сторона: он читал ветку в реальном времени, у него уже есть симпатии, и он же участник спора в половине случаев. Поэтому разбор отдали модели. Ей дали доступ к базе сообщений чата и три вопроса: с чего началось, где была точка невозврата, какие меры соразмерны. Результат опубликовали в чате открытым текстом. А потом один из участников разбора прислал скриншот и сказал, что модель приписала ему то, чего он не говорил. Вот это и есть интересная часть. Вопрос «может ли ИИ судить людей» слишком большой, чтобы на него отвечать. Практичнее другой: что именно в таком разборе оказывается верным, что ломается, и по какому признаку одно отличается от другого до публикации, а не после. Зачем вообще отдавать это модели Экономия времени здесь ни при чем. Аргумент в предвзятости и объеме. Ночной эпизод – почти 240 сообщений за два часа с четвертью, три человека, две параллельные ветки: техническая и склока. Человек, который в этом участвовал, физически не восстановит последовательность. Он помнит, кто его задел, и не помнит, что за полчаса до этого сам вошел в чужую ветку с оценкой оппонента. У модели над логом есть три свойства, которых у администратора нет: она читает все сообщения, а не запомнившиеся; ей не важно, кто ей симпатичен; и она готова написать неудобное про обе стороны сразу. В обоих разборах это сработало – меры получились асимметричными, но обоснованными, и ни один из участников не был назначен единственным виноватым. С одной оговоркой. «Ей не важно, кто симпатичен» – правда про участников конфликта, но не про заказчика разбора. Модель систематически подстраивается под того, кто задает вопрос. Исследование. Towards Understanding Sycophancy in Language Models (Sharma et al., 2023). Пять современных ассистентов на четырех разных задачах стабильно подыгрывают взглядам собеседника; и люди, и модели-оценщики заметную долю времени предпочитают убедительный угодливый ответ правильному. Для нас это значит: разбор заказывал администратор, он же формулировал три вопроса – и модель могла подстроиться под его рамку, а не под лог. Лечится нейтральным промптом без оценок. И еще одно, менее очевидное. Модель разбирала не только участников, но и модерацию. В ночном логе она нашла реплику администратора «Вы уже оба ходили по этой дорожке. Не нужно туда сворачивать. Обоим» – и написала, что она сработала ровно на ноль: через минуту после нее одна из сторон потребовала мьют оппоненту, а склока пошла дальше. Замечание было сделано после первого оскорбления, без санкции и без явного правила. Такого пункта в самостоятельном разборе не появляется почти никогда – администратор не пишет отчет о том, что его вмешательство ничего не изменило. Что модель нашла лучше человека Три находки стоят того, чтобы их выписать отдельно от истории. Эпистемический триггер. Ветка сломалась не на оскорблении, а раньше – на рекомендации без доказательств. Совет дали, трижды попросили пруфы, получили «во всех, это же очевидно». Ровно в этой точке технический спор стал спором о статусе, и дальше все реплики читаются как борьба за право считаться компетентным. Оскорбление – симптом, случившийся три четверти часа позже. Причем маркер был объективный: нейтральный третий участник сказал об этом вслух, без просьбы и до эскалации. Модель заметила эту реплику и использовала как доказательство, что претензия не выдумана одной из сторон. Хороший ход – в конфликте свидетельство незаинтересованного участника стоит дороже любого анализа тона. Разделение формы и содержания. По существу правой в первом конфликте была та сторона, которая вела себя хуже: у нее была методика, 1 000 референсных фраз, носители языка и цифра 74%. Модель это зафиксировала и предложила формулу, которая и есть главный практический вывод обоих разборов: Наказывать форму и подтверждать содержание – это то, что оставляет человека в сообществе. Рамочный вопрос. И самый полезный артефакт – переформулировка самой задачи: Кто перевел разговор в состояние, где плохое поведение стало единственным доступным следующим ходом? Это лучше, чем «кто виноват», по инженерной причине. «Кто виноват» ищет человека, а этот вопрос ищет момент – и потому имеет проверяемый ответ и подсказывает, где в следующий раз вмешиваться. Вопрос переносится куда угодно: в постмортем инцидента, в разбор сорванного релиза, в разговор двух тимлидов о смежной зоне ответственности. Аудит: четыре ошибки, которые нашлись при сверке Претензия участника звучала так: В этот раз у тебя модель как-то перепутала все. Андрею приписало много из того что он не говорил. И следом: Это хороший пример, когда модель пишет много, убедительно, но шизу. Формулировка эмоциональная, но проверяемая. Мы прогнали оба разбора против базы сообщений. Нашлось четыре расхождения разного класса. Что написано в разборе Что в логе «За 17 августа 163 сообщения. Из них 77 и 77. То есть 94% дневного трафика сделали двое» Арифметика верная, но не про день. В окне 06:30–08:40 действительно 161 сообщение и 77 на 77. За сутки в чате 301 сообщение, и двое сделали 51% «Единственный участник с фактурой», доказательство – ссылка на репозиторий с разбором ошибок памяти Эту ссылку принес другой человек – ровно тот, о ком в том же абзаце написано «технического вклада почти нет» «Технического вклада почти нет» В логе у него четыре содержательных сообщения: тот самый репозиторий с бэкпортом тестов, новый trait resolver в nightly, переписанный openssl, цель Rust на 2026 год по ядру Linux «Около 35 сообщений по кругу» в одном разделе и «около 20 повторов» в другом Фактически 21. Один и тот же документ дважды посчитал одно и то же и разошелся сам с собой почти вдвое Обратите внимание на первую строку. Это не галлюцинация: числа 161 и 77 существуют, они посчитаны правильно. Сломалось предложение вокруг них – окно эпизода названо сутками. Самый убедительный факт в отчете и самый неверный вывод из него – это одно и то же место. У этой ошибки есть точное имя в литературе. Исследование. On Faithfulness and Factuality in Abstractive Summarization (Maynez, Narayan, Bohnet, McDonald; ACL 2020). Авторы разделили ошибки суммаризации на два класса: faithfulness – утверждение не подтверждается исходным текстом, и factuality – утверждение ложно о мире. И показали, что нейросуммаризаторы массово галлюцинируют именно первое. Для нас это значит: строка про 94% – классическая ошибка faithfulness. Числа настоящие, они в логе есть, но рамка «за день» источником не подтверждена. Это не «модель выдумала факт», а «модель неправильно оформила факт». И чинится это по-разному: фактчек чисел не поможет, нужна сверка рамок и знаменателей. И на вторую. Участник почувствовал, что его обокрали, но не смог доказать: он видел одну свою реплику в чужой колонке. Сверка показала, что он был прав сильнее, чем утверждал, – украденная ссылка была не деталью, а несущей конструкцией. На ней держался вывод «технического вклада почти нет», а на этом выводе – раскладка ролей «поджигатель и тушивший». Почему ошибки оказались не случайными Если бы модель ошибалась случайно, ошибки распределились бы равномерно: часть в пользу одной стороны, часть в пользу другой, часть нейтрально. Так не вышло. Все четыре расхождения в нашем случае работают в одну сторону – в сторону вывода, который отчет уже начал формулировать. Сразу оговорка: это один разбор и четыре ошибки. Утверждать, что так будет всегда, по одному кейсу нельзя – аудит начался с претензии пострадавшего, и расхождения в другую сторону с меньшей вероятностью вообще попали бы в таблицу. Но направленность здесь не выглядит случайной по механизму – и у этого механизма есть имя. Перепутанный знаменатель усиливает драматургию: «двое захватили день» звучит серьезнее, чем «двое сделали половину дня». Переехавшая ссылка усиливает контраст между тем, кто спорил по существу, и тем, кто раскачивал. Оценка «вклада почти нет» довершает портрет. Разошедшийся счет повторов делает флуд массивнее. У модели нет выгоды лгать. Дело в том, как устроена генерация связного текста: как только сюжет наметился, каждое следующее утверждение выбирается из тех, что сюжету не противоречат. Согласованность повествования дешевле проверки, и она побеждает. Это рабочая гипотеза, а не доказанный механизм – но она согласуется и с сикофантией выше, и с тем, что модель не сверяет написанное с источником без отдельной команды. Практический вывод для любого «модель, прочитай лог и скажи, кто виноват»: выборочная проверка случайных цитат почти ничего не дает. Проверять нужно ровно те факты, на которых держится приговор, – ошибки в таком отчете стоит ожидать смещенными в сторону его собственного вывода, а не разбросанными шумом. Так было в нашем разборе, и механизм выше объясняет почему. И вторая причина, техническая. Атрибуция в многопоточном чате – самая сложная часть входа: реплики чередуются, ответы приходят через десять сообщений, реплаи ссылаются назад, а в этом конкретном логе двух участников зовут почти одинаково. При этом атрибуция – самая несущая часть вывода: в разборе конфликта «кто это сказал» и есть весь смысл. Сложность и важность оказались инвертированы. Модель хуже всего делает именно то, что в этой задаче важнее всего. У длинного входа есть известная слабость. Исследование. Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2023). Модели неравномерно используют длинный контекст: лучше всего вспоминают начало и конец входа, заметно хуже – середину, даже в моделях, заявленных как длинноконтекстные. Применительно к нашему логу на 240 сообщений: середина – это ровно там, где две ветки переплетались, а ответы уходили через десять реплик. Ошибки атрибуции в таком месте ожидаемы, а не случайны. Ловушка «суть верна, детали неверны» Самый честный момент истории – ответ администратора на претензию: Да, я заметил расхождения в деталях вчера. Но суть все равно передана корректно, поэтому не стал переделывать. Для технического саммари это нормальная позиция. Пересказ архитектурного обсуждения с перепутанной фамилией остается полезным: выводы про архитектуру от этого не меняются. Для разбора конфликта – не работает, и вот почему. В таком тексте люди и есть содержание. Утверждение «его технического вклада почти нет» – это не деталь при верной сути, это и есть суть, вынесенная о человеке публично. Участник, у которого забрали его собственную реплику, спорит теперь не с оппонентом. Он спорит с отчетом администрации, опубликованным на сайте сообщества. И его позиция в этом споре хуже, чем была в исходном конфликте: там он отвечал за свои слова, а здесь – за чужие. Публикация меняет и цену ошибки. Пока разбор лежит в личных заметках, неверная атрибуция – это ваше личное заблуждение. После публикации она становится памятью сообщества, и любой новый человек прочитает ее как установленный факт. Кстати, у истории есть рекурсивная ирония, ради которой ее стоит помнить целиком. Первый конфликт вырос из вопроса «ты это тестировал или просто веришь?». Неделя закончилась публикацией разбора, который не был протестирован. Что с этим делать: протокол на шесть шагов Развязка – не в том, чтобы отказаться от модели, и не в том, чтобы поднять усилие рассуждения. Усилие, кстати, обсуждали: разбор делали на среднем, и на максимальном он был бы точнее. Но точнее – это не то же самое, что проверено. И это не скепсис на ровном месте. Исследование. Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., ICLR 2024). Модель не может надежно исправить собственный ответ без внешней обратной связи: «внутренняя самокоррекция» – перечитать и поправить себя без новых данных – часто не помогает, а иногда и ухудшает результат. Для нас это значит: максимальное усилие рассуждения не заменяет сверку. Атрибуционную ошибку модель сама не увидит – ее увидит только сверка с логом. «Точнее» и «проверено» – это разные вещи. Перед самими шагами – два правила, которые следуют из исследований выше. Первое: промпт должен быть нейтральным, без оценок и без рамки заказчика, иначе модель подстроится под него (сикофантия). Второе: перед публикацией прогоните разбор с переставленными ролями – если вывод меняется только от того, кто назван первым, это смещение, а не факт. Два прогона: дознание, потом приговор. Первый только извлекает факты: реплика, автор, идентификатор сообщения, время. Никаких оценок. Второй судит – но уже по извлеченной таблице, а не по сырому логу. Тогда ошибка атрибуции ловится до того, как обрастет выводами. Исследование. Chain-of-Verification Reduces Hallucination in Large Language Models (Dhuliawala et al., 2023). Модель пишет черновик, затем отдельно планирует проверочные вопросы и отвечает на них независимо от черновика – чтобы не подыгрывать себе, – и только потом собирает финальный текст; галлюцинаций становится меньше. Для нас это значит: дознание и приговор должны быть разными прогонами именно потому, что проверка, сделанная поверх готового вывода, ему подыгрывает. Близкая идея – Decomposed Prompting (Khot et al., ICLR 2023): сложную задачу разбивают на подзадачи с отдельными промптами, и каждая решается лучше, чем одна монолитная. Извлечение фактов и оценка – ровно такие разные подзадачи. Идентификатор на каждую цитату. Утверждение без ссылки на конкретное сообщение в отчет не попадает. И проверяйте идентификатор кодом, а не глазами: сообщение существует, текст реплики совпадает с цитатой. Это дешевле любой сверки: непроверяемые фразы просто не рождаются, а выдуманные – не проходят. Исследование. Enabling Large Language Models to Generate Text with Citations (Gao, Yen, Yu, Chen; EMNLP 2023). Первый крупный бенчмарк генерации с цитатами (ALCE): даже лучшие модели до половины времени дают ответ без полной поддержки цитатами. То есть «идентификатор на каждую цитату» – это защита, а не бюрократия. Без привязки к сообщению модель легко приписывает реплику не тому – и может выдать несуществующий идентификатор, поэтому проверяет его код. Агрегаты – из базы, не из модели. Сколько сообщений, у кого, в каком окне – это SQL, а не модель. И называйте окно в самом отчете: «06:30–08:40», а не «за день». Половина спора о цифрах – это спор о знаменателе. Исследование. Tokenization counts: the impact of tokenization on arithmetic in frontier LLMs (Singh, Strouse; 2024). Числовые рассуждения модели зависят от того, как числа разбиты на токены; ошибки при этом систематические, а не «примерные». Для нас это значит: считать сообщения, доли и окна должна база данных, а не модель. Цифры в отчете – из SQL, модель их только пересказывает. Проверка несущих фактов. Спросите себя: если убрать это утверждение, вывод изменится? Если да – сверяйте вручную. Проверить три несущие цитаты полезнее, чем двадцать случайных. Исследование. FActScore: Fine-grained Atomic Evaluation of Factual Precision (Min et al., EMNLP 2023). Текст разбивают на атомарные факты и считают долю подтвержденных надежным источником; так, ChatGPT в биографиях фактуален лишь на 58%. Для нас это значит: разбор надо раскладывать на атомы и проверять те, на которых держится вывод, – это и есть «несущие факты». Дешевле полной сверки, полезнее случайной. Черновик – участникам до публикации. Ровно те люди, о которых написано, найдут ошибку атрибуции за минуту и бесплатно. Именно так она и нашлась здесь – только после публикации. Оговорка: участники – заинтересованные лица и оспорят не только неверное, но и неудобное. Такой просмотр ловит фактические ошибки, но не заменяет решения о выводах. Роль модели – дознаватель, не судья. Механизм – ее сильная сторона: как спор стал статусным, где точка невозврата, почему замечание не сработало. Оценки людей и меры оставьте себе: это ответственность, которую нельзя делегировать тексту. Исследование. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., NeurIPS 2023). Модели-судьи соглашаются с людьми примерно в 80% случаев – на уровне человеческого согласия, – но имеют систематические смещения: позиция (кто отвечал первым), многословность (длиннее кажется лучше), предпочтение собственных ответов. То есть «модель рассудила» – не нейтральный вердикт. Механизм модель опишет хорошо, а взвешивать людей и назначать меры должен человек. Отдельный пункт про сам разбор, вне зависимости от того, кто его делает. Оба отчета сходятся в одном: одного «не сворачивайте туда» недостаточно. В первом конфликте так и написали, во втором это повторилось с теми же людьми. Работает не общее пожелание, а адресное правило плюс явная санкция: одному – не входить в чужую ветку с оценкой оппонента вместо оценки темы, другому – тезис до допроса. Где это выстрелит еще Модерация чата – редкая задача. А вот класс задач – частый, и он у вас точно есть. Таблица ниже – гипотеза, перенос одного кейса на соседние задачи, а не измеренные риски. Но класс поломок в ней один и тот же: атрибуция. Задача Что модель делает хорошо Где сломается Постмортем инцидента по логам и переписке Восстановить последовательность, найти момент, где нормальный ход стал невозможен «Кто принял решение» и «кто предупреждал» – та же атрибуция, та же цена ошибки Саммари долгого код-ревью или обсуждения в RFC Свести позиции, вытащить нерешенное столкновение определений Приписать аргумент не тому автору и на этом построить вывод «команда согласилась» Подготовка перф-ревью по трекеру и чатам Собрать объем работы, заметить незамеченный вклад Оценочные суждения о человеке, собранные из активности, а не из результата Разбор жалобы сотрудника Хронология, симметрия претензий, что не сработало в процессе Все, где надо сказать, кто прав Общее правило простое. Чем ближе задача к описанию механизма, тем надежнее модель. Чем ближе к суждению о человеке, тем дороже каждая непроверенная строка – и тем меньше стоит формула «суть верна, детали неверны». Ночной эпизод, кстати, сгорел на нерешенном столкновении определений: больше получаса стороны спорили о связи двух терминов, ни разу не остановившись, чтобы их зафиксировать. Один из них даже предложил синхронизировать определения – и тут же убил свое предложение подколкой. Модель это увидела и описала точно. Такое она умеет. А кто что сказал – проверяйте сами. Особенно если собираетесь это опубликовать. Что из этого следует для Падавана У сообщества уже есть бот – Падаван: анонимные вопросы, пасты, поиск по архиву. Он админ в чате и видит каждое сообщение. Протокол читается как ТЗ на его новую роль, и роль эта – дознаватель. Первое и главное: атрибуцию должен отдавать пайплайн, а не модель. Все четыре ошибки разбора выросли из того, что модель восстанавливала «кто это сказал» по логу. У бота другая ситуация: каждое сообщение приходит с отправителем от самого Телеграма. Записать его в буфер – реплика, автор, идентификатор, время – это учет, а не анализ: атрибуция берется из метаданных, а не реконструируется. Самая сложная часть входа уходит из модели до того, как модель что-то прочитала. Модель при этом не читает поток: разбирать каждое сообщение – дорого. Работает порог. Падаван считает темп запросом к буферу – сколько сообщений за окно дали одни и те же участники, – и пока темп обычный, не происходит ничего. Порог пройден – появляется эпизод: окно сообщений, и вот его модель разбирает целиком. Триггер считается в базе, по правилу протокола: числа – из SQL, без модели. Что модель ищет внутри эпизода – подсказывают сами разборы: эпистемический триггер: тезис, за которым попросили пруфы и получили «это же очевидно»; переплетенные ветки, где ответ прилетает через десять реплик; первое оскорбление – точка, после которой форма сломана; реплика нейтрального третьего – по обоим разборам самое дорогое свидетельство. Алерты идут только в админский чат. Ни в общий, ни «ради прозрачности»: опубликованная ошибка атрибуции становится памятью сообщества, и один раз так уже было. Карточка собирается по протоколу: каждая цитата со ссылкой на сообщение, окно названо явно – «06:30–08:40», а не «за день», – точка невозврата помечена как кандидат, а не как факт. Реакции – три уровня, и выше первого бот без команды не идет: Маркеры копятся молча. Это данные, а не событие. Порог пройден – модель разбирает эпизод, и в админском чате появляется карточка с таймлайном. Админ решает, был конфликт или показалось. Действие только по кнопке: адресное напоминание правила, черновик мьюта, запрос разбора. Автоматических санкций нет: мьют – оценка человека, а оценки остаются у людей. Команда /razbor – тот же протокол одним действием: два прогона, нейтральный промпт, черновик в админском чате, публикация только после сверки и только кнопкой человека. Здесь есть техническая деталь: бот не умеет читать историю чата задним числом, он видит только то, что приходит при нем. Так что буфер сообщений – не опция, а условие: последние несколько дней живут в базе, и /razbor работает внутри этого окна. И то, что у бота получается без самообмана: мерить саму модерацию. Общее «не сворачивайте туда» в обоих разборах не изменило ничего. Падаван считает темп до вмешательства и после – и у админа появляется обратная связь, сработало замечание или нет. Отдельный вопрос – приватность. Падаван обещает хранить минимум, и буфер это обещание меняет: текст сообщений появляется в базе, пусть и на несколько дней. Минимальная версия такая: буфер скользящий, старые сообщения удаляются, в алертах остаются идентификаторы и ссылки – сами реплики живут в чате, а не у бота. Делать ли буфер постоянным – другой вопрос, и решать его стоит с сообществом. Чего Падаван не делает никогда: не публикует разборы сам, не называет виноватых в общем чате, не мьютит без кнопки и не выдает «кто начал» без ссылок на сообщения. Модель собирает механизм конфликта, решения по людям остаются за админом. Вы бы отдали модели разбор конфликта в своей команде – и на каком шаге у вас стоит проверка, прежде чем ее вывод станет чьей-то характеристикой? Теги: ии, модерация, конфликты, постмортем, тимлид, Казахстан, падаван ## Покрытие 92%, а баг в проде: как проверить сами тесты URL: https://teamleads.kz/articles/pokrytie-testami-vret-mutatsionnoe-testirovanie/ Дата: 2026-08-18 Кейс с округлением в Кувейте: почти полное покрытие, а логику не проверял никто. Что такое мутационное тестирование и как встроить его в процесс без боли. Автор: Сообщество «Тимлид не кодит» Баг был скучный до неприличия. Сервис считал процент от суммы заказа. Для Казахстана результат округлялся до двух знаков после запятой: 5,73637748 превращалось в 5,74. Для Кувейта нужно три знака – 5,736. Разница в тысячные доли. Умножьте эту разницу на 300 000 заказов в день. Один из участников сообщества пошел разбираться и открыл класс, который отвечал за округление. Класс был покрыт тестами почти полностью и в команде считался пуленепробиваемым. Он прочитал все тесты глазами. Половина из них проверяла, что поле пришло. Не логику. Не граничные значения. Не количество знаков. Просто наличие данных. Из интереса он открыл соседний класс. Там то же самое: почти сплошной Assert.NotNull. Общее покрытие проекта при этом составляло 92%. Что на самом деле измеряет покрытие Покрытие тестами – метрика исполнения. Она отвечает ровно на один вопрос: была ли эта строка выполнена хотя бы раз, пока крутились тесты. Все. На вопрос, который вас интересует на самом деле, она не отвечает. А интересует вас другое: заметит ли тест, если эта строка сломается. Разница между двумя вопросами кажется схоластической ровно до первого инцидента. Тест вызывает метод расчета и проверяет, что результат не null. Он честно прогоняет через себя все ветвления внутри. Покрытие растет. Отчет зеленеет. Поменяйте внутри плюс на минус – тест как проходил, так и проходит. Получается метрика, которая измеряет активность инструмента, а не его чувствительность. Примерно как оценивать пожарную сигнализацию по тому, что через нее прошел воздух. Отдельная ирония в том, что покрытие – одна из немногих метрик качества, которую легко автоматизировать и вывести на дашборд. Поэтому именно она обычно и попадает в квартальные цели. Дальше срабатывает закон Гудхарта: показатель, ставший целью, перестает быть хорошим показателем. Команда дописывает тесты до нужного процента самым дешевым доступным способом. Самый дешевый способ – проверить, что что-то вернулось. Тест для тестов Автор кейса сформулировал задачу непривычно: а можно ли протестировать сами тесты? Можно. Практика называется мутационное тестирование, и ей примерно столько же лет, сколько юнит-тестам: первые работы вышли в конце 1970-х. Массово ее не используют по банальной причине – она дорого стоит по времени. Идея при этом умещается в одно предложение. Инструмент берет ваш рабочий код и намеренно его ломает. Меняет плюс на минус. Меняет > на >=. Инвертирует условие. Выкидывает вызов метода. Заменяет возвращаемое значение на пустое. Каждая такая порча называется мутацией: отдельная сборка проекта с одним внесенным дефектом. Дальше на каждой испорченной сборке прогоняются ваши тесты. Если хоть один тест упал, мутация убита. Тесты заметили дефект, все хорошо. Если все тесты прошли, мутация выжила. Вы внесли в код настоящую ошибку, а набор тестов этого не заметил. Выжившая мутация – не гипотеза и не запах. Это конкретная строка кода, которую можно сломать, и ваша сборка останется зеленой. Когда автор кейса запустил инструмент локально, экран был красный. Мутации выживали даже там, где удалялись целые условия и ветки switch. При 92% покрытия. Если тест успешно прошел, то мутация выжила, а это значит, что тест неточный. Инструментов хватает почти под любой стек: Stryker для JavaScript, C# и Scala, PIT для Java, mutmut и cosmic-ray для Python, go-mutesting для Go. Все они работают по одной схеме и дают одну итоговую цифру – mutation score, долю убитых мутаций. В отличие от покрытия, эта цифра говорит о качестве тестов, а не об их наличии. Почему это не живет в CI Первая реакция инженера, который услышал про мутационное тестирование, всегда одинаковая. Отлично, добавим в пайплайн, пусть гоняется на каждом пулреквесте. В обсуждении это возражение прозвучало сразу: чем оно принципиально отличается от любого статического анализа в CI. Ответ автора кейса был коротким. В CI это дорого и долго. Арифметика простая. Мутационный прогон – это не один прогон тестов, а по одному прогону на каждую мутацию. Инструменты умеют отсекать лишнее: гонять только те тесты, которые покрывают измененную строку, распараллеливать, работать по инкременту от последнего коммита. Но даже с оптимизациями на среднем сервисе речь идет о часах, а не о минутах. Поэтому в кейсе выбрали другую частоту. Схема получилась такая: В Kubernetes стоит cron job, которая раз в месяц поднимает отдельный контейнер: 4 vCPU, 8 ГБ памяти. В контейнере запускается Stryker. Прогон занимает 2–3 часа. Отчет автоматически падает в канал в Slack. Команда смотрит на выжившие мутации и оценивает их. То, что признано значимым, уходит в бэклог как обычные задачи. Ключевое здесь – пункт четыре. Отчет не блокирует релиз и не заводит задачи сам. Он приносит список мест, где тесты слепые, а решение принимают люди. Такая асимметрия вообще характерна для дорогих проверок. Быстрые и дешевые сигналы (линтер, компилятор, юнит-тесты) имеет смысл ставить блокирующим гейтом. Медленные и глубокие (мутационное тестирование, фаззинг, полный прогон нагрузочных) работают как регулярная ревизия. Первые не пускают в мастер, вторые формируют бэклог. Попытка превратить вторых в первых обычно заканчивается тем, что пайплайн отключают целиком. Чего мутационное тестирование не сделает Практика полезная, но у нее есть честные ограничения. Лучше узнать о них до внедрения, а не после. Эквивалентные мутации. Часть внесенных дефектов не меняет поведение программы вообще. Классика: замена > на >= в цикле, который в реальности никогда не доходит до границы. Такая мутация выживет всегда, и никакой тест ее не убьет, потому что убивать нечего. В отчете это шум, который приходится отсеивать глазами. Доля эквивалентных мутаций – главная причина, по которой mutation score никогда не стоит гнать к 100%. Стоимость времени. Часы прогона – нормально для месячной ревизии и невыносимо для обратной связи разработчику. Мутационное тестирование не заменяет TDD и вообще не про скорость цикла. Только то, что покрыто. Инструмент ломает строки и смотрит на тесты. Если у куска кода тестов нет совсем, мутация в нем выживет, но это вы и так знали из отчета о покрытии. Ценность появляется именно там, где покрытие уже высокое и создает ложное ощущение безопасности. Только юнит-уровень. Ошибка с Кувейтом – про конфигурацию страны и бизнес-правило, и поймана она была бы на уровне класса. Интеграционные проблемы, гонки, неверные предположения о внешнем API мутационный прогон не увидит. Насколько можно судить по одному внедрению, это не серебряная пуля, а конкретный инструмент для конкретного вопроса: врут ли мои юнит-тесты. На этот вопрос он отвечает лучше остальных. Отдельная причина заняться этим прямо сейчас Есть контекст, из-за которого тема из академической стала практической. Тесты все чаще пишет не человек. Разработчик просит агента покрыть класс тестами, агент покрывает, покрытие растет, пулреквест выглядит убедительно. Проблема в том, что модель оптимизирует ровно то, что вы попросили: наличие тестов и зеленый прогон. Самый надежный способ получить зеленый прогон – проверять слабые утверждения. В том же обсуждении участник разбирал ситуацию буквально этими словами: половина тестов сгенерирована по принципу «это поле точно пришло», а логику не тестировал никто. Фразу сегодня можно услышать про добрую половину новых репозиториев. Дальше видна вилка. Если вы отказываетесь от построчного чтения сгенерированного кода (а к этому идет все больше команд), то приемкой становятся тесты. Но если тесты пишет тот же агент, что и код, то приемка проверяет сама себя. Нужен внешний арбитр, который не зависит от намерений автора. Мутационное тестирование на эту роль подходит буквально. Оно не читает тесты и не оценивает их стиль, оно ломает код и смотрит на реакцию. Инструменту все равно, что сгенерировало тест: человек, агент или генератор шаблонов. Проверяется поведение, а не происхождение. Что можно сделать за один вечер Возьмите самый ответственный класс в системе – расчеты, тарификация, права доступа, статусы заказа. Не весь проект, один класс. Посмотрите его тесты глазами и посчитайте долю утверждений вида «не пусто», «не null», «статус 200». Поставьте мутационный инструмент под свой стек и запустите его локально по этому одному классу. Разберите первые десять выживших мутаций. Отделите эквивалентные от настоящих дыр. Если настоящих дыр больше трех – заведите регулярный прогон по расписанию, а не в CI. Раз в месяц достаточно, чтобы видеть тренд. Отчет отправляйте в канал команды, а не лично себе. Смысл в том, чтобы выжившая мутация была видна автору теста. В определение готовности добавьте не процент покрытия, а формулировку: критичная логика не должна переживать удаление своего условия. Отдельно стоит договориться, что mutation score не становится KPI. Иначе через квартал вы получите те же игры с цифрой, только на уровень глубже. Что с этим делать тимлиду Самая неприятная часть истории – не баг с округлением. Неприятная часть в том, что команда год жила с ощущением, что этот кусок системы защищен. Ощущение было основано на цифре, которая ничего про защиту не говорила. Метрики качества имеют свойство превращаться в декорацию именно тогда, когда их удобно измерять. Покрытие удобно измерять. Количество тестов удобно измерять. Процент зеленых прогонов удобно измерять. Все три растут, когда команда пишет слабые тесты, и не падают, когда система становится хрупче. Мутационное тестирование неудобно: медленное, шумное, требует разбора руками. Зато оно отвечает на вопрос, который вы на самом деле задаете, когда смотрите на дашборд. Если завтра что-то сломается, узнаю ли я об этом до клиента. Какой процент ваших тестов переживет удаление ближайшей ифки – и хотите ли вы узнать ответ до того, как его узнает Кувейт? Статья выросла из обсуждения в сообществе «Тимлид не кодит». Контекст – в инсайтах за 10–16 августа. Присоединяйтесь к обсуждению в Telegram. Теги: тестирование, качество кода, CI/CD, тимлид, Казахстан ## Как проверить, что модель работает хорошо: эвалы против метрик модели URL: https://teamleads.kz/articles/kak-proverit-kachestvo-raboty-modeli/ Дата: 2026-08-18 Спор о том, чем доказывать качество ИИ: прогоном на реальных задачах или perplexity. Как собрать свой эвал-набор и когда вендорские бенчмарки бесполезны. Автор: Сообщество «Тимлид не кодит» Разговор начался с обычной рекомендации. Один из участников посоветовал маленькую модель для перевода текстов: быстро, эффективно, целые книги переводятся за пару секунд. Ему задали вопрос, который выглядит невинно ровно до тех пор, пока на него не нужно отвечать. В каких языковых парах она лучше специализированной модели для перевода? Ответ был: во всех, это же очевидно, сравни словарь. Дальше спор шел несколько часов и закончился плохо. Но внутри него лежал вопрос, который стоит любых часов. Не «какая модель лучше». А чем вообще доказывается, что модель делает работу хорошо. Два способа доказать, и оба не бесплатные Столкнулись две школы. И это не спор дилетанта с профессионалом, это спор о том, что считать доказательством. Первая школа меряет результат. Один из участников описал свою процедуру. Взял носителей языка, набрал 1 000 референсных фраз, дал людям перевести их с учетом максимального контекста. Получился эталон. Потом прогнал через маленькие модели те же фразы и сравнил. Специализированная 4B-модель для переводов дала около 74% приемлемых переводов без всякого тюнинга и оказалась лучше всех моделей размером до 9B. Дальше он два месяца собирал в работе кривые переводы, набралось около 200 случаев, и на них тюнил промпт и модель. Вторая школа меряет саму модель. Другой участник возражал, что оценка «вот это качественно, а вот это нет» субъективна по построению, и предлагал смотреть внутрь. На perplexity – меру того, насколько сильно модель сомневалась при выборе следующего токена. Если модель выбирала не из пяти-шести вариантов, а из тысячи, значит в этом месте латентного пространства у нее пробел или аномалия. Число объективное, считается автоматически, человек не нужен. И добавлял сильный аргумент про масштаб. Пока у вас 500 проблемных кусков, вы разберете их руками. Когда их 500 000, ручной разбор невозможен физически. Почему обе стороны правы про разное Спор не разрешался несколько часов по простой причине: участники измеряли разные вещи и оба называли это качеством. Perplexity – метрика уверенности, а не правильности. Модель может быть уверенно неправа. Если в обучающих данных ошибка встречалась чаще правильного варианта, модель выдаст ее с низкой perplexity. И наоборот: высокая perplexity часто означает не ошибку, а законную многовариантность. У фразы есть три хороших перевода, и модель честно колеблется между ними. Отсюда практический вывод, который стоит выписать отдельно. Сигналы модели – отличный маршрутизатор и плохой судья. Perplexity, логарифмические вероятности токенов, расхождение между несколькими прогонами – все это прекрасно отвечает на вопрос «куда смотреть в первую очередь». Отсортируйте 500 000 фрагментов по уверенности модели, возьмите верхние два процента, и вы получите выборку, где концентрация проблем в разы выше случайной. Ровно ради этого аргумент про масштаб и приводился. И он верный. Но ответить на вопрос «правильно ли это переведено» такая метрика не может в принципе. Она не видела правильного ответа. Прогон на реальных задачах – единственный судья и дорогой инструмент. Размеченный людьми эталон – единственное место, где вообще появляется понятие «верно». Плата за это – деньги, время и потолок по объему. Отсюда честная сборка обоих подходов. Сигналы модели просеивают объем, люди выносят приговор на выборке. Не «или», а «сначала одно, потом другое». Кстати, во время спора прозвучало наблюдение, с которым стоит согласиться, хотя произнесено оно было как укол. У обоих методов одна и та же болячка. И набор референсных фраз, и порог по perplexity выбирает человек, исходя из своих представлений о задаче. Полностью объективной оценки не существует ни там, ни там. Вопрос только в том, зафиксированы ли ваши представления явно или живут в голове. «Это же субъективно» – и что с этим делать Прозвучал еще один правильный вопрос: а если тот же перевод другому носителю языка покажется некорректным? Так и будет. Но это не отменяет измерение, а задает ему погрешность. Индустрия разметки живет с этой проблемой полвека и умеет ее ограничивать. Несколько оценщиков на один кейс. Два человека уже дают возможность увидеть расхождения, три – разрешать их большинством. Согласованность как отдельная метрика. Если ваши оценщики расходятся на 40% случаев, проблема не в модели, а в инструкции для оценки. Попарное сравнение вместо абсолютной оценки. Человеку тяжело поставить «7 из 10», но легко ответить, какой из двух вариантов лучше. Отсюда же растут все арены, где модели сравниваются вслепую. Правила вместо вкуса. Инструкция «перевод считается верным, если сохранены смысл, регистр речи и терминология» дает совсем другую согласованность, чем «оцените качество». Самый прагматичный якорь прозвучал в самом споре: правильный перевод – тот, за который платят деньги. Звучит цинично, зато операционально. У вашей системы есть заказчик, и его критерий приемки и есть определение качества. Если оценщики не сходятся, обычно это значит, что критерий приемки не сформулирован. И спорить надо не про модель. Чужие бенчмарки: почему они бесполезны и почему их отсутствие важно Параллельно на той же неделе в чате шел второй спор – про публичные бенчмарки вендоров. Он про то же самое, только на уровень выше. Аргумент против: бенчмарк меряет решение чужих задач и оценку чужих результатов. Что вам дает число, полученное на наборе, который вы не выбирали и не увидите в своей работе? Плюс даже один и тот же бенчмарк в отчетах разных вендоров показывает разные цифры на одних и тех же моделях. Аргумент за прозвучал неожиданно сильно. Он не про истину, а про обязанности продавца. Если вендор хочет внимания, бороться за пользователя должен он, а не пользователь – тратить свои деньги на проверку чужих обещаний. Аналогия из обзоров ноутбуков: зрителю неважно, что именно за тяжелый проект открывают в среде разработки и сколько там классов. Важно, что задача одна и та же для всех устройств, и цифры можно сравнить между собой. Получается вот такая рабочая позиция: Что Что оно вам дает Публичные бенчмарки Фильтр на входе: стоит ли тратить неделю на собственную проверку Отсутствие любых цифр у вендора Сигнал о вендоре, а не о модели Свой эвал-набор Единственное основание для решения о переходе Отдельный сюжет – цена ошибки. Один из участников рассказал, как купил годовую подписку на модель, которая в его работе оказалась бесполезной. Годовая подписка – ровно та ставка, которую эвал-набор на два вечера превращает в рутинную проверку. Как собрать эвал-набор, который окупится Хорошая новость: чтобы начать, не нужны платформы, разметочные команды и бюджет. Нужен один текстовый файл. Соберите 30–100 реальных случаев. Не придуманных, а тех, где система уже ошибалась. В кейсе с переводами за два месяца работы набралось около 200 – нормальная скорость накопления. Зафиксируйте эталонный ответ. Тот, который вы готовы показать заказчику. Там, где эталон один не бывает, зафиксируйте критерий приемки словами. Заморозьте условия прогона. Версия модели, промпт, температура, контекст. Меняя две вещи сразу, вы не узнаете, какая из них помогла. Считайте не одну цифру, а разбивку. Доля приемлемых ответов плюс типы ошибок: термин, смысл, формат, галлюцинация. Одна цифра скажет, что стало хуже, разбивка – что чинить. Добавьте автоматического судью, но откалибруйте его. Модель-оценщик экономит часы, но сначала сравните ее вердикты с человеческими на 50 случаях. Если совпадение ниже 80%, судью надо чинить, а не пользоваться им. Прогоняйте при каждой смене чего угодно: модели, версии, промпта, тюнинга. Это и есть та рутина, ради которой все затевалось. Отдельно ведите список случаев, где модель была уверена и неправа. Самая дорогая категория ошибок: их не поймает ни один порог по вероятностям. Стоимость такого набора – один вечер и потом полчаса в неделю на пополнение. Стоимость его отсутствия – решения о технологическом стеке, принятые по фразе «ну у меня работает». Что делать, когда эталона нет вовсе Отдельный класс задач – те, где правильного ответа не существует даже в теории. Саммари встречи, ответ поддержки, черновик письма. Здесь нет тысячи референсных фраз, потому что нет референса. Не повод отказаться от измерения. Просто судья меняется. Отрицательные критерии вместо положительных. Сформулировать, что такое хороший ответ, невозможно. А что такое неприемлемый – вполне: выдуманный факт, потерянное решение встречи, обещание от лица компании, переход на другой язык. Считайте долю прогонов, где сработал хоть один запрет. Это оценка не качества, а риска – и для продакшена она важнее. Сравнение вместо оценки. Старый вариант против нового, вслепую, на одних и тех же входах. Человеку не нужно знать, каким должен быть идеальный ответ, чтобы уверенно сказать, какой из двух он отправил бы клиенту. Поведение пользователей как метрика. Доля правок после генерации, доля отказов от предложенного варианта, повторные обращения в поддержку по тому же вопросу. Сигнал шумный и запаздывающий, зато его не надо размечать. Он приходит сам. И общее правило: чем размытее задача, тем важнее фиксировать не оценку, а границы. Полностью субъективное качество измерить нельзя. А вот заметить, что после смены модели количество выдуманных фактов выросло вдвое, вполне можно. Вопрос, который стоит задавать себе В том споре была одна реплика, ради которой его стоит помнить. На рекомендацию модели прозвучало: ты это тестировал или просто веришь? Вопрос неприятный, потому что честный ответ у всех нас чаще второй. Мы рекомендуем инструменты, которые понравились. Мы переходим на модель, потому что она новее. Мы считаем свою конфигурацию промптов лучшей, потому что собирали ее сами. Разница между инженерной позицией и верой не в уверенности, а в наличии процедуры, которая может показать, что вы неправы. У первой школы такая процедура была: 1 000 фраз, носители языка, число 74%. У второй тоже: perplexity, аномалии, распределения. Спор оказался бы полезным для обеих сторон, если бы вопрос звучал не «кто прав», а «что именно померил каждый из нас». А чем вы докажете, что модель, на которой стоит ваш продакшен, работает лучше соседней – кроме ощущения, что она хорошая? Статья выросла из обсуждений в сообществе «Тимлид не кодит». Контекст – в инсайтах за 10–16 августа и за 13–19 июля. Присоединяйтесь к обсуждению в Telegram. Теги: ии, эвалы, качество, тимлид, Казахстан ## Системный дизайн вслух: аналитика для антифрода без единой базы данных (часть 1) URL: https://teamleads.kz/articles/sistemnyy-dizayn-antifrod-bez-bazy-dannyh-chast-1/ Дата: 2026-07-06 Прохожу секцию system design вслух: как спроектировать хранилище для антифрода без Postgres, S3 и Redis – только диски и виртуалки. Часть 1: путь записи, шардирование по дате, кворум из трех реплик и стена из inode. Автор: Станислав Беляев Я записал, как прохожу секцию system design из головы, не подглядывая в шпаргалки и не рисуя заранее. Просто задача, таймер и рассуждения вслух. Ниже – расшифровка того, к чему я пришел в первой половине. Это ровно тот момент проектирования, когда самое интересное только начинается: мы упираемся в то, как физически хранить файлы, понимаем, что без индекса дальше не проехать, и на этом первая запись обрывается. Индекс и путь чтения – во второй части. Условие Нужно спроектировать кусочек аналитической системы для отлова фрода по заказам. API минимальный: insertOrder(order: Order): void getLongestNOrdersByDuration(n: int, startTime: datetime, endTime: datetime): Order[] getShortestNOrdersByDuration(n: int, startTime: datetime, endTime: datetime): Order[] Order – это блоб на 1–10 КБ с тремя выделенными полями: orderId, beginTime, finishTime. Два метода чтения возвращают n самых длинных или самых коротких заказов по длительности (finishTime − beginTime), среди тех, что стартовали в заданном окне времени. В этой первой части я разбираю путь записи и раскладку данных по машинам. Методы чтения и то, как под них устроен индекс, оставляю на потом – к концу расшифровки я как раз до них дохожу и упираюсь в необходимость индекса. Ограничение, ради которого задача интересна Начну не с методов, а с ограничения, потому что именно оно задает всю форму решения. Нельзя использовать ни одну внешнюю систему. Ни MySQL, ни Postgres, ни ClickHouse, ни Redis, ни S3. В распоряжении только машины в облаке – диски, память, процессор. Все хранилище надо построить руками. Первое, что хочется сделать с таким ограничением – мысленно его обойти. Ну поставим Postgres, ну прикрутим S3, задача решается за вечер. Но ограничение осмысленное, и держится оно на двух вещах. Стоимость. Если система по функциональности небогатая, а именно такая нам и досталась, то сделать все на голых дисках и виртуалках выходит очень дешево. Managed-база или объектное хранилище – это отдельная статья расходов, которая для нашего скромного набора операций не окупается. Операционная нагрузка. Когда я строю хранилище сам, мне нужно знать ровно одну вещь – как у меня разложены данные по дискам. Диски и виртуалки, с которыми я работаю, и все. Как только сверху появляется чужая система, мне нужно знать еще и как ее обслуживать: как она ведет себя под нагрузкой, что делает на пиках, как ее чинить, когда она встанет. Она даст больше возможностей, но этих возможностей задача не требует. Так что такой запрет реалистичен ровно там, где ресурсы – и по хранению, и по людям, которые все это сопровождают – жестко ограничены. Отдельно проговорю природу системы. Это аналитика, а не real time. Значит на чтении нет SLA по времени отклика: задача в том, чтобы данные отдать, а не отдать их за 50 миллисекунд. Это развязывает руки на пути чтения и позволяет платить временем там, где иначе пришлось бы платить железом. Исходный набросок: процессор над шардами Прежде чем рассуждать строго, я накидал на доске первый, наивный набросок – чтобы было от чего отталкиваться и что потом перекраивать. Сверху процессор (позже он у меня распадется на приемный слой и роутер), под ним шарды от первого до N-го: процессор разводит запись и сводит чтение. flowchart TD Proc[Processor] Proc --> Sh1[Sh1] Proc --> ShDots[...] Proc --> ShN[ShN]Первый ключ шардирования у меня был лобовой – ShardKey = UnixTimeStamp % 360, раскидать заказы примерно по 360 шардам, по одному на день года. Ниже я его разберу и заменю: остаток размазывает соседние даты по разным шардам, а мне нужно ровно обратное – чтобы запрос за период попадал в несколько соседних шардов, а не во все сразу. Заказ на доске я разложил так: ID – 20 символов, Guid; Date – UnixTimeStamp начала; Length – int, длительность, которую я считаю заранее и кладу в метаданные, а не пересчитываю на чтении; Path – до 2000 символов, путь к блобу, JSON или байт-строка; Decoder – декодер тела. Путь чтения (getN) я на доске тоже набросал, но его честно откладываю на вторую часть – он весь про индекс, а до индекса нам еще надо дойти. Значит, система распределенная Из ограничения и из требования надежности сразу следует форма. Аналитическая система с постоянным потоком записи должна работать условно 99,9% времени. Одна машина – это одна точка отказа: диск умер, и мы потеряли и данные, и доступность. Значит система обязана быть распределенной. Больше одного сервера, больше одной ноды. Это ограничение всплывает еще до того, как я начал что-либо рисовать, прямо из целевой доступности. И, скорее всего, размазанная по регионам Раз мы уже говорим о распределенности ради надежности, стоит дотянуть эту мысль до географии. Держать всю сотню машин в одном дата-центре – значит снова собрать точку отказа, только крупнее: пожар, сеть, питание в одной зоне кладут систему целиком. Поэтому реплики хочется разносить по нескольким регионам. Не буду переоценивать этот ход, у него есть цена. Тянуть согласование записи между регионами дорого по задержкам, и для строгой консистентности это был бы плохой размен. Но у нас аналитика без SLA на отклик, поток однонаправленный, и это ровно тот случай, когда географическое разнесение оправдано: durability и доступность – потеря целого региона не уносит данные и не роняет прием; disaster tolerance – система переживает отказ уровня зоны, а не только уровня машины; прием ближе к источнику – заказы можно принимать в регионе, где они возникают, а тяжелую раскладку и синхронизацию доигрывать асинхронно. У этого удобства есть цена – кворум между регионами, к этой развилке я вернусь в открытых вопросах. То есть многорегиональность здесь – не про скорость чтения, а про то же требование надежности, просто доведенное до его логического конца. За это мы платим сложностью синхронизации между регионами, и с этой ценой соглашаемся осознанно. Прикидка на салфетке Теперь, когда понятно, что машин будет много и стоят они в разных местах, посчитаем, сколько именно. Объем – это то, что диктует количество железа. 10 млн файлов заказов в сутки. Размер файла берем по максимуму – 10 КБ. Пик записи – около 1000 операций в секунду. Считаем хранение за год. 10 млн файлов в день по 10 КБ дает порядка 35 ТБ сырых данных за год. Мы заранее знаем, что будем реплицировать в три копии, поэтому закладываем порядка 100 ТБ дискового пространства. Если брать по 1 ТБ диска на машину, выходит около 100 машин, чтобы хранить все это добро. Диски побольше – машин поменьше, тут прямая арифметика. Вот откуда берется сотня нод, которую мы дальше будем раскладывать по шардам и регионам. Путь записи: принять быстро, обработать потом Мы работаем в одну сторону – данные только пишутся, поэтому сам прием можно сделать простым и быстрым. Но здесь важная поправка, которую я сначала проговорил неаккуратно. Для системы, где данные терять нельзя, «принято» не может означать «подержал в памяти и сразу ответил». Пока заказ не закреплен на нескольких машинах, он не принят. Поэтому клиенту я отвечаю «принято» только после того, как заказ надежно лег на кворум реплик (про кворум – ниже). А вот тяжелую доработку – финальную раскладку на диске и обновление индекса – уже можно унести в асинхронную обработку после ответа. То есть асинхронна не durability, а последующая возня с укладкой данных. Дальше – предобработка, и это ключевой момент. Прежде чем куда-то раскладывать заказ, я считаю его длительность один раз, при записи, а не каждый раз при чтении. И сохраняю рядом метаданные, по которым потом будет идти фильтрация: orderId, длительность (finishTime − beginTime), потому что по ней сортируют оба метода чтения, время начала заказа (beginTime), потому что по нему фильтруют по окну времени – и, как увидим ниже, по нему же шардируют. Логика такая: сырой файл падает во временное хранилище, например в оперативную память. Там мы считаем длительность, формируем метаданные, и уже осознанно отправляем заказ на нужный сервер – в зависимости от его beginTime. То есть запись – это не “положить файл на диск”, а “принять, посчитать, направить” – и подтвердить клиенту только после того, как кворум реплик закрепил заказ. Шардирование по времени начала заказа Теперь главный вопрос раскладки: как распределить файлы по сотне машин? В чате во время разбора всплыл соблазнительный вариант – один день недели на один сервер. Семь серверов, и все закрыто. Я его отбросил, и по двум причинам. Во-первых, потолок. Семь серверов – это ровно семь серверов. Данных у нас на сотню машин, так что схема не масштабируется в принципе. Во-вторых, перекос нагрузки и запросов. Заказов в будни и в выходные разное количество, так что данные лягут по серверам неравномерно. А запрос за период, скажем с 1 по 31 мая, придется размазать параллельными запросами по всем семи машинам сразу, и каждая будет перегружена. Поэтому ключ шардирования – время начала заказа, beginTime. И это осознанный выбор: beginTime – ровно то поле, по которому фильтруют оба метода чтения (окно startTime–endTime задается по времени старта заказа). Когда шардируешь по тому же измерению, по которому потом фильтруешь, запрос за период задевает только несколько соседних шардов, а не размазывается по всем. Шардировать по времени приема было бы ошибкой: заказы приходят с задержкой и не по порядку, и тогда фильтр по beginTime перестал бы совпадать с раскладкой. Считаем по объему, сколько дней помещается на один сервер, и получаем что-то вроде 30 дней на шард. Заказы, стартовавшие в январе, попадают на январский шард, и после того как январь закрыт, на запись мы туда практически не возвращаемся. Плюсы: Запрос за конкретный период превращается в арифметику: по датам вычисляем, какие шарды задеты, и шлем запрос только на них, параллельно. Не на все сто машин, а на те несколько, где реально лежат нужные дни. Холодные данные отделены от горячих. Старые шарды спокойно лежат, их никто не трогает записью. Минус у схемы честный, и я его не прячу. Горячая точка записи всегда на последнем шарде – на сегодняшнем дне. Она постоянно смещается вперед во времени, вслед за текущей датой. С этим перекосом придется жить, но выбор осознанный: предсказуемая горячая точка лучше, чем равномерно размазанный хаос. Реплики и кворум: шард – это кластер из трех Один сервер на шард – это риск потери данных, на который мы пойти не можем. Поэтому шард у меня – не машина, а кластер из трех одинаковых серверов, которые держат одни и те же данные, и эти три сервера хочется разнести по регионам из тех же соображений, что и выше. Три сервера идентичны и обрабатывают запросы одинаково – и на запись, и на чтение. Балансировать между ними ничего не нужно: запрос приходит на все три и обрабатывается на всех трех симметрично. Почему именно три? Ради надежности с запасом на восстановление. Отказ одной машины не роняет шард: две оставшиеся работают, а у нас появляется время поднять замену, восстановить на ней данные и вернуть шард в полный состав. Была бы одна машина – при ее потере мы просто сидим и трясемся над единственной копией. Запись в шард идет через кворум. Направив заказ в нужный кластер по его beginTime, я шлю его на все три сервера параллельно, но жду подтверждения только от двух. Как только две машины сказали “записал” – запись считается надежной, третья меня в этот момент не волнует. Двух зафиксированных копий достаточно, чтобы данные не потерялись. Как потом догнать и синхронизировать третью – это уже вопрос следующего слоя, к пути записи он отношения не имеет. Собираю путь записи целиком: приняли файл, положили во временное хранилище (RAM), посчитали длительность и метаданные, по beginTime выбрали шард, разослали на все три реплики в разных регионах, дождались двух подтверждений – и только тогда ответили клиенту «принято». flowchart TD Client([Клиент]) -->|insertOrder| Ingest[Приемный слой<br/>ack после кворума] Ingest --> Temp[Временное хранилище RAM<br/>считаем duration + метаданные] Temp -->|роутинг по beginTime| Router{Выбор шарда<br/>по beginTime} Router -->|январь| S1 Router -->|февраль| S2 Router -->|сегодня, горячий| S3 subgraph S1[Шард A ~30 дней] A1[Реплика: регион 1] A2[Реплика: регион 2] A3[Реплика: регион 3] end subgraph S2[Шард B ~30 дней] B1[Реплика: регион 1] B2[Реплика: регион 2] B3[Реплика: регион 3] end subgraph S3[Шард N горячий] C1[Реплика: регион 1] C2[Реплика: регион 2] C3[Реплика: регион 3] end Router -.кворум: пишем в 3, ждем 2.-> S3Ввод и вывод машины: замена реплики и рост без ребаланса Раз шард – это кластер из трех, надо ответить на честный операционный вопрос: что происходит, когда машину выводят на обслуживание или меняют выпавшую, и как система растет со временем. Замена реплики. Отказ одной из трех машин шард не роняет – две оставшиеся держат кворум и на запись, и на чтение. А вот как поднимать замену, зависит от того, горячий шард или холодный. Холодный шард (закрытый месяц) на запись больше не меняется, данные иммутабельны, поэтому новую машину я поднимаю простым bulk-копированием файлов с живой реплики, без всякой живой сверки. Горячий шард (сегодняшний) меняется прямо сейчас, поэтому новую реплику я сначала заливаю снапшотом, а потом догоняю по логу дозаписи, пока она не поравняется с двумя работающими, и только тогда возвращаю в кворум. Вывод на обслуживание. Тот же принцип наоборот: вывожу одну реплику, шард живет на двух, делаю что нужно, возвращаю с догоном. Правило одно – никогда не трогаю две из трех в одном шарде одновременно. Рост без ребаланса. Вот где шардирование по времени по-настоящему окупается: старые данные не переезжают. Нужно больше емкости – я не перекладываю уже разложенное, а просто нарезаю новые шарды под будущие диапазоны дат. Если суточный объем вырос настолько, что 30-дневный шард переполнится, я делаю будущие шарды короче, скажем по 15 дней, а прошлые оставляю как есть. «Ребаланс» здесь почти всегда сводится к append-only: историю я не двигаю. Это ровно та причина, по которой шардирование по диапазону времени выигрывает у раскидывания по остатку – там любой рост означал бы переезд данных. Куда упирается хранение внутри шарда: файлы, inode и индекс Данные разложены по шардам и репликам. Осталась самая приземленная деталь – как физически хранить файлы внутри одного шарда. И здесь наивный вариант упирается в очень конкретную стену. Если не пробовали, попробуйте: создайте один каталог с десятью миллионами мелких файлов по 1–10 КБ и сделайте на нем ls. Вы обнаружите, что даже просто вывести список – нетривиальная работа для операционной системы. Один каталог на 10 млн файлов упирается в ограничения файловой системы: каждый файл – это inode, чтение их метаданных долгое, поиск по каталогу медленный. А диск при этом постоянно занят чтением, и записать на него что-то параллельно уже толком не выходит. Значит, хранение внутри шарда надо организовать. Дальше видятся два пути. Первый – раскладывать файлы по каталогам, скажем не больше 4000 файлов на каталог, структурируя их по датам. Появляется структура, а зная структуру, можно ускорять чтение. Второй – хранить все в одном большом файле, дописывая новое содержимое в конец, и держать где-то бинарное смещение каждого заказа внутри этого файла. Это, по сути, ровно то, как работает база данных. И вот тут развилка сходится в одну точку. При любом из вариантов честный поиск сводится к одному и тому же: гонять один гигантский файл целиком в память – ресурсно неблагодарно; перебирать 10 млн файлов за один день – ровно так же неблагодарно. И в том, и в другом случае нужен индекс, который упростит поиск и навигацию по всему этому хозяйству. Как построить этот индекс – под фильтр по beginTime и сортировку по длительности, так, чтобы два метода чтения работали, не поднимая терабайты в память – это и есть содержание второй части. Открытые вопросы, которые я оставляю честно открытыми Ядро дизайна собрано, но не все развилки я закрыл в первой части, и часть оставляю открытыми сознательно. На системном дизайне это нормально – проговорить вслух место, где однозначного ответа нет. Кворум между регионами против быстрого приема. Я хочу и разносить реплики по регионам ради disaster tolerance, и подтверждать запись быстро. Но если две из трех реплик лежат в разных регионах, то кворум 2 из 3 включает межрегиональный round-trip, и «быстро» превращается в задержку WAN. Либо кворум внутри одного региона (тогда потеря региона может унести незареплицированное), либо через регионы (тогда прием медленный). Где провести эту границу – открытый вопрос, и зависит от того, что дороже: секунды на приеме или сценарий потери целого региона. Идемпотентность и дубликаты. insertOrder по ненадежной сети с ретраями рано или поздно приедет дважды. Естественный ключ дедупликации – orderId, но саму дедупликацию и защиту от коллизий при работе на нескольких серверах я в этой версии не проектировал. Это то, что нужно добить, прежде чем называть систему надежной. Наблюдаемость. Managed-систем мы себе запретили, значит и готовых дашбордов «реплика отстала», «шард перегрелся», «inode заканчиваются» никто не принесет – их придется строить самому. Это тема отдельной, следующей записи. Разбор в чате: вопросы и гипотезы Этот кейс я разобрал не только в голове, но и вживую в чате сообщества. Несколько человек по очереди пробовали спроектировать систему, а я гонял их вопросами – ровно как на секции system design. Получилась хорошая карта того, обо что спотыкаешься, и несколько гипотез, часть которых честно спорит с моим выводом про индекс. Вопросы, на которые стоит ответить самому По ходу разбора я собрал список – если хотите проверить себя, пройдитесь по нему прежде, чем читать вторую часть: Как сделать так, чтобы файлы не терялись при потере сервера – например, диск рассыпался в момент записи или чтения? Как обеспечить скорость записи 1000 запросов в секунду? Когда считать длительность – в момент запроса или заранее? Сколько оперативной памяти нужно, чтобы собрать данные за год? Какие сложности с хранением 30 млн файлов – на уровне одной ОС, на уровне одного каталога? Если серверов больше одного – как обеспечить запись и чтение? Как организовать хранение на диске – множество файлов или один большой blob? Нужен ли индекс? Если нужен – зачем и какой структуры? Что делать, когда один сервер выводят на обслуживание, а другой добавляют? Как синхронизировать? Как убедиться, что при работе больше чем на одном сервере нет коллизий? К списку добавился вопрос от Артура: SSD это или HDD? На SSD можно спокойно класть тысячи мелких файлов, на HDD случайная запись убивает производительность – и это уже повод группировать файлы программно. Гипотезы участников Кодировать метаданные в имя файла. Азат предложил имя вида {start}-{duration}-{id}.json и идти по каталогу итерацией, читая только имена. Дешево и без отдельного индекса, но упирается ровно в тот самый медленный обход миллионов файлов. Раз нет SLA на чтение – зачем вообще индекс? Тоже Азат: отправить один и тот же запрос на все серверы, слить результаты сортировкой, читать построчно. Честная контр-гипотеза к моему выводу. Мой ответ был встречным вопросом: ты правда готов гонять итерацией 30 террабайт на каждый запрос? WAL вместо JSON-индекса. Андрей сразу отмел JSON и предложил write-ahead log, по сути event sourcing – дописываем в конец, а индекс поднимаем поверх. S3-подобная обертка с двумя индексами. Артур зашел со стороны «построим свой S3»: первичный объект – блоб, а сверху два индекса, (дата создания, orderId) и (дата окончания, orderId), чтобы закрыть обе сортировки. Один файл на день, 365 каталогов. Василий предложил самый прямой путь – раскладывать по дням. Ровно на нем и всплыла тема inode: «No space left on device» при свободном диске, Argument list too long, медленный ls, дорогой rsync. Тот самый наивный вариант, о который спотыкается решение. Узкое место – не throughput, а IOPS. Михаил посчитал нагрузку: ~1 МБ/с по полосе – мизер, потянет и одиночный HDD. Но 1000 мелких случайных записей в секунду – это тысячи случайных IOPS, и вот это уже аргумент за flash, а не за диски. Полезное напоминание, что «объем маленький» и «нагрузка легкая» – разные вещи. А должна ли наша система вообще писать? Михаил же поставил под сомнение саму рамку: антифроду нужно только читать, писать в реалтайме может боевая БД, а нам хватит ежесуточной выгрузки. По условию задачи писать надо нам – но на реальном интервью такой вопрос к постановке дорогого стоит. Отдельно отмечу мысль, которая прозвучала в разборе: решение на system design – это не финальная схема, а сам процесс задавания вопросов и список операционных параметров той системы, что ты в итоге собрал. Продолжение – во второй части. Теги: system design, архитектура, распределенные системы, антифрод, собеседования, тимлид ## Джуны: чья ответственность их растить и когда они вообще не нужны URL: https://teamleads.kz/articles/dzhuny-chya-otvetstvennost-rastit/ Дата: 2026-07-02 Чья ответственность растить джунов – сотрудника или компании, почему на зрелом проекте джун не вывозит и как онбордить джуна в маленькой команде. Автор: Сообщество «Тимлид не кодит» Основатель молодого продуктового стартапа рассказывает про свою команду. Шесть человек, продукт запустили в январе, растет быстро. И вдруг фраза, от которой у половины сообщества дернулся глаз: джунов мы сейчас не берем. Не потому что жалко денег на зарплату. И не из принципа «пусть сначала докажет». А потому что проект дорос до состояния, в котором вчерашний студент просто не вывозит: слишком много доменной сложности, слишком много контекста, который живет в головах, а не в коде. Казалось бы, обычная бизнес-логика. Но именно с этой фразы началась двухчасовая дискуссия о том, кто вообще обязан растить джунов – сам джун, компания или рынок. И, что важнее, когда джун нужен, а когда это дорогая ошибка. Разберемся по порядку. Спор, который старше нас всех: чья это ответственность Первая линия фронта проходит по простому вопросу. Джун пришел сырой. Кто должен вложиться в то, чтобы он стал полезным? Одна позиция звучит жестко и по-своему честно: развитие – это ответственность самого сотрудника, а не обязанность компании. Спасение утопающих – дело рук самих утопающих. Логика такая. Компания заключает с человеком социальный контракт: платит деньги, дает задачи, дает возможность учиться на реальных ошибках. Все. Дальше хочешь расти – расти сам: бери отпуск, плати за курс, читай, спрашивай. Один из участников привел собственную историю. Работодатель не был заинтересован в его развитии, потому что его устраивал текущий расклад. Человек накопил денег, сам оплатил обучение, вырос и ушел к другому за зарплату на 50% выше. «В гробу я видал такого работодателя, спасибо им за опыт». Звучит убедительно. Но у этой позиции есть слепое пятно, и его быстро нашли. Компания существует не в вакууме. Особенно в Казахстане, где инфляция создает постоянное давление на фонд оплаты труда. Продукты дорожают, сотрудники хотят больше денег, а чтобы дать больше денег и не разориться, нужно повышать производительность труда. Повышать производительность, не повышая квалификацию, невозможно. Чтобы стоять на месте, надо быстро бежать. И вот вам петля. Сотрудник хочет больше. Компания может дать больше только при росте выработки. Выработка растет только при росте квалификации. А квалификация сама себя не поднимет, если все сидят на уровне знаний пятилетней давности. Получается, что «развитие – дело сотрудника» работает ровно до тех пор, пока рынок и инфляция не выставят счет. Компромисс, к которому в итоге подошли: верны обе позиции, просто для разных горизонтов. Для узкого прикладного IT модель «сотрудник учится сам, а мы берем готовых» – вполне рабочий бизнес. Для компании, которая хочет большего, чем закрывать сегодняшние тикеты, отказ от инвестиций в людей рано или поздно упирается в потолок. Вопрос не в том, должна ли компания вкладываться. Вопрос в том, какой у нее горизонт. Почему на зрелом проекте джун не вывозит Вернемся к тому основателю. Его аргумент не идеологический, а инженерный, и он заслуживает отдельного разбора. Проекту 2,5–3 года. За это время накопился пласт доменных знаний, пограничных кейсов и неочевидных решений. Джун приходит и не может «сходу разобраться и начать приносить value»: слишком высокий порог входа. А задачи при этом сложные и почти все срочные – живые клиенты с реальными интеграциями, где ошибка стоит клиента. Сравните с greenfield. Новый продукт, много принципиально новой разработки, микросервисы пишутся с нуля, минимум легаси-контекста. Вот здесь джуны отлично вывозят – «в любой конвейер можно джунов ставить». Разница не в людях, а в природе работы. И тут в разговоре всплыла мысль, которая переворачивает весь спор. А что, если джун на зрелом проекте – это не проблема джуна, а диагноз архитектуры? Сеньорность – это ведь не про то, чтобы писать сложный код. Это про то, чтобы писать сложное просто. Если у вас настолько высокий порог входа, что новый человек полгода не может ничего сделать, возможно, дело не в человеке, а в системе, и ее пора облегчать. Задача из категории «важная, но не срочная»: ее вечно откладывают ради очередной горящей фичи, а зря. Джун, которого вы вынуждены онбордить, работает как стресс-тест. Он показывает, где ваша система переусложнена настолько, что ее не понимает никто, кроме двух-трех старожилов. Знакомая ситуация? Это ведь еще и про бас-фактор. Проект, в который невозможно ввести нового человека, держится на нескольких незаменимых головах. И если одна из них уйдет, заменить ее будет практически невозможно. Основатель это честно признал: такие риски мы пока принимаем. Джун как инвестиция, а не как обуза Есть еще один ракурс, который легко упустить за операционной суетой. Если вы никогда не берете джунов и все время докупаете готовых мидлов и сеньоров с рынка – что происходит с вашей командой в долгую? Во-первых, у вас нет внутреннего трека роста. Некого менторить, а значит, ваши мидлы не превращаются в тимлидов: навык наставничества просто негде тренировать. А ведь менторство прокачивает в первую очередь самого ментора. Объясняя, ты сам начинаешь глубже понимать то, что раньше знал «в общих чертах». Во-вторых, вы паразитируете на рынке, ничего в него не возвращая. Все хотят готовых специалистов, но готовые специалисты откуда-то берутся. Если никто не растит джунов, завтра не будет мидлов. Классическая трагедия общего ресурса. В-третьих, джун – это инвестиция с отложенной отдачей. «Депозит, который вкладываешь сейчас, а получаешь больше потом». Не взяли и не вырастили сегодня – через год, когда людей будет остро не хватать, окажетесь перед выбором из плохих вариантов: либо переманивать дорого, либо срочно двигать кого-то на роль, к которой он не готов. Тут важно не впасть в другую крайность и не начать нанимать джунов пачками «для галочки». Джун оправдан там, где есть кому его вести, есть поток задач подходящей сложности и есть горизонт, на котором вложение окупится. Если ничего из этого нет, честнее не брать, чем брать и бросить. Две правды, которые придется держать в голове одновременно Дискуссия так и не свелась к единому ответу, и это нормально. Вот как разложились позиции. Вопрос «Ответственность сотрудника» «Ответственность компании» Кто вкладывается в рост джуна? Сам человек: учится на ошибках, платит за курсы, растет и уходит выше Компания: иначе упрется в потолок выработки и потеряет людей Что должна компания? Соблюдать социальный контракт: деньги, задачи, право на ошибку Инвестировать в квалификацию, потому что инфляция не оставляет выбора Когда модель работает? Узкое прикладное IT, стабильные процессы Когда компания хочет расти, а не только закрывать тикеты А поверх этого – инженерный водораздел про сам факт найма джуна: Ситуация Брать джуна? Почему Greenfield, много новой разработки Да Низкий порог входа, джуны отлично вывозят конвейер Зрелый проект (2,5–3 года), высокая доменная сложность Осторожно Джун долго не приносит value, но это еще и сигнал облегчить архитектуру Все горит, задачи срочные и сложные Нет, пока горит Некому вести, а онбординг требует ресурса, которого нет Обратите внимание: ни одна колонка не «неправильная». Правильный ответ зависит от стадии продукта, зрелости архитектуры и горизонта планирования. Тот, кто продает вам универсальное «джунов надо / не надо брать», скорее всего, не додумал контекст. Как онбордить джуна в маленькой команде: рабочая схема Самое ценное из встречи – конкретная механика, которую один из участников обкатал на своей команде. Если вы все-таки берете джуна и людей мало, вот подход, который не убивает команду ресурсом на присмотр. Трехмесячная стажировка со сдвигом от тестирования к разработке. Недели 1–2. Человек занимается только тестированием фич, которые написали более опытные ребята. Не пишет код, а проверяет. Постепенный сдвиг. Каждые две недели фокус смещается: сначала тестирование, потом мелкие багфиксы, потом все более содержательная разработка. К концу трех месяцев. У человека есть и понимание доменной области (потому что тестирование – это лучший способ ее изучить), и первый реальный код. Почему это работает лучше, чем «вот тебе задача, разбирайся»? Потому что тестирование – это клей, который наращивает доменные знания без риска сломать прод. Джун изучает систему изнутри, глядя на нее глазами пользователя фич, а не сразу ныряя в архитектуру, которую еще не понимает. Чек-лист перед тем, как открыть вакансию джуна: Есть ли поток задач подходящей сложности – или все горит и все срочное? Есть ли кому вести – человек, для которого менторство станет точкой роста, а не обузой? Терпит ли архитектура нового человека – или порог входа сигналит, что систему пора упрощать? Какой горизонт – успеет ли вложение окупиться до того, как джун вырастет и уйдет? Готовы ли вы к тому, что первые месяцы это минус к скорости, а не плюс? Если на большинство пунктов честное «нет», возможно, сейчас не время. И это нормально. Отложить наем джуна до подходящей стадии – это не жадность, а зрелость. Почему это важно за пределами одной команды Вопрос «растить или докупать» выглядит как операционная мелочь, но определяет он куда больше, чем кажется. Он определяет ваш бюджет найма: переманивать готовых дороже, чем растить, но растить – это отложенные затраты с риском, что человек уйдет. Он определяет ваш бас-фактор: команда без притока новых людей костенеет вокруг нескольких незаменимых. Он определяет здоровье всего рынка: если каждая компания хочет только готовых, готовые закончатся. И, пожалуй, главное – он определяет, честны ли вы с собой насчет своей архитектуры. Потому что «джун у нас не вывезет» слишком часто означает не «джун плохой», а «мы построили систему, которую не понимает никто, кроме нас самих». Так чья же ответственность растить джунов? Похоже, ничья в одиночку – и всех сразу. Сотрудник отвечает за инициативу, компания – за среду, в которой эта инициатива окупается. А вы у себя в команде на какой стадии сейчас: greenfield, где джун ускорит, или зрелый проект, который пора упрощать? Эта статья основана на встрече сообщества «Тимлид не кодит» 1 июля 2026 года. Присоединяйтесь к обсуждению в Telegram. Теги: джуны, найм, менторинг, онбординг, Казахстан ## Карьерный трек разработчика после сеньора: куда расти, когда потолок близко URL: https://teamleads.kz/articles/karernyy-trek-razrabotchika-posle-senora/ Дата: 2026-06-25 Почему сеньором в одной компании не вырастают, чем тимлид отличается от техлида и какие пути есть после сеньора – архитектор, эксперт, CTO. Автор: Андрей Курдюмов (kant2002) Я разрабатываю системы двадцать лет и до сих пор слышу один и тот же вопрос. «Я дорос до сеньора. А дальше-то куда?» Вопрос хороший. Ответ на него обычно плохой – потому что людям продают карту, которой не существует. Давайте разберёмся по-честному. Без слайдов про «грейды» и роадмапы, которые рисуют HR. Сеньора не дают. Сеньора берут Начнём с неприятного. Я не верю, что человек в рамках одной продуктовой компании вырастает с джуна до сеньора. Не потому что люди тупые. А потому что профиль другой. В аутсорсе и аутстаффе – верю. Там ты за пять лет проходишь десяток проектов, доменов, заказчиков. Тебя жизнь катает. А в одной продуктовой компании ты варишься в одном супе. Углубляешься – да. Но это другой рост. Знаю, что скажут. «Ну как же, у нас Вася зашёл джуном и стал сеньором, не выходя из опенспейса». Стал. Только сеньора не дают – сеньора берут. Лычку вам выпишут, а уровень проверяется не лычкой, а тем, что вы можете в чужом проекте, в чужом домене, под чужим давлением. Назвался груздем – полезай в кузов, дальше всё проверяется на практике. Именно поэтому «сеньор» в одной компании часто равен «мидл» в другой. И наоборот. Тимлид – это не «сеньор плюс» Дальше начинается путаница, которая стоит людям лет карьеры. Принято думать, что лестница простая: мидл → сеньор → тимлид. То есть тимлид – это сеньор, которому добавили подчинённых. Это неправда. По крайней мере, не всегда. Тимлидом можно стать после мидла. Серьёзно. Если ты умеешь договариваться с людьми, находить компромиссы, мотивировать команду работать в нормальной атмосфере и презентовать её работу наверх – ты тимлид. Техническая глубина сеньора для этого не обязательна. Тут надо различать две роли, которые называют одним словом. Тимлид – это про людей. Прокладка, которая отвечает за команду и показывает её работу вышестоящим. Если наверху не лезут в технические детали, хватает навыков общения, переговоров и презентации. Техлид – это про продукт и технологию. Человек, который реально держит в голове, как устроена система, на кого можно положиться, где рванёт. Значит, «дорасти до тимлида» и «дорасти до техлида» – это два разных маршрута. И иногда тимлидом проще стать раньше, чем сеньором. Особенно в аутсорсе: пошёл, пообщался с заказчиком, понравился – и вот ты уже на этом месте. Зоопарк ролей, в котором легко заблудиться Отдельная боль – названия. Project manager, delivery manager, technical project manager, тимлид, техлид. Компании раздают эти ярлыки как попало. Я серьёзно. Ты никогда не угадаешь, что компании нужно, пока не прочитаешь описание роли. А прочитав описание – всё равно не угадаешь, потому что описание тоже слоп. Угадаешь только когда поговоришь с тем, кто эту роль заказывает. Delivery-менеджер в одном месте – это большие деньги и ответственность за пачку проектов. В другом – «денег там нет», обычная прокладка с коррупционной составляющей в виде умения договариваться. Так что не ведитесь на название в вакансии. Название – это упаковка. Смотрите на содержание. Математика, про которую забывают Теперь главный фокус, который ломает популярный совет «иди в тимлиды, это следующая ступенька». Тимлидов в компании по определению меньше, чем сеньоров. Один тимлид – на команду. Сеньоров в этой команде может быть несколько. Значит, чтобы стать тимлидом, надо дождаться, пока освободится место или выделят новую команду. А средняя продолжительность жизни управленца в компании больше, чем технического спеца. Место не освобождается. Получается, сидеть и ждать тимлидской вакансии можно дольше, чем самому дорасти до сеньора. «Так надо убрать текущего тимлида» – скажет самый бойкий. Нет. Подковёрные игры – плохая стратегия. Это игра престолов, и вы не хотите работать в компании, которая вам такое позволит. Потому что та же компания позволит сделать это и с вами. Вам нужна не та контора, где можно подсидеть, а та, которая выгоняет за политику. Звучит парадоксально, но это так. Куда на самом деле расти после сеньора Хорошо, потолок близко. Деньги за чистую разработку расти перестали. Что дальше? Вариантов, по сути, несколько – и их полезно знать заранее. Остаться сеньором на десятилетия. Это нормально. Я видел такие примеры. Если технический трек вам в кайф – никто не обязан становиться начальником. Стать узким экспертом. Тем самым, которому платят один доллар за удар кувалдой и 999 за знание, куда ударить. Платят за это очень хорошо. Но таких – единицы, и карпатым по щелчку не станешь. Технико-менеджерский трек. Team lead, дальше C-level: CTO, CIO. Это если нет внутреннего конфликта с менеджерской работой. Кому-то она в радость, кому-то – ад. Архитектор или пресейл. Тоже выход из чистого кодинга, но с сохранением технической части. Стартап / своя ответственность. Только без иллюзий. Пойдёшь в стартап – там не миллион денег и сто инженеров, там пять коллег в лучшем случае и ты сам пропетляешь. По сути снова станешь тем самым тимлидом, только без подушки. Перейти в компанию посильнее на ту же должность. В Казахстане этот путь почти не реализован, быстро упирается в потолок. А вот за его пределами работает: ты остаёшься сеньором, но идёшь туда, где за сеньора платят в полтора раза больше и спрашивают больше. Заметьте контраст. Это не лестница «выше-выше-выше». Это развилка, где техническая ветка и менеджерская расходятся. И на развилке надо выбирать, а не «расти по умолчанию». Стеклянный потолок – это не оскорбление Тут важно сказать прямо. Если вы хотите остаться в технике, в какой-то момент деньги начинают платить за менеджерские качества. Это и есть стеклянный потолок. Не потому что вы плохой инженер. А потому что рынок так устроен. Дальше либо вы становитесь тем самым узким экспертом за 999 долларов, либо берёте на себя людей. Третьего, честно говоря, немного. И ещё. Сеньор – часто неинтересная лычка. Денег не сильно больше, а геморроя – заметно. Поэтому в аутсорсе народ нередко идёт в лиды не от большой любви к менеджменту, а чтобы не задрачиваться технически. Пошёл, пообщался с заказчиком – и нормально. Это не хорошо и не плохо. Это просто удачная конфигурация для конкретного человека. Что с этим делать прямо сейчас Соберу в чек-лист, чтобы не растеклось. Перестаньте измерять рост лычками. Меряйте тем, что вы можете в незнакомом проекте и домене. Решите развилку осознанно: техническая ветка или менеджерская. «Расти по умолчанию» – не стратегия. Если тянет в тимлиды – проверьте, тимлид там про людей или про технологию. Это разные работы. Не ждите тимлидскую вакансию годами. Посчитайте, что быстрее – дождаться места или сменить компанию. Хотите больше денег на технике – ищите компанию, где ваш «сеньор» считается мидлом. Переход часто выгоднее повышения. Не играйте в подсиживание. Контора, где это работает, сожрёт и вас. Почему это важно Карьерные советы в IT обычно врут одинаково. Они рисуют прямую лестницу, по которой надо упорно лезть вверх. А реальность – это развилки, потолки и роли с одинаковыми названиями и разным содержанием. Я не говорю, что знаю единственно верный путь. Это взгляд одного человека на свой кусок индустрии. Но за двадцать лет я насмотрелся, как люди годами ждут «повышения до тимлида», которого структурно не будет. И как другие просто меняют компанию – и получают и деньги, и рост. Так что не лезьте по чужой лестнице. Сначала посмотрите, куда она вообще приставлена. А у вас потолок где – в деньгах, в интересе или в названии должности? Обсудить можно в Telegram. Эта статья основана на встрече сообщества «Тимлид не кодит» 24 июня 2026 года. Присоединяйтесь к обсуждению в Telegram. Теги: карьера, сеньор, тимлид, грейды, Казахстан ## Бас-фактор: что делать, когда весь проект держит один человек URL: https://teamleads.kz/articles/bas-faktor-odin-nositel-znaniy/ Дата: 2026-06-25 Реальная история, как умер единственный носитель знаний по проекту, и почему документация вас не спасёт. Разбор бас-фактора без паники. Автор: Андрей Курдюмов (kant2002) Я разрабатываю информационные системы уже двадцать лет. И за это время понял одну неприятную вещь. Бас-фактор – это не строчка в чек-листе рисков. Это живой человек, у которого в голове лежит то, чего нет больше нигде. Расскажу историю. Недавно меня позвали на проект в стендбай. Просто побыть рядом, замещающим. Потому что у единственного разработчика на проекте нашли рак поджелудочной железы. План был нормальный. Человек ещё работает, мы потихоньку передаём знания, я вникаю, как оно всё устроено. Бизнес даже подготовился, насколько вообще к такому можно подготовиться. Но рак победил раньше. Буквально за две недели человека не стало. Что значит «один носитель знаний» на практике Дальше начинается то, ради чего я и пишу этот текст. Проект был сделан правильно. Не подхаченый на коленке, а по-взрослому. Требование HIPAA – значит, все данные на зашифрованном диске. Сам процесс крутится на зашифрованном диске. Безопасность на уровне. Но есть один нюанс. Пароль от этого диска знал только разработчик. Вот и всё. Один человек, один пароль, и человека больше нет. Хорошо, что код лежал в гитхабе – иначе разговор был бы совсем коротким. Но код – это ещё не система. Восстанавливать процессы реверс-инжинирингом по нескольким репозиториям – то ещё приключение. Я не могу сказать, что я плохо разбираюсь. Разбираюсь нормально. Но всё равно это тяжело. Потому что в коде лежит «как», а «зачем» лежало в голове. «А давайте AI всё восстановит» Знаю, что сейчас кто-нибудь скажет. «Так это же ерунда. Даже с AI?» Именно эту фразу я и услышал. «При чём здесь AI? С AI всё лучше». А притом, что AI там нечего жевать. Там нет кода, который объясняет бизнес. Там нет комментария «мы делаем эту проверку, потому что клиент в 2019 году попал на штраф». AI прекрасно достроит синтаксис. Но он не достроит контекст, которого нет в файлах. Это не задача про код. Это задача про знание, которое умерло вместе с человеком. Так что AI здесь – не спасатель. В лучшем случае – ускоритель раскопок. Откуда вообще берётся бас-фактор Тут важно не сваливать всё на злой рок. Экстремальные ситуации не падают с неба. Они рождаются из экономии. Смотрите, как это происходит. Весь процесс отдали на откуп одному разработчику. Он продуктовый, он шарит за бизнес, он оперирует доменом. Он молодец. Он закрывает собой всё. И именно поэтому он становится точкой отказа. Потому что когда человек оперирует бизнесом, его знание – это не строчки. Это понимание, почему сделано так, а не иначе. И вот это понимание по документам не передаётся. Документ говорит «что». Человек знает «почему». Бизнес экономит на дублёре, на ротации, на скучных разборах «а как это работает». Сперва это выглядит как эффективность. Один человек тянет – зачем платить двоим. Но кто же знал, что человек смертен. Причём, как говорил классик, иногда внезапно смертен. Документация – это не страховка Тут принято сказать «ну надо было всё задокументировать». Согласен. Но не обольщайтесь. Документация фиксирует состояние. А продуктовое знание – это не состояние, это способ думать. Вы можете описать все таблицы, все эндпоинты, все конфиги. И всё равно новый человек полгода будет въезжать, почему система ведёт себя именно так. Я это видел не раз. Приходишь на «полностью задокументированный» проект – и понимаешь, что документация отвечает на вопросы, которые ты ещё не научился задавать. Значит, документация нужна. Но она – нижний уровень страховки, а не весь полис. Чем бас-фактор отличается в продуктовой компании Тут есть тонкость, про которую часто забывают. В продуктовой компании каждый сильный разработчик неизбежно прирастает доменным знанием. Он по-другому не может – чтобы делать продукт, надо понимать бизнес. И это хорошо для продукта. Но это же повышает бас-фактор. Чем ценнее человек для домена, тем больнее его потерять. Не потому что код некому писать – код напишут. А потому что некому объяснить, что этот код означает для бизнеса. Получается ловушка. Тот самый продуктовый инженер, которого все хотят вырастить, – это и есть ваша главная точка отказа. И чем он круче, тем точка опаснее. Что с этим делать Серебряной пули нет. Но есть несколько вещей, которые реально снижают риск, а не создают видимость. Ни один секрет не должен жить в одной голове. Пароли, ключи, доступы – минимум в двух местах, лучше в нормальном секрет-сторе. Зашифрованный диск без второго держателя пароля – это бомба с таймером. У каждого критичного куска должен быть «второй человек». Не дублёр на полную, а тот, кто хотя бы раз сам прошёл весь путь руками. Передавайте «почему», а не только «что». Лучший формат – не документ, а живой разбор: посадить второго человека и провести его по бизнес-логике. Делайте ротацию на скучных, но критичных задачах. Тот, кто никогда не трогал деплой, в нужный момент его не сделает. Код – в общий репозиторий, всегда. Гитхаб в моей истории спас проект. Это банально, но банальности и спасают. Считайте бас-фактор осознанно. Сядьте и спросите: кто у нас единственный? Если ответ есть – это уже план работ. Заметьте, ни один пункт не про героизм. Бас-фактор лечится не подвигом, а скукой – регулярной, занудной, неинтересной передачей знаний. Почему это важно за пределами одной грустной истории Можно сказать – ну, редкий случай, человек умер, что теперь, паниковать. Не паниковать. Но и не врать себе. Человек не обязан умирать, чтобы выбить вам бас-фактор. Он может уволиться в обиде. Уйти к конкуренту. Уехать в другую страну. Просто выгореть и пропасть на месяц. Результат для проекта тот же – знание ушло за дверь, а вы остались с кодом, который надо расшифровывать. И вот что я понял за эти двадцать лет. Бас-фактор – это всегда плата за экономию, отложенная во времени. Сегодня вы экономите на дублёре. Завтра платите реверс-инжинирингом, сорванными сроками и нервами. Посчитайте свой бас-фактор честно. У кого в команде в голове лежит то, чего нет ни у кого больше? Обсудить можно в Telegram. Теги: бас-фактор, управление рисками, передача знаний, тимлид, Казахстан ## LLM как разведчик, а не runtime-компонент URL: https://teamleads.kz/articles/llm-kak-razvedchik/ Дата: 2026-06-08 Держать ИИ в каждом бизнес-процессе навсегда – рискованно. Разбираю подход, где LLM работает временно: находит, что автоматизировать, а потом уходит. Автор: Андрей Курдюмов (kant2002) Я разрабатываю информационные системы уже 20 лет. И каждый раз, когда слышу «а давайте встроим сюда ИИ навсегда», у меня дёргается глаз. Потому что по умолчанию все думают одинаково. Нашли процесс, посадили туда LLM, оставили жить. Чат-бот в поддержке, агент в CRM, ассистент в аналитике. Модель становится постоянной деталью механизма – как база данных или очередь. Это не архитектура. Это привычка. И вот недавно я наткнулся на точку зрения, которая эту привычку ломает. Общался с innovation director большой британской enterprise-компании. Они уже провели несколько раундов AI-оптимизации, причём не в стиле «сократим людей», а как реальное улучшение работы. И вывод у них получился неожиданный: держать LLM постоянной частью бизнес-процессов – слишком рискованно. Чему мы вообще делегируем Сперва договоримся, что такое LLM в этой картине. Не разум. Не сознание. Я смотрю на неё как на софтверный компонент, которому можно делегировать часть мышления: интерпретацию контекста, работу с неоднозначностью, построение следующего шага. И только. Мы не отдаём ей принятие решений. Мы отдаём ей работу с размытостью там, где обычный код спотыкается. Значит, и вопрос не в том, «как впихнуть LLM в продукт». Вопрос в том, оставить её там навсегда или использовать как временный инструмент. Разведчик, а не жилец Риска тут два. Первый понятный – vendor dependency, привязка к чужим ценам, лимитам и политикам. Второй тоньше: встраивая LLM в процесс навсегда, вы делегируете часть бизнес-мышления внешнему стохастическому компоненту. То есть тому, что по своей природе выдаёт вероятностный результат, а не гарантированный. Поэтому LLM здесь – не финальная архитектура. Это разведчик. Работает он в три захода: Людям дают агентов или LLM-помощников. Они работают в реальных задачах, а система собирает данные: что люди реально делают, что повторяют, где принимают решения, какие правила живут только в головах и в workflow никогда не были описаны. Логи анализируются, из них вытаскиваются устойчивые паттерны. Часть процессов автоматизируется уже не через LLM, а через обычный код: workflow-логика, правила в CRM, интеграции, дашборды, approval flows, внутренние тулзы. Идея не в том, чтобы навсегда усадить нейронку в каждый процесс. Наоборот. Использовать её как временный исследовательский слой, понять реальное операционное поведение компании, а потом всё, что можно формализовать, вернуть в обычный детерминированный код. Модель отработала разведку – и ушла. На её месте остаётся скучный предсказуемый код. Он не галлюцинирует, не жрёт токены и не зависит от чужого API. Почему это бьёт в старую боль Классическая автоматизация двадцать лет спотыкается об одно и то же. Об discovery. Прежде чем что-то автоматизировать, надо точно понять, как это работает. А люди не могут объяснить собственную работу. Половина правил живёт в головах, в негласных договорённостях, в «ну тут я обычно смотрю и решаю». Раньше это лечили аналитиками. Посади человека рядом, понаблюдай, опиши процесс. Но посадить аналитика к каждому сотруднику в компании на десятки тысяч человек – нереально. А раздать LLM-помощников и собрать логи реального поведения – вполне. Именно в этом ценность. Не в том, что ИИ умнее человека. А в том, что он масштабируется туда, куда живой аналитик физически не дотянется. И сразу уточню, пока не поняли неправильно. Это не про то, чтобы переложить работу на нейронку. Люди работают сами. Ты собрал логи, проанализировал, предложил, что автоматизировать. На основании реальных данных, а не впечатлений. «А кто ответит перед советом директоров?» В чате мне сразу прилетело здравое возражение. Мол, доверять нейронке нельзя там, где цена ошибки высокая. В юридические вещи, в расшифровку аудио для протоколов – лучше не пускать. «Галлюцинации могут стоить больших денег. Не могу же сказать совету директоров, ну сорян пацики тут нейронка проебалась». Возражение справедливое. Но оно не против разведчика, оно за него. Именно потому, что LLM не остаётся на критичном процессе навсегда. Она помогает понять, что там автоматизировать обычным кодом, и уходит. А перед советом директоров отвечает детерминированная система с предсказуемым поведением. Разведка снимает риск ровно потому, что не претендует на роль постоянного исполнителя. Это не серебряная пуля Тут легко увлечься и объявить scout-подход универсальным решением. Не надо. Как заметил коллега в чате, в разных бизнес-процессах разное соотношение детерминированной и вариативной составляющей. Где-то процесс на 90% из чётких правил – его и стоит формализовать в код после разведки. А где-то вариативность и есть суть работы, и там LLM по делу останется в рантайме. Я и сам про это говорил: такие техники почти не обсуждают. Куда чаще мусолят заезженные способы работы с ЛЛМ. А это интересная мысль, с которой стоит поиграться и подумать, где она применима. Не догма, а лишний вопрос, который полезно себе задать. Что делать на практике Перед каждым процессом задайте себе три вопроса. Это runtime или scout? LLM должна остаться в процессе навсегда – или её задача лишь понять, что тут автоматизировать кодом? Сколько здесь детерминированного, а сколько вариативного? Больше чётких правил – уходим в обычный код после разведки. Больше неоднозначности – LLM оправданна в рантайме. Кто отвечает за результат? Если ошибка стоит дорого, критичную часть держим на предсказуемом коде, а модель используем как помощника, а не как финальное звено. Звучит парадоксально, но самый зрелый способ внедрить ИИ – иногда внедрить его временно. Дайте модели разведать территорию, собрать карту реальных процессов. А потом постройте на этой карте надёжные, скучные, детерминированные дороги. И прежде чем сажать ЛЛМ в прод навсегда, спросите себя: вам нужен исполнитель или разведчик? Обсудить можно в нашем чате. Теги: AI, автоматизация, бизнес-процессы, архитектура, тимлид, LLM ## Сотрудник не соблюдает ритуал – что делать, когда увольнение не вариант URL: https://teamleads.kz/articles/sotrudnik-ne-soblyudaet-ritual-chto-delat/ Дата: 2026-05-24 Пять подходов к ситуации, когда человек систематически не выполняет процесс: от социального давления до делегирования. Реальный кейс из IT-сообщества. Автор: Сообщество «Тимлид не кодит» Василий задал в чате простой вопрос: У вас есть сотрудник, который систематически не соблюдает важный ритуал. Вы с ним проводили 1-1 – результата не принесло. Автоматизировать нельзя. Уволить тоже. Что делать? За два часа обсуждения сообщество предложило пять принципиально разных подходов – от манипуляций до шоколадок. Но самое интересное случилось, когда выяснилось, о каком именно ритуале шла речь. И кто этот «сотрудник». Подход первый: социальный конструктор Артур ответил первым. И без экивоков. Манипулировать, или публично гасить перед командой. Особенно если все остальные этот ритуал делают. На дейлике невзначай спрашиваешь «чё там логи, нормально на проде?» – конкретно у него. И он будет вынужден перед командой признать, что не смотрел. Дальше – больше. Не спрашивать напрямую, а через коллег: попросить тестировщика уточнить, потом продакта задать тот же вопрос. «В итоге социальный конструктор такой, что многие спрашивают одно и то же – и он начинает делать». Василий отреагировал сдержанно: «Запишем этот вариант, но подождём более этичных техник для работы с людьми». Артур не стал отрицать: «Много вариантов, могу ещё накидать. Они не все этичные, но работают». Здесь важно не отмахнуться. Социальное давление – реально работающий механизм. Исследования Соломона Аша показали, что более 70% людей подчиняются мнению группы, даже когда оно очевидно неверно. Когда весь коллектив задаёт один и тот же вопрос, это создаёт ощущение нормы. Человек начинает соответствовать не потому, что понял ценность ритуала, а потому что отклоняться стало некомфортно. Проблема в другом. Андрей тут же возразил: Социальное давление не сработает. Если человек забывает в тот момент, когда надо – как это поможет? Точное замечание. Давление работает, когда проблема – в мотивации. Человек не хочет делать. Но если проблема в другом – он забывает, отвлекается, не может встроить действие в свой рабочий ритм – никакой дейлик-допрос не поможет. Вы будете давить на совесть, а корень – в логистике. Подход второй: делегирование Андрей предложил альтернативу: «А можно процесс на другого человека переложить? Ну или раз команда – может кто-то возьмётся помочь с организацией?» Идея выглядит как капитуляция, но это не так. Делегирование ритуала – это признание того, что у задачи есть владелец, и этот владелец не обязательно тот, кого назначили первым. Если один человек систематически не справляется с конкретным действием, возможно, это действие ему не по психотипу, не по ритму, не по приоритетам. В книге «Drive» Дэниел Пинк описывает три столпа внутренней мотивации: автономия, мастерство, цель. Ритуал, который человек не выбирал и не считает своим, нарушает все три. Передать его тому, кто добровольно возьмёт ответственность – не слабость менеджера, а точное распределение ресурсов. Но тут есть ловушка, и Андрей сам её заметил позже: Я правильно понимаю, что сообщество считает – кто пашет, на том и едут? Если делегировать каждый провал самым ответственным, вы наказываете лучших дополнительной нагрузкой. Работает один раз. На второй – ответственный задумается, зачем он вообще старается. Подход третий: структурированная ретроспектива Ян предложил системный подход из пяти шагов: Поднять вопрос на ретро и объяснить важность ритуала перед всей командой Показать два кейса – когда ритуал соблюдался и когда нет, с конкретными последствиями Назначить ответственного за контроль исполнения Награждать тех, кто следует ритуалу Если ничего не работает – «сдать человека скрам-мастеру» Пятый пункт – с улыбкой, но в каждой шутке есть доля правды. Скрам-мастер (или любой фасилитатор процессов) существует именно для таких ситуаций. Его работа – устранять препятствия, в том числе поведенческие. Но ключевой элемент здесь – пункт два. Два кейса с последствиями – это не абстрактное «ритуал важен», а конкретное «вот что случилось, когда мы это не сделали». Человек, который забывает нажать кнопку записи, может не понимать, что из-за этого 15 человек не услышат дискуссию. Пока последствия невидимы – мотивации нет. Подход четвёртый: геймификация Азат предложил лёгкий вариант: «Договориться с командой – кто забыл что-то сделать, приносит всем шоколадки». Звучит несерьёзно, но за этим стоит теория подкрепления Б. Ф. Скиннера. Лёгкое негативное последствие (купить шоколадки) не вызывает сопротивления, зато создаёт ассоциативную связь: забыл → мелкое неудобство. Со временем это встраивается в поведение. Артур добавил корпоративный пример из Kaspi: правило «блокировать компьютер при уходе» было на обоях рабочего стола и приходило на почту раз в неделю. Сочетание клавиш Ctrl+L. «На всю свою жизнь запомнил». Повторение + мягкие последствия + визуальные триггеры – три механизма, которые вместе формируют привычку. По отдельности каждый слаб, вместе – работают. Азат также отметил очевидное: «А вообще, лучше всего работает, если ритуалы автоматизировать». Но в условии задачи автоматизация невозможна – и это делает кейс интересным. Подход пятый: устранение помех Павел предложил самое простое: «Если забывает – посоветуй ему стикер на монитор приклеить. Мне в своё время помогло». Модель поведения BJ Фогга описывает три компонента действия: мотивация, способность и триггер. Если мотивация есть (человек не против ритуала), а способность достаточна (он умеет), то проблема – в отсутствии триггера в нужный момент. Стикер, напоминание в календаре, автоматическое уведомление за минуту до созвона – всё это триггеры. Андрей, размышляя о собственной ситуации, описал проблему изнутри: Мне нужно выстроить ритм жизни так, чтобы я приходил в место, где я веду беседу, заранее. Для этого надо за 3–4 часа выйти вовремя. Потом или не сидеть в чатах в ожидании, или не работать в ожидании созвона. Или выработать дисциплину как-то нажимать две кнопки одновременно. Вот он – голос «нарушителя». Не саботаж. Не лень. Сложный процесс, состоящий из трёх шагов: запустить созвон вовремя, включить запись, модерировать дискуссию. «1 из 3 процессов очень сильно хромает. Первый, кстати, тоже иногда подбуксовывает». Раскрытие карт К этому моменту самые внимательные читатели уже догадались. Василий раскрыл контекст: Если перейти к конкретике, то у нас есть созвоны, на них Андрей записи не включает. «Сотрудник» – это организатор добровольного сообщества. «Ритуал» – нажатие кнопки записи на еженедельном созвоне. «Уволить нельзя» – это не метафора, а буквальное ограничение: в сообществе нет иерархии. Артур моментально заметил: «Сложно менеджерить и влиять на тех, кем не управляешь». Василий парировал: «У тебя просто практики с позиции силы». И добавил фразу, ради которой стоило прочитать весь тред: Отсутствие опции уволить ≠ отсутствию управления. Это ключевой инсайт. Большинство управленческих инструментов построены на предпосылке, что у менеджера есть власть: нанять, уволить, повысить, понизить. Но в реальности даже в корпорациях эта власть ограничена. Уволить действительно сложно – трудовое законодательство, дефицит кадров, потеря контекста. А в кросс-функциональных командах, где тимлид не является прямым руководителем? А в опенсорс-проектах? А в сообществах? Инструменты, которые работают без опоры на власть, – это и есть настоящий менеджмент. Диагностика: почему человек не следует процессу Прежде чем выбирать подход, стоит понять причину. Из обсуждения выкристаллизовались четыре типа: Причина Признак Что работает Не хочет Открыто или пассивно сопротивляется Социальное давление, ретро с кейсами Забывает Делает, когда напоминают, но потом опять Триггеры, визуальные напоминания Не может встроить Процесс конфликтует с рабочим ритмом Упрощение процесса, делегирование Не видит ценности «А зачем это вообще?» Показать последствия, два кейса Ошибка – применять один инструмент ко всем причинам. Социальное давление на человека, который забывает, создаёт стресс без результата. Шоколадки для того, кто сознательно саботирует, – пустая трата какао. Чек-лист: что делать, когда ритуал не соблюдается Определите причину: не хочет, забывает, не может, не видит ценности Если забывает – добавьте триггер максимально близко к моменту действия Если не видит ценности – покажите два кейса: с ритуалом и без Если не может встроить – упростите процесс или передайте другому Если не хочет – выясните, почему (на 1-1 или через третье лицо) Переведите обсуждение на уровень команды: ретро, а не допрос Попробуйте геймификацию – мелкие последствия без конфронтации Зафиксируйте договорённости публично: кто отвечает, что происходит при нарушении Если ничего не работает – примите это как данность и делегируйте Почему это важно за пределами созвонов Кейс с записью созвонов звучит мелко. Но механика – та же самая, что и в серьёзных производственных ритуалах: ежедневная проверка логов, обновление статуса задач, ведение документации, код-ревью перед мержем. Исследование Harvard Business Review 2019 года показало, что 70% инициатив по изменению организационного поведения проваливаются. Не потому, что люди плохие. А потому, что менеджеры путают «сказать» с «внедрить». Одна встреча, одно письмо, одно правило в Confluence – это не внедрение. Внедрение – это триггеры, последствия, повторение и терпение. И ещё одно наблюдение из дискуссии. Андрей, будучи тем самым «нарушителем», открыто признал проблему и начал искать решение вместе с сообществом. Это редкая вещь. В корпоративной среде «нарушитель» обычно защищается, оправдывается или делает вид, что проблемы нет. Сообщество, где можно сказать «да, я косячу, давайте вместе думать» – это среда, в которой процессы действительно могут измениться. Как часто в вашей команде «нарушитель» сам участвует в поиске решения? Обсудить можно в Telegram. Эта статья основана на обсуждении в чате сообщества «Тимлид не кодит» 22 мая 2026 года. Контекст – из инсайтов за 19–24 мая. Присоединяйтесь к обсуждению в Telegram. Теги: менеджмент, тимлид, процессы, мотивация, Казахстан ## Метрики врут – или вы неправильно смотрите? URL: https://teamleads.kz/articles/metriki-vruyt-ili-vy-nepravilno-smotrite/ Дата: 2026-05-24 Одни и те же данные, разная группировка – противоположные выводы. Кейс из Microsoft: 2 000 тестов, 300 разработчиков и три графика, которые показывают разное. Автор: Сообщество «Тимлид не кодит» Стас из Microsoft показал сообществу график стабильности билдов и попросил оценить: ситуация улучшается или ухудшается? Красное – упавшие тесты (возможно баг, возможно случайность). Зелёное – успешные сборки. Жёлтое – flaky-тесты: упал, перезапустили, прошёл. Линия – общее количество билдов. Ответы разделились мгновенно. Артур: «Явно хуже становится, раньше соотношение удачных 1:1,15 – сейчас каждый второй неудачный». Василий: «Улучшается – flaky становится меньше, стабильность растёт». Денис выдал развёрнутый анализ и завершил его фразой, ради которой стоит читать дальше. График – гавно. Чтобы разобраться, нужна бутылка. Столбцы не сопоставимы, легенда однородна – не понятно, что линия, а что столбец. А потом Стас показал те же самые данные, но сгруппированные по кварталам. И вот тут всё стало очевидно. Один датасет – три истории Стас поставил эксперимент на живых людях. Одни и те же данные о стабильности билдов он показал трижды, каждый раз меняя только масштаб группировки: По неделям. Хаос. Шум. Мозг не может построить линию тренда визуально. Artурр увидел стагнацию, Василий – улучшение, Жоха заявил, что «график бесполезен». Все правы и все ошибаются одновременно. По месяцам. Чуть яснее, но сортировка по алфавиту (Apr, Feb, Jan, Mar, May) запутала ещё больше. Азат отреагировал: «Я знал, что люди манипулируют визуализацией статистики, но до такого даже самые выдающиеся гении не догадались». По кварталам. Наконец видно: жёлтого (flaky) стало вдвое меньше – с 17% до 8%. Зелёного больше. Тренд однозначный – улучшение. Для метрик важна перспектива. На квартальном графике явно видны улучшения. На еженедельном – ситуация абсолютно не однозначная, потому что мозг не может построить линию тренда визуально. Это какой-то шум. И чтобы сделать выводы – нужно сменить перспективу, масштаб. – Стас Масштаб, который ломает интуицию За графиками скрывается контекст, который меняет всё. Это не стартап на трёх микросервисах: 2 000 тестов в одном компоненте 300 разработчиков в 10 командах 1 000–1 500 билд-машин плюс столько же для тестов, плюс около тысячи физических мобильных устройств 60–70 релизов в сутки (каждый PR – это релиз) Один PR может запустить от 17 до 3 000 параллельных билдов, в зависимости от глубины изменений Стас привёл математику, которая пробивает интуицию: Даже если каждый тест из 10 000 имеет 99% SLA – надёжность всей системы составит 36%. Каждый тест в отдельности работает почти идеально. Все вместе – падают чаще, чем проходят. Один процент ненадёжности, помноженный на масштаб, превращается в системную проблему. И на еженедельном графике эта системная проблема выглядит как случайный шум. Пять реакций – пять ролей Самое ценное в этой дискуссии – не ответ, а спектр реакций. Каждый участник подошёл к одному и тому же графику со своей управленческой парадигмой. Охотник за виновниками Артур сразу предложил декомпозировать: «По командам и по сотрудникам – найти тех, кто аномально часто крашит билды и нагревает планету сильнее». Он видел инструмент для поиска проблемных зон. «300 человек – прекрасный датасет. Я бы потрогал эту базу». Подход рабочий для небольших команд, но Стас остудил: одна команда владеет 70% компонента, кодовая база общая, твоё изменение может сломать чужой код. Виновник – не всегда тот, чей билд упал. Критик визуализации Денис не стал отвечать на вопрос «лучше или хуже» – вместо этого разобрал, почему сам вопрос некорректен: Столбцы не сопоставимы. Легенда однородна. Я бы перестроил: столбцы – количество билдов, спагетти-линии – процент по типам тестов. Тогда сразу будет понятно. Важное наблюдение: плохой график – это не косметическая проблема, а управленческая. Если руководитель не может прочитать дашборд за 30 секунд, он либо проигнорирует данные, либо сделает неверный вывод. Оба варианта дороже, чем переделать визуализацию. Прагматик Андрей не стал копаться в деталях: «Управленец должен принимать решение, даже если информация не полная. И не всегда попытки собрать дополнительную информацию реальны». Для него вопрос не в том, что показывает график, а в том, какое решение принять прямо сейчас. Скептик Жоха усомнился в самих данных: «А вдруг раннеры или билд-машины сломались? Сеть упала? Весь этот график ничего не показывает». Его позиция – без отделения инфраструктурных проблем от проблем кода график бесполезен. Стас признал: «Тесты могут быть красными, потому что на билд-агентах нет какой-либо библиотеки и они все стали падать разом». Грязные данные – реальность, с которой приходится работать. Системный аналитик Денис подвёл итог тремя тезисами, каждый из которых заслуживает отдельной дискуссии: Разная гранулярность даёт разные тренды – да, но для разного уровня решений тебе и нужна разная гранулярность. Разная перспектива даёт разные инсайты – да, но у тебя разный уровень полномочий влиять на разные аспекты. Тренд говорит о текущей ситуации – нет, тренд говорит о поведении конкретной метрики. Последний пункт – ключевой. Метрика – это не реальность. Это модель реальности. И как любая модель, она отражает то, что вы решили измерить, а не то, что происходит на самом деле. Проблема разработчика, а не менеджера Есть ещё один аспект, который обычно упускают. Стас описал его изнутри: Разработчику без разницы, что ему мешает смерджить PR – flaky-тест или инфра-проблема. Если количество инфра-падений или flaky значительное – разработчик не доверяет сигналам. Билд красный? Первая мысль – «это инфра, не я». Он не смотрит свой код, просто перезапускает билд. Вот она – эрозия доверия к метрикам. Когда система падает часто и по случайным причинам, люди перестают обращать внимание на сигналы. Красный билд становится нормой. А настоящий баг проскакивает незамеченным, потому что все привыкли нажимать «перезапустить». Исследователь Джон Расмуссен описал похожий механизм в теории управления рисками: системы с высоким уровнем «ложных тревог» приучают операторов игнорировать предупреждения. Чернобыль, Three Mile Island, Boeing 737 MAX – в каждом случае операторы научились не обращать внимания на сигналы, потому что сигналы слишком часто были ложными. В масштабах билд-системы это не катастрофа. Но принцип тот же: ненадёжная метрика хуже, чем отсутствие метрики. Чек-лист: как не обмануть себя метриками Смотрите на данные в нескольких масштабах: недели, месяцы, кварталы Если на одном масштабе – хаос, попробуйте укрупнить Проверьте сортировку – алфавитная вместо хронологической ломает восприятие Отделите сигнал от шума: инфра-падения, flaky-тесты, реальные баги – это разные категории Спросите себя: «Доверяют ли разработчики этой метрике?» Если нет – сигнал бесполезен Не ищите виновников по метрикам на общей кодовой базе – изменение одного разработчика может сломать код другого Посчитайте «системную надёжность»: 99% на каждый тест ≠ 99% на систему из 10 000 тестов Визуализация – это интерфейс к данным. Если руководитель не может прочитать график за 30 секунд – переделайте график, а не руководителя Какой масштаб правильный? Никакой. И все одновременно. Еженедельный масштаб показывает операционный шум – полезен, если вы ищете конкретный инцидент. Месячный – тактические изменения, ретроспективу спринтов. Квартальный – стратегические тренды, обоснование инвестиций. Проблема начинается, когда менеджер показывает руководству еженедельный график и ожидает стратегических решений. Или когда директор смотрит на квартальный тренд и делает вывод, что «всё хорошо» – не видя, что за благополучной средней скрываются недели полного хаоса. Артур подытожил просто: «Аналитику нужно смотреть и в хвост, и в гриву, и со всех сторон, и несколько раз». Денис возразил точнее: у глубины анализа есть своя стоимость. «Иногда проще забить на цифры и принять любое решение – это будет лучше, чем не принятие никакого решения». Какой подход к метрикам ближе вашей команде – копать глубоко или действовать быстро? Обсудить можно в Telegram. Эта статья основана на обсуждении в чате сообщества «Тимлид не кодит» 19 мая 2026 года, где Стас из Microsoft разобрал реальный кейс с метриками на масштабе 300 разработчиков. Контекст – из инсайтов за 19–24 мая. Присоединяйтесь к обсуждению в Telegram. Теги: метрики, визуализация, менеджмент, тимлид, Казахстан ## R&D в IT: что считать исследованием, а что – просто разработкой URL: https://teamleads.kz/articles/r-and-d-v-it-chto-schitat-issledovaniem/ Дата: 2026-05-22 Пять видов R&D, критерии Фраскати, реальные кейсы Kaspi, Sterdyev и казахского LLM-токенизатора. Разбираемся, где проходит граница между Research и Development в казахстанском IT. Автор: Сообщество «Тимлид не кодит» Недавно я попал на встречу сообщества «Тимлид не кодит», где собрались ребята из Kaspi, Sterdyev, Bereke Bank и нескольких AI-стартапов. Обсуждали одну простую вещь – что такое R&D в казахстанском IT. Казалось бы, вопрос на пять минут. Но кто же знал, что мы там застрянем на два часа. Итак, поехали. Три команды, три «R&D» Команда в Kaspi переводит маркетплейс на WebView, гоняет серию A/B-тестов, сталкивается с кучей неизвестных. Другая команда в Sterdyev учит нейросеть определять протёршиеся шины по фотографии и распознавать автомобили по звуку мотора ночью. Третья – полностью пересобирает LLM-токенизатор, чтобы одно казахское слово занимало один токен вместо пяти. Все три примера попадут в годовой отчёт под вывеской «R&D». Но все ли они – исследование? Спойлер: нет. Пять типов, и различия принципиальны Международная классификация (да, есть такая штука) выделяет пять типов R&D. Давайте коротко: – Фундаментальное исследование – работа ради нового знания, без конкретного применения. В коммерческом IT Казахстана практически не встречается. Это про университеты и государственные лаборатории. – Прикладное исследование – исследование с конкретной целью, но без гарантии результата. Для наших компаний – редкость. И это нормально. – Экспериментальная разработка – создание новых продуктов на основе уже известных знаний. Вот тут начинается территория, которую IT-компании обычно называют R&D. – Продуктовая R&D – улучшение существующего продукта. Самый распространённый тип в казахстанском IT. – Процессная R&D – оптимизация бизнес-процессов через контролируемые эксперименты. Тут нужен масштаб: несколько одинаковых подразделений для контрольных групп. А теперь честно. Большинство казахстанских IT-компаний занимаются четвёртым типом. Продуктовой разработкой. Внедряют и улучшают существующие бизнес-практики. Это полезная, важная, квалифицированная работа. Но называть её «исследованием» – значит, размывать термин до бессмыслицы. R или D? Главный спор На встрече народ быстро разделился на два лагеря. Это, в целом, отражает вопрос, с которым сталкивается каждый тимлид, когда пишет квартальный отчёт. Первая позиция, строгая. Если технологию знают и практикуют тысячи компаний в мире, то ваша работа с ней – Development. Точка. Неважно, насколько это было сложно конкретно для вас. Перевод маркетплейса на WebView? Инженерная задача. Оптимизация карточек через OpenCV? Инженерная задача. Тысячи компаний делали это до вас. Вторая позиция, широкая. Любой проект с существенной неопределённостью – это R&D. Когда ребята из Kaspi бралась за WebView-миграцию, количество неизвестных было колоссальным. Результат не гарантирован. Ресурсы тратились без уверенности в отдаче. Казалось бы, оба подхода имеют право на жизнь. Но на практике разница между ними определяет, как компания бюджетирует IT, какие ожидания ставит команде и какие решения принимает о найме. Тоесть это не теоретический спор, это про деньги. Есть один простой фильтр, который помогает определиться: сколько компаний в мире обладают экспертизой для решения вашей задачи? Если тысячи – это D. Если единицы – ближе к R. Критерии Фраскати: красиво, но ломается ОЭСР в руководстве Фраскати предлагает формализованный подход. Пять критериев для определения R&D: – Новизна – нацеленность на принципиально новые результаты. Проблема: «новое для компании» – это не «новое для мира». – Творчество – оригинальные, неочевидные концепции. Проблема: без базовых знаний «творчество» превращается в переизобретение велосипеда. – Неопределённость – непредсказуемость результатов и затрат. Проблема: любой сложный проект имеет неопределённость. Это не делает его исследованием. – Систематичность – запланированный и задокументированный процесс. Проблема: хаотичные эксперименты – не R&D, даже если дают результат. – Воспроизводимость – результаты можно передать или воспроизвести. Проблема: если знание «умерло» с уходом разработчика – оно не было зафиксировано. На первый взгляд – стройная система. Но участники встречи быстренько нашли уязвимости. «Творчество» без фундамента – это не инновация, а незнание предшественников. «Неопределённость» есть в любом проекте сложнее лендинга. А «систематичность» отсекает подавляющее большинство того, что компании неформально называют R&D. Даже международные критерии не дают однозначного ответа. Они полезны как ориентир, но уязвимы для интерпретации. Наверное, это нормально для области, которая по определению работает с неизвестным. Два кейса, которые прошли фильтр Sterdyev. Определение изношенных шин по фотографии и идентификация автомобилей по звуку мотора в ночное время. Мало кто в мире обладает такой экспертизой. Задача не решается стандартными подходами – нужно собирать собственные датасеты, разрабатывать уникальные модели, работать с ограничениями, которых нет в учебниках. Даже скептики на встрече согласились: это ближе к настоящему R&D. Казахский LLM-токенизатор. Стандартные токенизаторы крупных языковых моделей разбивают казахские слова на 3–5 субтокенов. Это снижает качество генерации и увеличивает стоимость инференса. Команда полностью пересобрала токенизатор, чтобы одно казахское слово – один токен. Для слаборесурсных языков это явная инновация. Решение требовало исследования морфологии казахского языка, экспериментов с корпусами и нестандартных архитектурных решений. Мировая экспертиза в этой области минимальна. Что объединяет оба примера? Малое количество мировой экспертизы в конкретной задаче. Именно это, наверное, самый надёжный маркер того, что вы занимаетесь R, а не D. А стартапы-то могут? На встрече прозвучал провокационный тезис: стартап не может заниматься R&D, потому что исследование – это систематический процесс, а систематичность требует ресурсов. Один эксперимент – не R&D. Один эксперимент – это один эксперимент. Возражение прилетело тут же: основатель AI-стартапа потратил два года на исследования, прежде чем выйти на рынок. «Больше 10% всей жизни», заметил он. Зашибись аргумент, конечно. Истина, наверное, в том, что стартап может делать R, но не может позволить себе его потерять. Отсюда практический вывод: если исследование не задокументировано и не опубликовано, оно не существует. Патентование, публикации, внутренние отчёты – без фиксации результатов ваш R&D «умирает» вместе с компанией или уходом ключевого разработчика. В Казахстане эта проблема особенно острая. Локальные патенты часто оформляются «для тендера», а не для защиты реальных разработок. Настоящие результаты исследований остаются в головах и уходят вместе с людьми. Обещание «мы потом опубликуем» – это не результат. Как измерить то, что по определению неизвестно Участники встречи не пришли к консенсусу. И наверное это единственный честный результат. Патенты – самая распространённая метрика, но легко становится целью вместо средства. Когда KPI привязан к количеству патентов, люди начинают патентовать тривиальные решения. Знакомо, да? Экономические параметры – стоимость прототипирования, время от идеи до деплоя, количество дефектов в экспериментальном коде. Полезно для D, но плохо ловит R. Модель DARPA – ротация программных менеджеров каждые несколько лет, чтобы убрать предвзятость. Интересный подход, но требует масштаба, который в Казахстане есть у единичных компаний. Подход Маска – KPI за количество идей, а не качество. Работает только при жёстком отборе людей, которые хотят менять статус-кво. В среднестатистической компании превратится в генерацию шума. Отсутствие универсальной метрики – это не баг, а фича. R&D по определению работает с неизвестным. Метрика для неизвестного – парадокс. Как проверить себя Прежде чем написать в отчёте «R&D», честно ответьте на пять вопросов: – Сколько компаний в мире решают аналогичную задачу? Если тысячи – это D, не R. – Вы действительно не знаете, получится ли? Или просто не делали этого раньше? – Процесс документируется? Есть гипотезы, эксперименты, выводы? – Знания сохраняются для передачи? Или «умрут» с уходом автора? – Вы расширяете мировой фронтир знаний или догоняете рынок? Если большинство ответов «нет» – ваша команда занимается Development. И это абсолютно нормально. Не нужно стесняться буквы D. Хорошая разработка создаёт реальную ценность. Но называя её Research, вы создаёте ложные ожидания – у руководства, у кандидатов, у самих себя. Почему это вообще важно Инфляция термина – не абстрактная проблема. Она бьёт по конкретным вещам. Бюджет. Если всё – R&D, то где приоритеты? Настоящее исследование требует другого горизонта планирования и готовности к провалу. Продуктовая разработка – предсказуемости и дедлайнов. Это две разные модели управления. Наём. Кандидат ожидает исследовательскую работу, а получает продуктовую разработку. Или наоборот – команда не готова к неопределённости настоящего R. И в обоих случаях кто-то разочарован. Мотивация. Команда либо разочаруется в «ненастоящем R&D», либо не поймёт, почему от неё ждут прорывов за инженерный бюджет. Репутация. Рынок учится быстро. Если ваш «R&D-отдел» делает то же самое, что обычная продуктовая команда – это заметят. И кандидаты, и инвесторы, и партнёры. Честная оценка того, чем занимается ваша команда – это первый шаг к тому, чтобы делать это хорошо. Будь то Research или Development. Так что разберитесь сперва, чем вы занимаетесь. А потом уже называйте это как угодно. Обсудить можно в Telegram. Эта статья основана на встрече сообщества «Тимлид не кодит» 21 мая 2026 года, где участники из Kaspi, Sterdyev, Bereke Bank и AI-стартапов обсуждали границы R&D в казахстанском IT. Теги: R&D, инновации, менеджмент, Казахстан ## Как бороться с навязанными техническими решениями URL: https://teamleads.kz/articles/kak-borotsya-s-navyazannymi-resheniyami/ Дата: 2026-05-10 Реальный кейс: организацию заставляют переехать на Jira при 20+ работающих интеграциях. Стратегия противодействия через экономику, союзников и деловую переписку. Автор: Сообщество «Тимлид не кодит» Приходит уведомление: «Переезжаем на Jira». В организации уже работает self-hosted система с 20+ интеграциями – автоматические боты, вебхуки, синхронизация с GitLab, генерация отчётов. Всё это строилось годами, поддерживается командой платформенных инженеров, которые «умеют и в инфраструктуру, и в кодинг». И вот кто-то наверху решил, что нужна Jira. Знакомая ситуация? Если нет – просто подождите. Рано или поздно это случится с каждым тимлидом. На встрече сообщества мы разобрали этот кейс живьём – с участником, который прямо сейчас проходит через миграционный ад. И выработали стратегию, которая применима не только к Jira, но к любому навязанному техническому решению. Почему «просто скажи нет» не работает Первый рефлекс инженера – объяснить, почему это плохая идея. Технически. Подробно. С аргументами. Проблема в том, что решение принималось не на техническом уровне. Кто-то хочет набрать политические очки путём «успешного внедрения». Или продажник из Atlassian хорошо поработал с вашим руководством. Или новый CTO хочет оставить свой след. Когда вы приходите с техническими аргументами к человеку, который принимает политическое решение, вы играете не в ту игру. Он не слышит «20 интеграций сломаются». Он слышит «айтишники опять ноют». Переведите проблему в деньги Менеджеры мыслят экономикой. Это не недостаток – это инструмент, который можно использовать. Вместо «20 интеграций» скажите: «21 проект по миграции и разработке новой платформы». Одна миграция Jira – это не один проект. Это проект по каждой интеграции плюс сама миграция. Плюс двойная нагрузка на обслуживание старой и новой системы в переходный период. Конкретный алгоритм: 1. Посчитайте интеграции. Не «у нас много интеграций», а «мы насчитали 20 интеграций». Число бьёт сильнее прилагательного. 2. Оцените каждую. «Если по оценке каждая интеграция – неделя работы, то получится столько-то человеко-месяцев». Даже грубая оценка лучше, чем никакой. 3. Покажите двойную нагрузку. В переходный период вы обслуживаете две системы. Тикеты по старой не исчезнут. Тикеты по новой появятся. Среднее время решения тикета вырастет. Посчитайте, насколько. 4. Учтите провижининг. Нужно железо? Доставка, настройка, тестирование. Пока серверы не приехали – команда простаивает. Уже полгода ушло – а до миграции ещё не начали. 5. Добавьте обучение. Новая система – новые привычки. Привычка помогает работать быстро. Когда привычку меняешь, человек замедляется. Это не лень – это физиология. Планируйте время на обучение, потому что иначе оно всё равно уйдёт – просто незаметно, в форме ошибок и задержек. Вам не нужно считать зарплаты. Достаточно человеко-месяцев. «Все менеджеры знают, сколько стоит, как это моментально в денежку пересчитать». Так вы не умничаете, но цифры говорят за вас. Найдите союзников Политические игры не выигрываются в одиночку. Кто пострадает от миграции, кроме вас? Отдел продаж, который пользуется дашбордом, сгенерированным из текущей системы. Финансы, которые получают автоматические отчёты. Любой отдел, у которого есть рабочий инструмент, завязанный на вашу систему. Найдите самые болезненные интеграции – желательно те, которыми пользуется человек, стоящий выше инициатора миграции. И скажите: «Эти дашборды сломаются на такой-то срок». Вам не нужно строить коалицию. Достаточно, чтобы пострадавшие знали о проблеме. Они начнут задавать вопросы сами. Не принимайте ответственность за чужое решение Это, пожалуй, самое важное. И самое сложное. Когда вам говорят «переезжайте на Jira», соблазн – взять задачу и тащить. Потому что вы инженер, вы привыкли решать проблемы. Но в этом случае проблема – не ваша. Её создал тот, кто принял решение. Практические шаги: Фиксируйте всё в деловой переписке. Устное «давайте переедем» – это ничего. Письменное «я, Иван Петрович, утверждаю миграцию на Jira в срок до…» – это ответственность. «Я зафиксировал наше решение, что такой-то декларировал…» – ваша страховка. Торгуйтесь. «Я соглашусь, если получу дополнительных людей / дополнительное время / снятие текущих задач». Если вам не дают ресурсы – скажите, что произойдёт: «Среднее время решения тикетов вырастет, мы не сможем отвечать вовремя». Ставьте инициатора в позицию того, кто принимает решение. Не вы решаете мигрировать. Вы описываете последствия. Решение – его. Тяните время (это не саботаж) Внедрение, которое растягивается, теряет поддержку. Продажники, которые лоббировали Jira, не готовы тратить ресурсы на сделку, которая займёт несколько лет. Внутренний спонсор теряет интерес, когда видит, что «быстрая победа» превращается в марафон. Вы не саботируете. Вы честно оцениваете. «Нам нужно оценить объём миграции – для этого нужно…» «Нужно закупить железо – доставка займёт…» «Нужно обучить людей – запланировали…» Каждый шаг – объективная необходимость. Но сумма шагов делает проект менее привлекательным для лоббиста. Кейс из стенограммы: система отчётности В разобранном кейсе была ещё одна деталь: система, которая автоматически генерирует отчёты по производительности сотрудников и отправляет их наверх. Внутри – обработка данных через LLM. При миграции на Jira эту систему нужно переписывать с нуля. А пока она не работает – отчёты не приходят. Или приходят из двух разных источников, и нужна «точка правды»: какая система считает правильно? Это идеальный аргумент. Потому что последствия видны наверху, а не внизу. Руководство перестанет получать привычные данные. И внезапно миграция станет их проблемой, а не вашей. Почему вообще принимаются такие решения Параллельно с разбором кейса сообщество обсуждало системную проблему менеджмента в Казахстане: вузы закрывают набор на управленческие специальности из-за переизбытка менеджеров – при том, что качество менеджмента хромает. «Рынок поощряет лояльных, а лояльные – это родственники», – сформулировал один из участников. Навязанные технические решения – часто симптом этой проблемы. Человек, принимающий решение о миграции, может не иметь технической квалификации для его оценки. Он принимает решение по другим критериям: рекомендация знакомого, красивая презентация от вендора, желание «стандартизировать». Это важный контекст для тимлида: вы боретесь не с глупостью, а с системой, в которой решения принимаются по нетехническим причинам. И поэтому технические аргументы не работают – нужны экономические. Когда бороться не стоит Не всякое навязанное решение – плохое. Иногда миграция действительно нужна. Иногда ваша «идеальная система» – это зоопарк из скриптов на пяти языках без документации, который держится на одном человеке. Честный тест: если автор системы уйдёт завтра, сможет ли команда её поддерживать? Если нет – может быть, стандартное решение не так уж плохо. Бороться стоит, когда: Текущая система работает, задокументирована, поддерживается командой Миграция не несёт экономической выгоды Решение принято по политическим, а не техническим причинам У вас нет ресурсов на миграцию без ущерба текущим задачам Чек-лист тимлида: что делать, когда «сверху» пришло плохое решение Посчитайте объём работы в человеко-месяцах, а не в абстрактных «это сложно» Найдите 3–5 критичных интеграций, которыми пользуется руководство Определите пострадавшие отделы – потенциальных союзников Переведите всё общение в деловую переписку Не принимайте на себя ответственность за решение о миграции Торгуйтесь за ресурсы: люди, время, снятие текущих задач Учтите провижининг, обучение и двойную нагрузку в оценке Честно оцените: может, текущая система действительно хуже? Ваш спокойный сон стоит нескольких часов подготовки. Документ с расчётами – это не бюрократия. Это ваша защита. А вы сталкивались с навязанными техническими решениями? Как боролись – или не боролись? Обсудить можно в Telegram. Эта статья основана на встрече сообщества «Тимлид не кодит» 7 мая 2026 года, где Жахангир разобрал живой кейс миграции на Jira. Контекст о проблемах менеджмента – из инсайтов за 5–11 мая. Присоединяйтесь к обсуждению в Telegram. Теги: менеджмент, тимлид, организация, переговоры ## Заменит ли AI разработчиков: аргументы обеих сторон URL: https://teamleads.kz/articles/zamenit-li-ai-razrabotchikov/ Дата: 2026-04-20 117 AI-агентов пишут код за одного человека. Разбираем, почему это не конец профессии – и почему расслабляться рано. Автор: Сообщество «Тимлид не кодит» Один человек управляет 117 AI-агентами, которые пишут код. Не прототипы, не наброски – готовый, рабочий код. Пост из LinkedIn облетел профессиональное сообщество и вызвал предсказуемую реакцию: одни увидели будущее, другие – очередной хайп. В нашем чате этот пост спровоцировал дискуссию на 300+ сообщений. Не абстрактные рассуждения о «будущем технологий», а конкретный вопрос: если один человек заменяет команду из 117 разработчиков, то что делать остальным 116? Спор обнажил фундаментальный разлом в сообществе: оптимисты верят в масштабирование моделей, скептики – в непреодолимые ограничения архитектуры трансформеров. И у каждой стороны есть аргументы, которые нельзя отмахнуть. «Готовый код – всё понятно» Первая реакция на пост с 117 агентами была ироничной. «Не прототип, не набросок. Готовый код – всё понятно» – моментальное раскусывание маркетинговой обёртки. За громким числом скрывается вопрос, который LinkedIn-пост элегантно обходит: кто несёт ответственность за этот код? Ответ очевиден: тот, кто релизит. И это ключевое наблюдение, которое меняет всю дискуссию. AI может генерировать код. AI не может нести ответственность за продакшн. Между «написать» и «выпустить» – пропасть из тестирования, ревью, понимания контекста системы, оценки рисков. Отсюда родилась первая модель будущего: разработчики не исчезают, а превращаются в SRE нового типа. Их работа – код-ревью, QA, поддержка и принятие решений о том, что именно попадёт в продакшн. Не кодеры, а стражи. Может ли аналитик заменить разработчика? Самый провокационный тезис дискуссии: если AI пишет код, то для валидации достаточно системного аналитика. Логика такая: аналитик умеет писать техническое задание. Если ТЗ достаточно формализовано, то результат можно проверить без понимания реализации – достаточно конвертировать код в артефакт, понятный аналитику. Возражение пришло мгновенно: LLM не знает ничего об изменяющейся системе. Модель видит код, но не видит контекст: какие миграции запущены, какие сервисы деплоятся параллельно, какие договорённости существуют между командами. Человек-разработчик держит этот контекст в голове. Аналитик – нет. AI – тем более нет. Это не вопрос «умности» модели. Это вопрос доступа к информации. Разработчик знает, что вчера коллега начал рефакторинг авторизации, потому что обсудил это в курилке. Модель этого не знает, пока ей не скажут. А кто ей скажет, если разработчика уволили? Математика деградации: почему 90% – это катастрофа Допустим, модель выдаёт 90% хорошего кода за одну итерацию. Звучит неплохо. Но вот незадача: код – это не единоразовое действие. Это итерации. Вторая итерация: 90% от 90% = 81% хорошего кода. Третья: 72,9%. Пятая: 59%. Десятая: 34,9%. Формулировка из дискуссии была грубее: «С каждой итерацией говно будет плодиться. Через 10 итераций там будет одно говно». Это не теоретическое упражнение. Это описание реального рабочего процесса, когда AI дописывает код, сгенерированный AI, который был основан на коде, сгенерированном AI. Каждый слой добавляет технический долг, который модель не осознаёт как долг – для неё это просто контекст. Контраргумент оптимистов: человеческий код деградирует точно так же, просто медленнее. Любой проект без рефакторинга через пять лет превращается в легаси. Вопрос не в том, деградирует ли код – а в скорости деградации и способности это контролировать. Планка человека не так высока Скептики исходят из предположения, что человек-разработчик – это высокая планка. Но так ли это? Провокационный аргумент: трансформеры уже могут то, что люди не могут. AlphaFold получил Нобелевскую премию за предсказание структуры белков – задача, которую десятилетиями не могли решить тысячи учёных. Если архитектура способна на это, то написание CRUD-приложения – задача на порядки проще. Ответ скептиков: белки – это закрытая система с фиксированными правилами. Софт – открытая система с меняющимися требованиями, политическими решениями и человеческими договорённостями. AlphaFold не общается с продакт-менеджером, который меняет требования в пятницу вечером. Но оптимисты парируют и это: средний разработчик тоже не блещет. Код, который пишут 80% программистов в ежедневной работе, – рутина. Формы, API-эндпоинты, миграции, конфигурации. Для этого не нужен искусственный интеллект – достаточно автоматизации с проверкой. Фундаментальный разлом: масштабирование vs ограничения Дискуссия выявила два лагеря, которые говорят на разных языках. Оптимисты верят в масштабирование. Модели становятся лучше с каждым поколением. То, что GPT-3 делал плохо, GPT-4 делает хорошо. То, что GPT-4 делает посредственно, следующее поколение будет делать отлично. Экстраполяция – их главный аргумент. Тренд не сломался ни разу за последние пять лет. Скептики указывают на фундаментальные ограничения. Трансформеры – это архитектура со своими потолками. Они не понимают – они паттерн-матчат. Они не планируют – они предсказывают следующий токен. Увеличение параметров не создаёт понимание, оно создаёт более убедительную имитацию понимания. Требование скептиков: «Источник уровня trust me bro?» Они хотят доказательств, что масштабирование приведёт к качественному скачку, а не количественному улучшению. Оптимисты отвечают: доказательство – сами модели. Каждый релиз – это доказательство. Этот спор не имеет решения в 2026 году. Но у него есть практические следствия. Реальная угроза: не замена, а обесценивание Разработчиков не заменят одномоментно. Это не выключатель «был нужен – стал не нужен». Это постепенный процесс, при котором стоимость определённых навыков падает. Написание бойлерплейта уже стоит меньше, чем год назад. Через год будет стоить ещё меньше. Разработчик, чья ценность – в скорости написания стандартного кода, конкурирует с машиной на территории машины. Это проигрышная стратегия. Что остаётся ценным: Понимание бизнес-контекста и перевод его в технические решения Владение системой целиком – не отдельными файлами, а архитектурой Принятие решений в условиях неопределённости Коммуникация с людьми, которые не знают, чего хотят Ответственность за последствия Иронично: это описание работы тимлида. Не кодера – а того, кто думает и отвечает за результат. Что конкретно делать Дискуссия не дала однозначного ответа на вопрос «заменит ли». Но дала ответ на вопрос «что делать, пока не заменили»: 1. Перестаньте соревноваться с AI в скорости написания кода. Это гонка, которую вы проиграете. Соревнуйтесь в понимании. 2. Учитесь работать с AI, а не против него. «Если реально самому работать, а не запускать автономных агентов – сложно упереться в лимит» – наблюдение из практики. Человек + AI эффективнее, чем человек или AI по отдельности. 3. Инвестируйте в системное мышление. AI плохо контролирует общее направление проекта. Он мечется между подходами, когда в проекте намешано несколько архитектурных стилей. Человек, который держит целостную картину – незаменим. Пока. 4. Не доверяйте AI ответственность. Код-ревью, валидация, принятие решения о деплое – это человеческие функции не потому, что AI не умеет, а потому что кто-то должен отвечать за последствия. 5. Следите за качеством, а не за скоростью. Когнитивный долг – реальная проблема. Чем быстрее вы пишете с AI, тем быстрее теряете понимание собственного проекта. Контролируйте это осознанно. Почему этот спор важен для тимлидов Если вы руководите командой, вопрос «заменит ли AI разработчиков» – не философский. Это вопрос о планировании найма, обучения и архитектуры команды на следующие 2–3 года. Наймёте 10 джунов на бойлерплейт? Через год их работу будет делать один человек с AI. Наймёте двух сильных инженеров, которые понимают систему целиком? Они останутся ценными независимо от того, чья модель будущего окажется правильной. Не ставьте на один сценарий. Стройте команду, которая ценна в обоих. Эта статья основана на дискуссии в сообществе «Тимлид не кодит» 14–20 апреля 2026 года. Полный обзор обсуждений недели – в инсайтах за 14–20 апреля. Присоединяйтесь к обсуждению в Telegram. Теги: AI, карьера, разработка, будущее профессии, тимлид --- # Операционка Рабочие шаблоны для тимлидов: 1-on-1, ретроспективы, постмортемы, рубрика найма, ADR. Открывайте на сайте или через cat в Shell. ## Рубрика найма: оценка разработчика по компетенциям URL: https://teamleads.kz/toolkit/hiring-rubric/ Дата: 2026-06-25 Структурированная рубрика найма: что проверять у джуна/мидла/сеньора, красные флаги, чек-лист решения. Найм под роль, а не ради головы. Найм под конкретную перегруженную роль, а не чтобы «рук стало больше». Решение опирается на рубрику, а не на ощущение «вроде нормальный чувак» – ощущение ловит предвзятость, рубрика ловит кандидата. Что проверяем (по грейду) Компетенция Джун Мидл Сеньор Код / инженерия Базовые структуры, чистый код Декомпозиция, edge-кейсы Архитектура, чужие домены под давлением Система и контекст Учит свой модуль Видит сервис целиком Держит систему + параллельные миграции Самостоятельность Под присмотром Доводит до прода Ставит направление Коммуникация Понятно излагает Аргументирует выбор Влияет через аргументы, а не саботаж Структура интервью (60–90 минут) Знакомство (5 мин) – о роли и команде, честно. Опыт / контекст (10 мин) – реальный кейс из прошлого: какую проблему решал, как. Практика (40–60 мин) – задача близкая к реальной, а не алгоритм в вакууме. Культура / поведение (10 мин) – конфликты, ошибки, работа в неопределённости. Вопросы кандидату (5–10 мин). Поведенческие вопросы (STAR) Расскажи про случай, когда ты ошибся в проде. Что делал? Чему научился? Спорил ли ты с тимлидом/заказчиком о решении? Как разрешал? Был ли момент, когда не хватало контекста? Как доставал? Красные флаги Сваливает все провалы на коллег и «токсичную атмосферу». Технологии выбирает по хайпу, не по задаче. Не может объяснить «почему» за своими прошлыми решениями. Уничижительно о бывших командах. Чек-лист решения Нанимаем под конкретную роль/компетенцию (какую именно?)? Есть дублёр/онбординг на ключевые знания (бас-фактор)? Все интервьюеры сошлись по рубрике, не только по «общему впечатлению»? Что будет через 3 и 6 месяцев – как оценим успех найма? Теги: найм, собеседование, оценка, команда ## Ретроспектива: рабочие форматы URL: https://teamleads.kz/toolkit/retro/ Дата: 2026-06-25 Три формата ретро под разное состояние команды: Start/Stop/Continue, 4Ls, Mad/Sad/Glad. С чек-листом фасилитатора. Ретро без формата превращается в жалобы. Формат держит фокус и заставляет договориться об действиях, а не просто «поговорить». Когда какой формат Состояние команды Формат Спокойный спринт, копим мелочи Start / Stop / Continue Был сложный период, эмоции Mad / Sad / Glad Хотим расти, искать возможности 4Ls (Liked / Learned / Lacked / Longed for) Start / Stop / Continue Каждый заполняет три колонки: Start – что начать делать. Stop – что перестать делать (чаще всего самое ценное). Continue – что работает, не ломать. 4Ls Liked – что понравилось. Learned – чему научились. Lacked – чего не хватило. Longed for – о чём мечтали, но не получили. Чек-лист фасилитатора Безблейм-фрейм с первого слова: разбираем процесс, а не людей. Молчаливым – голос: сначала пишут 5 минут в тишине, потом озвучивают. Группируйте похожее – показывает системное, а не единичные мнения. Голосование за топ-2–3 темы (точечное голосование). Не пытайтесь решить всё. Каждая action item: кто + что + к какому сроку. Без владельца – не действие. В начале следующего ретро – первым делом проверка прошлых actions. Антипаттерны Ретро «для галочки» без действий – команда перестаёт верить в формат. Тимлид защищается от критики. Ваша работа – слушать, не оправдываться. Теги: процессы, ретроспектива, agile, команда ## Постмортем: разбор инцидента без поиска виноватых URL: https://teamleads.kz/toolkit/postmortem/ Дата: 2026-06-25 Шаблон безблейм-постмортема: таймлайн, влияние, корневая причина, действия. Культура «учимся», а не «кто виноват». Постмортем отвечает на вопрос «почему система так себя повела», а не «кто накосячил». Блейм убивает честность – без честоты корневую причину не найти. Ответственность за исправления назначают, наказания – нет. Шапка Дата / длительность инцидента: ___ Серьёзность (SEV): ___ · Затронутые пользователи: ___ Ведущий постмортема: ___ · Дата разбора: ___ Что произошло (1–2 предложения, фактами) Влияние Пользовательское: ___ (доступность, данные, деньги) Бизнес: ___ Таймлайн (по UTC/локальному – выберите одно) Время Событие Кто действовал ___ Обнаружение (как узнали – алерт? клиент?) ___ ___ ___ ___ ___ Восстановление ___ Корневая причина (5 почему) Почему упало? ____ Почему это стало возможным? ____ …продолжайте, пока не упрётесь в систему/процесс, а не в человека. Что сработало хорошо ___ Что пошло не так / где заминка ___ Action items (каждое: кто + что + срок + тикет) ___ – @___ – ___ – #___ ___ – @___ – ___ – #___ Классификация (поставьте галочки) Недостаток мониторинга/алерта Процессуальный разрыв (ручная операция, нет чек-листа) Тестирование/окружение не поймали Изменение без отката / без canary Знание у одного человека (бас-фактор) Принципы Безблейм: «как система позволила этому случиться», а не «кто нажал не туда». Право на ошибку есть; права повторять одну и ту же – нет. Теги: постмортем, инциденты, безблам, надёжность ## ADR: запись архитектурного решения URL: https://teamleads.kz/toolkit/adr/ Дата: 2026-06-25 Шаблон Architecture Decision Record: контекст, варианты, решение, последствия. Лекарство от «почему мы так сделали – никто не помнит». ADR – короткая запись «почему мы выбрали именно так». Документ говорит «что», человек знает «почему», а ADR сохраняет рассуждение, когда человек ушёл. Без ADR через год никто не вспомнит, чем руководствовались, и перепишут всё с нуля. Заголовок ADR-№___: [коротко – какое решение принято] Статус: предложено / принято / устарело · Дата: ___ Контекст Какая проблема, какие ограничения (команда, бюджет, сроки, существующая система, требования безопасности/комплаенса). Фактами, без оценок. Варианты (минимум 2) Вариант Плюсы Минусы / риски A. ___ ___ ___ B. ___ ___ ___ C. (ничего не делать) ___ ___ Решение Выбрали вариант ___, потому что ____. Одна-две фразы, конкретно. Последствия Появляется: ___ (новые возможности, зависимости). Теряется / усложняется: ___. Технический долг, который осознанно берём: ___. Когда пересмотреть: триггер (рост нагрузки ×N, смена команды, …). Принципы Один ADR – одно решение. Короткий (1–2 страницы). «Вариант ничего не делать» – обязательный: он показывает цену изменения. Принятое и устаревшее не удаляем – история важнее «чистоты». Живёт рядом с кодом (repo/docs/adr), а не в чужой вики, которая умрёт. Теги: архитектура, adr, документация, решения ## 1-on-1: шаблон встречи с разработчиком URL: https://teamleads.kz/toolkit/one-on-one/ Дата: 2026-06-25 Рабочая структура еженедельной 1-on-1: повестка, блоки вопросов, чек-лист договорённостей. Не статус-апдейт, а разговор про человека. Еженедельная 1-on-1 – это не статус по задачам и не разбор релиза. Это 25–30 минут про человека: как он, что блокирует, куда растёт. Статусу место в таск-трекере. Каденс Раз в неделю, 30 минут, один на один. Встреча разработчика, не ваша: повестку Mostly формирует он. Не отменяется. Перенос – нормально, отмена – сигнал «ты не в приоритете». Структура (30 минут) 5 мин – как ты вообще? Энергия, настроение, что за пределами работы. Без этого остальное – враньё. 10 мин – его темы. Что болит, что мешает, о чём хочет поговорить. Молчит – задайте открытый вопрос из банки ниже. 10 мин – ваши темы. Обратная связь (сбалансированная), рост, контекст, который ему нужен. 5 мин – договорённости. Кто что делает до следующей встречи. Зафиксируйте. Банка вопросов (когда не о чём говорить) Что тебя сейчас больше всего драйвит? Что – выматывает? Если бы ты мог изменить одну вещь в команде/процессе, что бы? Где ты чувствуешь, что упираешься в потолок? Чего не хватает, чтобы его пробить? С кем из коллег тебе сложнее всего и почему? Какой фидбек ты хотел бы получить, но не получаешь? Антипаттерны Превращать в同步 по задачам – убивает смысл встречи. Копить критику месяцами и вываливать разом. Фидбек – в ту же неделю. Говорить больше, чем слушаете. Цель – услышать, а не доложить. Теги: люди, 1-on-1, обратная связь, мотивация --- # Рецепты агентов Рецепты агентов от сообщества тимлидов Казахстана: скиллы, промпты и харнессы для Claude Code, Cursor и других инструментов. Проверены в работе, добавляются через Pull Request. ## Фасилитатор безблеймового постмортема URL: https://teamleads.kz/agents/postmortem-facilitator/ Дата: 2026-08-01 Агент ведет разбор инцидента по шаблону сообщества: собирает таймлайн, докапывается до системной причины и останавливает разговор, когда тот сползает в поиск виноватых. Автор: Сообщество «Тимлид не кодит» Инструменты: Claude Проверено: Claude Opus 5, август 2026 Зачем Безблеймовый постмортем ломается в одном и том же месте: через двадцать минут разговор превращается в «кто выкатил». Человеку-фасилитатору неудобно останавливать коллег, особенно если в комнате есть кто-то старше по должности. Агенту неудобно не бывает. Он безжалостно возвращает разговор к системе и переформулирует обвинения в вопросы об устройстве процесса. Когда применять Разбор прода после инцидента, особенно если инцидент задел людей и разговор будет нервным Черновик постмортема, который надо превратить в документ до встречи Ретроспектива провального релиза Не применять: если инцидент связан со злым умыслом или нарушением правил. Это не постмортем, это другой разговор, и агент тут не помощник. Рецепт Ты фасилитатор безблеймового постмортема. Ты не участник и не эксперт по системе. Твоя единственная задача: провести разбор так, чтобы на выходе был документ, а не обиженные люди. Инцидент: {{ЧТО СЛУЧИЛОСЬ, одно предложение}} Дата и длительность: {{КОГДА, СКОЛЬКО ДЛИЛОСЬ}} Кто участвует в разборе: {{РОЛИ, без имен}} Порядок работы, строго по шагам, не забегая вперед: ШАГ 1. Таймлайн. Собери события по минутам: что произошло, когда заметили, кто что сделал, когда починили. Спрашивай про пробелы: «между 14:10 и 14:40 ничего не записано, что происходило?». Не переходи дальше, пока таймлайн рваный. ШАГ 2. Влияние. Сколько пользователей, сколько денег, какие обещания нарушены. Требуй цифры. «Много» не принимается. ШАГ 3. Причина. Задавай «почему» до системного уровня, минимум пять раз. Останавливайся только тогда, когда ответ звучит как свойство системы или процесса, а не как свойство человека. ШАГ 4. Действия. Каждое действие: что конкретно, кто владелец, к какому сроку, как поймем что помогло. Действия вида «быть внимательнее» и «добавить в чек-лист пункт» отклоняй как нерабочие. ШАГ 5. Документ. Собери все в постмортем по разделам: таймлайн, влияние, корневая причина, что сработало, что нет, действия. ПРАВИЛО, которое важнее всех шагов: Как только в разговоре появляется человек как причина, останавливай и переформулируй вслух. Примеры: «Вася выкатил без тестов» → «релиз можно выкатить в обход тестов. Почему?» «забыли откатить» → «откат не был очевидным следующим шагом. Что этому мешало?» «не заметили алерт» → «алерт не привел к действию. Куда он пришел и кому?» Делай это каждый раз, даже если уже делал пять минут назад. Не извиняйся. Начинай с ШАГА 1. Как запустить На встрече: откройте чат на общем экране, назначьте человека печатать за всех. Агент задает вопрос, команда отвечает вслух, печатающий фиксирует. Собранный документ на выходе уже готов к правке. Асинхронно: скиньте агенту сырую переписку из канала инцидента и попросите пройти шаги по ней. Он найдет дыры в таймлайне лучше человека, потому что читает все сообщения подряд и не устает. Структуру документа и разделы берите из шаблона постмортема. Что проверять за агентом Пять «почему» уводят в одну ветку. Классическая слабость метода, и агент ее наследует. У серьезного инцидента причин обычно несколько. Просите отдельно: «дай три независимые ветки причин, не одну цепочку». Он принимает цифры на веру. Скажете «затронуло примерно тысячу пользователей» – запишет как факт. Влияние считайте сами, по метрикам. Он предлагает шаблонные действия. «Добавить мониторинг», «улучшить документацию» приходят почти в каждом разборе. Отбраковывайте все, у чего нет владельца и проверяемого признака. Он не знает вашей политики. Что можно писать в постмортем, а что нельзя выносить за пределы команды, решает человек. Перечитайте документ перед тем, как класть его в общую вики. Теги: постмортем, инциденты, агенты ## Подготовка к 1-on-1 за десять минут URL: https://teamleads.kz/agents/one-on-one-prep/ Дата: 2026-08-01 Агент читает ваши заметки по разработчику и собирает повестку встречи: что осталось с прошлого раза, какие темы назрели, какие вопросы задать и о чем лучше промолчать. Автор: Сообщество «Тимлид не кодит» Инструменты: Claude, Claude Code Проверено: Claude Opus 5, август 2026 Зачем Проблема еженедельных 1-on-1 не в шаблоне, а в подготовке. Шаблон есть у всех. Открывается он за три минуты до встречи, и разговор скатывается в статус по задачам. Агент берет то, что у вас и так лежит – заметки с прошлых встреч, обрывки в календаре, пару строк в личных записях – и превращает в повестку. Десять минут вместо часа, который вы все равно никогда не тратите. Когда применять Еженедельная встреча с разработчиком, когда за неделю накопилось слишком много и слишком мало одновременно Первый 1-on-1 с новым человеком в команде Разговор, к которому вы внутренне не готовы: увольнение из проекта, отказ в повышении, конфликт в команде Не применять: вместо разговора. Агент готовит вас к встрече, а не проводит ее за вас. Рецепт Ты помогаешь тимлиду подготовиться к встрече один на один с разработчиком. Ты не психолог и не коуч. Ты собираешь повестку и вопросы. Человек: {{ГРЕЙД, сколько в команде, над чем работает}} Что было на прошлой встрече: {{ЗАМЕТКИ, как есть, можно обрывками}} Что произошло за неделю: {{ФАКТЫ: релизы, инциденты, конфликты, отпуска, что угодно}} Что меня беспокоит: {{ЧЕСТНО, одно-два предложения. Можно «ничего»}} Собери: 1. НЕЗАКРЫТОЕ. Что обещали друг другу в прошлый раз и чем это кончилось. Если из заметок не видно, так и напиши: «непонятно, спросить прямо». 2. ПОВЕСТКА, максимум четыре пункта, в порядке важности. По каждому: зачем поднимаем и чем хотим закончить. Пункты вида «обсудить задачи» не предлагай. 3. ВОПРОСЫ, 5-7 штук. Только открытые. Без «все ли хорошо» и «есть ли блокеры»: на них отвечают «да» и «нет», и встреча умирает. Формулируй так, чтобы человеку было проще ответить честно, чем удобно. 4. О ЧЕМ ЛУЧШЕ ПРОМОЛЧАТЬ на этой встрече и почему. Один-два пункта. 5. КРАСНЫЕ ФЛАГИ. Что в моих заметках выглядит тревожнее, чем я, похоже, это воспринимаю. Если ничего не видишь, честно скажи «ничего не вижу» и не выдумывай. Пиши коротко. Это шпаргалка, которую я открою одной рукой за минуту до встречи. Как запустить Разово: скопируйте промпт, вставьте заметки, получите повестку. Постоянно: держите на каждого человека один файл с заметками и дописывайте его после каждой встречи. Тогда в Claude Code достаточно сказать «подготовь меня к 1-on-1 с ним по этому файлу», и агент видит всю историю, а не последнюю неделю. Через полгода такой файл становится самым ценным документом тимлида. Структура самой встречи – в шаблоне 1-on-1. Что проверять за агентом Заметки о людях – чувствительные данные. Это главное предупреждение рецепта. Прежде чем отправлять текст про живого коллегу во внешнюю модель, посмотрите на политику компании и уберите то, что не должно уезжать наружу. Имена сокращайте до инициалов. Для многих команд правильный ответ – локальная модель. Он придумывает драму. Попросили красные флаги – найдет, даже если их нет. Пункт «если ничего не видишь, так и скажи» в промпте стоит не просто так, но срабатывает не всегда. Не верьте выводам о настроении человека, сделанным по трем строчкам заметок. Он не знает контекста отношений. Совет «поднимите тему зарплаты» может быть ровно тем, чего делать нельзя, и агент об этом не догадывается. Повестка – это гипотеза. Если человек с первой минуты говорит о другом, выкидывайте шпаргалку. Встреча про него, а не про ваш план. Теги: 1-on-1, люди, агенты ## Мок-интервью по рубрике найма URL: https://teamleads.kz/agents/mock-interview/ Дата: 2026-08-01 Агент проводит тренировочное собеседование на позицию разработчика или тимлида и выставляет оценку по рубрике найма сообщества. Работает как для кандидата, так и для интервьюера. Автор: Сообщество «Тимлид не кодит» Инструменты: Claude, Claude Code Проверено: Claude Opus 5, август 2026 Зачем Мок-интервью просили на встрече 3 июня: тренироваться негде, а живого интервьюера под рукой нет. Агент закрывает первый круг. Он не заменит человека на финальном собесе, но снимает главную проблему подготовки – отсутствие оппонента, который дожимает уточняющими вопросами. Второй сценарий, менее очевидный. Тимлид гоняет через агента себя в роли интервьюера: агент играет кандидата, а вы тренируете вопросы. Хорошо ловит собственные плохие формулировки. Когда применять Готовитесь к собеседованию и хотите прогнать пару кругов без свидетелей Составили новые вопросы для найма и хотите проверить, что они вообще работают Нужно откалибровать грейд: агент дает оценку по рубрике, а не «понравился/не понравился» Не применять: как финальный фильтр при реальном найме. Оценка агента – тренажер, а не решение о человеке. Рецепт Ты проводишь техническое собеседование. Роль: {{РОЛЬ, например Senior Backend Developer}}. Грейд, на который претендует кандидат: {{ГРЕЙД}}. Контекст компании: {{2-3 предложения про продукт, стек и размер команды}}. Правила ведения: 1. Задавай ровно один вопрос за раз. Дождись ответа. Никаких списков из пяти вопросов. 2. После каждого ответа задай минимум один уточняющий вопрос вглубь. Дожимай до границы знаний, а не до первого правильного слова. 3. Не подсказывай и не оценивай по ходу. Никаких «отлично!» и «хороший ответ». Реагируй нейтрально и переходи дальше. 4. Держи баланс: примерно 60% времени на технику, 40% на реальный опыт и решения. Спрашивай не «что такое X», а «расскажи, где ты применял X и что пошло не так». 5. Всего 8-10 вопросов, потом останавливайся и переходи к разбору. Разбор в конце: - По каждой компетенции: оценка (не тянет / джун / мидл / сеньор) и цитата из ответа кандидата как обоснование. Без цитаты оценку не ставь. - Красные флаги, если были. Отдельно отметь, где кандидат уверенно говорил неправду: это опаснее, чем незнание. - Три конкретные темы для подготовки, в порядке приоритета. - Итог: на какой грейд наговорил и чего не хватило до следующего. Начни с первого вопроса. Ничего не объясняй перед стартом. Для режима «я интервьюер» замените первый абзац: Ты кандидат на позицию {{РОЛЬ}}, грейд {{ГРЕЙД}}. Отвечай как живой человек: местами неточно, иногда уходя в сторону, иногда переспрашивая. Не выдавай идеальные ответы из учебника. Я интервьюер, веду собеседование. В конце скажи, какие мои вопросы были расплывчатыми или наводящими. Как запустить Скопируйте промпт, подставьте роль, грейд и контекст компании, отправьте в чат. Отвечайте голосом или текстом, как удобнее. Один прогон занимает 20-30 минут. Чтобы оценка легла на общую шкалу, приложите к промпту рубрику найма целиком – кнопка «Скопировать» на той странице отдает ее в markdown. Тогда агент будет оценивать по вашим критериям, а не по своим. В Claude Code удобно положить промпт в .claude/skills/mock-interview/SKILL.md и вызывать командой. Что проверять за агентом Он мягкий. Модель по умолчанию завышает оценку и находит хорошее там, где его нет. Если получили «сеньор» с первого прогона, не радуйтесь: попросите пересобрать разбор с установкой «занижай при сомнениях, отсутствие доказательства считается отсутствием навыка». Он не знает ваш рынок. Грейды в Казахстане и грейды в обучающей выборке модели – разные вещи. Без приложенной рубрики оценка поедет. Он додумывает вашу компанию. Если контекст задан в двух словах, агент придумает стек и масштаб сам и будет спрашивать про несуществующие проблемы. Цитаты проверяйте. В разборе агент иногда приписывает кандидату слова, которых тот не говорил. Это ровно та галлюцинация, из-за которой такой оценке нельзя доверять при реальном найме. Теги: найм, собеседования, агенты --- # Витрина проектов – Тимлид не кодит Проекты участников сообщества тимлидов Казахстана. Стартапы, open-source, блоги и инструменты от технических лидеров. ## NetCoreKalkan URL: https://teamleads.kz/showcase/netcorekalkan/ Дата: 2026-06-25 Библиотека для работы с криптопровайдером АО "НУЦ" NetCoreKalkan Проект: https://github.com/greident/NetCoreKalkan Автор: Рамазанов Адильбек канонизация). KalkanCore — REST-эндпоинты crypt/SignXml, crypt/SignWsse, crypt/SignWsseRaw, crypt/verify/xml, crypt/verify/xml/base64. Деплой через Docker (docker-compose.yml), CI на GitLab. Важный момент по безопасности Verify* валидирует входящие запросы, поэтому trust-валидация обязательна (fail-closed). Без trust-стора проверяется только криптоматематика — самоподписанный сертификат с поддельным IIN/BIN прошёл бы как валидный. Это закрыто ChainValidator. Детали и открытые риски (GOST-2004 не покрыт тестом, hash-алгоритм OCSP CertID не подтверждён против живого ответчика) — в SECURITY_VALIDATION.md. Теги: Open Source, Библиотека ## NKalkan URL: https://teamleads.kz/showcase/nkalkan/ Дата: 2026-05-24 Библиотека для работы с криптопровайдером АО "НУЦ" KalkanCrypt Проект: https://github.com/kant2002/NKalkan Автор: Андрій Курдюмов Кроссплатформенная поддержка для криптопровайдера АО “НУЦ” KalkanCrypt в .NET. Данная библиотека использует C API, в том числе на Windows, что позволяет иметь общее API на всех платформах которые поддерживает KalkanCrypt. Данная библиотека также распространяется через Nuget для удобстав разработчиков. Бинарные файлы KalkanCrypt не в ходят в комплект поставки и распространяются АО “НУЦ” самостоятельно. Теги: Open Source, Библиотека --- # Инженерные задачки и головоломки Инженерные задачки, головоломки и кроссворды от сообщества тимлидов Казахстана: простые числа, магические квадраты, судоку и разборы решений. ## Фигураның ауданы URL: https://teamleads.kz/fun/shape-area/ Геометрическая задача на площадь: фигура из двух квадратов со сторонами 8 и 10. Найдите площадь закрашенной области. Инженерная головоломка сообщества тимлидов Казахстана. Суретте қабырғалары сәйкесінше 8 және 10 болатын екі шаршыдан тұратын фигура көрсетілген. Көлеңкеленген фигураның ауданын табыңыз. ## Сиқырлы квадраттар URL: https://teamleads.kz/fun/magic-square/ Магические квадраты 3×3 и 6×6: соберите квадрат, где суммы по строкам, столбцам и диагоналям равны. Инженерная головоломка сообщества тимлидов Казахстана. Сиқырлы квадрат – бұл ұяшықтарына сандар жазылған квадрат, онда әрбір қатардағы, әрбір бағандағы және екі диагональдағы сандардың қосындылары бірдей болады. Суретте көрсетілген жасыл 3×3 квадраттардан осындай 6×6 өлшемді сиқырлы квадрат құрастыруға болады. Тексеріп көріңіз! Қызыл 3×3 квадраттың ұяшықтарын былай толтырыңыз: а. қызыл квадраттың өзі сиқырлы болсын; б. бүкіл үлкен 6×6 квадрат та сиқырлы болсын. ## «Жай сандар мен квадраттар» кроссворды URL: https://teamleads.kz/fun/prime-numbers/ Математический кроссворд с простыми числами и квадратами: инженерная головоломка от сообщества тимлидов Казахстана. Жай сандар мен квадраттар кроссворды. Көлденеңінен: a. Ең кіші екі таңбалы жай санның квадраты c. Соңғы цифры түбірі цифрларының қосындысына тең квадрат d. Цифрларының қосындысы түбірі цифрларының қосындысына тең квадрат f. Квадрат болып табылатын ең үлкен үш таңбалы сан h. Алғашқы екі цифрын орын алмастырғанда да жай болып қалатын жай сан i. Көлденең d-ден цифрларын ауыстыру арқылы алынатын жай сан l. Тігінен q санының квадраты m. Екінші цифры 8-ге тең жай сан o. Бірінші және соңғы цифрлары бірдей, тігінен k-ден 70-ке үлкен жай сан q. Жай сан; оның бірінші цифры қалғандарының қосындысына тең s. Соңғы екі цифры бірдей квадрат t. Тігінен l-ден 100-ге үлкен жай сан u. Алғашқы екі цифрының қосындысы үшінші цифрына тең жай сан Тігінен: a. Көлденең f-тегі сияқты дәл сол цифрлармен жазылатын квадрат b. Бірінші және соңғы цифрлары бірдей жай сан c. Бірінші цифры түбірі цифрларының қосындысына тең квадрат e. Тігінен d-тегі сияқты дәл сол цифрлармен жазылатын квадрат g. Көлденең i санының квадраты h. Алғашқы екі цифры бірдей квадрат i. 1 цифрымен басталып, 1 цифрымен аяқталатын жай сан j. Тігінен b-ден екінші және үшінші цифрларын ауыстыру арқылы алынатын жай сан k. Екінші цифры 1-ге тең жай сан n. Бірінші цифры екіншісінен екі есе үлкен жай сан p. Алғашқы екі цифры бірдей жай сан q. Көлденең t-ден 10-ға кіші жай сан r. Көлденең a-дан 6-ға үлкен жай сан --- # Сервисы и разделы сайта ## Paste URL: https://teamleads.kz/paste/ Поделитесь кодом, логом, конфигом или markdown короткой ссылкой – без регистрации и на 30 дней ## Зарплаты в IT Казахстана URL: https://teamleads.kz/salary/ Зарплаты в IT Казахстана по грейдам, ролям и городам: медиана, среднее, премия за ремоут и распределение. Живые данные сообщества techinterview.space, нетто/мес в тенге. ## Поиск URL: https://teamleads.kz/search/ Поиск по материалам сообщества «Тимлид не кодит» – через офлайн-ассистента Claude с полнотекстовым поиском по статьям, встречам и инсайтам. ## Спросить анонимно URL: https://teamleads.kz/anon/ Задайте вопрос в чат сообщества «Тимлид не кодит» анонимно: форма или бот, модерация админом, публикация без автора. Для тем, которые не задать при коллегах и руководителе. ## Терминал сообщества – Shell Mode URL: https://teamleads.kz/shell/ Браузерный терминал «Тимлид не кодит»: навигация по сайту (ls, cd, find), зарплаты в IT Казахстана, отзывы о компаниях, тимлид-симулятор, судоку и инженерные задачки. ## Что обсудить дальше? URL: https://teamleads.kz/questions/ Бэклог тем для обсуждения на встречах сообщества «Тимлид не кодит»