Agentic coding is changing what it means to be a software developer.
Traditionally, writing code consumed a large portion of a developer's day. As AI code agents become more capable, the developer's role is shifting — from writing every line to guiding, supervising, and validating AI-generated work.
A typical workflow now looks something like this:
- Maintain a high-quality knowledge base that accurately captures business requirements and architectural decisions.
- Select the right LLM to generate technical specifications from that knowledge base.
- Review and approve the generated specs before any code is written.
- Use a coding model to implement the approved specifications.
- Review the AI-generated code, reasoning, and comments — refine where necessary.
- Serve as the final gatekeeper, ensuring every change meets production standards for correctness, security, maintainability, and performance.
Rather than replacing developers, agentic coding shifts more of our effort from writing every line to reviewing, orchestrating, and validating. Strong engineering judgment is becoming more valuable, not less.
I've been experimenting with this workflow for .NET backend development under the name Supervised Secure Agentic Coding (SSAC).
The Problem with Pure Agentic Coding
Turning an AI agent loose on a codebase often feels like running a hackathon: fast early wins, inconsistent quality, and a lot of cleanup before anything is production-ready.
The failure modes are predictable:
- Request misalignment — Code compiles and runs but doesn't match the actual business requirement.
- Over-complex generation — Unnecessary abstractions, extra dependencies, scope the team never asked for.
- Rapid AI technical debt — Inconsistent patterns and shortcuts accumulate faster than a human team would allow.
- Overconfidence and hallucinations — Confident-sounding output hides wrong APIs, invented types, or broken assumptions.
The fix isn't to abandon agents — it's to treat them like a capable but junior contributor: give them clear boundaries, the right tools, and a review gate before anything ships.
The Three Pillars of SSAC
1. Guardrails as Architectural Constraints
Without guardrails, an agent may invent data models, bypass existing patterns, or pull in libraries that don't fit your stack.
Example constraint you might give an agent:
You can implement this endpoint, but you must follow our existing repository patterns, you cannot change the database schema without approval, and every public API must include consistent error handling.
The agent still moves quickly — it just moves inside the sandbox you define.
2. Skills as Specialized Tooling
A general-purpose model has to guess how your project works. Skills turn guessing into repeatable capability: run tests, query a schema, read internal docs, search the codebase for precedents, or follow the spec format your team already uses.
Well-chosen skills shift the agent from guessing to operating with the same tools a mid-level developer would reach for on day one.
3. Approvals as the Definition of Done
Supervision isn't optional. Generated code should pass the same bar as human-written code:
- Acceptance criteria are explicit before work starts.
- Automated checks (tests, lint, build) run before review.
- A human approves or rejects the result in a pull request.
If the output fails on security, performance, or business logic, it goes back to the agent with feedback — same loop as any other code review.
The Two Loops
SSAC operates on two decoupled iterative cycles:
- The Planning Loop (Requirements → Specifications): Refine high-level business goals into rigorous, deterministic markdown specs before a single line of code is written.
- The Execution Loop (Specifications → Production Code): Agents write code locally, iterating against local tests and lints until they hit the human approval gate.
Secure by Design
Many enterprise environments can't leak source code, credentials, or internal schemas to public cloud LLMs. SSAC addresses this directly with a local-first approach:
- Open-weight models running via vLLM, llama.cpp, or Ollama keep all project context inside your network boundary.
- GGUF quantization lets you run capable models on consumer-grade workstation GPUs (16–24 GB VRAM).
- Mixture-of-Experts (MoE) models split compute across RAM and VRAM, unlocking deeper reasoning without enterprise hardware budgets.
For cost routing, the strategy is simple: use open-source models for routine tasks (linting, basic refactoring) and reserve premium cloud models strictly for complex, high-risk architectural decisions.
The Open-Source Stack
The framework is agent-agnostic and LLM-agnostic — swap out the agent as long as skills and guardrails are configured for it. The demo defaults to OpenCode, but the workflow is not locked to it.
Key tools used in the reference setup:
- OpenSpec — spec-driven agent workflows
- GitNexus — local semantic search over your codebase
- Obsidian MCP — bring internal documentation into agent context
- Karpathy LLM Wiki — wiki-style knowledge base ingestion
What This Means for Developers
The developer's role doesn't disappear — it evolves. You become:
- A toolsmith: maintaining guardrails and skills that constrain and enable the agent.
- A specification writer: capturing business requirements clearly enough for an agent to implement them correctly.
- A gatekeeper: reviewing, reasoning about, and approving AI-generated changes — same standards as human-written code.
The engineers who thrive in this model are the ones with strong enough intuition to know when the output is wrong, even when it looks right.
If you're interested in how this works in practice for .NET backend development, check out the repository:
👉 github.com/robert-li/SupervisedSecureAgenticCoding
Issues, guardrail templates, and .NET-focused skills are welcome contributions.
Top comments (0)