Hacker News Digest

Строим продукты ИИ в эпоху вероятностей

Мы живём в момент, когда инструменты обогнали наши модели их понимания. ИИ изменил саму природу софта: вместо детерминированной функции F: X → Y мы получаем статистическое распределение.

Классическая эра

До ИИ продукты были предсказуемы: нажал «отправить» — сообщение ушло. Именно поэтому вся отрасль строилась на 100 % надёжности: SLO-дэшборды, тесты, аккуратные рефакторинги. PM и дизайн тоже сводились к прокачке воронок с заранее заданными входами и целями.

Новая реальность

С ИИ выход y стал вероятностным: один и тот же промпт может дать разные ответы. Это ломает привычные процессы:

• Инженерия перестаёт быть «написать код → проверить тесты». Теперь нужно управлять распределениями, подбирать промпты, валидировать выборки.
• Продукт больше не сводится к фиксированному набору фич. Модель сама генерирует новые пути ценности, а цели могут меняться по ходу использования.
• Организация требует новых ролей: «prompt engineer», «eval lead», «AI safety analyst».

Что делать

1. Отказаться от 100 % SLO. Достаточно 95 % качества при 10× скорости релизов.
2. Оценивать не функцию, а распределение. A/B тесты уступают место оценке статистических хвостов.
3. Строить обратную связь в цикл. Пользовательские данные теперь не просто метрика, а способ «дообучать» поведение модели на лету.

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

• Критики считают статью псевдонаучной: излишнее математическое оформление, «LinkedIn-философия» и игнорирование необходимости детерминизма в критичных системах.
• Автору вменяют ошибку: вероятностная система не является функцией, а «переход к квантовой теории» называют переходом к недетерминизму, а не «вероятностному детерминизму».
• Многие напоминают, что человечество всегда строило гибкие инструменты; жёсткая детерминированность ПО — скорее исключение, и будущее, вероятно, объединит детерминированные обвязки с вероятностными ядрами.
• Ряд участников подчёркивает: текущие LLM-агенты ненадёжны, «GPU-powered bullshit engine» не заменит проверенную инженерную практику, а «переписывать всё каждые три недели» — нереалистично.

Два месяца писал код только с Claude Code. Поначалу — восторг: задачи летят, коммиты сыплются.
Сейчас, когда приложение разрослось, всё затормозилось. Парадокс: само приложение умеет запускать множество копий Claude Code, и я держу одновременно 5 инстансов, пока придумываю новые фичи.

Задержка появляется при проверке PR. Каждый приходится локально применять, читать логи, просить Claude чинить собственные ошибки.
Объём кода огромен, но скорость воспринимается как мучительно медленная: после первого «ускорения» хочется, чтобы всё так же летело. Это затягивает.

Пока Claude остаётся QA-инженером, который требует контроля. Не верю, что CLAUDE.md решит проблему: правил-то он едва придерживается, а уж комплексные интеграционные тесты — тем более.

Пока что продолжаю мёржить PR вручную, вешать git-хуки за качество и «мчаться» по задачам, пока не выяснится, что модель придумала несуществующие методы библиотеки, и придётся вырезать Clerk и писать GitHub OAuth с нуля.

• Участники обсуждают «проблему золушки»: задача должна быть достаточно большой, чтобы оправдать описание и ревью, но не настолько, чтобы LLM «утонула».
• Ключевой узкое место — человек: быстро генерируемый AI-код всё равно требует внимательного прочтения и понимания.
• Нужно сразу задавать архитектуру и контролировать её, иначе проект быстро разрастается хаотично; README и тесты помогают, но сами тесты иногда «ломаются» или игнорируются агентом.
• Эффективные подходы: дробление задач на 4-5 мелких, запуск нескольких специализированных агентов (док-мен, безопасность, оптимизация), строгая типизация и CI-хуки для поимки галлюцинаций библиотек.
• Некоторые считают, что LLM-программирование — это отдельная дисциплина, где привычные паттерны не работают, а «медленно и гладко» оказывается быстрее в итоге.

Как «борцы за свободную науку» подавляют критику
Сжатая версия личного рассказа Тимоти Нгуена

• Контрарные популяризаторы (Вайнштейн, Хоссенфельдер, Китинг, Джаймунгал) строят имидж защитников «запретных» идей, но сами травят оппонентов.
• Geometric Unity (GU) — «теория всего» Вайнштейна, не имеющая научной ценности; физики игнорируют её, что подаётся как доказательство «подавления».
• Моя рецензия 2021 г. стала первым подробным разбором GU; вместо научного ответа последовали угрозы и попытки «отменить» меня.
• Хроника давления
  1. Вайнштейн требует удалить рецензию, обещает «разобраться лично».
  2. Его окружение (включая Хоссенфельдер) распускает слухи о «подлоге» и «травле» Вайнштейна.
  3. Подкастеры Китинг и Джаймунгал отказываются обсуждать критику GU, опасаясь «разрушить комьюнити».
• Итог: «свободное исследование» превратилось в шоу, где лояльность важнее фактов, а критика объявляется «враждебной».

