Неделя началась с поста Сантьяго Вальдаррамы, который прочитали больше миллиона раз: он две недели не смотрел на сгенерированный код, претензии остались только к стилю, и время лучше тратить на проверку системы целиком, чем на разглядывание строк. Чат разошелся не по линии «согласен – не согласен», а по линии «а чем вы это заменили».
Данияр подтвердил на своей практике: интерфейсы и сигнатуры он смотрит и правит руками, а имплементацию детально не читает уже полгода, и за эти полгода ни разу не понадобился отладчик. Азат зашел дальше – у него кода нет даже в репозитории, он тестирует такой подход. Андрей возразил с другой стороны: автор поста исследователь, а не инженер, ученые системно никогда не хотели писать код и сопротивлялись попыткам навести у них порядок. Михаил напомнил про исследование Microsoft о рисках для когнитивных способностей.
Интереснее всего оказался тезис Данияра, который он сам назвал непопулярным: чтобы эффективно применять агентов, нужен навык технического менеджмента хотя бы тимлидского уровня. На работу с агентом распространяются те же механизмы, что и на работу с исполнителем, и ошибки ровно те же. Тут спорящие внезапно сошлись – Андрей согласился «очень сильно».
Практическая иллюстрация пришла оттуда же. Андрей поддерживает форк инструмента деобфускации, куда прилетел большой пулреквест: код нормальный, но одним куском и без тестов, и разбирать его пришлось самому мейнтейнеру. Получается, вопрос не в том, читать ли код, а в том, кто платит за отсутствие структуры. Если чтение строк отменяется, то что именно занимает его место в вашем процессе – эвалы, приемочные тесты, ред-тим или ничего?
«Именно имплементацию я детально не читаю уже полгода где-то. Ну и самое главное: дебаггер мне не понадобился за эти полгода ни разу» – Данияр
«Я пришел к тому, что не только не читаю код – его никто не читает, его даже в репе нет» – Азат
Самая практичная история недели пришла от участника, который поймал баг с округлением. В Казахстане процент считается до двух знаков, а в Кувейте – до трех. Класс, отвечавший за операции, был покрыт тестами почти полностью и считался пуленепробиваемым. Разбор показал другое: половина тестов проверяла, что поле пришло, а логику не тестировал никто – сплошные Assert.NotNull.
Дальше он пошел гуглить, можно ли протестировать сами тесты, и нашел мутационное тестирование. Инструмент меняет в коде плюс на минус, равенство на «больше», выкидывает условия – и смотрит, упадет ли тест. Если тест после мутации проходит, мутация выжила, а тест неточный. При локальном прогоне выживали мутации даже там, где удалялись целые ветвления, при 92% покрытия.
Дальше это стало процессом: раз в месяц крон в кубере поднимает контейнер на 4 vCPU и 8 ГБ, Stryker крутится два-три часа, отчет падает в слак-канал, выжившие мутации разбираются и уходят в бэклог. Андрей заметил, что это по сути обычный статический анализ в CI, на что автор ответил коротко: в CI это дорого и долго – отсюда и месячная процедура, а не гейт на каждый пулреквест.
На фоне первой темы это выглядит как готовый ответ на вопрос «чем заменить чтение кода». Покрытие говорит, что строка выполнилась, мутационное тестирование – что тест поймает ее поломку. Разница между этими двумя утверждениями в кувейтском кейсе стоила три знака после запятой на 300 000 заказов в день. Знаете ли вы, какой процент ваших тестов переживет удаление ближайшей ифки?
«Посмотрел все тесты глазами и понял: половина тестов сгенерировано, типа это поле точно пришло, а вот логику никто не тестил» – участник чата
«Если тест успешно прошел, то мутация выжила, а это значит, что тест неточный» – участник чата
Азат сформулировал наблюдение, которое понравилось не всем, но зацепило многих: закон Конвея работает и в разработке с агентами. Один агент на всю репозиторию и один поток общения с ним дают одно большое спагетти. Оркестратор, который вызывает субагентов на каждый участок, дает иерархический код. Структура диалога отпечатывается в структуре кода так же, как структура организации.
Из этого он вывел обратный маневр Конвея: сначала нарисовать архитектуру, которую хотите получить, и уже под нее строить оркестрацию. Артем описал противоположную практику – десять репозиториев в одной папке и общий claude.md, где прописаны связи и конвенции между сервисами. Азат ответил, что говорит ровно об обратном: глобальный файл делает архитектуру монолитной и тесно связной.
Максим предложил компромисс, который у него уже работает: совмещать глобальный контекст и модульный, а в конце плана явно писать, что под каждый сервис должен работать отдельный субагент. Азат добавил рамку из книги Team Topologies – если заменить в ней «команду» на «агента», рассуждения про когнитивную нагрузку и поток ценности читаются один в один.
Антон отреагировал скептически – «переизобретаете разработку», Андрей увидел в этом скорее вайбмесиво. Азат ответил, что умные люди уже решили похожие проблемы, почему бы не воспользоваться результатами. Вопрос открытый: ваша схема запуска агентов сегодня отражает архитектуру, которую вы хотите, или ту, которая случайно сложилась?
«Если у тебя один агент на всю репу и ты общаешься с ним в одном потоке, то твой код неминуемо превратится в одно большое спагетти» – Азат
«Мой поинт в том – оркестрировать агентов так, как вы видите свою архитектуру» – Азат
Василий признался, что чем больше работает, тем больше ценит диаграммы. Раньше схемы были документацией из разряда «вроде надо, а вроде можно обойтись», теперь он от них фанатеет: по схеме ИИ сразу понимает, как разбить работу на агентов. Тема встретилась с той же неделей и тем же спором про чтение кода – и получила неудобный вопрос.
Максим спросил дважды и по делу: как вы поймете, что ИИ сделал так, как нарисовано, и как вы поймете, что он понял схему так же, как вы. Василий предложил проверку в обратную сторону – попросить сгенерировать схему по получившемуся коду и сравнить с исходной. Плюс смотреть не весь код, а интерфейсы: у сервисов это эндпоинты, вход-выход и схема базы, внутри сервиса – интерфейсы компонентов и база. Львиная доля остального – DTO, которые никого не волнуют.
Максим остался при своем: никогда не угадаешь, когда модель начнет придумывать. Василий ответил тем же аргументом, что и в теме про агентов как исполнителей: делегируя задачу человеку, вы тоже не знаете, когда сработает человеческий фактор. Похоже, схема тут работает не как гарантия, а как дешевый способ сравнить намерение с результатом – примерно как приемочный тест, только для структуры.
«Как ты поймешь, что ИИ понял схему правильно и так, как ты ее понял» – Максим
«Можно попросить сгенерить схему и сравнить то, что было, с тем, что получилось» – Василий
Из спора про схемы вырос отдельный тезис Василия: работать с агентами нужно так же, как с командами и людьми. Никита моментально уточнил – то есть кричать на них? Максим предложил формулировку капсом, которую хоть раз писал каждый: WHY THE FUCK YOU IMPLEMENTED LIKE THIS.
Ответ Василия оказался неожиданно жестким по отношению к менеджерам, а не к моделям. Агенты – это испытание для тех лидов, кто не умеет объяснять. Уволить агента нельзя, накричать можно, но результат от этого лучше не станет, а работать без него уже не выходит. Раньше плохую постановку задачи спасал догадливый разработчик, теперь спасать некому.
В чате вспомнили и обратный эффект: если давить, модель, как и человек, выдаст что угодно, лишь бы давление прекратилось. Получается неплохой диагностический инструмент – качество ваших промптов довольно точно показывает качество ваших постановок задач людям. Хотели бы вы, чтобы ваши тикеты читал кто-то настолько же буквальный?
«Агенты – это кстати испытания для людей, лидов, менеджеров, которые не могут объяснять» – Василий
«Никогда не угадаешь, когда ии загаллюционирует и начнет что-то придумывать, к сожалению» – Максим
Станислав заметил, что один из вендоров постоянно делает анонсы, но в бенчмарках не светится. Антон ответил вопросом, который развернул тему: а зачем вообще бенчмарк? Что он вам дает, если это оценка результатов на чужих задачах? Сам он хотел бы знать perplexity модели на своем вопросе, но с закрытой моделью этого не получить.
Максим защищал бенчмарки не как истину, а как обязанность продавца. Если вендор хочет внимания, он должен бороться за пользователя, а не пользователь – тратить свои деньги на проверку обещаний. Аналогия у него получилась убедительная: обзоры ноутбуков меряют открытие тяжелого проекта в XCode и рендер конкретного ролика. Зрителю неважно, что именно за проект, важно, что задача одинаковая для всех и цифры сравнимы.
Итог спора выглядит так: бенчмарк ничего не говорит о вашей работе, но его отсутствие говорит о вендоре. Как сформулировал Максим, если продавец не удосужился дать информацию, то либо он глуповат, либо информация не в пользу продукта. Станислав добавил третий слой – даже один и тот же бенчмарк в отчетах разных вендоров показывает разные результаты на одних и тех же моделях.
Практический вывод неделя дала тот же, что и месяц назад: публичные цифры – это фильтр на входе, а решение принимается на своих эвалах. Разница только в том, что теперь понятно, зачем читать чужие бенчмарки вообще – чтобы решить, стоит ли тратить неделю на собственную проверку.
«Я ожидаю больше инфы о продукте от продающего этот продукт. Если продавец не удосужился предоставить эту инфу, то либо он глуповат, либо эта инфа – не в пользу продукта» – Максим
«Точнее, что вам дает процесс решения чужих задач и оценка тех результатов» – Антон
Алексей пришел с конкретным вопросом после разговора с ботом-продавцом Anthropic: множители 5x и 20x относятся к дневной сессии, а насколько увеличен недельный лимит – нигде не написано. Ответы сообщества сложились в практическую картину.
Дмитрий: на каждодневную работу хватает подписки за 100 долларов, лимиты динамические, точного количества никто не скажет. Павел по ощущениям оценил недельный лимит примерно в пять дневных с небольшим запасом – когда он использовал 20x на полную катушку, недели хватало впритык. Алексей резонно заметил, что кодовая база у всех разная, от нее и зависит расход.
Станислав на это и обратил внимание: раз базы разные, чужие ответы не помогут – он сам выедает 70–80% от 5x, а когда вендор временно удвоил лимиты, не смог их сжечь даже на неважных проектах. И добавил то, что важнее самих цифр: расход определяется организацией работы. Планировать может дорогая модель, а ставить задачи на кодинг – дешевым.
«Лимиты динамические, количество тебе никто не скажет» – Дмитрий
«Важнее же, как вы организуете работу. Планировать может и fable, а задачи ставить другим дешевым моделям на кодинг» – Станислав
Участник анонсировал unissh – опенсорсный SSH-клиент с self-hosted zero-knowledge сервером синхронизации, сделанный как замена платному Termius. Обсуждение почти сразу свернуло с продукта на вопрос, который оказался интереснее: а кому вообще нужен синхронизируемый доступ к серверам.
Антон занял максималистскую позицию: разработчики, тимлиды и тем более гендиректор на сервере не нужны никогда, а те, кто занимается серверами, лезут туда не через SSH. В его практике добраться до сервака по SSH – это уже само по себе диагноз, дальше начинается неделя разбора инцидента. Значит и хранилище секретов для SSH-клиента решает проблему, которой не должно быть.
Возражения оказались приземленнее. Андрей: не все готовы к терраформам и ансиблам, потому что для этого нужна мотивация и умение в идемпотентность, а это нетривиально – и без процессов оно не появится. Станислав ответил еще честнее: хожу, потому что лень описывать все в ансибле. Тут же прилетел совет от тезки – взять логи терминала и заставить модель собрать из них сценарии ансибла.
Фоном шел старый спор о том, стыдно ли ронять прод. Максим предложил показать пальцем на человека с пятью годами опыта, который ни разу его не уронил, и желающих не нашлось. Похоже, честный вывод недели такой: SSH на проде – не грех, а метрика зрелости процессов, и полезнее не запрещать его, а считать, сколько раз в месяц он реально понадобился.
«В моей практике, как только ты через ssh добрался до сервака, это все – финита» – Антон
«Я хожу. Мне лень все описать в ансибл» – Станислав
Василий принес исследование, опровергающее роль осознанной практики, и сам не понял, радоваться или нет. Спор с Андреем растянулся на полдня и оказался не про науку, а про то, что лид говорит человеку в начале пути.
Позиция Василия: раньше он говорил коллегам, что усилия делают из них хороших специалистов, а теперь выходит, что нужно упоминать и потолок. Позиция Андрея: ничего не поменялось – практикуешься, становишься лучше; результат, который вы видели своими глазами, не отменяется новой статьей, а популярное толкование обеих работ сильно упрощено. Отдельно он заметил, что аргумент про гены – это уже провал популяризации.
Дальше подключились остальные и разложили тему на слои. Павел развел уровни: одно дело хороший специалист, другое – топовый, и на хорошего 10 000 часов вполне хватает; при этом тренер обязан честно назвать цену. Азат возразил на фатализм: откуда вы знаете свой потолок, пока не изучили технику и не попробовали. Станислав добавил третий фактор – удачу, то есть все, что не зависит от ваших усилий: семья, страна, компьютер в школе, а по некоторым данным даже дата рождения.
Для тимлида тут получается вполне рабочая формулировка. Разговор про статистический потолок демотивирует и почти всегда не про конкретного человека перед вами. Разговор про цену – про часы, отказ от других занятий, длину дистанции – честный и проверяемый. Что вы отвечаете сотруднику, который спрашивает, станет ли он сильным инженером?
«Когда я обучаю коллег, то говорю, что если прикладывать усилия – то вполне можно стать хорошим специалистом. А теперь оказывается, не совсем так» – Василий
«Не, одно дело хороших, а другое топовым. Для хорошего 10к часов хватит» – Павел
Социальный вопрос недели задал участник под ником LSTR: как вы совмещаете семью и работу из дома. Ответы разошлись ровно по наличию детей, что само по себе показательно.
Михаил: летом на каникулах это капец как непросто. Антон описал свой случай с двумя маленькими детьми как гиблое занятие – дом напоминает постапокалиптический пейзаж, а работы по постройке декораций идут круглосуточно; в итоге он просто перестал работать по найму, когда появились дети. Василий, у которого детей нет, честно сказал, что ожидал проблем, а по факту их нет: заранее обговариваются моменты, когда можно отвлекать, а когда нельзя.
Интересная деталь в его ответе – про агентов. Когда вы натравили агента и ждете результат, работа и так становится асинхронной, а значит рваный домашний ритм перестает конфликтовать с рабочим. Андрей закрыл тему одной фразой, которую сначала прочитали как «семья важнее работы». А сам автор вопроса предложил бытовое решение – возрождать практику коворкинга хотя бы раз в неделю.
«Семья всегда побеждает» – Андрей
«Учитывая текущее состояние, когда агентов натравил и сидишь ждешь – работа так и так становится асинхронной» – Василий
Хотите продолжить обсуждение?
Обсудить в Telegram