Hacker News Digest

• Fine-tuning is making a comeback as a niche tool for specific tasks, but the debate is whether it's worth the effort vs. using larger models with better prompting.
• The community is split: some see it as essential for control, IP ownership and cost savings, while others argue that frontier models have made it redundant for most use cases.
• Key friction points: cost-benefit of training vs. inference, data-labeling overhead, and whether the juice is worth the squeeze when prompt-engineering can achieve similar results.
• OpenAI, Anthropic and others are quietly re-opening fine-tuning APIs, while simultaneously pushing the narrative that "you don't need it anymore"—a tension that may be more about GPU budgets than user needs.
• The open-source community is rallying around LoRA and QLoRA as a compromise, but the real question is whether the economics of serving a custom model will ever make sense versus just paying per-token for a larger model.

• OpenAI запустила «AI Economic Index» — карты востребованных навыков и подбор вакансий для тех, кого её же модели вытеснили с рынка.
• Сервис анализирует миллионы объявлений, показывает, какие знания (например, промпт-инженерия) сейчас ценятся, и подсказывает, где учиться.
• Критики: компания сначала разрушает рабочие места, а теперь продаёт «палку-выручалочку»; данных о реальном числе потерянных профессий всё ещё нет.

• Участники спорят, действительно ли ИИ уже «съедает» рабочие места или пока лишь повышает продуктивность и сокращает штат постепенно.
• Крупные ИИ-компании, проповедуя «этику», одновременно разрабатывают замену самим же пользователям, используя их бесплатные данные для обучения моделей.
• Примеры реального вытеснения: OCR-переводчики, редакторы новостей, тех-поддержка 1-го уровня, джуниор-разработчики и рутинные офисные задачи.
• Walmart упоминается как крупнейший работодатель, но речь идёт о розничных, а не инженерных позициях; собственные IT-команды компании уже подвергались сокращениям.
• OpenAI предлагает «сертифицировать» 10 млн американцев к 2030-му и матчить их с корпорациями, что многие воспринимают как попытку монетизировать созданную ею же дезинформацию и дисбаланс рынка труда.

Не создавайте мульти-агентов

Фреймворки для LLM-агентов разочаровывают. Ниже — выжимка из нашего опыта и почему популярные идеи работают плохо.

Принципы контекст-инжиниринга

1. Делитесь контекстом целиком
2. Действия несут скрытые решения

Пока в мире LLM мы как в 1993-м с HTML: нет стандарта. Библиотеки вроде OpenAI Swarm и Microsoft Autogen продвигают мульти-агентов, но это, по нашему опыту, ошибка.

Почему мульти-агенты хрупки

Классическая схема:

• разбить задачу на подзадачи,
• запустить под-агентов,
• собрать результат.

Проблема: каждый уровень теряет детали. Пример: «сделай Flappy Bird» → под-агенты делают фон Mario и птицу, не похожую на оригинал. Сводить такие части — головная боль.

Принцип 1
Передавайте не сообщения, а полные трейсы агента.

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

• Пользователи обсуждают, что «агенты» — это просто разные промпты к одному и тому же API, а не отдельные сущности.
• Основная проблема — «размывание» контекста: при ~50 k токенов агенты теряют цель, поэтому многие отказались от сложных мульти-агентных схем в пользу одного агента + умного управления контекстом.
• Предложено строить «компиляторы контекста» вместо ручной курирования и использовать фиксированные pipeline-ы вместо свободно общающихся агентов.
• Некоторые сравнивают подход с супервизорами Erlang, но большинство считает это переизобретением старых идей.
• Общий вывод: пока нет надёжности, мульти-агентные системы неэффективны; начинать стоит с простейших блоков и адаптировать под свою задачу.

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».

Как собрать код-агента: бесплатный воркшоп

Материалы и исходники: GitHub

Суть

• Агент — это 300 строк кода, работающие в цикле, которому просто подаются токены LLM.
• Поняв принцип, вы перестанете быть потребителем ИИ и станете его продюсером, автоматизируя свою работу.

Зачем

• В 2025 г. знание, как создать агента, стало фундаментальным навыком, как понимание primary key.
• Работодатели ищут тех, кто может оркестрировать ИИ внутри компании.
• Во время Zoom-звонка ваш агент может уже писать код, который вы только обсуждаете.

Что будет на воркшопе

• Live-сборка агента прямо во время доклада.
• Объяснение внутреннего устройства: цикл, токены, промпты.
• Практика: агент строит агента под диктовку.

Дальше

• Если хотите, чтобы я провёл такой воркшоп у вас в компании — пишите.

• Команда Princeton SWE-bench выложила компактный (~100 строк) агент для SWE-bench.
• Пользователи жалуются на перегруженный AI-слайд-стиль и избыточные картинки, которые мешают чтению.
• Спор о необходимости отдельных инструментов: многие действия можно делать через bash, но специализированные утилиты экономят токены и повышают надёжность.
• Обсуждают, что «токены = деньги» и что локальные модели могут изменить ситуацию.
• Критика: пост показывает лишь базовый подход, не раскрывая продвинутые темы (sandbox, snapshot, prompt-инженерия).

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

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