A four-phase, AI-assisted methodology for architecture and development planning, shaped across Adobe Commerce engagements, that gets a project from discovery call to developer-ready tickets in days instead of weeks, with the architect still running every judgment call.

Introduction

Architecture and development planning is one of the most consequential phases of a project, and one of the most demanding. Discovery sprawls across multiple calls. Requirements emerge in fragments. The gaps don't show themselves until a developer is mid-implementation and asking why something doesn't add up. Documentation lags behind the conversations that produced it, and by the time tickets land with developers, the context has shifted and the architect has already moved on to the next priority.

Generative AI doesn't solve this on its own. Used deliberately, though, it speeds up the parts of the process that consume the most architect time while contributing the least architect value: reviewing call transcripts, drafting initial documentation, surfacing overlooked questions, generating diagrams, and converting requirements into ticket-ready language.

This document describes a methodology I have refined across Adobe Commerce engagements. The principles apply broadly; the platform specifics matter less than the workflow. The goal isn't to delegate architecture to AI. It's to stop spending architect hours transcribing what already happened, and put those hours toward the parts of the job that actually need an architect.

A note on responsibility and AI policy

Two things need to be clear up front.

First, AI is a convenience, not the brain. The architect's expertise and judgment are responsible for everything that follows: whether the documentation is accurate, whether the requirements hold up, and whether the implementation lands. Every AI output is a draft to be reviewed, corrected, and owned. Trust nothing blindly. The methodology below assumes the architect is the editor-in-chief throughout.

Second, follow your organization's AI guidelines. Most organizations maintain policies on what client data and intellectual property can be exposed to which AI tools. Before using any AI tool on client work, review your organization's current policy and confirm that the tools and workflows here are approved for the data you're handling. The methodology assumes you're operating inside those guidelines.

The methodology at a glance

The process moves a project from initial client conversation to developer-ready tickets in four phases. Each phase produces an artifact that feeds the next.

The phases are sequential but iterative. Phase 2's gap analysis often loops back into a follow-up discovery call, which feeds Phase 1 again. Phase 3's proofreading frequently surfaces new gaps that route back to the client. It's not a rigid pipeline; it's a structure repeatable enough to stop the most common failure mode I see, which is jumping from a half-understood discovery call straight to half-formed tickets.

Phase 1: Capture & comprehension

Step 1: Hold recorded, transcribed discovery calls

All client discovery happens over Microsoft Teams (or a similar company-approved platform like Zoom or Google Meet) with recording and transcription turned on. The recap and transcript become the raw material for everything that follows.

This sounds obvious, but it's the single most important habit shift. Without a transcript, you're reconstructing the conversation from memory and notes, and AI can't help with what it can't see. With a transcript, every step downstream has a reliable source of truth, assuming the transcription quality is decent.

Step 2: Feed the AI-generated recap into the model of choice

After the call, the AI-generated meeting summary goes to the chosen model. For complex synthesis work, that's typically Claude Opus, which handles long-form context and nuanced reading well. For lighter tasks downstream (ticket polish, quick rewrites), JIRA's Rovo AI is more efficient.

The choice of model matters less than being deliberate about the choice. Different tools have different strengths. Matching the tool to the task produces better output and lower cost than running everything through a single model.

Step 3: Ask the AI to summarize its understanding, then correct it

The first prompt is always a comprehension check. Ask the model to summarize, in its own words, what the project is trying to accomplish, who the stakeholders are, and what the major moving parts appear to be.

Then read that summary critically and push back. Wrong assumptions get corrected. Missing context gets added. Subtle misreadings (an AI mistaking a nice-to-have for a hard requirement, or a future-phase idea for a Phase 1 deliverable) get flagged and clarified.

This step can take anywhere from minutes to hours, depending on the size of the documentation set. It's worth every second. By the end, the model has an accurate working model of the project, and you've caught any drift between what the client said and what the AI heard. Everything downstream benefits from that alignment.

Phase 2: Gap analysis & iteration

Step 4: Ask the AI what is missing

Once the model has an accurate baseline, ask it a focused question: what wasn't asked, what's still unclear, what requirement gaps exist?

It almost always returns a long list. Some of it is useful. Some of it is not. Invalid suggestions, irrelevant tangents, and questions the architect already knows the answer to but didn't say aloud all need to come out. Filter and refine. What's left is a high-quality starting point for a gap list.

Then expand the list with your own additions: questions the AI didn't think to ask, but experience flags as important. The combined list drives one of two outcomes: questions answered quickly over chat or email, or a follow-up discovery call scheduled to address the larger items.

This step is where AI delivers outsized value. It takes a fresh perspective on a domain you already know well, and it asks questions you wouldn't have thought to ask precisely because you're too close to the problem.

Phase 3: Documentation build & sync

Step 5: Build the wiki structure as Markdown files

Once enough information is in hand, start building the project's wiki. Author the pages as Markdown files first, then paste into Confluence. Markdown is faster to write than Confluence's editor, and it leaves you with a local copy you can version-control and re-feed to the AI later when something changes.

A typical structure for a feature or system design uses an overview page as the parent, with technical detail pages as children. A recent engagement used the following structure:

• Overview & high-level plan: non-technical summary, problem statement, phasing, and core capabilities

• Data model & entity relationships: entity definitions, field-level schemas, relationship diagrams, and integration points with existing entities

• Stages, workflow, & business rules: lifecycle states, transition triggers, configurable rules, and side-state mechanics

