GPT-6 Astra для веб-разработки: промпты, подходы и практика

Что такое GPT-6 Astra и зачем она веб-разработчику

GPT-6 Astra — флагманская модель OpenAI, ориентированная на сложную многоэтапную работу. В официальной документации OpenAI среди основных сценариев применения Astra выделяет программирование, сложные рассуждения, исследования, computer use и выполнение задач от постановки до конечного результата.

Для веб-разработчика это принципиально важное изменение.

Ранние поколения AI-инструментов чаще использовались примерно так:

вопрос → фрагмент кода → копирование кода → ручная проверка.

Современный агентный сценарий может выглядеть иначе:

задача → анализ проекта → поиск связанных файлов → реализация → запуск проверок → исправление обнаруженных проблем → итоговый результат.

Особенно хорошо такой подход раскрывается в Codex, где модель работает непосредственно с проектом.

При этом не стоит воспринимать Astra как программиста, которому можно бездумно передать репозиторий и принять любые изменения.

Модель способна ошибаться, неправильно интерпретировать требования и принимать технически работающие, но не оптимальные архитектурные решения.

Поэтому разработчик остается тем, кто определяет требования, архитектурные ограничения и критерии качества.

Что реально умеет GPT-6 Astra

По официальной документации OpenAI, GPT-6 Astra поддерживает программирование, работу с инструментами, computer use, Structured Outputs, prompt caching, persisted reasoning, compaction и многоагентную оркестрацию.

Для API модель имеет контекстное окно до 1,05 млн токенов и максимальный текстовый вывод до 128 тысяч токенов.

Для reasoning доступны уровни:

low

medium

high

xhigh

max

Причем Astra не поддерживает режим reasoning none.

Но для разработчика важнее не размер контекста сам по себе.

Главное улучшение заключается в способности модели выполнять продолжительные задачи и сохранять цель при работе с несколькими этапами.

Это позволяет ставить перед AI уже не только локальные задачи вроде:

Напиши PHP-функцию.

а гораздо более содержательные:

Изучи существующую реализацию каталога, найди причину лишних SQL-запросов, предложи минимальное изменение архитектуры, реализуй его и проверь существующие сценарии.

Именно такой способ работы я считаю наиболее интересным.

Главное правило: ставьте задачу, а не пишите заклинание

Одна из ошибок при работе с AI — поиск универсального «идеального промпта».

Например:

Ты лучший senior-разработчик в мире. Думай очень внимательно. Используй все свои знания. Сделай максимально качественно. Проверь себя пять раз.

Практической информации здесь почти нет.

Модель не узнает:

• какой перед ней проект;
• какую проблему необходимо решить;
• что разрешено менять;
• какие технологии используются;
• что нельзя сломать;
• какой результат считается готовым.

Для Astra полезнее конкретная инженерная постановка.

Например:

В существующем интернет-магазине на WordPress + WooCommerce необходимо добавить избранные товары.

Авторизованным пользователям сохраняй список в user meta. Для гостей используй localStorage.

После авторизации объедини локальный и серверный списки без дубликатов.

Не изменяй WooCommerce Core.

Используй существующую архитектуру темы и стили компонентов.

После реализации проверь сценарии добавления, удаления и объединения списков.

Здесь почти нет «prompt engineering».

Зато есть хорошее техническое задание.

Базовая структура промпта для веб-разработки

Для большинства серьезных задач я использую примерно такую структуру:

# Задача

Что необходимо получить.

# Контекст

CMS/framework.
Версия PHP.
Используемые библиотеки.
Особенности проекта.

# Требования

Что обязательно должно работать.

# Ограничения

Что нельзя менять или использовать.

# Реализация

Какую степень свободы получает агент.

# Проверка

Какие проверки необходимо выполнить.

# Критерий готовности

Когда задача считается завершенной.

Это не обязательный синтаксис GPT-6 Astra.

Это просто удобный способ не забыть важную информацию.

Разберем каждый блок подробнее.

1. Задача: описываем конечный результат

Плохой промпт:

Сделай мобильное меню.

Формально задача понятна, но модель вынуждена принимать слишком много решений самостоятельно.

Что значит «мобильное»?

При какой ширине оно появляется?

Есть ли вложенные пункты?

Как открывается?

Что происходит с body?

Нужно ли закрывать меню по Escape?

Лучше:

# Задача

