Про AI.

В четверг был на конференции Yandex: Team Lead Go. В целом это было больше про нетворкинг, но был и один доклад о применении AI в мобильной разработке в Yandex Go. Со слов докладчика, у них уже сейчас используются AI‑агенты, которые парсят макеты в Figma и на их основе генерируют экраны мобильного приложения из коробки. Разработчик все еще нужен, чтобы провести ревью этого кода и самостоятельно добавить анимации. Со стороны это все выглядит невероятно.

Этой осенью на всех конференциях звучали доклады про AI. Автокомплит, рефакторинг, генерация тестов, code review, поиск уязвимостей, обнаружение неоптимального кода вроде n+1 - все это уже воспринимается как норма, а не как фантастика из будущего. При этом утверждается, что это все в помощь разработчику, чтобы быть эффективнее и быстрее перформить. Так ли это? Не знаю. Как будто тут есть доля лукавства. Точно понятно, что страдают джуны, которые сейчас никому не нужны, а senior-инженеры как были, так и остаются востребованы.

Время MVP прошло?

Мой опыт продуктовой разработки в любой роли в любой компании до ЗЯ строился на подходе "собрать быстрое MVP из говна и палок, запуститься, проверить гипотезу, а потом, если взлетит делать нормально". Логика простая, зачем тратить время и ресурсы на качество, если можно кое-как, но зато быстро. Но, кажется, время MVP прошло.

У меня нет на руках исследований или статистики, есть сугубо личное субъективное мнение. Рынок и мы сами, как пользователи цифровых продуктов, сильно изменились. Мы стали гораздо более требовательны к:
- визуальному качеству и целостности дизайна
- скорости и стабильности работы
- отсутствию навязчивой рекламы и "шумных" паттернов
- понятным онбордингам и прозрачной монетизации

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

В ЗЯ мы практически никогда не запускаем на клиентов MVP, в основном это всегда MLP, и это сложно. MLP тянет за собой более долгий discovery, а затем еще более долгий delivery-процесс. Хороший пример - новая программа лояльности.

Про интервью управленческого опыта.

Собрал себе гайд на основе доклада с этой конференции плюс дополнил своими мыслями. Гайд не претендует на истину в последней инстанции. Использовать строго через фильтр собственного здравого смысла и особенностей конкретной компании.

Общая структура интервью
- Формат: 5 секций, 70 минут суммарно, общая продолжительность интервью 90 минут
- Секции:
1) 🧑🏻👩 Управление людьми и командами - примерно 30 минут
2) 🔄 Управление процессами - примерно 10 минут
3) 🎯 Целеполагание - примерно 10 минут
4) 🔀 Внедрение изменений - примерно 10 минут
5) 🤑 Бизнес-экспертиза - примерно 10 минут

🧑🏻👩 Секция 1: Управление людьми и командами
Цель: понять подход к мотивации, развитию, найму/увольнению и дизайну команды.
Вопросы:
- Как ты работаешь с сотрудниками на регулярной основе? Какие практики используешь для поддержания мотивации?
- Как ты развиваешь людей и команду? Как оцениваешь прогресс и сравниваешь результаты между сотрудниками?
- Как принимаешь решения о найме? Кого и в каких ролях нанимал? Как и в каких случаях принимал решения об увольнении?
- Как проектируешь структуру команды и планируешь её рост/изменения?
Кейс-вопрос:
- Приведи конкретный пример: рост сотрудника, найм или увольнение. Какую роль ты в этом играл, как принимал решения, какой был результат?

🔄 Секция 2: Управление процессами
Цель: оценить подход к метрикам процессов, приоритетам качества и скорости, изменениям критичных процессов.
Вопросы:
- Как ты оцениваешь работу своей команды? Какие критерии и метрики используешь?
- Где твой приоритет в типичных дилеммах: качество vs скорость? Как принимаешь компромиссные решения?
- Есть ли у тебя опыт изменений критичных процессов? Как ты это делал?
- Что для тебя важнее — процесс или результат, и почему?
Кейс-вопрос:
- Приведи пример процесса, который тебе нравится или не нравится.

