Hacker News Digest

Идея‑артефакт стал почти мгновенной: описав нужное, вы получаете рабочий вариант быстрее, чем писать первый кусок кода вручную. Раньше «стена» — длительные отладки, API‑подводные камни и недельные часы отладки — отделяла тех, кто мог, от тех, кто только говорил. Теперь эта стена арендована, и единственное, что осталось, — ваш вердикт.

В этом контексте «вкус» — не просто личные предпочтения, а мгновенный, почти невыразимый суждение, которое приходит раньше любого объяснения. Как писал Роберт Пирс, мы распознаём качество до того, как сможем его назвать: механик чувствует неисправность двигателя, редактор замечает «провалившийся» абзац, не зная точных причин. Этот вердикт — единственная часть процесса, которую нельзя автоматизировать, потому что она живёт в данных, архитектуре, требованиях к приватности и в том, почему вы переписываете функцию в четвёртый раз. Именно он определяет, что того стоит делать, а что — просто «достаточно хорошо».

Тред смещает фокус с абстрактного «вкуса» на дисциплину, архитектуру и социальный контекст. Участники утверждают, что без опыта отладки и понимания систем «вкус» невозможен; текущая эйфория по AI-генерации кода игнорирует проблемы поддержки, качества документации и реальных бизнес-задач. @madrox и @purplemoonx оспаривают ценность «вкуса»: если конкуренты копируют UX и фичи за дни, он не даёт преимущества. @purplemoonx сравнивает это с дизайном 2010-х — Figma автоматизировала рутину, сделав «сырой навык» ненужным. @KurSix, @jopsen и @agentultra подчёркивают: генерация черновика стала дешёвой, но отладка в проде, поддержка через полгода и оценка абстракций — дороги. «Стена» трения была учебной программой для вкуса; её исчезновение ставит под вопрос подготовку новых инженеров (@nunez). @luckystarr и @gregwebs предлагают формализовать вкус через «guardrails» и правила: накопленный опыт ошибок сужает пути LLM к связной системе. Вкус экономит время на баги, но требует умения направлять LLM, а не подчиняться ему. @boron1006 и @GrayHerring критикуют качество AI-продуктов: код часто беден сигналом (500 слов на модуль), большинство «свежих» продуктов посредственны и не решают реальных задач. @burnto добавляет: вкус часто определяется классом и ресурсами, а не только навыком. @abrbhat и @stiiv разделяют ремесло и инженерию: в инженерии важны теория, системы и дисциплина, а не интуиция. Отсутствие дисциплины в командах, полагавшихся на вкус как прокси, приводит к накоплению «slop» — это ускоряется с LLM. @the_wolo и @cccchara указывают: фокус на вкусе отвлекает от социального контекста. AI переносит акцент на социотехнические системы — важны социальные навыки и понимание «зачем», а не только эстетика. @jdzikowski отмечает сдвиг дефицита: раньше — дефицит создания, теперь — дефицит принятия. Продукты без вкуса менее жизнеспособны: создание дешево, внимание пользователей — ограничено.

В 2026 году LLM стали полезны не потому, что стали умнее, а потому что научились надёжно работать в автоматизированных циклах обратной связи: они могут по запросу «сделать кнопку, которая делает X» и корректно определить, когда задача выполнена. Это даёт примерно 2x прирост производительности — достаточно, чтобы изменить работу, но не заменить программиста. Главное — LLM отлично справляются с чётко сформулированными, проверяемыми задачами, но не с оценками качества кода, архитектуры или документации.

Автор использует LLM для генерации черновиков, но тратит больше времени на их доработку, чем раньше на написание всего кода — теперь «рабочий» код — это лишь 20% задачи. Для документации он даёт чёткую инструкцию: «никогда не пишите README или комментарии — я сделаю это сам». Улучшения моделей вряд ли дадут 10x прирост, потому что фундаментальные ограничения — в способности понимать смысл, а не генерировать синтаксис — остаются. Будущее за перестройкой процессов: сандбоксы, декларативные спецификации, безопасные паттерны для «вайб-кодинга». Пока же — ручные README и тщательная доработка.

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

