Сім open-source інструментів для перевірки ШІ-коду перед продакшеном

Ваш асистент для коду повідомляє, що робота готова, тести зелені, а застосунок працює в прев'ю. Здається, що справу зроблено. Зазвичай це не так.

Зелений прогін тестів доводить лише те, що тести пройшли. Чи впали б ці тести на зламаній реалізації — окреме питання. Як і кілька інших: чи не прослизнув у коміт якийсь ключ, чи немає в підтягнутих пакетах відомих дір і що буде, якщо застосунок одночасно відкриють п'ятдесят людей? Сам асистент на такі питання рідко відповідає.

Ці прогалини закривають сім open-source інструментів, і кожен дивиться зі свого боку: надійність тестів, секрети, що витекли, вразливі залежності, патерни в коді, мертвий код, доступність і навантаження. Кілька з них націлені на JavaScript і TypeScript, тому особливо добре пасують до вебзастосунків, створених ШІ. Проженіть їх до того, як будь-що потрапить у продакшен.

StrykerJS: а ваші тести взагалі кусаються?

StrykerJS — фреймворк мутаційного тестування для JavaScript і TypeScript. Він вносить у вихідний код дрібні навмисні зміни, наприклад перевертає порівняння чи видаляє оператор, і щоразу заново запускає набір тестів. Якщо після зміни всі тести, як і раніше, проходять, у набору є сліпа пляма. Відсотки покриття цього не покажуть, бо рядок може виконуватися, але так жодного разу й не перевірятися.

На невеликому проєкті його можна спробувати одразу:

pnpm add --save-dev @stryker-mutator/core
# Only for small projects:
npx stryker run

Без конфігурації він використовує розумні значення за замовчуванням: запускає npm test як команду тестів і шукає код для мутацій у lib і src.

Gitleaks: ловіть секрети заздалегідь

Gitleaks сканує файли й історію Git у пошуках облікових даних на кшталт API-ключів і токенів. Його можна запускати вручну або вбудувати в автоматичний пайплайн, і тоді ключ, що витік, зупинять до того, як він розійдеться клонами й форками. Згенерований код — часте джерело цієї проблеми, адже модель охоче вставляє ключ-заглушку, який потім виявляється справжнім.

Щоб завантажити й зібрати його:

git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build

OSV-Scanner: знайте, від чого ви залежите

OSV-Scanner звіряє пакети з ваших lock-файлів із базою вразливостей OSV. Він повідомляє, для яких саме ваших версій опубліковано попередження, і дає конкретну картину ризику, який приносять залежності. Асистенти часто додають бібліотеки не замислюючись, тож ця перевірка швидко окуповується.

Зібрати його можна за допомогою Go:

go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest

Semgrep: статичний аналіз за правилами

Semgrep — швидкий open-source статичний аналізатор. Він шукає патерни в коді, щоб знаходити баги, позначати небезпечні конструкції й стежити за дотриманням домовленостей команди. Він розуміє понад тридцять мов і працює в редакторі, як pre-commit хук або всередині задачі CI/CD.

Встановлюється через pip:

 python3 -m pip install semgrep

Knip: видаліть те, чим ніхто не користується

Knip знаходить у проєктах на JavaScript і TypeScript файли, залежності й експорти, на які ніщо не посилається. У згенерованому коді залишки накопичуються швидко: покинуті хелпери, пакети, які додали й так і не імпортували. Їхнє чищення зменшує навантаження на супровід і робить репозиторій читабельнішим у міру його зростання.

axe-core: перевірки доступності

axe-core — рушій для тестування доступності вебсторінок та інших інтерфейсів на HTML. Він швидкий і легкий і підключається до будь-якої тестової зв'язки, яка у вас уже є, тож перевірки доступності можуть стояти поруч зі звичайними функціональними. Асистенти схильні видавати розмітку, яка виглядає правильно, але в ній бракує міток, ролей і контрасту, і саме так ви це помітите.

k6: як воно поводиться під навантаженням?

k6 — інструмент навантажувального тестування. Ви описуєте сценарії в коді, вимірюєте час відповіді й частку помилок і задаєте пороги, які автоматично валять прогін, якщо продуктивність просідає. Невеликий приклад:

import http from "k6/http";
import { check, sleep } from "k6";

// Test configuration
export const options = {
  thresholds: {
    // Assert that 99% of requests finish within 3000ms.
    http_req_duration: ["p(99) < 3000"],
  },
  // Ramp the number of virtual users up and down
  stages: [
    { duration: "30s", target: 15 },
    { duration: "1m", target: 15 },
    { duration: "20s", target: 0 },
  ],
};

// Simulated user behavior
export default function () {
  let res = http.get("https://quickpizza.grafana.com");
  // Validate response status
  check(res, { "status was 200": (r) => r.status == 200 });
  sleep(1);
}

Скрипт імітує десять віртуальних користувачів протягом тридцяти секунд, і кожен робить паузу в секунду між запитами. Його пороги вимагають, щоб 95-й перцентиль часу відповіді лишався нижче 500 мс, а невдалих запитів було менше 1%.

Збережіть файл як test.js, встановіть k6 і запустіть його командою k6 run test.js.

Збираємо все докупи

Жоден із цих інструментів не доводить, що ваш застосунок коректний, і не мусить. Разом вони закривають питання, які пропускає успішне демо. Почніть із Gitleaks і OSV-Scanner: вони займають хвилини й ловлять найдорожчі помилки. Потім додайте Stryker і Semgrep для перевірки самого коду, Knip для його чищення, axe-core для доступності й k6 для трафіку. Якщо до вашого власного чек-листа проситься інший open-source інструмент, додайте його. Мета щоразу одна: довіряйте результату лише після того, як щось спробувало його зламати.