Лысый из ASAO

Не ожидали меня слова услышать?

А я устал слушать, как AI «меняет шопинг».

Поэтому в ob.session (это наш новый проект, если кто-то пропустил) решили проверить довольно простую вещь: а люди вообще пользуются LLM, когда покупают одежду?

Не «представьте будущее e-commerce», а буквально:
«Что надеть с этой юбкой?»
«Найди мне такую же куртку».
«Мне на свадьбу, я понятия не имею, что хочу».

Где-то AI уже работает подозрительно хорошо. Где-то разваливается на самом простом запросе.

Сейчас собираем реальные сценарии использования.

Опрос на 2 минуты.

Если вы хоть раз пытались купить одежду с помощью ChatGPT / Claude / Gemini / чего-то ещё - расскажите, что из этого вышло👇
Опрос

Программирую больше 10 лет. Сегодня, начитавшись Threads, решил впервые в жизни посмотреть, что это за 1С, о котором там вещают из каждого утюга.

АААААААААААА! Пожалуйста, скажите мне, что это пранк.
Или люди на полном серьезе пишут что-то типа «Если ТипЗнч(ТекОбъект) = Тип("Строка") Тогда», и не возникает даже намёк на улыбку?

Пока условный Claude Code регулярно тупит на сколь-нибудь сложных задачах, мы держим руку на пульсе. Но вопрос времени, когда отношения с агентом перейдут из формата тимлид-джун в формат PM-разработчики.

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

Если сотрудник косячит в 1 задаче из 10, мы микроменеджим.
В 1 из 100 - мониторим и проверяем.
В 1 из 1000 - встраиваем guardrails в систему.

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

С AI-агентами также. И это гораздо опаснее, чем вероятность условного SkyNet.

Очень не люблю фразу «выйти из зоны комфорта».

Зон на самом деле три - комфорта, дискомфорта, и серая зона (ни то ни другое). Выйти из зоны комфорта в серую зону - это про пресловутый внутренний рост. Но насильно запихивать себя в зону дискомфорта - прямой путь к выгоранию и поехавшей кукухе.

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

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

Когда продукт выглядит как «пристройка к пристройке», проблема обычно не разработчиках. Это симптом отсутствия системного владельца.

В кейсе о котором я писал в прошлом посте, был подключён Fractional CTO. Не для «помочь команде», а чтобы вернуть управляемость. Первое, что он сделал - перестал обсуждать фичи. Начал обсуждать систему, что есть продукт, где границы доменов, как решения сегодня влияют на масштаб через полгода, какие компромиссы осознанные, а какие - просто случайные.

Дальше - базовая, скучная, но критически важная работа:
• единая карта архитектуры вместо знаний «в головах»;
• связь продукта, данных и инфраструктуры в одну цепочку;
• четкие зоны ответственности, без серых областей;
• простые правила принятия решений - чтобы не изобретать их каждый спринт.

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

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

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

Fractional CTO - это не про роскошь. Это про ограничение ущерба. Самострой всегда кажется дешевле. Пока не приходит счёт на этапе роста.

Стройка без прораба - это не дом, а набор ошибок.

Звучит смешно, пока не становится понятно, что половина стартапов живёт именно так. Представим стройку, где всем рулит дизайнер интерьеров - он про свет, плитку, диваны. Картинка - отличная. А дальше начинается реальность - электрик тянет провода через ванную, потому что «так быстрее», маляр красит поверх выключателей, потому что «так удобнее», шумоизоляции нет, потому что ее не было на рендерах.

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

Бизнес-фаундеры сильные - рынок чувствуют, стратегия понятная, питчи заходят. Но техфаундера нет. Денег нет → времени нет → «Возьмем мидла на фронт, мидла на бэк - и поехали».

Дальше - классические симптомы стройки без прораба:
• фичи по отдельности нормальные, вместе конфликтуют;
• решения без схемы: сегодня так, завтра иначе;
• код на костылях, потому что «потом перепишем»;
• ночные релизы под мантру «лишь бы не упало»;
• никакой аналитики, мышление от таски к таске.

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

CTO, fractional CTO, архитектор — название не принципиально. Человек, который знает:
• что строится;
• зачем именно так;
• как это складывается в одну систему;
• где границы ответственности.

