Code is a liability, not an asset
There is no denying that code generation has gotten extremely cheap. You can generate as much code as you want, effectively at the snap of your fingers.
But is more code always a good thing? We're not so sure.
Ultimately, code is often part of a broader software service contract. It's simply a translation layer between your intent and machine procedure. Your intent is expressible at a higher level, for example:
- what interfaces / APIs are exposed?
- what constraints are you operating under (SLAs/SLOs)?
- what kind of data gets stored?
whereas code captures implementation details:
- we're using Python 3.11 with Flask for the API service
- we've used Redis as a cache to hit our performance constraints
- we store logs in our database for 2 years to meet our data audit needs
Software services are code that someone keeps alive. That upkeep is the expensive part: keeping software running, up-to-date, secure, and reliable can account for up to 80% of its lifetime cost.
So more code usually means more maintenance overhead — owning custom software comes with a maintenance tax, and someone has to carry the liability.
Scale software ownership without the maintenance tax
Even though coding agents have accelerated the process of generating code, it's still expensive to own more software precisely because of this tax.
This isn't a new problem: Amazon's move toward service-oriented architecture was, in part, an attempt to scale software ownership internally. Bezos' API mandate organized software teams around "contractual" interfaces: an analytics service, a log service, a database service, a search service. This had two major effects:
- By breaking software down into interface and service-level contracts, Amazon was able to untangle its stack and let teams build far more software independently.
- Turns out these "service-level" interfaces were good enough that productizing them (à la AWS) was a great business.
For commodity services like data systems, the cloud made consumption simple. A few clicks and you get a "managed service" back: you can sleep easy at night since someone else is keeping the software alive.
But what if your software needs differ from stock offerings? What if you need a bespoke API, interface, or service-level guarantee? You're back to square one.
That changes if building and running a bespoke software service becomes as simple as using a managed cloud service.
The Goal Specification
At Telos, we're excited by the promise of decoupling disposable implementation from durable intent. We're abstracting out the source code in favour of a goal specification. Describe your desired interface, features and constraints, and get a running software service back.
Our agent runtime iterates in an adversarial loop against a declarative goal specification: writing, testing and deploying code, then maintaining the resulting software from deployment onward. On our cloud, we manage the coding environment, SDLC process and agent compute.
Most importantly, if you want to change the service, you simply edit the spec and watch the system reconcile. The code is an implementation detail you don't have to look at.
As agentic systems become reliable over long horizons, the new bottleneck becomes verifiable goal specification. Can you effectively articulate what you want, not how?
Welcome to the era of declarative software.
Join us
We're a small team of engineers working to make declarative software real. If that sounds like you, shoot us a note at [email protected].