AI coding tools are genuinely changing how fast product teams can work. Prototyping is faster and interfaces can be generated in hours rather than days, so the barrier to producing something that looks and behaves like a real product has fallen dramatically. But in connected products, the software was rarely the hard part. The hard part is actually everything the software has to connect to.
I spent several years building and scaling Plugsurfing, a pan-European EV charging network connecting thousands of charge point operators with automotive manufacturers, fleets and drivers. The technical complexity of that system was significant. But many of the failures that actually mattered, the ones that broke the customer experience and cost us the most time to fix, did not live inside the codebase but in the connections between systems.
Where the complexity actually sits
Take invoice reconciliation. As an EV network aggregator, Plugsurfing authorises charging sessions and then pays the charge point operator for each session processed. On paper, straightforward. In practice, the invoiced price frequently did not match the price used to clear the transaction and it was not always clear which tariff was correct.
The hard work was not writing the code but in deciding which data source to trust, enforcing consistency across different operator systems, building reporting to catch problems early and handling them automatically where possible. The complexity was in the connectivity between interdependent systems that could each have their own version of the truth. AI can help write that code faster but it cannot tell you which data source to trust.
Standards do not automatically create reliability
Much of the EV industry runs on a protocol called Open Charge Point Interface, OCPI. Its existence is one of the main reasons EV charging has achieved the level of interoperability it has today. But even excellent standards do not make everything interoperable.
How a standard is interpreted varies and how it’s implemented varies furthermore. Some backends implement it only partially while some aspects are genuinely open to interpretation. At scale, that creates significant interoperability challenges.
So when an EV driver plugs in to charge, a long chain of handoffs has to succeed: the vehicle and charger handshake, the charger connects to its management system, which connects to the driver’s mobility provider for authorisation and the payment method has to work. Every handoff is a potential failure point but the driver does not care about any of this as they just want to charge. The product’s job is to hide that orchestration completely. A protocol can standardise the connection but that alone does not create a reliable experience.
Data quality is not optional
Location data is another example. Finding a place to charge an EV is more complex than finding a petrol station. Drivers need charger speed, connector type, physical location, whether there is parking, whether it is covered and whether it is lit at night. Charging takes longer than refuelling, so surrounding context matters in a way it simply does not for fuel.
I saw the same principle earlier in my career at Nokia, where I was part of the team building the Nokia Maps app. The quality of the map data makes or breaks the usefulness of the map. Bad data breaks trust immediately and in IoT products, data quality means not just accuracy but completeness and both are necessary for the product to work. Fundamentally, AI can process poor data faster but it cannot make poor data good.
What falls hardest on the product team
When the cost of writing software goes down, the bottleneck shifts earlier: to knowing what to build, to understanding which customer problems actually matter and to validating assumptions in the real environment rather than in a prototype.
New EV drivers arriving at a charge point are often confused by why their car is not charging at 150kW even though they are connected to a 150kW charger. Explaining battery charging curves without a chemistry lesson is a product design challenge, so the product has to absorb that complexity and make the experience understandable without requiring the user to become an expert.
That kind of user understanding does not come from faster code generation but from watching real users use the product in the real environment and designing around what you see.
What I would tell a product team building connected products today
Do not use faster AI tooling as an excuse to build more features. Invest the time you save in understanding the customer more deeply, validate your assumptions in the environment where the product will actually run and focus on reliability and interoperability before adding capability. Success lies in a combination of fast building and deep customer understanding. Fundamentally, AI can make building easier, but customer insight and product judgement still determine whether what you build is worth using.
There’s plenty of other editorial on our sister site, Electronic Specifier! Or you can always join in the conversation by commenting below or visiting our LinkedIn page
