Создатели опенсорс-инструментов совершают продуктовые ошибки ещё чаще, чем предприниматели.

Каноничный пример — python-telegram-bot. Хороший, вроде бы, фреймворк: приемлемый бойлерплейт, поддерживает все нужные эндроинты, в документации разобраться тоже возможно.

Но вот несколько лет назад его взяли и переписали на asyncio. Получилось очень по-программистски: авторы не надели шляпу пользователей, у которых уже есть кодовая база. Хочешь новые фичи и секьюрити-фиксы — будь добр, переписывай кодовую базу под никому не нужный async. Авторы даже не удосужились как-то продать юзерам ценность перехода, добавить хоть каких-то фич. Просто переписали и всё — в анонсе нет вообще ни капли смысла, одни только «embracing the future».

Оно и понятно — откуда взяться смыслу, если у PTB в принципе не может быть задач, для которых нужен event loop. Если есть большая нагрузка, как, к примеру, у антиспам-ботов, то её легче обработать без фреймворка, в рамках отдельного потока. А если нужно дизайнить развесистый флоу общения с пользователем (для чего вобщем-то и нужен PTB) — скорее всего этот флоу никогда не нагрузят так, что там понадобится асинхронщина.

Самое смешное в этом переходе — фреймворк даже на asyncio продолжает быть однозадачным: не будет отвечать одному юзеру, пока обслуживает другого. Чтобы включить интуитивно ожидаемое поведение, надо в бойлерплейте писать какое-то странное заклинание, что-то вроде bot.init(simultaneos_updates=True).

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

И ни разу я не видел проекта, который не запустился из-за медленной разработки.

Конечно, в долине смерти много бизнесов, где код говно, а программисты нарушают обещания. Но причина их смерти — не в программистах, а всё в той же просранной продуктовой работе: нулевой product-market-fit, несходящаяся экономика, неумение нанимать людей и тестировать гипотезы.

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

В маленьком вебе (надеюсь, вы его читаете) можно найти целый диапазон мнений про AI-хайп — от отрицания до полного поклонения (автор последнего — целый автор Redis). В Х (его вы, надеюсь, не читаете) топ-менеджеры AI-компаний жалуются, как ловят FOMO от скорости появления новых технологий, которые их же компании производят. В общем хайп-поезд всё ещё едет.

Боязнь остаться за бортом характерна для нашей отрасли. И оправдана — если условный сисадмин с нормальным для рынка уровнем знаний в 2016-2018 годах пропустил появление k8s и облачных технологий, зарплата у него не вырастет, пока он не докачает знания до новой планки. Думаю, каждый вспомнит такие революции в своём стеке: фронтендеры вспомнят появление реактивных компонентов, vue, svelte. Бекендеры вспомнят graphql и микросервисы. Деды вспомнят AJAX и MVC. Все вместе вспомнят блокчейн.

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

Стратегия обычных потребителей — самая выгодная: пока они доходят до новой технологии, технология успевает достаточно созреть — обзавестись документацией, встроиться в экосистему, вылечить детские болячки. К этому времени цена изучения радикально снизится — сравните, к примеру, первую версию документации react, которая предлагала комплилировать JSX прямо в браузере и современный next.js, на котором собрать сайт можно за 10 минут без помощников.

AI, хоть и отличается скоростью от предыдущих революций, проходит тот же самый путь: какие-то части уже созрели (Cursor, агенты), какие-то — пока на ранней стадии (агенты, которые пишут агентов). А какие-то части уже умерли, или потихоньку стагнируют. Если следить за всеми этими новостями — на работу не останется времени.

Как поступать с AI, придерживая стратегии обычного потребителя? За пару дней подобрать себе удобный зрелый инструмент (cursor/claude cli/opencode/codex), и, применив закон Парето к своему FOMO, просто решать c ним текущие задачи. А если ещё какие-то части AI-инструментария дозреют до того, чтобы заслужить вашего внимания — вы наверняка об этом узнаете, как сисадмины узнали о k8s.

Не люблю сериалы, но смотрю.

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

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

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

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

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

Самый большой минус в резке костов — это самообман. Допустим, я придумал, как сэкономить 500 баксов на SaaS-ах, перенеся часть к себе — и (кроме геморроя в эксплуатации), получаю чувство, что прожил день не зря: это ж половина месячной аренды квартиры! Чувство, к сожалению, ложное — тяжело представить бизнес, для которого плюс-минус 500 баксов имеют решающее значение.

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

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