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

Вышла хорошая статья «8 Levels of Agentic Engineering» — автор постарался разделить на логичные уровни то, как разработчики эволюционируют в работе с кодинг-агентами. Первые пять уровней (tab complete, Agent IDE, context engineering, compounding, MCP/skills) многие уже так или иначе прошли. Что дальше?

Уровень 6 — harness engineering. Суть: дать агенту окружение, в котором от будет достаточно самостоятельным. Команда OpenAI Codex, например, подключила к рантайму агента Chrome DevTools и observability — и агент сам воспроизводит баг, пишет фикс, валидирует через UI, открывает PR и мёржит. Человек подключается только по запросу.

Уровень 7 — background agents. Когда harness настроен, агент может работать, пока вы спите. Популярная точка входа — Ralph loop: автономный цикл, где агент раз за разом запускает CLI, пока все пункты задачи не закрыты, каждая итерация — свежий инстанс с чистым контекстом. Важный на этом уровне совет, к которому я тоже пришел опытным путём: используйте разные модели под разные задачи. Opus на реализацию, Gemini на ресёрч, Codex на ревью. Одна модель (особенно в одной сессии) не должна и писать и ревьювить код.

Уровень 8 — агентные команды без центрального оркестратора. Anthropic 16 агентами написала C-компилятор, Cursor сотнями агентов строил браузер с нуля. Но по сути сейчас ни у кого это в полной мере не работает.

В интересное время живём!

@ai_for_devs

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

Итого

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

В каком направлении двигаться? Фреймворк с тестами и ревью.

1. Какое ревью? Чем больше кода за раз смотреть, тем тяжелее. Поэтому чем чаще, тем лучше.
2. Какие тесты? Перед разработкой список кейсов для реализации. После разработки - соответствующий набор автотестов.
3. Какой фреймворк? Вот именно.

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

По горячим следам

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

Все не очень радужно

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

Спустя 2,5 месяца я все ещё пытаюсь найти тех самых лидеров, от которых я, как мне казалось, должен был отстать. Но, если честно, что-то я их не очень нахожу.

Каменный век

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

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

Другая группа каждую неделю носится с next big thing: то spec-driven development, то bmad, то get shit done, то spek kit, то Ralph loops. А как только фреймворк закончил свою работу, они незаметно превращаются в первую группу.

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

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

Короче, все это, откровенно говоря, вообще не то.

Чего им всем не хватает?

1. Без фреймворка нельзя.

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

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

2. Тесты всему голова.

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

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

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

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

3. Нельзя без ревью.

Когда Антропик гордо заявляет, что "coding is solved", а потом не может даже 2 девятки показать, то это, конечно, вызывает ухмылку. Может, конечно, Антропик может строить успешный бизнес с двумя девятками, но есть огромная куча областей, где такая надёжность ну совсем неприемлема.

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

Такая жиза. Клод постоянно валяется в пятисотках, но заявляет, что software is solved😁

Думаю, всем уже понятно, про что будет следующий пост.

https://youtube.com/shorts/YvZW2J0uAuc?si=v_gumygq2Gwpl1Kq

Вот такая смешная история приключилась в Амазоне:

- За прошлый месяц лежали 6+ часов, в декабре лежали 13+ часов
- Даунтаймы связали с вайб кодингом
- Решили что весь код от AI coding assistants должен проходить ревью сеньоров

Удивительно, как быстро заметен эффект от внедрения ИИ в бизнес.

Думаю, что меры эти не помогут, и в критичных сервисах ИИ разработку запретят.

Не про девопс

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

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

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

Ответ тут, как обычно, зависит от ситуации.

Где это нужно

Возьмем для примера условный Амазон. Есть ли там место инфраструктурным инженерам? Конечно! Там в нулевые целая платформа родилась, чтобы обеспечить внутренние потребности разработки инфраструктурой. Т.е. виртуалками. И инфраструктурным кодом, который их спавнит, редактирует и убивает.

Сейчас мы эту платформу знаем как полноценный продукт, AWS, на котором крутится, наверное, половина всего софта на западе.

То есть инфраструктурные инженеры, объединённые в платформенные команды, могут быть весьма полезны в определённых условиях.

Корректно ли их называть девопсами? Трудно сказать. Но сути их работы это не меняет.

А что, если вы берёте уже готовую чужую платформу в аренду (например, aws), а поверх начинаете чудить свою платформу?

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

