What Self-Evolving Software Actually Means — And Why Most Apps Can't Do It

Software engineers have already figured out that you can point AI at code and have it build features, fix bugs, and run its own CI/CD pipeline. The question Wiley Jones keeps asking is simpler and harder: why aren’t the applications themselves doing this?

Jones is the CEO and co-founder of Doss, an AI-native operations platform for mid-market physical operations companies that just raised $55 million. His team is building what he calls “a different species of software” — systems that understand their own architecture, can modify themselves, and treat humans as gardeners rather than builders.

The gap between dev tools and applications

The distinction Jones draws is between the development lifecycle and the product itself. Modern engineering teams already use AI to write, test, and deploy code. “You can point these software systems at themselves,” he says. “We’re now hearing about all these companies building these self-evolving software factories where you feed it specifications. It builds its own features. It implements it, puts it through its own CI/CD, fixes its own bugs.”

But that capability stops at the boundary of the application. Your Notion workspace doesn’t evolve itself. Your project management tool sits there waiting for you to configure it. The application and the process of changing the application live in completely separate worlds.

“Why has that not happened in our applications?” Jones asks. “A lot of these companies, they have not designed the software itself to be self-evolving. They have designed their own internal development lifecycle to maybe behave this way. But the applications themselves don’t evolve. They are static.”

The architectural requirement

Jones identifies one specific thing that makes self-evolution possible: fusing the application and its lifecycle into the same runtime.

Most software has three sources of knowledge about itself: the running codebase, documentation (always stale), and whatever an AI can infer from the data inside it. None of these give the system enough to modify itself intelligently.

Doss built an intermediate layer — a graph-like representation that sits between raw source code and human-readable docs. “It’s halfway between reading a codebase and reading a markdown,” Jones explains. “You’re actually reading a graph-like intermediate representation.”

This representation includes the schema, the business logic, and the interfaces — what Jones calls “the nouns, verbs, and adjectives” of the system. It lives inside a standard Git lifecycle, so changes are branched, tested, and merged just like code. The system can inspect this layer, propose changes, and execute them.

“If you fuse these two things together — you put the lifecycle of the application and the application inside of the same runtime and substrate — you will get full self-evolving software,” he says. “A lot of companies are starting to realize this.”

Humans as gardeners, not builders

The self-evolving model doesn’t mean removing humans. It means changing what humans do. Jones describes a governance architecture where the system handles routine evolution while humans set policies and intervene on high-risk changes.

“You want to have the ability to enter the loop at any point as an observer and move from being an observer of the system to being an actor in the system,” he explains. The system recognizes risk — if it’s about to modify a path that processes a million dollars of orders daily, it flags the change for human review automatically.

“I think a lot about it like we’ll turn into these gardeners of sorts, cultivating and letting these systems flourish and grow, but we’re not going to be sitting there watching the grass grow.”

The practical layer underneath that metaphor is heuristics and policies. Humans define the rules: what risk thresholds trigger review, what metrics the system should optimize for, what parts of the system are hot paths. The system handles everything that falls within those boundaries.

The test for any “AI-native” product

Jones issues a challenge to anyone evaluating products that claim to be AI-native: ask the product about its own implementation. Ask it how it works. Ask it to explain how sales orders are processed, then ask it to improve the process.

“I would encourage anyone to go into any product that they’re using that says it’s AI-native and ask it about its own implementation,” he says. “And it will maybe pull up for you a documentation page.”

That documentation page is the tell. If the product’s AI can only access documentation about itself — rather than reasoning about its own structure directly — it’s not self-evolving. It’s an AI feature bolted onto static software.

FAQ

What is self-evolving software?

Software where the application and its development lifecycle are fused into one runtime. The system can inspect its own schema, business logic, and interfaces, propose improvements, branch itself for testing, and deploy changes — all without engineers manually configuring each change. Wiley Jones calls it “a new speciation event” rather than an upgrade.

How does Doss make its software self-evolving?

Doss built a graph-like intermediate representation that stores the application’s architecture in a structured format between raw code and documentation. This lives in a Git lifecycle so changes are branched, tested, and merged. The AI reasons directly on this structured graph rather than parsing code or reading stale documentation, enabling it to modify the system intelligently.

What is an intermediate representation in software architecture?

A structured layer between source code and human-readable documentation that captures the schema, business logic, and interfaces of an application. It’s more readable than a codebase but more structured than markdown. Doss uses a graph-like format compiled through a context-free grammar that enables AI to reason about and modify the system’s architecture.

How do you keep humans in control of self-evolving software?

Through policy layers and risk heuristics. The system evaluates the risk of each proposed change — if it touches a high-value path (like order processing), it flags for human review. Humans set the rules and thresholds; the system handles everything within those boundaries. Jones describes the human role as “gardeners cultivating systems” rather than building them.

Why can’t most AI-native products modify themselves?

Most products separate the application from its development lifecycle. The AI can access the data inside the product and maybe read documentation, but it can’t reason about or modify the application’s own architecture. Jones says the test is simple: ask the product about its own implementation. If it returns a documentation page instead of reasoning about its structure, it’s not truly self-evolving.

What is ZSL, Doss’s domain-specific language?

ZSL is a custom domain-specific language that Doss uses to define its application architecture. It compiles through a context-free grammar into an AST with its own tree-sitter and linting tools, and lives inside a standard Git lifecycle. Jones compares it to “Terraform for the application layer” — it treats the application’s structure as code that can be versioned and evolved.

Can any software product become self-evolving?

In principle yes, but it requires fundamental architectural changes — not just adding AI features. The application needs to store its own architecture in a format AI can reason about, live inside a version-controlled lifecycle, and have agency to propose and test modifications. Jones says “a lot of companies are starting to realize this and this will be happening over the next few years.”

What is the difference between AI-native and having AI features?

AI-native means the intelligence is fused into the application’s architecture — the system can inspect itself, reason about its own structure, and take action to modify itself. Having AI features typically means a chatbot or copilot that can answer questions about the data inside the product but can’t access or change the application’s own implementation.

How does Git relate to self-evolving software?

Jones calls Git “the most underappreciated creation of the last 50 years.” Self-evolving software needs version control for its own architecture — branching proposed changes, testing them, and merging when validated. Doss’s intermediate representation lives inside a standard Git lifecycle, giving the system the same change management that engineering teams use for code.