Врата Тангейзера

помошник 🐰

🥕🐰

Часть 4/4 Ну а теперь, чтобы не томить, перейду к тому что у нас произошло в компании. Дабы было понимание эффективности работы команды, мол "за какие заслуги мы им платим деньги", руководство приняло решение переформировать команды по конкретным доменам, за которые они будут всецело отвественны. Идея вроде бы и здравая, но люди на опыте уже задаются вопросом "а как метрики некоторых доменов оценить в деньгах?". Например, как вы оцените эффективность ИТ команды, что отвечает за решения в области legal & compliance? Посчитаете штрафы, на которые вы попадете? А что если не попадете? А что если вы будете судиться в другой юрисдикции? Уже сейчас сложность состоит в том, что не всегда понятно как оценивать эффективность маркетинговой команды, а мы уже хотим оценивать и core команды, что ответственны за какие нибудь АБС. Далее возникает другой интересный ход – унифицированность команд. Принято решение, что команда должна состоять из одного менеджера, нескольких разрабов и одного тестировщика. Бывалые ИТшники прекрасно понимают, что унифицированность работает хорошо исключительно в командах, что работают в схожем домене и конкурируют друг с другом. Однако, такой подход игнорирует специфичность доменной области, не позволяя реализовать полностью потенциал домена и уверенно смитигировать его риски. Случаев, которые четко показывали, что вайбкодинг человеком, не владеющим контекстом и навыками это очень плохо было к этому моменту не мало. Например, нашей команде упала задача с чеками, чтобы они генерились по запросу. Я сказал, что это работы на полторы недели, и приоритет у них низкий. Пришел человек из бизнеса и начал говорить, что это не дело, и вообще он навайбкодил решение за 15 минут, а мы тут про полторы недели разговариваем. Через 1,5 месяца, из-за неправильно сгенерированных чеков нам прилетает то ли штраф, то ли иск в суд в ЕС. Поставили науши всех, и нас в том числе. Выводов сделано не было. Как и в остальных случаях риски начали перекладывать все на всех, но никак не владелец вайбкода на себя. Были сокращены многие сотрудники, которые хорошо владели контекстом, в частности именно инженеры. Сделано это было в т.ч. и за косяки, которые были на их стороне. Однако, большинство из этих старожил можно было бы поставить обратно в строй если провести с ними работу на уровне отдела кадров. И тем не менее, было принято решение уволить старых, выгоревших, но с контекстом и заменить на новых. Более того, заменят не всех, потому что "ИИ заменяет инженера" по мнению не только бизнеса, но и СТО. Зато были открыты новые вакансии ХРов и маркетологов. И наконец самая большая ошибка, вся эта "ИИ-революция" происходит без понимания у С-левела как выстроены процессы, в том числе речь и про СТО. Он не провел архитектурный аудит чтобы понять что и как работает, он просто прочитал и послушал как это делалось в других компаниях (по рассказам владельцев бизнеса, что не шарят в ИТ скорее всего) и применил этот подход на совсем другую компанию, с совершенно другой конъюнктурой. Я предполагал, что после такого будут уходить ключевые инженеры и вот сегодня, через два дня после объявления и начале реструктуризации, я получаю от своего тех. лида инфу о том, что один уже принял оффер другой компании, другой на этапе собеседования, и это только те, про которых он знает. Получается, что за два дня мы уже потеряли 2/10 ключевых инженеров и по моей оценке скорее всего потеряем еще 4-х. Про других инженеров, QA и Ops я даже говорить не буду. Все это делается под знаменами ИИ-революции и под браварные заявления о том, как мы будем эффективно теперь работать. Проблема в том, что эту революцию возлаглавляют люди, что рассказывают о своих ИИ навыках, при этом из достижений у них это установленный по инструкции OpenClaw на mac mini, который за пару дней сжирает весь пул (у нас он общий) токенов.