Хорошо, а что если строить своё, как у AWS? Да, тут тоже без инфраструктурного инженера не обойтись. Но необходимо понимать, что у вас будет очень сильно хуже и очень сильно дороже, чем у Амазон.

Плохо ли это? Ну, если вам нельзя ни в AWS, ни в Яндекс облако по каким-то причинам, а продукт у вас толстенный и будет расти дальше, то это ваш путь.

Когда лучше без этого

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

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

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

Но можно же лучше?

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

Я уже упоминал в своих статьях про тестирование, что deployment pipeline - это не столько про поставку в прод, сколько про автоматическое тестирование всего, что можно протестировать до прода.

Ну то это есть, это не только прогнать юниты и собрать образы. Но ещё и поставить на стенды, прогнать там приёмочные е2е тесты, фронтовые тесты, нагрузочные тесты.

И только после этого уже ставить в прод уже проверенный билд проверенным скриптом с проверенной конфигурацией инфраструктуры. Или публиковать в маркетплейс, если это, например, мобилка.

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

Ну или не обнаружите, но это уже совсем другая и очень грустная история.

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

Краткий апдейт по моим промптам.

За те 2 недели, что прошли с моего прошлого поста про вайбкод, мой сетап увеличился на треть - с 4 тысяч до 6 тысяч строк. Я вносил в него изменения каждый раз, когда:
- видел регулярно повторяющийся косяк;
- замечал, что делаю одно и то же;
- три агента залипали в работу, и у меня появлялось время на то, чтобы дернуть четвертый с какой-то идеей оптимизации.

Помимо упомянутого /continue flow, который сильно механизировал мою работу, добавились 4-слойная архитектура промптов со своим описанием в rules и 2 специальных скилла под промпты: для корректного редактирования промптов, куда надо, и для их рефакторинга, куда надо. О ней, наверное, в следующий раз.

Ну и помимо кучи всякой мелочи, еще 2 прикольных скилла добавил для потока /continue. В концу туду-листа каждого фронтового кейса теперь стоит скилл /demo, который запускает Селениум и показывает, чего он там намалевал на фронте.

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

Снова про вайбкод

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

Значит ли это, что скоро бэк будет корректен в 3 из 4 случаев, а фронт в 9 из 10? Наступит ли то будущее, когда модельки будут правы в 99 случаях из 100?

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

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

Про железо

Если вы пойдёте смотреть, сколько вам будет стоить хотя бы час погонять какую-нибудь опенсурсную модель, сравнимую по бенчмаркам с Клодовским Опусом, у вас челюсть отвиснет. Даже 8-битная GLM5 INT8 (~97-99% от точности топовой 16-битной GLM5 FP16, бенчмарк которой в прикреплённом изображении) на 204 тысячи токенов (эт как у опуса) обойдётся вам в 41 видеокарту NVidia H100 на 80 Гб. Это почти 3 млн рублей за видеокарту или 120 млн рублей за сетап. Селектел за один сервак с такой NVidia просит 12к в день или 320к в месяц. На 41 видеокарту получается ~500к в день или ~12 млн в месяц.

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

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

Про контекст и промпты

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

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

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

Вот и у меня так же теперь. Я вызываю шаг /continue 12, Claude смотрит в сгенерированный им же todo-лист с прогрессом фичи под номером 12, видит, где он остановился в прошлый раз, и продолжает с этого места. Через 5 минут он отмечает прогресс и останавливается, чтобы я, как голубь, посмотрел на экран и клюнул ему на какой-то косяк. Потом я нажимаю /continue, и он едет дальше.

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

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

Про девопс

Наша индустрия тяжело больна двумя очень близкими болячками: карго-культ и semantic diffusion.

1. Карго-культ - это, как пример, про то, что бигтех делает аджайл и они крутые, поэтому мы тоже будем делать спринты, дейлики и ретроспективы.
2. Semantic diffusion - это, например, считать, что аджайл = спринты, дейлики и ретро.

Помимо аджайла жертвами этой болезни стали такие понятия, как микросервисы, CI, CD, DevOps и ещё, на самом деле, много чего. CI и CD насколько безнадёжно путают между собой, что даже превратили в единый термин CI/CD, чтобы не разбираться чем одно отличается от другого.

И вот из этого списка я пока не касался только девопса, наверное.

Что такое опс

Девопс - составное слово, состоящее из development и operations. И, если про первое всем всё понятно, то вот откуда взялось второе, и что оно значит - это прям загадка.

Если кратко, то это просто последняя фаза waterfall-модели: аналитики анализируют, архитекторы архитектурируют, девелоперы девелопят, тестировщики тестируют, а операции оперируют. В общем, операции - это те, кто эксплуатируют софт.

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

Конфликт

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

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

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

Эта проблема называется big wall of confusion и известна уже лет двадцать.

Решение

Тут есть 2 варианта решения:
1. Запихнуть всех в одну команду и спрашивать и за стабильность, и за темпы поставки.
2. Переложить ответственность за операции на команду разработки.

В Амазоне, например, все команды разработки называются devops teams. Именно поэтому.

Каждый разработчик имеет пейджер, на который ему приходят сообщения, если в проде беда. Ну и, естественно, график дежурств, on-call, третья линия - вот это все, на самом деле, и есть настоящий девопс.

И после переезда Netflix в облако Adrian Cockroft, архитектор Netflix, даже пошутил, что наступила эра NoOps - насколько легко разработчикам стало управлять своей айти инфраструктурой. Сейчас кстати он шутит, что наступила эра NoDevs.

Итого

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

А при чем тут тогда чел с зарплатой 500к, который круглые сутки кубер ковыряет и в дженкинсе джобы пишет? Или даже команда таких ребят?

А ни при чем.

Теперь коротенькая инструкция, как работать в "заводике":

I. Подготовка.
0. Покупаем клод (купить впн, купить карточку типа платипомиру). Рекомендую Мах-план за 90 баксов в месяц, ибо 20 баксов маловато.
1. Клонируем, открываем в IDE, запускаем в консоли клод.
2. Меняем под себя в папочке ProductSpecification файлики: BriefProductDescription.txt, ArchitectureDescription.txt, ExpectedLoad.txt, MvpStories.txt.
- Писать лучше на английском - token consumption в 2 раза меньше.
- У нас тут "Clean architecture" с юзкейсами всякими, так что смело меняйте под свои подходы.
3. Просим клод проапдейтить сетап под новый домен и архитектуру (у меня работают термины Claude Configuration, Claude Setup).
- Рекомендую использовать /plan, чтобы хорошо понимать, что нейросеть собирается менять.
- Рекомендую почистить контекст (/clear) и повторить потом запрос снова, чтобы убедиться, что следов от старого домена нет.
4. Копируем всё это счастье в свою репу, открываем IDE и консоль с клодом в ней.

II. Спеки.
1. Генерим и ревьюим сторю со скиллом "/story 1".
- Если есть какие-то важные нюансы, которые надо учесть, лучше предварительно создать "story-specifics.txt", положить в будущую папочку или передать промпту на вход.
- На выходе 2 md-файла - описание и заметки, на что надо обратить внимание.
2. Генерим и ревьюим мокапы фронта, если надо "/mockups 1".
- На вход пойдут ваши BriefProductDescription.txt и сгенеренное описание стори;
- На выходе - папочка с мокапами в HTML под ПК и мобилку + скрины
3. Генерим и ревьюим апи-спеку.
- На вход идёт описание стори + мокапы.
- На выходе openAPI (Swagger) спека.
4. Генерим и ревьюим тесты.
- На вход идёт всё выше сгенерированное.
- На выходе - целая куча папочек с тестами: API, UI, Security, Load, Infra, Integrations.
- Для каждого варианта тестов есть еще Extended файл с разными корнерами, которые на первом этапе можно опустить.

III. Бэк.
1. Имплементация
- Когда спека сгенерирована, вызываем 'run prompts/ScenarioImplementation.txt for story 1, api case 1'. Не обязательно так, можно как угодно.
- После первой итерации клод нарисует аксептанс тест, отревьюит его на строгость, сделает коммиты в локал и предложит оценить.
- Смотрим, просим исправить, что не нравится. Смотрите пункт про "Ментальную модель".
- Потом будет красный юнит-тест на логику application-слоя. Смотрим и правим. Иногда в этом слое правки не нужны, но он все равно туда лезет - надо ему на это указать.
- Зеленый тест и рефакторинг. Смотрим и правим.
- Потом, по идее, должен быть адаптерный тест. Если адаптера нет, то в интерактивном режиме предлагаем создать, смотрим предложения.
- Идём в том же цикле, пока все адаптерные тесты не готовы.
- В конце концов, клод переходит к /green-acceptance, запускает приложение и проверяет, что сценарий готов и ничего не сломано.
2. Комментарии
- при желании, можно отредактировать скрипт и скиллы под свою тестовую модель (только аксы / только юниты / аксы без запуска приложения) и выкинуть лишние шаги;
- при желании можно убрать лишние ревью, но я не рекомендую - ревью становится слишком утомительным;

