Код-ревью в эпоху ИИ: как агенты меняют проверку кода
На работе пулл-реквестов стало больше, они стали заметно объёмнее. Каждый последующий аппрув я ставлю с меньшей уверенностью.
В предыдущем ресёрче про coding agents и SDLC я разбирался, как и почему проверка кода становится узким местом в разработке. А теперь я решил отдельно посмотреть, что происходит с код-ревью.
Мне стало интересно: а что же сейчас происходит с код-ревью как процессом? Продолжают ли люди отсматривать построчно пулл-реквесты, сделанные агентами, или ставят аппрувы не глядя? И на что в итоге это влияет?
Лично я уже смещаю внимание на спецификации, архитектуру, контракты и интеграционные тесты. Насколько такой подход сохраняет качество и передачу знаний, я пока не могу оценить.
Из этих проблем и вырос мой новый ресёрч о том, как происходит код-ревью в эпоху ИИ. Вот несколько интересных тезисов:
➡️ AI-ревью на первом круге: полезные замечания есть, но экономию времени человека подтвердили далеко не везде. В A/B-тесте Google значимого ускорения ревью не нашли.
➡️ Аппрув и глубина проверки: в одной выборке люди чаще одобряют агентские PR и меньше комментируют. Это ещё не доказывает ухудшения качества, потому что дефекты за аппрувами не измеряли.
➡️ Проверка после мерджа: появляются данные о последующих исправлениях и откатах. Результаты различаются между агентами, свести всё к «AI-код хуже» не получится.
➡️ Передача знаний: человеческое ревью обсуждает контекст и помогает команде понимать систему. В агентских комментариях эти функции почти отсутствуют. Долгосрочный эффект для роста junior пока неизвестен.
В ресёрче я разбираю, что исследования уже показывают о пользе AI-ревью, поведении людей и исправлениях после мерджа. И объясняю, как меняю собственную проверку под выросший поток PR и какие последствия ещё предстоит измерить.
// Если прочитали — поделитесь, пожалуйста, обратной связью, был ли вам полезен и интересен ресёрч. Хочу сделать будущие публикации лучше :)
Тридцать замечаний LLM ради одного нужного вопроса
Вопросы от бездушного железного болванчика люди воспринимают спокойнее. Я на это и рассчитывал, когда подключал LLM к аналитике: пусть бездушная машина душнит, ищет противоречия, неотвеченные вопросы и делает допущения явными.
Почему аналитика? Неясное поведение затрудняет декомпозицию, оценку и тестирование. А уточнение фичи после реализации может стоить очень-очень дорого. О том, почему полезно душнить над деталями, я уже писал ранее.
Конечно же, раннее уточнение тоже требует времени. Какие-то неизвестные вещи всегда вылезут только при реализации, и если слишком сильно увлечься аналитикой, то можно потерять больше времени, чем сэкономить. Поэтому здесь нужно подходить с умом.
Например, недавно я провёл анализ фичи и получил от LLM-ки 30 замечаний, из которых всего лишь одно было полезным -- но если бы мы его пропустили, то переделка по моей оценке стоила бы 3-4 дня разработки (а у меня на ревью минут 30 ушло).
Для начала достаточно вгрузить аналитику в контекст и попросить модель проверить, какие вопросы остались без ответа. Например::
➡️ Что должно произойти, если операция выполнена лишь частично?
➡️ Одинаково ли описано поведение для разных участников и компонентов?
➡️ Какой результат позволит однозначно проверить, что эта фича работает?
Задачу лучше обозначить прямо: "Найти противоречия, допущения, неявные границы и неотвеченные вопросы, Пробелы своими догадками не заполнять".
Но не забывайте, что критиковать модельки умеют прекрасно, поэтому замечаний будет много. Каждое замечание всё равно должен оценить инженер: влияет ли оно на поведение продукта, тестирование или риск переделки? Количество замечаний само по себе не показывает пользу процесса
Напоследок я предлагаю вам провести реальный эксперимент: взять одну фичу, дать модели имеющееся описание и попросить найти неясности, не заполняя пробелы своими догадками. После этого зафиксируйте, сколько усилий вам потребовалось на то, чтобы разобрать замечания, и нашла ли модель что-то, что было бы ощутимо дороже переделать после того, как вы бы реализовали фичу без этого требования.
// А если вы уже используете LLM-ки для аналитики, то делитесь своими лайфхаками в комментариях
Я наконец-то собрал свой блог
За несколько лет ведения канала у меня накопились посты, лонгриды, исследования, выступления и эссе. Теперь всё это собрано на ulshin.tech.
Я давно хотел это сделать по нескольким причинам:
➡️ Мне не нравится, что мой контент живёт только в ТГ. Внезапная блокировка — и придётся срочно-срочно поднимать альтернативную площадку.
➡️ Некоторые форматы (например, лонгриды или эссе) откровенно не лезут в формат ТГ-поста. Я уже попробовал выложить одно эссе в md-разметке — было очень грустно и некрасиво.
➡️ Материала накопилось много, и темы часто пересекаются. В блоге удобнее связывать тексты между собой, чтобы можно было идти от одной мысли к другой.
Поэтому последние две недели я по вечерам потихоньку вайбкодил блог: поднимал его, делал дизайн и работал над накопившимися за эти годы заметками. Некоторые из них я в итоге объединил в отменные лонгриды.
Приглашаю вас посмотреть блог и сохранить его себе. А чтобы вам было вдвойне интересно — на выходных я написал продолжение эссе «Почему не все интересные идеи влияют на жизнь» под названием «Признаки трансформационной идеи», в котором разбираюсь, чем идеи, которые меня действительно изменили, отличаются от тех, над которыми было просто приятно подумать.
📎Сохраните адрес блога, если хотите возвращаться к моим материалам.
Приятного чтения!
В последнее время на вопрос "Как у тебя дела?" я отвечаю: "Как в альбоме Пневмослона" 😇
Один из моих любимых музыкантов, кстати.
Как я понял, что пора внедрять агентов в разработку
Меня долго беспокоил простой вопрос: как ограничивать агентов и вести с ними продолжительную командную работу над большим проектом? Поэтому с внедрением я не спешил. Но продолжал наблюдать, что меняется.
Опыт — это палка о двух концах. С одной стороны, опыт помогает принимать хорошие и качественные решения. Но с другой стороны, тот же опыт может мешать внедрению инноваций в работу и в итоге замедлять её.
Так получилось и с агентами. Бум разработки с AI начался ещё год назад (даже чуть больше). Тем не менее я не спешил тащить агентов куда-то в продакшн, потому что открытых вопросов было очень много и опыт рекомендовал не торопиться. Но я продолжал наблюдать.
Больше всего меня беспокоило отсутствие нормальных инструментов для ограничения работы агентов и для продолжительной командной работы над большим проектом. Поэтому я с большим интересом наблюдал за тем, как агенты писали говнокод и дропали базы в проде. В итоге индустрия ответила — появились SDD, гардрейлы, сендбоксинг и ещё много чего. Работа с агентами стала более безопасной, а сам процесс разработки обогатился подходящей методологией и созданием полезных артефактов на будущее.
Когда это произошло — я понял, что пришла пора активно внедрять агентов в разработку, и начал свой коварный процесс (пробить всем аккаунты Клода, показать пару личных примеров, скинуть интересный скилл в чат и прочая пропаганда). Изменений практик в индустрии оказалось достаточно, чтобы я переключился из наблюдения в действие.
В этом для меня смысл слежки за индустрией: замечать, когда снимаются ограничения, из-за которых я раньше откладывал внедрение. И быть готовым пересмотреть своё решение. Отсидеться на жопе ровно в нашей индустрии не получится.
// Какое ограничение вам нужно снять, чтобы активнее использовать агентов в команде?
Озвученная дата автоматически становится обязательством
Иногда «примерные даты» на роадмапе неожиданно становятся обязательством. Причём это может произойти даже без явного намерения человека, эти даты изначально написавшего. Причина тому проста: для читателя документа опубликованная дата уже выглядит согласованной.
Происходит это обычно так:
➡️ Продакт прикидывает фичи и сроки на некоторый период вперёд.
➡️ Показывает предварительный план бизнесу.
➡️ Бизнес видит конкретные даты и начинает считать их согласованными.
➡️ В разработку дата возвращается уже не как ориентир, а как обязательство.
➡️ Разработка впервые проверяет обязательство на выполнимость и закономерно негодует.
С такой же ситуацией я столкнулся несколько месяцев назад. В статусных материалах появились конкретные даты, которые не согласовали с разработкой. Когда мы сверили их с реальными возможностями, выяснилось, что заложенный объём работ в эти сроки не влезает. В итоге мне пришлось долго и упорно откусывать от скоупа каждую лишнюю фичу, чтобы обещание стало выполнимым.
Проблема заключается именно в показанных датах. Читатели уже начали строить вокруг них свои планы, поэтому последующее уточнение воспринимается не как завершение оценки, а как перенос срока.
Впоследствии часто оказывается, что треугольничек «сроки — объём — доступные ресурсы» не складывается и чем-то надо жертвовать прямо на ходу. Поэтому приходится резать требования, создавать технический долг или пытаться наковырять где-то у соседей ресурсы «на полставочки», но это отдельные переговоры, а не гарантированное решение проблемы.
Хороший роадмап — это не красивая картинка со сроками и графиком клюшкой, а точка согласования возможностей и обязательств тех сторон, которые этот роадмап будут выполнять. Нельзя просто взять и проверить дату: всё написанное в роадмапе нужно хотя бы примерно оценить на выполнимость и приоритезировать. Оценка не должна быть хирургически точной, но стоит хотя бы минимально провалидировать её с разработкой.
Дата в презентации уже выглядит обещанием результата, поэтому публиковать её стоит только после сверки планов с реальными возможностями разработки.
// Доводилось ли вам так случайно коммититься на дату, когда вы этого даже близко не планировали?
Технофитнес: как эффективно прокачивать hard skills
Наконец-то в паблике появилась запись моего доклада с HolyJS 2025 Autumn о том, как разработчику эффективно качать свои харды.
Этот доклад я готовил почти год и несколько раз обкатывал по частям на митапах, тестируя тезисы. Несколько раз я его кардинально перерабатывал, и в итоге получилась конфетка.
Сам доклад — это история моей боли. После перехода в менеджмент я ощутил, что сильно выпадаю из технички, и старался не потерять профессиональную опору. Я пытался компенсировать просадку книгами и курсами, но ничего не получалось — сил уходило много, результата было мало. И тогда я начал разбираться в вопросе.
Что интересного есть в докладе:
➡️ заблуждения о развитии hard skills, которые усиливают тревогу;
➡️ принципы выбора навыков и построения образовательной траектории;
➡️ конкретные способы получать больше технического роста из рабочих задач;
➡️ работа с книгами, статьями, конференциями и LLM без бесконечного потребления информации.
С того дня, когда я рассказывал этот доклад, прошел уже почти год. И мне кажется, что он стал только более актуальным — технологии в очередной раз совершают скачок, и многие мои знакомые тимлиды страдают от того, что выпадают из агентной разработки. Сейчас я разве что немного поправил бы построение образовательного трека — LLM-ки за год успели серьёзно качнуться.
🎞 Доклад
📎 Дополнительные материалы
Приятного просмотра!
«Масштабированный скрам. Как организовать гибкую разработку в крупной компании», Крэг Ларман, Бас Водде
Одна из моих текущих задач — выстраивание процесса разработки на несколько команд в одном продукте с последующим масштабированием этих практик на все остальные продукты, разработкой которых я управляю. В прошлый раз при решении этой задачи я умудрился переизобрести LeSS (Large-Scale Scrum). В этот раз я не стал мудрить и решил использовать те практики, которые уже хорошо себя зарекомендовали.
Книгу я взял, чтобы вспомнить, из чего вообще строится LeSS и как его аккуратно внедрить, когда команда уже в разгаре разработки. Но ответа на второй вопрос я не нашёл. Вместо алгоритма внедрения получил россыпь моделей, практик и теорий.
⭐️ О чём книга
Книга посвящена тому, как внедрить LeSS в большой организации. Авторы фокусируются на моделях мышления, которые нужны для успешного внедрения подхода, и дают кучу идей и практик, которые читателю рекомендуется попробовать. Много внимания в книге уделяется инструментам мышления и анализа, которые позволяют эффективно управлять работами.
⭐️ Три идеи, которые я забрал себе
🟡При масштабировании делить нужно работу, а не продукт. LeSS предполагает, что все команды работают в едином продуктовом бэклоге и едином ритме, а с требованиями помогает справиться единый владелец бэклога. Такой подход помогает не превратить команды в отдельные «мини-продукты со своим миром». Меня эта идея зацепила тем, что при масштабировании очень легко неосознанно размножить локальные бэклоги и получить несколько правильных приоритетов одновременно. Общий бэклог заставляет выбирать, что важнее для продукта целиком.
🟡В LeSS менеджер становится не просто «передастом» работы, а учителем. Задача менеджера — распространять правильные паттерны мышления и по сути выращивать культуру организации. Поэтому от менеджеров в LeSS ожидается, что они будут целенаправленно уделять время обучению и коучингу своих людей. Это та работа, которая (по моим личным ощущениям) даёт огромный профит с точки зрения человеческих ресурсов: сотрудники получают положительное внимание и растут.
🟡Задача команды — поставить фичу клиенту. Фича — это единица ценной функциональности. Здесь речь уже о границе ответственности. В функционально разделённых организациях я многократно встречал ситуацию: бэкенд закончил свою часть, передал работу дальше и формально всё сделал правильно, только клиент ценности не получил. При этом за фичу целиком уже никто не отвечает.
⭐️ Мои впечатления
Недавно в комментариях была просьба написать пост о книгах, на которые было зря потрачено время. Пожалуй, этой книгой можно открыть список.
В книге смешались в кучу кони, люди, Дао Тойота, ТОС, теория массового обслуживания и ещё невесть что. При чтении книга показалась мне несвязной и слабо структурированной. К счастью, навыки предварительного анализа и скимминга сэкономили мне кучу времени.
Проблема не в самих темах. Они реально полезны при работе с большой организацией. Проблема в том, что авторы постоянно прыгают между моделями мышления, оргдизайном, метриками и отдельными практиками, но не собирают их в последовательный ответ на вопрос «что делать завтра». Как руководство по внедрению LeSS книга для меня не сработала.
Не повторяйте моих ошибок. Если вам вдруг нужно внедрить LeSS (или вы просто хотите познакомиться с ним) — вот два замечательных ресурса:
➡️ LeSS Brochure — краткое, но ёмкое и наглядное описание LeSS в 8 страниц.
➡️ LeSS Rules — буквально шпаргалка по LeSS.
Если нужно быстро познакомиться с LeSS или освежить его устройство, книгу можно спокойно пропустить. Пригодиться она может тем, кто уже знает основы LeSS и хочет покопаться в лежащих под ним моделях мышления. Но как точку входа я её не рекомендую.
Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.
➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным.
➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog
Как я возвращаю паузы, которые у меня отнял ИИ
Недавно я писал, что ИИ убрал из моей работы передышки. Тогда я только описал проблему, а теперь придумал простое правило, которое помогает мне не сдыхать. Я стараюсь убирать руки от компа, как только запустил задачу в ИИ. Вместо «ещё одной задачи» я предпочитаю встать и размяться (и даже подумываю купить себе гирю).
Ожидание ответа агента ощущается как «свободное время, которое можно потратить на продуктивную эффективность». Руки сами тянутся открыть ещё одну вкладку и запустить там чего-нибудь поработать, не теряя ни секунды. Такая работа ощущается очень эффективной: ИИ жжёт токены, вкалывает человек.
При таком режиме работы можно сделать больше за небольшой промежуток времени. Но силы начинают уходить как будто в чёрную дыру. По ощущениям это напоминает бег: можно сильно разогнаться на старте, но долго в таком темпе не побегаешь.
Я решил привязать новое поведение к уже существующему (спасибо книжке «Атомные привычки»). Поэтому при запуске чего-либо в генерацию агента я физически убираю руки от компа и встаю размяться. Задача этого правила — не выжать побольше из каждой минуты времени, а сохранить рабочее состояние на протяжении дня (и недели).
В эти минуты я просто встаю из-за компа: разминаюсь, делаю пяток бёрпи, жмякаю кота или приседаю с дочкой на руках. Теперь вот думаю купить гирю — махи хорошо подходят для такой короткой паузы.
Это не универсальная методика, а моё правило под мой режим работы. Оно помогает не путать занятость каждой отдельной минуты с нормальной продуктивностью на дистанции.
ИИ должен экономить мои силы, а не помогать мне эффективнее их сжечь.
// А вы сразу запускаете нового агента или используете это время как паузу?
Почему не все интересные идеи влияют на жизнь
Я люблю читать книги.
В детстве меня поглощали миры и ситуации, придуманные талантливыми авторами. В более взрослом возрасте я плотно подсел на «нон-фикшн»: меня восхищали новые, яркие идеи, написанные умными людьми в разное время и в разных частях нашей планеты.
Эти идеи дарили мне радость долгое время, однако в какой-то момент я заметил, что в мою жизнь они проникают не очень-то активно. Лишь некоторые книги дали такую пищу для размышлений, что я по-новому взглянул на мир. Идеи из этих книг глубоко проникли в мою голову и изменили мировоззрение.
Момент времени, в который я осознал это, стал переломным. Меня больше не радовали новые интересные идеи сами по себе, потому что найти их довольно просто (достаточно оглядеться вокруг и немного подумать). Предметом моего любопытства теперь стала трансформация мышления и мировоззрения через усвоение чужих идей.
Что такое «усвоенная идея»?
Прежде чем мы двинемся дальше, я бы хотел дать своё определение термину «усвоенная идея», поскольку дальше мы им будем оперировать постоянно.
Для меня «усвоенная идея» – это идея, которая настолько прочно встроилась в мою голову, мышление и систему ценностей, что начала влиять на моё поведение, решения и мировоззрение. По сути, это идея, ставшая частью меня самого.
Примером такой усвоенной идеи являются «толстые хвосты» из творчества Нассима Талеба. В своих книгах он часто говорит о нелинейной природе вероятности, а «толстыми хвостами» называет маловероятные события (находящиеся слева/справа на кривой нормального распределения) с аномально мощными последствиями. Переварив эту идею, я перестал смотреть на маловероятные события только с точки зрения вероятности их наступления и начал задумываться ещё и о рисках, которые они создают (въедливый читатель тут к месту упомянет «чёрных лебедей» и будет прав, но это эссе не о теории вероятности в жизни).
Усвоение этой идеи поменяло мой взгляд на применение теории вероятности в реальном мире, сделало его шире и богаче. Подобное изменение в мышлении напоминает фарш в мясорубке – его невозможно обернуть вспять. После усвоения идеи начинаешь видеть мир иначе раз и навсегда.
⭐️ Область усвоения идей
Я довольно долго экспериментировал с различными методиками усвоения идей. Я работал над техниками обработки информации, учился писать заметки (и даже практиковался в мини-эссе), применял различные мнемотехники и даже попробовал скорочтение, но толку было немного. Процесс усвоения идей по-прежнему оставался для меня окутанным мраком случайности и везения.
Тогда я задумался: а что же кардинально отличало те идеи, которые залетели мне в голову и крепко там засели? Ответ пришёл в виде книги Оливера Беркмана «Четыре тысячи недель на всё», которая внезапно потрясла меня и дала возможность поискать ответ на вопрос выше. Ведь потрясение не на ровном месте произошло.
Крепко подумав над этой ситуацией, я пришёл к выводу, что книга Беркмана на самом деле попала в то напряжение, которое у меня в жизни уже было. Я долго страдал от ощущения, что я ничего не успеваю и во всём, что делаю, недостаточно хорош. Идеи Беркмана дали мне не готовое решение, но достойную пищу для размышлений, которая не отпускала меня несколько дней.
Из этой ситуации я вывел следующую гипотезу: усваиваются только те мысли и идеи, которые попадают в существующее напряжение в жизни. Этим напряжением может быть сильная личная потребность найти ответы, дискомфорт, боль, затруднение, недопонимание. Но главная отличительная черта напряжения – высокая степень личной значимости.
В первую очередь мы усваиваем идеи в областях, которые нам сильно небезразличны. Однако это не гарантирует, что идея усвоится. Но о поиске идей с сильным потенциалом усвоения – в следующем эссе.
// Неплохо я развлекаюсь на выходных, да? :)
Итоги курса «Руководитель отдела»
Вот и подошли к концу 4 месяца интенсивного обучения на курсе Стратоплана «Руководитель отдела». Этим постом я хочу подвести итоги обучения.
На курс я шёл, потому что чувствовал потребность в фундаментальном и системном обучении менеджменту. С ростом масштаба моих задач становилось всё больше вопросов и всё меньше готовых ответов.
Курс оказался для меня полезным, однако его главная ценность для меня была не в количестве новой информации. Раз за разом на лекциях я с удивлением обнаруживал, что всё делал правильно, но скорее интуитивно. Курс помог мне дать имена этим подходам, разложить их по полочкам в голове и понять границы их применения.
Обнаружились и области, где моего набора инструментов было недостаточно. Я узнал много нового об управлении изменениями, работе с финансами, реализации инженерной стратегии и масштабном people-менеджменте.
⭐️ Три самых сильных инсайта, которые я вытащил из обучения
➡️ Осознанность сильнее интуиции. Когда понимаешь, почему инструмент работает, его легче применять, передавать другим и замечать ситуации, в которых он не подходит.
➡️ Теория без практики не имеет ценности. Я об этом давно пишу, и обучение лишь подтвердило мой взгляд на вещи. Максимум пользы давали кейсы, групповая работа и попытки применить инструменты на свои задачи.
➡️ С ростом масштаба меняются сами инструменты управления. То, что работает для команды или небольшого числа людей, начинает ломаться на уровне отдела. Например, регулярные 1-1 уже нельзя считать всей системой people-менеджмента.
Самая сильная сторона курса — это постоянная плотная практика на управленческих кейсах и большое количество групповой работы. Но к концу курса из-за этой плотности и высокой нагрузки я ощутимо устал. Но зато я чувствую, что реально потыкал новые инструменты (а что-то сразу утаскивал в работу).
Есть у курса и недостатки. Во-первых, восприятие материала сильно зависит от преподавателя (например, я не люблю излишне многословных людей, а кому-то, наоборот, только такие и нужны). Во-вторых, AI-вставки были очень базовыми для моего уровня и оказались скорее бесполезными в большинстве своём. Но это мелочи на общем фоне.
По моим ощущениям, курс подойдёт, если у вас уже реально есть подходящие управленческие задачи. Материал рассчитан на цикл «понять — попробовать — применить в работе» и не годится для накопления информации «на вырост».
Это было интересное приключение. А теперь нужно передохнуть, разобрать накопленное и продолжать применять то, что я утащил с обучения.
«Не знаю» больше не значит «не могу»
С развитием LLM-ок фраза «я не знаю» перестала означать «я не могу это сделать». Благодаря бездушной железяке я могу спокойно зайти в плохо знакомую (или даже совсем незнакомую) область и начать в ней действовать, даже не имея глубокой экспертизы (но только до границы, за которой я уже не способен проверить результат).
Раньше это было намного сложнее. Чтобы сделать что-то для себя новое, мне приходилось читать доки или форумы, смотреть видосы, пытаться повторить, ошибаться, материться и не понимать, что происходит. Либо же приходилось искать того, кто знает. Теперь я могу разбирать с агентом конкретную задачу и получать достаточно контекста для следующего шага, не погружаясь предварительно во всю область.
Например, я всегда плохо знал Bash: пользовался им редко, каждый раз погружался заново, поэтому даже простой скрипт мог занимать несколько часов. Теперь же я простые баш-скрипты спокойно пишу агентом, а моих базовых знаний вполне хватает для их валидации. Благодаря этому я перестал прокрастинировать многие задачи на автоматизацию. Например, я наконец-то поигрался с DevEx на пет-проекте и теперь у меня нормально запускаются интеграционные тесты в монорепе с микросервисами (а раньше я это прокрастинировал, потому что "опять в баш лезть").
Этот пример не делает меня универсальным специалистом, а показывает, насколько дешевле стало осваивать соседние инструменты. Также человек всё ещё должен поставить задачу, заметить чушь, проверить корректность результата и принять за него ответственность. Я могу делегировать агенту Bash, потому что моих знаний хватает понять, делает ли скрипт то, что нужно, и не снесёт ли он полсистемы. Если я не способен проверить результат, «я не знаю» снова становится проблемой.
Конечно, глубоко заменить все соседние профессии один человек не сможет. Реальный рычаг ИИ гораздо скромнее (и важнее): Т-шейпиться теперь стало гораздо проще. Агенты помогают выходить за рамки своей специализации, но фундаментом специалистпо по-прежнему остаётся глубокая компетенция в своей области.
// Какую незнакомую задачу вы уже готовы отдать агенту, а какую не возьмёте, потому что не сможете проверить результат?
Из находки ИИ-радаров вырос лонгрид для Хабра
В понедельник оба моих ИИ-радара зацепились за одну гипотезу: агенты ускоряют написание кода быстрее, а проверка и выпуск начинают отставать. Я пошёл её проверять и вместо короткого продолжения написал полноценный лонгрид для Хабра.
Самую интересную цифру я вынес в заголовок: агенты дали оценённый рост коммитов до 240%, проектов до 80%, релизов только до 30%. Это не прямая конверсия коммитов в релизы, но разрыв хорошо показывает проблему: агенты ускоряют написание кода гораздо сильнее, чем выпуск изменений, и новое узкое место возникает во всём остальном SDLC. Код писать стало дешевле, но ревью, тестирование, архитектурный контроль и релизы не ускорились вслед за клепанием коммитов.
После исследования я стал увереннее в исходной гипотезе. Когда команда переходит от личного помощника к нескольким автономным агентам, важнее становится качество системы вокруг модели — спецификации, общий контекст, ограничения, автоматические проверки, история решений и обратная связь после релиза.
В лонгриде разбираю, где застревает поток AI-кода, какую обвязку уже строят LinkedIn и Atlassian и какими метриками искать новое ограничение. Приглашаю вас почитать и поддержать мою работу ❤️
Приятного чтения!
➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog
Два ИИ-радара для наблюдения за IT-индустрией
Не следить за IT-индустрией я не могу, потому что новинки могут повлиять на мои решения. Следить за всем тоже не могу, потому что петабайты контента выжирают все силы и внимание. Поэтому часть этой работы я решил отдать ИИ.
Раньше я писал, что новинки стоит замечать рано, а внедрять лишь после того, как спадёт первый хайп. Теперь я автоматизировал первую половину этого процесса.
Сначала я собрал один еженедельный дайджест, но он то ничего интересного не находил, то притаскивал пачку пустых новостей.
Подумав, я осознал, что смешал две задачи:
➡️ искать изменения, уже созревшие и способные повлиять на мри решения
➡️ ловить ранние сигналы того, что может изменить практику через 6–12 месяцев
Поэтому теперь у меня два радара.
➡️ «Значимые изменения» ищет доказанное «Было → стало» и приносит максимум три результата.
➡️ «Ранние сигналы» собирает проверяемые гипотезы и оценивает их потенциальное влияние.
Оба радара помнят контекст предыдущих выпусков и не повторяются. Сами промпты приложил к посту (сорри что одним файлом, но телега иначе не умеет).
Выход этих промптов мне уже нравится. Например, на этой неделе оба радара зацепились за agentic development (и разница между ними хорошо видна):
➡️ Значимое изменение: агенты превращаются в управляемую часть SDLC. Исследование NBER показывает, что ускорение написания кода вскрывает ограничения на остальных этапах, а другое исследование — что работа разработчика смещается к направлению и проверке AI. Появляются и инструменты управления этим процессом — например, governed agent loops от Atlassian. Для меня это означает, что пора подзабить на скорость написания кода и сосредоточиться на инфраструктуре агентной разработки.
➡️ Ранний сигнал: проверка становится её главным ботлнеком. Генерация дешевеет, но review, тестирование, контроль безопасности и архитектуры масштабируются хуже. Гипотеза радара: через 6–18 месяцев команды будут отличаться не моделью, а качеством своего harness (спецификаций, проверок и ограничений). Эта мысль совпадает с тем, что мне принёс радар значимых изменений.
Конечно, LLM может что-то пропустить. Но прочитать весь поток самостоятельно я всё равно не смогу (и не хочу). Настройка заняла у меня несколько недель, зато теперь два выпуска отнимают 30–40 минут в неделю и оставляют время поразмыслить над найденным.
// Подумываю разбирать самые интересные находки радаров и рассматривать потенциальные перемены в инженерных и управленческих решениях. Стали бы читать такие разборы?
