Skip to content
Specific Docs
Esc
navigateopen⌘Jpreview
On this page

Why Specific?

The case for agent-first infrastructure.

Coding agents are rapidly improving and writing more code. But when it comes to infrastructure, they hit a wall. To understand what’s deployed, they’d need to navigate CLI output. Terraform solves declaration by defining infrastructure as code, but it doesn’t handle local dev or deployment. Docker Compose handles local dev, but production requires separate tooling that must be kept in sync. The result is that agents can write your code, but the path from code to running application remains fragmented and manual.

Specific closes that gap: your agent declares services, databases, storage, and more in a single configuration file that lives next to your code, and the CLI runs the whole stack locally and deploys it to production. See How Specific works for the mental model.

Built for the agent feedback loop

After a successful deployment, anything that can fail will fail. Specific is designed so your agent can find out what went wrong without a human relaying screenshots:

  • specific check validates every configuration change before it’s applied.
  • specific dev runs the full stack locally, with per-service log files the agent can read and grep.
  • specific query gives the agent SQL access to production logs and metrics, scoped to an environment.

The agent that wrote the change is the one debugging it, with direct access to the evidence.

Not a coding agent

Specific works with the coding agent you already use, like Claude Code, Codex, or Cursor. The CLI gives your agent the documentation, validation, local environment, and deployment commands it needs to change infrastructure safely alongside your application code. See Coding agents for how that’s wired up.

No SDKs, no lock-in

Your application never imports a Specific library. Everything arrives through environment variables and standard protocols: Postgres is Postgres, storage is S3-compatible, Redis is Redis-compatible. That has practical consequences:

  • Any language and framework works, and a custom Dockerfile covers custom runtimes.
  • Services Specific doesn’t provide still work: connect to external APIs, hosted services, or third-party databases through normal secrets and client libraries.
  • Authentication stays yours. Use Better Auth, WorkOS, Clerk, or your own; Specific handles infrastructure and stays out of your user model.

Agents with guardrails

Letting an agent touch infrastructure raises a fair question: what stops it from breaking things?

  • Infrastructure changes are written to specific.hcl, so they’re reviewed like code and validated with specific check.
  • Agents work through Specific’s config schema and CLI, not arbitrary cloud or account settings.
  • The full stack is testable locally before anything ships, and specific deploy runs build checks before provisioning or rolling out.
  • Destructive actions and production controls, like scaling, changing production secrets, and deleting projects, stay with humans in the dashboard. Humans also configure deployment policy, like GitHub deploys and automatic PR previews.

How Specific compares

Was this page helpful?