Реализуй мобильное меню для существующей шапки сайта.

При ширине <= 991px основная навигация скрывается и появляется burger.

По нажатию открывается меню поверх страницы справа.

Требования:
- сохранить существующую HTML-структуру там, где это возможно;
- поддержать вложенные пункты;
- закрывать по кнопке, Escape и клику вне панели;
- блокировать прокрутку body;
- вернуть фокус на burger после закрытия;
- не изменять desktop-версию.

Теперь пространство возможных интерпретаций значительно меньше.

2. Контекст: рассказываем Astra, где она работает

Контекст особенно важен при работе с существующим проектом.

Например:

# Контекст проекта

CMS: WordPress
PHP: 8.3
WooCommerce: используется
Тема: собственная
Конструкторы страниц: отсутствуют
Frontend: SCSS + vanilla JS
Сборка: Vite
jQuery: не использовать в новом коде
Минимальная поддерживаемая ширина: 320px

Это намного полезнее фразы:

Используй современные технологии.

«Современные технологии» — субъективное понятие.

Конкретный стек — объективное ограничение.

3. Требования: описываем поведение

Требования отвечают на вопрос:

что система должна делать?

Например, для AJAX-фильтра каталога:

# Функциональные требования

Фильтр должен:
- фильтровать по категории;
- цене;
- наличию;
- производителю;
- работать без перезагрузки страницы;
- обновлять URL;
- восстанавливать состояние после перезагрузки;
- поддерживать back/forward браузера;
- сохранять существующую пагинацию.

Чем четче сформулировано поведение, тем проще проверить результат.

4. Ограничения защищают существующий проект

Это один из самых недооцененных элементов промпта.

Представим WordPress-проект.

Можно написать:

Реализуй функционал.

Но агент потенциально может установить новую библиотеку, создать несколько дополнительных классов или изменить существующий API.

Если это нежелательно, нужно сказать об этом прямо:

# Ограничения

Не изменяй WordPress Core и WooCommerce Core.

Не устанавливай новые плагины.

Не добавляй JS-зависимости без необходимости.

Не меняй существующие публичные PHP-функции и hooks.

Не выполняй рефакторинг файлов, не относящихся к задаче.

Сохраняй обратную совместимость.

OpenAI отдельно рекомендует избегать ненужной сложности, несвязанного cleanup и повторно использовать подходящие существующие utilities.

Для реального production-проекта это очень правильный подход.

5. Не заставляйте Astra переписывать половину проекта

Допустим, есть ошибка:

При добавлении вариативного товара в корзину иногда появляется 500.

Плохой запрос:

Полностью проанализируй систему корзины WooCommerce,
перепиши проблемный код и оптимизируй архитектуру.

Возможно, проблема находится в одной функции.

Глобальный рефакторинг только увеличивает риск.

Лучше:

Найди первопричину ошибки.

Сначала изучи минимально необходимую цепочку вызовов.

Предпочитай минимальное безопасное исправление.

Не выполняй архитектурный рефакторинг, если он не требуется для устранения причины ошибки.

Если обнаружишь отдельные потенциальные проблемы, перечисли их в конце, но не исправляй без необходимости.

Такой подход уменьшает scope creep — постепенное разрастание первоначальной задачи.

6. Сначала исследование, потом изменение

Для незнакомого проекта полезно явно потребовать изучить существующую реализацию.

Например:

Перед изменением кода:

1. Найди файлы, отвечающие за функционал.
2. Изучи связанные функции/classes/hooks.
3. Посмотри существующие тесты.
4. Проверь локальные инструкции проекта.
5. Определи минимальную область изменения.

После этого реализуй решение.

Не создавай новую архитектуру, если проект уже содержит подходящий паттерн.

Это особенно полезно для WordPress и 1С-Битрикс, где один и тот же функционал можно реализовать десятком способов.

Полный пример №1: разработка блока по макету

Рассмотрим реальную frontend-задачу.

Необходимо перенести секцию из дизайна на сайт.

Слабый промпт

Сверстай блок как на макете.
Адаптивно и pixel perfect.

Главная проблема здесь не в краткости.

Непонятно, что агент может менять.

Поэтому я бы поставил задачу так:

# Задача

Реализуй секцию Services по предоставленному макету.

Необходимо максимально точно воспроизвести визуальный дизайн
и сохранить существующую архитектуру проекта.

# Перед началом

