Agentic programming changes the speed, not the responsibility
An LLM can propose code. An agent can also read a repository, run tools, modify files, and verify results. That compresses delivery cycles, but it also increases the number of decisions and changes that require control.
An agentic cycle with verifiable boundaries
- Human intentoutcome · constraints · risk
- Specificationcontract · acceptance · exclusions
- Isolated agentsminimal context · bounded permissions
- Evidencetests · build · analysis · real output
- Reviewindependent context · fail-closed
- DeliveryCI · deployment · verification
The specification becomes executable
A vague instruction lets an agent produce vaguely correct changes faster. Before delegation, we define observable behavior, constraints, expected evidence, and actions that require human authorization.
- Acceptance criteria a test or inspection can verify.
- Boundaries on files, systems, data, and external effects.
- Explicit sources of truth; a plausible answer is not evidence.
- A mandatory stop when context is missing or a business decision appears.
TDD reduces the error surface
The RED–GREEN–REFACTOR cycle gives an agent a small, falsifiable target. The test must fail before the change for the expected reason; minimal implementation then makes it pass, and the full suite catches regressions.
- One behavior per cycle instead of a stack of imagined tests.
- Tests against real HTML, APIs, or artifacts when possible.
- Adversarial mutations to prove the contract rejects false positives.
- Refactoring only while behavior remains green.
Isolation and capability-based permissions
An agent does not need universal access to be useful. We separate branches, contexts, and tools; grant only the permissions needed for the task; and require approval before publishing, deleting, paying, or changing external systems.
- Isolated branches or worktrees for concurrent work.
- Secrets kept out of prompts, code, and logs.
- Destructive actions and publication behind a human decision.
- Subagent results treated as reports until independently verified.
Review must come from another context
The implementing agent shares assumptions with its solution. An independent reviewer receives the contract and diff, searches for logic, security, and provenance errors, and does not approve merely because the author sounds confident.
- A reviewer without the implementer’s narrative.
- Blocking findings separated from suggestions.
- Content checked against fabricated clients, metrics, or capabilities.
- Corrections verified again from a clean position.
Gates fail safely
If a test does not run, review cannot be parsed, or production cannot be checked, the state is unverified. Automation speeds up the happy path without turning uncertainty into automatic approval.
- Build, types, security, links, schema, and accessibility as reproducible gates.
- Green CI before integration and deployment.
- HTTP, DOM, and visual verification after publication.
- Rollback or stop when evidence contradicts the change.