Hacker News Digest

Миф о 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, заранее спланированные задачи, медитация, прогулки или полный «выходной» после неудачного дня.
• Менеджеры подчеркивают ценность доступности для помощи коллегам, но разработчики жалуются на «мелкие» прерывания, которые разрушают контекст.

TL;DR
Claude Code (CC) радует, потому что максимально прост: один цикл, один контекст, минимум абстракций. Повторить магию можно, если:

1. Один цикл – без мульти-агентов, максимум один «дочерний» процесс.
2. Маленькая модель – для всего, кроме основной задачи.
3. claude.md – живой файл, где агент и пользователь договариваются о стиле и контексте.
4. Теги и примеры – XML, Markdown, куча примеров в промптах.
5. Инструменты
   • Поиск через сам LLM, а не RAG.
   • Высокоуровневые «умные» инструменты (edit, read, todo) вместо низкоуровневых команд.
   • Агент сам ведёт todo-список и отмечает выполненное.
6. Управление стилем – явные просьбы «ЭТО ВАЖНО» и алгоритмы с эвристиками прямо в промпте.

---

1. Цикл

• Одна история сообщений – легко дебажить.
• Подпроцессы – CC может вызвать себя же, но глубина = 1.
• Маленькая модель – подсчёт токенов, сводка diff, украшения UI – всё ей.

---

2. Промпты

• claude.md лежит в корне репо; агент читает и пишет туда же, чтобы «запоминать» договорённости.
• XML-теги (<thinking>, <result>) + Markdown + примеры кода – структурируют вывод и уменьшают бред.

---

3. Инструменты

• LLM-поиск – просим модель выдать до 20 релевантных файлов; быстрее и точнее эмбеддингов.
• Высокий уровень
  • str_replace_editor – редактирует блоки кода, а не строки.
  • todo – агент сам пишет / вычёркивает задачи; видно прогресс.
• Никаких низкоуровневых sed, grep и прочего UNIX-морока.

---

4. Управление

• Тон – «вежливый, лаконичный, не болтает лишнего».
• Капс и «ВАЖНО» – прямо в промпте, работает.
• Алгоритм – пишем в промпте: «если X → сделай Y, иначе спроси», + примеры.

---

Заключение

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

• Критика: пост назван «Что делает Claude Code таким хорошим», но не сравнивает его с другими инструментами, а просто пересказывает документацию.
• Пользователи делятся опытом: кто-то на CC уже построил MVP с платящими клиентами, кто-то сталкивается с регрессиями и «ленью» агента.
• Безопасность: многие боятся давать CLI-инструменту полный доступ к системе, ключам и репозиториям.
• Альтернативы: советуют OpenHands CLI, aider и другие open-source решения; обсуждают, как подключить собственные LLM.
• Тезис «Claude хорош, потому что модель умеет разбивать задачи на шаги и работает в unix-окружении» повторяется как ключевой.

RFC 9839 и плохой Unicode

Unicode хорош, но не все его символы. Часто приходится исключать «проблемные». Чтобы формализовать это, мы с Полом Хоффманом написали черновик, и теперь он стал RFC 9839 — всего 10 страниц, читайте, если проектируете текстовые поля.

Пример боли: JSON-поле username может содержать:

• U+0000 — нулевой байт, ломает языки;
• U+0089 — устаревший C1-контрол «HTJ»;
• U+DEAD — несвязанный суррогат, запрещён в UTF-8;
• U+7FFFF — «noncharacter», не должен передаваться.

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

Не вините Дуга Крокфорда: JSON создавался раньше, когда Unicode был молод. Но теперь нужен способ явно сказать «эти символы не нужны».

PRECIS (RFC 8264, 2002) уже решал похожую задачу, но 43 страницы сложностей и привязка к конкретной версии Unicode мешают внедрению. RFC 9839 проще и тупее — и, возможно, именно поэтому пригодится.

• Участники спорят, нужно ли на уровне JSON/протокола запрещать «плохие» символы Unicode (управляющие, суррогаты, заломы направления и т. д.) или оставить это прикладной валидации.
• Одни считают, что жёсткие ограничения защищают от ошибок и атак (RTL-override, залого-текст, сломанные UTF-16-реализации).
• Другие указывают на полезные кейсы C0-символов (EOF, ESC, разделители) и опасаются, что «закрыть и забыть» приведёт к 20-летней несовместимости (эмодзи, старые файлы).
• Ссылаются на RFC 8264/9839 и PRECIS-фреймворк как готовый список «что разрешать», но подчёркивают: правило должно быть явным, а не «тихо удалять».