Изучи:
- структуру текущей страницы;
- используемую сетку;
- типографику;
- CSS variables;
- существующие breakpoints;
- готовые компоненты кнопок и карточек.

Переиспользуй существующие решения, если они соответствуют макету.

# Desktop

Ориентируйся на макет 1440px.

Сохрани:
- размеры контейнера;
- взаимное расположение элементов;
- типографическую иерархию;
- радиусы;
- интервалы;
- пропорции изображений.

# Responsive

Не масштабируй desktop механически.

Для tablet и mobile перестрой layout так,
чтобы контент оставался читаемым и элементы не переполняли viewport.

Проверь как минимум:
1440px
1024px
768px
375px
320px

# Ограничения

Не меняй глобальные стили без необходимости.

Не создавай дубликаты существующих компонентов.

Не используй inline styles.

Не добавляй новую библиотеку ради одного эффекта.

# Проверка

После реализации открой страницу в браузере.

Сравни desktop с исходным макетом.

Проверь overflow, переносы текста, состояния hover/focus
и поведение на указанных ширинах.

Исправь обнаруженные визуальные проблемы.

# Результат

Кратко перечисли измененные файлы и существенные решения.

Почему этот вариант лучше?

Мы не диктуем AI конкретный CSS.

Мы определяем:

что сохранить → что исследовать → что разрешено → что проверить.

Модель получает пространство для реализации, но не для бесконтрольной перестройки проекта.

Полный пример №2: WordPress-функционал

Предположим, требуется добавить AJAX-поиск.

Я бы использовал следующий запрос:

# Роль

Работай как опытный WordPress/PHP-разработчик.

# Задача

Добавь AJAX-поиск по записям и товарам WooCommerce
в существующую форму поиска в header.

# Контекст

WordPress + WooCommerce.
PHP 8.3.
Собственная тема.
jQuery уже используется проектом.

# Поведение

После ввода минимум 3 символов:
- выполнить AJAX-запрос;
- показать максимум 8 результатов;
- искать posts и products;
- для товара вывести название, изображение и цену;
- для обычной записи — название и изображение;
- каждый результат должен вести на страницу объекта.

Если ничего не найдено — показать соответствующее сообщение.

# Производительность

Добавь debounce 300ms.

Не отправляй запрос повторно, если значение не изменилось.

Предыдущий незавершенный запрос должен отменяться
или его устаревший результат не должен заменять актуальный.

# Безопасность

Используй nonce.

Санитизируй входные данные.

Экранируй вывод согласно WordPress API.

# Архитектура

Сначала изучи существующую форму поиска,
JS-структуру и организацию AJAX handlers.

Следуй существующей архитектуре проекта.

Не создавай отдельную систему, если подходящий механизм уже существует.

# Ограничения

Не устанавливай плагины.

Не изменяй WordPress/WooCommerce Core.

Не рефактори несвязанные компоненты.

# Проверка

Проверь:
- запрос < 3 символов;
- обычный поиск;
- отсутствие результатов;
- специальные символы;
- быстрый набор текста;
- мобильную версию;
- PHP errors/warnings;
- корректность nonce.

Считай задачу завершенной после прохождения релевантных проверок.

Это уже практически полноценное техническое задание.

Полный пример №3: поиск ошибки PHP

Для debugging особенно важно не заставлять модель сразу менять код.

Например:

# Проблема

После перехода проекта с PHP 7.4 на PHP 8.3
страница оформления заказа периодически возвращает 500.

# Задача

Найди первопричину.

Не исправляй симптомы путем подавления warnings/errors.

# Порядок работы

Изучи stack trace и файлы из цепочки ошибки.

Найди первый участок собственного кода проекта,
который мог вызвать проблему.

Проверь совместимость используемой конструкции с PHP 8.3.

Если есть несколько гипотез:
- проверь их по имеющемуся коду;
- не выдавай предположение за установленную причину.

# Исправление

После определения причины сделай минимальное безопасное изменение.

Не выполняй несвязанный рефакторинг.

# Проверка

Запусти релевантную проверку синтаксиса/тесты проекта.

Повтори сценарий, который вызывал ошибку.

Проверь связанные сценарии checkout.

# Итог

Укажи:
1. первопричину;
2. измененные файлы;
3. почему исправление работает;
4. что было проверено;
5. оставшиеся риски, если они есть.

