https://thedotnetblog.com/ru/tags/prompt-engineering/Articles, tutorials and insights from the .NET community.Hugoru@thedotnetblog (The .NET Blog)@thedotnetblogFri, 17 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ru/news/emiliano-montesdeoca/gpt-5-5-prompt-tuning-vscode-less-wandering/Fri, 17 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ru/news/emiliano-montesdeoca/gpt-5-5-prompt-tuning-vscode-less-wandering/Эксперимент VS Code с GPT-5.5 показывает, что измеримые улучшения приходят от дисциплинированной итерации harness и промптов, а не просто от перехода на более новые базовые модели.<p>Самая ценная часть поста о настройке GPT-5.5 в VS Code — не победивший вариант. Это методология. Чёткая гипотеза, контролируемые обработки (treatments), измерение на живом трафике и метрики ограждений — именно так и должно улучшаться качество агентов в производственных окружениях.</p> <p>Оригинальный источник: <a href="https://code.visualstudio.com/blogs/2026/07/06/optimizing-vscode-coding-harness-model-providers">https://code.visualstudio.com/blogs/2026/07/06/optimizing-vscode-coding-harness-model-providers</a></p> <p>Основная идея была проста: снизить исследовательский дрейф и проверять раньше после правок. Звучит очевидно, но интересный вывод в том, что структурное руководство промптом на уровне harness дало статистически значимые улучшения в задержке, использовании токенов в хвосте распределения и количестве вызовов инструментов без серьёзного падения качества.</p> <p>Моё мнение прямолинейно: организации, которые гонятся только за обновлениями моделей, оставляют на столе лёгкие выигрыши в производительности и стоимости. Поведение harness и дизайн системного промпта могут двигать бизнес-метрики быстрее, чем смена модели, особенно когда задействован биллинг по использованию.</p> <p>Вариант B победил, потому что он формализовал полный цикл, а не просто ограничение поиска. Он подталкивал модель формировать локальную опровержимую гипотезу, делать обоснованную первую правку и немедленно проводить сфокусированную проверку. Эта последовательность отражает то, как хорошие инженеры-люди отлаживают код под давлением времени.</p> <p>Что стоит скопировать командам, строящим внутренних агентов для написания кода?</p> <p>Определите ограждения качества заранее, затем оптимизируйте под задержку и стоимость в рамках этих ограничений. Измеряйте и медианное, и хвостовое поведение. Улучшения p95 во времени до первой правки и использовании токенов часто ценнее выигрышей p50 для реальной удовлетворённости пользователей.</p> <p>Также избегайте переобучения только под офлайн-оценки. Команда VS Code использовала офлайн-проверки, а затем валидировала на живом трафике перед выкаткой. Этот порядок важен, потому что реальные рабочие процессы выявляют поведение, которое пропускают синтетические бенчмарки.</p> <p>Один компромисс заслуживает внимания: небольшое движение в краткосрочных метриках выживаемости. Команда справилась с этим правильно, взвесив размер эффекта и значимость против более сильных, высокозначимых выигрышей в эффективности. Это зрелое принятие решений, а не выборочное цитирование метрик.</p> <p>Более широкий урок стратегический. Prompt engineering — это не «магия промптов». Это продуктовая инженерия: гипотезы, эксперименты, контроли и шлюзы развёртывания. Команды, которые операционализируют этот цикл, будут постоянно улучшаться. Команды, спорящие о рейтингах моделей в соцсетях, — нет.</p> <p>В ближайший год конкурентное преимущество в ИИ для разработчиков будет приходить меньше от доступа к конкретному семейству моделей и больше от того, кто может надёжно запускать этот цикл оптимизации. Результаты VS Code — практический план: наблюдай, выдвигай гипотезу, тестируй, доставляй, повторяй.</p>