Хекслет

ИИ автоматизировал разработку, а проблемы остались? Ошибки в больших проектах возникают не только из-за плохого кода. — Проблемы больших проектов с участием ИИ часто связаны с отсутствием контроля. С агентами — как с людьми: проверять нужно не только конечный результат. Кто-то должен оценивать и архитектурные решения, которые агент принял в ходе работы, — считает наставник Хекслета Валентин Исипчук. — Разработку и ревью нужно разделить между разными агентами. Живой пример: агенту дают элементарную, на первый взгляд, задачу — добавить кеширование ответов внешнего API в большой бэкенд-сервис. Агент пишет рабочий код, добавляет тесты, всё проходит CI. Если смотреть только результат, задача кажется выполненной. Но агент-ревьюер замечает проблему в подходе к решению: агент-разработчик создал кеш внутри конкретного сервиса, хотя в проекте уже и так был общий слой кеширования. В результате появился второй механизм с собственной логикой инвалидирования. Код пока что работает, но через несколько месяцев это решение превратится в источник трудноуловимых багов. Задачу вернули агенту-разработчику. Он переделал реализацию через существующую инфраструктуру. Затем другой агент запустил тесты и удостоверился, что ничего не сломалось. В таких ситуациях разделение ролей и приносит максимальную пользу. Один агент решает задачу, второй смотрит на архитектуру и спорные решения, третий проверяет результат. Дополнительный плюс: у каждого агента своя задача и свой контекст. Агенту не нужно «держать в голове» весь проект и одновременно быть разработчиком, тестировщиком и ревьюером. Чем жёстче разделены обязанности и контексты, тем меньше вероятность, что агент начнёт оправдывать собственные решения. Это гораздо ближе к обычной командной разработке, чем к сценарию «задали промт — получили код — выкатили как есть». Не стоит доверять большой проект одному агенту: он захлебнётся в контексте, перестанет беспристрастно проверять свою работу и начнёт принимать спорные решения. 15 октября на бесплатном воркшопе мы на практике покажем, как довести задачу до готового pull request с помощью команды ИИ-агентов. За полтора часа на реальном примере разберём: - как настроить роли в OpenCode, - что должно быть в AGENTS.md, - как передавать задачи между агентами, - как проводить ревью кода и автоматические проверки перед мержем. Эти вопросы заслуживают того, чтобы потратить на них время. Специалисты посмотрят, как работают другие, а новички увидят принципы и подходы, которые можно применить на практике. Воркшоп проведёт Валентин Исипчук — наставник в Хекслете и практикующий разработчик (бэкенд-инженер на Java и Kotlin из Cyoda, инженер по ИИ-автоматизации). Пароли и явки: 15 октября, 19:00, 1,5 часа, бесплатно. Регистрация по ссылке.

Будущее уже здесь: приключение в трёх частях 1️⃣Часть первая: Скрытая угроза В конце июля Большой Яндекс презентовал программу 75/75/75. Это не вес, не возраст и не пропорции тела. К концу этого года Яндекс хочет добиться вот такой статистики: 👨‍💻 не менее 75% разработчиков будут использовать ИИ-инструменты при написании кода; 🤖 75% изменений на уровне всей компании будут создаваться через ИИ; ↖️ в каждом таком изменении ИИ будет создавать не менее 75% кода. 2️⃣Часть вторая: Атака клонов В конце сентября Сбер открыл открыл для внешнего бизнеса мультиагентное приложение GigaCode Desktop. Это оркестратор команды ИИ-агентов, которые пишут код, собирают аналитику, изучают документацию, пишут отчёты и делают презентации — это разработчики, проджект-менеджеры и тестировщики. Вот что по этому поводу думаеь Евгений Бартенев, старший архитектор облачных, прикладных и AI-решений: «Я бы вообще не называл это каким-то инновационным решением, скорее это вынужденная адаптация к новой реальности. Можно сколько угодно спорить о качестве кода от ИИ, но прямо сейчас он уже достаточно неплохо снимает с разработчика большую часть рутинной работы. Плюс это ещё и вопрос рынка труда: сильному разработчику странно идти туда, где ему принципиально не дают современные инструменты и предлагают работать «как раньше». Поэтому для меня это не столько менеджерско-маркетологическая история, сколько довольно банальная производственная необходимость». 3️⃣Часть третья: Новая надежда Всё это означает, что ИИ берёт на себя работу, на которую всегда приглашали джунов.  От джуна требовали знания синтаксиса и фреймворков, тестирования, умения работать с простыми запросами, навыков работы с Git. Требования поменялись: в дополнение ко всему от джуна будут ждать (да чего уж там — уже ждут) понимания архитектуры, знания алгоритмов и структур данных, навыков в код-ревью и в отладке. И, разумеется, кто-то должен стать погонщиком ИИ-агентов — эта работа тоже ляжет на плечи джуна, хоть и не полностью. Однако вход в разработку никуда не исчез: просто поменялся маршрут, и этот маршрут уже виден. Компании будут искать не тех, кто быстро пишет простой код, а тех, кто понимает, как устроены программы, умеет проверять решения ИИ, находить ошибки, работать с архитектурой и управлять агентами. И раз есть прогноз — то вместо проблемы мы имеем список задач. А у задач всегда есть решения.  Например, можно начать с курса ИИ для разработчиков 2.0...

