This article is written as first-hand information from a non-engineer business owner who started using Claude Code and actually built four products with it. Rather than an abstract answer to the question “can non-engineers use Claude Code?”, this is a concrete record of how Yakumo’s founder (a non-engineer) got started, where they got stuck, what they gave up on, and what they managed to push through.
The technical implementation details — how to write CLAUDE.md, skill implementation patterns, agent design principles — are covered in the engineering-side article “Organizational Design Architecture for Non-Engineers Using Claude Code — CLAUDE.md Scoping, Permission Model, and Accident-Prevention Patterns”. This article contains no code whatsoever.
Three key takeaways:
- Claude Code is not “a coding assistant tool for engineers.” It has reached a stage where non-engineers can use it as an organizational workflow design tool. However, the biggest challenge is who designs the entry points — the CLAUDE.md and skill setup.
- There is a clear boundary between what a non-engineer can implement and what should be delegated to an engineer. That boundary is hard to draw in advance, but in retrospect the decision criteria become visible.
- The business decision to “invest in Claude Code” is less an investment in productivity improvement and more an investment in changing the organization’s information-processing structure. ROI should be measured not by short-term cost reduction, but by changes in decision-making speed and execution capacity over the medium to long term.
Why a Non-Engineer Business Owner Started Using Claude Code
It Started with the Reality of “No Engineers”
Yakumo began in April 2025 with one person — Takumi Morimoto (sole proprietor, PM and junior engineer). From the start there were attempts to hire engineers, but finding someone who could dedicate themselves to AI agent development wasn’t easy. The business had to move while waiting on hiring.
The encounter with Claude Code came in July 2025. The initial understanding was “AI that writes code,” but that understanding shifted within a few weeks of use. Claude Code wasn’t “a tool that generates code” — it was “an agent that takes an intent and sees it through to implementation.”
For a non-engineer business owner, this distinction is decisive. Code generation still hits the wall of “not knowing what correct code looks like.” But when you tell an agent “for this product, I want this business process to work this way,” it moves straight through from design to implementation. The human makes verification and correction decisions — and once this division of labor holds, product development can run without engineers.
The Choice to Build 6 Products in 10 Months, July 2025 to May 2026
After starting with Claude Code, Yakumo implemented the following 6 products in sequence.
1. synapse (cross-functional agent organization)
A system built on Claude Code consisting of a group of responsible agents (@director / @sales-director / @dev-director, etc.) and a suite of business skills. It handles much of the business workflow from order intake through invoicing, meeting minutes, and proposals. Since it was the first implementation, it went through the most trial and error, and the accumulated failures and improvements became the foundation for the other products.
2. montage (video content generation pipeline) A system that combines Claude Code agents with Remotion (a React-based video library) to mass-produce video content. Agents divide responsibilities across the workflow from research through scripting, voice synthesis, rendering, and thumbnail generation.
3. mcluhan (owned media operations engine) This article itself is published through the article pipeline that mcluhan manages. Article structure design, quality review, and publication scheduling are all automated.
4. corporate-site (corporate website) A website built with Astro + React + Tailwind. It includes the design system, SEO configuration, article CMS, and contact form. It also serves as the publication infrastructure for content managed by mcluhan.
5. medallion (financial data auto-collection foundation) A Python-based data collection tool that automatically fetches earnings reports every morning from JPX, TDnet, and individual company IR pages, accumulating them in a shared spreadsheet. It runs daily via launchd.
6. bateson (general-purpose Booking Engine)
A reservation engine with adapter-pattern and multi-tenant design using tenantId. The contact form on this site (/contact) also runs on bateson. It is also the starting point for a medium-term strategy to elevate implementation assets gained through contract work into a commercial license.
These 6 products were implemented over 10 months from July 2025 to May 2026. Across all of them, the state is “virtually zero code written by engineers.”
Axis 1: Safe Skill Delegation — What to Hand Off, What to Keep
What Is a Skill? (Explained for Non-Engineers)
A Claude Code “skill” is a text file that defines the procedure for a specific task. When you write out instructions saying “when doing this work, make these judgments in this order and produce output in this format,” the agent executes those instructions.
It’s similar to a cooking recipe. With just “make curry,” an agent has infinite interpretations. But if you define the procedure — “cut potatoes into 2cm cubes,” “fry onions until caramelized,” “600ml of water” — you get the same quality curry every time.
The first skill built out in synapse was a proposal-writing skill. It defined the procedure: “given a client name, requirements, and amount, generate a draft following Yakumo’s proposal format.” The initial version took a few weeks of trial and error, but once established, even non-engineer staff could produce proposal drafts at consistent quality.
Which Skills Are Safe to Delegate, and Which Aren’t
Over the course of operating synapse, the boundary became clear between skills that can be delegated and those that shouldn’t be.
Safe to delegate (deterministic work):
- Conversion into fixed formats (proposals, meeting minutes, invoices)
- Information gathering and organization (scraping, article summarization, data shaping)
- Boilerplate document generation (confirmation emails, progress reports, briefs)
- Quality checks (style consistency, forbidden-phrase detection, numerical consistency checks)
The common thread is work where “a correct answer can be defined.” Work with a fixed format and a clear input-output mapping is easy to define as a skill, and it runs safely even when operated by non-engineers.
Should not be delegated (work requiring judgment):
- Final decision on whether to propose to a client
- Determining contract terms and pricing
- Evaluations related to hiring and personnel
- Qualitative risk assessment
- Determining strategy and policy
These are judgments where “the correct answer changes based on context.” Leaving them to the agent means the agent will render some judgment, but the basis for that judgment and where responsibility lies become unclear.
In the montage example: “generate a script draft for a video” can be delegated. But the judgment of “whether to publish this video” is made by a human. The moment you fully automate publication approval for AI-generated video content, brand-related risk emerges.
How to Progress with Skill Delegation Incrementally
Looking back at how it actually went with synapse, there were three stages.
Stage 1 (first month): Verbalize existing work as-is Write out the work that was done manually, in words, as-is. Put into sentences “what, in what order, with what thinking, do I write a proposal.” At this stage Claude Code isn’t used — the focus is entirely on externalizing one’s own thought process.
Stage 2 (months 2–3): Build out as skills and test yourself Load the verbalized procedure into Claude Code as a skill file, run it yourself, and verify. Explore “does it run as intended,” “is the output quality acceptable,” “what kind of input makes it stable.” There were many failures at this stage.
Concretely: the blog-tech-write skill in its initial version didn’t reflect “learnings from retro,” and output articles contained cluster-alignment violations (business articles mixed with tech-level detail). The fix was encoding learnings A–H into SKILL.md and establishing a mechanism to tie them to retro and improve the skill itself (reference commit: 1bcad03 feat(blog-skills): encode A-H learnings). A skill isn’t something you build once and are done with — it’s something you keep updating with learnings from operations.
Stage 3 (month 4 onward): Delegating to other team members Build out skills that you yourself can use so that other team members can use them too. The main work is documenting operating procedures and adding constraints to CLAUDE.md to prevent misuse.
This is when “delegation to non-engineers” first becomes real. When only one person can use it, its value as an organization is small. Only when skills spread to other members of the organization does the investment in Claude Code pay off.
Axis 2: CLAUDE.md Design — Declaring Constraints and Permissions
The Role of CLAUDE.md (Explained for Non-Engineers)
CLAUDE.md is a text file that tells Claude Code “the rules of this organization.” When Claude Code starts up, it reads CLAUDE.md first and operates according to the rules written there.
It’s similar to an onboarding manual given to a new staff member: “here’s how we operate.” By writing rules like “we don’t use this word,” “always confirm before proceeding with this work,” “follow this format,” you reduce the risk of the agent taking problematic actions based on its own judgment.
CLAUDE.md Design for corporate-site
When designing the CLAUDE.md for corporate-site, the first problem faced was “not knowing what to write.”
For engineers, CLAUDE.md might be somewhat intuitive — write code style rules, prohibited libraries, test run commands. But non-engineers trying to write “code rules” don’t know what counts as a “rule.”
The breakthrough was a “write it after failure” approach.
Assign work to Claude Code, and when an unintended result comes back, add “don’t do this” to CLAUDE.md. A CLAUDE.md that started nearly empty gradually thickened through the accumulation of failures.
The corporate-site CLAUDE.md now contains constraints like these:
- No hardcoding (font sizes, colors, spacing must be referenced from config files)
- Commit messages in English
- Work on the develop branch (avoid direct push to main)
- Read _README.md before editing any given directory
Every one of these constraints was born from a failure that “actually happened.” CLAUDE.md functions not as something to “write perfectly from the start,” but as something to “keep adding rules learned from failures.”
Who Should Own CLAUDE.md Design
One important point to emphasize: CLAUDE.md design should be owned by an engineer. However, CLAUDE.md operations (adding, updating, maintaining) can be done by non-engineers.
Design and operations are different activities.
Design means deciding “what structure to use.” Which rules go global (shared across all projects) and which are project-specific. What granularity to set constraints at. These are judgments close to systems design, and they require involvement from people who understand the organization’s domain.
Operations means “adding problems that came up as rules.” Verbalizing experiences like “doing this work produced an unintended result” and adding them to CLAUDE.md.
The initial CLAUDE.md design for synapse was owned by the founder. While non-engineer by professional background, having taught programming independently and being capable of frontend implementation meant that structural design judgment was possible. Meanwhile, writing the actual body of CLAUDE.md was handed off to Claude itself — deciding “I want this structure,” having Claude draft the body in that structure, then reviewing the content and adding or revising it. The division of labor that became realistic: humans for design decisions, AI for writing, humans again for operational updates.
Axis 3: Staged Authority Delegation — Three Stages
Stage 1: Read-Only (Information Gathering, Document Generation)
Among the permissions Claude Code can hold, the lowest-risk is the “read” permission. Reading files, searching the web, referencing data — these are recoverable even if misused.
The first synapse implementation started from this Stage.
Concretely, the first skill built out was “research competitor websites and output a list of their initiatives in table format.” Claude Code searches the web, organizes information, and outputs it as a document. At this stage, even file writes weren’t permitted — output appeared in the terminal, and if it was going to be used, a human copied it.
What was learned at this stage: “even just automating information gathering, the actual reduction in work hours is significant.” Work that took several hours when a human did research reports shrank to about 20–30 minutes with Claude Code.
Stage 2: Proposal Generation (Draft Creation, Content Generation)
Stage 2 is granting the “write” permission. Generate drafts and save them to files.
The mcluhan article generation pipeline corresponds to this Stage. The agent reads an article brief, generates the body, and writes it as a Markdown file to a designated directory. A human reviews the generated file, and if approved, it enters the publication flow.
The most important design in Stage 2 is “where to place the checkpoints where humans intervene.”
In mcluhan, articles generated by the agent have a draft flag set. Articles with this flag are not auto-published. A human reviewing and clearing the draft state is the condition for publication. While the agent has the permission to “write” articles, the permission to “publish” belongs to the human — this design is what makes a safe Stage 2.
Stage 3: Execution Permissions (System Operations, External Integrations)
Stage 3 is the “run” permission. Writes to external systems, scheduler control, API calls.
synapse corresponds to this Stage. Saving files to Google Drive, sending emails from Gmail, committing to GitHub — these are all executed by Claude Code agents.
Stage 3 risk is qualitatively different from Stage 1/2. Writes to files are basically reversible, but sending an email cannot be undone. A GitHub commit can be erased with a force push but leaves a trace. It also includes operations that incur charges from external services.
One concrete risk management incident from this Stage is worth documenting.
When automating post-order paperwork in synapse, there was an incident where the same client was accidentally sent two invoices. The cause was a design error in the idempotency of the script (the property that executing the same operation multiple times produces the same result). The state was such that one command execution would run the sending flow twice.
In early 2026, the auto-send script (the predecessor to synapse) caused a double-send to the same client. The cause was an idempotency design flaw — one command execution would run the sending flow twice. Upon discovery, the situation was immediately explained and an apology issued to the client, and the duplicate invoice was cancelled (the client’s name is omitted here). As a result of this failure, when later organizing it into synapse, a “pre-send confirmation step” was elevated into a CLAUDE.md rule.
From this failure, a rule was added to CLAUDE.md that Stage 3 operations must include a “pre-send confirmation” step. The constraint is: “before executing any send operation to external parties, confirm the send content with a human first.” The design became a combination of automated operation and human final confirmation.
Migration Conditions for Each Stage
Here is a summary of the decision criteria for when to move between Stages.
| Transition | Condition |
|---|---|
| Stage 1 → Stage 2 | Stage 1 output has been continuously used for 2+ weeks and quality is confirmed to be satisfactory |
| Stage 2 → Stage 3 | A workflow has emerged where Stage 2 output can be judged usable without human checking |
These criteria are qualitative, but they are premised on the accumulation of “tried it and it was fine” experiences. Trust is built through track record.
Risk Management — Designing a Safety Net for Non-Engineer Use
Preventing Cost Overruns
Claude Code costs tokens (processing volume) based on usage. For non-engineers, developing a feel for “how much usage translates to what cost” takes time.
As an actual problem experienced: in the early synapse development period, a bug in a loop process caused token consumption to spike. Claude Code kept repeatedly executing the same process, generating unexpected costs.
From this experience, a rule was established. A monthly review was set up to check token consumption, and a monthly ceiling was set. ¥100,000 per month is the trigger to review how it’s being used.
The basics of cost management are “making usage visible.” The Anthropic dashboard shows usage and costs. Building the habit of checking this regularly is the first cost management step.
Preventing Misoperation and Unintended Execution
For non-engineers using Claude Code, the most frightening thing is “executing something in a state where you don’t understand what’s happening.”
The following designs were adopted in response to this.
1. Pre-execution plan confirmation (advance planning pattern) Before large tasks, have Claude Code write out “what it’s going to do” first. Confirm the plan before implementation begins, judge whether “it aligns with intent,” and only then permit execution.
2. Limiting the impact scope (scope restriction) When delegating work, attach explicit constraints like “don’t touch anything outside this directory” or “don’t edit anything other than this file.” Since Claude Code can work beyond the scope of instructions, intentionally narrowing the scope is necessary.
3. Reversible design (Git branch strategy) All code changes are managed in Git, and direct pushes to the main branch are prohibited. With corporate-site, work happens on the develop branch, and merging to main requires an intentional operation.
Designing Audit Logs and Approval Flows
In Stage 3 (execution permissions), logs recording “who, when, what, and why was executed” become important.
In synapse, logs of send operations to external parties are saved. Being able to trace what was sent, and when, if something goes wrong is the foundation for maintaining trust.
Approval flows are the same. For the synapse proposal-sending skill, the design is: send a confirmation message via Gmail, receive an approval reply, and only then send. Discord / Slack support is also planned for the future. This is one step slower than fully automating the entire process, but the judgment was made that maintaining the feeling of “humans make the final confirmation” is the right business decision.
Patterns and Failures Learned Across 6 Products
synapse — The First Failure Was the Best Teacher
Because synapse was the first implementation, it experienced the most failures.
The biggest failure was “giving the agent too much authority.” The initial design put the agent in a state where it could execute any operation it judged necessary. The thinking was “we can add constraints later,” but that thinking was wrong.
The actual problem that occurred was the agent rewriting a config file “in the belief that it was helpful.” When assigned a task, it didn’t just change what was directly requested — it also changed files it judged to be related. Those changes affected other workflows, and identifying the problem took time.
Lesson: Write constraints from the start. Begin with minimum authority and expand it only when needed.
After this failure, the way CLAUDE.md was written changed. It shifted to writing “what must not be done” before “what can be done.”
montage — Parts That Should Have Gone to an Engineer
In the course of implementing montage, there were multiple points where the judgment was “this should have been delegated to an engineer.”
Concretely: the video quality-checking logic. montage has a mechanism that automatically checks whether generated video text and footage meet quality standards, but designing that logic was difficult for a non-engineer.
Defining evaluation criteria for video required technical knowledge of “what is frame rate” and “how does bitrate affect video quality.” Asking Claude Code to “implement appropriate quality checks” would produce an implementation, but there was no way to judge whether that implementation was truly appropriate.
As a result, even this part of the implementation proceeded without delegating to an external engineer — instead having Claude Code read through the Remotion documentation and advancing step by step. For areas where technical judgment lacked certainty, Claude itself was asked to present multiple options to choose from, and quality was later guaranteed through operational verification.
The limit of non-engineers using Claude Code is “domains where you can’t judge what good design looks like.”
Claude Code can verify whether generated code runs correctly. But judging “is this architecture appropriate” or “can this design handle future expansion” requires technical experience.
corporate-site — The Boundary Between Design and Function
The most time-consuming part of the corporate-site implementation was building out the design system.
Claude Code can implement UI components. It can generate pieces like buttons, cards, and layouts. But judging “is this correct as Yakumo’s brand” requires design expertise.
The solution was to first establish DESIGN.md (a visual language definition document) and instruct Claude Code to “implement according to DESIGN.md.”
This approach worked, but it has limits. In situations requiring visual judgment not covered by DESIGN.md, Claude Code generates something “that looks right.” Whether “looks right” is “correct” requires a human to judge.
Concrete examples of rework: the magazine article TOC grew too long and broke the layout (fix(magazine/article): cap TOC at 50vh with internal scroll); the cancel button in the booking screen blended into the background in dark mode (fix(booking): make cancel button visible in dark mode); the Yakumo logo was appearing inside the magazine when it should have appeared on the corporate site side (fix(magazine/footer): send the yakumo logo back to the corporate site) — visual judgment gaps remain visible at the commit level.
The current rebuilt version of corporate-site was implemented in about 2 weeks. An exact comparison against the cost of delegating to an engineer is difficult, but there is a sense that a workload that would once have taken months was completed in 2 weeks.
What to Decide as a Business Decision — Pre-Implementation Checklist
Which Workflows and Team Members to Start With
When introducing Claude Code into an organization, the initial application should start with workflows that meet the following conditions.
Characteristics of workflows that are easy to start with:
- The procedure can be defined (“if we do this, that’s the correct answer” can be verbalized)
- You can judge the quality of the output yourself (you know what good output looks like)
- Failure is recoverable (you can check before pressing send)
- It occurs repeatedly (the benefits of automation accumulate)
The first application in synapse was “generating proposal drafts.” Given a client name, requirements, and amount, it generates a draft following Yakumo’s proposal format. This task met all conditions: the procedure can be defined, quality judgment is possible, content can be confirmed before sending, and it recurs with every engagement.
Estimating Preparation Costs
The cost of introducing Claude Code isn’t just “the Claude subscription fee.” There are real preparation costs involved.
CLAUDE.md initial design: a few days to about one week Initial design is more efficient when handled by an engineer. Non-engineers designing from scratch means longer trial-and-error time.
Skill setup: a few hours to half a day per skill The first few skills take time. Once the method of definition is familiar, the pace picks up.
Team member training: a few days per person The time to get comfortable with “running a skill” as an operation rather than “using Claude Code” broadly.
Maintenance and updates: a few hours per month Adding rules learned from failures, improving skills, extending application to new workflows.
Setting KPIs (What Counts as Success)
What state constitutes having “succeeded” with Claude Code investment?
Short-term indicators (3 months):
- Processing time for routine workflows reduced by 70% or more
- Team members can self-evaluate as “using it effectively”
Medium-term indicators (6–12 months):
- Application to new workflows is growing autonomously (team members adding and improving skills on their own)
- Time spent on important decisions has increased (freed from routine work)
Long-term indicators (1 year+):
- The organization’s “information processing speed” has changed
- Business scale has expanded without adding headcount
To be honest about where Yakumo stands: at the 3-month mark, processing time for routine workflows was shortened on target. Medium- and long-term indicators are still mid-evaluation.
Target: 70% reduction → Achieved: 90%+
Summary — Staged Authority Delegation Roadmap
What a Non-Engineer Was Able to Implement with Claude Code
From the experience of building 6 products, here is a summary of what was “implementable” by a non-engineer with Claude Code.
Was able to implement:
- Defining business flows in language and making them function as skills
- Adding rules to CLAUDE.md and restricting agent behavior
- Staged expansion from Stage 1 (information gathering) → Stage 2 (draft generation) → Stage 3 (execution)
- Running the cycle of learning from failures and improving constraints
Was not able to implement (an engineer was needed):
- Design decisions requiring judgment about technical quality
- Type definitions, API design, data structure design
- Verifying the validity of implementations related to performance and security
- Initial structural design of CLAUDE.md
Investment Decisions as Business Decisions
Here is the current answer to the question “was investing in Claude Code the right call?”
It was. However, the value of “expanding what can be done” turned out to be greater than the expected “cost reduction.”
The fact of being able to run products without hiring engineers can’t be explained by cost calculation alone. The state of “being able to do what you want to do” changed the speed of decision-making. Being able to run the cycle from idea to implementation yourself changed the driving force of the business.
Claude Code feels less like an “efficiency tool” and more like a “democratization of execution capacity.” Whether that expression is accurate I’m not sure, but “things that had been written off as technically impossible became possible” — that is the most honest assessment.
The Authority Delegation Roadmap as Next Steps
As a proposal to executives and business owners reading this article, here is a staged roadmap.
Weeks 1–2: Observation Write out the tasks performed over one week. List the work where “I’m doing this on repeat” becomes apparent.
Weeks 3–4: Stage 1 Trial From the listed work, pick one that falls under “information gathering and summarization” and have Claude Code try it. Start from the stage of “looking at the output as a reference” rather than using it directly.
Months 2–3: Initial CLAUDE.md Setup While continuing trials, add to CLAUDE.md points where “this didn’t run as intended.” Having an engineer handle the initial design is ideal, but if that’s not possible, start by consulting Claude Code itself: “I want to set up the CLAUDE.md for this project.”
Months 3–6: Expansion to Stage 2 With Stage 1 running stably, add work that falls under “draft generation.” Start with documents you’re repeatedly producing — proposals, reports, content.
Month 6 onward: Decision on Stage 3 Consideration of external integrations and auto-sending should wait until sufficient track record has been built in Stage 1/2. By this point, the intuition for “where to automate and where to keep humans in the loop” should be well-developed.
The technical aspects of organizational design for non-engineers using Claude Code — the concrete structure of CLAUDE.md, skill implementation patterns, agent design architecture — are detailed in the engineering-side article “Organizational Design Architecture for Non-Engineers Using Claude Code — CLAUDE.md Scoping, Permission Model, and Accident-Prevention Patterns”.
This article is written with Claude Code’s assistance through the owned media pipeline that Yakumo operates, and is based on that experience.
Related: AI Agents at the Business Core — Design Principles Beyond Passive Use