I developed this standard for my team at Edensoft Labs for agentic coding in defense software, where systems stay deployed for decades and weak code becomes operational risk. Agentic coding tools are powerful, but not magic: they don't write maintainable code on their own, and code generation is just the first part of software delivery. Other essential work includes requirements, specification, verification against real system behavior, and refactoring around it, because agents generate code, but humans must own every line shipped. Here’s a flyby overview of the standards:
Agentic Coding Standards
Tier 1: Requirements
[RI1] Conduct stakeholder interrogation before writing any specification. Document what was agreed, what was ruled out, and what remains uncertain
[RI2] After stakeholder interrogation, conduct agent interrogation. Ask the agent to interview you about every assumption, constraint, and edge case before any code is generated
[RI3] Both interrogation outputs are written artifacts stored in a durable location, not in memory or a chat window
Tier 2: Planning
[TD1] Before any significant agent session, confirm the task is fully specified and the output is independently verifiable
[TD2] If either condition is not yet met, complete the preparation work before starting the agent session
[TD3] If either condition can’t be satisfied, keep the agent in exploratory mode. Exploratory output should not be committed to the mainline until both conditions are met
Tier 3: Foundational engineering habits
[SP1] Complete the specification conversation before any agent generates code
[SP2] Document constraints, invariants, and edge cases before generation starts
[SP3] Be explicit about what must not be sacrificed in pursuit of the objective
[EM1] Before diagnosing or changing code, the agent must inspect actual data, logs, errors, tests, and system state
[VT1] Every piece of agent-generated output is verified against actual system behavior before being accepted, regardless of how confident the agent appeared
[DW1] Direct the agent to document intent, rationale, and constraints inline as it generates code
[DW2] Every significant decision made during an agent session must be traceable in the code
[DW3] Don’t accept agent-generated code that lacks documented rationale for significant decisions
[RF1] Refactor for architectural fit before review
[RF2] Refactor for naming consistency before review
[RF3] Refactor for duplication before review
[RF4] Refactor for simplicity before review
[RF5] Does it fit the existing architecture?
[RF6] Does it preserve conceptual integrity?
[RF7] Does it introduce complexity that wasn't worth the cost?
[RF8] Does it damage quality attributes that matter more than the feature itself?
[RF9] Is this the simplest good solution, or just the fastest plausible one?
Tier 4: Agent supervision skills
[TB1] Break agent work into bounded tasks with clear checkpoints
[TB2] Build a validation loop into the task wherever possible
[TB3] When agent output gets shaky, reduce the scope. Tighter boundaries produce more dependable agents
[TB4] Specification first. Generation second. Verification third. Refactoring fourth. Each pass has one job
[TB5] For significant multi-step work, structure the workflow as an orchestrator session directing subagent sessions
[TB6] When working in a single session, manage context rot by ending the session early and handing off deliberately
[AM1] Inspect intermediate output during the session, not just the final diff
[AM2] For actions that can't be undone, remove the capability structurally
[AM3] Don't rely on agent instructions to prevent destructive actions
[AM4] When you review agent-generated code, it’s your responsibility to ensure it’s built on correct assumptions about the system, not just whether it works
[AM5] Implement hooks to enforce structural constraints deterministically in the agent's execution pipeline
[AM6] For large or architecturally significant agent runs, ask the agent at the end of the session to list any decisions it made that weren't explicitly covered in the specification
[RD1] Reviewers must evaluate agent-generated PRs for pattern consistency, architectural fit, and maintainability, not just test results
[RD2] Apply RF5 through RF9 before approving any agent-generated PR
[AC1] If you check in agent-generated code, your name is on it
[AC2] Ownership means comprehension. If you merged it, you can explain what it does, why it was built that way, and what it touches in the system
[CU1] Optimize for engineering leverage, not raw token minimization
[CU2] Before any significant agent session, define the question being answered, the files in scope, the expected output, and when to stop
[CU3] Before the agent executes a task, ask it to map its intermediate steps and review them before giving the go-ahead
[CU4] Match the model to the task. Use lighter models for mechanical work and reserve frontier models for tasks that require complex reasoning
[CU5] Provide the context that matters for the task, organized so the agent can reason from the right facts
[CU6] Don’t make the agent rediscover context you already have
[CU7] Stop and rescope when the agent starts thrashing
[CU8] Capture useful understanding from sessions in durable artifacts
[CU9] Treat excessive token usage as a workflow problem, not a budgeting problem
Tier 5: Systems engineering discipline
[AO1] Before every session, re-orient the agent to the architectural patterns and invariants of the system. Don’t assume it remembers
[AO2] Before directing an agent to make a change, trace the full impact boundary yourself. The agent can’t do this reliably
[AO3] Keep system architecture diagrams current. Update them when the architecture changes, immediately, not deferred
[AO4] Run an agent-assisted architectural drift scan at minimum monthly, and more frequently on active codebases
[SI1] Challenge every new abstraction, layer, dependency, and generalized solution before accepting it
[SI2] Design modules with a small, simple interface and substantial internal functionality
[SI3] Design for Service → Namespace → Class → Method navigability. Any engineer or agent should find the relevant code in seconds and safely ignore 99% of the rest
[DK1] Before directing an agent on a feature, understand the user needs, product constraints, and quality attributes that shape the solution
Code that works, passes tests, looks clean, and that nobody can explain is risky "dark code”. Strong discipline is needed to leverage agents to achieve 2x-10x productivity gains. Weak discipline will result in accumulating technical debt at machine speed.
You can get the full 29 page document from my LinkedIn page: https://www.linkedin.com/pulse/engineering-standards-agentic-software-development-edensoft-park-ki1se/
