AI development: from request to verified release
Organize investigation, changes, review and release around evidence. A bug example shows what each stage of AI-assisted work should produce.
A user reports that the on-screen report shows one period while the exported file contains another. An AI assistant can help locate the mismatch and prepare a fix. The work is complete only when someone can reproduce the case, inspect the change and observe the correct export in the intended environment.
This hypothetical example places AI within the development lifecycle without confusing code generation with delivery.
Make the request verifiable
Record the screen, filters, action sequence, current result and expected behavior. Explain who is affected and provide a reproducible example without sensitive data. “Fix the export” leaves too many decisions open.
Ask the assistant to trace the information: filter state, API request, query and file generation. A diagnosis should identify where behavior diverges, not merely list files containing the word report.
Expose the failure before fixing it
Reproduce the issue or write a case that fails under the current implementation. If the environment prevents this, record the limitation and missing observation. A plausible hypothesis is not a confirmed cause.
In the example, investigation might suggest that the browser filters the table while export calls a route without the date range. That is a hypothesis to check against code and actual output before deciding the change.
Limit the change to the necessary behavior
Use a branch or working copy that preserves others’ changes. Explain project conventions and scope. Fixing a filter does not require replacing the table component, date library and permission structure at the same time.
Request a description of the change and verified cases, then read the diff. If the solution adds an abstraction, ask which concrete repetition or constraint it addresses.
Review through different paths
A test that mirrors the new implementation can pass alongside its bug. Use expected behavior as the reference and check variations: empty period, date boundaries, ordering, no records and an unauthorized user.
OWASP’s AI-assisted coding guidance emphasizes review and independently written tests for critical controls. Authorization comes from product rules, not generated suggestions.
For an interface, follow the browser flow. For persisted data, verify a later read. A passing build confirms that technical step; it does not establish that the user completed the task.
Release with something specific to check
Record the version, changes, required configuration and route back to the previous state. Confirm authority for external actions and apply only reviewed work. After release, repeat the scenario with suitable data and watch for failures absent locally.
Document prepared, tested and published work separately. If a step depends on missing access or a team decision, state the precise gap: which scenario remains unchecked and who needs to act.
The model evaluation guide helps measure the tool’s contribution. For access and execution, see agent automation and responsibilities. Benefits should appear in completed, reviewed work rather than the volume of generated code.
About the author
Tiago F SantiagoComments
No comments yet
Share a question or an experience related to the article.
Related articles
