AI Coding Is Scaling. Software Intent Is Becoming the Bottleneck.

The signal in the research

Three independent lines of evidence point the same way — adoption is high, trust is low, and the value is shifting upstream.

• Stack Overflow's 2025 Developer Survey: 80% of developers use AI tools, while trust in AI output fell to 29%. The most common frustration was output that was 'almost right, but not quite,' and 66% reported spending more time fixing such output.
• Sonar's 2026 State of Code survey: AI-generated code made up 42% of committed code, expected to reach 65% by 2027 — yet 96% of developers did not fully trust AI-generated code and 38% said reviewing it took more effort than reviewing a human colleague's code.
• A 2026 academic study found GenAI produces substantial time savings in implementation, testing, design and documentation, but far smaller gains in requirements analysis and planning — concluding that value is shifting toward specification quality, architectural reasoning and oversight.

If AI can increasingly produce the implementation, what becomes the primary artifact that humans and AI work with?

The code bottleneck is moving upstream

Traditional software development is heavily implementation-oriented. A simplified model runs from requirement down to executable software.

Business Requirement
  ↓
Specification
  ↓
Architecture
  ↓
Code
  ↓
Executable Software

AI coding systems are automating the bottom of this chain. That is a real productivity gain — but it does not eliminate the top.

Architecture
  ↓
  AI
  ↓
Generated Code
  ↓
Executable Software

Someone still has to communicate what the system should represent, which concepts exist, how they relate, what the system is allowed to do, which constraints apply, what behavior is required, which architectural decisions matter, and how new features relate to existing software.

AI can generate implementation faster than organizations can reliably define and maintain software intent. That is where the next bottleneck emerges.

Prompts are not a software architecture

The natural response has been ever more sophisticated prompts. Prompt engineering genuinely helps — but a prompt has an architectural limitation. It is usually temporary, conversational, model-dependent, hard to govern, hard to version as architecture, hard to connect systematically to the rest of the application, and not inherently executable.

"Create a customer dashboard that shows the customer's
 accounts, recent transactions, portfolio performance
 and risk."

This is useful instruction. But it does not formally establish what a Customer is, what an Account is, how Account relates to Customer, what a Transaction represents, which relationships are authoritative, which capabilities can operate on those concepts, or how the feature relates to the rest of the application. The AI must infer all of it — and that inference gets more fragile as complexity grows.

The missing layer: software intent

A different approach is to make software intent itself a structured artifact — intentionally above implementation code. It describes the concepts and relationships that matter without requiring every implementation detail.

Entity Customer

Entity Account
    references Customer

Entity Transaction
    references Account

Feature CustomerOverview
    uses Customer
    uses Account
    uses Transaction

The distinction is subtle but decisive. A prompt tells an AI what to do. A structured intent describes part of what the software is.

From code generation to intent-based development

This suggests a different development model: intent, then architecture, then AI reasoning, then implementation, then execution — rather than prompt, AI, code.

Software Intent
  ↓
Architecture
  ↓
AI Reasoning
  ↓
Implementation
  ↓
Execution

The distinction matters even more when multiple AI agents participate in the lifecycle. If every agent communicates primarily through natural-language prompts, development becomes a chain of interpretations — each agent re-inferring what the last one meant. A structured representation of intent gives them a common artifact to work from.

• A requirements agent needs to understand the intent.
• An architecture agent transforms it into an architecture.
• An implementation agent generates code.
• A testing agent validates behavior.
• A security agent verifies constraints.
• A deployment agent prepares execution.

Why existing languages are not designed for this

Traditional programming languages are optimized for specifying implementation. They express executable structure well — but they are not necessarily the best representation of business intent.

class Customer { /* ... */ }
class Account { /* ... */ }
class Transaction { /* ... */ }

At the other extreme, natural language is expressive but ambiguous. Between the two lies a spectrum — and AI-native development creates an opportunity to introduce a more explicit representation between human intent and implementation.

Natural language      expressive, unstructured
  ↓
Prompts
  ↓
Structured intent
  ↓
Architecture
  ↓
Programming language
  ↓
Machine code          executable, implementation-oriented

AIS: a language for software intent

ADAAS developed AIS (AI-Script) around this problem. AIS represents software intent in a form AI systems can interpret and connect to architecture and implementation. The objective is not to replace conventional programming languages — it is to introduce a higher-level software representation that AI can reason over, describing what the software means while implementation technologies determine how that intent becomes executable.

AIS vs. prompt engineering

This distinction matters because enterprise software is not a collection of isolated AI requests. It is a continuously evolving system.

The enterprise problem is bigger than code generation

Consider an organization with hundreds of applications and thousands of developers. If AI increases implementation speed by 5x but architecture, requirements and validation remain unchanged, the organization does not achieve a 5x improvement in delivery. The bottleneck simply moves upstream.

Before AI
Requirements → Architecture → Development → Testing
                              ↑ bottleneck

After widespread AI coding
Requirements → Architecture → AI Implementation → Testing
     ↑               ↑
     └─ emerging bottlenecks ─┘

The ability to generate code becomes less scarce. The ability to define correct software intent and architecture becomes more important — exactly what the research shows AI leaves unresolved.

Intent becomes a strategic software asset

If implementation can increasingly be generated, organizations need to preserve something more fundamental than source code: a durable representation of business concepts, domain relationships, architectural decisions, capabilities, requirements, constraints, dependencies and application intent.

• That representation becomes a common source of context across the lifecycle — architecture, development, testing, security, documentation, deployment and evolution.
• Instead of documenting architecture separately from implementation, the intent representation is the shared model AI and engineering systems reason over.
• An AI agent no longer starts from an empty context inferring files, entities, conventions, APIs and rules — it operates inside a structured software model, which directly attacks the 'almost right' problem.

AIS is part of a larger architecture

AIS is not meant to operate in isolation. Within the ADAAS Architecture Intelligence Platform it forms part of a larger chain: AIS represents intent, A-Concept represents structural relationships and boundaries, A-Frame indexes and composes the relevant knowledge and capabilities, AI agents reason over that context, and implementation produces executable software. The objective is to keep these layers connected.

The question for technology leaders

For CTOs and engineering leaders, the strategic question changes. Instead of asking only how many lines of code AI can generate, organizations should also ask a harder set of questions.

• How is our software intent represented?
• Can AI understand our architecture?
• Can multiple AI agents share the same software context?
• Can requirements remain connected to implementation?
• Can architectural constraints be enforced during AI-generated development?
• Can we generate implementation without losing architectural control?

The real transition

The first phase of AI-assisted development focused on making developers faster. The next phase is likely to focus on making the software development system itself more machine-understandable. AI can generate implementation — but implementation is only the final expression of a much larger system of intent, architecture, knowledge, constraints and business meaning. The more capable AI becomes at generating code, the more valuable that higher-level context becomes.

Don't only teach AI how to write code. Give AI a structured representation of what the software is supposed to be.

The important transition is not from humans writing code to AI writing code. It is from implementation-centric development to intent-centric development — where business intent, architecture, knowledge, AI agents, implementation and execution remain continuously connected.