Still Writing 2,000-Word Prompts for Claude? You May Be Tying Its Hands

Addy Osmani recently wrote an article with a very direct title: You're probably overprompting Claude. When Viking relayed it, he put it bluntly: with today's strongest models, too many prompts hold them back.

The most striking data point in the article is that Claude Opus 5 and Claude Fable 5 removed more than 80% of the Claude Code system prompt, and the coding eval showed no measurable decline. Viking added in the tweet that many previous skills could be deleted, and that over-constraining is like making a new model dance with shackles on. The original tweet is here: vikingmute/status/2116070310428733678.

Prompts often get long because the requirements weren't thought through. The model can only guess, the user keeps adding rules, and eventually the system prompt becomes a stack of old patches. One commenter joked in a reply that their CLAUDE.md still contains rules from three models ago, and they don't dare delete them.

A more efficient process is to give Claude a clear goal and then a clear validation condition. Viking mentioned that he likes to use E2E passing and screen-recording passing as acceptance criteria. If you haven't figured out what to do yet, first have Claude interview you in reverse until you can write a spec, then start a new session and use that spec to execute.

Addy also gave a few operational details. For Opus 5.5, you can start from /effort medium and adjust as needed. For long background tasks, use /goal to specify a condition and have another model check each round. Claude will stop when it thinks it's done. Auto mode uses a classifier to analyze actions instead of relying on per-action permission prompts, but this doesn't guarantee safety, and blindly approving every prompt doesn't guarantee it either. After Claude reports back, have it show the commands and output, or take screenshots.

Don't open subagents indiscriminately. Claude will delegate on its own, and only large independent work such as long audits or migrations is worth splitting into parallel work. Opening subagents for small tasks increases cost and latency. Addy's point is that subagents can parallelize and provide a second opinion, but by default they don't make things smarter. What he has seen is that a single agent with skills is often better on quality, cost, and latency than a subagent design.

If you want to close your laptop and run tasks, you can use cloud session. Start it from claude.ai/code, the Claude app, or claude --cloud; it runs in an isolated VM with a fresh clone of the repository, so push your commit before starting. Check issues, view diffs, and open PRs on your phone. Tasks that need local resources should stay local. Parallel sessions only pay off when a single session can run to completion independently.

Projects is another thing that saves management overhead. It is a long chat that helps you do project management: when there is a new issue or job, paste it in, and Claude opens a thread for each task, usually a cloud session, running in parallel. Give instructions once and they apply to new threads. Overview shows what is complete, which PRs are ready, and what is waiting for your input. Projects is in public beta on Pro and Max. One commenter posted an image in a reply, hoping Projects could have a cross-thread overview.

Review is still important, it's just that the process has changed. On the Claude Code team, most changes are reviewed and fixed by Claude at least once before a human sees them. Team and Enterprise can use Code Review, or for something lighter, use /code-review, which has a subagent that hasn't seen the current conversation review the diff. You can also just start a new session, give it the spec, and tell it to ignore style issues.

Don't take a one-size-fits-all approach. Some commenters reminded people that prompts can be cut, but skills don't necessarily all need to be deleted. Skills loaded on demand don't normally take up context; what really needs slimming down is the rules stuffed into the system prompt every time. A safer approach is to keep a set of regression tasks before trimming, see which problems actually come back after deletion, and then add the necessary constraints back. You can also turn off old skills one by one and run through them, then add back the ones the model misses.

Acceptance criteria also need to guard against cheating. One commenter asked whether E2E should be written in advance and locked down, or left for the model to write itself. If you let it write them, it will occasionally change the tests when they fail. It's best if acceptance criteria can be locked down.

Addy suggests auditing your way of working every few months, rather than building processes around the habits of old models. Prompt engineering is like early search engines, where users had to learn how to enter keywords; later everyone just said what they wanted to search for. Writing prompts for Claude now can also move in that direction: state the goal clearly, lock down acceptance, and intervene less in the middle.

Matt Pocock's grill-me was mentioned in many replies, and the Chinese comparison site is an unofficial learning site: mattpocock.ganhai.cloud.