AI Gave Business a Superpower. Don't Drown in One JS File

Rewritten in October 2026

The first version came out in April and was about one pain: a domain expert builds an app with AI, it works, and inside there is one 2,800-line JS file. Six months later that pain has mostly dissolved. The current generation of agents plans on its own, splits code into files on its own and writes tests on its own, if you don't rush it. The bottleneck moved from the code into the person's head: which task to point the agent at, what context to give it, where to draw the boundary and how to check the result.

So the text has been rewritten almost entirely. It is now about what I recommend to business, with a roadmap for learning to work with agents and ready-to-use prompts for reports, decks and contracts. Websites get a short section: a starter prompt and how to use it. The REWORK.md file from the old version is still available for download; it is still useful if you already have a messy prototype.

Something quiet but important is happening: developer tools are increasingly used by people who are not developers. Lawyers, consultants, doctors, logistics people, compliance specialists, wine experts — people who have never made a Git commit — sit down in Claude Code or Cursor and get a working result. In spring those were mostly app prototypes. Now it is reports, presentations, contract reviews, spreadsheet clean-ups, internal procedures. Apps turned out to be the smaller part of the story.

I see it among friends and acquaintances from very different fields. The line between 'business person' and 'developer' is not disappearing, but it is moving to places where it never was.

What they build is often genuinely good

The results sometimes impress. Because the person is not building an abstraction — they are building what they do with their own hands every day. They don't have the 'understand the domain' problem. They are the domain.

A programmer starting a similar task almost always simplifies something. Not out of laziness — they just don't know where the real pains live. A domain expert is the opposite: they know so much that the result comes out precise right away.

What happened to the 'one JS file'

In spring the typical picture was this: the app works, clients are happy, and in the code everything sits in one pile, auth is 'sort of like a login', the same function is rewritten ten times. Back then I suggested the refs/ folder and REWORK.md trick, so the agent could rebuild that chaos into a structure.

The trick still works, but it is needed less and less. Agents learned to do it themselves: plan first, then structure, then code in small steps. If today you end up with one 2,800-line file, the problem is almost certainly not the model but how you asked.

A different problem grew instead, and it is not only about code. It looks like this: one endless chat where a draft of the quarterly report, three versions of a commercial proposal and comments on a contract all sit together. Every request starts with 'as a reminder, we are a company that…'. The result is slightly different every time. A month later nobody can say which version is the real one.

That is the same 'one JS file', just in documents. The cause is the same — no structure and nothing to lean on; the model has nothing to refer to except the last message. And the cure is the same, see below.

What I recommend to business

Over six months I arrived at five rules. They did not grow out of theory but out of my own projects: the AI track at Kyrgyz Single Window, Open Cradle, my own mistakes. I have written about each one separately; here they are applied to business.

1. Point the agent at one named, expensive task

Not 'introduce AI in the company'. Not 'try out agents'. One task with a name and a price in hours: 'preparing the weekly report for the owner eats four hours of Monday for two people'. That is what we remove.

The only KPI I know how to defend: hours on a named process, before and after. Everything else — number of deployments, coverage percentage, share of processes 'with AI' — measures the spread of a technology, and the spread of a technology helps nobody. I went through this in detail in The Orange Problem.

You find the task in complaints, not in strategy. Ask your people what eats their week. The one who complains usually describes the task more precisely than anyone.

2. Context lives in files, not in the chat

An agent works with a folder. Everything in the folder it can read and re-read. Everything you said in the chat lives until the end of the session. So the company, the style, the rules, the samples go into files. Once.

