☝🏻☝🏻☝🏻

Как же хорошо сказано, Артём как боженька молвил.

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

Эпитафия сеньорам

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

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

Но пришла новая школа, новый уклад. Пришли великие агенты и AI. Ты смотришь на это, и тебе кажется, что это порождение нейрослопа для школьников, которые теперь могут писать B2B SaaS за три дня, а твои навыки незыблемы, и тебе эти AI-помогаторы не нужны

Так вот, дорогой друг, у тебя теперь два стула. Выбирай любой.

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

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

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

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

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

Да и в целом ты сможешь, заперевшись в темной комнате, обложившись десятью вкладками Claude Code, за неделю дня сделать работу, которую в прошлом мире делала бы команда из пяти человек целый месяц.

И с такими знаниями и умениями ты с уровня Архангела Гавриила превознесешься до архитектора Матрицы.

———
Все совпадения случайны. Не принимайте близко к сердцу

Эпитафия касается не только сеньоров, а спецов на любых уровнях. Мастерство с AI-агентами кратно ускоряет ваши возможности и потенциал, мультиплицирует их.

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

Так что качайте базу и качайте мастерство AI инструментов.

———
P.P.S: забыл один важный момент. Текущим сеньорам в среднем по 30-40 лет. И в этом возрасте частенько наступает нежелание разбираться в чем-то большом и новом, похожее на то, как миллениалам после инстаграмма было влом понимать фишку Snapchat.

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

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

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

#мнение
Какие проджекты сейчас не нужны

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

Я полагаю ты заметил как попритихли чаты, группы, конференции и образование. Рынок перестал покупать не проектное управление как таковое, а harness management. Давай разберемся, кто именно попадает в зону риска

1. Проджект-администратор

Ведет Jira. Собирает статусы. Двигает карточки. Напоминает про дедлайны. Пишет отчеты. Организует созвоны. Раньше это выглядело как полноценная работа - процесс был тяжелым, контекст размазан по головам, автоматизации минимум. Сейчас это всё чаще выглядит как дорогая операционная обвязка, которую либо автоматизируют, либо распределяют внутри команды. Человек-напоминалка с зарплатой мидла


2. Проджект-прокси

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

3. Ритуальный agile-проджект

Да простят меня все agile/scrum/kanban/modern ManOps коучи. Умеет проводить дейли, ретро, планирование, груминг и ревью. Не умеет объяснить, зачем именно этот набор ритуалов нужен конкретной команде в конкретной ситуации. Спринты есть - значит, у нас скрам! Ретро проводим - значит, мы agile!

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

4. Непогруженный delivery manager

Отвечает за сроки и часто упоминает управление end-to-end и оптимизацию потока ценности, но не понимает инженерную реальность. Не может сам прочитать базовую документацию, глянуть MR, разобраться в логах, понять, где реально риск, а где команда просто плохо объяснила. Казалось бы, зачем ПМу лезть в инженерку??

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

Давление без понимания - самый токсичный вид менеджмента. И, к сожалению, самый распространенный в кровавом энтерпрайзе

5. Менеджер-маршрутизатор

На требования зовет аналитика. На архитектуру - техлида. На приоритеты - продакта. На конфликт - Head of. На сложное решение - CTO

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

Если единственный твой инструмент - позвать кого-то умнее, то зачем ты в цепочке?

6. General management без домена

Я умею управлять людьми и процессами - раньше звучало солидно. Сейчас звучит как: я всё и ничего

Рынок образования тоже это подтверждает. Классические MBA теряют часть привлекательности. Студенты уходят в прикладные треки - data, AI, finance, supply chain, domain-specific skills. В Китае вообще жестко: университеты массово режут устаревшие management-программы и добавляют технологические

Широта без глубины перестает продаваться. Рынку нужен T-shaped профиль: широкий кругозор + глубокая экспертиза в конкретном домене. Просто менеджер - это уже не профессия, это описание активности
- - -
P.S. Из всего этого не следует, что проджекты больше не нужны. Это слишком плоский вывод, и я его не делаю/ Скорее так: больше не нужен проджект как человек-обвязка

#иное
Митап Agentic Harness: что под капотом

9 июля проводим открытый митап про устройство AI-агентов и агентских систем. Будем разбирать не общие разговоры про «агенты скоро всё сделают», а практическую инженерную часть: как агент получает контекст, вызывает инструменты, работает с MCP, skills, hooks, memory и внешними сервисами.

Дата: 9 июля
Время: 18:30–21:15
Место: БЦ «Q», ул. Желтоксан, 191, зал Jailau
Формат: офлайн Алматы + онлайн трансляция
Регистрация: https://luma.com/48q2s0f5

Доклады:
Кастомизация агентских харнесов на примере Pi
Павел Королев — Android Tech Lead в QazCode
Поговорим о том, как настраивать агентскую систему под конкретные инженерные задачи: workflow, точки расширения, практические ограничения, и сравнение решений.

Контекстный движок CodeAlive и code exploration benchmark
Родион Мостовой — AI architect, co-founder CodeAlive.ai
Родион расскажет, как в CodeAlive устроен собственный агент и контекстный движок, как команда подходит к code exploration, что измеряет в бенче и как добивается сильных результатов на Qwen 3.6.

В чем настоящая ценность agent skills
Артем Летюшев — Tech Project Manager в twinby.com, гильдмастер AEG
Разберем, зачем нужны agent skills, чем они отличаются от обычных промптов и как становятся переиспользуемым слоем управления агентами.
- - -
Митап будет полезен AI-инженерам, LLM-инженерам, дата-сайентистам, вайбкодерам, техническим менеджерам и всем, кто уже собирает AI-инструменты в реальных проектах.

#мнение
Место менеджмента AI-native оргструктуре

Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний

Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает:

1. Экономика
AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения

2. Таланты и новые роли
AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения
Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности

3. Структура команд
Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы
Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца

4. Операционная модель
Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже

5. Управление и контекст
Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными

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