Coding agents in the enterprise: the challenge is infrastructure

From autocomplete to executing tasks#

For years, the promise of AI in software development came down to one picture: an assistant suggesting the next line while you type. Useful, but limited.

That picture is out of date. Today's coding agents take a task, explore the repository, edit files, run terminal commands, read the errors, fix them and try again until they close out a workflow that used to take hours of human work.

This is already measured with public benchmarks that simulate real engineering. The Artificial Analysis Coding Agent Index, for example, combines software engineering tasks on repositories, agentic terminal use and technical questions that require understanding how a whole codebase behaves, and it also publishes the average cost and time per task for each agent. The index composition is revised over time, so check the current version before quoting numbers.

What those results show is that agents already operate well beyond producing isolated snippets. So the useful question for a company is no longer which coding agent is best, but whether its infrastructure is ready to run one.

Documentation: Artificial Analysis · Coding Agent Index ↗

The agent doesn't work alone: it works in your infrastructure#

A coding agent does not live in a vacuum. It has access to repositories, runs commands on a system, reads and writes files, spends tokens on every interaction and leaves a trail of actions that, without controls, nobody can audit or undo.

OWASP calls this excessive agency: giving an LLM-based system more functionality, permissions or autonomy than the task needs. When an agent runs without clear boundaries, the risks are concrete:

• Security: it can read environment variables, configuration files or secrets if permissions are not segmented.
• Cost: a vague task or an unbounded loop burns tokens, and money, without anyone noticing. Cost per task varies widely across agents and models, so measure it in your own environment.
• Production errors: if it can write straight to critical branches without review, a bad change can end up deployed.
• Data exposure: without access policies, it can read sensitive information from the repository or the systems it touches.
• Lost traceability: without a record of what it did, when and why, auditing is impossible.

None of these problems goes away by picking a more capable model. They are solved with infrastructure.

Documentation: OWASP GenAI · LLM06:2025 Excessive Agency ↗

Platform engineering: the enabler nobody mentions#

The coding-agent conversation tends to stop at models, benchmarks and demos. It rarely reaches the place where their success in a company is actually decided: the platform engineering team that builds and runs the internal environments where software is developed, tested and deployed.

That team now has to answer new questions:

• Where does the agent run: on your own infrastructure or on an external service?
• What permissions does it have on repositories? Can it write directly, or only propose changes through pull requests?
• How does it plug into the existing CI/CD pipeline?
• Which isolated environments exist so it can test code without touching real systems?
• How is its access to secrets, credentials and sensitive configuration controlled?

The CNCF defines a platform as an integrated collection of capabilities presented according to the needs of its users, your internal teams, and DORA describes it as an internal product built around golden paths. An agent wired into that platform inherits its controls; an agent dropped onto makeshift infrastructure is an operational risk.

Documentation: CNCF TAG App Delivery · Platforms white paper ↗ · DORA · Platform engineering ↗

Isolate every run in an ephemeral sandbox#

Every agent task should run in a container or microVM created for that task and destroyed when it ends. A destructive command then cannot affect shared systems, and every run starts from a clean, reproducible environment.

docker run --rm \
  --user 10001:10001 \
  --read-only --tmpfs /tmp:rw,size=512m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 --memory 4g --cpus 2 \
  --network agent-egress \
  -v "$PWD/worktree:/workspace" -w /workspace \
  agent-runner:1.4.2 run-task --task-file .task.md

Containers share the host kernel. If the agent will execute untrusted code, add another layer such as gVisor or microVMs, and on Kubernetes enforce the restricted Pod Security Standards profile on the namespace where agents run.

Documentation: Docker Docs · Docker Engine security ↗ · Docker Docs · docker container run ↗ · gVisor · Documentation ↗ · Kubernetes · Pod Security Standards ↗

DevSecOps: security can't be an afterthought#

Build first, secure later does not work when an agent can run commands, change code and browse repositories. Security has to be there from day one:

