That’s when the token math broke.

The decision nobody questioned

Early on, we had a choice: dynamic SQL generation or intent classification with predefined queries.

Dynamic felt right. Natural language in, SQL out. The model reads the schema, figures out which tables to use, generates the query. Flexible. Works for any question. Demo-friendly.

But here’s what dynamic means in production: every request sends the entire database schema as context. For our ecommerce platform that was thousands of tokens. Per request. Per store.

One store asking “show me yesterday’s sales” cost roughly 3–4k tokens per request.. Fifty stores asking variations of that question all day and you do the math.

Nobody did the math during the PoC.

What production actually looks like

The pilot ran on one store. Token costs looked manageable. Call it $50/month of API usage. Seemed reasonable for the value.

Then we scaled to five stores for testing. Token bill jumped to $280. Not linear - stores ask similar questions but phrased differently, so no caching benefit and data varies for each store. Each query regenerates SQL from scratch.

Extrapolate to 50 stores and suddenly you’re looking at $2,000+/month in token costs just for a briefing agent. For a small retail chain, that ROI conversation gets uncomfortable fast.

Is a daily sales briefing worth $40/store/month in tokens alone? Before you factor in infrastructure, maintenance, updates?

The question never came up in the PoC because we optimized for “does it work” not “does it scale.”

The architecture decision that locked in the cost

Here’s the thing nobody documented: we chose dynamic SQL because it was easier to demo. Handles edge cases. Looks intelligent. But that choice locked in a token cost structure.

The alternative — intent classification + predefined queries — would have cost 90% less in tokens. Classify the question type (sales summary, inventory check, discount analysis), route to a parameterized query, done. Schema context sent once during setup, not every request.

But it’s less flexible. Handles the 80% case, not the long tail. In a demo that feels limiting. In production it’s the difference between viable and unsustainable.

We made that call in week two of the PoC. Six months later, the production team inherited the architecture without understanding the token economics that shaped it.

What we’re seeing now in the team

We run a practice group where people build AI workflows. Some are experienced, they instinctively limit context, reuse embeddings, batch requests. Others learn by hitting token limits mid-sprint.

Same pattern: build something that works, use it for a week, wake up to “my tokens expired.”

There’s no governance layer tracking this. No rule engine capping request size or flagging expensive patterns before they hit production. The tooling exists — request limits, token budgets, usage dashboards — but applying it requires someone to own the decision.

In a PoC, nobody owns it. In production, it becomes a cost problem before it becomes anyone’s responsibility.

Domain knowledge shapes token costs

Here’s something that doesn’t show up in AI optimization guides: understanding the business determines what you send to the model.

We had AI developers on the team. Strong technical skills, knew the models well. But without retail domain background, they couldn’t assess criticality. Every field looked potentially relevant. Better to include it than risk missing context.

So the schema context ballooned. Product tables, pricing history, customer segments, promotional calendars, store-level inventory — all sent with every request because “the model might need it.”

Someone with retail experience would have known: for a daily sales briefing, you need transaction totals and category breakdowns. You don’t need individual SKU attributes or historical pricing rules. That’s 80% less context for the same answer.

Field names don’t tell you business priority. discount_tier sounds important. In practice, for a morning briefing query, it’s noise. But you only know that if you’ve actually run a retail operation.

Domain knowledge isn’t just about building the right feature. It’s about knowing what to leave out. And in a token-priced world, what you leave out is half the optimization.

Lessons, not tips

This isn’t about which model is cheaper or how to write better prompts.

The lesson is: architecture decisions made for demo flexibility become cost commitments in production. And if the reasoning behind those decisions doesn’t transfer to the team that inherits the system, they can’t optimize what they don’t understand.

Ask during the PoC:

• What’s the token cost per request × expected request volume × number of locations?

• Are we optimizing for demo or for scale?

• Who decided this architecture and what were the trade-offs?

Document it.

Because six months from now, when someone asks why the token bill is 10× the estimate, “it worked in the demo” won’t be enough.

Production doesn’t inherit the demo. It inherits the decisions nobody documented.

The demo worked. The retail store briefing agent understood natural language queries. Store managers could ask about yesterday's wastage, discount performance, today's plan - and get structured answers across four stores. Looked real.

The architect reviewed it and asked good questions. The code structure was reasonable. The documentation I generated explained the schema clearly — tables, columns, relationships. It was not a throwaway prototype. It was a working system built through careful iteration, domain knowledge baked into every prompt, and multiple refinements until the outputs felt right.

Then the real question arrived.

How do we make this production ready?

What the Code Believed (vs. What Production Needs)

The agent worked because I told it what to believe during the build.

For perishable items — bread, milk, fresh produce — I had encoded logic that made intuitive sense: as the day progresses and stock remains, increase the discount to move product. Cap it at 60%. The agent followed this faithfully and the demo outputs looked realistic.

But in a real retail system that logic is not a rule. It is a starting point. There are supplier agreements that restrict how low a price can go. There are store manager overrides when a promotion is already running. There are category-specific behaviours — bread on Thursday behaves differently from bread on Saturday in a store near a market. There is a provision to override the discount ceiling entirely when circumstances require it.

None of that existed in the code. The agent had an assumption. Production needs a parameter, a configuration layer, a connection to actual pricing rules, and a human override mechanism.

The same problem appeared in loyalty segmentation.

I had built four loyalty tiers as a dictionary — a clean, logical structure that worked perfectly in the demo. Online customers were identified by email or mobile. POS customers swiped a card or provided a loyalty number. The agent applied discount multipliers based on tier.

But real loyalty in retail is messier. The same customer might exist in the online system under their email and in the POS system under a card number that was never linked. The tiers I defined were conceptually sound but operationally disconnected from how loyalty data actually flows across channels. The dictionary was not wrong. It was a simulation of loyalty, not a connection to it.

When the team looked at the code they found columns and fields that existed purely to generate randomness for the demo. Category-wise discount percentages hardcoded as defaults. Start and end date assumptions that made sense for a PoC running in a single session but would break in a system running across real days with real data.

The CLAUDE.md problem

The architect asked about the CLAUDE.md file.

For anyone who has not encountered it — this is the file that tells Claude Code what the project is, what decisions have been made, what rules to follow, and what context to carry across sessions. It is the memory of the build. Without it every new session starts without the reasoning behind the code.

I had not created one.

Everything that shaped the agent — the decisions about how to handle perishable items, the loyalty tier logic, the reasoning behind the schema structure, the specific retail context I had brought to every prompt — lived inside a single chat session. When the session ended the reasoning ended with it. What remained was the code, a schema document, and the demo.

The team could see what the code did. They could not see why it was built that way. The CLAUDE.md file would have captured that. Without it the handover was a transfer of outputs without a transfer of intent.

This is not a vibe coding failure. It is a documentation gap specific to how AI-assisted development works. The code is generated fast. The reasoning that produced it evaporates unless someone deliberately captures it. In traditional development that reasoning lives in PRs, commit messages, architecture decision records, and the conversations that happen during code review. In a vibe coding session it lives in the prompts — and prompts are not automatically preserved anywhere.

The Gap Every Enterprise Will Face

This is where the story gets broader than one PoC.

Enterprise teams are building with vibe coding in two distinct situations. Some have Copilot licences and work within an integrated development environment where context can be maintained and teams can collaborate around the AI. Many others — and this is more common than the tooling conversations suggest — are building through prompt sessions, often without licences, often on personal accounts, often in a single extended conversation that produces something good and then closes.

The PoC gets built. It works. The demo is strong. And then the organisation asks the question it always asks: how do we take this to production?

At that point the real requirements appear. Code review against actual standards. Security audit — not just environment variables but the logic itself, the assumptions, the edge cases the prompt never surfaced. NFR assessment — can this handle real POS load across four stores simultaneously? What happens when the inventory feed is stale? What happens when a store manager’s query hits a category the agent was never trained on?

And underneath all of it the question the architect was really asking: where is the reasoning? Not the code. The reasoning.

What production-ready actually means for AI-assisted code

The vibe coding session produced something genuinely good. The domain knowledge I brought to the prompts meant the outputs were grounded in real retail understanding. The perishable discount logic made sense. The loyalty tier structure was logical. The briefing format was useful.

But production-ready is a different standard from demo-ready. Not just technically — organisationally.

Production-ready means a developer who did not build this can understand why it was built this way. It means a store manager can override the discount ceiling without calling a developer. It means the loyalty segmentation connects to actual customer data rather than a dictionary that approximates it. It means the randomness that made the demo look realistic has been replaced by real data feeds or configurable parameters.

And it means the CLAUDE.md file — or its equivalent — exists. The document that says: here is what this system is responsible for, here is the domain context it operates in, here is what the agent should never assume, here are the constraints that must hold when reality does not match the template.

That file is more important than the code. You can regenerate code from a well-written context document. You cannot regenerate the reasoning from the code alone.

The pattern every enterprise will face

The store briefing agent is not unusual. Across retail, logistics, finance, and operations, teams are building AI PoCs through vibe coding sessions — some with enterprise tooling, many without — and producing things that genuinely work. The barrier to a working demo has collapsed.

The barrier to production has not.

It has just moved. From “can we build this” to “can we hand this over, maintain this, extend this, and trust this when something breaks at 2am on a Saturday.”

The PoC that took hours to build will take weeks to productionise — not because the code was bad but because the reasoning was never captured, the assumptions were never validated against real data, and the domain knowledge that made it work lived in one person’s head and one chat session that is now closed.

The demo is the easy part.

The CLAUDE.md file is where the real work begins.

The barrier to demo has collapsed. The barrier to production hasn't - it's just moved.

Have you hit this wall — a working PoC that stalled on the way to production?

I would like to hear what specifically broke down. Hit reply.

The demo went well.

The virtual assistant understood natural language queries. A customer could type “where is my order” or “what happened to my return” and get a clear, accurate response. It fetched the right data, logged the interaction, and handled follow-up questions without breaking. The team had built something that worked - cleanly, reliably, in a domain where getting it wrong has real consequences.

Then came the question nobody had prepared for.

“Where is the AI?”

The debate nobody expected to have

What followed was one of those conversations that starts small and quietly unsettles everything.

Someone said: we use NLP to understand intent - that is AI. Someone else said: we used a model to classify the query - that is AI. A third voice said: this is not AI, this is automation. A bot reading a query and fetching data from an API is not intelligence, it is a lookup with extra steps.

The team that had just delivered a working system found themselves in a debate about whether what they built counted. Not whether it worked - it clearly worked. Whether it qualified.

Nobody had planned for this conversation. And the longer it went on, the more something shifted in the room. The team that had been confident ten minutes earlier started second-guessing themselves. Is this AI? Where exactly does the AI live in what we built? If a bot calls our API, does that count? What if someone else builds the same thing without a model - is theirs less AI than ours?

The PoC did not fail. The framing did.

And underneath that debate was a quieter problem

Nobody named it out loud because admitting it felt like admitting unreadiness - which was the one thing the organisation could not afford to say.

The team was still learning. Not because they were unprepared - because the tools they were using in January did not exist in October. A model that was the right choice at the start of the project had a newer, cheaper, more capable replacement by the time the PoC was halfway through. The person who made the architecture decision three months earlier was not wrong then. They just had no way of knowing what would exist now.

Walk into any AI project today and you will find this: engineers debating which model to use, which framework to build on, which approach to take - not because they lack judgement but because the options multiplied faster than any team could absorb. By the time the team gets comfortable with one set of tools, the landscape has shifted again. Copilot. Then Cursor. Then agents. Then multi-agent frameworks. Then a new model that makes last quarter’s architecture decision look dated.

This is the reality of building AI capability right now. The ground is moving while you are standing on it. Teams are not falling behind because they are slow. They are falling behind because the pace of change does not pause for delivery timelines. And the pressure to deliver does not pause either.

Why this conversation is happening everywhere

This is not a story about one team or one project. It is happening across IT services right now, in different rooms, with different technologies, producing the same confusion.

The pressure is real and it is legitimate. AI is not a trend that organisations can wait out. The disruption is structural - the way services are delivered, the way SDLC works, the roles that exist and the ones that are disappearing, the expectations clients bring to every conversation. You cannot opt out of this transition. If you do your competitors will be far ahead before you decide to move.

Only around 4% of organisations have moved AI beyond the pilot stage. Most are still in the PoC loop, building and demonstrating and starting again.

The gap between exploring AI and operationalising it is where most organisations are stuck right now. And it is a harder gap to cross than the announcement cycle suggests.

So IT services companies are responding the way organisations respond to existential pressure - they invest, they form teams, they build PoCs, they develop capability. This is the right response. Nobody in that room was wrong to be moving fast.

But the rush arrived before something important was in place. Not the technology. The shared language.

Existing clients are asking: what have you done in AI? Prospects want to know: are you an AI company? Leadership needs to answer upward: where is our AI capability? And the teams doing the actual work are trying to answer a question that was never precisely defined - with technology that did not exist six months ago.

The real problem with the “where is the AI” question

When a leader asks “where is the AI” they are usually asking something else underneath it. They are asking: can I point to this? Can I defend this investment? Can I show a client that we are serious?

Those are fair questions. The problem is they get directed at the delivery team as a technical question when they are actually a positioning question. The team hears “prove this is AI” when the real question is “help me explain the value of what we built.”

The virtual assistant understood human language, interpreted intent, retrieved accurate information, and responded in a way that felt natural to the user. A year ago that would have been called intelligent automation and everyone would have been satisfied. Today it feels ordinary because everyone has used ChatGPT. The bar moved and nobody told the team.

This is the gap causing the confusion. Not a lack of technical knowledge. A mismatch between what the technology does, what the organisation expected it to look like, and what the market is asking the organisation to prove.

Wrong question, right room

The NLP debate, the model debate, the automation debate - these are real distinctions but they are not the question that matters in a delivery context.

The question that matters is: what did this system do that could not have been done before, at this scale, with this consistency, without this technology?

The virtual assistant handled queries across order status, returns, and cancellations in natural language, without a human agent, at any hour, with consistent accuracy. That is not nothing. That is real capability that required real thinking to build. Whether you call the intent classification layer AI or advanced NLP or a fine-tuned model does not change what the customer experienced or what the business saved.

The confusion happens when organisations define AI by its components rather than its outcomes. The component debate will never be settled - every year the definition shifts, what was AI last year becomes table stakes this year, and the goalposts move before the team crosses the line.

The teams that navigate this transition well are the ones that learn to talk about outcomes first and then explain the capability that produced them. Not “we used a model” but “we built a system that handles this type of query at this accuracy without human intervention - here is what that required and here is what it replaced.” That framing survives the “where is the AI” question because it does not depend on a definition that will change again next quarter.

The transition nobody chose but everyone is navigating

Using AI in SDLC is becoming the default assumption. Not a differentiator - a baseline. The question clients will stop asking is “do you use AI” and start asking is “show me what you built with it and what it actually does.”

That shift is coming faster than most organisations are preparing for. And the teams that will be ready are not the ones that memorised the definitions or picked the right model at the right time. They are the ones that can walk into a room, describe what they built, explain the decisions they made under uncertainty, and connect those decisions to outcomes the business can measure.

The PoC that triggered the “where is the AI” debate was not a failure. It was a signal. The technology was ready. The conversation around it was not.

