Behind

Setting Up Dev & Ops Environments for Our Secret (and Not-So-Secret) Agents

At Stew, we're sharing how we set up and utilize our environment for agentic coding. The AI landscape moves at breakneck speed—honestly, our own workflows evolve dramatically every 3 to 6 months—so this post might have a short shelf life. Still, as long as the core LLM paradigm sticks around, these insights should prove valuable. So, here's a snapshot of how we roll as of September 2026.

The key shift? We no longer treat AI agents as just another tool in our stack; they are now the primary interface—the starting point and the finish line for everything we do. It has become essential to build an environment where AI can access and operate across all workflows (dev, testing, docs, restricted DB access, logging, monitoring, and even customer support), assigning and orchestrating tasks on demand.

Remote Dev Servers & CLI Operations

We keep our codebase and CLI tools on a remote development server, accessing them via SSH from laptops or even mobile devices. Tailscale handles secure internal networking between our dev boxes and internal services. This means no more "works on my machine" headaches—we get a consistent repository and runtime wherever we are. The biggest perk? Running Claude Code (hereafter claude) or Codex CLI (hereafter codex) directly on the server to see results instantly after edits. Plus, a 24/7 server makes scheduling, repetitive jobs, and background automation an absolute breeze.

Letting the Agent Take the Wheel (Responsibly)

Skipping approval prompts to run sequential commands—often called `bypass permissions` or affectionately known as "YOLO mode"—is a game changer. It's incredibly handy in a remote dev setup for blazing through low-risk, well-defined tasks like repetitive grepping, running test suites, or digging through logs.

Of course, going full YOLO widens the blast radius. If the agent can touch production assets or credentials, a single hallucination could ruin your day. That's why we set up strict guardrails: pre-execution hooks to block sensitive files, mandatory confirmation before AWS infra changes, and strict access controls on Cloudflare tokens. Slashing tedious approval clicks is great, but letting an AI run wild without a safety net? That's a whole different story.

Supercharge Your File Search in Claude 🚀

While we might not type out full file names as often as we used to, seamless file referencing is still an absolute lifesaver. In my workflow, Codex usually nails the short path suggestions, but Claude's default file search can sometimes feel a bit… sluggish (to put it politely!). So, to keep our creative momentum rolling, I set up a custom script under `fileSuggestion` in `.claude/settings.json`.

This nifty script only scans files tracked by `git ls-files` and prioritizes clean prefixes and shorter paths. If you haven't typed a query yet, it smartly suggests recently modified files first. It lets you zip through your project assets way faster than the default search! The only trade-offs? Untracked files won't show up, and you’ll need `fzf` installed along with a few minor external dependencies—a tiny price to pay for speed, right?

Locking Down Sensitive Info: Don't Let Your Secrets Leak! 🔒

Switching into bypass or "YOLO mode" gives your AI agent massive superpowers, but with great power comes the risk of oversharing. Convenience should never cost you your security! If sensitive environment variables like `.env` accidentally sneak into the chat prompt, they’re out in the open. That’s why we run a rock-solid, two-tier security perimeter.

First, we establish clear global guidelines: the agent is strictly forbidden from reading or printing `.env`, AWS credentials, Cloudflare configs, private SSH keys, and secret token stores. Critical files packed with real secrets—like `.env*`, `.aws/credentials`, `.cloudflared`, `.npmrc`, or `auth.json`—are completely out of bounds. If a secret value is needed, humans handle the verification manually; the agent is only allowed to touch sanitized identity checks or public resources.

Here’s the catch: even with strict global rules, an overeager agent might still try to peek into `.env` if it thinks it’s being helpful. That's why you need an automated safety net to catch rogue requests. We enforce a deny list in `.claude/settings.json` paired with a `PreToolUse` hook in `block-credential-access.py` to inspect both file access and Bash commands. Any attempts to dump environment variables, decrypt AWS Secrets Manager, inspect Lambda envs, or run `wrangler secret` get slapped with an instant block and logged with a `[CRED-GUARD]` tag. On top of that, we use `.claudeignore` to filter out env files, build artifacts, and bloated cache or upload directories. Keep your context clean, lean, and completely secure! ✨

Want to set up your own environment guardrails? You can easily prompt your AI agent like this:

Separate Global Instructions from Detailed Docs

`AGENTS.md` and `CLAUDE.md` serve as the foundational rulebooks automatically referenced by your AI agents. As your project scales, the list of things your AI "needs to know" grows fast. If you're not careful, these global instructions will balloon into an endless novel—and become the primary culprit devouring your precious tokens (and wallet!).

That’s why global instructions should strictly stick to the essentials: your core tech stack, non-negotiable security protocols, key coding conventions, and a quick directory of where deeper docs live. Your agent just needs to know what exists and where to find it, so keep it to a snappy summary, purpose, and path. At Videostew, we enforce a strict diet: keeping global rules lean, ideally within 100 to 200 lines.

This way, the agent smartly decides whether a task actually requires reading extra files, pulling in only what’s needed for that specific session. Less bloat, zero wasted tokens!

Leveraging Custom Skills

For repetitive daily workflows like committing, reviewing, creating pull requests, or Git operations, we turn them into reusable "Skills." Here at Videostew, we rely on shorthand commands like `cm`, `rv`, `pull-request`, and `aws`. These skills do a lot more than save a few keystrokes—they standardize repetitive routines and let you continuously fine-tune the workflow over time.

We build and manage our custom skills around two simple rules: First, we craft them in-house only when genuinely needed. AI loves to over-engineer code and documentation, so we steer clear of "do-it-all" skills copied off the web. Instead, we start with the simplest version focused purely on the immediate goal, and iterate naturally by adding edge cases as we work. Second, we only automate high-frequency tasks. Having too many skills clutters session initialization and recommendation prompts. If a task is rare but important, a standalone doc in `docs/` is all you need.

At the end of the day, a skill is simply another type of document that an AI agent reads. Even with a separate `md` file, as long as you provide clear execution steps and decision criteria, the final output isn't all that different from a pre-packaged skill. The real difference comes down to usage frequency, discoverability, and how effortlessly it can be called upon.

Managing Infrastructure in One Place

We set up our AI agents to handle most infrastructure lookups and repetitive maintenance tasks. For AWS, we lean on the AWS CLI; for Cloudflare, it's Wrangler; and for Google Cloud, we run the Google Cloud CLI's `gcloud` commands. Once the CLIs and authentication environments are wired up on the server, you no longer have to wander aimlessly through labyrinthine back-office dashboards. Just describe what you need in plain English (or natural language!), and the agent figures out the required commands and steps. It can even crunch traffic and billing metrics to help you estimate costs on the fly.

This is an absolute lifesaver when dealing with AWS. While Cloudflare’s dashboard is delightfully clean and intuitive, AWS breaks services down into a million granular pieces—meaning you can easily spend half your day just hunting for the right toggle. When an agent maps out related services and configurations for you, you can skip the tedious rabbit holes and focus on what actually moves the needle.

