Неделя открылась спором, который потом дважды перерос в конфликт. Один участник посоветовал маленькую модель Qwen для переводов, второй спросил простое: ты сравнивал ее с translategemma и в каких языковых парах она лучше. Дальше три круга уточнений, и прямого ответа так и не прозвучало.
Андрей Звездочка описал свою методику вслух: тысяча референсных фраз, носители языка перевели их с максимальным контекстом, потом те же фразы прогнали через маленькие модели. translategemma 4b без тюнинга дала около 74% переводов, которые носитель признает корректными. Антон возразил, что это максимально субъективный критерий, и предложил объективный – перплексию, то есть насколько сильно модель сомневается при выборе токена: по ней видно, где в латентном пространстве пробел.
Спор так и не сошелся, потому что стороны меряли разное. Одному важно, звучит ли фраза естественно для человека, который платит за перевод. Другому – где у модели структурная дыра, которую можно закрыть дообучением. Обе метрики полезны, но одна не заменяет вторую: перплексия не скажет, что перевод звучит по-русски, а опрос носителей не подскажет, что чинить.
Нейтральный третий участник сформулировал претензию точнее всех спорящих. Максим заметил, что странно рекомендовать модель для конкретной задачи, а на вопрос «как ты понял, что она хороша» ответить, что проверку доверил другой модели. Вопрос, который остается после этой ветки: когда вы советуете инструмент коллеге, вы можете назвать цифру и способ, которым ее получили?
«Взял носителей языка и погонял процесс. Есть 1000 референсных фраз... translategemma 4b показала лучший результат, около 74% верных переводов без тюнинга» – Андрей Звездочка
«Странно рекомендовать какую-то модель для определенной задачи, а когда спросили, как ты понял, что модель в этой задаче хороша – ответить, что проверку доверил другой модели» – Максим
Спор про переводы за полчаса скатился в личные оскорбления, и админ выдал мьют обоим участникам. Дальше произошло необычное: разбор конфликта отдали модели. Ей дали доступ к базе сообщений чата и попросили ответить на три вопроса – с чего началось, где была точка невозврата и какие меры соразмерны. Разбор опубликовали в чате открытым текстом, на русском и английском.
Логика разбора оказалась внятной. Ключевой вопрос сформулировали так: кто перевел разговор в состояние, где плохое поведение стало единственным доступным следующим ходом. Ответ – оба, но на разных уровнях, поэтому и меры разные. Одному – более длинный мьют за недоказанные утверждения плюс осознанную провокацию и отдельное предупреждение за реплику с офлайновым подтекстом. Второму – более короткий, за первое прямое оскорбление и за флуд, который сделал ветку нечитаемой и похоронил единственное реально ценное сообщение дня – его же собственный прогон на тысяче фраз.
К концу недели ночью случился второй конфликт тех же участников, уже про Rust и Си, и по нему тоже вышел автоматический разбор. И вот тут прилетела обратная связь, ради которой стоит про это писать. Андрей Звездочка показал скриншот: модель приписала ему чужие реплики и построила на них аргументацию. Админ признал расхождения в деталях, но оставил публикацию, потому что суть передана верно. Обсудили и причину – разбор делали на Opus 5 со средним усилием рассуждения, и для такой задачи этого, похоже, мало.
Получается двойной урок. Модель хорошо отделяет форму от содержания – наказывать за форму и вслух признавать правоту по существу это то, что оставляет человека в сообществе. Но она же уверенно и убедительно путает, кто что сказал, а в разборе конфликта именно атрибуция реплик и есть весь смысл. Если бы вы модерировали свой чат так, вы бы публиковали разбор без ручной сверки цитат?
«Ключевой вопрос: кто перевел разговор в состояние, где плохое поведение стало единственным доступным следующим ходом? Оба. На разных уровнях. Значит и меры разные» – из разбора модели
«Это хороший пример, когда модель пишет много, убедительно, но шизу» – Андрей Звездочка
Станислав рассказал историю с понятным финалом. Он занимался стабильностью сборок, нашел в данных по запускам, что две системы плохо взаимодействуют и отдают случайные таймауты на зеленых тестах. Разработчик видел красный результат, ругал систему и тратил еще час на перезапуск. Находку провалидировали, команда исправила, случайных ошибок стало меньше.
В ответ на рассказ он услышал не спасибо, а претензию: об этой проблеме знали еще с лета, почему ты не обратил на нее внимания раньше. Возразить, по его словам, было особо нечего – сигналы действительно были, а то, что он в тот период занимался другим, звучит как оправдание. Он называет это атакой в прошлое: прошлое уже случилось, оно неопровержимо, и потому идеальное оружие.
Андрей предложил смотреть не на риторику, а на устройство организации. Процессуально такие вещи не решаются, они решаются горизонтальными связями, когда сигналы идут не только по центральным каналам и мелочи чинятся независимо. Проблема в том, что это проблемы второго, а то и третьего порядка: они не двигают метрики, поэтому инвестировать в них не разрешают, и по линии партии они не проходят.
Дальше разговор ушел в то, чем это оборачивается. Такие проблемы едят мораль и убивают мотивацию, а разработчикам, которые хотят просто кодить, приходится заниматься политикой и менеджментом за других. Василий вспомнил практику, где на техдолг и тесты выделяют явные часы в неделю – и заметил, что она вскрывает настоящую причину: не разработчики слабые и не умеют отстоять границы, а менеджеры душат. А как в вашей команде проходит наверх проблема, которая всем портит кровь, но не двигает ни одну метрику?
«Небезопасно, когда вас винят и ругают за то, что вы чего-то не сделали или должны были сделать раньше. Это называется атака в прошлое, и это вполне себе методика» – Станислав
«Такие проблемы едят мораль, убивают мотивацию, но из-за того что коммуникации идут всегда по линии партии, это не решается» – Андрей
Василий предложил чату задачу без подвоха: вам выдали тысячу резюме, фильтровать и сортировать можно как угодно, нужно выбрать пару человек, которых вы поведете дальше. Ответы разошлись сильнее, чем можно было ожидать от чата тимлидов.
Участник под ником 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-кодинга» – Артур
Из разговора про боль найма родилась идея: сделать сервис для рекрутеров силами сообщества, а заработанное вернуть в сообщество. За полчаса появилась организация на гитхабе, несколько человек записались, обсудили название. Хорошая иллюстрация того, как быстро инженерный чат переходит от проблемы к репозиторию.
Тут в разговор вошел Евгений, делавший продуктовые трансформации в банках, и задал неудобный вопрос: а начать с гипотезы ценности и ее проверки не вариант, сразу в деливери? Андрей Звездочка ответил жестко: плевать на причины, найм дорогой и непредсказуемый и для соискателей, и для бизнеса, эту проблему я вижу и на ней можно заработать. Азат сформулировал четыре вопроса, на которые ответа пока нет: в чем продукт, какую проблему решает, почему решает именно он и почему существующие продукты ее не решают.
Дальше разговор сам себя проверил на прочность. Выяснилось, что проблема формулируется по-разному с разных сторон: у одного бизнеса пятьсот откликов на вакансию и их нужно просеять, у другого проблемы нет вообще, потому что отклики просеивает ИИ, а третий вообще считает, что дело макроэкономическое – кандидатов больше, чем мест, и тулой это не лечится. Андрей Звездочка при этом сформулировал версию решения, которая звучит убедительно и совсем не технически: рекрутер, который своей репутацией гарантирует нанятых, и пул из тысячи проверенных людей, которых можно годами ротировать между компаниями.
Спор про кастдев обычно выглядит как ритуальный, но здесь он получил живую иллюстрацию: два часа обсуждения дали три разные формулировки проблемы и ни одного носителя проблемы в разговоре. Один участник предложил компромисс – собрать форму, раскидать по знакомым в бизнесе, собрать общий профиль и уже потом собирать прототип. С чего начали бы вы, если инженеров в чате много, а доступа к клиенту нет ни у кого?
«А начать с гипотезы ценности и ее проверки не вариант? Сразу в деливери?» – Евгений
«Я вижу тут только одно решение: рекрутер, который своей репутацией гарантирует, что нанятые им люди не мудилы. Но это не техническая задача, а социальная» – Андрей Звездочка
Андрей Звездочка рассказал, что делает CI/CD для себя, и уже в третий раз меняет модель данных, потому что предыдущие две не подошли. Ему нужна штука, которая умеет работать и как гит-хук, и как полноценный CI, запускаться на самом хосте, а не в докере, и стоить дешево – цель в том, чтобы оптимизировать пайплайн через модель, а для этого прогонять его надо часто.
На простой сценарий «раз в сутки забрать сообщения из телеграма и обработать» Андрей предложил один скрипт. Ответ был показательным: и вот тут начинается мастерство велосипедов – как запускать по таймеру, надо ли запускать задачу, если предыдущий прогон еще не закончился, и постепенно ты пилишь оркестратор задач, если вообще догадаешься, какие проблемы надо предусмотреть.
Станислав разобрал конструкцию до конца: пайплайн, его версия, запущенный инстанс версии, рантайм, который в цикле считает состояние по статусам в базе и запускает следующий шаг, задачи – скрипты на любом языке, условия и зависимости – ваш код. И подытожил: и вот, ты сделал jenkins. Возражение оказалось интереснее самого спора – формально да, но Jenkins никак не задает формат обмена данными между задачами, а именно это и было нужно.
Василий предлагал третий путь – не пайплайны, а гитопс: в пайплайне важен порядок и живет внутреннее состояние, а в гитопсе актуально то, что закоммичено. Спор уперся в вопрос, как положить в гит выгрузку на сто гигабайт, и разошелся, но схема родилась: артефакты в S3, в гит – только отметки о том, какой шаг завершен. Похоже, вопрос не в том, велосипед это или нет, а в том, какой ровно один аспект существующего инструмента вас не устраивает.
«И вот ты постепенно пилишь оркестратор тасок, если догадаешься, какие проблемы тебе надо предусмотреть» – Андрей Звездочка
«Формально – да, но на практике – нет. Дженкинс никак не задает формат обмена данными между тасками» – Андрей Звездочка
Азат принес статью про софт для одного человека и спросил, много ли из приложений, которыми вы пользуетесь, можно быстро собрать самому, если выкинуть масштабируемость и все остальное. И добавил ключевой ход: если убрать из приложения само понятие пользователя, зная, что пользователь – это вы, все упрощается на порядки.
Аргумент за: у продукта на большую аудиторию есть миллион ограничений по производительности, безопасности, монетизации, мультитенантности и 90% фич, которые вам не нужны. Между демонстрационным MVP и продакшеном лежит пропасть, но если пользователь один, MVP хватает за глаза. Станислав тут же привел свой случай – он собирается написать приложение для учета топлива для себя и брата, вместо платных аналогов с подписками, а лицензия разработчика стоит сто долларов.
Аргумент против прозвучал от двоих сразу. Андрей Звездочка считает это главным заблуждением: чаще всего такие подходы заканчиваются фразой «прошло пару месяцев – ааа, вот почему так было сделано». Вопрос не в том, хватит ли MVP сегодня, а в том, сколько времени вы готовы тратить на поддержку и не дешевле ли заплатить десять долларов стороннему дяде и ущемиться. Андрей добавил свое наблюдение: он видел самоделкиных, которые растят франкенштейна именно потому, что сначала было маленькое и простенькое.
Показательно, что сам Андрей Звездочка на этой же неделе третий раз переписывает модель данных в CI, который делает для себя, и говорит, что с радостью платил бы за это 100–200 долларов в месяц. То есть спор не теоретический, а про то, где именно проходит граница одноразовой вещи. У вас есть самодельный инструмент, который вы поддерживаете дольше, чем планировали?
«Если ты уберешь из аппа само понятие юзера, зная, что юзер – ты, все на порядки упростится» – Азат
«Чаще всего подобные подходы заканчиваются тем, что прошло пару месяцев – ааа, а вот почему так было сделано» – Андрей Звездочка
Василий рассказал, что получил реджект за ответ «показать на цифрах два пути и дать выбрать» – формулировка звучала как «слишком много перекладываешь и на процессы надеешься». Отсюда вырос спор, который в чате идет по кругу, но в этот раз дошел до сути: на собеседовании вы отвечаете как считаете правильным или как принято отвечать.
Максим описал разрыв прямо: вопрос в чате про то, как ты считаешь правильным, а на собеседовании понятно, что надо говорить социально приемлемые ответы, желательно обтекаемые, сводимые к «зависит от контекста». Василий добавил вторую половину – за обтекаемость тоже можно получить отказ, потому что не даешь точных формулировок. Станислав напомнил, что ответ «все три варианта возможны» тоже верный, если дано объяснение.
Антон предложил перевернуть рамку: собеседование – это ваша возможность посмотреть на людей и компанию и решить, стоит ли туда идти, а если вы адаптируетесь под окружение, то стоит спросить себя, хотите ли вы впитывать код среды, к которой у вас нет эмпатии. Возражение пришло быстро: те, кто говорят правду-матку о себе, чаще сидят без работы, а честность как стратегия работает, когда у вас есть запас прочности.
Через несколько дней тема вернулась с другой стороны стола. Нурлан спросил, нормально ли писать пять лет опыта, когда их нет, и получил ответ, что если на джуна просят пять лет, выбора не остается. Андрей Звездочка предложил работодателям депрекейтнуть выслугу лет как критерий, а Нурлан рассказал про случай, когда рекомендация перевесила опыт. Похоже, вранье в резюме – это симптом того, что критерии отбора врут первыми.
«Недавно меня реджектнули из-за показать на цифрах два пути и дать выбрать ему. Типа слишком много перекладываю и на процессы надеюсь» – Василий
«Не надо врать, ребята. Не нужна вам эта работа» – Андрей Звездочка
В чат прилетела статья с заголовком о том, что фраза «код никогда не был сложной частью» оскорбляет всех программистов, а вслед за ней – хабровский пост об обратном, в комментариях к которому автору тоже досталось. Дальше в чате разобрали, что именно задевает.
Андрей сформулировал точнее статьи: оскорбляет не сама мысль, а выкидывание всего, что было сложно, и подмена понятий. Василий сказал резче – те, кто говорит, что код никогда не был проблемой, обманывают других и сами живут в этом обмане. Участник под ником LSTR согласился частично и добавил наблюдение про смену жанра работы: раньше, пока код писался в голове, идеи прорабатывались, а сейчас чувствуешь себя роботом на конвейере, и задача сводится к супервайзингу модели и подтиранию за ней.
Из этого вырос неудобный обмен. Если не нравится подтирать – почему ты используешь ИИ? Ответ: это ложная дихотомия, и есть проекты, где слоп просто запрещен политикой, например Avalonia, а есть личные, где не использовать модель уже не получается. Претензия при этом не к самому подходу, а к цене ошибки: фронтир-модель на мердже написала тест на несуществующий кейс, а когда ее спросили зачем, назвала его хрупким tripwire и предложила выбросить. Тест обошелся в 17 долларов, вопрос про него – еще в три.
Из статьи резонировала другая цитата – что очень мало программистов хотят разговаривать со стейкхолдерами и тем более с клиентами, а «ясность по приоритетам» на практике сводится к «просто скажите, что делать, и не меняйте это каждые два дня». Возможно, спор не про сложность кода вообще, а про то, что у разных людей сложным было разное – и агенты забрали не у всех одно и то же.
«Раньше, пока код писался в голове, идеи прорабатывались. Сейчас с нейронкой чувствуешь себя роботом на конвейере» – LSTR
«Те, кто говорит, что код никогда не был проблемой – обманывают других и сами живут в этом обмане» – Василий
Азат признался, что его в последнее время бесят фронтир-модели: они слишком умные, делают то, чего не просят, лезут куда не надо и добавляют абзацы «вот еще одна важная вещь», не имеющие отношения к задаче. Вывод у него практический – он потихоньку переходит на более слабые модели. И тут же дал объяснение без конспирологии: когда модель тренируют учитывать все на свете, чтобы проходить бенчмарки, она начинает учитывать все на свете.
Василий принес живую иллюстрацию с другой стороны. Он потратил тридцать минут, убеждая модель вернуть .env-файл в репозиторий: она отвечала, что файл не нужен и хранить его в репе нельзя, а когда ей объяснили, что он используется в крон-джобе, предложила создать пайплайн и прописать переменные в интерфейсе. Технически модель права, но у пользователя уже работала костыльная версия, и переделывать ее он не собирался.
Дальше разговор дал два практических хода. Первый – проверять, не тянется ли упрямство из памяти: новая сессия иногда лечит, но не всегда, и участники хотели бы анонимные сессии без контекста. Второй – формулировка Василия, которая связала эту ветку с половиной остальных тем недели: с моделями надо работать как с людьми. Он же заметил параллель со статьей про то, как задачу отдали тому, кто задает меньше вопросов.
Есть и обратная сторона: слабые модели тоже не спасают – по наблюдению Азата, Haiku плохо тянет даже одну сфокусированную задачу. Похоже, выбор модели превращается в тот же вопрос, что и выбор исполнителя: сколько инициативы вы готовы оплачивать и сколько отменять. Как вы решаете, когда переключиться на модель попроще?
«Они слишком умные и делают то, чего не просят, начинают лезть туда, куда не надо. Потихоньку на более слабые модели перехожу» – Азат
«Это не в сторону того, что вопросы задавать сотрудникам не надо, а то, что с моделями как с людьми работать надо» – Василий
Из спора про модели-переводчики выросла более спокойная и более полезная ветка. Азат предложил простое правило: если качество перевода не критично – а в большинстве случаев это так – берите любую модель с приемлемым результатом за меньшие деньги, а если критично, то все равно придется пруфридить профессиональным переводчиком.
Максим возразил тем, что критичность – это спектр, а не бинарный флаг. Как автор мобильного приложения на нескольких языках он хотел бы доверять результату модели без пруфридинга и потому хочет знать, какая модель дает лучший результат. Андрей ответил, что без пруфридинга нормально не будет: суть текст передаст, но читателя будет раздражать. И добавил наблюдение – жалобы на такие переводы он слышал как раз от европейцев, тогда как многим пользователям все равно.
Самое ценное в ветке – смещение фокуса. Антон заметил, что проблема не в переводе, а в локализации: перевести научились еще в 80–90-х, а сложность в том, чтобы передать идею, а не слова. Азат добавил инженерную часть: интернационализация – большая тема, и перевод в ней самое легкое, потому что верстка едет от немецких слов-франкенштейнов, а на арабском добавляется правостороннее письмо. Отдельно всплыло, что для малых языков все хуже, чем для крупных.
Пример на подумать оттуда же: даже у Microsoft с бесконечными деньгами локализация офисов и Windows на многие языки сделана некорректно. Если бюджет не решает, то, возможно, вопрос не в качестве модели, а в том, на скольких языках вы вообще готовы отвечать за смысл. А сколько языков поддерживает ваш продукт – и кто последний раз читал их глазами носителя?
«Критичность качества перевода – это спектр, а не бинарный результат» – Максим
«Проблема переводов не в переводе, а в локализации. Перевести не сложно, эту задачу решили еще в 80–90-х» – Антон
Хотите продолжить обсуждение?
Обсудить в Telegram