Hacker News Digest

Специалист по поисковой оптимизации создал сайт с 50 000 вымышленных статистических данных, чтобы проверить, как большие языковые модели выбирают источники. Домен stateglobe.com был сгенерирован за один день с помощью GPT-4.1 примерно за 30 долларов, позже добавили ещё 15 000 списков — итого около 50 долларов. Ни одна цифра не проверялась, но именно эти фальшивые числа начали распространяться по сети.

Результат оказался неожиданным: Google почти сразу деиндексировал сайт после двух обновлений, оставив лишь 5–20 показов. Зато ChatGPT за семь месяцев направил на ресурс более 10 000 сессий, а свыше 330 доменов — включая Shopify, Bluehost и DHL — сослались на выдуманные данные. Они попали даже в академическую работу и инвестиционное исследование банка. Автор объясняет это тем, что модели ищут «надёжные» цифры для заполнения пробелов в знаниях, а статистика выглядит убедительно.

Для отслеживания эффекта он советует смотреть логи серверов на активность ботов вроде ChatGPT-User и PerplexityBot, сессии из чат-ботов в GA4, новые ссылающиеся домены и упоминания без ссылок. При этом подчёркивает: публиковать заведомо ложные данные нельзя, эксперимент носил исследовательский характер, а сайт теперь содержит дисклеймер. Тактика может перестать работать, и она не должна быть основой всей стратегии.

Тред подтверждает, что фальшивая статистика легко попадает в обучающие наборы LLM, становясь источником дезинформации. Текущие механизмы фильтрации недостаточны: без надежного отбора источников модели цитируют любые сайты, включая вымышленные данные. Проблема «citogenesis», когда недостоверные сведения становятся базой для новых цитат, усиливается автоматическими скреперами. Мнения о решении разделились: @ShadowOfThePit предлагает ограничить модели официальными источниками и строго фильтровать веб, тогда как @nurrysbek считает это нереалистичным и полагается на улучшенное обоснование, признавая невозможность полного искоренения лжи. Поскольку SEO-спам и фальшивый контент давно манипулируют поисковиками, а LLM лишь ускоряют их распространение, борьба требует совместных усилий разработчиков моделей и поисковых систем. В качестве мер предлагается обучать классификаторы для отделения сгенерированного текста от человеческого, использовать API государственных статистических служб вместо запросов к LLM и внедрять пост-обработку с проверкой фактов.

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

Масштаб проблемы шире одного человека: шестеро или семеро знакомых из группы по «DevOps» потеряли работу или получили уведомление за последний месяц, включая сотрудника одной из FAANG-компаний, которому выдали шесть месяцев выходного пособия и уничтожили личные вещи. Другой нанимающий менеджер лишился должности через неделю после того, как генеральный директор запоздало опубликовал статью о том, что «ИИ меняет разработку». Автор подчёркивает: корректнее говорить не «ИИ забрал мою работу», а «ИИ поспособствовал упразднению моей роли».

При этом модели, по его мнению, всё ещё не заменяют опытного инженера: им не хватает вкуса в продуктовых решениях и предвидения последствий — роста издержек, сложности, доступности. Но они уже достаточно хороши, чтобы под присмотром переносить проверенное поведение между платформами: «Shopify» переписал приложение с «React Native» на нативный код, а порт «TypeScript» на «Rust» воспроизвёл даже исходные баги. В итоге модели не заменили людей — они убедили тех, у кого есть деньги, тратить их иначе.

Тред подтверждает, что компании увольняют инженеров ради экономии, заменяя их дешевыми подписками на AI-модели (например, Fable), или используют ИИ как предлог для сокращений ради краткосрочной прибыли (@glimshe, @philipodonnell). Это напоминает прошлый опыт замены сотрудников дешевым аутсорсингом (@voidifremoved, @TrackerFF). Мнения о возможностях LLM разделились. @gregwebs и @echelon считают, что модели уже способны генерировать готовый код, поэтому роль инженера трансформируется в техническое руководство и управление ИИ. Другие (@dofm, @TrisEck) уверены, что моделям не хватает вкуса и продуктового чувства. @jdw64 приводит пример приложения на моделях Astra и Fable, которое оказалось полно багов, что доказывает невозможность полной замены квалифицированного программиста. Пострадавшим инженерам советуют создавать собственные проекты с помощью тех же моделей для сохранения дохода (@laylower), а также относиться к работе как к средству, а не центру жизни (@sajithdilshan, @danw1979).