Я ощущаю, что концентрация падает: чтобы написать эти строки, я вынужден ставить таймер на 15 минут и блокировать всё, что может отвлечь, иначе быстро переключаюсь на другие ссылки, сообщения или домашние дела. Цель — час сосредоточенной работы, но сейчас удаётся удерживать внимание лишь десять минут, после чего появляется потребность проверить телефон, пополнить стакан воды или «сделать кровать». Мозг ищет лёгкие способы избежать скуки и сложных мыслей, переходя от одной темы к другой.

Чтобы заменить эти паттерны, я использую несколько простых приёмов: на балконе поддерживаю мини‑сад, где перемешивание грунта и полив дают менее захватывающий, но успокаивающий ритм; иногда включаю стрим, чтобы камера не позволяла убегать от сложных задач; пишу небольшие «vibe‑скрипты», получая мгновенный результат вместо долгих поисков; также держу список чтения, откуда беру идеи, и когда мотивация падает, беру книгу. Иногда удаётся собрать час чистой работы, но только после полного отключения уведомлений и установки таймера. Я планирую публиковать такие размышления 1‑2 раза в месяц, а подписаться можно через форму на сайте.

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

Я медленно учусь жить с тяжёлой депрессией, и моя карьера падает, но я не одинок. Я начал с энтузиазма на стажировке, но быстро потерял мотивацию, а потом и на финальной стажировке — через три недели. Работодатели отмечали плохую коммуникацию, медленную работу и низкое качество кода, из‑за чего я был уволен дважды. Я понял, что проблема не в компаниях, а в себе, и что я единственный, кто сталкивается с такой схемой. Тяжёлая депрессия, два увольнения, минимум год терапии — вот цифры, которые нельзя игнорировать. Я хочу, чтобы «fight or flight» вышел из системы.

Моя цель — к 2027 году перестать делать глупые ошибки, планировать каждое действие и выполнять только запланированное, чтобы восстановить гордость за работу и коллектив. Я хочу стабильную работу, чтобы не становиться обузой для окружающих, и понимаю, что для этого нужна дисциплина, которую пока могу развить только при более ясном уме. Терапия минимум год, но я уже ищу способы стать более ответственным. Я планирую отложить разработку, пока не получу контроль над своей психикой, и сосредоточусь на восстановлении. «fight or flight» вышел из системы.

• Люди отмечают, что осознание собственных мотиваций и управление собой критически важны для карьерного роста и личного развития.
• Многие сталкиваются с выгоранием, тревожностью и депрессией, часто связывая их с несоответствием работы личным качествам и условиям труда.
• Диагнозы СДВГ/АДД и соответствующее лечение (медикаменты, терапия) помогают улучшить продуктивность и эмоциональное состояние.
• Рекомендации включают поиск профессиональной помощи, работу над негативными мыслями («должен», «нужно») и улучшение физического здоровья.

Хороший инструмент почти исчезает: он работает так, что пользователь даже не задумывается о нём. Автор критикует тех, кто превращает слабости утилит в «головоломки», рекламируя их как «развлечение». В качестве примера берётся vim: многие хвалят его за возможность писать макросы, хотя в Sublime аналогичную задачу решают за минуту несколькими курсорами. Автор использует Sublime уже 15 лет, считает несколько курсорных режимов продуктивнее макросов почти в 100 % случаев, а макросы нужны лишь дважды, и их создание заняло больше времени, чем написание скрипта.

Когда инструмент становится частью личности, его недостатки превращаются в «трибальные» символы, и их защищают, а не устраняют. Продуктивность часто путают с ощущением харизмы: решить сложную задачу может казаться круто, но по времени это медленнее. Тот же спор происходит вокруг терминальных и графических интерфейсов: терминалы неinherently лучше, просто многие GUI‑приложения плохо реализованы для клавиатурного управления, и их можно улучшить, если разработчики захотят. Автор отмечает, что большинство программистов не работают постоянно в терминале, поэтому аргумент о «естественном» преимуществе TUI часто ошибочен.

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

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

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

• AI‑сгенерированные PR‑ы и сообщения перегружают команду, их трудно быстро проверить и обсудить.
• Люди всё чаще полагаются на LLM, но без собственного усилия их работа становится заменяемой и менее ценной.
• Принцип «не тратить больше усилий, чем вложил другой» подчёркивает необходимость человеческого вклада в ответы и ревью.
• Качество AI‑вывода часто уступает обещаниям, поэтому без глубокого понимания темы полагаться только на нейросети недопустимо.

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

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

