Вы открываете редактор. Пишете комментарий о том, что вам нужно. Нажимаете Tab. И код появляется. Магия? Нет. Обычный вторник для миллионов разработчиков, которые уже не представляют работу без Copilot, Cursor или Gemini.
Но что, если эта магия стала слишком обыденной? Microsoft официально заявляет, что в некоторых командах GitHub Copilot генерирует до 30% кода. Google продвигает свой Antigravity в реальные проекты – тот самый, который использовал Линус Торвальдс в своем AudioNoise.
Цифры впечатляют. Но за ними стоит более тревожный тренд, который уже получил имя: vibe coding.
Когда 30% кода пишет не человек
Тридцать процентов. Каждая третья строка. В масштабах Microsoft это гигабайты кода ежедневно, которые разработчики не написали, а лишь проверили и приняли.
Vibe coding – это не просто использование AI-ассистента. Это принципиально новый подход, где разработчик формулирует намерение, а не алгоритм. Вы описываете "сделай красивую анимацию появления", а не пишете keyframes в CSS.
Проблема в том, что намерение и реализация – разные вещи. AI может прекрасно понять первое и ужасно выполнить второе. Особенно если речь идет о сложных системах, где важна не функциональность, а архитектура.
Вспомните наш разбор про vibe-coding и кризис архитектуры. Там мы подробно разбирали, как легкость генерации убивает системный подход.
Antigravity против Copilot: две философии автоматизации
Microsoft с Copilot идет по пути интеграции в существующие рабочие процессы. Инструмент живет прямо в IDE, подсказывает, дописывает, исправляет. Он похож на очень умного партнера по печати.
Google с Antigravity (и его использованием Торвальдсом, о чем мы уже писали) предлагает другой подход. Это не помощник в написании строк. Это генератор целых блоков кода по техническому заданию. Дайте математическую формулу фильтра – получите реализацию на C.
| Подход | Microsoft Copilot | Google Antigravity |
|---|---|---|
| Философия | Помощник в потоке | Генератор по требованию |
| Контекст | Текущий файл, проект | Техническое задание, спецификация |
| Что генерирует | Строки, функции, комментарии | Модули, алгоритмы, целые файлы |
| Роль разработчика | Пишет с подсказками | Задает требования, проверяет результат |
Оба подхода ведут к одному: разработчик все меньше пишет код руками. Все больше – формулирует задачи, проверяет, исправляет.
А что же архитектура?
Вот здесь начинается самое интересное. И опасное.
Когда код генерируется по кусочкам (Copilot) или даже целыми модулями (Antigravity), кто отвечает за общую структуру? За связи между компонентами? За то, что система через год не превратится в спагетти-код, который невозможно поддерживать?
Представьте: вы просите AI "добавить кэширование для API". Он генерирует красивый код с Redis. Отлично. Через месяц просите "сделать инвалидацию кэша при обновлении данных". AI добавляет еще один слой логики. Еще через месяц – "добавить распределенный кэш для масштабирования".
В итоге получается монстр из трех разных подходов к кэшированию, которые конфликтуют друг с другом. Потому что каждый раз AI решал локальную задачу, не видя общей картины.
Так что, отказываться от AI?
Нет. Это было бы глупо. Тот же Торвальдс не стал бы использовать Antigravity, если бы это не давало реальных преимуществ.
Но нужно менять подход. Если 30% кода пишет не вы, значит, ваша работа смещается в другую плоскость:
- Архитектор, а не каменщик. Вы проектируете систему, а не кладете кирпичи.
- Рецензент, а не автор. Ваша задача – не написать код, а оценить его качество, соответствие стандартам, безопасность.
- Спецификатор. Вы учитесь формулировать задачи так, чтобы AI понимал их правильно. Это отдельный навык, о котором мы писали в гайде по промптам для Copilot.
Кстати, о безопасности. Когда код генерирует AI, кто отвечает за уязвимости? Недавний инцидент с OpenCode и RCE-уязвимостью показал: доверять сгенерированному коду без проверки – игра в русскую рулетку.
Что делать прямо сейчас?
Первое – принять, что 30% это только начало. Скоро будет 50%. Потом 70%. Как в "невидимом ИИ" 2026 года.
Второе – научиться работать с этим новым миром. Вот несколько практических советов:
1 Перестаньте измерять продуктивность строчками кода
Это бессмысленно. Сейчас 100 строчек могут означать либо гениальное решение сложной проблемы, либо копипасту из AI. Считайте ценность, а не объем.
2 Пишите промпты как ТЗ для подрядчика
Не "сделай кэш", а "реализуй кэширование ответов API в Redis с TTL 5 минут, инвалидацией по ключу при POST-запросах и фоновым обновлением при 80% истечении TTL". Чем конкретнее – тем лучше результат.
3 Добавьте в процесс code review проверку на "AI-запах"
Код выглядит шаблонно? Слишком много комментариев? Нет понимания, почему выбрана именно эта реализация? Возможно, это чистый AI-вывод без осмысления.
4 Изучайте не новые фреймворки, а принципы
AI отлично генерирует код для React, Vue, Angular. Но он не сможет спроектировать хорошую архитектуру, если вы сами не понимаете принципов композиции, слабой связанности, SOLID. Эти знания теперь ценнее, чем знание синтаксиса.
Самый важный навык будущего – не умение писать код, а умение не писать код. Определять, что можно автоматизировать, что нужно переиспользовать, а что вообще не стоит делать.
Microsoft и Google просто ускорили неизбежное. Программирование как ремесло ручного написания строк умирает. Но программирование как искусство создания систем – только начинается.
Парадокс в том, что чтобы эффективно использовать AI, который пишет 30% вашего кода, вам нужно знать на 100% больше, чем раньше. Нужно понимать не только как работает код, но и как работает AI, генерирующий этот код. Как в том анекдоте про бухгалтера и Excel: "Раньше я считал на бумаге. Теперь я вожу мышкой по таблице и думаю, почему цифры не сходятся".
Так что да, 30% кода теперь пишут не люди. Но ответственность за эти 30% лежит на вас. И это куда сложнее, чем просто написать их самому.
