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

Вот эту мысль надо тоже прокомментировать. Для многих тесты, рефакторинг и вот это все - это отдельные практики, имеющие самостоятельную ценность.

Но немногие знают, что именно Agile-movement лежал у истоков их популярности. И именно аджилисты заложили в наши головы ценность этих практик, настолько необходимых для того самого "передумывания". Современная индустрия выросла на работах Agile-первопроходцев: Кента Бека, Мартина Фаулера, Дяди Боба, Дейва Фарли, Эрика Эванса, Алистара Кокберна, Дена Норта и многих-многих других.

Я много раз упоминал, что народ вообще не втыкает, что такое Agile.

Не дайте себя обдурить, Agile - это не про chaos over order. Agile - это про Lean: не тратьте время на софт, который никому не нужен. Это глубоко экспериментальный подход, подразумевающий, что у вас все должно быть заточено под "передумывание": тесты, дизайн и процессы.

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

PS: если вы всерьёз считаете, что Agile = Scrum, то суть поста вам пока недоступна.

AI CI

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

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

Как так?

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

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

Как быть?

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

Чтобы не было конфликтов, в каждый момент времени все сессии должны видеть изменения других сессий в режиме реального времени. Как в Google Docs. В реальности это, конечно, недостижимо, но можно приблизиться к этому, синхронизируя их максимально часто между собой. 

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

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

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

Какие есть альтернативы? 

1. Больше man-in-the-loop, меньше параллельных сессий. Это либо более короткие автономные сессии, либо длинные автономные сессии с параллельной ручной разработкой. По идее, тут выходит меньше производительность труда, но нет недостатков от множества параллельных сессий: конфликтов и сложностей с частой сменой контекста.
2. Меньше рефакторинга. Минусы понимаете сами.
3. Ещё больше машинок в пайпе и ещё больше коммитов в мастер. Это правильный подход, хоть и стоит денег.
4. Можно работать без пайпа, гоняя тесты локально. Но это менее надёжно и увеличивает длину каждой итерации ещё сильнее.
5. Можно отдавать разруливание конфликтов ии и надеяться, что он ничего при этом не упустит. Но это я вообще не рекомендую.

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

Чует моя пятая точка, что это он поторопился называть эксперимент успешным 😔

По крайней мере, мой опыт говорит, что так делать невероятно опасно. Из смягчающих обстоятельств - уже имеющийся референс на другом языке и набор тестов. Из явных признаков, что может быть больно:
- отсутствие ревью (какое ревью вообще на миллионе строк),
- big bang replacement,
- долгая отладка с большим количеством первоначальных ошибок.

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

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

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

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

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

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

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

Интересное про DAU Claude.

Еще пол года назад казалось, что все уже в теме, все юзают Claude.

Но реальный адопшен случился только в апреле.

На скрине легендарный график Hockey Stick, легенда экспоненциального роста.

Сначала накапливается критическая масса (база пользователей, узнаваемость, сетевые эффекты, ретеншен), и пока ее мало – мы видим стабильный уверенный рост.

Когда масса набрана – каждый новый юзер приводит еще двух, и начинается ракета.

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

В небольшое забавное приключение вчера вляпался.

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

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

Альтернатив нормальных нет, пробую снова поставить, уже под впн, а она сносит инсталлер и делает ребут. Тут у меня уже сгорела пятая точка, пожелал этому козлине 2 дня поноса и три дня запора и пошёл на пару с Claude сочинять велосипед. Иронично, что Клоду, вообще говоря, самому запрещено работать с русскими, но он все равно ринулся обходить блокировки другой такой же программулины. В общем, стащили мы из этой утилитки подход с GrubInst, написали простенький ps-скрипт и в 4 утра таки поставили любимую Убунту.

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

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

Тоже последние пару месяцев все чаще задумываюсь, что agentic cli - лучшая оболочка над операционной системой. По крайней мере, для линуксоидов, которым дай волю - они бы и со всем остальным миром через CLI общались.

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

Ну и в продолжение

Что у других?

1. Процессы без частого человеческого ревью.

Тут есть две концепции. 

Первая - это мечтатели, которые все пытаются сделать полностью автономные"рои агентов", которые все сами. Пока это либо теоретики, у которых все на тестах как надо, и вообще теперь разрабы - это про что угодно, кроме кода. Либо практики, которые честно признаются, что пока ничего не получается, и деструктивные действия агентов другими агентами пока не купируются. Примеры: gas town и weaving loom.

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

2. Однослойные тесты.

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

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

3. MCP-driven AI-manual тесты.

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

А раз селениума нет, а фронт тыкать надо, то можно под это дело запрячь нейросеть. Ей даётся playwright-mcp и она отправляется тестировать интерфейс. И это ещё хорошо, если по одному и тому же тест-плану.

Какие тут проблемы? 

3.1. Надёжность. 

Нейросеть легко может сказать, что все проверила, и все работает, а на деле это будет не так по миллиону причин: не запустила проверки вообще, проверила не все; была проблема, но она ее посчитала нерелевантной, pre-existing или ещё чего.

3.2. Токеносжигание. 