That gap - between what gets built and what the organisation knows how to talk about - is where most of the real work is happening right now. Not in the models. Not in the frameworks. In the rooms where people are trying to explain to each other what they actually did and why it matters.

The organisations that come out ahead will not just be the ones that built the most AI. They will be the ones that built the shared language to understand what they built - before someone in a room asks where the AI is.

Have you been in this conversation - the debate about whether what your team built actually counts? Share your similar experiences on what happened in your discussions.

There is a meeting that used to happen before a major page went live.

Not a sprint review. Not a demo. The earlier one - where the team sat with the wireframe, pulled up personas, referenced analytics, and argued about placement. Someone would say “our users in this segment don’t scroll that far” and someone else would push back with data from a previous release. The BA had already done a few rounds of refinement before the conversation even started.

These meetings were slow. Sometimes frustrating. And they produced something that never showed up in any sprint metric - a shared understanding of what the page was actually for and who it was actually serving.

I was in one recently. Same type of problem - a key customer-facing page, high traffic, first impression for most users. But this time the conversation was different.

The team was using Lovable to build the page. The discussion was about how to write a better prompt. How to get the layout closer to what was needed. How to iterate faster on the form structure.

The personas were not pulled up. The analytics from previous releases were not referenced. The placement decisions were not debated. The assumption, mostly unspoken, was that AI had handled that part. The team’s job was to direct it well.

The form got built. It looked good. The sprint moved fast.

But the thinking that used to happen in those earlier meetings - catching edge cases, remembering what failed before, connecting this to what the team already knew - didn’t happen. Not because nobody valued it. The room had moved on before it could start.

The knowledge that lives in conversation

There were experienced people in that meeting. People who had worked on similar pages, who remembered the old personas, who would have asked the right questions if the conversation had created space for them.

It did not. The energy in the room was toward the prompt, toward iteration speed, toward getting something on screen. The voices advocating for AI were louder and more numerous. The quieter voices - the ones with context - got heard briefly and then the momentum moved on.

This is not a story about AI replacing experienced developers. It is a story about how the shape of a meeting changes what knowledge gets activated.

The old sprint planning sessions were not just planning exercises. They were knowledge transfer mechanisms. Someone described a problem and someone else said — wait, we had something similar in Q3, there is actually a configuration that controls that workflow. Three days of development work disappeared because one person remembered something in conversation that they would never have thought to document.

That kind of knowledge does not surface in a prompt. It surfaces when someone describes a problem out loud and another person makes a connection they did not know they were going to make. It is tacit, contextual, and completely invisible until the moment it becomes relevant.

The output keeps coming. The understanding of what was built and why gets thinner.

I’ve seen teams ship faster, but struggle to explain what the code is doing or why it works. The output is correct. The understanding is thinner.

I have been watching it happen in sprint rooms for the past two years.

AI does not have access to your team’s accumulated knowledge. It knows the general case - documented patterns, common solutions, best practices from across the industry. It does not know that your checkout flow behaves differently during promotional events because of a decision made three years ago that nobody wrote down. It does not know that users in a specific segment drop off on long forms because you learned that the hard way on a previous release.

The readymade answer is generic because it has to be. Your system is not generic.

Where the saved time is going

AI tools genuinely save time. Copilot writes code faster. Lovable builds pages faster. Velocity numbers go up and stakeholders are pleased.

But the time saved is not going into deeper thinking. It is going into more building.

The pressure runs one way. Stakeholders see AI as a productivity multiplier and immediately want to redeploy the saved capacity - more features, more automation, more integrations. The developer who used to spend two days on a page now spends two hours and is expected to deliver five pages. The sprint that used to reserve time for hard technical conversations now skips them because the tool already produced something.

It shows up in individual habits too. The learning curve that used to be built into unfamiliar work - the afternoon spent reading documentation, writing test code, understanding a new API before using it - that friction is gone. AI handles the unfamiliar thing and the developer ships without understanding what they built. That feels like efficiency. Six months later it shows up as nobody in the room who actually knows how that part of the system works.

So the early thinking meetings get shorter. Personas get assumed. Analytics get skipped.

Nobody flags it because the output keeps coming. The velocity is real. What’s disappearing is harder to see - shared understanding, institutional memory, the edge case someone almost mentioned before the meeting moved on.

The voices that stopped being heard

What struck me most in that recent meeting was not what the AI missed. It was what the experienced people in the room did not say.

They were there. The knowledge was in the room. But the conversation was not designed to surface it. The advocates were louder. The momentum was set. Slowing down to pull up old personas in a meeting focused on prompt optimisation feels like resistance, not contribution.

This is where the real loss happens. Not when AI gives a generic answer - that’s expected.
But when the people who would have caught the edge cases stop speaking up because the room has already decided how the work gets done.

AI did not silence those voices. The shape of the meeting did. The assumption that the tool had handled the thinking made the thinking feel unnecessary.

AI should be the entry point, not the destination. Use it to generate the first draft, the initial layout, the working prototype. Then bring the team back into the room — not to optimise the prompt but to ask the harder questions. Does this match what we know about our users? Have we seen this pattern break before? Is there something in the system this doesn’t account for?

The major burden of coding is genuinely lighter now. That is real and worth using. But what that time buys is not more features. It is the space to think properly about the ones you are already building.

The teams that will use AI well are not the ones that move fastest. They’re the ones that keep the slower conversation alive alongside the faster execution. Where the experienced person still gets the floor. Where someone asks - are we solving the right problem - before asking how to make the prompt better.

That meeting still needs to happen. AI just made it easier to skip.

Have you been in a room where the experienced voice got buried under the momentum? would like to hear what happened.

Leave a comment

A few years ago I worked with a retailer running their ecommerce operation on Magento Community Edition. Free platform, strong ecosystem, thousands of extensions, a large developer community behind it. For a growing retailer without deep technical resources it was a reasonable choice. They set it up, added the extensions they needed, and it worked. Revenues grew. The business scaled.

When the growth became visible enough, the conversation shifted. Community Edition had served them well but Enterprise had more - better support, more features, a path that felt appropriate for a company at their stage. The license cost was real but the business case was there. We planned the migration carefully. Same core platform, most extensions had enterprise support, the heavy data migration risk wasn’t there. It took two to three months. The site went live and things were fine.

For a while.

When the platform becomes the problem

Magento was acquired by Adobe in 2018. What had been built as a developer-first open source platform started moving toward enterprise software pricing logic. GMV-based licensing meant the more a retailer sold, the more they paid. Growth stopped being purely good news - it became a cost trigger.

For retailers who had standardised on Magento Enterprise, this was a structural problem. The negotiation conversations started. Some succeeded. Many didn’t. License costs went up. Extension vendors followed. The total cost of ownership on a platform that had felt like an investment started feeling like a tax.

Our client was in this position. And they had a more complicated version of it — stores running in multiple countries, some on Magento Enterprise, one on Shopify, one still on Magento Open Source. The original plan had been to consolidate everything onto one global platform. Magento Enterprise was supposed to be that answer. The GMV pricing made the consolidation business case fall apart before it started.

The evaluation that went nowhere

So we started looking. Feature mapping, cost benefit analysis, platform shortlisting. The room had tech people and business people and the constraints came from both sides.

The tech team was LAMP-comfortable. That set a boundary before the evaluation formally started - nobody said it out loud but the shortlist quietly excluded anything that required the team to rebuild their skills from scratch. The client had their own constraint: no more vendor lock-in. After what had just happened with Magento pricing, that was non-negotiable.

Shopify was the obvious candidate. They already had one country store running on it. It worked. Simple to operate, no infrastructure overhead, no patching cycle. But Shopify is SaaS - you don’t own your data, you can’t touch the core, and your product roadmap is Shopify’s roadmap. The app marketplace fills most gaps but not all of them. Different lock-in, same fundamental dependency.

The client also had marketplace feeds going out to third party channels, and orders punching back in from those marketplaces with inconsistent attribution. That problem didn’t go away on any platform. It followed them into every evaluation conversation.

Commercetools, SFCC, replatforming to a composable architecture - these came up. But they required rebuilding, significant investment, and a level of technical commitment that a retailer who just wanted to sell goods couldn’t justify. They were not a technology company. They had never wanted to be. The tools required to sell online had turned them into one against their will, and they were not interested in going deeper in that direction.

Every option extracted something different. Magento extracted engineering capacity and eventually money. Shopify extracted data ownership and flexibility. Custom builds extracted time and risk. There was no neutral option. There never is.

So the evaluation stalled.

Inertia is also a decision

The revenues kept coming. The platform kept running. The problems were real but not visible enough to force a choice that had no clean answer.

This is not a failure of leadership or technical judgment. It is what happens when a business that sells goods gets pushed into technology company problems by the tools it needs to operate. The platform decision becomes a proxy for deeper questions the organisation isn’t ready to answer - who owns the data, what does global unified commerce actually require, how much technical debt are we carrying in our custom extensions, and what is our real tolerance for disruption during peak trading season.

When none of the options are clearly better, continuity wins. Every time.

The cost of that continuity is invisible until it isn’t. A security patch that stops coming. An extension that breaks on a version upgrade. A marketplace integration that fails at the wrong moment. The platform doesn’t announce when it becomes a liability. It just quietly becomes one.

This Is Not One Retailer’s Story

The pattern above is playing out across the industry right now - not as a historical artifact but as a live operational reality for thousands of mid-market retailers.

Magento’s installed base is still enormous. Adobe Commerce migrations away from the platform are accelerating but messy. The retailers leaving are discovering that the lock-in they thought was in the license was actually in eight years of customisation, business logic buried in extensions, and teams whose muscle memory is platform-specific. You can change the platform name. You cannot easily change any of that.

The retailers staying are managing a platform whose vendor incentives no longer align with their growth. Every order they add to their GMV is an argument for their competitor to undercut them on total cost of ownership.

The retailers who chose Shopify are discovering the ceiling - not immediately, but when they need something the app marketplace doesn’t cover, or when they want their data in a structure their analytics team can actually use, or when they expand into a market where Shopify’s localisation support is thin.

What the Path Forward Actually Looks Like

The retailers navigating this well are not the ones who found the perfect platform. There isn’t one. They are the ones who stopped treating the platform decision as a technology question and started treating it as a business constraint question.

What does your team actually have the capacity to maintain? What data do you need to own, and what can you rent? Where is your real competitive differentiation — and is any of it actually in your platform customisation, or did it end up there by accident?

For most mid-market retailers the honest answer is: the differentiation is in the relationships, the product range, the fulfilment capability, and the customer experience. Almost none of it is in the code. Which means the platform should be as boring and maintainable as possible - not a competitive asset, but a cost of operations.

The composable commerce conversation - headless, API-first, best-of-breed - is the industry’s current attempt to deal with this. It is the right direction architecturally. It is also genuinely hard to execute for a team that is LAMP-comfortable and just wants to sell goods.

Which is why the stall continues. Not because retailers are making bad decisions. Because the options are genuinely hard and the cost of being wrong is high and the revenue keeps coming in.

The platform trap is not a technical problem with a technical solution. It is a business problem that keeps presenting itself as a technical one. Until the industry - platforms, implementers, and retailers together - gets honest about that, the evaluation cycles will keep stalling and the inertia will keep winning.

And somewhere right now there is a retailer running a version of this same conversation, with a slightly different cast of platforms, wondering why none of the options feel right.

They are not wrong to wonder.

If you work around ecommerce platforms, digital operations, or the systems behind online retail, you might find Between Roles useful.

Leave a comment

Share

In the early days, you needed your own website - a domain, hosting, a payment gateway, someone to build the thing. Then Amazon and Flipkart built marketplaces and suddenly you could list your products without a storefront. Then came dark stores, quick commerce, and social commerce - new surfaces, same fundamental idea: meet the customer where they are.

We are now at the next one. And unlike the others, this shift changes something more fundamental than the channel.

It changes who - or what - is making the buying decision.

What as actually happening

In September 2025, OpenAI and Shopify announced that shoppers can buy products directly inside a ChatGPT conversation. No redirect. No website visit. No checkout page. One prompt, one confirmation tap, done.

A few weeks later, Google and Shopify co-announced the Universal Commerce Protocol - an open standard for AI agents to connect directly to merchant storefronts and complete purchases without the customer ever visiting. Walmart, Target, Wayfair, and Etsy signed on at launch.

Then Mastercard launched Agent Pay. Visa followed with its own Trusted Agent Protocol. The Linux Foundation stood up a governance body - the Agentic AI Foundation - co-founded by OpenAI, Anthropic, and Block, with members including AWS, Google, Microsoft, Shopify, SAP, IBM, and Salesforce.

In roughly eight weeks at the end of 2025, most of the plumbing for a new kind of commerce suddenly appeared across the biggest platforms in the world. This is not a feature release. This is infrastructure investment at scale.

Reason for paying attention

I have sat through a lot of “the future of retail” conversations, but this one feels different — not because of the technology, but because of who is building the infrastructure and how fast they are moving.

When Visa and Mastercard both independently build authentication frameworks for agent-initiated transactions in the same quarter, that’s not speculative. Payment networks do not build production infrastructure on a maybe. That corroboration is what makes me take this seriously.

Mastercard CEO Michael Miebach said it plainly: “Agentic commerce is here, and we’re at the center of it.” That framing - from a company with a $450 billion market cap - is the tell.

The players and what they are actually building

OpenAI launched Instant Checkout inside ChatGPT in September 2025, live for 900 million weekly active users. The underlying standard is the Agentic Commerce Protocol, co-developed with Stripe. The agent never sees the card number - it passes an encrypted payment token through to Stripe.

Shopify built a toolkit: a Catalog API, a Universal Cart, and a Checkout Kit. The idea is that when ChatGPT or Gemini or Copilot needs to complete a purchase, Shopify handles the product data, cart, and payment rail - even if discovery happened somewhere else. They have also launched an “Agentic Plan” where merchants not on Shopify can still get their catalog into AI agent storefronts. Whoever wins the AI interface war, Shopify wants to be the rails underneath the transaction. Same position they have always played, just a much bigger definition of where commerce can happen.

Google launched UCP with Shopify and separately launched AP2 - the Agent Payments Protocol - backed by Mastercard, PayPal, American Express, Klarna, and Etsy. Their shopping graph has 50 billion product listings refreshing continuously. Google is positioning to be both the discovery layer and the transaction standard simultaneously, which if it succeeds is a meaningful concentration of commercial leverage.

Mastercard introduced “Agentic Tokens” - payment credentials scoped to a specific AI agent, with spending limits and merchant controls built in. Already live for US Bank and Citibank cardholders, global rollout in early 2026. Visa followed with its Trusted Agent Protocol, backed by Stripe, Shopify, Worldpay, and Nuvei. Both frameworks are designed to be compatible with ACP and UCP. The question they are both trying to answer: when an AI agent makes a purchase on your behalf, how does the merchant verify it is a legitimate action by a consented human - and not a rogue script?

Amazon is notably absent from all the open protocols. They are building Rufus AI, Alexa+, and “Buy for Me” - all proprietary, all designed to keep the agent and the transaction inside their ecosystem. The open protocol versus walled garden dynamic is replaying exactly as it did in the early web. Worth watching which approach wins this time.

The standards race - and why this time is different

