Intent-driven development: How to guide agents from idea to implementation
Senior Technical Content Marketing Manager
Intent-driven development (IDD) is an approach to AI-assisted software development where teams make the desired behavior, constraints, and criteria for success explicit, then give an agent freedom to determine how to achieve the result.
As agents take on larger and more autonomous development and maintenance tasks, the implementation itself becomes easier to replace. The important question is whether the software still behaves the way the team intended. IDD keeps the team’s intent available as plans, specifications, and implementations change, giving the agent a stable reference for making decisions and giving the team a basis for evaluating the result.
The rest of this article explains what intent means in practice, how IDD relates to approaches such as TDD, BDD, and spec-driven development, and how teams can carry intent through planning, implementation, and validation.
What does “intent” mean in software development?
In an IDD workflow, intent is the set of decisions that defines an acceptable result. For a software change, intent usually includes:
- Objective: What should the software accomplish?
- Constraints: Which requirements or boundaries must the implementation respect?
- Behavior to preserve: What should continue working after the change?
- Success criteria: What must be true before the work can be considered complete?
Intent should capture the desired outcome, important constraints, and enough of the reasoning behind them for an agent to make implementation decisions without guessing about product requirements or consequential tradeoffs.
For example, declared intent for a passwordless authentication change might specify that enterprise users can authenticate through an approved identity provider, existing password authentication must continue working, failed authentication must not create a session, and authentication events must remain auditable.
The team’s intent doesn’t have to live in a dedicated document. A task description, issue, specification, design document, acceptance criteria, or sufficiently complete prompt can all capture the objective, constraints, and success criteria.
How prompts, specs, and intent fit together
A prompt tells the agent what to do next, while the intent defines what a successful result looks like.
A prompt might say:
Implement the passwordless-login change described in AUTH-142.
Start by reviewing the current authentication flow and propose
a plan before modifying code.
AUTH-142 might contain the objective, constraints, and success criteria used to evaluate the finished change. For a smaller task, the prompt can contain both the instructions and the intent:
Add a validation check that rejects negative quantities.
Existing handling for zero remains unchanged, and all current
tests must continue to pass.
A specification can make the intent more structured by translating requirements, decisions, and expected behavior into an artifact that guides planning and implementation. Tools such as Kiro formalize the process by turning requirements into design and implementation tasks that an agent can work through.
The distinction becomes more useful as work spans multiple prompts or agent sessions. Instructions, specifications, and implementation plans can change as the agent learns more. The requirements governing the finished result should remain available unless the team deliberately changes them.
How IDD builds on TDD, BDD, and spec-driven development
IDD builds on ideas software teams already use to make expected behavior explicit and guide implementation toward it.
| Approach | Primary focus | How it relates to intent |
|---|---|---|
| Test-driven development (TDD) | Writing a failing test, implementing enough behavior to pass it, then refining the implementation | Tests express specific behavioral expectations as executable checks and drive implementation toward them |
| Behavior-driven development (BDD) | Describing expected behavior through concrete user or system scenarios | Scenarios make requirements more concrete and give developers or agents examples to implement and validate |
| Spec-driven development (SDD) | Using a structured specification to guide implementation | Specifications provide a persistent artifact for carrying requirements and intent into implementation |
| Intent-driven development (IDD) | Keeping the desired behavior, constraints, and criteria for success explicit throughout agentic development | Intent provides the basis for planning, implementation decisions, and evaluation as the implementation changes |
TDD and BDD provide familiar ways to make parts of intent concrete through tests, scenarios, and examples. Both can fit naturally into an intent-driven workflow.
Spec-driven development is the closest adjacent approach. SDD uses a structured specification to guide implementation, while IDD keeps the broader intent available as specs, plans, and implementations change. Some sources consider SDD a subset of IDD; for clarity, this article treats them as separate but related concepts, with SDD organized around the specification and IDD around the intent the specification is meant to carry.
How the IDD workflow works
A practical IDD workflow looks like this:
Idea → intent → context → specification or plan → implementation → validation → refinement
Responsibility shifts across the workflow. Humans lead the definition of intent. Agents can gather context and drive much of the implementation work. Planning, validation, and refinement often combine agent execution with human judgment.
The workflow is iterative. An agent can discover missing context while planning, uncover an ambiguous requirement during implementation, or revise a specification after validation exposes a decision the team hasn’t made yet.
1. Specify intent
The first step in IDD is deciding what the software should do and how the team will know whether the result is acceptable.
A short request might be:
Add passwordless login for enterprise customers.
The request identifies the feature but leaves important decisions undefined. A more complete declaration of intent might look like:
Objective:
Enterprise users can sign in without a password using their
organization's approved identity provider.
Constraints:
- Existing password login continues to work.
- Customers without SSO are unaffected.
- Failed authentication doesn't create a session.
- Authentication events remain available in audit logs.
Success criteria:
- Approved users can sign in successfully.
- Unapproved identity providers are rejected.
- Existing authentication behavior continues to pass regression tests.
The declaration defines an acceptable result without prescribing exactly how the authentication system should be changed.
Agents can help identify missing decisions, conflicting constraints, or success criteria that are too vague to evaluate, while people decide what the software should do and which tradeoffs are acceptable.
2. Give the agent the context it needs
The agent needs enough information about the existing system to make implementation decisions consistent with the intended result.
For the passwordless-login change, relevant context might include:
- the existing authentication flow
- session handling
- audit logging
- current authentication tests
- relevant security policies
Agents can gather much of the context from the development environment. Developers may need to provide information stored elsewhere or resolve conflicts between sources.
The stated requirements help determine which information matters. Preserving password login makes the current authentication flow relevant, while maintaining auditability makes the logging implementation relevant. Context engineering helps the agent find the information needed for the task without loading every available file or document.
3. Turn intent into a spec or plan
The agent now has a defined result and enough context to decide how to approach the change.
For the passwordless-login example, the agent might propose:
- Extend the existing authentication flow.
- Reuse the current session logic.
- Preserve the password-login path.
- Record successful and failed authentication attempts.
- Add targeted authentication tests.
- Add regression coverage for existing behavior.
A larger change might also produce or update a specification, design document, task breakdown, or architectural proposal before implementation begins.
The plan and supporting technical artifacts can evolve as the agent learns more, provided the resulting implementation still satisfies the objective, constraints, and success criteria.
Making the approach visible before substantial work begins also gives a developer an opportunity to review assumptions and consequential technical choices. If the proposed session-handling approach creates an authorization problem, the agent can choose another implementation without changing the desired behavior.
4. Let the agent implement and iterate
The agent implements the proposed solution and runs targeted checks as the work progresses.
A failing test can inform the next edit immediately, allowing the agent to revise the code and rerun the relevant check while the task context is still active. Passing targeted tests shows that the current implementation works for the cases exercised during development.
With agentic development, an implementation can change substantially as the agent learns more. The agent may try several approaches, abandon one, or rewrite portions of the solution. In intent-driven development, every implementation still has to satisfy the same objective, constraints, and definition of success.
Broader validation determines whether the complete change behaves correctly in the surrounding system.
5. Validate the behavior against the intent
Validation determines whether the implemented software satisfies the objective, constraints, and success criteria defined in your stated intent.
Different requirements need different forms of evidence:
| Requirement | Validation |
|---|---|
| A function returns the correct result | Unit tests |
| An API remains compatible | Contract tests |
| Services interact correctly | Integration tests |
| Unauthorized access is blocked | Security tests and policy gates |
| Performance stays within limits | Performance tests |
| A deployment remains healthy | Deployment and post-deploy checks |
| Generated output or behavior satisfies qualitative criteria | Agent evaluation or human review |
| An architectural approach fits the system | Human review, potentially assisted by another model |
Deterministic requirements are best checked with tests, policies, or measurements. Requirements involving meaning, quality, relevance, or adherence to a rubric may be better evaluated by a human or another model acting as an evaluator.
For the passwordless-login change, the team can connect the specified requirements directly to evidence:
| Requirement | Evidence |
|---|---|
| Approved users can sign in | End-to-end authentication test |
| Unapproved identity providers are rejected | Security or integration test |
| Existing password login still works | Authentication regression tests |
| Failed sign-ins don’t create sessions | Session tests |
| Authentication events remain auditable | Audit-event integration tests |
Some validation happens while the agent works. Compilation, type checking, linting, and targeted tests provide fast feedback on the current implementation.
Other requirements need broader validation through full test suites, cross-service tests, security controls, policy checks, infrastructure validation, and deployment checks that may depend on CI infrastructure or system access unavailable in the agent’s immediate working environment.
The passwordless-login implementation might pass its targeted tests while a broader integration test reveals that customers with multiple identity providers can sometimes be matched to the wrong provider. The implementation needs another revision because the resulting behavior still conflicts with the specified requirements.
6. Use failures to refine the implementation, spec, or intent
A validation failure can reveal a problem with the implementation, expose a flaw in the specification, or uncover a decision the team never made.
Implementation problems can usually return directly to the agent. For the passwordless-login example, the agent can update the identity-provider matching logic and rerun the relevant checks.
A failure can also expose an incorrect assumption in a specification or plan. The agent can update the technical approach while preserving the requirements the implementation still needs to satisfy.
Some failures reveal ambiguity in the intent itself. If organizations with multiple identity providers could reasonably use either a default provider or a user-selected provider, a person needs to decide which behavior the product should support. The team can clarify the requirement, and the agent can continue from the updated definition of success.
The work is complete when the available evidence satisfies the objective, constraints, and success criteria.
Where IDD breaks down
IDD depends on clear intent, enough context for the agent to make informed decisions, and validation capable of detecting incorrect results.
The agent doesn’t know what the team wants
An agent can implement a reasonable interpretation of a request even when the interpretation differs from what the team intended.
Consider:
Add support for account deletion.
The request leaves major decisions unresolved:
- Is deletion immediate or delayed?
- Can users recover the account?
- What happens to invoices?
- What happens to audit records?
- Are API tokens revoked?
- How are shared resources handled?
- Are there retention requirements?
Long-running agent sessions can create a similar problem. Implementation details, failures, corrections, and new instructions accumulate while the original requirements become harder for the agent to recover.
The team needs to define enough of the desired behavior and keep the requirements accessible for the agent to recognize an acceptable result.
The agent can’t see enough of the system
Clear intent can still produce a poor implementation when the agent lacks information about the surrounding system.
An API change may pass its own tests while breaking an undocumented downstream consumer, or a migration may work locally while violating assumptions in another service.
The agent needs enough information about the surrounding system to avoid breaking dependencies and assumptions it can’t see.
Validation doesn’t measure what matters
A change can compile and pass local tests without satisfying the actual requirements.
Cross-service requirements need system-level evidence, authorization requirements need security validation, performance requirements need measurements, and qualitative requirements may need rubric-based evaluation from a human or another model.
Validation needs to cover the behavior the team cares about. A weak rubric or poorly calibrated model evaluator can create the same problem as a weak test suite: the implementation appears successful because the validator didn’t measure the requirement well enough.
How CI closes the loop between intent and implementation
IDD depends on evidence throughout the agentic development loop. Agents need fast feedback while implementation is still changing, followed by broader validation once code reaches CI. When CI discovers a problem, the resulting context needs to get back to the agent so implementation can continue.
CircleCI’s approach to agent experience connects validation across the inner and outer loops: pre-push checks help agents iterate while they work, and CI provides broader evidence once a change enters the shared delivery process.
Validate before the push with Chunk sidecars
Chunk sidecars bring validation into the agentic inner loop before code is committed and pushed.
A sidecar gives the agent an isolated environment where it can exercise working-directory changes against realistic dependencies. The agent can run targeted checks, inspect failures, revise the implementation, and validate again while the task context is still active.
Pre-push validation helps the agent catch problems before every intermediate attempt reaches CI. Broader validation can still happen after the change is pushed.
Validate the shared change in CI
Once code is pushed, continuous integration (CI) provides broader validation against the shared codebase and infrastructure.
CircleCI can run full test suites, cross-service integration tests, contract tests, security controls, policy checks, infrastructure validation, model-based evaluations, deployment workflows, and other checks that are impractical to reproduce completely inside the agent’s working environment.
This stage of the development cycle is often called the outer loop. The outer loop provides independent evidence about whether the proposed change satisfies the requirements needed before it’s merged into the shared codebase.
Feed CI failures back to the agent
CI feedback becomes more useful when the agent responsible for the implementation can consume it directly.
The CircleCI CLI provides an agent-friendly interface for working with pipeline context from the same environment where the agent is modifying code. Agents can inspect runs, workflows, jobs, test results, and failure information without relying on a developer to manually move the relevant information back into the coding session.
When a pipeline fails, circleci run get --failure-report condenses the relevant failed-step output into a focused report designed for agent consumption. The agent can use the failure report to understand what broke, revise the implementation, and send the updated change through validation again.
The CircleCI CLI includes a built-in MCP server, allowing compatible agents to access CircleCI data and actions through native tool calls. CircleCI also provides a hosted MCP server for agents that need remote access to CircleCI capabilities.
The complete loop can therefore look like:
intent → implementation → sidecar validation → revision → push → CI validation → pipeline context returned through the CircleCI CLI or MCP → revision → validation again
The implementation may move through the inner and outer loops several times before merge. Each validation stage provides new evidence about whether the current implementation satisfies the requirements.
Keep implementation aligned with intent
AI agents can revise plans and implementations quickly. IDD keeps the objective, constraints, and success criteria available throughout the work so each new approach can be evaluated against the same intent.
Tests, policies, CI results, model evaluations, and human review provide the evidence needed to decide whether the current implementation is acceptable. If the intended behavior changes, people update the intent and give the agent a new target.
CircleCI supports intent-driven validation loops with Chunk sidecars before the push, broader CI checks after the push, and the CircleCI CLI to return pipeline context to the agent when more work is needed.
Ready to bring CI feedback into your IDD workflow? Install the CircleCI CLI and run circleci onboard in your repository to connect your project and start validating agent-generated changes with CircleCI.
