The dangerous weather example seems like a poor example. Most fields I would add would be orthogonal to existing functionality, and if they weren't, I would account for things I need to change (e.g. the is dangerous function) during the specification phase.
As an example of what I mean: The spec for "is dangerous" would have specified what "dangerous" means, and if that included high speeds, then that would have been known in advance when I made a plan to implement the speed feature.
The reason I mention this is that agentic coding seems to be requiring us to move to "spec-driven development" and it behooves us all to learn how best to adapt to this new landscape.
A simple example of an inline spec (i.e., a spec living as a comment in the code file, a bit like literate programming) for "is dangerous" would be something like:
/*
* dangerous = anything that would cause a risk of getting hurt for a healthy adult, e.g. heat stroke, lightning strike, hypothermia, gale force wind, flood, hurricane, tsunami, earthquake
* Not all of this is implemented now, but that is what this function should try to do.
*/
As an example of what I mean: The spec for "is dangerous" would have specified what "dangerous" means, and if that included high speeds, then that would have been known in advance when I made a plan to implement the speed feature.
The reason I mention this is that agentic coding seems to be requiring us to move to "spec-driven development" and it behooves us all to learn how best to adapt to this new landscape.
A simple example of an inline spec (i.e., a spec living as a comment in the code file, a bit like literate programming) for "is dangerous" would be something like: