Неделя открылась двумя счетами. 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 часов в день, а головой. Иногда час работы головой заменяет месяц кодинга» – Азат
На выходных в чате протестировали три модели распознавания речи на реальной задаче – записи открытой встречи сообщества «Тимлид не кодит» от 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 лучше», а методический: выбирая модель для своей задачи, замеры нужно проводить на своих записях, иначе слово «внедрили» ничего не значит. Сколько ошибок в ваших протоколах встреч вы бы заметили, если бы никто не сверял их с записью?
«Одно некорректное слово может поменять смысл» – Станислав
«Без бенчмарков на ваших задачах, ошибка может быть значительной» – Станислав
В пятницу вечером в чат принесли список из семи трендов – смерть IDE, конец гонки за токены, код-ревью в состоянии зомби, открытые модели ради экономии, смерть среднего менеджмента, работаем больше чем когда-либо, найм стал сложнее – и вопрос, с какими из них согласны. Дмитрий согласился с первыми тремя, Азат со всеми, а дальше разговор ушел в ревью и не вернулся.
Спор о ревью – самый устойчивый сюжет чата за лето. В начале июля обсуждали, читать ли код, который пишет ИИ, в августе прозвучало «я больше не читаю сгенерированный код», две недели назад – требования как тесты вместо ревью. Эта неделя добавила новое: впервые ревью защищали не как контроль качества, а как культуру команды, которую агенты ломают. Андрей считает, что ревью часто и было театром: исчезло социальное давление, и люди радостно признались, что им безразлично, что делают другие, и учиться у коллег они не хотят. Азат возразил: хорошо, если было театром, но команды с настоящей культурой ревью сейчас страдают. Стоит одному участнику начать пользоваться агентами, и PR копятся быстрее, чем их можно прочитать, а на качество еще никто не готов махнуть рукой. Станислав добавил, что ревью имело смысл в общей кодовой базе, где никто не знает весь контекст, а сейчас все прогоняют через агентов и постят комментарии, возможно даже не читая код.
Дальше спор ушел глубже: Азат считает, что модель на ревью находит не то – десять проблем в том, как сделано, и ни одного вопроса, зачем. Дорогая модель наоверинженирит абстрактные фабрики синглтонов там, где хватило бы одной строки, а ревьюер похвалит качество. Станислав ответил вопросом: а в чем тут проблема модели, если контекста в коде нет? И привел свою цифру: онбординг человека в кодовую базу возрастом 18 лет занимает четыре-шесть месяцев, первый PR с исправлением бага – через 40 дней. Из них десять дней уходят на доступы, которые выдаются с лагом в сутки в трех-пяти системах подряд, и это проблема систем, написанных людьми, а не моделей. Позиция Станислава радикальна: понимать код не нужно. Азат парирует: чем больше кода делегируешь, тем меньше он твой, и мириться с этим должен каждый в команде, а не один энтузиаст.
LSTR предложил конструктивный ответ вместо спора: ревью работает, когда оно неформальное и точечное, когда подсвечивается действительно важное, чего агенты плохо находят, и тимлид не должен поощрять формальное ревью с комментариями от агентов. Он же прошелся по всем семи трендам от лица маленькой команды в большой структуре: IDE нужна для дебага, но реже; токены уходят не на максимизацию, а на мультимодельное ревью документов; ревью живо, но ревьюится в основном проза, потому что ерунда в прозе быстро прорастает в планы; работаем больше – однозначно да; найм просто оказался не готов к резюме, нарисованным моделями, но научится. На следующий день в чат принесли интервью одного из создателей Codex, где та же мысль звучит с другой стороны: человеческое обсуждение стоит сосредоточить на намерении и контрактах – что компонент должен делать и какие инварианты сохранять, а корректность и безопасность проверять автоматически. Если ревью в вашей команде стало формальностью, что именно оно перестало ловить?
«Code review часто и было театром, просто социальное давление исчезло» – Андрей
«Он найдет десять проблем в том, как это было сделано, и ни разу не спросит: а нафига это было сделано» – Азат
Николай выложил в чат dnd.kz – портал для клубов настольных ролевых игр, собранный в дуэте с агентом. Автор честно предупредил: он не веб-разработчик, не дизайнер, а из стека 1С, где пользователь должен страдать; уровень вайбкодинга – 146 процентов. Цель беты была не про функционал, а про безопасность и ошибки новичка в деплое, которые видны всем, кроме автора.
Первая реакция чата оказалась не про код. Андрей: пока пусто, и это сильно смазывает впечатление, заведи друзей – уже будут «мастера». И вторая, от человека, участвовавшего во многих стартапах: функционала сделано непропорционально имеющимся пользователям, клубы можно было не делать, а доделать, когда набралась бы масса мастеров и игр. Станислав добавил, что без контента обратную связь дать сложно: портал есть, а что ожидалось – непонятно, и если платформа мертвая, нет интереса остаться. Азат сформулировал общий вывод: самое сложное в таком проекте – не сайт написать, а набрать критическую базу пользователей, и заметил, что группы обычно организуются в чатах, так что бот может оказаться проще сайта.
Николай возражал разумно: это платформа социального взаимодействия, ее нельзя наполнить иначе как постепенно, значит нужен сам социум. Но через день пришел настоящий бета-тест: Андрей выкатил список из десятка замечаний – разные отступы у выпадающих списков, склонение «найдено 2 игр(-ы/-а)», сломанные пути к портретам, счетчик «история игр 12» при двух отображаемых, два стиля оформления игроков, которые оказались заглушками, пустой блог, нерабочая почта поддержки, указанная на сайте. Реакция автора – «фронт не мое», на что Андрей ответил точнее: фронт не ваншотится.
Месяц назад чат уже упирался в тот же вопрос, когда сообщество решило делать свой продукт и сразу споткнулось о гипотезу: чья это боль. Тогда спор шел до кода, сейчас – после. Из этой истории торчат два наблюдения. Первое: агент собирает сайт за ночь, но глаз замыливается быстрее, чем раньше, потому что блоков стало больше, а внимания на каждый – меньше. Второе: показать программистам пустую платформу означает получить ревью верстки вместо ревью идеи. Заглушка с одним клубом и двумя анонсами дала бы больше сигнала, чем отдельный раздел с кланами. Когда вы показываете свой проект впервые, какую обратную связь вы на самом деле хотите получить, и позволяет ли ее дать то, что вы показываете?
«Много функционала сделал, не пропорционально имеющимся пользователям» – Андрей
«Самое сложное в таком проекте не сайт написать, а набрать критическую базу пользователей» – Азат
Станислав третью неделю подряд ведет дневник разработки приложения для учета расходов на авто: две недели назад это были двенадцать часов агента и сорок долларов, неделю назад – сто долларов и 250 задач. На этой неделе дневник впервые ушел от технической части к продуктовой. Состояние знакомое каждому: первые 80 процентов проекта сделаны за 20 процентов времени, оставшиеся 20 займут все остальное. Ломается интеграция между частями, ручное тестирование вскрывает плохой пользовательский опыт вроде удаления без подтверждения. Заодно попросил другого агента оценить UI-тесты: часть из них тестирует примерно ничего и подлежит удалению, 80–90 процентов адекватны, но недостаточны для покрытия – и список недостающих сценариев ушел в задачи.
Продуктовая часть оказалась интереснее технической. Николай семь-восемь лет ведет три автомобиля в конкурирующем приложении и платит за подписку 370 тенге в квартал – сумму, которой не жалко и которая просто убирает рекламу. Станислав собирается продавать дополнительные функции, и тут выяснилось, что у конкурента платная даже смена темы и экспорт. Андрей одобрил: такие вещи и нужно давать за деньги, они стимулируют купить хотя бы на месяц.
Дальше был спор, за что вообще платить. Станислав не видит смысла контролировать цены на топливо: они одинаковы от заправки к заправке, есть только сезонность. Николай ответил тремя сценариями: журнал цен за несколько лет как аргумент в спорах, потому что память у людей как у золотой рыбки; напоминания по пробегу и датам; прогноз расходов для семейного бюджета. Еще одно: график среднего расхода, который уполз вверх на пару литров – это повод заехать на диагностику. Автор согласился не со всем, но признал, что для продажи история работает.
Самый практичный момент – про целостность данных. У Станислава в истории есть опечатки в датах и одометре, от которых ломается весь расчет расхода, особенно если править задним числом. Конкурент решает это грубо: валидирует соотношение даты и пробега на входе и не дает сохранить, пока не исправишь, а старую запись править вовсе не позволяет. Иногда лучший UX – это отказ. Какие данные в вашем продукте пользователь может испортить одной опечаткой, и кто это заметит?
«Прозвучит странно – аргумент в спорах. У людей память, как у золотой рыбки. А журнал за последние N лет с ценами – это весомый аргумент» – Николай
«У меня сейчас состояние, что первые 80% проекта я сделал за 20%, а оставшиеся 20% – займут теперь 80% всего проекта» – Станислав
Хотите продолжить обсуждение?
Обсудить в Telegram