# Бизнес-инструмент без разработчика: как ставить задачу агенту

Свой внутренний сервис я собрал в одиночку, когда только учился. Показываю, как сегодня ставится задача на новую функцию: не промт за промтом, а разговор, в котором агент сам задаёт уточняющие вопросы и предлагает решения, до которых я бы не додумался.

// масштаб

## Внутренний сервис, который я собрал, когда учился

В одном из роликов я уже показывал свой внутренний корпоративный сервис — мы делали его для себя одним из первых. Это набор инструментов, которые помогают мне и команде меньше возиться со стандартной рутиной.

Собирал я его в одиночку, и это был буквально мой тестовый проект, когда я учился вайб-кодингу.

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

карточка 1 — метка «кто собирал» / значение «один» / капшен «тестовый проект во время учёбы»; карточка 2 — метка «чужое решение той же задачи» / значение «15 $» / капшен «и меня оно не устроило»; карточка 3 — метка «порог, после которого дорабатываем» / значение «200+ чатов» / капшен «раньше не трогаем». Ключевая — #1

// точка ноль

## Я больше не пишу промт за промтом

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

Сейчас, создавая новую функцию, я вообще не иду этим путём. Я примерно понимаю, чего хочу, и закидываю это в улучшатель промтов — он добавит то, чего я не дописал.

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

врезка `// ПРАВИЛО`: текст «Не улучшай промт вручную. Опиши задачу как понимаешь и отдай улучшателю — он допишет то, о чём ты не подумал.»

// метод 1

## Он нашёл вариант, до которого я бы не додумался

Дальше происходит интересное. Агент идёт искать, как такие задачи решают другие, и приносит варианты.

В моём случае он нашёл решение, о котором я вообще никогда не слышал. Показывает: вот так это устроено у людей, вот за 15 $ можно собрать и поставить на хостинг.

Я посмотрел — мне не понравилось. Но важно другое: я увидел чужой подход до того, как начал делать свой.

строка 1 — «пишу промт → смотрю результат → пишу следующий»; строка 2 — «описываю задачу → улучшатель дописывает → агент приносит варианты». подпись строки 1 — «как было»; подпись строки 2 — «как сейчас»

// метод 2

## Обсуждение и разработка живут в одном месте

Мы специально делаем это всегда в одном проекте. Обсуждение того, как будем создавать, и сама разработка — в рамках единого пространства.

Он сразу показывает концепцию системы, модель данных, что за чем идёт. И тут же выдаёт уточняющие вопросы.

«ОПИСАЛ ЗАДАЧУ» → «КОНЦЕПЦИЯ И МОДЕЛЬ» → «УТОЧНЯЮЩИЕ ВОПРОСЫ» → «РАЗРАБОТКА». Ключевая — #3

// центральный блок

## Он сам придумал, каким должен быть отчёт

Вот момент, ради которого я это показываю. Он сам предложил структуру: столько-то чатов позитивных, один нейтральный. Мы об этом вообще не говорили — он придумал это сам, исходя из задачи.

Дальше идут вопросы, на которые надо ответить, и он сразу переходит к следующему шагу. Спрашивает про существующего бота — будем использовать его или новый. Спрашивает, кто получатель отчётов; у нас в файле настроек уже есть рабочий чат, туда и отправлять.

Я отвечаю и говорю: идём дальше. И только теперь переходим к разработке.

Важный момент: у меня уже открыт проект, который разработан раньше, и добавлены нужные ключи доступа. Мы делаем новую функцию поверх существующего инструмента, а не архитектуру с нуля. Даже если у тебя до этого была просто оболочка с минимальной логикой — этого достаточно, чтобы строить дальше.

- 01 «Описал как понимаю» — метрика «хаотично» — своими словами, без структуры
- 02 «Улучшатель» — метрика «шаг первый» — дописывает то, что я упустил
- 03 «Поиск решений» — метрика «до начала работы» — агент приносит чужие варианты
- 04 «Вопросы» — метрика «отвечаю коротко» — он спрашивает про бота, получателя, формат
- 05 «Разработка» — метрика «не с нуля» — делаем поверх готового проекта

// метод 3

## Я говорю с ним как с разработчиком

Я с ним много говорю — примерно так же, как разговаривал бы с разработчиками, если бы делал это чужими руками.

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

И такие мелочи, которые всплывают в разговоре, потом оказываются самыми полезными в работе.

// wow-эпизод

## Если через полгода чатов станет 200 — тогда и добавим

Отдельно про то, чего делать не надо. Иногда, особенно сейчас, большая функция за один заход оказывается для агента неподъёмной.

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

У меня чатов действительно больше двухсот — и именно поэтому часть решений нужна мне сейчас, а не «на будущее».

врезка `// ПРАВИЛО`: текст «Не проси агента предусмотреть всё сразу. Договорись о пороге, после которого доработка станет нужна, и вернись к ней тогда.»

// инструмент

## Справедливый вопрос: в какой программе работать

Справедливый вопрос: нужен ли специальный редактор? Отвечаю: разницы нет.

Можно пользоваться VS Code, можно любой другой средой. Инструмент здесь не решает — решает то, как ты ставишь задачу.

Что действительно нужно заранее: открытый проект и добавленные ключи доступа к сервисам. Без них разговор упрётся в технику вместо задачи.

, , ,

// дашборд

## Что изменилось в постановке задачи

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

строки «Показатель → Значение»: формулировка задачи → через улучшатель, не руками; поиск решений → агент приносит чужие варианты; уточнения → он спрашивает, я отвечаю; структура отчёта → предложил сам; база для работы → существующий проект, не с нуля; спорные доработки → откладываем до порога

// метод 4

## Инструменты делаются под свою рутину, а не под рынок

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

Сокращатель ссылок появился не потому, что таких сервисов нет. Они есть. Он появился, потому что мне нужна была своя статистика в своём месте, а не в чужом кабинете.

Отсюда простое правило: инструмент имеет смысл, когда закрывает конкретно твою повторяющуюся боль. Если чужое решение за 15 $ её закрывает — бери чужое.

// возражения

## Я не разработчик, у меня нет проекта

- «~~У меня нет готового проекта, чтобы строить поверх~~» → Достаточно самой простой оболочки с минимальной логикой. Дальше всё наращивается поверх — начинать с чистого листа не обязательно.
- «~~Я не смогу поставить задачу технически грамотно~~» → Я и не ставлю её технически. Я описываю своими словами, а улучшатель дописывает то, чего не хватает.
- «~~Проще купить готовое~~» → Иногда да — я сам смотрел решение за 15 $. Но оно мне не подошло, и в этом весь смысл: своё делают тогда, когда чужое не закрывает задачу.

// что дальше

## Опиши задачу словами и отдай улучшателю

Ты дочитал до конца — значит, вопрос был не в том, каким инструментом писать код. Вопрос в том, как поставить задачу. Описал своими словами, улучшатель дописал, агент принёс чужие решения, задал вопросы — и только потом началась работа.

Один вопрос напоследок. Ответь себе одним предложением: какая рутина в твоей работе повторяется так часто, что под неё стоит собрать свой инструмент? Назови её конкретно — с этого и начинается разговор с агентом. Я читаю.

1 — человек собрал · 15 $ — чужое решение · 5 — шагов до кода · 200+ — порог доработки

---

Источник: https://localhost:3000/m/biznes-instrument-bez-razrabotchika-kak-stavit-zadachu-agentu