Большие языковые модели часто используют как один большой "мозг": написал промпт, нажал Enter - и сразу запускаешь сгенерированный код. Быстро, удобно и наполненно магией. Такой подход можно называть вайб-коддингом.

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

В этой статье я покажу, как относиться к LLM не как к "герою-одиночке", а как к команде ролей (аналитик, ресерчер, архитектор, разработчик, ревьюер, QA, техписатель, валидатор) и собрать полноценный AI-Driven Development (AIDD) процесс с понятными договорами и quality-гейтами на каждом шаге.

Это практический how-to: от минимальной версии до более строгого процесса с ролями, гейтами и интеграцией с CI. Все примеры - на базе Claude Code, но принципы подхода можно перенести и на другие инструменты (Cursor, Copilot, локальные агенты и т.п.).

В первой и второй частях нашего гайда мы — техлид backend-команды Rustore Григорий Рябов и руководитель команды разработки RuStore: направление платежей Александр Котельников, прошлись по всем подготовительным этапам — от Kick-off до разработки и тестирования.

В первой части гайда RuStore по доставке фичей мы — техлид backend-команды Rustore Григорий Рябов и руководитель команды разработки RuStore: направление платежей, Александр Котельников, разобрали подготовительные этапы, которые закладывают прочный фундамент для всей разработки: от Kick-off и архитектурного планирования до Technical Design и тестовой стратегии.

Полтора года назад мы в RuStore собрали новую команду, чтобы с нуля разработать собственное платёжное решение. Тогда всё началось с одной фичи. Казалось бы, «просто запилить», чего тут сложного. Но на деле это обернулось целым кварталом разработки, бесконечными доделками и болью на финальном этапе интеграции. Тогда мы столкнулись с типичным набором проблем — от отсутствия документации и слабой декомпозиции до невозможности предсказать сроки. Да, в конечном итоге всё как-то заработало, но по ощущениям исключительно на энтузиазме.

Всем привет! В данной статье хотел бы рассмотреть инструменты документирования в принципиально разных подходах в разработке API, а именно для CodeFirst - инструменты Spring Rest Docs (а также его надстройки Spring Auto Rest Docs) и для ApiFirst - инструменты экосистемы Swagger(Open-Api).

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