AI is genuinely useful for software development. It generates boilerplate quickly, helps write tests, suggests implementations, and takes a lot of mechanical work off the table. A good developer using AI tools can move significantly faster than one who isn’t.
At Logicc, we use those tools throughout our work. But we treat them the way you’d treat a fast, capable junior with great output and no accountability for the outcome: everything the AI produces gets reviewed by someone who can tell the difference between code that looks correct and code that will actually work in a live supply chain environment.
That distinction matters more here than almost anywhere else in software development.
Why supply chain makes this harder
Supply chain is an industry built on exceptions. Carrier APIs that behave differently from their own documentation. Customs rules with carve-outs that apply only to specific commodity codes, certain routes, or shipments above a particular value. Warehouse systems that handle 99% of cases correctly and fail in a very specific way on a Monday morning when a particular combination of order types hits the pick queue.
These aren’t hypothetical scenarios. They’re the kind of thing that gets discovered in production, usually at the worst possible time, because no specification document captured them and no AI encountered them in training. They exist because real supply chain operations have been accumulating exceptions and workarounds for decades, and the rules governing them often live in experienced people’s heads rather than in any formal record.
An AI generates code based on patterns in its training data. It doesn’t know about the carrier that sends malformed tracking responses on bank holidays, the customs authority that requires a specific field format that differs from the standard, or the client whose warehouse system uses a non-standard interpretation of a palletisation code. A developer who has worked in this space for twenty years does know these things — or knows enough to ask the right questions and recognise when something doesn’t look right.
What “experienced engineer” actually means
When people talk about industry experience, they usually mean time served. The more useful definition is: exposure to failure.
An experienced supply chain software developer has seen systems go down before a critical shipment. They’ve debugged integrations with carrier APIs at 2am. They’ve watched a well-intentioned change to an order routing algorithm cause a week of delivery exceptions because of a combination of conditions no one anticipated. They’ve had conversations with operations teams trying to explain, in plain terms, why the software is doing something the software thinks is correct but that creates a serious problem in the physical world.
That accumulated experience shapes how they approach problems — not just technically, but in terms of what questions to ask, where to look for risk, and how to tell a client that what they’ve asked for will work in theory but cause problems in practice.
AI doesn’t have that. It can produce something that resembles the surface of it. But it has no actual experience of consequence. When it gets something wrong, nothing breaks. When an engineer working on a live supply chain system gets something wrong, freight doesn’t move, customers don’t get their orders, and someone has to fix it under pressure.
How we run it in practice
We use AI throughout our development work and it makes us faster – faster at generating code, at writing documentation, at building and running tests. That’s genuinely valuable, and it means we can deliver more for a given budget than we could a few years ago.
But we use it as a tool, not as a substitute for engineering judgement. The decisions about architecture, about where the risk lies in a system, about how software should behave in circumstances the happy path doesn’t cover? Those are made by engineers who have been working in this domain long enough to know what the happy path misses.
We also don’t treat AI output as finished work. Code generated by an AI gets reviewed by a developer who knows the difference between code that compiles and code that holds up in a live supply chain environment. Tests get checked against the actual edge cases the system needs to handle, not just the obvious ones. The AI does a lot of the mechanical work, but a person with relevant experience is responsible for the output.
What to ask development partners
If you’re evaluating development partners and someone tells you they use AI and it means they can build things faster, that’s probably true. If they tell you it means they no longer need experienced supply chain developers, that’s not true, and it’s worth pushing on.
The value of twenty years in supply chain software isn’t in writing code. It’s in knowing what the code needs to do, what it might encounter in the real world, and what to do when it encounters something it wasn’t designed for. AI makes experienced engineers more productive. It doesn’t replace what makes them experienced.