Копайлоты, вайб-кодинг и MCP
Александр напоминает, что GitHub Copilot был не первым, но первым массовым инструментом: раскатить его можно было на всех пользователей GitHub, и, когда решение подало признаки жизни, это давало вау-эффект — тем более в связке с VS Code. Потом появился Cursor: команда, если Александр правильно помнит, пришла в редактор кода и тулинг для разработчиков из ML-инфраструктуры для рантайма больших языковых моделей. Была и ещё одна заметная компания, которую почти купила OpenAI, но так и не купила: основатели ушли в Google, а сам стартап достался другому покупателю. Термин vibe coding запустил в начале 2025 года Андрей Карпаты, бывший директор по AI и автопилоту в Tesla и один из фаундинг-мемберов OpenAI: новый вид программирования, где ты отдаёшься потоку и забываешь про код — он сам пишется. Идею подхватил Y Combinator — под прототипы стартапов она подходит отлично — и выпустил в стартап-школе советы, как правильно вайб-кодить.
Оптимизм рынка иллюстрирует прогноз Дарио Амодеи: месяца за четыре до доклада CEO Anthropic говорил, что через три-шесть месяцев ИИ будет писать 90% кода, а через двенадцать — почти весь. Александр замечает, что глава компании, выпускающей одну из лучших моделей для кода, отчасти предвзят. Anthropic отметилась не только заявлениями: её Model Context Protocol занял нишу между ассистентами и агентами с одной стороны и тулингом с другой, и теперь компании поднимают MCP-серверы вокруг собственных инструментов, чтобы ассистент мог отвечать на почту, вести календарь и писать в Slack. Ограничение протокола — синхронный вызов с ожиданием ответа, тогда как агентам нужна распределённая асинхронная архитектура; эту проблематику, по словам Александра, закрывает протокол A2A от Google. Индивидуальному разработчику можно брать любой понравившийся инструмент, но инженерные навыки всё равно нужны — иначе выходит как в меме, где человек, которому ассистент переписал весь проект, на совет восстановиться из предыдущего коммита спрашивает, что такое git.
От DevOps к платформенной инженерии
Часть этой инженерии инструменты забирают на себя: в Replit, вспоминает Александр, на себя взяли снапшоты и восстановление прежнего состояния, так что агентом можно управлять, почти не глядя в код. В большой компании так не выходит, и доклад отматывает историю назад. Когда-то разработка и operations жили порознь, требования приезжали апфронт большими ТЗ, а работа сводилась к перекидыванию полуфабрикатов соседу. С середины двухтысячных пришла DevOps-культура с бесконечным циклом plan — code — build — test — release — deploy — operate — monitor, и часть бигтеха обошла конкурентов просто потому, что быстрее выкатывала продукты, собирала обратную связь и чинила баги. Остальным пришлось адаптироваться, и адаптация оказалась дорогой: у всех появились CI/CD-пайплайны, хранилища кода, тесты и обзервабилити, а к 2019 году около четверти всех инженеров банка занимались не продуктовой разработкой, а поддержкой этих инструментов.
Ближе к концу 2010-х возникла идея разделить продуктовую и платформенную разработку, чтобы снять когнитивную сложность; свои попытки начались году с 2018-го, но были разрозненными, а в 2020-м платформу пришёл собирать Игорь Маслов, и к концу года её контуры уже были видны. Платформа — продукт для разработчиков, поэтому дальше речь про developer experience: whitepaper, изначально называвшийся What Actually Drives Productivity, предлагал мерить когнитивную нагрузку, скорость циклов обратной связи и способность инженеров держать состояние потока. Пример нагрузки — ландшафт Cloud Native Computing Foundation: когда Александр лет семь назад сдавал Certified Kubernetes Administrator, кубиков было немного, а сегодняшний ландшафт средний инженер, которому нужно делать фичи, испугается, заплачет и закроет. Платформа эту сложность прячет, оставляя сценарии по кнопке.
Уровни улучшений, кейсы и Нестор
Whitepaper Google 2024 года про измерение целей разработчиков раскладывает жизненный цикл на фазы и джобы, выделенные по логам внутренних инструментов и ежеквартальным опросам с 2018 года: джоба вроде «писать код высокого качества» линкуется с IDE, код-ревью и поиском по коду, и видно, кому поможет очередное улучшение. Другой пейпер той же серии, про то, чего разработчики ждут от AI, раскладывает улучшения по степени проникновения AI: гидроусилитель руля и антиблокировка тормозов — это автодополнение кода, камера заднего вида и датчики слепых зон — саджесты в код-ревью и чат с моделью внутри IDE, а продвинутый круиз-контроль — уже делегирование: автооткаты проблемных изменений, удаление мёртвого кода, генерация тестов. Оттуда же видно, что болит инженерам: техдолг, плохая документация, изучение новых технологий. Первый кейс — Google: два whitepaper 2024 года про управление API описывают формальный процесс, где правила проектирования живут примерно как Python Enhancement Proposals, линтер даёт обратную связь рано, а дизайн-ревью проходит почти автоматически, если правила соблюдены; во второй статье поверх этого появился генератор спецификации API по продуктовым требованиям. Вывод Александра: работает закон Матфея — зрелая инженерная культура с формализованными правилами внедряет GenAI гораздо эффективнее.
В ByteDance код-ревью устроено как таксономия правил и две модели: одна генерирует комментарии, вторая оценивает их качество, бесполезные правила выкидывают и дообучают модель, а на старте смотрят на adoption и retention. Uber посчитал, что переход с Java на Kotlin руками займёт 10 лет, чистыми LLM — 3 года, и собрал пайплайн из моделей и работы с абстрактно-синтаксическими деревьями. Booking взял внешнего подрядчика и сдвинул четырнадцатилетнюю миграцию кода, а Datadog делает агента-дежурного, который в два часа ночи разбирает инцидент по ранбукам и пишет постмортем. У себя в Т-Банке генеративные модели встраивают в существующую платформу Spirit, а не покупают инструмент, который решит все проблемы: копайлот Нестор умеет автодополнение, чат с моделью, поиск по внутренней документации и правку выделенного кода, а вокруг фаз SDLC — от бизнес-анализа и тестирования до SRE, саппорта и документации — собраны отдельные рабочие группы, и в SRE-блоке уже работает свой бот.
Что стоит унести с собой
- 01Маленькой компании публичных инструментов хватает для гипотез и MVP; большой внешний копайлот не делает разницы, пока в него не занесены внутренний контекст и MCP-серверы вокруг платформенных продуктов, иначе платишь фактически за UI.
- 02Для большой компании это одновременно про возможности и про защиту: коробочные сервисы прячут технологии за вызовами API, а внешние инструменты несут риски интеллектуальной собственности, персональных данных и санкций.
- 03Приоритизировать внедрение стоит от джобов инженеров и их болей — техдолга, документации, изучения новых технологий, — а не от списка доступных инструментов.
- 04Автоматизация окупается там, где инженерная зрелость уже есть: модели проще следовать формализованным правилам дизайна API, а агент-дежурный работает только на реальных логах, метриках и написанных ранбуках.
Источники
- Слайды материала
- Запись выступления