Microsoft Is Putting Specifications Before AI Code: What Should Business App Buyers Ask For?

Microsoft is increasingly treating specifications, requirements and acceptance criteria as the starting point for AI-assisted software development rather than asking AI to generate code first. For Sydney and NSW businesses commissioning internal applications, the practical lesson is procurement discipline: define the workflow, data, permissions, exceptions, integrations and acceptance tests before development begins, so the finished system can be objectively tested against the business outcome that was actually purchased.

Artificial intelligence has dramatically reduced the amount of time required to turn an idea into working software. That does not necessarily mean businesses should start building sooner.

Microsoft's emerging approach to AI-native engineering points in almost the opposite direction. Its teams are increasingly emphasising spec-driven development, where business intent, user requirements, constraints, edge cases and acceptance criteria are established before implementation becomes the centre of attention.

Microsoft Digital describes specifications as a living source of truth connecting business objectives with architecture, development, testing and validation. GitHub's Spec Kit follows a related sequence: define what is required, clarify uncertainty, create the technical plan, break the project into tasks, implement it and then validate the result against the specification.

For organisations commissioning AI software development in Sydney, this is more significant than another software-engineering methodology. It changes what a buyer should expect to receive before agreeing that development has properly started.

The central procurement question becomes: What evidence will allow the business to decide that the application works as commissioned?

AI Has Made Code Cheaper. Ambiguity Has Not Become Cheaper.

Traditional custom software projects could spend weeks moving from requirements workshops to interface designs, architecture and development.

AI coding agents can compress parts of that process dramatically. A developer can describe a dashboard, customer portal, workflow application or internal operations tool and receive functioning components quickly.

That speed creates a new temptation: allowing the prototype to become the specification.

A manager sees a working screen and asks for another field. The operations team asks for a second approval state. Finance discovers that records need a different numbering convention. Staff later explain that one category must never progress automatically. An integration behaves differently when a customer record is duplicated.

The application is being designed while it is already being built.

AI can make that cycle feel inexpensive because each individual change may be generated quickly. The commercial problem appears later through accumulated rework, inconsistent logic, regression errors and uncertainty over which behaviour represents the approved requirement.

Microsoft's spec-first position matters because it recognises that faster implementation increases the value of precise intent. When code is cheap to produce, poorly defined requirements can become the larger constraint.

The Business Buyer Should Own The Definition Of Done

A Sydney business commissioning an internal application should not need to understand every framework, API or database decision. It does, however, need to understand what it is buying.

Consider a property or project-delivery business commissioning an application that converts incoming enquiries into operational projects.

A brief such as "build an AI app that reads enquiries, creates jobs and schedules the team" is not yet a sufficiently testable specification.

Before implementation, the project should establish matters such as:

• which email addresses, forms or communication channels can create an enquiry;
• which customer and project details are mandatory;
• how duplicate customers or properties are detected;
• which information AI may infer and which information must be explicitly supplied;
• when a record remains a lead and when it becomes an active project;
• who can approve pricing, dates, access arrangements or contractual commitments;
• what happens when information is contradictory or incomplete;
• which systems receive the final information;
• what evidence must be retained about significant actions; and
• what must happen before the project is considered successfully handed over.

Those are not merely technical details. They are operating rules.

Elyment's analysis of enquiry handling between email, CRM and quoting illustrates why the distinction matters. AI can classify and extract information, but the business still needs deterministic rules for records, ownership, stages, escalation and commercial commitments.

A Specification Should Describe Behaviour, Not Just Features

Many software briefs are feature inventories.

They say the application requires a dashboard, CRM integration, document upload, notifications, AI search and reporting. That information may help estimate the project, but it says surprisingly little about how the application should behave.

A useful specification goes further.

Instead of: "The app needs project approvals"

The specification might establish that a project coordinator may prepare a variation, but a variation above a defined financial threshold cannot change status until an authorised manager approves it.

Instead of: "The app connects to the CRM"

It might establish which system owns the customer record, which fields can be updated by the new application, how duplicates are handled and what occurs if the CRM is unavailable.

Instead of: "AI summarises documents"

