Fedkin is thinking

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

Ну мы вроде договорились — когда сделаете задачку? — в четверг ... наступает четверг — привет, доделали? — да — а где можно потыкать? — ну мы код со своей стороны написали, передали в тестирование Как бы это глупо ни выглядело, а ситуация реальная:) Даже слово "сделать" разные люди могут интерпретировать по разному. Поэтому если у тебя возникает подозрение, что тебя могли не так понять, переспроси то, как ты понимаешь договореннсть, только другими словами — когда сделаете задачку? — в четверг — то есть в четверг будет на проде и сможем пользоваться? — нууу, не совсем ... передоговариваются на другую дату — Это актуально примерно для любых взаимодействий: • "хочу роста" — зарплаты? грейда? экспертизы? ответственности? • "я перегружен" — не хватает времени? слишком много параллельных задач? постоянно дергают? • "возьми эту задачку на себя" — написать код? организовать работу? отвечать за результат целиком? • "всё согласовано" — все сказали да? или просто никто явно не возразил?

Пару месяцев назад я ходил на конфу Тинька, посвященную в основном GenAI в поддержке В одном из докладов был интересный подход, как можно собирать контекст для агентов, если он разбросан по куче разных мест (в т.ч. головам людей) — Проблема формулируется примерно так: операторы поддержки отвечают пользователем на основе базы знаний. Но... много контекста живет еще в каких-то левых пдфках, чатах, таблицах, неявных договоренностях, опыте операторов и тд При этом качество агента = качеству контекста. Если агенту явно не подложить весь этот неявный контекст, он не будет хорошо работать Встает вопрос — как этот контекст собрать — Предлагается такой подход: 1. Берем нашу базу знаний 2. Ставим агента, который смотрит на поток обращений и ответов операторов. Этот агент пытается пруфануть ответ оператора какой-то инструкцией из БЗ 2.1. Пруфануть получилось => отлично, контекста хватает 2.2. Не получилось => оператор ответил на основе какого-то знания, которого нет в базе. Заводится задачка на бизнес-эксперта, мол было такое-то обращение и такой-то ответ, текущих инструкций из БЗ не хватает, нужно добавить новую То есть собирается feedback-loop между потоком, агентом и бизнес-экспертом, который позволяет обогащать базу знаний, и привести ее к виду, где на каждое обращение можно ответить правилом/инструкцией из БЗ — К чему это я все?) Как будто похожий подход можно применить к разработке. Аналогии примерно такие: • тикет в поддержку => тикет с задачкой • ответ оператора => пулреквест с кодом • база знаний операторов => дока к системе • бизнес-эксперт => разработчик То есть ставим агента, который проходится по задачкам и пулреквестам к ним, пытается запруфать, почему надо было сделать именно так на основе документации, получилось => отлично, не получилось => заводится таска на разработчика, что надо обогатить доку Что думаете? Мб кто то уже пробовал похожее

Первый шаг к хорошей техностратегии Команда упорно работала 3 месяца и подняла аптайм системы с 99.9% до 99.99%, перепилив архитектуру сервиса, из-за которого еженедельно падали на 10 минут. Молодцы конечно, а это точно кому-то было нужно? Вполне может оказаться, что бизнесу было ок и с этим 10минутным даунтаймом и "ваще на че вы потратили 3 месяца???" — Любая система обладает набором свойств: надежность, секьюрность, скорость доставки фич, масштабируемость, ... Они конкурируют за один и тот же ресурс — твое время. Вкладываясь в одно, ты по определению недоинвестируешь в другое Поэтому главный вопрос — во что вкладываться. Мне нравится такой фреймворк (возможно у него даже есть название): • Выписать все свойства, которые для твоей системы имеют значение • Вместе с бизнесом отранжировать их • Выделить топ 3 — туда вкладываемся. Остальным сознательно жертвуем Самый важный момент, что ранжировать надо вместе с бизнесом. В моменте может быть нужна скорость выкатки фич, и нам ок осознанно пожертвовать аптаймом. Иногда же бывает известно, что в следующем полугодии к нам заезжает крупный клиент, и надо бросить все силы на то, чтобы сделать возможным масштабирование под него После того как фокусы понятны, думаешь какие проекты нужны, чтобы прокачать эти свойства системы. И получившиеся технические проекты уже будут иметь понятное бизнес-велью, которое легко защитить

