1. Перестать писать код*
*руками, те кто все еще продолжают писать код руками, не доверяя ИИ, заметно отстают, у компаний достаточно инструментов трекать все подряд, чтобы видеть кто “отстает”
И работать с бюджетными моделями знать когда вызывать Haiku (на чтение) а когда Sonnet (на написание), а когда и Opus (на планирование). Правило стабильности - Sonnet для всего, и не будет вопросов по бюджетам.
2. Выстроить ворклфлоу работы с ИИ
Который не будет делать ошибок, или сведет их к минимуму, проверяя работу до и после, это означает, что должны быть например созданы скилы с код-стилем команды, выстроены лимиты и ограничения (например для прода read only), подключены тулы через mcp, чтобы трекать настоящие метрики и логи и делать выводы какие-то
Метрики: PR Size & Review Turnaround (нужно уметь с ИИ дробить свою работу на несколько PR, просить убрать мусор, лаконично и читабельно, без комментариев, а то ИИ любит книгу написать в коде)
3.Развиваться в продуктовом мышлении и владении метриками
Просто что-то делать ради того чтобы сделать уже не надо, надо понимать зачем.
Важен outcome а не про output.
Выполнить задачу сделать красной кнопкой уже не достаточно, надо понимать на что это повлияет, например на какую то метрику (условно люди начнут чуть больше нажимать эту кнопку потому что она заметнее), а что это дает? это приносит в итоге сколько то денег?
Метрики: Conversion rate, drop-off, MRR/ARR, TTV, LTV, DAU/MAU, ARPU, Feature adoption rate, OKR, KR, Goals, User Acquisition и др.
4.T-shape повсюду, никаких бекенд фронтенд девопс и даже мобайл
Ожидания от программистов что они уже смогут сделать все что угодно end-to-end, и на бекенде, и на фронтенде, и инфрастуктуру серверную, и даже мобайл (пока еще нет, но скоро, проблема или ценность мобайла, что мобайл немного в другом мире живет чем бекенд/фронтенд/инфра). От мобайла ожидания что iOS разработчик начнет делать Android и наоборот, а в ближайшие годы возможно и бекенд с фронтенлом и инфраструктурой.
Метрики: Lead Time for Changes, Cycle Time, Bus Factor, Deployment Frequency и др
5. Быстрая реакция на инциденты/дебаг/траблшутинг
Искать root case, несколько часов уже непозволительная роскошь, на готове должны быть все скиллы, скрипты, подключены все mcp к логам, метрикам, базам данных на чтение. Чтобы за 5 минут увидеть проблемы которые только могут возникуть.
Метрики: SLI / SLO / SLA, Error Budget, Latency (p50, p95, p99), Availability (Uptime), MTTD и MTTR, Alert Actionability и др
6. Видимость работы и управление ожиданиями (Managing Up) ([пост](https://t.me/andreyposnov/3645))
Если ценность неочевидна для руководства, то в условиях оптимизации, “оптимизирует” того кто не заметен. Важно проактивно подсвечивать решенные проблемы или предлагать решение проблем (не просто ее подсвечивать), понимать риски/сроки зачем они и откуда берутся.
—-
Главное сменить фокус с написания кода, лучше подумать например о более глобальной оптимизации, например о потребление памяти во всех сервисах, приложениях, перестройки потоков и оптимизации данных или сложных миграций. Скорости работы, пропускной способности.
Не просто найти техническое решение, а упаковать его в прозрачный план действий и чек-лист, скилл, чтобы другие инженеры, смежные команды или ИИ-агенты могли автономно масштабировать этот результат на всю систему.
А потом сделать красивый Managing Up, как вы у себя в команде все оптимизировали, теперь расходы на систему снизились на 5-30%,или больше, и вы сделали еще скилл/план который может каждая команда/отдел применить.
—
Но такое конечно, не для всех разработчиков, те кто любили в тишине пописать код на механической клавиатуре спокойно попивая матэ/латтэ и другие напитки, скорее всего перейдут из такой потогонки в свои пет проекты или более спокойные профессии.
Потому что сейчас разработчик - это чтец и жнец и на дуде игрец, да еще и который понимает бизнес от А до Я со всеми бизнес метриками и тд __(спрашивается правда тогда а зачем таким крутым чувакам эти компании, если он сам все понимает + может построить круто/стабильно)__
#карьера
📸 Изображения
