Agentic Development: What It Is, and Where It Works

"Agentic development" is having a moment, and like every term having a moment, it is being stretched to cover everything from tab-completion to fantasies about firing your engineering team. We have spent the last months shipping real software this way — nftably, a firewall UI, was built almost entirely by AI coding agents under human direction — so this is our attempt at a working definition, from practice rather than from a keynote.

The ladder: autocomplete, chat, agents

It helps to see agentic development as the third rung of a ladder, because each rung changes what the human does, not just how fast the typing goes.

Autocomplete — Copilot in its original form. The model predicts the next few lines while you type. You are still the one writing the program; the model is a very good keyboard. The unit of work is the line.

Chat-assisted coding — you describe a problem, the model proposes code, you paste and adapt it. Useful, but the model is blind: it cannot see your repo, run your tests, or find out whether its suggestion even compiles. You are the model's hands and its only feedback loop.

Agentic development — the model gets tools: it can read and edit files, run shell commands, execute the test suite, and inspect the results. Given a goal, it works a loop — plan, act, check, adjust — until the tests pass or it gets stuck. Claude Code, GitHub Copilot's agent mode, Cursor's agent, and Codex-style agents all work this way; the differences between them matter less than what they share, which is the loop.

That loop is the whole point. An agent that runs your tests catches its own broken code before you ever see it. The feedback that used to route through your eyes and fingers now routes through the toolchain, and the human moves up a level.

What actually changes

The unit of work becomes the reviewed diff, not the typed line. In our workflow, we no longer really "write code" in the old sense. We write specifications — a design doc, a milestone description, a bug report with a reproduction — and we review diffs. The interesting question stopped being "how fast can we type this" and became "how precisely can we say what we want, and how reliably can we tell whether we got it."

Specification becomes a first-class artifact. Every one of our projects starts with a PLAN.md that a human writes: the architecture, the data model, the milestones, the explicit non-goals. A well-written design doc turns out to be a far better prompt than any conversation. We wrote about the mechanics of this in our AI-driven development workflow.

Verification becomes the bottleneck — and the moat. When code generation gets cheap, everything that validates code becomes the scarce resource: tests, CI, linters, review attention. A codebase with a strong test suite and strict CI can absorb agent-written code safely, because the loop has something to push against. A codebase with neither gives the agent nothing to verify against, and it will happily produce plausible-looking wrongness at scale. If you want a one-line prediction: teams with good verification infrastructure will get compounding returns from agents; teams without it will get compounding debt.

What it isn't

It is not autonomous software engineering. Nobody we know ships an agent's output unread, and neither do we. On our own projects the agents did most of the typing; the object model, the safety semantics, and every merge decision stayed human. The agent is a tireless, fast, occasionally overconfident mid-level engineer. It is not an engineering organization.

It is not a replacement for design judgment. An agent will implement the design you give it, including the bad parts, with great enthusiasm. Deciding that a firewall UI must apply changes atomically with an auto-revert — so a bad rule can't lock you out — is a design judgment. No agent proposed that; a human who has been locked out of a remote box did. The agent then implemented it well.

It is not magic on an untested codebase. Point an agent at a large legacy system with no tests and ambiguous conventions and you will mostly generate confident regressions. The agent's loop needs a "did it work?" signal. No signal, no loop — just generation.

Where it shines, where it fails

From our experience — three shipped tools, documented in a case study — the pattern is consistent.

It shines when:

• The problem is well-specified and the acceptance criteria are checkable (CRUD layers, API handlers, renderers, migrations, test scaffolding, packaging)
• The stack is conventional — Go, TypeScript, SQL, systemd units — where the model's training distribution is dense
• The codebase has tests and CI the agent must keep green
• The work is voluminous but not deep: fifty similar endpoints, not one subtle algorithm

It fails when:

• Requirements are ambiguous — the agent resolves ambiguity by picking something, silently
• The problem is genuinely novel and there is nothing comparable in the training data
• Correctness is safety-critical and subtle: concurrency, crypto, financial rounding, anything where plausible-but-wrong is the dominant failure mode (we wrote a field guide to reviewing AI code for exactly this)
• The verification signal is missing or slow

The honest summary

Agentic development is real, and it changed how we build software: our last three tools were mostly typed by agents and entirely designed and reviewed by humans. It is also narrower than the hype suggests. The technology moves the human from typing to specifying and verifying — which means the humans who are good at specifying and verifying become more valuable, not less.

Takeaways

1. Agentic = tools + loop — an agent edits files, runs commands, and checks results against a goal; that loop is what separates it from autocomplete and chat
2. Your job shifts to specs and review — the reviewed diff is the new unit of work
3. Verification is the moat — tests, CI, and review discipline determine whether agents compound value or debt
4. Design judgment stays human — agents implement decisions; they don't make good ones
5. Match the tool to the terrain — conventional, well-tested, well-specified work first; novel and safety-critical work last

If you want help bringing agentic development into your team — with the guardrails that make it safe — talk to us.