Привет, Хабр! Меня зовут Максим Панфилов, я ИТ-предприниматель. Моя история в разработке началась 25 лет назад с программирования, но со временем переросла в управление собственной веб-студией. Последние лет 15 я не писал код, полностью переключившись на менеджмент и бизнес-процессы. Я думал, что мои дни в роли разработчика остались в прошлом, пока не случилась революция больших языковых моделей.

Внезапно у меня появилась возможность вернуться к созданию продуктов своими руками. Это возвращение ощущалось так, будто я обрёл сверхспособности. Задачи, которые раньше требовали бы команды и недель работы, теперь я решаю за считанные дни. И это не просто пет-проекты для развлечения, а реальные рабочие веб-сервисы, некоторые – с десятками тысяч пользователей.

Главным инструментом, моим «костюмом Железного человека», стала среда разработки Warp. За последний год я перепробовал всё, где есть AI: Cursor, Windsurf, Replit и другие. Но именно Warp позволил мне в одиночку за два месяца полностью переписать и модернизировать сложный легаси-проект и довести до продакшна несколько новых.

В этой статье я хочу подробно рассказать, почему терминал в основе среды ИИ-разработки — это удобнее, чем текстовый редактор, как правильно «думать» вместе с LLM, и какие конкретные rules, MCP и фреймворки помогают мне в разработке, ускоряя её в разы.

Warp: среда разработки в терминале с ИИ

Большинство современных AI-инструментов, таких как Cursor или Windsurf – это форки IDE VS Code с панелью чата с ИИ: в их основе лежит текстовый редактор. Warp шел другим путем: изначально это был клиент для терминала, куда встроили ИИ.

По сути, команды терминала - это «шорткаты» для определенных действий, которые мы просим выполнять машину: то есть тоже язык. Но благодаря AI в терминале нет необходимости в том, чтобы запоминать «словарь» команд – LLM выступает переводчиком с естественного языка.

Режимы работы Warp

Процесс разработки так или иначе активно задействует терминал: сборка, git, ssh, docker, запуск скриптов, управление зависимостями. Warp не пытается изолировать вас от этого — он погружает вас в эту среду и усиливает ее.

Главная магия происходит в едином поле ввода. Оно легко переключается между двумя режимами:

1. Терминал: Для выполнения стандартных команд. Warp здесь предлагает умные автодополнения и запоминает часто используемые команды в контексте конкретных директорий проектов, что ускоряет работу: например, по какому адресу подключаться к серверу, как запустить проект, какие команды для git – достаточно нажать на клавиатуре стрелку вправо, и текст из подсказки заполнится в поле ввода.

2. AI-агент: Для общения с языковой моделью на естественном языке – в ответ на ваши промпты Warp будет писать код или выполнять команды в терминале. Если кому-то нравится надиктовывать текст, то есть возможность включить режим расшифровки аудио (я его отключил, мне удобнее печатать).

Warp достаточно умен, чтобы в большинстве случаев автоматически определять, что вы хотите. Начинаете вводить git push... — он понимает, что это команда. Пишете по-русски «объясни мне этот bash-скрипт» — он активирует AI. Это создает абсолютно бесшовный, непрерывный рабочий процесс, где AI — не отдельное окно, а естественное продолжение вашей командной строки. Есть удобный шорткат Cmd+I (на MacOS) для переключения между режимами.

При этом Warp состоит не только из командной строки – в интерфейсе можно открыть и файловый менеджер, и текстовый редактор (не такой крутой, как у подобий VS Code, но для того, чтобы поправить мелочи за ИИ хватает).

Warp как ваш личный DevOps

Одно из преимуществ Warp как терминала — его возможности не ограничиваются локальной машиной. После подключения по ssh Warp «прокидывает» своего агента на удаленный сервер — это называется "warpify session".

Это даёт возможность для автоматизации типовых DevOps-задач:

• Настройка Nginx: Добавь новый конфиг для домена example.com с проксированием на порт 3000 для проекта из папки /folder.

• Работа с Docker: Покажи логи контейнера 'my-app' за последний час и найди все ошибки.

• SSL-сертификаты: Выпусти и настрой Let's Encrypt сертификат для домена my-app.com.

AI видит файловую структуру сервера, может читать конфиги и выполнять команды. Для простых и средних проектов это практически полностью заменяет необходимость в отдельном DevOps-инженере.

Далее я расскажу про принципы, инструменты и методы разработки с использованием ИИ, к которым я пришел за последние полгода. В целом, их можно применять не только в Warp – это общие подходы, которые будут работать в любой среде разработки с LLM.

