В какой-то момент я понял, что у меня открыто четыре IDE с разными проектами. В каждой запущены сессии с Claude AI. Я постоянно переключаюсь между вкладками, планирую, провожу ревью там, где это критично, а в остальных местах запускаю хитрые тестовые сценарии, тестируя проекты как black box. Приходится держать в голове множество контекстов — на каком шаге я на каждой вкладке и в каждом проекте. И в какой-то момент — бам: пора спать, есть или гулять с ребёнком. Все процессы останавливаются. Агенты ждут. И оказывается, что слабое звено — не модель с её ошибками, а я. Я начинаю спать меньше. Парадокс: казалось бы, модели должны работать, пока я отдыхаю. Но получается наоборот.
Тесты вместо ревью
Я стал реже делать ревью и чаще придумывать тесты. Сначала — в тех местах, где ошибки не приведут к финансовым потерям. Потом начал применять этот подход и в критичных участках.
Пример: нужно загрузить в EVM смарт-контракт с ценами из внешних источников как можно быстрее. Решаю: сделаем на Rust. Подписываемся на CEX, слушаем события через веб-сокеты, при изменениях отправляем транзакцию. Чтобы ускорить процесс, сразу даю «экспертизу»: nonce считаем offline, не вызываем eth_getTransactionCount, не делаем estimateGas, а gasLimit фиксируем константой. Оставляем только sendRawTransaction. Добавляем round robin для адресов и пару рекомендаций под конкретные EVM. Агент реализует, а я сижу и думаю: догадался ли он, как правильно обрабатывать тики с новыми ценами? Надо было объяснить чётче.
Когда всё готово, агент сообщает: «можно тестировать». Но мы-то знаем. Получается какая-то сборка на Rust. Внутрь не заглядываем. Как проверить результат без ревью? Начинаем копать:
- Сделай параллельно код-ревью — из текущего контекста и с чистого листа;
- Что будет, если пропадёт соединение с источниками цен?
- Как работает механизм gasPrice? Не сольёшь ли весь депозит на комиссию в новой сети?
- Сколько времени занимает обработка тика? Транзакции отправляются асинхронно?
- Замокай отправку и сделай dry run — посмотрим логи.
- и т.п.
Прогоняем множество сценариев: проблемы с отправкой, контроль баланса, подтверждение транзакций, синхронизация nonce. Каждый раз уточняю: «а синхронизацию ты правильно сделал?». Шаг за шагом получается рабочий бот. Да, в основном покрыт happy path, но и известные по опыту проблемы закрыты тестами. При этом код я так и не смотрел.
Когда эксперт — не ты
Это работает, когда я сам выступаю экспертом. Но что, если я сам не знаю, как лучше? Как только доходим до такой точки, я начинаю ждать — и даже надеяться — что агент решит всё за меня. Хотя до этого я «возил» его, опираясь на свои знания. Думаю: сейчас опишу возможные варианты, а он проведёт ресерч и скажет точно — «лучше вот так». Но этого не происходит.
Итог: роль разработчика меняется
Роль разработчика трансформируется. В перспективе это будет не просто AI-оператор, а эксперт-оператор уровня сеньора. Нужно будет вести несколько проектов параллельно, иметь серьёзный бэкграунд и, главное, нести ответственность за результат.
Чтобы решить проблему со сном, кроме очевидного совета «спать больше», вероятно, появится оркестрация не только агентов, но и операторов. Что-то вроде единого информационного пространства проектов. Подключаешься, берёшь задачи и, если есть права и навыки, — простаивающих агентов, которые ждут ревью и команд. Смотришь контекст и принимаешь решения. Как оператор горячей линии.
Есть ещё несколько идей, что нас ждёт впереди. Но это, пожалуй, уже отдельная статья.