Один такой человек меняет все. У решений появляется «почему». У продукта появляется шанс расти, а не разваливаться от следующей фичи.

Самый дорогой специалист не спасет бизнес, если проблема не в человеке.

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

Где это обычно ломается:
Тимлид → Head. Человека тянут выше, но его реальная сила - в работе с одной командой. В итоге он начинает микроменеджить, лезет в детали, душит процессы и выгорает за полгода.

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

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

Важно помнить порядок ролей: Individual Contributor → Team Lead → Head → VP / Director → CTO. И еще важнее - понимать, что рост не обязан быть линейным и не каждый сильный инженер или менеджер хочет и должен идти до CTO.

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

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

CTO - это не главный программист. Это человек, который переводит технологии на язык денег, рисков и выживания бизнеса.

Когда CEO спрашивает: «Почему мы не можем сделать это за неделю?», а команда отвечает: «Потому что архитектура», и дальше тишина, это - это большая проблема.

Не техническая. Организационная.

Важно разделять роли.
Founding engineer / tech founder - может быть отличным разработчиком, который умеет быстро собрать продукт, написать код, довести MVP до жизни.

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

И да, CTO по-хорошему нужен не “когда прижало”, а как минимум с момента product–market fit. Дальше прототипа без этой роли компания начинает накапливать дорогие ошибки.

Типичная ситуация:
• продукт, данные и инфраструктура живут как три параллельные вселенные;
• технические решения принимаются локально, а платит за них бизнес;
• впереди дорогие и необратимые выборы — архитектура, аналитика, безопасность;
• между CEO и инженерами нет моста, только переводчик в виде слайдов.

Что меняется, когда появляется нормальный CTO:
• появляется честный аудит - где дыры, где риски, где можно выиграть;
• архитектура становится понятной не только инженерам, но и бизнесу;
• костыли не “чинят”, а последовательно убирают;
• возникает план «сейчас / потом / никогда», который экономит реальные деньги.

Важно: первый технический человек в компании не обязан быть CTO навсегда. Спокойно можно начать с сильного founding engineer, а после PMF - пригласить полноценного CTO, иногда даже введя его как кофаундера.

Тимлид управляет людьми.
Хед - командами.
CTO - связкой «технологии - бизнес» и ценой ошибок на этом уровне.

Когда тимлиды начинают воевать - пора нанимать хеда.

Команд три, приоритетов пять, а сроки у каждого "самые важные". Бюджет улетел куда-то в космос, архитектура держится на костылях, техдолг растет быстрее, чем фичи.

Кажется логичным нанять ещё одного тимлида? Спойлер: не поможет.

Хед (Head of X) - это менеджер домена (dev / data / ML / что угодно), который видит всю картину сверху и собирает хаос в систему. Он уже не тонет в коде. Он про другое:
• приоритизация между командами: кто делает что, кто отдает ресурсы, кто получает.
• архитектура и инфраструктура: не как написать эту фичу, а как нам вообще не развалиться через полгода.
• найм и рост людей: единые стандарты, онбординг, карьерные треки, дорожная карта на месяцы, а не недели.

Сигналы, что нужен именно хед, а не очередной тимлид:
• Команд несколько, приоритеты конфликтуют, все дергают всех.
• Война за ресурсы стала нормой.
• Упираетесь в архитектуру/инфраструктуру постоянно, техдолг копится быстрее, чем его закрываете.
• Нужны найм, единые стандарты и дорожная карта на кварталы вперед, а не спринты.
• Бюджет на инструменты расползается, никто не видит общую картину. Счета растут, а толку нет.

Не нужно больше исполнителей. Нужен тот, кто остановит хаос на уровне системы.

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

Тимлид рулит одной командой. Хед - рулит войной между командами и превращает ее в оркестр.

Тимлид - это не старший разработчик. Это предохранитель от хаоса.

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

Тимлид - это все еще сильный разработчик, но с другой задачей в голове: не "как мне сделать фичу?", а "как сделать так, чтобы команда стабильно приезжала к результату?".

Он:
• общается с людьми, а не прячется в задачах;
• раздает работу так, чтобы никто не тонул и не простаивал;
• следит за качеством кода и сроками одной команды, а не всего мира.

