Prompt Engineering Is Dead. Long Live Folder Management.

SATIRE — The software industry has formally retired prompt engineering after determining that asking a machine to do a thing was insufficiently enterprise. In its place, the International Bureau of Contextual Arrangements recommends Folder Management: the disciplined practice of putting the sentence you used to type into chat inside a Markdown file, committing it, and discovering six months later that it confidently instructs your coding agent to use a package removed during the last redesign.

This is progress. A prompt is a fragile little thought, typed at 4:47 PM beneath a diff you do not fully understand. Folder Management is that thought promoted into organizational infrastructure. It has a filename, an owner who left in February, three conflicting copies in a monorepo, and a place in the onboarding checklist after “install Node.” The agent is no longer merely asked to write a test. It is welcomed into a civilization.

The new prompt is a small constitution

The modern workflow begins with an instruction file. Depending on the tool, it may be called AGENTS.md, CLAUDE.md, a project rule, a command, a memory, or a quiet warning that appears after the agent has already modified package.json. The names differ because interoperability is a journey, and the journey requires several text files explaining where the other text files live.

For example, create a root-level AGENTS.md and write the things that repeatedly matter: the real test command, the package manager, what not to touch, and where the architecture documents are. Do not write a 1,400-line sacred scroll declaring that every function must “embody excellence.” A current Codex guide explicitly argues for a short, roughly 100-line map pointing to deeper documentation rather than one enormous instruction manual. That is not because agents dislike prose. It is because everyone dislikes stale prose, including the person who wrote it with great confidence during an incident.

# AGENTS.md

## Before editing
- Read docs/architecture/index.md.
- Do not modify generated/**.
- Do not read or print .env files.

## Checks
- pnpm lint
- pnpm test -- --runInBand

## API changes
- Update packages/api/openapi.yaml.
- Add a migration note to docs/changes/.

This file is not prompt engineering, obviously. It is operational doctrine. The difference is that operational doctrine can be reviewed in a pull request by somebody who says, “Why does the test command contain an undocumented incantation involving Redis?” Prompt engineering could only be reviewed by scrolling upward until Slack stopped loading.

Scoped instructions: because the frontend has its own weather system

A single repository instruction file soon encounters the problem it was built to create: the repository. The backend needs migration rules, the mobile app has a release ritual involving certificates and an emotional-support MacBook, and the documentation site is maintained by a static-site generator with personal boundaries. So you add local instructions nearer to the relevant work.

This is a genuinely useful pattern. Cursor’s project rules can live under .cursor/rules, be version-controlled, and be scoped by paths; its CLI also reads root AGENTS.md and CLAUDE.md. AGENTS.md guidance similarly supports nested files, with the closest instructions taking precedence. In practice, this means the agent can learn that services/billing/ has special rules without being burdened by the frontend team’s carefully negotiated preference for trailing commas.

It also means the agent can receive four instructions about the same database field, each written by a different era of the company. The root file says “never update balances directly.” The service file says “use applyLedgerEntry.” A README from 2023 says “balances are eventually consistent.” A comment says “temporarily synchronous until Q2.” The agent chooses one. You, meanwhile, experience the purest form of code review: archaeology with a green check mark.

A practical Folder Management protocol

For teams that would like to avoid founding the Ministry of Instructions, use a boring protocol:

1. Keep the root AGENTS.md short: setup, test commands, hard safety boundaries, and links to canonical docs.
2. Put instructions beside genuinely distinct subsystems. If every directory has one, you have converted navigation into an LLM configuration format.
3. Make imperative claims testable. “Run pnpm lint” is useful. “Write elegant code” is a postcard from management.
4. Treat agent-facing instructions as production documentation: change them with the workflow, review them, and delete obsolete rules.
5. Start an agent session with a task and acceptance criteria anyway. A repository file is persistent context, not telepathy.

The last point is where the rebrand becomes most visible. You still need to say what you want. “Fix authentication” is not a task; it is a grant application to the Department of Unbounded Diff. Say which path is broken, how to reproduce it, what behavior must remain unchanged, and which command proves success. If the agent has shell access, decide whether it should ask before commands run, and configure that boundary rather than relying on a sentence written during a caffeine event. Claude Code, for example, documents tool allowlists and denylists as CLI options; Cursor documents explicit shell and file permissions, with deny rules taking precedence.

What Folder Management is bad at

It is bad at making undocumented decisions true. An AGENTS.md cannot settle whether the new authorization model should be role-based or relationship-based. It can only preserve the decision after a human makes one. It is bad at discovering that pnpm test takes 19 minutes on CI but 43 seconds locally because the integration suite silently needs credentials. It is bad at security when “do not expose secrets” is its only control. It is especially bad at resolving conflicts between instructions, because that would require an institutional memory stronger than the one that created three style guides.

And it is bad at novelty. The more rules you load, the more likely the agent is to reproduce your existing habits at industrial scale—including the habit of creating an abstraction after the third duplicate line, even when the third line is in a test fixture.

The old job survives

Prompt engineering was never chiefly about finding magic words. It was the unglamorous work of supplying constraints, examples, context, and a way to tell whether the result is correct. The files, rules, commands, and permission policies are improvements because they make some of that work durable and reviewable. They are not improvements when they hide the fact that someone still has to understand the system well enough to state the task.

The true observation, standing quietly after the ceremony: agents work better when the repository has reliable tests, clear documentation, and explicit boundaries. We have not escaped prompt engineering. We have finally admitted it was documentation maintenance with a chat box attached.