Video walkthroughs · Claude Code Club

The Five Rules Anthropic Rewrote for AI-Native Work

14 minute read · Companion guide to “How Anthropic Hires AI Engineers for Claude Code (what really matters)”

Most advice about working with AI is about producing more. This one is not. Fiona Fung runs engineering for Claude Code and Claude Cowork at Anthropic, which means she manages the team building the tool and she hires the people who build it. She published what her team changed once agentic coding became their default way of working, and the interesting part is not what got faster. It is what quietly stopped working and had to be replaced.

The full breakdown of the article, rule by rule, with what each one means for a one-person business.

Start here: the bottleneck moved, it did not disappear

Her opening line is the whole article compressed. On the Claude Code team, writing code rarely slows them down anymore. Writing tests and refactoring do not slow them down either. But the bottlenecks did not go away when agentic coding took over the typing. Verification, code review and security took their place.

Read that as a general claim and it stops being about code. Every kind of work has a producing step and a checking step. For twenty years the producing step was the expensive one, so every process, every meeting, every role and every hiring bar was built around protecting it. The model just made the producing step cheap. Everything built to protect the expensive step is now protecting the wrong thing.

This is why the standard reaction of doing the same job faster gets you so little. If you write five times the code, you have five times the code to verify. If you generate five times the posts, you have five times the posts to check for tone and accuracy. Volume moves the pressure downstream. The only real gain comes from redesigning the checking step, and that step is where humans still hold the advantage.

Rule 1: Ask Claude first, not last

Before agents, the first step to answering most questions was to find the person who wrote the thing. You walked down the hall, you searched a wiki, you posted in a channel and waited. That habit is expensive in a way nobody measured, because the cost was hidden in other people's calendars.

The new norm is to ask Claude first. Not because Claude always knows, but because the cost of asking is close to zero and the answer arrives with the actual files in front of it. In our community the same pattern shows up daily. Members send a question, wait a few hours for a reply, and the answer turns out to be something Claude could have found in their own project in ninety seconds, with the benefit of seeing their setup rather than a description of it.

• Ask the person when the answer depends on history nobody wrote down, on a decision that was political, or on something only they have permission to see.
• Ask Claude when the answer lives in files, logs, code, documents or data you already have.
• Ask Claude first even when you plan to ask the person, so the question you send them is sharper and takes them one minute instead of twenty.

Rule 2: Go one level deeper on the question before you ask it

This is the part of the article most people skim past, and it is the one that changes your results the most. Her instruction is to go a level deeper on what you actually need to know. Are you trying to find who caused a regression? Are you trying to get an expert answer for a customer? What is the true thing you are trying to figure out?

Most weak prompts are weak because the person has not decided what they want yet. They ask a shaped-like-a-question sentence and get a shaped-like-an-answer paragraph. The fix costs one sentence of thinking. Write down the decision you are about to make, then ask for the thing that decision needs.

Then comes the second half of the rule, and it is the half that compounds. No matter what the question is, her team also asks: is there a way to automate this? Every question you ask more than once is a job description in disguise. The answer you got today is worth something. The thing that produces that answer every day without you is worth much more.

Rule 3: Stop checking everything equally

On her team, code review changed shape. Claude handles style, obvious bugs and test coverage. Humans focus their attention on the parts that need domain expertise. This is not humans checking less. It is humans checking a smaller set of things much harder.

The sorting rule is simple and it is about consequences, not difficulty. Some mistakes are annoying and you fix them in a minute. Some mistakes cost you money, cost you a customer, or leak something that should never have left your machine. Those two categories deserve completely different amounts of your attention, and most people give them the same amount.

• Let it pass on a first read: formatting, naming, structure, tidying, boilerplate, first drafts of anything you will revise anyway.
• Check it yourself, every time: anything touching money, credentials, customer data, anything that deletes or overwrites, anything published under your name, and any factual claim you would be embarrassed to have wrong.
• Check it once, then build a rule: repeated mistakes of the same shape belong in a project instruction file, not in your head.

