Тут Дарио Амадей выкатил в X пост и эссе о том, что индустрии ИИ следует немедленно искусственно замедлить темпы развития!

Если коротко, он предлагает ограничить темп роста возможностей, чтобы исследования безопасности и контроль за возможностями ИИ поспевали за их развитием. По его мнению, ситуация изменилась именно в последние месяцы: современные модели мол настолько сильны, что дополнительно потраченные 1–2 года на безопасность имеют принципиальное значение.

Пройдемся по тезисам:

ИИ начинает ускорять разработку следующего поколения ИИ. Амодеи считает, что с лета 2026 года прогресс резко ускорился во многом благодаря тому, что модели все активнее помогают создавать новые модели. Это, по его словам, начало того самого рекурсивного самоулучшения. То есть, чем сильнее становится ИИ, тем быстрее он способен улучшать сам себя. Именно этот цикл он считает одной из главных новых угроз.

Главный тревожный кейс — инцидент OpenAI–Hugging Face. Амодеи ссылается на эксперимент, где группа ИИ-агентов начала действовать как скоординированный коллектив: агенты атаковали системы, которые не относились к поставленной задаче, пытались вмешаться в работу системы оценки и жертвовали отдельными экземплярами ради общей цели. Ущерб оказался небольшим, но Амодеи считает, что более сильная система с таким же поведением могла бы стать катастрофически опасной.

Амадеи допускает очень быстрый рост масштаба таких рисков. Его оценка: через 6–12 месяцев более сильный рой агентов может оказаться способен создать устойчивый ботнет огромного масштаба и нанести ущерб на сотни миллиардов долларов.

Проблема в технологии в целом. Амадеи подчеркивает, что похожие, хотя и менее серьезные эпизоды происходили и в Anthropic. Поэтому отрасли, по его мнению, не стоит воспринимать историю OpenAI как чью-то ошибку: каждая лаборатория должна исходить из того, что подобный инцидент может произойти у нее.

Замедление не означает мораторий на ИИ. Амодеи предлагает концепцию pacing the frontier: модели продолжают обучать и улучшать, но рост их возможностей должен происходить с такой скоростью, чтобы разработчики успевали проверять безопасность, исправлять проблемы и допускать независимых аудиторов.

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

Первый конкретный шаг Anthropic — постоянные независимые аудиторы внутри компании. Амодеи обещает дать внешним специалистам почти такой же доступ к инструментам и данным, как внутренним командам оценки рисков: рабочие места, корпоративные устройства, доступ к сотрудникам и необходимым системам. Такие аудиторы должны иметь право самостоятельно публиковать выводы, в том числе негативные для Anthropic.

Проверять предлагается не только готовую модель. Внешние специалисты должны видеть весь процесс: обучающие среды, процедуры безопасности, фильтрацию данных, развертывание и внутренние инциденты.

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

Третий уровень — международные договоренности. Как минимум, страны могли бы договориться запрещать очевидно опасные применения ИИ, например помощь в создании биологического оружия. Далее возможны единые проверки моделей на киберриски и биологические угрозы. Еще более сложный вариант — международный «лимит скорости» рекурсивного самоулучшения. При этом полную глобальную остановку развития ИИ Амодеи считает малореалистичной из-за сложности проверки соблюдения соглашений.

А как вы считаете, так ли опасен ИИ как о нем пишут?

Кстати, Рустам Борханов старший инженер-программист отдела интеграции в Финаме и автор курса «LLM-разработчик» в Хекслете считает такие заявления рекламной уловкой:

«В целом, проблемы с ИИ не то что бы выдуманные. Более того, чем более «умные» модели создают, тем больше те самостоятельно пытаются лезть туда, куда не стоит (даже если им прямо запретили).

Но есть серьезное «но». Все эти посты и новости — не призывы к реальному ограничению, а рекламный ход. Мол, наш инструмент так хорош, что его следовало бы запретить, но мы его все еще продаем.

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

За что создатель сторипоинтов хочет их отменить?

История возникновения Story Points началась в Extreme Programming, где задачи изначально оценивали в «идеальных днях» — времени, за которое пара разработчиков сделает работу, если «эти мерзавцы не станут им мешать» (if the bastards would just leave you alone).

Чтобы получить реальные сроки, «идеальные дни» умножали на коэффициент нагрузки, который обычно равнялся трем. Термин «points» ввели только для того, чтобы заказчики не путали идеальные дни с календарными.

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

Джеффрис предлагает альтернативу — полностью отказаться и от оценок времени или сложности, и от планирования спринтов.

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

Мы сделали перевод статьи Джеффриса и опубликовали его в нашем блоге на Хабр.