• Участники обсуждают, как Сабина Хоссенфельдер со временем вышла за рамки своей экспертизы и стала производить более популярный, спорный контент.
• Тимоти Нгуен, напротив, выглядит как пример добросовестного исследователя, который терпеливо добивается научной ясности.
• Эрик Вайнштейн критикуется за уклонение от прямого научного обсуждения и за поведение, напоминающее продажу «змей-в-масле».
• Некоторые подчеркивают, что вся эта публичная драма — скорее интернет-развлечение, чем настоящая наука, которая должна решаться в журналах и на конференциях.
• Есть мнение, что алгоритмы YouTube и экономика внимания подталкивают популяризаторов к всё более провокационным и менее точным заявлениям.

Rust — это язык с жёсткой внутренней связностью.
Он не сложен из-за плохой документации, а потому что его концепты переплетены: замыкания, трейты, заимствование, Send/Sync, итераторы и прочие вещи нужны сразу. Поняв их, вы получаете мощный и последовательный инструмент.

Мини-пример.
20 строк кода на Rust, отслеживающие изменения файлов:

use notify::{Watcher, RecursiveMode};
fn main() -> Result<(), notify::Error> {
    let mut w = notify::recommended_watcher(|r| {
        if let Ok(e) = r {
            println!("{:?} {:?}", e.kind, e.paths);
        }
    })?;
    ["pages", "templates", "static"].iter()
        .try_for_each(|p| w.watch(p.into(), RecursiveMode::Recursive))?;
    loop { std::thread::park(); }
}

Даже здесь нужно знать: Result, замыкания, итераторы, трейты Display, 'static, Send.
На JavaScript то же заняло бы 5 строк и не потребовало бы ни трейтов, ни заимствований.

Вывод.
Внутри Rust прячется «меньший, чище» язык с ясным видением: безопасность без сборщика мусора, абстракции без потерь, композиция через трейты. Этот язык появляется, когда все части складываются в единую картину.

• JS-пример из поста содержит несколько багов (null-файл, for-in вместо for-of), которые TypeScript не всегда ловит.
• Автору ставят в вину, что он «забыл» упомянуть async/await, Promise, модули и прочие скрытые концепции JS.
• Комментаторы спорят, можно ли выкинуть из Rust «половину» фич и остаться при этом «малым и чистым»; большинство считает, что нет.
• Многие советуют новичкам не начинать с Rust: компилятор будет целыми днями выдавать ошибки, прежде чем программа запустится.
• Несколько человек упоминают Gleam, Zig и Austral как «упрощённые» альтернативы, но подчёркивают, что это уже другие языки.

• Коротко: крупнейший австралийский банк CBA вынужден вернуть 45 уволенных сотрудников после того, как профсоюз доказал, что руководство солгало о «росте производительности» чат-бота.
• Как было: в июле CBA объявил, что голосовой бот сократил поток звонков на 2 000 в неделю, и сократил людей, работавших в службе поддержки иногда десятилетиями.
• Факт: на деле звонки росли, банк давал овертайм и даже ставил менеджеров на линии, чтобы справиться.
• Разбирательство: профсоюз FSU подал в Fair Work Tribunal; CBA признал, что «ошибся в прогнозе» и роли не были избыточными.
• Сейчас: уволенным предложили вернуться, перевестись или уйти с компенсацией; банк извинился.
• Контекст: Bloomberg ранее прогнозировал, что глобально банки могут сократить до 200 000 мест из-за ИИ, но случай CBA показывает, что поспешные автоматизации могут обернуться против самих банков.

• У большинства пользователей чат-боты решают <5 % обращений; чаще всего они лишь перенаправляют к FAQ или человеку.
• Снижение количества звонков (CBA: –2 000/нед) объясняют не эффективностью ИИ, а тем, что клиенты просто сдаются и не звонят.
• Компании рассматривают поддержку как расход, а не как способ укрепить доверие; результат — дешёвые, бесполезные боты.
• Союз заставил CBA вернуть уволенных сотрудников, но банк не понёс других последствий.
• Исключения (Amazon, UPS) возможны, но требуют серьёзных инвестиций и настройки; при «режиме экономии» ИИ в поддержке работает плохо.

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

95 % компаний не получают отдачи от $30 млрд, потраченных на генеративный ИИ, — MIT

• Исследование MIT: только 5 % проектов приносят измеримую пользу.
• Причины: нечёткие KPI, отсутствие данных, недостаток навыков персонала.
• Вывод: без стратегии и качественных данных ИИ превращается в дорогую игрушку.

• 5 % проектов приносят деньги, 95 % — нет: основная причина — отсутствие чёткого плана и метрик.
• Реальные экономии уже есть: автоматизация пост-обработки звонков в кол-центрах экономит миллионы.
• Рынок перегрет: многие запускают «AI-инициативы» ради хайпа и финансирования, не ради пользы.
• Компании тратят деньги на консультантов и маркетинг вместо решения конкретных задач.
• Наблюдается спад доверия («Trough of disillusionment»), но технология остаётся ценной как встроенная функция, а не как отдельный продукт.

