A coding agent can quickly produce a proposal. The question remains: a proposal for what, for whom and under which rules?
For the IMIKNDEV cohort, I prepared a resource on Spec-Driven Development. The work begins before code generation.
Provide a clear context
The project context helps explain constraints: who needs the feature, where it fits and which behaviours already exist. Describing this context avoids leaving an unresolved operational decision to the code.
Describe observable behaviour
A feature is clearer when described through what users can do and what should happen than through a list of files to create.
Teaching example: for attendance tracking, specify who can record an absence, which session it belongs to and how a correction should appear. This illustrates the method; it does not document the rules of our internal application.
Prepare for review
Acceptance criteria provide a basis for checking the result. They make it possible to discuss expected behaviour, a missing case or a misunderstood rule.
A good specification does not guarantee a good result. It makes the request clearer and the review more concrete.
The workshop resource is available on GitHub. It supports learning; decisions and validation still need to be explained.