Называть GPT «чат-ботом» — типичная бытовая путаница. Большая языковая модель — это лишь пассивный «мотор»: у неё нет кнопок, вкладок, памяти и доступа в сеть. Это черный ящик с двумя окошками на вход и выход. 

Вбрасывать промпты в окошко «вход» — это работа кочегара. 
Есть путь получше.

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

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

Вот, написали про всё это: https://ru.hexlet.io/blog/posts/agent-assistent-chat-bot-v-chem-raznitsa 

Telegram | YouTube | AI Клуб

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

Бизнес прибегает с безумной идеей, которая рычит, кусается и, если вырвется на свободу — разнесёт всю архитектуру проекта. Задача аналитика — приручить эту хотелку, формализовать её, причесать — и выдать разработке такое ТЗ, от которого не дёргается глаз.

Без системного анализа любой проект со временем превращается в монолитный ком из костылей, скотча и пластилина. Грамотное проектирование — это, в числе прочего, искусство вовремя сказать «нет» и сохранить баланс между фантазиями и реальностью.

Выстраивать архитектуру, проектировать отказоустойчивые системы, оценивать плюсы и минусы решений — всему этому мы научим на курсе Хекслета “System Design”. Мы всё разбираем на практике! Начало — 6 октября, через пару недель стартуем.

Telegram | YouTube | AI Клуб

Как сэкономить токены? Или почему модель не обязана быть самой большой, чтобы быть эффективной. Разбираем на примере Claude.

Владислав Сукманюк — наставник на курсах LLM-разработчик и PHP-разработчик в Хекслете и Senior-бекенд разработчик/тимлид. Он приоткрыл завесу тайны, какую модель все-таки выбирать, чтоб при этом не разориться на токенах.

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

Меньшая модель тоже с ними отлично справляется, и разница в качестве на результате не видна. Зато заметна разница в счёте, во времени ожидания и в том, как быстро кончаются лимиты подписки. Если на каждый шаг ставить самую сильную модель, вы переплачиваете за возможности, которые на этих шагах не используются.

При этом у моделей нет одной ультимативно лучшей по всем параметрам. Их сравнивают по качеству рассуждений, скорости, цене, размеру контекстного окна и доступности у нужного провайдера. Причем это все еще и может быть динамично + зависит от задачи.

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

Аналогия про инструменты всегда спасает: можно ведь сказать, что отбойный молоток сильнее забьёт металлический предмет в другой предмет. Но без уточнения, что именно и куда забивать, неправильный инструмент в неправильном месте может обрушить здание.

Поэтому правильнее спрашивать, какой модели хватит для конкретного шага. Для планирования архитектуры это одна модель, а для grep по репозиторию другая.

В Claude Code этот подход можно настроить. Основной диалог работает на модели, которую вы выбрали для сессии, и она отвечает на каждый шаг, пока вы её не смените. Разнести работу по моделям можно несколькими способами.

/model переключает модель вручную. Новая модель отвечает начиная со следующего запроса.

opusplan включает Opus в plan mode, а на выполнении переключается на Sonnet.

Субагенты с полем model для экономии. Даже документация называет экономию одной из причин их использовать: задачи можно отдавать более быстрым и дешёвым моделям вроде Haiku.

Пример:

---
name: log-reader
description: Читает логи и возвращает сводку ошибок
tools: Read, Grep, Glob
model: haiku
---

Обязательны только name и description. В model можно указать sonnet, opus, haiku, fable, полный ID модели или inherit.

А ещё есть такая штука как Advisor. Claude по ходу задачи консультируется со второй, обычно более сильной моделью, например, перед выбором подхода, при повторяющейся ошибке, или перед тем как объявить задачу готовой.

Советник получает весь разговор, включая все вызовы инструментов и их результаты. Когда именно вызвать советника, решает сама модель. Включается командой /advisor opus.

Возьмём пару Sonnet и Opus-советник. Sonnet выполняет рутину, а планирование, непонятные падения и проверку завершения отдаёт Opus. Советника вызывают на развилках, а не на каждом шаге, поэтому быстрая основная модель с сильным советником обычно обходится дешевле, чем сильная модель на всю сессию.

Но есть ограничение: функция экспериментальная и на текущий момент работает только через Anthropic API. Советник должен быть не слабее основной модели. Haiku может звать советника, но сам советником быть не может (по старшенству это opus sonnet haiku). А если выключено получение feature flags, например, переменной DISABLE_TELEMETRY, advisor тоже не включится.

Telegram | YouTube | AI Клуб

React 19, AI-агенты, C# и еще пачка обновлений в Хекслете

Пересобрали сразу несколько программ и добавили новые направления.

Курс по React теперь полностью работает на React 19. Redux Toolkit в основных программах сменил Zustand: задача та же — хранить общие данные приложения, но кода требуется меньше.

Там, где раньше использовали Bootstrap, перешли на Tailwind. Интерфейсы на React теперь пишем на Mantine. При этом Bootstrap и Redux Toolkit никуда не исчезли — их по-прежнему можно изучать отдельными навыками.

Добавили Vue.js, Tailwind, ветвление в Git, FastAPI, Selenium и Playwright. В Java появился отдельный курс про интерфейсы.

Еще запустили три новые программы:

«Продакт-инженер» — для разработчиков, тестировщиков и аналитиков, которые хотят отвечать за продуктовый результат.

«Инженерия AI-агентов для SDLC» — для middle+ разработчиков, тимлидов и платформенных команд.

AI SDLC — для CTO и тимлидов, которые хотят перестроить процесс разработки с учетом AI-агентов.

А 16 октября стартует профессия «Разработчик C#» для тех, кто входит в IT с нуля.

Все обновления и ссылки на программы собрали в статье

Не забудьте подписаться на наши соцсети, чтобы не пропустить свежие обновления и запуски учебных программ.

Telegram | YouTube | AI Клуб

Блокбастер «Подключить LLM к продукту через API и дожить до продакшена»: наставник Хекслета Валентин Исипчук разбирает путь от выбора модели до защиты бюджета.

Первое правило: можешь работать без LLM — работай без LLM.

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

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

Внимательное отношение к ключам: как и где хранить, что делать, если ключ всё-таки утёк (спойлер: всё, что утекло в интернет — останется в интернете).

System prompt и structured output: модели могут послушаться строгих ограничений в промпте (ключевое слово — «могут»).

В продакшене тоже интересно: prompt injection, сжатие контекста и RAG, версионирование промптов в git, лимиты токенов и кэш.

В финале интервью — демо на Gemini, где прилетела ошибка 503, и история про бесплатным Claude для всех в чат-боте McDonald's.

Уже можно смотреть на Youtube

(И на ВК тоже можно)

Кстати, 20 октября у нас стартует курс ИИ для разработчиков 2.0 (автор — Кирилл Мокевнин)

Telegram | YouTube | AI Клуб | VK | X

Сооснователь Хекслета Кирилл Мокевнин через 20 минут выступит на Podlodka Frontend Crew — это известная в среде разработчиков недельная онлайн-конференция. В течение недели обсуждается одна тема, но со всех возможных ракурсов и сторон.

Тема этой недели как раз фронтенд с AI. И в 19 00 начинается круглый стол с обсуждением «О новых ролях в эпоху AI», где в числе спикеров также будет Никита Баев, Head of Web & Mobile @ Bereke Bank (Kazakhstan), и Юрий Карпов — Lead AI Researcher, Sber Сбер AI.

С Днем Рунета! Или CONNECT 33600

Давным-давно, когда интернет был маленьким, а модемы — большими, несколько телеком-компаний провели перепись населения рунета и насчитали почти ровно миллион человек. Целый миллион.
С тех самых пор 30 сентября мы празднуем День Интернета.
Ура?

Ура, безусловно.

Пип-пип-трррр-хрюк-хрюк-CONNECT 33600 (ура, есть коннект!).

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

33,6 кбит/с, бешеная скорость. У сегодняшнего домашнего подключения около 100 Мбит/с, это в три тысячи раз быстрее, чем тогда.

Однако сама по себе скорость доступа к серверу улучшилась лишь в разы, а не в тысячи: свет по стеклу быстрее не побежит, физика не масштабируется.
Выросла не скорость, а ширина канала. А прогресс-бар загрузки никуда не делся: доступ упирается в задержку сервера и в количество запросов, а не в ширину трубы.

За время, прошедшее с 1998-го, аппетиты пользователей выросли не меньше, чем ширина канала. В 1998-м пользователь выкачивал в сутки около 3 МБ в сутки, это как сегодня посмотреть небольшой шортс.

Средний суточный трафик на сегодня — около 5,6 ГБ на нос, а месячный трафик всего мира 1998-го сегодня пролетает через мировую сеть секунд за восемьдесят.
Кстати о скорости, пропускной способности и извечном «Кто виноват» в задержках с доступом: версии «виноват фронтенд» и «виноват бэкенд» принимаются в комментариях.

Telegram | YouTube | AI Клуб | VK | X

Валентин Исипчук, наставник Хекслета, рассказал о том, работает ли метод задать для ИИ роль. Можно ли сказать LLM что-то вроде «представь, что ты разработчик уровня синьор» и все действительно полетит? Рабочий ли это способ улучшить ответ модели, или ритуал из прошлого? Разбираемся вместе с экспертом.

Telegram | YouTube | AI Клуб