Hacker News Digest

Краткие мысли о LLM и разработке ПО
Мартин Фаулер, 28 авг 2025

Собираясь в отпуск, хочу поделиться набросками о текущем состоянии LLM.

1. Опросы о влиянии ИИ на разработку
   Большинство используют LLM как «умный автокомплит» (Co-pilot), но те, кто получает реальную пользу, заставляют модель напрямую читать и редактировать файлы. Игнорируя различия в подходах, исследования дают искажённые данные.

2. Будущее программирования
   Никто не знает, что будет дальше: исчезнут ли джуны, вытеснят ли сеньоров. Единственный совет — экспериментируйте сами и делитесь деталями рабочих процессов.

3. Пузырь ИИ
   Это пузырь, как и при любой технологической революции. Он лопнет, но неизвестно когда и какие компании выживут (после dot-com упали Pets.com и Webvan, но не Amazon).

4. Галлюцинации как фича
   Rebecca Parsons утверждает: галлюцинации — не баг, а главная особенность LLM. Поэтому:

   • Задавайте один и тот же вопрос несколько раз с разной формулировкой.
   • Сравнивайте ответы, включая числовые — минимум три раза.
   • Не просите LLM считать то, что можно вычислить детерминированно; лучше попросите сгенерировать код для расчёта и всё равно проверьте его.

Жду встречи с коллегами на GOTO Copenhagen — не выступаю уже пару лет, но скучаю по общению.

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

CLI-агенты: зачем покупать, если можно собрать

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

Архитектура

• База: Pydantic-AI + LLM
• MCP-серверы (плагины):
  • запуск кода в песочнице
  • актуальная документация библиотек
  • AWS-инструменты
  • поиск в интернете
• Desktop Commander – полный доступ к файловой системе (осторожно!)

Как мы росли

1. Старт: простой CLI-запуск тестов.
2. Интеллект: добавили системные инструкции и распознавание намерений.
3. MCP: подключили песочницу Python, доки, AWS, поиск.
4. Оптимизация: длинные цепочки рассуждений, структурированные ответы.

Полученные выводы

• Прозрачность: видим каждый шаг.
• Контроль: сами решаем, что разрешено.
• Гибкость: легко добавить новый MCP-сервер.

Дальше

• GUI-обёртка, CI/CD-интеграция, автоматические PR.
• Публикация MCP-серверов как open-source.

Собственный агент дешевле, понятнее и точнее подходит под ваши правила.

• Большинство участников хвалят Pydantic AI за отзывчивую команду, лёгкое расширение API и гибкую модель агента без DAG.
• Некоторые жалуются на баги при работе с редкими фичами (Azure OpenAI, стриминг) и предпочитают самописные решения или LiteLLM.
• Есть сомнения в стабильности работы с Pydantic-моделями: кто-то добивается лучших результатов «вручную», минуя библиотеку.
• Обсуждаются альтернативы и затраты: Claude Code дешевле API Sonnet 4, SWE-bench дорог для оценки код-агентов, LiteLLM проще в документации.

Blocky Planet — демо на Unity, превращающее кубические воксели Minecraft в полностью разрушаемую сферическую планету из 20+ блоков.

Частые вопросы

• Где играть? Бесплатно на itch.io (Windows + web).
• Зачем? Вдохновился старым демо Jordan Peck и хотел добавить текстуры и масштабное разрушение.
• Будет ли игра? Вряд ли: мало времени, а путь от демо до релиза огромен.
• Сколько времени? ~1 месяц по 15 ч/нед. Пост занял вдвое дольше.
• Стек: Unity 6, C#, Job System + Burst, но без DOTS.
• Код? Пока закрыт — стыдно.
• Текстуры? Нарисованы вручную или скриптами; многие блоки ≈ шум + тонировка.
• Идеи/вопросы? Пишите в реддит-пост.

Делаем сферу

Простой способ — отфильтровать блоки внутри заданного радиуса, но тогда гравитация не совпадает с «верхом» блоков. Нужно:

1. Наложить 2D-квадратную сетку на 3D-сферу.
2. Сохранять ширину блоков при удалении от центра.

Карта без искажений — миф

Гаусс доказал: без искажений не обойтись. Попытки втиснуть глобус в прямоугольник дают чудовищные искажения у полюсов.

