I spent years on the planning and operations side of supply chain, including as a supply chain manager on the Pratt & Whitney F100 engine program. Today, through my company Statadventure, I build supply chain software in Python and SQL, and I use AI tools every day to do it. This post explains how I work, where AI helps, and where I keep a human firmly in charge.
The tools, and what I use each for
I use several assistants because each has strengths, and because a second opinion catches mistakes.
- Cursor is my editor. It keeps the AI inside the codebase, so suggestions can see the files, functions and tests I’m working with.
- Claude and ChatGPT are where I think through design: data models, edge cases, and how a planning rule should behave before any code exists.
- Grok and Gemini are my cross-checks. When an answer matters, I ask a different model to review it or explain it back to me.
None of them replaces knowing the domain. An assistant can write a reorder-point function in seconds. It can’t tell you whether your lead times are measured from purchase order release or from supplier ship date. That knowledge comes from planners, buyers and the shop floor.
My workflow, step by step
- Write the business rule in plain English first. For example: “Reorder when on-hand plus on-order falls below average daily demand times lead time plus safety stock.” If I can’t state it clearly, the AI can’t build it correctly.
- Define inputs and outputs. I list the tables, columns, units and grain (item, location, day). Most supply chain bugs are unit or grain mistakes, not syntax errors.
- Generate small pieces. I ask for one function, one query or one test at a time, never a whole application in a single prompt.
- Read every line. I review generated code the way I’d review a junior analyst’s spreadsheet: line by line, with the formula in front of me.
- Test against numbers I calculated by hand. More on that below.
- Commit in small steps with version control, so any change can be traced and reversed.
Prompt patterns that work
A few patterns consistently give me better results:
- Role and context: “You are helping build an inventory planning tool in Python 3 with pandas. Demand is daily, by SKU and location.”
- Constraints: “Use only the standard library and pandas. No hard-coded file paths. Handle zero and missing demand.”
- Examples: I paste a tiny, made-up sample of input rows and the exact output I expect.
- Explain before coding: “Describe your approach and assumptions first; then write the code.” This surfaces wrong assumptions early.
- Review mode: “Review this SQL for join fan-out, NULL handling and date-boundary errors.” Asking for a critique is often more valuable than asking for code.
Testing and validation
AI-generated code can look right and still be wrong. My rule is simple: no output reaches a decision-maker until it matches a known answer.
- I build small worked examples by hand, such as a safety stock calculation with a known result, and turn them into automated tests.
- I check edge cases planners actually hit: new items with no history, items with long gaps between orders, negative on-hand from timing issues, and unit-of-measure conversions.
- I reconcile totals. If a report says total inventory value is one number, it should tie back to the source system within a known tolerance.
- For SQL, I check row counts before and after every join. A duplicated row in a join quietly inflates demand.
Guardrails and data security
Supply chain data is sensitive. Supplier pricing, part numbers and customer demand often belong to a client and may be covered by contracts or export-control rules. My guardrails:
- No confidential data in prompts. I describe structure with synthetic or anonymized samples instead of pasting real records.
- Follow the client’s policy first. If an organization restricts AI tools, that’s the rule. Where tools are approved, I review each tool’s data-use and retention settings.
- Secrets stay out of code. Credentials go in environment variables or a secrets manager, never in a prompt or a repository.
- Humans own decisions. The software recommends; planners and managers decide.
For a structured way to think about AI risk, the NIST AI Risk Management Framework is a solid, vendor-neutral starting point.
Why this matters for manufacturers
Many planning teams still run critical decisions out of spreadsheets that one person understands. AI-assisted development lowers the cost of turning those spreadsheets into tested, documented, repeatable tools. The value isn’t in the AI itself. It’s in pairing it with someone who understands both the code and the supply chain, and who insists on checking the math.
If you want the formulas and definitions behind this kind of work, I keep them in my Knowledge Base. The pandas documentation and the statsmodels time-series documentation are also excellent references.
Peter Klausz is an MBA, the founder of Statadventure, LLC, and a former Pratt & Whitney F100 supply chain manager. He builds supply chain software in Python and SQL with AI-assisted development and is open to contracting and new roles. Get in touch.