Agentic Software Development: A Practical Guide

84% of developers used or planned to use AI tools in 2025, but only 31% were using AI agents, according to Stack Overflow's developer survey. That gap matters more than another coding demo. Getting useful code from a model isn't the same as trusting it to carry a product change through design, implementation, review, and merge.

Agentic software development works best when agents are governed teammates, not unattended coders. The highest return isn't necessarily faster typing. It's giving engineers time to work on product design, customer problems, and distribution without spending that time correcting delegated work.

Why Agents Are Still a Small Slice of Development

A developer asking a chatbot to explain a failing test remains in charge of every next step. An agent that edits files, runs commands, and opens a pull request takes on more responsibility. Teams have good reasons to treat those situations differently.

Among developers who had used agents at work, 69% reported increased productivity, while 46% of developers distrusted AI output accuracy, compared with 33% who trusted it, according to the 2025 Stack Overflow survey results. These are different respondent groups, not opposing answers to the same question. Together, they describe a practical tension: useful assistance doesn't remove the need for verification.

Trust depends on the task

Consider a contained bug with a clear reproduction and an existing regression suite. An agent can investigate it without needing to invent the intended product behavior. Compare that with a request to redesign onboarding: the code may be straightforward, but the choices about user intent aren't.

The important question is where autonomy belongs, not whether a team supports AI. A useful decision framework checks:

• Reversibility: Can the team undo the change without repairing customer data?
• Blast radius: Could a mistake affect permissions, billing, or shared infrastructure?
• Specification quality: Does the card explain expected behavior and exclusions?
• Verification: Can tests and a preview expose an incorrect result?

Practical rule: Expand autonomy when you can explain how failure will be detected and contained.

Skepticism isn't necessarily resistance to progress. An engineering lead can value agent output while refusing to accept an unsupported claim that a change works. Scaling responsibly means defining permissions, review gates, and escalation rules before increasing the volume of delegated work.

What Agentic Software Development Actually Means

Agentic software development means giving an AI system tools and a bounded objective so it can take actions, inspect results, and continue working. Think of a junior teammate with repository access, a terminal, and a checklist. The analogy describes the supervision it needs, not a claim that it has human judgment.

A chatbot usually returns an answer for you to act on. An IDE assistant may suggest a completion or explain selected code. An agent can carry a card forward by finding relevant files, changing them, running checks, and responding to failures.

What separates an agent from autocomplete

• Tool use: It can inspect the repository and execute permitted commands rather than merely describe them.
• Iteration: It can observe a failed check, revise its work, and try again.
• Persistence: It carries task state across actions until it completes the card or reaches a stopping condition.

The distinction matters when interpreting productivity research. A controlled AI-pair-programming experiment found a 55.8% reduction in completion time for a bounded coding task, as reported in the GitHub-affiliated productivity paper. That experiment didn't establish the same benefit across requirements, design approval, review, deployment, or complete project delivery.

The objective is a finished change

In a broader workflow, agents can draft product requirements, propose a technical plan, implement code, inspect design conformance, and address review comments. Humans still decide what should be built and which risks are acceptable.

The discipline described in agentic engineering extends beyond generating code. A useful completion condition is an accepted change with supporting evidence, not a confident final message. The agent's explanation helps reviewers understand the work, but it doesn't replace the work itself.

The Agent-Driven SDLC From Design to Merge

Treat each product change as a card with an approved intent and a visible history. The card should retain its designs, implementation artifacts, review findings, and decisions as it moves across the board. Otherwise, each handoff becomes another opportunity to lose context.

Product design comes first. A design agent can draft the user problem, expected behavior, edge cases, and exclusions, but a human must settle unclear choices. Sending an unresolved product question into implementation doesn't eliminate the decision. It lets the worker make it implicitly.

Stages, Agents, and Human Checkpoints

Technical design should identify affected components, dependency changes, compatibility concerns, and how the team will verify the result. It shouldn't become a speculative document that prescribes every line of code. Give the worker enough direction to avoid architectural improvisation while leaving room to solve local implementation details.

After implementation, the reviewer checks the patch against the approved designs. A clean test run doesn't establish that the worker built the intended experience. Likewise, visual approval doesn't establish that authorization or error handling works.

