Вопрос «что такое AKASHI?» из Ташкента запустил самый длинный тред недели. Речь про строящийся дата-центр от Фридома на 100 МВт с заявленным Tier 4. Реакция чата оказалась резко скептической и на удивление конкретной.
Станислав разложил претензии по трем пунктам: в Казахстане нет электричества, чтобы питать такой ЦОД, нет спроса на такие мощности, и не решена проблема канала во внешний мир. Для масштаба он привел сравнение: 100 МВт – это потребление примерно города Караганда. Предложение решить каналы парой Старлинков разбилось о требования самого Tier 4: все каналы должны быть дублированы, а латенси спутника для ЦОД неприемлема. Отдельно прозвучало, что 100 МВт по нынешним меркам вообще не поражают – большие игроки строят на гигаватты.
Дальше разговор ушел в более практичное русло: а что вообще есть на рынке. Картина получилась невеселая. Yandex Cloud в Казахстане живет в одном ЦОДе, PS периодически ложится под DDoS, AWS в регионе нет. У pskz семь площадок, но мощности там оценили в единицы мегаватт. Василий сформулировал итог одним словом – колхоз. Ответ Андрея был короче: никто не готов платить за надежность, а HA всегда стоил дорого.
Из спора вылез рабочий обходной путь: брать трех провайдеров и собирать свой виртуальный дата-центр, приняв на себя проблему сетевой связанности. Вопрос, на который чат ответа не дал: если ваш прод сегодня стоит в единственном ЦОДе, вы уже знаете цену переезда – или узнаете ее в день пожара?
«100 МВт – это потребление электричества примерно с г. Караганда» – Станислав
«Никто не готов платить за надежность» – Андрей
Андрей принес разбор пайплайнов Bun и поставил диагноз: делать ненадежный сигнал – это организационный косяк. Проблема не в падающих тестах, а в том, что при пачке коммитов старые прогоны отменяются, и история билдов превращается в кашу. Понять, что где и когда сломалось, невозможно.
Возражения прозвучали с двух сторон. Станислав: отменять устаревшие прогоны логично, зачем вейстить ресурсы. Андрей Звездочка: последовательный CI нужен там, где много разработчиков параллельно пилят фичи и надо уметь выкинуть сломанный коммит – а если над проектом работает фактически один человек, такой проблемы просто нет, найти упавшую сборку можно бинарным поиском. Андрей ответил встречным вопросом: тогда зачем вообще запускать так часто, если на один пройденный прогон приходится пять-шесть остановленных – это ведь тоже трата.
Дальше вылезла интересная развилка про природу флаки. Станислав признал, что у него самого качество CI ниже 50%, но там сверху гоняются нестабильные E2E-тесты на продукте. У Bun же все детерминированно, то есть зеленый CI – вполне достижимая цель, а у Node он держится около 90%. Получается, ненадежный сигнал в детерминированном проекте – это выбор, а не обстоятельство.
Финальная рамка спора вышла шире одного репозитория. С одной стороны – стартап-стайл «ну ладно, поправит», который индустрия изживала много лет. С другой – возражение, что издержки от него просто недостаточно велики, чтобы отказываться. Пока рядом с проектом один человек, это правда работает. А потом он заболеет или уволится.
«Я не понимаю, почему вообще им сиай нужен, если он ничего не показывает. Ну типа чето, когда-то работает» – Андрей
«Значит, издержки от стартап-фигни недостаточно большие, чтобы отказываться от этого. Бывает» – Андрей Звездочка
Спор начался с невинного вопроса Василия: насколько вы больше доверяете исследованиям, чем собственным наблюдениям, по шкале от 0 до 100? Станислав ответил, что скорее исследованиям – если там достаточно данных и респондентов, а свое наблюдение это всегда частный случай. Василий возразил ходом, который трудно опровергнуть: люди, верящие, что гениями рождаются, книжку «Гении и аутсайдеры» просто не приняли. Исследование живет внутри картины мира автора.
Дальше разговор ушел в удачу. Позиция Станислава: даже выполнив все условия – условные десять тысяч часов – ты не станешь лучшим, и рассуждать стоит на уровне вероятностей. Знание про удачу дает спокойствие вместо самобичевания: отказ в работе не всегда про плохие скиллы. Позиция Василия зеркальная: удача нам неподконтрольна, значит думать о ней смысла нет, план один и тот же – идти дальше и повышать шансы. А если относиться к удаче всерьез, это уже недалеко от религии.
Разрешил спор Азат с неожиданной стороны. Как полупрофессиональный игрок в покер он заметил: карты приходят всем одинаково, примерно раз в 221 сдачу, но про выигрывает много на хороших и проигрывает мало на плохих, а новичок наоборот. На дистанции удача выравнивается в среднее, значение имеет скилл. Профессионал не рассчитывает на один турнир – он играет год.
Практический остаток спора неожиданно приземленный. Максим сформулировал его короче всех: суть удачи в том, чтобы к подвернувшейся возможности быть готовым. А вопрос про исследования остался открытым: если данные расходятся с вашим ежедневным опытом, что вы пересмотрите первым?
«Удача не важна. Людям часто встречаются удачные стечения обстоятельств, но кто-то выжимает из них максимум, а кто-то их игнорирует» – Азат
«Плох ли ты скиллами, ты можешь оценить. А удачу – нет» – Станислав
Уалихан вспомнил архитектора, с которым работал: 56 лет, фабричные линии, софт для атомной промышленности, система связи атомных ледоколов. Редкий навык – проектировать масштабируемый софт на десятилетия вперед. И тут же поставил вопрос ребром: работая в облачном провайдере, он видит, что такой человек команде нужен, но где его взять.
Андрей сразу указал на природу дефицита: этот навык вполне обучаем, просто большинство бизнес-окружений ему не учат – они учат гибкости. И спорить об этом с адептами гибкости тяжело. Его совет был не про людей вовсе: менять бизнес-процессы в сторону измерения операционных показателей, а специалисты подтянутся. Если руководство не готово принимать решения на данных, никакой найм не поможет.
Уалихан ответил на предложение растить инхаус коротко: мы уже довыращивались, можно не надо. И развернул претензию: инхаус-рост имеет смысл, когда есть четкая лестница специалиста и регламенты. А когда человек работает десять с лишним лет в одной компании и не знает, что бывает иначе, это уже не специалист, а адепт одного культа. Ошибка такого рода вгоняет компанию в проблемы, которые решаются не год и не два.
Здесь чат столкнул две честные позиции. Растить внутри дешевле, но легко вырастить эксперта по собственному легаси. Нанимать снаружи дорого и долго, а редкого системщика можно просто не найти. Третий путь – начать с измерений и решать по цифрам – самый медленный и наименее популярный.
«Когда человек работает 10+ лет в компании и знать не знает, что можно как-то иначе, это уже не спец, а просто сектант-адепт одного культа» – Уалихан
«Вам нужно бизнес-процессы менять в сторону измерения своих операционных показателей. Технические специалисты подтянутся» – АндрейЧитать в чате →
Мимоходом брошенное «интенсивность работы явно выросла» вылилось в один из самых практичных выводов недели. Станислав сформулировал механику: ИИ не уменьшает работу, он ее уплотняет – вы просто делаете больше за то же время. Растет не свобода, а эффективность.
Василий добавил к этому наблюдение из практики. Делая больше, он стал ценить узкие интерфейсы вместо всеобъемлющих – причем не только API компонентов, но и пользовательские. Раньше это было nice to have, теперь стало must have, потому что иначе агенту очень тяжело объяснить, что куда и зачем, и он начинает писать ерунду. Простой CRUD со списком, формой и кнопкой удаления агент вывозит. А форма, где объекты связаны и одним запросом можно создавать цепочки и переставлять связи, для него уже сложна.
Иллюстрация подъехала в тот же день. У Василия на фронте поехала дата из-за таймзоны, и модель вместо похода в бекенд предложила напихать сдвиг на фронте. Когда ее ткнули носом, она поправила бекенд, но не сделала миграцию старых данных – и аргументировала это тем, что две недели назад миграцию уже предлагала и получила отказ. Прямо как человек, только человека можно переспросить.
Вывод получается неудобный, но полезный: сложность интерфейсов теперь имеет прямую цену в токенах и в качестве генерации. Стоит ли осознанно упрощать API ради того, чтобы агент справлялся, или это преждевременная подгонка архитектуры под инструмент?
«ИИ уплотняет работу, не уменьшает ее. Ты просто теперь делаешь больше» – Станислав
«Раньше узкие интерфейсы были nice to have, теперь must have. Иначе ИИ очень тяжело объяснить, что куда зачем, и он там херню пишет» – ВасилийЧитать в чате →
На среде разговор дошел до неожиданно узкого места. Андрей заметил, что при обучении ЛЛМ не помогает: она отлично помогает решать задачи, но передача проекта и онбординг – это классические примеры именно обучения, и с ними есть вопросы.
Азат поспорил: смотря как учиться. Онбордируемый с ЛЛМ быстрее разбирается сам, у него возникает меньше вопросов к команде. Андрей ответил вопросом, который стоит того, чтобы его записать: он разобрался в системе или смог сделать задачу? Азат парировал встречным: а какие критерии приемки у «разобрался в системе»?
Спор оборвался без победителя, но оставил рабочий инструмент. Прием, который на той же неделе прозвучал в другой ветке – из исследования про студентов, отказывающихся сдавать код, который не могут объяснить построчно – ложится сюда идеально. Вопрос «объясните, что здесь происходит» превращается из вредности в проверку, отличающую понимание от закрытого тикета.
«При обучении ЛЛМ не помогает. Передача проекта – это как раз классический пример обучения. Как и онбординг» – Андрей
«Он разобрался в системе, или смог сделать задачу? Как мне кажется, есть нюансик в этом» – АндрейЧитать в чате →
Статистика по ускорению от ИИ вызвала у участницы чата простой вопрос: как в крупных компаниях валидируют код от ИИ, чтобы получать плюшки, но не падать в качестве. Ответ Андрея оказался коротким до обидного: линтеры – или пишут медленнее.
Дальше разговор ушел в тесты, и там прозвучал важный нюанс. Полное покрытие, как и всегда, не так уж важно – важно покрытие того, что нужно: рискованных и значимых вещей. А стремление к стопроцентному покрытию Андрей описал едко: это больше чтобы агенту приятно было. Как крайний случай он привел разработчиков Dragonfly, которые ИИ-код просто не пушат – и говорят, что за счет этого стабильность выросла.
Цифры недели ложатся в тот же сюжет. GitClear и GitKraken разобрали 623 миллиона реальных изменений кода за 2023–2026 годы: дублирование выросло на 81%, повторное использование упало на 70%, рефакторинг легаси – на 74%. Это объективные коммиты, а не опрос. Если команда меряет продуктивность объемом произведенного кода, эти цифры – аргумент сменить метрику.
Второй набор данных подсказывает, куда смотреть еще. По опросам, 41% иногда отдают работу, которую не смогут объяснить, если спросят, а 39% отправляют, не проверив до конца. Сэкономленный день не исчезает – он возвращается отложенным риском у кого-то ниже по процессу. И проверка на галлюцинации, судя по июльской работе на arXiv, дешевле как система, а не как внимательность конкретного человека в конце дня.
«Фулл-покрытие как и обычно не так важно. Важно покрытие тестами того, что нужно – рискованных и важных вещей. Фулл это больше чтобы агенту приятно было» – Андрей
«Как в крупных компаниях валидируют код от ии, чтобы получать плюшки, но не падать в качестве?» – участница чата
Артур пожаловался на консультанта-ассистента в маркетплейсе, Уалихан посоветовал послать модель матом – говорят, повышает эффективность. Станислав ответил жестко: нет, абсолютно не повышает, это только ухудшает работу, помогает лишь структурированный ввод. Василий тут же принес исследование, утверждающее обратное.
Дальше спор стал интереснее самого вопроса про мат. Станислав отвел статью двумя аргументами: ей уже год, и она про вежливость, а фронтир-модели всю эту магию делают под капотом сами – эффект ловится на слабых моделях. Андрей Звездочка зашел с другой стороны: если бы исследование было реальным, авторы выложили бы эвалы. Trust me bro – это шиза.
Здесь Андрей возразил своему тезке, и возражение стоит того, чтобы его удержать. То, что данные не выложили, говорит лишь о том, что авторы поступили плохо, но само по себе ничего не говорит о качестве результата. Отбрасывать исследования по быстрой эвристике – рациональный на вид ход, но так можно выкинуть почти все, включая работы вполне классных ученых, и остаться наедине с мифами. Разговор дошел до DOI: у препринта он есть, но сам на себя, и нигде статья не опубликована.
Станислав добавил рамку, снимающую часть напряжения: arXiv ценен препринтами, которые могут никогда не выйти в журнале. Это идеи для валидации в реальном времени. Хочешь проверить – повтори эксперимент у себя. Что, если честно, и есть ответ на вопрос из начала треда.
«Если нет воспроизводимости, а все как trust me bro – то не стоит тратить время на этот текст» – Андрей Звездочка
«Отказываться от результатов и списывать по быстрой эвристике – так можно чуть ли не все исследования выкинуть» – Андрей
Уалихан рассказал, зачем строит свой control plane: не очередное облако для энтерпрайза и государства, а доступная отказоустойчивая инфраструктура с низкой наценкой для МСБ и инди-разработчиков. Фокус не на «управляй как хочешь», а на готовой платформе под кодовую базу.
Чат отреагировал вопросами, которые обычно задают на кастдеве. Станислав: почему твое облако, а не OpenShift, если OKD денег не стоит? Ответ: OKD бесплатен, а управление им – нет, СХД, сети, траблшутинг и observability никуда не исчезают по воле оркестратора. Андрей посчитал иначе: для клиентов такая система дает не меньше 200% оверхеда на инфру, а это еще сильнее сужает и без того специфическую нишу. Уалихан ответил, что как раз широкая ниша ему и не нужна – без инвестиций и штата не надо отбивать тонны денег.
Отдельно всплыл спор про опенсорс. Уалихан: ни одно опенсорс-решение не может быть managed infrastructure, потому что ты не знаешь, на каком железе его запустят, и потому популярные PaaS застревают на Docker Swarm и боятся идти в кубер. Андрей возразил: это не твоя проблема, пусть тот, кто запускает, приходит с патчем – а если не веришь в силу опенсорса, то показывать исходники бессмысленно, ты теряешь и продажи, и социальную составляющую.
Самое неприятное замечание пришло не про технологии. Уалихан упомянул, что вкладывает 40% зарплаты и ужинал дошираком. Нурлан ответил тем, что стоит повесить над столом каждому фаундеру: отсутствие расходов увеличивает runway, но он не бесконечен.
«Самый лучший фаундер – это сытый и выспавшийся фаундер» – Нурлан
«Если не веришь в силу опенсорса, то ты зачем-то показываешь исходник, что не нужно для продаж, и лишаешься социальной составляющей. Это худшее из двух миров» – Андрей
Хотите продолжить обсуждение?
Обсудить в Telegram