AI дал бизнесу суперсилу. Теперь осталось не утонуть в одном JS-файле

Сейчас тихо, но заметно происходит важная штука: инструментами разработчиков всё чаще пользуются не разработчики. Юристы, консультанты, врачи, логисты, комплаенс-специалисты, эксперты по вину — люди, которые никогда не делали коммит в Git, садятся в Claude Code или Cursor и получают рабочий результат. Весной это были в основном прототипы приложений. Сейчас — отчёты, презентации, разборы договоров, чистка таблиц, регламенты. Приложения оказались меньшей частью истории.

Я вижу это у знакомых из совсем разных областей. Граница между «человек из бизнеса» и «разработчик» не исчезает, но смещается туда, где её раньше не было.

Что получается — часто получается хорошо

Результаты иногда действительно впечатляют. Потому что человек делает не абстракцию, а то, что своими руками делает каждый день. У него нет проблемы «разобраться в домене». Он сам — домен.

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

Что случилось с «одним JS-файлом»

Весной типичная картина была такая: приложение работает, клиенты довольны, а в коде — всё в одной куче, авторизация «типа логин», одна и та же функция переписана десять раз. Я тогда предлагал приём с папкой refs/ и файлом REWORK.md, чтобы агент пересобрал этот хаос в структуру.

Приём по-прежнему работает, но нужен всё реже. Агенты научились делать это сами: сначала план, потом структура, потом код небольшими шагами. Если сегодня у вас получается один файл на 2800 строк, дело почти наверняка не в модели, а в том, как вы её попросили.

Зато выросла другая проблема, и она касается не только кода. Выглядит так: один бесконечный чат, в котором вперемешку лежат черновик квартального отчёта, три версии коммерческого предложения и замечания к договору. Каждый запрос начинается с «напомню, мы компания такая-то». Результат каждый раз чуть другой. Через месяц никто не может сказать, какая версия — настоящая.

Это тот же «один JS-файл», просто в документах. Причина та же — нет структуры и нет опоры, модели не на что ссылаться, кроме последнего сообщения. И лечение то же, о нём ниже.

Что я рекомендую бизнесу

За полгода у меня сложилось пять правил. Они выросли не из теории, а из своих проектов: из AI-направления в Едином окне, из Open Cradle, из собственных ошибок. Каждое я уже описывал отдельно, здесь — в применении к бизнесу.

1. Направляйте агента на одну названную, дорогую задачу

Не «внедрить AI в компании». Не «попробовать агентов». Одна задача, у которой есть имя и цена в часах: «подготовка еженедельного отчёта для собственника съедает четыре часа понедельника у двух людей». Вот её и убираем.

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

Задачу ищут не в стратегии, а в жалобах. Спросите сотрудников, что съедает их неделю. Тот, кто жалуется, обычно и описывает задачу точнее всех.

2. Контекст живёт в файлах, а не в чате

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

Минимальный набор: папка на задачу, внутри подпапка refs/ с исходниками (прошлые отчёты, шаблоны, договор контрагента, выгрузки) и короткий файл COMPANY.md с описанием компании и правил. Пример такого файла — ниже, в роадмапе.

Когда папок становится много, это уже база знаний. Я свою веду в Obsidian и подключил к ней Claude Code через Ars Contexta, но для начала хватает обычных папок с файлами.

3. Агент предлагает — решаете вы. И успех исполнения не равен проверке результата

Это главное правило, и оно тяжелее всех даётся. В Open Cradle я разделил работу агента на четыре отдельные записи: что агент предлагает, что ему разрешили, что инструмент вернул и держится ли результат по независимому источнику. Сделал это кодом, чтобы обходных путей не осталось, — писал об этом в статье про runtime. Для бизнеса достаточно той же логики в голове и в промптах:

• →Сначала план и вопросы, потом работа. Агент не начинает делать, пока вы не подтвердили, что он правильно понял.
• →Каждая цифра — с источником: из какого файла, из какой колонки. Вывод, а не факт — помечен как вывод.
• →Там, где агент не уверен, он пишет «нужна проверка юриста/бухгалтера», а не угадывает.
• →Готовый файл — не результат. Результат — когда вы или ваш специалист его открыли и проверили.

У агентов есть известный антипаттерн: когда тест падает, агент правит тест, а не код, потому что его цель — «сделать зелёным». В бизнесе это выглядит так: цифры не сходятся — агент подгоняет формулировку, чтобы сошлись. Я разбирал это в статье про лечение тестов. Антидот один: если что-то не сходится, агент обязан сначала объяснить, почему, и только потом трогать.

4. Границы: доступ к папке, а не к компьютеру

Я до сих пор не даю ни одному агенту доступ ко всему компьютеру. Даже любимому. Отдельная папка на задачу — да. Папка Downloads — нет. Почта и календарь — только чтение, пока не понятно, зачем нужно больше. Писал об этом в «Отдыхе и границах», и с тех пор только утвердился.

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

5. Команда инструментов, а не один любимый

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

