How AI coding agents change what a small integrator can build

A custom EPOS integration used to be something only a bigger reseller could afford to build. Writing the code against a till’s API, testing it properly and supporting it afterwards took enough developer time that a small job — sync your till to one accounting package, push orders from one webshop — rarely paid for itself. AI coding agents have changed that arithmetic for us. This article explains plainly what they do, what they don’t, and what we check ourselves before any integration touches a real till.

What an AI coding agent actually does

An AI coding agent is a tool that can read a codebase and a specification, then write, run and fix code in a loop rather than just suggesting a line at a time. Given a documented API — ICRTouch’s XML socket interface, its JSON remote interface, or an ETAL script, for example — it can draft the calls needed to send a sale, look up stock or print a ticket, write tests against that draft, run them, read the output when they fail, and correct the code, over and over, until the tests pass (ICRTouch, TouchPoint; Google Cloud, “What is agentic coding?”). For a bounded, well-specified task — “when TouchPoint records a sale, post it to this accounting API” — that loop can do in an afternoon what used to take a developer the better part of a week: reading docs, writing boilerplate, running the till in a test environment, checking edge cases.

That’s a real, useful change. It is not a multiplier we’re willing to put a number on. The most careful trial of this kind of tool to date — a randomised trial by METR, the closest thing this field has to a clinical-trial methodology — found that experienced developers working in large, mature codebases they knew well and had maintained for years actually completed tasks 19% slower with AI coding tools than without them, even though they had expected a 24% speed-up beforehand and still believed afterwards that the tools had sped them up by 20% (METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”). That study isn’t about our kind of work — it tested experienced maintainers working in their own large, established projects, not a small, scoped integration against a documented API we already know — but it’s a fair warning against believing any flat percentage, including ours. We don’t quote one. What we can say is that a well-specified integration against a documented API is exactly the kind of task these tools are good at, and a large, complex codebase with ambiguous requirements is exactly the kind they’re bad at.

What we still check ourselves

An AI coding agent drafts code. It doesn’t decide what the integration should do, and it doesn’t take responsibility for what happens when it’s wrong. Five things stay with a person on every job:

• The spec. What should actually happen when an order comes in, a sale is voided, or two systems disagree about a price — that’s a business decision about your till and your workflow, not something to leave to a model’s best guess.
• The data mapping. Which field in your accounting package matches which field on the till, what happens to a discount or a service charge, how VAT is handled — get this wrong and every report downstream is wrong too, quietly.
• Security. Veracode tested AI-generated code from more than 100 models across 80 coding tasks in four programming languages, and found that 45% of it contained a security flaw — across vulnerability classes including SQL injection, cryptographic failures, cross-site scripting and log injection (Veracode, “AI-Generated Code Security Risks” — Veracode sells application-security tooling, so treat that figure as an interested party’s own benchmark, not an independent audit). In our own experience an agent left unsupervised will happily hard-code a credential or skip a signature check unless someone tells it not to, so we review every integration for exactly that before it goes anywhere near a live API key.
• The test against a real till. Code that passes its own tests against a mock still has to run against your actual TouchPoint, ByTable or CES Touch setup, with your menu and your hardware, before we trust it.
• Deployment and support. Someone has to decide when it goes live, watch it on the first day of real trading, and be the person you call if it breaks. That’s us, not the agent.

Why this matters if you’re a small business

None of this is about replacing the judgement a proper integration needs — it’s about where the hours go. Less time goes on typing out boilerplate against a documented API; the same amount goes on deciding what the integration should do and checking it’s safe and correct before it touches your till. For a small integrator, that means jobs that used to be too small to be worth building — one payment provider, one accounting sync, one delivery platform — are now within reach, without cutting the checking that keeps your till reliable.

If you want to see what a documented API actually looks like on a real till, read what an EPOS integration actually is and ICRTouch’s developer interfaces explained. If you’re weighing up how the data should actually move once the integration is built, see choosing between webhooks, polling and file drops for EPOS data. For the fuller picture of how we approach this work, see our integrations and AI page or browse the integrations directory for the systems we’ve already connected.

Sources

• ICRTouch, TouchPoint — developer integration options (XML socket, JSON remote interface, ETAL scripting)
• Google Cloud, “What is agentic coding?”
• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (2025)
• Veracode, “AI-Generated Code Security Risks: What Developers Must Know”