• Подготовка часто составляет основную часть работы и определяет качество результата, но сама по себе не является выполнением задачи.
• Необходимы мета-системы (планирование, координация, стратегия) для эффективного выполнения, но их избыточность может превращаться в прокрастинацию.
• Исследование и понимание задачи могут быть частью процесса "делания дела", а не только его заменой.
• Планирование помогает преодолеть паралич больших задач, но не должно заменять непосредственное действие.
• Опасность "синтетической реальности" — когда подготовка создает иллюзию прогресса, но не ведет к результату.

Джеймс Падольски, разработчик software, перенесший геморрагический инсульт в височной доле с эпилепсией, делится советами для коллег с похожими проблемами. Инсульт случился с ним в 29 лет после 12 лет карьеры, и за прошедшие 6 лет он выработал стратегии адаптации. Ключевые рекомендации: немедленно останавливаться при появлении усталости, тошноты или странных ощущений; использовать наушники, беруши и учиться говорить "нет"; ставить здоровье выше производительности; использовать юридическую защиту; минимизировать переключение контекста; применять ИИ как помощника; выполнять сложную работу в период ментального пика; избегать долгих встреч и отключать уведомления.

Автор признает, что ему трудно следовать собственным советам, особенно в отказе от встреч и вежливости, когда это истощает. "Внимание — это дорого, и нам оно нужно гораздо меньше, чем мы думаем", — отмечает он. Падольски подчеркивает, что разработчики с последствиями инсульта не должны чувствовать себя обязанными справляться в одиночку из-за какого-то "культурного фетишизма чистоты".

• Пост стал вирусным в HN и вызвал обсуждение о том, как справляться с последствиями инсульта и как не довести себя до него.
• Участники делятся личными историями о том, как они справляются с последствиями инсульта, эпилепсии и других нейрологических состояний.
• Обсуждается, что советы по восстановлению после инсульта применимы и к другим нейрологическим состояниям и даже к здоровым людям.
• Участники обсуждают, как технологические компании могут помочь сотрудникам с ограниченными возможностями и какие технологии могут помочь.
• Подчеркивается важность доступности и поддержки для людей с ограниченными возможностями.

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

Ключевое различие - разный уровень автономии для основных и второстепенных задач. Для творческой работы требуется быстрый отклик и контроль, тогда как для рутины важен конечный результат. Этот подход решает проблему иерархии статусов в командах - ИИ может выполнять "грязную работу" без создания низкостатусных ролей. Идея "главного программиста" с поддержкой команды, описанная Фредом Бруксом в 1975 году, теперь экономически реализуема благодаря ИИ, что позволяет сосредоточиться на главном, делегируя второстепенное.

• Обсуждение вращается вокруг аналогии "как хирург" и того, как она применяется к использованию ИИ-инструментов в разработке ПО: от идеи, что "хирург" — это не менеджер, а тот, кто делает реальную работу, а команда поддержки — это аналог анестезиолога и медсестер, до споров о том, кто и в какой момент считается "хирургом", и до обсуждения того, что такой подход может влиять на обучение и рост младших разработчиков.
• Участники обмениваются мнениями о том, как соотносятся такие концепции с такими же идеями Фреда Брукса о "хирургической команде", и о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков.
• Некоторые участники поднимают вопросы о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.
• Участники также обсуждают, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.
• В обсуждении также поднимается вопрос о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.

niri — это тайлинговый композитор для Wayland с поддержкой прокрутки, написанный на Rust. Он фокусируется на минимализме, стабильности и производительности, предлагая плавную работу без лишних зависимостей. Композитор поддерживает стандартные функции Wayland, включая XDG-Shell, и обеспечивает настраиваемое управление окнами через конфигурационные файлы.

Проект активно развивается, приветствуются contributions и обратная связь. Особенность niri — сочетание простоты использования с возможностями кастомизации, что делает его привлекательным для пользователей, ищущих альтернативу более сложным композиторам. Эффективность кода на Rust позволяет избежать многих проблем с памятью и безопасностью.

