Behind

Setting Up the Dev & Ops Environment: A Field Guide for Our Agents (Yes, You!)

Today, we're pulling back the curtain to share how we set up and supercharge our environment for agent-based coding here at Stew! The AI landscape moves at breakneck speed—honestly, our own workflow evolves completely every 3 to 6 months—so this post might have a short shelf life. But hey, as long as the LLM paradigm holds steady, we figured our hands-on experience could spark some ideas. So, here’s a snapshot of how we roll as of September 2026!

The secret sauce? We don’t treat AI agents as just another tool in our kit. Instead, they’ve become our primary interface—the starting line and the finish line for virtually everything we do. It’s no longer just about chatting with an AI; it’s about plugging our agents into all our day-to-day operations (development, testing, documentation, scoped databases, logging, monitoring, and even customer support) so they can navigate, execute, and help manage tasks on demand.

Remote Dev Servers & CLI Magic

We keep our codebase and CLI tools on dedicated dev servers and simply SSH in from our laptops—or even on the go from our phones! Everything connects securely through a Tailscale private network. This means zero tethering to a single machine: same repo, same runtime, anywhere in the world. Running Claude Code (or Codex CLI) directly on the server lets us see changes instantly in the dev environment. Plus, with servers humming 24/7, automating scheduled routines and repetitive tasks becomes an absolute breeze.

Letting the Agent Take the Wheel (Responsibly!)

Skipping approval prompts to run commands back-to-back—often dubbed "bypass permissions" (or affectionately, YOLO mode)—is a massive time-saver. It’s fantastic for blazing through low-risk, well-defined tasks like repetitive searches, quick tests, and log lookups in a remote sandbox.

Of course, "YOLO" shouldn’t mean playing with fire. Granting bypass permissions widens the agent's reach, and if it has access to production or live credentials, an AI slip-up can get spicy real quick. That’s why we bake in guardrails: hooks blocking sensitive files, mandatory confirmations before AWS modifications, and strict limits on Cloudflare secrets. Slashing friction isn’t the same as letting chaos run wild—smart automation is safe automation!

Supercharging Claude's File Search (Because Waiting Around is So Last Year)

While we might not ping specific files as often as we used to, seamless file referencing is still an absolute lifesaver. In our daily workflow, we noticed Codex does a great job suggesting neat, concise file paths on the fly. Claude's default file suggestions, on the other hand? Let’s just say it can test your patience a bit. To keep our creative momentum going, we decided to hook up a custom script under `fileSuggestion` in `.claude/settings.json`.

This script zeroes in only on tracked files via `git ls-files`, putting clean file prefixes and tidy, short paths front and center. If your search query is empty, it smartly pulls up your most recently modified files first. The massive upside? Finding project files is blazingly fast compared to the default setup! The slight trade-off: untracked files won't show up in suggestions, and you'll need the permissions to install `fzf` or juggle a few external dependencies.

Locking Down Sensitive Data: Safety First, Always! 🛡️

When running in 'bypass' or full YOLO mode, AI agents get pretty adventurous with the files they touch. Sure, it feels super smooth and convenient—until it accidentally becomes a security nightmare. If sensitive environment variables like your `.env` secrets slip into the chat context, game over. That’s why we run a strict, two-tier security shield behind the scenes.

First off, our global instructions lay down the law: the AI agent is explicitly forbidden from reading or printing `.env` files, AWS credentials, Cloudflare configs, private SSH keys, token vaults, and the like. Files holding raw secrets—like `.env*`, `.aws/credentials`, `.cloudflared`, `.npmrc`, and `auth.json`—are completely out of bounds. If a secret value is ever needed, human hands handle it directly; the agent sticks strictly to public checks or identity confirmations that keep the juicy details hidden.

Here’s the catch: even with ironclad prompt rules, enthusiastic AI agents love to "help out" and peek at `.env` anyway when they hit a roadblock. That’s why you need an unyielding mechanical blocker to stop credential leaks dead in their tracks. We use a deny-list in `.claude/settings.json` paired with a `PreToolUse` hook in `block-credential-access.py` to inspect every file read and Bash command. Commands that dump all env vars, decrypt AWS Secrets Manager, spill Lambda variables, or invoke `wrangler secret` get slapped with an immediate block tagged with `[CRED-GUARD]`. Finally, our `.claudeignore` sweeps away config files, build artifacts, cache folders, and upload directories to keep our context clean, lean, and totally secure.