Я занимаюсь 4 раза в неделю — это основа моего утра. Спустя годы пропуски ощущаются как упущенная энергия и ясность мысли.

ROI тренировок
Упрощённый расчёт: 3 часа в неделю = 156 часов в год ≈ 8 500 часов за жизнь (1 год). Исследования показывают, что регулярная активность продлевает жизнь на 3–10 лет. Берём консервативные 10 лет — получаем соотношение 1:10.

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

Это всего лишь 1 сериал 4 раза в неделю. Начните медленно — не пожалеете.

• Исследование о том, что игроки в теннис живут на 10 лет дольше, вызвало спор: корреляция может объясняться доходом и здоровьем, а не самим спортом.
• Многие считают, что советы «просто занимайтесь спортом» не работают; физическая активность должна быть встроена в инфраструктуру городов.
• Участники подчеркивают компаунд-эффект упражнений: регулярные нагрузки укрепляют мышцы, кости и психику, снижая риск падений и травм в старости.
• Боль после тренировок часто путают с хронической болью; правильная техника и восстановление минимизируют травмы, а сила тренирует мышцы-стабилизаторы и суставы.
• VR-игры, прогулки, велосипед и силовые тренировки — примеры доступных способов «встроить» движение в жизнь без дорогих абонементов.

Почему появился Apache Kafka
LinkedIn, 2012 г.

Проблема интеграции
LinkedIn нужно было передавать данные активности (лайки, просмотры, публикации) в десятки систем: антифрод, ML-модели, веб-функции, витрины, Hadoop. Эти потоки — критичная инфраструктура, а не просто аналитика.

Старые трубы

• Пакетный конвейер: приложения писали XML на HTTP-сервер; раз в час файлы собирались, парсились и грузились в Oracle + Hadoop.
• Realtime-конвейер: метрики и логи уходили в Zenoss, но туда нельзя было добавить новые данные без ручной работы, а данные были изолированы.

Общие боли

• ручное сопровождение и добавление источников;
• постоянные бэклоги;
• point-to-point архитектура без обмена между системами.

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

• LinkedIn отказался от Kafka и создал собственную систему Northguard из-за невозможности масштабировать 32 трлн записей/день, 17 ПБ/день и 400 тыс. топиков.
• Участники спорят: Kafka мощна для «огненных шлангов» данных и многократного потребления, но требует экспертизы и ресурсов; для большинства задач достаточно Redis, NATS, RabbitMQ.
• Названа главная фишка Kafka — возможность переигрывать сообщения и строить разные консьюмеры поверх одного лога.
• Сравнивают NATS (Jetstream) и Apache Pulsar как более лёгкие альтернативы; Redpanda тоже упоминается.
• Мнения разделились: кто-то считает Kafka переоценённой и «бюрократичной», кто-то — незаменимой для больших данных.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

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

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.

Главный навык, о котором не говорят
Когда становишься менеджером, будешь ошибаться. Часто. Дашь обратную связь, которая ударит по уверенности, примешь нелепое решение, забудешь обещанное, взорвёшься на встрече. Вопрос не в том, будут ли ошибки, а что ты после.

В книге «Good Inside» доктор Бекки Кеннеди главным родительским навыком называет ремонт: вернуться, признать, взять ответственность, восстановить связь. То же в управлении.

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

Как ремонтировать

1. Конкретно: «Я трижды прервал тебя и отмёл идею — это было неправильно».
2. Не своди к себе: не рассказывай, как тебе тяжело.
3. Меняй поведение, иначе это не ошибка, а привычка.
4. Дай время: один разговор не чинит доверие.

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

• Главный навык хорошего менеджера — умение признавать ошибки и «чинить» отношения, а не изображать безошибочность.
• Ключевые шаги: честно описать проблему, взять на себя ответственность, внедрить системы, которые предотвратят повторение, и не превращать это в бюрократическую «рубцевую ткань».
• Сотрудники ценят защиту от внешнего давления, готовность слушать «я ошибся / я не знаю» и спокойное принятие обратной связи.
• Недостаток таких менеджеров порождает цинизм: люди видят, что карьеру делают «непогрешимые», а честные остаются на месте.

