Preface

An account of AI centric software development

Puma wants this book to explain the thinking behind a great deal of practical work with software agents, and to expose that thinking to criticism. These are complementary aims. A method becomes easier to criticize when its assumptions and consequences are visible. It becomes more useful when readers can decide which parts fit their own work.

The subject is a way of connecting purpose, design, implementation, and evidence. AI agents make that connection unusually important. They can produce plausible code quickly, distribute work across multiple tasks, and maintain extensive records. They can also elaborate an assumption that nobody meant to make. A coherent plan, a clean architecture diagram, or a passing test suite can preserve a misunderstanding rather than expose it.

Practical engineering work provides the setting for the examples. Recurring questions concern resource lifecycles, execution, coordination, knowledge representation, and provenance. The examples make decisions, assumptions, and consequences inspectable; readers need not reproduce a particular collection of projects to examine the reasoning.

The case studies do not establish a finished, proven method. Nor do they show that every declared practice is followed consistently. A published standard says what its consumers should do. Source code shows a particular implementation. A test observes behavior under its conditions. A conversation explains an intention. These are different kinds of evidence, and the differences matter.

The account uses third-person references to Puma where describing stated views or inspected work. The explanations, exercises, and proposed alternatives are the book's synthesis. They should not be mistaken for quotations, a transcript of Puma's development sessions, or a claim that every suggested technique is already in routine use.

How to use this book

The chapters follow a change from an uncertain request to a usable result, then ask what happens when many such changes become an ecosystem. You can read them in order or start with a current problem. A developer struggling with resource ownership may begin with chapters 7 and 25. Someone coordinating several agents may start with chapters 18 through 22. A reader evaluating the approach critically may find chapters 27 and 31 useful companions to the opening.

A running example keeps the discussion concrete: an application acquires a local resource so another component can use it. Sometimes that resource is a model. The illustrative system has enough moving parts to expose identity, readiness, cancellation, ownership, and acceptance, but it is illustrative rather than a reconstruction of any one implementation. Each example states the behavior under discussion instead of expecting familiarity with that repository.

The exercises ask you to make decisions and produce inspectable artifacts. They do not require adopting a particular agent product or reproducing Puma's technology stack. You can perform most with a small application and an ordinary version-control workflow. The work should remain proportional. If an exercise exposes no consequential uncertainty in your task, record that conclusion and use the simpler path.

Experienced practitioners appear where they illuminate an actual choice. Their accounts include enthusiasm, restraint, failures, and changes of mind. Academic and technical sources provide additional distinctions and counterweights. Neither testimony nor a benchmark validates this entire method. References are included so you can inspect the basis of a claim rather than accept it on authority.

The repository cases are pinned to revisions inspected on 2 October 2026. Local tests were not rerun for this book; where results come from project reports or hosted logs, the wording says so. Living external sources were checked during the same research period. Software and model capabilities will change. The durable questions concern ownership, feedback, evidence, and the cost of decisions, not a permanent ranking of products.

The strongest criticism will identify a specific claim, an omitted condition, or a credible alternative. Perhaps a proposed boundary creates more work than it removes. Perhaps a record is too expensive to maintain. Perhaps an ordinary implementation followed by a demonstration would discover the problem faster. Those are useful objections. The book succeeds if it makes them easier to formulate and investigate.