co-founder of Infracost here, we launched Infracost on HN five years ago, when the CLI just generated cost estimates for Terraform. Earlier this year we were scoping a 1.0 release: the CLI would stop being just a cost-estimation tool and start surfacing the issues behind the costs: previous-generation instances, policy violations, the kinds of issues a thorough PR review would catch.
Then agent traffic started showing up, and it became clear the 1.0 scope was the right idea aimed at the wrong caller. A human reviewer reads a PR comment; an agent runs `infracost inspect --filter` ... and gets the same insight as a tabular row it can pipe into the next step. So we decided to skip our planned 1.0 release and go for 2.0, where we treated agents as a first-class citizen user of the CLI.
Along the way we picked up some interesting lessons on optimizing user token usage when designing a CLI, and we want to share them with the HN community since other CLI builders might benefit.
Comments
co-founder of Infracost here, we launched Infracost on HN five years ago, when the CLI just generated cost estimates for Terraform. Earlier this year we were scoping a 1.0 release: the CLI would stop being just a cost-estimation tool and start surfacing the issues behind the costs: previous-generation instances, policy violations, the kinds of issues a thorough PR review would catch.
Then agent traffic started showing up, and it became clear the 1.0 scope was the right idea aimed at the wrong caller. A human reviewer reads a PR comment; an agent runs `infracost inspect --filter` ... and gets the same insight as a tabular row it can pipe into the next step. So we decided to skip our planned 1.0 release and go for 2.0, where we treated agents as a first-class citizen user of the CLI.
Along the way we picked up some interesting lessons on optimizing user token usage when designing a CLI, and we want to share them with the HN community since other CLI builders might benefit.