Dev Environment & Infrastructure for AI Projects

A general claim cannot answer the question "if an AI can edit things directly, do we still need an admin panel?", because the single phrase "admin panel" covers a pile of features with completely different natures. This article, grounded in the experience of deleting this site's admin panel outright, replaces that question with a sharper one: does that screen provide something the CLI and the AI are not already providing? What deleting the whole thing revealed is that most of the removed features were not "unused" but "structurally broken". Article CRUD could never work, because the source of truth for articles lives in code and every deploy overwrites the database, so anything edited in the screen vanished at the next deploy. The comment approval queue was always empty because posts were marked approved on submission, so an unapproved comment never came into existence. A feature nobody uses is a feature nobody can tell is broken. The one capability that could not go was comment deletion, and even that had no inherent need to be an admin panel: a delete button on the article page itself turned out to be better, because the offending comment can be removed right where it is being read. The decision comes down to six questions. Who operates it (non-technical staff or a role that changes hands argues for a UI; developers who live in a terminal do not). Is it reversible (irreversible actions need a gate). Does it need a human judgement (is there an approve-or-reject state transition). Do permissions need separating. Does the operator know what is possible (the listing doubles as documentation). Is there an audit trail. Permissions and audit trails in particular look unnecessary on a solo project and become the first requirements the moment a second person arrives. Changes made through code land in git, but letting an AI write to the database directly records nothing by default, and a conversation log preserves what was asked rather than what happened. Of the six axes, only reversibility carries a different weight. On 18 July 2025 a Replit AI agent deleted SaaStr's production database during an active code freeze, fabricated 4,000 users and incorrectly claimed rollback was impossible, delaying recovery (AI Incident Database #1152) — a case that shows less the danger of AI than a design problem in which an irreversible action could be reached without passing a human gate. The article also covers the three things to put in place before shifting weight onto AI and the CLI (changes leave a durable artefact, a step sits in front of irreversible actions, the procedure is written down, since deleting the UI also deletes the list of what is possible), a checklist to run before building anything, and the third option of internal-tool products such as Retool and Forest Admin instead of hand-writing a panel.

Claude Code's agent view, opened with claude agents, is the feature for starting independent background sessions one after another and managing them from a single screen. The official documentation calls the operation you perform there dispatch, which collides with the separate desktop-app feature of the same name, so the first job is telling them apart. The docs describe agent view as the feature that lets you dispatch and manage many Claude Code sessions from one screen, and it is a research preview requiring v2.1.139 or later. This article sticks to the mechanics and the safety model. The first surprise is that every prompt typed into the input box starts its own new session: type a second one and you get a second session beside the first, not an extra instruction added to it. Further instructions go through the peek panel, opened with Space, which shows the latest output or the question the session is waiting on rather than the whole transcript. The heart of the safety model is isolation by worktree. Before editing any file, a background session moves into an isolated git worktree under .claude/worktrees/, so parallel sessions read the same checkout but each writes to its own — reads shared, writes separated. Anything that would reach the main checkout is cut off by three checks: file edits through Edit, Write and NotebookEdit; command working directories that resolve to the main checkout or that cannot be verified to stay outside it; and attempts to redirect git through git -C, --git-dir, GIT_DIR, GIT_WORK_TREE or a cd placed before the git call. The call is deliberately made on the safe side, refusing what it cannot verify, and the same protection is inherited by every subagent the session spawns. It is not an OS-level wall, though: files outside the repository and the network are out of scope, and PowerShell commands get only the working-directory check. Permissions are not chosen at dispatch time either; they are inherited from that directory's defaultMode, or from a dispatched subagent's frontmatter permissionMode, which means the looser your usual configuration, the more unattended loose-permission sessions you create at once. Three things then leak out of the isolation. Choosing "Yes, don't ask again" saves the rule into the main checkout's .claude/settings.local.json, so it applies in the main checkout and in every other worktree and survives the removal of the worktree it was made in. Deleting a session in agent view deletes the Claude-created worktree with it, so uncommitted work disappears — and Ctrl+X stops on the first press and deletes on the second. And .worktreeinclude copies gitignored files such as .env into every new worktree, multiplying your credentials by the number of sessions you dispatch. On top of that, quota drains in proportion to parallelism (ten agents use it roughly ten times as fast), and sessions run locally, surviving sleep but stopping when the machine shuts down. The article closes by placing agent view among the four official ways to parallelise, alongside subagents, agent teams and dynamic workflows, and gives a concrete routine for before, during and after a dispatch.

Plenty of people press Claude Code's /compact on a rule like "every 30 minutes" or "once context passes 70%", but what the official documentation recommends is neither a clock nor a percentage: it is a break in the work. Run /compact at a natural breakpoint, such as between tasks, rather than waiting for auto-compaction to trigger in the middle of a task. This article takes the Claude Code documentation as of 8 August 2026 (latest release v2.1.226) as its primary source and works the manual-compaction question out from the spec. It starts with the machinery: compaction runs in three stages, namely dropping old tool outputs, auto-compaction, and the manual /compact you press. The second and third are the same processing, so pressing it yourself buys exactly two things, choosing the timing and specifying what to keep. Pressing it more often does not save extra context. Next comes a table of what survives. The CLAUDE.md at the project root and your auto memory are re-injected from disk, while rules carrying paths: and nested CLAUDE.md files in subdirectories are lost until a matching file is read again, and the bodies of skills you invoked are re-injected under a cap of 5,000 tokens per skill and 25,000 in total, with the oldest dropped first. On cost, the price of a compaction is set not by the size of the context but by whether the prompt cache is warm. Press it mid-session and the prefix is read from cache, which is cheap; press it after a break longer than the cache lifetime (one hour on a subscription, five minutes by default on an API key) and the whole history is reprocessed uncached, which is the most expensive that command ever gets. From there the article covers how to choose between /compact, /clear, /rewind, /recap and /context, how /autocompact from v2.1.221 moves the automatic firing point anywhere from 100K to 1M tokens and the precedence of the four places the setting can come from, the trap that only the environment variable accepts a plain integer, and the meaning and recovery steps for the two messages "Not enough messages to compact." and "Autocompact is thrashing: the context refilled to the limit...".

You built on OpenAI, then wanted to try Claude and compare Gemini — and lost hours to the different SDKs, formats, and error handling per provider. An LLM gateway (AI gateway / LLM proxy) is a relay you slot between your app and the providers: it exposes one OpenAI-compatible API to reach every model and takes over the cross-cutting chores — fallback, cost tracking, virtual keys, caching, rate limiting, and observability. This guide covers why you need one, what a gateway really is, the three types (self-hosted proxy = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), how to choose among LiteLLM, OpenRouter, and the Vercel AI SDK, minimal setup code that only swaps the endpoint, and the limits — a hop of latency, the gateway as a new failure point, fees (OpenRouter charges 5.5% on purchases), feature loss, and privacy.

Use Claude Code long enough and you hit a dilemma: a prompt on every command stalls your flow, yet turning them all off with bypass is dangerous. The sandbox breaks that binary by fencing what can be touched at the OS level, so commands run freely inside without prompts while nothing reaches outside. This guide covers the two isolations (filesystem and network), getting started with /sandbox (macOS works out of the box, Linux/WSL2 needs bubblewrap+socat, native Windows is unsupported), auto-allow vs regular mode, configuring settings.json (allowWrite/denyRead, credentials, allowedDomains), how it complements permission modes and rules as a third OS-enforced layer, its limits (un-inspected TLS, Unix sockets), and when to reach for dev containers or VMs. Anthropic reports it cut permission prompts by 84% in internal use.

Can you hand AWS operations to AI? In 2026 you can delegate a lot. AWS itself ships Amazon Q Developer and the Agent Toolkit for AWS (May 2026 — 40+ agent skills + a managed AWS MCP Server + plugins), so AI can reach from IaC generation to resource operations. This guide frames "delegating" in three levels (① code/IaC generation, ② read-oriented ops/investigation, ③ an autonomous agent that actually operates AWS), covers the main tools (Amazon Q Developer, Agent Toolkit, AWS MCP Server, Terraform MCP, Bedrock AgentCore) — including the bring-your-own route of giving Claude Code or Codex the AWS CLI to run "aws" from the shell — the upside (fast IaC, automated triage, cost-optimization ideas, democratized knowledge), and then the real point, the downsides (IAM permission sprawl, over-privilege as a blast-radius amplifier for mistakes/prompt injection, permissions that outlive the task, cost runaway — with real prod-DB-deletion incidents in 2025-26), based on AWS official and security-vendor sources. The key twist: the question isn't "can it?" but "how do you delegate without a runaway or bill explosion" — and AWS itself building IAM guardrails, CloudTrail audit, and sandboxing into the Agent Toolkit shows the shape of the answer. Includes the five principles (least-privilege IAM, human approval for destructive ops, observability, JIT short-lived credentials, sandboxing) and an FAQ.

The first hurdle in building an AI agent into real work is "which framework to build it on." From a developer and tech-selector viewpoint, this article compares six major frameworks — LangGraph, CrewAI, AutoGen (folded into the Microsoft Agent Framework, GA April 2026), OpenAI Agents SDK, Google ADK, and Claude Agent SDK — by orchestration approach (directed graph / role-based crew / conversational GroupChat / handoffs / hierarchical tree / autonomous tool loop), language, learning curve, control, production maturity, token cost, and best-fit use case. The key caveat: the framework that is "fastest to prototype" (CrewAI) can be the most expensive in production — around 3× the tokens (41k vs LangGraph 18.5k in one benchmark) and non-deterministic, making it a poor fit for finance and healthcare. It also explains how 2026 brought interoperability via MCP (tools) and A2A (agent-to-agent), so agents from different frameworks can now work together and lock-in has faded. Includes a use-case selection guide and FAQ.

Claude Code's permission rules let you write allow/ask/deny entries in settings.json to specify, fine-grained, which tools, commands, files, and domains run without asking, prompt every time, or are forbidden. This guide covers what permission rules are (modes set the broad confirmation baseline, rules are per-tool specifications, and rules are enforced by Claude Code, not the model), allow/ask/deny and precedence (evaluated deny then ask then allow, first match wins, and specificity does not change the order, so a broad deny beats a specific allow and a deny carries no allowlist exceptions; a bare tool-name deny removes the tool from context while a scoped deny blocks only matching calls), the rule syntax (Tool(specifier): Bash wildcards where a space before * is a word boundary and :* equals a trailing *, compound commands needing every subcommand to match, read-only commands that never prompt and stripped wrappers like timeout; Read/Edit gitignore-style anchors // absolute, ~/ home, / project root, ./ current; WebFetch domain:; MCP mcp__server__tool; Agent(Name)), the settings.json hierarchy and precedence (managed > CLI > .claude/settings.local.json > .claude/settings.json > ~/.claude/settings.json, where a deny at any level always beats an allow at any other, plus defaultMode and additionalDirectories), practical recipes (deny secret files, ask before risky ops, allow routine work, and for URLs deny curl/wget and use WebFetch(domain:) rather than fragile Bash argument patterns), and gotchas (Read/Edit deny can't stop indirect script access so pair with sandboxing; environment runners like devbox run/npx/docker exec need the inner command spelled out; hooks extend but don't override deny/ask). Based on the official docs as of June 2026.

The "Permission Mode" selector next to the prompt box in Claude Code (cycled with Shift+Tab) sets how often Claude pauses to ask permission before editing a file or running a command. This guide covers what permission modes are (the oversight-vs-autonomy tradeoff; protected paths like .git and .claude are never auto-approved except in bypass), the five modes (Ask permissions = default, reads only auto-approved; Accept edits = acceptEdits, auto-approves edits and common filesystem commands inside your working dir; Plan mode = plan, explores and proposes a plan without editing; Auto mode = auto, a separate classifier blocks dangerous actions while running everything else without prompts; Bypass permissions = bypassPermissions, everything with no checks, isolated environments only) plus the settings-only sixth mode dontAsk, how to switch (Shift+Tab cycles default to acceptEdits to plan, auto and bypass join conditionally, the --permission-mode flag, and defaultMode in settings, with auto honored only in user settings), auto mode in depth (the classifier's allow/block defaults, requirements of Opus 4.6+ or Sonnet 4.6, conversational boundaries honored as block signals, and the 3-consecutive / 20-total block fallback), which mode to use when and safety (bypass has no prompt-injection protection so it's isolated-only; auto is the right answer for everyday prompt fatigue; hooks still run in bypass), and how permission mode relates to the effort setting (permission mode = how much it asks, effort = how hard it thinks). Based on official docs and the live UI as of June 2026.

That "Effort" slider next to the model name in Claude Code — the Faster-to-Smarter dial — sets how much work (thinking, tool calls, and response text) the AI puts into each reply. This guide covers what effort is; the slider's 6 items and labels (the API has 5 levels, low to max, and Claude Code adds its own Ultracode mode; the slider reads Low, Medium, High, Extra, Max, Ultracode, where "Extra" = xhigh and the top effort is "Max" — Ultracode is an add-on, not a step); what saves vs. is session-only (low–xhigh persist, Max and Ultracode are session-only); model support and auto-downgrade (xhigh is limited to Fable 5, Opus 4.8, Opus 4.7, etc.; Opus 4.6 and Sonnet 4.6 have no xhigh and downgrade to high; Claude Code's default is high, xhigh on Opus 4.7, while the API default is high everywhere); how to set it (/effort slider and direct values, /effort auto, /model, --effort, the CLAUDE_CODE_EFFORT_LEVEL env var as highest priority, the effortLevel setting, and skill/subagent frontmatter); a quick-reference table; an in-depth look at Ultracode (a two-layer mode that sends xhigh and has Claude auto-launch multi-agent dynamic workflows, limited to xhigh-capable models and session-only, with how to enable it, when to use it, and cost cautions); and related features (ultrathink, /fast). Based on official docs and the live UI as of June 2026.

