Понедельник начался с простого вопроса – много ли багов делают агенты. Ответ оказался неожиданным: багов в привычном смысле нет, компилятор, линтеры и тесты ловят их до коммита. Ломается другое. Фича реализована в коде, но в интерфейсе нет места ей воспользоваться. Есть кнопка, но за ней ничего не стоит. Две задачи работают по отдельности, а сквозного процесса между ними никто не написал. Каждая была вне скоупа своего брифа.
Азат сформулировал корень проблемы жестче: агент пишет корректный код по некорректной спеке. Человеческий язык гибкий, любое требование можно истолковать или объявить неприменимым, а потом написать полотно о том, почему сделано «правильно». Отсюда его подход: код одноразовый, требования живут только в тестах. Оркестратор пишет тесты, свежий агент в пустой песочнице получает единственную задачу – сделать их зелеными, возвращает артефакт без кода, оркестратор вкладывает его в мастер-тест. Через несколько итераций спека кристаллизуется.
Дмитрий защищал другую конструкцию: спеки живут в файлах, а связь с кодом обеспечивает трассировка – требование, реализация, тесты. Нет реализации или тестов у требования – ошибка, и находит ее алгоритм, а не агент. Проверку соответствия можно поручить модели с маленьким контекстом, а сверху поставить оппонента, например мутационное тестирование. Азат возражал по опыту: агент отчитается, что все покрыто на 146 процентов, а запускаешь – не работает.
Самый убедительный аргумент недели пришел из практики. Требование «вся логика на GPU» не заенфорсилось ни через инструкции, ни через ревью другим агентом – все клялись, что все на GPU, а приложение выдавало 10 кадров в секунду. Сработал единственный тест: миллион объектов быстрее миллисекунды. После него программа полетела на 144. Побочный эффект подхода тоже полезен: когда требования противоречат друг другу, агент в песочнице находит это безжалостно. А как в вашем проекте отличают выполненное требование от отчета о выполнении?
«Агенты пишут корректный код, но некорректную спеку. Код делает что описали, но не то, что тебе надо» – Азат
«Получается театр, построенный агентом: все требования оттестированы и выполнены на 100%. Запускаешь, а там ничего не работает» – Азат
Станислав продолжил вести разработку приложения вслух. К концу недели – больше ста долларов, 250 зарегистрированных задач, работающий бэкенд, сборка в TestFlight и лэндинг. Код по-прежнему пишет агент, автор его не читает: читает спеки и чат агента. Тесты занимают около 70 процентов кодовой базы, и за все время приложение ни разу не крашнулось.
Интереснее список того, что все-таки сломалось. Пикер даты закрывается, только если выбрать дату, отличную от сегодняшней. Язык переключается, а обещанного уведомления о перезапуске нет. Есть мертвый код – написан, но не вызван. Половина этих дефектов – не баги, а слабые постановки: человек по ходу реализации додумывает детали сам, агент не додумывает, если не попросить. Пятьдесят задач в бэклоге, каждая пятая, появились именно из ручного тестирования на живом телефоне.
Отдельная строка – про секреты, которые на этапе разработки уехали в облако, и ротацию, отложенную до продакшена. Ее стоит держать в голове всем, кто повторяет этот маршрут: инфраструктура готова раньше, чем дисциплина работы с ней.
Вывод, который автор сделал сам, звучит спокойнее, чем ожидаешь после такого списка. Агент забывает погасить фоновые процессы, пишет лишнее или не пишет нужного, оставляет мертвый код – ровно то, что делают живые люди в команде. Джуны ошибались так же, сеньоры оверинженирили, споры про количество тестов были всегда. Разница только в скорости. И тут же честная оговорка скептика: это не продакшен-код, за который платят зарплату. А какая часть ваших претензий к агентам – это претензии к процессу, который вы бы предъявили и человеку?
«Это проблемы слабых постановок. Не прописаны детали изначально в сценариях» – Станислав
«У меня такая же работа, только вместо медленного человека у меня быстрая машина» – Станислав
Спор, который тянулся всю неделю и так и не сошелся. Азат запрещает агенту писать markdown-файлы и комментарии хуком на Write – по регексу, без сложной логики. Мотив прагматичный: проза от модели противоречива, не обновляется вслед за кодом и съедает контекст. В generic-библиотеке агент опишет кейсы конкретных потребителей, в тесте напишет, что тест зафейлится, хотя тест должен просто краснеть и зеленеть.
Станислав держит противоположную позицию и показывает файлы, где в комментарии зашита ссылка на требование: агент, открывая такой файл, сразу видит происхождение зависимостей. Это та же трассировка из первой темы, только записанная в коде, а не в отдельном реестре. Возражение на возражение: если комментарии плохие, дайте в инструкции несколько примеров хороших. Ответ Азата закрывает круг – не работает, потому что качество комментария невозможно проверить автоматически.
Андрей развел это на две честные стратегии. Первая – комментировать мало и добирать контекст общением в команде. Вторая – комментировать ритуально. Проблема второй в том, что ритуал обычно не сопровождается разговором, и текст быстро превращается в мусор. Агент, работающий круглосуточно, просто масштабирует ритуал до промышленных объемов.
Практическая развилка здесь не про вкус, а про верифицируемость. Правило, выполнение которого нельзя проверить машиной, агент выполнит недетерминированно – а значит рано или поздно не выполнит. Какие из ваших правил в claude.md сегодня подкреплены хоть каким-нибудь гейтом?
«Я не доверяю прозе вообще, потому что это чистый слоп» – Азат
«Комменты считаю важной частью документации, потому что там есть контекст существования этих настроек» – Станислав
К четвергу разговор о моделях перестал быть перечислением бенчмарков и стал разговором о ролях. Наблюдение Азата: одна модель лучше в итеративной работе, другая – в ваншоте. И следом менее очевидное продолжение: модель, которая требует меньше контроля, забирает у вас контроль. Хорошо это или плохо – зависит от того, что вы делаете.
Станислав привел встречный замер на исследовательской задаче: экономная модель потратила в семь раз меньше токенов и принесла ноль ценного, дорогая потратила больше и дала результат. То есть дешевизна меряется не ценой за токен, а ценой за полезный ответ. Отдельно прозвучала жалоба на среднюю по силе модель, которая стоит как топовая, и симпатия к дешевым моделям для несложных задач.
Практический сюжет недели – возможность подключить сторонние модели прямо в привычный харнесс. Ценность не в системных промптах вендора, а в единой экосистеме: не жонглировать двумя форматами инструкций, хуками, скиллами и правами. Контраргумент тоже прозвучал – альтернативные харнессы читают те же инструкции и скиллы, а вот хуки и песочницу придется дублировать.
И общий фон: доверия к вендорским бенчмаркам в чате нет ни на грош, ждут независимых замеров. Хорошая привычка на неделю, когда очередная модель объявляет себя лучшей. По какому измерению вы сравниваете модели – и совпадает ли оно с тем, за что вы платите?
«Сол лучше в итеративной работе, опус в ваншот» – Азат
«Опус требует меньше контроля, как результат ты теряешь контроль» – Азат
Разговор про казахстанский рынок облаков вышел из бытовой жалобы: железо старое, нового почти нет, вендоры не дают гарантий. Дальше Уалихан разложил, почему крупный локальный игрок выбирает не самое удобное облако, а самое давнее. Решает доверие: местный бизнес, отсутствие санкционных рисков и сомнительных связей. Малый и средний бизнес про это думает меньше – ему нужны удобство разработчика, широкий выбор сервисов и цена.
Из этого следует довольно жесткая развилка для нового игрока. Либо нишевый продукт под конкретных клиентов, либо открытый код. Второе выбрано сознательно: открытость дает сопоставимый кредит доверия там, где его нельзя купить возрастом компании. Банковские облака под этот аргумент не подпадают – они либо еще не публичные, либо слишком молодые, чтобы надстраивать над собой платформенные сервисы.
Фон для всего этого невеселый: инфраструктуры под ИИ в стране практически нет, GPU сдают в аренду по ценам сбитого боинга, а инференс-провайдеров не видно. Прозвучал и контраргумент из зала – продавать можно и эскимосам, вопрос только в том, что именно. Дискуссия местами скатывалась в личные выпады, но содержательная часть от этого не пострадала.
Полезная рамка отсюда шире облаков. Когда вы выходите на рынок, где ваш продукт объективно удобнее, но клиенты выбирают старожила, вы конкурируете не функциями, а репутацией. И прозрачность – один из немногих способов ее ускорить. Чем в вашем продукте закрывается вопрос доверия, если истории у вас пока нет?
«Вся проблема облаков строится от доверия» – Уалихан
«OpenSource может дать доверие сопоставимое, поэтому я вижу именно это направление как наиболее рациональный выход» – Уалихан
Понедельник неожиданно ушел в разговор о том, кто в чате пишет, а кто молчит. Андрей поставил вопрос прямо: специалистов-женщин на рынке достаточно, а в чате их почти не слышно – значит, дело в нас. И привел личный случай: пригласил коллегу в сообщество, где ему все казалось нормальным, она быстро ушла со словами «они токсики», и только тогда он увидел, почему.
Айгерим ответила из другого опыта. Она ушла из нескольких крупных чатов – где-то стало скучно, где-то слишком токсично, где-то ей выдали мнение за факт и позволили себе оскорбления. Ее позиция: дело не в поле, токсичными бывают все, и женщины нередко поддерживают своих абьюзеров. Кристина добавила недостающую деталь – в таких ситуациях чаще всего остается наблюдать и не вкладываться.
Ниже по треду обсуждали второй немой вопрос – казахский язык в чате. Здесь тоже нашлась развилка: без реальной практики язык не выучить и непонятно зачем, но есть города и клубы, где встречи ведут на казахском, и это работает. Оба сюжета про одно и то же: состав сообщества – это не данность, а следствие того, какие ценности оно транслирует явно.
Отдельно стоит отметить, что в этот же день чат сорвался в перепалку с личными выпадами – ровно то, что отталкивает новых людей быстрее любой модерации. Заявлять ценности легко, удерживать в моменте сложно. Что в вашем сообществе или команде сигнализирует новичку, что здесь безопасно говорить?
«Если девушки не пишут, значит мы не дорабатываем – в целом хватает девушек специалистов на рынке» – Андрей
«Дело не в поле, ни в паркетном, ни в мужском, ни в женском. Мы все люди и токсичными можем быть все» – Айгерим
На неделе в чате появился второй в Казахстане обладатель статуса Microsoft MVP и единственный по dotnet – всего таких в мире около 1255 человек. Повод для поздравлений превратился в разбор того, как туда попадают, и разбор получился отрезвляюще практичным.
Путей несколько, и ни один не про код: развитие локального сообщества вокруг технологии, статьи для местного рынка, организация митапов, хардкорные технические материалы. Речь идет про абстрактный вклад, и статьи для джунов тут могут весить не меньше, чем для сеньоров. Из бонусов – бесплатные лицензии и небольшой кредит на облако, порядка 150 долларов в месяц.
Самая полезная деталь – про вход. Нужна рекомендация от кого-то из уже существующих MVP, и способ ее получить банален: писать действующим обладателям статуса, в том числе незнакомым. Один из участников рассказал, что подавался именно так.
Ценность истории не в статусе, а в механике. Признание в индустрии выдается за видимую активность, а видимость почти всегда растет из сообщества – чата, митапа, статьи. Это не путь технаря в чистом виде, но если вам нравится помогать людям, он неплохо конвертируется в личный бренд. Что из того, что вы уже делаете для коллег, никем снаружи не видно?
«Чтобы начать, надо следовать закону кумовства – чтобы кто-то порекомендовал из уже существующих людей» – Андрей
«Это не совсем путь технаря, но если вы любите помогать людям, думаю это хороший способ развивать личный бренд» – Андрей
Две темы недели про язык сошлись в одну. Первая началась с замечания к статье: слишком много калек с английского. Автор согласился, но диагноз поставил не модели, а домену – русскоязычных материалов про агентную разработку мало, поэтому модель думает в этой области на английском и калькирует. Рабочий прием из чата: отдельным проходом попросить переписать текст естественным русским и явно проверить на кальки.
Вторая – полушутливое наблюдение, что длинное тире стало маркером сгенерированного текста. Кто-то предположил, что лет через тридцать оно уйдет из грамматики: люди ленятся редактировать вывод модели, а следующее поколение моделей учится на этих же текстах. Возражение не менее убедительное – на телефонах длинному тире научили задолго до всякого ИИ, просто потому что удобно.
И третий слой, самый неприятный. В чат принесли историю о том, как три сайта нагенерировали 215 тысяч страниц вида «лучший софт для», и поисковый ИИ их исправно цитирует. Рядом – личный эксперимент: модель, выбирая между своим сниппетом из другого чата и отредактированным человеком, стабильно выбирает свой. Возражение прозвучало разумное: веб-поиск работает обычными алгоритмами, и если сгенерированная страница поднялась в выдаче, она, возможно, действительно решала задачу.
Собранные вместе, эти наблюдения дают неуютную петлю: модель пишет текст, текст попадает в индекс, модель предпочитает его человеческому и учится на нем дальше. Заодно всплыл честный вопрос без ответа – влияет ли ресерч агентов на поисковую статистику, по которой мы потом принимаем решения. Как вы отличаете источник, написанный человеком, от источника, написанного для модели?
«Все модельки начинают в этом домене думать на английском и калькировать на русский» – Данияр
«Люди потом продолжают учиться на своих же текстах с длинными тире» – Кристина
Хотите продолжить обсуждение?
Обсудить в Telegram