🎯 Секция 3: Целеполагание
Цель: понять горизонты планирования, метод постановки целей и механизм их достижения.
Вопросы:
- На какой горизонт ты планируешь и почему? Как выбираешь уровень детализации?
- Как ты ставишь цели себе и команде? Как обеспечиваешь достижение?
- Ты ожидаешь цели сверху или формируешь их самостоятельно?
- Как выстраиваешь операционный процесс под выбранные цели?
- Как переводишь абстрактные цели в измеримые планы и метрики?
Кейс-вопрос:
- Приведи пример конкретной цели и расскажи, как ты её достигал: план, трекинг, корректировки, результат.

🔀 Секция 4: Внедрение изменений
Цель: оценить подход к “приятным” и “болезненным” изменениям, управлению сопротивлением.
Вопросы:
- Как ты внедряешь изменения, которые команда воспринимает позитивно?
- Как ты внедряешь болезненные, но необходимые изменения? Как снижаешь сопротивление и риски?
Кейс-вопрос:
- Приведи пример неприятных для команды изменений, которые ты внедрял: контекст, план, коммуникации, результат. Если такого опыта не было — как бы ты подошёл к подобной ситуации?

🤑 Секция 5: Бизнес-экспертиза
Цель: понять, как кандидат видит вклад команды в бизнес, работает с метриками и влияет на них.
Вопросы:
- Как ты понимаешь роль и вклад своей команды в контексте бизнеса компании?
- Какие ключевые метрики у твоей команды? Как ты влияешь на них и на бизнес-результат?
Кейс-вопрос:
- Приведи пример конкретной бизнес-метрики и объясни, как твои действия повлияли на неё: гипотеза, действия, измерение эффекта.

По итогам каждой секции ставится 🟢,🟡 или 🔴 флаг. На основе количества флагов по цветам принимается решение о найме.

Лучший кейс по внедрению ИИ

(Взято из интернета)

В прошлом квартале я внедрил Microsoft Copilot для 4 000 сотрудников.

$30 за один аккаунт в месяц.

$1,4 миллиона в год.

Я назвал это «цифровой трансформацией».

Совету директоров понравилась эта формулировка.

Они утвердили всё за одиннадцать минут.

Никто не спросил, что именно он будет делать.

Включая меня.

Я сказал всем, что это даст «рост продуктивности в 10 раз».

Это не реальная цифра.

Но звучит как реальная.

HR спросили, как мы будем измерять эти 10х.

Я ответил, что мы «задействуем аналитические дашборды».

Они перестали задавать вопросы.

Через три месяца я посмотрел отчёты по использованию.

47 человек открывали Copilot.

12 использовали его больше одного раза.

Одним из них был я.

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

Это заняло 45 секунд.

Плюс время на исправление галлюцинаций.

Но я назвал это «успешным тестом».

Успех означает, что пилот не провалился явно.

Финансовый директор спросил про ROI.

Я показал ему график.

График шёл вверх и вправо.

График измерял «AI-адптацию».

Я выдумал эту метрику.

Он одобрительно кивнул.

Теперь мы «AI-ориентированная компания».

Я не знаю, что это значит.

Но это есть в презентации для инвесторов.

Старший разработчик спросил, почему мы не использовали Claude или ChatGPT.

Я сказал, что нам нужна «корпоративная безопасность».

Он спросил, что это значит.

Я ответил: «комплаенс».

Он спросил — какой именно комплаенс.

Я сказал: «весь».

Он посмотрел скептически.

Я назначил ему «разговор о карьерном развитии».

Он перестал задавать вопросы.

Microsoft прислала команду для анализа кейса.

Они хотели представить нас как историю успеха.

Я сказал им, что мы «сэкономили 40 000 часов».

Я посчитал это, умножив число сотрудников на число, которое выдумал.

Они не стали проверять.

Они никогда не проверяют.

Теперь мы на сайте Microsoft.

«Глобальная корпорация добилась прироста продуктивности на 40 000 часов с Copilot».

CEO выложил это в LinkedIn.

Он получил 3 000 лайков.

Он никогда не пользовался Copilot.

Никто из топ-менеджеров тоже.

У нас есть налоговая льгота.

«Стратегический фокус требует минимального цифрового отвлечения».