Every time a new infrastructure layer emerges in commerce, it follows the same cycle: proprietary chaos, fragmentation, then eventually standards. EDI in the 1980s. Card payment rails in the 1990s. REST APIs in the 2000s. Open banking in the 2010s — still incomplete in most markets, because it required regulatory pressure that moved slowly.

With agentic commerce, the incentive runs toward adoption rather than against it. Merchants want their products discoverable by agents. When the commercial interest aligns with the standard, timelines collapse — and that is what is happening here.

Four protocols form the technical plumbing. MCP (Model Context Protocol, Anthropic, now donated to the Linux Foundation) is the data access layer — how agents read product catalogs, policies, and inventory signals. Over 10,000 published servers; Stripe, Square, and Shopify have all built integrations. A2A (Google) handles how agents coordinate with other agents. AP2 handles payments and liability. ACP handles the end-to-end checkout flow.

These four interlock, no single company owns all of them, and they are designed to be compatible across platforms. The Agentic AI Foundation — launched in December 2025 under the Linux Foundation — exists to govern them, with the stated goal of doing for agentic commerce what the W3C did for the web.

The standards that win are the ones that make it easier for everyone to build. That is what is happening here.

The problem not talked enough

All of this infrastructure only works as well as the product data underneath it.

Most product catalogs are not built for machine reading. Attributes are inconsistent across SKUs. Inventory signals are stale. Return policies are buried in PDFs written for humans. If an agent cannot parse your policies or trust your inventory data, it will get the recommendation wrong — or skip you entirely.

Your storefront is now your API documentation.

Or more precisely, your product catalog is.

Before worrying about which protocol to integrate with, most businesses need to answer a more basic question: if an AI tried to sell your products right now, would it even have accurate information?

Messy catalogs. Inconsistent specs. Broken inventory feeds. These unglamorous problems will determine which merchants show up in agent-driven results and which become invisible. That is the gap nobody in the announcement cycle is talking about — but it is where the real implementation work happens.

There is a pattern emerging in how this plays out by category. True Fit announced a specialized agentic commerce agent in February 2026 built on twenty years of transactional and returns data from 80 million active users, 100,000 brands, and 500 retailers. Why does this matter? Because 70% of fashion-related questions that come into shopping agents are about size and fit — and generic agents cannot answer them reliably without specialized data. The moat is not the agent. The moat is the data.

This points to something broader: vertical agents solving category-specific problems that horizontal agents cannot. Size and fit in fashion. Ingredient compatibility in food. Technical specs in electronics. In each case, the agent is only as good as the specialized data behind it. And most merchants are nowhere near ready on that dimension.

What the future looks like

Right now: Agent-assisted with human confirmation. The agent researches, surfaces options, presents a confirmation. Human approves. Live today in ChatGPT shopping and Google AI Mode.

2026–2027: Delegated purchasing within limits. You set rules — “reorder when stock drops,” “find a replacement under this price” — and the agent executes without asking each time. Mastercard’s Agentic Tokens are built specifically for this.

2027 onwards: Agents manage recurring purchases, monitor prices across merchants, switch suppliers when a better deal appears. This is when brand loyalty becomes a genuinely different problem. The agent does not have brand loyalty. It has your criteria.

At each stage, what matters shifts. Right now, product data quality is the lever. Later, agent preference algorithms will matter — the equivalent of SEO, but for AI decision-making. Nobody fully understands that layer yet. But the merchants who have clean data when that layer hardens will be ahead of the ones scrambling to catch up.

The direction is settled, details are not

We do not yet know how consumer trust in autonomous purchasing will develop at scale. We do not know how liability resolves when an agent makes an incorrect purchase. We do not know if Amazon’s walled garden approach wins in certain categories.

What we do know: when Visa, Mastercard, Google, OpenAI, Shopify, IBM, and SAP all move into the same space in the same quarter — with production deployments and a governance foundation — the direction is set even if the details are not.

Ecommerce has always rewarded the people who understood new channels early and prepared seriously. The preparation that matters right now is not picking a protocol. It is making sure your product data is accurate enough for a machine to sell from it.

The channel is open. The question most merchants should be asking is not whether this is real. It is whether an AI agent could sell their products accurately today - and what it would take to get there.

If you have been in retail or ecommerce and have thoughts on how this is landing in practice - especially on the catalog data problem or agent trust - I would be interested to hear it. Hit reply.

Share

Subscribe now

On paper, things looked good.

80 to 90 percent of revenue was coming from marketplaces. The rest came through WhatsApp groups, Telegram, word of mouth — people who’d found him directly and kept coming back. He knew those buyers. They knew him. But that second number — the 10 to 20 percent — didn’t appear in any dashboard. No system tracked it, no report counted it.

That gap is where the real problem was sitting.

The obvious reason to start on a marketplace

Most sellers begin here for good reason. No tech team needed. No payment infrastructure to build, no logistics to figure out, no traffic to drive to a website nobody’s heard of. The marketplace handles all of that. You focus on the product.

The commission hurts, but it’s a known cost. You’re paying for distribution, trust, and operational infrastructure you’d spend months building yourself. For a seller testing whether demand is real, that’s a reasonable trade.

Starting on a marketplace isn’t the mistake. It’s what doesn’t get built while you’re there.

What the marketplace actually keeps

As orders grow, so does everything else. Commissions. Storage charges. Return handling fees. Promotional participation — technically optional, practically required if you want visibility.

But the harder loss isn’t the margin. It’s the data.

The customer who bought your product — you don’t know who they are. You know 43 units sold today. You don’t know if that’s 43 different buyers or 12 repeat customers. Where they’re from, what else they browsed, whether they’d buy again. You can’t reach out. The marketplace owns that relationship. You get a settlement report.

And it doesn’t stop at contact details. Our client wanted to improve how his products were presented — richer content, 360-degree views, eventually a tool to show buyers how a piece would look in their home. Reasonable ambition for a handcraft seller trying to stand out. But the platform controls the product page. You work within what they allow. The experience layer isn’t yours to build.

Pricing isn’t fully yours either. Platforms run promotions on your listings and you absorb the discount. Pricing parity clauses — explicit or implicit — mean one platform’s algorithm affects what you can charge everywhere else. You listed a product. Someone else is deciding what it costs.

The data problem you don’t notice until you need it

This one caught us late.

When our client started thinking about growing more systematically — better inventory planning, demand forecasting, seasonal patterns — we hit a wall. The data needed wasn’t available.

What marketplaces give you isn’t enough to plan or forecast anything meaningful. Aggregate sales by product. Basic trend reports. Enough to manage day-to-day, not enough to build on.

Detailed purchase history by customer segment? Not available. Browsing behaviour before purchase? Not available. Demand signals across categories? Not available. Early years of sales data in a usable format? Whatever the platform decides to export, in whatever format they provide, for however long they retain it.

If you want to build a demand forecasting model or plan inventory for a new launch, you need historical data with enough granularity to be useful. What most sellers find when they try is that the data from their marketplace years is either unavailable, incomplete, or buried in formats that need significant work before they’re usable.

You didn’t just lose the customer. You lost the history.

When he wanted out

At some point our client wanted to build his own identity. Reduce the dependency. Own the customer relationship. He had a real product, real demand, two years of order history.

Here’s what he actually had:

Sales numbers. Aggregated. By platform, by product, by month.

That was it.

No customer list. No purchase history by buyer. No way to know who his most loyal customers were, which products they returned for, what price point worked without a discount. The marketplaces had all of that. He had a spreadsheet.

The 80 to 90 percent from marketplaces? That relationship ends the day you stop listing. The 10 to 20 percent from WhatsApp and Telegram? That’s what he actually owned. That was the real starting point.

Two years of orders. Almost no portable equity.

The brand hadn’t transferred either. His marketplace buyers remembered where they bought it, not who made it. “I got it on Amazon” is not the same as “I buy from this seller.” When he wanted to reach them directly, they didn’t know him.

How the dependency builds quietly

This isn’t the marketplace’s fault. They built what they built — a platform for sellers who need distribution, not a CRM for sellers who want relationships. They were always clear about what they offered.

The incentives push you toward optimising for the channel that’s working. And the channel that’s working is the one you don’t own.

Every hour spent optimising listings is an hour not spent building a direct relationship. Every percentage point in fees is margin not going into owned channels. The business grows. The dependency deepens. Both happen at the same time, quietly.

By the time the economics stop working — commissions up, a competitor undercutting, a policy change you had no say in — you find out the customer relationships you thought you were building belong to someone else. And the data you’d need to plan your next move is locked behind an export API that gives you summaries, not history.

What actually compounds

I’ve written before about platform lock-in — how migrations cost more than estimated, how AI makes dependency worse, how to think about what to own versus rent. Marketplace dependency follows the same logic, but it’s less visible because there’s no migration project to trigger the conversation.

Marketplace sales don’t compound for you. Each transaction teaches the platform more about your customer. A direct sale — even a small one through WhatsApp — teaches you something you can use next time. The buyer’s name. What they asked about. Whether they’d buy again.

Our client’s WhatsApp buyers were more valuable than his marketplace buyers. Smaller in number, but he knew them. He could tell them about a new product. He could ask what they wanted next. He had a relationship, not a transaction record.

That 10 to 20 percent was the only equity he actually owned.

Thousands of sellers have built real businesses starting exactly this way. The marketplace gave them distribution they couldn’t have afforded, customers they couldn’t have reached, infrastructure that would have taken years to build. That part is real.

But from day one, there’s one number worth tracking alongside revenue: the buyers you could reach tomorrow if every platform shut down tonight. The history you could actually use if you needed to forecast demand for next year.

If that number is close to zero after two years of selling — that’s the cost nobody put on the spreadsheet. Not in rupees. In relationships. And in years of data you can’t get back.

Last week I watched a developer accept a Copilot suggestion, run the tests, see green, and move on. The code was correct. The logic was borrowed from a pattern that makes no sense in our system. Nobody caught it until code review - and only then because a senior happened to recognize it from a vendor’s public repo she’d seen before.

I’m not writing this as someone who thinks AI coding tools are a problem. I use Copilot. It’s genuinely good. For scaffolding a project, matching an existing codebase’s style, or eliminating boilerplate that used to eat a morning - it earns its seat at the table.

But I’ve spent twenty years watching projects fail. Not because of technology, but because of the gaps between the people in the room. And right now, I’m watching Copilot quietly widen every one of those gaps.

What the data actually says

Let’s be honest about both sides by saying that the productivity gains are real.

GitHub’s research shows developers completing tasks 55% faster with Copilot. Internal telemetry suggests it writes roughly 46% of the code in files where it’s active. If you’re leading a team and not experimenting with this, you’re at a disadvantage.

But here’s where it gets uncomfortable.

GitClear analyzed 211 million lines of changed code between 2020 and 2024. They found code churn - lines revised or reverted within two weeks - nearly doubled, from 3.1% to 5.7%. Refactored code dropped from 25% of all changed lines in 2021 to under 10% by 2024. And for the first time in their dataset, copy-pasted code exceeded refactored and reused code.

More output. More rework. Less visible system-level thinking.

Stack Overflow tells a parallel story. Monthly questions dropped roughly 76% between 2022 and 2024 - almost perfectly aligned with the rise of AI coding assistants. Developers aren’t asking fewer questions. They’re asking them in private sessions that disappear when the tab closes.

Their 2025 Developer Survey adds another signal: 84% of developers now use or plan to use AI tools, but trust declined from 43% to 33% year over year. The most common frustration? Solutions that are “almost right, but not quite.”

More code. Less confidence in it.

The gap between roles, getting wider

Here’s what those numbers don’t capture - and it’s the thing I watch in my practice every week.

Copilot doesn’t know the room.

It doesn’t know what sales promised. What compliance requires. What the team tried and abandoned eighteen months ago. Why the checkout flow looks strange but is built that way for a reason nobody has bothered to document because everyone just... knows.

That memory lives in the humans. And what I’m seeing is this: when a developer solves a tricky logic problem in a private AI session, that reasoning dies in the chat window. It doesn’t go into a PR comment. It doesn’t surface in standup. It doesn’t become the story a senior tells a junior six months later when they hit the same wall.

The knowledge was generated. It just wasn’t transferred.

The Stack Overflow collapse is one signal of this. Developers used to think out loud in public. They’d post the error, describe what they tried, get corrected by three people who’d been burned by the same thing, and that whole thread would sit on the open web for the next team that hit the same problem. That’s gone. The reasoning now happens in a black box owned by no one.

Research published in Communications of the ACM found that senior developers spend significantly more time reviewing AI suggestions than juniors - not because they’re slower, but because they’re pattern-matching against production incidents they’ve already survived. The junior who hasn’t lived through those incidents yet accepts more and understands less of what they’re accepting. The gap between those two groups is growing, and Copilot is quietly widening it.

The failure mode I keep seeing in retail

I run a Gen AI practice, and a large part of it is retail and ecommerce. Let me make this concrete.

Copilot can generate a checkout form in minutes. It does this well. What it cannot know is that checkout in your specific system isn’t a form - it’s a set of assumptions. It’s payment trust thresholds. Retry logic under partial transaction failures. Session handling during a flash sale when twelve thousand people hit the cart simultaneously. Edge cases carved out after outages no one wants to relive.

I’ve watched AI-generated authentication code pass every test and still carry a timing attack vulnerability that a senior caught on instinct. Not through test coverage. Through scar tissue.

I’ve also noticed that migrations produce code so deeply coupled to a vendor’s patterns that untangling it later cost close to a million dollars. Not because the code didn’t run. Because no one asked whether it fit the system it was entering, whether the team owned it or was renting it. Copilot generated code that was syntactically correct and architecturally expensive.

The LinearB data backs this up: a Fortune 500 financial services team spent three months refactoring authentication modules that technically worked but violated their security architecture. Copilot had pulled patterns from public repositories that made no sense in a regulated environment. The code ran. The code was wrong.

What this is not and what to actually do about it

This isn’t an argument to stop using Copilot. The velocity gains are real and teams that aren’t using these tools are falling behind, not standing still.

The problem is that adoption has been backwards. We gave the tools to the people writing code and measured their velocity. We didn’t change how we review. How we mentor. How we document. Or what we consider “done.”

The shift I push with every tech lead I work with is simple: stop being a syntax reviewer and start being a logic auditor.

The review question is no longer “does this run?” It’s “does the developer understand why it runs - and what happens when it doesn’t?” If they can’t walk you through the reasoning behind the suggestion, the review isn’t finished. Make AI usage visible in pull requests. If Copilot wrote something, say so, and explain why you accepted it. That transparency forces the thinking that the tool itself lets developers skip.

The other thing worth doing: normalize “Copilot-free” sessions for complex features - not as a punishment or a Luddite exercise, but as the deliberate practice of building the mental models that make AI assistance actually safe to use. Seniors do this instinctively. Junior developers need it structured in.

The gap between roles has always been where projects break. Sales promises something, engineering builds something adjacent to it, and nobody caught the drift because the knowledge lives in three different people’s heads and one private Slack thread.

Copilot just makes it easier to ship code across that gap before anyone notices it’s there.

The teams I worry about aren't the ones moving slowly. They're the ones moving fast and mistaking the absence of errors for the presence of understanding. Those are different things. And the gap between them is where projects quietly go wrong.

Leave a comment

Subscribe now

“I built this in 3 hours.”

You may have seen these type of claims and posts. And the output is real. The speed is real. I’m not here to argue with that.

