Re:In Praise Of –Dry-Run
by wging on Saturday January 31, 2026 @08:57PM
(#46842909)
One nice way to do things, if you can get away with it, is to model the actions your application takes explicitly, and pass them to a central thing that actually handles them. Then there can be one place in your code that actually needs to understand whether it's doing a dry run or not. Ideally this would be just returning them from your core logic, "functional core, imperative shell" style.
[ Parent
| on HN ]
I totally agree with both this and the comment you replied to. The common thread is that you can architect the application in such a way that dry vs. wet running can be handled transparently, and in general these are just good designs.
Re:In Praise Of –Dry-Run
by IgorPartola on Saturday January 31, 2026 @09:56PM
(#46843201)
That’s what I prefer as well. A generation step and an execution step where the executor can be just a logger or the real deal.
Re:In Praise Of –Dry-Run
by clawsyndicate on Sunday February 01, 2026 @07:32AM
(#46845776)
we rely on this separation for our agents. the llm outputs a declarative json plan that gets validated against security policies before the runtime executes any side effects. catching a bad command during validation is way cheaper than rolling back a container.