IV. Фронт.
1. Имплементация
- Когда бэк готов, вызываем 'run prompts/FrontendScenario.txt for story 1, ui case 1'. Не обязательно так, можно как угодно.
- После первой итерации клод нарисует selenium acceptance тест, смотрим его и правим.
- Потом клод сделает красный юнит-тест на бизнес-логику - смотрим и правим.
- Потом имплементация - смотрим и правим.
- Дальше апи-клиент к бэку в таком же цикле
- Затем вёрстка, чтобы позеленить селениум и приведение к мокапу.

Продолжаем про вайбкод

0. Подарочек

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

1. Про мотивацию

Короче, уже видно, что AI-assisted software engineering - это 100% состоявшаяся практика. Ждать ничего уже не надо, это работает уже сейчас - надо брать и переезжать.

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

В итоге, получается несколько даже перекошенный (хоть и в правильную сторону) результат. Если базовый функционал все так же едет вперед с неплохой стабильной скоростью, то вот обвязка, которую часто раньше делали по остаточному принципу (документация, UI/UX, тесты, инфраструктура и многие другие "фишечки") ИИ делает теперь автономно и очень быстро. Поэтому, когда функционал готов, он готов уже сразу весьма хорошо, на уровне лучших домов.

2. Про инженерный подход

Сегодня мне скинули вот этот пост, и, в целом, я с ним согласен. Если кратко, то там хаотичному "вайб-кодингу" противопоставляется "Инженерный подход". Я бы даже сказал ИИнженерный.

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

Поэтому в нашей команде очень серьезно относятся к идеям Executable Specification, когда реальное поведение смотрят по тестам, а документация нужна лишь для заметок аналитиков и коммуникации между аналитками и разработкой.

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

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

3. Про ментальную модель

А вот с чем я не согласен, так это с аналогией, что LLM - это компилятор нового поколения. В книге у Vibe Coding Джина Кима и Стива Йегге указывается, что более корректная ментальная модель - не инструмент, а тиммейт. И наш опыт взаимодействия тоже показывает, что одна лишь фраза "What do you think?" в конце каждого промпта полностью меняет процесс взаимодействия.

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

А вот что работает круто:
- объяснить, что не нравится
- спросить мотивацию такого решения (если оно было принято только что)
- предложить свой вариант решения
- спросить мнение нейросети и попросить её предложить свои варианты

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

4. К скиллам

У меня получился целый фреймворк, который мы зовём "заводиком", заточенный чисто под мою разработку. Я не планировал им делиться, но раз уж спросили, то вот. Из подготовки к публикации - только сожженые 50% макс-сессии токенов на замену любых упоминаний моего проекта на таск-менеджер. Поэтому не серчайте сильно, что не очень user-friendly.

Уже месяц с головой барахтаюсь в вайб-кодинге. Описал свои впечатления от этого месяца на Хабре.

И это еще компания небольшая. Месяца полтора назад писал именно об этом :)

Делай просто

Я сижу и понимаю, что мою простую задачу – поменять текст на лендинге – делают уже третью неделю.

Начинаю разбираться:

– Сначала задача от меня попадает в Jira к продакт-менеджеру
– Продакт создает таск в Джире
– Потом он с этим таском отправляется на ревью к дизайнеру, а оттуда на ревью к юристам
– Потом он это всё согласовывает и отдает разработчику
– Разработчик делает пулл-реквест, который проходит код-ревью
– После этого изменения попадают на тестовый сервер
– Тестировщик проверяет в отдельной системе трекинга багов
– И только потом все изменения попадают на прод

8 этапов, 6 человек, три системы.

Чтобы поменять одно предложение на сайте.

Самому было бы поменять 2 минуты вместо трех недель.

Это ситуация из моего 2020го.

Что я из нее понял?

