cherkashin.dev

ИИ сейчас повсюду, я честно не знаю, как эти 20+ человек из опроса умудряются его избегать 😅

Но после появления ИИ меня волнуют несколько моментов.

1️⃣ Во-первых, ощущение, что контроль постепенно утекает из рук. Я прекрасно помню код, который писал сам, но достаточно быстро забываю большую часть того, что написал ИИ. С одной стороны, работать стало проще, а с другой — в конце дня чувствую себя как выжатый лимон.

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

3️⃣ Ещё часто слышу про Spec Driven Development. Я честно попробовал его у себя в пет-проекте. Заявления о том, что спека станет новым источником правды, звучат красиво. Вот только «гладко было на бумаге, да забыли про овраги». Попробуйте обновлять спеку на каждую правку, на каждую маленькую фичу. Но, возможно, я просто не умею всё это готовить.

На этой неделе начался новый сезон Подлодки, и каждую неделю будет новая тематика.
Следующая — неделя «Фронтенд с AI». Это будет, наверное, уже 4-й сезон, на который я пойду.

Из докладов щля себя пока выделил:
- AI Coding на дистанции: к концу дня голова ватная, а через месяц проект разваливается
- Мастер-класс «Spec Kit Driven Development»
- Демо-сессия «Beyond the diff»
- Демо-сессия «Нанейродизайнили. Что дальше?»

Обычно ходил только на фронтенд, но в этот раз решил, что за лето я достаточно отдохнул, поэтому ещё думаю сходить на AI Crew и Teamlead Crew.
Так что следующие три недели постараюсь рассказывать, чего интересного было на конфах. Если вывезу 🤷‍♂️
Ну и надеюсь, кто-то из вас сможет составить мне компанию на каждой из них.

📆 Неделя «Фронтенд с AI» — 5–9 октября
🔗 Программа и билеты: https://podlodka.io/fecrew
🏷 Промокод на скидку: cherkashindev

А вы пойдёте на Подлодку?
👍 — Пойду
👀 — Пока думаю
👏 — Давай билет

Когда клод нагенерил пул реквестов и приходит время делать ревью

Код ревью в эпоху ИИ

Ещё одна мысль после конференций — код ревью придётся делать иначе.

Когда количество PR увеличивается, человек становится ещё большим бутылочным горлышком. Никто не в состоянии внимательно вычитывать каждую строчку.

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

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

И, возможно, вообще не все ПРы нужно ревьюить.

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

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

Но полностью отменять код ревью пока рано. Оно нужно не только новичкам, но и для шеринга знаний. Даже сеньоров стоит ревьюить: иначе критичный контекст может остаться в одной голове, а bus factor станет слишком маленьким.

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

Ещё появляется неприятный антипаттерн: коллега вместо ревью полностью отдаёт PR ИИ-агенту, не валидирует его замечания — и в пулл реквесте появляется куча нейрослопа. Не надо так 😬.

А как вы делаете ревью?
👍 — проверяю каждый пул реквест сам
🔥 — одновременно делаю ревью сам и прошу сделать ревью агента
👀 — отдал полностью агентам, пусть сами занимаются этой фигнёй

#ai #processes #codereview

Наболело ....

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

1️⃣ Управление контекстом

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

Значит, контекст нужно собирать в одном месте:
- либо переносить всё в Markdown;
- либо настраивать интеграции через MCP со всеми возможными системами.

Перед работой над задачей я иногда запускаю поиск по имейлам или перепискам в Teams, чтобы собрать дополнительный контекст. Сюда же мой прошлый пост про выгрузку всех созвонов. Требования можно хранить прямо в репозитории или дать ИИ доступ через MCP к Jira, Confluence и другим системам.

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

2️⃣ Знания остаются в головах

Собирать контекст в одном месте — хорошо, но MCP для доступа к нашему мозгу, к счастью, ещё не придумали 🧠

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

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

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

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

3️⃣ Не всех нужно пересаживать на Git

Когда мы говорим, что весь контекст должен храниться в одном месте, хочется сразу дать всем Git и заставить писать Markdown. И мне кажется, это неплохая идея.

Но в Яндексе был отдельный доклад про то, что для базы знаний нужна прослойка, чтобы не обучать всех Markdown и Git. Продакты должны писать требования в удобной для них среде.

Интересная фраза из доклада:

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

Кажется, эту проблему должен закрыть docs as code, но я пока не изучал этот вопрос. А вообще ещё нужен автоматический аудит, чтобы требования не устаревали относительно кода.

В следующем посте поговорим о том, как ИИ меняет code review

А у вас в компании как с контекстом для ИИ?
🔥 — активно передаём контекст ИИ
👀 — худо бедно, что-то делаем
🤷‍♂️ — пытаюсь быть незаменимым

#ai #processes

Время продуктовых инженеров

Я последнюю неделю провёл в Москве и посетил Deep Tech Night и TeamLead Today.
И, честно говоря, в ИТ всё так быстро меняется, что немного не по себе.

После Deep Tech Night поговорил с разработчиками, и мне начало казаться, что нас очень скоро совсем заменят. Но потом вернулся на работу, открыл рабочие задачи, понял, что мы ещё не дошли до этого, и немного успокоился 😅.
Но как ни крути, если так и дальше будет продолжаться, то роль разработчиков изменится. Уже меняется.

1️⃣ Теперь недостаточно быть просто бекендером или фронтендером