Здесь принципиальна фраза:

«не выдавай предположение за установленную причину».

Для debugging это одно из самых полезных ограничений.

Полный пример №4: 1С-Битрикс

Теперь пример ближе к разработке на Битрикс.

Задача: интеграция каталога с внешним API.

# Задача

Реализуй синхронизацию остатков каталога 1С-Битрикс
с внешним REST API.

# Контекст

Проект работает на 1С-Битрикс.
PHP 8.2.

Объем каталога: около 50 000 товаров.

Внешний API возвращает:
external_id
quantity
updated_at

В Битрикс external_id соответствует XML_ID товара.

# Требования

Синхронизация должна:
- работать через cron;
- обрабатывать данные пакетами;
- не превышать лимиты API;
- обновлять только изменившиеся остатки;
- корректно переживать временную недоступность API;
- логировать ошибки;
- не останавливать всю синхронизацию из-за одной ошибочной позиции.

# Надежность

Предусмотри retry только для временных ошибок.

Не допускай бесконечных повторов.

Повторный запуск не должен повреждать корректно обработанные данные.

# Производительность

Не загружай весь каталог в память.

Избегай N+1 запросов, где это возможно.

# Bitrix

Используй публичные API 1С-Битрикс.

Не изменяй файлы ядра.

# Перед реализацией

Изучи существующую структуру local/,
текущие cron-задачи и используемый проектом способ логирования.

Переиспользуй существующие механизмы, если они подходят.

# Результат

Реализуй рабочее решение.

После выполнения опиши:
- архитектуру;
- обработку очереди;
- retry;
- логирование;
- обработку частичного сбоя;
- измененные файлы;
- способ запуска и проверки.

Вместо «напиши интеграцию» мы определили характеристики production-решения.

Именно это существенно влияет на качество результата.

Полный пример №5: рефакторинг старого JavaScript

Рефакторинг — опасная задача для AI, потому что модель легко начинает «улучшать» больше, чем требовалось.

Поэтому границы особенно важны.

# Задача

Проведи локальный рефакторинг cart.js.

Цель:
упростить код и устранить дублирование обработчиков,
не изменяя пользовательское поведение.

# Сначала

Изучи:
- cart.js;
- HTML, с которым он взаимодействует;
- связанные AJAX endpoints;
- существующие тесты.

Опиши текущее поведение до изменения.

# Разрешено

- убрать явное дублирование;
- выделить небольшие функции;
- улучшить обработку ошибок;
- исправить подтвержденные проблемы.

# Не разрешено

- менять API;
- менять HTML без необходимости;
- подключать framework;
- переводить весь проект на другую архитектуру;
- рефакторить несвязанные файлы.

# Критерий

Поведение корзины до и после рефакторинга должно оставаться эквивалентным.

Проверь:
- изменение количества;
- удаление;
- пересчет;
- быстрые повторные клики;
- AJAX error;
- пустую корзину.

Ключевое слово здесь — эквивалентность поведения.

Astra и тестирование: не всегда «чем больше, тем лучше»

OpenAI отдельно обращает внимание на интересную особенность GPT-6 Astra: при программировании модель склонна тщательно тестировать работу перед завершением задачи.

Для критических изменений это хорошо.

Для изменения padding одной кнопки — избыточно.

Поэтому OpenAI рекомендует калибровать объем проверки в зависимости от изменения.

Для небольшой frontend-правки я использую что-то вроде:

Изменение локальное и обратимое.

Не создавай новые автоматические тесты только ради этой правки.

Проверь затронутый компонент и убедись,
что изменение не вызвало очевидной регрессии.

А для checkout:

Изменение затрагивает критичный пользовательский сценарий.

Выполни существующие релевантные тесты.

Проверь happy path и основные error states.

После успешного прохождения не повторяй проверки
без новой причины или нового изменения.

Это позволяет избежать двух крайностей:

«код написан — значит готово»

и

«изменили 5 строк — запускаем весь проект на два часа».

Не заставляйте Astra постоянно спрашивать разрешение

GPT-6 Astra, согласно OpenAI, чаще предыдущих моделей задает уточняющий вопрос, если ответ пользователя способен существенно изменить результат.

Для архитектурных решений это полезно.

Для мелких деталей может мешать.

Поэтому при агентной разработке можно определить уровень самостоятельности:

Если требования позволяют однозначно продолжить работу,
не останавливайся для подтверждения каждого шага.

Самостоятельно принимай обратимые низкорисковые решения,
следуя существующим паттернам проекта.

Задавай вопрос, если решение:
- меняет публичный API;
- требует необратимого изменения данных;
- влияет на безопасность;
- требует выбора между существенно разными архитектурами;
- невозможно надежно определить из проекта.

В остальных случаях продолжай до готового результата.

Это намного лучше, чем:

Никогда не задавай вопросов.

Иногда вопрос действительно необходим.

AGENTS.md становится важнее самого промпта

При работе с Codex часть правил лучше не повторять в каждом запросе.

Для этого используются инструкции проекта, например AGENTS.md.

Там можно хранить стабильные правила:

# Project

WordPress/WooCommerce custom theme.

# PHP

Minimum PHP: 8.2.

Follow WordPress Coding Standards.

Never modify WordPress or WooCommerce core.

# JavaScript

Use existing project utilities.

Do not introduce dependencies without a clear need.

# CSS

Use existing variables and breakpoints.

Mobile minimum width: 320px.

# Changes

Prefer minimal scoped changes.

Do not perform unrelated cleanup.

# Verification

Run checks relevant to changed code.

Do not create redundant tests for trivial visual changes.

После этого рабочий промпт может быть намного короче.

Например:

Добавь AJAX-поиск в header.

Требования:
[конкретные требования]

Следуй AGENTS.md и существующим паттернам проекта.

Но здесь есть важный нюанс.

OpenAI специально предупреждает, что Astra чувствительнее к инструкциям из AGENTS.md, Skills и других доступных файлов.

Если за год работы там накопились десятки старых правил, противоречий и костылей, они могут ухудшить результат.

Поэтому с переходом на Astra имеет смысл провести аудит инструкций проекта.

Не переносите старые промпты на Astra вслепую

11 сентября 2026 года OpenAI опубликовала отдельный материал о необходимости пересмотреть Skills, AGENTS.md и task prompts для GPT-6 Astra.

Причина проста.

Старым coding-моделям требовалось больше вспомогательных инструкций.

Например:

Сначала найди файл.
Потом прочитай его.
Потом найди импорт.
Потом прочитай импорт.
Потом составь план.
Потом...

Для более сильной агентной модели подобный микроменеджмент часто уже не нужен.

Более того, он способен мешать.

Если модель самостоятельно умеет исследовать кодовую базу, полезнее задать:

Перед реализацией изучи релевантный код и существующие
паттерны проекта. Определи минимальную область изменений.

То есть мы определяем обязательный результат исследования, а не каждый вызов инструмента.

Когда нужен высокий reasoning

Не каждая задача требует high, xhigh или max.

Для простой CSS-правки глубокое reasoning обычно избыточно.

Более высокий уровень разумнее использовать для задач вроде:

• сложного debugging;
• архитектурного изменения;
• миграции;
• concurrency;
• производительности;
• сложной интеграции;
• большого рефакторинга;
• анализа незнакомой кодовой базы.

Например:

изменить border-radius → low;

добавить типовой компонент → low/medium;

найти нестабильную ошибку checkout → medium/high;

спроектировать миграцию большого legacy-приложения → high/xhigh;

особо сложная задача с большим пространством решений → возможно max.

Это не жесткие правила OpenAI, а практическая схема выбора.

Главный принцип — не тратить максимальное reasoning там, где задача тривиальна.

Нужно ли писать «думай пошагово»

Обычно нет.

Современной reasoning-модели не нужно объяснять, что ей необходимо рассуждать.

Вместо:

Думай пошагово.
Очень внимательно проанализируй.
Перепроверь каждую мысль.

лучше определить проверяемое поведение:

Проверь решение на:
- race conditions;
- повторные запросы;
- ошибки сети;
- некорректные входные данные.

Не считай задачу завершенной,
пока релевантные сценарии не проверены.

Первый вариант описывает процесс мышления.

Второй — качество результата.

Для разработки второй намного полезнее.

Используйте скриншоты и браузер для frontend-задач

У GPT-6 Astra есть сильные возможности visual/computer use, поэтому frontend-разработка не обязательно должна заканчиваться генерацией HTML и CSS.

Более правильный цикл:

макет → реализация → запуск → визуальная проверка → исправление → повторная проверка.

Например:

После реализации открой страницу в браузере.

