1. Start from the process, not the tool
I choose an activity that I know well and repeat. Inputs must be sufficiently stable, rules explainable and the result controllable. I do not start with the most complex process; I start with one that can be compared with an already reliable working paper or historical output.
- It recurs monthly, quarterly or annually.
- The data have a recognisable structure or can be normalised.
- Ordinary rules and the main exceptions can be written down.
- There are reconciliations or historical results against which the output can be verified.
2. Assign a role to each environment
There is no need to know every model. What matters is separating design, development, memory and control. One environment can help structure the process and brief; another can write the code; a knowledge base preserves sources, mapping, decisions and tests; a fresh chat performs the review.
3. Teach the process before asking for code
The first request should not be “write the program”. I first describe the objective, provide real inputs, explain columns, signs and rows to ignore, write rules and exceptions and define outputs and controls. I then ask the model to return a complete brief and identify what remains unclear.
- If an essential datum is missing, the tool must stop and report it.
- Professional decisions must not remain implicit in the prompt.
- The brief is approved before development begins.
4. Define tests before the prototype
An application is not correct merely because it produces a number. Before development, I prepare cases and expected results. After development, I deliberately try to make it fail. PASS or FAIL criteria are defined in advance so that they are not adapted to the result obtained.
- Ordinary case with a manually verified result.
- Edge case with reversed signs, new accounts or zero balances.
- Invalid input: missing columns, wrong format or inconsistent data.
- Comparison with the expected result prepared before the prototype.
5. Develop in small releases
The first version should do a limited number of things and make them verifiable. One function at a time, real data and a changelog. Complexity is added only when the previous version is stable and regression tests continue to pass.
6. Separate production from review
The same chat that built the tool should not certify it. I open a new conversation and provide the code, brief and testing matrix, but not the development history. I ask it to search for errors, unsupported assumptions and unhandled cases, returning PASS or FAIL, rationale, evidence and correction for each control.
7. Release with limitations, manual and memory
Release does not coincide with the end of coding. It requires a user manual, a changelog, a description of accepted inputs, the controls performed, open assumptions and the tool's limitations. The professional must understand not only how to use it, but also when not to use it.