ARO is the programming language where features become code.
Built for humans. Perfected for AI.
(* Your first ARO feature *) (sayHello: Greeting API) { <Create> the <greeting> with "Hello, World!". <Return> an <OK: status> with <greeting>. }
Every statement in ARO follows the natural pattern of how we describe work.
It's not magic. It's just really, really good design.
Write code the way you write user stories. Each feature set maps directly to a business capability.
<Extract> the <user> from the <request>.
The first language designed from the ground up for AI collaboration. Natural language syntax that LLMs understand intuitively.
<Validate> the <data> against <schema>.
Your OpenAPI contract is your routing table. Define your API, and ARO handles the rest.
<Return> an <OK: status> with <result>.
Think about it. When you ask an AI to write code, you describe what you want in natural language. Then the AI translates that into Python, JavaScript, or Rust.
That translation step? It's where bugs are born.
ARO eliminates the gap. The language is the specification. When you write
<Store> the <user> into the <database>, there's no ambiguity.
The AI doesn't have to guess what you meant.
"The best code is code that reads like a conversation between the business and the computer."
Same language. Same understanding.
Real examples that show how ARO makes complex tasks simple.
(* Fetch weather data from an external API *) (Application-Start: Weather Client) { <Log> the <message> for the <console> with "Fetching weather...". <Create> the <api-url> with "https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41¤t_weather=true". <Request> the <weather> from the <api-url>. <Log> the <data> for the <console> with <weather>. <Return> an <OK: status> for the <startup>. }
The <Request> action makes HTTP requests to external APIs.
Use from for GET requests, to for POST.
JSON responses are automatically parsed.
Join the developers who are writing the future—one feature at a time.