1. Start with an observable business change
Describe what a user should be able to do differently before asking an AI tool to produce code. Identify the record, permitted actor, state change and conditions that should stop the operation. TROIA provides the development environment behind canias ERP; knowing that environment does not tell a tool what your business intends. An approval change, for example, includes rejection, resubmission and attempts by unauthorised users. Writing those behaviours down gives developers and reviewers a common test of whether the change works, beyond whether it compiles.
- Express the requirement as a user action and an observable result.
- List the modules and behaviours that the change must leave alone.
2. Prepare the smallest useful context
More context is not automatically better context. Start with approved field definitions, a relevant code fragment and a fictional record that demonstrates the problem. Decide which information may reach which service before using it. Remove credentials, personal records and commercially sensitive details from examples. If the installation version or an extension is unknown, mark it as unknown. Ask the tool to identify missing information instead of filling gaps with plausible names. This makes unsupported assumptions easier to spot and keeps the review focused on the actual change.
- Check the source, version and permitted use of each input.
- Exclude unnecessary fields and substitute fictional values for real records.
3. Ask for a change that can be reviewed
Hakan built a purpose-made AI tool to help with canias module development at a manufacturing company. That is a concrete use of AI around a development task, rather than a claim that generated code is automatically production-ready. Keep each requested change narrow enough for a reviewer to understand. Ask for the proposed edit, affected behaviour, assumptions and reasoning together. Separate unrelated rewrites from necessary work. A smaller change makes it easier to see whether the tool has answered the requirement or merely produced something that looks technically convincing.
- Keep one business behaviour at the centre of each proposal.
- Turn unverified table, class and method names into explicit review questions.
4. Review consequences as well as syntax
Human review has to cover more than syntax. Examine permissions, document states, dependencies and the integrity of the resulting records. NIST's AI-assisted development reference work similarly places generated outputs within review, testing and accountable approval. Ask what happens if an operation stops midway, whether a blocked user gets a useful explanation and how the change behaves when two people work on the same record. These questions connect code to operations. A proposal that cannot answer them still needs investigation, even when its structure looks polished.
- Review actions that should be refused as carefully as the normal path.
- Record the review decision and unresolved questions with the change.
5. Test the requirement independently
Tests copied from the generated implementation can repeat its assumptions. Agree acceptance examples with the process owner first, including missing values, unauthorised access, repeated submissions and corrections to existing records where relevant. Check both the visible response and the resulting stored state. Note meaningful differences between the test environment and intended use. A test count alone says little about the decision to release. The useful evidence is which behaviours were exercised, what happened and which uncertainties still require judgement.
6. Keep ownership after the code is accepted
Prepare release instructions, a recovery route and checks for initial use. Make it clear who can decide to stop the rollout and what evidence they will need. AI can assist the work, but ownership of the business rule, code review and release decision must remain explicit. The goal is a useful change that the team can maintain. Jay is a separate product initiative still in development; the purpose-built tool described here should not be mistaken for Jay or for a generally available canias connector.