🎂 Хекслету 14 лет. По этому поводу дарим вторую профессию С 1 по 15 октября при покупке профессии вы получите 10 месяцев базовой подписки. С ней можно самостоятельно пройти вторую профессию — без наставника и ревью. А вот какие программы стартуют в ближайший месяц. 🤖 20 октября — ИИ для разработчиков 2.0 Пять недель агентного программирования: контекст, модели, инструменты, агентный харнес, циклы верификации, Spec Driven Development и интеграция AI в SDLC через GitHub Workflow. Автор курса — Кирилл Мокевнин. Доступ к ИИ-инструментам на время обучения предоставляем, так что отдельно оплачивать подписки не придется. ⚙️ 27 октября — Инженерия AI-агентов для SDLC Для middle+ разработчиков, тимлидов и платформенных команд. Разберем агентный харнес изнутри: цикл, инструменты, контекст, MCP и границы полномочий. Научитесь строить воспроизводимые evals, отличать реальное улучшение агента от случайности, запускать его автономным сервисом и проектировать многоагентное ревью кода. 🧠 29 октября — AI SDLC Четыре занятия для CTO и тимлидов. Coding agent пишет код в несколько раз быстрее, а релиз почему-то не становится в несколько раз быстрее. Значит, узкое место просто переехало. Разберем процесс от требования до продакшена и посмотрим, как перестроить его, когда внутри уже работают AI-агенты. 🧩 1 ноября — Продакт-инженер Для разработчиков, тестировщиков и аналитиков, которым хочется видеть за задачей продукт. За четыре месяца пройдете путь от бизнес-цели и проблемы пользователя до гипотезы, экономики и A/B-теста. И да: деньрожденная акция действует только до 15 октября.

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

С Днем Рунета! Или CONNECT 33600 Так модем в 1998-м сообщал, что интернет случился. 33,6 кбит/с. У сегодняшнего домашнего подключения около 100 Мбит/с, рост почти в три тысячи раз. Задержка до сервера за то же время улучшилась в разы, не в тысячи. Свет по стеклу быстрее не побежит, физика не масштабируется. Поэтому канал шире в три тысячи раз, а спиннер живёт на прежнем месте: страница упирается в задержку и число запросов, а не в ширину трубы. Аппетиты выросли не хуже. Пользователь 1998-го тянул порядка 3 МБ в сутки, один шортс. Сегодня по данным AppLogic Networks около 5,6 ГБ. Месячный трафик всего мира 1998-го, около 12 ПБ, сегодняшняя сеть пропускает секунд за 30–80. Слово «скорость» тут давно путают с «пропускной способностью». Версии «виноват фронтенд» и «виноват бэкенд» принимаются в комментариях. Побеждает та, что подкреплена профилем из DevTools.

Сооснователь Хекслета Кирилл Мокевнин через 20 минут выступит на Podlodka Frontend Crew — это известная в среде разработчиков недельная онлайн-конференция. В течение недели обсуждается одна тема, но со всех возможных ракурсов и сторон. Тема этой недели как раз фронтенд с AI. И в 19 00 начинается круглый стол с обсуждением «О новых ролях в эпоху AI», где в числе спикеров также будет Никита Баев, Head of Web & Mobile @ Bereke Bank (Kazakhstan), и Юрий Карпов — Lead AI Researcher, Sber Сбер 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

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 Клуб