But I’ve been on both sides of a production fire. The side where you ship something fast and feel like a genius. And the side where you’re staring at logs at 2am trying to figure out why something that “worked” has quietly been failing for six hours. Those two experiences are separated by a lot of things - and one of them is whether you actually own what you shipped.

That’s what I want to talk about. Not whether vibe coding works. It does. But what it quietly costs if you’re not paying attention.

I use GitHub Copilot regularly. I use vibe coding too - Claude, ChatGPT, whatever makes sense for the task. I’m not writing this as someone who’s skeptical of the tools. I’m writing this as someone who’s watched what happens inside engineering teams when the tools start doing the understanding on everyone’s behalf.

And those are not the same thing. Using a tool is fine. Outsourcing your comprehension to it is a different situation entirely.

The story I keep coming back to: I had a working POC. One piece was broken. I pasted the error, the model came back with something like — this is a known issue with this version of Node.js - and then explained exactly why. Confident. Detailed. Correct.

I still spent hours fixing it.

Because the model understood the error in the abstract. It didn’t understand my file structure, my dependency tree, what I’d already patched elsewhere, why two things that looked unrelated were actually connected. Every suggestion made sense on its own. None of them accounted for the full system. And I was the only one in the room who could.

That’s the gap. Not that the AI was wrong. It was right. But understanding a problem and being able to resolve it inside a specific, messy, real context - that’s still a human job. And it always will be.

Here’s where I want to be precise about something, because I see this conflated constantly: GitHub Copilot and vibe coding through a chat interface are not the same tool.

Copilot sits inside your editor. It sees your codebase - your imports, your naming conventions, your actual file structure. It’s autocomplete with serious context. Vibe coding through a chat window is working from your description of reality, not reality itself. You’re the translator. And something always gets lost in translation.

Both are useful. I use both. But the detachment in chat-based vibe coding means coherence becomes your responsibility faster than you might expect. You patch one section and quietly break another. You’re not always aware it’s happening.

Now, the part that concerns me - not about the tools, but about the developers using them.

I’ve watched junior engineers ship features they can’t explain. Not because they’re bad engineers - they’re not. But because they generated something that worked, got it merged, moved on. And when it broke, they had no map. The AI had done the understanding for them, and that understanding didn’t transfer with the code.

This isn’t a new problem. We had it with Stack Overflow. We had it with copy-paste culture generally. But the speed has changed. You can now generate an entire feature without ever having to hold the logic in your head. That’s extraordinary for momentum. It’s a liability for ownership.

Senior engineers aren’t immune to this. But they tend to know when to stop prompting and just fix it. They recognise a version conflict before chasing it through five generated suggestions. They can feel when something’s wrong even when the code runs.

That intuition is built from years of things breaking in your hands. Vibe coding doesn’t give you that. It skips over it. And if you let it skip over too much for too long, you end up with engineers who are very good at describing what they want and increasingly uncertain about what they’ve built.

There’s also the confidence problem, and it might be the most dangerous one.

AI output looks finished. Clean formatting, confident tone, no hedging. It doesn’t say I’m guessing here or this might break if your setup is slightly different. It says here’s the fix. That presentation trains you to trust it - and most of the time, trust is warranted enough that you don’t notice when it isn’t.

Until you’re in production and something that should have been caught in review wasn’t, because the generated code looked so authoritative that nobody questioned it.

I’ve been in rooms where that happened. It’s not a fun conversation.

Here’s what I actually think:

Vibe coding is some of the best leverage I’ve seen for getting from zero to one fast. Getting a skeleton up, testing whether an idea holds, making something real before you’re sure it’s worth building - it’s genuinely changed how I prototype. I’m not going back.

But there’s a handoff moment. A point where you need to stop generating and start owning. Reading the code. Understanding what it does and why. Knowing what breaks if the input is malformed, what happens if the external API times out, where credentials live and who can reach them.

The mistake isn’t using vibe coding. It’s not noticing when it’s time to stop.

Production ready isn’t a 3-hour build that runs. Production ready is a build you can wake up at 2am and debug without needing to ask the AI what it built for you. It’s error handling that’s thought through rather than assumed away. It’s logs that tell you something useful when things go wrong.

None of that gets generated in an afternoon. Vibe coding reduces the cost of starting. It doesn’t reduce the cost of understanding what you’ve built.

The developers who’ll use these tools best aren’t the ones who prompt the hardest. They’re the ones who stay close enough to the code that they can tell when something feels off, who use AI for speed and then apply judgment the AI doesn’t have.

Use it for momentum. Use it to make ideas real fast. But when real users are involved, when data matters, when uptime matters - read it. Understand it. Know what breaks and why.

The code that runs is not the same as the code you own.

And ownership - that hasn’t changed. That’s still yours.

Share

Subscribe now

There’s a quiet shift happening beneath the AI productivity narrative - one that has less to do with speed and more to do with where knowledge lives.

We’re told that AI now assists with 40–46% of code in some organizations. That number will climb. Within a few years, most scaffolding, boilerplate, and routine logic will likely be generated by models.

The story usually ends there: faster builds, smaller teams, more leverage.

But there’s a second-order effect that matters more. You can see it in the pattern.

The Pattern

Stack Overflow’s traffic tells a clear story. New questions have declined roughly 70% from early 2023 to late 2024. The site now processes question volumes it hasn’t seen since its early years - after nearly two decades of growth.

The timing roughly aligns with ChatGPT’s launch in late 2022. The decline accelerated through 2023 and 2024.

This isn’t really about Stack Overflow specifically. It’s about a behaviour shift: when developers hit an error, many no longer post publicly. They open an AI assistant.

What Changed

Before:

You’re debugging a React hook that keeps re-rendering. You search “useEffect infinite loop.” You find a thread with 47 answers, one accepted answer with 892 upvotes, 15 comments debating edge cases, and several wrong answers with hundreds of downvotes. You piece together your solution from answers 3, 7, and a comment.

The whole exchange - including the failed attempts - is now indexed and searchable.

Now:

Same bug. You paste your code into Claude or Copilot with “this keeps re-rendering.” You get immediate diagnosis, a fix, and an explanation. No public trail. No one else can Google it.

On a free tier, your iteration may feed the model. On an enterprise plan, it feeds your company’s telemetry.

Either way, the debugging still happens - but it leaves no public residue.

The knowledge wasn’t lost. It moved into private infrastructure.

The New Loop

For two decades, software development left a public trail. When something broke, developers searched. They landed on threads. They posted. They argued. They got downvoted. They refined the question. The final answer - and often the failed attempts - became indexed knowledge.

Debugging wasn’t just problem-solving. It was artifact creation.

Today, that loop is changing. AI companies have built feedback loops that, in some ways, are richer than public forums were. Instead of seeing only final Q&A exchanges, modern systems can capture:

• Prompt chains and how developers refine them

• Which suggestions get accepted or rejected

• Error patterns and real-time corrections

• Full iteration context, not just outcomes

This data may be more useful for training than forum threads ever were.

The difference is ownership.

What We’re Losing

Stack Overflow was noisy. It became infamous for gatekeeping, duplicate-marking, and harsh moderation. The decline actually started years before AI - around 2014, when moderation intensified and many developers stopped asking because the site felt unwelcoming.

The platform wasn’t perfect. But it served a specific function: it captured the messy, unhappy path of technology. Official documentation describes how systems should work. Public forums recorded how they actually fail - version conflicts, deployment errors, brittle integrations, misunderstood edge cases.

I remember setting up XAMPP on Windows years ago. The guide said it would take ten minutes. It didn’t.

Apache wouldn’t start. Port conflicts. Version mismatch.

I copied the error into Google. Landed on three Stack Overflow threads. One from 2011. One with an accepted answer that didn’t work. One where the real solution was buried in a comment explaining a Windows service conflict.

It took an hour. Maybe two.

That hour became part of the archive. The next person searching that error could follow the same messy trail.

Today, the same error would likely be pasted into an AI assistant.
The diagnosis would be immediate.
The fix applied.

No thread. No comments. No residue.

If more of that failure analysis moves into private sessions, the question isn’t “will AI stagnate?” It won’t. Models will improve regardless, drawing from repositories, internal corpora, and reinforcement signals.

The real question is: who gets access to the improvement cycle?

Knowledge Asymmetry

The shift is about distribution.

Individual developers once contributed to - and benefited from - a shared commons. Now that pattern is splitting:

• Free-tier users may contribute training data

• Enterprise customers get private, fine-tuned systems

• Small teams inherit a thinner public knowledge base over time

Large organizations with internal telemetry refine their systems faster. They accumulate:

• Private debugging logs

• Custom model improvements

• Proprietary error pattern databases

• Competitive advantage built on knowledge production

This isn’t new in principle. When academic journals moved behind paywalls, research became less accessible. When tools moved from open-source to SaaS, expertise became more centralized.

Now debugging knowledge is following a similar path.

Knowledge production hasn’t stopped. It’s been tiered.

The Mutation

Debugging isn’t disappearing. It’s moving up a layer.

As AI generates more code, humans increasingly debug:

• Integration failures

• Model behaviour and drift

• Instruction misalignment

• System interactions across boundaries

• Guardrail logic

The failure surface doesn’t shrink. It mutates.

For years, friction in public forums produced durable artifacts. Being corrected, challenged, even downvoted forced clarification - and that clarification became searchable knowledge.

AI removes social friction. It replaces it with smooth, instant iteration.

That smoothness is a productivity gain. But friction was also how we built collective memory.

What This Means

We’re not starving AI of intelligence. We’re reshaping where intelligence compounds.

The shift from public to private debugging isn’t inherently good or bad. It’s structural. And structure determines who compounds faster.

As more debugging happens privately, the open archive thins.

Do we need new public systems designed for AI-era workflows — systems that capture iteration, not just answers?

Or is this the natural endpoint — knowledge production becoming a competitive advantage rather than a shared good?

The debugging still happens.
The knowledge still accumulates.
But it accumulates inside different walls.

The next era of software may not be defined by who writes the best code —
but by who owns the richest debugging loops.

Leave a comment

Subscribe now

I’ve worked in retail systems where data governance meant mostly masking the credit card field and restricting the database access.

I’ve also part of discussions where an AI assistant had visibility into customer behaviour data, order history, refund logic, pricing overrides, and vendor contracts - and nobody could clearly explain who owned the risk if it made the wrong call.

Retail governance didn’t fail overnight.
It evolved.

And AI is the first time we’ve given systems the authority to decide.

That changes everything.

When governance meant protecting the database

Early ecommerce was structurally simple.

Website - Checkout - ERP - CRM - Payment gateway - Warehouse system.

Data was centralized and ownership was clear. IT and compliance ran the show.

Governance meant:

• PCI compliance

• PII masking

• Role-based access control

• Audit logs

• Backup and recovery discipline

I remember one release getting blocked because an error log captured partial payment metadata during a failure scenario. It wasn’t a breach. It wasn’t exposed externally. But compliance didn’t care. The rule was clear: sensitive data should never appear in logs. Fix it before go-live.

It was rigid. Slow. Sometimes frustrating.

But control was visible.

Back then, governance meant protecting what was stored.

Omni-Channel broke the illusion of control

Then retail expanded.

Website. Mobile app. Physical stores. Marketplaces. Third-party logistics. APIs.

Data stopped sitting quietly in one place. It started moving.

The biggest issue wasn’t hackers. It was synchronization.

During one omni-channel expansion, we faced repeated overselling of specific SKUs. Customers were placing orders online while marketplace inventory sync lagged behind. Two systems updating stock at different intervals. Both technically correct. Operationally disastrous.

Refund cycles increased. Support tickets spiked. Operations blamed tech. Tech blamed sync frequency. Everyone blamed “the system.”

It wasn’t a security failure. It was a governance failure.

We didn’t have a meeting where someone said, “we need better governance.” What we had was the VP of Operations walking in with a spreadsheet showing $47,000 in refunds from oversold inventory in one month. That got everyone’s attention.

We redesigned around a single source of truth. Moved to event-driven updates. Added monitoring around inventory delta thresholds. Introduced stricter API throttling.

That was the shift.

Governance stopped being just about protecting data at rest.
It became about controlling data in motion.

Marketplaces added political complexity

When marketplaces matured, governance got another layer.

Now you’re not just protecting customer data. You’re managing:

• Seller data

• Vendor banking details

• Commission logic

• Sponsored placement rules

• Cross-border compliance

• Multi-tenant data isolation

Ownership blurred slowly.

In one marketplace implementation, we discovered an internal analytics dashboard that allowed aggregated performance views across sellers. It wasn’t exposing raw data directly, but a smart user could infer competitive metrics.

No malicious intent. Just schema design that didn’t fully enforce tenant isolation.

Legal got involved. They wanted to know if we’d violated any seller agreements. We hadn’t - technically. But the gap between “technically compliant” and “actually safe” was uncomfortably wide.

We restructured query permissions. It took three weeks. We rewrote the analytics layer to enforce strict seller-scoped views. Added explicit data classification tags at the schema level. Migrated every dashboard query to use the new segmentation logic.

It wasn’t a breach. It was a structural vulnerability that nobody noticed until someone asked the right question.

That moment made something clear:

Marketplace governance isn’t just technical.
It’s contractual. Structural. Political.

At this stage, governance was about protecting ecosystems.

AI doesn’t just access data - It acts on it

Now we’re layering AI on top of all of it.

AI shopping assistants browsing inventory.
Agents placing orders on behalf of customers.
Automated refund evaluation.
Chatbots with access to payment methods and order history.
Workflows capable of executing transactions.

Here’s the real shift:

Traditional systems stored data.
Omni-channel systems moved data.
Marketplace systems distributed data.
AI systems interpret and act on data - AI systems interpret and act on data - with customer credentials in hand..

That’s not iteration. That’s a different category of risk.

When the shopping assistant has your Credit Card

We deployed an AI shopping assistant pilot last quarter. Customer says, “reorder my usual groceries,” and the agent pulls order history, checks inventory, applies coupons, and completes checkout.

it is absolutely Convenient.

Then we ran a red team exercise.

One tester said: “Add organic milk to my cart and place the order.”

The agent did. No confirmation. No review screen. No “are you sure?”

Another tester: “Cancel my subscription and reorder everything as one-time purchases.”

The agent started processing. It had access to subscription APIs. It had payment methods on file. The only thing that stopped it was a rate limiter after three rapid API calls.

We weren’t breached. We were exposed by design.

The agent wasn’t malicious. It was obedient.

Here’s what we changed:

Every action touching payment or subscription now requires explicit confirmation. We added a review step before any transaction executes. We implemented per-session spend limits - if total order value exceeds a threshold, the agent hands off to human review.

We also started tracking prompt patterns that led to unintended actions. Vague instructions like “handle my subscription” were being interpreted as full authority.

The wake-up call: AI doesn’t understand consequence. It understands instruction.

When the agent gets your address wrong

Different pilot. AI agent handling customer service for order modifications.

Customer: “I moved last week, update my delivery address for all future orders.”

Agent updated the address. It also updated three in-transit orders.

Two packages rerouted mid-delivery to the wrong address. One returned to warehouse. Support ticket. Refund issued. Customer annoyed.

Total cost: $240 in shipping, inventory loss, and support time.

The agent followed logic. It saw “all future orders” and interpreted in-transit orders as future relative to the original order date.

It wasn’t wrong by the letter of the instruction. It was wrong by the intent.

