AI does not only make development faster, it moves the capability out into the whole organisation. Suddenly anyone can build and change things in the systems. It is enormously powerful, but combined with old ways of working it leads to either chaos or no effect at all. Here is how you lead the shift from tree-tender to forest ranger before entropy runs away from you.
The first thing that happens when AI really lands in an e-commerce organisation is not that development goes faster, it is that development moves out of IT. Anyone can turn anything into chaos, isn't it wonderful?
Suddenly the head of e-commerce is sitting there putting together their own retail media app to sell ad space to their suppliers. The product owner asks the AI to explain how the stock integration works and gets an answer in a second (hopefully not hallucinated), without going via the developers. The head of marketing whips up a small tool that pulls out customer data to follow up the effect of influencer collaborations, hopefully no one does a GDPR review. The ability to change the systems has left the development organisation and spread across the whole business, for better and worse.
It is enormously powerful, but that is also where the chaos begins. So how do you handle this?
I strongly believe one thing: companies will find it hard to use this technology without everyone tripping over each other in different ways. Not because AI tech is bad, but because most people try to run it with exactly the same way of working as before, and then one of two things happens. Either it becomes chaos, or the noticeable difference in output fails to appear at all, despite everyone doing much more. Why do I think that?
Giving a team powerful tools and keeping the old routines is like swapping all the cars for rockets but keeping the same traffic rules and the same roads. It goes fast, until the first intersection. Growing companies already move fast, corners are cut everywhere, and today they already solve a lot of problems with manual shortcuts and spreadsheets, but now they can do it on steroids.
Imagine an integration to the ERP being changed without anyone owning or reviewing it, and orders start quietly falling between the cracks, or come into your ERP with slightly wrong data now and then. That a smart filter on a campaign page is built that works fine in test but dies on Black Friday under full load (poor test that did not load-test, do it). That two people in different teams solve shipping cost at the same time in their own way and both push, so that suddenly there is contradictory logic in the system and no one knows which one applies. That is what can happen when powerful tools meet unchanged ways of working, or if your way of working does not match when the business comes storming into the code base. I can with 100% certainty say that it does not, no organisation has prepared for how this should work because it is entirely new.
The last kind of collision, two people building the same thing at the same time, is the key to understanding the whole shift that is happening. Before, that kind of collision solved itself almost automatically. Not because we were better at communicating, but because there was a built-in slowness in production speed. It took time to build things, and during that time people had time to talk, and those who built sat on the same team and actually talked with each other (unless they had a flame war about Amiga vs Commodore 64) at a stand-up or a "new tickets" sync meeting. The slowness synced the team for free.
AI removes the slowness and multiplies who acts outside the team, and that free synchronisation we have all leaned on without even knowing it disappears. What used to happen by itself now has to happen consciously. You have to chase not just the developers but the whole organisation (and be a bit more restrictive with GitHub access before you have set the processes).
You can think of it like this:
We in IT are all used to taking care of a single tree. We inspect every leaf, we tend to the bark, we know our tree. That has been the whole job.
The future is that we have to manage an entire forest. The whole massive landscape of AI-built systems and code bases, and you cannot possibly inspect every leaf in a forest. If you try, you go under.
But sometimes you still have to go down and look at a single leaf. Not for the leaf's sake, but because a sick leaf can be the symptom of something systemic, a fungus or an infestation, that threatens the whole forest. You look at the leaf to understand the pattern. Then you act broadly, at the forest level, not leaf by leaf (OK, sometimes you have to get down and polish a single needle).
The systems developer role and the whole of IT have to shift their focus from code focus to systems focus. From building every tree to reading the forest, seeing the patterns and catching the systemic symptoms before they spread. It is of course not 100%, but it is a system shift in how you see your role. Let the business actually help build the systems that provide value, from the people who know what provides value, and let IT focus on making sure the forest survives.
This is hard and complex. But it is entirely possible to handle with the right support and a little thinking. It is about finding how you organise yourselves, set policies and stitch together a structure where everyone can change and adjust. The power is enormous. But it is just as much a question of handling the entropy that follows. There is no silver bullet, you always just swap problems however you turn it.
The spec is more important than ever. Yes, you will keep iterating, but iterate on the right things. It sounds counterintuitive, almost like we are reintroducing old requirements documents and waterfall, but it is the opposite. Execution is now the cheap part. Building something takes almost no time at all (if you have a lot of tokens and do not run into all these limits). Then the thinking itself becomes the expensive and valuable part, and the spec is where the thinking happens. It is also at the spec stage you discover the overlap, before two people have started executing on the same thing. The demand for a light, shared spec is infinitely cheaper than cleaning up the chaos afterwards. Now everyone who has made it this far is thinking "but oooh I just want to start prompting", but I say no. Think first, communicate first.
The next thing is that someone has to own the path to production. Everyone should be allowed to build and experiment, that is the whole point, and we should not choke that. But experimenting must not be the same thing as pushing to production. The boundary is not at who is allowed to build, it is at how and what reaches production, and who owns that decision. Somewhere a QA Manager is cheering right now for what I am about to write: testing becomes very important.
Communication becomes a trained discipline. Because slowness no longer syncs the team for us, we cannot hope people will find time to talk. Communication has to become something we consciously build in and train, not something we rely on to happen by itself. The role moves from leaf to forest, and those who used to build everything become the ones who guard the whole, set the patterns and read the systemic symptoms.
This should not be read as a warning list, because the upside is gigantic. Practically necessary in the future. It will be such an insane advantage to have a business that can on demand adjust the system to fit reality.
When it works you can accelerate all your development. You can take advantage of the knowledge that actually exists in the business, in the people who work in the systems every day. The organisation distils the specifications directly from those who know, without first sending them through developers to interpret and understand. You cut steps in the whisper game. What used to get watered down along the way now comes through sharp and direct. That is what is at stake. Not avoiding chaos, but freeing that power without drowning in it.
This shift will happen whether you lead it or not. The tools are already on your colleagues' screens. The question is not whether the ability moves out into the business, it already does.
The question is whether you build a forest or a rubbish dump.
The organisations that learn to lead this, that treat the spec as thinking, own the path to production and train their communication, will run away from everyone else. Those who let it happen by itself will end up sitting with a growing pile of undocumented systems no one dares touch, and a business standing still in the middle of all its new pace.
It is hard and complex. But it is entirely possible to handle with the right support, and it is exactly that work that will decide which e-commerce operators win in the coming years.
Related articles
AI makes it possible to produce code faster than ever, but more code does not automatically mean more value. What AI really does is amplify the skill and judgement already present in the person or team using it. That makes the ability to understand the problem, spot risks and know what not to build more important than ever.
Technical debt is more than a technical concept, it is a business-critical reality that affects everything from time-to-market to customer experience. In e-commerce, where every millisecond and every click counts, the choices you make in your technical platform can have far-reaching consequences. When quick fixes are prioritised over long-term durability, an invisible but growing debt is built up. It affects not only development speed and stability, but at worst can slow the company's ability to innovate and compete. To face the future the right way, technical debt has to be understood, quantified and managed as the strategic investment it actually is.
For Swedish retailers there are plenty of ways to meet this threat by building on what the Chinese giants cannot offer: strong local brand stories, product safety and sustainability as competitive advantages, and a presence that ties digital and physical commerce together. Temu has no stores. Yet.
