Саша Раковский

Оптимистичный сценарий

Да. Я тоже сразу же после тестов разочаровался.

Про клавиатуру, микрофон и нейроинтерфейсы

Я за последние месяцы уже несколько раз натыкался на посты, где за голосовой ввод активно топили. В целом, логика понятна: голос — 120–150 слов в минуту, печать — 50–60, вроде бы победитель очевиден.

Впервые в нашей профессии появилась возможность радикально изменить способ ввода: вместо печати можно диктовать задания агентам сырым текстом, чтобы уже из него ИИ генерировал код.

Я загорелся идеей и попробовал, но несколько вещей меня довольно быстро сильно смутили.

Во-первых, качество транскрипции, что на английском, что на русском, жутко раздражало. Ты говоришь одно, а транскрибатор агенту вообще про другое. На выходе, как в том анекдоте про поручика Ржевского - простите, мадам, я не расслышал вопроса, но да!

Во-вторых, печатал я с детства быстро, вслепую, а говорю при этом, как умственно отсталый — долго соображаю и подбираю слова. Значит, думаю, в режиме композиции, когда я формулирую мысль на ходу, разницы не должно быть. Во эту гипотезу я и решил проверить.

Эксперимент

Экспромт на произвольную тему про программирование. Три минуты диктовки на английском на одну тему, три минуты на русском на другую, минута печати на русском на третью, минута свайпа на телефоне на русском на четвёртую.

Результаты по сырым словам;
- диктовка (английский и русский) по ~120 слов в минуту (~90, если убрать филлеры);
- печать и свайп по ~50 слов в минуту.

Не сработало: не так уж круто я печатаю, не так уж медленно разговариваю. Хотя и английский устный, и свайп на телефоне приятно удивили.

От слов к смыслу

Смотрю на сами тексты. Диктовка рыхлая: слов полно, а смысла мало. Печать плотная: каждое слово в цель. Отдаю тексты двум агентам, чтобы те насчитали смысловые единицы. Результат - 1,7-2,0 тезиса в минуту на каждый текст, независимо от канала ввода.

Все встало на свои места. Независимо от канала ввода больше 2 тезисов в минуту даже на знакомую тему я отдать не смог. Судя по всему, думаю я медленнее, чем печатаю или, тем более, говорю. Впрочем, при N=1 - это не исследование никакое, это так развлечение. Но что говорит наука? А то и говорит.

Исследование Caltech (Zheng & Meister, 2024): человеческое мышление работает со скоростью около 10 бит в секунду. Причём этот результат согласуется с данными, которые накапливались ещё с начала XX века.

Следствие для агентов

Если вам особо не надо думать, вы уже подумали, то голосом будет быстрее. Это, как правило, небольшие промпты. Если вы думаете со скоростью света, скорее всего, голосом будет быстрее, но научных данных, подтверждающих разницу в скорости мышления напрямую, я не нашёл. Только скорость решения задач, но это не совсем то. Если вы печатаете не очень быстро, то голосом тоже будет быстрее. Если вы на чилле или, наоборот, на бегу или за рулём, то голос опять же выигрывает.

Но если речь заходит про режим, где вы сидите за компом, у вас нет проблем с печатью, думаете по ходу написания промпта, а вокруг люди, которым вы не хотите докучать, то голос очевидно проиграет. И за счёт ошибок транскрипции, и за счёт того, что в тексте будет куча воды и междометий. Да и просто, потому что вы не хотите мешать другим людям.

Про прекрасное далёко

И ещё заход. Сейчас активно разрабатываются ЭЭГ-нейроинтерфейсы, недавно даже про это была большая новость. В целом, весьма может быть, что большого эффекта от этого и не стоит ожидать: быстрее, чем вы думаете, ввод все равно невозможен. А думаете вы, скорее всего, медленнее, чем даже печатаете.

Короче, новая рубрика "Клод сказал".

Вопрос:

Есть хоть какие-то исследования, которые подтверждают, что встроенная в код документация - это топ для агентской разработки?

Ответ:

Коротко: прямого подтверждения «это топ» нет — есть смешанная картина, причём с важными нюансами. Что реально есть в литературе:

За. Исследование MITRE: рост числа комментариев улучшает понимание кода LLM (проверяли через quiz-точность), причём мелкие неточности в комментариях почти не вредят, а грубые — существенно деградируют понимание. Эмпирическое исследование по автоматическому багфиксу прямо рекомендует не удалять комментарии из данных и тщательно документировать код, чтобы лучше использовать LLM для исправления багов. [arxiv](https://arxiv.org/pdf/2601.23059) По тестам: Javadoc-комментарии сами по себе давали сопоставимую или лучшую точность генерации тестовых оракулов, чем реализация метода, а подход только на Javadoc находил на 19–94% больше реальных багов в Defects4J. [arxiv](https://arxiv.org/pdf/2412.09360)

Против. Обзор контрпримеров: в одном исследовании включение комментариев не дало статистически значимого эффекта; в бенчмарке RepoQA удаление комментариев у большинства моделей *улучшало* результаты; ещё одна работа показала, что исключение комментариев повышало точность суммаризации кода. [arxiv](https://arxiv.org/pdf/2512.16790)

Про агентские контекст-файлы (AGENTS.md/CLAUDE.md) — самое релевантное для тебя. ETH Zurich (AGENTbench, февраль 2026): LLM-сгенерированные контекст-файлы улучшали результат лишь на 2,7% и только когда из репозитория удаляли остальную документацию — они в основном пересказывают README; а доминирующий паттерн «всеобъемлющий, сгенерированный LLM, тяжёлый по архитектуре» добавляет стоимость и снижает корректность. Помогали именно написанные разработчиком файлы с узко скоуплеными требованиями. [Notchrisgroves](https://notchrisgroves.com/when-agents-md-backfires/) Другая работа: наличие корневого AGENTS.md ассоциировано с меньшим расходом токенов и более быстрым завершением задач, но корректность и соответствие интенту там не измеряли.

Честный вывод: подтверждается более слабый тезис — *точная* документация рядом с кодом помогает, *неточная* активно вредит (хуже, чем её отсутствие), а избыточная дублирующая — жрёт контекст без пользы. Это скорее аргумент за твою ATDD-логику: исполняемая спецификация (тесты) не устаревает, в отличие от комментариев.

О вреде электронных рабов

Наблюдаю у коллег один и тот же императивный стиль в работе с агентами: сделай то, поправь это. Прям электронный раб какой-то.

У меня прижилось другое. Не команда, а описание: вот что произошло, вот какую проблему я вижу, вот чего хочу и вот как мне кажется надо сделать. А в конце вопрос. Что думаешь? Какие варианты? Может, я что-то не так понял?

Это очень мощный инструмент защиты от твоей же глупости. И от глупости агента. От вашей совместной глупости. Ты точно видишь, что агент и твою мотивацию понял, и твоё решение, и предложил своё, и ещё подсветил, если ты совсем какую-то ерунду мелешь.

Сегодняшний случай. Починяем с коллегой примус, агент в процессе что-то не то удалил. Коллега начинает печатать «сделай обратно» — торможу его, пишем иначе: «Видим, что ты удалил вот это. Нам кажется, оно ещё понадобится и удалять его не стоило. Наверное, надо вернуть — или у тебя было другое понимание?»

Агент разобрал свои действия и первым делом поправил нас: мы не совсем верно поняли, что он вообще сделал. Однако часть удалённого действительно оказалась нужной, и решение он предложил своё — посмотрели, годное, приняли.

Для чего нам агенты? Чтобы не нырять в проблему на всю глубину самим. В итоге контекст мы знаем зачастую хуже агента, которому все делегируем. Поэтому подстелить такую соломку под своё невежество никогда не вредно.

Это, вообще говоря, дефолтная рекомендация от всех гуру агентской разработки. Так что если твой промпт заканчивается точкой, а не вопросом — скорее всего, ты только что выкинул половину пользы от агента.

Есть такая широко известная в узких кругах бабушка, Элизабет Хендриксон. Это известный специалист по тестированию, которая стала знаменита благодаря своей статье 2000 года better testing, worse quality.

Пересказывая суть статьи в 2 словах: в одной софтверной компании произошла очень странная ситуация. Чем больше тестеров они нанимали, тем хуже качество софта было на выходе. Оказалось, что разработчики перестали проверять свою работу сами и стали отдавать код тестировщикам без тестирования.

Казалось бы, ну и что? Это не их работа тестировать, их работа код писать. Хорошо, но почему тогда это ломается?

Вообще говоря, ответ на этот вопрос давно известен: это типичная проблема shift-right. Кто-то помнит, как я уже рассказывал, что в автомобилестроении есть такая же беда. Заводы, где дефекты сборки не устраняют на месте, а оставляют на контроль качества, стабильно имеют радикально худшее качество на выходе, чем те, у которых косяки исправляют сразу. Просто потому что контроль качества оказывается перегружен и не способен обнаружить все пасхалки от сборщиков.

Вот и в статье проблему починили классическим lean-подходом из того самого автомобилестроения: сделали shift-left и build quality in. Короче, заставили разрабов тестить самостоятельно.

В целом, вот уже на этом месте я бы мог остановиться или что-нибудь актуальное высосать из пальца про вайб-код и product engineering, но я не для этого этот пост начал писать.

Про баг, который и правда фича

Так вот, история. Эта самая Элизабет Хендриксон однажды попала в команду к экстремальщикам и мрачно офигела с того, какой это другой мир. Конечно, любой экстремальщик прекрасно понимает, о чем я. После знакомства с экстремальным программированием картинка переворачивается с ног на голову у всех: как прежде ты уже на разработку смотреть не можешь.

И вот один из моментов, который она описала, мне лично очень откликнулся. Когда она обнаруживала недоработку и заводила баг на разраба, то ей нередко в ответ прилетал негатив, который она поначалу не могла понять:

- Зачем ты выдумываешь новый функционал?!
- Что значит, новый функционал? Это же недоработка, баг.
- Нет, Элизабет, - говорили ей, - баг - это когда что-то работает не так, как планировалось. А вот так, как ты хочешь, оно никогда и не планировалось. Ты просто называешь новый функционал багами.

Это я к чему вспомнил. Да вот сейчас на работе вот так: пользакам выкатили мвп, а они свои хотелки нам накидывают, оформляя их как баги. "Ну а как мы без этого должны работать?"

А ты им, как попугай, одно и то же: все сделаем, все будет, но не сразу. Давайте то, без чего совсем беда будет.

Начальство за это грызут: чего это у вас столько дефектов? Хорошо, хоть нам такие вопросы никто не задаёт. Но был в моем опыте и момент, когда в похожей ситуации начали задавать: вы ж говорили, что у вас автотесты и тдд, а тестировщик у вас баг за багом находит.

И попробуй объяснить, что тестировщик занимается неосознанным вредительством, раздувая без того передутый скоуп работ на ровном месте.

Сегодняшний пост Фарли из Continuous Delivery:

Если ваш AI-ассистент для написания кода ощущается как отвлекающий автокомплит, который копирует плохие паттерны из вашего легаси-кода, — решение в том, чтобы практиковать кое-что другое…
«Harness Engineering» (проектирование обвязки / оснастки).
Вместо того чтобы позволять AI действовать бесконтрольно или скачивать универсальные промпты, командам нужно строить собственную агентную обвязку, используя «гайды» (feed-forward правила вроде markdown-файлов) и «сенсоры» (петли обратной связи вроде детерминированных скриптов), чтобы жёстко удерживать AI в рамках своих стандартов качества.
Итеративно выстраивая такую обвязку и владея ею, вы создаёте «эффект маховика» (flywheel effect), при котором ваши AI-агенты помогают вашему легаси-коду активно улучшаться со временем, а не деградировать.

Не умеете в хорошие тесты - у меня есть гайд в 3 частях, есть целый фреймворк со скиллами, который можно просто брать и использовать.

И с этого момента можете уже спокойно потихоньку рефачить и экспериментировать с неблокирующими вариантами ревью.

Можно без экстремального программирования?

Можно. Нарезать команды на самостоятельных продукт инженеров. Код-ревью уйдёт. Все остальные проблемы - нет, но станут уже проблемами самого разработчика.

PS: вообще, залетайте в чат канала. Вижу, что есть, что обсудить, а чат что-то пустует. Не порядок)

ИИ против процессов

Тут в отпуске в одной тёплой стране встретил толпу русских айтишников, гуляющих свой корпоратив, мирно обсуждающих римскую империю. Я их спросил: "Пацаны, вайбкодите?"

А один из них ко мне подскочил и резко пояснил меня криком: "Без удовольствия!"

Ладно, мемы в сторону, олды все равно не помнят, но вечером в лобби один из них показывает на коллегу и говорит: "вот этот, блин, любит повайбкодить. Выкатит пр на сто файлов, и как это ревьюить?"

И это, конечно, вообще не надуманная проблема. Пулл-реквесты и до агентов не были идеальным решением, а теперь разработчики по всему миру попали в ситуацию, где они, прямо говоря, нормально ревьюить эти тонны нейрослопа не способны.

В результате начинается какой-то кружок творческой самостоятельности. Понимая, что адекватное ревью всего этого нейрослопа - это утопия, народ городит ИИ-ревью, комбинируя его с поверхностным ревью глазами. Решает ли это проблему? Скорее, нет.

Что ещё сломалось?

Поверх наслаивается и другая беда: для большинства команд мира и, особенно, РФ автоматический регресс - это какая-то фантастика недостижимая. Как правило, разработчик в процессе реализации, скорее всего, вносит какую-то деградацию и хорошо, если все корнер-кейсы своей фичи сделает без ошибок, что уж говорить про регресс существующего функционала.

Это означает, что тот, кто рожает наибольшее количество нейрослопа, тот и больше всех ломает существующий функционал, вызывая негатив всей команды как в свой адрес, так и в адрес агентской разработки, в целом.

Не очень способствует такая обстановка и рефакторингу с чистотой кода. Работает - не трогай. В итоге, неудивительно, что все не очень любят чувака, который пр за пром выкатывает нейрослоп, который он вряд ли сам хорошо смотрел, с десятками изменённых файлов, полных костылей и новых багов. Я и до ИИ слышал, как подобных охотников за тасками в джире называли говнофиксерами. Теперь же, пока ии фигачит, все вокруг отсматривают огромные пры таких перформеров, фиксят их баги и утопают в тоннах нейрослопа.

Что ещё в этой системе перестаёт работать? Ручное тестирование. Как только ии берётся на вооружение, таски начинают закрываться, как из пулемёта. Те, что просачиваются сквозь бутылочное горлышко ревью, попадают в бутылочное горлышко тестирования. Что усугубляет беду? Больше правок - больше багов. Больше нейрослопа - ещё больше багов. К чему это все приводит? К недотестиованности и срывам релизного расписания.

Какие ещё проблемы? Вообще типовая беда фича-веток на большом объёме изменений - это, конечно, мерж-конфликты. И вот тут есть нюанс: агенты очень легко мержат конфликты, снимая эту головную боль, но проблема тут в том, что они при этом легко могут внести деградацию. И без тестов вы это не отловите.

К чему это я? Типовые командные процессы даже без ИИ работали с большими нареканиями. Сейчас это выглядит так, будто этому приходит конец - оно просто становится несовместимо с ИИ.

Как быть то?

Первые полгода я в этом канале писал практически исключительно про экстремальное программирование, автотесты и тдд, дизайн и архитектуру, про рефакторинг, разработку без фича-веток и пулл-реквестов. Вопреки интуиции, это устойчивые процессы разработки, которые позволяют держать хорошие темпы и качество годами.

Вообще говоря, эти идеи не являются какой-то дикой экзотикой, это, как раз, наоборот самый мейнстрим среди лидеров индустрии, хоть, к сожалению, по разным причинам не ставший мейнстримом во всей индустрии.

Но именно тут лежит ключ к разрешению озвученных проблем: автоматический регресс, рефакторинг и отказ от PR, в принципе.

До ИИ, если вы начали разработку без автоматического регресса, то он у вас уже не появится никогда. Теперь с ИИ все иначе. Волевым решением вы с помощью ИИ собираете все поведение системы, которое задокументировано и не задокументировано. Потом с помощью же ИИ разрабатываете тестовую модель на основе имеющейся + собранного поведения. И с помощью ии пишете тесты. И после больше никогда не пишите код без тестов. Все. Только ревьюить результат на каждом шаге не забывайте.

Ревью недостаточно

Похоже, уже все доехали до мысли, что ИИ-разработка без разработчика — затея так себе. Но, кажется, не все ещё догоняют, насколько это может быть опасно на самом деле. Вот вам пример из реальной жизни.

Представьте, что вы списываете с клиента подписку раз в месяц через какую-нибудь юкассу. Реализация вроде тривиальна: раз в день вы отбираете всех клиентов, у которых прошёл месяц с последнего списания, и списываете.

И вот тут есть типовая ошибка, с которой знаком любой сеньор-помидор. Вы списали деньги и сохраняете списание в базу. Но если что-то по какой-то причине сломалось, то деньги списались, а в базу ничего не сохранилось. На следующем проходе вы снова видите этого клиента, у которого последняя дата списания больше месяца назад — и списываете деньги ещё раз. Неприятная ошибка, да?

Решается это идемпотентностью вызова. В наше время любой сеньор про эту проблему знает, понимает её и умеет разруливать.

Но я лично видел, как опус эту ошибку не заметил и сделал наивное решение без всякой идемпотентности. При том что у поставщика в API этот ключ идемпотентности есть и чётко прописан. Агент просто не придал этому значения.

Стрём? Не то слово.

Плот твист

Куда более стрёмно другое: эта ошибка не была замечена и на человеческом ревью, несмотря на весь опыт и экспертизу. Потому что агентская разработка сильно усложняет вникание: продумать задачу на всю глубину становится тяжелее, когда код написан не тобой. Об этом уже многие говорили, но мне важно зафиксировать сам механизм: опасность не только в ошибках ИИ, но и в том, что человек выпадает из глубокого осмысления задачи.

Плот твист #2

Кстати ошибка нашлась самим же опусом при валидации тестовой модели на стенде: плохо настроенная интеграция сломалась и навела клод на мысль, что тут что-то не так.

Может, всё-таки при хорошем харнессе можно уже и без человека? Раз уж он все равно не ловит такие ошибки.

Плот твист #3

Если вас тоже посетила эта мысль, то вот вам последний поворот сюжета: при попытке фикса этой проблемы тупая ллмка неправильно поняла проблему, написала неправильный тест и начала его зеленить.

Выводы?

Стрёмно! Ошибка вроде простая, но ни модель не углядела сразу, ни человек. Что означает, что ИИ-разработка, в целом, не снижает требования к разработчику, а, наоборот, повышает. Впрочем, не сказать, что это большая новость: метафора спорткара на этом канале уже звучала.

Причём, эта конкретная проблема - это же просто пример. Реально таких опасных мест в разработке куда больше.

Что делать?

Мы знаем, что разработчики при достаточной включённости такое ловят. Этот пример показывает, что и нейросеть подобное может поймать в определённых обстоятельствах. Поэтому в свой процесс надо для каждого этапа включать моменты максимальной вовлечённости разработчика в проблему и создавать условия для агента, в которых он должен ловить такое.

За сим пойду починять фреймворк, наверное.

Какая же жиза, блин 😒

Крутой небольшой пост про то, как Гугл, имея технологическое лидерство и лучшие кадры в ИИ на протяжении многих лет, умудряется который год подряд делать второсортные продукты, отставая от лидеров индустрии радикально.

Почему?

Существующие бизнес-модели приносят корпорациям столько денег, что они могут быть безумно неэффективными.

Сегодня кончилась подписка на клод, и я не провёл факт-чекинг. Стыдно.

Клод говорит: product-engineer - это термин от Atlassian из 2019. В целом, означает именно то, что я описал в посте выше, ну разве что клод разгоняет про "продуктовое мышление". И это справедливо: в таких вакансиях это всегда идёт отдельной строчкой, потому что является центральной частью такого формата мышления, где вы отвечаете не за задачку, а за сам продукт.

Есть ещё более широкая и менее каноничная трактовка в формате, где pe = pm+se, т.е. фулл-фулл стек: там уже будет и исследование конкурентов, и gtm, и продажи, и все остальное. Но это уже скорее не канон, а его расширение.

Так что, будьте в курсе.

Про продакт-инжинегров

На рынке труда относительно массово появляется новая вакансия - Product Engineer. Этакий человек-оркестр, вооружённый агентами: сам пилит бэк, сам пилит фронт, CI/CD, мобильное приложение, тесты. На мой взгляд, это хорошие перемены, отражающие реальные изменения в нашей профессии.

Бизнес видит, что слишком оптимистично думать, будто разработчики больше не нужны, и продуктовые люди сами смогут с помощью ИИ разрабатывать код. Всё-таки без реальных знаний техники писать код прям опасно.

Но зато теперь совершенно реалистично считать, что ранее сильно специализированные разработчики могут отвечать за куда более широкий набор технологий и, по сути, за полный цикл разработки.

Больше вам не нужна толпа народу на продукт со всеми нашими любимыми дейли, ретро, груммингами, код-ревью и вечными спорами, как правильно делать. Один человек отвечает за техничку, второй - за продукт.

Минусы: bus-фактор, более высокие требования к квалификации инженера и, все же, не та же скорость. Product engineer экономит на командном взаимодействии, едет быстрее за счёт ИИ, но вот прям сравниться с командой в скорости без жульничества (скип-ревью, например) будет непросто.

Для хорошего уровня подобной инженерии вам будет уже крайне полезно понимать стандарты индустрии в области sdlc, архитектуры и практик автотестирования. К тому же по первой такие инженеры будут супер смешно ошибаться: бывшие бэки косячить на фронте, бывшие фронты косячить с бэком.

Ну и, наверное, подмастерье для митигации bus-фактора и обучения смены не помешает.

Итого, кажется, индустрия движется к очень небольшим продуктовым парам/тройкам: product-engineer (или пара) + product manager (вероятно, один на несколько таких инженеров/пар).

Кого заменит ИИ?

Постоянно вижу заголовки в духе "ИИ заменит тех" и "ИИ заменит этих".

Думаю, что все текущие сокращения связаны не с эффектом от внедрения ИИ, а с тем, что компании годами хотели порезать жир ковидных времён, и тут появился такой прекрасный повод.

Вот кого "заменил ИИ" на самом деле:

- Бездельников, кого хотели уволить ещё год назад
- Раздутые отделы, которые наняли на хайпе 2021-го
- Менеджеров-пересыльщиков, без которых ничего бы не изменилось
- Разработчиков ненужных продуктов и фичей
- Целые прослойки, которые держались на том, что начальник не хотел конфликта
- Хороших ребят, которые просто попали под раздачу и оказались в неправильном бизнес-юните в неправильный момент

И так далее.

Если посмотреть на индустрию в целом - большие SAAS компании, соцсети и сервисы либо на плато, либо в стагнации. Мега-рост только в AI стартапах, но там нет столько сотрудников.

Так что я бы не переживал, что какие-то профессии исчезнут, ведь ИИ все доделывает только на 80%.

Переживать надо, что ты пилишь продукты, которыми никто не пользуется, и фичи, которые никто не видит.

Вот это реальная зона риска.

Про глупые модели

В моём представлении интеллект модели - это её ключевая характеристика. Чем выше интеллект, тем меньше времени уходит на взаимодействие с моделью и ее корректировку при решении той или иной задачи. Даже самые умные модели сейчас требуют немало времени на ревью и корректировку.

При этом есть несколько надёжных, как швейцарские часы, способов превратить даже самую умную модель в непроходимого идиота.

Контекст

Ну это уже, наверное, всем известно: чем больше контекст, тем сильнее деградация. Для далёких от вайбкода: чем больше чат, тем глупее ответ. При этом, чем меньше модель, тем выше этот эффект. Впрочем у моделей, которые намеренно проектируют и обучают для работы на длинных контекстах, деградация слабее, но она все равно крайне ощутима.

Русский язык

Многим, наверное, известно, что взаимодействие с ллм на русском в 1,5-2 раза дороже, чем на английском в плане токенов. Но мало кто знает, что не-английский язык даёт штраф в 5% точности на большой модели и до 25% (!) на малой. Как это меняется с ростом контекста - загадка, но вряд ли контекст влияет на это положительно.

Говнокод

Нужно ли рефакторить в эпоху вайб-кода? Если код читать и править не вам, то это вполне логичный вопрос. Многие и для себя-то не особо стараются. Однако, насколько говнокод делает модель глупее?

Судя по всему, намного: если изменить все имена в коде на случайные, то модель на том же бенчмарке вместо 88 баллов выдаёт 58. Купили опус за 200 баксов, а пользуетесь гигачатом.

А если имена будут вводить в заблуждение и врать, то результат будет ещё хуже.

Про малые модели

Вообще, малые модели на coding-бенчмарках выдают баллы, близкие к большим. Но это не значит, что они так же хороши в реальности: тут важно понимать, за счёт чего достигаются эти цифры. Малые модели, чтобы решить ту же задачу, думают больше: не по времени, а по токенам. Они компенсируют недостаток знаний и ума усердием. И это значит 2 вещи: больший расход контекста на задачу и, вероятнее всего, худшее качество кода на выходе.

Мой опыт с моделями показывает следующее: если модель изначально воткнула какой-то кривой костыль, то рефакторинг тут уже не поможет - это будет красиво обёрнутый костыль.

Подытоживая

В целом, я регулярно вижу, что народ использует маленькие модели для кодинга. И русский язык в промптинге и проектах. И пренебрежение ревью и, тем более, рефакторингом тоже вижу.

И тут, судя по всему, скупой платит дважды, а ленивый трижды: дешёвая маленькая модель думает-думает, загаживает себе контекст, плодит говнокод, в котором она справляется ещё хуже. И все это ещё усугубляется тем, что все на русском.

Как эту ситуацию добить? Не писать тесты. В первом проходе модель (не имея результатов тестов) решает всего 50% всех задач бенчмарка. К 40-й итерации набирает >80%. То есть без обратной связи модель ошибается гораздо чаще.

Из свежего опыта общения с новой моделью Fable 5 от Антропик😔

Снова про review-bottleneck

Наткнулся на видео, где мужик говорит, что проблема code review bottleneck в ai-разработке решается через отказ от code review. В моей системе координат это совет является безусловно вредным, но раз человек знает, что такой bottleneck есть, то, наверное, ему есть, что предложить.

В общем, смотрю, что мужик предлагает: TDD, agentic review и более тщательное SDD. Ну то есть, как я это понял:
1. Вы с агентом написали тест, который проверяет, что желаемое поведение появилось
2. Вы с агентом составили архитектурное решение, как вы видите реализацию.
3. Агент нагенерил реализацию.
4. Другой агент отревьюил на предмет фигни и поправил.
5. ???
6. PROFIT!

Насколько это лечит проблему?

По-моему, в апреле, у меня появился новый этап в цикле разработки - design preview. Он появился после того, как я понял, что на сложных кейсах, где меняется существующая логика, первая итерация red-usecase, green-usecase сразу гарантированно идёт в помойку, потому что ИИ начинает впихивать костыли, лишь бы позеленить тест. Поэтому я решил, что необходимо все же добавить небольшой этап проектирования перед разработкой.

В итоге, теперь сразу после red acceptance агент, имея документацию, код и текст ошибки падающего теста, предлагает несколько вариантов решения текущего кейса. Наша задача только выбрать подходящий и зафиксировать в ADR.

По идее, это должно было избавить меня сразу от целого класса проблем, где агент намутил совсем невменяемую ерунду, лишь бы позеленить тест. А именно это являлось всегда главной причиной, по которой необходимо было ревьюить код. В каком-то смысле, так оно и оказалось, если бы не несколько но.

1. Review bottleneck никуда в таком подходе, откровенно говоря, не уходит. Просто смещается влево на этап архитектуры. Сокращает ли это man in the loop? Вот хз вообще.
2. Спроектированная заранее архитектура - это набросок. Как она реально ляжет в настоящий код - большой вопрос. Весьма вероятно, что никак. И это много раз случалось у меня, например. Как это влияет? Просто придётся вернуться на этап проектирования и все продумать заново. И, вероятно, код читать придётся.
3. Даже на спроектированной заранее архитектуре даже отрефакторенный код может оказаться кучей вонючей субстанции. И без человеческого ревью это, как оказалось, не выловить.
4. Агенты умеют нарушать инструкции. Если он не сможет реализовать вашу ADR, или тест окажется красным, агент легко может реализовать что-то ещё и сказать, что все готово. И то что он сделает, даже отдалённо не будет напоминать то, что вы от него ожидали. Хотя вот это можно выловить агентским ревью.

Что это значит?

С одной стороны все 4 возражения не очень строгие.
1. По идее, проектирование только архитектуры может быть дешевле, чем ревью. В смысле человеческого времени.
2. Если не попал в решение, и тест все ещё красный, или агент поднимает какой-то консерн, то, во-первых, это все ещё не каждый раз, во-вторых, всегда можно повторить этап проектирования.
3. Если код плох, но работает и архитектурно соответствует желаемому, то, в целом, можно и удовлетвориться.
4. Если агент сделал что-то не то, то на агентском ревью это можно обнаружить и поправить.

С другой стороны, вот у меня вроде точно такой процесс, как озвучивает автор: и tdd, и sdd, и agentic review (хоть пока и без архитектурного контроля независимым агентом), но от ревью я, если честно, отказываться не готов.

Да и не занимает это ревью так уж много. По моим ощущениям, большинство кейсов не требуют больше 15 минут ревью суммарно. Итого, небольшое приложение на 100 кейсов не потребует больше 25 часов ревью, то есть больше 3 рабочих дней. По моему опыту разработка сотни кейсов занимает 2 недели. Ну полнедельки-то из них на ревью уж можно выделить?

Короче, на мой скромный взгляд, сейчас отказываться от человеческого ревью кода РАНО. Думаю, лучше тут не торопиться, ещё успеется.

Плоский прокат, листовая сталь для автомобилей и кораблей. Считалось, что Nucor не сможет это делать. Пока они не стали выпускать листовую сталь. 

В бизнесе и войне побеждает тот, кто может в реакцию и управляемость. Bethlehem была очень крутой компанией с великой историей. Она просто была очень неповоротливой. И умерла. Вопрос выживаемости это не вопрос только денег и ресурсов. Это вообще про другое. Способность или неспособность адаптироваться к переменам и текущим вызовам.