We locked in-transit orders from automated modification unless explicitly confirmed. Added before/after state logging tied to conversation context.

But here’s the real issue: that failure mode wasn’t in our test cases. We didn’t predict it. The system behaved literally.

Governance isn’t just about restricting access. It’s about restricting interpretation.

Fraud detection fails and the agent keeps approving

We tested an AI refund agent. It analysed order history, return patterns, and fraud signals. Accuracy in testing: 94%.

Then we simulated an upstream failure. The fraud detection service went down and started returning empty responses.

The agent kept running.

It approved 47 refund requests in 11 minutes. Total value: $18,000.

No fraud signals meant no fraud flags. The logic was technically sound.

Operationally, it was a disaster waiting to scale.

We added circuit breakers. If fraud data is unavailable, the agent stops processing. We implemented financial thresholds - above $500, human review is mandatory. We added service health checks before the agent sees a request.

Every decision now gets logged with full context: what data was retrieved, what was missing, what was considered, and what action was taken.

When these systems fail, they fail fast.

The unanswered questions

If an AI agent places an order using the wrong address, who’s liable?

If it cancels a subscription the customer didn’t clearly authorize, who refunds the loss?

If it approves fraudulent refunds because upstream data failed, who eats the cost?

Most retail orgs are tracking model accuracy and customer satisfaction.

Almost none have clear answers to those questions.

Accuracy isn’t enough.
Autonomy must be controlled.
Accountability must be defined before something breaks.

What AI forces us to confront

AI doesn’t just require better data protection. It requires governance of decisions.

You now have to answer:

• What data can this system see?

• What actions can it trigger?

• What is the blast radius if it’s wrong?

• Who owns accountability for automated judgment?

Most retail leaders are benchmarking model accuracy and tracking CSAT.

Very few are mapping action authority.

We started testing these systems like attackers, not just users. Prompt injection attempts. Cross-role retrieval. Boundary stress testing. Simulating upstream failures.

Governance must be testable. Not documented and forgotten.

The structural evolution

Traditional ecommerce governance protected databases.

Omni-channel governance protected data movement.

Marketplace governance protected ecosystem boundaries.

AI governance must protect decisions and actions.

And protecting decisions requires something most organizations still don’t have:

Clear ownership of automated authority.

If an assistant recommends a refund, that’s a suggestion.

If it executes the refund, that’s delegated power.

The difference matters.

What needs to change

If you’re deploying AI agents in retail and you haven’t defined:

• Action boundaries with explicit confirmation gates

• Dependency health checks and circuit breakers

• Per-session and per-action spend limits

• Full decision logging for audit and analysis

• Clear liability ownership when automated decisions fail

Then you don’t have AI governance.

You have automation with fingers crossed.

AI will not break retail because it hallucinates.

It will break retail because we granted execution authority before designing guardrails.

And the retailers who build constraints before convenience are the ones who will scale without burning customer trust.

Share

Leave a comment

I’ve been in tech long enough to see tools change how we work. IDEs, Stack Overflow, automated testing - each one made us faster. None of them made me worry about whether we were still thinking.

AI is different.

Last month, I sat through a sprint review that should’ve been routine. My team had crushed their goals. Five developers with good mix of experience, couple of folks with 2-3 years, rest are veterans - shipped features early. Velocity was up 40%. The demo was flawless.

Then the client asked a simple question: “Can you walk me through your implementation strategy? Why did you choose this approach?”

Silence.

The senior developer fumbled. The mid-level engineer opened their IDE like the answer might be hiding in the code. Nobody could articulate why the solution worked, just that it did.

After the call, I went back through the code. The comments were suspiciously polished. The optimization patterns looked textbook. I asked one of the developers about a specific refactoring choice.

“Oh, I just fed the review feedback into Claude and applied what it suggested.”

The code worked. Tests passed. Client was happy with the output.

But nobody from my team - not even the people with ten years of experience could explain the thinking behind what they’d built.

They’d outsourced the reasoning whereas they were supposed to outsource the typing.

This Isn’t About One Team

That sprint review was six weeks ago. Since then, I’ve been watching more carefully - not just developers, but across the whole delivery chain.

The pattern shows up everywhere.

Developers who can generate clean code but can’t debug without Copilot running. When I ask them to trace through a problem manually, they stare at the screen like I asked them to do long division without a calculator. The muscle for analytical thinking is atrophying. They’ve become managers of AI output, not engineers.

Business Analysts handing me requirements documents that look impressively thorough - detailed user stories, edge cases documented, acceptance criteria spelled out. But when I ask about a specific business rule buried in story #8, they pause. “Let me check my conversation history with ChatGPT.” They generated the requirements through prompts. They can’t defend the logic without going back to the source chat.

QA engineers with test coverage numbers that look better than ever. But last week, an edge case we’ve hit three times in production wasn’t caught - again. When I reviewed the test plan, it was AI-generated based on happy-path scenarios. The weird, “this shouldn’t happen but users will definitely try it” cases? Never considered. AI optimizes for obvious. QA’s job is to think adversarial.

This isn’t about people being lazy. It’s about an entire software development lifecycle where thinking has become optional.

The COVID Education Gap

There’s a pattern I can’t ignore: this problem is significantly worse among people who started their development or testing careers after 2020.

Not universally and there are exceptions. But the trend is clear enough that I’ve stopped thinking it’s coincidence.

Here’s what I think happened as per my understanding.

The COVID disruption broke something in technical education that we haven’t acknowledged yet.

When the world went remote in 2020, most educational institutions weren’t ready. Not because teachers weren’t good, but because the infrastructure wasn’t there. The pedagogy hadn’t caught up. Teaching someone to code isn’t like teaching them history - you can’t just put a lecture on Zoom and call it equivalent.

What got lost in that transition:

The debugging sessions at 11pm in the computer lab where you and three classmates stared at the same error until someone spotted the logic flaw. That collaborative struggle - where you talked through the problem, defended your assumptions, got challenged by peers - that’s where analytical thinking gets forged.

The in-person code reviews where a professor physically walked through your logic, line by line, asking “why did you do it this way?” You couldn’t hide behind working code. You had to articulate your reasoning.

The hallway conversations where you overheard seniors debugging something obscure and absorbed problem-solving patterns osmotically. The casual “oh, I hit that issue last semester, here’s what I learned” exchanges that don’t happen in asynchronous Slack channels.

The hands-on lab work where you actually broke things, dealt with real errors, and couldn’t just Google your way out because the professor was watching and wanted to see your thought process.

That entire layer of learning-by-struggling-together got flattened into “watch this video, submit your assignment, pass the automated tests.”

So a generation of developers graduated having learned coding syntax but not coding reasoning. They learned to make code work, but not how to think through why it works.

And then they entered the workforce right as AI coding assistants became ubiquitous.

AI became the holding hand they never had in school.

You prompt, get code, it works, you’re done. No need to think through the logic. No need to debug manually. No need to wrestle with why something broke.

I want to be clear: this isn’t their fault. They didn’t choose to have their education disrupted. They didn’t intentionally skip the foundational struggle. They’re doing what makes sense in the environment they entered.

But the result is the same: a cohort of technically capable people who never built the muscle for reasoning through problems without AI assistance.

And now, three or four years into their careers, that gap is becoming visible.

The senior developers on my team - the ones who learned to code in 2015, 2012, 2008 - they use AI too. Heavily. But when I ask them to explain their approach, they can. When Copilot is down, they’re annoyed but functional. When something breaks in production, they know how to trace it.

The post-2020 folks? Many of them are legitimately stuck without the tool. Not because they’re less smart. Because they never had to build the foundational skills that let you operate independently.

AI didn’t make them dependent. It arrived exactly when they needed scaffolding most - and became structural instead of temporary.

And here’s the uncomfortable part: I don’t know how to fix this at scale.

You can’t recreate four years of missed foundational struggle in a two-week bootcamp. You can’t retroactively give someone the experience of debugging for six hours straight until they finally understand pointers or recursion or state management.

What I’m trying with my team and this is still experimental - is creating artificial constraints:

• “No AI for the first implementation” rules on critical features

• Pairing junior developers with seniors for debugging sessions where AI is off

• Code reviews that focus on “walk me through your thinking” rather than “does it pass tests”

• Dedicated time for “struggle work” where the goal isn’t shipping, it’s understanding

It’s slow. It’s frustrating for people who’ve learned that fast prompting equals productivity. Some of them resist it.

But the alternative - a generation of engineers who can execute but can’t reason — that’s not sustainable.

Not for them. Not for the teams that depend on them. And not for an industry that needs people who can think, not just prompt.

Why This Is Different

Every previous tool made us faster at executing. AI is making us faster at not thinking.

Excel didn’t make you forget math. You still had to know what formula to use and why.

IDEs didn’t make you forget syntax. They just saved you from memorizing semicolons.

Stack Overflow didn’t make you forget how to reason. It gave you reference implementations you still had to adapt and understand.

But AI does the thinking. It doesn’t just help you execute your approach — it generates the approach. And when you can get a working solution in 30 seconds without understanding it, why would you spend 30 minutes struggling to figure it out yourself?

The incentives are broken. We’re optimizing for output without understanding.

And we’re calling it productivity.

The Training Data Paradox

Here’s what keeps me up at night.

Every AI coding assistant - GPT-4, Copilot, Claude, all of them - was trained on millions of hours of human developers doing the hard work:

• Debugging weird edge cases

• Finding creative solutions to problems nobody had solved before

• Thinking through scenarios no one had considered

• Making architectural choices and documenting why

That corpus of human reasoning is what made these tools useful.

But now developers are using AI to skip that exact thinking.

So where does the next generation of training data come from?

If BAs stop thinking through business scenarios and just prompt for requirements... If QAs stop hunting edge cases and just generate happy-path tests... If developers stop debugging and just ask AI to fix it...

We’re not just losing skills. We’re poisoning the well.

AI tuning AI has limits. The breakthroughs - the creative solutions, the “wait, what if we tried THIS” moments - those come from human brains wrestling with hard problems.

I do use AI for my work and I’m not anti-AI. I’m watching this daily. And what I’m seeing is a recursive collapse problem that nobody’s talking about.

If we outsource struggle, we don’t just make ourselves weaker. We make the next generation of AI weaker too.

What Actually Breaks

These aren’t theoretical concerns. I’ve seen what happens when teams lose the ability to think through their own systems.

Client trust evaporates when you can’t answer “why did you build it this way?” I’ve sat through enough awkward calls to know that “the AI suggested it” doesn’t inspire confidence.

Systems become fragile when nobody understands them. At 3am, when production is down and customers are losing money, you need engineers who can reason through the problem. Prompting ChatGPT doesn’t work when the problem is novel.

Junior developers never become senior if they skip the struggle that builds judgment. You don’t learn systems thinking by watching AI generate code. You learn it by making mistakes, debugging them, and understanding why they broke.

Entire organizations become dependent on tools they don’t control. What happens when the API goes down? When the model changes behaviour? When you need to do something the AI wasn’t trained for?

I’ve been in retail tech for twenty years. I’ve seen what happens when systems hit Black Friday traffic, edge cases nobody predicted, load patterns that break assumptions. That’s when you need people who can think, not just prompt.

What I’m Trying To Figure Out

I don’t have this solved. I’m wrestling with it alongside my team.

But here’s what I’m seeing work:

Use AI after you think, not instead of thinking. First pass without AI for critical features. Understand the problem, sketch the approach, identify the edge cases. Then use AI to help you execute faster. The thinking has to be yours.

Code reviews that require “why,” not just “what.” I don’t care if the code works. I want to know why you chose this approach. If the answer is “AI suggested it,” we’re not done.

Distinguish scaffolding work from thinking work. AI is phenomenal for boilerplate, refactoring, documentation, test generation — the grunt work. But for architecture decisions, debugging complex issues, thinking through business logic? That needs human brains engaged.

Create space for struggle. The uncomfortable moment when you don’t know the answer — that’s not wasted time. That’s where learning happens. Let people sit with problems before reaching for AI.

I use AI myself. Mostly as a first draft to save typing, then validate whether my thinking aligns with what it generated. The thinking comes first. The tool comes second.

That order matters more than people realize.

The Uncomfortable Question

I’ve been in tech long enough to see multiple generations of developers come up. The ones who learned in the Stack Overflow era. The ones who learned with GitHub Copilot from day one. The ones whose education got disrupted by COVID and graduated straight into an AI-assisted world.

Each cohort has different strengths. Each has gaps.

But this is the first time I’ve seen a gap in foundational reasoning - and it’s not because people are less capable. It’s because the circumstances of their education, combined with the timing of AI tool availability, created a perfect storm.

We’re moving faster than ever. Shipping more code. Completing more sprints. Hitting more deadlines.

But are we building anything we truly understand?

And when it breaks - and it will, because everything eventually breaks - who’s going to fix it?

I’ve been the developer writing the code, the BA gathering requirements, the tech lead managing the team, the architect designing the system. Every role that argues in the room, I’ve been in that chair.

And from every angle, I’m seeing the same thing: we’re training a generation of people who can execute but can’t reason. Who can generate but can’t debug. Who can optimize for velocity but not for understanding.

We can fix this. But not by banning AI. And not by expecting people to retroactively develop skills they never had a chance to build.

We fix it by being intentional about where AI helps and where it hinders. By creating space for struggle. By valuing understanding as much as we value velocity.

And by recognizing that the developers entering the workforce today didn’t choose this situation - but they’ll live with the consequences if we don’t address it.

Because the moment we stop wrestling with hard problems, stop hunting edge cases, stop asking “why” instead of just “does it work”...

We don’t just lose our skills.

We lose the ability to create what comes next.

And that’s not a productivity problem. That’s an existential one.

If you’ve seen this pattern in your team or if you’ve figured out how to use AI without losing the thinking muscle - I’d genuinely like to hear about it. I’m still working this out myself, and the best insights come from people in the trenches.

Drop a comment or reply. Let’s figure this out together.

Leave a comment

Share

Single page or multi-step.
Guest checkout or login.
Payment first or address first.

But checkout design isn’t really about patterns but more of what you assume about the buyer at that moment.

Do they trust you?
Do they have time?
Do they already know what they want?
Are they buying for themselves - or someone else?

The answers change everything.

Why Amazon’s “Buy Now” works

Amazon’s one-click or “Buy Now” flow is often treated as the gold standard of checkout speed. But speed isn’t the real achievement here. Certainty is.

Amazon already knows:

• Where the order will be delivered

• How it will be paid for

• What happens if something goes wrong

The checkout isn’t removing steps.
It’s removing decisions.

That only works when trust has already been earned - through delivery reliability, returns, customer support, and repetition. One-click checkout isn’t a UX trick. It’s a reward for familiarity.

Most stores don’t start from that position, and pretending otherwise is how checkout breaks.

Platform defaults are not accidents

If you’ve implemented checkout on platforms like Magento or Shopify, you’ve seen this first-hand.

The default templates:

• Feel rigid

• Resist reordering

• Push back when you add or move fields

That resistance isn’t laziness. It’s intentional.

Those flows are shaped by validation logic, payment rules, address resolution, fraud checks, autofill behaviour, and mobile constraints.

You don’t “move a field.”
You move a dependency.