• Автор продемонстрировал работающий «кубический» voxel-мир на сфере, где основной проблемой остаётся вертикальное искажение.
• Комментаторы сравнили проект с Space Engineers, Seed of Andromeda, PlanetSmith, Minetest и другими попытками создать «Minecraft на планете».
• Предложены альтернативы: геодезические сферы, торо-сфера (Eco), шестигранные воксели, HEALPix, S2, а также уменьшение игрока при приближении к ядру.
• Пользователи отметили удовольствие от орбитальной механики и мечтают о гибриде Minecraft + Kerbal Space Program.

Люди слишком уверены в себе. В коде это проявляется так:

if currentLocation.distance(to: target) < 100 {
    print("Вы прибыли!") // А точно ли? 🤨

GPS-координаты приблизительны, но Bool требует выбора. Мы «схлопываем волновую функцию» слишком рано.

В 2014 г. исследователи предложили тип Uncertain<T>, встроенный в систему типов. Я портировал идею на Swift:

import Uncertain

let loc = Uncertain<CLLocation>.from(currentLocation)
let nearby = loc.distance(to: target) < 100
if nearby.probability(exceeds: 0.95) {
    print("Вы прибыли!") // с 95 % уверенности
}

Сравнение возвращает не Bool, а Uncertain<Bool> — вероятность истинности. Под капотом используется распределение Рэлея и метод Монте-Карло; выборка происходит только при необходимости, а SPRT экономит вычисления.

let speed = 400 / Uncertain<Double>.normal(mean: 60, sd: 5)
let ok = speed < 6
print(ok.probability(exceeds: 0.9))

Такой подход делает неопределённость первоклассной и заставляет писать более умный код.

• Обсуждение крутится вокруг идеи «Uncertain<T>» — типа данных, который носит и распространяет неопределённость (ошибки, распределения вероятностей) через обычные вычисления.
• Участники вспоминают похожие подходы: interval arithmetic, вероятностное программирование, fuzzy logic, а также библиотеки Boost, gvar, monad-bayes и Pyro.
• Отмечают, что GPS-ошибки редко бывают круглыми и независимыми; важно учитывать ковариацию и корреляции между переменными.
• Кто-то мечтает о таблицах, где можно вводить «1 m ± 10 cm» и получать правильную пропагацию погрешностей, а кто-то — о языках, где «Uncertain» был бы типом по умолчанию.
• Главный вопрос: почему, несмотря на множество реализаций, такие типы всё ещё не стали мейнстримом в продакшене.

• Китайские инструменты (Shadowsocks, V2Ray/Xray с VLESS/Trojan/Reality, Clash) считаются самыми продвинутыми против цензуры.
• Надёжный способ — арендовать собственный VPS за границей и поднять WireGuard, OpenVPN, AmneziaWG, SSH-SOCKS или Outline.
• Если протоколы блокируют, применяют обфускацию: WebSocket, HTTP/3 (QUIC), Amnezia, XTLS-Reality, wstunnel.
• Готовые антицензорские клиенты: Psiphon, Tor + Snowflake, Obscura, Outline, AmneziaVPN.
• Не стоит полагаться на коммерческие VPN — их быстро блокируют; лучше иметь несколько резервных методов.

Pong Clock — ретро-хронометр в стиле Pong, адаптирован под мобильные экраны 4:3 с высокой чёткостью.

Поддержать проект можно через PayPal: £2–£10 или любая сумма в GBP, EUR, USD, AUD, CAD, JPY, NZD, CHF, SEK, NOK.

Для работы часов необходим JavaScript.

• Пользователи в восторге от идеи «Pong-clock», но хотят точно 1 секунду между ударами.
• Кто-то фантазирует, что за ракетками сидят «хранители времени», а промах ускоряет жизнь на Земле.
• Некоторые жалуются: промахи выглядят ненатурально (ракетка просто отъезжает вверх), и предлагают сделать их правдоподобнее.
• Дали консольный «чит-код» для форс-промаха и скрипт, который ускоряет мяч до одного отскока в секунду.
• Участники делятся ссылками на тематическую музыку и готовые скринсейверы, а один собирается запустить проект на старом телевизоре через Raspberry Pi.

Почему военные заслуживают права на ремонт
Лейтенант-полковник Синди Серрано Робертс (в отставке)

Во время развертывания в Баладе, Ирак, я, молодой лейтенант ВВС, получила сообщение: «Генератор вышел из строя, льда не хватает для тел погибших. Сколько ждать?»
Я отвечала за генераторы, но не была техником и не имела нужных деталей. Единственный резервный агрегат находился на другом конце страны. Выбор был: запускать долгий контракт с гражданским специалистом или отправить конвой — рискуя жизнями. Мы пошли вторым путём и выиграли.

Но что, если бы не повезло?

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

Поэтому я поддерживаю право на ремонт.

• Участники сходятся во мнении, что Пентагон как крупнейший покупатель вполне может требовать в контрактах право на ремонт, но по разным причинам этого не делает.
• Поднимаются примеры: техника ломается после 5 000 миль без выезда в поле, генератор в морге не могут починить без долгого найма подрядчика.
• Некоторые считают, что проблема не в законе, а в том, что ремонт выгоднее отдавать подрядчикам, чем делать технику простой в обслуживании.
• Предлагают требовать не только доступ к запчастям и документации, но и исходники ПО и полные лицензии на конструкцию.
• Есть опасение, что даже если военные получат RtR, гражданские останутся без этих прав: документацию выдадут под NDA.

PINE64 сообщает:
PinePhone Pro временно недоступен. Причина — нехватка компонентов и задержки на фабрике. Поставки возобновятся, как только появятся чипы RK3399S и экраны. Точную дату пока не назвали.

• Пользователи сочли PinePhone Pro неудачным продуктом: устаревшее «железо», критические аппаратные дефекты, баги в базовых функциях и отсутствие нормального ПО.
• Высокая цена (≈ 600 € в Европе) и плохая поддержка покупателей (поломанные устройства, враждебная политика возвратов) добили интерес.
• Многие ждут «карманный Debian-компьютер» с клавиатурой и сотовой связью, но считают, что Pine64 не смогли сделать ни аппарат, ни софт «на уровне ежедневного драйвера».
• Некоторые надеются на альтернативы: Librem 5, Fairphone + PostmarketOS, FuriPhone, MNT Pocket Reform, StarLite-планшет, но признают, что Linux-телефоны пока остаются нишей.

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

Vibe-кодинг глазами ветерана

Эксперимент
2 недели, 40 часов, 5 k строк Python: AI-агент и я пишем микро-игру с алгоритмами A*, Minimax и пр. Цель — проверить, вытесняет ли LLM «искусство программирования».

Процесс

• Промптинг: описываю задачи естественным языком, AI генерирует код.
• Рефакторинг: «сделай класс короче», «добавь тесты» — срабатывает 80 %.
• Отладка: трассировка стека + «почему падает?» — LLM быстро находит баги.
• Архитектура: за меня выбирает структуру пакетов, но я корректирую.

Что понравилось

• Скорость: MVP за 3 вечера.
• Меньше рутины: никаких «import os.path.join».
• Новые идеи: AI предложил кэш-стратегию, которой я не планировал.

Что не так

• «Галлюцинации» API: методы, которых нет в библиотеке.
• Сложные баги: race condition LLM не видит без контекста.
• Читаемость: имена вроде helper_utility_v2 приходится переименовывать.

Выводы

• Junior-девелопер теперь = «человек, который умеет спрашивать».
• Сеньор нужен, чтобы фильтровать, тестировать и нести ответственность.
• Синтаксис умирает, зато растёт ценность системного мышления и prompt-инженерии.

Советы ветеранам

1. Делайте микро-промпты: «добавь docstring» → «добавь пример вызова».
2. Держи CI/CD: автотесты ловят ошибки, которые AI пропустил.
3. Используй AI как пару, а не замену: «покажи diff» вместо «перепиши всё».

Итог
Vibe-кодинг не убивает профессию, а сдвигает фокус: от написания символов к управлению смыслом. Сборочная линия есть, но над ней всё ещё нужен человек с вкусом.

• Участники сравнивают LLM с консалтинговой фирмой: 50 % шанс получить эксперта, 50 % — стажёра; приходится перечитывать каждую строку.
• «Vibe-coding» (генерация без чтения) вызывает опасения: сложно дебажить, нельзя защитить авторские права, а тонкие баги пролезают.
• Опыт показывает: AI полезен в известных языках и задачах (Python, CRUD), но почти бесполезен в нишевых (C/C++ gamedev, Prolog, Haskell).
• Старшие разработчики всё равно нужны: только они могут проверять, направлять и «владеть» кодом, созданным ИИ.
• Возникает вопрос: если не брать джунов, откуда возьмутся будущие сеньоры?
• Предлагают термины вместо «vibe-coding»: «pro-coding», «prompt-coding», «reviewing code».