Нейросеть для кода Java: агент, тесты и Spring без лишних правок

Нейросеть для кода Java полезна, пока она работает внутри ваших правил: той версии JDK, того стиля внедрения зависимостей и тех библиотек, что уже есть в проекте. Без правил агент охотно добавит Lombok в проект, где его никогда не было, подтянет новую версию библиотеки в pom.xml или перепишет половину слоя сервисов ради одной мелкой правки. Ниже: как задать рамки, какие команды сборки дать, как генерировать тесты и как проверять результат, а также сколько это стоит.

Что поручать нейросети в Java-проекте

Хорошо ложатся на агента задачи с чёткой проверкой результата:

• unit-тесты для существующих классов (JUnit 5, Mockito);
• рутинный код: DTO, мапперы, простые репозитории;
• рефакторинг по образцу («сделай так же, как в OrderService»);
• разбор стек-трейсов, особенно длинных цепочек Caused by;
• миграции между версиями API внутри проекта.

Хуже подходят задачи без проверки: «улучши архитектуру», «оптимизируй». Какая модель лучше справится, заранее неизвестно, поэтому проверяйте на своих задачах.

Правила для агента: файл инструкций

В корень проекта положите файл инструкций: CLAUDE.md для Claude Code или AGENTS.md для Codex (см. как писать CLAUDE.md↗). Для Java-проекта полезен такой минимум:

## Проект
- Java 21, Spring Boot, сборка Maven (wrapper: ./mvnw).
- Внедрение зависимостей только через конструктор. Не используй field injection.
- Lombok в проекте не используется, не добавляй его.
- Тесты: JUnit 5 и Mockito. Новые зависимости не добавляй без вопроса.

## Команды
- Сборка и тесты: `./mvnw -q test`
- Один тестовый класс: `./mvnw -q test -Dtest=OrderServiceTest`
- Перед ответом «готово» тесты должны проходить.

## Границы
- Не меняй pom.xml, application.yml и миграции базы без явной просьбы.
- Не переименовывай публичные классы и методы вне задачи.

Версии и тип сборки подставьте свои. Если у вас Gradle, команды другие: ./gradlew test для всех тестов и ./gradlew test --tests "com.example.OrderServiceTest" для одного класса. Если в проекте нет wrapper-скриптов, используйте установленные mvn или gradle.

Файл не должен быть длинным: он уходит в контекст каждого запроса, и каждый лишний абзац оплачивается как входные токены.

Генерация тестов: пример

Допустим, есть сервис:

public class PriceService {
    private final DiscountRepository discounts;

    public PriceService(DiscountRepository discounts) {
        this.discounts = discounts;
    }

    public long finalPrice(long basePrice, String promoCode) {
        if (basePrice < 0) {
            throw new IllegalArgumentException("basePrice must be >= 0");
        }
        int percent = discounts.findPercent(promoCode).orElse(0);
        return basePrice - basePrice * percent / 100;
    }
}

Хороший запрос агенту: «Напиши JUnit 5 тесты для PriceService.finalPrice с Mockito. Покрой: нет промокода, процент 10, процент 100, отрицательная цена. Не меняй сам класс». Ожидаемый результат выглядит примерно так:

@ExtendWith(MockitoExtension.class)
class PriceServiceTest {

    @Mock
    DiscountRepository discounts;

    @InjectMocks
    PriceService service;

    @Test
    void noPromoCodeMeansNoDiscount() {
        when(discounts.findPercent("NONE")).thenReturn(Optional.empty());
        assertEquals(1000, service.finalPrice(1000, "NONE"));
    }

Тесты нужно не только запустить, но и прочитать. Типичные проблемы сгенерированных тестов: проверяется то, что делает код, а не то, что он должен делать (баг закрепляется в тесте); лишние verify на детали реализации; Mockito-заглушки, которые никогда не вызываются, из-за чего строгий режим падает. Хороший приём: попросите агента отдельно перечислить граничные случаи до написания кода, и сверьте список со своим пониманием.

Как проверять результат

1. Запустите тесты командой из файла инструкций. Зелёные тесты у модели не доказательство: убедитесь, что новые тесты действительно падают, если сломать код (временно поменяйте формулу).
2. Посмотрите diff целиком: нет ли изменений в pom.xml, конфигах, чужих файлах.
3. Проверьте импорты и зависимости: модели иногда выдумывают несуществующие методы библиотек. Компиляция это поймает, но неочевидные случаи вроде устаревших API лучше проверить по документации библиотеки.
4. Для Spring отдельно проверьте аннотации и версию Spring Boot: между мажорными версиями меняются пакеты и поведение. Укажите версию в файле инструкций.

Чтобы агент работал в рамках, Claude Code и Codex умеют запрашивать подтверждение перед выполнением команд; не отключайте это на основном репозитории. Подключение описано в документации Claude Code↗; если вы работаете в IntelliJ, обратите внимание на статью про JetBrains AI Assistant↗.

Какую модель пробовать

Мы не утверждаем, что какая-то модель лучше пишет Java. Сравнивайте по цене, контексту и индексу силы (Intelligence Index, Artificial Analysis), затем проверьте 5-10 своих задач. Цены Zukko на 18 октября 2026, $ за 1M токенов:

Расчёт: тесты для 30 классов

Допущение: на каждый класс 6 000 токенов входа (класс, соседние файлы, правила) и 1 500 токенов выхода (тест). Итого вход 30 × 6 000 = 180 000, выход 30 × 1 500 = 45 000.

• claude-sonnet-5-5: 0.18 × $0.4 + 0.045 × $2 = $0.072 + $0.09 = $0.162. По официальным ценам: 0.18 × $2 + 0.045 × $10 = $0.36 + $0.45 = $0.81.
• gpt-6.1-sol: 0.18 × $0.27 + 0.045 × $1.32 = $0.0486 + $0.0594 = $0.108.
• glm-5.3-flash: 0.18 × $0.04 + 0.045 × $0.04 = $0.0072 + $0.0018 = $0.009.

Это без кэша и без повторных итераций, когда тест приходится переделывать. Реальный расход смотрите в разделе «Использование» кабинета. Актуальный список и цены: GET https://api.zukko.pro/v1/models.

Подключение

Claude Code: ANTHROPIC_BASE_URL=https://api.zukko.pro (без /v1), ANTHROPIC_AUTH_TOKEN=fetch_.... Для OpenAI-совместимых инструментов и скриптов: https://api.zukko.pro/v1. Если нужен вызов из самого Java-приложения, пример со Spring AI разобран в статье Spring AI и Claude↗. Ключ создаётся в кабинете↗; задайте дневной лимит, пока тестируете.

Частые вопросы

Можно ли доверять сгенерированным тестам?

Только после чтения. Проверьте, что тест падает на сломанном коде и что он проверяет требуемое поведение, а не копирует реализацию.

Как не дать агенту менять pom.xml?

Напишите это в файле инструкций и не выдавайте разрешение на правку при запросе подтверждения. Просмотрите diff перед коммитом.

Подойдёт ли недорогая модель для Spring?

Для рутины (DTO, простые тесты) часто да, но проверьте на своём коде. Для запутанных вещей вроде транзакций и конфигурации сравните с более сильной моделью.

Что делать с устаревшим API в ответе?

Укажите в файле инструкций версии Java и Spring Boot и просите ссылаться на конкретные классы. Спорный фрагмент сверяйте с документацией библиотеки.