Comments 20
Спасибо за статью. Интересно было почитать результаты.
Пробовали ли вы SDD подход? Т.е. поставить на рельсы требования и сделать их единственной точкой истины и актуальными в любой момент времени?
Кажется, что это могло бы решить часть проблем, которые описаны в статье.
Мне кажется одна из проблем сейчас именно в том, что начинают внедрять с конца или просто изолированно друг от друга.
И сталкиваются с проблемами которых могло не быть, если бы двигались вместе с общим источником контекста, лежащим в 1 месте.
Мне всегда было интересно, в каком мире живут те, у кого в каждый момент времени есть только один актуальный и истинный срез системы, с которой надо работать? Изменение/работа уже предполагают минимум два состояния: как есть и как будет, а значит по умолчанию есть пространство для путаницы. Это навело меня на мысли о том, какие вызовы может встретить подход, где код меняется в реальном времени без откатов. Если это станет возможным, то мы сэкономим на путанице в контексте, но каждая ошибка будет приводить к новому багфиксу, где контекст это весь проект, включая ошибку, вместо отката и переработки только неверного решения. Может это и выгоднее будет, но возможна ли параллельная разработка в таком случае... А нужна ли параллельная разработка, если ИИ в один поток сможет писать код и исправлять ошибки синхронно быстрее, чем путающиеся в контекстах агенты. Вопросов больше, чем ответов.
Совсем не QA, но опыт с ИИ.
Спросил у ИИ, а есть ли что-то вроде поколения Python, но для изучения Java. Ответ: да, от тех же разработчиков, есть поколение Java
Ищу, такого нет. Спрашиваю еще раз.
Ответ: Я ввел вас в заблуждение, такого курса действительно нет
Т. е. ии по факту просто придумывает то, чего нет. Такое может быть и в коде, поэтому пока рано говорить о замене человек ии.
Напомнило ситуацию, когда построили здание, приходит тех надзор, смотрит, вроде выглядит нормально и дает ОК на введение эксплутацию. Через месяц крышу у дома ветром уносит в Уругвай, а фундамент разваливается под тяжестью самого дома
Потом выясняется, что тех надзор тупо не знал, что он вообще проверяет и по каким критериям. Также и с ИИшкой, он может нагородить такой ерунды, но все равно нужен кожаный мешок, который потом за это ответит, чат ботику ты же не предъявишь и в тюрьму его тоже не посадишь
Общался недавно на мероприятии СберТеха с людьми, которые могут сесть в тюрьму за ошибку.
В этот момент подумалось, что основная проблема современного IT в том, что it-шник за свою ошибку в тюрьму не садится, it-шник (хакер) садится в тюрьму за чужие ошибки. И это странно.
И вот эти люди совсем не горят желанием применять ИИ. Основной мотив: всё равно нужно всё перепроверять. А перепроверка подразумевает вычитку огромного объёма сгенерированного материала. Экономика процесса не понятна. "Оно само" не работает. За чей счёт банкет, в итоге? Вот сидит управляющая компания из трёх сотрудниц, и управляет в меру своих возможностей, бюджет у них не космический, токены жечь они не могут себе позволить (даже зарплаты одной сотрудницы, я думаю, не хватит, чтобы нормально обрабатывать всю ту стопку нормативных документов, важные пункты из которых она в голове держит). Специалистов по Python у них нет, чтобы вычитывать код, сгенерированных агентами, сгенерированных агентами, сгенерированных... И чего?
А дальше проблема в том, что тому же Сберу нужно отбивать деньги, инвестированные в ИИ. А у Сбера (у Google, у Microsoft, у Anthropic - нужное подчеркнуть) есть выход на правительство и на людей, которые принимают законы... ИИ-шка, которая не способна решать созидательные задачи, вполне способна решать задачи государственные и военные: анализ соцсетей, боты для формирования общественных настроений, целеуказания всякие (низкая цена ошибки для принимающих решения), массовая обработка неокрепших умов через системы виртуальных подружек и так далее. Поэтому все эти компании на хорошем счету во властных структурах, эти компании реально помогают властям решать проблемы властей. К просьбам этих компаний прислушиваются. А компании хотят, чтобы ИИ был внедрён повсеместно, чтобы отбивать бабки (ну, и собирать данные о пользователях, куда уж без этого?). И находят понимание в этом вопросе. То есть сотрудницам управляющей компании таки придётся ИИ внедрить так или иначе, вне зависимости от его стоимости и эффективности.
И вот чем это закончится?.. Сложно представить.
Когда софт начинает всё в большем количестве ситуаций на ровном месте подглючивать, а экосистемы накрывает вал однотипных забагованных приложений клонов клонов клонов функциональности, в котором становится весьма трудоёмко найти нечто надёжное (скоро деньги можно будет брать, я думаю, просто за доступ к спискам надёжного софта), это ещё не так страшно. Без бажного вконтактика прожить можно. Но вот когда начнут глючить водопроводы, электросети, газопроводы, транспорт и так далее... Вызывает это опасения.
работаю в заграничной компании. Тестирую только backed, так мне ИИ помогает найти все затронутые endpoints, если я с ходу сам не нашел, в этом кайф. Но тестовые примеры и кейсы 5.2 пишет отвратительно
В автоматизации тоже кое как. Pojo сделать - он молодец, а на основе 20 curls написать 40 тестов с разнообразными пограничными и выходящими за границы значениями - он не может 😔
Ну и в конце: все объявили, что ai будет нам помогать, полгода продвигали, а недавно сказали, что токены экономить надо 🤌
А ну и товарищи написали агента, который тест кейсы в зефир пишет на основе тикета. Скинул пару своих тикетов, кейсов 0. Ну, а какие кейсы могут быть при обновлении dependencies в spring? А то, что свагер может поломаться или само приложение не стартануть агент не понимает.
Если конечно все описать в .MD, каждый чих, натравить ещё агента, который проверяет другого агента учитывает ли он данные из MD файла и так далее - может быть да. Но там жизни не хватит же.
Ну последний пример. Скормил я 5.2 кучу логов и 2 проекта и попросил объяснить, почему возникает такая ошибка. Была куча предположений, но верных 0. Нужно было просто в базу сходить и посмотреть, что у юзера просто нет одной переменной. Это даже из логов очевидно было. Может gpt 5.5 справился, но токенов ему надо на много больше
Спасибо за статью! Отличный приземленный разбор.
Появился чисто инженерный вопрос по поводу сбора контекста и поиска «источника истины». Из текста сложилось ощущение, что агент во многом полагался на текстовое описание задач и спеки, из-за чего и увязал в «spec hell».
Скажите, а пробовали ли вы заходить со стороны жесткого детерминированного анализа самой системы, чтобы разгрузить LLM от чтения доки?
Использовались ли инструменты статического анализа кода для Python (парсинг AST для поиска связей, проверка типов через
mypyдля понимания структур данных, построение графов зависимостей/импортов), чтобы агент сразу четко и без галлюцинаций видел архитектуру и связи внутри проекта?Пытались ли вы построить полноценный RAG для поиска нужных вхождений, контрактов и кусков кода по кодовой базе, или агент «выхватывал» контекст по прямым ссылкам из тасок?
Пробовали ли вы Property-Based Testing (PBT)? Поскольку агент хорошо генерировал только очевидные сценарии, не было ли мысли заставить его писать тесты на основе свойств (например, через
hypothesisдля pytest), чтобы сама библиотека генерировала edge-кейсы и цементировала инварианты, раз уж ИИ их не видит?Пытались ли вы зайти со стороны TDD? Был ли опыт, когда MCP-сервер сначала читал спеку/контракты, писал тесты под еще не существующий код, а уже разработчик (или другой ИИ) пытался писать код под эти тесты?
Кажется, что без связки «детерминированный статанализ + RAG» ИИ физически обречен тонуть в хаосе документации. Любопытно, прощупывали ли вы эту сторону. Еще раз спасибо за материал!
А сто нужно сделать для пункта 2?
Разве кодовые агенты по умолчанию не строят семантический индекс?
Немного углублялся как работает под капотом. Вроде тот же RAG в лайт варианте.
Вот пример Copilot Agent.
Почти, для локального автокомплита в IDE это работает отлично. Но "коробочный" семантический индекс жестко ограничен только кодовой базой проекта. Если задача построить автономного QA-агента, нам критически важны внешние источники истины: тикеты в Jira/YouTrack, контракты, Swagger и дока в Confluence. Локальный плагин расширить до полноценной базы знаний не получится. Ну и главный минус вы правильно подсветили: судя по скриншоту, этот индекс требует ручного обновления , что полностью перечеркивает идею автоматизации в CI/CD пайплайнах
Согласен по поводу фрагментации контекста по разным сущностям (Jira, Conflu). Но на сколько мне известно, сейчас некоторые бигтехи пытаются эту задачу решать комплексно отказываясь от привычного флоу с этими сущностями.
Есть фреймворки SDD типа https://github.com/Fission-AI/OpenSpec/ в рамках которых вся спецификация и таски хранится в кодовой репе в md файлах. Соответственно, это все досутпно кодовуму агенту.
Да, но кажется, что со временем спека всё равно стремительно деградирует, и придется как-то решать проблему актуализации и архивации данных. К тому же, простой багфикс, который модель могла бы «ваншотнуть» в коде за пару секунд, становится значительно дороже, если каждый раз строго прогонять его через спецификацию.
Тот же PBT (Property-Based Testing), на мой взгляд, в качестве спецификации дает гораздо больше профита. Хоть он и требует времени на определение инвариантов, зато с ним они буквально «цементируются», и агенту становится гораздо сложнее сделать плохо. При этом мы жестко экономим контекст: вместо тысяч строк классических юнит-тестов можно использовать пару сотен строк PBT, и это даст агенту куда больше полезной инфы, чем любой
.md-файл.Я это всё к чему: современные модели хоть и умеют много всего из коробки, но жесткая обвязка («харднес») вокруг них, на мой взгляд, важнее встроенных тулзов. Чем лучше настроен внешний контур и детерминированная инфраструктура вокруг нейронки, тем предсказуемее и надежнее результат. При этом граница между харднесом и возможностями самой модели постепенно размывается, и наш разговор — прямое тому доказательство.
Иногда мне кажется, что мы начали забывать саму суть QA и кто такие вообще QC. Под QA сгребли всё. Спасибо за обзор.
Спасибо за статью и примеры из вашего опыта
Это как в старом анекдоте: " а потом вложили русские мужики в японскую лесопилку железный лом. -Трр-р, сказала японская лесопила. - Ага, сказали русские мужики и пошли валить лес двуручными пилами"
Ну, т.е. никто же не верит в серьез, что на этом этапе развития технологии можно засунуть в MCP сложный недостоверный неактуальный неконсистентный противоречивый документ на 20000 строк и ждать хорошего результата?
В секции про качество есть слой, который в статье не дораскрыт.
“Тесты покрывают только happy path” - это первый уровень проблемы. Но когда агент пишет и код, и тесты в одном контексте, появляется второй уровень: оба артефакта несут одни и те же предположения. Тест не просто пропускает edge cases, он подтверждает то, что агент предполагал реализовать. CI становится зелёным, и это выглядит как сигнал “всё правильно”. Хотя на самом деле это сигнал “агент с собой согласен”.
Был похожий кейс из практики. Fixture создавала тестовый слот с фиксированными timestamp’ами. В изоляции тест всегда был зелёным. В CI при определённом порядке запуска появлялся SLOT_OVERLAP.
Агент может прочитать спеку, контракты и весь код теста, и не найти там ничего подозрительного. Потому что проблема живёт не в документах, а в том, как тесты взаимодействуют друг с другом во времени: порядок запуска, shared state, побочные эффекты между прогонами. Это слой, который не индексируется.
Успех — это что? Ответ 200? Или воркфлоу стартанул? Или событие упало в Kafka топик? А проверять это как: контрактно, интеграционно, e2e, через мок Kafka?
В данном случае успех — это ответ: “При невнятном ТЗ, результат — ХЗ”
Мы пытались заменить QA нейросетью. Не получилось