Сигналы, что пора заводить тимлида:
• Дедлайны плывут, задачи теряются между чатом и таск-трекером.
• Разработчики ждут идеальные ТЗ и зависают на каждом непонятном - месте.
• Код «кто в лес, кто по дрова»: нет общих правил, ревью и онбординга.
• Горизонт планирования - 1-4 недели, дальше туман.

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

Что меняется после появления нормального тимлида:
• скорость становится предсказуемой, а не "как пойдет";
• процессы становятся прозрачными, задачи не теряются по дороге;
• факапов становится меньше не потому, что все начали стараться, а потому что появился тот, кто отвечает за сам процесс.


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

Карьерная лестница разработчика - это сказка для HR.

Представьте табуретку из IKEA, которую кто-то решил использовать как стремянку. Формально работает. Пока не упадешь.

Вот так же устроены «повышения» в большинстве компаний.

- Сильный разработчик ≠ нормальный тимлид
- Тимлид ≠ Хед
- Хед ≠ CTO

Но почему-то до сих пор живет логика: «Пишешь отличный код? Руководи людьми».

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

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

И да, размер имеет значение: Есть больше 2-х разработчиков? Уже нужен тимлид. Появилось несколько команд? Без хеда будет сложно. Много направлений (dev, data, ops, ML)? Нужен CTO. Иначе страдать будут все.

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

P.S. Reality Check:
Перед тем как кого-то повышать: Кто реально сейчас решает проблемы? Кто давно «перерос» свою зону? Не держите ли тимлидов на уровне, где им тесно? Или наоборот - на позиции CTO сидит человек, которому некомфортно нести ответственность и руководить?

Представьте, что три отдела считают прибыль компании в разной валюте. Финансы - в евро. Маркетинг - в долларах. Продакт - «примерно по ощущениям». И потом все удивляются, почему цифры не сходятся.
 
Ровно так же выглядит большинство компаний, когда дело доходит до метрик. Когда разные команды по-разному считают одну и ту же метрику - это не данные. Это хаос, замаскированный под аналитику.
 
Картина, которая встречается очень часто:
- одна команда считает retention на 20-й день;
- другая - на 5-й;
- третья - только по платящим.
 
Все уверены, что делают «правильно». И параллельно строят дашборды, ставят цели и принимают решения - каждая в своей отдельной реальности.
 
На выходе:
- отчёты противоречат друг другу;
- решения принимаются на разных основаниях;
- приоритеты расползаются;
- а иногда ещё и выручка, ROI и LTV считаются криво, но с умным видом.
 
Самое скучное и при этом самое рабочее решение - Single Source of Truth.
Одна часть knowledge base, где:
- метрики определены одинаково;
- за них есть ответственные;
- документация жива, а не «когда-то была»;
- и все смотрят в одни и те же числа, а не спорят о том, какие именно числа правильные.
 
Работа без блеска. Без вау-эффекта. Зато внезапно продуктовые, маркетинговые и дата-решения начинают попадать в цель.
 
Если команды спорят о цифрах вместо того, чтобы двигать результат - SSOT нужен был ещё вчера.

Десять лет назад было просто: "большой банк = безопасно", "новый банк = рискованно".
Сейчас эта логика не работает.
 
Посмотрите на Revolut: когда-то это была игрушка для 20-летних в худи, а теперь - серьезная альтернатива для компаний, которые раньше работали только с традиционными гигантами.
 
А традиционные банки всё ещё пытаются догнать.
 
🔥 Корпорации проигрывают, потому что они медленные.
- Они работают по полугодовым циклам, а стартапы выкатывают фичи за недели.
- Любое изменение проходит через 10 согласований и 100 встреч.
- Даже когда копируют современные продукты, старые системы и устаревший менеджмент их тянут вниз.
 
🔥 Маленькие игроки побеждают, потому что быстрые.
- Они делают акцент на удобство: мультивалютные счета, акции, крипта, нормальные проценты - все в одном приложении.
- "Надёжность" больше не является преимуществом. Новые банки имеют те же лицензии, страховку и регуляцию, что и старые гиганты.
 
Традиционные банки, конечно, не умрут. Пока что они проигрывают битву за потребительский сегмент. Зато все еще доминируют в корпоративном финансировании и больших сделках. Надолго ли?

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

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

Остальное - разберем по мере поступления.

