Behind

Setting Up the Dev & Ops Environment for Our Secret Agents (Yes, You!)

Today, we're pulling back the curtain to show you how our team sets up and powers through work using agentic coding workflows. The AI landscape moves at lightning speed—honestly, even our own workflows transform every three to six months, so this guide might have a short shelf life! Still, unless the LLM paradigm flips completely upside down tomorrow, we figured documenting our setup as of September 2026 would spark some inspiration for your own creative and dev pipelines.

The biggest shift? We no longer treat AI agents as just another tool in the drawer. Instead, they’ve become our primary interface—the starting point and finish line for practically everything we build. The real game-changer is creating an environment where AI can seamlessly access and orchestrate across all tasks (dev & testing, docs, scoped database access, logging, monitoring, and even customer support), delegating and managing work right when you need it.

Remote Dev Servers & Powering Through the CLI

We keep our codebase and CLI tools hosted on a dedicated development server, remoting in via SSH from laptops or even on the go from mobile devices. Tailscale securely stitches together our private network access to the server and internal services. This means no getting tethered to a single machine—same repo, same rock-solid environment, anywhere in the world. Running tools like Claude Code (claude) or Codex CLI (codex) right on the server means instant feedback the moment code changes. Plus, having a 24/7 server running makes scheduling, automated tasks, and background jobs an absolute breeze.

Letting the Agent Take the Wheel (Responsibly!)

Skipping approval prompts to run chains of commands continuously—a setup affectionately known as "YOLO mode"—is a massive speed boost. When you're in a sandboxed remote dev environment running repetitive queries, running tests, or sifting through logs, it lets the AI blast through low-risk tasks without breaking your flow.

That said, going full YOLO expands the blast radius if an agent ever gets near production data or critical credentials. To keep things safe without slowing down, we set up guardrails: pre-execution hooks blocking sensitive files, mandatory confirmations for AWS infra changes, and strict locks on Cloudflare keys. Streamlining approvals doesn't mean leaving the front door wide open—it's all about moving fast with the right safety net!

Supercharging Claude's File Search

While we might not type out full file paths as often as we used to, quick file referencing is still a developer's best friend. In our testing grounds, tools like Codex usually nail the exact short path you want when mentioning a file. Claude's default file suggestions, on the other hand? Let’s just say it can test your patience a bit. That's why we took matters into our own hands and plugged a custom script into `fileSuggestion` inside `.claude/settings.json`.

This nifty script only sifts through files tracked by `git ls-files`, putting filename prefixes and concise paths front and center. Haven't typed a query yet? No problem—it greets you with recently modified files first. It locates project files way faster than the default setup! Just keep in mind the trade-offs: untracked files won't show up in suggestions, and you'll need the right permissions or external dependencies to run `fzf`.

