Я руковожу отделом тестирования роботизированных систем в Cognitive Pilot. В этой статье расскажу, как устроено тестирование автопилота для сельхозтехники: какие уровни проверок у нас есть, чем они отличаются от обычного QA, что получилось и что пока не получается автоматизировать.
Пусть функция должна разворачивать строку. Агент написал тест: на входе abba, на выходе ожидается abba. Тест зеленый. Он останется зеленым, если функция вообще ничего не делает. Пример учебный, но ошибка выбора входа реальная: в одном из прогонов эксперимента Дэна Лу агент проверял разворот битового потока на палиндроме. Назвал рискованное место, независимо вывел результат, провел аудит […]
Мы много разрабатываем с помощью coding agents: веб‑приложения, MCP‑серверы, пайплайны обработки данных, системы из нескольких агентов. И чем лучше становилась инфраструктура вокруг агентов, тем больше в ней появлялось инструкций, проверок, субагентов и автоматики. По идее, разработка должна была становиться дешевле. А расход контекста рос. Первое подозрение было очевидным: слишком раздутые промпты. Мы искали не там. 38 килобайт текста со смыслом «всё хорошо» Агент закончил […]
Сигнализацию в доме проверяют не по зелёной лампочке. Открывают дверь и слушают, сработает ли она. Лампочка может гореть зелёным и когда всё в порядке, и когда сама сигнализация сломана. По индикатору эти состояния не различить. Различить их можно, только если заставить сигнализацию сработать. Меня как руководителя интересует не только качество отдельного теста. В какой‑то момент мне всё равно приходится отвечать на более практичный вопрос: могу ли я […]
Многие считают, что задача QA — найти как можно больше багов. И чем будет длиннее список в баг‑трекере, тем «полезнее» тестировщик. В этой статье расскажем, почему QA — не просто ловец багов, а инженер качества. Разберем, как инженерный подход к стабильности помогает команде Modus управлять рисками задолго до первой строчки кода и почему это полностью меняет отношение к процессам тестирования. Найденный баг может быть сигналом о проблемах в процессе, а не просто […]
Часть 20: контракты вместо ассертов — проверка того, что не ложится в юнит-тест.
Вокруг кричат, что ИИ заменит разработчиков и даст x10. А наш реальный темп — десятки деплоев в день — держится не на геройстве и не на магии, а на скучной дисциплине: маленькие задачи, зелёные тесты, автодеплой за минуту. Хочу рассказать, почему лучшее в нашей разработке — то, что она скучная. Типичный день в нашем CI […]
Сначала нам советовали подробно задавать правила в промпте. Промпты росли и постепенно превращались в: Ты опытный программист. Пиши хороший код. Плохой код не пиши. Потом появился следующий рецепт: сначала подготовьте подробную документацию, а уже затем поручите агенту писать код. В результате люди начали сначала генерировать агентом документацию, а потом тем же агентом — код по этой документации. Между человеком и кодом просто появился […]
Что теперь программирует настоящий программист? Вы открываете задачу и пишете одну строку: Добавь идемпотентность в API создания заказа. Через некоторое время перед вами diff в незнакомом репозитории. Изменены обработчик API, модель данных, тесты и документация. Все проверки проходят. При этом вы не написали ни одной строки кода.
Активно занимаюсь вайб кодингом. Есть у меня полка. Туда ложатся правила, за которые я ещё не заплатил собственной болью — потому что мойпринцип гласит: правило рождается из прожитого инцидента, а не из чужой «лучшей практики». Возьмёшь чужое правило, боль от которого не прожил сам, — первым же и найдёшь, как его обойти. На полке лежало правило с условием срабатывания, записанным дословно: Первый влитый PR с полностью зелёным чек‑листом DoD — и с абсолютно нерабочим […]