Natural Language Is
The New Ontology
Business logic no longer needs to be translated into rigid configuration before software can act on it.
Palantir's Ontology was the most important architectural idea in enterprise software of the last two decades. It was the right answer for a world where machines couldn't understand natural language, but that world no longer exists.
Ontology solved a real problem: machines couldn't understand how businesses operate unless you translated that understanding into formal structure. Typed objects, defined relationships, deterministic rules. It was expensive, it was rigid, and it required engineers to maintain. But it was the only way to make business logic legible to software.
With models like Opus 4.7 and GPT-5.5, that constraint is gone. LLMs can now interpret natural language business rules with sufficient precision and reliability to execute them directly, in production, on decisions that matter. The data still needs structure. Databases, schemas, APIs aren't going anywhere. What's obsolete is the requirement to encode your business logic, the rules, the decisions, the routing, into that same formal structure before software can act on it.
A Concrete Example
Consider commission calculations at a mid-market industrial company. The rules are intricate: different rates for different job types, one-off overrides for specific individuals, thresholds that change the payout structure, bonuses tied to conditions that the CFO carries around in their head. These rules change every few months.
You could build a configurable UI: dropdown menus for rate tiers, input fields for thresholds, exception tables for individual overrides. You'd spend weeks building it, and the first time the CFO says "actually, for this one person, the rate should be different if the job is in this region and was referred by an existing client," you'd realize your UI doesn't support that level of specificity. So you add more configuration options, making the interface more complex with each iteration. Eventually, you've built a mini-ERP just for commissions, and it still doesn't cover every case.
Or you could write custom code. An engineer encodes every rule as conditional logic, and it works perfectly until the rules change. Now you're filing a ticket, waiting for an engineer, testing, deploying. The person who actually understands the rules is separated from the system by at least one engineer and a deployment pipeline.
Today's models offer an alternative: you describe the commission rules in natural language. The system reads the description and calculates commissions directly. When the rules change, the CFO updates the description. No ticket, no engineer, no deployment. The same person who understands the rules is the person who maintains them, in the same language they use to explain those rules to a new hire.
Systems built on this pattern are running in production today, handling real calculations that affect real paychecks, at a reliability level equivalent to deterministic code.
What Structure Used To Buy You
Ontology was the most ambitious version of a pattern that runs through all of enterprise software. SAP built thousands of configuration tables, requiring specialized consultants who understand the configuration system better than most operators understand their own business. Sage Intacct built sprawling admin panels where rules are expressed as nested dropdowns and conditional checkboxes. ServiceTitan built settings pages that their own implementation teams configure on the customer's behalf.
Each of these attempts to solve the same problem: business logic is specific, edge-case-heavy, and changes constantly. The solution was always some form of structured encoding, a way for the business to express its rules in a format that deterministic software can execute.
Configuration emerged as a specialized skill to resolve this tension. There are entire consulting practices built around knowing which SAP tables to modify. The configuration layer, which was supposed to make software adaptable, became its own source of complexity and cost. And for businesses whose logic doesn't fit cleanly into any product's configuration model, they build custom software, knowing full well that when the business changes in six months, that code will need to be rewritten.
Why Natural Language Changes The Equation
When business logic lives in natural language, the relationship between the business and its software inverts. In the traditional model, the business translates its operations into a format the software understands: structured data, configuration parameters, or code. The software dictates the vocabulary. When natural language is the interface, the business describes how it actually operates, and the software adapts. The business dictates the vocabulary.
Domain experts maintain domain logic. The person who understands the commission rules maintains the commission rules. No engineer as an intermediary. This isn't about cost reduction. It's about removing a translation layer that introduced errors and delays.
Edge cases become trivial. In deterministic systems, every edge case requires a new branch of code or a new configuration option. In natural language systems, an edge case is a sentence. No UI redesign, no code change, no deployment.
Software evolves with the business. When the rules change, the description changes. There's no lag between how the business operates and what the software does.
The system accumulates operational knowledge. Over time, the natural language description becomes a living specification, reflecting not just the rules but the exceptions and refinements discovered through experience. The prompt becomes an institutional asset. No traditional software system produces this as a byproduct.
New Problems, Better Problems
This isn't without trade-offs. Natural language business logic requires versioning, monitoring, guardrails against contradictions, and feedback loops that surface outputs to users so they can verify the system is interpreting their rules correctly.
These are real engineering challenges. They are also dramatically better problems than the ones they replace. Versioning a natural language document is simpler than versioning a complex codebase. Monitoring AI-interpreted rules is more tractable than auditing thousands of SAP configuration tables. Teaching a business user to write clear rule descriptions is easier than teaching them to navigate an ERP's admin panel.
What This Means
The configuration surfaces that enterprise software has spent decades building are legacy interfaces. They were the best available answer to "how does a business express its rules to software?" Natural language is a better answer. Not incrementally better. Categorically better.
The brittleness problem that has plagued custom software is solvable. Custom software has always offered a trade: it does exactly what you need, but it breaks when your needs change. Natural language business logic removes that trade.
The engineer's job shifts from "maintain and update the business logic" to "build the infrastructure that interprets and acts on business logic expressed in natural language." The engineer builds the system once. The business evolves the logic forever.
Ontology was the right abstraction for a world where software couldn't understand natural language. It imposed structure because structure was the only way to make business logic legible to machines. That constraint has disappeared. The structure can now be inferred rather than imposed. And that changes everything about how software gets built, configured, and maintained.
Natural Language Is
The New Ontology
Business logic no longer needs to be translated into rigid configuration before software can act on it.
Palantir's Ontology was the most important architectural idea in enterprise software of the last two decades. It was the right answer for a world where machines couldn't understand natural language, but that world no longer exists.
Ontology solved a real problem: machines couldn't understand how businesses operate unless you translated that understanding into formal structure. Typed objects, defined relationships, deterministic rules. It was expensive, it was rigid, and it required engineers to maintain. But it was the only way to make business logic legible to software.
With models like Opus 4.7 and GPT-5.5, that constraint is gone. LLMs can now interpret natural language business rules with sufficient precision and reliability to execute them directly, in production, on decisions that matter. The data still needs structure. Databases, schemas, APIs aren't going anywhere. What's obsolete is the requirement to encode your business logic, the rules, the decisions, the routing, into that same formal structure before software can act on it.
A Concrete Example
Consider commission calculations at a mid-market industrial company. The rules are intricate: different rates for different job types, one-off overrides for specific individuals, thresholds that change the payout structure, bonuses tied to conditions that the CFO carries around in their head. These rules change every few months.
You could build a configurable UI: dropdown menus for rate tiers, input fields for thresholds, exception tables for individual overrides. You'd spend weeks building it, and the first time the CFO says "actually, for this one person, the rate should be different if the job is in this region and was referred by an existing client," you'd realize your UI doesn't support that level of specificity. So you add more configuration options, making the interface more complex with each iteration. Eventually, you've built a mini-ERP just for commissions, and it still doesn't cover every case.
Or you could write custom code. An engineer encodes every rule as conditional logic, and it works perfectly until the rules change. Now you're filing a ticket, waiting for an engineer, testing, deploying. The person who actually understands the rules is separated from the system by at least one engineer and a deployment pipeline.
Today's models offer an alternative: you describe the commission rules in natural language. The system reads the description and calculates commissions directly. When the rules change, the CFO updates the description. No ticket, no engineer, no deployment. The same person who understands the rules is the person who maintains them, in the same language they use to explain those rules to a new hire.
Systems built on this pattern are running in production today, handling real calculations that affect real paychecks, at a reliability level equivalent to deterministic code.
What Structure Used To Buy You
Ontology was the most ambitious version of a pattern that runs through all of enterprise software. SAP built thousands of configuration tables, requiring specialized consultants who understand the configuration system better than most operators understand their own business. Sage Intacct built sprawling admin panels where rules are expressed as nested dropdowns and conditional checkboxes. ServiceTitan built settings pages that their own implementation teams configure on the customer's behalf.
Each of these attempts to solve the same problem: business logic is specific, edge-case-heavy, and changes constantly. The solution was always some form of structured encoding, a way for the business to express its rules in a format that deterministic software can execute.
Configuration emerged as a specialized skill to resolve this tension. There are entire consulting practices built around knowing which SAP tables to modify. The configuration layer, which was supposed to make software adaptable, became its own source of complexity and cost. And for businesses whose logic doesn't fit cleanly into any product's configuration model, they build custom software, knowing full well that when the business changes in six months, that code will need to be rewritten.
Why Natural Language Changes The Equation
When business logic lives in natural language, the relationship between the business and its software inverts. In the traditional model, the business translates its operations into a format the software understands: structured data, configuration parameters, or code. The software dictates the vocabulary. When natural language is the interface, the business describes how it actually operates, and the software adapts. The business dictates the vocabulary.
Domain experts maintain domain logic. The person who understands the commission rules maintains the commission rules. No engineer as an intermediary. This isn't about cost reduction. It's about removing a translation layer that introduced errors and delays.
Edge cases become trivial. In deterministic systems, every edge case requires a new branch of code or a new configuration option. In natural language systems, an edge case is a sentence. No UI redesign, no code change, no deployment.
Software evolves with the business. When the rules change, the description changes. There's no lag between how the business operates and what the software does.
The system accumulates operational knowledge. Over time, the natural language description becomes a living specification, reflecting not just the rules but the exceptions and refinements discovered through experience. The prompt becomes an institutional asset. No traditional software system produces this as a byproduct.
New Problems, Better Problems
This isn't without trade-offs. Natural language business logic requires versioning, monitoring, guardrails against contradictions, and feedback loops that surface outputs to users so they can verify the system is interpreting their rules correctly.
These are real engineering challenges. They are also dramatically better problems than the ones they replace. Versioning a natural language document is simpler than versioning a complex codebase. Monitoring AI-interpreted rules is more tractable than auditing thousands of SAP configuration tables. Teaching a business user to write clear rule descriptions is easier than teaching them to navigate an ERP's admin panel.
What This Means
The configuration surfaces that enterprise software has spent decades building are legacy interfaces. They were the best available answer to "how does a business express its rules to software?" Natural language is a better answer. Not incrementally better. Categorically better.
The brittleness problem that has plagued custom software is solvable. Custom software has always offered a trade: it does exactly what you need, but it breaks when your needs change. Natural language business logic removes that trade.
The engineer's job shifts from "maintain and update the business logic" to "build the infrastructure that interprets and acts on business logic expressed in natural language." The engineer builds the system once. The business evolves the logic forever.
Ontology was the right abstraction for a world where software couldn't understand natural language. It imposed structure because structure was the only way to make business logic legible to machines. That constraint has disappeared. The structure can now be inferred rather than imposed. And that changes everything about how software gets built, configured, and maintained.
The Future of Coding Is Orchestration
Ciridae's CTO explains how Claude Code shifted their engineering from manual coding to AI orchestration, accelerating delivery through specification.
As CTO at Ciridae, I used to measure momentum in keystrokes—lines added, diffs merged, tickets closed. That framing breaks down when the fastest path to production isn’t typing; it’s arranging. The future of coding is orchestration: specify the outcome, define contracts and invariants, and let the system assemble the pieces. Claude Code is the first tool that made that shift stick across our entire engineering org.
The receipts-by-SMS project was the proof point. Field workers text photos of receipts; we return structured invoices without manual entry. The components are standard: a programmable SMS gateway sends webhooks, Temporal provides fault-tolerant workflows and state, an AI image parser extracts line items, and a record-management API updates invoices. The slow part used to be glue: endpoint contracts, parsers, error paths, policies around retries and alerts. Claude Code handled the connective tissue and the boring fragility, documentation drift, auth quirks, client scaffolding, so the first iteration behaved like our codebase, not a demo. Most importantly, test failures weren’t dead ends; Claude read the logs, adjusted the parser and orchestration, and moved forward.
Precision was the unlock. The more concrete the spec, file names, method signatures, payload shapes, return types, the more the system behaved like a teammate who knew our preferences. Writing “create a parseReceipt.ts module with parseLineItems(buffer): { items, subtotal, tax, total }, add three fixtures, and ensure the Temporal activity retries on network timeouts only” produced code that dropped straight into review. Ambiguity wastes cycles; orchestration rewards specificity.
To keep that specificity stable, we introduced a CLAUDE.md at the root of each repo: brief project overview, directory structure, naming conventions, invariants, testing strategy, and the handful of decisions we don’t want to re-argue. Because Claude Code treats this as first-class context, new sessions begin aligned with our architecture. That single page shortened onboarding for the tool and for humans. It also made parallelism safe: I often run three or four instances at once across repos without losing consistency.
We’re Anthropic preferred partners, and we now run Claude Code at enterprise scale across our workflows. The gains show up in day-to-day engineering rather than a single flashy demo. Context management happens automatically; we don’t babysit file lists. Refactors that used to require a day of careful renaming and validation land with the right migrations and checks. Merge conflicts resolve the way we would resolve them. Pull requests arrive with rationale, test diffs, and notes for release. Routine implementation—clients, serialization, fixtures—stops blocking design decisions. And the parallel work streams don’t step on each other because the orchestration is explicit.
On my productive days, I have like three or four Claude Code instances running simultaneously on different projects. Sometimes I’ll spin up a branch for a ticket, let Claude Code take a first attempt, and when I come back it’s like a junior engineer already made a draft implementation. I haven’t written a pull request manually since I started using it
CYRUS SINGER
Founding Engineer
Our development loop changed accordingly. We write tests and expected outputs first, then ask Claude Code to generate the implementation and the tests that exercise the behavior. Review shifts from syntax to systems: are we honoring invariants, are the workflows idempotent, are retries bounded and observable, is the logging structured for production debugging? CI becomes a feedback channel, not a gate. When something fails, Claude reads why and adjusts
the orchestration rather than papering over symptoms. The cycle is short: specify, generate, review, iterate, merge.
Why now? A few primitives finally matured together. Claude Code’s context handling means we specify intent instead of curating files. Repo-aware operations turn instructions into deterministic edits, not suggestions. Tight loops with tests and logs make failure data useful in the moment. A lightweight memory (CLAUDE.md) carries design decisions forward so each branch starts smart. And the enterprise pieces—permissioning, audit trails, predictable diffs—make the tool viable beyond hobby projects. Put together, this is less “autocomplete” and more “continuous delivery for decisions.”
The same pattern helped us integrate legacy systems that used to demand hours of archaeology. A brittle API stops being a research project and becomes an orchestration problem: define the boundary, encode the contract, isolate side effects, name failures, and let the workflow enforce the rules. The implementation matters, but the orchestration makes it durable.
If yesterday’s AI story was speed—prompt, code, ship—today’s story is arrangement. The work that moves the needle is deciding how services talk, how failure behaves, and how knowledge persists. Claude Code didn’t make us type faster; it made us specify better. That’s the practical meaning of “the future of coding is orchestration,” and the reason the answer is “why now.”