Want to set up these eco-friendly guardrails yourself? You can simply ask your AI agent with a prompt like this:

Separate Global Rules from Deep Docs

`AGENTS.md` and `CLAUDE.md` serve as the default rulebooks that your AI automatically reads before jumping into project tasks. As your project grows, the list of things your AI needs to know gets endlessly longer. Left unchecked, your global rules become a massive bloatware file—and the ultimate token incinerator! 🔥

That’s why global guidelines should only hold the essentials: your tech stack, non-negotiable security rules, core coding conventions, and a clean map of reference docs. To make sure your agent knows where to look, just include a brief summary, purpose, and file path for each document. Following this strategy, we keep our global rules lean and mean—aiming strictly for under 100 to 200 lines.

Your AI agent can then determine if your request actually needs extra files and loads only what's required for that specific session. Bye-bye, token waste!

Supercharge with Custom Skills

Frequent, repetitive tasks—like committing, code reviewing, opening PRs, and Git routines—are bundled into reusable "skills." Here at Videostew, we use handy shorthands like `cm`, `rv`, `pull-request`, and `aws`. Skills do much more than save keystrokes; they standardize repetitive workflows and allow you to refine procedures over time.

We build and manage our skills based on two simple golden rules: First, create them by hand, only when truly needed. AI loves to bloat code and docs, so we never blindly copy-paste "do-it-all" skills found online. Instead, we start with the simplest version built around a clear purpose, test-drive it ourselves, and fine-tune edge cases as we go. Second, turn only high-frequency tasks into skills. Hoarding too many skills clutters session loading and recommendation lists. For important yet infrequent knowledge, stash it in dedicated docs under `docs` instead!

At the end of the day, a "Skill" is just another form of documentation for an AI agent to read. Even in a simple `.md` file, as long as you clearly outline the execution steps and decision-making criteria, the end result isn't all that different from a native skill. The real difference comes down to frequency: how often do you need it, and how easily can you discover and trigger it?

Managing Infrastructure from a Single Hub

We set up our AI agents to handle the heavy lifting for routine queries and repetitive tasks across our infrastructure. That means relying on the AWS CLI for AWS, Wrangler for Cloudflare, and the `gcloud` command for Google Cloud CLI. Once the CLI and authentication environments are wired up on the server, you can ditch the headache of navigating endless back-office menus. Simply describe what you want in plain English, and the agent identifies the right commands and procedures. It can even pull traffic and cost metrics so you can keep tabs on your budget before running anything expensive (goodbye, surprise bills! 💸).

This is an absolute lifesaver when dealing with AWS. While Cloudflare’s dashboard is relatively sleek and intuitive, AWS is split into countless granular micro-services—spending hours just hunting down a single toggle is all too common. By letting an agent map out the relationships between services and configurations, you skip the steep learning curve and jump straight into creating.

That said, because infrastructure changes directly impact production (and nobody wants unexpected downtime on video render days), having a safety net is non-negotiable. Always embed a dry-run or pre-check process into your global instructions or skills: verify the objective, the exact changes, target resources, and potential blast radius before applying any real updates.

Keeping Eyes on Everything: Smart Monitoring

Logs are a developer's best friend—critical for debugging during development, and vital for stats and customer support once live.

In dev environments, there's no need to blast logs to external platforms; writing backend and frontend logs to local files does the trick. On the frontend, we intercept the browser's `console` methods to pipe logs directly to a dedicated logging endpoint, which saves them to a file. The backend simply leverages the framework’s default logging path. This lets the agent inspect runtime logs firsthand during tests and apply quick fixes on the spot—saving developers from the tedious ritual of copy-pasting terminal lines back and forth.

In our production environment, errors originating from the client-side are routed through a dedicated pipeline into an ingestion layer like AWS Lambda and stored directly in CloudWatch. Meanwhile, our backend gathers framework errors into CloudWatch Logs using syslog and custom log agents. We make sure to document which CloudWatch resources store each log type—along with search guides—either in our global guidelines or dedicated documentation (because nobody likes hunting for lost clues!).

Here is how this keeps our video editor running silky smooth.

By centralizing error logs in CloudWatch, we can search through issues consistently—even when our heavy-lifting features are distributed across multiple servers, workers, and Lambda functions. Even if different services spit out unique logging formats and call stacks, centralized logging lets us pinpoint bottlenecks instantly. This makes it a breeze for our agents to track down where things went wrong and cross-reference the relevant code before your video export even misses a beat.

