---
title: "Discussion on \"How much specification does an agent need?\" | Hashnode"
description: "Discussion on \"How much specification does an agent need?\". How much specification do coding agents need? On existing context, open questions, and decisions that emerge during implementation."
url: "https://hashnode.com/posts/how-much-specification-does-an-agent-need/6aa46924a9b5f506090a6413"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [How much specification does an agent need?](https://arvindand.hashnode.dev/how-much-specification-does-an-agent-need?utm_source=hashnode&utm_medium=feed)

How much specification do coding agents need? On existing context, open questions, and decisions that emerge during implementation.

Sep 11 · 6 min read · arvindand.hashnode.dev  
Read the article

-   [#software-architecture](https://hashnode.com/tag/software-architecture)
-   [#ai-agents](https://hashnode.com/tag/ai-agents)
-   [#spec-driven-development](https://hashnode.com/tag/spec-driven-development)
-   [#software-engineering](https://hashnode.com/tag/software-engineering)

## Written by

[Arvind Menon](https://hashnode.com/@arvindand)

@arvindand · Amsterdam, Netherlands

  
[View profile](https://hashnode.com/@arvindand)

Software Architect with 9+ years in Java, Spring Boot, and cloud-native architectures. Building MES software at Rockwell Automation. Also exploring AI tooling and agentic systems.

## Responses 5

Markdown supported · ⌘↵ to post

[Dmitry Yurkin](https://hashnode.com/@dmitry-yurkin)

[Oct 23](https://hashnode.com/posts/how-much-specification-does-an-agent-need/6aa46924a9b5f506090a6413/comment/6adb4bdf5ae06650eaeec2bb)

I'd scope the spec to the behavior being changed and the contracts it must preserve. In your caching example, a rule such as "reads may be 30 seconds stale, but a successful write invalidates the entry" gives the agent a boundary while leaving implementation choices open. Decisions that change those boundaries need review and a corresponding specification update.

In Reqode, we've made the change itself the handoff: a Change Request groups affected specification revisions, and the coding agent retrieves the relevant context through MCP. The task can stay short because it points to the agreed specifications.

[Arvind Menon](https://hashnode.com/@arvindand)

[Oct 31](https://hashnode.com/posts/how-much-specification-does-an-agent-need/6aa46924a9b5f506090a6413/comment/6adb4bdf5ae06650eaeec2bb#reply-6ae664a2fb66ed37b336da7f)

Makes sense! Stating the boundary (how stale, what invalidates it) and leaving the mechanism open is roughly where I’d want the spec to stop. Anything that moves the boundary then needs a discussion and a spec update.

Grouping the spec revisions under the change makes sense to me, as long as the reasoning also ends up with the system’s documentation.

[Vlad Zoff](https://hashnode.com/@vladzoff)

[Oct 1](https://hashnode.com/posts/how-much-specification-does-an-agent-need/6aa46924a9b5f506090a6413/comment/6abdf3b252950c0a4520735f)

The distinction between requirements and evidence is the part I find most useful. A spec can tell an agent what to build, but it doesn't prove it built the right thing. For production tasks I want acceptance criteria tied to repeatable checks, and open decisions to be explicit rather than silently inferred.

[Arvind Menon](https://hashnode.com/@arvindand)

[Oct 31](https://hashnode.com/posts/how-much-specification-does-an-agent-need/6aa46924a9b5f506090a6413/comment/6abdf3b252950c0a4520735f#reply-6ae6641a484f04de61ef96a4)

Agreed, and I think that’s where the spec and the evidence have to meet. A spec can describe what “right” looks like, but only checks we can rerun show that we got there. It seems worth writing acceptance criteria with the check in mind (which test or measurement would show it holds). If I can’t name the check, the criterion is probably too vague.

The open decisions are the harder part for me. Agents are good at quietly picking a reasonable answer, so making those explicit has to be something we ask for rather than something we expect. Do you have the agent flag them as it goes, or do you mostly catch them in review?

[Vlad Zoff](https://hashnode.com/@vladzoff)

[Nov 1](https://hashnode.com/posts/how-much-specification-does-an-agent-need/6aa46924a9b5f506090a6413/comment/6abdf3b252950c0a4520735f#reply-6ae73c915cc46e26e58aa7fc)

I try to catch them as early as possible, ideally during planning, rather than relying on review to uncover them. I ask the agent to separate confirmed requirements from assumptions and open decisions. If a decision affects user-visible behavior, data contracts, security, or scope, it should stop and ask instead of silently choosing. For low-risk, reversible details, it can make a reasonable choice, but should record the assumption. Review is still important, but it should validate those decisions rather than be the first place they become visible.