Продукт, тех и взаимопонимание Уверен, все были свидетелями обсуждений где продакт говорит про пользовательский путь, ценность и сроки, а разработка про какие-то мистические "сущности", апишки и очереди. Вроде все всё правильно говорят, но чето обсуждение не двигается На помощь приходят хорошие практики типа ubiquitous language, event storming, user story mapping, ... ... и прототипирование. Год назад я писал пост, что один из классных методов борьбы с неопределенностью — это взять самое простое и логичное решение, покрутить его, собрать фидбек, отправиться на следующую итерацию Сейчас прототипировать стало очень дешево. Поэтому если у тебя есть непонятный проект с кучей неопределенности, возможно вместо того, чтобы неделями на грумингах обсуждать требования толпой в 10 человек, имеет смысл потратить пару дней на вайбкод-поделку, и позволить пройти полный пользовательский путь всем заинтересованным лицам. Затем собрать фидбек и идти в нормальное решение Последнее время активно применяю с командой, работает офигенно ВАЖНО!!! • прототип может быть немасштабируемым, несекьюрным, непроизводительным — это окей, его задача снять продуктовую неопределенность • поэтому не забудь его выкинуть, и нормально продумать НФТ для целевого решения

У меня иногда возникает желание почитать что-то эдакое забористое про бэкенд И если бы меня попросили порекомендовать что-то русскоязычное по теме, я бы порекомендовал канал Лёши Рыбака (многие из вас его знают по курсам по сисдизу devhands) Леша делает классные разборы: - PostgreSQL на 800млн пользователей от OpenAI — что с ним не так https://t.me/rybakalexey/402 - SPDY, QUIC, HTTP/2 и HTTP/3: кратко: https://t.me/rybakalexey/479 - Бенч-порн: HAProxy vs Angie: https://t.me/rybakalexey/289 И пишет про насущные темы без булшита: - Фриз найма и что на рынке: https://t.me/rybakalexey/514 - Про «пузырь в AI» и «несерьезность» кодинга с агентами: https://t.me/rybakalexey/457 - Критика исследования Гарварда про AI https://t.me/rybakalexey/461 Рекомендую начать с первой статьи про постгрю. Мне всегда интересно, что под капотом у таких неконвенциональых решений типо постгри почти на лярд юзеров:)