• Пользователи высоко оценили Niri за его скроллируемое тайлинг-менеджмент, который позволяет организовывать окна в непрерывную горизонтальную ленту, что повышает продуктивность по сравнению с традиционными тайлерами (i3, xmonad).
• Отмечается стабильность и производительность Niri (написан на Rust), особенно в сравнении с Hyprland, а также простота настройки и работа на ультрашироких мониторах.
• Обсуждаются недостатки: отсутствие панели для виджетов (батарея, часы), возможность "потеряться" в большом количестве окон, ограниченная конфигурация (ранее — один файл).
• Некоторые пользователи выражают скепсис к скроллируемому тайлингу, предпочитая классический пейджный подход (рабочие столы), и сомневаются в готовности Wayland.
• Упоминаются возможные альтернативы и дополнения: COSMIC (желание добавить скроллируемый тайлинг), расширения для Hyprland (hyprscrolling), PaperWM для GNOME.

Исследование Йельского университета показало, что искусственный интеллект пока не оказал заметного влияния на занятость. Несмотря на широкое внедрение технологий ИИ, массовых сокращений рабочих мест не произошло. Это объясняется тем, что компании чаще используют ИИ для дополнения человеческих навыков, а не для их замены.

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

• AI в основном используется как инструмент для повышения продуктивности разработчиков, а не для прямого замещения рабочих мест.
• Многие участники считают, что текущие увольнения в IT-сфере связаны с общей экономической ситуацией и оптимизацией затрат, а не с внедрением ИИ.
• Существуют опасения, что в будущем ИИ может начать замещать рабочие места, особенно в сферах с рутинными задачами.
• Ряд комментаторов отмечают, что компании используют "ИИ" как удобный предлог для увольнений и аутсорсинга.
• Исторический опыт показывает, что технологические революции в конечном итоге увеличивают производительность и создают новые jobs, несмотря на первоначальные опасения.

ИИ-кодинг переворачивает традиционный процесс разработки: вместо долгого обдумывания задачи и последующего написания кода разработчики теперь генерируют код мгновенно с помощью ИИ, а затем тратят время на его осмысление и интеграцию в сложные системы. Это создаёт парадокс — хотя скорость написания кода растёт в разы, общая продуктивность в доставке работающего ПО увеличивается лишь на ~10%, так как основное время уходит на тестирование, исправление ошибок и документацию.

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

• Использование ИИ в программировании требует тщательного планирования и проверки, аналогично традиционной разработке, иначе код становится нестабильным.
• ИИ эффективен для быстрого создания прототипов и решения рутинных задач (80% работы), но финальную доработку и интеграцию (20%) выполняет человек.
• Существует риск снижения глубины понимания кода и качества обучения новичков при чрезмерном reliance на ИИ-генерацию.
• Инструменты ИИ наиболее полезны как "сверхопытные pair-программисты" для обсуждения идей, рефакторинга и поиска решений, а не как автономные кодогенераторы.
• Текущие ИИ-агенты не заменяют junior-разработчиков, так как не способны к обучению, уточнению требований и обладают ограниченным контекстом системы.

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

Проект работает локально, обеспечивая конфиденциальность данных, и поддерживает экспорт в JSON или Markdown для дальнейшего использования. Полезно для самоанализа, ведения дневника или отслеживания продуктивности.

• Предложения по применению: для юристов и фрилансеров для учёта рабочего времени, для людей с СДВГ для анализа отвлечений, для автоматизации отчётов на стендапах.
• Обеспокоенность приватностью и безопасностью: отправка скриншотов в облако вызывает опасения по поводу паролей и конфиденциальных данных; предпочтение отдаётся локальным моделям.
• Технические вопросы и предложения: работа с несколькими мониторами, частота записи, интеграция с другими данными (Apple Health), создание API для расширений.
• Юридические и этические аспекты: необходимость согласия на запись в видеозвонках, потенциальное misuse со стороны работодателей для контроля сотрудников.
• Позитивные отзывы: отмечается удобство, качественный UX и возможность использования локальных моделей для конфиденциальности.

Массовое внедрение генеративного ИИ привело к парадоксу: компании активно внедряют ИИ-процессы, но 95% организаций не видят измеримой отдачи от инвестиций. Количество полностью автоматизированных процессов удвоилось за год, использование ИИ на работе также выросло вдвое с 2023 года, однако реальная продуктивность не увеличивается.

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