Context is king

Самое важное, что я осознал за время работы с AI в разработке: единственное, чем мы можем и должны управлять — это контекст. Качество работы любой модели напрямую зависит от того, насколько полный и релевантный контекст мы ей предоставляем. Все «агенты» и «инструменты разработки» по сути являются лишь продвинутыми менеджерами контекста для LLM. Вот несколько примеров, как можно управлять контекстом в Warp.

По сути весь промпт-инжиниринг и управление контекстом решают задачу направления и ограничения LLM при работе, чтобы она меньше выдумывала от себя, то есть галлюцинировала.

Контекст проекта – файл warp.md

Находясь в папке с кодом проекта достаточно выполнить команду /init, чтобы Warp проиндексировал кодовую базу и создал специальный файл warp.md. В нём содержится информация о стеке технологий, структуре директорий, основных зависимостях. Туда же вы можете добавить в него указания о своих архитектурных предпочтениях и другие моменты вашего код-стиля и принципов разработки для данного проекта – всё это LLM будет автоматически брать в контекст, когда вы будете ставить ей задачи.

Правила для кодинг-агента

Как и в других средах разработки с LLM, управлять поведением AI в Warp помогают настраиваемые правила – Rules. Вы можете задать как общие правила для всех своих проектов, так и специфические для каждого отдельного.

Поскольку я почти все пишу на Node.js и TypeScript, у меня есть глобальный набор правил под этот стек, которому агент следует всегда:

• Архитектура: Всегда использовать подходы SOLID и Clean Architecture при проектировании решений.

• Типизация: В конце задачи проверять ошибки компиляции TypeScript, особенно в части строгой типизации.

• Комментарии: Обязательно оставлять инлайн-комментарии в коде. Это помогает не только мне быстрее разбираться в том, что он написал, но и самому AI, так как он использует эти комменты для лучшего понимания контекста при последующих задачах.

• Запреты (Deny List): У меня есть строгое правило никогда не трогать файл .env. Он может работать с .env.example, но рабочий .env ему трогать, удалять или редактировать запрещено.

• Согласование: Любые изменения, связанные со структурой базы данных, агент должен проводить только с моего согласования.

MCP Context7

Также есть возможность подключать внешние источники данных через MCP (Model Context Protocol). Самый главный из них для меня — это Context7, библиотека самой актуальной документации по десяткам тысяч фреймворков и библиотек, адаптированной для использования LLM.

Это критически важно, потому что модели, даже самые новые GPT-5 или Claude Sonnet 4.5, имеют «отсечку по знаниям» – их внутренняя «память» заканчивается на дате где-то за полгода до выпуска. Они могут не знать о выходе, например, Nuxt 4, и будут писать код по старым гайдам для Nuxt 2. Подключив в настройках MCP Context7, я просто добавляю в правила «всегда консультируйся с Context7», и агент идет в эту библиотеку за самой свежей документацией, что гарантирует использование актуальных версий и подходов.

Режим планирования и документация

Большие проекты, вроде полного рефакторинга кодовой базы или создания сложного веб-сервиса, нельзя выполнить одним промптом. Ключ к успеху — это Spec-Driven Development – разработка на основе спецификаций.

Мой обычный рабочий процесс над крупными задачами выглядит так:

1. Создание спецификации: Я начинаю с промпта-шортката: «Спроектируй...». Для AI это триггер, что нужно составить подробную документацию по функциональности, которую я описываю, и записать ее в .md файл в папку docs/.

2. Режим планирования: Для сложных задач Warp предлагает «режим планирования» (Planning). Я прошу AI составить пошаговый план внедрения (чек-лист) прямо в этом файле документации.

3. Контроль выполнения: Я даю команду: «Приступай к реализации по этому плану и отмечай прогресс в этом же файле по ходу выполнения».

Это помогает удерживать LLM в рамках контекста. Даже если AI «забивает» свое окно контекста и начинает новый диалог, он всегда может вернуться к файлу с документацией и отметкой прогресса, посмотреть, что уже сделано, а что нет, и продолжить работу ровно с того места, где остановился. Я же, как тимлид, просто проверяю этот docs/ файл и правлю спецификацию, если AI что-то понял не так, пока не согласую ее и не пущу в работу.

Контекст диалога