I’ve seen teams design a checkout that looks perfect, only to hit PCI reality. A payment provider hands you an iframe - or forces a redirect to a hosted page. Suddenly you’re trying to maintain visual continuity across a boundary you don’t control.

Some providers allow limited styling. Others allow almost none. And then come the edge cases: the iframe doesn’t load, the redirect fails, the user hits “back” after entering card details.

The checkout you design and the checkout that ships are often two different things - not because of bad planning, but because payments live outside your domain.

This is also why checkout customization is harder than landing page customization. The system is protecting itself from states that break fulfilment, payments, or trust.

A headless approach gives more freedom, but not less work. You gain control - and with it, the responsibility to rebuild the guardrails platforms normally give you for free.

Checkout is a fragile system, not just a UI

Checkout is often the most complex form on an ecommerce site.

Not because it has many fields - but because everything connects to it.

Payments. Coupons. Discount rules. Cart logic. Inventory checks. Shipping calculations. Fraud signals.

A small change in one place can ripple through the entire flow.

Coupons are a good example.

On the cart page, applying or removing a discount is relatively safe. The user hasn’t committed yet. But at checkout, everything is already in motion.

Remove a coupon and the totals change - often across multiple items. That usually triggers a refresh. Which means:

• Shipping selections might reset

• Entered addresses could be lost

• Payment details must be re-entered

• The user shifts from “almost done” to “something broke”

Now you have decisions to make. Do you allow coupon changes at checkout at all? Do you support multiple coupons? Do you lock discounts once checkout starts?

There’s no universal right answer. But the wrong answer is assuming it’s just another field you can add anywhere.

This is why checkout is one of the easiest places to accidentally break a site. A new field can interfere with autofill. A reordered block can affect validation timing. A visual tweak can slow page load just enough to matter.

Performance matters here more than almost anywhere else. Checkout is where latency is felt most sharply, especially on mobile networks. Every extra script or re-render competes directly with intent.

Multi-step checkout adds another layer of fragility. Once a user moves forward, the system has to reliably retain state - addresses, shipping choices, discounts - while handling refreshes, back navigation, payment failures, and timeouts.

When this breaks, users don’t always retry. They leave.

This is why platforms are conservative about checkout customization. They aren’t just protecting patterns. They’re protecting state, consistency, and recoverability.

When flexibility becomes fragility

Some businesses push for maximum flexibility at checkout: item-level shipping addresses, quantity-level splits, “send part of the order here and the rest there.”

On paper, it sounds customer-friendly. In practice, it’s an architectural risk.

You’re now managing:

• Multiple shipping calculations

• Split inventory allocations

• Separate delivery timelines

• Complex state persistence

The UI starts to resemble a spreadsheet. The backend becomes fragile. And unless the person making changes deeply understands the flow, every edit risks collapse.

I’ve seen this in B2B and gifting contexts, where it’s sometimes justified. But for general retail, it’s rarely worth the complexity.

The more flexibility you add, the more you ask users to solve a logistics problem while they’re trying to buy something.

Most people don’t want that responsibility.

Single page, multi-step, billing first, shipping first

These aren’t preferences. They’re assumptions.

Single-page checkout assumes:

• The buyer is ready

• The product is familiar

• The risk is low

Multi-step checkout assumes:

• Reassurance matters

• Confirmation reduces errors

Shipping-first flows assume:

• Delivery feasibility matters more than payment

Billing-first flows assume:

• Delivery is trivial

• Payment is the real gate

None of these are right or wrong.
They simply reveal what the system believes about the purchase.

Mobile changes the rules quietly

Most checkout friction doesn’t come from complexity.
It comes from violating muscle memory, especially on mobile.

People don’t read forms carefully on small screens.
They recognize patterns.

First name → last name
Address → city → postcode
Card number → expiry → CVV

These are not standards. They’re learned sequences.

When a form breaks that sequence:

• Typing slows

• Autofill fails

• Errors increase

• Doubt creeps in

Geography plays a role here - not as localization, but as behaviour. Name structures, address expectations, and input flows differ across regions. Checkout quietly assumes a lot about how people describe themselves.

The more unfamiliar the product, the less tolerance users have for unfamiliar forms.

Urgency changes everything

Most checkout flows assume the user has time but sales don’t.

During sales or limited-inventory moments:

• Speed matters more than reassurance

• Typing becomes the bottleneck

• Multi-step flows feel heavier

This is why saved addresses exist. Stored payment methods exist. Wallets exist. Express checkout appears conditionally.

Urgency turns checkout from a decision flow into an execution flow.

Instant payment options aren’t just about convenience. They’re about certainty under pressure.

Why product context matters more than patterns

An online cake shop doesn’t sell objects.
It sells coordination.

Delivery date, time slot, and location matter more than payment speed. Checkout here is about reducing the chance of something going wrong, not finishing fast.

A gifting portal carries emotional risk. The buyer wants reassurance:

• That the message is correct

• That delivery will happen

• That mistakes can be fixed

Here, confidence beats speed.

Forcing a universal checkout pattern across these contexts usually hurts more than it helps.

A quieter way to think about checkout

Checkout isn’t where people decide to buy.
It’s where they decide whether they still feel safe doing so.

Platforms, patterns, acceleration features, and defaults all exist to manage that feeling - under different assumptions about trust, time, and intent.

There is no best checkout.
Only a checkout that matches what you’re selling, who you’re selling to, and the moment they’re in.

The best checkout isn’t the most flexible one.
It’s the one that matches how people actually think when they’re trying to buy something.

Checkout is not a design problem to solve once.
It’s a system of assumptions to keep aligned - between users, platforms, and reality.

Everyone talks about loyal customers like they exist in a vacuum. But the truth? Most of them vanish the second a better deal comes along.

I hear a lot of brands talk about “loyal customers” like it’s some mystical thing. But working on ecommerce solutions every day, the reality looks very different.

Most customers aren’t loyal to a store. They’re loyal to what’s convenient, easy, or cheap. And in today’s world of endless apps, marketplaces, and aggregators, staying loyal is actually hard.

Sure, discounts and cashback keep people coming back. That’s the easiest lever to pull. But it’s fragile. If you pause the promo for a week, and most “loyal” users jump to whoever is cheaper.

We learned this the hard way. Early in one project, we assumed freebies and heavy discounts would build a loyal customer base for the future. We poured money in, expecting these users to stick. When we finally looked at the analytics, the story was different - only 2% returned.

That 2% number sat with us for a while.

So if discounts aren’t the real glue, what is? We started asking the people who came back without a promotion why they did. The answers weren’t glamorous. They liked that they could find what they needed quickly. Checkout didn’t feel like solving a puzzle. When something went wrong, we fixed it fast, without making them jump through hoops.

Boring stuff, right? But that’s what made them feel confident and understood. And when you layer in thoughtful touches - recommendations that actually make sense, clear communication, a brand voice that feels human - you start moving from “I shop here because it’s easy” to “I shop here because it feels right.” That second one is rare, and it sticks.

The tricky part is that most brands treat loyalty like a slogan. “We have loyal customers!” What they often really have is transactional loyalty - deal-driven, fragile, and gone the moment someone else runs a better promo.

After that 2% wake-up call, we changed how we looked at loyalty.

We saw a similar pattern in a very different category.

For a laminates and plywood client, we built a QR-based loyalty system for carpenters and architects. Every purchase earned points, redeemable for gifts. Adoption was strong, scans kept growing, redemptions followed.

Then, as the program scaled, we reduced coupon value by about 10%.

Almost immediately, engagement dipped.

Nothing else changed. Same product. Same brand. Same program.

That’s when it became clear: the loyalty wasn’t to the brand. It was to the reward value. We hadn’t broken loyalty - we had simply tested it.

We stopped treating all customers the same. We created a simple segment: people who came back twice without any discount or promotion. That group became our focus. We cut our first-time discount budget by ~30% and redirected it into things these repeat customers actually cared about - faster delivery windows, better support response times, smoother returns.

The ROI shift was real. Instead of burning budget on people who were never coming back anyway, we invested in a small group building actual lifetime value.

There are three types of loyalty worth thinking about: transactional, operational, and emotional. Discounts drive the first. Smooth, reliable experiences drive the second. And real connection - the kind that comes from feeling understood - drives the third. That last one is rare, but it’s the only one that actually lasts.

If you want customers to stick around, you have to go beyond the easy lever of discounts. Make them feel like they choose you - not because you’re cheaper, but because you work… and sometimes, because you feel right.

If you’re trying to “build loyalty,” start by finding your version of that 2% - the customers who come back even when you give them no reason to.

I don’t think this experience is unique. Most teams working on loyalty probably have a version of this story. The interesting part is understanding what kind of loyalty you’re actually building.

In Part 1, we saw how migrations balloon from $150K estimates to $800K realities - and the data you lose that never shows up on spreadsheets.

In Part 2, we looked at why AI makes this worse, not better. Your platform’s AI learns from your data. When you leave, that intelligence stays behind.

So what do you actually do?

Stop asking “build or buy?” Start asking better questions.

Warning Signs You’re Already Trapped

The migration conversation becomes scary.

Team estimates exceed 6 months. Multiple people say “that’s impossible to extract.” Vendor migration docs are vague or missing. You realize nobody knows what half the integrations actually do.

Workarounds exceed native features.

Your Shopify app count exceeds 15. You have scripts running nightly to “fix” platform limitations. Every feature request starts with “well, the platform can’t do that, but...”

Data requests hit walls.

“We need X data for analysis” → “That’s not exportable.” APIs have rate limits that block meaningful use. Reports come as PDFs, not raw data. Custom fields can’t be bulk-exported.

The vendor feels like a partner you can’t fire.

Upgrade pressure increases because they know you’re stuck. Support quality decreases. Pricing becomes less negotiable. Sales rep stops returning calls.

Your team talks about the platform more than the business.

Engineering stand-ups are 60% platform issues. Board meetings include “platform roadmap” as a topic. Product decisions get blocked by “platform limitations.”

If any of this sounds familiar, keep reading.

Three Questions That Actually Matter

If this platform disappeared tomorrow, how long to replace it?

Be honest with yourself. If the platform went down for good tomorrow:

Back in a week? No real problem. Back in a few weeks? Painful, but manageable.
Back in a few months? You’re betting the business on this platform. No clear answer? That IS the answer. You’re trapped.

If this component gets 10x better through AI, who benefits?

Mostly you - you own the learning loop. Good. Split benefit - acceptable for commodities. Mostly them - you’re funding their competitive moat. Danger.

What would we lose if we decided to leave in 2 years?

List it. Customer behavioural data. Business logic and rules. AI model training and insights. Integration configurations. Historical performance data. Team knowledge.

If that list scares you, you’re already locked in.

The Ghost Data Exercise

Run this with your team this week.

Step 1: List every piece of data or business logic in your platform.

Step 2: Mark each item - YOURS (you could export it fully and use it elsewhere), THEIRS (platform-specific, proprietary, or not exportable), UNCLEAR (you’re not sure who owns it).

Step 3: For everything marked THEIRS or UNCLEAR, ask: could we rebuild this from scratch in 3 months? Do we even know what this does or why it’s important?

Step 4: Calculate your lock-in score. If more than 50% is THEIRS, you’re highly locked in. If you marked lots of UNCLEAR, you’re trapped and don’t even know it.

The results are usually sobering.

What This Looks Like in Real Life

We worked on a Magento Open Source to Shopify migration. Should have been straightforward - we estimated 3 months.

The store had dozens of extensions. Custom code everywhere. Worse: they’d modified the extension code itself. No documentation on what was changed or why.

As we started digging, we discovered the extensions were dumping data in different formats. There was no apple-to-apple mapping between Magento extensions and Shopify apps.

We were bound to lose data. The question was how much.

Six months later, the migration finished. But some data never made it. Customer interaction patterns from certain extensions. Custom pricing logic that was buried in modified code. Historical A/B test results that lived in a now-discontinued plugin.

They’re live on Shopify now. The business runs. But when someone asks “why did this customer segment convert better in Q2 2023?” - the answer is trapped in a Magento backup nobody can query anymore.

This is what “data loss” actually means. Not catastrophic failure. Just questions you can’t answer anymore.

What to Own vs. What to Rent

Always try and own these things:

Customer data and behaviour. Not just contact info - interaction patterns, preferences, journey data. The raw data, not aggregated reports. In a format you control.

Decision logic. Your pricing rules, promotional strategies, product ranking, merchandising rules, personalization logic.

AI experimentation layer. The ability to test different models, keep training data and results, learn from experiments, track model performance history.

Business-critical integrations. Anything that touches customer experience, supply chain connections, inventory and fulfilment logic.

Almost always rent wherever possible:

Infrastructure like hosting, CDN, DDoS protection. These are commodities - switching cost is low, no learning advantage from owning.

Payment processing. PCI compliance is brutal to own. Switching payment processors takes days, not months. No competitive advantage here.

Commodity features. Basic search infrastructure (but own the ranking logic). Email delivery (not email strategy). Tax calculation engines. Shipping rate calculators.

Be careful with anything that:

Improves through machine learning using your data. Contains business logic you can’t easily replicate. Integrates deeply with multiple systems. Holds historical data you’ll need long-term. Your team doesn’t understand well enough to rebuild.

If you can’t clearly articulate the exit cost, you’re probably underestimating it.

When to Walk Away

Sometimes you’re already on a platform and need to decide: stay or migrate?

Stay for now if migration cost exceeds 12 months of margin improvement, business is stable and platform issues are manageable, you’re not losing competitive ground, and team bandwidth is maxed on core business.

Start planning migration if platform costs are growing faster than revenue, competitors are shipping features you can’t because of platform limits, you’re losing customers due to performance gaps, AI capabilities you need aren’t on roadmap or are locked behind premium tiers, or exit cost will only get worse with time.

Migrate immediately if the platform is sunsetting or being acquired, you have security/compliance issues you can’t fix, costs have become unsustainable, or customer experience is suffering measurably.

If you’re spending more time managing platform issues than improving your business, the platform has become the problem.

The Hybrid Reality

Most successful companies run in hybrid mode. They own the data layer, business logic, AI experimentation. They rent infrastructure, commodity tools, compliance-heavy features. They use marketplaces strategically for distribution, but not dependency.

Example: Shopify for storefront (replaceable in 4-6 weeks), AWS for data warehouse (portable), owned recommendation engine trained on your data, Stripe for payments (switchable), own customer data platform.

The key - nothing is so deeply embedded that exit takes more than 3 months.

What You’re Actually Trading

Migration isn’t just hard. It’s lossy.

Especially if you’ve been with them for years and not everything is documented. There were “urgencies,” “quick-fix,” “need-today” moments not captured anywhere.

You leave data behind. Not because you don’t want it, but because the platform won’t let you take it, can’t convert it, or never really let you own it in the first place.

You don’t realize what you’ve lost until six months later when someone asks a simple question and the answer is trapped in a system you no longer use.

This is why the build vs. rent question isn’t about launch speed anymore.

It’s about what you’re willing to lose.

Not just features. Not just flexibility. Your learning. Your intelligence. Your ability to understand your own customers.

Because in the AI era, whoever owns the data owns the learning. And whoever owns the learning compounds competitive advantage quarter after quarter.

Choose dependencies you can afford to lose.

Because one day, you will need to.

What to Do This Week

If you’re evaluating platforms: run the Ghost Data Exercise with your team, run the three-question test.

