От ассистента к агенту: трансформация роли разработчика

Три уровня поведения AI-инструментов

AI-инструменты для разработки -- это не однородная категория. Они различаются по уровню автономности, и эта разница фундаментально влияет на роль разработчика.

Уровень 1: Responsive Assistants (реактивные ассистенты)

Разработчик: "Напиши функцию сортировки"
AI: [генерирует функцию]
Разработчик: "Добавь обработку пустого массива"
AI: [добавляет проверку]
Разработчик: "Теперь оптимизируй для больших массивов"
AI: [рефакторит]

Характеристики:

• Следуют явным инструкциям -- шаг за шагом
• Не проявляют инициативы
• Каждое действие требует промпта от человека
• Нет собственных "целей" -- только ответы на запросы

Инструменты: ChatGPT, Claude (web), Copilot Chat в простом режиме.

Аналогия: Это как голосовой помощник (Siri/Alexa). Вы говорите -- он делает. Не говорите -- стоит и ждёт.

Уровень 2: Collaborative Agents (совместные агенты)

Разработчик: "Реализуй RegistrationService"
AI: [читает существующий код]
    [замечает]: "UserRepository не имеет метода existsByEmail.
     Создать его, прежде чем продолжить?"
Разработчик: "Да"
AI: [создаёт метод в репозитории]
    [создаёт сервис]
    [запускает PHPStan]
    [исправляет найденную ошибку типов]
    [запускает снова]
    "Готово. RegistrationService создан, PHPStan чист."

Характеристики:

• Работают полуавтономно в рамках задачи
• Проявляют инициативу (замечают проблемы, предлагают решения)
• Балансируют между самостоятельностью и запросом подтверждения
• Используют инструменты (файловая система, терминал, тесты)

Инструменты: Claude Code, Cursor (Composer mode), Windsurf (Cascade).

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

Уровень 3: Development Partners (партнёры по разработке)

Разработчик: "Нужна система уведомлений для платформы"
AI: [анализирует кодовую базу]
    [изучает существующие паттерны]
    [создаёт спецификацию]
    [представляет план]:
    "Я проанализировал проект. Предлагаю:
     1. Entity Notification с полиморфным типом
     2. NotificationService с dispatch через Messenger
     3. 4 канала: email, telegram, push, in-app
     4. API: 4 эндпоинта (list, read, read-all, settings)
     Хочу уточнить: нужен ли real-time через SSE/WebSocket?"
Разработчик: "SSE для in-app, остальное ок. Делай."
AI: [реализует всю систему]
    [пишет тесты]
    [проверяет всё]
    [отчитывается]

Характеристики:

• Интернализируют цели проекта
• Самостоятельно диагностируют проблемы
• Persistent к решению (не сдаются после первой ошибки)
• Предлагают архитектурные решения
• Запрашивают ввод только для стратегических решений

Инструменты: Claude Code (agent mode), Devin, Codex CLI с расширенными правами.

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

Сравнение уровней

Как трансформируются навыки разработчика

Традиционная разработка

Навыки разработчика (до AI):

[████████████] Написание кода
[████████████] Отладка
[████████░░░░] Проектирование
[██████░░░░░░] Коммуникация
[████░░░░░░░░] Управление проектом

Основной навык -- написание кода. Разработчик проводит 60-70% времени за набором, чтением и отладкой кода. Проектирование занимает 15-20%, остальное -- коммуникация и менеджмент.

AI-ассистированная разработка

Навыки разработчика (с AI, стадии 4-5):

[████████░░░░] Ревью AI-кода
[████████░░░░] Формулирование промптов
[████████████] Проектирование
[██████████░░] Написание кода (уменьшилось)
[████████░░░░] Коммуникация
[████░░░░░░░░] Верификация

Баланс смещается: написание кода уменьшается, а ревью и формулирование промптов увеличиваются. Проектирование становится важнее.

Разработка в эпоху агентов

Навыки разработчика (агенты, стадии 7-8):

[████████████] Specification writing
[████████████] Context engineering
[██████████░░] Quality verification
[██████████░░] Systems thinking
[████████░░░░] Risk assessment
[████████░░░░] Коммуникация
[████░░░░░░░░] Написание кода (только вмешательства)

Написание кода сокращается до вмешательства при проблемах. Основные навыки -- спецификации и верификация.

Новые навыки: что осваивать

1. Specification Writing (написание спецификаций)

Спецификация -- это основной output разработчика на стадиях 6+. Качество спецификации напрямую определяет качество AI-output.

Что нужно уметь:

• Формулировать чёткие, однозначные требования
• Выбирать правильный паттерн спецификации (API-First, Test-First, State Machine и т.д.)
• Определять edge cases до реализации
• Писать верифицируемые критерии успеха

# ❌ Плохая спецификация
Нужна авторизация. Пользователи логинятся по email и паролю.
Должно быть безопасно.

# ✅ Хорошая спецификация
## Login Endpoint
- POST /api/v1/auth/login
- Input: {email: string(email), password: string(8-128)}
- Output (200): {access_token: JWT(RS256, 15min), refresh_token: opaque(7d)}
- Output (401): {code: 401, message: "Invalid credentials"}
- Rate limit: 10 attempts per email per 15 minutes
- After 5 failures: require CAPTCHA
- After 10 failures: temporary block (30 min)
- Logging: auth attempts (without password), IP, user-agent
- NOT logged: password values, full tokens

2. Context Engineering (инженерия контекста)

Контекст -- это то, что AI "знает" о вашем проекте при генерации кода. Инженерия контекста -- это навык предоставления AI правильной информации в правильном объёме.

Что нужно уметь:

• Структурировать CLAUDE.md / AGENTS.md / .cursorrules
• Решать, какие файлы включить в контекст задачи
• Не перегружать контекст (слишком много = AI "теряется")
• Не недогружать контекст (слишком мало = AI "додумывает")

# Context hierarchy (from most to least important):

## MUST FOLLOW (rules)
- All classes final by default
- strict_types always
- No raw SQL

## SHOULD FOLLOW (conventions)
- UUID v7 for IDs
- Keyset pagination
- Constructor injection

## FOR REFERENCE (examples)
- See src/Service/ExistingService.php for service pattern
- See tests/Unit/ExistingTest.php for test pattern

3. Quality Verification (верификация качества)

Когда AI генерирует 80% кода, ваша способность найти ошибки в этом коде становится критичной. Это не просто code review -- это систематический процесс верификации.

Что нужно уметь:

• Настраивать автоматическую верификацию (тесты, линтеры, type checkers)
• Читать код критически (AI-код часто "выглядит правильно", но содержит тонкие ошибки)
• Проверять соответствие спецификации
• Ловить паттерны AI-ошибок

Типичные AI-ошибки, которые нужно уметь ловить:

// AI-ошибка 1: Ignoring concurrency
// AI написал "проверить и создать" без транзакции
$existing = $repository->findByEmail($email);
if ($existing === null) {
    // Race condition: другой запрос может создать пользователя
    // между проверкой и созданием
    $repository->save(new User($email));
}

// AI-ошибка 2: Incorrect error handling
// AI обработал общее исключение, скрыв конкретные
try {
    $this->processPayment($order);
} catch (\Exception $e) {
    // Скрывает InsufficientFundsException,
    // PaymentGatewayException, NetworkException --
    // все обрабатываются одинаково
    return new JsonResponse(['error' => 'Payment failed'], 500);
}

// AI-ошибка 3: Security blind spot
// AI "забыл" про авторизацию внутри сервиса
public function deleteOrder(string $orderId): void
{
    $order = $this->orderRepository->find($orderId);
    // Нет проверки: имеет ли текущий пользователь
    // право удалять этот заказ?
    $this->orderRepository->remove($order);
}

4. Systems Thinking (системное мышление)

Понимание AI как системы с возможностями и ограничениями. Не антропоморфизация ("AI думает"), а точная модель того, что AI может и не может.

Что нужно понимать:

• AI не "понимает" код -- он генерирует статистически вероятные последовательности токенов
• AI не имеет "памяти" между сессиями (без специальных инструментов)
• AI может быть уверенно неправ (hallucination)
• AI лучше работает с типичными задачами, хуже -- с уникальными
• Контекстное окно ограничено -- AI "забывает" начало длинной беседы

5. Risk Assessment (оценка рисков)

Не весь AI-код одинаково рискован. Развейте интуицию: когда результат AI можно принять с минимальным ревью, а когда нужна тщательная проверка.

Уровень риска AI-output:

НИЗКИЙ (минимальный ревью):
├── Boilerplate код (entity, DTO, migration)
├── Стандартные CRUD контроллеры
├── Тривиальные утилиты
└── Конфигурационные файлы

СРЕДНИЙ (стандартный ревью):
├── Бизнес-логика (сервисы)
├── Интеграция с внешними API
├── Обработка ошибок
└── Тесты (особенно edge cases)

ВЫСОКИЙ (тщательный ревью + ручное тестирование):
├── Аутентификация / авторизация
├── Финансовые операции
├── Обработка персональных данных
├── Конкурентный доступ
└── Криптография

Метафора "Project Manager"