That said, infrastructure changes can make or break live services (and we definitely don't want any accidental outages!). That's why having strict pre-flight confirmation steps in your global guidelines or skill routines is a non-negotiable must. The agent should always verify the operational goal, proposed edits, target scope, and potential blast radius before executing any changes.

Keeping Eyes on Everything

Logs are your best friend during development for bug hunting, and they're indispensable in production for debugging, analytics, and resolving customer issues before they even notice.

In dev environments, there’s no need to blast logs off to external platforms, so we simply dump both backend and frontend logs into local files. On the frontend side, we hook into browser `console` methods to ship logs directly to a designated logging endpoint, which then appends them to a file. The backend uses the framework's native logging setup. This lets our AI agent inspect test logs directly and patch errors right on the spot—saving developers from the soul-crushing routine of manually copying and pasting console errors back and forth!

In our production environment, errors 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 ships framework errors to CloudWatch Logs via syslog and log agents. We make sure to document which CloudWatch resource holds each log type—and how to query them—in our global engineering guide or dedicated logging docs.

Here’s why this matters for your workflow:

By centralizing error logs in CloudWatch, you can search and diagnose issues the exact same way—even if your features are scattered across multiple servers and serverless functions. Regardless of differing logging formats or call stacks across services, a centralized log hub lets you trace problems effortlessly. This makes it a breeze for our AI agents to pinpoint bugs and cross-reference the relevant code in no time.

Bulletproof Issue Management: Never Drop the Ball

When you're building alongside AI agents, side quests pop up fast. You start digging into Issue A, and suddenly you uncover a hidden bug, a blocker that needs fixing first, or a tricky edge case you resolve for now but need to monitor via logs later. This is where GitHub Issues becomes our absolute superpower.

To keep the momentum going, we set up a dedicated GitHub Issue skill (like /issue). Whenever a rabbit hole appears mid-development, we just trigger this skill to spin off a sub-issue on the fly. Then, we snap straight back to tackling Issue A. These branched issues stay safely tracked on our radar so nothing slips through the cracks. Plus, keeping the focus tight on one problem at a time preserves the agent's context window and saves precious tokens!

The truth is, many bugs don't just live in the code—they only trigger when real user data meets the production database. You simply can't catch these with dummy test data in staging, and if they don't trigger hard error alerts, they might stay buried forever. Our solution? Once a patch is shipped, we create a dedicated watch issue—or add an observation plan to the existing issue—with a set monitoring window and review date. By slapping a Due: metadata tag on the very first line alongside smart labels, tracking the review date is effortless. When it’s time to review, we simply inspect the collected data and determine whether the issue is genuinely resolved or needs another round of polish.

Keep Small Tasks Small, Big Tasks Big

Look, we're an ambitious (read: budget-conscious) startup, which means we can't just throw top-tier, ultra-smart AI models at every single sneeze. That got us obsessing over maximum model efficiency. When you're coding or running day-to-day operations, a surprising chunk of tasks boils down to simple stuff: "check this," "verify that," "let's tweak this." Even before diving into heavy-duty jobs, you often run lightweight scans just to scope things out. Factoring all this in, our default workhorse is a cost-effective, mid-tier model (think Sonnet for Claude, or Terra for Codex).

To make this work seamlessly, we set global rules so that when a task gets truly hairy, the default model automatically summons a high-level sub-agent to delegate the heavy lifting (like Opus or Fable for Claude, Sol High for Codex). This turns our base model into a smart router that picks the right brain for the right job, keeping everything balanced and cost-efficient.

Here’s how delegation works: the sub-agent scopes the impact and drafts a battle plan. Once it hands that plan back, the base model rolls up its sleeves and writes the actual code. Of course, it's not pure magic—there are trade-offs. The main bottlenecks are the slight delay during handoffs, and the occasional hiccup where the base model overconfidently butchers a task it should have passed up the chain.

The fix? Fine-tune your global prompts. Tell it to automatically escalate when dealing with high-complexity tasks, security, auth, or DB schema changes—or to abort and delegate if a task takes too long or balloons in scope. Keep a crystal-clear division of labor: the main agent handles routing, context injection, coding, and testing, while the sub-agent focuses purely on planning. Escalation thresholds will vary by project, so treat it like tuning an instrument until it fits your workflow perfectly.

※ Pro tip for Claude users: there's an unlisted mode called 'opusplan' that lets you separate models for general execution versus planning mode.

※ And yes, if we know from minute one that a task is a monster, we don't play around—we bring in the heavy-hitter model right from the start.

The All-in-One, Fully Integrated Manual

Refund policies, checklists for processing refunds, account rules, the bare minimum ops knowledge to keep the lights on... Internal manuals are absolute beasts. They grow endlessly and demand real-time updates whenever a quirky edge case pops up. Plus, with the whole team chipping in, clean version history and zero merge drama are absolute must-haves.

Our secret sauce? We manage our entire ops manual in a dedicated Git repository packed with Markdown files. The front door—our README.md—acts as the ultimate directory, mapping out exactly which file covers what domain. We hooked this repo right into our setup via the standard Git CLI or Git MCP and wired it up as an AI skill (/manual). The result? Our AI agent can pull up or tweak any doc on the fly, whenever duty calls.

※ Pro-tip: This hierarchical doc structure is a recurring superpower for us—both for general guidelines and day-to-day runbooks. It keeps token usage delightfully low while maximizing efficiency!

A Few Extra Notes from the Trenches

--

That wraps up our high-level look at how we build and run things agent-first! If we missed anything juicy, don't worry—we’ll break it down in future posts. Stay tuned!