AI for Technical Architecture Design: Start With Constraints

Use AI for technical architecture design by giving it measurable requirements and constraints, asking for a few viable options, and testing the assumptions behind each option. The useful output is a justified software design that your team can build and operate, with open questions clearly marked.

Start with what the system must do rather than a list of technologies you hope to use. fenbs can keep those constraints, human decisions, and unfinished design tasks available across sessions, so a fresh assistant starts from the current agreement.

What is the first design sequence?

1. Describe one real user journey and the business result it must produce.
2. List hard constraints, expected workload, data handling rules, and the team’s operating limits.
3. Ask the assistant to restate the requirements and identify contradictions or missing information.
4. Develop two or three plausible designs using the same comparison criteria.
5. Test the riskiest assumption, choose an option with a person responsible, and record the next design task.

For example, say a small supplier needs a customer portal for submitting orders and viewing their status. The first design question is what must happen when a customer presses Submit, including failures and repeated attempts. Choosing a message queue before answering that question can create complexity without solving a defined problem.

Separate a requirement from a preference. “Orders must remain recoverable after a failed deployment” describes an outcome. “Use three services” describes one possible implementation. The Azure application design principles↗ (opens in a new tab) likewise connect technical choices with business requirements and operating concerns.

Which constraints belong in the starting context?

Provide enough context to rule options in or out. Include who will use the system, what data it holds, how it connects to existing software, and who will support it. If a number is unknown, give it an owner and a way to establish it rather than letting the assistant invent a precise estimate.

State which instructions remain binding and which are suggestions. Include the source and date for important constraints, such as an approved internal handling policy. When something changes, record the replacement rather than leaving contradictory instructions for the assistant to reconcile.

This is one practical use of an AI brain: preserve the context that changes the next piece of work. In fenbs project context, rules and current progress can stay connected to the tasks they guide.

How do you get different options?

Ask for alternatives that differ in a meaningful boundary, data flow, or operating responsibility. A list of three cloud vendors is not useful if every option quietly assumes the same architecture. Require each alternative to explain how it handles the same user journey and the same failure scenario.

Use the requirements and constraints below.
First list missing facts and conflicting requirements.
Then propose two viable software designs.
For each, explain:
1. Request and data flow for the main user journey
2. Ownership of each piece of data
3. Behavior when a dependency fails
4. Deployment and recovery responsibilities
5. Main tradeoff and assumption to test
Prefer the simplest design that meets the requirements.
Do not choose for us or invent workload measurements.

For the supplier example, compare a single application with background work against a design that separates order processing. Ask what evidence would justify that separation. Both designs need a clear answer for duplicate submissions, customer access, and stock-system failures; neither earns credit just for looking more elaborate.

Use the AWS Well-Architected Framework↗ (opens in a new tab) as a source of review questions when designing an AWS workload. Apply questions to your actual constraints rather than treating a framework as a machine that selects the right architecture.

How much detail should the design contain?

Show enough detail for another developer to explain a request from start to finish. Name the caller, the application boundary, the data owner, and important external systems. Write down what each arrow carries and what happens when that interaction fails. A diagram without those meanings can hide an unresolved design.

The C4 model↗ (opens in a new tab) provides several levels of software diagrams. Choose the level that helps the next decision: an overview for the surrounding systems, a closer view for applications and data stores, and further detail only when needed. Keep diagram labels consistent with the written design.

Include a short decision record beside the design: context, options, choice, consequences, and remaining checks. The technical design document template helps structure the longer artifact. If you are designing software that uses autonomous assistants, AI agent architecture covers that more specific system shape.

How do you test assumptions before building everything?

Find the assumption whose failure would force the largest redesign. It may concern an external interface, data isolation, request volume, or the team’s ability to restore the system. Design a small test that could disprove the assumption and define the result you need before running it.

• Interface uncertainty: verify a representative request and failure response against the real documented interface.
• Recovery uncertainty: rehearse recovery in an appropriate test environment and record what the team actually restored.
• Capacity uncertainty: measure a representative workload rather than extrapolating from a tiny happy-path example.
• Operating uncertainty: have the person who will support the system walk through deployment and incident steps.

An AI-generated prototype is evidence about the behavior you checked, not proof of every requirement. Save the test conditions and limitations. If a test changes the preferred option, update the design and explain why instead of quietly replacing the earlier recommendation.

How to do this with fenbs

1. Create a free account and add a project for the system you are designing.
2. Record the goal and the approved constraints in the project context and Decisions and rules. Keep source links and definitions easy to find.
3. Add tasks for the design options, risky assumptions, and outstanding checks. Put the intended approach and verification in each task’s plan.
4. Connect your supported assistant through Integrations, ask it to read the project context first, and save where the design stands before stopping.

fenbs does not generate or run your architecture. Use a design or diagram tool when you need the actual technical artifact; fenbs fits when constraints and decisions need to survive changing chats, assistants, or teammates. People choose and sign off; assistants can record those choices.

What makes the design ready for implementation?

A design is ready enough when someone can build the next bounded piece without guessing about its essential behavior. The important constraints have an answer, unresolved risks have an owner, and the team knows which evidence is still missing. The document can remain short if those answers are clear.

Ask a developer who did not join the design chat to explain the main flow and its failure behavior. Correct the record where they have to infer a key decision. The context engineering hub offers more ways to make that starting information useful to people and their assistants.