Длиннопост про сон 50 реакций набрали оч быстро, поэтому ловите! Важное уточнение: причиной плохого сна могут быть конкретные заболевания • апноэ • синдром беспокойных ног • гормональные сдвиги / дефициты витаминов Поэтому по-хорошему сначала надо сходить к врачу и удостовериться, что у тебя с этим все норм Далее речь про мой опыт. Показатели сна трекаю кольцом oura, неплохо отражает реальную картину Низкое влияние • Витамины Магний, железо, D3 — эффекта не было, т.к. не было больших дефицитов • Бады l-теанин, глицин, ашваганда, валериана — легкий седативный эффект, но не сильно заметно • Ложиться рано (23:00 или раньше) Не мое, почти всю жизнь ложился в час или позже • Тяжелое одеяло Есть такие одеяла, которые весят по 10кг (перестилать постель тот еще ад). Прикольно, но эффекта не заметил Среднее влияние • Беруши Помогало не просыпаться, когда в соседней квартире кто то просыпается раньше и начинает шуметь • Блэкаут шторы Хорошо помогает, когда просыпаешься посреди ночи и надо обратно заснуть. Если в комнате будет светло, тяжелее уснуть обратно • Силовые нагрузки На сам процесс сна влияния не заметил, но засыпаешь сильно быстрее. Важно, чтобы было не близко ко сну, а то эффект будет противоположный • Прогулки перед сном Влияет, но не сильно. Спишь чуть крепче Высокое влияние • Отказ от кофеина Мой tier s. Кофе/энергосы выпитые даже до 12 дня на меня прям плохо влияют — спать начинает хотеться сильно позже, чем надо • Алкоголь В ночь после посиделок/тусовок сон ужасный, что по ощущениям, что по показателям • Не думать про что то сложное ~за час до сна И куда-то в заметки выписывать, если что-то крутится в голове. Тоже отлично влияет • Раскатываться на валике Помогает расслабить мышцы шеи, спины, ног. Оч помогает как засыпать, так и поддерживать сон • Стабильное время подъема Не обязательно супер рано, просто в одно и то же время. Это + факторы выше = начинаешь и засыпать в одно и то же время • Дефицит калорий Очень плохо влияет на сон. Помогало переносить бОльшую часть калорий ближе к вечеру и ужинать "медленными" белками и углеводами — Если суммаризировать, то что сейчас использую на постоянной основе: • Вставать +- в одно и то же время • Силовые нагрузки утром • Отказ от кофеина • Раскатываться на валике перед сном • За час до сна не думать о чем-то сложном + выписывать мысли • Блэкаут шторы В выходные чуть продалбываюсь и позволяю себе лечь/встать попозже

Есть простая ловушка, в которую легко попасть, если тебе нравится твоя работа - начать слишком сильно в нее вкладываться и забивать на остальное Пока всё получается - кайф, ты растешь, получаешь постоянное позитивное подкрепление, вкладываешься еще больше Но как только начинаются первые проблемы, мозгу начинает казаться мол вся жизнь говно. И формально это правда, если работа занимает большую часть жизни Поэтому в какой-то момент более эффективной стратегией становится вкладываться не в работу, а в остальные сферы жизни: хороший сон, спорт, хобби, встречи с друзьями. Если у тебя помимо работы есть много всего хорошего/приятного, устойчивость сильно выше — Сам я дольше всего разбирался со сном: несколько лет спал по 5-6 часов урывками, сейчас 7-8 достаточно качественно Накидаете 50 реакций - расскажу, что помогло, а что нет

Как чуть меньше страдать от нейрослопа Или небольшой полезный тех, который ты можешь сделать за пару дней Давеча я писал, что агенты без должного контекста о системе склонны к локально оптимальным решениям. Это часто приводят к: • нарушению направления зависимостей в коде • смешиванию доменной логики и инфраструктурной • странному неймингу и расположению классов Хорошая новость — многое из этого можно ловить детерминированными тестами Есть прекрасные инструменты, как например ArchUnit для Java (если знаете похожие инструменты для других языков, пишите в комменты), которые позволяют писать декларативные тесты на архитектуру приложения: Домен не должен зависеть от инфры: noClasses() .that().resideInAPackage("..domain..") .should().dependOnClassesThat() .resideInAPackage("..infrastructure.."); In-порты называются ...UseCase classes() .that().resideInAPackage("..port.in..") .should().haveSimpleNameEndingWith("UseCase"); Все порты должны быть интерфейсами: classes() .that().resideInAnyPackage("..port.in..", "..port.out..") .should().beInterfaces(); Потратив пару дней на обдумывание и написание таких правил в паре с агентом, можно заметно увеличить качество летящих в тебя пулреквестов, потому что они будут корректны как минимум по структуре. По ходу движения список правил может дополняться Как уже многие писали, разработка с агентами не привносит каких-то кардинально новых принципов, а только усиливает значимость старых добрых бест-практисов p.s.: зачем эти детерминированные проверки, если я могу дать агенту правила в виде текста: • промпты не дают гарантий • не проверяют уже написанный код

