Навайбкодить 10k строк кода за час — дело нехитрое. Но как проверить, что этот код рабочий? Можно потратить много часов на ревью классическим способом, а можно прочитать эту статью и применить у себя новый метод. В материале архитектор Mindbox Саша Кальницкий рассказывает, как перестроил работу с AI‑агентами, чтобы больше им доверять и не тратить время на код‑ревью.

Писать или не писать тесты — выбор очевидный. Конечно, писать. Но если проект масштабный, одних unit‑тестов будет недостаточно: они бессильны на границах модулей, в интеграциях и пользовательских сценариях, а значит в этих местах будут пролезать баги. Такой код будет сложно поддерживать, вносить в него изменения и получать ожидаемый результат.

В статье поговорим про разные стратегии тестирования под разные риски и кейсы. Поднимемся над привычными unit‑тестами и заглянем, что там есть еще. Спойлер: а еще там workflow‑, integration‑, property‑based‑ и resilience‑тесты.

Даже в правильно работающем коде бывает сложно разобраться. Чем больше в нем абстракций, циклов и вложенных условий операторов, тем сложнее представлять в уме его поведение. Приходится перечитывать все несколько раз — ревью затягивается, при доработке легко пропустить баг.

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