AI Review не отвечает за качество ревью - он лишь оркестратор между LLM и VCS
Результат зависит от модели и промптов: gpt-4o дает самые стабильные ответы, Claude - хорошо умеет в код, Gemini - самый быстрый и дешевый (и качество соответствующее). Ollama - зависит от выбранной модели и ресурсов, где развернута: Mistral средний вариант, Ollama 3 показывает себя лучше.
Добрый день! На самом деле все просто :) По умолчанию встроенные промпты написаны на английском - поэтому и комментарии формируются на английском. Чтобы перевести ревью на нужный язык (например, русский), достаточно переопределить шаблоны промптов в своем проекте
В корне проекта создайте папку:
./prompts/
Скопируйте туда три файла с собственными инструкциями на русском, например:
inline.md
context.md
summary.md
В конфиге .ai-review.yaml укажите путь к этим файлам:
Да, в теории - можно. Там нет завязки на конкретного провайдера, архитектура сделана так, что можно добавить адаптер под любую LLM
Пока из коробки реализованы OpenAI, Claude и Gemini - просто как самые распространенные. При желании - можно форкнуть, легко добавить поддержку локальных LLM
Если коротко: при использовании личного токена OpenAI (или другого публичного провайдера) ваши запросы и контекст (в данном случае - код) могут использоваться для дообучения модели, если не включён специальный корпоративный режим.
OpenAI прямо пишет в политике, что данные, отправленные через обычные персональные ключи, могут использоваться для улучшения моделей. Поэтому, если вы используете такой ключ в CI/CD или на корпоративном репозитории, - фактически весь код улетает в OpenAI.
Для бизнеса у них есть корп тарифы, где обучение отключено и контент не сохраняется. Именно об этом я и говорю:
личный токен = данные могут попасть в дообучение;
корпоративный токен = данные не сохраняются и не используются.
Для многих компаний это вопрос инфобеза и регуляторных требований (GDPR, ISO, SOC2 и т.д.), поэтому важно разделять ключи и не использовать личные для рабочих репозиториев, иначе могут быть последствия
В целом, да, качество кода и удобство использования не всегда напрямую связаны. Можно сделать очень грязную реализацию, которая при этом покажется удобной. Но проблема в том, что такие "удобные костыли" плохо масштабируются: как только тестов становится больше или проект сложнее, начинаются флейки, неотлаживаемость и технический долг. Как писал в статье:
«Работает — не трогай. Сломалось — не починишь».
И да, Pytest когда-то распространялся одним файлом (я тоже помню те времена :)), но там ключевое отличие: даже в таком виде это был инструмент с продуманной архитектурой и четкой зоной ответственности. Одно дело - минималистичная поставка зрелого фреймворка, другое - свалка из 3500 строк, где UI, API, SQL, "безопасность" и нагрузка вперемешку.
Рад, что оказалось полезно :) Решил сделать подробный разбор потому, что на курсах у студентов этот вопрос про асинхронность возникает постоянно. У многих есть ожидание, что если в коде поставить "магические" async/await, то тесты сразу ускорятся в 10 раз, а то и больше. На деле же важнее правильно оптимизировать архитектуру и подход к тестированию
Да, требования часто перегибают. Но опыт в QA — это по факту хороший трамплин: дальше можно уйти в разработку, аналитику или продуктовую роль. Это вполне рабочая стратегия роста.
Я использовал pytest-asyncio, потому что хотел показать сам принцип работы async/await в тестах и как именно приходится переписывать фикстуры, PageObject и API-клиентов.
pytest-playwright-asyncio существует, но он решает другую задачу - просто дает встроенные async-фикстуры для Playwright. В то время, как pytest-asyncio в целом открывает опцию писать async/await в pytest, эти два плагина про разное.
Для целей статьи это не критично, поэтому я сделал вручную через async_playwright(). Суть статьи ведь не в том, какой плагин выбрать, а в том, что сама по себе асинхронность не делает тесты быстрее и без понимания, зачем она нужна, превращается скорее в усложнение, чем в пользу.
Да, в ряде проектов это дается непросто, особенно при работе с внешними командами. Но, как показывает практика, в большинстве случаев внедрить тестовые id все же можно, вопрос лишь в том, какими усилиями.
Я даже писал об этом отдельную статью: "Тестовые идентификаторы: как и где расставлять правильно". Где-то достаточно просто договориться с фронтенд-разработчиками и показать им минимальную документацию, а где-то придётся пройти через все круги бюрократии, обсуждения и "security hell". Но результат обычно стоит затраченных усилий - особенно на долгой дистанции поддержки автотестов.
Это классика - QA и HR исторически считались самыми "легкими" и быстрыми путями входа в IT, поэтому здесь всегда был высокий поток новичков. Сейчас, когда рынок перегрет, логично смотреть и в другие направления, в том числе DevOps, аналитика, разработка - просто путь туда обычно чуть длиннее и требует более специфической подготовки.
Да, требования выросли, и рынок стал более конкурентным. Тут, к сожалению, либо растем и подстраиваемся под новые ожидания работодателей, либо рассматриваем смежные направления, где можем применить свой опыт. По личным наблюдениям, сейчас многие коллеги из QA делают переход в разработку, системный анализ или DevOps - это помогает расширить зону востребованности.
Кстати, видел проект, естественно платный, где ставят телефон, а над ним - робота, который буквально "пальцем" нажимает кнопки на экране. Насколько стабильно это работает - вопрос, но кто-то уже явно пытается заменить нас роботами :)
Пока мы можем сами воспроизводить и изолировать баги - роботы наши места не отберут :) А если когда-нибудь научатся делать это стабильно, значит, появятся новые роли для тех, кто сможет ими грамотно управлять
Согласен, автоматизация - это естественный путь развития тестирования, и сама идея действительно не нова. Вопрос в том, как и за какую цену её реализовать :)
Если сравнить написание автотестов 10 лет назад и сегодня - это совершенно разные задачи, с разным инструментарием, скоростью и стоимостью внедрения. И вот здесь современные AI-инструменты, включая ChatGPT, могут сильно ускорить и удешевить процесс, даже если они не являются основной причиной сокращения вакансий для ручных тестировщиков.
Да, скорее всего дело в ограниченном контексте (токенах) - на больших файлах/классах Copilot теряет контекст и начинает тупить. Возможно это также лимитации бесплатной версии
По моему опыту, AI Assistant работает заметно лучше, особенно в GoLand, WebStorm, PyCharm. Поэтому на него и решил перейти :)
Полностью согласен - вопрос безопасности критичен.
Для этого существуют корпоративные лицензии аля ChatGPT Enterprise, где они гарантируют, что данные сотрудников не используются для обучения моделей. Не знаю на сколько это правда, но даже в этом случае все зависит от внутренней политики компании и согласования с ИБ.
Думаю, что идея стать "повелителем ИИ" вполне жизнеспособная :) На рынке уже давно востребованы ML-инженеры, специалисты по Data Science и AI-интеграции. Например, в финтехе большая часть риск-менеджмента и антифрода уже давно строится на нейросетях
Что касается сценария с "обрубленным" интернетом, честно, сложно дать однозначный прогноз. Пример с YouTube показал, что даже при ограничениях находят способы обхода. Думаю, в случае серьезных ограничений IT-комьюнити также будет искать технические решения, чтобы сохранить доступ к зарубежным источникам знаний
Долго чесал голову над тем, что именно за посыл заключен в этой фразе.
Такой посыл и был: сделать простую задачу чрезмерно сложной, когда инструменты подобраны не по задаче, а по принципу "так модно". Но, согласен, метафора может восприниматься по-разному :) Возможно, здесь уместнее была бы другая метафора: вас просят просто передать сахар, а вы в ответ начинаете проектировать систему автоматизированной доставки сахара с сенсорами, очередями и логами
Пока нет, но это вопрос интеграции. Можно закинуть feature request сюда: https://github.com/Nikita-Filonov/ai-review/issues
AI Review не отвечает за качество ревью - он лишь оркестратор между LLM и VCS
Результат зависит от модели и промптов: gpt-4o дает самые стабильные ответы, Claude - хорошо умеет в код, Gemini - самый быстрый и дешевый (и качество соответствующее). Ollama - зависит от выбранной модели и ресурсов, где развернута: Mistral средний вариант, Ollama 3 показывает себя лучше.
Добрый день! На самом деле все просто :) По умолчанию встроенные промпты написаны на английском - поэтому и комментарии формируются на английском. Чтобы перевести ревью на нужный язык (например, русский), достаточно переопределить шаблоны промптов в своем проекте
В корне проекта создайте папку:
Скопируйте туда три файла с собственными инструкциями на русском, например:
В конфиге
.ai-review.yamlукажите путь к этим файлам:Все, теперь AI Review будет использовать именно ваши тексты промптов, а значит - комментировать на русском
Да, в теории - можно. Там нет завязки на конкретного провайдера, архитектура сделана так, что можно добавить адаптер под любую LLM
Пока из коробки реализованы OpenAI, Claude и Gemini - просто как самые распространенные. При желании - можно форкнуть, легко добавить поддержку локальных LLM
Если коротко: при использовании личного токена OpenAI (или другого публичного провайдера) ваши запросы и контекст (в данном случае - код) могут использоваться для дообучения модели, если не включён специальный корпоративный режим.
OpenAI прямо пишет в политике, что данные, отправленные через обычные персональные ключи, могут использоваться для улучшения моделей. Поэтому, если вы используете такой ключ в CI/CD или на корпоративном репозитории, - фактически весь код улетает в OpenAI.
Для бизнеса у них есть корп тарифы, где обучение отключено и контент не сохраняется. Именно об этом я и говорю:
личный токен = данные могут попасть в дообучение;
корпоративный токен = данные не сохраняются и не используются.
Для многих компаний это вопрос инфобеза и регуляторных требований (GDPR, ISO, SOC2 и т.д.), поэтому важно разделять ключи и не использовать личные для рабочих репозиториев, иначе могут быть последствия
В целом, да, качество кода и удобство использования не всегда напрямую связаны. Можно сделать очень грязную реализацию, которая при этом покажется удобной. Но проблема в том, что такие "удобные костыли" плохо масштабируются: как только тестов становится больше или проект сложнее, начинаются флейки, неотлаживаемость и технический долг. Как писал в статье:
И да, Pytest когда-то распространялся одним файлом (я тоже помню те времена :)), но там ключевое отличие: даже в таком виде это был инструмент с продуманной архитектурой и четкой зоной ответственности. Одно дело - минималистичная поставка зрелого фреймворка, другое - свалка из 3500 строк, где UI, API, SQL, "безопасность" и нагрузка вперемешку.
Рад, что оказалось полезно :) Решил сделать подробный разбор потому, что на курсах у студентов этот вопрос про асинхронность возникает постоянно. У многих есть ожидание, что если в коде поставить "магические"
async/await, то тесты сразу ускорятся в 10 раз, а то и больше. На деле же важнее правильно оптимизировать архитектуру и подход к тестированиюДа, требования часто перегибают. Но опыт в QA — это по факту хороший трамплин: дальше можно уйти в разработку, аналитику или продуктовую роль. Это вполне рабочая стратегия роста.
Я использовал
pytest-asyncio, потому что хотел показать сам принцип работыasync/awaitв тестах и как именно приходится переписывать фикстуры, PageObject и API-клиентов.pytest-playwright-asyncioсуществует, но он решает другую задачу - просто дает встроенные async-фикстуры для Playwright. В то время, какpytest-asyncioв целом открывает опцию писатьasync/awaitвpytest, эти два плагина про разное.Для целей статьи это не критично, поэтому я сделал вручную через
async_playwright(). Суть статьи ведь не в том, какой плагин выбрать, а в том, что сама по себе асинхронность не делает тесты быстрее и без понимания, зачем она нужна, превращается скорее в усложнение, чем в пользу.Да, в ряде проектов это дается непросто, особенно при работе с внешними командами. Но, как показывает практика, в большинстве случаев внедрить тестовые id все же можно, вопрос лишь в том, какими усилиями.
Я даже писал об этом отдельную статью: "Тестовые идентификаторы: как и где расставлять правильно". Где-то достаточно просто договориться с фронтенд-разработчиками и показать им минимальную документацию, а где-то придётся пройти через все круги бюрократии, обсуждения и "security hell". Но результат обычно стоит затраченных усилий - особенно на долгой дистанции поддержки автотестов.
Это классика - QA и HR исторически считались самыми "легкими" и быстрыми путями входа в IT, поэтому здесь всегда был высокий поток новичков. Сейчас, когда рынок перегрет, логично смотреть и в другие направления, в том числе DevOps, аналитика, разработка - просто путь туда обычно чуть длиннее и требует более специфической подготовки.
Да, требования выросли, и рынок стал более конкурентным. Тут, к сожалению, либо растем и подстраиваемся под новые ожидания работодателей, либо рассматриваем смежные направления, где можем применить свой опыт. По личным наблюдениям, сейчас многие коллеги из QA делают переход в разработку, системный анализ или DevOps - это помогает расширить зону востребованности.
Кстати, видел проект, естественно платный, где ставят телефон, а над ним - робота, который буквально "пальцем" нажимает кнопки на экране. Насколько стабильно это работает - вопрос, но кто-то уже явно пытается заменить нас роботами :)
Пока мы можем сами воспроизводить и изолировать баги - роботы наши места не отберут :) А если когда-нибудь научатся делать это стабильно, значит, появятся новые роли для тех, кто сможет ими грамотно управлять
Согласен, автоматизация - это естественный путь развития тестирования, и сама идея действительно не нова. Вопрос в том, как и за какую цену её реализовать :)
Если сравнить написание автотестов 10 лет назад и сегодня - это совершенно разные задачи, с разным инструментарием, скоростью и стоимостью внедрения. И вот здесь современные AI-инструменты, включая ChatGPT, могут сильно ускорить и удешевить процесс, даже если они не являются основной причиной сокращения вакансий для ручных тестировщиков.
Да, скорее всего дело в ограниченном контексте (токенах) - на больших файлах/классах Copilot теряет контекст и начинает тупить. Возможно это также лимитации бесплатной версии
По моему опыту, AI Assistant работает заметно лучше, особенно в GoLand, WebStorm, PyCharm. Поэтому на него и решил перейти :)
Полностью согласен - вопрос безопасности критичен.
Для этого существуют корпоративные лицензии аля ChatGPT Enterprise, где они гарантируют, что данные сотрудников не используются для обучения моделей. Не знаю на сколько это правда, но даже в этом случае все зависит от внутренней политики компании и согласования с ИБ.
Думаю, что идея стать "повелителем ИИ" вполне жизнеспособная :) На рынке уже давно востребованы ML-инженеры, специалисты по Data Science и AI-интеграции. Например, в финтехе большая часть риск-менеджмента и антифрода уже давно строится на нейросетях
Что касается сценария с "обрубленным" интернетом, честно, сложно дать однозначный прогноз. Пример с YouTube показал, что даже при ограничениях находят способы обхода. Думаю, в случае серьезных ограничений IT-комьюнити также будет искать технические решения, чтобы сохранить доступ к зарубежным источникам знаний
Добрый день! Тут все зависит от задачи:
Для работы в IDE раньше пользовался GitHub Copilot, сейчас перешел на AI Assistant от GetBrains, потому лучше интегрируется в мой текущий стек
Для автоматизации рабочих процессов связка
api.chatgpt+n8n, очень удобно для генерации моков, тестов, массовой обработки JSON, анализа логовДля текстов, идей, поиска обычный ChatGPT
Такой посыл и был: сделать простую задачу чрезмерно сложной, когда инструменты подобраны не по задаче, а по принципу "так модно". Но, согласен, метафора может восприниматься по-разному :) Возможно, здесь уместнее была бы другая метафора: вас просят просто передать сахар, а вы в ответ начинаете проектировать систему автоматизированной доставки сахара с сенсорами, очередями и логами