Я написал эту политику.

Лицензии продлеваются в следующем месяце.

Я запрашиваю расширение.

Ещё 5 000 лицензий.

Мы не использовали первые 4 000.

Но в этот раз мы «простимулируем внедрение».

Внедрение означает обязательное обучение.

Обучение — это 45-минутный вебинар, который никто не смотрит.

Но прохождение будет отслеживаться.

Прохождение — это метрика.

Метрики идут в дашборды.

Дашборды идут в презентации для совета директоров.

А презентации для совета директоров дают мне повышение.

К третьему кварталу я стану старшим вице-президентом.

Я всё ещё не знаю, что именно делает Copilot.

Но я знаю, зачем он нужен.

Он нужен, чтобы показать, что мы «инвестируем в ИИ».

Инвестиции — это траты.

Траты — это приверженность.

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

А будущее — это то, каким я скажу ему быть.

Главное, чтобы график шёл вверх и вправо.

Телеграм канал HR-аналитики

Про планирование бюджета.

Открыл для себя интересный способ планировать бюджет через AI. Суть в том, чтобы через n итераций добиться от AI некого HTML-шаблона, который позволит как-то визуализировать бюджет на команды/отделы/людей с учётом индексации, найма новых ставок, переработок и т. д. и т. п. Всё это, конечно же, можно сделать в Excel, но для этого надо иметь по нему "чёрный пояс".

Само собой, никакие реальные данные в самого AI-агента мы не передаём, т. е. просим от него лишь сгенерировать сам HTML-шаблон (инструмент) на выдуманном примере данных про условных кошечек и собачек. Мой промпт выглядит так, пользуйтесь👇

У меня есть вот такой пример данных. 
;Сотрудник;Команда;Должность;Грейд;Доход net
<сюда вставьте строка за строкой пример выдуманных данных, чтобы AI понимал, что вы будете загружать потом в шаблон>

Ты можешь мне помочь с планированием ФОТ бюджета департамента разработки? Мне надо, чтобы ты дал мне какой-то шаблон в виде HTML‑страницы, куда я могу загрузить данные уже локально у себя на компьютере. 

Мои требования к шаблону:  
- хочу иметь возможность делать разные фильтрации по всем полям, в полях "Сотрудник", "Команда", "Должность", "Грейд" хочу иметь возможность выбрать несколько вариантов, т.е. иметь мультивыбор. При этом можно выбрать как всех, так и не выбрать никого. В фильтрах также должен быть доступ поиск по подстроке. 
- хочу иметь возможность заложить индексацию, чтобы увидеть, как вырастет ФОТ с её учётом  
- хочу иметь возможность заложить какое-то количество новых ставок, чтобы увидеть, как вырастет ФОТ с ними  
- хочу иметь возможность заложить количество дней, которые сотрудники будут перерабатывать, с указанием средней стоимости 1 часа переработки  
- хочу иметь возможность заложить возможность выбрать % налогов, которые компания выплачивает государству от совокупного дохода сотрудника  
- в общей таблице, где будет показываться список сотрудников, я хочу видеть, кроме полей "Сотрудник", "Команда", "Должность", "Грейд", "Доход net", ещё новые поля. Это "Доход gross", "Доход net (с индексацией)", "Доход gross (с индексацией)", "ФОТ сотрудника", "ФОТ сотрудника (с индексацией)"
- видеть общие графики по значениям для выбранных сотрудников в фильтрах: "Доход net", "Доход gross", "ФОТ", "Доход net (с индексацией)", "Доход gross (с индексацией)", "ФОТ (с индексацией)"

Визуально раздели шаблон на части. Визуально части должны идти одна за одной в шаблоне сверху вниз.
- Загрузка файла с данными.  
- Параметры расчёта - налоги. Пусть там будет: "% НДФЛ", "% совокупная налоговая и страховая нагрузка на ФОТ".  
- Параметры расчёта - индексация. Пусть там будет: "% индексации". 
- Параметры расчёта - новые ставки. Пусть там будет: "количество ставок" и "Средний доход net для 1 новой ставки". 
- Параметры расчёта - переработки. Пусть там будет: "общее количество переработок в часах", "средняя стоимость переработки за 1 час (доход net)".  
- Общая сводка ФОТ без индексации. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с переработками. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с новыми ставками. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с индексацией.  Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с индексацией, переработками и новыми ставками. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Графики ФОТ. Пусть там будут как общие значения "net", "gross" и "ФОТ на сотрудника". Аналогично по подзразделениями. 
- Таблица сотрудников.