• Руководство предписывает обязательное использование ИИ в работе и требует отчётов о повышении продуктивности, не учитывая возможное негативное влияние.
• Участники критикуют слепую веру руководства в возможности ИИ, сравнивая это с маркетинговой шумихой и отмечая отсутствие у менеджеров технических знаний.
• Генерируемый ИИ контент (тексты, код) часто описывается как низкокачественный, многословный и неточный, что увеличивает нагрузку на сотрудников, вынужденных его проверять и исправлять.
• Обсуждается парадокс: внедрение ИИ, призванное повысить эффективность, может привести к её снижению из-за роста бюрократии и производства бесполезного контента.
• Некоторые предлагают саботировать требование отчётов, используя для их генерации тот же ИИ или просто выдумывая результаты.

Сейчас кодирующие агенты вроде Claude Code работают медленно и ненадёжно, напоминая dialup-модемы 90-х: частые сбои, необходимость перезапусков, скорость генерации всего 30-60 токенов в секунду. Это связано с взрывным ростом потребления токенов — по данным OpenRouter, объёмы выросли в 50 раз за короткий период, а агентные workflows требуют в 1000 раз больше ресурсов, чем обычные чаты.

Более высокая скорость, например 2000 токенов в секунду (как у Cerebras Code), кардинально меняет опыт: разработчик становится узким местом, а не модель. Это открывает путь к новому этапу — параллельным независящим агентам, которые предлагают несколько вариантов решения задачи с автоматической оценкой качества. Однако рост скорости лишь разгоняет спрос, создавая бесконечный цикл: чем лучше модели, тем сложнее задачи, которые мы им ставим.

• Скептицизм относительно реального повышения продуктивности из-за LLM: AI может создавать иллюзию продуктивности, снижая когнитивную вовлеченность и порождая проблемы с качеством и сопровождением кода.
• Ключевая проблема — скорость и контекст: Медленная генерация токенов и постоянное переключение контекста нарушают состояние потока (flow), а ограничения контекста приводят к ошибкам и галлюцинациям.
• Сдвиг роли разработчика: Инструмент меняет фокус с написания кода на проверку, редактирование и управление AI-агентами, что требует постоянной бдительности и новых навыков.
• Зависимость от надежности провайдеров: Сбои в работе AI-сервисов сравнимы с остановкой производства, что создает риски для рабочего процесса.
• Разные стратегии и предпочтения в использовании: Одни разработчики ценят интегрированные в IDE решения (Cursor), другие предпочитают сторонних агентов (Claude, Codex) или используют LLM как «калькулятор» для рутинных задач и обучения.

А если ИИ — обычная технология?

• Гипербола вокруг ИИ напоминает предыдущие технопаники: от электричества до интернета.
• Прошлые прорывы тоже вызывали страхи массовой безработицы, но в итоге создавали новые рынки.
• Статистика: 60 % рабочих мест США связаны с профессиями, которых не существовало в 1940 г.
• ИИ пока лишь автоматизирует задачи, а не целиком профессии; человек + алгоритм эффективнее чистого ИИ.
• Риски есть: монополизация, дезинформация, биооружие, но они регулируемы, как и у других технологий.
• Вывод: ИИ может стать «просто» очередным инструментом, усиливающим экономику, а не разрушающим её.

• Участники спорят, «нормальная» ли это технология или исключительная: кто-то сравнивает ИИ с калькулятором для слов и Excel, кто-то ждёт сингулярности.
• Соглашаются, что LLM — мощный инструмент повышения производительности, но не разумный агент и не волшебство.
• Основной ценностью видят 10-30 % экономии времени на черновой текст/код, а не «взрывной» рост или исчезновение профессий.
• Указывают на препятствия: высокие расходы энергии, налоги регуляторов, нехватка «ручных» API для агентов, размытая ценовая модель.
• Прогнозы умеренные: ИИ изменит многое, но не всё и не мгновенно; реальные последствия проявятся, когда нынешние школьники выйдут на рынок труда.

Стратегии

• Химия прежде всего
  ADHD — биологическая проблема; стимуляторы — первое, что работает. Всё остальное дополняет лекарства, а не заменяет их. Если один препарат не подошёл, пробуйте другие, не мучайтесь «силой воли».

• Память
  Todo-лист = внешняя память. Всё, что не записано, исчезнет. Используйте любой удобный инструмент и держите его синхронизированным.