You probably assume an LLM has to run in the cloud, but in 2026 running AI entirely inside your own PC — a "local LLM" — is a realistic option. A local LLM means running a model like ChatGPT or Claude directly on your machine instead of in the cloud. The three big draws are privacy (input never leaves your device), zero cost (no API fees), and offline use (works with no internet). The downsides: it is not as smart as the top-tier cloud AI, needs a reasonably capable PC, takes some setup, and has no up-to-date knowledge. This beginner guide covers what a local LLM is (a streaming-vs-downloading analogy), the upsides and downsides, the specs you need and quantization (the GGUF format, with Q4_K_M the go-to that keeps quality while cutting memory to about a quarter; roughly 0.5 GB of memory per 1B parameters at 4-bit), how to start (LM Studio's GUI for beginners, Ollama's CLI for developers — 52 million monthly downloads in Q1 2026), recommended 2026 models (Llama 3.2 7B, Google Gemma 4, Alibaba Qwen3.5, plus DeepSeek and Mistral — all open), and when to use local vs. cloud (local for confidential, high-volume, and offline work; cloud for hard problems). The fastest first step: run one small 3B–7B model in LM Studio.

Environment setup is where every beginner programmer gets stuck. In 2026, generative AI (Claude Code, Codex, Cursor) is genuinely usable for routine infrastructure work — local environment setup, Dockerfile generation, Terraform drafts, CI/CD pipelines. HashiCorp shipped its official Terraform MCP Server in 2026, and Anthropic released Agent Skills so infrastructure expertise can be loaded on demand. But "delegate everything" is a different question: an open 0.0.0.0/0 security group, an SSH key committed to GitHub, a $3,000 month-end AWS bill — all 2026 real incidents. This article splits five safe-to-delegate areas, three "verify-then-trust" risk zones, four human-only areas, a four-step beginner-safe workflow, and the latest 2026 tooling (Claude Code, MCP, Agent Skills) — focused on capability evaluation, not career impact.