Requisite Variety

A Systems Method for Working with AI

Tips and prompt collections go stale within months. This book offers a method instead — a way to see your work with AI as a system, set goals, organize the activity and grow the practice — that will outlive any change of models.

The theoretical spine

The entry door is Ashby’s law of requisite variety: only a controller whose variety is at least as large as the variety of the process can control that process. Systems methods are variety engineering: they amplify the human’s variety and attenuate the machine’s excess variety.

But Ashby’s law is the door, not the house. Behind it stands the systems theory of the twentieth century — Ashby himself, Stafford Beer, and the general theory of systems and activity that grew out of cybernetics. Every system drifts toward a goal of its own. Activity breaks into components that don’t substitute for one another. Norms are variety stored in writing. Control is a tolerance zone built into the design, not a matter of attention. A system that has stabilized goes quiet — and rusts unnoticed. The book takes these regularities and gives them the language of daily engineering practice.

Tools come and go. The model you use today will be replaced before this book is finished; the agent you’ll run next year doesn’t exist yet. The regularities stay, because they are about how systems behave, not about how a particular tool is built. Learn them once — and you can work with any new tool, now and whatever comes after.

Four reading tracks

  • Main — engineers: code, review, debugging, architecture, legacy, agent pipelines.
  • Creators — non-engineers making their own tools with vibe coding: finance, HR, operations, support — Part V speaks to them directly.
  • Side — everyone who works with LLMs: every chapter closes with a sidebar «In your craft».
  • Overview — managers: Part VI, deliberately compact.

Finished chapters