Сравни результат с предоставленным референсом.

Обрати внимание на:
- размеры контейнера;
- вертикальные интервалы;
- typography;
- alignment;
- размеры изображений;
- border radius;
- responsive behavior.

Исправь подтвержденные визуальные расхождения.

Не меняй элементы, которые уже соответствуют макету.

Последняя строка особенно полезна.

Иначе после каждой проверки агент может начать «улучшать» уже корректные участки.

Не просите одновременно «pixel perfect» и «сделай красивее»

Это противоречащие требования.

Если задача:

Сделать 1 в 1 по макету.

модель должна воспроизводить макет.

Если задача:

Использовать макет как референс и улучшить UX.

модель получает право принимать дизайнерские решения.

Поэтому заранее определите режим.

Режим воспроизведения

Макет является источником истины.
Не изменяй композицию и визуальные решения по своему усмотрению.

Режим творческой разработки

Макет используется как направление.
Можно улучшать композицию и responsive behavior,
если сохраняются стиль и функциональные требования.

Это две совершенно разные задачи.

Как правильно поручать большой проект

Не стоит пытаться в одном гигантском промпте подробно расписать каждую страницу будущего интернет-магазина.

Лучше разделить работу на уровни.

Сначала:

Изучи требования проекта.

Предложи архитектуру:
- структуру приложения;
- основные сущности;
- модель данных;
- API;
- authentication;
- ключевые компоненты frontend;
- интеграции.

Отметь архитектурные решения,
которые трудно изменить после начала разработки.

Пока не реализуй проект.

После согласования архитектуры:

Реализуй базовый каркас согласно согласованной архитектуре.

На этом этапе:
[scope]

Далее — отдельные функциональные этапы.

Причина не в том, что Astra не способна выполнить большую задачу.

Причина в стоимости ошибки.

Если неправильное архитектурное предположение обнаружится после генерации половины проекта, исправлять его значительно дороже.

Промпт для полноценной разработки лендинга

Вот вариант, который я бы действительно использовал:

# Цель

Разработать production-ready landing page
для услуги разработки сайтов.

Основная конверсия — отправка заявки.

# Аудитория

Малый и средний бизнес, которому нужен новый сайт
или переработка существующего.

# Визуальное направление

Темный premium tech.

Основной фон: #080808.
Акцент: теплый золотой.
Высокий контраст.
Много свободного пространства.
Минимум декоративного шума.

# Структура

Header
Hero
Services
Advantages
Portfolio
Development process
Testimonials
FAQ
Final CTA
Footer

# UX

Главный CTA должен быть виден в первом экране.

Повторяй CTA в логичных точках,
но не превращай страницу в набор кнопок.

На mobile основные действия должны оставаться доступными
без горизонтального overflow.

# Frontend

Используй существующий стек проекта.

Перед разработкой изучи:
- tokens;
- typography;
- container;
- buttons;
- forms;
- breakpoints.

Переиспользуй компоненты.

# Animation

Используй анимацию только там,
где она помогает иерархии или восприятию интерфейса.

Учитывай prefers-reduced-motion.

Не добавляй тяжелые библиотеки без необходимости.

# Accessibility

Semantic HTML.
Keyboard navigation.
Visible focus.
Корректные labels.
Контрастный текст.

# Performance

Оптимизируй изображения.
Избегай layout shifts.
Не подключай ненужные зависимости.

# Responsive

Проверь:
1440
1024
768
375
320

# Verification

После реализации открой страницу в браузере.

Проверь:
- layout;
- responsive;
- формы;
- navigation;
- console errors;
- overflow;
- keyboard interaction.

Исправь найденные проблемы.

# Completion

Не останавливайся после генерации первой версии.
Доведи реализацию до рабочего проверенного состояния.

В конце перечисли:
- измененные файлы;
- ключевые решения;
- выполненные проверки;
- известные ограничения.

Здесь Astra получает достаточно свободы для разработки, но результат остается контролируемым.

Самая эффективная схема работы с Astra

После практики с coding agents я бы свел рабочий процесс к следующей модели:

1. Дайте модели цель.

Не «напиши код», а «какой результат должен получить пользователь».

2. Дайте контекст.

Стек, проект, версии, существующая архитектура.

3. Установите границы.

Что можно и нельзя менять.

4. Заставьте сначала изучить существующее решение.

Особенно для legacy.

