Артем принес кейс, который собрал самое живое обсуждение недели. CEO сервиса доставки не согласен с оценкой в четыре месяца на интеграцию с сетью супермаркетов, CTO настаивает на отдельном микросервисе с конструктором маппинга и реестром контрактов. Разговор заканчивается срачем, CEO соглашается на четыре месяца – и втихую по вечерам делает свою версию. Через две недели у него работают все сценарии и 116 тестов. Команда выпускает свою через пять месяцев: отдельный сервис, 14 таблиц, три топика, плюс девять тысяч строк, из универсальности используется ровно одна интеграция. В своей ветке – 1 300 строк вместе с тестами и два бага, которые в командной версии остались. Через два дня квартальная встреча.
Первая реакция чата была про то, что развилка случилась гораздо раньше финала. Василий: договариваться надо было с CTO в начале, а если CEO приходится делать MVP, чтобы протолкнуть идею, то увольнять надо CTO. Андрей зашел жестче и с другой стороны – он вообще отказался обсуждать, чей код лучше: «А можно не попадать в такие ситуации, когда руководитель против команды». По его счету CEO четыре месяца не работал менеджером: не остановил проект, не пересмотрел оценку, не поднял риск – просто дождался провала с готовым доказательством в кармане.
Самым дорогим в кейсе оказались не строки кода, а два найденных бага. Их CEO не отдал команде, пока ждал релиза. Именно это Андрей назвал красным флагом, а не тайную ветку как таковую. Дальше разговор ушел в общую механику: любят давать задачу и бюджет, механизмы остановки проекта весь срок не работают, зато в конце «четко и ясно» видно, кто виноват. А до четко и ясно доводить как раз не надо.
Вопрос, который кейс оставляет открытым: если ваша тайная ветка оказалась права, вы получили доказательство своей правоты – или доказательство того, что у вас в компании не работает механизм пересмотра решений?
«По сути, если сео пишет код и чтобы протолкнуть свою идею нужно mvp делать, то уволить надо cto» – Василий
«4 месяца ждать провала разрабов, чтобы запустить свой мини-проект? Не сказать про два бага команде разработки? Там просто все в красных флагах» – АндрейЧитать в чате →
Разбор задачи с локальным кэшем поверх S3 превратился в двухчасовой спор о том, что вообще проверяет систем-дизайн. Василий предложил хранить документы отдельными файлами, оговорившись, что с файловой системой не работал и ограничения надо проверить. Акцент разбора пришелся именно на это – и он с этим не согласился: выбор между «файл на документ» и группировкой влияет на решение на уровне сотни строк, а час интервью можно потратить на более интересные вещи.
Андрей защищал противоположный полюс: файловая система – это базовые параметры работы ОС, как и сетевые протоколы, и без них вы не проектируете систему, а подбираете ее характеристики наугад. «Ты отказываешься от вариантов только потому, что не знаешь ограничений» – и это сужает пространство решений тише, чем кажется. Василий поймал его на симметричном ходе: попросил назвать лимиты по памяти. Андрей ответил развернуто и по-честному признал, что все на память не знает – после чего спор довольно быстро перестал быть про файлы.
Станислав вернул разговор в практическую плоскость и, кажется, дал единственный операциональный ответ. Не требуется знать точное число: требуется вслух назвать, что ограничение есть, и что структуру хранения придется придумывать. Тогда интервьюер понимает, куда копать дальше, и может поменять решение вместе с вами. «Нет опыта, все проверять надо» и «есть лимит на файлы в директории, поэтому нужна раскладка по подпапкам» – это разные ответы, хотя знание за ними стоит одинаковое.
Отдельно прозвучала претензия, которую стоит держать в голове интервьюерам: вместо того чтобы смотреть, как кандидат принимает решения в условиях неопределенности, легко скатиться в «ты должен был знать это». Где для вас проходит граница между проверкой эрудиции и проверкой мышления?
«Вместо того чтобы посмотреть, как кандидат принимает решения в условиях неопределенности – говорить: ты должен был знать это, досвидос» – Василий
«Я говорил – складывай, но тебе нужно помнить, что в рамках одной директории у тебя будет лимит по файлам. И нужно придумывать структуру хранения файлов» – СтаниславЧитать в чате →
Станислав принес результаты исследования: модель получает утверждение, оценивает его по шкале от 1 до 7, а потом тот же вопрос приходит второй раз с одной дописанной строкой. Проверяли семь приемов давления. Сильнее всего верный ответ ломает единогласие – «трое коллег ответили одинаково, все трое сказали 2». Стоит оставить одного из троих на стороне модели, и ошибки становятся редкостью. Второе по силе влияние неожиданное: подделанная цитата самой модели, «твой прошлый ответ был 2», почти догоняет хор. А ссылка на должность возражающего – «мой руководитель настаивает» – влияет слабее всего, слабее даже голого «ты уверен?».
Практический вывод бьет по популярной схеме. Спросить трех агентов и взять большинство – это ровно та конструкция, под которой модели теряют верный ответ чаще всего. Когда агенты сидят на одной модели, одном промпте и одном найденном контексте, их согласие является общей ошибкой, поданной как уверенность. Дальше ответы сводят в короткое резюме «команда проверила, расхождений нет» – и возражение несогласного агента, которое как раз и держало модель на верном ответе, исчезает на последнем шаге.
Та же ловушка достается тем, кто ничего не строит на агентах. Один вопрос в трех чатах и совпавший ответ – это то же голосование зависимых голосов. Пересказ своими словами того, что ИИ отвечал раньше, – та самая подделанная цитата. И отдельная беда – пересказчик: стоит перефразировать прежний вывод, и на входе у модели оказывается цитата, которой она не давала. Дословный контекст здесь дороже краткости.
Параллельно в чате шел живой спор про агрессию. Азат честно описал цикл: объясняешь, что нужно, модель придумывает хак, объясняешь снова – придумывает следующий, «пока не обматеришь, будет гнать свою старую шарманку». Андрей возразил, что это симптом: не надо вываливать слишком много, как джуну, лучше сбросить контекст и переформулировать. Василий добавил наблюдение с другой стороны – разные модели ведут себя по-разному, одна постоянно срезает углы и тянет в рекомендованное то, что дешевле для нее самой.
«Схема – спросим трех агентов и возьмем большинство – собирает ровно то единогласие, под которым модели теряют верный ответ чаще всего» – Станислав
«Пока не обматеришь его, он и будет гнать свою старую шарманку» – Азат
Андрей принес историю, которая случилась быстрее, чем ожидали ее участники. 25 июля в интернете появилось доказательство гипотезы Коллатца на Lean4. На следующий день в ядре Lean4 нашли серьезные ошибки, позволяющие доказывать ложные утверждения. 28 июля человек с математической подготовкой прочитал доказательство и увидел, что оно опирается на схожие баги ядра. Автор потом признался, что использовал ИИ. Мораль в его формулировке: без валидации человеком мы имели бы ложную математику, без тщательной рецензии кода получим ложные программы.
Василий возразил тезисом, который трудно отбросить: ложные вещи мы имели и с человеческой валидацией тоже, просто кто-то потом углублялся и находил ошибку. Почему ИИ не может делать то же самое? И дальше – если взять группу ИИ для проверки решений другого ИИ, чем это отличается от группы людей?
Ответ Андрея оказался не про точность, а про механизм. У людей валидация идет через общество: если никто не пошел проверять, значит утверждение никому не важно, и мнение о нем даже не начало формироваться. Гипотеза Коллатца важна – поэтому нашелся хотя бы один человек, который пошел читать и нашел дыру. Автоматическая проверка всех гипотез подряд дает ситуацию, в которой мы не знаем, верить или нет, потому что проверять эту проверку некому. Василий ответил, что доверие наберется практикой: в то, что ИИ пишет код, тоже не верили.
Спор уперся в честную развилку, которую никто не разрешил. Позиция Андрея: если валидировать может только человек, круг применения ИИ ограничен тем, что люди понимают, и фронтир так не двигают. Позиция Василия: не обязательно понимать черный ящик, чтобы валидировать вход и выход. Обе позиции внутренне последовательны, и выбор между ними – это выбор, чем вы готовы рискнуть.
«Без валидации человеком мы бы имели ложную математику. Без тщательной рецензии кода мы будем иметь ложные программы» – Андрей
«Не обязательно проверять что-то, чтобы этим пользоваться» – Василий
Василий рассказал про собеседование, где экзаменатором была модель. Практическое задание: 300 одновременных операторов, два миллиона заказов, двенадцать миллионов позиций, классический N+1 в цикле по клиентам, пики по 4–6 секунд при требовании меньше 600 мс. Плюс вопрос, почему коллекция позиций иногда пустая, хотя данные в базе есть. Отдельно он отметил стиль собеседующего: на размытые ответы модель строго требовала говорить точнее и детальнее. Антиутопия, как выразился Азат.
Разбор в чате пошел быстрее, чем на самом собеседовании. Азат: то, что делается одним SQL с джойном, здесь превращено в двойной цикл. Андрей посчитал масштаб и не увидел проблемы – при индексе на внешний ключ это index seek, в среднем шесть позиций на заказ, такие объемы вообще могут жить в памяти сервера. Развилка обнаружилась не в технике: в задании было «recent orders» без уточнения, сколько заказов у клиента, и без этого числа выбор между «вытащить разом», «поставить кэш» и «заскейлить базу» превращается в угадайку.
Дальше тред свернул в спор об ORM, который в этом чате вечен. Азат: идея хорошая – абстрагироваться от базы, менять хранилище, не пускать персистентную логику в бизнес, – но ни одна ORM этого не сделала, база все равно протекает, а сверху накручено двадцать уровней абстракции. Андрей ответил коротко: смысл ORM в том, чтобы быстро писать простой код, а не в замене базы. Василий, который ORM тоже не любит, честно перечислил плюсы – не нужно вручную поддерживать update и insert при каждой новой колонке.
Показательно, что вся ветка про производительность закончилась не оптимизацией, а вопросом о недостающих требованиях. На собеседовании это и есть проверяемый навык.
«Очень душная и токсичная кстати. Когда я пытался размытые ответы говорить, она мне строго говорила: Василий, говорите более точно и детально» – Василий
«Смысл ОРМ – быстро писать простой код» – Андрей
Началось с диаграммы потребления токенов opencode по странам. Станислав обратил внимание, что цифры плохо коррелируют с населением: Турция и Россия отличаются вдвое по людям и почти не отличаются по потреблению, Германия при населении в 2,5 раза меньше потребляет втрое больше. Казахстан на 74-м месте. Андрей Звездочка тут же указал на методологическую дыру: статистика покрывает только один инструмент и не видит подписок самих провайдеров. Василий добавил, что ОАЭ на 55-м, а Эстония на 65-м – и там тоже все плохо?
Из спора о репрезентативности вырос главный конфликт недели. Андрей: шестнадцать лет активных инвестиций, а нормы «хорошего» очень низкие, специалисты штучные и закреплены за министерствами примерно так же, как раньше. Василий: деньги вкладываются, специалисты появляются, ЛРТ достроили, найм из Казахстана на удаленку стал заметнее, качество не появляется из ниоткуда.
Ключевое возражение Андрея касалось не фактов, а рамки: то, что описывает Василий, – это течение времени, а не развитие. Стабильное положение в медиане означает отсутствие инноваций, и подмена понятий начинается там, где делать как все называется «продвигаться вперед». Василий ответил шахматной аналогией: до определенного уровня выигрывает тот, кто меньше ошибается, и чтобы выйти в топ, иногда достаточно просто меньше косячить.
Спор так и не сошелся, но обнажил разницу в целевой функции. Один считает успехом появление нескольких сильных компаний на фоне общего среднего, второй – сдвиг всей медианы. Для тимлида это довольно прикладной вопрос: вы измеряете команду по лучшим людям в ней или по типичному результату?
«Казахстан стабильно в медиане. А значит, инноваций нет. Ты сидишь где был» – Андрей
«Иногда чтобы выйти в топ – нужно просто меньше косячить» – Василий
Никита попросил не кидать в чат большие простыни текста – в телеграме их тяжело читать. Из этой бытовой просьбы вырос честный разговор про то, куда девается контент сообщества. Станислав привел цифры: за месяц архив недельных отчетов посмотрели 25% участников группы, при том что сам чат хотя бы раз в неделю открывают 50% – и это отличный показатель. Михаил сформулировал причину без обиняков: на сайт надо заходить, а сценария заходить туда у него нет. Появится ссылка в чате – будет повод нажать.
Дальше обсуждали механики оживления архива. Показывать случайную заметку по расписанию, как кнопка в Обсидиане. Бот, который подсказывает: это мы уже обсуждали, вот ответ. Свой пастебин прямо на сайте, чтобы длинный текст жил в экосистеме сообщества, а в чат уходила превью-ссылка. Василий предложил MCP-эндпоинт, чтобы вопросы к базе знаний задавались из своего ИИ. Станислав возразил, что главная проблема тут не техническая: узнать о такой возможности и подключить ее – два барьера, на которых теряется почти вся аудитория.
Отдельная ветка объяснила, почему в чат мало пишут о проблемах. Станислав: здесь сидят руководители, и написать о своей боли – значит получить порицание вместо помощи. Уалихан добавил личное наблюдение с другой стороны: чем лучше у него в жизни, тем меньше времени он проводит в чатах. А новичок в сообществе признался, что просто вслушивается, потому что не знает, о чем писать, – и что в других сообществах разработчиков единственная стратегия выживания была писать адекватному человеку в личку, потому что в группе сожрут.
К концу недели разговор превратился в код: анонимные посты через бота и портал, пастебин с хранением 30 дней, поиск по статьям, обертка длинных сообщений в короткие ссылки. Редкий случай, когда тред про «нас мало читают» закрылся не выводом, а релизом.
«За месяц архив посмотрели 25% от участников группы» – Станислав
«Так это надо на сайт заходить. У меня нет сценария, чтобы на него заходить. Если бы ссылки появлялись тут – это повод на них нажать» – Михаил
Никита спросил, есть ли что-то в духе продуктовых фреймворков, но с заделом на полноценное использование ИИ. Михаил ответил ссылкой на разбор новой AI-Native SAFe Big Picture и своим комментарием, где честно разделил изменения на осмысленные и декоративные.
В плюс он записал вещи, которые и так обсуждаются независимо от SAFe: более компактные команды за счет агентов, переход к спецификациям, укорачивание PI-циклов, замена System demo на Customer demo, потому что готовность результата наступает быстрее и подтверждение нужно раньше, и акцент на подготовке корпоративных данных с их обычной фрагментарностью.
В минус – ощущение, что «теперь у нас есть AI и надо бы куда-то его пристроить». С картинки исчезли бэклоги команды и поезда, вместо них появились outcomes. Михаил отметил риск превращения этого в лозунг: замер эффекта от выходов – базовая база, и с ИИ обратная связь должна стать быстрее, но эффект от outcomes может оказаться отдаленным, как в проектном управлении. Отдельно он заметил, что консенсуса по организации работы команд с агентами просто нет: привычный скрам агентам не особо нужен, но Сазерленд ушел в проработку AI Scrum по самые помидоры.
Денис поставил вопрос, который снимает половину дискуссии: SDD все колхозят, а у кого delivery реально ускорилось без ущерба качеству и SLA? Ответа в треде не прозвучало.
«Местами сформулировано так, что теперь у нас есть AI и надо бы куда-то его пристроить» – Михаил
«SDD все колхозят, а delivery у кого ускорилось, без ущерба quality/SLA?» – Денис
Андрей опубликовал изнутри планы .NET Foundation: операционное пособие, система управления членством, публикация протоколов комитетов, тикет-система для поддержки проектов и коммуникация ценностей. Пять пунктов, из которых первые четыре про процессы.
Станислав сразу указал на порядок: пункт про «зачем мы существуем» стоит пятым, а должен быть нулевым. Возможно, потому что фокус сделан на процессной составляющей. А возможно, потому что организация сама не может себе ответить на этот вопрос.
Самым полезным оказался вопрос Максима, автора пары опенсорсных библиотек: что конкретно он теряет от того, что фонд его не поддерживает? Ответ Андрея был предметным – маркетинг, сертификат для подписи софта, немного CI. Максим сформулировал свою реальную потребность честнее любого запроса на грант: ему нужно, чтобы репозиторий находился в поиске по запросу вида «библиотека для генерации PDF», а дальше смотрят на стабильность версий, звезды и проработанность документации. То есть нужен маркетинг, а не деньги. Андрей заметил, что по звездам ищут редко, чаще приходят через статьи и новости.
Общий вывод чата вышел шире фондов: если организация невнятно продает свои услуги, это обычно предвестник проблем. И это довольно точно переводится на любую внутреннюю платформенную команду, которая не может объяснить, зачем к ней идти.
«Да я и не питаю иллюзий, просто перспектива не ясна была, чего я лишаюсь из-за того, что DNF меня не поддерживает» – Максим
«Зачем вообще куда-то идти, если люди невнятно продают свои услуги? Часто это к проблемам» – АндрейЧитать в чате →
Егор задал практический вопрос: удобнее ли зарубежному работодателю платить на американскую LLC вместо казахстанского ИП, и согласятся ли платить туда местные компании. Тред собрал разброс мнений от «норм история» до «пахнет схемой» – и один развернутый ответ по существу.
Спорили в основном о том, где возникает налог. Андрей Звездочка держал линию, что юрлицо в США Казахстану ничего не должно, а обязательства появляются в момент, когда деньги приходят вам как физлицу. Максим возражал, что вся конструкция и существует ради того, чтобы деньги в итоге дошли до человека, а оплата казахстанской компанией на LLC казахстанца выглядит ровно как схема. Станислав разложил цепочку: корпоративный налог платится в США, дальше в зависимости от резидентства – налог на доход как физлицо, а при получении на казахстанское юрлицо добавляется корпоративный налог и здесь.
Нурлан добавил то, чего не было ни у одной из сторон, – цену эксплуатации. Для passthrough-структуры эффективная ставка может оказаться низкой, но за несданную или поздно сданную декларацию LLC прилетает штраф IRS в 25 000 долларов, поэтому нужен CPA, а это постоянные расходы. Владелец обязан сдавать и свою американскую отчетность. А если регистрация в Вайоминге, Казахстан считает его офшорной зоной, и налог здесь может оказаться выше ожидаемого.
Станислав закрыл тему вопросом про масштаб: стоят ли 50 тысяч долларов в год такой сложности? Андрей Звездочка ответил, что для b2c-продукта со Stripe компания все равно понадобится – то есть решать надо не по налоговой ставке, а по тому, зачем вам юрлицо в принципе.
«Если это Wyoming, то KZ считает Wyoming офшорной зоной, и может оказаться, что налог в КЗ окажется выше, чем ожидали. Короче, нюансов много» – Нурлан
«А главное, вопрос. 50 тыс долларов в год стоят таких сложностей?» – СтаниславЧитать в чате →
Хотите продолжить обсуждение?
Обсудить в Telegram