Agentic Workflows for Software Development: What Actually Works

I have been shipping code with agentic workflows for over a year now, across full-stack SaaS features, AWS serverless integrations, and the autonomous content systems I built for BizFlowAI. Most of what I read about "AI coding agents" online is theater. Demos that generate a function in isolation. REPL loops that work on a toy repo. None of that survives contact with a real codebase, a CI pipeline, or a production incident.

Here is what actually works when you wire LLM agents into a real software development loop. Not theory. Not what will be possible "someday." The patterns, tools, and guardrails I use today to ship production code with minimal human supervision.

The Four-Phase Loop: Plan, Execute, Review, Correct

A production agentic dev workflow is not a single prompt that says "write this feature." It is a four-phase loop where each phase has a distinct purpose, a distinct context window, and distinct failure modes. I learned this the hard way: early on, I tried to do everything in one pass and the agent would produce 600 lines of code, half of which contradicted the other half.

Phase 1: Planning. The agent reads the codebase, identifies the files that need to change, and produces a step-by-step implementation plan. No code gets written. The output is a structured plan: files to touch, functions to add, tests to write, risks to flag. I review this plan before execution begins. This is the cheapest place to catch a wrong assumption.

Phase 2: Execution. The agent implements the plan, file by file, running tests after each logical unit of work. This is where tool use matters most. The agent needs filesystem access, a test runner, and a linter. Without the test runner, you get code that looks right but is not.

Phase 3: Review. A second agent (or the same agent with a fresh context) reviews the diff against the original plan. Does the implementation match the plan? Are there unhandled edge cases? Did the agent introduce a regression? I run this as a separate context window to avoid the sunk-cost bias where an agent defends its own work.

Phase 4: Self-correction. If review finds issues, the agent patches them and re-runs tests. If tests pass, the loop exits. If the agent fails twice on the same issue, it escalates to me.

The critical insight: separate the context windows. Do not let the planning context bleed into the execution context, and do not let the execution context bleed into the review context. Fresh context for each phase means the agent reasons about the current state, not the history of how it got there.

Tool Selection: What I Actually Use in 2026

I have tried most of the agentic coding tools that exist. Here is my honest assessment of what holds up in production:

My daily driver for BizFlowAI and client work is Claude Code for the heavy lifting, with a custom orchestration layer on top for the autonomous content pipeline where I need scheduled execution and self-evaluation. For quick fixes and interactive work, I use Cursor.

The point is not which tool is "best." The point is matching the tool to the task. A 15-file refactor with database migrations needs a planning-heavy agent loop. A one-line bug fix in a React component needs an inline completion. Using the wrong tool for the job is the most common mistake I see.

Planning Context: The Make-or-Break Phase

The planning phase is where agentic workflows succeed or fail. I have spent more time tuning my planning prompts and context construction than anything else in my pipeline. Here is what I have learned.

Give the agent a map, not the whole territory. Early on, I would dump entire codebases into the context window. This works on small projects but falls apart on anything with real complexity. Instead, I provide a curated context: the relevant files, the project structure, the coding standards document, and recent git history. The agent does not need to see every file. It needs to see the right files.

Require structured output. The planning phase must produce a machine-readable plan, not a prose essay. I use a format like this:

## Implementation Plan

### Files to Modify
1. `src/api/handlers/content.ts` — Add new endpoint for draft publishing
2. `src/db/queries/content.ts` — Add `publishDraft` query
3. `tests/api/content.test.ts` — Add integration test for new endpoint

### Steps
1. Add `publishDraft` query with proper error handling
2. Create endpoint handler with input validation
3. Write integration test covering happy path and error cases
4. Run full test suite to verify no regressions

### Risks
- Draft publishing touches the same table as the scheduler. Verify no race condition.

This structure does two things. It forces the agent to think concretely before writing code. And it gives the review phase a clear spec to check against.

Budget for planning tokens. Planning is cheap. Writing wrong code and then debugging it is expensive. I would rather spend 10,000 tokens on a thorough plan than 50,000 tokens on a failed implementation. Treat the planning phase as an investment, not overhead.

Execution and Tool Use: Where Agents Earn Their Keep

Execution is the phase that gets the most attention and where most implementations are weakest. The difference between a toy agent and a production agent is tool integration.

A production coding agent needs at minimum:

• Filesystem read/write with respect for .gitignore and project conventions
• Shell access for running tests, linters, and build commands
• Git operations for creating branches, staging changes, and reading diffs
• Search across the codebase for symbols, patterns, and references

