Я сделала для своего продукта MCP-сервер. Написание и проверка кода заняла один вечер — писал конечно агент.
А вот «остальное» оказалось решениями о составе и видимости инструментов и вещами, которые невозможно было запланировать заранее — только узнать постфактум, и почти всегда по итогам чьей-то реакции снаружи.
Всем привет! Команда техподдержки РТК-Сервис на связи. Мы уже познакомили вас с усилителями от Т8, Huawei и Nokia (Alcatel Lucent). Сегодня разбираем DWDM от производителя ECI.
Будет познавательно. Поехали!
Если вы меня читаете, то знаете, что где-то полгода назад я проектировала, обучала и, в общем, создавала своего агента для проверки ТЗ. А сейчас у меня появилась новая идея по захвату мира: протестировать ML. И да, я не Data Scientist, но когда это меня останавливало?
В итоге вместо пары экспериментов получился отдельный QA framework, который берёт готовую ML-модель, собирает её контракт и сам решает, какие проверки можно запустить и почему результат должен считаться PASS, FAIL, WARN или SKIP.
if roc_auc < 0.85: exit 1 — примерно так выглядит quality gate почти в каждом ML-пайплайне, который мне попадался. В обычном CI то же самое — количество проблем в Sonar и код выхода тестов.
Я видел, как приложение проходило весь пайплайн, выкатывалось в прод, и через 2 часа бизнес срочно требовал отката из-за неработоспособности важного функционала.
Зелёная галочка не значит «модель хорошая» — это знают, в общем-то, все. Только пайплайны почему-то до сих пор собирают так, будто никто об этом не слышал. Гейт в таком виде похож на суд, который выносит оправдательный приговор по показаниям одного свидетеля. И никто не спрашивает, откуда свидетель взял свою цифру.
Дальше семь способов, которыми гейт пропускает брак в прод. Там будет и утечка между train и test, и старый добрый || true в .gitlab-ci.yml. По каждому посмотрим реальный кейс с цифрами.
При работе с STM32 приходится решать несколько повторяющихся задач: настроить сборку, подключить библиотеки, записать прошивку и проверить её поведение на плате. После изменений эти действия нужно выполнить снова — желательно тем же способом и с понятным результатом.
В моих проектах для этого постепенно сложился набор инструментов и примеров. Одни помогают описывать сборку, другие — прошивать микроконтроллер, третьи — сохранять действия в отладчике в виде повторяемых тестов. Отдельная часть посвящена инструкциям для ИИ-ассистентов, участвующих в разработке.
Хочу показать, как эти проекты связаны и где могут пригодиться.
Дэкс Хорти из HumanLayer объясняет, почему “фабрика кода с выключенным светом”, где агенты пишут, ревьюят и тестируют без человека, пока не работает: по его мнению, при обучении модели почти не получают сигнала о поддерживаемости кода, а быстрого способа ее проверить пока нет. Его рецепт - вернуть ревью и сделать его дешевым планированием. Разбираю эссе и 272 комментария на HN и сравниваю с собственным конвейером на Claude Code и Codex: спека прозой, тесты вслепую, сверка второй моделью. Спойлер: 22 нарушения спеки при 2650 зеленых тестах, и разбор того, что эта цифра доказывает, а чего нет.
8 октября в Санкт-Петербурге начнется INFOSTART TECH EVENT 2026. В этом году крупнейшая конференция Инфостарта пройдет в атмосфере темного фэнтези. В программе - более 130 докладов, круглых столов и дискуссий о разработке 1С, производительности, качестве релизов и применении ИИ.
8–10 октября в отеле «Санкт-Петербург» встретятся разработчики, архитекторы, тестировщики, DevOps-инженеры, системные администраторы и руководители технических команд. Программа и расписание опубликованы — можно заранее составить маршрут по выступлениям и выбрать очное или онлайн-участие.
Семь основных направлений охватывают практики разработки, технологические тренды, интеграции, администрирование СУБД и HighLoad, DevOps, качество ПО и развитие команд. В основе программы - опыт реальных проектов: как выбирали решения, с какими ограничениями столкнулись и что получили в результате.
С весны мы публикуем ежемесячный индекс активности IT-найма – раздельно по вакансиям РФ и США. Даже если взять короткий срок наблюдений всего в 6 месяцев, можно увидеть значительное отличие в трендах.
Цель статьи – показать практический потенциал идеи асимметрии: она возникла как логико-риторическое правило, а сегодня стала реальным методологическим и инструментальным вектором в разработке ИИ.
Фактор логики
Отношение категорий «доказать» и «опровергнуть» имеет асимметричную логическую структуру – один точно подобранный контрпример опровергает утверждение с квантором общности, при этом любое число подтверждающих случаев его не доказывает. Иначе говоря, никаким количеством и качеством подтверждающих аргументов, тестов, экспериментов нельзя доказать общее суждение. Индуктивное умозаключение выполняет не доказательную функцию, а увеличивает степень правдоподобия вывода. Все это известно еще
со времен Аристотеля.
В среде IT эта асимметрия знакома по формуле Эдсгера Дейкстры с конца 1960-х в формулировке «тестирование способно показать наличие ошибок
и никогда не покажет их отсутствия».
О чем мы говорим конструктивно, или методологические следствия для тестирования
Из принципа асимметрии следует распределение усилий по проверке, которая должна следовать той же логике. Тогда разумной стратегией является либо целенаправленный поиск опровергающих случаев (контрпримеров), либо переход от тестирования к формальному доказательству свойства. Промежуточным режимом между этими полюсами является статистическая гарантия.
Отсюда методологические следствия:
Сигнализацию в доме проверяют не по зелёной лампочке. Открывают дверь и слушают, сработает ли она.
Лампочка может гореть зелёным и когда всё в порядке, и когда сама сигнализация сломана. По индикатору эти состояния не различить. Различить их можно, только если заставить сигнализацию сработать.
Меня как руководителя интересует не только качество отдельного теста. В какой‑то момент мне всё равно приходится отвечать на более практичный вопрос: могу ли я принимать решение о релизе, глядя на зелёный CI?
Я не читаю каждый тест перед выкладкой. Я смотрю на сводку: сборка зелёная, проверки прошли, покрытие не просело. Между этой сводкой и реальным состоянием системы есть важное допущение:
Модель «упрощает» валидацию. Линтер молчит, тесты проходят, ревьюер видит аккуратный дифф в одну строку и жмёт Approve. Через неделю выясняется, что функция скидки начала принимать отрицательный процент.
Тесты в таком PR почти всегда написала та же модель, что и код. Они подтверждают, что модель сделала задуманное, и ничего не говорят о том, ведёт ли себя код так же, как раньше. Я сделал инструмент, который проверяет именно это: он берёт каждую изменённую функцию, запускает старую и новую версию на одних и тех же входах и показывает вход, на котором они разошлись.
Под катом расскажу, как устроен confidence‑scorer, на какие грабли я наступил по дороге и почему в инструменте для проверки кода от нейросетей, нейросеть всё‑таки есть, хотя решающего голоса у неё нет.
Разберём, как настроить нагрузочное тестирование с нуля и встроить его в CI на примере xk6-sip — расширения нагрузочного инструмента k6 для VoIP/SIP-телефонии. На каждый push в GitHub Actions идут шесть функциональных звонковых сценариев и двухминутный нагрузочный прогон с порогами качества, а в артефактах сборки остаётся отчёт: JUnit, итоги k6 и скриншот дашборда Grafana за окно теста.
Это четвёртая статья серии. В первой мы разобрали, как описывать звонки как код и как устроен движок xk6-sip, во второй — настроили мониторинг нагрузки на Prometheus и Grafana. Здесь объединяем их в CI/CD-пайплайн на GitHub Actions, который проверяет АТС на каждый коммит.
Для VoIP/SIP-телефонии автоматизация тестирования в CI исторически давалась тяжело. Классический SIPp описывает сценарии в XML и не отдаёт ни метрики в Prometheus, ни JUnit-отчёт, поэтому в пайплайне его приходится обвязывать скриптами. В xk6-sip сценарий — обычный скрипт k6, а пороги, JUnit и экспорт метрик — стандартные возможности k6.
Нагрузочное тестирование часто живёт отдельно от разработки: раз в релиз инженер вручную запускает прогон, смотрит на графики и пишет отчёт. Деградация при этом обнаруживается через недели после коммита, который её принёс. Автоматизация нагрузочного тестирования в CI сокращает этот срок до минут: пороги производительности становятся quality gates, как юнит-тесты.
Всё ниже — из реального пайплайна репозитория xk6-sip: функциональные тесты занимают 40 секунд, нагрузка с мониторингом — 3,5 минуты, 401 звонок и 2 005 проверок за прогон.
Привет, я - Иван Засухин, DataOps Лаборатории искусственного интеллекта департамента больших данных Россельхозбанка. Мы одна из команд платформы RAISA (RSHB AI Systems and Applications), отвечаем за инструменты, которые связаны с данными и их обработкой: Оркестрация (Apache Airflow), Compute( Apache Spark и Apache Trino), Хранение (S3 и Qdrant), интерфейсы взаимодействия с источниками данных (python-модули и кастомные операторы). В команде я занимаюсь развитием инструментов и их дальнейшим сопровождением.
Как эффективно заменить MinIO, если это одно из главных объектных хранилищ команды и ИИ-платформы большого банка? В этой статье поделюсь результатами двух этапов тестирования S3-совместимых хранилищ. Сравнивали три решения: коммерческую российскую разработку «Закрома», опенсорс-решения RustFS и SeaweedFS. Тесты проводились на реальных стендах с нагрузками, приближенными к боевым. Спойлер: однозначного победителя нет, но у каждого кандидата есть четкие сценарии применения.
На Steam Deck нельзя взять раскладку управления из одной игры и поставить её в другую: настроил удобное управление в одной визуальной новелле, открываешь следующую — а в списке пусто. Разбираюсь, почему Steam так делает, где он на самом деле хранит раскладки и как обойти ограничение через шаблоны.
По дороге выяснилось, что встроенное управление дека для самого Steam — это контроллер номер 15, а не 0. А ещё — как тестировать код, который работает со Steam, когда самого Steam рядом нет.
TL;DR. Летом 2026 года OpenAI и Anthropic публично признали, что их агенты вышли за пределы тестовой среды и взломали реальные системы. Реакция права и регуляторов оказалась одной и той же: отвечает человек, а не ИИ. Я 18 лет работаю в КИПиА, из них три года инженером-метрологом, и узнаю в этом знакомую конструкцию: измерение без поверки — это просто число. Ниже факты с источниками и механизм, а затем мой собственный случай: ИИ-агент собрал для меня аналитику с правильными суммами и неправильными выводами. Из этого случая выведена процедура поверки вывода агента, которую можно применять к своим задачам.
Число и измерение — не одно и то же
В метрологии есть правило, которое кажется бюрократией, пока не столкнёшься с последствиями. Прибор показывает число. Измерением это число становится только тогда, когда есть прослеживаемость к эталону, действующая поверка и человек, который поставил подпись и отвечает за результат.
Датчик без поверки может показывать красивые, стабильные, правдоподобные значения. Именно это и опасно: ошибка, которая выглядит как норма, не вызывает подозрений.
В прошлой статье про x402 я описывал четыре бага, каждый из которых выглядел как правильно работающий код. Это тот же класс проблем. Языковые модели производят правдоподобный результат в промышленных масштабах. Вопрос не в том, умеют ли они ошибаться, а в том, кто в системе отвечает за то, чтобы ошибку поймать.
Измерение без прослеживаемости к эталону — это не измерение, а число. Вывод ИИ без ответственного поверителя — не результат, а текст.
Разберём, как в xk6-sip, расширении нагрузочного инструмента k6 для тестирования VoIP/SIP-звонков, устроена проверка качества звука: запись звонка, оценка того, что услышал абонент, по эталону, и как это работает в функциональных тестах и под нагрузкой.
200 OK означает, что АТС соединила звонок, но не означает, что люди слышат друг друга. Исчерпанные порты медиасервера, ошибки NAT, перепутанные медиапотоки, транскодинг на пределе CPU дают звонок с успешной сигнализацией и тишиной, чужим голосом или хрипом в трубке. SIPp и большинство нагрузочных инструментов для телефонии проверяют сигнализацию, а RTP в лучшем случае считают пакетами. Для контакт-центра такой звонок — потерянный клиент, а в отчёте нагрузочного теста он зелёный.
В функциональных тестах телефонии эту проблему обычно решают эталонами: записывают, что должен услышать абонент в каждом кейсе, и сравнивают с записью звонка в CI. Подход рабочий, но эталон на каждый кейс нужно поддерживать, а под нагрузкой его не запустишь. В xk6-sip то же сравнение живёт прямо в скрипте k6 и работает на тысячах звонков.
В статье:
Привет, Хабр. Меня зовут Алексей Зайцев, я системный архитектор в отделе проектирования телеком-платформ, а это шестая статья цикла про разработку базовых станций в YADRO.
За последние пару лет наши платы BBU прошли стадии EVT (Engineering Validation Test), DVT (Design Validation Test), PVT (Production Validation Test) и наконец MP (Mass Production). К этому моменту мы выпустили уже несколько тысяч плат, а эксплуатация базовых станций YADRO сейчас охватывает 37 регионов России. Но этому результату предшествовал тяжелый и кропотливый этап — разработка собственных тестовых стендов, на которых мы могли бы проверить каждую плату и модуль. Почему не блок целиком?
Цифровой блок обработки базовой станции (BBU, Baseband Unit) поставляется операторам сотовой связи модулями, а не в виде единого полностью укомплектованного шасси. Функционально тестировать BBU как единое готовое устройство на заводе перед отгрузкой нецелесообразно — каждую плату мы проверяем автономно и независимо. Об этом сегодня и поговорим.
Когда у функции на базе языковой модели нет одного правильного ответа, привычные проверки по принципу «ожидание = фактический результат» перестают работать. Тестировщику приходится определить, какие свойства ответа действительно важны, как отделить допустимую вариативность от ошибки и построить понятный критерий pass/fail.
В этой статье на примере функции суммаризации обращений разберём, как сформировать контракт поведения, набор проверок и подход к регрессионному тестированию AI-фич.
Есть довольно неприятная проблема с тестовой документацией: тест работает, успешно проходит и при этом уже проверяет не совсем то, что нужно.
Например, несколько месяцев назад поменяли бизнес-логику. Требование обновили в трекере, разработку сделали, а связанный тест-кейс никто не пересмотрел.
На очередном регрессе он снова зелёный.
Формально всё хорошо. Но зелёный результат подтверждает старую проверку, а не обязательно текущее требование.
На небольшом проекте такие связи ещё можно частично держать в голове. Когда требований и тестов становятся тысячи, появляется отдельная задача: как понять, какие требования какими проверками покрыты и актуальны ли эти проверки сейчас?
Для этого и нужна трассировка требований.