Shopify переходит обратно на нативную разработку мобильных приложений после пяти лет успешного использования React Native. В 2020 году выбор фреймворка был обусловлен необходимостью избегать дублирования функций, расширить круг разработчиков и снизить затраты на поддержание паритета между iOS и Android. Эти преимущества реализовались: команда экономила время, привлекала специалистов без мобильного опыта и сосредотачивалась на доставке ценности. Однако к концу 2025 года фундаментальное предположение о стоимости дублирования труда изменилось благодаря прогрессу больших языковых моделей (LLM). Shopify начал использовать ИИ с 2021 года, и к 2025-м агенты стали способны не только ускорять написание кода, но и выполнять перевод функций между платформами, помогать в наboardingе разработчиков и обеспечивать проверку кода и тестов на основе общих спецификаций. Это снизило нагрузку по поддержанию паритета до уровня, когда нативная разработка перестала быть непрактичной.

Теперь Shopify считает, что преимущества нативной разработки — близость к платформенным возможностям, доступ к первым-party инструментам и меньшее количество абстракционных слоёв — вновь перевешивают выгоды от共享 кода. Компания не отказывается от React Native резко: она планирует чистый переход, продолжая поддерживать свои открытые библиотеки (например, Reanimated и React Native Skia), которые стали лидерами в своих нишах. Одновременно Shopify активно нанимает мобильных инженеров и специалистов на стыке ИИ и разработки. Переход не отрицает прошлых успехов: React Native был правильным выбором в 2020 году благодаря усилиям сотен инженеров и поддержке сообщества, включая Meta, Software Mansion и Уильяма Кандильона. Накопленный опыт и инструменты останутся фундаментом для будущей мобильной стратегии Shopify.

Переход Shopify на нативную разработку обусловлен ростом сложности React Native, нестабильностью библиотек, проблемами с обновлениями и несоответствием с платформенными фреймворками, что повышает стоимость поддержки. LLM значительно снижают стоимость генерации и поддержки нативного кода, делая миграцию экономически целесообразной даже для крупных продуктов — даже без глубокого знания Swift или Kotlin. Нативная разработка обеспечивает лучшую производительность, стабильность и контроль над платформой, особенно в сложных сценариях отладки. Отказ от React Native устраняет угрозы цепочек поставок npm. Даже без LLM миграция оправдана из-за высокой стоимости поддержки абстракции, что подтверждается опытом команд до 2026 года. Споры остаются: отказ от OTA-обновлений критичен для быстрорастущих компаний; сложность отладки крашей в JS, C++ и нативных потоках не устраняется LLM и может быть дороже поддержки двух кодбаз. Рекомендации: стартапам React Native и Flutter остаются разумными для MVP; после зрелости — переход на нативный код для контроля качества и производительности. При миграции важно отделить бизнес-логику от UI, чтобы LLM могли тестировать состояние через CLI. Использование агентов требует строгого контроля зависимостей и тестов — иначе компания рискует стать зависимой от нестабильных LLM. Нативные инструменты (Jetpack Compose, SwiftUI) становятся более предсказуемыми, а LLM эффективнее работают с прямым доступом к платформе, чем через слои абстракции. Ранее привлекательный аргумент «React Native для веб-разработчиков» устарел: LLM позволяют генерировать нативный код без знания платформенных языков. Опыт показывает, что React Native-проекты часто превращаются в «junk show» из-за нестабильности и низкого качества библиотек. Снижение стоимости генерации кода LLM меняет баланс: дублирование кода теперь дешевле, чем поддержка абстракции без полного контроля. Индустрия движется к отказу от высокоуровневых абстракций в пользу нативного кода.

Компания Tailwind Labs, разработчик популярного фреймворка Tailwind CSS, объединяется с компанией Shopify. Основатель Tailwind Labs начал работать над фреймворком более 9 лет назад, с целью создать инструмент, который облегчит построение красивых интерфейсов для своих проектов. Сегодня фреймворк устанавливается более 110 миллионов раз в неделю и используется многими крупными компаниями, включая ChatGPT, X, Cloudflare, Reddit и Shopify.

Присоединение к Shopify обеспечит Tailwind CSS стабильный долгосрочный дом, где он будет активно поддерживаться для миллионов пользователей. Основатель Tailwind Labs подчеркивает, что Shopify предоставляет уникальную возможность для разработки фреймворка в рамках реального продукта, решающего важные проблемы для реальных людей. Кроме того, Shopify была одной из первых компаний, которая оценила потенциал Tailwind CSS и начала использовать его для своих проектов. После объединения, фреймворк останется открытым и будет поддерживаться командой Tailwind Labs при участии Shopify.