Когда вы ведете длинный диалог, контекстное окно модели начинает заполняться: в него попадают как ваши промпты и другие входные данные, так и ответы LLM и код, который она пишет. Окно контекста (context window) измеряется в тысячах токенов: например, 200 тысяч для Claude Sonnet или даже миллион для Gemini. Но при активной разработке на проектах с разветвленной архитектурой даже большое окно контекста заполняется. Тогда Warp незаметно для пользователя автоматически суммирует предыдущую беседу и уже эту выжимку использует как контекст, очищая контекстное окно, при этом сохраняя ключевую информацию из истории диалога.

Тем не менее, иногда качество ответов может ухудшаться, если контекст становится слишком большим. В таком случае можно попросить записать саммари по проделанной работе в отдельный md-файл, затем вручную начать новый диалог (есть шорткат Сmd+Shift+N) и передать весь необходимый контекст заново – "на чистую голову" модель может начать думать лучше, чем в перегруженном старом диалоге.

Ещё есть удобные функции дополнения контекста из результатов работы команд терминала:

• выделите любой текст в терминале – он автоматически добавится в контекст следующего промпта (над полем ввода появится плашка "selected text attached"),

• также в правом верхнем углу каждого блока с результатами работы команды терминала есть кнопка "Attach as Agent Mode context" – она добавляет в контекст,

• шорткат Cmd+↑ добавляет в контекст весь текст из результата последней команды терминала.

Скриншоты

При работе с фронтендом удобно просто копи-пастить скриншоты интерфейса в поле запроса – все модели в Warp мультимодальные, то есть могут обрабатывать изображения. Это упрощает задачу, когда нужно показать, как выглядит текущий UI, который нужно поправить, или передать сложную схему, не тратя время на ее словесное описание.

Выбор языковой модели

В Warp доступны все ключевые на текущий момент языковые модели, за исключением OpenAI Codex и моделей Grok.

Какие выводы я сделал по использованию языковых моделей (актуально на ноябрь 2025 года):

• Claude 4.5 Haiku: У меня установлена в настройках по умолчанию. Для быстрых, простых задач: внести небольшую правку, объяснить фрагмент кода, выполнить команду в терминале. Самая быстрая и дешевая.

• GPT-5 High Reasoning: Мой основной выбор для сложных архитектурных задач. Рефакторинг, проектирование новых модулей, анализ взаимосвязей в большой кодовой базе. На моем опыте, именно GPT-5 лучше всех справляется с удержанием «в уме» сложной, многоуровневой логики и работой с документацией.

• Claude 4.5 Sonnet: Тоже подходит для сложных задач. Не так эффективно, как GPT-5, зато быстрее. Главное отличие – использует emoji в ответах!

• Claude 4.5 Sonnet (thinking): Вариант флагманской модели от Claude с размышлениями. Это главный конкурент GPT-5 High Reasoning в моём списке. Думает быстрее и часто хорошо справляется, но всё же даю ему второе место.

• Gemini 2.5: Идеален для работы с текстом, когда нужен копирайтинг, но с кодом он справляется хуже GPT или Claude, даже несмотря на заявленное окно контекста в 1 миллион токенов.

На сложных задачах я всегда выбираю GPT-5 High Reasoning: на ключевом проекте, о котором я расскажу ниже, у меня было несколько моментов, когда я решил поэкспериментировать и доверил задачи сложного рефакторинга модулей Claude Sonnet и Gemini – обе модели ушли не туда, и пришлось откатывать изменения. С GPT-5 я успешно завершил задуманное.

Кейс: воскрешение из легаси-ада за два месяца

Чтобы не быть голословным, расскажу о реальной задаче. Мой пет-проект «OK, Bob!» — трекер задач в Telegram с мини-аппом и веб-версией — за несколько лет превратился в монстра. Он состоял из трех разных репозиториев (бек на Nest.js, фронт на Vue.js и бот на Telegraf.js), написанных в разное время разными разработчиками. И если фронт мы успели отрефакторить, то кодовая база бека страдала от всех известных болезней: спагетти-код, отсутствие единого стиля, устаревшие зависимости, три разные версии API, работающие одновременно. Развивать это было болью, а пользовательская база росла, и мне хотелось продолжать улучшать продукт.

Я поставил себе амбициозную задачу: переписать бек с нуля с помощью LLM. И сделал это в одиночку за два с небольшим месяца, будучи, по сути, «ржавым» кодером.

Шаг 1: Аудит и планирование

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

Проведи аудит модуля src/module/users. Используя документацию из context-7 по Nest.js и принципы Clean Architecture, составь подробный план рефакторинга.

В результате я получал подробный Markdown-документ, который содержал:

• Цели и задачи рефакторинга

• Предложенная новая файловая структура модуля

• Детальный пошаговый план работ, разбитый на этапы

• Описанные риски и критерии приемки

