[dtnewman]

This is what inspired me to build my new CLI tool, Burn, Baby, Burn (https://github.com/dtnewman/burn-baby-burn/tree/main).

(If you are a VP at Amazon, yes, I'll consider acquisition offers. I'm also working on an enterprise version of this with additional features.)

Show HN here: https://news.ycombinator.com/item?id=48151287

[stephenhuey]

Just sent it to some developers who could really benefit from this! Please let us know when you have Codex and Gemini versions ready to rumble.

[dtnewman]

Sorry, it will be a while. We're currently building out enterprise features like SSO/SAML support, role based burn access, and a carbon offset marketplace. As you can imagine, we're burning a lot of tokens to get these out, but actual productivity isn't up as much as you'd think.

[ted_bunny]

How about a built-in AI assistant to answer my burning questions?

[sznio]

I want a in-browser Gemini version. For some reason my company doesn't count Gemini CLI use. I guess I'm supposed to copy code between my browser and my editor.

[sph]

AI-powered cobra breeding tool.

https://en.wikipedia.org/wiki/Perverse_incentive

[dyauspitr]

Only problem with this is that outcome metrics are still jira storypoints. Burning huge number of token while not improving the velocity is going to get you fired.

[recursive]

If we had a way of measuring velocity, we'd already be using that instead of tokens.

[dyauspitr]

What do you mean? You get story points for free with jira. That’s like the one metric every place uses.

[recursive]

Story points are unicorn dust that crumbles under any attempt of serious optimization. The fundamental problem is that SP is not an objectively defined metric. If we come under serious pressure to improve velocity measured by SP, there's nothing to stop that initiative from trickling down into the SP estimation/measurement. SP works fine as long as you don't look too closely at it.

[dyauspitr]

Yeah everything is subjective unicorn dust but there are ways of making sure story points have some semblance of accuracy. Either ways it’s probably the best metric we have atleast for an established team.

[promano]

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]

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!

[promano]

A token is approximately word generated by a LLM; a few dozen tokens gets you a line of code... so measuring token burn rate is the same as counting lines of code. All it took was a change of name, and we're back to the most primitive metric we ever got for measuring programmer productivity.

I don't think I can take anything from management in tech seriously again after tokenmaxxing.

[joquarky]

"When a measure becomes a target, it ceases to be a good measure"

https://en.wikipedia.org/wiki/Goodhart%27s_law

[jimbokun]

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]

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]

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.

[cgio]

Next feature is creating stories. Double burn.

[cyanydeez]

any plans for a distributed deployment via cloudflare works. I'm not sure this thing is powerful enough for my use case.

[dtnewman]

Yeah, lots of enterprise features in the works, but first i need to raise money at a $1B+ valuation (this might seem high for a project that started 4 hours ago, but it's actually very low for the project that will soon be the #1 consumer of tokens on the planet)

[cyanydeez]

recommend you extrapolate your value based on the token spend rates of FAANG; if you can spend 10x FAANG, then you should get atleast 10x valuation. godspeed.

[Esophagus4]

You got four hours of Claude Code usage without hitting a rate limit???

[LikeBeans]

Brilliant

[kurthr]

Like attack ships off the shoulder of Orion, the only way to burn!

[jimbokun]

This is hilarious and utter genius.

[eudamoniac]

Won't the company audit the requests to AI and see you're sending a bunch of BS?

[jimbokun]

If only Scott Adams were alive to write Dilbert comics about this.

[palmotea]

> Won't the company audit the requests to AI and see you're sending a bunch of BS?

Shouldn't be too hard to game. Version 2 uses the M365 MCP server to load up your email and iterate over all the messages, summarizing them over an over.

[cleaning]

Do you have an example of any company ever doing this?

[eudamoniac]

No, but if you run this non judiciously and burn 100x the next guy with no output, maybe they would want to know how