На стадиях 7-8 разработчик становится по сути менеджером проекта для AI-агентов. Эта метафора точно описывает новую роль.

Что делает PM для людей vs разработчик для AI

Навыки PM, которые становятся актуальны

1. Целеполагание. Чётко определить, чего мы хотим достичь, прежде чем начинать работу.

# ❌ "Сделай систему уведомлений"
→ AI сделает что-то, но неизвестно что

# ✅ "Цель: пользователи получают уведомления о новых статьях
#    в курсах, на которые подписаны. Каналы: in-app + email.
#    Метрика: 0 пропущенных уведомлений, доставка email < 5 мин."
→ AI имеет чёткую цель и критерии успеха

2. Приоритизация. Что делать первым? Что можно отложить?

# Приоритеты реализации:
P0 (блокер): API endpoints для уведомлений (frontend зависит)
P1 (важно): In-app уведомления (основной канал)
P2 (нужно): Email уведомления (дополнительный канал)
P3 (потом): Push уведомления (после MVP)

3. Мониторинг. Отслеживание прогресса без микроменеджмента.

# Dashboard прогресса
| Задача | Статус | Попытки | Время |
|--------|--------|---------|-------|
| Entity | ✅ | 1 | 30s |
| Service | ✅ | 2 | 1.5m |
| Controller | 🔄 | — | — |
| Tests | ⏳ | — | — |

# First-attempt success rate: 50% (ниже нормы 70%)
# Причина: недостаточный контекст в задачах
# Action: добавить примеры существующего кода в задачи

4. Принятие решений. Только те решения, которые AI не может принять сам.

# Решения, которые принимает разработчик:
✅ Архитектурные: "Используем event-driven, не polling"
✅ Компромиссные: "Жертвуем consistency ради availability"
✅ Бизнесовые: "Уведомления не отправлять ночью (22:00-08:00)"

# Решения, которые AI принимает сам:
✅ Технические: "Использовать Doctrine QueryBuilder vs DQL"
✅ Стилистические: "Порядок методов в классе"
✅ Реализационные: "Как именно имплементировать фильтрацию"

Что НЕ меняется

При всей трансформации роли, некоторые фундаментальные навыки остаются критичными -- и не исчезнут с развитием AI.

Алгоритмы и структуры данных

AI не заменяет понимание алгоритмов. Вы должны знать, что O(n^2) -- это проблема на больших данных, даже если AI написал этот код. Вы должны понимать, почему hash map быстрее для поиска, чем массив.

Почему это важно:
- AI может сгенерировать неоптимальный алгоритм
- Вы должны заметить O(n^2) в цикле с 100K элементов
- AI не всегда выбирает правильную структуру данных
- Понимание сложности = способность верифицировать AI-output

System Design

Понимание распределённых систем, trade-offs, CAP-теоремы, масштабирования -- это навыки, которые AI не может заменить, потому что они требуют контекста бизнеса и понимания ограничений.

Security Awareness

AI систематически недооценивает безопасность. Он генерирует "функционально правильный" код, который может быть уязвим. Ваша задача -- видеть уязвимости.

// AI сгенерировал рабочий код поиска:
public function search(string $query): array
{
    return $this->connection->executeQuery(
        "SELECT * FROM articles WHERE title LIKE '%$query%'"
    )->fetchAllAssociative();
    // SQL Injection! AI "забыл" про параметризацию
}

// Разработчик с security awareness заметит и исправит:
public function search(string $query): array
{
    return $this->connection->executeQuery(
        'SELECT * FROM articles WHERE title LIKE :query',
        ['query' => '%' . $query . '%']
    )->fetchAllAssociative();
}

Domain Knowledge

AI знает о технологиях, но не знает о вашем бизнесе. Почему заказ не может перейти из "создан" в "доставлен"? Почему скидка не может превышать 50%? Почему уведомление не отправляется ночью? Это знание домена, которым владеете вы.

Communication

AI не ведёт переговоры с заказчиком, не объясняет PM-у, почему фича займёт 3 недели вместо 1, не участвует в ретроспективе команды. Коммуникация -- навык разработчика, а не AI.

Парадокс продуктивности

AI делает отдельные задачи быстрее. Но добавляет новые задачи, которых раньше не было.

Время БЕЗ AI:
Проектирование:  ████ (20%)
Написание кода:  ████████████████ (60%)
Тестирование:    ████ (15%)
Документация:    █ (5%)
                 Всего: 100 единиц времени