Такой подход к разработке с AI называется Spec-Driven Development или «разработка, основанная на спецификации». И это единственный способ, которым можно справляться с сложными задачами, требующими тщательного планирования и архитектуры.

Шаг 2: Итеративная реализация

Далее я работал итерациями, давая команды вида:

Приступай к реализации этапа 1 из файла docs/users/refactoring_plan.md. Отмечай прогресс по ходу выполнения в этом же файле.

AI начинал писать код, а я выступал в роли ревьюера: в warp можно установить режим «автоприёмки», но это не всегда подходит, особенно если задача сложная. По умолчанию все изменения в файлах нужно согласовывать: если что-то не устраивает, можно отредактировать вручную или дать уточняющие инструкции для LLM.

Шаг 3: Автотесты

Разработка проекта с множеством взаимосвязей внутри кодовой базы требует тщательного подхода к тестированию. С помощью LLM удобно писать unit-тесты для бекенда. Для моей задачи я также сделал покрытие e2e-тестами для сравнения идентичности работы старых и новых методов API, которые были написаны с ИИ.

Сейчас на проекте более 700 автотестов. Они стали моей страховкой и позволили проводить рефакторинг с уверенностью, что я ничего не сломал.

Результат

Чуть больше, чем за два месяца я получил:

• Единый репозиторий для бекенда и бота, без необходимости их связки через API

• Архитектуру модулей, построенную на принципах Clean Architecture: изоляция логики, разделение на сервисы, контроллеры, репозитории для взаимодействия с базой данных, валидаторы, DTO, интерфейсы и абстракции

• Оптимизированное взаимодействие между модулями (вместо медленных API-вызовов между сервисами теперь это внутренние вызовы через порты)

• Полное покрытие кода тестами

На этой основе уже можно было продолжать развивать продукт. Добавление новых функций пошло г��раздо проще: за несколько недель я запустил новую систему per-seat тарификации, прикрутил GPT в бота для постановки задач, закрыл старые баги, ну и в целом подчистил накопившийся беклог. Сейчас работать с проектом одно удовольствие, а скорость релизов возрасла в разы.

Фреймворки – ещё один способ управлять контекстом

Напомню, что одна из главных задач применяющего ИИ разработчика – минимизировать галлюцинации LLM. Поэтому для проектов, которые я начинаю с нуля, я использую фреймворки и инструменты, которые хорошо поддаются инструкциям и имеют четкую структуру. Это еще один отличный способ задать рамки при работе с ИИ.

Next.js

Недавно попалась на глаза статья Dead Framework Theory про то, что React – это уже не фреймворк, а платформа. Все LLM-ассистенты по дефолту генерят код на React – просто потому, что на нем написано 80% веба, на котором они учились. Поэтому Next.js – сейчас очевидный выбор, чтобы выжать из AI-агентов максимум при разработке веб-сервисов (особенно, если нужен SSR).

Payload CMS

Но под Next.js нужна админка для бека. Тут после энного количества экспериментов я остановился на Payload CMS – максимально гибкой и простой для быстрого запуска. Вот основные преимущества:

• Конфигурация в коде (Code-First): Схема данных, коллекции и конфигурация описываются кодом на TypeScript. Это обеспечивает версионирование и строгую типизацию.

• Автоматические миграции: Встроенные инструменты для генерации и управления миграциями базы данных через CLI упрощают изменение схемы данных.

• Встроенный ORM: Payload использует Drizzle ORM для работы с БД, предоставляя удобный и типизированный доступ к данным. ORM – это абстракция над базой данных, которая упрощает взаимодействие и делает код более предсказуемым и безопасным.

• REST и GraphQL API из коробки: Система автоматически генерирует REST и GraphQL API на основе схемы данных.

• Система хуков (Hooks): Позволяет встраивать собственную логику событий на разных этапах жизненного цикла документов (до и после сохранения, удаления, чтения).

• Расширяемая админ-панель на React: Админ-панель построена на React и полностью кастомизируется. Можно добавлять собственные React-компоненты для полей, представлений или целых страниц.

• Гибкая аутентификация и контроль доступа: Встроенная система аутентификации и гранулярного контроля доступа на уровне полей и операций (CRUD), которую можно расширять и адаптировать.

• Полная поддержка TypeScript: Обеспечивает строгую типизацию во всей системе, от конфигурации до API, помогая отлавливать ошибки на этапе разработки.

• Live Preview и Hot Reload: Позволяет видеть изменения контента в реальном времени на фронтенде и обеспечивает мгновенное обновление при разработке без перезагрузки сервера.

