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

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

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

Claude Code v2.1.32 вышел 5 февраля 2026 года . Именно в этом релизе auto-memory стала публично доступной.

Основная проблема - как тратить на сохранение и поиск информации константное и минимальное время (секунды/минуты) не теряя в качестве. Использование тегов в итоге скатывается в неразбериху, а поиск может не захватить некоторую важную информацию. В итоге чтобы все работало надо чуть ли не с математической точностью оцифровывать каждый процесс, а это дорого в реализации и поддержке. Нужна золотая середина которая даст 80% качества и не будет давать информации простаивать без дела.

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

Если заходить: только через узкие ниши, реальный экспертный контент, диверсификацию партнёрок (SaaS/сервисы с 20–40% и длиннее куки), а Amazon — как дополнительный канал.

Поправьте если не прав, но вроде ничего не гарантирует что write() выполнится до read()

Именно процент от прибыли — вот что по-настоящему замотивирует человека.

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

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

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

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

Картина когда никто не знает ни про дедлайны, ни про сроки, выглядит соблазнительной для того чтоб вписать в селфревью, но я вообще не верю в то, что такое будет работать в продуктовой команде где продукт почти никогда не подстраивается под реалистичные сроки и когда для конкуренции за грейдап тебе надо подстраивать сроки под продукт 95% времени.

Тут две крайности:

• Ожидать возвыситься над окружающими, выполняя рутинный труд.

• Возводить в норму обесценивание труда.