Что если у вас в компании “продуктовая культура” и “процессы”, а оффер на лендосе меняется три недели – значит конторе скоро пиздец, и надо что-то срочно предпринимать.

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

Про слонов и мышей

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

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

В общем, не так давно посмотрел вот этот доклад Джеймса Льюиса и был очень впечатлён. Как обычно, рекомендую ознакомиться именно с первоисточником, но, как аннотацию, оставлю краткий пересказ тут.

Испорченный телефон

Оказывается, что существуют и тот, и другой механизм. Но большинство компаний все же попадают в первую категорию: чем они больше, тем сложнее им расти: каждый следующий рост на 15% хуже предыдущего. Однако есть и другие компании, например, Амазон, в которых в каждой следующей итерации рост на 15% выше, чем в предыдущей.

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

Complexity Science

Ответ лежит в теории жизнеспособных систем из Complexity Science, основным объектом исследования которой является сложная адаптивная система. Если простым языком, сложная адаптивная система - это абстракция, под которую можно подвести разные самоорганизующиеся штуки: организмы, города и страны, коммерческие и иные организации, экосистемы и рынки. Характеристик у таких систем много, но главные: множество похожих взаимодействующих элементов, самоадаптация системы и эмерджентность - система имеет свойства, которых у ее составляющих нет.

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

В таких структурах работает экономика масштаба, когда многие вещи делать дешевле за счёт масштабирования.

Например, животному, которое больше в 2 раза, нужно примерно в 1,85 раз больше калорий. То есть чем больше животное, тем дешевле его кормить в пересчёте на килограмм. Зависимость там не линейная, а степенная, но, как результат, лабораторная мышь потребляет в среднем 1 ккал на 1 грамм массы тела, в то время как слон потребляет где-то 10 ккал на 1 кг тела, то есть в пересчете на вес в 100 раз меньше.

Обратно к организациям

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

Про светлое будущее

Альтернативная топология - плоская или горизонтальная структура. Пример из жизни: город. Здесь также работает экономика масштаба. Например, в 2 раза большем городе затраты на дороги будут всего в 1,85 раза выше. Но здесь нет очередей и иерархий, которые бы сдерживали дальнейшее развитие системы, поэтому с ростом плоских организаций в 2 раза мы получаем в 2,15 больше денег.

Именно, такая экономика лежит в основе плоских организационных структур бигтехов. И именно иерархическая организационная структура связывает многие компании по рукам и ногам.

Про кранч

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

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

Про переработки

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

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

При переработках люди выгорают, устают, в среднем работают менее эффективно. Что эти 5-10% дополнительных трудозатрат дают? Экономию на ФОТ? Ну снизьте вы вилку при найме тогда на те же 5-10%; все равно специалист, в итоге, будет примерно того же уровня.

Умный в гору не пойдёт

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

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

С чего это я вообще завёлся

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

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

Например, мы особо не рассказываем руководству про свои внутренние процессы и взгляды. И, скорее всего, именно поэтому нам особо никто не мешает.

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

Как стать тимлидом?

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

Как у меня было

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

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

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

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

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

Про проблемы

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

1. Это пассивная позиция

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

2. Текущая команда

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

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

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

Как тогда быть?

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

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

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

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

NB

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

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

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

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

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

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

3. Набор специалистов.

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

Это происходит по нескольким причинам:
- почти нигде нет нормального автоматического тестирования и, в целом, длинные циклы обратной связи = накладные расходы;
- избыточно сложная архитектура = накладные расходы (см. п. 1);
- избыточные процессы = накладные расходы (см. п. 2);
- эффект ёмкости задачи (9 женщин не могут родить одного человека за месяц);
- недостаточное внимание к приоритизации часто приводит к тому, что огромную часть времени команды тратят на второстепенные задачи, пока киллер-фичи простаивают. Например, из трех команд одна загружена киллер-фичами на полгода вперёд, а две другие пилят всякую малозначительную ерунду из своего бэклога. То же можно сказать и про специалистов: один загибается над ключевыми задачами, второй подметает всякую второстепенную мелочёвку из бэклога. В итоге, команда работает вполсилы.
- Избыточно узкая специализация сотрудников, когда бэки в мыле пилят фичи, фронты от безделья фреймворк меняют и кнопки красят, а девопсы все настроили и вообще бамбук курят или на второй работе фигачат.

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

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

Вывод

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