Приобретение Tailwind Shopify подтверждает: бизнес-модель на продаже UI-шаблонов и коммерческих продуктов для CSS-фреймворков разрушена ИИ — генерация кода заменила необходимость в готовых компонентах. Tailwind UI и Plus перестали быть рентабельными: пользователи перешли на чистый CSS, так как ИИ устраняет рутину написания стилей, а Tailwind добавляет сложность без выгоды. Трафик документации упал на 40% с начала 2023 года, несмотря на рост популярности фреймворка; 75% инженеров Tailwind Labs уволены из-за падения доходов. Tailwind стал де-факто стандартом разработки интерфейсов — его ценность теперь в доминировании, а не в монетизации. Shopify покупает не продукт, а команду и бренд для контроля над стандартом и удержания доверия разработчиков. Это acqui-hire: цель — не коммерческий актив, а ключевая команда. ИИ уничтожает модели «мы уже решили за вас»: если продукт можно воспроизвести по документации, платить за него бессмысленно. Разработчики используют линтеры, чтобы сдерживать хаос от неконсистентного применения Tailwind-классов, генерируемых ИИ. Некоторые считают Tailwind избыточным: utility-классы — плохой дизайн, CSS Modules или чистый CSS с современными возможностями — предпочтительнее. Технологии вроде Stylex (Meta) становятся более привлекательными для ИИ — их структура лучше подходит для генерации, чем утилитарные классы. Бизнес-модели DevTools теперь требуют масштабирования: хостинг или управление инфраструктурой, а не продажа кода, который ИИ генерирует бесплатно. Снижение доходов — не из-за качества, а потому что ИИ устранил боль, которую Tailwind решал.

Мы заменили Redis‑хранилище резервов на MySQL и смогли выдержать нагрузку в $5,1 млн продаж в минуту в 2025 году.
Ключевая идея — по одной строке на каждый товарный остаток, а не на одну строку на товар с колонкой количества. Это позволило использовать SKIP LOCKED, получая конкурентный доступ к отдельным единицам и избегая конфликтов при одновременных покупках.

Получилось два важных вывода. Во‑первых, старые ограничения (одна строка‑количество) устарели: современные версии MySQL уже поддерживают нужный уровень изоляции, и их стоит перепроверить при росте нагрузки. Во‑вторых, простая прототипная проверка (небольшой скрипт, мониторинг блокировок) раскрыла реальный узел — избыточное использование соединений, а не «медленные» запросы. В итоге система стала надёжнее: больше нет перепродаж и больше завершённых покупок, а база остаётся здоровой для всех остальных процессов.

Тред критикует подход Shopify к резервированию товаров, предлагая альтернативы: отдельная строка на заказ-товар или фоновый возврат товаров в запас. Участники согласны, что денормализация повышает производительность, но может вызывать проблемы с согласованностью и блокировками. Рекомендуется шардирование таблицы запасов по ID магазина для снижения нагрузки. Некоторые считают Shopify шагом назад — вместо Redis используется диск-ориентированная БД, не справляющаяся с десятками тысяч одновременных соединений. Хотя готовые решения проще, в данном случае они могут быть неоптимальны.

Pi — это лёгкий, но мощный фреймворк для агентного программирования, который сознательно отказывается от «тяжёлых» системных промптов и множества встроенных инструментов. Его ядро состоит всего из четырёх базовых средств, а полный набор инструкций и описаний укладывается в менее 1 000 токенов. Такая «контекстная дисциплина» позволяет модели работать в узком рабочем пространстве, экономя ресурсы и ускоряя выполнение.

В независимых исследованиях, включая оценку Databricks на многомиллионной кодовой базе, Pi продемонстрировал наивысший проходной коэффициент при значительно меньшей стоимости за задачу по сравнению с Claude Code и Codex. Аналогично, в кейсе Shopify команда создала собственный набор расширений поверх Pi, сохранив минимализм, но получив гибкость для построения кастомных рабочих потоков. Такое сочетание дешевизны, скорости и возможности добавлять только действительно нужные инструменты делает Pi идеальным как для крупных корпораций, так и для локальных моделей с ограниченным контекстом.

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

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

Ключевые ошибки работодателей — устаревшие представления о длительном онбординге и интервью, сфокусированные на алгоритмах, а не на реальных навыках. Джуниоры, свободные от шаблонов, часто превосходят сеньоров в гибкости и скорости обучения. Чтобы найти лучших, стоит искать кандидатов вне традиционных каналов, например, среди тех, кто не прошёл в Y Combinator, но проявил инициативу.

• Сложности найма джунов из-за заучивания LeetCode и использования ИИ в учебе, снижения страсти к профессии.
• Риски найма слабых джунов и необходимость эффективных фильтров для выявления талантов.
• Переизбыток выпускников CS на фоне сокращения числа вакансий для новичков.
• Важность реального опыта для джунов и конкуренции с ИИ.
• Разные подходы к оценке джунов: сложные задачи vs. простые, проверка мышления и сотрудничества.

