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.
- For a store owner that means faster changes, a shorter queue of small fixes, cheaper maintenance and less dependence on a single vendor, because the project context lives in the repository rather than in two people's heads.
- 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 is set: 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 day-to-day store operations but to how the platform itself is built and developed. This chapter comes last 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
The difference between serious work with agents and generating code on the cheap is not in the tool or in the length of the instruction. It is in the rigor around the tool. A model can write a working piece of 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. Working with agents therefore 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 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 of them 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 below 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 that actually catch the errors that matter to sales, type checking that finds mismatches before anything runs, a preview environment for every change, and a review independent of the author.
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. First: changes land faster, so Monday's idea does not wait for next quarter. Second: the queue of small fixes stops growing, because a small fix stops costing like a small project. Third: maintenance gets cheaper, since most maintenance work is repetitive and well described, and that is exactly the kind of work this process handles best. Fourth: dependence on a single vendor 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 an off-the-shelf solution where you pay a subscription and accept 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.
Reuse: the next project starts further along
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 specifications, dictionaries and checklists, which are assets too, just rarely treated as such. The effect is that the second market launches faster than the first and the third faster than the second, provided somebody deliberately keeps the shared parts shared. For the same reason 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.
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. Somebody has to write specifications, and 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. Somebody else has to hold the right to say "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.
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. A team that changes its toolkit every month never reaches the point where any of them repays the effort put in. 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.
Six chapters 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. Next 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.
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.
