We had a way of measuring velocity, but who cares about estimating stories when we could be spinning up more agents? Burn a bunch of tokens and those stories will be DONE before you could even find your planning poker cards!

▲

recursive a day ago | parent | next [-]

I've lived through a bunch of initiatives about improving planning and estimation. None of them turned into a stable process that worked for anyone. I don't know if I can extrapolate from that, but it gives me an inclination that no one really trusts anything that comes out of task estimation. Which would be why we're looking for more objective metrics like token burn rate. No room for argument - tokens are tokens!

	▲	joquarky 2 hours ago \| parent [-]
		"When a measure becomes a target, it ceases to be a good measure" https://en.wikipedia.org/wiki/Goodhart%27s_law

▲

jimbokun 20 hours ago | parent | prev [-]

This but unironically.

The speed of generating code is now faster than the time it takes to plan and estimate how long it will take to generate the code.

▲

recursive 20 hours ago | parent [-]

Generating more code faster might be useful, but there have to be some other constraints on it.

Using this paradigm, we can achieve unlimited bugs sooner than ever before.

1. To fix a bug, always add code, never remove. 2. Whenever you fix one bug, always introduce at least two new ones.

	▲	joquarky 2 hours ago \| parent [-]
		This sounds like government software, in my experience. I was brought on to one particular team to do cleanup and all I was given was band-aids to layer on top. Odds are good your local or state government is running this software right now for managing its courtrooms.