Some of it can be busywork, but for me the intermediate artifacts (plans, design docs, etc) serve a real purpose: they create a verification surface where you can check that the agent is creating the right thing before it goes all the way. It's exactly the same reason we created short sprints: if the team misunderstood the requirements and built the wrong thing, you only lost a sprint. We lost months of work when we did waterfall because the product did not match what the customer had in mind.
I have deterministic and stochastic tests that run on each artifact. For those that have a high risk of "not the right thing", I manually review the artifacts. But if it's bog standard I just rely on the auto-gates to reject and get the agent to retry the artifact.
This gets me a high-volume pipeline that yes uses a lot of tokens, but at the same time doesn't overwhelm me. I only deal with things that genuinely need my attention. That's worth it for me, and not busywork.
Comments
Some of it can be busywork, but for me the intermediate artifacts (plans, design docs, etc) serve a real purpose: they create a verification surface where you can check that the agent is creating the right thing before it goes all the way. It's exactly the same reason we created short sprints: if the team misunderstood the requirements and built the wrong thing, you only lost a sprint. We lost months of work when we did waterfall because the product did not match what the customer had in mind.
I have deterministic and stochastic tests that run on each artifact. For those that have a high risk of "not the right thing", I manually review the artifacts. But if it's bog standard I just rely on the auto-gates to reject and get the agent to retry the artifact.
This gets me a high-volume pipeline that yes uses a lot of tokens, but at the same time doesn't overwhelm me. I only deal with things that genuinely need my attention. That's worth it for me, and not busywork.