Ключевая идея:
Используем не сырые показания сенсоров, а «поведенческие» признаки (шаги, сон, ЧСС, калории и т. д.), извлечённые из носимых устройств. На их основе обучаем фундаментальную модель (FM) с архитектурой BERT-подобного трансформера.

Данные:

• 1,2 млн человек, 1,3 млрд дней наблюдений (Fitbit).
• 7 категорий признаков: активность, сон, ЧСС, калории, BMI, возраст, пол.
• Представление временных рядов: токенизируем каждый день (max 512 токенов), добавляем «класс» токен для задачи предсказания.

Обучение:

• 110M-параметровый трансформер, MLM + задача предсказывать следующий день.
• 16 GPU, 3 дня.

Результаты:

• На 15 задачах здоровья FM превосходит CNN/RNN/LSTM/GBDT на 6–18 % AUROC.
• Особенно сильно улучшение при малых выборках (до +25 %).
• Zero-shot перенос на NIH All of Us (≈ 12 тыс. человек) без дообучения сохраняет 90 % качества.

Абляции:

• Удаление любой группы признаков падает AUROC на 1–3 %.
• Уменьшение модели до 35 M параметров теряет 2–4 %, но всё ещё лучше бейзлайнов.

Применение:

• Личные «цифровые двойники» для раннего выявления диабета, гипертонии, депрессии.
• Данные и веса модели будут открыты.

• Apple-2025: новая «фундаментальная» модель переходит от сырых сенсорных данных к поведенческим биомаркерам (HRV, ЧСС покоя и др.) и показывает высокую точность для ряда заболеваний.
• Участники удивлены: в ~10 задачах модель проигрывает простому демографическому базлайну, а где выигрывает — лишь «чуть-чуть».
• Нет открытых весов и данных из-за соглашений с участниками Apple Heart and Movement Study; доступен лишь экспорт личных XML-файлов.
• Для самостоятельного анализа годятся HealthKit/Swift или сторонние бета-инструменты.
• Обсуждаются риски приватности и интерес страховых компаний к таким данным.

Unity Industry
Превращайте 3D-данные в интерактивные приложения, которые повышают эффективность и достигают бизнес-целей.

• 30-дневный пробный период бесплатно.
• Купить или посмотреть демо.

---

Преимущества

• Реал-тайм 3D: быстрый вывод продукта, оптимизация ресурсов.
• Принятие решений: пространственные визуализации ускоряют согласование.
• Экономия: меньше дублирования, ниже себестоимость.
• Кроссплатформенность: 20+ платформ — от мобильных до VR.

---

Возможности

• Импорт CAD/BIM через Unity Asset Transformer Toolkit (70+ форматов).
• Управление активами в Unity Asset Manager (облако).
• Создание и симуляция реалистичных сцен и процессов.
• Развёртывание на AR/VR, веб, десктоп, мобильные устройства.

---

В составе

• Unity 6: быстрый рендер, AI, мультиплатформа.
• Unity Asset Transformer Toolkit (бывший Pixyz).
• Unity Asset Manager: облачное DAM для 3D-активов.
• Build Automation: CI/CD для сборки и деплоя.

Узнать больше

• Unity не возвращала «Runtime Fee» для игр: новая 4 % отчисления касаются только лицензии «Industry» для неигровых продуктов.
• Сообщество критикует Unity за плохую коммуникацию, непрозрачные цены и «contact sales», что выглядит как попытка «выжать» клиентов.
• Многие разработчики уже мигрируют или советуют Godot/Unreal, считая Unity ненадёжным партнёром, способным менять условия в любой момент.
• Некоторые напоминают, что специальные лицензии для неигровых рынков существовали лет 10, но теперь процент берут прямо с выручки.

ChartDB — инструмент для интерактивной визуализации схем БД.
Поддерживает PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, CockroachDB, MongoDB.

Ключевые возможности

• Импорт схемы одним кликом из любой поддерживаемой СУБД.
• Авто-раскладка таблиц и связей; ручное перемещение.
• Экспорт в форматы PNG, SVG, PDF.
• Режим «одной страницы» для быстрого просмотра.
• Поиск и фильтрация по названию таблицы или столбца.
• Тёмная и светлая темы.

Быстрый старт

1. Открыть chartdb.io.
2. Нажать «Import from DB», вставить строку подключения или SQL-дамп.
3. Получить готовую схему за секунды.

• Некоторые команды продолжают рисовать ERD и документировать именно схему БД, особенно при проектировании новых фич и онбординге.
• Другие полагаются на абстракции вроде ORM/DDD и считают диаграммы избыточными, особенно для типовых SaaS с generic auth и payment.
• Инструменты вроде dbdiagram.io, Lucidchart и ChartDB спросом пользуются, но часто ломаются при >15 таблиц или требуют изучения нового UI.
• Сторонники диаграмм аргументируют: «базы живут дольше абстракций», а отсутствие документации — потеря для индустрии.