Самая ценная часть поста о настройке GPT-5.5 в VS Code — не победивший вариант. Это методология. Чёткая гипотеза, контролируемые обработки (treatments), измерение на живом трафике и метрики ограждений — именно так и должно улучшаться качество агентов в производственных окружениях.
Оригинальный источник: https://code.visualstudio.com/blogs/2026/07/06/optimizing-vscode-coding-harness-model-providers
Основная идея была проста: снизить исследовательский дрейф и проверять раньше после правок. Звучит очевидно, но интересный вывод в том, что структурное руководство промптом на уровне harness дало статистически значимые улучшения в задержке, использовании токенов в хвосте распределения и количестве вызовов инструментов без серьёзного падения качества.
Моё мнение прямолинейно: организации, которые гонятся только за обновлениями моделей, оставляют на столе лёгкие выигрыши в производительности и стоимости. Поведение harness и дизайн системного промпта могут двигать бизнес-метрики быстрее, чем смена модели, особенно когда задействован биллинг по использованию.
Вариант B победил, потому что он формализовал полный цикл, а не просто ограничение поиска. Он подталкивал модель формировать локальную опровержимую гипотезу, делать обоснованную первую правку и немедленно проводить сфокусированную проверку. Эта последовательность отражает то, как хорошие инженеры-люди отлаживают код под давлением времени.
Что стоит скопировать командам, строящим внутренних агентов для написания кода?
Определите ограждения качества заранее, затем оптимизируйте под задержку и стоимость в рамках этих ограничений. Измеряйте и медианное, и хвостовое поведение. Улучшения p95 во времени до первой правки и использовании токенов часто ценнее выигрышей p50 для реальной удовлетворённости пользователей.
Также избегайте переобучения только под офлайн-оценки. Команда VS Code использовала офлайн-проверки, а затем валидировала на живом трафике перед выкаткой. Этот порядок важен, потому что реальные рабочие процессы выявляют поведение, которое пропускают синтетические бенчмарки.
Один компромисс заслуживает внимания: небольшое движение в краткосрочных метриках выживаемости. Команда справилась с этим правильно, взвесив размер эффекта и значимость против более сильных, высокозначимых выигрышей в эффективности. Это зрелое принятие решений, а не выборочное цитирование метрик.
Более широкий урок стратегический. Prompt engineering — это не «магия промптов». Это продуктовая инженерия: гипотезы, эксперименты, контроли и шлюзы развёртывания. Команды, которые операционализируют этот цикл, будут постоянно улучшаться. Команды, спорящие о рейтингах моделей в соцсетях, — нет.
В ближайший год конкурентное преимущество в ИИ для разработчиков будет приходить меньше от доступа к конкретному семейству моделей и больше от того, кто может надёжно запускать этот цикл оптимизации. Результаты VS Code — практический план: наблюдай, выдвигай гипотезу, тестируй, доставляй, повторяй.
