Melio PM: Claude runs 80% of my day, and the setup took months

The word coming out of every AI workflow post right now is the same: the tool matters less than how you set it up. A PM at Melio says Claude runs 70% to 80% of his day. Google engineers say the best prompt argues with you. Someone shipped a paying SaaS app without reading a line of code. All of it points at one shift. The skill is moving from doing the work to directing the work. Let me catch you up.

The deep cut

• Architecture beats the tool you pick. Daniel Blum built his 80% system on tools Melio already licensed, not a perfect platform.
• Context is a standing system, not a setup task. Blum's morning brief flags what it does not know and asks before guessing.
• Give each instruction one home. Overloaded CLAUDE.md files break the same way a junk-drawer prompt history does.

What "runs my day" actually took to build

Daniel Blum, a PM at Melio, told Lenny Rachitsky's show that Claude now handles most of his workday. The headline number is real, but the path there is the part your team needs to hear. He spent months feeding voice memos, decks, and links into context files, then built recurring updates so those files refresh every few weeks.

He is blunt that the first weeks feel slow. The system does not know enough, the output is off, everything needs a second look. The payoff comes only after you push through the boring work of centralizing what the AI needs to know. Blum now does in one day what used to take a week, but he earned that with setup, not a clever prompt.

The system that learns without being told

The trick that makes Blum's setup keep improving is a loop that watches him. A weekly self-improvement skill compares what Claude drafted against what he actually sent, then learns from the small edits he made by instinct. His morning brief scans Slack and email for terms it does not recognize, like "settlement cap," reads the thread, and asks him to confirm before saving it.

Blum's read on the real limit is worth repeating in your next planning meeting. The gap is not intelligence, it is persistence. Claude cannot yet keep working while his laptop is off. So the bottleneck your team hits will not be model quality. It will be whether you built the context and the feedback signals to make the model useful at all.

The junk-drawer problem, applied to your team

The same discipline shows up on the engineering side. One Towards AI breakdown names the failure mode plainly: teams dump every instruction into one CLAUDE.md file until coding standards sit next to incident response and a weekly security prompt loads into a debugging chat. The fix is boring and useful. Give each instruction a home. Standing facts go in CLAUDE.md. Repeatable procedures become Skills you call with a slash. Specialized work with its own context goes to a subagent.

A companion piece on the Skills API pushes the same line for production apps. Skills teach the model how you do a class of work. Tools perform one deterministic action with validation and audit logs. The hidden write, where a Skill quietly triggers a state change with no approval gate, is the trap. Keep the irreversible action behind a tool your system owns.

Direct the loop, do not chat with it

The prompting itself is where the craft is visible. Another Towards AI guide frames Claude Code as an agentic loop, and says the win is directing it in three stages: investigate first, plan before code, then implement in scoped steps. Under-specify the prompt and the agent fills the gaps with guesses that conflict with your codebase.

Google's own engineers landed in the same place. In a Google Cloud roundup, ten of them independently described using AI as a skeptical second opinion instead of an agreeable helper. One assigns a "strict principal engineer" persona and forces a letter grade, no A unless the code is robust. Another cites a study where roughly 40% of Copilot-generated programs carried a real vulnerability. AI code compiles and passes a casual glance, which is exactly why an adversarial review beats a polite one.

Shipping without reading the code

Then there is the far end of this. Paweł Huryn walked through building a paying SaaS app with Claude Code, Clerk, and Supabase, without opening a file. His larger project has 5,094 unit tests, ~177K lines of code, and he reviewed none of it. Users are already paying, $1,920 ARR before he even turned on managed hosting.

What makes it work is the same thing again: the setup. His template hands the agent a strategic context file, opinionated defaults, and instructions to consider common threats like XSS before any review. He writes intent as a flat list of what is wrong, "the button does nothing," not how to fix it. That is the shift for a PM. You own the intent and the guardrails. The agent owns the keystrokes.

Three questions for your team

• Who on your team is willing to eat the slow first weeks of building context, and are we measuring the payoff or just the setup cost?
• Where do our AI instructions live today, and would a new hire know whether a rule belongs in shared context, a reusable skill, or a locked-down tool?
• On our next build, what is the irreversible action, and is it behind an approval gate the model cannot skip?