The minimal set: one folder per task, a refs/ subfolder inside with the sources (past reports, templates, the counterparty's contract, exports) and a short COMPANY.md describing the company and the rules. An example of that file is below, in the roadmap.

When there are many folders, that is already a knowledge base. I keep mine in Obsidian and connected Claude Code to it through Ars Contexta, but plain folders with files are enough to start.

3. The agent proposes, you decide. And a successful run is not a verified result

This is the main rule, and the hardest to live by. In Open Cradle I split the agent's work into four separate records: what the agent proposes, what it was allowed to do, what the tool returned, and whether the result holds against an independent source. I did it in code, so no bypass remains — see the runtime post. For business, the same logic in your head and in your prompts is enough:

Plan and questions first, work second. The agent does not start until you confirm it understood correctly.
Every number comes with a source: which file, which column. A conclusion, not a fact, is marked as a conclusion.
Where the agent is unsure, it writes 'needs a lawyer's / accountant's check' instead of guessing.
A finished file is not the result. The result is when you or your specialist opened it and checked it.

Agents have a known anti-pattern: when a test fails, the agent fixes the test rather than the code, because its goal is 'make it green'. In business it looks like this: the numbers don't add up, so the agent adjusts the wording until they do. I covered it in the post on fixing tests. There is one antidote: if something doesn't add up, the agent must first explain why, and only then touch anything.

4. Boundaries: access to a folder, not to the computer

I still don't give any agent access to my whole computer. Not even my favourite one. A separate folder per task — yes. The Downloads folder — no. Mail and calendar — read-only, until it is clear why more is needed. I wrote about this in Rest and Boundaries, and I have only grown more convinced since.

For business I will add: passwords, keys, customers' personal data and anything that by contract must not leave your perimeter do not go into the agent's folder. If a task needs such data, that is a conversation about an on-premise setup, and it is a separate one.

5. A team of tools, not one favourite

Not every task needs the strongest model. Planning, a contract review, the structure of a report — strong model. Reformatting a hundred rows, renaming fields, cleaning a spreadsheet — a good-enough, cheap one. I got there through my own subscription bill and described it in The Multi-Agent Developer. For business the conclusion is the same: AI work is not finding the best agent, it is assembling a small team of roles.

And one last thing, a position rather than a rule. AI is an exoskeleton, not an excavator. It makes an employee stronger if the employee stays inside the construction. Deploying agents in order to cut the people who know how to use them is shooting yourself in the foot. See AI as an Exoskeleton.

Roadmap: how a business can learn agents in three months

This is not a course and not a certification. It is the order I would follow myself if I were starting from zero today without a programmer. Each stage has a 'passed' criterion — until it is met, the next stage is premature.

Stage 0. One task in the chat — week one

Tool: Claude in the browser, the Projects feature. No terminal.

Pick one task by rule number one. Create a project, upload three to five files into it: past results of this task and everything they relied on. In the project instructions write five sentences about the company and the style. Do the task three times during the week, each time starting by asking for a plan.

Passed when: you sent the third result to colleagues without rework, and you can say how many hours it saved.

Stage 1. A folder, refs/ and COMPANY.md — weeks two and three

Tool: Claude Code in the terminal or in VS Code, or Cursor. It is an agent that works with the files in a folder: Word, Excel, PDF, PowerPoint, exports, notes. No code needed.

Folder structure: COMPANY.md at the root, refs/ with the sources, results at the root. The ready prompts for this stage are below. Start with the same task as in stage 0, then add a second one.

Passed when: three different tasks have been done from folders, and every number in every result points to a source.

Stage 2. A repeatable process — month two

Now the task is done not by a prompt but by an instruction in a file. Write (together with the agent) a file like weekly-report.md: where the data comes from, what the sample is, what to check, whom to send it to. The prompt shrinks to 'do the weekly report per weekly-report.md'.

Connections appear at this stage too: spreadsheets, mail, calendar, CRM through ready connectors. Read-only first. Write access after you have lived a month on read-only and never once regretted it.

Passed when: one process is run from the instruction by a person who did not set it up.

Stage 3. Your own tool — month three and beyond

Once a process has settled, it sometimes becomes clear that it needs an app rather than a document: a form, a table, access for three colleagues. Now, and only now — a website or an internal tool. The starter prompt and the rules are in the next section.

Passed when: someone other than you uses the tool, and you understand where what you can maintain yourself ends. That boundary is the subject of the end of this post.

Ready prompts for stage 1

They are written for Claude Code but also work in Claude.ai projects, if you attach the same files.

COMPANY.md — the context you write once

# COMPANY.md

Company: Example Ltd, wholesale building materials, 40 employees,
customers are construction companies and retail chains in three regions.

How we write: short, to the point, no marketing adjectives.
Numbers always come with a source. Currency is EUR, dates are DD.MM.YYYY.

What we don't do: we don't promise delivery dates without stock confirmation,
we don't quote prices without a reference to the current price list in refs/.

People: Ivanova — commercial director (approves proposals),
Petrov — chief accountant (approves anything involving VAT).

Working rules:
- Plan and questions first, result second. Wait for confirmation.
- Every number names the file and column it came from.
- If you don't know something about the company — ask, don't invent.
- If something doesn't add up — explain why first, then propose.

Put this file in the root of the folder and start every prompt with 'Read COMPANY.md'. The example is a placeholder; fill in your own.

A report from exports

Read COMPANY.md.
In refs/ there are sales exports for September (sales_2026-09.xlsx) and
August (sales_2026-08.xlsx), and last month's report report_2026-08.docx —
that is the model for structure and tone.

Task: prepare the September report for the board.

First:
  1. Describe which columns you found in the exports and how you understood them.
  2. Ask about anything in the data that looks odd (gaps, outliers).
  3. Propose the report structure — sections and key figures.
Wait for my confirmation.

Then build report_2026-09.docx with the same structure as the previous one.
Every number must say which file and which column it came from.
Where you draw a conclusion rather than state a fact, mark it explicitly.

A presentation from text

Read COMPANY.md.
In refs/ there is a description of the new product (product_brief.md), the
price list (price_2026-10.xlsx) and last year's customer deck (deck_2025.pptx) —
that is the model for visual style, not for content.

Task: a deck for a meeting with a retail chain, 10–12 slides, 20 minutes.

First write the outline: a title and one idea per slide.
Wait for confirmation.

Then build deck_retail_2026-10.pptx in the style of the previous deck.
One idea per slide, no more than 30 words. Numbers only from the price list
and the brief. Separately, in speaker_notes.md, write what to say on each slide.

A contract review

Read COMPANY.md.
In refs/ there is a supply contract from the counterparty (contract_draft.docx)
and our standard contract (our_template.docx).

Task: prepare me for the negotiation on this contract.

Produce contract_review.md with three sections:
  1. A table of differences from our standard contract: clause, their
     version, our version, whose favour the difference is in.
  2. Terms that carry risk for us: what exactly can go wrong and what it
     could cost. Flag penalties, payment terms, unilateral termination and
     liability for quality separately.
  3. A list of questions for the counterparty and proposed wording.

Do not rewrite the whole contract. If you are not sure about something,
write 'needs a lawyer's check' instead of guessing.

The last line matters. The agent is good at finding discrepancies and phrasing questions, but the decision on a seven-figure contract is made by a lawyer, and the signature under the report belongs to the accountant. The agent prepares the material; a person answers for it.

An instruction for a repeatable process (stage 2)

# weekly-report.md

When: every Monday before 10:00.
Data: last week's export from the accounting system — refs/weekly/YYYY-MM-DD.xlsx.
Sample: the latest report in reports/.
Check before building: the total of the 'Shipments' column matches the
export's total; no weeks with zero — if there is one, ask, don't write zero.
Result: reports/weekly-YYYY-MM-DD.docx + a three-line summary in the chat.
Don't: change the report structure without an explicit request.

On websites: the starter prompt and how to use it

If stage 3 brought you to your own app, here is where to start. I would take the same stack as in spring: Next.js, TypeScript, Tailwind, SQLite or managed PostgreSQL, GitHub, Vercel. Docker, your own server and CI/CD — later, when the first ten users arrive. But the stack no longer needs explaining: one prompt in an empty folder is enough.

I am not a developer. I want to build an internal tool for [one sentence:
who uses it and what they do]. Up to 20 users, all from one company.

Stack: Next.js (App Router), TypeScript, Tailwind CSS, shadcn/ui, SQLite via
Drizzle, deploy on Vercel, code on GitHub. Do not add anything more complex.

First:
  1. Ask me questions about the task until you understand it fully.
  2. Propose a plan: pages, database entities, user roles.
  3. Create a CLAUDE.md file with the project rules: folder structure, no
     business logic inside components, one component per file, tests for
     everything that calculates money, dates or access.
Wait for confirmation.

Then build one page at a time. After each one — a commit to GitHub and a
short note on what changed and how to check it by hand.

How to use it more effectively than in spring:

One feature, one session. Finished, committed, closed. A long session with ten tasks is the main source of chaos.
CLAUDE.md at the root is COMPANY.md for code. The agent reads it on every start. Anything you have told the agent twice goes there.
Ask for tests on anything that calculates money, dates or access. And don't let it edit a test until it has explained why the test failed.
Commit after every step. GitHub is your insurance: any step can be rolled back, even if you don't know how Git works.
Deploy from day one. A Vercel link your colleagues can see disciplines better than any plan.

If you already have a prototype and inside it is that one file — the refs/ folder trick still works: a new empty folder, the old code in refs/, REWORK.md next to it, and the first prompt: 'Read refs/REWORK.md, then everything else in refs/, propose a plan and wait for confirmation.'

When to bring in a developer — and in what role

The tool stays yours. Nobody takes it away or rewrites it 'because I know better'.

But at some point a project stops fitting into one head. The signals are simple: the agent fixes one thing and breaks another; you are afraid to touch what works; real users have arrived and errors start costing money; you need roles, integrations with the accounting system, a proper deploy, and it is not clear how. A separate signal: data that by contract or by law cannot go to the cloud. That is an on-premise conversation.

In spring I would have written here: 'at this step, call a developer, they will sort out the code and connect the database'. Now I will write it differently.

If the project has started to live, bring in an experienced developer not as a contractor but as a co-founder. You have the domain expertise and access to customers who already pay or are ready to. We have the ability to turn a working prototype into a system that survives growth, and an honest understanding of where the agent will cope on its own and where it won't. Neither side covers this alone right now.

Developers are not having an easy time either. The hiring market has turned into a ritual, which I described in The Hiring Market Is a Zombie, and large companies are stuck in the processes of the 2010s — see Enterprise Is Stuck in Time. Strong engineers increasingly look not for a vacancy but for a task with real users and a share in the outcome. You have such a task. It is an exchange where each side brings what the other lacks.

What this changes in practice: the developer comes not 'to fix the code' but for an hour's conversation about what really eats your team's week and who pays for it. One legitimate outcome of that conversation is 'don't build this yet', in writing, with reasons. Another is agreeing on roles and shares and moving forward together. That is how I work now: go through what exists, pull out what works, move it into a structure, connect data, access and deploy — and stay in the project rather than hand it over against a sign-off.

In closing

In spring I wrote that the world splits into those who can build a prototype and those who can turn it into a system. That is still true, but the line has moved. Almost anyone can build now. The rare skill became something else: pick one task, give the agent context, set a boundary, and refuse to trust the result until it has been checked.

That can be learned in three months. The roadmap above is for that.

Have a task with real users and need an engineer alongside, not on contract? Get in touch