Put decisions where they are cheapest

For a web application, site review should happen on a preview deployment. Reviewers can inspect loading states, empty states, navigation, and error behavior in context. Their feedback should return to the same card rather than disappear into a separate chat.

A human checkpoint should resolve a decision, not merely acknowledge that an agent finished running.

When a reviewer discovers a missing product decision, return the card to design. Do not let repeated fix requests turn into a new specification. After approval, use established merge and deployment controls rather than giving the agent discretion to bypass them.

Architecture and Integration Patterns That Make It Work

A useful agent platform needs more than a queue of prompts. It needs durable card state, execution controls, review artifacts, and a way for humans to intervene without restarting the task.

The board should distinguish working, waiting, stuck, and needs-you states. Workflow rules should decide when a card advances, when another agent receives work, and when execution pauses. An agent's statement that it's done should trigger verification, not automatically authorize the next risky action.

Separate execution from verification

The worker agent changes the repository. The reviewer agent receives the approved design, the patch, and verification evidence. Keep their responsibilities separate so the reviewer does not inherit the worker's explanation.

Repository benchmarks reinforce the importance of executable outcomes. SWE-bench contains 2,294 issues from 12 Python repositories; its initial retrieval-augmented baseline resolved 1.96%, while the early SWE-agent system reached 12.47%, according to the original SWE-bench results. These historical results aren't a ranking of current tools. They show why file navigation, execution, and test feedback matter alongside code generation.

Use isolated execution environments and independently run the required checks. Record the commands, results, and patch revision so reviewers can tell which evidence applies to which change.

Keep collaboration attached to the card

Several interaction patterns are worth evaluating:

• Interactive takeover: A human works synchronously with an agent, resolves a blocker, and returns the card to background execution.
• Document review: Line comments and approvals remain attached to the product or technical design.
• Preview annotations: A site-review widget records UI feedback against the relevant card.
• Consolidated inbox: Questions and approval requests appear together instead of requiring constant board inspection.

Integrations should let teams choose execution tools without rewriting workflow policy. Codex, Claude Code, OpenRouter, and MCP can serve different roles in that setup; don't assume they provide identical capabilities or permission models. Compare AI code generation tools by how they fit the workflow, not just their demos.

A local bridge can run workers through user machines and subscriptions rather than a central model proxy. That arrangement gives teams direct control over execution, but operators still need clear policies for credentials, machine availability, artifact retention, and permitted network access.

Benefits, Risks, and the Real Productivity Trade-Off

The highest ROI is human time released for work that shouldn't be delegated autonomously. Product design and distribution are central examples. An implementation agent is useful when it lets a lead develop a better product or reach customers, not when it produces more changes for that lead to babysit.

Well-specified cards are the strongest starting point. Routine fixes and contained features let agents work toward an observable result. Ambiguous cards invite plausible but unwanted behavior, followed by human review and correction.

A merged PR isn't the whole story

In a study of 8,106 agent fix-related pull requests, 65.0% were merged, while 26.1% were closed without merging and 8.9% remained open, according to the agent PR integration study. Failed tests and issues already solved by another PR were common reasons for non-integration. That means rejected work isn't always evidence of poor code, but it still consumes resources.

Another empirical study found human intervention in 52.17% of agent PRs. Of recorded intervention effort, 58.02% involved guidance, such as restricting actions or enforcing conventions, according to the developer intervention research. Guidance is real work even when the human never edits a file.

In the workflow behind this guide, a recurring observation is that cards needing attention often have incomplete product design. Agent-generated PRs can pass without human code fixes, but that doesn't mean they required no human judgment. Clear design work happens before the patch exists.

Watch the downstream queue

A large-scale analysis reported 30% more generated code, 20% more commits, and 23% more PRs, but 49% longer average time from PR submission to merge, as summarized in Ars Technica's coverage of agent productivity. That's a warning against treating output volume as delivered value.

Track human review time, unplanned interventions, and post-merge defects alongside implementation speed. Separate scheduled human checkpoints from unexpected rescues, and distinguish guidance from direct code fixes.