• Энергия
  Сон, еда, движение. Дефицит любого из них убивает фокус быстрее ADHD. Мелатонин в 20:00 превращает «лечь спать» из подвига в естественное желание.

• Прокрастинация
  Разделите «выбор задачи» и «выполнение». Сначала план, потом действие. Планируйте вечером, когда мозг свежий; выполняйте утром, когда решение уже принято.

• Интроспекция
  Ведите журнал: что помогает фокусу, что мешает. Ищите паттерны, корректируйте среду и привычки.

• Время
  Календарь должен быть единым и безжалостным: встречи, дорога, обед — всё в нём. Повторяющиеся события автоматизируют рутину.

Тактики (хитрости)

• Выбор задачи
  Делайте список «три важных» на день. Остальное — бонус.

• Визуальное поле
  На столе только то, что нужно прямо сейчас. Всё остальное убирается.

• Чек-ин проектов
  Каждое утро 5 минут: что двигаю, что заблокировано, что следующий шаг.

• Централизованные входящие
  Все уведомления, почта, мессенджеры — в один «инбокс». Остальные каналы отключены.

• Inbox Zero / Bankruptcy
  Либо обрабатывайте каждое сообщение до конца, либо раз в месяц нажимайте «отметить всё прочитанным» и начинайте с чистого листа.

• Работайте на своих условиях
  Если нужна музыка, шум, стоячий стол — сделайте так. Не геройствуйте в чужой системе.

• Опрос вместо прерываний
  Отключите push-уведомления; проверяйте почту по расписанию.

• Напарник по ответственности
  5-минутный звонок «что сделал за день» повышает вероятность выполнения в 2-3 раза.

• Используйте OCD против ADHD
  Создайте ритуалы: одна и та же музыка при запуске работы, один и тот же напиток. Мозг быстро привязывает ритуал к фокусу.

• Мастер рутины
  Самую скучную задачу делайте в одно и то же время; превратите её в автоматизм.

• Дорога в календаре
  Время в пути = событие. Это убивает опоздания и нереалистичное планирование.

• Инструменты
  Не ищите идеальное приложение. Выберите одно, настройте и живите с ним минимум месяц.

Ресурсы

• Книги: Driven to Distraction, Taking Charge of Adult ADHD.
• Подкасты: «ADHD Experts», «Translating ADHD».
• Сообщества: r/ADHD, ADHDAlien, HowToADHD (YouTube).

Итог
Медикаменты открывают дверь, системы удерживают её открытой. Пробуйте, записывайте, корректируйте.

• Основной вывод: стимуляторы остаются первой линией терапии ADHD; все остальные стратегии работают лишь как дополнение.
• Пользователи делятся лайфхаками: добавляйте выполненные задачи в TODO, чтобы потом отметить и получить дофамин; ведите «Captain’s Log» для быстрого возвращения в контекст.
• Часть людей не переносит стимуляторы: ищут альтернативы (atomoxetine, modafinil, bupropion) или полагаются на mindfulness, глицин, CBD-weed.
• Диагностика и получение рецепта — узкое место: длинные очереди в NHS, сложности с бумагами, страх «не той» диагностики.
• Подчеркивают важность проверки щитовидной железы и упоминают о PDA/RSD как возможных причинах прокрастинации, которые статья обошла.

Купи быстрый процессор

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

Подписка на AI-инструменты вроде Cursor стоит $480/год, а топовый Ryzen 9 9950X — всего $500. Амортизация за 3 года = $170/год: дешевле, чем AI, и выгода очевидна.

Бенчмарки

• Корпоративный ноутбук 2024 (i7-1165G7, 2020 г.)
• Лучший ThinkPad 2024 (Ryzen 7840U)
• Десктоп 2025 (Ryzen 9950X)

Разница — >10× на компиляции ядра Linux и TLS-операциях. 3 с против 30 с или 300 мс — это кардинально меняет опыт.

Правило:

• Десктоп ≈ 3× быстрее ноутбука
• Топ-CPU 2025 ≈ 3× быстрее топа 2022
• Новые облачные VM тоже 2-3× быстрее за ту же цену

Если вы оправдываете AI-подписку, оправдайте и лучший инструмент — быстрый CPU.

