Agentic Coding: 3 Micro Experiments Using SED and Subagents

Agentic coding means letting AI agents plan, write, test, and revise code with minimal hand-holding, using real tool calls and execution feedback instead of one-shot text generation. It differs from a chat-based assistant in one key way: the agent runs your tests, reads the logs, and repairs its own mistakes. It works best on multi-file features, automated test repair, and mechanical refactors, not on judgment calls that need a human's context.

TL;DR:

Agentic coding performs best on multi-file features and automated test repairs, not on judgment-heavy or security-sensitive tasks.

The core cycle involves planning, acting, observing, and repairing, often utilizing subagents to avoid context bloat and improve reliability.

Using dedicated worktrees, small experiments, and strict guardrails significantly reduces the risk of near-miss failures and security issues.

Most effective when starting with feature scaffolding, test repair loops, and refactors, with clear permissions and thorough logging for oversight.

Progress should be measured through pass rates, false positives, time-to-merge, and regression incidents to ensure safety and effectiveness.

What Is Agentic Coding, and How Autonomous Can It Get?
How Does the Agent Loop Actually Work?
What Does an Agentic Coding Workflow Look Like Day to Day?
What Are the Real Risks in Agentic Coding?
How Do You Build Guardrails Into an Agentic Workflow?
How Do You Get Started With Agentic Coding?
What I'd Tell Any Team Starting This Today
Ready to Try Agentic Coding Without Babysitting the Output?
Sources

What Is Agentic Coding, and How Autonomous Can It Get?

Autocomplete suggests a line. An agent finishes the feature. That gap is the whole story of agentic coding, an approach where coding agents interface with your file system, run terminal commands, and read execution logs to self-correct instead of waiting for you to paste an error back into a chat window.

A useful way to place any given tool on that spectrum is the Five Levels of Autonomous Programming, which run roughly like this:

Level 1: Assisted completion. The model finishes lines or short blocks; you approve everything.
Level 2: Chat-driven generation. You describe a change; the model writes it, but you copy, test, and wire it in yourself.
Level 3: Conditional automation. The agent edits files, runs commands, and iterates inside constraints you define. This is where most production tools sit today.
Level 4: High autonomy. The agent handles entire features or bug reports with light oversight.
Level 5: Full autonomy. Minimal to no human review, reserved for narrow, well-tested domains.

If your team assumes tools are already at Level 4 or 5, that mismatch is where most of the trust problems start. Set expectations at Level 3, and design your review process around it.

How Does the Agent Loop Actually Work?

Underneath the marketing language, every agentic coding system runs the same basic cycle: plan, act, observe, repair. The agent reasons about the task, calls a tool (editing a file, running a CLI command), reads what came back (test results, stack traces, linter output), and decides whether to keep going or fix something first.

That loop breaks down fast on anything nontrivial if a single agent tries to hold the whole task in its head. This is why serious implementations lean on a subagent pattern: a top-level orchestrator delegates narrow jobs (write the migration, update the tests, check the types) to smaller agents, each working with a tight, specialized context. Practitioner writeups on subagent decomposition point to this as the main fix for context bloat in multi-step coding tasks.

The repair half of the loop has its own name: SED, or Synthesize, Execute, Debug. The agent generates a candidate change, executes the test suite against it, diagnoses whatever fails, and either repairs or replaces the candidate before re-running. Research on LLM-generated code backs this up directly: generated programs suffer from what researchers call near-miss syndrome, meaning the code looks plausible but fails on execution, and an iterative SED-style repair loop measurably outperforms single-shot generation.

Synthesize a candidate fix or feature based on the current plan.
Execute it against real tests, not just a syntax check.
Debug by feeding the failure back into the next synthesis pass, repeating until tests pass or a budget runs out.

Recent multi-agent research pushes this further by assigning separate generator and critic roles that debug each other's output, an approach documented in iterative multi-agent debugging frameworks that show real gains on program-synthesis benchmarks over single-agent SED.

None of this works without state. Agents need persistent sessions, isolated dev worktrees or branches, and sandboxed execution so a bad command doesn't touch your main branch or production data.

Pro Tip: Give each subagent its own worktree, not just its own prompt. Context isolation without file isolation still lets one agent's half-finished edit leak into another's test run.

What Does an Agentic Coding Workflow Look Like Day to Day?

The fastest way to build trust in agentic coding is to keep the first experiments small, observable, and reversible. Three patterns cover most of what teams actually run in production.

Session-first development. Every agent run happens inside an ephemeral branch or dev worktree, tied to a named agent session you can inspect later. VS Code's agent sessions formalize this: you pick a harness, set permission levels, and the session persists so you can review exactly what the agent touched.