Время С AI (стадия 6-7):
Написание спеки:     ████████ (25%)     ← НОВОЕ
Context engineering:  ████ (10%)         ← НОВОЕ
AI реализация:        ██ (5%)           ← было 60%
Верификация:          ██████ (20%)      ← выросло
Ревью AI-кода:        ████ (12%)        ← НОВОЕ
Исправление AI:       ███ (8%)          ← НОВОЕ
Тестирование:         ████ (12%)
Документация:         ██ (8%)           ← AI помогает
                      Всего: ~70 единиц (30% экономия)

Вывод: AI экономит время, но не в 10 раз, как кажется на первый взгляд. Реальная экономия -- 20-40% для опытного пользователя на стадиях 6-7. Огромная экономия наступает на рутинных задачах (CRUD, boilerplate, тесты), умеренная -- на бизнес-логике, минимальная -- на архитектуре и проектировании.

Карьерные последствия

Роли, которые растут

Роли, которые трансформируются

Новые роли

• Prompt Engineer / Context Engineer -- специалист по настройке AI-контекста для проектов
• AI Quality Assurance -- верификация AI-output на уровне процесса
• Specification Architect -- разработка шаблонов и паттернов спецификаций
• Human-AI Process Designer -- проектирование рабочих процессов с AI

Практические советы: как оставаться релевантным

1. Используйте AI как умножитель, не как замену

❌ "AI заменит разработчиков, мне конец"
✅ "AI умножит мою продуктивность, если я научусь им управлять"

Аналогия:
- Экскаватор не заменил строителей. Он сделал каждого строителя
  в 100 раз продуктивнее. Но строители, которые отказались
  учиться работать с экскаватором -- да, их заменили.

2. Двигайтесь вверх по стадиям осознанно

Месяц 1: Освойте стадию 4 (генерация кода) — научитесь ревьюить AI-output
Месяц 2: Освойте стадию 5 (pair programming) — научитесь вести диалог с AI
Месяц 3: Начните стадию 6 (SDD) — напишите первые спецификации
Месяц 4-6: Закрепите стадию 6 — реализуйте 5-10 фич по спекам
Месяц 7+: Стадия 7 — автономное выполнение задач

3. Усиливайте то, что AI не может

Инвестируйте в навыки, которые AI не автоматизирует:

• Понимание бизнеса вашей компании
• Коммуникация с заказчиками
• Архитектурные решения
• Security awareness
• Менторинг (людей, не AI)

4. Стройте "T-shaped" профиль

Широкие знания:
├── System design
├── Security basics
├── DevOps fundamentals
├── Frontend basics
├── AI tools & SDD ← NEW
└── Business understanding

Глубокая экспертиза (ваш стек):
└── PHP/Symfony ← или Go, или Vue, или ...
    └── Глубокое знание, которое позволяет
        верифицировать AI-output в этом стеке

5. Документируйте свой опыт с AI

Ведите журнал: что работает, что нет, какие паттерны AI-ошибок вы заметили. Это ваша персональная база знаний, которая делает вас эффективнее с каждой неделей.

## AI Experience Log

### 2026-03-07: RegistrationService
- Pattern: Contract spec → Claude Code agent mode
- Result: 3 tasks, 4 attempts, 10 minutes
- AI mistake: forgot database transaction
- Lesson: always specify transaction requirements explicitly
- Updated: task template — added "Transaction requirements" field

Итоги

Переход от ассистента к агенту -- это не техническое изменение. Это трансформация профессии. Разработчик перестаёт быть "человеком, который пишет код" и становится "человеком, который управляет созданием ПО".

Ключевые выводы:

1. AI-инструменты имеют три уровня автономности -- от реактивных ассистентов до партнёров по разработке. Каждый уровень требует других навыков от разработчика.

2. Навыки трансформируются, не исчезают. Вместо "написание кода" -- "написание спецификаций". Вместо "отладка" -- "верификация AI-output". Вместо "реализация" -- "контекст-инженерия".

3. Фундамент остаётся. Алгоритмы, system design, security, domain knowledge -- эти навыки не исчезнут. Они становятся ещё важнее, потому что это то, что AI не может делать самостоятельно.

4. Метафора PM точна. На стадиях 7-8 разработчик -- это менеджер проекта для AI-агентов. Целеполагание, декомпозиция, мониторинг, принятие решений.

5. AI -- умножитель, не замена. Те, кто научится управлять AI -- будут на порядок продуктивнее. Те, кто откажется -- останутся на стадии 1-2, где конкуренция жёстче.

Финальная мысль: Лучшее время начать двигаться по стадиям эволюции -- сейчас. Не потому что AI "заменит" вас завтра. А потому что через год разработчик на стадии 7 будет в 3 раза продуктивнее разработчика на стадии 3. И эта разница будет только расти.