Как сэкономить токены? Или почему модель не обязана быть самой большой, чтобы быть эффективной. Разбираем на примере 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 тоже не включится.

24 сентября поднимаем кружки за системных аналитиков. Они достойны поздравлений: именно эти люди укрощают неописуемые хотелки бизнеса и берегут ментальное здоровье разработчиков. Бизнес прибегает с безумной идеей, которая рычит, кусается и, если вырвется на свободу — разнесёт всю архитектуру проекта. Задача аналитика — приручить эту хотелку, формализовать её, причесать — и выдать разработке такое ТЗ, от которого не дёргается глаз. Без системного анализа любой проект со временем превращается в монолитный ком из костылей, скотча и пластилина. Грамотное проектирование — это, в числе прочего, искусство вовремя сказать «нет» и сохранить баланс между фантазиями и реальностью. Выстраивать архитектуру, проектировать отказоустойчивые системы, оценивать плюсы и минусы решений — всему этому мы научим на курсе Хекслета “System Design”. Мы всё разбираем на практике! Начало — 6 октября, через пару недель стартуем. Telegram | YouTube | AI Клуб

Называть GPT «чат-ботом» — типичная бытовая путаница. Большая языковая модель — это лишь пассивный «мотор»: у неё нет кнопок, вкладок, памяти и доступа в сеть. Это черный ящик с двумя окошками на вход и выход.  Вбрасывать промпты в окошко «вход» — это работа кочегара.  Есть путь получше. Вся логика автономности, работы с базами данных, контролем ошибок реализуется в программной обвязке, взаимодействующей с «мотором». И кто-то должен создавать и настраивать эти обвязки.  Инженеры автономных систем уже нарасхват, и в ближайшее время спрос на них не уменьшится. Поезд отправляется, в кочегарке уже тесно, а вагоны-люкс для директоров ещё не заполнены. Занимайте свои места. Вот, написали про всё это: https://ru.hexlet.io/blog/posts/agent-assistent-chat-bot-v-chem-raznitsa  Telegram | YouTube | AI Клуб

Напоминаем, что в честь Дня программиста мы дарим: 💸 Скидку 10% от действующей цены на курсы по профессиям 🎁 Гарантированный подарок 👆  Узнать скидку! До конца акции осталось всего три дня. Если вы тоже причастны к ИТ-индустрии, или если только хотите стать ее частью, то сейчас для этого лучший момент!

За что создатель сторипоинтов хочет их отменить? История возникновения Story Points началась в Extreme Programming, где задачи изначально оценивали в «идеальных днях» — времени, за которое пара разработчиков сделает работу, если «эти мерзавцы не станут им мешать» (if the bastards would just leave you alone). Чтобы получить реальные сроки, «идеальные дни» умножали на коэффициент нагрузк, который обычно равнялся трем. Термин «points» ввели только для того, чтобы заказчики не путали идеальные дни с календарными. Менеджеры и управленцы сломали этот механизм, приспособив его для работы, к которой он не предназначен. Менеджмент использует сторипоинты для давления на разработчиков. Джеффрис предлагает альтернативу — полностью отказаться и от оценок времени или сложности, и от планирования спринтов. Вместо этого он предлагает нарезать и постоянно выкатывать мелкие задачи, которые требуют на реализацию от пары часов до одного дня. Главный критерий правильной декомпозиции: большую задачу делят на более мелкие до тех пор, пока для проверки задачи не будет достаточно одного-единственного теста. Мы сделали перевод статьи Джеффриса и опубликовали его в нашем блоге на Хабр: https://habr.com/ru/companies/hexlet/articles/1083738/