Часть 3/4 Но несмотря на то, что ИТ-сектор дает некое пространство для маневров, все таки, оно не бесконечное. Да, в перспективе можно сделать ультра-маленькие команды, что будут вайбкодить без какой либо спеки, ну или с номинальной спекой, вот только владельцев логики/кода там не будет. Даже если у вас "спек-кодить" будут именно разрабы (а не, как в крайнейм случае, бизнес) если они не будут тратить время на доскональное ревью кода, то они эту логику не запомнят. С учетом, что руководству все равно и они не понимают как устроено ИТ, то оно будет руководствоваться, что "ну у вас же есть ИИ-агенты, пусть кодят они, а вы только проверяйте". И таким образом получается, что у вас будет раздуваться кодовая база до невероятных размеров, которой никто по факту не владеет. Вдобавок к этому, и я и тех. лиды заметили, что даже Fable 5 не способен всецело владеть контекстом, чтобы выстраивать код не как временное решение, а как целевое, с возможностью дальшейго масштабирования этого направления по определенному вектору. Соответственно, переспектива выстраивается следующая (берем пример с идеальной инфраструктурой): у вас будут некие SWE, которые через полуавтоматизированный пайплайн гоняют бизнес-спеку в код через Клод, проверяют чтобы максимум было более-менее рабочее решение, также его правят через ЛЛМ, и деплоят с минимальным вмешательством. Звучит неплохо впока не встанет вопрос, что что-то было хакнуто, украдено, упало и т.д.. В данном случае, у вас два варианта: либо отправить людей разбираться, либо ЛЛМ, и как вы понимаете, во втором варианте это однозначно будет борьба с симптомами. В первом-же варианте, вы получаете ситуацию, когда вы отправили людей с пониманием существующей логики на уровне джуна. Люди будут разбираться, но по итогу и тут придут к решению, которое скорее будет напоминать заплатку, а не реальное решение проблемы, так как "надо разбираться". Перечисленная выше проблема является стратегической, и по факту, чтобы такой пайплайн выстроить вы столкнетесь с очень большим количеством локальных проблем, которые когда нибудь будут кем-то решены, но на горизонте нескольких лет, так как требуется выработка совершенного иного подхода.

a

Часть 2/3 И вот теперь исходим из того, что было сказано и становится понятно, что ЛЛМ не заменяет специалиста с хорошим контекстом по домену, а уж тем более не заменит и специалиста с контекстом и "хардами". Ответ на вопрос "но почему и с хардами" прост – человек способен мыслить дальше, статегически, а не тактически (хотя и не каждый). ЛЛМ выдают порой действительно хорошие generic-решения, которые прошли проверку рынком, вот только это решение является слишком generic, и порой плохо вписывается в архитектурный контур конкретной компании. Соответственно, если мы полностью переводим разработку на ЛЛМ, то мы с вами получим решения, которые хорошо работают в краткосрочной перспективе, но не подходят для масштабирования. А последнее – это именно то, что любому процветающему бизнесу на конкурентном рынке и нужно. Да и что из себя в прицнипе должна представлять LLM-friendly/AI-first инфраструктура компании? Наверняка это и развернутая A2A сеть, и отдельный LLMOps контур со своими VCS и прочими DevOps штуками. Не будем забывать и о проработанных discovery и delivery кластерах. Звучит в теории как нечто уже более менее работающее, имеющее свои killswitch, guard-rails, а также четкое понимание где именно human в этом самом loop, иначе говоря – четко выстроенный конвейер. И если сравнивать с реальным сектором, то там то эти самые производственные конвейеры очень скурпулезно прорабатываются на этапе планирования, дабы избежать издержек, так как они дороже обходятся в реальном секторе, нежели в ИТшечке.

Приболел. Надеюсь будет также. Всем покойной ночи и сна.

Останій раз ты пишешь имя Господа Нашего Иисуса Христа с маленькой буквы. Jasne?