The tell for which list something belongs on is one question. If this is wrong and nobody notices for a week, what does it cost? If the honest answer is nothing, stop reviewing it line by line. If the honest answer is a refund, a lost client or an apology email, that is a thing you read yourself before it ships.

Rule 4: Start with the task you dread

Her closing advice is a single move. Pick your noisiest workflow. It might be the most expensive one, or the one you keep pushing to next week, or the one nobody on the team looks forward to. Then ask whether it still serves its purpose.

The reason this works better than picking your favourite workflow is that dread is a reliable signal. You do not dread work that is producing an obvious result. Dread usually means the task survived the reason it existed. It was built to close a gap, the gap closed, and the ritual kept running because nobody was assigned to end it.

Rule 5: Stop planning six months out

When she joined the Claude Code team they wrote a solid six month roadmap. It was out of date by month three. Not because the plan was bad, but because the tools underneath it changed faster than the plan could absorb.

So the team moved to just-in-time planning. They do not run many product reviews. The process now is to prototype, get a lot of internal users on it, and act on their feedback. That is a smaller and less impressive-looking process, and it is a better one, because the feedback comes from people using a real thing instead of people reacting to a description of a thing.

For anyone building a product, an app or an offer alone, this is the most directly transferable rule in the article. The build cycle now runs in an afternoon. Every week you spend planning is a week you spend guessing about users you could have talked to. Ship the small version, put it in front of five real people, and let what they do decide the next thing.

Rule 6: Let the roles blur, including your own

One of the changes she highlights is that product managers on her team now write a lot of code. Engineers take on content and design. The fixed job boxes stopped mapping to the work, because the thing that used to gate each box was syntax, and syntax is no longer the gate.

This is the line that matters most to people who do not think of themselves as technical. If you can describe what you want clearly, in plain language, with the right context attached, you can now do work that used to require a specialist. The skill being tested is not the language. It is whether you can state a problem precisely and recognise a correct answer when you see one.

The same door opens the other way. If you are already technical, the parts of the business that used to be somebody else's job are now within reach: the landing page, the video, the customer research, the brief. The people winning right now are the ones who stopped defending the edges of their old role.

Rule 7: Judge by judgment, not by throughput

The hiring section is where all of this becomes concrete, because hiring is where a team states out loud what it values. She indexes on two profiles. The first is creative builders with product sense, meaning people who are deeply curious and want to ship things that solve real problems. The second is engineers with deep systems expertise, the specialists you need when something has to hold up at scale.

What she indexes on less is raw throughput, because the models handle volume now. The more useful question is where human expertise is still required, and that is where she puts attention. Judgment and taste are what she is buying.

If you are selling AI work to clients, this is your positioning, stated by the person who hires for it. Nobody is paying a premium for output volume in a world where output is cheap. They pay for someone who can tell them which of the five options is the right one, and why the other four are wrong.

Worked example: three real processes and what happened to each

The article contains three specific processes and three different outcomes, which is exactly the range you will hit in your own work.

The first was the six month roadmap. It was a real process that closed a real gap: when building was slow and expensive, planning far ahead was how you avoided wasting the expensive resource. Once building got cheap, the plan became a guess with a calendar attached. It was stale by month three. The outcome was replacement, not deletion. Planning still happens, but it happens just in time, against a working prototype and real internal users.

The second was a weekly status meeting on a team she was previously on. Large room, many people, expensive hour. She noticed everyone was on their laptops except during their own status update, when they would look up, say their piece, and go back down. She asked one question out loud: why are we having this meeting? That question was enough for everyone to realise it was not needed, and the meeting was cancelled. The outcome was deletion. No tool involved, no automation built, the whole hour returned.

The third was her own morning ritual. She used to have Claude summarise customer feedback every morning, by hand, with her coffee. It was genuinely useful work, which is the point. It was worth doing, so it was worth automating, and now it runs in the background without her. The outcome was automation. The process she deleted was the one nobody valued, and the process she automated was the one she did every single day.

