Integration Guys Ltd

Two days to write, weeks to test

Last week, after we shipped an MCP server for Earth Rebates, I wrote that MCP is the new EDI. This week I gave an AI the kind of job I started my career doing, mapping one data format to another, and timed it.

For most of my career, a new mapping took two to three days to write. That was never the expensive part. The time went on testing: getting real data samples out of the customer, running validation rules, and chasing product IDs and units of measure that meant something slightly different in every system.

One customer stays with me. They ran a heavily customised SAP system that sent different IDocs, through different workflows, depending on the internal customer and the business line. Seed behaved differently from crop protection. Every new trading partner we onboarded meant changing a mapping, and every change meant regression testing all the variants, because fixing one path could quietly break another.

Writing the map was drudgery. Testing it was the job.

The test

I picked a mapping every ag retailer and manufacturer will recognise: a distributor's sales reconciliation file, converted into an AgGateway Product Movement Report.

• Input: a flat file in the Ag eStandards Sales Reconciliation layout approved in 2004. It is still the shape of a lot of what moves between distributors and manufacturers.
• Output: one Product Movement Report against the current Chem eStandards 7.1 schema.
• Data: synthetic. Invented distributor, growers, products and IDs, so nothing confidential.
• The mess: I planted the problems real files have. A line sent twice. Returns as negative quantities. A transfer between the distributor's own branches. Invoices either side of the reporting month. Cases and bags where the manufacturer thinks in gallons and pounds. The same product as a manufacturer code, a GTIN, and a code Excel had mangled (40210.250 saved as 40210.25). Three different ID qualifiers. And X12 unit codes, where the 7.1 schema expects UN/ECE Rec 20.
• The AI: a fresh agent with no context from me, run twice. Once with just the file and the schema. Once with the 2004 implementation guide as well.

I then checked its output against a set of automated tests, including validation against the schema. The data, schema, grader and both AI runs are on GitHub, so you can run the same test on your own tools.

What happened

Round one: the file and the schema, nothing else. About four minutes later I had schema-valid XML. It had spotted the duplicate and reported it once. It typed the returns as returns and the branch transfer as a transfer, not a sale. It read the US dates correctly, converted cases and bags using the pack size, stripped the Excel apostrophes, and worked out that 40210.25 was really product 40210.250. It also noticed that the barcodes I had invented had invalid check digits. That was not a planted trap. It was my mistake, and it caught it.

It got one thing wrong, and how it got it wrong is the interesting part. One grower's ID came with the qualifier C5. Nothing in the file or the schema says what C5 means, so the AI sent it as "Other" and wrote in its notes that the team should find out what kind of ID it was. It did not guess.

Round two: add the implementation guide. C5 is in the guide (it is a NAPD number), and the gap closed. The AI also noticed something I had not pointed out: the 2004 guide no longer matches the 7.1 schema. The XML paths have moved, the qualifiers are now words rather than EDI codes, and the guide's X12 unit codes are not the ones the schema expects. It followed the schema and listed the differences.

The catch. Look at how the two runs encoded the same return. Round one sent it as a Return of -8 gallons. Round two sent it as a Return of 2 cases. Both are valid against the schema. A manufacturer's system will treat them differently, and the first risks subtracting a return that is already marked as a return.

The schema allows both. Only an agreed implementation guide, and a test that enforces it, decides which one is right.

Where the time actually went

The AI took four minutes to write the mapping. Almost all the effort in this exercise went into the test: inventing realistic data, planting the problems, writing the checks and an answer key, and making sure the checks failed when they should. The mapping was the quick part.

That is the same ratio I lived with for most of my career, just compressed. AI has made the drudgery of writing a map almost free. It has not touched the part that always burnt the time, which is proving the map is right for this partner, and still right after the next change.

If anything, the testing matters more now. When a first draft costs four minutes, you will get many more of them. Every one needs checking against data that looks like the real thing.

What I would do now

1. Let the AI draft the map. Give it the schema and the implementation guide as context. Read its notes; they are where the useful questions are.
2. Treat the implementation guide as the product. Write down the decisions the schema leaves open: how returns are signed, which unit codes, which identifiers. The AI follows a guide well; it cannot invent your agreement.
3. Build a test pack per trading partner. Sample files, expected outputs and automated checks, kept with the mapping. This is the asset that lasts, not the map.
4. Regression test on every change. That SAP customer taught me this the hard way. When onboarding a new partner means touching a shared map, every existing variant gets re-run, automatically.
5. Use AI on the test data too. It is very good at generating the awkward cases (bad units, duplicates, mangled codes) that real sample files never contain until production. More on that later in this series.
6. Keep a human on the agreement. Two valid encodings of the same return is a business decision, not a technical one.

The job has moved, not gone

The first draft of an integration is now nearly free. The implementation guide, the test pack and the conversation with the trading partner are where the value is, and where most teams still under-invest.

A few honest caveats. This was a demonstration, not a benchmark: twelve rows of synthetic data, problems I chose, and an AI agent that could check its own XML against the schema, as any developer using these tools would today. Real files have thousands of rows and twenty years of history in them. I built the test with AI help too, which rather proves the point.

If you are onboarding trading partners and your testing still depends on someone eyeballing sample files, I would be glad to compare notes.

Previously in this series: MCP is the new EDI.

Next week: spec first, prompt second. How we actually build software with AI coding agents.

Notes

• Chem eStandards 7.1 schema: Copyright (c) Open Applications Group, Inc. All Rights Reserved. oagi.org. Chem eStandards are used by AgGateway for ag eBusiness messaging.
• All parties, products and identifiers in the test data are invented.