Разработка фич

Неофициальный перевод раздела Cursor Learn. Мы переводим английский оригинал и чуть расширяем объяснения — это не материал от Cursor Inc.

Codebase уже чуть понятнее — пора строить новое.

Ключ к шиппингу фич с agents: дробить работу на шаги, которые agent может сам верифицировать. Большие фичи начинай с плана, потом ставь guardrails, чтобы agent ловил свои ошибки.

Начни с плана

Agents помогают продумать, что строить, ещё до кода.

Решений много: делать thin vertical slice или сразу «как в проде»? Какие design constraints важны? В Plan Mode Cursor agent исследует codebase, задаёт уточняющие вопросы и выдаёт пошаговый план, который можно править руками.

После ответов на вопросы получается структурированный план с milestones — agent сможет сверяться с ним по ходу:

# Notification preferences

## Overview
Add a notification preferences page to user settings. Users can toggle email, push, and in-app notifications per category (marketing, product updates, security alerts). Preferences stored in the database with optimistic UI updates.

## Approach
- Follow the existing settings page layout in src/pages/Settings.tsx
- Use the UserPreferences table with a JSONB column for notification config
- Reuse our existing Toggle component from the UI library

## Tasks
- [x] Add notification_preferences column to UserPreferences table
- [ ] Create NotificationPreferences component following Settings.tsx patterns
- [ ] Add API route at app/api/user/notifications/route.ts
- [ ] Wire up optimistic updates using our existing useOptimistic hook
- [ ] Add tests for preference toggling and API validation

Сила таких планов — в маленьких independently verifiable шагах. На каждом шаге agent может измерить прогресс и идти дальше.

Когда лучше начать заново

Иногда результат мимо. Вместо бесконечных follow-up «почини ещё вот это» — вернись к плану. Откати изменения, уточни план, запусти снова.

Если в плане не хватало ключевого architectural constraint, дальше чинить «кривой фундамент» обычно дольше, чем пересобрать с правильного направления. Контринтуитивно, но часто быстрее.

TDD с agents

Agents особенно сильны, когда у них есть сигнал «правильно / неправильно». Упал тест — видно, что сломалось, можно попробовать снова.

TDD существовал давно, но с agents писать тесты сначала стало практичнее:

Сначала тесты — по ожидаемым inputs/outputs. Явно скажи, что это TDD, чтобы agent не наклепал mock’ов «под будущий код».
Убедись, что тесты падают — feature code пока не пишем.
Закоммить тесты — зафиксируй requirements.
Попроси написать код — все тесты зелёные, тесты не трогать.
Закоммить код после ревью поведения.

TDD: write tests first

Write tests for a discountCode() function that:

Returns the discounted price when given a valid code
Throws InvalidCodeError for expired codes
Applies fixed-amount discounts correctly (e.g., “10OFF” = $10 off)
Never returns a negative price (floor at $0)

Follow the test patterns in src/__tests__/pricing.test.ts. Do NOT write the function yet.

TDD: make the tests pass

Make all tests in src/__tests__/discountCode.test.ts pass. Follow the service patterns in src/services/PricingService.ts. Do NOT modify the tests.

Почему это работает: agent получает concrete feedback на каждом прогоне. Без тестов у него нет компаса «сработало или нет». Особенно ценно на backend, где нельзя «просто посмотреть на экран».

Design → code

Agents понимают изображения. Вставь скрин или мокап в prompt — и проси собрать UI близко к картинке.

Работает для:

Mockups — wireframe / Figma export → компонент
Visual debugging — скрин странного UI-состояния → разбор
Iteration — скрин текущего результата + список правок

Можно подключить Figma MCP, чтобы agent тянул design tokens и specs напрямую. А встроенный browser позволяет agent’у самому открывать страницы, снимать скрины и проверять визуальный результат — меньше ручной челночной передачи картинок.

Частый fail: скорость без verification

Главный риск быстрой генерации — пропустить проверку. Много кода быстро ≠ много правильного кода.

Дай agent’у способы самопроверки:

Tests — поведение
Type checking — структура
Linters — стиль и паттерны
Browser tools / MCP — feedback по UI

Если agent не может верифицировать output, ты потом оплатишь это временем на ручные правки.

Что дальше

Фичу зашиппили. Но баги неизбежны. Дальше — системный debugging с agents.