Agentic engineering: how we build ecommerce platforms with AI agents

Agentic engineering is software engineering in which an AI agent does most of the actual coding, but makes no decisions and touches nothing irreversible without a human sign-off. The counterintuitive core: once an agent writes many times faster, writing is no longer the bottleneck, verification is. So we build the whole process around checking rather than around generating: automated gates (typecheck, build, tests, lint), an adversarial review by a second model, and a human who holds the architecture, the risk and the hand on irreversible actions such as deploys, database migrations and operations on customer data. For a client that means one thing: faster and safer at once, because the speed comes from the agent and the safety from the discipline around it. This is not "AI writes code, we watch". It is engineering in which AI is the fastest tool, not the party that is accountable.

What agentic engineering is, and what it is not

Agentic engineering differs from simply "using AI for code" in one thing: the agent works in a loop, reaching for files, running tests, reading errors and fixing them, but it does so inside a frame someone set for it. The opposite is vibe coding: prompting away without a spec, without tests and without understanding what came out. Vibe coding looks impressive until the first real problem, and then nobody knows why the system does what it does. What separates us from it is not a better prompt, but what the agent gets as input and what happens to its output.

Spec before code: the agent builds on a plan, not on guesses

Before the agent writes a single line, a plan exists. For us that is the Blueprint stage: described system behaviour, a data model, repository conventions and scope boundaries. The agent builds from that specification rather than from guesses, because a model that guesses intent also guesses architecture, and that is the most expensive kind of mistake. A good spec is in fact what makes the agent fast in the first place: the less it has to guess, the fewer rounds of correction it needs.

Why verification, not writing, is the bottleneck now

When generating code gets several times cheaper and faster, attention shifts to what did not speed up: confirming that the code is correct, secure and does exactly what it was meant to. That is the new bottleneck. A team that misses this simply produces more unchecked code, which is more debt, only faster. So in agentic engineering most of the engineering effort moves from writing to verification, and most of that verification can be automated.

Four gates the code passes before a human sees it

Every change from the agent passes through the same set of gates as a change from a human, only faster, because the agent runs them itself in a loop:

• Typecheck in strict mode catches a whole class of errors the model cannot see, because it writes locally while types guard the consistency of the whole system.
• Build confirms the project actually compiles and runs, not just that it looks right in the editor.
• Tests check behaviour, especially where a mistake is costly: payments, stock levels, migrations.
• Lint keeps one style and one set of conventions, so code from the agent looks like the same team wrote it.

The agent does not finish a task until all four are green. This is the first line of defence and the cheapest, because it runs without a human in the loop. But green gates say the code works, not that it is good.

Adversarial review: a second model hunts for holes, not praise

So we add a second layer: an adversarial review in which a separate model is told to find holes in the change rather than praise it. It looks for edge cases, assumptions that will not hold, security gaps and places where the code does something subtly different from the spec. The model that wrote it and the model that critiques it see differently, and that tension catches things a single pass misses. Only then does the code reach a human, already filtered.

The human stays on decisions and risk

Automation filters out defects, but it does not make decisions. The human stays where the stake is judgement: the choice of architecture, the trade-off between simplicity and flexibility, the call on whether a change is worth its risk. These are the things we do not delegate to the agent, because responsibility for a client platform sits with us, not with a model. The whole split of roles is clearest stage by stage:

The agent speeds up every stage; the human keeps the decisions and everything that cannot be undone.

Irreversible actions are the hardest boundary in the process

Code can be rewritten, a test added, a badly named function fixed. You cannot undo a deploy that broke orders in the middle of the day, or a migration that overwrote data, or a script that deleted something in production. So everything in that category goes through a human, always, no matter how confident the agent is. A green gate is a necessary condition, not permission to ship.

Security: least privilege and customer data on copies

Security in this way of working starts with access. The agent runs on least privilege: it gets the minimum permissions the task needs and nothing beyond, so even a mistake has a limited blast radius. We do not work on customer data where it lives: the agent and the tests get copies, not the production database. Secrets and keys stay out of the model reach. This is not distrust of the tool, it is the same principle you apply to any automated process: you assume something will eventually go wrong and design so the consequence is small.

A reusable core: the next project starts from a higher floor

There is one more reason this way of working is fast, and it is missing from the AI slogans. The next project does not start from zero. Proven foundations, integration patterns, an automation layer and conventions carry over between builds, so the agent starts from a higher floor and the gates and review are already set. This is part of how a platform can be delivered at a fixed price and on a fixed date at all: we take the estimation risk onto ourselves, because much of the core is already built and tested. We describe the build stage itself on the Engineering page, and the automation layer that goes inside the platform on the AI Automation page.

Agentic engineering is neither a promise that AI will build the store on its own nor a warning that AI will break everything. It is the sober middle: the fastest available tool for writing code, enclosed in a process that controls that tool. What that process looks like on a concrete task, we show step by step in the piece on cleaning a catalog with Claude Code. The difference between a platform that still works in two years and one someone will be rescuing does not lie in whether AI was used. It lies in what the AI got as input and who checked its output.