The agent must run tests after each change, not at the end. I configure my execution loop so that after every logical unit of work (one function, one endpoint, one component), the test suite runs. If tests fail, the agent gets the error output in context and patches immediately. This is how a human engineer works. Your agent should do the same.

One thing that took me too long to learn: cap the number of iterations. An agent stuck in a loop, making the same change and hitting the same error, will burn through tokens fast. I set a hard limit of three attempts per issue. After three failures, the agent logs the problem and escalates. This single guardrail cut my token spend on BizFlowAI's content pipeline by roughly 30% without any loss in output quality.

MAX_RETRIES = 3

for attempt in range(MAX_RETRIES):
    result = agent.execute(plan_step)
    if result.success:
        break
    agent.feed_error(result.error)
else:
    log_escalation(plan_step, result.error)
    notify_human()

This is not fancy code. It is a guardrail that prevents a minor test failure from becoming a $50 API bill.

The Review Phase: Why Agents Cannot Grade Their Own Homework

Self-review is the most overclaimed capability in agentic coding. Yes, an agent can review a diff. No, the same agent that wrote the diff should not review it. Context bias is real and measurable.

I run review as a separate invocation with a fresh context window. The reviewer agent gets:

1. The original plan
2. The final diff
3. The test results
4. The project's coding standards

It does not get the conversation history from planning and execution. This prevents the reviewer from rationalizing decisions made during implementation.

The review prompt is specific. I do not ask "is this code good?" I ask targeted questions:

• Does every function in the plan exist in the diff?
• Are error cases handled for every external call?
• Does the code follow the project's existing patterns (naming, error handling, file structure)?
• Are there any console.log or debug statements left behind?
• Do the tests actually assert the behavior described in the plan?

I got more concrete results from specific review questions than I ever did from open-ended review prompts. Vague prompts produce vague reviews. Specific prompts produce actionable feedback.

For critical paths, like database migrations or payment flows, I still do a human review on top of the agent review. The agent catches syntax issues, missing tests, and pattern violations. I catch business logic errors and architecture decisions that require domain knowledge the agent does not have.

Pitfalls I Have Hit So You Do Not Have To

Context poisoning from failed runs. If an agent attempts a task, fails, and you retry in the same context, the failure context poisons the next attempt. The agent "remembers" the wrong approach. Always start a retry with a fresh context window that includes only the plan and the current state of the code.

Over-reliance on a single model. I have pipelines that use Claude for planning and execution, then run the review step with a different model. Cross-model review catches biases that a single model will consistently miss. This is not theoretical. I have seen Claude miss an edge case in its own code that GPT-4 flagged immediately, and vice versa.

No evaluation harness. If you are running agentic workflows on a schedule (like my content pipeline), you need automated evaluation. Not every run, but sampled. I run evaluations on 10% of outputs using a separate LLM-as-judge prompt that checks against quality criteria. When quality dips, I get alerted before it affects the end product.

Ignoring token costs on long loops. A coding agent that runs for 45 minutes can easily consume 200,000+ tokens. At current pricing, that is real money. Monitor your token spend per task. Set budgets. I track cost-per-task across my pipelines and flag any task that exceeds 2x its historical average.

What I Would Do Differently If Starting Today

If I were building an agentic dev workflow from scratch in 2026, here is exactly what I would do:

1. Start with Claude Code for the agent loop. It has the best out-of-the-box tool integration and codebase understanding I have worked with.
2. Write a detailed CLAUDE.md (or equivalent project context file) that documents architecture, conventions, and testing commands. This file is the single highest-leverage investment you can make.
3. Build the four-phase loop: plan, execute, review, correct. Separate context windows for each.
4. Add iteration caps and token budgets from day one. Not after the first $200 bill.
5. Set up a sampled evaluation pipeline so you catch quality regressions early.
6. Keep a human in the loop for planning approval and final review on anything that touches production data, payments, or infrastructure.

The teams and founders I talk to who are failing with agentic workflows are almost always skipping step 3 or step 4. They let the agent run free, skip the review phase, and then are surprised when the output is inconsistent.

Agentic software development is not about replacing engineers. It is about building a reliable loop that handles the repetitive 70% of implementation work so you can focus on the 30% that requires judgment, domain knowledge, and trade-off thinking. Get the loop right and the leverage is significant. I have automated content pipelines and serverless integrations that run on this pattern with minimal supervision, saving dozens of hours per month.

If you are building agentic workflows for software development and want to compare notes, or you need help designing a production-grade agent pipeline for your team, reach out at lazar-milicevic.com/#contact. I work with a small number of companies on AI automation and LLM engineering engagements, and I am always up for a hard architecture problem.