Инженерия 80/20: как я перестроил свой сайт за выходные

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

Вместо этого большую часть времени я занимался тем, чего избегают большинство разработчиков, как чумы — подготовкой. Документированием. Записыванием. И когда я наконец открыл редактор и начал работать с OpenAI Codex, сама реализация прошла как отрепетированный фокус.

Это история о том, как 80% работы делаются до написания единой строки кода, и как это изменило всё.

Почему переписывать сайт?

Мой сайт работал на Qwik v3. Надёжная технология, приятная атмосфера, но я хотел больше гибкости — особенно в маршрутизации. Я перешёл на React Router в режиме framework. Полная перестройка, а не рефакторинг. Новая архитектура, чистая структура файлов, обновлённые стили (привет, Tailwind v4) и чистый лист.

Но что меня удивило: само кодирование заняло около 2–3 часов. От начала до конца. И всё сработало с первого раза.

Так что же происходило в остальные 5 часов?

80%: подготовка Codex как консультант готовит презентацию

Большая часть усилий ушла на создание «мега-промпт-системы» — не в навороченном UI, а прямо в папке проекта. Вот что я делал перед тем, как попросить Codex написать хоть один компонент:

• Скачал всю документацию React Router и сохранил её в каталог /guides.

• Сделал то же для Tailwind CSS v4, преобразовав самые важные страницы в Markdown с помощью Firecrawl.

• Написал файл PROMPT.md с обзором проекта:

  • «Легаси-код находится в /, новый код — в /app.»
  • «Минимальный UI, сосредоточиться на бизнес-логике.»
  • «Использовать Tailwind v4. Придерживаться режима framework в React Router.»
  • И так далее.

Это было не пустое оформление. Это был операционный контекст — тот подробный бриф, который вы даёте новому участнику команды в первый день. Codex не гадал, чего я хочу, у него была документация в репозитории. Были точные правила на простом английском. Были ограничения.

Когда я наконец напечатал:

«Прочитай PROMPT.md. Сначала мигрируй все маршруты в новое приложение.»

Codex отреагировал так, словно ждал этого задания всю жизнь.

Мега-промпты, минимум галлюцинаций

Результаты были поразительными. Codex следовал инструкциям. Не фантазировал. Не придумывал ничего лишнего. Уважал директиву «не фокусироваться на UI». Логика сервера была перенесена аккуратно. Конфигурация маршрутов выглядела так, будто я писал её сам — если бы у меня было терпение компилятора.

Это было не просто «промпт-инжиниринг». Это было закрепление Codex на реальных и актуальных спецификациях. Не расплывчатый список задач. Не список желаемых функций. А структурированный ввод, чёткие примеры и локальный доступ к нужной документации.

Что заняло время? Не код

Когда фундамент был заложен, работа разделилась на две чёткие фазы:

1. Режим Codex — быстрое, структурированное, повторяемое выполнение. Проходила миграция, логика и даже разметка с почти идеальной точностью.
2. Режим исследования дизайна — медленное, ручное и открытое. Человеческая часть: выбор внешнего вида, проба макетов, эксперименты с компонентами. Когда появлялся рабочий визуальный стиль, Codex снова брался за дело, распространяя шаблоны дизайна.

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

Главное понимание: Codex хорош ровно настолько, насколько качественна подготовка

Эти выходные укрепили одно изменение, которое я замечаю в своей работе:

Кодирование становится простой частью. Планирование — это сложно и самое важное.

Для небольших и средних проектов я теперь рассматриваю реализацию как 20%-ную задачу. 80% — это предзагрузка: сбор документации, написание конкретных задач, построение контекстных промптов.

Codex отлично работает с такой структурой. Если давать ему неоднозначные данные, он выдаст неоднозначность. Но если выстроить среду с намерением — документы, ограничения, чёткие описания — он работает как старший разработчик с идеальной памятью и без эго.

Вперёд: относитесь к ИИ как к члену команды, а не к джинну

Вывод прост: относитесь к своим инструментам ИИ для кодирования как к коллегам. Давайте им те же материалы, что дали бы реальному инженеру. Подготовьте контекст. Будьте конкретны. Будьте исчерпывающими.

В следующий раз, для более крупного проекта, я пойду ещё дальше:

• Один мастер-документ с планом, определяющий весь объём проекта.
• Индивидуальные спецификации задач по подсистемам или компонентам.
• Рабочий набор Markdown-документов и файлов-примеров как локальная база ссылок.

Codex не нужны волшебные слова — ему нужна структура.

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

Эволюция дизайна: визуальное путешествие

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

Версия 1: отправная точка

Версия 2: более чёткий стиль

Версия 2.1: доработки и полировка

Версия 3: эпоха Qwik

Версия 4: простота и фокус с Remix

Каждая версия добавляла новые идеи о том, что делает сайт эффективным — не только в эстетике, но и в ясности, удобстве использования и удобстве поддержки. Путь дизайна отражал путь разработки: обдуманный, итеративный и всегда направленный в будущее.