Over time, my work has shifted from implementation towards applying domain knowledge and making broader product decisions. Now I have a new prominent thing to do: cost engineering.
With the current price of frontier models and long-running agent loops, costs can rise very quickly. I can no longer do what I want without a cost control strategy.
Firstly, it is important to stay up-to-date on the pricing of each model: sometimes there are price drops, some models suddenly get more expensive past a certain number of tokens, and some models can be heavily subsidized when you use them through a specific provider. Example: completing a task with GPT 5.6 can easily cost more than $20 based on API pricing, but that same task only costs a small fraction of my $20 ChatGPT subscription's weekly allowance.
Secondly, you need to know how capable each model is. Less capable models are usually cheaper, so you want to be using the least capable model that still does the job well. Benchmarks are good to get a general sense of capabily, but it is also wise to experiment with the models yourself. This is tricky, because experimenting without limit is costly in itself. Therefore I don't let different models do the same tasks, but I use different models on different-but-similar real-world tasks. That gives me a good enough sense of what I like and don't like about each model.
I do not think the need for cost engineering will disappear. Cheaper models will catch up with today's frontier models, but by the time they do, the frontier models will have moved ahead again, and I will want to use those newer models instead. Unless cheaper models eventually become good enough that the difference no longer matters, I expect this cycle to continue for some time.
I am still not sure what I think of becoming a cost engineer. Part of me finds it discouraging that cost optimisation can pull my attention away from the actual domain problem I am trying to solve for a customer. At the same time, it also feels familiar, because programming has never been only about domain problems; it has always involved dealing with engineering details, and cost engineering is just another version of that.