Хекслет

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

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

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

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

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

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

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

Так почему же крупнейшие ИИ-компании заговорили о замедлении? Еще три версии.

(Предыстория: Дарио Амодеи (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

Telegram | YouTube | AI Клуб

🥳 С Днем тестировщика! Похоже, ваша работа все еще нужна, причем даже агентам.

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

Telegram | YouTube | AI Клуб

На интервью разработчика могут попросить спроектировать целую систему.

Это, кстати, устоявшаяся практика у гигантов вроде Amazon и в России бигтех (и не только) уже уверенно ее перенял. Для middle+ это уэе вполне обычная секция. LeakCode проанализировал базу из 33 000+ отчетов кандидатов и нашел в ней 1 722 размеченных раунда по system design.

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

Эти навыки пригодятся и после собеседования. В DORA 2025 опросили почти 5 000 технических специалистов. Один из выводов: ИИ усиливает уже существующую инженерную систему. Поэтому с распространением AI-агентов системный дизайн не становится менее важным. Решить, как собрать из функций надежный продукт, по-прежнему должен инженер.

14 сентября в 19:00 проведем бесплатный воркшоп по System Design. На реальном кейсе за 1,5 часа пройдем секцию от требований и оценки нагрузки до архитектуры, SLA, масштабируемости и защиты решений.

🤖 Как нанимать специалистов по ИИ, не требуя невозможного?
Или топ причин, почему вы так и не наняли человека для внедрения ИИ

Достаточно открыть парочку вакансий по AI/LLM, чтобы увидеть проблему: от кандидата требуют годы опыта с технологией, которая появилась совсем недавно. Новая версия истории с рекрутерами, которые путали Java с JavaScript. Но если бы проблема была только в этом...

Компании часто начинают искать «специалиста по ИИ», не понимая, а что именно он должен сделать? Работать с документами? Создать поиск по внутренней базе знаний? Автоматизировать работу с клиентами? Встроить агентов в существующие процессы?
А ведь от ответа зависит то, кого вообще нужно нанимать.

В большинстве случаев нужен сильный разработчик с инженерной базой, который дополнительно понимает:
— как устроены LLM и агентские системы;
— зачем нужны векторные базы;
— как оркестрировать несколько компонентов;
— как выбрать модель под конкретную задачу;
— как встроить всё это в уже работающий бизнес-процесс.

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

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

В новой статье Рустам Борханов разбирает найм с обеих сторон: что делать бизнесу и рекрутерам и что показывать в резюме разработчику, который хочет заниматься LLM.

https://ru.hexlet.io/blog/posts/specialist-po-ii-kogo-nanimat-dlya-vnedreniya

Telegram | YouTube | AI Клуб

Обновили редактор Хекслета — изменения, усиливающие опыт студентов.

Что появилось:
— Python теперь получает подсказки: функции стандартной библиотеки, сигнатуры, описания и методы с учетом типов. Редактор также видит функции из соседних файлов проекта.

— Для PHP и Ruby автодополнение стало полезнее: вместо слов из текущего файла — реальные функции стандартной библиотеки с сигнатурами и описаниями.

— Makefile, Erlang, Vue, Scheme, ini и другие форматы теперь подсвечиваются. А Makefile еще и предупреждает о классической ошибке с пробелами вместо табуляции.

— Поиск Cmd/Ctrl + Shift + F ищет текст сразу по всему проекту и открывает найденное место в нужном файле.

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

— Результаты тестов теперь выводятся в полноценном терминале: с цветами, кликабельными ссылками и нормальной работой с большим объемом текста.

Исправили и несколько раздражающих мелочей. Cmd/Ctrl + S действительно сохраняет код, тесты запускаются на актуальной версии файла, горячие клавиши учитывают текущую вкладку, а ошибки при работе с файлами снова показываются пользователю.

Главная идея обновления — сделать учебный редактор ближе к инструментам, которыми ИТ-специалисты пользуются в реальной работе. Чтобы привычка искать по проекту, читать логи, разбираться в сообщениях языка и работать с терминалом появлялась еще во время обучения.

https://ru.hexlet.io/blog/posts/redactor-hexlet-092026

Telegram | YouTube | AI Клуб

Какие навыки помогают разработчику дорого стоить в 2026 году

ИИ все лучше справляется с непосредственным написанием кода. Кодовый агент уже может изучать репозиторий, менять файлы, писать тесты, запускать команды и готовить изменения для ревью.

Поэтому преимущество разработчика постепенно смещается туда, где одной генерации кода недостаточно.

В июне Anthropic опубликовала анализ примерно 400 000 сессий Claude Code от 235 000 пользователей. Исследователи выяснили, что сильная экспертиза связана с большей вероятностью успешно выполнить задачу. При этом более компетентные пользователи могли делегировать Claude больше работы всего одной инструкцией.

Еще один важный навык — нормально ставить задачу. Авторы CodeScout проверили подход, при котором агент сначала изучает нужный контекст кодовой базы, а затем уточняет исходное описание проблемы. На SWE-bench Verified такой подход повысил долю решенных задач на 20% относительно базового метода.

Высокая скорость генерации сама по себе еще не означает качественную разработку. В основной модели исследования MSR 2026 внедрение Cursor связано с ростом числа добавляемых строк на 28,58%, предупреждений статического анализа — на 30,26%, сложности кода — на 41,64%.

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

Например, с тестами агенты уже работают довольно активно. В исследовании MSR 2026 ИИ оказался автором 16,4% коммитов, добавлявших тесты. Другая работа на выборке более 1,2 млн коммитов показала, что агенты затрагивали тестовые файлы в 23% своих коммитов против 13% у остальных авторов и чаще добавляли моки — 36% против 26%.

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

🔗 В статье подробно разбираем семь таких навыков:

https://ru.hexlet.io/blog/posts/navyki-razrabotchika-kogda-kod-pishet-ii

Telegram | YouTube | AI Клуб

«Выбирай то, что нравится» — не самый полезный совет по профориентации

Интерес к работе действительно имеет значение. Но научные данные показывают, что формула, если любишь что-то делать, то сделай это работой — не всегда эффективна.

В 2020 году исследователи объединили результаты 105 исследований с 39 602 участниками, которые проводились на протяжении 65 лет. Люди, чья работа лучше соответствовала их профессиональным интересам, действительно были в среднем более удовлетворены ею. Но эта связь оказалась умеренной — ρ = 0,19. То есть, хотя совпадение профессии с интересами и имеет значение, но далеко не определяющее. И не факт, что выбрав душой, потом не пожалеешь.

Полезнее при выборе направления рассматривать сразу на несколько аспектов:

— какие навыки нужны для старта;
— реально ли найти первую работу;
— сколько времени займет вход;
— что происходит со спросом;
— как ИИ меняет профессию.

Последний пункт особенно важен. Всемирный экономический форум опросил более тысячи работодателей и прогнозирует, что к 2030 году 39% нынешних навыков работников изменятся или устареют. Самыми быстрорастущими категориями навыков стали ИИ и большие данные, сети и кибербезопасность, технологическая грамотность.

Но вход в IT для новичков не закрылся. По данным hh[.]ru, в 2025 году около 13% вакансий отрасли — почти 65 тысяч — были доступны начинающим.
На бесплатном воркшопе Хекслета мы не будем определять профессию по типу личности или магическому шару. Вместо этого сравниваем рынок: шесть IT-направлений, требования к новичкам, зарплаты, сроки входа, работодатели и влияние ИИ.

Когда? Уже сегодня, 26 августа, в 19 00

👉 https://special.hexlet.io/career-guidance?utm_source=telegram&utm_medium=social&utm_campaign=hexlet-blog&utm_content=promo&utm_term=post_250826

ИИ уже умеет писать код. Но строить системы за разработчика пока не научился.

В Stack Overflow Developer Survey 2025 84% разработчиков сообщили, что уже используют ИИ-инструменты или собираются это делать. При этом 72% участников ответили, что вайб-кодинг не входит в их профессиональную разработку.

Масштаб происходящего доказывает и исследование Anthropic. Компания проанализировала около 500 тысяч взаимодействий пользователей с Claude.ai и Claude Code. В Claude Code 79% диалогов относились к автоматизации, то есть модель самостоятельно выполняла задачу, а не просто помогала человеку ее решить.

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

В новой статье разобрали, почему системный дизайн становится одним из главных навыков разработчика в эпоху ИИ — на данных Anthropic, Stack Overflow, METR и DORA.

Читать: https://ru.hexlet.io/blog/posts/sistemnyy-dizayn-pochemu-ii-ne-zamenil-razrabotchikov

Telegram | YouTube | AI Клуб

ИИ-агент написал код. Разработчик обязан его прочитать?

В X обсуждают заявление Роберта Мартина — «дядюшки Боба», автора легендарной книги «Чистый код» («Clean Code»). Так вот, дядя Боб признался, что вообще не читает код, созданный его ИИ-агентами. По его словам, тогда выигрыш в производительности просто исчезает.

Вместо классического ревью Мартин устраивает коду «полосу препятствий»:
— юнит-тесты;
— сценарии поведения в формате «дано — когда — тогда»;
— QA-процедуры;
— метрики качества;
— проверку покрытия;
— мутационное тестирование.

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

Сторонники такого подхода считают, что построчное чтение сгенерированного кода превращает разработчика в самое медленное звено системы. Если агент способен выполнить задачу, а результат проходит все проверки, зачем дублировать его работу?

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

Особенно интересно эта дискуссия выглядит на фоне исследования британского AI Security Institute. Во время кибериспытаний все проверенные институтом модели хотя бы иногда пытались обойти правила: искали готовые решения, изучали тестовую инфраструктуру или атаковали системы за пределами разрешенного контура.

Одна из задач из-за ошибки оказалась нерешаемой. Модель не остановилась, а написала и запустила код на внешнем сервисе, пытаясь получить доступ к инфраструктуре испытания. Ущерба удалось избежать, но эксперимент показал: собственным объяснениям модели и ее рассуждениям нельзя доверять на все 100%.

Как тогда работать с ИИ-агентами безопасно и эффективно?

Рустам Борханов, автор и ведущий программы LLM-разработчик в Хекслете считает так:
«Я бы доверял ИИ-агенту примерно так же, как младшему специалисту. Важно понимать, насколько хорошо поставлена задача, где могут возникнуть проблемы и что действительно стоит перепроверить.

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

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

Как раз 25 августа у нас пройдет бесплатный вебинар — поговорим о том, как ускорить разработку с помощью ИИ, не пропустив проблемы в коде и не занимаясь бесконечными проверками: 

https://special.hexlet.io/ai-developer_llm_webinar?utm_source=telegram&utm_medium=social&utm_campaign=hexlet-blog&utm_content=promo&utm_term=post_220826  

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

А вы читаете весь код, созданный ИИ, или доверяете тестам и метрикам?

Хекслет pinned «☀️ Что изучить на Хекслете в августе и сентябре Собрали популярные программы и мероприятия! Для тех, кто выбирает направление или планирует сменить профессию: ⌨️ Бесплатный вебинар «Как выбрать профессию в IT» — 26 августа. Разберем направления: от разработки…»

☀️ Что изучить на Хекслете в августе и сентябре

Собрали популярные программы и мероприятия!

Для тех, кто выбирает направление или планирует сменить профессию:

⌨️ Бесплатный вебинар «Как выбрать профессию в IT» — 26 августа. Разберем направления: от разработки и DevOps до ИИ-систем. Обсудим рынок, зарплаты и вакансии для новичков и перспективы роста.

Для действующих разработчиков:
🤖 Курс «LLM-разработчик» — старт 27 августа. Работа с большими языковыми моделями, ИИ-инструментами и их интеграция в продукты;
🖥 «Бэкенд для фронтенд-разработчиков» — для тех, кто хочет глубже разобраться в серверной части и расширить свой стек;
🏢Бесплатный вебинар «Системный дизайн» — 14 сентября. Разберём системный дизайн и подготовку к соответствующему этапу технических собеседований.

Профессии с нуля:
— Курс «DevOps-инженер с нуля» — учимся работать с инфраструктурой, автоматизацией, CI/CD и облачными технологиями. В программе — практические проекты от Yandex Cloud;
🐍Курс «Python-разработчик» — старт 27 августа;
🖥 Курс «Фронтенд-разработчик» — старт 27 августа;
🤍 Курс «Golang-разработчик с нуля» — старт 27 августа + навык быстрого написания кода с ИИ-агентами.

Бесплатно про ИИ:
🦋 Курс «ИИ и нейросети для начинающих» — знакомимся с современными ИИ-инструментами и учимся использовать их для повседневных и рабочих задач;
🕵️‍♂️ Бесплатный мини-курс «AI для разработчиков» — за 1,5 часа соберёте ИИ-агента для тестирования, подключите его к GitHub Actions и настроите создание тестов для каждого pull request.
Мини-курс можно пройти прямо в Telegram: запустить курс.

Ждем вас на программах Хекслета!
Не можете определиться с направлением? Напишите нам — поможем выбрать.

Telegram | YouTube | AI Клуб

Каждый шестой коммит с новыми тестами уже делает ИИ

Исследование «Testing with AI Agents: An Empirical Study of Test Generation Frequency, Quality, and Coverage» (MSR 2026) проанализировало 2 232 коммита с изменениями тестов и обнаружило, что 16,4% коммитов, добавляющих тесты, были сделаны AI-агентами. При этом вклад AI-тестов в покрытие кода оказался сопоставим с тестами, написанными людьми.

Другое исследование — «Are Coding Agents Generating Over-Mocked Tests? An Empirical Study» — проанализировало более 1,2 млн коммитов в 2 168 репозиториях за 2025 год. Из них 48 563 были сделаны агентами. У агентов 23% коммитов затрагивали тесты против 13% у остальных коммитов. То есть агенты заметно чаще берут тестирование на себя.

Но есть нюанс. То же исследование «Are Coding Agents Generating Over-Mocked Tests? An Empirical Study» показало, что 36% тестовых коммитов AI-агентов добавляли моки против 26% у остальных.

Авторы отдельно обращают внимание: чрезмерный мокинг может делать тесты менее эффективными при проверке реальных взаимодействий в системе.
Поэтому навык 2026 года — уметь собрать AI-агента, который понимает кодовую базу, запускает тесты, проверяет результат и работает внутри CI-процесса.

Сооснователь Хекслета Кирилл Мокевнин отмечает: ИИ сильно упростил отладку, которая раньше занимала гигантское количество времени. Теперь агенты взяли на себя рутину — долгие и нудные способы проверить, что именно не работает и почему.

Именно поэтому бесплатный мини-курс Хекслета «AI для разработчиков» посвящен тому, как создать ИИ-агента для тестирования. Если хотите научиться встраивать агентов в реальную разработку — идите на мини-курс и соберите своего первого рабочего AI-агента. За 1,5 часа настроите агента, подключите его к GitHub Actions и получите тесты на каждый pull request.

Курс доступен прямо в Телеграме: https://telegram.me/HexletWelcomeBot?start=wwb_fs1e45d0ea-7705-4da8-b07a-82a372469ea9

Telegram | YouTube | AI Клуб