It might identify which document types may be processed, which information must be extracted, what sources must be cited in the summary, which documents are excluded and when low-confidence results must be referred to a person.

The difference is testability.

"Has AI document summarisation" can be demonstrated. "Correctly extracts six required fields from the approved document set and escalates when one cannot be established" can be accepted or rejected.

Acceptance Tests Belong In The Commercial Brief

Acceptance testing is often treated as something that occurs near the end of development. Spec-driven development suggests that many of the critical acceptance conditions should exist much earlier.

For a business buyer, this changes the commercial conversation.

Before commissioning the build, ask the supplier to identify how each material requirement will be demonstrated.

• Prevent duplicate projects
• Example acceptance evidence: A defined set of duplicate-address and duplicate-customer scenarios passes without creating an unintended second project.
• Restrict financial approvals
• Example acceptance evidence: Users outside the approved role cannot authorise, bypass or indirectly trigger the restricted action.
• Extract information using AI
• Example acceptance evidence: A representative evaluation set is tested against agreed accuracy and escalation criteria.
• Integrate with an existing platform
• Example acceptance evidence: Successful writes, rejected writes, authentication failures, duplicates and service outages are tested.
• Protect customer information
• Example acceptance evidence: Role access, logs, data flows and prohibited information paths are demonstrated and documented.
• Support business continuity
• Example acceptance evidence: The team can identify failed processing, recover work and continue through an agreed fallback procedure.

This is where acceptance criteria become commercially important.

Without them, disagreement near handover can become subjective. The supplier may reasonably say the requested feature has been delivered. The customer may reasonably say the feature does not work in the way operations requires.

A testable specification reduces that gap before money has been spent implementing the wrong interpretation.

Ask For The Exceptions Before Asking For The Happy Path

Demonstrations naturally show software under ideal conditions.

Production businesses operate under less convenient conditions.

Sydney property, renovation, professional-services and infrastructure teams regularly deal with:

• missing addresses;
• multiple contacts for the same project;
• changed access instructions;
• duplicate enquiries;
• late documents;
• supplier substitutions;
• cancelled work;
• incorrect customer records;
• changed project dates;
• approval delays;
• integration outages; and
• information that cannot safely be inferred.

An AI-built application should therefore be specified around both normal processing and exception processing.

A useful procurement workshop may spend more time asking "what happens when this is wrong?" than discussing how attractive the normal workflow looks.

That approach also distinguishes this procurement issue from the separate question of AI autonomy. Elyment has previously examined how deterministic business rules can be separated from AI reasoning. Specification-driven procurement begins one stage earlier. It asks the buyer to define the intended behaviour before deciding how much of that behaviour should be implemented through deterministic code, AI reasoning or human judgement.

The Data Specification May Matter More Than The Interface

Businesses often spend substantial time reviewing screens because screens are visible.

The more consequential design decisions may be underneath them.

Before commissioning an operational application, buyers should be able to answer:

1. What is the authoritative record?
2. Is the source of truth the new application, an existing CRM, accounting platform, project system or another database?
3. Which fields are mandatory?
4. A workflow should not rely on staff knowing informally which information matters.
5. Who may change each field?
6. Viewing a record and changing a commercially significant record are different permissions.
7. What can AI generate or infer?
8. Generated classifications should not quietly become authoritative facts unless that is intentionally designed.
9. How is conflicting information handled?
10. The system needs a rule for competing sources.
11. How long is information retained?
12. Storage and logs should reflect actual operational, contractual, privacy and compliance requirements.
13. What happens when an external system rejects an update?
14. A successful local screen does not prove the connected workflow completed.

This matters particularly where personal information enters AI-enabled functionality. The Office of the Australian Information Commissioner advises organisations selecting AI products to understand intended uses, data flows, access, testing, human oversight, privacy risk and whether the system is appropriate for the purpose.

Privacy, therefore, should not appear as a generic line saying "the application will comply with privacy requirements". The specification should identify the relevant information paths and controls.

Security Requirements Should Also Exist Before Development

The same principle applies to cybersecurity.

The Australian Signals Directorate's secure-by-design guidance emphasises that procuring organisations should establish, document and understand their security requirements so products can be evaluated against them.

