AI дал бизнесу суперсилу. Теперь осталось не утонуть в одном JS-файле
Сейчас тихо, но заметно происходит важная штука: приложения всё чаще пишут не разработчики. Юристы, консультанты, врачи, логисты, комплаенс-специалисты, эксперты по вину — люди, которые никогда не делали коммит в Git, садятся в Cursor или Claude Code и собирают рабочие прототипы.
Я вижу это у знакомых из совсем разных областей. И меня не покидает ощущение, что граница между «человек из бизнеса» и «разработчик» просто смещается.
Прототипы иногда действительно впечатляют. Дизайн — аккуратный, продуктовая логика — живая. Потому что человек собирает не абстракцию, а то, что своими руками делает каждый день. У него нет проблемы «разобраться в домене». Он сам — домен.
Программист, начинающий похожий проект, почти всегда что-то упрощает. Не потому что ленится — просто не знает, где в реальной работе настоящие боли. А доменный эксперт наоборот: знает слишком много, и продукт сразу получается точным. Иногда даже слишком точным для первой итерации.
Приложение работает. Клиентам показали — одобрили. Инвестору запустили — впечатлился. Партнёр попросил доступ — зашёл и ничего не сломал.
Открываешь код:
Это не плохо. Это типично. Прототип для того и прототип — на этом этапе разбираться с архитектурой рано, и никто это и не ожидает. Важно другое: понять, что вы делаете именно прототип, и что у него есть своя граница.
Между ними — вполне конкретная инженерная работа:
Если проект начал жить, в какой-то момент его придётся перевести из первого состояния во второе. Третье приходит позже — часто уже после первых реальных денег.
Если вы не разработчик, но хотите собрать веб-приложение, которое потом можно будет развивать, — я бы брал такой набор:
На старте ничего сложнее этого списка я бы не брал. Docker и свой сервер на первой неделе — это попытка играть в «энтерпрайз-инженера» до того, как появились первые десять пользователей.
Что делать, если прототип уже есть, но внутри — мешанина, и переписывать его руками вы не умеете.
Создайте новую пустую папку для проекта. Внутри создайте подпапку refs/. Переместите туда всё, что было сделано прошлой версией AI: старый код, промпты, скриншоты, описания фич. Ничего не чистите — это референс, а не финальный проект.
Рядом в refs/ положите файл REWORK.md. Это инструкция для агента, что он должен сделать с вашим прототипом. Текст ниже универсальный, под любой домен. Копируйте целиком, ничего не нужно дописывать.
my-new-app/
└── refs/
├── old-prototype/ # everything you built before
├── screenshots/
└── REWORK.md # the file below, saved as-is# REWORK.md This folder (refs/) contains my current prototype. It was built with AI tools over several iterations. Treat everything inside refs/ as a reference, not as the final code. You are allowed to ignore, rewrite, or restructure any of it. ## Goal Rebuild this prototype as a clean, maintainable web application. The goal is not a new design or new features. The goal is a proper structure I can keep developing without fear of breaking everything. ## Stack - Next.js (App Router) - TypeScript - Tailwind CSS - shadcn/ui for UI components, where it makes sense - SQLite for the database to start with - GitHub as the source of truth - Vercel for deployment Do not introduce Docker, Kubernetes, microservices, or custom CI/CD pipelines. If any of that becomes necessary later, we will add it then. ## How the code must be organized - Split the UI into small, reusable components. One component per file. - Keep pages thin. Pages assemble components; they do not contain business logic. - Move all business logic into a /services folder. Logic must not live inside React components. - Create a data layer under /lib/db. All database access goes through this layer only. UI and services never talk to the database directly. - Keep TypeScript types in one place per domain. Do not redefine the same type in multiple files. - No single file should grow beyond ~300 lines. If it does, split it. ## Data - Use a real database from day one. SQLite via Prisma or Drizzle is fine. - Define the entities clearly. If the prototype implies entities that are not explicit, name them and propose a schema. - Do not store important data only in React state or in local JSON files. ## Auth and roles - Start with simple email + password authentication, or magic-link flow. - Support at least two roles: admin and user. Add more only if the prototype already needs them. - Protect admin routes on the server, not only by hiding them in the UI. ## Admin area - Create a minimal admin area inside the same Next.js app under /admin. - It must let me view, create, edit, and delete the main entities of the product without touching the database directly. - Keep it simple: tables and forms. No dashboards, no charts, no decoration. ## What to keep from the prototype - The product flows. How the user moves through the app step by step. - The domain terminology and naming. - Any UI decisions that clearly work well. ## What to discard from the prototype - Copy-pasted blocks of code. - Inline styles mixed with logic. - Anything that looks like it was patched more than twice. - Single files longer than ~500 lines. ## Hard rules - Do not put everything in one file. - Do not mix UI and business logic. - Do not invent new frameworks or exotic libraries. - Do not optimize anything I have not explicitly asked you to optimize. - Do not add features that are not in the prototype. New features will be requested separately. ## Workflow for every task 1. Read relevant files in refs/. 2. Re-read this REWORK.md. 3. Propose a short plan before writing code. 4. Wait for approval. 5. Implement one area at a time. Small, reviewable steps. 6. After each step, tell me what changed and why.
После этого откройте папку проекта в Cursor или VS Code. Для VS Code нужно поставить плагин Claude (Anthropic) и залогиниться. В Cursor он уже встроен.
В чате напишите короткий промпт — агент сам возьмёт детальные инструкции из REWORK.md:
Read refs/REWORK.md first. It describes exactly what I want. Then read everything else inside refs/ — that is my current prototype. Before writing any code: 1. Produce a short plan: folder structure, main components, services, data layer, routes, and database schema. 2. List what you will keep from the prototype and what you will rebuild. 3. Wait for my approval. Only after I approve — begin implementing, one area at a time.
Это одна команда, но она превращает хаос в структуру — при условии, что у агента есть, на что опираться. Refs/ и REWORK.md как раз и есть эта опора.
Прототип остаётся вашим. Его никто не забирает и не переписывает «потому что я лучше знаю».
Но в какой-то момент проект перестаёт помещаться в одной голове и одном файле. Сигналы простые: AI чинит одно и ломает другое; вы боитесь трогать код, который работает; появились первые реальные пользователи, и ошибки в проде начинают стоить денег; пора подключать базу, роли, админку и нормальный деплой, а как — неясно.
На этом шаге я обычно и помогаю: разобрать существующий код, вытащить то, что работает, аккуратно перенести в нормальную структуру, подключить базу, авторизацию и деплой. Не переписать всё с нуля — это почти всегда лишнее. А собрать из того, что у вас уже есть, проект, с которым дальше не страшно работать.
Мир сейчас делится не на «разработчиков» и «бизнес». Он делится на тех, кто умеет собрать прототип сам, и тех, кто умеет превратить прототип в систему. Обе способности важны, и обе нужны.
Эта статья создана в гибридном формате человек + ИИ. Я задаю направление и тезисы, ИИ помогает с текстом, я редактирую и проверяю. Ответственность за содержание — моя.