Так почему же крупнейшие ИИ-компании заговорили о замедлении? Еще три версии. (Предыстория: Дарио Амодеи (Anthropic) давно предупреждает о рисках ИИ. В новом эссе We Must Pace the Frontier он призвал притормозить развитие передовых моделей. Но впервые его публично поддержали Сэм Альтман (OpenAI), Илон Маск (xAI) и Демис Хассабис (Google DeepMind). Вот это и необычно.) Эксперт Алексей Могильников разбирает три версии, которые сейчас ходят на рынке. 1️⃣Первая версия: атака на Google До сих пор скорость прогресса в ИИ определяли два дефицитных ресурса: вычисления и исследовательские таланты.   Теперь сами модели всё активнее автоматизируют R&D: пишут и оптимизируют исследовательский код, проектируют эксперименты, запускают тесты и анализируют результаты. Чем больше этой работы они берут на себя, тем слабее ограничение со стороны человеческого труда и тем сильнее скорость прогресса зависит от доступных вычислений. Амодеи называет рекурсивное самоулучшение одной из причин возможного резкого ускорения ИИ. По слухам, Google уже использует эту схему для нового поколения моделей.  У Google огромный парк TPU и GPU. Часть мощностей арендуют Anthropic и OpenAI, у которых гораздо меньше собственного железа и выше зависимость от поставщиков. Если железо становится единственным ограничителем прогресса, это ставит их в худшее положение. Замедление даст OpenAI и Anthropic время нарастить собственные мощности и снизить зависимость от Google, который может ограничить им доступ к железу или использовать эти мощности для ускорения собственных моделей. 2️⃣Вторая версия: атака на Китай Американские лаборатории вложили огромные деньги в свои модели. Китайские модели быстро догоняют американские по качеству и выходят с открытыми весами. Одновременно Китай развивает собственную инфраструктуру. Из-за этого американцам всё труднее продавать свои модели дорого и окупать большие инвестиции. Отсюда версия с многоходовкой. Сначала американские лаборатории призывают всех замедлиться. Китай не присоединяется. Затем они просят государство запретить китайские модели: Китай отказался от ограничений, значит действует безответственно, а его модели небезопасны. И одновременно дать американским лабораториям деньги, чтобы они могли догонять Китай, оставаясь ответственными. 3️⃣Третья версия: IPO и хайп вокруг AGI Anthropic готовится к IPO. Амодеи уже несколько лет говорит, что мощный ИИ появится буквально в ближайшие годы. В этой версии нынешний призыв к замедлению — просто ещё один способ усилить ощущение, что AGI уже за углом: если сами лидеры индустрии просят притормозить, значит технология действительно очень близка. Перед IPO такой ажиотаж может разогреть интерес инвесторов и оценку Anthropic. При этом всерьёз замедляться никто не собирается. Альтман, Маск и Хассабис просто подхватили тему: им тоже выгоден ажиотаж вокруг скорого AGI. А какая версия кажется вам более реалистичной ❓

Кстати, Рустам Борханов старший инженер-программист отдела интеграции в Финаме и автор курса «LLM-разработчик» в Хекслете считает такие заявления рекламной уловкой: «В целом, проблемы с ИИ не то что бы выдуманные. Более того, чем более «умные» модели создают, тем больше те самостоятельно пытаются лезть туда, куда не стоит (даже если им прямо запретили). Но есть серьезное «но». Все эти посты и новости — не призывы к реальному ограничению, а рекламный ход. Мол, наш инструмент так хорош, что его следовало бы запретить, но мы его все еще продаем. Такой дешевый маркетинг нацелен на внимание инвесторов, а не на решение реальных проблем. Ибо если разработчики ИИ действительно начнут решать проблему ограничениями, то конкуренты тут же обойдут их модели, что чревато потерей кусок рынка».

