标签：#Automation

Successfully onboarding an automated test suite to Harness CI requires configuring infrastructure placeholders, secrets, pipelines, and branch protection rules. Here is a 10-step checklist to help you onboard your end-to-end (E2E) automation pipelines seamlessly. Step 1: Replace Infrastructure Placeholders Ensure your pipeline YAML definitions (e.g., .harness/e2e-poc.yaml and .harness/e2e-regression-parallel.yaml) contain your specific environment values: ORG_ID: Harness Organization Identifier PROJECT_ID: Harness Project Identifier GIT_CONNECTOR: Harness Git Connector for GitHub Enterprise access APP_REPO_NAME: Target repository in owner/repo format K8S_CONNECTOR: Kubernetes connector for build infrastructure K8S_NAMESPACE: Kubernetes namespace where build pods run Step 2: Configure Environment Secrets In Harness, set up the following runtime secrets: CONNECT_URL CONNECT_USERNAME CONNECT_PASSWORD Step 3: Setup PR Validation Pipeline Import your short-run pipeline YAML into Harness. Save it as your PR Validation Pipeline. Run a manual validation test using runtime overrides: TargetEnv = qa cucumberTags = @smoke Step 4: Verify Artifact Generation Confirm that the initial execution correctly generates and uploads all required outputs: JUnit Report: reports/junit-report.xml Test Reports: reports/** Failure Artifacts: test-results/** (screenshots, traces) Step 5: Setup Nightly Parallel Pipeline Import your parallel pipeline YAML into Harness. Save it as your Nightly Regression Pipeline. Run a manual validation test with target concurrency parameters: TargetEnv = qa cucumberTags = @regression cucumberParallel = 4 Step 6: Configure Automated Triggers & Branch Protection PR Trigger: Configured on pull requests with cucumberTags= @smoke . Nightly Schedule Trigger: Configured on a nightly cron schedule with cucumberTags=@regression and cucumberParallel=4. GitHub Branch Protection: Enable branch protection on target branches requiring the Harness PR pipeline status check to p

n8n has added a documented workflow template for automated stock analysis that combines technical indicators, company financial information and news sentiment into an emailed Buy, Hold, or Sell recommendation . The template, listed in n8n's workflow marketplace as workflow 11772, is a practical example of how no-code orchestration can assemble multiple AI and data services into a single decision-support workflow. The official n8n workflow listing describes the template as a system for generating AI stock reports using fundamental, technical and news analysis through free APIs. Rather than relying on one broad prompt, it uses a central orchestrator to coordinate specialist sub-workflows, then synthesizes their outputs into a professional HTML report delivered by email. For n8n users, the significance is less the existence of a Buy, Hold, or Sell label than the workflow design behind it. The template packages a repeatable pattern: collect structured and unstructured inputs, delegate analysis to focused agents, combine results and route the final output to a business channel. That pattern can be adapted well beyond market research. How the n8n stock-analysis workflow is structured The workflow divides a complex research task into specialized components. Its central AI agent acts as an orchestrator, calling sub-workflows for technical analysis, fundamental analysis and news sentiment before producing the final recommendation. This is a more traceable automation design than asking a single model to handle every input and conclusion in one step. The documented workflow includes the following elements: Technical analysis uses indicators including RSI, MACD and Bollinger Bands, alongside a chart image analysis component. Fundamental analysis retrieves financial statements and summarizes the company's financial health. News sentiment analysis aggregates and interprets relevant market news. Report generation and delivery synthesizes the analyses into a recommendation and send

Accelerating test execution in a Hybrid Automation Framework (combining Data-Driven and Keyword-Driven architectures) requires an efficient parallel execution strategy. By dynamically mapping keyword actions and test data rows to concurrent threads, you can drastically reduce execution time without compromising framework design. Here is a guide on setting up parallel execution using a central Allocator and Run Manager. 1. Overview of the Setup The framework leverages a Run Manager sheet to map keywords to execution steps and pull test data dynamically. Parallelization works by assigning NumberOfThreads to match the exact number of active test cases marked for execution. Key parameters are configured globally inside the Global Settings.properties file. 2. Configuration Steps a. Set the Number of Threads Total the number of test scenarios marked with Execute=Yes across your target keyword and data sheets. Set NumberOfThreads equal to this count. Example: If your Run Manager sheet contains 42 test iterations set to Execute=Yes, update your configuration: NumberOfThreads = 42 b. Disable Profile-Based Execution (If Not Needed) For clean parallel browser execution, set EnableProfile=False. If user profiles are required to maintain session state across keywords, set UseMultiProfile=True and configure separate profile directories per thread to avoid file-lock conflicts. c. Prepare the Run Manager Flag every keyword test case intended for the current run with Execute=Yes. The allocator will read these rows, pair them with their corresponding data sets, and dispatch them to the thread pool. 3. Executing the Test Suite Trigger the allocator flow via Maven: mvn clean test -P runAllocator The allocator reads the mapped keyword sheets and test data, initializes the specified NumberOfThreads, and executes the tests in parallel. 4. Handling Multiple Keyword & Data Sheets Option 1: Use a Master Control Sheet (Recommended) Consolidate execution rows into a single master sheet (e.g.,

WLOADCTL is built as a distributed scheduling platform composed of multiple cooperating processes. Communication between different nodes, such as: Server ↔ Agent Server ↔ Client is handled through TCP/IP socket communication. However, communication between components on the same node relies heavily on Linux Inter-Process Communication (IPC) mechanisms, including: Message Queues Shared Memory Semaphores In some environments, the default Linux IPC configuration may not be sufficient for high-volume scheduling workloads. When this happens, WLOADCTL may encounter message queue-related errors or communication bottlenecks. This article explains how to: Check current IPC limits Increase message queue capacity Inspect IPC resource usage Remove unused IPC resources Understanding Current IPC Limits Before making any changes, it is important to inspect the current IPC configuration. Use: ipcs -l This command displays the system-wide limits for IPC resources, including: Maximum number of semaphore sets Maximum number of semaphores Maximum message queue size Maximum shared memory limits Pay special attention to the Message Limits section. Example: ------ Messages Limits -------- max queues system wide max size of message (bytes) default max size of queue (bytes) If the value of: default max size of queue (bytes) is around: 16384 the queue capacity may be too small for larger scheduling environments. Increasing Message Queue Capacity If the current limits are low, we recommend adjusting the Linux kernel IPC parameters. As the root user, edit: /etc/sysctl.conf and add the following settings: kernel.msgmni=1600 kernel.msgmax=8192 kernel.msgmnb=1638400 Parameter descriptions: Parameter Description Typical Default Recommended msgmni Maximum number of message queues 16 1600 msgmax Maximum size of a single message (bytes) 8192 8192 msgmnb Maximum capacity of a message queue (bytes) 16384 1638400 In WLOADCTL, a typical internal message is approximately: 512 bytes After modifying the con

This is an English write-up of a post from my Japanese dev diary. Original: https://saas-diary.com/tech-log/backup-restore-drill-automation/ For over a year, my backup job has reported success every single night. Green check, every day, no exceptions. Then I asked myself one question and went cold: "How many times have I actually restored from it?" Zero. Not once. "It was backed up" and "it can be restored" are different states My setup has two paths. One mirrors all source to a private repo. The other packs the things I can never recreate — notes, config, and Android signing keys — into an encrypted bundle and ships it to a private channel every night. Both were green every day. But green only proved the upload finished . It never proved the contents were right, or that the archive could even be opened. Within one month, I had two failures that stayed green the whole time. Failure 1. The collector for signing keys used three hardcoded paths. I kept shipping new apps, so the number of keys kept growing — but the collector didn't. By the time I noticed, 7 of 10 keys were missing from the backup . Five of those apps were live on the store. If my machine had died, I could never have shipped an update for them again. The backup reported success every night through all of it. Failure 2. The mirror push failed 7 days in a row (a large binary hit the host's file-size limit). But the script printed "✅ done" and returned exit code 0 even when one half failed. A failure that isn't visible isn't a failure — it's a time bomb. So I automated a restore drill Once a month, a job now does this: Rebuild the encrypted bundle (without shipping it) Actually decrypt it with the stored passphrase Extract it and count what's inside Check the mirror is not stalled (latest commit timestamp via API) Delete the scratch folder and the generated bundle The encryption is openssl-compatible AES-256-CBC with PBKDF2 (SHA-256, 100k iterations). I deliberately avoided depending on the openssl binary,

The Day I Realized I Wasn't Building Apps For years, I thought I was building apps. That's what I called them anyway. A scheduler. A job bot. A healthcare platform. An AI project. A content tool. A browser automation system. Looking at my GitHub, they seem completely unrelated. Honestly, that's something I've worried about before. I have over a hundred repositories. If someone spends thirty seconds scrolling through them, I can imagine them thinking: "Wow. This person is all over the place." The funny thing is that I eventually realized the opposite was true. My GitHub is here: https://github.com/ashb4 The Scheduler That Wasn't A Scheduler One of my projects started life as a simple scheduler. That was the goal. I hated posting content manually. Open platform. Paste content. Upload image. Repeat. Again. And again. And again. It felt repetitive. It felt annoying. Most of all, it felt like something a computer should be doing instead of me. So I built a scheduler. At least, that's what I thought I was building. Then Things Got Weird The scheduler worked. But now I needed content. Then I needed analytics. Then I needed to know what content was working. Then I needed a way to track winners. Then I needed a way to reuse content. Then I needed platform-specific strategies. At some point I looked up and realized I wasn't building a scheduler anymore. I was building a system. A system for discovering, creating, publishing, measuring, and improving content. The scheduler was just one piece. Then I Started Looking At Everything Else That's when I noticed the same thing happening in almost every project I'd ever built. My job application tools weren't really job application tools. They were systems designed to reduce repetitive effort. My automation projects weren't really automation projects. They were systems designed to reduce repetitive effort. Even my AI projects weren't really about AI. They were systems designed to reduce repetitive effort. Different technologies. Diffe

Grab is using AI agents to automate analytics workflows, cutting mechanical analyst work from 44% in February to 30% in June. Its approach combines agent autonomy, certified data, context management and human oversight, with self service analytics increasingly handling metric, data and SQL requests without analyst intervention. By Leela Kumili

Fragile element locators are one of the primary drivers of test flakiness in UI automation. Relying on auto-generated, deeply nested CSS selectors or long XPath expressions makes your test suite sensitive to minor layout changes, styling refactors, and DOM updates. Adopting a clear locator strategy simplifies maintenance and ensures tests remain reliable as applications evolve. Core Principles for Locator Selection Prioritize Intent-Revealing Attributes: Always prefer dedicated, stable testing attributes such as data-test, data-testid, or data-qa. Avoid Style-Driven Locators: Steer clear of brittle, structure-dependent CSS paths (e.g., div > div > span:nth-child(2)) and complex XPath queries unless absolutely necessary. Preferred Selector Patterns Buttons & Actions: button[data-test="login-submit"] Content & Inputs: [data-testid="product-name"] Practical Migration Tips Centralize Locators: Group and manage all selector definitions inside dedicated Page Object Model (POM) files rather than hard-coding strings within step definitions or tests. Collaborate for Testability: If a critical UI element lacks a distinct test attribute, submit a quick PR to your developer team to add a dedicated data-test attribute. Automate Audits: Implement a lightweight audit script in your workflow to scan and flag missing data-test attributes across key target pages before running full regressions.

Hard-coding credentials, API keys, or access tokens in automated test suites is one of the most common security risks in software engineering. Ensuring that sensitive variables remain isolated across local developer environments and CI/CD pipelines is critical for keeping your code repositories secure. Here is a practical guide and best-practices workflow for managing secrets cleanly in test automation frameworks. Core Recommendations for Secure Test Suites Zero Source Control Leakage: Always add .env and .env.local files to your .gitignore. Never commit raw tokens or passcodes to git. Use Managed CI Secret Stores : In build pipelines, leverage platform native secret managers such as GitHub Secrets, Harness Secrets, Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault. Dynamic Injection via Environment Variables: Read sensitive data dynamically inside tests using standard environment variables (e.g., process.env.API_KEY or process.env.API_BASE_URL). Enforce Least Privilege: Scope test credentials strictly to non-production environments and configure them to expire periodically. Implementation Examples Local Development Usage: Create a non-committed local environment file (.env.local): API_BASE_URL = https://staging.example.com/api API_TOKEN = your_secret_token_here Execute your test suite while passing or overriding variables inline: # Setting environment variables directly before execution $env :API_BASE_URL = 'https://staging.example.com/api' npm run test :api CI Pipeline Integration (e.g., GitHub Actions): Store API_TOKEN under your repository's Settings > Secrets and variables > Actions, then pass it into your execution job step: - name : Run API Tests run : npm run test:api env : API_TOKEN : ${{ secrets.API_TOKEN }} API_BASE_URL : ${{ secrets.API_BASE_URL }}

Setting up a fresh test automation framework can feel overwhelming without a clear blueprint. Having a structured setup process ensures that directory layouts, configuration files, and execution scripts are aligned right from day one. Here is a quick setup guide for initializing a hybrid BDD framework powered by Playwright, Cucumber, and JavaScript. Installation & Directory Setup Start by installing project dependencies and creating the core folder hierarchy for feature files, step definitions, page objects, and utilities: # Install dependencies npm install # Create required folder structure mkdir features features/API features/UI mkdir step-definitions step-definitions/API step-definitions/UI mkdir page-objects utils setup setup/fixtures mkdir test-data test-data/json test-data/excel mkdir reports logs test-results Key Framework Files Ensure your framework repository includes the following core files: Configuration: package.json, playwright.config.js, cucumber.config.js Page Models & Drivers: page-objects/PageManager.js, utils/ApiHelper.js Hooks & Fixtures: setup/hooks.js Step Definitions: step-definitions/API/PlaywrightAPISteps.js, step-definitions/API/JsonTestDataSteps.js Test Data Strategy & Execution Test Data Management: Primary test data is managed via JSON (test-data/json/testData.json, test-data/json/apiTestData.json), with optional Excel support for tabular data inputs. Environment Setup: Store key environment variables (e.g., BASE_URL, API_BASE_URL) inside your local .env configuration file. Execution Commands: # Run API test suite npm run test :api # Run UI test suite npm run test :ui # Run full execution suite npm run test

Hook: Imagine being able to set up rate limiting for your LLM APIs in MuleSoft—something that typically requires complex code—simply with just three clicks. No need to dive deep into Java or XML; it’s as simple as configuring a few settings on Anypoint. Demystifying Rate Limiting: Your Path to Controlled API Usage If you're a citizen developer or business analyst navigating the world of no-code/low-code automation, one common challenge is managing your LLM API usage without overwhelming your monthly budget. Tools like MuleSoft often present rigid pre-built connectors and complex data mapping transformations that can be daunting if you’re not well-versed in XML or Java. But fear not! The process doesn’t have to be as complicated as it seems. Let’s take a look at how Anypoint simplifies the implementation of rate limiting, allowing your client applications to use LLM APIs responsibly and without breaking the bank. Step 1: Setting Up Token Bucket Policy First, you'll want to set up a token-bucket policy on Anypoint that caps per-client spend. This is where MuleSoft’s flexibility shines through its intuitive interface: Navigate to Your API Gateway: Log in to your Anypoint Platform and select the API Gateway. Choose Rate Limiting Policy: In the policies section, choose 'Rate Limiting'. Configure Token Bucket Settings: Set up a token bucket policy where you define how many tokens (requests) are allowed within a given time frame. This straightforward setup prevents any single client from overusing LLM resources, ensuring fair and sustainable usage across all your applications. Step 2: Handling Excess Requests with Grace Now, what happens when a client exceeds their allocated limit? The magic of MuleSoft lies in its ability to handle these scenarios gracefully: Automated 429 Responses: When the rate limit is exceeded, Anypoint automatically returns a 429 status code (Too Many Requests). This clear response tells the client application that it needs to slow down. Retry-After

Every skill my AI setup learns lives in one folder on my laptop — and none of it reaches the repo I created yesterday. That gap is why I built a weekly job that pushes my accumulated skills into every project on the machine. This is what it does, and the four failures I hit getting it to run unattended. Why this mechanism works Claude Code's ~/.claude/skills/auto/ is essentially a personal "habits library." Workarounds, completion criteria, and verification commands discovered mid-task get written out to skill files automatically by the AI, and can be referenced immediately on the next request — that's how the mechanism is designed. Reality is a little different, though. Skills keep piling up in .claude/skills/auto/ . But a project in a freshly created git repo, a side-gig job opened for the first time in weeks, a set of tools written in another language — those don't have the skills at all to begin with . Unless a human copies them by hand, or I type "refer to that skill" every single time, the habits I so carefully accumulated are completely dead in other projects. The structure of the problem looks like this. Skills accumulate in one place, .claude/skills/auto/ (global) They're actually referenced only "when that project has .agents/ or .claude/skills/ " (local) That bridging doesn't happen each time you create a new project (zero start) This isn't "growing your environment," it's "regrowing it every time." Once monthly revenue crosses a certain line, the number of concurrent jobs rises, and there are weeks where I cut two or three new repos. Each time, noticing the missing skills, copying manually, verifying — that work quietly eats time. Not the duration of a single tool call, but the opportunity cost of "if that skill had been here, this would have taken three minutes." The weekly auto-distribution script solves this. Early every Sunday morning, it scans all git repositories and pours the skills in. Without a human doing anything, the project you open on Monda

Most social-media automation tutorials stop at “call the API on a cron job.” That works, but it leaves the hard questions unanswered. Which account is the automation using? How does it avoid posting the same story twice? What happens when an API request times out after X has already accepted the post? And where should an AI agent’s editorial freedom end? I recently built a scheduled X publishing workflow with Codex and xurl , the official command-line client for the X API. The result is not just a timer attached to an AI prompt. It is a small publishing system with four distinct layers: An X developer application with read-and-write user authentication. xurl , which stores the credentials and communicates with the X API. A fixed-account Codex skill that verifies the identity before every write. A Codex scheduled task that researches, checks history, drafts, and publishes. That separation is the important part. Codex can make editorial decisions, but it cannot casually choose an account or improvise the publishing command. The skill owns the deterministic write boundary, while the scheduled task owns timing and editorial policy. In this article, I’ll show you how to build the same architecture. X developer settings, API packages, Codex features, and command-line options can change. The workflow below was verified in August 2026, but you should check the current upstream documentation before using it in production. What You Will Need Before starting, you will need: Codex on a Mac with access to Scheduled tasks. An X developer account and an application with read-and-write permissions. Homebrew. A dedicated or clearly identified X account for the automation. A local project containing the source material or editorial context the agent should use. You should also decide what the automation is allowed to publish before you give it access to an account. A good editorial policy is specific enough to reject a story, not merely broad enough to describe a topic. For example,

I have a problem with my social media feed: there are some people whose content I find really valuable, but on the other hand, there is too much trivial content, so I waste too much time watching low-value videos... BAD DEAL!!! So, let’s solve this issue using AI automation. We can solve this issue by using Telegram as our own social media platform and using automation to make our own feed, far from the algorithms of social media platforms. Choose the people whose content you find really valuable. Use AI automation to monitor them whenever they publish a new video. Once a new video is published, AI sends it to a Telegram bot where you can download it. The person who gave me this idea is Abo Ziad (the Egyptian version of Ali Abdaal), and he is one of my favorite YouTubers. Personally, I think you can add some entertaining channels to make it more balanced. I’ll try this solution for one month, and if you’re interested, I’ll share my experience with you, whether it succeeds or fails. In the end, it’s up to you. Tell us in the comments if you found the general idea useful or not, and whether AI automation is the best solution for this issue.

Imagine waking up to a notification on your phone: "Your blood sugar levels are dipping. I've already analyzed your recent CGM (Continuous Glucose Monitor) trends and added low-GI complex carbs to your grocery cart." 🚀 This isn't science fiction anymore. With the rise of Autonomous Agents and specialized libraries like Browser-use , we can now bridge the gap between health data analysis and real-world actions. In this tutorial, we are building a personalized Nutritionist Agent that monitors health metrics and navigates the web just like a human to fulfill your dietary needs. By leveraging LangChain for logic and Browser-use for web automation, we’re moving beyond simple chatbots to "Action-Oriented AI." 🏗 The Architecture: From Insight to Action The workflow involves three main layers: the Data Input (CGM reports), the Brain (LangChain Agent), and the Hands (Browser-use + Playwright/Selenium). graph TD A[CGM Sensor Data] -->|GraphQL/JSON| B(LangChain Agent) B -->|Analyze Risk| C{Hypoglycemia Detected?} C -->|Yes| D[Identify Low-GI Foods] D -->|Navigate Browser| E[Browser-use Controller] E -->|Automate Shopping| F[Fresh Grocery Site] F -->|Action| G[Add to Cart & Notify User] C -->|No| H[Continue Monitoring] 🛠 Prerequisites To follow along, you’ll need a Python environment and the following stack: LangChain : For orchestrating the LLM logic. Browser-use : The star of the show for AI-driven browser navigation. Playwright/Selenium : To handle the underlying browser instance. OpenAI/Anthropic API : To power the reasoning engine. Step 1: Analyzing the Health Data First, we need to process the CGM (Continuous Glucose Monitor) data. We'll use GraphQL to fetch the latest metrics and LangChain to determine if the user needs a nutritional intervention. import os from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate # Mocking a CGM Data Fetcher via GraphQL logic def fetch_cgm_metrics (): # In a real scenario, use a GraphQL client to query your he

The morning after I lost my job, my Mac finished and filed an ASMR video. Nobody asked it to. It just ran. In the first post, I walked through the structure of the pipeline itself — ComfyUI × FFmpeg × the Freesound API, generating long-form ASMR videos with nothing but free tools. This second post covers the other half: putting that pipeline on macOS launchd so it fires at a fixed time every day, and the self-healing logic that gets the script past the "cold start" problem, where you boot the Mac and ComfyUI simply isn't running. Two numbers do most of the work here: the ComfyUI startup wait went from 180 seconds to 600, and the Freesound download timeout went from 90 seconds to 240. Before those changes, mornings failed 2–3 days a week. Why this setup works The ceiling on manual work Making a single 30-minute ambient ASMR video carefully takes 2–3 hours of hands-on time. Tuning image-generation prompts, layering the BGM, checking the loop points, building the thumbnail, filling in YouTube metadata — each step is small, but they stack up. Trying to hold 30 videos a month means 60–90 hours of pure labor. I attempted it while holding a side job, and it collapsed in two weeks. That was the first time I understood that "scaling output" isn't about moving your hands faster — it's about building a state where output accumulates without your hands at all. When I was laid off and my income went to zero, the first thing I rebuilt was this environment . Own an environment, not a workflow The essence of automation is constructing, exactly once, a mechanism where output keeps growing while you do nothing. That's precisely what daily.sh delivers: when the script finishes, ~/Desktop/ASMR/<date>_<theme>/ lands atomically with the video, thumbnail, youtube.md, and still image all in place. I just check it the next morning. Whether I step away mid-generation or I'm asleep, the files keep piling up. One line in the code embodies the whole philosophy: # 冪等性は「その日に1本でもあればskip」(1日1本・テーマ違

Setting up an API automation framework requires aligning business goals, developer specifications, infrastructure, and core testing strategies. Here is a comprehensive requirement checklist and workflow to ensure complete coverage across every stage of your API automation setup. 1. Requirements from Client / Business Owner Before writing code, define what needs to be tested: Business requirements (BRD) & user stories / use cases Expected API behavior & acceptance criteria (success & failure cases) Priority APIs (critical vs optional pathing) Performance expectations (SLA, response time) API versioning policy (backward compatibility expectations) Security & compliance requirements (data privacy, PII handling) 2. Technical Details from Developers Understand how the APIs operate: API Documentation: Swagger / OpenAPI specifications Endpoints: Base URL + specific paths HTTP Methods: GET, POST, PUT, DELETE, PATCH Request Details: Headers, query params, request body (JSON/XML) Response Details: Expected status codes (200, 201, 400, 401, 403, 404, 500) and response schema structures Authentication: OAuth, JWT, API keys, or Basic Auth Error Handling: Error codes & error messages API Contracts: Consumer-driven contract definitions (e.g., using Pact) Rate Limits & Throttling: Maximum request limits and wait strategies Downstream Dependencies: Dependent APIs required for mock/stub planning 3. Infrastructure & Environment Setup Coordinate with the Application Owner or Infra Team for execution requirements: Environment URLs: Dev, QA, UAT, and Prod environments Access Control: VPN access, API gateway setups, credentials Test Data Strategy: Valid, invalid, edge case, and boundary value datasets Data seeding scripts for pre-test setup Data teardown/cleanup scripts for post-test cleanup Data isolation per environment Database Access: Direct access for validating API output directly against DB records Mocking/Stubbing: Availability of tools like WireMock or MSW for dependent APIs Secr

Originally published on my Substack . I'm a Microsoft MVP based in Japan, writing in English about the AI agent systems I actually run in production. AI tools have multiplied. So have agents, skills, and automation scripts. And yet, somehow, my hands are never free. I wake up, open a dashboard, check notifications, go look at the logs for a failed job, and think, "wait, where was that process even running?" Every time I add one more automation, I add one more place I have to go check. That was me, up until last year. The cause was clear: I kept thinking about what to have AI do, and never once designed where I myself would touch things. So I rewrote my policy down to one line. There are only two things a human does: throw tasks into one place, and have conversations in one place. No other entry points get added. 🤖✍️ This article was co-written with AI — an AI agent (Claude Code) generated the draft automatically based on real collaborative work with Ebisuda, who then reviewed and revised it before publishing. In this series, I share the systems I've actually built using AI as case studies — including both the ones that worked and the ones that failed. What I Set Out to Build What I set out to build wasn't a specific tool or a specific agent. It was the design of the surface humans touch. The rule I settled on was just two lines. The only human entry points are Todoist (for dropping in things to do) and Discord (for conversation) Everything else gets pushed to the AI and scheduler side This is the opposite of "let's have AI do a ton of work." When people try to maximize what AI can do, they end up adding more tools. More tools means more settings screens, more places logs pile up, more places you have to go check "how's it doing now." Left unchecked, the number of automated processes and the number of places a human has to go look both grow together. So the thing I needed to decide first wasn't the scope of AI's work — it was the footprint on the human side. If you f

For three mornings in a row, my audit log printed the same line: published today: 0 / target: 3 . Nothing crashed. The scripts ran, exited, and produced nothing. The entire cause turned out to be a 41-second margin — a 300-second timeout against a process that actually takes 259 seconds. Changing one number to 600 turned 0/3 into 3/3 the next morning. Some background: I went from earning 100k yen a month as a university student to 600k a month juggling multiple gigs, then lost all of it overnight to a company-initiated layoff. Over the following six months I built an autonomous Claude Code environment, and I'm now above 1.2M yen in monthly revenue. At the core of it is a system that publishes three affiliate articles every morning without a human touching anything. Why this system works The difference between people who keep earning from affiliate marketing and people who drop out is not writing skill, and not a nose for picking products. It's whether you can keep going . Articles that tend to earn on Rakuten Affiliate share a common pattern: spec-comparison articles about home appliances and gadgets priced above 50,000 yen, with lots of reviews and in stock. Robot vacuums, portable power stations, heat-pump washer-dryers, fully automatic coffee makers. The search intent is "I want to compare before I buy," so product link click-through is high and it fits the structure of affiliate marketing well. The problem is cost. Researching the specs of a high-ticket appliance on the web, building a comparison table, and finishing an article good enough to include the "honestly weak points" section takes 30 to 40 minutes. Three articles is close to two hours. Almost nobody has the willpower to repeat that 365 days a year. I don't either. What you need here isn't "trying harder" — it's an environment that keeps running even when you don't try hard . Once the system is built, the running cost is just API calls. The affiliate-factory I built is a simple structure made of four sh

85 containers. 24 PostgreSQL databases. 67 domains. 232 cron jobs. One developer. 120 EUR/month in Hetzner bills. This is not a startup fantasy pitch. This is my production infrastructure for a SaaS ecosystem serving German golf clubs, a golf school management platform, a community platform, a CRM, and an auth service. Every customer gets their own database. Physical tenant isolation, not software filters. People tell me this cannot work. The containers disagree. The Stack Next.js for all frontends. Single-tenant PostgreSQL per customer (Supabase stacks). Docker on bare metal. Coolify for deployment orchestration. Traefik as the reverse proxy handling 67 domains. Two Hetzner servers in Germany. Total infrastructure cost: 120 EUR/month. The single-tenant architecture is a deliberate trade-off. Multi-tenant saves infrastructure cost, but one RLS bug exposes every customer's data. One compromised tenant enables lateral movement to all others. GDPR Article 17 deletion in multi-tenant requires complex cross-tenant queries. In single-tenant, deletion is DROP DATABASE . No residual risk. The cost is more operational complexity. Which is exactly why automation is not optional. 176 Guard Rules: The Immune System My AI agents (Claude Code with custom hooks) execute roughly 80% of daily development and operations work. That is dangerous without constraints. So I built a guard system: 176 shell scripts that fire on every command, every file edit, every session end. The architecture is simple. Four dispatchers route to context-specific guards: #!/bin/bash # Pre-Bash-Dispatcher: Loads guards based on command profile. # Not all 176 guards fire on every command. Profiling classifies # each command (git, docker, npm, database, deploy, comms) and # loads only relevant guards. set -uo pipefail GUARDS_DIR = " $( dirname " $0 " ) /guards" INPUT = $( cat ) CMD = $( echo " $INPUT " | jq -r '.tool_input.command // ""' ) # 8 security gates fire ALWAYS, non-negotiable: # tabu-gate, pii-gate,