Beyond Prompt-to-Code:
Intended Design

Executive summarySoftware should be described once, and produced many times

zAppDev is a browser-based platform that connects natural language AI to software engineering. You describe a business application with AI, and the description, an Intended Design, is checked across database, server and screens before any code is produced. The engine then produces ordinary source code for your target stack, which you can download and run anywhere. Every service can become an MCP tool, automatically. People and AI agents work on the same checked Intended Design of the application.

What it is

The approach describes an application across six connected views: Intent, Domain, Logic, UX/UI, Integration and Data. Every element in every view knows what it is related to, so the whole Intended Design forms a connected graph. Behaviour is written in one language. Studio is the browser workspace where all of it is created, tested and built.

What it changes

• Code stops being the source of truth. The validated Intended Design is. The engine turns it into a complete, readable application for a chosen target, today .NET and Angular.
• Engineering knowledge becomes executable. The engine runs a program for each target, an implementation strategy, that encodes patterns, architecture, libraries and security practice. It runs with no inference or further reasoning and gives the same result every time, however large the application.
• AI gets the right context. Instead of guessing at relationships in thousands of lines of code, an AI works on a connected, validated, much smaller Intended Design, and its changes are checked before anything is generated.
• You can take the result with you. The produced code is real, readable and portable. Download it, and the Intended Design files.

Who it is for

Teams that build and maintain line-of-business applications and want them consistent and governable. Architects who want standards enforced by programs, not reviews. Developers who want to spend their time on the interesting work. Organisations adopting AI who want it to work inside guardrails.

1 · The problemSoftware stays slow, fragile and locked away

Four problems are familiar to every team that builds software for a living.

AI sharpens the problem

Language models have made code cheap to produce. They have not made it cheap to keep coherent. Asked to change a large system from a few files, an LLM guesses at the relationships it cannot see, and produces plausible code with no way of proving it is right. The faster code is produced, the faster inconsistency accumulates.

This changes where the value sits. When code is abundant, the scarce things are a precise statement of what the application is, and a way to check changes against all of it. Both live above the code.

2 · The approachDescribe the architecture in views

For fifty years we have written code and hoped the intent survived inside it. This approach reverses that. You state what the application is, at each level of abstraction, and the code is produced from that statement.

Six connected views

Each view has its own vocabulary. Intent describes why the application exists: its goals, constraints and principles.

Four properties

Why it fits how people think

People do not hold an application in their heads as files. They hold purposes, things, rules and screens, and the links between them. Six views keep each question small, and links mirror how ideas connect. A tool with the same shape makes understanding and description line up.

3 · The Intended DesignAn application as a connected graph

Every element is a node and every relationship is an edge. The Intended Design is a graph you can ask questions of.

The Intended Design is the complete description of one application: structure drawn in Studio and behaviour written in the language. It is the single source of truth. Ask what would break if a Role object changed, and the graph answers across every view, because the relationships are explicit rather than implied.

The shape of every Intended Design

Behind every application is the same shape: the types of element zAppDev knows, and the named relationships allowed between them. It is what the checks enforce, and what an AI learns once. The next page shows it.

What an element type holds

4 · One language for logicTyped, close to C#

Behaviour is written once, in a clear, typed language that lives inside the Intended Design.

The language for the logic of the architecture has a syntax and type system close to C#, and it is used wherever logic lives: class operations, form actions, service operations, automation steps and tests. Because it is part of the Intended Design, every statement knows which objects, forms and services it uses, and it is checked against all of them.

function Domain.InteractionDTO CreateInteraction(
  Domain.InteractionDTO data) {
  var owner = Domain.PMOUser.GetAll()
    .First(o => o.Roles.Any(
      r => r.Name == Application.Roles.SalesMan));
  int accountId;
  if data.AccountId > 0
  {
    accountId = data.AccountId;
  }
  else
  {
    accountId = data.Account.CreateAccount().Id;
  }
  var lead = Domain.Lead.Init(
    data.FlowId, accountId, data.Title, owner);
  data.UpdateLead(lead);
  lead.Save();
  return Domain.InteractionDTO.Fill(lead);
}

public MyApp.BO.InteractionDTO CreateInteractionImplementation(
  MyApp.BO.InteractionDTO data) {
  MyApp.BO.PMOUser owner = new MyApp.DAL.Repository()
    .GetAsQueryable<MyApp.BO.PMOUser>()
    ?.FirstOrDefault((o) => o.Roles.Any(
      (r) => r.Name == "SalesMan"));
  int? accountId = new int?();
  if ((data?.AccountId ?? 0) > 0) {
    accountId = (data?.AccountId ?? 0);
  }
  else {
    accountId = (data?.Account?.CreateAccount()?.Id ?? 0);
  }
  MyApp.BO.Lead lead = MyApp.BO.LeadExtensions.Init(
    (data?.FlowId ?? 0), accountId, (data?.Title ?? ""), owner);
  data?.UpdateLead(lead);
  new MyApp.DAL.Repository().Save<MyApp.BO.Lead>(lead);
  return MyApp.BO.InteractionDTOExtensions.Fill(lead);
}

Excerpt from a service operation in a customer-relationship application, and the C# generated from it. Names are anonymised and indentation is added for width.

What this gives you

• One language, many targets. The same logic can be produced for a different stack, because it is not written in that stack's language.
• Validation across layers. A reference to a missing object or a wrong type is caught in the Intended Design, before any code exists.
• Traceability. A code map links every generated method back to the Intended Design element it came from, so a stack trace leads to its source.

5 · The engine and its targetsKnowledge that executes

For each target, the engine runs a program, an implementation strategy, that encodes how great software is built, and applies it with no inference or further reasoning, on applications of any size.

