Intent-Driven Autonomous Delivery: An Agentic Coding PoC

The Problem

The classic software delivery bottleneck isn’t writing requirements — it’s the gap between “we know what we want” and “it’s in the codebase.” Even with a well-written PRD, a team still has to break requirements into tickets, assign and schedule the work, navigate back-and-forth between spec and implementation, and manually verify each acceptance scenario. For a team juggling multiple repositories and initiatives at once, this serializes delivery and creates a constant lag between intent and execution. I wanted to test a specific thesis: if intent can be made precise enough, can an AI agent eliminate that gap entirely — going from spec directly to a tested, committed implementation with no human in the loop?

The Solution

I designed and built agentSmith, a PM workspace for authoring requirements and managing specs across multiple repositories, with an autonomous delivery feature I called “Full Send” as its core mechanism. Once acceptance scenarios for a set of requirements are marked ready, pressing Full Send hands the entire feature to Claude: it plans against every functional requirement, implements each one with an accompanying test run and a review against explicit Given/When/Then acceptance criteria, then commits. A final pass runs full regression and cleans up working state. The developer gets back a feature branch with one commit per requirement, a green test suite, and a commit history that maps directly to the original spec — the loop only stops and asks for help when it genuinely can’t proceed.

Outcome & Impact

The proof-of-concept validated the full autonomous loop end-to-end against a live internal repository: Claude planned, implemented, tested, and committed a real feature with zero manual intervention, halting cleanly and escalating exactly once when it hit a case it couldn’t resolve on its own.

Capability	Result
Phase-based orchestration	Executed reliably through planning, per-requirement implementation, and finalization
Commit granularity	One commit per requirement, mapped 1:1 to the spec
Runaway-loop protection	A repeated-failure circuit breaker halted and escalated cleanly instead of thrashing
Resume from checkpoint	Progress state allowed the loop to recover mid-run after an interruption

The clearest finding: the AI’s coding capability was never the constraint. Output quality tracked almost perfectly with how precisely the acceptance scenarios were written — which reframed the open question from “can the AI do this” to “how do we get humans to specify unambiguously.”

My Role & Contributions

Aspect	Detail
Role	Sole designer and implementer
Team size	1
Timeline	Built as an internal proof-of-concept, August 2026
Scope	Full system: product data model, workspace UI, orchestration engine, prompt engineering for the agent loop, execution protocol
Key decisions	Three-layer requirements model, phase-based (not single-prompt) execution, the runaway-loop circuit breaker, per-requirement commit granularity, terminal-based (not backgrounded) execution for visibility

This was built in direct service of my own product-management work — I was both the designer and the first user. It was also my first real exposure to agentic coding. I came into this with genuine nerves about touching a codebase I had no history in — this PoC is where that changed. Watching Claude plan, implement, test, and commit against a spec I’d written gave me the confidence to code alongside AI myself: to ship real code, build prototypes, and get comfortable working directly in a codebase rather than staying at arm’s length from it.

Technical Overview

agentSmith enforces a three-layer discipline that makes autonomous execution possible: a Why layer (program goals, overviews), a What layer (PRDs with discrete functional requirements), and a When layer (Gherkin-style acceptance scenarios tied to each requirement). The When layer is the bridge — without machine-readable, scenario-level success criteria, an autonomous loop has no way to verify its own work.

Full Send assembles a prompt containing the requirement set and its linked scenarios, generates a sequence of orchestration scripts, and launches them in a visible terminal session rather than a backgrounded process — trading a cleaner architecture for the ability to watch and intervene while validating a new pattern. Each phase runs against a hard turn budget, and phase completion is signaled back to the orchestrating script through a structured marker in the model’s output, since the shell-based approach means the agent can’t call a function to advance state directly. Progress and status are checkpointed to disk, which a polling UI reads to render a live execution monitor and which allows a run to resume after interruption.

Challenges & Key Decisions

Signaling phase transitions without tool calls

Because the orchestration lives in shell scripts rather than a function-calling harness, Claude can’t directly signal “move to the next phase.” I settled on having the model emit a structured completion marker in its own output stream, which the orchestrating script watches for. Getting this reliable took real prompt-engineering iteration — the model has to both do the work and consistently signal state, and early versions occasionally did one without the other.

A circuit breaker for runaway loops

Early runs showed that without a hard stop, the agent would sometimes loop on a failing test indefinitely — trying small variations without making real progress. I added a rule: if the same test fails with the same error three times in a row, the loop halts and escalates to a human rather than continuing to thrash. That single constraint was the difference between a tool I could trust unattended and one I had to babysit.

Phase decomposition over one large prompt

Asking the model to “implement everything” in a single pass produced unpredictable results on larger features. Splitting the work into distinct plan, implement, and finalize phases bounded the context each step needed to hold, made each phase’s success independently testable, and — critically — let the loop bank progress and commit even when one requirement turned out harder than expected.

Visibility over a cleaner background process

I could have run the whole loop as a backgrounded child process. I chose to launch it in a visible terminal window instead. For a new orchestration pattern I didn’t yet trust, being able to watch the agent work in real time and intervene if something went sideways mattered more than architectural elegance.

Lessons Learned

• Specification precision is the real bottleneck, not model capability. The loop can implement anything it can verify — the constraint is writing acceptance scenarios specific enough to serve as automated ground truth. A vague scenario reliably produced a vague implementation.
• Circuit breakers are non-negotiable for autonomous loops. A simple repeated-failure rule turned a potential infinite thrash into a clean, human-actionable escalation. Any unattended agent loop needs an explicit failure-detection and halt condition, not an implicit trust that it will eventually converge.
• Phase decomposition beats a single monolithic prompt for larger work. Separate plan/implement/finalize phases kept context bounded and let the loop make and preserve partial progress, rather than risking an all-or-nothing pass on a large feature.
• This shifts the job, not just the tooling. Autonomous delivery is achievable once intent is precise enough — but that moves the practitioner’s job from “manage delivery” to “specify unambiguously.” That’s a distinct skill, and one worth deliberately building.