Ну что, ваши резолюции на 2026 уже готовы?
 
Каждый декабрь одно и то же шоу. Люди массово обещают себе «начать новую жизнь», а компании - «стать более data-driven».
 
В январе обычно выполняется одно и то же: ровно ничего.
 
2026-й обещает быть ещё веселее. ИИ уже пишет за студентов, кодит за джунов и помогает HR отделам проводить регулярные децимации. Компаниям это нравится. Людям - не всегда. Эмоции, как обычно, не совпадают с экономикой.
 
И тут начинается ежегодная резолюция уровня:
«В 2026 мы обязательно разберемся, как использовать ИИ».
 
Та же резолюция была в 2025, 2024 и в конце 2023, когда все еще спорили, «опасен ли GPT». Разница лишь в том, что в 2026-м все это уже не «тренд», а инфраструктура.
 
Как интернет в нулевых: кто не подстроился - тот сидит в углу и печатает объявления в WordArt.
 
Реальные резолюции 2026 года выглядят куда честнее:
- не потеряться в зоопарке новых моделей, которые выходят быстрее календарных недель;
- избавиться от любых процессов, которые ИИ делает быстрее и не хуже;
- перестать бояться автоматизации и начать бояться её отсутствия;
- отделить хайп от пользы (проще сказать, чем сделать).
 
И главное - наконец перестать планировать 2026-й так, будто он будет похож на 2025-й.
 
Не будет. Темп ускоряется, и никто не ждет, пока кто-то «разберется и внедрит по плану».
 
Но, как показывает практика, единственная резолюция, которая реально срабатывает каждый год - «Ладно, потом разберусь».
 
И уже в феврале компании снова строят стратегию по принципу «Пока все не горит - трогать не будем».
 
Мир меняется быстрее резолюций. Какой тогда смысл в списках, которые живут меньше, чем новогодняя ёлка?

Уже устал повторять.

UI-обертка вокруг OpenAI API с парой промптов - это не стартап. Это прототип, который живет до первого обновления модели.

Инвестиции на такое получить можно разве что от родителей - и то под обещание «мы потом все перепишем нормально».

Какие навыки вообще имеет смысл проверять, если ИИ пишет лучше человека
 
Раньше сочинения и гуманитарные задания были нормальным прокси. Никто всерьез не проверял красоту слога - проверяли, как у человека работает голова.
 
Что именно проверялось:
Обработка большого объёма информации. Давалась стопка текстов, половина из которых написана так, будто автору платили за количество страниц. Нужно было не утонуть, разобрать материал, отделить шум от смысла и вообще понять, что происходит.
 
Умение вытащить главное. Не пересказать все подряд, а схватить центральную идею, увидеть связи, выкинуть лишнее. По сути - сделать первичную аналитическую выжимку.
 
Упаковка в связную мысль. Из хаоса заметок собрать текст, который можно читать без боли: выстроить логику, акценты, выводы. То есть показать способность не просто понимать информацию, но и превращать её в понятный результат.
 
И это всё имело смысл, потому что альтернатив было мало: большая часть знаний действительно находилась внутри ВУЗов, библиотек и учебников - туда и приходилось пробираться с боем. Сейчас, справедливости ради, любой ChatGPT спокойно объяснит 80% теории не хуже ведущих университетов.
 
Поэтому старые прокси постепенно теряют ценность: источник знаний изменился, а инструменты проверки - нет. Сейчас львиную долю этой работы забрал на себя ИИ. И проверка в духе «умеет ли человек руками делать то, что машина делает быстрее и лучше» - выглядит странно.
 
Тогда логичный вопрос: что проверять вместо «напиши реферат»?
 
Смысл есть в том, что не автоматизируется «в лоб»:
- какие вопросы задаются ИИ;
- как формулируется задача;
- как человек спорит с ответом, а не принимает его на веру;
- как результат прикручивается к реальной задаче, продукту, бизнес-контексту.
 
Проблема, конечно, шире ИИ. Университетские программы обновляются раз в десять лет, а мир катится на новую версию примерно раз в полтора года. Просто на примере ИИ особенно видно, насколько система неповоротлива.
 
ИИ никуда не денется. Притворяться, что его нет - это как сдавать экзамен на водительские права, демонстрируя управление конной повозкой.