Three processes, three outcomes: replace, delete, automate. Run every workflow on your list through those three doors and most of your decisions make themselves.

The three guardrails that hold the whole thing together

The article names three principles the team treats as non-negotiable, and they are what stop the rest of this from turning into chaos. Autonomy inside guardrails works. Autonomy without them does not.

• Use your own product every day. Every person on the team works with Claude Code and Claude Cowork daily, so problems are found by the people who can fix them.
• Keep the structure flat. Managers start as individual contributors, so the people setting process still remember what the work feels like.
• Give explicit permission to kill processes. This is the one most teams skip. If nobody is allowed to ask why a meeting exists, every meeting exists forever.

Borrow the third one even if you work alone, because you are also the person who will not question your own rituals. Put a recurring block in your calendar whose only job is to ask which standing commitments still earn their slot.

Where this goes wrong

Every rule above has a failure mode that looks like success for a few weeks. These are the ones we see most often in the club.

• Automating the ritual instead of the outcome. If you automate a weekly report nobody reads, you now have an unread report arriving forever and a false sense of progress. Check that somebody acts on the output before you build the pipe.
• Skipping verification because the first ten outputs were correct. Confidence built on a small sample is how expensive mistakes ship. Keep the money, credentials and customer-facing checks manual no matter how good the streak is.
• Prototyping without users. Just-in-time planning only works if real people touch the prototype. Without users you have not replaced the roadmap, you have deleted it and kept the guessing.
• Blurring roles without building any depth. Doing every job at a shallow level is not the same as expertise moving around. Pick one area where you are genuinely the best judge of quality and keep it sharp.
• Deleting a process that was quietly holding something up. Before you cancel a recurring commitment, write down what it was originally protecting and check that something else covers it now.

Three numbers that tell you it is actually working

The article names three indicators the team watches to know whether new norms have taken hold, and each one has a plain equivalent for a small team or a one-person business.

• Onboarding ramp time. On their team, engineers ship real code in their first week. Your version: how long from a new person or a new client arriving to something real being delivered.
• Cycle time from start to shipped. As generation gets faster, this number exposes exactly where your pipeline jams, and it is almost never the writing step.
• Share of work that is AI-assisted. On their team essentially every commit involves Claude. Your version: what fraction of your recurring work still runs entirely by hand, and whether that fraction is falling.

Pick one and track it for a month. A single honest number beats a dashboard nobody opens.

Do this in one sitting

Here is the shortest honest path from finishing this page to having something real. Give it ninety minutes.

1. List every recurring task in your work that happens weekly or more often. Do not filter, do not judge, just write the list. Ten to twenty items is normal.
2. Mark the one you dread most. That is your starting point, not the easiest one and not the most interesting one.
3. For that task, write one sentence saying what gap it was created to close. If you cannot write that sentence, you have found something to delete today.
4. If the gap is real, decide which of the three doors it goes through: replace it with a lighter version, delete it, or automate it.
5. For the automate case, write down the exact input it starts from and the exact output somebody acts on. Both must be specific things you can point at.
6. Build the first version in one session with Claude Code and run it by hand once to check the output is correct.
7. Add one verification rule: the single check that must stay human because a mistake there costs you money.
8. Run it manually every day for a week before you schedule it. A week of real output is the only proof that matters.
9. At the end of the week, go back to your list and pick the next one.

Step three does most of the value. Roughly a third of a typical list turns out to be work nobody can justify anymore, and deleting those is faster than any automation you could build.

What to take from all of this

The person who hires the engineers building Claude Code stopped measuring how much they can produce, because the model produces more than any human can. What she wants is judgment and taste. That is not a comment about hiring. It is a description of which half of the work is still yours.

So the question to leave with is the one she ends on, and it takes ten seconds to answer honestly. What is one piece of your workflow, your business or your week that you should automate or drop entirely? You already know the answer. The list you wrote in step one just made it hard to ignore.

Read this online at claudecodeclub.ai