A working first slice creates new questions. Where should authorization live? How will the application handle notifications? What becomes difficult if the customer asks for another workflow? Architecture is the set of consequential decisions that shapes those answers. A diagram can help communicate the decisions, but drawing more boxes does not make a system more resilient.
Chapter 2 delivered a narrow request-management workflow. Here we examine how to use AI to explore architecture while keeping decisions tied to the product's actual constraints. The hypothetical tracker remains deliberately small. We will resist adding infrastructure until a concrete requirement makes its cost worthwhile.
Begin with the forces acting on the system
List the requirements that affect structure. For the tracker, users belong to organizations, requests contain potentially sensitive operational details, and coordinators need reliable saves. The team is small and must be able to deploy, diagnose, and support the application without a dedicated infrastructure department.
Separate these requirements from preferences. “Keep organization data isolated” is a requirement. “Use microservices” is an implementation choice that needs justification. “Make notifications eventually reliable” might become a requirement once notifications are part of a promised workflow; it should not silently become a requirement because an agent suggested a queue.
Ask the agent to summarize the forces and identify conflicts. A useful response explains trade-offs such as quick delivery versus operational complexity. Review the summary against the actual business context before requesting a design.
Draw boundaries around responsibilities
A simple starting design might contain a web interface, an application layer, and a relational database. Within the application, distinguish request operations, identity and authorization, and later notification handling. Logical boundaries can exist inside one deployable application; they do not require separate services.
For each boundary, explain what it owns and what it may assume. Request operations own validation and state transitions. Authorization determines whether the caller may perform the operation on the particular organization and record. Storage enforces the constraints needed to keep records consistent.
Use AI to challenge the boundary with a concrete change request. “If we add assignment history, where would the write occur?” is more useful than “Is this architecture scalable?” The answer should reveal coupling and ownership, not merely praise familiar design patterns.
Make the data model explain the workflow
Represent the states that the product actually uses. A request might be open, assigned, or completed. Define the permitted transitions and who can perform them. If reopening a completed request matters, decide whether it changes the original record or records a new event.
Keep organization identifiers on records where they support isolation, and validate their relationships on the server. A foreign key can establish that an assignee exists; it does not necessarily establish that the assignee belongs to the caller's organization. Authorization and relational integrity solve related but different problems.
Ask the agent for examples of invalid states. A completed request without an assignee might be valid in one workflow and invalid in another. The team must decide. Encoding the rule before discussing it can create an accidental policy that later users experience as a product limitation.
Compare alternatives using the same scenario
Start with a credible baseline
Use the simplest design that satisfies the known requirements and can be operated responsibly. For a small tracker, a modular application with one database may be enough. State its limitations, such as the consequences of a database outage or the capacity of its deployment environment.
Add one alternative when a force warrants it
Suppose notification delivery must continue after an email provider temporarily fails. Compare synchronous delivery with a durable job mechanism. Evaluate retries, duplicate delivery, monitoring, and support effort. A new component should solve a named problem, not provide an impressive diagram.
Record the reason for the choice
A short decision record should contain the context, options considered, chosen approach, consequences, and conditions that would justify revisiting it. An agent can draft this record, but the responsible engineer should verify that it reflects the decision the team actually made.
Design failure behavior alongside the happy path
Ask what happens if a user repeats a request, a database operation times out, or an external service responds late. A browser showing an error does not prove that the server failed to save. Retrying an uncertain operation can create duplicates unless the operation is designed to tolerate repetition.
For request creation, consider a client-generated operation identifier with a server-side uniqueness constraint. Keep the original result associated with the identifier so that a retry can return the same outcome. The exact implementation depends on the stack and workflow; the architectural requirement is a defined outcome under repetition.
When a workflow touches several systems, identify which system is authoritative and what happens between steps. Do not assume a local database transaction also commits an external email. Explain the recovery process for a partially completed workflow before promising reliable automation to users.
Review security boundaries explicitly
Trace one sensitive action from browser input to stored result. Identify where identity is established, where permission is checked, which data crosses a trust boundary, and where validation occurs. Ask the agent to attempt a different organization identifier and to explain why the server rejects it.
Keep secrets outside source files and public bundles. Give integrations narrowly scoped access and plan how access can be revoked. If the architecture includes an AI service, decide what information may be sent, how outputs are validated, and what happens when the service is unavailable or produces unsuitable content.
The OWASP Authorization Cheat Sheet offers useful reference material for reviewing access decisions. Apply its guidance to your actual routes and records. Citing a checklist is not evidence that the application enforces the intended policy.
Ask for artifacts you can maintain
Request a small diagram, a data model, decision records, and example request flows. Keep them near the code and update them when a consequential choice changes. A large generated architecture document becomes a liability if it describes features that do not exist or promises resilience that has not been tested.
An especially useful artifact is a short list of invariants. For the tracker: a user cannot read another organization's request; a request creation retry does not create a second record; a failed notification does not erase a saved request. Each invariant can later guide implementation and testing.
Link architectural claims to evidence where possible. A route test can support the organization-isolation claim. A retry test can support the operation-identifier design. Where evidence is missing, label the claim as a design intention that still needs verification.
Know when to revisit a decision
Set triggers tied to observed constraints. Revisit notification handling when failures cannot be recovered within the promised service level. Revisit storage access when measured query behavior affects the workflow. Revisit deployment structure when teams or release boundaries create a real coordination problem.
Avoid triggers such as “when we become successful,” which are too vague to guide action. Equally, do not treat the first design as permanent. Good architecture makes foreseeable changes manageable while leaving room to learn what the product actually requires.
Conclusion: use AI to expose decisions
AI is useful in architecture when it helps the team find hidden assumptions, compare credible alternatives, and explain failure behavior. The engineer remains responsible for choosing boundaries and verifying their consequences. A compact design that the team can operate is often more valuable than a broad design that nobody can confidently change.
Review your first slice from Chapter 2 and write three invariants plus one architecture decision record. Chapter 4 will turn these statements into a testing and release strategy for the MVP.
