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 depend on how the session starts (an agent view opened in a shell and claude --bg follow a normal launch's rules, one opened with ← uses the target directory's defaultMode or the originating session's mode, and /bg keeps the current mode), 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 five official ways to parallelise, alongside subagents, agent teams, dynamic workflows and Projects, 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 4 October 2026 (latest release v2.1.289) 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.

The Claude Code sandbox restricts file and network access by sandboxed shells and their child processes at the OS level. Learn /sandbox setup, write locations, denied reads, allowed domains, and regular versus auto-allow permissions. Built-in Read/Edit/Write, MCP, hooks, excluded commands, and unsandboxed retries are separate routes. It does not guarantee prevention of every destructive action, transmission within allowed areas, or secret leak; the guide explains mode-specific handling of unknown hosts and exception settings.

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 permission rules control tool calls through allow, ask, and deny in settings.json. Learn settings precedence, command and path matching, and practical examples. The guide also explains alternate Bash spellings, arbitrary scripts, Read/Edit negation patterns, and decision changes by mods, distinguishing these rules from a guarantee that secret files or network access are blocked through every route.

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; with v2.1.283 or later, terminal and VS Code sessions start in Auto on every plan (earlier, only on Pro, Max, and Team), while claude -p and the Agent SDK start in Manual; protected paths like .git and .claude are never auto-approved outside bypass), the five selector modes (Manual = default, reads only auto-approved; Accept edits = acceptEdits, auto-approves edits and common filesystem commands such as mkdir, rm, and mv inside your working dir; Plan = plan, explores and proposes a plan without editing; Auto = auto, a separate classifier blocks dangerous actions while running everything else without prompts; Bypass permissions = bypassPermissions, nearly everything with no checks, isolated environments only) plus a sixth, dontAsk, which never appears in the Shift+Tab cycle and is set by flag or in settings, how to switch (Shift+Tab cycles Manual, Accept edits, and Plan, with Bypass and Auto joining after Plan when available; the --permission-mode flag; and defaultMode in settings, where auto and bypassPermissions don't take effect from project settings), auto mode in depth (the classifier's allow/block defaults, available by default on Team and Enterprise unless an admin turns it off, supported models Opus 4.6+, Sonnet 4.6+, or Fable, 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; with bypass available in a terminal, plan mode doesn't stop edits), and how permission mode relates to the effort setting (permission mode = how much it asks, effort = how hard it thinks). Based on the official docs and the desktop app's UI as of October 5, 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 5 levels and labels (the API has 5 levels, low to max; the slider reads Low, Medium, High, Extra, Max, where "Extra" = xhigh and the top effort is "Max"); what persists (low–xhigh are saved per model when you confirm with Enter, Max is session-only); model support and auto-downgrade (xhigh needs a relatively recent model such as Fable 5.1, Opus 5.5, or Sonnet 5.5; Opus 4.6 and Sonnet 4.6 have no xhigh and downgrade to high; the legacy Haiku 4.5 has no effort control while Haiku 5.5 supports every level; Claude Code's default varies by model: medium on Opus 5.5, Sonnet 5.5, and Haiku 5.5, high on Fable 5.1); how to set it (/effort slider and direct values, /effort auto, /model, --effort, the CLAUDE_CODE_EFFORT_LEVEL env var as highest priority, the modelSettings and effortLevel settings, and skill/subagent frontmatter); a quick-reference table; an in-depth look at Ultracode (not an effort step but an on/off switch that works at any level and has Claude build multi-agent dynamic workflows on its own; limited to xhigh-capable models; turned on with /effort ultracode, the Tab key, or "ultracode": true in settings; when to use it, cost cautions, and what changed in v2.1.284); and related features (ultrathink, /fast). Based on official docs (as of September 2026) and the live UI.

You probably assume an LLM has to run in the cloud, but small models are only a few gigabytes and run even on an ordinary laptop. A local LLM means running an AI model directly on your own PC instead of in the cloud. Its upsides are privacy (input never leaves your machine), no API fees, and offline use; its downsides are that it isn't as smart as top-tier cloud AI and needs a reasonably capable PC. This beginner guide covers quantization (Q4_K_M is about 30% of the fp16 size: 16 GB → 4.9 GB for Llama 3.1 8B), a table of real download sizes from Ollama's tag lists (as of September 30, 2026), the official system requirements for Ollama and LM Studio, Ollama's official steps (install.sh on macOS and Linux, install.ps1 on Windows, then ollama run gemma4 and ollama ps to confirm it's on the GPU), a warning that ":cloud" models don't run on your machine, how to choose a model (with Llama 3.1, Gemma 4, Qwen3.8, and DeepSeek-R1 as examples), and when to use local versus the cloud.

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 released its official Terraform MCP Server in 2025 (generally available since June 2026), and Anthropic released Agent Skills so infrastructure expertise can be loaded on demand. But "delegate everything" is a different question: a $3,000 month-end AWS bill, a production DB accidentally made public, an SSH key committed to GitHub — all incidents that can happen when you hand everything off. 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.