For an AI-enabled business application, the buyer's specification may need to address:

• identity and sign-in requirements;
• multi-factor authentication or single sign-on;
• user roles;
• administrative access;
• service accounts and credentials;
• audit logging;
• data encryption;
• backup and recovery;
• third-party APIs;
• environment separation;
• security patch responsibilities;
• incident notification; and
• what access remains with the developer after handover.

These requirements become especially important when AI can initiate tool calls or actions rather than merely produce text. Elyment's examination of controls around AI agent tool calls considers the later execution stage. A strong specification establishes many of those authority boundaries before the application's architecture is locked in.

NSW's AI Assurance Approach Reinforces The Value Of Early Definition

NSW Government's AI Assessment Framework applies specifically to NSW Government agencies rather than automatically imposing the same process on private Sydney businesses.

Its lifecycle approach is nevertheless instructive for organisations buying AI-enabled systems.

The framework requires agencies to identify use cases, risks, governance responsibilities and mitigation measures across development, procurement, deployment and operation. It also emphasises assessment during project planning rather than treating assurance as a final gate immediately before launch.

Private organisations can draw a useful procurement principle from that approach: material risk requirements should enter the project while the system can still be designed around them.

Adding privacy, security, auditability or approval architecture after an application has been substantially built can require expensive structural changes.

What Should Be In The Specification Pack?

The answer does not need to be a 300-page requirements document.

Microsoft's own writing on spec-driven development warns against turning specifications into bureaucratic documents that nobody uses. The purpose is structured clarity, not paperwork for its own sake.

For many SME and mid-market Sydney projects, a practical specification pack can be relatively compact while still covering the decisions that matter.

1. Business objective

State what operational problem is being changed and how success will be measured.

2. Users and authority

Identify user groups, permissions, approval authority and administrative roles.

3. Workflow definition

Document the significant states, handoffs, triggers, dependencies and completion conditions.

4. Business rules

Record mandatory conditions, thresholds, prohibited actions and escalation rules.

5. Data model

Define important records, required fields, ownership, validation and source-of-truth rules.

6. AI behaviour

Identify precisely where AI classifies, extracts, recommends, drafts or acts, together with confidence, escalation and review expectations.

7. Integrations

Specify which external systems communicate with the application, what data moves between them and what should happen on failure.

8. Security and privacy requirements

Define access, logging, personal-information handling, credentials, retention and environment controls.

9. Non-functional requirements

Establish important expectations for performance, reliability, availability, mobile use, browsers, accessibility, backup and recovery.

10. Acceptance scenarios

Write testable conditions representing routine operations, boundary cases and known exceptions.

11. Handover requirements

Define documentation, source-code access, credentials, deployment information, support arrangements, training and ongoing ownership.

12. Change-control process

Establish how additions or changed assumptions alter scope, cost, timing and acceptance criteria.

A Prototype Is Evidence Of Possibility, Not Evidence Of Completion

AI development makes prototypes unusually persuasive.

A developer can create a polished interface, realistic workflow and convincing AI interaction early in the engagement. Senior stakeholders may understandably feel that the project is almost finished.

The remaining work may include the difficult parts:

• real permissions;
• production data;
• integration reliability;
• security hardening;
• exception paths;
• migration;
• auditability;
• testing;
• deployment;
• staff training; and
• support arrangements.

Buyers should therefore avoid tying the concept of project completion to visual maturity.

A visually simple internal application can be operationally sophisticated. A visually sophisticated prototype can remain operationally incomplete.

The Contract Should Distinguish Defects From New Requirements

Specification quality also affects cost management.

Custom software projects frequently encounter disputes over whether a requested change is fixing a defect or adding new scope.

If the original specification says only that "managers can approve jobs", several interpretations remain possible. If it says which manager roles can approve which project states, at what thresholds, under which conditions and with what audit record, the position is considerably clearer.

A practical change-control mechanism should distinguish:

• non-conformance: delivered behaviour does not satisfy the agreed requirement;
• clarification: the requirement remains unchanged but additional detail is required;
• changed requirement: the business has changed what it wants;
• new scope: functionality was not included in the original commissioned outcome; and
• external change: a platform, API, regulatory requirement or dependency has changed.

