Давайте дізнаємося + покритикуємо, як велика компанія на кшталт FAANG "Vibe Coding": «Змусьте достатню кількість зацікавлених сторін спочатку кивнути на знак згоди» "Потім зробіть огляд дизайну" «Потім були тижні документації» "Потім продакт-менеджер і проджект-менеджер розділяють завдання туди-сюди" Після трьох місяців очікування нарешті настав час почати кодування Vibe! --- Ось як ми в FAANG робимо "Vibe Coding" Всім привіт. Причина, через яку я хочу опублікувати тут, полягає в тому, що я завжди бачу, як люди кажуть, що код за допомогою штучного інтелекту не може бути використаний у реальних продуктах. Це абсолютна нісенітниця. Почнемо з передісторії: я інженер-програміст зі штучним інтелектом з більш ніж десятирічним досвідом, половину з якого я провів у FAANG. Першу половину своєї кар'єри я провів як системний інженер, а не розробник, але пишу код майже 15 років. Без зайвих слів, дозвольте мені розповісти про те, як наша команда почала використовувати штучний інтелект для написання реального виробничого коду. 1. Починати завжди слід з технічного проектного документа. Це основна частина всієї роботи. Цей документ схожий на пропозицію, і вам потрібно переконати достатню кількість стейкхолдерів у тому, що ваше рішення є життєздатним. Тільки коли проект буде затверджено, можна приступати до розробки самої системи. Цей документ повинен включати повну архітектуру системи, інтеграцію з іншими системами тощо. 2. Перед тим, як йти в розробку, проведіть експертизу дизайну. На цьому етапі старші інженери в команді будуть «обігрувати» ваш конструкторський документ знову і знову. Це добре, я називаю це «ставити біль на перше місце»**. 3. Якщо перевірка пройшла успішно, можна офіційно приступати до робіт з розробки. У перші кілька тижнів ви витрачаєте багато часу на написання більш детальної документації для підсистеми, яку збирається будувати кожна команда розробників. 4. Далі йде розробка беклогу та планування спринту. На цьому етапі розробники зустрічаються з менеджерами продуктів (PM) і технічними менеджерами проектів (TPM), щоб розбити великі цілі на конкретні завдання, з якими розробники можуть почати. 5. **Розробка програмного забезпечення**. Нарешті, ми можемо почати вводити код і знищувати карти місій. І ось тут у гру вступає штучний інтелект, це наш мультиплікатор сили. Ми використовуємо модель Test Driven Development (TDD), тому перше, що я роблю, це доручаю агенту штучного інтелекту писати тестові випадки для функцій, які я хочу розробити. *Лише коли тест буде написано, я почну просити агента штучного інтелекту допомогти мені створити конкретні функції*. 6. **Перевірка подання коду**. Наш код повинен бути затверджений двома розробниками, перш ніж його можна буде об'єднати з основною гілкою. У цьому посиланні штучний інтелект також показав великий потенціал, щоб допомогти нам у наших оглядах. 7. **Тест у передрелізному середовищі (постановка)**. Якщо з тестами все піде добре, нас офіційно випускають у виробниче середовище (PROD). Загалом ми побачили зростання приблизно на 30% за весь процес від пропозиції функції до остаточного запуску. Для нас це величезний крок вперед. ** Занадто довго читати (TL; DR) :** Завжди починайте з надійного дизайн-документа та архітектури; Потім реалізуйте його по частинах; Завжди пишіть тести наперед.