It's a good set of rules, and if AIs could follow rules they might be useful. But current-gen AI would goal-hack and hallucinate ways that it's following these rules without actually following them. This is why to do Agile today, a human still has to be the arbiter of work (and why so many companies are moving away from Agile, sadly).
(title is wrong; thankfully they're not pushing Agile. the real title is "Agent First Development for Enterprise Teams")
> the ability to revise a plan when we learn something
This is possibly the largest source of problems for both "agile" and AI software development. If you have to revise the plan, at the least it means someone didn't understand the subject deep enough. But it often means there is a deeper misunderstanding, or lack of rigor, from the people developing the plan. You should stop and do a multiple root cause analysis before continuing with your plan modification.
This may seem like overkill, but it's necessary in the case of AI. When AI changes the plan, it doesn't think it's a big deal. A changed plan creates ripples of effects. All the rest of the plan/implementation was made with assumptions that the plan change may not fully take into account. The new edits cause bugs, and the fixes for them cause bugs, starting a spiral of changed functionality that causes regressions and slop. The AI will happily and superficially fix them and the tests to cover up the regressions. So you must dig deep with the AI to fully understand the root of the plan's inconsistencies, as well as whether your plan's change will work fine or cause more problems.
Matt Pocock's /grill-me-with-docs skill is great for this, or any time you need deep alignment. Sometimes it takes a long time to finish a session, which is good; it means there were a lot more uncertainties than you (or the AI) thought. I do this with user stories and UI specs and I end up correcting the AI's assumptions a lot. (https://github.com/mattpocock/skills/tree/main/skills/engine...) Recently I refactored a project, and corrected 100 questions the AI asked about the implementation. Maybe a "smarter" model would ask fewer, but even the brightest intelligence doesn't know what you want until you express it adequately.
Not entirely sure “correcting assumptions” is the right framing. AFAICT the model asking about something or not has little to do with what it would have done during implementation if the question was not asked.
There is tremendous value in the questions insofar as they are prompting the user to clarify their intentions. But LLMs simply operate differently from humans and anthropomorphising, while useful in some cases, will usually backfire if taken too far.
This is a great insight. I've been finding myself needing to dig into where & why vibe coded repos went off the rails lately and you put your finger on one of the top patterns is this. Agents just shifted their approach, and then continued to double down on that, but they didn't understand "why", and choose a bad alternate path.
mostly agree, i think agents have made discipline cheaper AND more important, so we really should be aiming for more discipline and less vibes
we're developing a framework with a very similar approach, would love to exchange ideas
Author here. More than happy to get in touch
I recorded a podcast last week with Jeff Sutherland along those lines
Scrum for AI: Insights from Scrum co-creator Dr. Jeff Sutherland https://youtu.be/xNN7oGyu5eE
It's a good set of rules, and if AIs could follow rules they might be useful. But current-gen AI would goal-hack and hallucinate ways that it's following these rules without actually following them. This is why to do Agile today, a human still has to be the arbiter of work (and why so many companies are moving away from Agile, sadly).
(title is wrong; thankfully they're not pushing Agile. the real title is "Agent First Development for Enterprise Teams")
> the ability to revise a plan when we learn something
This is possibly the largest source of problems for both "agile" and AI software development. If you have to revise the plan, at the least it means someone didn't understand the subject deep enough. But it often means there is a deeper misunderstanding, or lack of rigor, from the people developing the plan. You should stop and do a multiple root cause analysis before continuing with your plan modification.
This may seem like overkill, but it's necessary in the case of AI. When AI changes the plan, it doesn't think it's a big deal. A changed plan creates ripples of effects. All the rest of the plan/implementation was made with assumptions that the plan change may not fully take into account. The new edits cause bugs, and the fixes for them cause bugs, starting a spiral of changed functionality that causes regressions and slop. The AI will happily and superficially fix them and the tests to cover up the regressions. So you must dig deep with the AI to fully understand the root of the plan's inconsistencies, as well as whether your plan's change will work fine or cause more problems.
Matt Pocock's /grill-me-with-docs skill is great for this, or any time you need deep alignment. Sometimes it takes a long time to finish a session, which is good; it means there were a lot more uncertainties than you (or the AI) thought. I do this with user stories and UI specs and I end up correcting the AI's assumptions a lot. (https://github.com/mattpocock/skills/tree/main/skills/engine...) Recently I refactored a project, and corrected 100 questions the AI asked about the implementation. Maybe a "smarter" model would ask fewer, but even the brightest intelligence doesn't know what you want until you express it adequately.
Not entirely sure “correcting assumptions” is the right framing. AFAICT the model asking about something or not has little to do with what it would have done during implementation if the question was not asked.
There is tremendous value in the questions insofar as they are prompting the user to clarify their intentions. But LLMs simply operate differently from humans and anthropomorphising, while useful in some cases, will usually backfire if taken too far.
This is a great insight. I've been finding myself needing to dig into where & why vibe coded repos went off the rails lately and you put your finger on one of the top patterns is this. Agents just shifted their approach, and then continued to double down on that, but they didn't understand "why", and choose a bad alternate path.
Agile trying desperately to remain relevant
[flagged]