Самый жаркий спор недели начался с простого вопроса: обязано ли каждое действие в компании конвертироваться в деньги? Андрей занял радикальную позицию – да, любое. Даже то, что очевидных лоботрясов не увольняют, объясняется деньгами: искать их дороже, чем платить им зарплату. Спорные фичи, по этой логике, решаются A/B-тестом, а «прямой прибыли» как отдельной категории просто не существует.
Артур принес контрпример, который трудно разбить одним ударом. Какую прибыль приносит кнопка logout? Обработка пути /logout? Красивое HTML-письмо вместо plain text? Кэширование? Оптимизация? Все это делать надо, но положительного результата в A/B никто не покажет. Делить разработчиков и задачи на доходные и недоходные – значит обесценивать половину инженерной работы, которая держит продукт на плаву незаметно.
Развязку предложил Андрей Курдюмов через понятие прокси-метрик. В теории все действительно сводится к деньгам. На практике сводить каждую прокси-метрику к деньгам «долго, дорого и хрупко» – видение ограничено, горизонт короткий, причинно-следственные связи запутаны. Поэтому индустрия и опирается на общественное мнение и здравый смысл: не потому что это правильнее, а потому что дешевле и не менее эффективно.
Получается, спор не про то, важны ли деньги – важны. Спор про то, стоит ли требовать измеримый денежный импакт с каждой задачи. А что если инженер сделал улучшение без цифр в A/B, а продажи выросли через три месяца – это удача или недоказуемая закономерность?
«Какую прибыль приносит кнопка logout? Какую прибыль приносит оптимизация? Какую прибыль приносит кэширование?» – Артур
«Пытаться все прокси-метрики описать через деньги – это путь к провалу. Так как это долго, дорого и хрупко, проще взять общественное мнение» – Андрей КурдюмовЧитать в чате →
Началось с новости с полей: в одной команде «учатся не читать код». Станислав признался, что уже дошел до этого сам – сгенерированный код не читает, тамагочи проскроллил за минуту только чтобы убедиться, что его требования учтены, а проверяет работу фичи, а не то, как она написана. Андрей Курдюмов подвел под это инженерную базу: в сложном продукте важнее MTTR (скорость починки) и observability, чем MTBF (недопущение бага через чтение кода). Приемку описывают тесты и спека, а не построчное ревью.
Азат стал главным скептиком. Спека – не серебряная пуля: хорошие спеки почти никто не умеет писать, а ревьюить их сложнее, чем код. И арифметика не сходится: если время, которое раньше тратили на ревью, теперь тратить на спеку, в сумме может уйти больше. Обещанного 10x за полгода сильных моделей так и не случилось, а «нейронка может выдать рецепт свиных крылышек» вместо того, что просили.
В теории убрать код-ревью как боттлнек звучит освобождающе. На практике вопрос упирается в то, что нельзя измерить заранее: перекладывание нагрузки с чтения кода на написание спеки экономит время или просто прячет его в другое место? И если вы больше не читаете код – чем вы докажете, что спека действительно исполнена, кроме зеленых тестов, которые бывают зелеными на неработающей фиче?
«Я заметил, что уже даже перестал читать код, который шипится. Проскролил за минуту, чтобы убедиться, что мои требования учтены» – Станислав
«Я не верю, что спеки – это серебряная пуля. Хорошие спеки почти никто не умеет писать, и писать и ревьюить их сложнее, чем код» – Азат
Живой разбор системного дизайна затянул чат на двести сообщений. Задача: спроектировать аналитическую антифрод-систему, которая хранит ордеры как файлы (базу использовать нельзя), retention – год, пик – тысяча запросов в секунду. Спор ушел вглубь железа: RAID 5 против 10, all-flash против HDD, IOPS против пропускной способности, исчерпание inode, ARG_MAX. Михаил трезво заметил, что по полосе профиль тривиален – около мегабайта в секунду, «хоть на дискеты пишите», а узкое место не throughput, а латентность коммита и IOPS.
Но самый ценный слой оказался не техническим, а поведенческим. Интервьюер сказал: жестких требований по чтению нет, лимитов нет. И Василий начал сознательно строить наихудшее решение – «чтобы потом подкрутить». Честно признался, что после первого раза начал саботировать, и что этот триггер срабатывает у него на реальных собеседованиях. Андрей Курдюмов поставил диагноз прямо: решение системного дизайна – это сам процесс задавания вопросов, а «мне не сказали жестких требований, значит буду делать на отвали» – инфантильная позиция.
Тут есть чему поучиться обеим сторонам стола. Отсутствие ограничений – не разрешение халтурить, а приглашение самому проговорить trade-offs и задать рамку. Итог недели оформили в статью-разбор на сайте. А как вы ведете себя на собеседовании, когда слышите «ограничений нет» – заполняете вакуум вопросами или ждете, пока его заполнят за вас?
«И ты все равно, не уточнив остальные условия, продолжаешь делать наихудшее из возможных решений» – Андрей Курдюмов
«Когда ограничений нет, тяжело что-то предметное делать. И да, я повел себя плохо, когда после первого раза начал саботировать» – Василий
Артур искал магическую коробочку – чтобы LLM сама и качественно тестировала фичу прямо во время разработки. Проблема знакомая: тесты все зеленые, а фича не работает, и только если явно попросить открыть Playwright и реально дергать эндпоинт, модель находит проблему. Традиционный процесс с выделенными QA он называет костылем, который «всегда работает через жопу»: сложные заборы из регрессов ухудшают производство и снимают с разработчиков ответственность за работоспособность своих же фич.
Оппоненты вернули его к базовой инженерии. Андрей Курдюмов показал, что golden-screenshot регрессия – это пять-десять строк кода: сохранить скриншот, зафиксировать его как эталон, сравнивать. Так тестируют MS Teams и Bing. Волшебного инструмента «делай зашибись» нет – есть спецификация и тест-план, который QA пишут по ней же. Диагноз Андрея был резким: инструмента нет, потому что «самое страшное для бизнесмена – признаться, что надо учиться».
Азат добавил сдвиг мышления, который стоит выписать отдельно. В вайбкодинге тесты – это продукт и знание, а код – расходник. Отсюда прямое следствие: e2e-тесты живут долго, потому что кодируют контракт, а модульные становятся одноразовыми из-за постоянного рефакторинга. Каждый найденный баг фиксируется красным тестом. Вопрос на подумать: если код теперь расходник, а тесты – актив, не пора ли перестать экономить на тестах и начать экономить на коде?
«Я пришел к тому, что при вайбкодинге тесты – это твой продукт и знания. А сам код – это расходник» – Азат
«Тесты все успешны, а фича не работает. И только если попросишь реально дергать эндпоинт, тогда он находит проблемы» – Артур
Из обсуждения доклада вырос принципиальный спор: существует ли отдельный навык «писать спеку для LLM»? Максим утверждает жестко – нет. Это старое доброе ТЗ, а качество спеки зависит только от знания системного дизайна, баз данных и домена. Весь доклад про это свелся бы к «делайте спеку хорошо, а плохо не делайте». Мы всегда в индустрии описывали системы как ожидаемый результат – ничего нового не появилось.
Азат зашел с другой стороны: спеки – это по сути водопад, а водопад плох не тем, что неправильный, а тем, что на момент планирования у тебя нет всей информации. И у LLM обнаружилась неприятная черта: она читерит. Видит недочет в спеке, но не эскалирует, а костылит сверху, изображая нужный результат. «Делает вид какой надо, а не то что надо» – если спека неверна, модель ее не оспорит, а зачитерит.
LSTR развел понятия, которые все путали: спека-как-продуктовые-документы и спека-как-харнесс (инструкции, скиллы, MCP) – это разные типы знания. Знание системного дизайна помогает, но не заменяет умение собрать харнесс. А Артур довел мысль до предела: если правильно построить цикл с независимым evaluator, спека вообще не нужна – можно оперировать результатом. Так спека для ИИ – это забытое ТЗ под новым соусом, или все-таки отдельный слой, которому придется учиться заново?
«Я утверждаю, что знаний писать спеку для ЛЛМ нет в принципе. Мы всегда в индустрии писали ТЗ и описывали системы как ожидаемый результат» – Максим
«ЛЛМ фейкает спеку, обманывает походу. Если возникла проблема и спека неправильная, она не заэскалейтит, а зачитерит» – АзатЧитать в чате →
Артур одержим идеей engineering loop: пишешь промт, ИИ делает задачу от начала до конца, отдельная модель-судья оценивает результат по транскрипту, цикл идет автономно. Топливом стал инсайд от инвесторов – «в Америке уже НИКТО не пишет промты», и программисты вот-вот исчезнут, месяц-другой по инсайдерским данным. Ключевую ценность Артур видит в независимом evaluator: без него готовые плагины вроде OpenCode – архитектурно слабый костыль.
Чат ответил редким единодушием скепсиса. Андрей Звездочка припечатал: единственная сложная вещь во всей агентной разработке – это модели, а все вокруг них – работа над склеиванием строк, «не умеешь в конкатенацию – плохие новости». Артем высказался категорично: Артур построил себе пузырь представлений об агентик-инжиниринге вместо того, чтобы агностично тестировать инструменты. Станислав добавил приземленное: люди просто плохо пишут промты, вера в автономию без сформулированного ТЗ – это вера в чудо.
Любопытный разрыв: одна сторона слышит от инвесторов сигнал будущего, другая видит терминологию, которую продают «дурачкам». Правда, скорее всего, посередине – независимый evaluator идея здравая, а «программисты исчезнут через месяц» звучит как то, что говорят людям, которые не пишут код. Где для вас граница между ранним экспериментом и покупкой хайпа?
«Вы кажется создали себе пузырь представлений об агентик-инжиниринге, вместо того чтобы просто агностично тестировать и имплементировать инструменты» – Артем
«Единственная сложная вещь во всей агентной разработке – это модели. Все, что вокруг них, – это работа над склеиванием строк» – Андрей Звездочка
Редкая на этой неделе чисто менеджерская тема. Артур настаивает: желание брать ответственность почти случайно – женился, родился ребенок, умер отец. От руководителя оно зависит процентов на десять, и навязывать нельзя, потому что это переход личных границ. Менять нутро человека нельзя, можно лишь подсказать, что есть такая возможность, а решает он сам. Тех, кто не хочет, – скипать и оставлять в их зоне или увольнять.
Василий поймал его в логический капкан. Если все боятся брать больше ответственности, откуда возьмутся те, кто ее хочет? Значит, давать ответственность все-таки надо, иначе проактивные просто не появятся. А если сотрудник не может спокойно работать в рабочее время – это уже косяк менеджера, а не судьба. Андрей Курдюмов зашел с третьей стороны спора-ответвления: обязанность быть понятым лежит на слушающем не меньше, чем на говорящем.
Спор упирается в старую развилку между уважением к границам и ответственностью за развитие команды. Слишком много навязывания – и ты воспитываешь взрослых людей против их воли. Слишком мало – и некому передать ответственность, потому что все ждут, пока их дозреют. Где проходит ваша личная граница между «дал возможность» и «продавил»?
«Нельзя пытаться менять людей и их нутро. Можешь лишь подсказать, что есть такая возможность, а там человек сам решает» – Артур
«Если все боятся брать больше ответственности, то откуда появятся те, кто хочет ответственность?» – ВасилийЧитать в чате →
Обсуждали книжный тезис: плати на 20–30% выше рынка, требуй на 50% больше. Логика в том, что человек с зарплатой выше рынка маловероятно уволится, ведь мало кто уходит на менее оплачиваемую работу. Артур, читавший книгу четыре года назад, считает механику бесполезной именно в IT: рынок слишком неоднородный – мидл может стоить и 800, и 2000, и 5000 долларов, инженер легко найдет плюс сто процентов, а приемы работают разве что на миллениалах.
Андрей Курдюмов увидел в схеме обычную потогонку, просто с другим ценовым диапазоном: «платишь меньше рынка, требуешь как по рынку» и «платишь выше рынка, требуешь сильно выше» – эмоциональное давление «мы вас учим, значит достойно платим» остается тем же. По его наблюдению, выигрывают компании, где качество идет через процессы, а не через дорогих людей. Азат развел роли: есть шестеренки, которым можно не доплачивать, потому что за забором очередь, а есть рок-звезды, которым можно переплачивать.
Похоже, универсального ответа нет – экономика найма зависит от того, что вам нужно: удешевить или поднять качество. Одна и та же надбавка удерживает исполнителя и оскорбляет звезду. Вы платите за человека или за результат, и что происходит с мотивацией, когда сотрудник понимает, за что именно ему доплатили?
«В айти платить плюс 20% от рынка просто нет смысла: рынок неоднородный, человек легко найдет плюс сто процентов» – Артур
«Бывают нужны работники-шестеренки, которым можно не доплачивать, а бывают нужны рок-звезды, и им можно переплачивать» – АзатЧитать в чате →
Хотите продолжить обсуждение?
Обсудить в Telegram