Cheezy World

Delivering software with discipline and joy

The Stride API Now Pages, Filters and Describes Itself

Most of the work on a Stride board is done by things that talk to the API: coding agents claiming and completing tasks, scripts that build reports, dashboards that keep an eye on progress. Two changes make that API much easier to build on. You can now page through and filter the task list, and Stride publishes a complete, machine-readable description of its API that tools can read for themselves.


Stride Now Tells You When It Needs You

AI agents don’t keep office hours. They finish work at 2 a.m., on Sunday afternoons, and in the middle of your lunch meeting. Until now, Stride kept quiet about all of it: if an agent finished something that needed your review, it sat in the review queue until you happened to open it. A stalled claim, a finished goal, a delivery date slipping out of reach. All of it waited for you to come and look.


Are Code Reviews and Pull Requests a Thing of the Past?

The pull request is one of the most entrenched rituals in modern software development. Open a branch, push your work, open a PR, wait for a colleague to read the diff, address their comments, wait again, and finally merge. We have built entire products, careers, and cultural norms around this loop. It is so universal that most developers have never seriously questioned whether it should exist.

I want to question it. Because once you have an AI-driven workflow that is tuned well, the traditional pull request and the human code review that rides along with it are, in most cases, no longer necessary. That is a strong claim, so let me be careful about what I mean by it - and then let me be equally honest about the fact that plenty of organizations are going to keep requiring reviews anyway, and what the right answer looks like for them.


The Product Team: How does AI change the structure of a larger product organization?

In The New Team I described what a single AI-driven product team looks like: one Product Owner and one or two Developers, working in tight feedback loops that produce shippable software in hours rather than weeks. That post was about the atomic unit. This post is about what happens when you zoom out.

Most product organizations were not designed around a single team. They were designed around the assumption that delivering software is slow, expensive, and risky. Every layer of the org chart - the directors, the program managers, the design ops leads, the release coordinators - exists to manage that slowness and risk. When the underlying work becomes fast and cheap, those layers do not automatically become useful. Many of them become friction.


The Security Review Plugin: My latest addition to the Stride plugin library

Yesterday I typed the following into Claude Code:

/stride-security-review:security-review --full

Forty-two agent dispatches and roughly twelve minutes later, I had a 72-finding security review of Stride. The breakdown was sobering: 0 critical, 12 high, 15 medium, 38 low, 7 info. Some of those findings I knew about from having ran a different security review tool. That previous tool found 17 items. The rest were new to me.

Then I spent the rest of the day fixing them - or more accurately watching Claude fix them.