Agentic AI Development: From Requirements to a Design Plan

For the example feature, a project team wants to import a vendor sheet and review the extracted prices. The central rule is that an unfinished import must not replace accepted catalog prices. That rule is more useful to a planning agent than a requirement to use a particular queue or framework, because it constrains every candidate design.

Separate known requirements from open questions. The vendor relationship and review step are part of this exercise. Maximum file size, acceptable processing time, and whether projects keep historical prices are decisions still to make. Ask the agent to name those gaps. A generated design that quietly picks answers can become expensive to correct after data has been saved.

Give the agent a narrow inspection task: locate how users are authenticated, how project access is checked, where uploads enter the backend, and how the UI displays failed requests. Ask for the relevant file paths and a short explanation of each boundary. For a new application, use an explicit assumptions list instead of pretending those components already exist.

Keep observation separate from recommendation. An existing background worker is evidence that a job-based design may fit the application. Finding a queue package in a lockfile does not prove that workers are deployed. Repository documents and example files can also be stale. Confirm the actual execution path before letting a tool turn a dependency into an architectural commitment.

For a small, predictable import, a bounded request could parse the input and return a draft directly. That is simple to operate, but the request has a deadline and a disconnected browser needs a recovery story. For variable-duration processing, a persisted job can let the browser return later. That adds job ownership, state transitions, retry handling, and worker operations.

Ask the agent to walk through one interruption for both options: the provider returns an extraction, then the server stops before the browser receives a response. Where is the result? What will a second submission do? A design comparison becomes useful when it explains these consequences, not when it assigns unsupported performance scores to a list of technologies.

A vendor price and a project price are related, but they may have different lifetimes. If a vendor publishes a new sheet, should an existing project immediately use the new values, or retain the revision its team accepted? Either policy can be reasonable. The UI, data model, and update operation all need the same answer.

Record the selected policy in a short decision note with its reason and the condition that would make you revisit it. Include how a draft refers to its source and how an accepted record is identified. These are useful tasks for an agent to organize, but the agent cannot decide a business policy by inventing facts about users.

Walk through an authorized import, a user with no access to the project, a missing currency, a repeated submission, and a review interrupted by a page reload. For each case, state what is stored and what the user sees. The cases should follow the product rules rather than mirror whatever the proposed implementation happens to do.

The planning deliverable should also identify the smallest uncertainty worth prototyping. If the difficult question is whether a supplied sheet can be parsed into rows, investigate that with synthetic data before building a polished dashboard. If the difficulty is permission inheritance, exercise that boundary first. A focused experiment can eliminate a much larger speculative build.

A useful first slice might create and retrieve a draft through the existing authentication and project-access path, using a fake extractor with deterministic rows. That lets the team check the contract and review screen before making provider calls. A second slice can integrate extraction behind the same boundary, followed by failure handling and operational limits.

An agentic coding tool may choose files and commands while investigating, but its authority should still match the task. A planning assignment does not require production credentials, real vendor documents, or permission to deploy. Review generated plans and code independently; a fluent explanation and a passing generated check can share the same mistaken assumption.

After implementation, record actual processing time, failed imports, retry behavior, and review corrections. Those observations can justify a worker, a different parser, or a clearer review screen. An architecture decision should have a reason to change; the presence of AI in the feature is not itself a reason to introduce autonomous orchestration.

The useful outcome of AI-assisted planning is a design another engineer can explain and challenge. Keep the decision note close to the feature, update it when the assumptions change, and use it as context for the next bounded coding task.