By not using it. The tech is flawed. It hallucinates. It's not production ready. I've said it before, and I will say it again. Anyone using AI in a production environment is a fucking idiot.
Ask HN: How are you keeping AI coding agents from burning money?
11–20 of 60 posts
Re: Ask HN: How are you keeping AI coding agents from burning money?
#12Don't use tech with deep, unresolved flaws and you won't get fucked.
Would you find it acceptable if Postgresql occassionally hallucinated and returned gibberish? Fuck no.
Wny is this okay with ANY software? Answer, it's not. AI IS NOT READY.
Re: Ask HN: How are you keeping AI coding agents from burning money?
#13[deleted]
Re: Ask HN: How are you keeping AI coding agents from burning money?
#14[dead]
Re: Ask HN: How are you keeping AI coding agents from burning money?
#15[dead]
Re: Ask HN: How are you keeping AI coding agents from burning money?
#16Kinda of an adjacent question but do you think the token/usage way of paying for things will stick? I still think people would rather pay a monthly subscription for a seat.
Re: Ask HN: How are you keeping AI coding agents from burning money?
#17In what settings do you mean - there are multiple strategies, I think building your own compaction layer in front seems a bit over-kill ? have you considered implementing some cache strategy, otherwise summary pipelines - I made once an agent which based on the messages routed things to a smaller model for compaction / summaries to bring down the context, for the main agent. But also ensuring you start new fresh cont…
yes, compaction and smaller models help on cost per step. But my issue wasn’t just inefficiency, it was agents retrying when they shouldn’t. I needed visibility + limits per agent/task, and the ability to cut it off, not just optimize it.
I'm working on a fun project I call OpenFAST, which essentially tries to solve the context transitioning - but its still in early days and haven't released anything yet.
I think one of the bigger issues, is the o(n) orchestration to agent calls that often feels uncontrolled .. ending up making the orchestrator of sub-agents the main bottleneck due to the large context it sometimes ends up with.
I'm working on an idea where agents delivers briefs & deliveres as real artifacts, and then having each spawned sub-agent read briefs, and if they need further information pick up the delivery for that specific brief.
It helps drift detection across agents, and the best part is orchestrator only delegates jobs, but doesn't do much further than that.
Whenever sub-agents has delivered their tasks, orchestrator can then read a merged brief/delivery for that specific round.
So far it helps cutting that extra tool call where each sub-agent answers the orchestrator - but it also helps the orchestrator only dwelve into deliveries which it believes are relevant rather than trying to understand and comprehend every small detail.
I can share more when I'm a bit further maybe you could get some inspiration here.
Re: Ask HN: How are you keeping AI coding agents from burning money?
#18[flagged]
Re: Ask HN: How are you keeping AI coding agents from burning money?
#19cost control is a policy problem - we certainly don't need to use opus 4.6 for a simple test refactor, but many people (including myself) default to it anyways. we need a way to measure cost / performance for agents on individual repos, with individual types of tasks, to get a better sense of what tasks can be trusted to cheaper agents, and what tasks must be routed to the SOTA
Re: Ask HN: How are you keeping AI coding agents from burning money?
#20Kinda of an adjacent question but do you think the token/usage way of paying for things will stick? I still think people would rather pay a monthly subscription for a seat.
Companies won't survive with seats pricing