Никита Ульшин про IT

Как я понял, что пора внедрять агентов в разработку

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

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

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

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

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

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

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

Озвученная дата автоматически становится обязательством

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

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

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

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

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

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

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

// Доводилось ли вам так случайно коммититься на дату, когда вы этого даже близко не планировали?

Как я возвращаю паузы, которые у меня отнял ИИ

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

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

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

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

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

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

ИИ должен экономить мои силы, а не помогать мне эффективнее их сжечь.

// А вы сразу запускаете нового агента или используете это время как паузу?

Почему не все интересные идеи влияют на жизнь

Я люблю читать книги.

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

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

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

Что такое «усвоенная идея»?

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

Для меня «усвоенная идея» – это идея, которая настолько прочно встроилась в мою голову, мышление и систему ценностей, что начала влиять на моё поведение, решения и мировоззрение. По сути, это идея, ставшая частью меня самого.

Примером такой усвоенной идеи являются «толстые хвосты» из творчества Нассима Талеба. В своих книгах он часто говорит о нелинейной природе вероятности, а «толстыми хвостами» называет маловероятные события (находящиеся слева/справа на кривой нормального распределения) с аномально мощными последствиями. Переварив эту идею, я перестал смотреть на маловероятные события только с точки зрения вероятности их наступления и начал задумываться ещё и о рисках, которые они создают (въедливый читатель тут к месту упомянет «чёрных лебедей» и будет прав, но это эссе не о теории вероятности в жизни).

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

⭐️ Область усвоения идей

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

Тогда я задумался: а что же кардинально отличало те идеи, которые залетели мне в голову и крепко там засели? Ответ пришёл в виде книги Оливера Беркмана «Четыре тысячи недель на всё», которая внезапно потрясла меня и дала возможность поискать ответ на вопрос выше. Ведь потрясение не на ровном месте произошло.

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

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

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

// Неплохо я развлекаюсь на выходных, да? :)

«Не знаю» больше не значит «не могу»

С развитием LLM-ок фраза «я не знаю» перестала означать «я не могу это сделать». Благодаря бездушной железяке я могу спокойно зайти в плохо знакомую (или даже совсем незнакомую) область и начать в ней действовать, даже не имея глубокой экспертизы (но только до границы, за которой я уже не способен проверить результат).

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

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

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

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

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

ИИ убрал из моей работы передышки

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

В последнее время я снова выкраиваю время на разработку. Что-то удаётся делать на работе, что-то — по вечерам в пет-проекте. Сначала списывал усталость на обычное «руководитель решил ещё и вечером поработать», но эффект повторялся.

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

У меня появилась рабочая гипотеза: ИИ убрал из моего процесса длинные участки исполнения уже принятого решения, которые всегда были для меня самой лёгкой частью. Из цикла «подумал-написал-протестил-поревьюил-порефакторил» ушла часть про «написал» (и даже «протестил» сильно видоизменилась). Теперь ИИ легко и быстро «настукивает», а на мне остаются постановка задач, выбор решения, проектирование и анализ результата.

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

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

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

Агент может работать без передышки. Я — нет.

// Если тоже заметили, что с ИИ стали уставать быстрее — ставьте 👍

Я прочитал 150 книг и решил читать меньше

За последние полтора года я прочитал около 150 книг и в итоге решил отказаться от режима «книга в неделю». Большинство прочитанного, по моим ощущениям, не стоило потраченного времени.

Я не гнался за цифрой как таковой: просто мой пайплайн чтения позволял столько читать без особого напряга. Но последние несколько месяцев я ехал в том же потоке, а чувство ценности от чтения куда-то пропало. Осознать проблему мне помогли рождение дочери и книга «Четыре тысячи недель на всё». Дочь мощно срезала количество свободных сил, а книга напомнила: я всё равно не успею изучить все интересные идеи в мире. Да и не нужно.

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

Последние несколько недель я провёл в кризисе: по-старому уже не хочется и не можется, а новой модели поведения ещё нет. Я упорно размышлял (и размышляю) над тем, почему только единичные книги действительно повлияли на мою жизнь и дали ценные идеи. Эта проблема «чешет мне череп изнутри» настолько, что я снова начал писать заметки. Особенно смешно, что раньше я уже похоронил заметки и мини-эссе, решив, что они для меня не работают. Тогда заметки были ещё одним этапом обработки прочитанного, а теперь я возвращаюсь к ним, чтобы подольше не отпускать вопросы, на которые у меня пока нет ответа.

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

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

Например, сейчас я пишу серию заметок, в которой размышляю о следующих вещах:
➡️ почему одни хорошие идеи действительно меняют жизнь, а другие проходят мимо;
➡️ как отличить просто «вкусную» идею от той, что повлияет на меня;
➡️ как я могу улучшить свою работу с такими идеями (и могу ли вообще).

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

Не знаю, что из этого получится, но мне интересно. Присоседивайтесь 😉

// Какая книга повлияла на вас сильнее всего?

Поднимаем SDD на уровень продукта

Spec-driven development хорошо работает, пока продукт помещается в один репозиторий. У нас это не так: фронт и бэк живут в разных монорепах, а общая фича начала превращаться в две разные спеки.

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

Недавно в OpenSpec появились Stores — отдельные Git-репозитории для общих specs и changes, на которые могут ссылаться кодовые репозитории. Наши бэк и фронт живут в разных монорепах, поэтому модель хорошо ложится на продукт.

На выходе мы получаем довольно интересный docs-as-code:
➡️ Аналитик пишет общие proposal и specs.
➡️ Разработка и QA ревьюят их и при необходимости добавляют designs и tasks.
➡️ Реализация остаётся в репозиториях с кодом.
➡️ Где хранить designs и tasks (в общей репе или у каждой команды отдельно), пока не решили — проверим оба варианта.

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

Конечно, OpenSpec — это просто инструмент. Нам всё ещё нужно определить ownership документации, настроить её обновление и написать кастомные скиллы. К тому же Stores пока в бете.

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

// А у вас требования к сквозным фичам живут в одном месте или собираются по кусочкам из нескольких репозиториев?

Большинство AI-новинок не стоит вашего времени

Я слежу за новыми AI-инструментами сразу, но не спешу тратить время на их освоение. За несколько месяцев очередная «революция» либо превращается в рабочий инструмент, либо растворяется в новостной ленте.

Я уже видел несколько финалов технологического хайпа. Блокчейн почти исчез из повседневной IT-повестки. ML перестал быть магическим словом и стал обычным инструментом для подходящих задач. Микросервисы остались, но вместе с хайпом испарилась вера, что ими нужно обмазать вообще всё (я и сам не раз вливал сервисы обратно в монолит).

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

Как и в любой хайповой теме, новые AI-инструменты появляются быстрее, чем люди успевают их освоить. Большая их часть исчезает из информационного поля раньше, чем успевает пригодиться. Если смотреть не на количество релизов, а на сам процесс разработки, за последний год я вижу мало устойчивых изменений: модели стали лучше писать код, а SDD и harness engineering получили распространение. Всё.

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

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

// Вы пробуете новые AI-инструменты сразу или ждёте, пока индустрия отфильтрует шум?