ROI test: Did this accepted change release human attention, or did it move the same work into review?

If intervention isn't instrumented yet, say so. An impression that agents usually need little help isn't a reliable baseline for scaling them.

Choosing and Comparing Models Without Guesswork

Adversarial review across different models is a useful working pattern, not proof that any model pairing is automatically superior. The practical observation behind this workflow is that different models can challenge each other's assumptions. That gives teams a reason to test the pattern against a simpler single-model setup.

A single model implementing and reviewing its own patch has less orchestration overhead. A separate reviewer adds another run and may generate unnecessary objections. The right comparison asks whether independent review prevents meaningful errors without creating excessive fix cycles.

Make the reviewer challenge the patch

Give the reviewer the same card and approved designs, but ask it to evaluate evidence rather than polish the worker's summary. For example, Codex could implement a card while Claude reviews it, or the roles could be reversed. Treat those pairings as experiments, not established rankings.

• Conformance: Identify requirements the patch doesn't satisfy.
• Behavior: Check failure paths, boundaries, and unintended changes.
• Evidence: Distinguish executed checks from unsupported assertions.
• Actionability: Explain the problem and expected correction without rewriting unrelated code.

The worker should answer findings with a patch or a reasoned explanation. A human should resolve genuine product or architectural disagreements. Otherwise, agents can spend repeated rounds arguing about preferences.

Compare accepted outcomes

Record the worker model, reviewer model, card type, verification results, and outcome on each card. Compare cost per completed card, fix rounds, and hours to merge, not just generation latency. Include unsuccessful attempts so a cheap run that never produces an accepted change doesn't look efficient.

An LLM cost comparison helps frame spend, but usage price alone doesn't identify the right model. A more expensive worker may need less correction; a cheaper reviewer may miss important design drift.

Keep task categories separate. Small bug fixes, UI changes, and cross-cutting architectural work test different capabilities. When changing models, preserve the evaluation criteria and record workflow changes that could explain a different result. That makes selection an engineering decision rather than a preference for whichever response sounds most convincing.

Adoption Guidance and Evaluation Criteria for Teams

Start with a narrow, reversible card type. A reproducible bug or a small web feature with clear acceptance criteria is easier to evaluate than a broad refactor. Keep sensitive permissions, customer-data changes, and unclear architectural work outside the initial autonomous scope.

Before expanding, establish how the team will detect failure and who owns each decision. Instrument the pilot from the start. Without a baseline, engineers can notice faster implementation while overlooking longer review or more interruptions.

Pilot, instrument, then expand

• Pilot: Choose work with observable acceptance conditions and a dependable test environment.
• Instrument: Log cost per finished card, fix rounds, hours to merge, merge rate, and intervention type.
• Define escalation: Pause for unclear requirements, prohibited actions, architectural deviations, or repeated verification failures.
• Expand selectively: Broaden scope where accepted outcomes justify it, not because agents can attempt more work.

Set explicit ownership for product approval, technical decisions, and release authorization. A card marked needs-you should identify the unresolved question and the evidence needed to answer it. Humans shouldn't have to read an entire agent transcript to discover why a run stopped.

Evaluate the workflow, not the demo

Ask platform vendors to show how an actual card moves from intent to accepted PR. Inspect whether approvals bind to specific document versions, whether failed checks prevent advancement, and whether reviewers can reconstruct decisions.

Loupe is one option for this board-based approach. It connects product design, technical design, implementation, and review; includes worker and reviewer roles; and provides explicit “You” checkpoints. Its analytics include cost per finished card, merge rate, fix rounds, and hours to merge.

Teams can self-host it under the AGPL using Docker Compose with web, worker, and Postgres services, or use the hosted private beta. Self-hosting gives operators deployment responsibility as well as control, so evaluate backups, upgrades, and worker access before choosing that route.

Choose the system that makes delegation inspectable and stoppable. An agent workflow should help the team accept better changes, not merely start more runs.

---

Loupe offers an agent-driven board that connects approved designs, coding work, independent review, and human checkpoints. Visit Loupe to explore self-hosting or the hosted private beta, and evaluate it with a contained card whose cost, fix rounds, and time to merge you can track.