Фронтендеров отправляют изучать бекенд, а бекендеров — фронтенд, чтобы человек мог сам закрывать всю фичу.
И в целом роли будут схлопываться.
Ценность самого кода сильно упала. Разработчики должны решать проблемы, а не просто писать код.
Кажется, так было и раньше, но теперь сложить лапки и сказать «моё дело таски делать» уже не особо прокатит.

2️⃣ Вместо того чтобы бесконечно уточнять требования, люди генерят прототипы

Если вы читали «Совершенный код», там говорится что-то вроде:

Если на этапе требований была допущена ошибка, то её исправление на этапе разработки будет стоить дороже.

Так вот, теперь эта ситуация немного меняется.

Знаете ситуацию: кто-то приходит и говорит «хочу реализовать вот такую штуку», а ты просто генерируешь прототип и спрашиваешь:
«Если вот так будет выглядеть — подойдёт?»

Мы в команде тоже решили идти в эту сторону. Как бонус во время прототипа понимаем, с какими проблемами столкнёмся при реализации.

3️⃣ Команды дробятся на микрокоманды

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

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

А помните, нам обещали, что ИИ избавит нас от рутины?

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

Код теперь и Claude с Codex пишут неплохо, особенно если есть чёткие требования. А решение задач в таком случае превращается просто в копирование постановки задачи в чат.

И ещё один момент, который мы там обсуждали.

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

Сами себе копаем яму.

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

А вы как считаете:
🔥 — лучше копать яму
👀 — давайте плыть по течению и продлевать прайм-эру программистов
🤷‍♂️ — сейчас токены подорожают и всё откатится

#ai #processes

Похоже, пора подтюнить инструкции для агентов. Читать планы Claude и Codex иногда просто невозможно, особенно если работаешь с незнакомым кодом...
План на 5 страницы — изменений 20 строчек.

А вам тоже проще прочитать сам код, чем 5 страниц плана, который написал агент?

- 👍 — проще читать код
- 🔥 — проще читать план
- ❤️ — у меня всё норм, я подтюнил CLAUDE.md / AGENTS.md

P.S поделитесь формулировкой, как вы подтюнили это у себя 🙏

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

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

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

Перед первым посещением ещё успел завалить вопросами их поддержку.

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

В первый день я там и сидел — по кайфу вайбкодил с видом на город.

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

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

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

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

А вы где обычно работаете?

• 👀 — в основном дома
• 👍 — в основном в офисе
• 🧑‍💻 — в кофейнях/коворкингах

Obsidian как vim, можно настраивать бесконечно.

Меня всегда бесил outline в правой панели, он постоянно пропадает. И мне не хватало того, как он реализован в Notion. Загуглил и нашел, что есть прекрасный плагин Floating Headings.

Просто наводишь на полосы в правой части и на ховер появляется оглавление — красота.

А ещё нашел, что можно беклинки, также можно перенести прямо на страницу.

Идёте Settings => Core plugins => Backlinks.

👍 — полезно
👀 — не пользуюсь obsidian

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

Ну хоть кто-нибудь описал бы конкретно по шагам, как они это настроили. Если у вас есть годные статьи — присылайте.

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

Но сегодня не об этом. Расскажу о конкретном примере использования ИИ.

1️⃣ Неделю назад решил выкачать все транскрипты созвонов с продактами, с командой — в общем, всё, что записывалось.
Попросил Клода, тот пошёл через MCP в Teams и Fathom, выкачал все транскрипты, для каждого создал отдельный Markdown, добавил саммари и всё сложил в Obsidian в папку Meetings.
Так вот, сегодня это пригодилось.

Приходит ко мне разработчик и спрашивает: а как вот тут должно работать? А я помню, что мы вроде обсуждали этот момент с ПМом, но что именно — не помню.

Пошёл, спросил у Клода. Тот порылся в записях и выплюнул мне ответ.

Кажется, что так вообще можно было бы упростить все обсуждения фич. Загнать ПМов писать маркдауны, настроить автоматизации и рядом складывать записи всех созвонов, чтобы ничего не потерять.
Кто-то уже такое сделал?

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

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

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

А помните, раньше кто-то что-то говорил на митинге, а потом утверждал: «Да не было такого, я такого не говорил»?
Так вот, всё, больше такое не прокатит...

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

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

#ai

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

Но в Сетке запустили челлендж «Оставайтесь в профессиональной форме» про привычки, которые помогают расти в профессии. Поэтому решил рассказать, что помогает мне расти в профессиональном плане — метод текущей инициативы. Узнал о нём лет 5 или 6 назад.

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

Это может быть архитектура, project management, какая-нибудь новая технология — в общем, что угодно, что сейчас важно для моего роста. Например, последний год моей текущей инициативой были нейросети.

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

А прямо сейчас я, кстати, отдыхаю от текущих инициатив. Потому что иногда лучшая привычка для профессионального роста — на некоторое время перестать пытаться профессионально расти :)

📝 А вот мой пост в Сетке
👉 А тут можно посмотреть, какие привычки у других трудяг.

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

Расскажите, а вы есть в Сетке?
- 👍 — да
- 👀 — слышал
- 👎 — нет

#timemanagement #setka

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

Последний — мой любимый.

#about_me

Робот меня заменил — ну и отлично ...

Я про робот-пылесос, а вы о чём подумали?

Ремонт движется, мы наконец-то съехали со съёмной квартиры и вернулись к себе. Теперь снова можно делегировать уборку 😄