Since November 2025, coding agents like Claude Code, Cursor, and Codex have fundamentally reshaped how developers write software. But what's really under the hood? A new deep dive from tidydesign shows these seemingly magical AI assistants are built on something far more mundane: six core functions that mirror exactly how a human programmer interacts with a codebase.

The Six Functions That Power Every Coding Agent

According to the analysis, every major coding agent relies on variations of the same half-dozen operations. Read file retrieves contents from disk or partial sections. Write file creates new files with fresh content. Edit file makes targeted changes by swapping one text chunk for another. List files displays directory structures so the agent can navigate projects. Search finds lines matching patterns across the codebase. And run command executes arbitrary shell instructions, giving the agent a literal escape hatch to do anything else it might need. The author demonstrates this by building a minimal coding agent in R using the ellmer library, starting with just three tools: read_file, write_file, and run_command. Each function returns a string fed back to the LLM as a tool call result. The shell command is particularly powerful—execute "ls" for directories, "grep" for code search, or "git" for version control. It's the ultimate "get out of jail free" card.

Security Implications of Unfettered Shell Access

Here's where things get interesting from a hacker perspective. Handing an LLM general-purpose shell access is a security nightmare. Shell commands vary between platforms (Windows lacks native "ls" or "grep"), produce noisy output, and critically, are nearly impossible to audit for safety. A malicious or buggy prompt could execute anything on your system. The article walks through implementing safer list_files and search_files tools with explicit path validation. The safe_path() function resolves paths using normalizePath(), then verifies the result stays within the project directory by checking it equals or is a child of the working directory root. This prevents traversal attacks where an agent tries "path = '..'" repeatedly or accesses absolute paths like "/etc/passwd". Importantly, dotfiles like .Renviron (where R programmers store API keys) stay protected because list.files() defaults to all.files = FALSE.

Why Edit Tools Are the Real Innovation

The biggest weakness in a minimal agent is that write_file forces complete file rewrites. For a 500-line file where you only need one line changed, the model must reproduce all 500 lines perfectly—slow, expensive, and error-prone. The edit_file function solves this by accepting "old" and "new" text parameters: it locates an exact string match in the target file, replaces it once with new content, then writes back. This approach has two major advantages beyond efficiency. First, the model only generates the changed lines rather than entire files, reducing token costs significantly. Second, edit_file fails loudly when the "old" text doesn't appear exactly once—preventing silent corruption that write_file risks. The author notes real agents add cleverness around whitespace handling, safeguards against multiple matches, and detection of concurrent human edits.

Key Takeaways

  • Coding agents are harnesses with six categories of file operations: read, write, edit, list, search, run command
  • Only three tools (read, write, shell) are truly essential—everything else is ergonomic refinement
  • General-purpose shell access is powerful but dangerous; specialized tools are easier to sandbox
  • Path validation prevents directory traversal attacks that could expose credentials or system files
  • Edit tools beat full-file rewrites on cost, speed, and safety due to exact-match requirements

The Bottom Line

The coding agent revolution isn't magic—it's plumbing. Six functions doing what developers already do manually every day. That's actually good news for security-conscious shops: these aren't mysterious black boxes but well-understood systems with clear attack surfaces. Now it's on the community to build better safeguards before someone inevitably exploits that shell tool.