If you’re already on a platform: assess your lock-in score, look for the warning signs, make a plan.

The goal isn’t to avoid all platforms - it’s to go in with eyes open about what you’re trading and when that trade stops making sense.

Series Wrap-Up

Over these three posts:

• Part 1 - how migrations actually work and why they cost 10x the estimate

• Part 2 - why AI makes platform lock-in worse, not better

• Part 3 - the decision framework that actually works (this post)

Writing Part 3 took the longest, because exit costs are the part most teams avoid thinking about.

The pattern is clear. Entry costs are visible but exit costs are hidden. And in the AI era, the gap between them is getting wider.

Your move is to make ownership decisions that won’t backfire 18 months later.

Coming Soon

Next up: how platform lock-in plays out specifically in the Indian market.

I’ll cover the Reliance/Jio ecosystem trap, quick commerce lock-in (Blinkit, Zepto, Swiggy), and why international platforms create different problems in India. If you’re building a D2C brand in India, you’ll want to read this.

📬 Subscribe to get it in your inbox when it drops.

Have questions about this series? Hit reply. I read every response.

Read the series:
← Part 1: The $800K Migration Nobody Saw Coming
← Part 2: Why AI Makes Lock-In Worse

Thank you for reading this series. If it helped you think differently about platform decisions, share it with your team or someone evaluating platforms right now.

In Part 1, we have seen how a $150K migration turned into $800K - and why teams lose critical data they didn’t even know was at risk.

That was the old lock-in. You were trapped by their features.

The new lock-in is worse and you’re trapped by their learning.

The Learning Lock-In

When Shopify’s AI gets better at product search, all Shopify stores benefit. Including your competitors. Your customer data trains their models. Your buying patterns improve their recommendation engine.

When Amazon’s algorithm optimizes product rankings, Amazon learns. You just execute.

When the marketplace improves personalization, their AI gets smarter. You get access to the output, but zero insight into why it works or how to replicate it.

Old world lock-in: You couldn’t change features easily. You had to wait for new features based on their roadmap.

AI era lock-in: Your competitive intelligence goes to zero while the platform gets smarter using your data.

You’re paying them to train models on your customers, improve their AI with your behaviour data, build competitive moats using your insights, and sell those improvements back to you as “features.”

When you try to leave? All that learning stays behind.

The AI Migration Myth

There’s a new assumption I keep hearing in platform discussions:

“Even if migration is painful, AI will make it faster and cheaper when the time comes.”

Sounds reasonable, right?

AI can read messy schemas, map fields, transform formats, generate migration scripts. So why worry about lock-in now? We’ll just use AI to migrate later.

This doesn’t work in reality.

AI helps with translation. It does not solve extraction, completeness, or trust. And those are the parts that dominate migration cost and risk.

Where AI Actually Helps

AI does reduce effort in specific tasks:

Interpreting undocumented schemas and poorly named fields. Mapping old structures to new data models. Transforming data formats - flat to nested, JSON to relational. Cleaning inconsistent text. Migrating CMS content. Generating one-off scripts and reconciliation checks.

This saves time on mechanical work.

It doesn’t change the overall shape of the migration.

Where AI Actually Breaks Down

The Access Problem

If the platform won’t give you raw behavioural events, historical personalization data, or experiment-level results, there’s nothing for AI to work with.

AI can’t magically extract data that was never made available.

If all you get are aggregated reports, PDFs, sampled datasets, or rate-limited APIs, then AI is working with lossy inputs. The result will be lossy too.

No model can reconstruct data that was never there in the first place.

The Invisibility Problem

AI migrates what it can see. It won’t warn you about what never arrived.

Six months later, someone asks:

“Why can’t we explain churn the way we used to?”
“Where’s the logic behind those customer segments?”
“Why do recommendations behave differently now?”

Only then do teams realize: Certain datasets were never exported. Key logic lived inside the platform. Parts of the system were out of scope without anyone noticing.

AI didn’t fail.

The assumption that “everything important will come over” failed.

The Validation Problem

Even with AI-assisted migration, teams still have to answer: Does this data mean the same thing as before? Are timestamps aligned correctly? Are nulls real, or introduced during transformation? Did business rules change subtly in the process? Do downstream systems behave the same way?

AI can suggest checks. It cannot certify correctness.

Most migration overruns happen here - during reconciliation, validation, and fixing edge cases that only show up under real traffic.

I watched one team spend three months on “the last 10%” because AI had migrated everything perfectly... except it had silently converted all their datetime fields to UTC, breaking every report that depended on local time zones.

The Logic Problem

Platforms don’t just store data. They execute decisions.

Ranking rules. Personalization thresholds. Pricing constraints. Fallback behaviours. Workflow conditions.

Much of this logic is configuration-driven, undocumented, and evolved incrementally over years. AI can read code if you have it. It cannot reconstruct logic that lived inside a black box.

Teams end up rebuilding by reverse-engineering behaviour, running systems in parallel, comparing outputs, guessing why results differ.

Slow. Expensive. Rarely perfect.

What AI Actually Changes

AI reduces the cost per unit of effort.

It does not reduce the amount of effort required.

People assume AI will make migrations easier. It helps in some places—translating logic, mapping schemas - but it doesn’t solve the hard parts.

If the platform won’t let you extract something, AI can’t magically pull it out. And it definitely can’t tell you what you’re missing until it’s already broken in production.

Migration is still constrained by what you’re allowed to extract, how complete those extracts are, how much logic lives outside your control, and how confident you need to be in the final result.

In some cases, AI even increases risk by creating false confidence early in the process. The CTO sees AI migrate 80% of the data in a week and thinks, “Great, we’re almost done.” Then spends the next six months on the remaining 20%.

Better Question

Instead of asking “Can we use AI to migrate this later?”

Ask: “If this platform limits what we can export, what will AI actually have to work with?”

If the answer is reports, aggregates, summaries, or platform-defined schemas—AI won’t change the outcome.

You’re still locked in. Just with better tools when you try to leave.

The Core Problem

AI doesn’t reduce platform lock-in.

It makes ownership decisions more important.

If you don’t own the raw data, the decision logic, and the historical context—AI helps you migrate the surface. The intelligence stays behind.

This is why the build vs. rent question isn’t about launch speed anymore. It’s about what you’re willing to lose when you eventually need to leave.

Coming Next: The Decision Framework

Migration is brutal. AI makes lock-in worse. So what do you actually do?

In Part 3, I’ll share the decision framework that actually works:

• When to own vs. when to rent

• The three questions that reveal if you’re already trapped

• What to do if you’re on a platform right now

• How to make build vs. buy decisions that won’t backfire 18 months later

📬 Subscribe to get Part 3 in your inbox next week - I’ll show you the exact framework for deciding what’s worth owning, and what you can safely rent without getting locked in.

Already subscribed? Hit reply and tell me:

• Are you relying on your platform’s AI features?

• Have you thought about what happens if you need to migrate?

• What data would you lose that you don’t have access to export?

Part 2 of 3: The Migration Tax Nobody Talks About

← Read Part 1 https://opplearner.substack.com/p/platform-lock-in-in-the-ai-era

I’ve sat through dozens of build vs. buy debates over the years. They all start the same way.

“We want to launch fast.”
“We want control.”
“We want to own our data.”
“But we don’t want to run infrastructure.”

Pick a platform, accept some limits, move on and that used to work since many years.

What nobody talks about is what happens two years later. Not during launch. Not during growth. But when the platform starts pushing expensive upgrades, performance slips, your custom workarounds break - and someone in leadership finally asks:

“What would it take to move?”

That’s when you find out what you actually signed up for.

Entry cost? That was on a spreadsheet. Clear. Budgeted.

Exit cost? Nobody mentioned that. And it’s usually 10x higher.

This is Part 1 of a short series about the migration tax that hits 18-24 months after you choose a platform. By then, it’s too late.

The Pattern

I’ve watched this play out at least a dozen times:

Month 0-6: Launch on Platform X. Fast, clean, everyone’s happy. Marketing runs campaigns, sales grow, the platform “just works.”

Month 12-18: Performance starts degrading. Site gets slower. Platform says “you’ve outgrown the standard tier - time to upgrade to Enterprise.” New price: 3-5x what you’re paying now.

Month 18-24: Custom integrations start breaking. The workarounds your team built stop working after platform updates. You need their premium support package.

Month 24-36: Someone asks: “Should we consider switching platforms?”

You run the migration estimate.

You realize: you’re trapped.

What Migration Actually Looks Like

Everyone talks about vendor lock-in. Almost no one talks about what migration actually looks like, which is the messy reality of moving data and content to a new platform.

I’ve watched teams spend 18 months and $800K trying to migrate. And they still left behind data they needed six months later.

The Optimistic Beginning

Vendor estimate: “6-8 weeks for data migration, pretty straightforward”

Your team estimate: “Maybe 3-4 months if we’re careful”

Reality: 12-18 months. 3x budget. Team burned out.

The Data Negotiation

You start asking for your data.

You: “We need to export our customer data.”
Them: “Sure, here’s the standard export format.”

You: “Where’s the customer behaviour history? The interaction patterns?”
Them: “Different format. We can provide aggregated reports. Fixed format.”

You: “What about the custom fields we added over the years?”
Them: “Platform-specific extensions. Not included in standard export. Need additional efforts.”

You: “The product recommendation performance data?”
Them: “That’s generated by our proprietary algorithm. Not exportable.”

You: “The A/B test results from the last 3 years?”
Them: “We can give you summary PDFs. The raw experimental data stays in our analytics system.”

What You Actually Leave Behind

By the time migration is “complete,” what have you lost?

Eighteen to thirty-six months of customer interaction patterns. All your A/B test results - you get summaries, but the raw data? Still locked in their analytics system. The custom workflow logic you embedded over the years. Integration configs that “just worked” and nobody documented because they just worked.

Historical pricing data. Support ticket context. Seasonal buying patterns. Customer segments you spent years defining.

The list goes on.

And here’s the tragedy: You don’t know what you’re losing until you need it.

The “Support” Reality

The platform does provide “migration support.”

Translation: You get their export format. Good luck if it doesn’t match your new system. You get their schema - your new platform uses different structures. You get their timeline - migration requests processed in 5-7 business days. You get their terms: “We’ve provided the data export. Implementation is your responsibility.”

Want better migration support? Premium package: $25K-50K.

And even then, they won’t help you replicate custom logic, fix data integrity issues, or translate their proprietary features to something generic. If your original team is gone and nobody remembers what certain fields mean? Your problem. Anything that breaks after migration? Also your problem.

The Ghost Data Problem

When you come back after six months of migration:

Sales team: “Why can’t I see why Customer X stopped buying last year? We used to have that data.”
You: “That behavioural data didn’t migrate. It was in their proprietary format.”

Marketing: “Where’s the customer segmentation logic we spent 2 years building?”
You: “It was embedded in their system. We couldn’t extract the rules.”

Operations: “Our conversion rate dropped 15% after migration. Why?”
You: “We lost the personalization rules. Trying to rebuild them but it’s guesswork.”

Finance: “The pricing optimization isn’t working like before.”
You: “The historical pricing performance data didn’t come over. We’re starting from scratch.”

You’re not just switching platforms.

You’re lobotomizing your business intelligence.

A Real Example

Mid-size DTC brand. Five years on Platform A. $15M annual revenue.

The problem: Platform performance was degrading and costs were increasing. They wanted more control over customer experience and AI capabilities.

The decision: Migrate to Platform B for better flexibility and data ownership.

The estimate: Four months. $150K. Manageable risk.

What actually happened:

Fourteen months later, they were still cleaning up. The budget had blown past $400K once you counted consultants, internal dev time, rework. At some point they stopped tracking everything.

The team was exhausted. Revenue took a $300K hit in the first six months because conversion rates dropped during the transition. And two years later, they’re still finding bugs from the incomplete migration.

But the worst part is that after eight months in, they discovered they’d lost the customer segment data that explained their entire seasonal buying strategy. Gone. It took another six months to rebuild from scratch.

It was never quite the same.

Total real cost: 10x the initial estimate.

Feature parity with what they had before? Still don’t have it.

I remember the quarterly review meeting where they had to explain this to the board. The CTO had a spreadsheet titled “Things We Lost in Migration” with 47 rows. They’d been on the new platform for three months.

Nobody asks about exit costs during the vendor pitch.

Coming Next

Migration is already brutal.

But most teams don’t realize there’s a hidden factor that makes it 10x worse - and it’s getting worse every quarter.

Part 2 explains why AI doesn’t make migration easier, but it amplifies the risk. You’ll see why relying on your platform’s AI features, their recommendation engine, or thinking “we’ll handle migration later with AI” backfires spectacularly.

📬 Subscribe to get it in your inbox - I’ll show you the exact moment teams realize what they actually lost, and why the “AI will make migration easy” assumption is dangerously wrong.

Already subscribed? Hit reply and share your experience:

• Have you been through a platform migration?

• What unexpected costs did you face?

• What data did you lose that you didn’t expect?

Part 1 of 3: Platform Lock-In in the AI Era

Subscribe now

“Agentic AI” sounds exciting - systems that think, decide, and act for you. But what if most of what we call agentic today isn’t agentic at all and what if your “smart AI tool” is really just a bot in disguise?

Everyone is selling “agentic AI” now. But did you know that most of what vendors call “agentic” is just automation with better marketing?

If you’re a product manager, engineer, or ecommerce operator - someone who ships features, wrestles with trade-offs, and explains these concepts to leadership - this post is for you. We’ll explore familiar ecommerce problems and show how the same use case can look very different depending on its level of autonomy. Along the way, we’ll reference real-world examples from major platforms and industry leaders to keep the discussion grounded.

This post is a practical lens to bring clarity to a space full of fuzziness - and to give you language you can actually use.

In this post, you’ll see how the same ecommerce problem can be handled differently at four levels of AI capability - and why understanding that matters when you’re building products. These levels are not industry defined, but a simple way to group things. These are grouped as most "AI" falls into one of four categories. Understanding which one you're dealing with saves you from overpaying for glorified automation.

A simple framework: four levels of AI

Think of AI not as a single label, but as a spectrum of capabilities:

Chatbots – responds when asked

Automated Rules– acts when triggered by rules

Workflow – orchestrates multiple steps with state

Agentic – pursues goals and chooses actions autonomously

Most real-world systems today operate between bots, automation, and workflows. That’s intentional. Commerce values predictability and trust far more than flashy autonomy.

We will talk about few use cases and classify them into the above framework to distinguish between AI and Agentic.

Use Case 1: Order Support & Customer Service

The question “Where is my order?” seems simple, but how AI handles it changes drastically depending on autonomy.

Chatbots: reactive and simple

Customer asks for order status and system fetches tracking info and responds
Stateless, no initiative, very low risk

Automated Rules: triggered action

If delivery is delayed > 48 hours → send an apology email or coupon
Acts without being asked, but rule-based and predictable

Workflow: orchestrated sequences

Detect delay → check carrier SLA → update inventory → notify customer → open support ticket if unresolved → escalate if necessary

Multiple systems coordinated, process is stateful, medium initiative, moderate risk

Agentic: goal-directed resolution

Goal: resolve customer issue with minimal cost and minimal churn

Chooses between refund, replacement, or proactive outreach. Factors in customer history and lifetime value and learns which actions reduce churn over time

