AI-First Integration Engineering With Claude Code: A Real Debug Session

Most “AI wrote my code” stories are demos with a clean prompt and a clean result. This is not that. This is a real session on a real APIANT integration product, including the actual prompts, the wrong turns, the corrections, and the moment a human memory beat the machine.

The point is not that AI is impressive. The point is what the collaboration actually looks like when you sit down and do the work.

The setup

The product is one of our CRMConnect integrations, Mindbody to HubSpot. A customer reported that sales paid with more than one payment method were syncing wrong. A sale of $8,400 split across three payment methods showed up in HubSpot as a single $400 deal. The other $8,000 was missing from the pipeline.

We track engineering work in GitHub Issues. The customer conversation lives in HubSpot Service Hub. The session started with the builder pointing the AI at the work.

Prompt: “look at the payment issue”

The AI searched the repo’s GitHub issues, found the open incident, pulled the full body, and read it back: a multi-payment sales bug, with two prod execution IDs cited as evidence. No hand-holding needed. It then asked for the next step in plain terms instead of guessing.

Prompt: “what does the logic do and which automation / actions?”

The AI loaded the relevant automation from the platform, walked its structure step by step, and explained the failure precisely. The automation builds a deduplication key for each HubSpot deal. For multi-payment sales, Mindbody returns one row per payment method, all sharing the same key, so rows two and three collided with the deal created by row one and their amounts were silently dropped.

Useful. But the builder already had a stronger lead.

The hint that redirected everything

Prompt: “compare this unique identifier for the deal with how we do it with the crmconnect-mindbody-zoho project. I thought we had solved it there. Do a laser focused compare.”

This one sentence changed the shape of the work. The builder did not describe a fix. He pointed at a sibling product and said, in effect, go read it.

So the AI did. It opened the Mindbody to Zoho integration, a completely separate product, located the automation that handles historical sales, and read it. Then it found and read the subroutine that writes payment records. Not summaries. The actual automation logic, step by step.

It came back with a focused comparison. The Zoho integration had indeed solved this, but with a different architecture:

• The HubSpot product writes one flat deal per sale line, using Mindbody’s older sales endpoint, which returns pre-split payment rows.
• The Zoho product writes a parent purchase record plus separate child records for line items and for payments, using Mindbody’s newer endpoint, where each payment carries its own real payment ID.

The AI’s read was that Zoho was architecturally cleaner, and it initially proposed porting the whole three-object model into HubSpot.

The builder pulls scope back

This is where the human kept things grounded.

Prompt: “Not ready for V4.0 yet. Save it for later, now we need to fix the issues with deals missing reported by the customer.”

The AI had drifted toward a satisfying architectural rewrite. The builder cut it back to the actual problem: the customer needs correct deal amounts, not a new data model. The AI agreed, closed the rewrite proposal as a future item, and re-scoped to a surgical fix on the existing deal automations.

That correction matters. AI is good at finding the elegant general solution. It is not always good at knowing when the elegant solution is more than the moment calls for. The builder supplied that judgment in one sentence.

The AI then adapted the principle behind the Zoho design, without copying its structure: reconcile one deal per sale line item, source the data from Mindbody’s richer endpoint, and aggregate the amount correctly across payment methods instead of letting the first payment overwrite the rest. Different platform, different actions, same underlying idea.

The hunch

While reworking the deduplication key, the AI looked at one of its components: a date. Its reasoning was clean. The sale ID and the sale detail ID already make the key unique. The date is redundant. It recommended dropping it to simplify the key and remove a source of fragility between the two automations.

The builder did not have a code reference to argue with. He had a memory.

Prompt: “i seem to recall that i added the date because it was needed (2 payments on the same transaction, or something weird like it)?”

Neither of them could prove it from the current automation. So the AI went into the automation’s version history. The automation had ninety-three saved versions, going back to 2021. The AI read the change descriptions until it found the relevant ones.

From January 2022:

“Added EPOCH MILLIS to deal ID saving in DB to keep it unique when multi payments are made on same item”

From February 2022:

“Added sale date for find deal by custom property so it processes payments on previous sales”

There it was, in the builder’s own words, four years earlier. When a customer makes a payment later against an earlier sale, Mindbody re-emits that sale on the new date. Without the date in the key, the later payment collides with the original deal and cannot get its own record. The date was not redundant. It was load-bearing, deliberately added to handle installment and autopay payments.

The AI’s response was to reverse its recommendation immediately and say so plainly:

“Trust that recollection. If you added the date deliberately, it is load-bearing, and dropping it is off the table. Found it in the version history.”

It then went further. Since the date had to stay, the two automations needed to produce the exact same date value or the keys would not match and duplicate deals would appear. The original automation builds the date from a specific Mindbody field. The AI re-pointed the new automation to read that identical field, from the same API call, with the same timezone conversion. Same input, same output, keys guaranteed to match.

A regression that would have quietly broken installment-payment handling never happened. Not because the AI was careful, but because a human remembered a hunch and the AI could verify it against four years of history in seconds.

The unglamorous part: build, run, read the trace, fix

With the design settled, it became iterative engineering. Build the change in a dev environment, run it, read the execution trace, find the next problem, fix, re-run. The real bugs were ordinary:

• A deal-creation step failed with sixteen PROPERTY_DOESNT_EXIST errors because the field bindings were not carrying HubSpot’s internal property names. The AI read the trace, fetched the connector’s field schema, and rebound every field with its correct ID.
• A loop ran twice when it should have run once, because the platform was counting iterations off the longest array in the source data, and the payments array was longer than the line-items array. The AI inserted an explicit iteration control so the loop counted line items only.
• A “find deal” step halted the whole run when no deal existed yet, because its default error mode treated “not found” as fatal. The AI switched it to continue-on-error so the create branch could run, matching how the sibling automation already handled it.

None of this is glamorous. It is the actual texture of integration work. What changed is the loop speed. The AI could read a full step-by-step execution trace and point at the failing step immediately, so each fix cycle was minutes. Nothing shipped to a customer until the dev tests passed.

What this means for Builders

Strip away the narrative and here is the working model:

• The AI’s strength is reading. It studied an entire sibling integration, cross-referenced a problem we had already solved, adapted an architecture across two different platforms, and dug through ninety versions of history to verify one design decision. No human does that in an afternoon.
• The human’s strength is memory and judgment. “I think I added that for a reason” is not in any file. “Not ready for V4.0 yet” is not in any file. Both came from having lived the product. Each one changed the outcome.
• The speed comes from the loop. Read the trace, fix the step, re-run. The friction that usually slows debugging, reconstructing what happened, is gone.

AI-first integration engineering is not the AI working alone, and it is not the human working faster. It is the AI doing the reading no human has time for, and the human supplying the context no codebase records. Put those together and a four-year-old recurring bug gets understood, fixed, and verified in a single working session.

That is the workflow worth building toward.