Vishal Rajpurohit
Bring the software problem
Engineering LeadershipAdvanced12 chapters

Shipping With Agents

Running an engineering organisation when machines write most of the code

When authorship stops being the constraint, specification and review become it, and an organisation that keeps its old review, ownership and measurement model just converts a coding bottleneck into a queue.

Merge rate goes up, cycle time does not move, and everyone blames the tooling. The tooling is fine; the operating model is not. This book redesigns the functions that authorship used to absorb: what a specification has to contain now, how to triage review by risk, what PR size and queue discipline actually buy, who owns code nobody typed, how tests become the contract with the agent, and which delivery metrics still mean anything once most committed code is machine-written.

Written for: CTOs, VPs and team leads whose merge rate went up and whose cycle time did not.

Read the chapter planTalk to Vishal

No chapter is published yet. The full contents below is the finished outline; chapters go live as they are written, and none of them will sit behind a signup.

Jacket for Shipping With Agents — Running an engineering organisation when machines write most of the code

What it makes operable

Outcomes, not topic coverage.

  1. 01Redesign review as scarce capacity, with triage, size limits and a named owner per queue
  2. 02Write specifications and tests that hold an agent to a contract
  3. 03Measure delivery when most committed code was not typed by a person
  4. 04Keep ownership and craft intact as adoption increases

Complete contents

12 chapters, in order.

Each chapter settles one decision, so it can be read on its own. Read in sequence to build the argument the book is making.

  1. 01

    The Bottleneck Moved

    More merged pull requests, the same cycle time, and where the hours went.

    In writing
  2. 02

    What a Specification Has to Contain Now

    Writing intent precisely enough that a machine can implement it.

    In writing
  3. 03

    Review as the Scarce Resource

    Treating reviewer attention as capacity to be planned, not goodwill to be spent.

    In writing
  4. 04

    Automated First-Pass Gates and Risk-Based Triage

    Moving baseline correctness off people, and routing low-risk change around them.

    In writing
  5. 05

    PR Size, Batching, and Queue Discipline

    Limits and batching rules that stop the queue from becoming the product.

    In writing
  6. 06

    Ownership When Nobody Typed the Code

    Accountability, on-call and code ownership for generated change.

    In writing
  7. 07

    Tests as the Contract With the Agent

    The suite as the specification an agent is actually held to.

    In writing
  8. 08

    Measuring Delivery When DORA Stops Working

    Which metrics survive, which mislead, and what has to be added.

    In writing
  9. 09

    Juniors, Craft, and Not Deskilling the Team

    Building judgement in people who never had to write the easy version.

    In writing
  10. 10

    Tooling Budgets and Where the Money Actually Goes

    Seats, tokens, compute and review hours, costed against delivered change.

    In writing
  11. 11

    Security and Compliance Inside the Loop

    Putting controls where the agent works instead of downstream of it.

    In writing
  12. 12

    Adopting This Without Breaking the Team

    A sequence of changes engineers will not have to resist.

    In writing

Evidence

What this book is arguing against.

Third-party sources behind the book's premise. Every figure in them belongs to the party that published it and is attributed to them in the text.

Continue through the library

Adjacent operating manuals.

Cover of System Design for Developers by Vishal Rajpurohit
ArchitectureAdvanced

System Design for Developers

Design is not drawing boxes. It is deciding, in order, what load the system has to absorb, where state lives and what consistency it needs, and how the thing behaves when a dependency is gone — then recording the constraint that forced each answer and the signal that would reverse it. This book works through that order using the decisions that actually cost money later: data model, service boundaries, caching, queues and backpressure, timeouts and idempotency, observability, capacity, and how to migrate a system that cannot stop running.

Read the full book
Cover of Laravel Optimization Playbook by Vishal Rajpurohit
LaravelAdvanced

Laravel Optimization Playbook

An application that got slower as it got busier does not need a new framework. It needs to be measured, then worked through in a fixed order: the query layer, then write contention, then cache invalidation, then queue saturation, then the runtime. This book runs that order with a measurement at every stage, and ends with the budgets and regression gates that stop the win from decaying the week after you ship it.

Read the full book