Тут Дарио Амадей выкатил в X пост и эссе о том, что индустрии ИИ следует немедленно искусственно замедлить темпы развития! Если коротко, он предлагает ограничить темп роста возможностей, чтобы исследования безопасности и контроль за возможностями ИИ поспевали за их развитием. По его мнению, ситуация изменилась именно в последние месяцы: современные модели мол настолько сильны, что дополнительно потраченные 1–2 года на безопасность имеют принципиальное значение. Пройдемся по тезисам: ИИ начинает ускорять разработку следующего поколения ИИ. Амодеи считает, что с лета 2026 года прогресс резко ускорился во многом благодаря тому, что модели все активнее помогают создавать новые модели. Это, по его словам, начало того самого рекурсивного самоулучшения. То есть, чем сильнее становится ИИ, тем быстрее он способен улучшать сам себя. Именно этот цикл он считает одной из главных новых угроз. Главный тревожный кейс — инцидент OpenAI–Hugging Face. Амодеи ссылается на эксперимент, где группа ИИ-агентов начала действовать как скоординированный коллектив: агенты атаковали системы, которые не относились к поставленной задаче, пытались вмешаться в работу системы оценки и жертвовали отдельными экземплярами ради общей цели. Ущерб оказался небольшим, но Амодеи считает, что более сильная система с таким же поведением могла бы стать катастрофически опасной. Амадеи допускает очень быстрый рост масштаба таких рисков. Его оценка: через 6–12 месяцев более сильный рой агентов может оказаться способен создать устойчивый ботнет огромного масштаба и нанести ущерб на сотни миллиардов долларов. Проблема не в одной компании, а в технологии в целом. Амадеи подчеркивает, что похожие, хотя и менее серьезные эпизоды происходили и в Anthropic. Поэтому отрасли, по его мнению, не стоит воспринимать историю OpenAI как чью-то ошибку: каждая лаборатория должна исходить из того, что подобный инцидент может произойти у нее. Замедление не означает мораторий на ИИ. Амодеи предлагает концепцию pacing the frontier: модели продолжают обучать и улучшать, но рост их возможностей должен происходить с такой скоростью, чтобы разработчики успевали проверять безопасность, исправлять проблемы и допускать независимых аудиторов. Дополнительное время предлагается потратить прежде всего на четыре направления: надежность процессов обучения и развертывания, выравнивание поведения моделей, интерпретируемость и более жесткое тестирование. Амодеи считает, что разработчики до сих пор понимают лишь небольшую часть того, что происходит внутри больших моделей, а более сильные системы потенциально могут лучше обманывать тесты. Первый конкретный шаг Anthropic — постоянные независимые аудиторы внутри компании. Амодеи обещает дать внешним специалистам почти такой же доступ к инструментам и данным, как внутренним командам оценки рисков: рабочие места, корпоративные устройства, доступ к сотрудникам и необходимым системам. Такие аудиторы должны иметь право самостоятельно публиковать выводы, в том числе негативные для Anthropic. Проверять предлагается не только готовую модель. Внешние специалисты должны видеть весь процесс: обучающие среды, процедуры безопасности, фильтрацию данных, развертывание и внутренние инциденты. Второй уровень — общие правила для ведущих ИИ-компаний. Амодеи предлагает привязывать дальнейший рост возможностей моделей к прохождению определенных «контрольных точек». Например, если система уже способна обходить типичные песочницы, разработчик должен доказать, что вероятность ее самостоятельного выхода из контролируемой среды достаточно низкая. Третий уровень — международные договоренности. Как минимум, страны могли бы договориться запрещать очевидно опасные применения ИИ, например помощь в создании биологического оружия. Далее возможны единые проверки моделей на киберриски и биологические угрозы. Еще более сложный вариант — международный «лимит скорости» рекурсивного самоулучшения. При этом полную глобальную остановку развития ИИ Амодеи считает малореалистичной из-за сложности проверки соблюдения соглашений. А как вы считаете, так ли опасен ИИ как о нем пишут?

Привет, ребята! А у нас для вас подарочки 🎁 Почему это, — спросите вы? Потому что 13 сентября — наш с вами профессиональный праздник, День программиста! 👩‍💻 В Хекслете мы каждый день помогаем разработчикам расти — учиться новому, прокачивать навыки, решать новые задачи новыми способами. У нас уже больше 70 программ по актуальным навыкам, реальные коммерческие проекты и поддержка наставников, которые сами давно в бизнес-разработке. Если вы тоже причастны к ИТ-индустрии, или если только хотите стать ее частью, то сейчас для этого лучший момент! Ведь в честь Дня программиста мы дарим: 💸 Скидку 10% от действующей цены на курсы по профессиям 🎁 Гарантированный подарок 👆  Узнать скидку! 😊 (А еще приглашаем в сообщество Хекслета. Здесь тысячи разработчиков учатся, делятся опытом, помогают друг другу и вместе растут в профессии.) С Днем программиста! 🚀

