Introduction
I'm Yuki Tatsunami, founder of OkojoAI. I started out as a software engineer, then moved into Deep Learning research. For the past year or so, I've been spending most of my time building LLM-powered software and SaaS products.
Honestly, I'd rather just be doing Deep Learning research. But the reality is, in fast-moving spaces, you can't compete without tools like Claude Code. I use it, even though it sometimes feels like it's taking away the joy of thinking through problems myself.
That tension is actually where ClaudeOps comes from: what do you delegate to Claude, and what do you keep thinking through yourself?
What is ClaudeOps?
Here's my definition:
ClaudeOps is the practice of running Claude continuously in the background to automate routine detection, triage, and action generation — where judgment is shared between Claude and humans, and final approval always stays with humans.
Compared to existing Ops practices:
| What gets automated | |
|---|---|
| DevOps | Build, test, deploy |
| MLOps | Model training, evaluation, serving |
| LLMOps | Prompt management, model evaluation, inference cost |
| ClaudeOps | Judgment and information-processing pipelines |
The distinction from LLMOps is worth spelling out. LLMOps is about how you operate LLMs themselves. ClaudeOps is about how you use LLMs to automate business operations. Claude is the infrastructure. ClaudeOps is the operational practice built on top of it.
Three Phases
ClaudeOps is structured around three phases:
1. Scan
Regularly scan code, data, and external services to detect problems and changes.
2. Surface
Organize and classify what was detected, then deliver it in a form humans can act on — filing issues, posting Slack summaries, generating reports.
3. Act
Execute actions based on a hybrid of Claude's judgment and human input — creating PRs, posting review comments, and sending notifications.
Scan → Surface → Act. That's the core loop.
The Design Principle: Intentional Delegation
The heart of ClaudeOps is Intentional Delegation.
Decide upfront what you're handing to Claude and what you're keeping for yourself. Not vague automation, but an explicit line between Claude's authority and human authority.
In practice, it breaks down like this:
Claude decides
- Bug detection via scheduled scans
- Issue filing and classification
- Auto-fix labeling where the fix is unambiguous
- Review comment generation
Humans decide
- Applying auto-fix labels to issues Claude couldn't classify confidently
- Merging PRs
- Designing and adjusting the pipeline itself
Hybrid
- Deciding what gets fixed: Claude labels what it's confident about, humans fill in the rest
It sounds obvious, but making this explicit at design time changes how safe and sustainable the whole thing feels in practice.
A Real Example: Automating a Dev Pipeline
At OkojoAI, we built this pipeline using Claude Code's Scheduled Tasks:
05:00 Bug detection Scan entire codebase → file Linear Issues Auto-apply auto-fix label where confident
06:00 PR creation auto-fix labeled Issues only → open PRs automatically
07:00 Code review All open unreviewed PRs → post review comments
The only thing a human needs to do is apply the auto-fix label to issues that Claude wasn't confident enough to label themselves. PR merges are always human decisions.
We're also exploring using Sentry as a polling trigger to detect production errors and file issues automatically within the same pipeline.
No custom infrastructure, no API development. Just a Claude Code subscription.
Beyond Engineering
ClaudeOps isn't limited to dev workflows. The Scan → Surface → Act loop applies across SaaS operations:
- Product analytics: Pull PostHog data on a schedule and post summaries to Slack
- Customer success: Detect churn risk from usage patterns and notify CS teams
- Support: Classify incoming requests and suggest routing
The structure generalizes. The specifics depend on your stack.
Closing
ClaudeOps is a brand-new concept. We just built our first implementation and haven't fully validated it yet, so I'm not going to oversell it.
What I do believe is that "just automate it" without thinking carefully about the human-Claude boundary tends to go badly. ClaudeOps is an attempt to put that boundary at the center of the design from the start — to keep the right things in human hands while letting Claude handle the rest.
If this resonates with you or if you're already doing something similar, I'd love to hear from you.
A follow-up post is in the works.
Top comments (0)