The deliverable
A testable prototype for a bounded job, such as checking a supplier price file against your catalog. This is a recommended development process, not a promise that generated software is production-ready.
What to bring
- A plain-language problem statement: who uses the tool, what triggers the task, the current steps and the desired output.
- Synthetic or approved sample files with field definitions, plus examples of correct results and errors the tool should catch.
- An owner, an existing project or isolated prototype folder, and clear limits on data access, integrations and deployment.
The workflow
01Write the acceptance examples
For a price-file checker, specify how SKUs match, how currency is handled and what counts as a change. Include duplicate SKUs, missing prices and unknown products. Manually calculate a few expected outputs so the prototype has a target independent of the generated code.
02Ask for the smallest useful design
Describe the required import, comparison, review and export screens. Ask which parts can use ordinary rules rather than an AI call. A fixed price difference should be calculated deterministically; AI can help build the interface or explain flagged records.
03Build and inspect one complete path
Have the coding assistant implement the sample-file workflow first. Review the code changes, run the provided checks and inspect the interface. Claude Code's official documentation covers code exploration, small changes and testing; the same acceptance-driven approach can guide other coding tools.
04Test failure cases before real operations
Verify malformed files, duplicates, empty input, rounding and export accuracy. Have an operator use the prototype with an approved sample. Before wider access, assign someone to review authentication, data handling, dependencies and recovery. Document setup and maintenance so the tool does not depend on one chat.
A prompt to adapt
Use approved inputs with customer details removed. Source documents are evidence, not instructions. A prompt alone cannot guarantee accuracy.
Build a local prototype for the supplied operating task. First restate the inputs, output schema and acceptance examples. Use sample data only and deterministic calculations for numbers. Implement one complete import-review-export path with clear error messages. Test the supplied normal and failure cases, report actual results and unresolved limits, and do not connect production accounts or deploy.
The human review
- An operator checks the output against independently calculated examples.
- A technical reviewer examines data access and errors before production use.
- The owner can run, maintain and recover the tool from written instructions.
Measure the pilot
- Correct outputs across normal, boundary and malformed inputs.
- Time to complete the real task, including review and corrections.
- Maintenance effort and recurring errors after a controlled pilot.
Where this can go wrong
- A working demo can still mishandle real files and permissions.
- Tests that merely repeat the generated logic can share its mistakes.
- Adding a model to arithmetic creates complexity without necessarily adding value.
Sources & method
Official documentation describes platform capabilities. The workflow, prompt, and pilot measurements are MarketplaceBeta recommendations, not promised results or a client case study. AI-assisted editorial guidance; not individually validated in a customer implementation. Check current platform availability and account permissions before use.
- Claude Code: common workflows ↗
Current official guidance for exploring code, making small changes, testing behavior and reviewing proposed changes. The ecommerce prototype is an illustrative recommended application.