"ФОТ на сотрудника" - это сумма сколько компания тратит всего денег на сотрудника чтобы заплатить ему ЗП и все налоговые и страховые выплаты. 

Сделай данный шаблон HTML в палитре цветов светло‑синей, а не чёрно‑белой. Пусть шаблон будет достаточно компактный, чтобы не приходилось много скролить вверх вниз.

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

Про клиентские метрики.

В рамках backend-разработки клиентские метрики - это метрики запросов из сервиса А в сервис Б, когда со стороны сервиса А измеряются RPS, latency, error rate и тд и тп по всем вашим интеграциям как с внутренними сервисами/системами компании, так и с внешними, с которыми вы, например, взаимодействуете по интернету.

Для внешних интеграций это актуально по множеству причин, начиная с банального, что нельзя слепо доверять тому, что вам говорят ваши партнёры, и заканчивая тем, что между вами могут быть firewall и прочие слои ИБ-инструментов, которые точно будут влиять на скорость ответа между вами, при этом сам партнёр об этом может не знать. Он предоставит вам данные о метриках со своего сервиса «в кубе» или чуть-чуть выше, но о том, что где-то ещё сильно-сильно выше стоит какой-нибудь WAF, он может не подозревать. Актуально для IT-гигантов, где тысячи инженеров, сотни команд, десятки отделов и передача верной информации затруднительна из-за эффекта сломанного телефона.

Для внутренних интеграций, например, в случае взаимодействия внутри куба, это позволяет оценить "здоровье" вашей внутренней сети. Если между вами только внутренняя локальная сеть, то время на транспорт должно занимать не более условных 3-5 ms.

На скрине (latency 99p) я наложил "клиентские метрики", как сервис A видит запросы в сервис B, на "серверные метрики", которые собирает сам сервис B по этим же запросам c самого себя.

Жёваный крот! Щука, брат!

Можно ли ругаться матом на работе? Хочется сразу ответить категорически "нет", но на деле всё не так просто. Почему мы вообще ругаемся матом? В критических ситуациях только мат (к сожалению) может передать всю глубину и сложность проблемы и/или ситуации, с которой мы столкнулись.

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

Вариант 1
Коллеги, кажется, у нас что-то не так. Похоже, мы теряем выручку прямо сейчас. Я вижу проблему уже как минимум 30 минут, и меня это сильно беспокоит. Помогите, пожалуйста.

Вариант 2
Ёлки-палки, уже 30 минут ни черта не работает. Что за ерунда?

Вариант 3 (осторожно мат)
Какого хрена у нас сайт лежит? Где все?

1-й и 3-й варианты крайности, которые неуместны. 2-й вариант наверное, какая-то золотая середина, но он всё равно ни разу не передаёт всю глубину и проблематику ситуации. Что делать?

На эту тему был интересный доклад на крайнем Heisenbug 2025 - Матерюсь — значит, существую. Записи не нашел, видимо ее еще не выложили.

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

P.S.: я так и не понял, как правильно, "жеваный" или "жованый", вроде как "жеваный", но все мемасы через "о".

Как назвать?

В Магнит в 2021 году я разработал (возможно, откуда-то и скопировал, но уже не помню) свой паттерн именования каналов в корпоративном мессенджере. Тогда это был MS Teams, но это не столь важно. Знаю, что этот подход до сих пор используется в Магнит OMNI с некоторыми вариациями. В ЗЯ я его немного доработал, вот что в итоге получилось.

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

Всё базируется на префиксах team, tool, guild, release, support, proj, recruit и постфиксах qna, news.

