Will Larson Pointed an Agent at a Project Instead of a Task
Will Larson wrote up what he calls the software factory pattern, and the one line definition is looping on a broad goal and then relying on the harness to drive progress toward that goal. Not a task, not a ticket, a project. The post went up September 20 at https://lethain.com/software-factory-experiment/.
The implementation is a skill he calls /linear-project-loop. It reads project goals out of the RFCs where they were actually written down, checks the metrics on the Datadog and Snowflake dashboards that are supposed to move, updates task status in Linear, picks up whatever is not blocked and pushes it forward through pull requests, reviews and clarifying questions, and when a project description has gone stale relative to reality it re-evaluates the direction instead of grinding on obsolete tickets.
He is honest that there are no numbers here. His verdict is that it works well enough that he expects to move it into his orchestrated harness, which is the kind of judgment you should read as a signal and not as evidence. The findings he does offer are better than a benchmark anyway. Building it forces you to notice every place your process kept state in someone's head, and once it exists you get project monitoring after release rather than only before it.
The caveat in his own words is the important part. The pieces compound only to the extent that you have the other pieces. This loop needs work tracked in a queryable system, goals written where a machine can read them, and metrics wired to dashboards with a real API. A team whose goals live in a slide deck and whose status lives in standup gets nothing from this.
Which reframes the last three years of engineering hygiene work. Writing RFCs and instrumenting dashboards was documentation discipline. It is now the difference between having an agent that can work on your project and having one that cannot.
← Back to all articles
The implementation is a skill he calls /linear-project-loop. It reads project goals out of the RFCs where they were actually written down, checks the metrics on the Datadog and Snowflake dashboards that are supposed to move, updates task status in Linear, picks up whatever is not blocked and pushes it forward through pull requests, reviews and clarifying questions, and when a project description has gone stale relative to reality it re-evaluates the direction instead of grinding on obsolete tickets.
He is honest that there are no numbers here. His verdict is that it works well enough that he expects to move it into his orchestrated harness, which is the kind of judgment you should read as a signal and not as evidence. The findings he does offer are better than a benchmark anyway. Building it forces you to notice every place your process kept state in someone's head, and once it exists you get project monitoring after release rather than only before it.
The caveat in his own words is the important part. The pieces compound only to the extent that you have the other pieces. This loop needs work tracked in a queryable system, goals written where a machine can read them, and metrics wired to dashboards with a real API. A team whose goals live in a slide deck and whose status lives in standup gets nothing from this.
Which reframes the last three years of engineering hygiene work. Writing RFCs and instrumenting dashboards was documentation discipline. It is now the difference between having an agent that can work on your project and having one that cannot.
Comments