• Granular identity and permissions: least privilege, with short-lived credentials scoped to the task.
• Mandatory review: protected branches that require a pull request and human approval before any agent change is merged.
• Secret scanning: generated or modified code is checked for credentials, tokens and keys before it lands in the repository.
• Action audit: every file touched, command run and API called is recorded.

On GitHub Actions, a sensible flow lets the agent work on its own branch, with a minimally scoped token and a time limit, and ends in a pull request that branch protection forces someone to review.

name: agent-task
on:
  workflow_dispatch:
    inputs:
      task:
        description: "Task for the agent"
        required: true

# Least privilege: the token can only push the agent's branch and open a PR.
permissions:
  contents: write
  pull-requests: write

jobs:
  agent:
    runs-on: ubuntu-latest
    timeout-minutes: 30          # stops runaway loops and spend
    steps:
      - uses: actions/checkout@v4
      - name: Run the agent on its own branch
        env:
          TASK: ${{ inputs.task }}   # never interpolate inputs directly in run:
          GH_TOKEN: ${{ github.token }}
        run: |
          git switch -c "agent/${GITHUB_RUN_ID}"
          ./scripts/run-agent.sh "$TASK"      # runs inside an ephemeral container
          git push origin "agent/${GITHUB_RUN_ID}"
          gh pr create --fill --base main --head "agent/${GITHUB_RUN_ID}"

With autonomous agents, DevSecOps is not optional: it is the minimum bar for operating safely.

Documentation: GitHub Docs · About protected branches ↗ · GitHub Docs · Automatic token authentication (GITHUB_TOKEN) ↗ · GitHub Docs · Security hardening for GitHub Actions ↗ · GitHub Docs · About secret scanning ↗

Observability: if you can't see it, you can't control it#

Benchmarks measure what a company also needs to measure in production: time per task, token usage, cost per operation and success rate. A real environment needs more:

• What the agent did: the full action log, not just the final result.
• What it cost: the real cost of each session, including input, output and cached tokens.
• What changed: a clear diff of every modification, linked to the task behind it.
• What failed and why: where it stopped and which error it hit.
• How to roll back: a simple, fast and complete revert path.

OpenTelemetry has semantic conventions for generative AI that standardize spans and metrics for model calls, such as token usage per operation. Instrumenting the agent with them puts that data in the same backend where you already observe the rest of your platform, instead of relying on a vendor dashboard.

Without that visibility the agent is a black box inside your infrastructure, and a black box that can change code is not an asset: it is a risk.

Documentation: OpenTelemetry · Semantic conventions for generative AI ↗ · OpenTelemetry · GenAI metrics ↗

Benchmarks measure capability; infrastructure decides viability#

It is valuable to know which agents handle complex repository work best, which are most efficient in the terminal and which offer the best cost-performance ratio. But no benchmark can tell you whether your organization is ready to run one in production.

An agent solving a share of a benchmark's hard tasks does not mean it will reproduce that result on your repository. Your code, dependencies, conventions and controls are different. Only an honest assessment of your infrastructure, security processes, observability and operational maturity answers that question.

The NIST AI Risk Management Framework gives that exercise a structure: govern, map, measure and manage the risks of an AI system across its lifecycle.

Documentation: Artificial Analysis · Coding Agent Index ↗ · NIST · AI Risk Management Framework ↗

Checklist before giving an agent access#

The competitive edge is the platform#

The companies that get the most out of coding agents won't necessarily be the ones on the most advanced model. They will be the ones that built the right platform to run agents safely, measurably and at scale: isolated environments, clear permissions, human review in the pipeline, visibility into cost and actions, fast rollback, and platform and security teams aligned on adoption.

That is the difference between using AI opportunistically, with inconsistent results and unmanaged risk, and using it as a real organizational capability. The model is the engine; the infrastructure is the chassis, the brakes and the steering wheel.