И последнее, уже не правило, а позиция. AI — экзоскелет, а не экскаватор. Он делает сотрудника сильнее, если сотрудник остаётся в конструкции. Внедрять агентов, чтобы сократить тех, кто умеет ими пользоваться, — стрелять себе в ногу. Об этом — «ИИ как экзоскелет».

Роадмап: как бизнесу освоить агентов за три месяца

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

Этап 0. Одна задача в чате — первая неделя

Инструмент: Claude в браузере, функция «Проекты». Никакого терминала.

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

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

Этап 1. Папка, refs/ и COMPANY.md — вторая и третья недели

Инструмент: Claude Code в терминале или в VS Code, либо Cursor. Это агент, который работает с файлами в папке: Word, Excel, PDF, PowerPoint, выгрузки, заметки. Код тут не нужен.

Структура папки: корень с файлом COMPANY.md, подпапка refs/ с исходниками, результаты — в корень. Готовые промпты для этого этапа — ниже. Начните с той же задачи, что на этапе 0, потом добавьте вторую.

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

Этап 2. Повторяемый процесс — второй месяц

Теперь задача делается не промптом, а инструкцией в файле. Напишите (вместе с агентом) файл вида weekly-report.md: откуда брать данные, какой образец, что проверять, кому отправлять. Промпт сжимается до «сделай еженедельный отчёт по weekly-report.md».

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

Пройден, когда: один процесс делается по инструкции человеком, который его не настраивал.

Этап 3. Свой инструмент — третий месяц и дальше

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

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

Готовые промпты для этапа 1

Они написаны под Claude Code, но работают и в проектах Claude.ai, если прикрепить те же файлы.

COMPANY.md — контекст, который пишется один раз

# COMPANY.md

Компания: ООО «Пример», оптовая торговля стройматериалами, 40 сотрудников,
клиенты — строительные компании и розничные сети в трёх регионах.

Как мы пишем: коротко, по делу, без маркетинговых прилагательных.
Обращение к клиенту — на «вы». Цифры — всегда с источником.
Валюта — рубли, даты — в формате ДД.ММ.ГГГГ.

Чего не делаем: не обещаем сроки без подтверждения склада,
не называем цены без ссылки на действующий прайс в refs/.

Люди: Иванова — коммерческий директор (согласует КП),
Петров — главбух (согласует всё, где есть НДС).

Правила работы:
- Сначала план и вопросы, потом результат. Жди подтверждения.
- Каждая цифра — с указанием файла и колонки, откуда взята.
- Если чего-то не знаешь о компании — спроси, а не придумывай.
- Если что-то не сходится — сначала объясни, почему, потом предлагай.

Положите этот файл в корень папки и начинайте любой промпт со слов «Прочитай COMPANY.md». Пример учебный, подставьте своё.

Отчёт из выгрузок

Прочитай COMPANY.md.
В refs/ лежат выгрузки продаж за сентябрь (sales_2026-09.xlsx) и август
(sales_2026-08.xlsx), а также прошлый отчёт report_2026-08.docx — это
образец структуры и тона.

Задача: подготовить отчёт за сентябрь для совета директоров.

Сначала:
  1. Опиши, какие колонки ты нашёл в выгрузках и как их понял.
  2. Задай вопросы по данным, которые выглядят странно (пропуски, выбросы).
  3. Предложи структуру отчёта — разделы и ключевые цифры.
Дождись моего подтверждения.

Потом собери report_2026-09.docx по той же структуре, что и прошлый.
Все цифры — с указанием, из какого файла и какой колонки они взяты.
Там, где ты делаешь вывод, а не констатируешь факт, — пометь это явно.

Презентация из текста

Прочитай COMPANY.md.
В refs/ лежит описание нового продукта (product_brief.md), прайс
(price_2026-10.xlsx) и прошлая презентация для клиентов (deck_2025.pptx) —
это образец оформления, не содержания.

Задача: презентация для встречи с розничной сетью, 10–12 слайдов, 20 минут.

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

Потом сделай deck_retail_2026-10.pptx в стиле прошлой презентации.
На слайде — одна мысль, не больше 30 слов. Цифры — только из прайса и брифа.
Отдельно, в speaker_notes.md, напиши, что говорить к каждому слайду.

Проверка договора

Прочитай COMPANY.md.
В refs/ лежит договор поставки от контрагента (contract_draft.docx) и наш
типовой договор (our_template.docx).

Задача: подготовить меня к переговорам по этому договору.

Сделай contract_review.md с тремя разделами:
  1. Таблица отличий от нашего типового договора: пункт, что у них,
     что у нас, в чью пользу разница.
  2. Условия, которые несут для нас риск: что именно может пойти не так
     и сколько это может стоить. Отдельно отметь штрафы, сроки оплаты,
     односторонний отказ, ответственность за качество.
  3. Список вопросов контрагенту и предлагаемые формулировки.

Не переписывай договор целиком. Если в чём-то не уверен — напиши
«нужна проверка юриста», а не угадывай.

