Key points
- Working with agents differs from firing off prompts in three ways: a specification before any code, gates that cannot be skipped, and a review carried out by someone other than the author. Irreversible actions, meaning production deploys, data migrations and deletions, are approved by a human.
- Delivery gets faster not because somebody writes code quicker, but because the distance from "written" to "safe to ship" gets shorter. The bottleneck is trust in the code, so the investment goes into verification rather than typing speed.
- Written-down company knowledge plus agents compound in the build as well: specifications, dictionaries and tests stay in the repository, so every sprint starts further along and dependence on a single vendor drops.
- Grow it in stages: gates first (tests, an automatic build, a preview environment), then agents on the best-specified tasks, and from day one a clear split between who writes specifications and who approves.
Oversight of your automation works: you know who approves, on what basis, and what happens when the machine gets it wrong. That is a good moment to move up a level. The same way of working, meaning a clear specification, hard verification and a human on irreversible decisions, applies not only to descriptions and feeds but to the code your store is built from. This chapter closes the main path because for most companies it follows from the previous five rather than starting the journey. And you do not need to write code yourself to judge whether somebody is building your store in a way you can control.
Working with agents is not writing longer prompts
A scene from a project: the store needs a "batch number" field on a product variant. It sounds like an hour of work, and an agent really will generate that code in minutes. But writing code was never the most expensive part of a project. The expensive parts are agreeing exactly what should be built and checking that what was agreed is what got built.
- Carts: what about the variants customers already have in their carts?
- Feeds: what about the feed to a channel that has no such field?
- Returns: what about returning a whole batch?
Working with agents pushes the team's effort in both of those directions: more time on the specification before the code and on verification after it, less on the typing in between. Skip both ends and keep the middle, and you get exactly what you were complaining about before, only faster and in greater volume.
A specification before code
It means that before anyone, human or agent, touches the repository, someone has written down the scope of the change, the edge cases, the impact on data and the definition of "done". Without it you get code that works on the happy path and falls apart on product variants, returns or the warehouse integration, which is precisely where ecommerce lives.
A written specification has a second effect that only shows up months later: it is the only place that records why something works the way it does. How that mode of work differs from generating code fast without structure, we covered in the piece on why AI native is not vibe coding.
The gates every change has to pass
Rigor does not come from good intentions, it comes from gates that cannot be talked around by tiredness or a deadline. Some are automatic and run on every change: type checking, build, tests, lint, dependency checks. Others need a human, or a review by someone other than the author. The table shows where the machine's discretion ends.
| Stage | What happens | What blocks the next step |
|---|---|---|
| Specification | Written scope, edge cases, impact on data and a definition of "done" | An unclear acceptance criterion or no agreement on scope |
| Implementation | The agent writes code in small steps, each inside the agreed scope | The change grows beyond scope or touches areas outside the spec |
| Automatic gates | Type checking, build, tests, lint and dependencies, on every change | A red result on any gate, with no "just for today" exceptions |
| Review | Someone other than the author reads the change against the specification | Unresolved comments or drift from the specification |
| Deploy and migrations | Publishing to production, migrating data, deleting resources | No explicit human approval |
A machine can run the first four rows. The last one stays with a human, and that does not change as the team matures.
Whatever is irreversible gets human approval. Production deploys, data migrations, deleting resources and changes to payment configuration are decisions you do not hand to a machine, however well it handles the rest of the work. The criterion is not "can the tool manage it", it is "what does it cost to undo if it gets it wrong".
The bottleneck is not the code, it is trust in the code
Delivery speeds up not because somebody types faster. It speeds up because the distance from "written" to "safe to ship" gets shorter. In a typical project that distance is where most of the time goes: the change waits in a review queue, somebody clicks through it by hand on a test environment, a list of comments comes back, the cycle repeats. If code generation gets faster while that distance stays the same, all you grow is the queue. So the investment goes into verification:
- Tests: the kind that actually catch the errors that matter to sales.
- Type checking: finds mismatches before anything runs.
- A preview environment: for every change.
- Review: independent of the author of the change.
This inverts the usual intuition about cost. A team that sped up writing code without strengthening its gates has only increased the rate at which defects reach production. A team that built the gates first can afford far more changes per week, because each one is cheap to check and cheap to undo.
Quality here is not the price you pay for speed, it is the condition for it. How this works for us step by step, from specification through the gates to deployment, is in the piece on agentic engineering.
What this changes for a store owner
From the point of view of the person paying for it and living off it, four things matter:
- Speed: Monday's idea does not wait for next quarter, because changes land faster.
- The fix queue: stops growing, because a small fix stops costing like a small project.
- Maintenance: gets cheaper, since most maintenance work is repetitive and well described, and that is exactly the kind of work this process handles best.
- Vendor dependence: drops, because the project context is written down in the repository, in specifications and tests, rather than held by the two people who happen to know the code.
There is a further consequence. As long as every change to an owned platform cost a lot and took a long time, the arithmetic often favored a box: a subscription plus the limits that come with it. When the cost of change falls, that arithmetic shifts.
An owned platform stops being a line item you have to defend to the board and becomes the place where you can build what competitors on the same box cannot. That is a conclusion, not a promise, and one thing decides it: whether your team has ideas worth building.
A platform that learns with every sprint
Work done properly stays done. A cart module, a warehouse integration, feed handling, a test suite for the checkout path: once specified and verified, they carry over to the next project and the next market instead of being rebuilt from scratch.
The same goes for knowledge. Specifications, attribute dictionaries, checklists and written-down decisions add up to a knowledge hub the agent draws on for every next task, and every reviewer correction flows back into the rules instead of vanishing into somebody's head. The compounding effect we saw with operational workflows works in the build as well: the second market launches faster than the first, and the third faster than the second. One condition: somebody deliberately keeps the shared parts shared.
Out of the same conviction we publish an open set of ecommerce skills for AI agents under an MIT license: written-down industry context that does not need to be reinvented on every project. It is exactly the material we work with ourselves.
How to grow this in your own company, in stages
Start with the split of roles, because that is what decides whether the process survives:
- Who writes specifications: it does not have to be a developer. The best person is usually the one who knows the assortment, the customer and what is supposed to happen in the store.
- Who says "this is not going in": usually one person on the technical side, with a clearly defined set of irreversible decisions.
- The rest of the team: works in between, describing, checking, correcting.
Without that split, every change ends in an argument about who actually decided, and accountability dissolves at exactly the moment you need it.
Sequence and tooling
The second thing is sequence. If you have no tests, no build running automatically and no preview environment today, your first step is not an agent, it is those three things, because without them there is nothing to hold anything to. Agents come after that, on the best-specified tasks.
The third thing is restraint with tooling: one tool per stage, replaced when it genuinely fails rather than when a newer one appears. In our BEAM framework this stage is called AI Automation, and it covers exactly what this guide describes: from automating operational work to the way we build and develop the platform itself.
The whole path in one paragraph
The path we walked is simple and deliberately ordered. First you work out where AI actually makes money in your store, instead of starting with a chatbot because that is what everyone starts with. Then you audit operational work and learn where the hours go. You put your data in order, because without that every automation only scales the mess. You launch a first workflow in a narrow scope and judge it with a control sample rather than an impression. You set up oversight, quality and compliance so that what works does not start working against you. And only then do you move the same way of working onto building and developing the platform.
Each step assumes the one before it, and none of them is a one-off. And if you want to start in your own company today, chapter seven, the bonus, is a ready-made rollout framework: Claude Code and a company knowledge hub, step by step.
One last thing worth remembering when the tooling is impressive. AI will not make your business decisions: it will not pick your assortment, set your price positioning or tell you which market is worth fighting for and against whom. It does not know your customers better than you do, and it has no access to knowledge you never wrote down. It removes repetitive work and shortens the distance from decision to execution, but the execution of what remains a question for a human. And that question matters more than the choice of tool.
Questions
Does this mean a company without developers can build a store?
No. What changes is the distribution of work, not the need for the skill. Somebody has to set up the gates, design the architecture, judge a change against its specification and make the calls on deploys and migrations. Those are engineering tasks and they need an engineer. What does grow is the role of a non-technical person on the store side, because a good specification comes from someone who knows the assortment and the customer, not from someone who knows the framework.
How do you check whether a vendor works this way if you cannot read code?
Ask about four things and ask to see them on their most recent change. Whether a written specification with an acceptance criterion exists before work starts. What runs automatically on every change and what happens when the result is red. Who reviews the change independently of its author. Who approves production deploys and data migrations. All of that can be verified without reading a line of code: gate reports, change history and a working preview environment are enough.
Is code written with AI safe to ship to production?
The question is framed wrongly, because the risk does not depend on authorship but on what happens between writing and shipping. Code typed by hand with no tests and no review is just as risky. So what you want to know is not who wrote it, but whether the change passed the gates, whether someone reviewed it independently and whether it can be rolled back quickly. No process reduces that risk to zero.