Most engineering knowledge lives in documents. It has to be read, interpreted and applied by each person or each AI, every time. The engine encodes that knowledge as code, so it is applied consistently everywhere.

What the engine encodes

Why a program beats a document

• Executed. It executes the rules. Nothing is read, planned or reasoned about at generation time, however large the application.
• Without guessing. Every decision is a rule, not an interpretation. The same Intended Design always produces the same code.
• Consistent at scale. The ten-thousandth file follows the same patterns and standards as the first.
• Improved once. When a practice, library or standard moves on, the knowledge is updated in the engine, not hunted down across many code bases.
• Kept current, as a service. Each target is maintained so that it follows the latest versions of the frameworks and libraries an application is built on (for example .NET, Angular, PrimeNG, NHibernate and the PDF and Excel libraries). To move forward you run a build, with no reasoning or inference involved. Your own logic and custom libraries remain yours to keep current, and your tests run on every build.

Write your own

Because a target is produced by a program, it is not limited to the ones that ship. An organisation, or a specialist, can encode its own architecture, standards and expertise, and the whole Intended Design benefits at once, with no rework of the Intended Design.

Availability of tooling for writing custom targets is described in the documentation and may change.

6 · AI and the Intended DesignWhy the graph is the right context

If an LLM can write code directly, why describe the application first? Because scale, alignment and speed all depend on what the LLM is given to read.

Four reasons

1. The whole system in view

Asked to add an approval workflow for high-budget items, an LLM working from raw code inspects a few files and guesses. Working from the graph, it sees every entity, relation, cascade rule and security flag at once, in a compact form, without thousands of lines of boilerplate.

2. Rules that are stated, not guessed

"Make BudgetItem depend on Budget" can be built several ways in code. In the Intended Design it is one explicit relationship with its multiplicity and delete behaviour. The AI does not choose a pattern. It translates a specification.

3. A guardrail before any code exists

A language compiler checks types within code. Validating the Intended Design checks relationships across the whole application: a broken link, a wrong type, a rule that contradicts another. The failure message is precise, so the AI can correct itself immediately.

4. One description, any target

Because the graph describes the application and not one language, the same change can be produced for any target.

Two stages

In stage one the AI changes the Intended Design, quickly, because there is little to process. In stage two the engine produces the same code every time from the validated Intended Design. There is no AI call in that loop, so the same Intended Design always gives the same application.

Open to your own agents

zAI inside Studio is one way in. Any agent that speaks the Model Context Protocol (MCP) can use the same Intended Design through tools to read the application, add or change classes, attributes and associations, validate the Intended Design and build, under the same checks that protect a person working in Studio.

7 · The toolsStudio, zAI and the engine

Studio is the browser workspace where the Intended Design is created, tested and built. It runs in the browser, with nothing to install.

Ten editors, one workspace

zAI

zAI works inside Studio on the Intended Design itself. You describe a change in plain language, zAI reads the relevant part of the graph and proposes it, the Intended Design is validated, and you review it like any other change.

The engine

The engine works in three phases.

Starting points

New applications begin from a template: Empty (the theme only) or Web application (sign-in, users, roles, permissions, settings, a Welcome page). Two live demonstration applications, Lite ERP and Issue Manager, are available to open and explore.

8 · Ownership and architectureWhat you get, and what you keep

No black box in the way: the output is a standard application you can read, build and host yourself.

What is produced

Framework versions follow the current release; check the documentation for exact versions.

What you keep

• The code. It is real and readable. Open it in Visual Studio, put it in your own Git repository, run it on your own servers.
• The Intended Design. It is the portable description of what you built, independent of any one stack.
• The freedom to move. Download the generated solution and the Intended Design files at any time.

Governing at the right level

Reviews, approvals and audits can happen on the Intended Design, where intent is visible, while the generated code stays open for anyone who wants to read it. The engine enforces standards as programs, so compliance is a property of the build, not of a review.

9 · Adopting itFrom first Intended Design to leading the build

Intended Design, describing an application so that people and machines build the right thing, is a skill that can be learned in stages, by building.

Three ways in

A learning path

Your first hour

1. Create a free account and open Studio in your browser.
2. Pick the Web application template. Sign-in, users, roles and a Welcome page are already there.
3. Ask zAI for a Customer list. Review the change, build, and see it run.

Glossary and statusOne term per concept

zAppDev

The application development platform.

Studio

The browser workspace where applications are described, tested and built.

Checked Intended Design

A description of the whole application, checked mechanically by the engine, from which the code is produced. An AI works from it instead of inferring the application from code.

View

One level of abstraction: Intent, Domain, Logic, UX/UI, Integration or Data.

Intended Design

The complete description of an application: structure drawn in Studio and behaviour written in the language.

Element / Relationship

A node in the Intended Design, and a link between two elements, within or across views.

Connected graph

The Intended Design seen as connected elements and relationships.

Shape

The types of element and the named relationships allowed between them: the shape every Intended Design follows.

The language

The typed language for the logic of the architecture, close to C#.

The engine

Checks and optimises the Intended Design, then produces the application for the chosen target.

Target

One stack the engine produces for, through an implementation strategy: a program that encodes the practices, patterns, architecture, libraries and security knowledge for one target and executes it with no inference or further reasoning, and consistently.

zAI

The AI assistant inside Studio that proposes changes to the Intended Design.

MCP

Model Context Protocol: lets AI agents use an application through standard tools.

Template / Sample

A starting point for a new application, and a complete example application to learn from.

What is available, and what is proposed

This paper describes the platform as of October 2026. Details that change, such as versions and plans, are in the documentation.

© 2026 zAppDev. All rights reserved. zAppDev is the name of the zAppDev platform. This document is provided for information and may be shared in its original, unmodified form. Other product and company names are the property of their respective owners.