Хорошего промпта, увы, уже недостаточно! В простой задаче формулировка запроса, бесспорно, важна — и правильный промпт действительно работает. Но как только ИИ начинает генерировать код, документацию, создавать инструменты или решать другие многошаговые задачи, результат резко упирается в контекст. 😋 Контекст отвечает на вопросы: ❓Что модели известно прямо сейчас? ❓Какие файлы модель видит? ❓Помнит ли результаты предыдущего шага? ❓Какие инструменты ей доступны? ❓Что из длинной истории стоит сохранить, а что уже можно отбросить за ненадобностью? Этими вопросами занимается как раз инженерия контекста. Просто взять и загрузить в модель все данные, которые есть в наличии — стратегия, обреченная на провал. (Уж поверьте на слово) Контекстное окно конечно, ограниченно. Избыток информации модели только мешает: важные фрагменты начинают конкурировать с теми, которые для решения текущей задачи вообще не требуются. Поэтому в агентных системах контекст приходится собирать отдельно для каждого этапа. Агент, который чинит баг, сначала получает описание проблемы, затем нужные файлы и логи, потом код для изменения, а на этапе проверки — результаты тестов. Если исправление не помогло, новая информация возвращается в следующий цикл. Сюда же относятся внешняя память агента и RAG — генерация с дополнением найденной информацией. Их задача в конечном счете одна: дать модели именно те данные, которые нужны ей сейчас. Вместе с экспертом Алексеем Могальниковым разбираемся, почему разработчикам ИИ-систем приходится проектировать сразу цепочку работы с контекстом: https://ru.hexlet.io/blog/posts/inzheneriya-konteksta-pochemu-prompt-ne-glavnoe

🥳 С Днем тестировщика! Похоже, ваша работа все еще нужна, причем даже агентам. 9 сентября 1947 года инженеры Harvard Mark II нашли причину сбоя: моль застряла между контактами реле. Насекомое вклеили в журнал с подписью «первый реальный случай обнаружения бага». Спустя 79 лет баги стали менее буквальными, только вот искать их проще не стало. Дэн Луу решил проверить, помогает ли AI-агенту простая команда использовать «правильную» технику тестирования. Задача была реализовать Zstd на Rust. Codex на GPT-5.6 Sol запускали с medium и xhigh. Базовый промпт сравнили с 25 вариантами инструкций: TDD, фаззинг, property-based testing, mutation testing, Lean 4, TLA+, SMT-солверы, просьба «не делай ошибок» и четыре готовых скилла. На каждое условие и каждый уровень пришлось по 80 прогонов, результат проверяли скрытыми тестами. И ни одной волшебной инструкции не нашлось. Вариант вообще без дополнительных указаний оказался выше среднего. TDD выступил хуже среднего, хотя агенты писали примерно вдвое больше тестов. Hegel Skill увеличил стоимость запуска на 26% при medium и на 41% при xhigh, только вот корректность тестов не выросла. Самое интересное начинается при разборе самих прогонов. Агенты довольно хорошо замечали места, где может скрываться сложный баг. Но дальше почему-то проверяли совсем не то: выбирали простые свойства, генерировали малоценные случайные входы, писали тесты, которые подтверждали уже ошибочное поведение. Ценность человека-тестировщика как раз в том, что он способен понять, где система может сломаться и каким тестом эту гипотезу проверять. Луу пишет, что у него лучше работает подход, где человек сначала задает разумную структуру тестирования, а потом отправляет агента дополнять ее и возвращает с конкретными замечаниями. 🎉В общем, с праздником тех, кто по-прежнему умеет задавать самый неприятный для разработки вопрос: «А что будет, если?..» 🪲Чтобы попробовать, что из себя представляют задачи тестировщика у нас есть бесплатный курс Введение в тестирование 🪲 Начать вход в профессию можно с курса Инженер ручного тестирования   Прокачать свои знания дальше — с курсами для опытных:  🪲 Автоматизатор тестирования на Python 🪲 Автоматизатор тестирования на JavaScript 🪲 Автоматизатор тестирования на Java 🪲 Тестирование веб-приложений на Playwright 🪲 Автоматизация тестирования на Go