Claude Code Profit Workflow: 4 Upgrades Before You Build

Nate Herk's headline is intentionally aggressive: he asked Claude Code to make him as much money as possible, then says four upgrades helped him 3x his income in 30 days.

I would not turn that into a promise. But the underlying workflow is useful. The lesson is not "Claude Code prints money." The lesson is that Claude Code gets much more valuable when it stops behaving like a pleasant assistant and starts behaving like a critical business operator.

Source note

Credit for the source video goes to Nate Herk | AI Automation. You can follow Nate on X at @nateherk. Nate also linked the video skills and prompts in this Google Drive folder.

This post uses the transcript as the walkthrough source and adds a practical builder interpretation. I am not reproducing Nate's downloadable skill files here. Review them from his link, read what they do, and only install skills you understand.

First, this is not a money promise

The strongest version of this post is honest: Claude Code will not make every idea profitable. It can build the wrong thing faster. It can make a landing page for an offer nobody wants. It can say a task is done when it is only half done. It can lose quality when the context gets messy.

That is exactly why Nate's four upgrades are worth discussing. They are not magic prompts. They are operating rules:

• Challenge the idea before building it.
• Verify the output before trusting it.
• Reset context before the session gets noisy.
• Use parallel agents when the work can be split cleanly.

Anthropic's own Claude Code research points in the same direction: users tend to make the planning decisions, while Claude handles much of the execution. That means human judgment still decides whether the work matters.

1. Stress-test the idea before Claude builds it

Nate's first upgrade is a "roast" style skill. Instead of asking Claude whether an idea is good, you ask it to attack the idea from multiple angles before any code is written.

In the video, the example idea is a $9/month tool that turns YouTube transcripts into a week of LinkedIn posts. A normal assistant might say it is useful. The roast workflow says something closer to: this is a commodity tool, the buyer is too broad, the price may not support acquisition, and the product needs a sharper niche or proof of willingness to pay.

That is the right habit. Many AI builds fail before the first file is created because the business idea was never challenged.

The key is the verdict. Do not ask for vague encouragement. Ask for a decision and a cheap next test.

This also protects against AI sycophancy. Anthropic has published research on sycophancy in language models, which is the tendency for models to mirror or agree with users. In business work, agreeable answers are dangerous when the idea itself needs pressure.

2. Make Claude verify instead of just saying done

The second upgrade is the most important one for client work: "done" must mean verified, not merely generated.

In Nate's demo, Claude builds a waitlist landing page and then verifies it with screenshots, desktop and mobile checks, and form testing. That is the difference between a pretty artifact and a usable output.

For a website, verification might include:

• start the local server;
• open the page in a browser;
• take desktop and mobile screenshots;
• check every section for overflow, broken layout, and unreadable text;
• submit the form with valid and invalid inputs;
• report evidence, not just confidence.

For a data workflow, verification might mean fixture files, row counts, error cases, and before/after samples. For outreach, it might mean draft review, unsubscribe rules, CRM state, and a no-send gate. The method changes, but the rule does not: Claude should check its work before handing it to you.

This is not theoretical. The well-known "Asleep at the Keyboard?" paper found security weaknesses in a substantial share of GitHub Copilot-generated programs. The exact model and tool landscape has changed since that paper, but the lesson still holds: generated code needs review, tests, and threat thinking.

3. Reset context before the session gets sloppy

Long sessions feel productive because the agent "remembers" everything. They can also become worse because the context fills with old decisions, irrelevant details, stale errors, and half-abandoned branches.

Nate's answer is a session handoff. Before clearing the context, ask Claude to write a compact restart document:

• what the project is;
• what decisions are locked;
• what shipped;
• which files matter;
• what was verified;
• what remains open;
• where the next session should begin.

Then clear the chat and paste the handoff into a fresh session. You keep the important state without dragging the entire conversation behind you.

This lines up with the broader long-context caution. Chroma's "context rot" research argues that model performance can degrade as context grows, even when the model technically supports a large context window. More context is useful only when it is relevant, organized, and current.

4. Stop being the bottleneck: use sub-agents and goals

The fourth upgrade is about throughput. If every task waits for one agent to finish before the next begins, you are still running a single-threaded workflow.

Sub-agents are useful when work can be split cleanly:

• one agent researches competitors;
• one drafts positioning;
• one builds the landing page;
• one writes outreach copy;
• one creates the launch checklist;
• one verifies the output.

Anthropic has described a multi-agent research system where a lead agent coordinates specialized subagents. Their engineering write-up says the multi-agent system outperformed a single-agent setup on their internal research evaluation, while also noting that coordination and token cost matter.

That caveat is important. Parallel work is not free. It is worth using when independent tasks can run at the same time and produce evidence that a lead agent or human reviewer can reconcile.

In Nate's demo, the final workflow combines everything: the idea is challenged, the work is split into deliverables, the goal defines completion conditions, sub-agents create separate files, and the main agent verifies before declaring done.

Prompt patterns you can copy

Here are the safe versions of the patterns from the video.

Challenge the idea

Before building, stress-test this idea.
Use these roles: contrarian, buyer, market researcher, operator, and judge.
Give me:
- green light, reshape, or kill
- strongest reason this fails
- strongest upside
- riskiest assumption
- cheapest 48-hour test
- what I should build only if the test passes

Build with verification

Build the feature, then verify it before reporting back.
Start the local app if needed.
Use browser checks or tests appropriate for the work.
Capture evidence.
Report:
- files changed
- commands run
- tests or screenshots
- issues found and fixed
- known limitations
- what a human should review

Session handoff

Create a handoff for a fresh Claude Code session.
Include:
- project goal
- locked decisions
- files that matter
- current running state
- verification already completed
- open risks
- deferred work
- exact next prompt to continue

Parallel deliverables

Use parallel sub-agents for independent deliverables.
Each sub-agent must work in its own file.
When all sub-agents finish, synthesize the result.
Then run a verification pass and fix anything thin, generic, duplicated, or unsupported.

Where this can actually make money

The useful question is not "can Claude Code make money?" The useful question is: which revenue-adjacent workflow can Claude Code improve with proof?

That is the JQ AI SYSTEMS version of the money claim: use Claude Code on work near revenue, delivery, retention, or speed. Then measure the result.

Risks and caveats

• Third-party skills need review: read skill files before installing or invoking them.
• Verification can become theater: a screenshot is useful, but not enough for security, finance, customer data, or production changes.
• Parallel agents can waste tokens: use them when tasks are independent and outputs can be checked.
• Context handoffs can omit important details: keep source files, tests, and logs as the ground truth.
• Income claims are personal outcomes: treat Nate's 3x claim as his reported result, not a general promise.

The point is not to make Claude Code more dramatic. The point is to make it less naive.

A good agent workflow should challenge weak ideas, verify real outputs, preserve important context, and let you review higher-leverage work instead of babysitting every step.

CTA: Before asking Claude Code to build the next thing, ask it to attack the idea, define proof of done, verify its work, and create a handoff that lets the next session continue cleanly.

Sources

• Nate Herk video: I asked Claude Code to make me as much money as possible
• Nate Herk | AI Automation on YouTube
• Nate Herk on X
• Nate Herk's linked Claude Code skills and prompts folder
• Anthropic docs: Claude Code overview
• Anthropic docs: Claude Code slash commands
• Anthropic docs: Claude Code sub-agents
• Anthropic research: Agentic coding and persistent returns to expertise
• Anthropic engineering: How we built our multi-agent research system
• Anthropic research: Towards understanding sycophancy in language models
• Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions
• Chroma research: Context rot