Software Is Now Text, Not Code

Andrew Maryasov, AI consultant. I deploy AI agents for businesses and I watch the very nature of software development shift every day. This piece is about one release from OpenAI that I reread three times, because I thought I’d missed something. I hadn’t. The rules had simply changed.

TL;DR (in 30 seconds)

• OpenAI released Symphony not as code, but as a specification. An 18-page document and one instruction: “Tell your AI agent to build this in any language.”
• The reference implementation is in Elixir. A deliberately uncommon language. The signal: the implementation language doesn’t matter, the specification does.
• This isn’t an exception, it’s a paradigm shift. Before: developer → code → product. Now: specification → AI agent → product.
• What it means for business: competitive advantage shifts from “who wrote the code” to “who wrote the better specification.” The cost of implementation approaches zero — what remains is the cost of thinking.

The release that looked like a mistake

A few days ago OpenAI released a new product. Or rather — not a product.

Symphony is an orchestrator for AI agents. A thing that takes a task from a tracker (Linear, for example), hands it out to agents, who write code, open PRs, wait for review, address the comments. All autonomously, with no human in the loop.

But the interesting part isn’t what they built, it’s how they released it.

The README literally says:

“Tell your favorite coding agent to build Symphony in a programming language of your choice: Implement Symphony according to the following spec”.

In other words: take your AI agent, let it read the specification — and it will build this product for you on its own. In any language. For your needs.

(Seriously — I reread their page three times because I thought I’d missed something. No, it really does say “tell your agent to build it.” That’s the whole instruction.)

What they actually handed users

The “product” itself is an 18-page document. Text. Not code.

There is a reference implementation in Elixir, but that’s secondary. The main thing is the specification: algorithms, state machine, retry logic, workspace management, failure recovery. Everything is described in enough detail that an AI agent can build it from scratch.

A few numbers that show the proportions well:

• SPEC.md — 18 sections, from the domain model to the test matrix.
• Reference implementation — in Elixir. Not Python, not JS — because the language doesn’t matter.
• 4.9k stars within a few days of release.

The choice of Elixir isn’t an accident. It’s a language few people use in day-to-day development. A deliberate signal: the implementation is secondary, the specification is primary. Want Python? Go ahead. Go? No problem. The agent will read the same text and assemble it for your environment.

Before and now

The easiest way to show the shift is with a table.

	Before	Now
What you get	Code / a finished program	A specification (text)
What you do with it	Download, install, configure	Let AI read it — it builds
Implementation language	The vendor’s choice	The consumer’s choice
Where the value is	In the code that’s written	In the quality of the specification
Cost of implementation	High	Approaching zero

We’re used to software being something you download, install, update, fix when it breaks. And now one of the biggest AI companies in the world ships a product as text. Not code — text. Because AI will read it and build it for you anyway.

Consequences for business

This isn’t just an interesting way to do an open-source release. It’s a shift in how software is distributed — and it touches everyone who runs a product or a technical team.

Competitive advantage shifts from “who wrote the code” to “who wrote the better specification.” The cost of implementation approaches zero — what remains is the cost of thinking. And maintaining and updating the product also happens through the specification, not through patches.

Your IP stops being code and becomes a document. If you run a technical team, it’s worth thinking right now about how this changes what you own and what you protect.

This is exactly what work with AI agents at Grow2.ai is built on: a well-described task is worth more than the code that carries it out. And when we automate business processes at Auspex, half the work isn’t “writing the integration,” it’s precisely formulating what the system is supposed to do. If you’re curious where the line runs between a simple bot and a system that acts on a specification, I covered that separately: AI agent vs chatbot.

This is no longer a single case

I’ve been writing about this for two months now — and the topic is only gaining momentum. I see more and more projects where the specification matters more than the code.

Anthropic’s CLAUDE.md, various agent specs, prompt-driven systems — all of these are variations on the same thing: the specification matters more than the implementation.

It’s as if instead of selling cars, people started selling blueprints — because every garage already has a robot that can assemble a car overnight.

The question I can’t shake: when will the first “App Store of specifications” appear? Not of programs — of specifications. You buy one, hand it to your agent, and it builds it for your environment, on your infrastructure, in your language.

The answer “any day now” feels too optimistic to me. Or does it?