Issue Management: Leaving No Bug Behind

When developing alongside AI agents, projects tend to branch out way faster than you’d expect. You dive deep into fixing Bug A, only to stumble upon hidden edge cases, prerequisite roadblocks, or “resolved for now, but definitely need to double-check the logs later” scenarios. Whenever this happens, we lean heavily into GitHub Issues.

We set up a quick slash command skill (/issue) so we can summon GitHub Issues seamlessly. Whenever a rabbit hole appears mid-development, we fire off this command to spin up a sub-issue right on the spot. Then, we snap right back to tackling our primary objective, Issue A. These branched issues stay safely on our radar, ensuring we never drop the ball before a fix is delivered. Plus, staying laser-focused on a single task keeps the agent's context clean and saves precious token usage!

The tricky part? Many bugs look spotless in isolated code, only to act up when tangled with real-world user video assets and production databases. Dummy data in dev environments rarely tells the whole story, and quiet quirks that don't throw an error-level alert can stay buried forever. That's why, post-development, we create a dedicated watch issue—complete with an observation window and review date—or tack on an observation plan to existing tickets. By utilizing Due: metadata in the issue’s first line alongside labels, tracking review timelines becomes automatic. When it’s time to say, “Let’s check the issues past their observation window,” we can evaluate real metrics to confirm if a bug is truly squashed or if it needs a little extra polish.

Keep Small Tasks Small, Big Tasks Big

As a scrappy startup, our wallets aren't exactly overflowing, meaning we can't just spam top-tier AI models 24/7. So, we obsess over getting the absolute most bang for our buck. When coding or managing operations, a surprising amount of daily grind boils down to simple stuff: "check this," "verify that," or "let's do X." Even before tackling hefty tasks, we often run lightweight probes just to get the lay of the land. Taking this into account, our go-to cost-effective strategy is setting a mid-tier model as our default driver (like Sonnet for Claude, or Luna/Terra for Codex).

To make this work seamlessly, our global system prompt instructs this default model to autonomously call in a heavyweight model as a sub-agent whenever things get hairy (think Opus or Fable for Claude, Sol High for Codex). In essence, our base model doubles as a smart router—striking that sweet balance by delegating the heavy lifting only when necessary.

Delegating looks like this: the sub-agent is tasked with assessing the blast radius and drafting an action plan. Once it hands that blueprint back, our everyday base model rolls up its sleeves and implements the code. It’s not all sunshine and rainbows, though. The trade-offs? You might hit occasional bottlenecks during handoffs, and sometimes the base model overconfidently butchers a complex task it really should have escalated in the first place.

The fix? Give it clear boundary rules. Instruct it to escalate when it smells hardcore challenges, auth/security updates, or database schema changes—or simply when a task starts dragging on and expanding in scope. Keep a crystal-clear division of labor: Main Agent (delegating, context injection, coding, and testing) vs. Sub-Agent (strategic planning). Escalation thresholds naturally vary across projects, so feel free to fine-tune those boundaries on the fly to match your workflow.

※ Pro tip for Claude users: There’s an unlisted 'opusplan' setup that lets you neatly decouple your planning mode model from your general environment.

※ Of course, if a task looks like an absolute beast right from the get-go, we don't beat around the bush—we just bring out the big-gun models from square one.

A Fully Integrated, Living Manual

Refund policies, refund checklists, account rules, the essential "don't break this" operational knowledge... internal service manuals are massive beasts. Plus, they need constant updates every single time a wild edge case appears. Since everyone on the team has to chip in, clean version history and zero merge conflicts are absolute musts.

Our secret weapon? We run our entire operational manual as a dedicated Git repository packed with clean Markdown (.md) files. The entry point, README.md, acts as the ultimate air traffic controller—mapping out exactly which files cover which areas. By authenticating this repo via the standard Git CLI or Git MCP and wiring it up as an AI skill (/manual), our agents can look up guidelines or push updates instantly on the fly. Cool, right?

※ Pro-tip: This hierarchical document structure is our go-to pattern for everything from general SOPs to operational playbooks. It keeps things super efficient while saving precious LLM tokens!

A Few Extra Pro-Tips from the Trenches

--

We've kept this overview focused on the core essentials of our agent-driven development and operations. For anything we missed, stay tuned—we'll dive into the details in upcoming posts!