Проблема: один разработчик, три роли, дедлайн вчера
В 2026 году рынок высоконагруженных бэкендов живёт по странным правилам: продукт нужен вчера, бюджет — на одного инженера, а требования — как у команды из трёх человек: архитектор, который проектирует gRPC-контракты и микросервисы; concurrency-инженер, который выжимает максимум из асинхронного программирования; SRE, который профилирует p99-латентность и читает flamegraph.
Rust и Go — два языка, которые чаще всего выбирают для таких задач. Go даёт простую модель горутин и встроенный планировщик, Rust — zero-cost абстракции и гарантии на уровне типов через Send/Sync. Но ни один из них не даёт вам третью и четвёртую пару рук. Именно здесь в игру вступают промты — не как «магические кнопки», а как способ сжать цикл «идея → рабочий код → измерение» до нескольких минут.
Ниже — подборка из 10 промтов, проверенных на реальных проектах: от проектирования gRPC-схемы до чтения профиля и ревью кода. Каждый промт — с полным текстом, объяснением, зачем он нужен, и примером результата.
Базовый уровень: проектирование и каркас
Промт 1. Генерация gRPC-контракта из бизнес-требований
Задача: получить .proto-файл с корректными типами, стримингами и версионированием.
Промт:
Ты — инженер по API-дизайну. Спроектируй gRPC-контракт (proto3) для сервиса
обработки платежей. Требования: идемпотентное создание платежа, стриминг статуса,
пакетная отмена. Используй google.protobuf.Timestamp и well-known types.
Добавь комментарии к полям, объясни выбор server-streaming vs unary.
Укажи пакет payment.v1 и правила эволюции схемы (reserved-номера).
Пример результата: модель выдаёт service PaymentService с методами CreatePayment (unary, идемпотентность через idempotency_key), WatchStatus (stream PaymentEvent), BatchCancel. Ключевой момент — поле reserved 4, 7; для удалённых полей, чтобы не сломать совместимость. Официальные правила эволюции описаны в Protobuf Language Guide, и промт явно просит им следовать.
Промт 2. Скелет Go-сервиса с graceful shutdown
Задача: не забыть про context.Context, отмену и корректное завершение.
Промт:
Сгенерируй Go 1.22+ сервис: HTTP-сервер + gRPC на отдельных портах.
Обязательно: context propagation, graceful shutdown по SIGTERM с таймаутом 15с,
структурированные логи через log/slog, health-check /healthz.
Покажи main.go и объясни порядок закрытия ресурсов.
Пример результата: модель возвращает http.Server с Shutdown(ctx), grpc.Server.GracefulStop() и signal.NotifyContext. Это ровно тот код, который обычно пишут в последний день и забывают про порядок закрытия БД после сервера.
Продвинутый уровень: конкурентность и производительность
Промт 3. Rust: безопасный параллелизм без гонок
Задача: превратить последовательный код в параллельный, сохранив гарантии компилятора.
Промт:
У меня есть Rust-функция, обрабатывающая Vec<Request> последовательно.
Перепиши её на rayon для параллельной обработки. Объясни, почему выбранный
подход удовлетворяет трейтам Send + Sync. Если нужен Mutex — покажи, где узкое место.
Пример результата: модель предлагает requests.par_iter().map(process).collect(). Ключевой аргумент: rayon требует Fn + Send + Sync, и если process захватывает Rc, компилятор это отклонит — промт просит объяснить именно это, чтобы вы понимали ограничение, а не просто копировали. Документация по трейтам — std::marker::Send.
Промт 4. Диагностика утечки горутин
Задача: найти причину роста числа горутин в проде.
Промт:
В Go-сервисе растёт runtime.NumGoroutine(). Вот код с каналами и select.
Проанализируй: где горутина может блокироваться навсегда? Покажи сценарии
с nil-каналом, отсутствующим default и небуферизованным каналом.
Предложи исправление и как воспроизвести утечку в тесте с goleak.
Пример результата: модель находит горутину, читающую из канала, в который никто не пишет после ошибки, и предлагает context + select с ctx.Done(). Для тестов — библиотека go.uber.org/goleak, которая падает, если горутины остались после теста.
Промт 5. Профилирование p99-латентности
Задача: интерпретировать pprof-вывод, а не просто его собрать.
Промт:
Вот вывод go tool pprof -top по CPU и по блокировкам. Объясни, какие функции
влияют на p99, а не на среднее. Предложи 3 гипотезы и способ проверить каждую.
Учти, что GC может давать хвостовую латентность.
Пример результата: модель указывает на runtime.mallocgc в топе, объясняет, что это признак аллокаций в горячем пути, и предлагает sync.Pool или преаллокацию слайсов. Это классический кейс: p50 стабилен, p99 скачет — и виноват GC.
Экспертный уровень: архитектура и ревью
Промт 6. Выбор между Tokio и async-std
Задача: обосновать рантайм для нового Rust-сервиса.
Промт:
Сравни Tokio и async-std для сервиса с 10k одновременных соединений.
Учти: экосистема, поддержка io_uring, стабильность API, размер бинарника.
Дай таблицу и рекомендацию для продакшена в 2026 году.
Пример результата: таблица ниже.
| Критерий | Tokio | async-std |
|---|---|---|
| Экосистема | Доминирует (hyper, tonic, axum) | Уже |
| io_uring | Поддержка в развитии | Ограниченная |
| Стабильность | LTS-политика | Реже релизы |
Вывод модели: для нового продакшена — Tokio, из-за tonic и hyper. Это не «мнение», а следствие экосистемной зависимости.
Промт 7. Ревью кода как senior-инженер
Задача: получить ревью уровня staff-инженера, а не линтер.
Промт:
Сделай ревью этого Go-кода как staff-инженер. Ищи: гонки данных, ошибки
контекста, неэффективные аллокации, нарушение идиоматичности.
Для каждого замечания — severity и конкретный фикс с кодом.
Пример результата: модель ловит err без errors.Is/errors.As, отсутствие defer cancel(), и предлагает заменить fmt.Errorf("%v") на %w для unwrap. Это именно то, что пропускают линтеры.
Промт 8. Нагрузочное тестирование и его интерпретация
Задача: не просто запустить hey/k6, а понять узкое место.
Промт:
Напиши k6-скрипт для сценария: 500 RPS, ramp-up 30с, проверка p95 < 200мс.
Затем объясни, как по результатам отличить bottleneck в БД от bottleneck в сети.
Пример результата: скрипт на k6 с stages и thresholds, плюс объяснение: если CPU сервиса низкий, а латентность растёт — смотрите пул соединений к БД; если CPU в потолке — профилируйте.
Промт 9. Схема деградации и circuit breaker
Задача: спроектировать отказоустойчивость микросервисов.
Промт:
Спроектируй стратегию отказоустойчивости для цепочки из 4 микросервисов
на Go. Нужны: circuit breaker, retry с backoff, timeout budget.
Покажи код с sony/gobreaker и объясни, почему retry без jitter опасен.
Пример результата: модель объясняет thundering herd: синхронные retry без jitter усиливают нагрузку на падающий сервис. Решение — экспоненциальный backoff с случайным разбросом.
Промт 10. Миграция с монолита на gRPC-микросервисы
Задача: план миграции без остановки продакшена.
Промт:
Составь пошаговый план миграции Go-монолита на gRPC-микросервисы
без простоя. Используй strangler fig pattern. Укажи, как шарить типы
между сервисами и как избежать распределённых транзакций.
Пример результата: план из этапов: выделение bounded context, фасад, постепенный перенос трафика, при этом модель предупреждает про сагу вместо 2PC.
Что реально даёт такой подход
Промты не заменяют инженера — они убирают рутину, оставляя вам архитектурные решения. Ключевой навык 2026 года — не писать код быстрее, а формулировать задачу так, чтобы модель выдавала проверяемый результат: с трейтами Send/Sync, с context.Context, с p99 в голове.
Начните с трёх промтов из базового уровня, прогоните их на своём проекте и сравните время до первого рабочего коммита. Дальше добавляйте профилирование и ревью — именно они дают эффект «команды из трёх». А если хотите системно прокачать Rust и Go с AI-обучением — загляните на asibiont.com.
Comments