You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been using Spec Kit with a Claude Code (Opus 4.7) skill, and I've noticed a consistent pattern I wanted to check against others' experience.
Regardless of the actual complexity of the spec — amount of code change, number of files touched, or test complexity — the spec.md generated by /speckit-specify almost always lands somewhere around 13–20 functional requirements, unless I explicitly specify otherwise. It seems oddly insensitive to the underlying scope of the feature.
Is this something others are seeing too?
My concern is that for relatively simple, small feature work, this tends to over-stack FRs. The spec ends up carrying more requirements than the feature actually warrants, and I get the sense it's hurting the quality of the resulting implementation — the model spreads effort across requirements that didn't really need to exist, rather than doing a clean, focused job on the few that matter.
Curious whether this is a known characteristic, and if anyone has found a good way to get the FR count to scale more naturally with the real complexity of the change.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I've been using Spec Kit with a Claude Code (Opus 4.7) skill, and I've noticed a consistent pattern I wanted to check against others' experience.
Regardless of the actual complexity of the spec — amount of code change, number of files touched, or test complexity — the
spec.mdgenerated by/speckit-specifyalmost always lands somewhere around 13–20 functional requirements, unless I explicitly specify otherwise. It seems oddly insensitive to the underlying scope of the feature.Is this something others are seeing too?
My concern is that for relatively simple, small feature work, this tends to over-stack FRs. The spec ends up carrying more requirements than the feature actually warrants, and I get the sense it's hurting the quality of the resulting implementation — the model spreads effort across requirements that didn't really need to exist, rather than doing a clean, focused job on the few that matter.
Curious whether this is a known characteristic, and if anyone has found a good way to get the FR count to scale more naturally with the real complexity of the change.
Beta Was this translation helpful? Give feedback.
All reactions