https://stackresearch.org/editorial/Recent content in Editorial on Stack ResearchHugoen-usSun, 08 Mar 2026 00:00:00 +0000https://stackresearch.org/editorial/build-for-the-hour-after-failure/Sun, 08 Mar 2026 00:00:00 +0000https://stackresearch.org/editorial/build-for-the-hour-after-failure/<p>At 4 a.m., the model is rarely the whole problem. The missing recovery path is.</p> <p>Agent systems are often designed around the moment before action: the prompt, the tool schema, the evaluator, the approval check, the confidence score. Those pieces matter. They shape whether the system should act at all. But the harder question arrives after a bad action has already crossed the boundary into production.</p> <p>What stops next? What is still allowed to run? Which identity was used? Which records changed? Which downstream systems trusted the result? Which part can be reversed, and which part can only be compensated for?</p>https://stackresearch.org/editorial/software-that-expires/Mon, 16 Feb 2026 00:00:00 +0000https://stackresearch.org/editorial/software-that-expires/<p>Software accumulates by default.</p> <p>Features go in. Compatibility layers remain. Old state keeps its place because removing it feels riskier than carrying it. A temporary endpoint becomes a customer dependency. A migration flag survives long after the migration. A data field whose meaning has changed three times continues to answer because some quiet part of the system still asks for it.</p> <p>The usual word for this is technical debt, but debt is too clean a metaphor. Debt has a lender, a balance, and a date on the bill. Software decay is less orderly. It is closer to sediment. Each layer is understandable when it lands, and opaque once enough layers have settled above it.</p>