В каждой инженерной команде есть два типа людей. Одни любят исследовать: пробуют новые фреймворки, пишут прототипы, копаются в чужом коде. Другие — эксперты по эксплуатации: они наводят порядок, оптимизируют, превращают прототип в надёжный продукт. Раньше считалось, что успех зависит от наличия «100x-инженера» — человека, который пишет в сто раз больше кода, чем остальные. Но с появлением ИИ-ассистентов и подхода vibe coding эта картина мира рушится. Теперь любой может сгенерировать сотни строк кода за минуты. Вопрос в другом: умеете ли вы правильно выбирать стратегию — исследовать или эксплуатировать? Разберёмся, что это значит на практике.
Исследователи и эксплуататоры: две стороны одной медали
Понятия explore и exploit пришли из теории обучения и reinforcement learning. В математической модели перед агентом стоит дилемма: либо исследовать окружающую среду, получая новую информацию, либо использовать уже известную стратегию для получения награды. В разработке эта дилемма проявляется постоянно.
Explorers (исследователи) — это разработчики, которые:
- любят работать с неизвестными технологиями;
- быстро пишут прототипы, чтобы проверить гипотезу;
- предпочитают широкий охват вместо глубокой проработки;
- часто переключаются между задачами.
Exploiters (эксплуататоры) — те, кто:
- фокусируется на оптимизации и стабильности;
- пишет тесты, документацию, проводит рефакторинг;
- использует проверенные паттерны и библиотеки;
- доводит проект до продакшена.
В классической команде оба типа дополняют друг друга. Но в эпоху ИИ-ассистентов границы стираются. Один и тот же человек может быть исследователем утром и эксплуататором во второй половине дня — достаточно сменить промпт.
| Характеристика | Explorers (исследователи) | Exploiters (эксплуататоры) |
|---|---|---|
| Отношение к новому | Любят пробовать, рискуют | Предпочитают проверенное |
| Скорость прототипирования | Высокая | Низкая |
| Готовность к продакшену | Низкая | Высокая |
| Основной инструмент | Прототипы, экспериментальный код | Тесты, документация, рефакторинг |
Vibe coding: когда код пишет машина
Термин «vibe coding» ввёл Андрей Карпати (основатель Eureka Labs) в феврале 2025 года. Он описал подход, при котором разработчик полностью «отпускает» детали и позволяет ИИ генерировать код по описанию на естественном языке. Это стало возможным благодаря большому контексту современных моделей и их способности удерживать всю кодовую базу проекта.
Vibe coding идеально подходит для исследователей: можно набросать идею, попросить модель собрать прототип, и за час получить работающее приложение. Например, вам нужно быстро проверить, подходит ли новая библиотека для обработки изображений. Вместо чтения документации вы описываете желаемый результат, и ИИ генерирует код, который можно сразу запустить. Эксплуататоры тоже выигрывают: вместо ручного написания тестов или рефакторинга они могут поручить это ИИ, а самим заняться архитектурой.
Но есть и обратная сторона. Код, сгенерированный ИИ, часто требует тщательной проверки. Исследователь может увлечься и забыть о безопасности, а эксплуататор обязан довести код до ума. Здесь и проявляется разница: первый ищет новые возможности, второй — гарантирует надёжность.
Миф о 100x-инженере
Представление о «10x» или «100x» разработчиках уходит корнями в исследование Сакмана, Эриксона и Гранта, опубликованное в 1968 году. Они обнаружили, что разница в продуктивности между лучшими и худшими программистами может достигать 28 раз. В последующие годы эта цифра многократно цитировалась, превратившись в миф о супер-инженерах, которые пишут невероятно быстро.
Важно понимать: открытие Сакмана и его коллег часто неправильно интерпретируют. Разница в 28 раз — это не разница в скорости набора кода, а разница в общем времени решения задачи, включая проектирование, отладку и общение. Уже тогда исследователи выделили, что лучшие программисты не пишут быстрее, а лучше понимают постановку задачи и избегают лишней работы. С появлением ИИ этот аспект стал ещё заметнее: модель может написать код за секунды, но человек должен точно сформулировать, что нужно сделать, и проверить результат.
Современные исследования также показывают, что продуктивность программиста не сводится к скорости набора кода. Например, исследование Microsoft (2022) показало, что разработчики, использующие GitHub Copilot, выполняли задачу на 55% быстрее, чем контрольная группа. Это значит, что «100x» сегодня достигается не за счёт личных качеств, а за счёт правильного использования инструментов.
Более того, в эпоху, когда код генерируется автоматически, ценность инженера определяется его способностью принимать решения: какую архитектуру выбрать, какие компромиссы допустимы, как обеспечить безопасность и масштабируемость. Это уже не про количество строк, а про качество решений.
Как прокачать оба режима: практические советы
Чтобы стать эффективным и исследователем, и эксплуататором, нужно сознательно практиковать переключение. Вот несколько конкретных приёмов.
1. Для исследователей: генерируйте несколько вариантов решения
Вместо того чтобы спрашивать ИИ «напиши скрипт для парсинга CSV», попросите его предложить три разных подхода с разными библиотеками. Сравните их по скорости, читаемости, надёжности. Пример промпта:
Предложи три способа реализовать парсинг CSV в Python:
1) с использованием встроенного csv,
2) с pandas,
3) с polars.
Сравни их по производительности и удобству.
Это позволит быстро исследовать пространство решений, не тратя время на написание кода вручную.
2. Для эксплуататоров: используйте ИИ для рутины
Пусть ИИ пишет юнит-тесты, генерирует документацию или рефакторит код. Например, промпт:
Отрефактори следующий код, выделив общую логику в отдельную функцию, и добавь docstring. Вот код: ...
Так вы освобождаете время для задач, требующих человеческого суждения.
3. Организуйте процесс как чередование фаз
В начале спринта выделите время на исследование: прототипы, проверка гипотез, технические спайки. Затем переключитесь в режим эксплуатации: стабилизация, тесты, ревью. Такой подход используют многие продуктовые команды.
4. Используйте ИИ для обучения
Если вы столкнулись с незнакомым API, попросите модель объяснить его на примерах. Это ускоряет вход в новую тему и помогает исследователям быстрее становиться эксплуататорами.
Пошаговый процесс для переключения между режимами
- Начните с исследования. Когда вы получаете новую задачу, не бросайтесь писать код. Сначала используйте ИИ, чтобы составить список возможных подходов. Например, промпт: «Какие существуют паттерны для обработки фоновых задач в Django?»
- Выберите самый перспективный вариант и попросите ИИ создать прототип.
- Проверьте прототип в действии. Запустите его на реальных данных. Если что-то не работает, уточните промпт.
- Переключитесь в режим эксплуатации. Когда прототип работает, попросите ИИ написать тесты, добавить обработку ошибок и отрефакторить код.
- Проведите ревью. Даже с ИИ важно проверять код вручную. Помните, что модели могут генерировать правдоподобный, но неоптимальный код.
Командная динамика: исследователи и эксплуататоры в одном лице
Современные инструменты позволяют совмещать обе роли. Например, в стартапе, где нужно быстро выпустить MVP, разработчик может использовать vibe coding для прототипа, а затем переключиться на укрепление кода — добавить тесты, обработку ошибок, метрики. Это и есть путь от исследователя к эксплуататору.
Но не стоит забывать о командном балансе. Если все будут только исследовать, проект никогда не будет доведён до продакшена. Если все только эксплуатировать, команда перестанет развиваться. Идеальная команда — это смесь людей с разными наклонностями, которые уважают сильные стороны друг друга.
В эпоху ИИ-ассистентов и vibe coding преимущество получают те, кто умеет гибко переключаться между исследованием и эксплуатацией. Они могут быстро проверить гипотезу, а затем превратить её в надёжный продукт. Именно такие инженеры становятся настоящими 100x-специалистами — не потому, что пишут в 100 раз больше, а потому, что принимают в 100 раз лучшие решения.
Комментарии