Автор, известный как «парень из Bundler», рассказывает о 15-летней истории проекта, который он помогал развивать с 2010 года. Изначально созданный Yehuda и Carl, Bundler быстро стал стандартом управления зависимостями в Ruby, сохранив свою структуру до версии 2.7.2. После ухода основателей автор взял на себя ведущую роль в поддержке, сотрудничая с Terence Lee и позже основав Ruby Together для финансирования разработки.

Сейчас Ruby Central заявляет права на владение названием Bundler, что противоречит духу сообщества. В ответ автор зарегистрировал товарный знак, чтобы защитить репутацию проекта и его maintainers, подчеркивая, что код остаётся под MIT-лицензией, а название принадлежит сообществу. Ключевая цель — обеспечить, чтобы решения по проекту принимались самими пользователями и разработчиками, а не одной организацией.

• Финансирование Ruby Central от спонсоров вроде Shopify было условием захвата контроля над Bundler и RubyGems, что привело к корпоративному захвату инфраструктуры.
• В ответ на это был зарегистрирован товарный знак Bundler, чтобы предотвратить захват и передать его под управление нового, действительно сообщественного органа.
• Ключевой риск — потеря давних мейнтейнеров, раскол сообщества и форк ключевой инфраструктуры, что создаст хаос.
• Сообщество ожидает ответа от Ruby Central, включая возобновление запланированного Zoom-звонка, но пока ситуация в подвешенном состоянии.
• Под вопросом юридическая сила товарного знака, так как его долгое отсутствие enforcement может означать отказ от прав или генерализацию.

Ruby Central, испытывающая финансовые трудности после потери спонсорства Sidekiq ($250 тыс. в год), по требованию Shopify взяла под контроль ключевые проекты Ruby-сообщества — Bundler и RubyGems — без согласия их многолетних сопровождающих. Shopify пригрозила отозвать финансирование, если Ruby Central не обеспечит полный контроль над репозиториями и правами на gems, что привело к принудительному изменению прав доступа и исключению ведущих разработчиков, включая Андре Арко с 10-летним стажем.

Этот захват был преднамеренным: Shopify заранее организовала дежурство для замены прежних сопровождающих, а совет Ruby Central проигнорировал предупреждения о незаконности действий и альтернативы в виде форков. Инцидент подчеркивает риски зависимости open-source от корпоративного финансирования, где сообщество теряет автономию под давлением спонсоров.

• Sidekiq прекратил спонсорскую поддержку Ruby Central на $250 тыс. в год из-за участия DHH в RailsConf 2025, что вызвало споры о его политических взглядах.
• Shopify и Ruby Central взяли под контроль инфраструктуру RubyGems и Bundler, удалив ключевых мейнтейнеров, официально — для усиления безопасности supply chain.
• Сообщество раскололось: часть видит в действиях Shopify корпоративный захват, другие — необходимые меры после недавних атак на npm.
• Критики обвиняют Ruby Central в злоупотреблении властью и плохой коммуникации, особенно после передачи прав на репозитории без консенсуса.
• Наблюдатели отмечают, что конфликт усугубляется давними культурными разногласиями в сообществе Ruby, выходящими за рамки технических вопросов.

Tempo — блокчейн первого уровня, созданный для платежей. Поддерживает все основные стейблкоины, обеспечивает 100 000+ TPS, финальность <1 сек, предсказуемые минимальные комиссии и встроенную приватность. Разработан Stripe и Paradigm при участии Visa, Deutsche Bank, Shopify, Revolut и др.

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

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

Для разработчиков

EVM-совместимый, нейтральный к стейблкоинам, нативный обмен между ними, документация скоро.

Доступ

Сейчас приоритетный доступ к тестнету для партнёров.
[partners@tempo.xyz](mailto:partners@tempo.xyz?subject=Requesting access to Tempo)

• Stripe запускает «блокчейн» Tempo под стейблкоины, чтобы ускорить и удешевить движение денег между своими клиентами.
• Критики считают проект маркетинговым трюком: вместо децентрализованной сети — закрытая база данных под контролем Stripe и партнёров.
• Главная выгода — регуляторный арбитраж: стейблкоины пока обходят банковские нормы, позволяя хранить и переводить доллары без классических банков.
• Технически ничего нового: высокая пропускная способность достигается за счёт централизованного набора валидаторов; Ethereum-совместимость нужна лишь для совместимости с инфраструктурой.
• Бизнес-кейсы — мгновенные выплаты, ликвидность между странами и спасение от медленной банковской инфраструктуры в ЛатАмерике и Азии.