Спор начался с практики. LSTR описал реальную задачу: миграция набора легаси-приложений, которые вендор выводит из эксплуатации, при этом легаси писали 10 лет и в нём много неочевидного. Чтобы исследовать его и замапить на новые подходы, без документации и матриц соответствия требований не обойтись. Азат занял противоположный полюс: он удалил всю документацию из своих проектов, потому что она мешает, а не помогает – «коду верю, документации нет».
Главный нюанс всплыл вокруг LLM. Азат заметил, что документация часто противоречит коду, и тогда модель ловит когнитивный диссонанс. Хуже того – есть ловушка ленивого агента: если в доке описана целевая архитектура, а в коде пока костыль, модель выберет быстрый путь и закостылит так, чтобы это выглядело как новый подход. LSTR с этим частично согласился: модель туповата независимо от размера, поэтому её нужно ограничивать – детально расписать рефакторинг и покрыть тестами, тогда она сделает то, что описано, а не то, что проще.
Кристаллизующая мысль прозвучала так: абсолютно точная пошаговая документация без двусмысленности уже существует – она называется код. LSTR назвал это краеугольным камнем дискуссии, но возразил: код завязан на платформу и содержит костыли реализации, а документация чётче отражает интент. Отсюда вывод, на котором сошлись оба: код удобно делегировать модели, а принятие решений остаётся за человеком. И единого ответа нет – для разных проектов и зрелости команды подходят разные подходы, инструмент под задачу, а не наоборот.
Если код – это и есть самая точная документация, то что мы на самом деле пытаемся зафиксировать в отдельных доках – и не проще ли это выразить тестами и диаграммами?
«Как называется абсолютно точная пошаговая документация, не позволяющая двусмысленности? – код, она называется код» – Azat Jalilov
«Код удобно делегировать ЛЛМ, а принятие решения остаётся на человеке» – LSTR Unit
Нурлан задал острый вопрос: смотрите ли вы на рейтинг работодателя, и если кандидат пришёл из компании в самом низу рейтинга – это сразу нет? Аргумент в пользу фильтра звучал так: чему научишься там, где всё сделано через одно место (пароль зашит в код – значит, где-то такое видели и считают нормой)? Андрей ответил резко: смысла в этом ноль. Михаил добавил, что человек как раз молодец, что решил идти дальше, а страх «солёных огурцов» – так себе основание.
Максим перевернул вопрос: а как ты отнесёшься к тому, что работодатель посмотрит на твою прошлую компанию, увидит её внизу рейтинга и поставит «нет»? Нурлан честно признал, что, подавайся он на свою же позицию, скорее всего не прошёл бы. Это и есть ответ: отказ из-за прошлого работодателя – форма дискриминации, а не оценка человека.
Азат довёл мысль до предела: вместо суррогатов лучше построить процесс отбора, который измеряет то, что реально нужно в работе, – а рейтинг компании имеет нулевую корреляцию, «можно монетку подбрасывать». Отдельно разгорелся спор о рекомендациях: Нурлан доверяет звонку бывшим коллегам, Азат скептичен – в нашей культуре дать плохую рекомендацию зашквар («ну ты напиши сам, я подпишу»), и говорит она больше о том, как хорошо вы общались, чем о профессионализме. Михаил предложил рабочую середину: спросить на собеседовании, с какими практиками в прошлой компании человек был не согласен и что он с этим делал.
Если бренд работодателя не предсказывает качество, какой дешёвый сигнал в резюме вообще стоит чего-то – и не честнее ли просто потратить время на каждого кандидата?
«Важно не то, где человек работал, а как работал» – Андрей Звёздочка
«Можно монетку подбрасывать – эффективность такая же будет» – Azat JalilovЧитать в чате →
Василий предложил мысленный эксперимент: какую команду вы собрали бы вместо классической (pm, lead, backend, frontend, mobile, qa, аналитики, devops) с учётом новых реалий? Ответы посыпались смелые: «1 senior agents developer», «me, claude, codex, glm», «1 product builder и 3 product engineer». Никита сформулировал общий вектор: команды на две пиццы больше не нужны, когда большую часть пиццы съедают агенты, а ценен человек, закрывающий несколько скоупов и понимающий продукт.
Но Василий тут же подсветил, что энтузиасты пропускают. Первое – бас-фактор: один-два человека на весь продукт это риск, а не оптимизация. Второе и главное – доменные знания и вторая специализация учатся долго и дорого. Фронтендер, залезший в мобилку, не станет сразу продуктивным; пока набьёт шишки, пройдёт очень много времени, и каждый раз, когда роль упирается в незнакомую область, процесс стопорится.
Никита парировал it depends: с хорошими quality gates (включая ручную проверку) и постоянно работающими агентами-мониторами даже сложные случаи закрываются – лишь бы подписки хватило. На что Василий задал неудобный вопрос: а кто будет делать ту самую ручную проверку, если оба разработчика в мобилке не разбираются? Получился честный срез: дешёвый кодинг не отменяет стоимости переобучения людей и проверки результата – она просто переехала в другое место.
Если узкое место теперь не написание кода, а доменная экспертиза и проверка – не выгоднее ли инвестировать в обучение людей домену, чем в количество агентов?
«Никому уже не нужны команды на две пиццы, когда большую часть времени эту пиццу съедают агенты» – Nikita Bayev
«Доменные знания – очень долго и тяжело учить» – VassiliyЧитать в чате →
Тезис о том, что AI удешевил разработку, LSTR назвал полуправдой: процесс написания кода стал дешевле, но код-ревью и разгребание прод-инцидентов как были дорогими, так и остались – и это не делегировать модели. Василий возразил: инциденты тоже дешевеют, ведь за те же две недели теперь можно написать не только фичу, но и тулинг для обслуживания, дашборды и алерты.
LSTR вернул разговор к экономике спроса: теперь бизнес хочет две фичи за две недели, и количество прод-инцидентов удваивается. Дешёвая разработка не успокаивает, а повышает аппетит заказчика. Отсюда вывод Василия – самое время научиться говорить нет; а говорить нет проще, когда знаешь, что не пропадёшь, поэтому стоит ходить на собеседования и иметь подушку.
Глубже всех ушёл аргумент про ёмкость продукта: в любой продукт можно запихнуть лишь ограниченное число фич за период времени, и этот предел был ниже скорости разработки ещё до всякого AI. То есть удешевление кода не конвертируется линейно в больше поставленной ценности – узкое место просто переехало: в ревью, в инциденты, в способность бизнеса переварить фичи и в умение лида сказать нет.
Если код стал дешёвым, а ревью, инциденты и ёмкость продукта – нет, не превращается ли «успеваем больше» в «ломаем чаще»?
«Теперь бизнес хочет две фичи за две недели, и количество прод-инцидентов удваивается» – LSTR Unit
«Самое время научиться говорить нет» – VassiliyЧитать в чате →
Поводом стал пост с Reddit: человек унаследовал репозиторий от вайб-инженера и заменил трёхмесячный кодслоп новеньким кодслопом. Азат отреагировал неожиданно: 10 тысяч строк слопа, делающего то же самое, вполне могут быть качественным слопом – он сам давно не ревьюит код построчно, а смотрит на объём, чтобы тот был адекватен задаче.
Дальше Азат описал свой флоу. Один день он параллельно запускает несколько агентов, чтобы заимплементить много фич; они наплодят кучу говнокода, но эти фичи и есть, по сути, спека. Потом две недели он муторно рефакторит это всё – тоже агентом, прося объяснить, что тот наворотил, и сразу видно, где воняет. Логика в том, что слоп точно копирует код людей, просто ускоренный в сто раз: код становится легаси мгновенно.
Никита подвёл черту, которая объясняет, почему у одних это работает, а у других нет: одна и та же модель в руках разных людей даёт и x100, и -x100 инженера. То есть дело не в модели, а в архитектуре процесса – как выстроить так, чтобы поток слопа сходился к рабочей системе, а не к новому легаси. Максим мрачно пошутил, что со временем толерантность сместится, и следующий разработчик сначала выпилит три миллиона строк, а потом напишет пост на Reddit.
Если фичи-как-спека дают результат только при дисциплинированном рефакторинге, не честнее ли считать «день кодинга» началом работы, а не её концом?
«Одна и та же модель в руках разных людей может сделать x100 инженера и -x100 инженера» – Nikita Bayev
«Они наплодят кучу говнокода, но эти фичи и есть, по сути, спека. Потом две недели сижу и муторно рефакторю» – Azat JalilovЧитать в чате →
Разговор о созвонах (Zoom против Google Meet против Teams) вырулил на неудобный вопрос: откуда столько мемов про неработающие Teams и Outlook, если внутри сидят тысячи сильных инженеров и почти бесконечный бюджет? Станислав, работающий в этой компании, дал инсайдерский ответ. Во-первых, догфудинг: сотрудники сидят на ранних alpha- и beta-сборках, которые пекутся ночью, поэтому часть багов – это цена раннего доступа, а не вечная поломка.
Во-вторых – приоритеты, и тут прозвучала ключевая мысль: не забывай, кто пользователи. Не ты, а CTO или CIO. Компании уровня Volvo и GM звонят напрямую Сатье во время инцидентов; баг, который не мешает тому, кто на прямой линии с CEO, – не такой уж важный баг. Заодно разобрали изолированные ЦОДы для госструктур как нормальную индустриальную практику, а не аномалию.
Азат предложил другое объяснение, и в нём вторая половина правды: дело не в приоритете, а в архитектуре – нельзя пофиксить в одном месте, не сломав всё приложение. И это, как утверждается, написали лучшие в индустрии, на которых все равняются. Для самого явления даже завели словарный термин – enshittification. Получилась честная картина: в теории гигант должен поставлять самый надёжный софт, на практике связка «кто реально платит» плюс накопленная архитектурная связность объясняют музей багов.
Если приоритеты диктует тот, кто платит больше всех, а архитектура десятилетиями копит связность – чинится ли это в принципе изнутри одной компании?
«Просто не забывай, кто пользователи. Не ты, а CTO или CIO» – Stanislav Belyaev
«Компания с тысячами хороших программистов и почти бесконечным бюджетом годами не может пофиксить простейшие баги – что-то явно не так» – Azat Jalilov
Практическая боль недели: субагенты вычитывают токены как не в себя. Запускаешь ресёрч для новой фичи – и за полчаса лимит кончается, работа встала. Станислав подтвердил масштаб: одним запросом слил несколько миллионов токенов, а результат «не WOW».
Причину разобрали тут же. Если ставить Opus на каждого субагента, каждый перечитывает одну и ту же информацию вместо общего кэша. Денис спросил: а зачем на всех субагентов мощную модель, нельзя ли делать их форком от общей сессии? Дмитрий предложил конкретику: сначала составить план исследования в файле, чтобы каждый субагент взял независимую часть и копал только свой вопрос без пересечений с остальными.
Вывод вышел нетривиальным: субагенты – это не бесплатная параллельность. Без плана, который разбивает работу на непересекающиеся части, и без общего контекста вы платите за один и тот же контекст несколько раз. При этом нашёлся и контрвзгляд: Василию наоборот нравится – итераций по итогу меньше. То есть это размен – сожжённые токены против числа итераций.
Если каждый субагент стоит как отдельная сессия, где проходит граница между «распараллелил» и «сжёг лимит впустую»?
«Я несколько млн токенов слил одним запросом. Результат не WOW» – Stanislav Belyaev
«Сначала сделай план исследования в файле, чтобы каждый субагент взял независимую часть без пересечения с остальными» – Dmitriy MelnikЧитать в чате →
Хотите продолжить обсуждение?
Обсудить в Telegram