The feature-build micro-experiment. Scaffold the skeleton yourself, write the acceptance tests first, let the agent implement against those tests, verify the run, then merge. This mirrors how Adrian builds an app step by step, where planning and test scaffolding happen before generation, not after.

The automated test-repair loop. Point a SED-style repair agent at a flaky or failing suite and let it iterate: run, diagnose, patch, re-run. This is one of the highest-leverage entry points because the blast radius is small. A few practical notes:

Use a local harness for fast, cheap iteration on small repos or private code.
Switch to cloud execution when you need more compute or parallel subagents.
Keep a hard iteration cap so a repair loop can't run indefinitely against a broken test.
Always diff the final output against the original, even when tests pass.

What Are the Real Risks in Agentic Coding?

Near-miss syndrome is the risk that matters most, because it defeats a quick read-through. Code that compiles and looks reasonable can still fail edge cases your reviewer never thought to check, which is exactly why the ACM study on generated code found iterative execution and repair necessary rather than optional.

A few other failure modes show up consistently once agents start running longer, multi-step tasks:

Context bloat. Long sessions accumulate stale assumptions; the agent keeps building on a fact that changed three steps ago.
Security and supply-chain exposure. An agent that can add dependencies or edit config files can just as easily introduce a vulnerable package.
Over-automation. Removing human judgment entirely erodes the traceability you need when something breaks in production.

IBM's guidance on agentic coding frames the fix plainly: guardrails, review, and logging aren't optional extras, they're what makes agent output usable at all. Our own breakdown of why AI-generated apps compile but don't work covers the same failure pattern in more detail.

How Do You Build Guardrails Into an Agentic Workflow?

Reliability in agentic coding comes from constraints, not from a smarter model. A working checklist looks like this:

Define scope and permission levels before the agent runs. Decide what files, commands, and network access it can touch.
Sandbox anything risky. Database writes, deployments, and package installs happen in isolation, never against live systems.
Require tests and independent verification before any agent-authored change merges. No exceptions for "obviously simple" edits.
Log every action. Tool calls, intermediate outputs, and file diffs need to be auditable after the fact, not just visible in the moment.
Use subagents for single-responsibility tasks. A narrow job produces more predictable behavior than one agent juggling five goals.
Wire agents into CI/CD with approval gates. Automated runs still need a human checkpoint before production.

Pro Tip: Log agent actions the same way you'd log a junior engineer's first week: not because you distrust them, but because you'll want the trail the first time something breaks in a way nobody can immediately explain.

How Do You Get Started With Agentic Coding?

Run small before you run wide. Three experiments cover the useful range without much risk:

Scaffold a feature with acceptance tests written first, then let an agent implement against them.
Run a test-repair loop on a suite you already know has flaky tests, and measure how many it fixes cleanly.
Try a refactor with mandatory review, comparing the agent's diff against what a human would have written.

Before any of that, get your environment ready: a dedicated dev worktree, a sandboxed runner, a real test harness, and logging that captures every tool call. On the skills side, you'll get more out of agentic coding by writing precise acceptance tests, building reusable prompt templates, and learning to read execution traces quickly, since that's where you catch near-miss failures before they merge. If you're running models locally, check which local coding model fits your machine before committing to a workflow that assumes more RAM than you have.

Track four numbers as you scale: test pass rate, false-accept rate (code that passed review but broke later), time-to-merge, and regression incidence. If false-accepts climb, your review gate is too loose, not your model.

What I'd Tell Any Team Starting This Today

Agents earn their keep fastest on mechanical work: test repair, boilerplate features, refactors with a clear spec. Judgment calls, architecture decisions, and anything touching security still need a person who owns the outcome. At Adrian Labs, sandboxed builds and autonomous debugging exist because we don't trust a single generation pass either; we trust the repair loop and the audit trail behind it. Run one small experiment before you bet a sprint on it.

— Adrian

Ready to Try Agentic Coding Without Babysitting the Output?

Everything in this guide, the SED repair loop, sandboxed execution, session isolation, is what some platforms run under the hood when you describe an app in plain language. Instead of assembling a harness, a test runner, and a permission model yourself, you get a platform where planning, generation, testing, and autonomous debugging happen inside an isolated build.

Adrianlabs

If you want to see the pattern in action, start with a small build on Adrian's platform and watch how it scaffolds, tests, and repairs before you touch a line. If you're wondering exactly how your code and data are handled during that process, read where your code actually goes first. Either way, the fastest way to trust agentic coding is to run something small on it this week.