Source: [If AI can build the software, what is the architect for?](https://treenodes.com/articles/if-ai-can-build-software-what-is-the-architect-for/)

This Markdown version is generated from the public page. Visit the source for interactive examples and full-size visuals.

[All writing](https://treenodes.com/articles/)

Published 7 September 2026 · Systems design · 8 min read

# If AI can build the software, what is the architect for?

A convincing portal demo leaves important decisions open. Follow a delivery-change request to see how architecture connects business rules, system ownership and recovery when AI helps build the software.

Written by [Nermien Barakat](https://treenodes.com/articles/by/nermien-barakat/)  · Software Architect & Engineer | Web & Mobile Applications | Business Systems & Applied AI

 ![TreeNodes editorial illustration: a woman architect at her desk connects a customer's delivery-change request with the existing order record, staff and warehouse. A coral branch represents recovery while the outcome is uncertain.](https://treenodes.com/assets/articles/ai-and-the-architect/00-article-illustration.png?v=f47de1b9b9c3)

Building a new system is one challenge. Moving a working business into it is another.

The new customer portal looks ready.

Customers can sign in, view orders and request a different delivery date. An AI coding tool has helped produce the screens, application logic and tests. The demonstration is convincing.

Then someone asks: **“Why don't we use AI to replace the old platform altogether?”**

Consider a hypothetical supplier whose existing platform handles accounts, agreed prices, orders and fulfilment. Staff check delivery changes before accepting them. The business wants fewer routine enquiries, less manual handling and clearer commitments to customers.

The portal can display a changed date. That does not establish that the warehouse can honour it, that the customer was authorised to request it, or that everyone sees the same confirmed order.

Faster implementation makes it easier to act on a design. It also makes it more important to establish what that design means for the business before extending it.

The architect's contribution is to make those decisions work together: what should change, what must remain true, and what evidence justifies the next step.

## AI can contribute to the decisions

“Humans think, machines type” would be a weak defence of the profession. GitHub documents agents that investigate repositories, develop plans, change code and run tests. [\[1\]](https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent)

I would use AI to challenge requirements, compare designs and investigate dependencies. Its proposals still need a basis: verified business rules, relevant constraints and evidence that the chosen approach works. So do mine. A job title is not evidence of correctness.

DORA's 2025 research describes AI as an amplifier of organisational strengths and weaknesses. My practical reading is that better tools should be accompanied by better ways of establishing context, evaluating changes and learning from results. [\[2\]](https://dora.dev/research/2025/dora-report/)

The question is how the team reaches a justified decision and who has authority to accept its consequences.

## Establish the business meaning first

“We need a new platform” is a proposed solution. The problem might instead be that too many eligible delivery changes need staff intervention. Establishing a baseline for that measure gives us something more useful than counting portal features.

Suppose staff currently check each change because some orders have already entered dispatch. We need to establish which checks remain necessary, which can be automated and who may approve exceptions.

Then distinguish three facts: **the date the customer requested, whether that request was accepted, and the currently confirmed delivery date**.

Storing all three meanings in one editable field would erase a distinction the operating process depends on.

Analysis helps the business agree on that meaning. Architecture connects it to permissions, records, system responsibilities and failure behaviour. Implementation and testing expose gaps in those agreements. The activities overlap as the team learns.

The aim is to preserve verified business obligations while removing workarounds that no longer serve a purpose.

## The first decision might be not to rebuild

Before approving a replacement, compare improving the current application, adding a focused portal, buying a suitable capability and replacing selected parts. Include integration, operation, support, transition and retirement costs in the comparison.

For our supplier, a reasonable first proposal is a portal that displays selected information and submits change requests. The existing platform keeps responsibility for accepted orders and fulfilment decisions.

That proposal has conditions. The existing platform must support the necessary access checks, rules and reliable integration, or be improved to do so. A diagram cannot assume an interface into existence.

If those conditions cannot be met affordably, an information-only portal or a controlled staff handover may be a better first release.

The value of the first step is a better customer channel with less routine handling. Replacing the core becomes a separate decision, supported by evidence about its constraints.

## Design the transition

While old and new software coexist, the business depends on that arrangement. It needs its own design.

The *Patterns of Legacy Displacement* authors describe transitional architecture as software that can deliver benefits earlier and reduce migration risk, even when parts are eventually removed. Its cost still needs to be justified. [\[3\]](https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html)

Diagram: A new channel. Not a second authority. Comparison of current staff-mediated service and a first-release customer portal with existing order ownership retained. Later architectural choices are alternatives. · A new channel. Not a second authority. · Comparison of current staff-mediated service and a first-release customer portal with existing order ownership retained. Later architectural choices are alternatives. · 01 / SYSTEM RESPONSIBILITIES · A proposed first release. Change the customer experience before changing ownership. · TODAY · PROPOSED FIRST RELEASE · Customers · Ask for a delivery change · Staff · Check the request and update the order · Existing platform · Accounts, prices and accepted orders · Fulfilment decisions · One authoritative accepted order record. · Request, then track the result · New portal · Customer interface · Durable request tracking · Existing route · Defined interface · Requests and results · Owns accepted orders · and fulfilment decisions · A request is not yet an accepted change. · NEXT DECISION, AFTER EVIDENCE · Retain the boundary · The first release meets the need. · Improve the existing core · Remove a demonstrated constraint. · Move one capability · Transfer ownership deliberately. · Illustrative responsibility view. Future choices are alternatives, not a sequence. · TreeNodes

Figure 1. Proposed responsibilities for the first release. Future choices are alternatives, not inevitable migration steps.

[Download Figure 1 PNG](https://treenodes.com/assets/articles/ai-and-the-architect/01-system-responsibilities.png?v=b3e44936dc47) [Download SVG](https://treenodes.com/assets/articles/ai-and-the-architect/01-system-responsibilities.svg?v=00a9e5b7fd53)

The portal owns receipt and tracking of customer requests. The existing platform owns the decision and record of an accepted change. The integration must connect each request to its outcome, preserve access restrictions and make delays visible. Staff need a way to resolve exceptions without creating contradictory orders.

A short architecture decision record preserves the context and consequences of significant choices. [\[4\]](https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record) For this proposal:

**Decision:** Keep accepted order changes under the existing platform's control. Show confirmation only after its authoritative outcome is established.

**Reason:** Introduce a customer channel without competing versions of an accepted order.

**Alternative and trade-off:** Moving order ownership now would widen the change and require a new integration boundary. Retaining it means some requests may wait or need staff intervention.

**Revisit when:** Evidence shows that the boundary blocks a needed capability, causes unacceptable delays or costs more to sustain than a targeted replacement.

## “Request received” is not “change confirmed”

Now test the design against an interrupted interaction.

A customer asks to move a delivery. The portal sends the request. No response arrives.

The request may have been accepted, refused or never received. A missing response does not establish which happened. AWS's guidance on safe retries explains why repeating an operation without dependable recognition of the original request can produce duplicate effects. [\[5\]](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

This design needs an explicit pending state and a way to establish the original outcome before claiming success or starting another business action.

Diagram: Request received is not change confirmed. A request to the order owner can be accepted, refused or not yet confirmed. Unknown outcomes stay pending and are resolved using the original request identity. · Request received is not change confirmed. · A request to the order owner can be accepted, refused or not yet confirmed. Unknown outcomes stay pending and are resolved using the original request identity. · 02 / RUNTIME RECOVERY · Request received ≠ change confirmed. · Do not turn an uncertain result into a promise to the customer. · Record the authorised request · Preserve its identity and requested change · Ask the order-owning platform · It applies the agreed rules and records the result · Which result · is established? · ACCEPTED · REFUSED · NOT ESTABLISHED · Confirm the change · Show the authoritative · confirmed delivery date. · Explain the refusal · Show the current · confirmed date. · Explain the reason. · Keep it pending · Do not claim success · or start a fresh request. · Recover the original request · Check its authoritative outcome. · Repeat only if duplicate-safe behaviour is verified. · Still unresolved? Preserve evidence and investigate. · Once resolved, · re-evaluate the result. · Illustrative runtime flow. A request ID alone does not enforce duplicate protection. · TreeNodes

Figure 2. Pending means the outcome is unknown. A request identifier alone does not enforce duplicate protection.

[Download Figure 2 PNG](https://treenodes.com/assets/articles/ai-and-the-architect/02-request-recovery.png?v=f0590f4e2c4b) [Download SVG](https://treenodes.com/assets/articles/ai-and-the-architect/02-request-recovery.svg?v=cbaa0b45965e)

If a request is refused, show the current authoritative confirmed date. Do not assume the portal's earlier display is still current: staff or another authorised request may have changed the order meanwhile.

Define how conflicting requests are resolved, how copied display data stays current and how unresolved cases reach support. These decisions connect a customer's promise to a recoverable operating process.

## Agree what “works” means

Feature behaviour is only part of acceptance. How current must order information be? What happens when the existing platform is unavailable? How is access restricted to the right customer account? How quickly must an unresolved request reach support?

An older order snapshot might be acceptable if its age is visible. Accepting a change against outdated fulfilment information might not be. That distinction needs an agreed policy.

Before widening the release, check what happens to requests already received if the portal is disabled. They must remain traceable and capable of resolution. Returning to an old screen does not undo business decisions already made.

## Use AI throughout, with evidence

Give AI the current responsibilities, verified rules, known uncertainties and acceptance examples. Ask it to challenge the proposal: “Which dependency have we overlooked?” and “What evidence would disprove this design?”

Define which repositories, tools and data the agent may access and which actions require approval. GitHub's guidance emphasises scoped tasks, context, and review and testing of generated work. [\[6\]](https://docs.github.com/en/copilot/responsible-use/agents)

The shared workflow should leave evidence behind: an agreed problem and baseline, a reason for the chosen approach, testable rules, a reviewable implementation, and results that justify release. Small changes make that evidence easier to assess and feedback faster to obtain. DORA recommends small batches to support effective AI adoption. [\[7\]](https://dora.dev/capabilities/working-in-small-batches/)

Diagram: From intent to evidence. Six-stage delivery workflow with outputs at every stage, a release decision and a revision path. AI can assist at all stages. No new software is a valid option. · From intent to evidence. · Six-stage delivery workflow with outputs at every stage, a release decision and a revision path. AI can assist at all stages. No new software is a valid option. · 03 / AI-ASSISTED DELIVERY · A shared team workflow. AI can contribute throughout. · A selected software change follows this path. “No new build” is also a valid choice. · WORK · EVIDENCE LEFT BEHIND · 01 · Understand the problem · Agreed problem + · success measure · 02 · Choose the approach · Chosen option and trade-offs · 03 · Set the contract · Rules, boundaries + · acceptance examples · 04 · Build a small change · Reviewable implementation · 05 · Verify against evidence · Results and unresolved risks · Evidence supports this release · and approval is in place? · NO · REVISE · Return to the affected · stage, then recheck. · YES · 06 · Release and learn · Observed outcome + · next decision · Real use can reopen the problem, the approach or the design. · Delivery workflow, not a runtime process. Review depth follows the consequences of failure. · TreeNodes

Figure 3. AI can contribute throughout. Review depth follows the consequences of failure, and the chosen approach may require no new software.

[Download Figure 3 PNG](https://treenodes.com/assets/articles/ai-and-the-architect/03-evidence-workflow.png?v=4e9edff73d6a) [Download SVG](https://treenodes.com/assets/articles/ai-and-the-architect/03-evidence-workflow.svg?v=4960473ff8a4)

Verification must include unauthorised access, conflicting changes and lost responses. If code and tests both assume that a request is automatically accepted, they can agree perfectly while violating the business rule. Expected results must come from the agreed process.

## Try it: recover an uncertain delivery change

Use the article’s hypothetical supplier and a delivery-change request whose response never arrived. Compare the proposed customer state and recovery process with the business rules.

**How to try it.** Open a new chat in your preferred AI assistant and copy the complete prompt. Its fictional fixture is included; no live order system or external data is needed. Compare the response with the expected results, then inspect the staff-change variation.

Recover a delivery-change request

Included file: delivery-change-recovery.txt

[Download file](https://treenodes.com/downloads/practice/delivery-change-recovery.txt)

**Full prompt**

```
An existing platform owns accepted orders. A portal records delivery-change requests. It sends one authorised request but receives no response.

Propose the customer-facing state and a recovery process. Do not assume the request failed or that repeating it is safe. What must be verified before confirming a date?

Then reconsider your answer if staff changed the order while the request was pending.
```

### What your result should show

-   The request remains pending until its authoritative outcome is established. A missing response alone proves neither acceptance nor refusal.
-   Recovery follows the original request and checks its authoritative outcome. Repetition requires verified duplicate-safe behaviour; a request identifier alone is insufficient.
-   The confirmed date comes from the order-owning platform. If another authorised change has occurred, the response identifies a conflict or versioning decision instead of presenting the portal’s old date as current.

### Change one condition

Staff change the order while the customer request is pending, as in the final sentence of the prompt. The answer should explain how to establish the current order version and resolve the conflict. It should ask for the applicable business policy instead of inventing priority for either request.

Release with monitoring, a support owner and a workable recovery procedure. Then check whether customers and staff can manage eligible changes with less intervention before widening the scope.

## The role should earn its place

This does not prove that every team needs separate architect and analyst positions. The business owns its policies and risk decisions; analysts, architects, engineers, product specialists and operational teams contribute expertise. One person may carry several responsibilities.

Judge the architectural contribution by what it improves: unnecessary complexity avoided, business rules made explicit, changes made easier to evaluate and failures made easier to recover from.

The architect should help the team move without waiting for an architect at every step. Clear boundaries, useful decision records and automated checks should reduce dependence on a permanent approval bottleneck.

Success for our supplier is better order management, fewer unresolved exceptions and a cost the business can sustain. AI can help design and build that outcome. Architecture connects the choices that make it possible.

Before your next AI-assisted build, ask: **what must remain true about the business, even if the implementation changes completely?**

* * *

*The supplier, portal and proposed designs are hypothetical, not a reported client case. The sources support the referenced capabilities and engineering principles; they do not establish an outcome for this scenario. Sources checked on 7 September 2026.*

## Takeaways

-   Agree what must remain true about the business before extending the implementation.
-   Give accepted changes one authoritative record and keep unknown outcomes recoverable.
-   Judge architecture by the decisions it improves and the operating results the team can verify.

READING PATH · 5 OF 5

## Making architecture decisions

Understand what software architecture means, model the system, choose useful views, then trace what happens at runtime.

You’ve reached the end of this path. [Choose another reading path →](https://treenodes.com/articles/reading-paths/)

[View the complete reading path](https://treenodes.com/articles/reading-paths/#dependable-systems-ai-era)

1.  [01 What is software architecture?](https://treenodes.com/articles/what-is-software-architecture/)
2.  [02 Modelling the system before the code](https://treenodes.com/articles/modelling-the-system-before-the-code/)
3.  [03 The C4 model: architecture at the right level](https://treenodes.com/articles/c4-model-software-architecture/)
4.  [04 What happens when you press a computer’s power button?](https://treenodes.com/articles/what-happens-when-you-press-the-power-button/)
5.  05 If AI can build the software, what is the architect for?

**REFERENCES AND FURTHER READING  — 7 sources**

1.  [About GitHub Copilot cloud agent](https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent)  — GitHub
2.  [State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/)  — DORA
3.  [Transitional Architecture](https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html)  — Ian Cartwright, Rob Horn and James Lewis
4.  [Maintain an architecture decision record (ADR)](https://learn.microsoft.com/en-us/azure/well-architected/architect-role/architecture-decision-record)  — Microsoft
5.  [Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)  — AWS Builders’ Library
6.  [Application card: GitHub Copilot Agents](https://docs.github.com/en/copilot/responsible-use/agents)  — GitHub
7.  [Working in small batches](https://dora.dev/capabilities/working-in-small-batches/)  — DORA