This is one reason businesses considering custom systems should make the build-versus-buy AI decision before assuming that rapid AI-assisted coding automatically makes bespoke software economically preferable.

Seven Questions To Put To An AI App Developer Before Signing

1. What specification will exist before implementation?
2. Ask whether the project will document users, workflow behaviour, business rules, data, integrations, constraints and acceptance criteria before substantial coding begins.
3. How will you resolve ambiguous requirements?
4. The answer should involve clarification with accountable business owners, not silent assumptions made by a coding agent.
5. What tests define successful delivery?
6. Request acceptance scenarios before handover, not only a demonstration after development.
7. How will requirements remain connected to the finished application?
8. Ask whether specifications, tests and implementation decisions remain versioned and traceable as the project changes.
9. What happens when AI produces the wrong result?
10. Require defined escalation, review and failure behaviour for AI-dependent functions.
11. What exactly will we own and receive at handover?
12. Clarify source code, repositories, deployment documentation, credentials, configurations, data, test evidence and support obligations.
13. Who decides that the application is accepted?
14. Technical completion should not substitute for operational acceptance by the business people who understand the workflow.

The Best Specification Is Built With The People Who Actually Do The Work

One danger of spec-driven development is assuming that a technically precise document is automatically an accurate one.

It is not.

A specification can perfectly describe the wrong process.

Business application projects therefore need participation from the people who understand operational reality. For a Sydney property or renovation operation, that may mean involving administration, estimating, project delivery, finance and management rather than allowing a software supplier and one executive sponsor to design the workflow alone.

Frontline staff know where information arrives late. Finance knows which status cannot change before reconciliation. Project managers know which booking assumptions fail on real sites. Management knows which commitments require authority. Technology teams know which systems and security constraints have to be respected.

Spec-driven development works when those perspectives become explicit before AI begins converting assumptions into code.

AI Software Development Sydney Is Becoming A Procurement Discipline

Microsoft's move towards specification-led AI engineering points to a broader change in the software market.

The competitive advantage of a development firm will increasingly be less about demonstrating that it can generate code with AI. That capability is becoming widely available.

The more valuable capabilities are likely to be:

• understanding the client's operating process;
• turning that process into clear requirements;
• identifying conflicting assumptions before construction;
• designing testable acceptance criteria;
• controlling data and integration boundaries;
• managing changes without losing traceability;
• testing real operational exceptions; and
• delivering a system that another team can understand and maintain.

Businesses beginning this process can also use an AI consulting and implementation review to determine the workflow and delivery model before selecting the development approach.

Define The Application Before Paying To Build It

AI SOFTWARE · REQUIREMENTS · PROJECT DELIVERY

Review the workflow, requirements, data, permissions, integrations, acceptance tests, implementation sequence and handover obligations before an AI-built business application moves from prototype to commissioned system.

Request An AI Application Project Review

The Commercial Lesson From Microsoft's Spec-First Shift

AI can increasingly generate software faster than organisations can decide what the software should actually do.

That changes where discipline is required.

A Sydney business commissioning an AI-built application should not begin by asking how quickly the developer can produce the first version.

It should ask what specification will control the build, which assumptions will be resolved before implementation, what evidence will prove the requirements have been satisfied and who has authority to accept the finished system.

Spec-driven development does not remove iteration, experimentation or AI-assisted speed. It gives those capabilities a reference point.

The specification becomes the bridge between what management believes it ordered and what the development team actually builds.

As AI-generated code becomes faster and cheaper, that bridge may become one of the most valuable assets in the entire project.

Sources and References

• Microsoft Digital: Spec-driven development and specification-led AI engineering.
• GitHub: Spec Kit.
• Office of the Australian Information Commissioner: Guidance for organisations selecting and using AI products.
• Australian Signals Directorate: Secure-by-design guidance.
• NSW Government: AI Assessment Framework.
• Elyment: Enquiry handling between email, CRM and quoting
• Elyment: Deterministic business rules and AI reasoning
• Elyment: Controls around AI agent tool calls
• Elyment: Build-versus-buy AI decision
• Elyment: AI consulting and implementation review