Haiku поставила PASS и указала существенную ошибку: как мы разбирали отчет ревью
Проверка замечаний в отчете ревьюПри вычитке десяти статей для блога мы получили от Haiku такой отчет. Фрагмент сокращен:{ "verdict": "PASS", "meaning_preserved": true, "issues": }
МАЯК: сначала документация, потом кнопки
Я не люблю писать документацию. Чек-листы, планы тестирования, блоки проверок, схемы — вот это всё. Не люблю, потому что, пока ты это пишешь, теряется время на главное: разбираться и тестировать систему, с которой ты работаешь.Идея её автоматизации жила у меня с первого дня в ИТ — тогда мне её жизненно не хватало. Но понятного пути, как это реализовать, не было ни в голове, ни в OSS, нигде. Ну или я не нашёл — такой вариант тоже не отметаю.
Как мы проверяем, какие данные остаются в тексте после маскировки перед LLM
Вот результат обработки искусственного документа нашим локальным Pii-Mask:{{PERSON_1}}, инженер. Номер в отраслевом реестре: Z-99-65432104. Маскер закрыл ФИО, но оставил номер. Здесь он вымышленный; в настоящем документе такой идентификатор может позволить найти человека в открытом реестре. Успешное завершение маскера этого не исключает.Перед передачей текста в модель мы ищем в нем известные идентификаторы документа. Список для этой проверки составляется по исходному материалу: если брать только найденные маскером сущности, пропущенный идентификатор не попадет в список для проверки.Что проверяем
Приниматоры решений: бенчмарк на русском для Jev‑style моделей
Последние пару лет мы довольно странно используем большие языковые модели.
Тест проходит даже с багом: что показал эксперимент Дэна Лу
Пусть функция должна разворачивать строку. Агент написал тест: на входе abba, на выходе ожидается abba. Тест зеленый. Он останется зеленым, если функция вообще ничего не делает.Пример учебный, но ошибка выбора входа реальная: в одном из прогонов эксперимента Дэна Лу агент проверял разворот битового потока на палиндроме. Назвал рискованное место, независимо вывел результат, провел аудит - и все равно не обнаружил ошибку. Проверка была, различия между правильным и неправильным поведением в ней не было.
Зелёный пайплайн ничего не доказывает. Семь способов, которыми quality gate пропускает брак в прод
Каждая секунда на счету, когда надо запускать manual джобуif roc_auc < 0.85: exit 1
Пусть агент сам докажет, что написанные им тесты можно не пройти
В зелёном тестовом наборе может сохраниться такая же ошибка, как и в коде. Попросите агента показать тот баг, который отлавливается при помощи написанного им теста, а потом проверьте, откуда берётся ожидаемый ответ
Мы искали, куда coding agents тратят токены. Дело оказалось не в промптах
Мы много разрабатываем с помощью coding agents: веб‑приложения, MCP‑серверы, пайплайны обработки данных, системы из нескольких агентов. И чем лучше становилась инфраструктура вокруг агентов, тем больше в ней появлялось инструкций, проверок, субагентов и автоматики. По идее, разработка должна была становиться дешевле. А расход контекста рос.Первое подозрение было очевидным: слишком раздутые промпты. Мы искали не там.38 килобайт текста со смыслом «всё хорошо»Агент закончил изменение и запустил тесты. 178 тестов, все зелёные. На stdout прилетело 38 365 байт TAP:# Subtest:...ok 1 ‑...‑-duration_ms:...type: 'test'..
Неделя до INFOSTART TECH EVENT 2026: практики 1С в мире темного фэнтези
INFOSTART TECH EVENT 2026 ждет тебя!
