Software engineering has moved through space and time over the last two years.
I still recall the rush of using Opus-class models back in December 2025. It felt like a defining step change in capability: snap your fingers, and you could build anything you wanted in no time.
You could feel it online: new side projects were being spun up faster than ever before, and there was buzz and excitement in the air.
The breakthrough wasn't simply that AI could write good code. It was that I no longer had to read it. I could work entirely out of my coding agent. All that time I spent playing around with Vim shortcuts was now replaced by a simple chat-box in my terminal!
But as this capability accelerated my work, the process around it started to feel increasingly backwards. Over the following months, what began as a headrush was slowly turning into a hangover:
More code, more problems
For starters,
- AI chats today are imperative, step-by-step instructions. The prompts we're writing are streams of thought that get thrown away. The generated code is what we end up storing.
In traditional software engineering, you write, store, and maintain code which gets compiled down to a lower-level language that we treat as a black box. With vibe coding, we write our "intent" as prompts (that we throw away), treat generated code as a black box, but store, maintain, and iterate on the generated code. That's an inversion!
- We're feeling the tyranny of the weakest link more than ever. Generating code faster just shifts the bottleneck elsewhere: code review, pull requests, CI, and the repeated handoffs between dev, test, and prod.
Constantly reviewing AI output, prodding panes of agents on, and manually taming AI slop made the job feel like managing a bunch of fussy, impatient pets. This was fatiguing!
It became clear that we were retrofitting new technology into processes designed for a world where code was scarce and expensive, and the way we were working with coding agents hadn't kept up with what they could do.
Moving above the code
As the models improved, the unit of work they could tackle expanded with them.
I could describe a verifiable goal (with /goal) and let an agent work toward it for hours or even days.
But I was still sitting there, watching my agents tear through a terminal faster than my eyes could follow, stuck in the following loop:
- chat with interactive agent
- watch it write code
- run tests locally
- clean up AI-generated slop
- create a PR (and get it superficially stamped)
- wait for CI/CD (zzz)
- check out real world result
- repeat
Even with a clear concept of what I wanted to do in my mind, I spent most of my programming time in this loop. I was productive, but man was this tiresome! I felt less like a programmer and more like a janitor.
Most of all, I certainly didn't want to read and maintain massive volumes of inscrutable AI-generated code.
The reality was, while a chunk of my role in this loop was janitorial, the hard part of the job - defining what my goal was, designing systems, and setting constraints - was far from gone. To the contrary, it was more important than ever, and I wanted to bring that front and center.
I started to wonder: if the system became reliable enough, could I step out of this loop and move a layer above it? Could the goal itself become the abstraction?
Out of that mix of wishful thinking and a growing list of grievances with the existing state of the world, I started building the system I wanted to use. We've spent the months since dogfooding it quietly and we're now ready to share it.
Introducing Telos Cloud
Today, we're introducing Telos Cloud: a new, declarative abstraction layer for software engineering. We treat the goal specification as the source of truth, and Telos builds, runs, verifies, and evolves the software behind it.
Telos Cloud is built with the following core principles:
- A goal should be a persistent, living artifact that is owned by human authors.
- A goal should be continuously "compiled" to running software by background agents in the cloud.
- Code should be treated like a compiled artifact and be invisible by default.
We shared the source code of our goal-oriented agent runtime in prior posts. Turns out agents are only as useful as their environment! Telos Cloud takes care of a cloud environment with a rich set of developer tools, stateful sandboxing, and cloud hosting.
Writing goals is not trivial. Some may even criticize this as a return to "waterfall". We think the best way to write goals is where you already work: by pairing with your coding agent. With Telos, the developer loop becomes:
- chat with interactive agent
- refine goal
- launch with Telos (build, verify and deploy in the background)
- observe real world results
- repeat
In our dogfooding, we found the iterative cycle with Telos to feel a lot like "micro-waterfall" at the speed of agile. Most importantly - since it centers design, craft, and taste - this was fulfilling!
Let's walk through a simple example:
Take the status page from our product demo on the homepage:
---
name: status-page
version: 1.1.3
platform: cloud
---
# Goal
Run a public status page for Halcyon's services.
Expose `GET /api/status` to return every service with its current state.
- Poll and surface incidents every minute.
- Persist incident history indefinitely.
# Acceptance
- A fresh incident should appear on the page within 60 seconds of happening.
First, preview the goal with telos plan
$ telos plan SPEC.md
Spec status-page
Target cloud
Path SPEC.md
...
This is straightforward enough, so let's apply it
$ telos apply SPEC.md
Status working
Goal goal_5f702bdd73
...
This starts the Goal in the background and returns immediately.
At any point, you can check on the running Goal with telos describe
$ telos describe goal_5f702bdd73
Name status-page
Status working
Service https://status-page-5f702bdd73.usetelos.ai
Or, if you want a more granular view of what it's doing, use telos logs.
$ telos logs goal_5f702bdd73
...
[2026-08-26T13:03:05Z] [INFO] Added one-minute probing against the live production services
[2026-08-26T13:07:42Z] [INFO] Stood up /api/status per goal requirements
[2026-08-26T13:12:18Z] [INFO] Wired service history to PostgreSQL backed by persistent storage
...
Once your service is marked ready, open the URL and review the generated service.
If you decide you want to change the service, you can simply update the local copy of the goal specification and re-plan against the running Goal.
$ telos plan SPEC.md --goal goal_5f702bdd73
Goal goal_5f702bdd73
Version 1.1.3 -> 1.2.0
+- Render 30 days of uptime history per service.
After reviewing the plan output, re-apply
$ telos apply SPEC.md --goal goal_5f702bdd73
This has the Telos system wake up and reconcile against the updated goal - all on the same persistent sandboxed environment. Simple!
Putting it all together
Telos is our answer to the problems above:
-
Intent gets thrown away. The Goal becomes the living source of truth that we read, review, version, and change.
-
Everything after codegen becomes the bottleneck. Telos collapses dev, test, and prod into one environment, shortening the loop from intent to a running, verified result.
-
How do we trust code we don't read? The Goal persists as requirements change, and an independent verifier agent checks the implementation against it. We wrote more about why that works here.
-
Agents are fatiguing to manage. Parallelizing across agents rarely yields real productivity gains, but parallelizing across independently verifiable background goals is far more manageable.
Growing process and complexity pains with imperative systems are a tale as old as time in the computing world: React replaced manual DOM updates with a declarative framework, Terraform and Kubernetes replaced imperative infrastructure provisioning with a declarative management model.
Telos is our bet that AI coding can and must make the same jump - and it all starts with a new abstraction layer: the Goal.
A more ambitious Goal
While the status page above demonstrates the interface, we wanted to close with a more ambitious test of the system's capabilities.
So we wrote a goal to build, evolve, and operate a multiplayer browser FPS. We let it run autonomously for 26 days, over nine goal edits to produce Breachpoint.
Telos built, tested, and deployed the whole system autonomously, and by the end of the run, the system had ~22K lines of first-party code and had completed over 1,260 agent passes. We wrote a technical deep dive, for those who are interested in the details.
I still haven't read the generated code.
Get started
Telos Cloud is now in open beta. Try it in the cloud, or run the harness locally (source code).
For inference, use our managed inference gateway, connect an existing ChatGPT or xAI subscription, or bring your own key (BYOK) - we're flexible by design.
Give this to your coding agent:
Set up Telos with your agent.
- Install it with
curl -fsSL https://usetelos.ai/install.sh | sh. - Run
telos loginto sign in to Telos Cloud. - Read the installed
telos-cliskill to get started.
Telos the product is early, but we're now running a good chunk of our production software stack on our own platform. We think this will become one of the defining ways of working in the AI coding age, but there's a lot left to be done - from improving our platform to helping people write high-quality Goals!
If any of this resonated, or if you want to be a part of our mission - we'd love to hear from you at hello@usetelos.ai.