Playwright-mcp - самый страшный пожиратель токенов, который только можно придумать. Прогон сотни тестов легко сожрёт все ваше пятичасовое окно.

3.3. Время прогона.  

Даже Selenium-тесты известны своей неторопливостью. Они не только завязаны на сеть, базу и даже, порой, шедуллеры, как апи-тесты, но и на многократное ожидание отрисовки и срабатывания элементов интерфейса.

А вот playwright-mcp тесты сюда добавляют ещё и обмен с mcp, и поход на север ллм, и болтологию ллм, и тупняк ллм. 

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

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

4. Хаотичный вайб-код.

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

5. Экзотика.

Тут креативные ребята вовсю выдают разные фреймворки в меру своего понимания глубины проблемы. 

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

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

Что там по вайб-коду?

Снова делюсь промежуточными итогами и мыслями по ИИ-разработке.

Мой процесс устаканился

В общем, вопреки ожиданиям, мой процесс разработки с агентами с конца марта практически не изменился. Фреймворк чуть поумнел, но не радикально.

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

Что меня смущает?

Больше всего - скорость итерации. Сейчас средняя скорость разработки находится в районе 1 кейса в час работы. При 8-часовом рабочем дне и ~30 кейсах на историю - это 4 дня на одну историю.

Это не сильно быстрее, чем ручная разработка. При этом из-за работы в параллель lead time по средней истории в таком цикле занимает 2-3 недели. То есть вы выдаёте не одну историю через неделю, а 4 истории разом, но через 3 недели.

И тут я вижу следующие сдерживающие факторы:

1. Ошибки ллм.

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

По ощущениям каждый второй-третий запрос в агента - просьба что-то доделать или поправить. Это х1.5-2 к времени реализации.

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

2. Скорость ллм.

В текущем процессе Клод у меня молотит итерацию по 10 минут минимум. Чаще всего это связано с большим количеством проверок (на ревью-агентах и на тестах) и (через часик-другой) перегревом ноута, который в параллель крутит 6 ide, 6 сессий и 6 копий приложения и инфраструктуры в докере. Причём, тут есть положительная обратная связь: чем медленнее едет сессия, тем больше надо открывать в параллель, чтобы работа не простаивала, тем медленнее идёт сама сессия.

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

3. Количество кейсов.

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

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

4. Частота ревью.

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

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

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

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

5. Противоречия в требованиях.

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

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

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

По касательной ко вчерашней теме вот какая мысль идёт.

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

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

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

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

Что самое важное в айти?

Вот прям самое-самое важное? Щас покажу.

Я сейчас езжу на Шкоде Октавии 2020 года. И каждый раз, когда я сажусь в неё, вижу перед собой пособие того, как не надо разрабатывать программное обеспечение.

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

Ну зацените:
1. Карты.
-  доступны по всему миру 
-  с геопозицией
-  с определением направления движения
-  с механизмом построения маршрута 
-  адресная книга на весь мир
-  автоматическое предложение проехать до ближайшей заправки на низком уровне топлива
-  собственно список азс
-  отображение карты на цифровой приборной панели
-  отображение следующего поворота на маршруте внутри спидометра цифровой приборной панели.
-  ну ещё всякие фичи типа "избранного"
2. Голосовой ввод (который нормально не работает)
- звонок по голосовому вводу
- ввод маршрута
- реакция на кодовое слово
- бог знает, что ещё
3. Ну и по мелочи:
- регулировка освещения в салоне
- плюс (!) предустановленные варианты освещения
- управление ассистентами на основном экране
- плюс (!) управление ассистентами на цифровой приборной панели
- плюс (!) управление ассистентами только на отдельной картиночке

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

К чему это я?

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

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

Хотите наглядный пример? Посмотрите на всеми любимого "супер-единорога", на гугл:
1. Гугл Карты не разработаны гуглом, он их купил в 2004 году. Огромный поток выручки от рекламы.
2. Ютуб? Куплен в 2006 году. Огромный поток выручки от рекламы. Убил Google Video.
3. Android? Куплен в 2005 году. Огромный поток выручки от Play Market. 
4. Google Docs, Sheets, Slides, Photos, AdSense, AdMob, DeepMind? Куплены.

И там ещё десятки таких поглощений. Плюс большинство своих сервисов гугл развивал не столько успешной разработкой, сколько покупкой очередной технологической компании: как, например, Google Translate получил часть фич за счёт поглощения Word Lens. Из гибридов у нас ещё: Google Meet, Cloud, Pixel и ещё много чего.

При этом есть целый список из сотен проектов самого гугла, которые так и не взлетели. Кто-то ещё, наверное, помнит Google Glass или Google+, соцсеть, на которую гугл сливал деньги аж до 2019 года. 

О чем это говорит? О том, что мелочь развивается эффективнее.

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

Так что самое важное в айти?

В целом, ни тесты, ни чистый код, ни что-то ещё не дадут вам столько, сколько банальный вопрос: "а что будет, блин, если мы это не сделаем?" Вы удивитесь, как часто вы будете себе отвечать: "ничего страшного". 

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

Хотя нет, если у вас есть горы ненужных денег, то тогда деньги - король разработки. С деньгами вам даже lean не нужен. Но, если денег нет, то lean.