• Dashboard & admin UX: grid columns, filtering, detail views, and role-based permissions

• Email & communication tracking: outbound email templates, activity logging, and integration with existing email infrastructure

• Discovery questions for next session: resolved items (with their resolutions inline) and open questions organized by topic

The overview page is intentionally non-technical. It exists so that a stakeholder, business analyst, or new team member can understand the shape of the work without needing to read schema definitions. The subpages carry the technical weight.

The discovery questions page matters more than it looks. It isn't deleted as items resolve. Answered questions stay on the page, marked resolved with their resolution noted inline; unresolved questions remain visible. That single page becomes the running record of every decision made during planning, which pays off six weeks later when a developer asks why a design choice was made.

Step 6: Proofread, finalize in Confluence, and re-sync the Markdown

After pasting into Confluence, proofread each page top to bottom twice. Adjustments are usually small: a misnamed field, a missing edge case, a sentence that reads cleanly in Markdown but awkwardly in Confluence's rendering. Occasionally, a larger gap appears and triggers a clarification with the client.

Once each Confluence page is finalized, download it as a PDF and share it back with the AI model with a simple instruction: update the local Markdown file to match the finalized page exactly. The result is a Markdown copy that mirrors Confluence.

This bidirectional sync pays off the first time requirements change. When a requirement shifts three weeks later, feed the new requirements to the AI and confirm it understood them correctly. The AI updates the local Markdown files and reports which files were changed. You then paste the updated content into the corresponding Confluence pages. Markdown stays canonical for AI-assisted iteration; Confluence stays canonical for the team.

Diagrams: Generate ASCII first, upgrade to Miro when time allows

Throughout the documentation build, ask the AI to produce ASCII relationship charts, entity diagrams, flowcharts, or whatever the page calls for. ASCII diagrams are not pretty, but they're immediate, embeddable, and good enough to communicate structure during early review.

When time permits, upgrade those ASCII renderings to graphical diagrams in Miro or a similar program, built manually or generated through the program's built-in AI features, and then refined. The graphical versions replace the ASCII in the final wiki pages. Both versions still earn their keep: the ASCII often stays in the local Markdown for AI-assisted editing, and the polished version lives in Confluence for human readers.

Phase 4: Ticket creation & linkage

Step 7: Generate a draft ticket list, then refine it

Once the next round of discovery questions is closed out and the wiki pages are finalized, ticket creation begins. Ask the AI to produce a list of ticket titles based on the wiki content. This list is rarely exactly right, for one reason or another. Add to it, remove from it, modify it, until it reflects the work breakdown you actually want.

The AI's contribution here is speed. It reads the wiki content and produces a structured list of ticket titles in seconds, which you can review, refine, and paste into JIRA. The titles are the scaffolding; descriptions and details are added afterward. What would otherwise be a slow manual exercise of translating documentation into a backlog becomes a fast copy-and-refine task.

Step 8: Link tickets to wiki pages and refine the language

Each ticket gets linked in JIRA to the wiki page or pages most relevant to its scope. Because the wiki pages are either deeply technical (table structures, business rules, UX flows) or descriptive enough in plain language, a short summary in the ticket description is usually enough. That summary calls out which specific requirements from the linked wiki(s) the ticket is responsible for implementing.

Refine the summary for clarity. JIRA's Rovo AI handles this well: it tightens the language and improves flow, and the result reads cleanly to a developer encountering the ticket for the first time. Apply the same refinement step to the wiki content during Phase 3, using whichever AI is already in context for that page.

The result is a ticket a developer can pick up and execute against without reverse-engineering the architect's intent. Context lives in the wiki. Specific scope lives in the ticket. The link between them is explicit.

Cautions and practical realities

Trust nothing blindly

This is the single most important rule. Every AI output is a draft. The gap analysis will include irrelevant questions. The ticket list will miss workstreams. The summary will subtly misread requirements. The diagrams will get relationships wrong. Your job is to catch these errors before they propagate; the AI's job is to give you a head start, not a finished product.

Confidentiality is a hard constraint, not a preference

Some client data, IP, and contractual information cannot be sent to AI tools at all. Other data can be sent only to specific approved tools. This isn't negotiable, and it isn't something to reason about case by case in the moment. Read your organization's AI policy before you start a project, not after. The methodology in this paper assumes you're operating inside those guidelines.

Know which AI does what

Not every model suits every task. Synthesis of long, ambiguous discovery transcripts benefits from a high-capability model. Quick language polish on a ticket description does not. Matching the tool to the task improves quality and reduces unnecessary cost. It also avoids over-relying on any single tool, which is good practice for both performance and risk reasons.

Closing thoughts

The promise of AI in architecture work isn't that it replaces the architect's thinking. It's that it removes the friction between thinking and producing. Discovery transcripts get summarized in minutes instead of hours. Gap analysis stops being a blank page. Documentation becomes something you sync rather than something you author from scratch. Tickets are a refinement task instead of a writing task.

The compounding effect matters more than any single time saving. Projects that used to need two weeks of post-discovery synthesis can be dev-ready in days. Documentation that used to rot now stays current because updating it is quick. Developers get tickets with full context because the architect actually had time to write that context down.

None of this happens automatically. The methodology requires discipline. That means recording every call, validating every AI output, keeping the Markdown-to-wiki sync alive, and pruning the AI's mistakes before they reach the team. The discipline is small compared to the alternative, and the architect's expertise compounds rather than burns out under it.

The architect remains the brain. The AI is a faster pen.