5. Определите критерии приемки.

Как понять, что задача выполнена.

6. Разрешите модели действовать самостоятельно внутри этих границ.

Не микроменеджерите каждую команду.

7. Требуйте проверки результата.

Но масштаб проверки должен соответствовать риску изменения.

Получается:

цель → контекст → ограничения → реализация → проверка → готовый результат.

Чего я бы не писал в промптах

Я постепенно убираю инструкции вроде:

Ты программист уровня middle+

Используй 100% своих возможностей.

Думай как команда из 20 senior-разработчиков.

Никогда не ошибайся.

Проверь код ровно 10 раз.

Сначала обязательно напиши подробный план из 20 пунктов.

Они либо практически ничего не определяют, либо искусственно ограничивают работу модели.

Гораздо ценнее:

Не изменяй публичный API.

Не выполняй несвязанный рефакторинг.

Используй существующие компоненты.

Проверь checkout для гостя и авторизованного пользователя.

Не считай гипотезу причиной ошибки без подтверждения.

Это конкретные инженерные требования.

Промпт должен становиться короче по мере улучшения проекта

На первый взгляд это звучит странно.

Но хороший AI-ready проект постепенно переносит постоянные правила из промптов в сам проект.

Например:

AGENTS.md содержит coding rules.

README объясняет архитектуру.

Tests определяют ожидаемое поведение.

Linters контролируют стиль.

Type system ловит часть ошибок.

CI выполняет проверки.

Skills описывают специализированные процедуры.

В итоге вместо огромного промпта:

Ты senior developer... вот 200 правил...

можно написать:

Исправь проблему с повторным AJAX-запросом при изменении количества товара.

Симптом:
[описание]

Следуй инструкциям репозитория.

Найди первопричину, сделай минимальное исправление
и выполни релевантные проверки.

И это, пожалуй, одна из главных идей современного AI-assisted development.

Лучший промпт не компенсирует плохо организованный проект.

GPT-6 Astra не отменяет разработчика

Чем лучше становятся coding-модели, тем чаще возникает впечатление, что программирование превращается в обычное написание промптов.

Я с этим не согласен.

На практике происходит другое.

Модель берет на себя все больше механической работы:

• boilerplate;
• поиск по проекту;
• создание типовых компонентов;
• часть debugging;
• тестирование;
• документацию;
• рефакторинг;
• перенос повторяющихся изменений.

Но кто-то все равно должен понимать:

правильно ли поставлена задача;

подходит ли архитектура;

безопасно ли решение;

соответствует ли оно бизнес-логике;

можно ли поддерживать этот код через два года.

Если разработчик не понимает PHP, плохой PHP-код от AI может выглядеть для него отличным.

Если он не понимает безопасность, уязвимая авторизация может казаться рабочей.

Если он не понимает frontend, страница, которая хорошо выглядит на его мониторе, может оказаться непригодной для реального использования.

Поэтому AI не отменяет инженерные знания.

Он увеличивает отдачу от них.

Итог: как получить максимум от GPT-6 Astra

GPT-6 Astra лучше воспринимать не как генератор кода, а как мощного coding-агента, которому требуется нормальная инженерная постановка задачи.

Для простого изменения достаточно короткого запроса.

Для сложной задачи нужны контекст, требования, ограничения и критерии готовности.

Не стоит подробно объяснять модели каждый шаг работы, если она способна определить его самостоятельно.

Вместо этого лучше четко определить куда необходимо прийти и какие границы нельзя пересекать.

Для веб-разработки я бы сформулировал универсальную схему промпта так:

Что нужно получить?

Где это реализуется?

Как должно работать?

Что нельзя ломать или менять?

Что модель должна изучить перед изменением?

Какие проверки подтверждают результат?

Когда задача считается завершенной?

Если на эти вопросы есть конкретные ответы, обычно получается хороший промпт.

А если подобных требований нет, даже GPT-6 Astra придется угадывать, чего именно хотел разработчик.

Именно поэтому с развитием AI значение грамотного технического задания не уменьшается.

Наоборот — чем автономнее становится модель, тем важнее правильно определить задачу, границы и конечный результат.

Нужна разработка сайта?

Я  веб-разработчик WordPress и 1С-Битрикс. Разрабатываю сайты под ключ, интернет-магазины, индивидуальный функционал, интеграции и выполняю доработку существующих проектов.