Последняя строка важна. Агент хорошо находит расхождения и формулирует вопросы, но решение по договору на миллионы принимает юрист, а подпись под отчётом ставит бухгалтер. Агент готовит материал, человек отвечает.

Инструкция для повторяемого процесса (этап 2)

# weekly-report.md

Когда: каждый понедельник до 10:00.
Данные: выгрузка из 1С за прошлую неделю — файл refs/weekly/YYYY-MM-DD.xlsx.
Образец: последний отчёт в reports/.
Проверить перед сборкой: сумма по колонке «Отгрузки» совпадает с итогом
в выгрузке; нет недель с нулём — если есть, спросить, а не писать ноль.
Результат: reports/weekly-YYYY-MM-DD.docx + три строки резюме в чат.
Не делать: не менять структуру отчёта без явной просьбы.

Про сайт: стартовый промпт и как им пользоваться

Если на этапе 3 вы дошли до собственного приложения, вот с чего начинать. Стек я бы брал тот же, что и весной: Next.js, TypeScript, Tailwind, SQLite или managed PostgreSQL, GitHub, Vercel. Docker, свой сервер и CI/CD — позже, когда появятся первые десять пользователей. Но теперь этот стек не нужно объяснять: достаточно одного промпта в пустой папке.

Я не разработчик. Хочу собрать внутренний инструмент для [одно предложение:
кто пользуется и что делает]. Пользователей — до 20, все из одной компании.

Стек: Next.js (App Router), TypeScript, Tailwind CSS, shadcn/ui, SQLite через
Drizzle, деплой на Vercel, код в GitHub. Ничего сложнее не добавляй.

Сначала:
  1. Задай мне вопросы про задачу, пока не поймёшь её полностью.
  2. Предложи план: страницы, сущности в базе, роли пользователей.
  3. Создай файл CLAUDE.md с правилами проекта: структура папок, запрет
     на бизнес-логику в компонентах, один компонент — один файл, тесты
     для всего, что считает деньги или даты.
Дождись подтверждения.

Потом делай по одной странице за раз. После каждой — коммит в GitHub
и короткое описание, что изменилось и как это проверить руками.

Как пользоваться этим эффективнее, чем весной:

• →Одна фича — одна сессия. Закончили, закоммитили, закрыли. Длинная сессия с десятью задачами — главный источник хаоса.
• →Файл CLAUDE.md в корне — это COMPANY.md для кода. Агент читает его при каждом запуске. Всё, что вы повторяете агенту дважды, — туда.
• →Просите тесты на то, что считает деньги, даты и доступ. И не разрешайте править тест, пока агент не объяснил, почему он упал.
• →Коммит после каждого шага. GitHub — ваша страховка: любой шаг можно откатить, даже если вы не знаете, как устроен Git.
• →Деплой с первого дня. Ссылка на Vercel, которую видят коллеги, дисциплинирует лучше любого плана.

Если прототип у вас уже есть и внутри него тот самый один файл — приём с папкой refs/ по-прежнему работает: новая пустая папка, старый код в refs/, рядом REWORK.md, и первый промпт: «Прочитай refs/REWORK.md, потом всё остальное в refs/, предложи план и жди подтверждения».

Когда звать разработчика — и в какой роли

Инструмент остаётся вашим. Его никто не забирает и не переписывает «потому что я лучше знаю».

Но в какой-то момент проект перестаёт помещаться в одной голове. Сигналы простые: агент чинит одно и ломает другое; вы боитесь трогать то, что работает; появились реальные пользователи, и ошибки начинают стоить денег; нужны роли, интеграции с учётной системой, нормальный деплой, а как — неясно. Отдельный сигнал: данные, которые по договору или закону не могут уйти в облако. Это уже про закрытый контур.

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

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

Разработчикам тоже непросто. Рынок найма превратился в ритуал, который я описывал в «Рынок найма — это зомби», а большие компании застряли в процессах 2010-х — об этом «Enterprise отстал». Сильные инженеры всё чаще ищут не вакансию, а задачу с реальными пользователями и долю в результате. У вас такая задача есть. Это обмен, в котором обе стороны приносят то, чего нет у другой.

Что это меняет практически: разработчик приходит не «починить код», а на час разговора о том, что реально съедает неделю вашей команды и кто за это платит. Один законный исход такого разговора — пока это не строить, письменно и с причинами. Другой — договориться о ролях и долях и дальше идти вместе. Так я сейчас и работаю: разобрать существующее, вытащить то, что работает, перенести в структуру, подключить данные, доступ и деплой — и остаться в проекте, а не сдать его по акту.

В заключение

Весной я писал, что мир делится на тех, кто умеет собрать прототип, и тех, кто умеет превратить его в систему. Это по-прежнему так, но граница сдвинулась. Собрать теперь умеет почти каждый. Редким навыком стало другое: выбрать одну задачу, дать агенту контекст, поставить границу и не поверить результату, пока его не проверили.

Этому можно научиться за три месяца. Роадмап выше — для этого.

Есть задача с реальными пользователями и нужен инженер рядом, а не на подряде? Написать