A language for expressing software intent to AI.

Why AI needs more than natural-language prompts

Large language models made it possible to describe software in natural language. A developer can write “create a customer management system with customers, accounts, and transactions,” and a model can generate an implementation. But a prompt has fundamental limitations. It is:

• temporary
• ambiguous
• difficult to validate
• difficult to version as a software artifact
• disconnected from the application’s architecture
• difficult to reuse consistently
• dependent on conversational context
• not inherently connected to implementation

Most importantly, a prompt describes an instruction to an AI model. It does not become a persistent representation of the software itself. AIS approaches the problem differently: it provides a structured language in which software intent becomes an actual part of the application.

What is AIS?

AIS (AI-Script) is a declarative language designed around the idea that software can be described in terms of concepts, relationships, features, and intent, rather than beginning with implementation-level instructions. A simplified example:

concept('customer management platform') {

  entity('a customer with identity and contact details') {
    ref: customer
    exposes('serializes a customer to JSON')
  }

  entity('a financial account owned by a customer') {
    ref: account
    stores(ref: customer)
  }

  component('creates and updates customers and their accounts') {
    ref: customer_manager
    exposes('registers a new customer')
    exposes('opens an account for a customer')
    throw(ref: customer_not_found)
  }

  error('the requested customer does not exist') {
    ref: customer_not_found
  }
}

The purpose of this syntax is not to provide a shorter way to write conventional code. It is to create a structured representation of what the application means — which the ADAAS platform can then interpret using its own architecture, knowledge, packages, frameworks, AI capabilities, and execution environment.

From programming code to software intent

Traditional programming languages require developers to specify implementation details. A customer-management feature may require defining:

• classes
• database schemas
• API endpoints
• controllers
• services
• repositories
• validation
• frontend components
• state management
• serialization
• error handling
• dependencies

AIS moves the starting point to a higher abstraction level. Instead of describing how each component is implemented, the developer describes what exists, how concepts relate, what the application should do, and what capabilities a feature requires. The platform can then determine much of the implementation — a clean separation between intent and implementation:

Intent

What the software should represent and accomplish.

Implementation

How that intent is translated into executable software.

AIS is not a prompt language

AIS should not be understood as a collection of prompts wrapped in programming syntax. A prompt tells an AI model what to do. AIS defines a structured software artifact that can become part of the application’s architecture.

Create a customer dashboard
showing account balances.

concept('customer dashboard') {

  entity('an account with a current balance') {
    ref: account
    exposes('exposes the current account balance')
  }

  component('renders a dashboard of customer account balances') {
    ref: customer_dashboard
    exposes('presents account balances for a customer')
  }
}

The AIS representation can become part of the application’s persistent model. It can be inspected, modified, connected to other concepts, interpreted by the platform, and used as context for AI-driven implementation. The intent becomes reusable.

An abstraction layer above conventional code

AIS does not attempt to make traditional programming languages obsolete. It introduces an abstraction layer above them. A conventional application may contain millions of lines of implementation code; AIS represents the higher-level structure that gives that implementation meaning. This lets architects work primarily with concepts and architecture, developers move between AIS and generated implementation, AI agents operate on the structured model, and the runtime execute the resulting system.

A language designed for AI-native development

Conventional programming languages were designed around human programmers writing implementation instructions. AI changes the economics of software: when it can generate thousands of lines of implementation in a short time, manually specifying every detail becomes less important. The scarce resource becomes correct intent — what the software should do, which concepts exist, which relationships must hold, which constraints apply, and which architecture to use.

Humans define the intent. AI and the platform determine more of the implementation. The role of the programming language shifts from describing every implementation step to describing software meaning.

Business concepts as first-class software elements

A conventional implementation is full of implementation artifacts. The business, however, thinks in terms of domain concepts. AIS represents those concepts directly, creating a closer relationship between the language of the business and the structure of the software.

CustomerService
AccountRepository
PortfolioController
TransactionModel
PositionEntity
RiskCalculator

Customer
Account
Portfolio
Position
Transaction
Risk

In AIS those concepts are expressed directly, so the software model is easier for developers, architects, product teams, and AI systems to reason about:

concept('wealth management') {

  entity('a client of the firm') {
    ref: client
  }

  entity('an investment portfolio held by a client') {
    ref: portfolio
    stores(ref: client)
  }

  entity('a position held inside a portfolio') {
    ref: position
    stores(ref: portfolio)
  }

  entity('a transaction recorded against a position') {
    ref: transaction
    stores(ref: position)
  }
}

From domain model to executable application

An AIS definition does not need to remain a static domain model. Within the ADAAS platform it can become a source of information for generating the structures the application requires:

concept('customer accounts') {

  entity('a customer of the platform') {
    ref: customer
  }

  entity('an account owned by a customer') {
    ref: account
    stores(ref: customer)
  }

  feature('presents an overview of a customer and their accounts') {
    stage('load the customer', ref: customer_reader)
    stage('load the customer accounts', ref: account_reader)
  }
}

Depending on the application and platform configuration, those structures may include:

• data models
• backend logic
• APIs
• UI components
• application services
• validation
• integrations
• AI capabilities

This is where AIS differs fundamentally from documentation-oriented modeling: the model can participate directly in software creation.

AIS and architecture

AIS is designed to operate together with architectural information. Constructs are interpreted within a larger application architecture:

context('regulated wealth management boundary') {
  ref: wealth_management
  constraint('client data must remain inside the regulated boundary')
}

component('presents a portfolio overview for a client') {
  ref: portfolio_overview
  context(ref: wealth_management)
  exposes('returns a portfolio overview for a client')
  throw(ref: portfolio_unavailable)
}

error('the portfolio could not be loaded') {
  ref: portfolio_unavailable
}

The platform can combine AIS with application concepts, architectural relationships, package knowledge, reusable components, organizational constraints, AI agents, and implementation frameworks. This lets AI operate with far more context than a standalone coding assistant. Instead of Prompt → Code, the model becomes Intent → Architecture + Knowledge + Constraints → Implementation.

AIS and AI agents

AIS provides a structured surface for AI agents to work with software. An agent does not need to reason directly over millions of lines of source code for every task; a higher-level representation is a more efficient way to understand concepts, relationships, features, dependencies, intended behavior, and architectural structure. The agent can then determine what implementation changes are required — reducing the gap between AI reasoning and the actual architecture of the application.

AIS and knowledge

AI-generated software is only as good as the context available to the AI. AIS works within the broader ADAAS knowledge environment, which can contain information about business domains, application concepts, architecture, packages, frameworks, reusable components, implementation patterns, constraints, and organizational standards.

The language describes the application. The knowledge environment explains the context. AI uses both to determine the implementation.

AIS in practice: an order management system

A traditional approach might start with database tables and services. With AIS, an enterprise order management application can begin with its business concepts:

concept('order management platform') {

  entity('a customer who places orders') {
    ref: customer
  }

  entity('a product that can be ordered') {
    ref: product
  }

  entity('a customer order') {
    ref: order
    stores(ref: customer)
  }

  entity('a single line item within an order') {
    ref: order_item
    stores(ref: order)
    stores(ref: product)
  }

  component('creates orders and their line items') {
    ref: order_creator
    exposes('creates an order for a customer')
    throw(ref: product_unavailable)
  }

  error('a requested product is not available') {
    ref: product_unavailable
  }
}

The application definition is now understandable without reading hundreds of implementation files. A developer sees the domain structure, an architect reasons about the relationships, a product owner recognizes the business concepts, and an AI agent uses the same representation as context. The underlying implementation can evolve without rewriting the high-level intent every time a detail changes.

Adding a business capability

Suppose the business introduces a rule: customers receive a discount when an order exceeds a defined threshold. Instead of manually locating every affected component, the capability is expressed at the intent level:

feature('applies a discount when an order exceeds a threshold') {
  stage('calculate the order total', ref: order_total_calculator)
  stage('apply the eligible customer discount', ref: discount_calculator)
  throw(ref: discount_not_applicable)
}

component('calculates the total value of an order') {
  ref: order_total_calculator
  exposes('returns the total value of an order')
}

component('applies eligible discounts to an order') {
  ref: discount_calculator
  exposes('applies a threshold discount to an order')
}

error('the order is not eligible for a discount') {
  ref: discount_not_applicable
}

The platform uses this higher-level definition, together with the existing architecture and implementation, to determine what needs to change. The important idea is that the change begins with business intent rather than source-code navigation.

AIS and software evolution

Software rarely stays static — businesses add products, regulations change, integrations appear, processes shift. Traditional development forces those changes to propagate manually through requirements, architecture documents, tickets, code, tests, and deployment. AIS provides a higher-level representation that stays connected to those changes.

The goal is to reduce the distance between business evolution and software evolution.

AIS compared with conventional programming

AIS does not eliminate conventional source code. It introduces another level above it.

AIS compared with natural-language prompting

The prompt is useful for communicating with AI. AIS is designed to become part of the software itself.

AIS inside the ADAAS Architecture Intelligence Platform

AIS does not operate in isolation. It is one layer of the broader ADAAS Architecture Intelligence Platform: AIS expresses intent, A-Concept provides the conceptual framework, A-Frame provides indexing and composition, AIS Studio provides the development environment, and A-OS provides the operating environment for AI-developed applications.

AIS Studio: where AI-Script becomes a development experience

AIS becomes significantly more powerful inside an environment designed around it. AIS Studio is the development environment for working with AIS applications, concepts, architecture, and implementation. Instead of treating AIS as a standalone language file, developers work in an environment where:

• application concepts are visible
• relationships can be explored
• architecture can be inspected
• implementation can be generated
• AI capabilities can be used
• dependencies and knowledge can be accessed
• application changes can be managed

Who AIS is for

Software architects

Define application concepts and architectural intent at a higher level while keeping a connection to implementation.

Enterprise developers

Work with business concepts and application behavior while AI and the platform handle more of the implementation detail.

CTOs & engineering leaders

Create a more structured foundation for scaling AI-assisted software development across teams.

Product & technology teams

Represent business capabilities in a form that can participate directly in software development.

AI agents

Use structured application intent as a higher-level source of context when reasoning about software changes.

The future of programming is not necessarily more code

Programming languages have historically evolved by making developers more productive at expressing implementation. AIS explores another direction. If AI increasingly handles implementation, the value of the human-readable layer shifts toward expressing intent, concepts, constraints, and architecture. The question becomes less “how do I write this code?” and more “what should this software mean?”

Prompting tells AI what to do. AIS describes what the software is. That distinction is at the heart of AI-native programming.

Frequently asked questions