Locking Down Sensitive Info (Because "YOLO" Shouldn't Apply to Security)

Running in bypass or "YOLO" mode might feel like having superpowers, but it expands the file perimeter your AI agent can poke into. That's pure convenience trading blows with security risks. If sensitive secrets like your `.env` accidentally sneak into the context window, they're out in the open. To keep our secrets actually secret, we run a tight, two-layer defense.

First off, our global instructions strictly forbid the agent from reading or printing `.env` files, AWS credentials, Cloudflare configs, private SSH keys, and token stores. Anything holding raw sensitive data—like `.env*`, `.aws/credentials`, `.cloudflared`, `.npmrc`, or `auth.json`—is totally off-limits for the agent. If values are needed, humans step in. The agent only gets to check non-sensitive identities or public metadata.

Here’s the catch: even with strict global rules, an over-eager agent might still try to sneak a peek at `.env` if it thinks it will help solve your problem. That’s why you need programmatic guardrails that actively block sensitive paths from ever slipping into chat. We combine deny lists in `.claude/settings.json` with a `PreToolUse` hook via `block-credential-access.py` to inspect file accesses and Bash commands. Risky actions like dumping all env vars, decrypting AWS Secrets Manager, logging Lambda environment variables, or running `wrangler secret` are stopped dead in their tracks (tagged with a clear `[CRED-GUARD]` prefix in the logs). Finally, we back it up with `.claudeignore` to filter out env files, build artifacts, and cache/upload folders—keeping context windows clean, lean, and worry-free!

If you'd like to set up these environment protection rules yourself, here's how you can prompt your AI agent.

※ Chatting with non-developers diving into "vibe coding," I've noticed security often takes a backseat. The mindset is usually, "Hey, if the database connects and it deploys, we're golden!" But here’s the catch: sensitive keys should never end up in your source code repository or even in your chat history with the agent. Sure, it might feel a bit tedious, but manage them directly via your terminal or a text editor. Let the agent work blindly with environment variable names without ever knowing the actual secret values.

Splitting Global Instructions and Documentation

`AGENTS.md` and `CLAUDE.md` serve as the default rulebooks that agents automatically reference before tackling project tasks. As your project grows, the list of things your AI needs to know expands fast. If you're not careful, your global instructions will balloon out of control—turning into a total token-guzzling monster.

That’s why global guidelines should only cover the essentials: the core tech stack, non-negotiable security rules, coding standards, and pointers to domain-specific docs. The agent just needs to know where things live, so keep it to brief summaries of what each document does and where to find it. Aim to keep your global rules lean and mean—ideally capped between 100 to 200 lines.

The agent will then smarten up: it determines whether your prompt actually requires extra context, loading only the necessary files for that specific session. Bye-bye, wasted tokens!

Running Custom Skills

Turn frequent tasks—like committing, code reviewing, opening Pull Requests, and handling Git routines—into modular skills. At Videostew, we rely on streamlined shortcuts like `cm`, `rv`, `pull-request`, and `aws`. These skills do way more than save you a few keystrokes; they standardize repetitive workflows and let you continuously level up your processes over time.

When it comes to building and managing skills, we live by two simple golden rules. First, we only build in-house when it's genuinely necessary. Let’s be honest—AI loves to bloat things up, whether it’s code or documentation. That’s why we never blindly copy-paste those "do-it-all" skills floating around the internet. Instead, we start with the bare minimum—just the core direction and purpose—and refine it through real-world use, adding edge cases and trimming the fat until it fits our project like a glove. Second, we only turn high-frequency tasks into skills. Packing too many skills into your setup bogs down initial session loading and clutters your recommendation list. For those "must-know but rarely used" details, we tuck them neatly into dedicated `docs` files instead.

At the end of the day, a skill is just another type of document for an AI agent to read. As long as you clearly outline the execution steps and decision-making criteria in a standalone `md` file, the end result is virtually identical to a full-blown skill. The real difference? Simply how often you need it, and how easily your agent can discover and trigger it.

All Your Infrastructure, Managed in One Place

We’ve set up our infrastructure management so our AI agent can handle the heavy lifting for lookups and repetitive routines. That means AWS CLI for AWS, Wrangler for Cloudflare, and the Google Cloud CLI `gcloud` command for Google Cloud. With the right CLIs and auth environments wired into our servers, there's no need to click through dizzying back-office menus. You just explain what you want in plain English, and the agent maps out the exact commands and workflows you need. It can even pull real-time traffic and cost metrics to help you crunch the numbers on projected expenses.

This is an absolute lifesaver, especially on AWS. While Cloudflare gives you that crisp, intuitive dashboard, AWS is a sprawling maze of hyper-granular services where you can easily lose an entire afternoon digging through settings. Having an agent connect the dots between related services and configurations saves you from reading endless manuals, letting you focus on what actually matters—shipping great work.

Of course, with great power comes great responsibility! Because infrastructure changes can make or break live services, we strictly enforce a pre-flight checklist within our global rules and skills. Before applying any live change, the agent must confirm the purpose, exact modifications, target environment, and blast radius. Better safe than sorry!

Keeping an Eye on Everything (So You Don't Have To)

Logs are a developer's best friend. In development, they’re your personal bug-hunting guide; in production, they’re the unsung heroes behind debugging, smart analytics, and lightning-fast customer support—vital when you're powering real-time AI video editing!

On our dev servers, there’s no need to broadcast logs to the outside world, so we store both frontend and backend logs locally as files. On the frontend, we hook into the browser's `console` methods and route them straight to a dedicated logging endpoint, which dumps them into a log file. The backend sticks to its framework's built-in logging paths. This setup lets our AI agent inspect test logs directly and patch issues on the fly—saving developers from the dreaded copy-pasting of console logs.

In production, reliability is the name of the game. Client-side errors travel through dedicated collection pipelines like AWS Lambda straight into CloudWatch. Meanwhile, backend framework errors are gathered via syslog and log agents right into CloudWatch Logs. We keep everything crystal clear by documenting which logs go to which CloudWatch resources and how to query them in our global playbooks.

Here’s why this matters to you (and us):

Centralizing error logs with CloudWatch means that even with distributed microservices, render nodes, and Lambda functions crunching video frames, everything is searchable under one roof. No matter the service or call stack quirk, centralized tracking lets our AI agent pinpoint root causes and match up the right code in a flash—keeping your video rendering smooth and uninterrupted.

Issue Tracking: Never Dropping the Ball

Working alongside AI agents is amazing, but it can spawn quite a few rabbit holes! While digging into Issue A, you often stumble upon a sneaky hidden bug, a blocker that must be solved first, or a tweak you solved but need to monitor later. When that happens, we lean heavily on GitHub Issues.

To make tracking effortless, we built a custom GitHub Issue skill (`/issue`). Whenever a tangent pops up during development, a quick command spins up a linked sub-issue. From there, we snap back to the primary task without losing momentum. These spin-off tasks won’t get lost in the void—they’ll wait patiently until we're ready. Plus, staying laser-focused on one problem at a time keeps our AI agent's context clean and slashes unnecessary token usage. Win-win!

Here’s a hard truth: many bugs aren't just about the code. When code meets real-world user data and live databases, that's when things get truly spicy. Dummy data in dev environments rarely tells the whole story, and if a bug doesn't trigger a red-alert error log, it might just stay hidden forever. In cases like this, once we wrap up a fix, we spin up a dedicated `watch` issue—or update the existing ticket—with a clear observation period and a review date. Dropping a `Due:` metadata tag on the very first line alongside tracking labels makes scheduling a breeze. Once that review date rolls around, we look at the real production data to decide: did we actually fix it, or do we need another round of tweaks?

Small Tasks Stay Small, Big Tasks Go Big

Look, we're a scrappy startup, which means we can't just throw ultra-high-IQ (and ultra-expensive!) AI models at every single sneeze. We have to be smart with our tokens. If you look at daily coding and operations, a massive chunk of work boils down to simple nudges: "check this," "run a quick test," or "let's tweak that." Even before tackling a monster task, you often run lightweight explorations just to get the lay of the land. Knowing this, we set our cost-effective, mid-tier model as the default workhorse (think Claude Sonnet or Codex Terra).

To make this work seamlessly, our global instructions guide the default model to delegate heavy lifting by summoning an advanced sub-agent whenever it senses danger (think Claude Opus/Fable or Codex Astra). This turns our everyday base model into a smart router—striking the perfect balance by deploying the right brainpower for the right job.

In practice, delegating means passing off the heavy scoping and detailed battle-plan creation to the big-brain sub-agent. Once that plan is ready, our standard model takes the reins to write the actual code. Is it flawless? Not quite. You will encounter delegation bottlenecks, and sometimes the base model overconfidently tries to juggle a high-tier task all by itself and makes a mess.

The fix? Clear guardrails. Update your global instructions so the model immediately delegates when it detects high-complexity tasks, security, auth flows, or database schema shifts. You should also instruct it to halt and call for backup if a task drags on or the scope blows up mid-way. Keep a crystal-clear division of labor: the main agent handles context injection, delegation, coding, and testing, while the sub-agent acts strictly as the master planner. Every project has its own tolerance, so experiment with your setup, see how it performs in the wild, and fine-tune those escalation thresholds as you go!

※ Fun fact: For Claude, there is a hidden gem called the 'opusplan' model. This lets us split our setup—using standard models for routine tasks and reserving the planning mode for the heavy lifting.

※ For mission-critical tasks that require laser focus right out of the gate, we just unleash the top-tier models from square one.

A Fully Integrated, Living Manual

Refund policies, prerequisites for processing refunds, account management rules, essential operational know-how... Internal service manuals can quickly turn into overwhelming encyclopedias. Plus, they need constant updates whenever edge cases pop up. Because the whole team contributes, having crystal-clear revision history without nasty merge conflicts is a non-negotiable must.

We solve this by managing our entire operational manual in a dedicated Git repository filled with modular Markdown files. The primary `README.md` acts as an intuitive gateway, mapping out which files cover which areas. We authenticate this repo via standard Git CLI or Git MCP and hook it straight into an AI skill (`/manual`). This means our agents can look up guidelines or push updates on the fly—seamlessly keeping our AI video editor running like clockwork.

※ A hierarchical document structure is our go-to pattern for everything from daily guidelines to operations. It’s an absolute lifesaver for slashing token costs while maximizing efficiency.

A Few Extra Pro Tips

--

And that wraps up our bird's-eye view of agent-centric development and operations! In our next post, we'll dive into Smart Token-Saving Hacks for AI Agents—stay tuned!