More and more, the work is orchestrated — automation pipelines, scheduled processes, optimization jobs, increasingly autonomous systems. So we ask a different question: are we building for users, or for systems acting on behalf of users?
The assumption that a person logs in, navigates a dashboard and operates it manually is breaking down. In energy, the real capability isn't the upload form — it's the optimization engine underneath. When that engine is callable predictably and programmatically, it becomes infrastructure other systems can depend on: composable, testable, pipeline-compatible. The dashboard becomes optional.
Nick Hodges wrote something recently in InfoWorld that stuck with us. He described spending a Saturday building a small project with an AI coding tool — getting it live, working exactly as intended — and then realising something interesting: the website itself was almost beside the point. Nobody was going to manually navigate to it. Instead, they’d want their own systems to call it programmatically. So he had the model build a CLI. The whole arc — idea to deployed cross-platform command-line tool — happened in an afternoon.
It’s a small story, but it captures something larger that’s already underway. Across many industries, the assumption that a person logs into a system, navigates a dashboard and manually operates it is starting to break down. More and more, the work is orchestrated. That raises a design question we’ve been thinking about: are we building for users, or for systems acting on behalf of users? Increasingly the answer is both — and that changes where you put your energy.
Behind every polished interface is something more fundamental: a command, an API call, a file transformation, a structured output. When modern systems run, they ultimately resolve to something programmable. In the energy sector this shows up clearly in optimization workflows. A battery scheduling algorithm might take a set of day-ahead prices and output the optimal charge and discharge schedule. Traditionally that capability lives behind a web dashboard where a user uploads a file and downloads the results. But the real capability isn’t the upload form — it’s the optimization engine underneath.
If that engine can only be accessed through a GUI, it creates friction in automated workflows. If it can be called directly — predictably and programmatically — it becomes much more useful. For example, an optimization engine might expose a simple CLI:
battery-optimize --prices CSV [options]
battery-optimize --prices CSV --out schedule.json
battery-optimize --prices CSV --stdout
battery-optimize --prices CSV --format prettyA system can feed it a CSV of day-ahead prices and receive back a structured JSON schedule describing the optimal battery dispatch. That output flows directly into other systems — forecasting pipelines, trading tools, asset controllers, or version-controlled operational plans. Once that layer exists, the dashboard becomes optional.
The traditional model is interface-first: build a web form, configure panels, upload files, display results. That works if a person is always in the loop. But modern energy systems increasingly operate as coordinated workflows — forecasts generate price expectations, optimization models compute schedules, asset controllers execute dispatch, monitoring systems evaluate performance. In that environment the optimization engine is more useful as a callable service than as a webpage. A CLI or API lets the capability run inside automated scheduling systems, as part of trading or forecasting pipelines, in batch optimization jobs, and in reproducible workflows managed through version control. Instead of being a tool someone opens, it becomes infrastructure other systems depend on. We prefer infrastructure.
One thing we’ve observed is that the command line has quietly re-emerged as one of the most stable interoperability layers in modern software. CLI tools are scriptable, testable, automatable, composable, and easy to integrate into pipelines. A CLI-based optimization engine slots into workflows like:
fetch-prices → battery-optimize → validate-schedule → deploy
forecast-prices | battery-optimize --stdout | store-scheduleThese pipelines are simple, transparent and reproducible.
Instead of asking “what does the user click?”, we start with “how does this capability fit into a larger operational workflow?”
None of this removes humans from the process. Human judgment still matters enormously — from trading strategy to asset configuration to risk management. But execution increasingly happens through automated processes. When optimization needs to run daily, hourly, or across many assets simultaneously, it becomes far more reliable to treat that capability as something programmable. The products that hold up are the ones that integrate cleanly into larger operational systems: composable, predictable, pipeline-compatible.
When you design from that starting point, priorities change. Clean APIs matter more. Structured outputs like JSON or version-controlled artifacts matter more. Clear contracts between systems matter more. The interface becomes something you add on top of a solid programmable core, not the thing you build toward. It’s the same conviction behind treating dispatch as a design choice and the restraint of building with clarity.
If you're working on optimization pipelines, asset scheduling, or trading infrastructure that needs a solid programmable core, we'd be glad to talk.