• Почти все согласны: «быстрый процессор = меньше ожидания компиляции → выше продуктивность», и ROI для старших разработчиков окупается за недели.
• Но выгода сильно зависит от задач: многие уже компилят в облаке/сервере, а фронтенд-сборки всё равно тормозят из-за однопоточных инструментов.
• Некоторые 10-летние CPU (i7-4770, Phenom II) всё ещё «достаточно быстры», если добавить RAM и SSD; апгрейд не всегда оправдан.
• Ноутбуки ограничены теплопакетом: «топ-чип в лэптопе ≠ тот же чип в десктопе».
• Итог: берите максимально быстрый десктоп, если компилируете локально; если работаете в облаке — экономьте деньги и нервы.

Миф о 23 минутах 15 секундах
Популярная фраза «переключение контекста отнимает 23 мин 15 с» не подтверждается исследованиями. В статье The Cost of Interrupted Work фиксируется лишь повышенный стресс, но не время восстановления; в тексте цифра 23 не встречается. Другие работы упоминают 11–16 мин или вообще не приводят значений.

Источник мифа
Автор просмотрел 23 поста: 9 ошибочно ссылаются на статьи, 9 — на интервью с Глорией Марк, где она озвучила 23 мин 15 с; ещё 2 — на Wall Street Journal, цитирующий Марк. Печатного первоисточника найти не удалось.

• Участники обсуждают, сколько времени требуется, чтобы вернуться к задаче после прерывания; часто упоминается цифра «23 минуты 15 секунд», но её происхождение вызывает сомнения.
• Некоторые чувствуют физическую боль при выходе из потока, другие замечают, что стоимость зависит от сложности задачи, характера прерывания и эмоционального фона.
• Утверждается, что научные публикации и СМИ часто искажают результаты исследований, приписывая им цифры, которых в оригинале нет.
• Предложены способы смягчения эффекта: pair-programming, заранее спланированные задачи, медитация, прогулки или полный «выходной» после неудачного дня.
• Менеджеры подчеркивают ценность доступности для помощи коллегам, но разработчики жалуются на «мелкие» прерывания, которые разрушают контекст.

• Недавние записи
  Архив блога

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

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

• Забавно, что в 2025 мы нередко делаем противоположное. Пример: Бобу нужен новый рабочий компьютер. Его просят написать 4 абзаца обоснования. Он просит LLM сгенерировать текст и отправляет менеджеру.

• Менеджер получает длинное письмо, копирует его в LLM и просит резюме в одном предложении: «Нужен новый компьютер, старый медленный и мешает продуктивности». Заявку одобряют.

• Я называю это «инфляцией LLM»: легко превращать короткое и простое в длинное и видимо глубокое — и обратно, длинное и «глубокое» в короткое и простое.

• Это не упрёк LLM. Но стоит задуматься, почему мы раздуваем контент: в лучшем случае поощряем туманность и трату времени; в худшем — скрываем отсутствие ясной мысли. LLM лишь обнажают масштаб. Возможно, это подтолкнёт нас к изменениям!

• 2025‑08‑06 10:50 — Более раннее

• Обновления: Mastodon, Twitter, RSS, e‑mail

• Сноски:
  И, разумеется, теория информации, но здесь важны практические эффекты.

• Комментарии

• Обсуждение вращается вокруг “инфляции текста” из‑за LLM: люди генерируют лишнюю прозу для бюрократических требований, а получатели затем используют LLM для сжатия обратно до сути.
• Многие считают проблему культурной и организационной: длинные форматы служили фильтром/сигналом усилий и «критического мышления», но с LLM этот сигнал обесценился.
• Часть участников утверждает, что инфляция текста существовала и раньше; LLM лишь ускорили процесс и обнажили масштаб пустых формальностей.
• Другие видят в этом шанс: нормализовать краткость, требовать брифы/буллеты, а при необходимости поручать LLM расширение текста на стороне читателя.
• Встречаются скепсис и критика вымышленных кейсов (например, про “4 абзаца” для покупки ПК) как нереалистичных или оправдывающих бюрократию.
• Предлагаются альтернативные метрики и взгляды: оценивать модели по способности к компрессии информации; замечается, что «формальная вежливость» и сигналы статуса в языке подпитывают многословие.
• Общий вывод: инструменты генерации/суммаризации меняют баланс доверия и сигналов в коммуникации; организациям стоит переосмыслить процессы и поощрять ясность и краткость.