Итак:
• team-<team_name>-<theme>, например team-main-qna, team-fs-news. qna - в данном случае это "приёмная" команды, куда может обратиться кто угодно с любым вопросом извне. news - это соответственно, канал новостей команды, которые команда может транслировать вовне, например о запуске какой-то крупной и важной фичи. Зачастую хватает только канала qna.
- guild-<guild_name>-<theme>, например guild-ios-qna. Тут всё аналогично team.
- tool-<tool_name>-<theme>, например tool-mattermost-qna, tool-mattermost-news.
- proj-<project_name>, например proj-new-search или proj-tips. proj - префикс, отражающий крупный проект/фичу, которая затрагивает множество команд где им нужно синхронизировать общие вопросы и сроки.
• release-<mobile|web> - каналы релизов МП и веба.
• recruit-<theme> - каналы про найм, например recruit-android или recruit-net.

Данный подход можно по-разному крутить, добавляя свои префиксы и постфиксы. Главное чтобы сохранялся общий паттерн, на основе которого можно было бы просто искать каналы. Английский язык используется просто потому, что он короче, и список каналов будет более компактным.

Про 360 и оценку сотрудников.

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

При оценке сотрудников в формате 360 "школьный подход" часто приводит к конфликту восприятия, тк в нашей работе невозможно постоянно быть отличником. Задачи разные, контекст меняется, а результат зависит не только от усилий конкретного человека. Поэтому 3 - это нормальный, те ожидаемый результат. И это НОРМАЛЬНО!

Мое воспринятие:
1 - значительно ниже ожиданий. Провал, требуется срочного исправление.
2 - ниже ожиданий. Немного не дотянул до нормы.
3 - соответствует ожиданиям. Уверенная норма, те все ОК.
4 - выше ожиданий. Заметно лучше требуемого уровня.
5 - выдающийся, редкий результат. Уровень Rockstar.

Про офис для руководителя.

Пока вокруг все говорят про внедрение ИИ, про удалёнку, про распределённые команды, про метрики и т. д. и т. п., хочется вернуться во времена, когда мы просто приходили в офис, завтракали на кухне, потом садились за общий стол на 3–4 человека и вместе работали. Без созвонов, встреч и календаря.

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

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

Было же время!

P.S.: картинка отсюда.

Пост про бардак.

Я глубоко уверен, что первопричиной большого количества проблем в современном IT (и не только) является простой бардак. Попробую, попытаюсь объяснить.

Начнём издалека, с некоторой аллегории. Представьте, что к вам подходит ваш ребёнок и просит помочь собрать пазл из LEGO. Вы, конечно же, готовы помочь. Идёте в комнату, а там бардак. Игрушки разбросаны, кровать не убрана, одежда валяется на полу и тд и тп. Можно ли в такой комнате собрать LEGO на фоне бардака? Наверное, да, но хочется сначала навести порядок, а уже потом собирать LEGO.

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

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

Бардак - это не что-то, что видно сразу, что можно пощупать и измерить. Это могут быть достаточно метафизические вещи, типа отсутствия понятных зон ответственности или непрозрачности/отсутствия каких-то процессов.

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

Про оценку настроения/cчастья команды.

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

Я в это не верю. Я не верю, что сотрудник, которого просят раз в полгода вспомнить всё, что было хорошего и плохого за это время, может как-то адекватно и целостно собрать свои мысли и дать актуальный и честный фидбэк. Особенно если опросник состоит из 100500 вопросов, а время его заполнения занимает 15 минут и более. Я верю, что нужно собирать оценку настроения сотрудников каждый день, по итогам дня, но так, чтобы это занимало не более 10 секунд.

Я не знаю, как правильно, я лишь помню, как это было на одном из мест моей работы. Бот стучался к тебе в личку каждый день ближе к концу рабочего дня и просил оценить твой день по шкале bad/hard/neutral/good/excellent и, опционально, оставить комментарий. В итоге ты как менеджер видел анонимную среднюю оценку настроения своей команды каждый день в динамике, с историческими данными, и мог понять, как и какие события тем или иным образом на нее влияют.

У меня, к сожалению, не осталось пруфов (скриншотов), как это выглядело, но те, кто со мной работал тогда, помнят этот сервис TeamMood. Кажется, что спустя многие годы ничего такого же простого и удобного не появилось.

"Письмо" в редакцию.

Ниже текст не обиженного луддита, настальгирующего по good old days - а скорее анализ происходящего и попытка трезво принять будущее.

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