Несколько избитая тема, но мне кажется очень красивой идея, которая стоит за structured output в современных ллмках Задача — пользователь передает json-схему, нужно сгенерировать ответ строго по переданной схеме 1. Наивный вариант Подложить схему в контекст: ... Return a JSON object that strictly matches the following schema: { "type": "object", "properties": { "status": { "enum": ["SUCCESS", "FAILED"] } }, "required": ["status"], "additionalProperties": false } Будет ли работать? Да, в большинстве случаев. Но без каких либо гарантий, что схема в итоге будет корректная 2. Добавляется constrained decoding LLM генерирует ответ токен за токеном, на каждом шаге строя распределение вероятностей: "{" = 0.75 "status" = 0.20 ":" = 0.04 "answer" = 0.01 А дальше в процесс вмешивается constrained decoding Из json-схемы строится контекстно-свободная грамматика (CFG), которая позволяет понять, какие продолжения ответа в текущий момент всё еще могут привести к валидному результату Например, для схемы выше грамматика могла бы выглядеть как-то так: root ::= "{" ws "\"status\"" ws ":" ws status ws "}" status ::= "\"SUCCESS\"" | "\"FAILED\"" И, согласно грамматике, инференс-движок накладывает маску на распределение вероятностей следующего токена "{" = 0.75 "status" = 0.20 ":" = 0.04 "answer" = 0.01 Превращается в "{" = 0.75 "status" = 0 ":" = 0 "answer" = 0 Сгенерили { — "status" = 0.6 ":" = 0.3 "answer" = 0.1 Превращается в "status" = 0.6 ":" = 0 "answer" = 0 Сгенерили {"status" ... и так далее — С относительно небольшим оверхедом это позволяет генерить ответ, строго соответствующий схеме

Если ты слишком хорошо решаешь проблемы — возможно, ты решаешь не те Пост по мотивам одного из худших полугодий на работе:) Когда всё вокруг горит, мы начинаем преувеличивать значимость каждой конкретной проблемы. Каждая проблема кажется той самой, что нужно решить прямо сейчас. Естественная реакция на такое — сделать хоть что-то, что продвинет ситуацию вперед • Команды не договорились — синхронизировать • Сроки едут — заовертаймить • Где-то возник затык — лично прийти разблокировать ... Это дает ощущение движения и контроля — ты же что-то делаешь, постоянно кому-то помогаешь, с каждым разом все лучше и быстрее решаешь проблемы. Становишься эдаким эффективным пожарным. Результат у этого всегда один — выгорание и демотивация Что делать — вы и без меня знаете: остановиться и позадавать себе вопросов • А почему проблема дошла до меня? • Почему глобально система допускает возникновение таких проблем? • Что сделать, чтобы починить корневую причину таких проблем? В условиях горящих сроков и давления такое бывает сделать правда сложно, но нужно сделать волевое усилие и "zoom-out"-нуться Поэтому если ты N-ый раз решаешь одну и ту же проблему, подумай, ту ли проблему ты решаешь

Очень грубо инженеров можно классифицировать на два типа: 1. Те, кто работает с техническими проблемами проактивно: • Увидел плавное повышение cpu usage на БД => раздебажил из-за чего, добавил нужных индексов, предотвратил инцидент • Увидел, что новая функциональность в модуль добавляется очень странным образом => инициировал и довел до конца рефакторинг, благодаря этому крупный проект сошелся в срок • Сделал удобные алерты, что позволило видеть проблему раньше пользователей и предотвращать инциденты 2. Те, кто работает с техническими проблемами реактивно: • TTM фичей вырос в два раза, постоянные баги => только тогда начинаем рефакторинг • Количество инцидентов стало совсем неприемлемым => только тогда инициируем проект по стабилизации (да, не существует чистых типов 1 и 2, это всегда спектр, и всегда нужно уметь работать в обоих режимах) Но в чем неприятный парадокс — признание за технический вклад в основном получают люди, работающие во втором режиме Почему так происходит? Потому что для наблюдателей есть прозрачная логическая цепочка: что-то сломалось, конкретный человек это починил, он молодец Если же чинить проблемы проактивно, то со стороны может показаться, мол ничего особенного, все так и должно работать — фичи делаются быстро, система работает стабильно Поэтому очень важно для всех опрозрачивать эту логическую цепочку: "что бы произошло, если бы мы не сделали эту техническую доработку". Да, это сложно. Но оно того стоит Хороший руководитель безумно ценит людей, которые самостоятельно предупреждают проблемы. И задача руководителя — помочь опрозрачить такой вклад сотрудника для остальных

Разработка фичей без достаточной экспертизы в системе зачастую превращается в набор "локально-оптимальных" решений: здесь добавили ифчик, здесь протянули новую зависимость, здесь скопипастили похожий код, здесь обошли существующую точку расширения Каждое такое решение обычно выглядит норм в моменте — оно закрывает задачу, проходит тесты, не выглядит совсем плохо на ревью Проблема начинается, когда такие решения последовательно наслаиваются друг на друга. Это приводит к architecture drift: фактическая архитектура системы постепенно отклоняется от той, которая была задумана С агентской разработкой принципы те же — если у агента нет достаточного контекста о системе, он будет стараться делать минимальные локальные изменения, которые приведут к решению задачи. Только с агентами это все происходит быстрее Главная проблема в том, что самая полезная архитектурная экспертиза обычно живет не в документации, а в головах людей, которые годами работали с системой. Они держат огромный набор фактов о том, почему сделано так, как это развивать, как точно делать не надо и т.д. И честно говоря, я пока не видел чтобы такая экспертиза была в достаточной степени оцифрована — всегда остается много вещей, которые живут только в чьей-то голове. В таком сетапе агенты всегда будут медленно тянуть архитектуру куда-то в сторону (зачастую не самую хорошую) А как вы боретесь с этим явлением?

Как сделать карьерный рост чуть приятнее Чем выше роль, тем меньше работа про сами задачи и тем больше — про людей. Всегда кто-то что-то требует, кто-то не согласен, кто-то аккуратно тянет одеяло на себя. Кто-то заходит в разговор так, что выходишь после него с ощущением, будто из тебя высосали всю энергию Но, на самом деле, в таких сложных разговорах у разных людей одни и те же паттерны — тебя уводят от сути разговора, тебя пытаются ставить в оправдывающуюся позицию, разговор о предмете обсуждения подменяется разговором о личности и так далее Нормально это осознать помог курс от ребят из SSL, который я проходил аж в 2024 (и до сих пор считаю одним из лучших вложений) Один из тренеров курса — Миша Ромашов, который параллельно преподает переговоры в ВШЭ и лидит одно из направлений в Сбере. Миша ведет свой тг канал, где рассказывает интересные кейсы из практики: • Про эмоции • Про чужую картину мира • Про конфликты без права сепарации Если у вас в работе много сложных коммуникаций — рекомендую

Хочешь долгого выполнения задач — нагрузи всех подзавязку В теории массового обслуживания есть очень простая и удобная модель M/M/1: Есть бесконечный поток задач, один узел обслуживания и очередь перед ним поток задач -> очередь -> узел обслуживания Где: • поток задач описывается Пуассоновским процессом • время обслуживания описывается экспоненциальным распределением Интересно вот что: если взять • λ — скорость прихода задач • μ — скорость обработки • ρ = λ / μ — утилизация • W — среднее время в системе То получается, что • W = 1 / (μ - λ) (proof) И если переписать через утилизацию: • W = 1 / μ(1 - ρ) То есть среднее время нахождения задачи в системе растет гиперболически относительно утилизации. Возьмем простой пример: μ = 1 задача / день И по формуле выше получаем такое среднее время нахождения задачи в системе W: 50% utilization -> 2 дня 80% utilization -> 5 дней 90% utilization -> 10 дней 95% utilization -> 20 дней 99% utilization -> 100 дней Такое происходит из-за того, что задачи поступают в систему неравномерно. Поэтому если обработчик загружен под 100%, то любая неравномерность приводит к скоплению очереди, и как следствие, взрыву времени ожидания Например, при переходе 95% -> 99% утилизация выросла всего на 4п.п., при этом среднее время ожидания скакнуло с 20 дней до 100 дней На произвольные распределения этот эффект обобщается формулой Кингмана — Какой из этого можно сделать практичный вывод? Не хочешь внезапных задержек — оставляй исполнителям задач некоторый запас капасити Например, разработчик загружен на 100%, он сидит, работает себе, а потом ему прилетают 3 пулреквеста на ревью. И 3 задачи встанут, потому что у разработчика нет капасити на то, чтобы их поревьюить. Ну и в такой ситуации обычно начинают браться в работу новые задачи, начинает раздуваться WIP, и проявляться прочие спецэффекты, описанные в этом посте

Хотел написать пост не про эйай но получилось как обычно Обзор на книжечку Agentic design patterns, которая оказалась скачана на телефон во время 8ми часового полета Несмотря на многословность и не очень прикрытую рекламу гугловых инструментов (книга от инженера из гугла), она дает хорошее понимание, как из ллмки - функции, которая просто предсказывает следующий токен, набором инженерных решений получаются крутые инструменты типа claude code Рассказываются основные паттерны, которые устоялись за последние пару лет разработки агентских систем Базовые: • prompt chaining — пайплайн из вызова ллмок, где результаты передаются по цепочке • rouing — ллмка решает, куда дальше идти в воркфлоу • parallelization — кусочки, которые можно распаралеллить, параллелим. Например, сбор данных из разных систем • reflection — первая ллмка отвечает, вторая оценивает ответ, дает фидбек первой, первая корректирует ответ • planning — вместо "реши сложную задачу" сначала просим ллмку сформулировать план. Далее выполняем набор более простых задачек • reasoning techniques — chain-of-thoughts, tree-of-thoughts, ReAct и несколько других Как достучаться до внешнего мира: • tool use — обычный тул колинг: ллмке даются спеки тулов, а она отвечает, что и с какими аргументами нужно вызвать для продолжения работы • mcp — простой небольшой рассказ что это, что такое mcp client, mcp server • rag — ретривим релевантную информацию из базы знаний перед ответом Память: • memory management — про short term memory (на уровне одного чата) и long term memory (глобальная память) • learning and adaptations — прикольная глава про то, как сделать так, чтобы агент автономно (или полуавтономно) обучался и не повторял тех же ошибок Как не допустить говна: • exception handling and recovery — просто глава-напоминание о том, что внешние системы могут лежать/агент можно не справляться с задачей, и это надо как-то уметь обрабатывать • human in the loop — зовем человека, когда делаем рисковое действие • guardrails — ллмке как на вход, так и на выход поступает примерно что угодно, поэтому хорошо бы добавлять явные проверки/валидации, что запрос/ответ приемлем Системы из нескольких агентов: • multi-agent — есть несколько агентов, заточенных под свои узкие области, которые друг другу дают задачи. Зачастую есть отдельный агент-оркестратор • A2A — гугловый протокол взаимодействия между агентами в распределенных системах Всякое разное около самих агентов: • evaluation and monitoring — какие есть способы мониторить агентов и их качество Примеров оч много (даже слишком), поэтому читается легко 7/10

Про Стратоплан и менеджмент (итог) Я уже как ~месяц назад закончил обучение в Стратоплане на руководителя отдела https://stratoplan-school.com/head/ Обучение весьма удачно совпало с новой зоной ответственностью на работе, поэтому многое удалось попробовать на практике. Если меня попросить топ выводов/мыслей, в которых убедился на собственном опыте, я бы ответил так: • Не хочешь внезапных разочарований (в т.ч. от себя) — явно проговаривай ожидания • Регулярное обеспечение прозрачности таки действительно рождает доверие (как и наоборот) • Эффективность каждого конкретного человека по отдельности ≠ эффективность команды • Если проблемы со всеми людьми одновременно, то скорее всего проблемы не с людьми) — Еще на первом занятии упоминалось, что задача рук-ля отдела — строить систему, и в целом курс действительно направлен на то, чтобы абстрагироваться от решения локальных проблем, и решать их на уровне всей системы Поэтому я думаю, обучение точно будет полезно: • тимлидам, у которых начала разрастаться команда, и "уследить за всеми" уже стало как-то нереально • M2 руководителям, которые не понимают, что происходит Если у вас только-только появилась команда, то скорее всего будет полезнее тимлидское обучение Подробности про обучение писал в постах • раз • два • три • четыре • пять Если интересно пообщаться лично и поспрашивать подробности, можно писать в личку, всем отвечу!

random thought Привычные аргументы насчет гексагоналки/clean arch выглядят так: +: высокая тестируемость +: понятная структура проекта -: много бойлерплейта -: много абстракций -: высокий порог входа Но если вспомнить, что сейчас большинство кода пишется агентами, которым как раз нужна • высокая тестируемость • понятная структура проекта При этом для агентов не проблема • написать бойлерплейт • осознать абстракции мэтч?

Почему загрузить разработчиков на 100% — плохая идея Иногда в управлении командой есть очень соблазнительная мысль — давайте полностью загрузим каждого разраба, и тогда команда будет работать эффективно. На практике это часто дает обратный эффект Занятость людей ≠ движение работы Цель команды — протолкнуть фичу до прода. Проталкивание обычно включает в себя разработку → кодревью → тестирование → выкатку на прод Пример, что происходит, когда все загружены на 100%. Начало спринта: • Разработчик 1 делает фичу А • Разработчик 2 делает фичу B • QA тестирует предыдущую фичу C Разработка фичи A завершена, требуется ревью. Но разработчик 2 загружен. Чтобы не просиживать, разработчик 1 берет следующую фичу D: • разработчик 1 делает фичу А (ждет ревью) • разработчик 1 делает фичу D • разработчик 2 делает фичу B • QA тестирует предыдущую фичу C На следующий день аналогичная ситуация случается со вторым разработчиком. При этом QA до сих пор тестирует фичу С, так как фича оказалась большой и сложной • разработчик 1 делает фичу А (поревьюено, ждет QA) • разработчик 1 делает фичу D • разработчик 2 делает фичу B (ждет ревью) • разработчик 2 делает фичу E • QA тестирует предыдущую фичу С Спустя несколько дней получаем: • растущую очередь перед кодревью • растущую очередь перед QA • кучу незавершенной работы Незавершенная работа ⇒ раздутый WIP ⇒ огромный Cycle Time ⇒ фичи в проде появляются очень медленно Ситуация выше описывается Теорией Ограничений — нет смысла усиливать ту часть производства, которая не является узким местом. Потому что это будет приводить к раздуванию очереди перед узким местом, и как следствие, повышению времени цикла Что с AI? Может возникнуть мысль что с AI-ассистентами проблема выше неактуальна, так как • бэкендер может написать немного фронта • фронт может сам поправить контракт апишки • разрабы могут сильно помогать QA Пункты выше действительно ослабляют проблему 100% загрузки, потому что люди становятся более "кросс-функциональными". Но тут есть важный нюанс — AI не отменяет закон очередей. Он просто делает границы между ролями чуть более размытыми Поэтому очень важно использовать AI правильно — не генерить кучу незавершенки, а помогать разгружать узкое место. Об этом писал в одном из предыдущих постов — Пишите в комментах, если сталкивались с желанием загрузить всех на 100%, и что из этого вышло:) P.S.: те 10% девушек, которые читают этот канал, с праздником вас!