Shadcn Blocks

Для быстрого запуска фронтенда я открыл для себя ShadcnBlocks (на базе Shadcn UI). Это не просто библиотека компонентов, а набор готовых, стилизованных блоков (шаблонов).

Мой воркфлоу: я захожу в каталог блоков, выбираю подходящий (например, «Hero Section»), копирую код и вставляю его в Warp с инструкцией: «Сделай мне раздел на странице на основе этого кода, контент возьми отсюда». Не нужно верстать с нуля, при этом кастомизация с помощью Tailwind CSS ничем не ограничена.

Так, например, я сделал сайт для нового направления своего бизнеса, связанного с внедрением GenAI – panfilov.consulting.

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

В какой-то момент мне понадобилось быстро создать простую, но функциональную админку для управления кейсами студии. Мои поиски привели меня к Refine. Это оказался идеальный инструмент для таких задач: это фреймворк на базе React, специально созданный для быстрой сборки админ-панелей, дашбордов и внутренних инструментов.

Что меня в нем привлекло:

• Агностицизм к UI-фреймворкам: встроенная поддержка популярных библиотек, таких как Material UI, Ant Design, Chakra UI, Mantine, а также возможность использовать любой собственный дизайн или TailwindCSS.

• Автогенерация CRUD-интерфейсов: можно автоматически создавать CRUD-страницы на основе структуры данных.

• Встроенные компоненты: Refine идет с огромным количеством готовых решений. Например, в нем уже встроена авторизация (включая логин через Яндекс, который привязывается очень просто), управление правами доступа и ролями (администратор, менеджер), инвайты и так далее.

• Интеграция с данными: БД на PostgreSQL, подключение к S3-хранилищу для файлов и CDN для их раздачи.

В итоге из внутреннего инструмента для управления кейсами студии я запилил ещё один пет-проект: я прикрутил ИИ для сбора инфы по кейсам, сделал лендинг на Payload CMS – и получилась «Кейс-Платформа», ИИ-ассистент и админка для управления кейсами.

Выводы

Возвращение в разработку после 15-летнего перерыва могло стать болезненным опытом, но благодаря инструментам вроде Warp оно превратилось в увлекательное приключение. Это не просто ускорение работы – это фундаментальное изменение парадигмы. AI становится вашим напарником, младшим разработчиком, архитектором и DevOps-специалистом в одном лице.

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

Я не написал про ценообразование Warp, потому что как раз сейчас они его меняют и я еще не разобрался с новой тарифной сеткой. Единственное, что могу сказать: в предыдущей конфигурации тариф Lightspeed за $225 в месяц отбился у меня минимум х10, а скорее всего – х100. За 20 тысяч рублей в месяц я мог бы купить максимум 10-15 часов работы middle разработчика. С Warp же я получил результат, эквивалентный трудозатратам команды с бюджетом в несколько миллионов рублей.

Общие рекомендации по работе с LLM

• Управляйте контекстом. Качество работы модели напрямую зависит от полноты и релевантности предоставленной информации. Используйте все возможности для его уточнения: файлы с описанием проекта (warp.md), настраиваемые правила (Rules), внешние базы знаний (MCP Context7) и даже скриншоты для задач по фронтенду.

• Используйте разработку через спецификации (Spec-Driven Development). Для больших задач не пытайтесь всё сделать одним промптом. Сначала попросите AI составить подробный план и документацию, согласуйте их, и только потом приступайте к пошаговой реализации.

• Выбирайте модель под задачу. Экспериментируйте и подбирайте оптимальный вариант: используйте быстрые и дешевые модели (Claude Haiku) для простых правок, а мощные и «думающие» (GPT-5 High Reasoning) — для сложного рефакторинга и проектирования архитектуры.

• «Заземляйте» модель с помощью фреймворков. Инструменты с четкой структурой (Next.js, Payload CMS, Refine) и ORM задают рамки, в которых AI работает более предсказуемо и меньше галлюцинирует.

• Делегируйте, но контролируйте. Выступайте в роли архитектора или тимлида. Делегируйте AI рутину и написание boilerplate-кода, но всегда проводите ревью и не используйте «авто-приёмку» для сложных задач.

• Пишите автотесты. Это ваша страховка при рефакторинге и разработке. Попросите AI помочь с написанием unit- и e2e-тестов, чтобы быть уверенным, что новые изменения ничего не сломали.

Спасибо за внимание! Если было интересно меня читать, ещё я делюсь опытом у себя в Telegram-канале и всегда готов обсудить с вами вопросы там или здесь в комментариях.