В Software Engineering всегда было разделение на «художников» и «маляров». Художники творят Linux, Redis, Python. Маляры решают прикладные задачи перематывая всё это изолентой. Спрос на вторых рос десятилетиями, но сейчас приходит смерть профессии в ее привычном виде, ака демократизация малярного дела.

Все мои знания аргументов grep, параметров gunicorn или трюков оптимизации Docker-образов больше не нужны (даже мне так то!). Даже хитровыебанные знания, вроде паттернов проектирования или систем дизайна. LLM в них компетентнее. Когда я получаю от нейронки снисходительное «You are absolutely right», мы оба знаем: это просто вежливая лесть за уплоченны токены.

Мы поднимаемся на новый уровень абстракции, где становится неважно, *как это сделано*. Нам же плевать на регистры и сдвиги в ассемблере? Теперь этот подход добрался до нашего “высокоуровневого” кода,

Я вижу это на ревью: прилетает PR на 1000 строк нового кода в репозиторий, где всего их 3000. Там всё ок: тесты, документация, структура.
• Да, можно это сделать проще через стороннюю библиотеку - так уж вышло что я это знаю.
• Да, это стоило бы разбить на пять мелких PR, чтобы я не сошел с ума это всё ревьюить.

Но реальность такова: этот код больше не предназначен для чтения человеком. Индустрия переходит в write-only режим. Если нейронка написала тысячу строк, которые работают, и она же сможет их потом поправить — «красота», «переиспользуемость» и «поддерживаемость» кода в человеческом понимании становятся атавизмом.

Так уж вышло что последние 10 или сколько там лет я практиковался именно в “как”. Как сделать код поддерживаемы, безопасным. Как побить на зависимости и сделать общие части переиспользуемыми. Как сделать красиво - ну это самый кайф в нашем достаточно скучном корпаротивном болоте. Теперь этот навык превращается в избыточную нагрузку для бизнеса – хотя wait a second, it always been.

Про настоящий gamechanger от AI.

Что действительно может быть сделано на основе AI, что драматически перевернёт весь мир? Создание полнометражного фильма уровня Голливуда одним человеком? Создание новой игры типа GTA7 одним человеком? Нет. Это, конечно, сильно поломает текущие индустрии развлечений, но всё же нет.

Если вы читали или смотрели экранизацию книги «Автостопом по галактике», то там была рыбка, которая позволяла главному герою понимать любую речь в галактике. Вот оно. Уже сейчас есть Neuralink. Если его как-то скрестить с AI и позволить работать как эта рыбка, то вот он геймченджер. Не надо больше учить никакие языки. Вы понимаете всё, что слышите, и вас также понимает любой слушатель. Мир радикально изменится, так как обмен любой информацией с любым человеком на Земле больше не будет иметь никаких преград.

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

Про успешный успех.

Недавно слушал свежий выпуск подкаста безвотэтоговотвсего с CTO flowwow.

Я не знаю, это какие-то особенности бьюти-рынка или рынка услуг, но flowwow очень близок к ЗЯ в вопросе подготовки к 8 марта и той нагрузки, которая приходит на наши сервисы в этот день. В подкасте было сказано про рост x30, в чём-то автор прав.

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

Спасибо всей команде! Молодцы!

С AI работа стала еще более асинхронной.

Но по факту я хотел заставить агента немного поработать в выходной, не себя 😁

Лет 15–20 назад была популярна шутка "Мой код компилируется". Можно было написать пару строчек кода, нажать Build и пойти пить чай. Всё циклично, и сейчас мы вернулись к похожей ситуации, только уже в формате "Я жду ответа от своего AI-агента". Конечно, время ожидания отличается, но суть очень похожа.

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

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

Про первый AI skill

Написал свой первый AI скилл. Суть простая. На вход передаёшь агенту путь до исходников на локальном диске, а на выходе получаешь C4 L1/L2 архитектуру и sequence-диаграммы их взаимодействия между собой в формате .md файла. Если подключены плагины к Notion или Miro, потом можно попросить загрузить результаты туда.

На github много похожих скилов, но свой велосипед всегда приятнее ;)