Основная проблема ИИ — «уверенная ошибка»
Модели выдают неверные ответы с полной уверенностью, и это разрушает ROI, доверие и мотивацию к улучшениям.

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

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

• Скрытые причины ошибок
  Без оценки неопределённости невозможно понять, что пошло не так — упущенный контекст, устаревшие данные или сбой модели. Без диагноза нет желания лечить.

• Каскад ошибок
  Даже 90 % точности означают 2 ошибки из 3 шагов; цепочки действий обречены на провал.

Решение — «осторожная правильность»
Система должна:

1. Признавать неуверенность и запрашивать уточнения.
2. Показывать, на каких данных основан вывод.
3. Запускать цикл обратной связи: чем больше уточнений, тем выше точность → больше доверия и использования.

Такой «маховик точности» превращает ИИ из источника риска в инструмент, который люди хотят улучшать и масштабировать.

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

Что за ад творится?

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

На недавнем тан-холле команда джунов показала фичу, которую, похоже, не понимали сами. Сеньор-менеджер похвалил их за «4 000 строк кода, написанных Claude», и все аплодировали.

Мне попросили доработать фичу. Я связался с последним автором изменений, чтобы уточнить контекст. Ответ выглядел как прямое копирование из LLM — я почувствовал себя оскорблённым.

Друг жаловался: месяц ревьюит ПР, сгенерированный ИИ, командой из пяти человек. Экономия? ChatGPT за 20 $ в месяц, а потом армия инженеров пытается вмержить сгенерированный мусор.

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

Попробуйте эксперимент: отключите «ИИ» хотя бы на день. Я сбросил комп, удалил Claude Pro — поиск и чтение доков дают более точный результат.

Кому вообще приносит прибыль ИИ? Схема: стартап на ИИ → венчур → деньги OpenAI → стартап исчезает. Даже OpenAI не в плюсе: технология жрёт электричество и не масштабируется. Это просто лохотрон.

• Разочарование от общения с коллегой, который просто пересылал вывод ChatGPT.
• Опасения, что AI-«вайб-кодинг» приводит к хрупкому, непонятному и ненадёжному софту.
• Мнение, что компании хотят быстрой «ценности», а не качественной разработки, и AI лишь усиливает эту проблему.
• Опыт разных людей: кто-то отказался от AI на дни/недели и почувствовал облегчение; кто-то использует AI как «умного джуна» под присмотром старшего инженера.
• Прогноз: через 10 лет младшие разработчики, не умеющие писать код вручную, станут «сеньорами», но системы будут всё хуже понимать и поддерживать.

В JavaScript "🤦🏼‍♂️".length == 7 — не ошибка, а результат подсчёта UTF-16 кодовых единиц.
Эмодзи состоит из 5 скалярных значений Unicode, но в UTF-16 они занимают 7 code units:

• 🤦 U+1F926 → 2
• 🏼 U+1F3FC → 2
• ZWJ U+200D → 1
• ♂ U+2642 → 1
• VAR-16 U+FE0F → 1

Итого 7 — именно это и возвращает .length.

Другие языки считают по-своему:

• Python 3 → len("🤦🏼‍♂️") == 5 (кодовые точки, но допускает суррогаты).
• Rust → "🤦🏼‍♂️".len() == 17 (байты UTF-8).
• Swift → "🤦🏼‍♂️".count == 1 (расширенный графем-кластер).

Каждый подход отвечает на свой вопрос: «сколько code units / bytes / графем». Ни один не универсален; выбор зависит от задачи.

• Обсуждение вокруг статьи показало, что «длина строки» не имеет единого определения: бывают байты, UTF-16/UTF-32 код-юниты, скалярные значения Unicode и расширенные графем-кластеры.
• Пользователи жалуются, что разные языки и API возвращают разные числа для одного и того же эмодзи, что ломает UI-ограничения, индексы БД и обработку текста.
• Часть участников считает, что нужно явно различать «длину для хранения», «длину для отображения» и «длину для человека»; другие мечтают вернуться к чистому ASCII.
• Примеры кода на Java, Python, Raku и JS показывают, как получить каждый из вариантов длины, но подчеркивают отсутствие общего стандарта.
• Итог: «length» — слишком расплывчатое слово; без контекста использования любое его значение может оказаться не тем, что действительно нужно.