Software

This post is about software, and the expectations vs reality we as builders grapple with. If you are like me, you write code, ship features, and get a dopamine hit when you click “Merge Pull Request.”

I want to talk to you about the moment we’re in together.

I build web-based software. I have since 2004. Writing code, FTP’ing it to a server, and seeing the page load was my digital-nicotine laced loop. I wanted to iterate, improve, and inject strange ideas into everything I built. And the enchanting experience of seeing my software be used by other humans (friends, family, strangers) is something that drove me from teenaged hobby to a durable career.

It didn’t matter that our 56k modems teased us with tinnitus to load pages with hideous color palettes and <marquee> tags. Software was magical. It was unique. Something we as a society hadn’t seen or felt before. The web upended the world.

I loved hearing “wow” from my users. It’s lovely to experience it myself, too. But those wows have waned for us all. And software’s curtain for Act II has started to rise.

Higher Expectations

When I use software now, I expect it to do more for me. I want it to anticipate my needs, adjust its outcomes for different situations, and all with more autonomy. Frustration creeps in when platforms only integrate with themselves, and refuse to play well with others. I feel like a hostage.

And the effort from calcified incumbents has been redirected to their balance sheets and away from innovation. Teams have been constrained by the dreaded “switching cost”, or put another way, “no one else exceeds our expectations well enough to switch anyways.”

Because we all have that one vendor that failed to build us new features since signing on their dotted line. We patiently waited, requested, begged for new ideas. And then they have the audacity to ask for more money at renewal.

The nerve.

The homogenous software we’ve been relegated to use in our work and personal lives has me wanting more. I want new outcomes from my tools, not the same ones with a different coat of paint.

The New Outcomes

People are the animators of software. We exchange clicks, clacks, right swipes, and “Hey Siri” for outcomes from our software. We set software into motion with us charting the route to a destination. We pedal and steer our digital bike while the software moves us along our route.

Which means every new outcome costs us another journey. Copy and paste, drag and drop, “per my last email” is in our tool belt of ways of starting the next journey towards our ultimate objective. We’ve had to disembark one bike only to mount another for a different destination. A high switching cost in and of itself.

Anytime a customer has to do something monotonous in our platforms, it’s a passive burglary of time they could use to create the next great thing.

AI changed the possibilities of software connectivity and outcomes. The infinite cardinalities of large language models are already morphing our software rickshaws into vehicles that can transport users in any direction.

So we need to upgrade the pedals and handles together.

Agentic Interfaces

AI offers an opportunity for us all to transition from the bronze age of software into the iron age. An age when tools became more abundant, stronger, and practical. And teams participating in Act II of software must be able to forge new tools that artificial intelligence can wield.

The trouble is that the human-centric software knobs and ropes of today must change for AI models to power multi-directional software outcomes. Because intuitive human interfaces are diametrically opposed to what large language models see and touch.

More poetically: AI doesn’t give a shit what color your buttons and forms look like. Models only care about the outcome the “button” gives them.

And we developers already have a well-known primitive for this: An API.

Productive AI agents demand programmatic interfaces. What we know as keyboards and trackpads they know as tool calls. And these tools we give them are what elevate AI models from brains in a jar to spirited assistants.

APIs alone aren’t enough. They are inert. A bat without a batter.

Runtimes

So erecting innovative APIs in the form of MCP, gRPC, REST, or {insert protocol} is only one piece of delivering the vivid experiences customers are expecting in Act II of their software. Businesses must connect their APIs to intelligent models, too.

In the same way we convert electrical signals from our brains to our hands to type mildly passive-aggressive emails to our colleagues, our software now needs a digital one to act on our behalf: An Agentic Runtime.

The pain is that teams are wrestling with changing requirements for their software’s outcomes, and then they have to build the autonomous runtime for it. Forging the sword while in the duel might result in flesh wounds.

Which forces a choice. Do we build the API-powered features and the agentic runtime that connects and governs them all? Or do we exceed our customers’ expectations with relentless focus on innovation only? We are forced to weigh the opportunity cost.

As an engineer, I know the temptation we feel to build base layers. It’s fun to build platforms and runtimes. But it’s more rewarding to hear that next “wow” from your customers.

Batter up!

Act II is starting whether we’re ready or not. Some teams will spend it forging new features their customers will tell stories about. Others will spend it rebuilding runtimes from first principles, in a corner by the “core services” team, getting nothing for the effort except the right to say they built it themselves.

Cadenya is for teams who’d rather build the next thing than the thing underneath it.

All you have to do is build an API.