Isaac Emmanuel

2026.06.24

The LLM was the easy part

What building the backend for an AI advertising product taught me

Also published on Medium on 2026-10-31.

Before joining Koreshield, I worked as a backend engineer on adGPT, an AI product designed to automate ad campaign creation, data retrieval and PPC management across major advertising platforms. It also included forecasting pipelines to predict return on ad spend.

Going in, I assumed the hard part would be the AI. It wasn’t. Here’s what actually took the time, and what it taught me about building AI products in general.

1. The LLM was the easy part

Getting a language model to draft ad copy, suggest keywords or summarise campaign performance is not difficult anymore. A good prompt, sensible structure and some evaluation gets you surprisingly far.

What took the time was everything around the model. Each advertising platform has its own API, authentication flow, rate limits, data model, quirks and release schedule. Fields mean slightly different things across platforms. Endpoints change. Some operations are synchronous; others return a job you have to poll. Errors range from helpful to cryptic.

The AI layer was a thin, impressive surface. Underneath was a large amount of careful integration work, and that’s where most of the engineering went.

2. Forecasting is a data problem wearing a model costume

Predicting return on ad spend sounds like a machine learning problem, and partly it is. But the quality of the forecast depended much more on the data going in than on the model choice.

Missing days, attribution differences between platforms, currency and time zone inconsistencies, campaigns renamed halfway through a month, tracking changes and outliers from one-off events all affected results more than any modelling decision.

The work that improved forecasts most was unglamorous: cleaning, aligning, validating and documenting data. If you’re building any AI product that makes predictions, budget more time for data quality than you think you need.

3. AI products need boring infrastructure

A single “generate a campaign” request might involve fetching account data, calling the model, validating its output, calling one or more platform APIs and recording the result. Any of those steps can fail, time out or be rate limited.

That means the same infrastructure you’d need for any serious backend:

  • Queues for work that shouldn’t block a user request
  • Retries with backoff for flaky external calls
  • Idempotency so a retried step doesn’t create duplicate campaigns
  • Caching for expensive or rate-limited reads
  • Clear state tracking so you know exactly where a multi-step job stopped

The model call is one step in a longer pipeline. Treat the pipeline with the same care you’d give a payment flow, because in this case it’s spending real money.

4. Users don’t trust automation that touches their money until they can see it

This was the biggest lesson. Advertisers were interested in automation, but they were cautious about letting software make changes to campaigns with real budgets. That’s completely rational.

Trust came from visibility:

  • Showing what the system planned to do before doing it
  • Explaining why it recommended a change
  • Logging every action it took, with the data that led to it
  • Making it easy to review, approve or reverse changes

Features that worked silently, even when they worked well, were trusted less than features that showed their reasoning.

5. Validation is not optional

Model output can be confidently wrong. It can produce a budget in the wrong currency, a keyword that violates policy or a field value an API will reject. Every output that turned into an action needed validation against business rules and platform constraints before it was sent anywhere.

That’s a general principle I now apply everywhere: model output is untrusted input to the rest of your system.

How this shaped my thinking about AI security

These lessons fed directly into how I think about AI systems at Koreshield. If you take them seriously, you end up with a few rules:

  • Every action an AI takes should be explainable, so people can understand why it happened
  • Every action should be logged, with the inputs that triggered it
  • Actions should be reversible where possible, and confirmed by a human where not
  • Model output should be validated before it’s trusted

Those rules make AI products more trustworthy for users. They also make them much more secure, because the same visibility and validation that build user trust also catch manipulation, mistakes and misuse.

The takeaway

If you’re building an AI product, expect the model to be the smallest part of the work. The integrations, data quality, pipeline reliability and user trust are where products succeed or fail. Build the boring parts well, and the impressive parts get to shine.