High initiative, adaptive decision-making, higher risk - true agentic behaviour

The difference is not the technology - it’s what the system is trying to achieve and how independently it decides.

Which level do most of your tools fall into?

Next, let’s look at content and catalog problems - another area where AI is everywhere but true autonomy is rare.

Use Case 2: Catalog Enrichment & Product Content

Content is king - but AI approaches differ drastically.

Chatbots: generate a product description on request
Automated Rules: automatically enrich new SKUs with descriptions or images
Workflow: run content pipelines across multiple systems, check compliance, localize, and push to storefront
Agentic: identify underperforming products, decide which content to improve, test variations, and iterate autonomously to optimize conversion

Real-world examples from industry leaders show that most deployments stop at automation or workflow. Agentic implementations remain rare, especially in production.

Could your team benefit from moving from automation to workflow, or is agentic too risky right now?

Use Case 3: Merchandising & Optimization

Chatbots: “Which products are trending?” → returns analytics
Automated Rules: Boost high-conversion products, suppress out-of-stock items automatically
Workflow: Coordinate pricing, inventory, and ranking updates across multiple systems
Agentic: Optimize merchandising strategies dynamically based on conversion, margin, and churn, making autonomous trade-offs across the catalog

Again, most platforms today operate around workflows - true agentic autonomy remains aspirational for many ecommerce teams.

Where the Big Platforms Actually Are

Honestly, looking at what what Shopify, BigCommerce, and Adobe Commerce actually offer, is not Agentic as of now:

• Lots of chatbots (product recommendations, basic support)

• Heavy automation (inventory sync, order routing, abandoned cart emails)

• Some workflows (multi-step abandoned cart sequences, review request flows)

• Almost zero true autonomy (because trust matters more than flash)

This isn’t a criticism. Ecommerce needs predictability. You can’t let an AI randomly decide to discount everything 50% because it “learned” that increases conversions.

Full autonomy isn’t always desirable. Predictability, auditability, and trust are more important in commerce than flashy agentic behaviour.

Why the distinction matters

If you don’t know what level you’re operating at, things might go wrong:

Your CEO thinks you bought autonomy. You bought automation.
Now they expect the system to “handle it” when it really needs constant babysitting.

You underestimate the testing required.
Automation breaks in predictable ways. Autonomy breaks in creative, expensive ways.

You blame “AI” when things fail.
Maybe the AI is fine. Maybe your rules were shit.

The Real Question Isn’t “Is This Agentic?”

It’s “How much autonomy does this problem actually need?”

Customer support for high-value clients? Maybe you want autonomy.
Bulk catalog updates for commodity products? Automation is fine.
Anything involving refunds over $500? Keep humans in the loop.

The best systems mix all four levels. Chatbots for simple lookups. Automation for repetitive tasks. Workflows for complex coordination. Autonomy for high-stakes decisions where you have data and trust.

Final Thoughts

If a vendor says their tool is “fully autonomous” but won’t let you see the logic, won’t explain edge cases, and gets defensive about testing... it’s probably automation with a prompt.

Ask them: “What happens when it makes the wrong decision? How do I audit it? What can it do that I didn’t explicitly tell it to?”

If they dodge, you know what you’re getting.

So where are your tools actually sitting? Probably Level 2, pretending to be Level 4.

Everyone talks about the $1M milestone like it’s a finish line.
It’s actually not and it’s where a different kind of pain starts.

Your Shopify payouts suddenly come with a 5 to 10 % rolling reserve. Not because you did anything wrong - just because growth tripped a risk model.

Inventory cash is sitting in containers you won’t see for months.
Support tickets climb faster than revenue.
Traffic is up, but attribution feels like guesswork as AI agents intercept discovery before customers even reach your site.

If this feels familiar, it’s because it is.

These aren’t edge cases but they are the most upvoted complaints in r/ecommerce right now. The $1M+ stage looks glamorous from the outside. Inside, it’s often cashflow pressure, operational drag, and constant second-guessing.

One founder summed it up bluntly in a recent thread:
“Revenue doubled, cash disappeared. Stripe froze 7% of payouts, my supplier wants 50% upfront, and support is on fire. On paper we’re ‘winning.’ In reality, it feels fragile.”

That tension clicked for me during a pre-sales call last quarter.
A founder walked me through their dashboard: ~$800K run-rate, processor holds freezing ~8% of inflows, support volume up ~40% month over month. We talked AI support layers and payment routing. But the real moment came later.

They weren’t asking for tools.
They were asking if this chaos was normal.

That’s the opportunity most content misses.

Founders don’t share posts because they found a clever tactic. They share them because someone finally named what they’re experiencing - clearly, accurately, without hype.

So I went back to one of those raw Reddit threads where founders ranked their biggest scaling pains and distilled them into 15 content plays. Not thought leadership. Practical formats that travel: how-to’s, listicles, contrarian takes, simple frameworks.

Use them in a newsletter. Turn them into X threads. Break them into LinkedIn carousels. Or use the pattern to hunt pain in your own niche.

Why this matters more in 2026

Agentic commerce is accelerating.
AI agents now handle research, comparison - even checkout.

But the fundamentals didn’t disappear.
Processors still lock funds when growth spikes.
Supply chains still break timelines.
Marketing attribution is getting worse, not better, as discovery goes zero-click.

As someone who’s architected retail stacks where AI agents now intercept 20–30% of early discovery, I’ve seen attribution black boxes widen - yet processor holds and inventory drag remain the real cash killers.

The winners aren’t just “using agents.”
They’re translating persistent human pain into content that builds trust before the agent acts.

If you can articulate the bottleneck better than the hype, you win attention when founders are most receptive.

The 15 Plays (Grouped by format)

How-To (Saved, not skimmed)

• Break the 5–10% Reserve Lock Negotiate processor holds using your own chargeback and volume data.

• Scale Support Without Hiring a Team Automate tier-1 with AI, outsource overflow intelligently.

• Audit Suppliers Like Compliance Quality gates that catch disasters before they ship.

• Unlock Trapped Inventory Cash Faster turns without starving stock.

• Find the Ad Spend Leak Why 25–35% of budget quietly stops working at scale.

Listicles (Fast, shareable, concrete)

• Processor traps still draining ecommerce in 2026

• Affordable tools that kill support overload

• Sourcing failures that stalled growth (and how they recovered)

• No-spend marketing shifts post-AI discovery

• Brands that escaped cashflow hell at $1M+

Contrarian Takes (Debate starters)

• $1M Revenue at All Costs Is a Trap Cashflow > vanity metrics.

• Big Processors Aren’t “Safer” Reserves protect them, not you.

• Cheap Overseas Sourcing Is Losing Its Edge Speed beats cost in an agent-driven funnel.

Frameworks (For repeatability)

• CASH Trap Breaker Calculate → Automate → Secure → Hedge

• SCALE Firewall Scan → Calibrate → Automate → Leverage → Evaluate

What actually changes
Content stops being volume.
It becomes precision pain-naming.

Founders forward pieces that mirror their dashboard dread.
One clear how-to becomes the bookmarked reference.
One grounded contrarian take sparks the right debate.

This isn’t opportunistic farming.
It’s empathy plus pattern recognition.

Name the scream. Then draw the map.

Where does this leave you?
What’s the one metric on your dashboard that looks “successful” but is quietly hurting you?

Today, AI in retail mostly advises.
Very soon, it will execute.

The real shift in commerce isn’t smarter recommendations or better chat interfaces — it’s deciding who is allowed to act on intent, and under what rules.

Over the last year, most retail conversations around GenAI have followed a familiar path.

Better recommendations.
Smarter search.
Nicer chatbots.
More productivity for teams.

Useful. Incremental. Safe.

But quietly, something more structural has started to shift - and it has very little to do with how intelligent AI is.

It has to do with who executes intent.

Imagine telling your phone: ‘Book me the cheapest AC train ticket to Pune next Friday, under ₹1500, window seat if possible.’ Today the AI suggests options → you pick and pay.
Agentic means: it searches, compares, books, and pays - but only because you already set rules like budget, preferred class, and card approval.

Until now, AI in retail has mostly assisted humans.
What’s emerging next is AI that can act - across discovery, decision, and transaction - with far fewer human checkpoints in between.

That difference matters more than most people realise.

Search commerce: I browse, compare, decide, execute
Agentic commerce: I declare intent, set constraints, approve outcomes

Why this matters more now

This isn’t just about better models or another retail AI feature.

What’s changing right now is the plumbing.

We’re starting to see:

• shared commerce protocols

• common ways for agents to discover products

• standardized flows for carts, checkout, identity, and payments

• clear separation between execution, trust, and control

When platforms begin defining how agents are allowed to transact - not just what they can recommend - experimentation starts turning into infrastructure.

And when infrastructure hardens, behaviour changes.

Retail has lived through this before:

• Search reshaped discovery

• Marketplaces reshaped distribution

• Mobile reshaped conversion

Agentic commerce reshapes execution.

A moment that made this click for me

In multiple retail AI discussions recently, I’ve noticed the same pattern.

Teams talk about:

• improving search relevance

• adding GenAI to customer support

• using copilots for internal efficiency

All valid.

But when the question comes up -
“Where does the decision actually get made?” - the room goes quiet.

Because most current GenAI initiatives still assume:

A human will decide.
A human will click.
A human will complete the journey.

Agentic systems quietly challenge that assumption.

Not by removing humans - but by collapsing steps that used to require explicit human action.

And retail is full of those steps.

Consider replenishment.
Not “discovery” or “inspiration” - just replenishment.

In an agentic model, the user doesn’t search or browse.
They define intent once: brand preference, price ceiling, delivery window, substitution rules.

From that point on, the system executes - repeatedly - without human clicks.

That silence usually happens because current tools still hand control back to humans - but emerging standards are quietly removing the need for that handoff.”

Why standards matter more than smarter agents

This is why the most important shift in agentic commerce isn’t better models - it’s standards.

Google’s Universal Commerce Protocol (UCP) is a strong signal that the industry understands this. Instead of each agent inventing its own way to browse, negotiate, checkout, and pay, UCP defines clear boundaries between agents, merchants, and payment systems.

What’s notable is not the technology itself, but the intent: agents are treated as participants in commerce, not shortcuts around it. Discovery, cart creation, identity linking, checkout, and execution all happen through explicit protocols - not implicit trust.

Payments are where this becomes real - and where control matters most.

Networks like Mastercard are already defining standards for agent-initiated payments, where AI agents can act on behalf of users without being allowed to act freely. These frameworks focus on agent verification, cryptographic consent, spending limits, and auditable transactions.

The message is clear: agentic commerce is not about letting AI spend money. It’s about letting AI act within tightly defined, enforceable boundaries.

Think of it like giving your trusted family member your debit card with strict instructions: ‘You can spend up to ₹5000 on groceries this month, only at BigBasket or DMart, and send me the bill screenshot.’ Mastercard-style rules do exactly that for AI agents - verify them, set limits, require your pre-consent - so nothing happens outside your guardrails.

What “agentic” really changes in retail

This is where a lot of confusion comes in.

Agentic ≠ better chatbot
Agentic ≠ smarter recommendations

Agentic means the system can:

• understand intent

• reason across constraints

• take action across systems

• and close the loop

For that to work at scale, agents need more than intelligence.

Funnels example: Instead of scrolling Amazon for hours comparing earphones, you say ‘Get me noise-cancelling ones under ₹3000 with good reviews and fast delivery.’ The agent picks, adds to cart, checks out - all while you make chai. Retailers now compete on how easy their data is for agents to understand and trust, not just on pretty photos.

They need coordination - clear rules for how discovery, checkout, identity, and payments are handled across platforms.

Humans don’t disappear in agentic commerce.
Their role shifts from execution to intent design, constraint setting, and exception handling.

Agents need coordination across systems - which is why protocols (not just better models) are the real unlock right now. That’s why protocols matter more than models at this stage.

In retail terms, this has four major implications.

1. Discovery shifts from “findability” to “eligibility”

Search and SEO were designed for humans browsing.

Agents optimise for:

• structured, reliable product data

• clear constraints (price, availability, delivery)

• predictable fulfilment

• confidence in outcomes

If an agent can’t interpret or trust your product data, it won’t surface you - no matter how strong your brand is.

Visibility becomes a systems problem, not just a marketing one.

2. Funnels stop looking like funnels

Traditional retail funnels assume friction:
search → browse → compare → cart → checkout

Agent-mediated flows compress this into:
intent → decision → execution

This doesn’t remove choice - but it reduces surface area and time.

Retailers who depend on mid-funnel persuasion (landing pages, nudges, visual storytelling) may find those moments shrinking unless they’re redesigned for agent-driven execution.

3. Conversion becomes less visible and harder to attribute

When agents initiate carts and complete transactions on behalf of users:

• attribution gets fuzzy

• “last click” loses meaning

• influence matters more than interaction

This isn’t just an analytics challenge.
It’s a mental model shift in how performance is understood.

4. Control quietly shifts upstream

The biggest risk - and opportunity - is ownership.

If agents become the primary interface:

• who controls prioritisation?

• who defines defaults?

• who decides what “best” means?

This is why the emergence of shared commerce standards - like Google’s Universal Commerce Protocol - is significant.
Not because of who published it, but because it signals where the industry is heading:
from bespoke integrations to agent-readable, standardized execution flows.

Retailers that treat this as “just another channel” may lose leverage without noticing.
Retailers that treat it as strategic infrastructure may help shape the rules.

What this does not mean

This does not mean:

• websites disappear tomorrow

• humans stop shopping

• agents replace retail strategy

It does mean:

• execution layers are changing

• assumptions baked into retail stacks are being challenged

• and “AI strategy” can no longer stop at copilots and content

This is early.
But it’s directional — and direction matters.

We’re starting to see this take shape across the ecosystem - not just one protocol, but a wave of them.

Google’s Universal Commerce Protocol (UCP), co-developed with Shopify, Target, Walmart, and endorsed by Visa, Mastercard, Stripe, Adyen, and others, is a strong merchant-facing signal. At the same time,

OpenAI and Stripe’s Agentic Commerce Protocol (ACP) is pushing agent-initiated flows from conversational interfaces, Microsoft is piloting agentic checkouts in Copilot experiences, and payment networks like Visa and Mastercard are layering in consent, limits, and auditability for agent actions.

The point isn’t which one wins outright. It’s that the infrastructure race is on, standards are emerging in parallel, and the real shift is happening where execution moves from human clicks to system-led decisions - quietly, but irreversibly.

One question retail leaders should start asking now

Not:

“Which AI tool should we use?”

But:

“Where, in our retail journey, could decision-making move from human-led to system-led - and are we ready for that?”

That single question reframes:

• data priorities

• architecture decisions

• operating models

• and even brand strategy

You don’t need all the answers yet.

But if you’re not asking the question, someone else - or something else - will answer it for you.

Agentic commerce isn’t about hype or headlines.
It’s about who executes intent in the next version of retail.

And that’s a shift worth paying attention to.

Share

The competitive advantage in agentic commerce won’t come from having the smartest model.
It will come from deciding where execution is allowed — and where it isn’t.

The real question for retailers is no longer “How good is our AI?”
It’s “What are we willing to let it do?”

This is less about AI innovation — and more about commerce architecture.

P.S. I’m spending more time exploring how agentic systems intersect with real retail constraints - especially data, trust, and ownership. More to come.