Давайте изучим и раскритикуем, как такие крупные компании, как FAANG, занимаются «программированием по ощущениям (Vibe Coding)»: «Сначала нужно, чтобы достаточно много заинтересованных сторон кивнули в знак согласия» «Затем проводим обзор дизайна» «После этого идет работа с документами, которая длится несколько недель» «И только потом менеджеры по продукту и проекту разбивают задачи» И вот три месяца спустя, наконец, можно начинать Vibe Coding! --- Вот как мы в FAANG занимаемся «программированием по ощущениям (Vibe Coding)». Всем привет. Я хочу опубликовать этот пост, потому что постоянно вижу, как кто-то спорит, что код, написанный с помощью AI, совершенно не подходит для реальных продуктов. Это абсолютно неправда. Сначала немного о себе: я инженер-программист в области AI с более чем десятилетним опытом, из которых половину времени я провел в FAANG. В первой половине своей карьеры я работал системным инженером, а не разработчиком, но я пишу код уже почти 15 лет. Не будем тянуть, давайте я расскажу, как наша команда начала использовать AI для написания настоящего **производственного кода (production code)**. 1. Вы всегда должны начинать с **технического проектного документа**. Это самая важная часть всей работы. Этот документ похож на предложение, вам нужно убедить достаточно много заинтересованных сторон (stakeholders), чтобы они поверили, что ваше решение осуществимо. Только после одобрения дизайна вы можете приступить к разработке самой системы. В этом документе должны быть представлены полная архитектура системы, интеграционные схемы с другими системами и так далее. 2. Перед началом разработки необходимо провести **обзор дизайна (Design review)**. На этом этапе старшие инженеры (Senior Engineers) в команде будут многократно «проверять» ваш проектный документ. Это хорошо, я называю это **«предварительным устранением проблем»**. 3. Если обзор прошел успешно, вы можете официально начать работу над разработкой. В первые несколько недель все будут тратить много времени на написание более детальных документов для каждого подсистемы (subsystem), которую необходимо построить команде разработчиков. 4. Затем идет разработка **бэклога (Backlog)** и планирование спринта (sprint planning). На этом этапе разработчики будут встречаться с менеджерами по продукту (PMs) и техническими менеджерами проектов (TPMs), чтобы разбить большие цели на конкретные задачи, которые могут быть выполнены разработчиками. 5. **Разработка программного обеспечения**. Наконец, мы можем приступить к написанию кода и устранению задач. И здесь AI проявляет свои суперспособности, он просто наш **умножитель эффективности (force multiplier)**. Мы используем метод **разработки через тестирование (Test Driven Development, TDD)**, поэтому первое, что я делаю, это заставляю **AI-агента (AI agent)** написать тестовые случаи для функции, которую я собираюсь разработать. *Только когда тесты написаны, я начинаю просить AI-агента помочь мне создать конкретную функцию.* 6. **Обзор кода перед его отправкой**. Наш код должен быть одобрен двумя разработчиками перед слиянием с основной веткой (main). На этом этапе AI также демонстрирует огромный потенциал, помогая нам в обзоре. 7. **Тестирование в предрелизной среде (staging)**. Если тесты проходят успешно, мы официально публикуем в производственной среде (prod). В общем, от предложения функции до окончательного запуска мы обнаружили, что вся процедура **ускорилась примерно на 30%**. Это огромный прогресс для нас. **Слишком длинно, не читайте (TL;DR):** Всегда начинайте с основательного проектного документа и архитектуры; затем реализуйте это по частям; всегда пишите тесты заранее.