From 7% to 79%: How loveholidays Made Everyone a Builder with Codex

OpenAI published an enterprise case study on August 26, 2026: how the online travel company loveholidays is making everyone a builder with Codex. The numbers are hard: in one year, AI-assisted code changes grew from 7% to 79% of all changes; AI-assisted deployment frequency increased without growing the engineering team; and Data Platform change success rose from 58%. loveholidays is a leading online travel agent operating across eight European markets. The thesis comes from Dmitri Lerko, Head of Engineering: "Everybody is a builder. Making changes to our applications, infrastructure, and deploying code is no longer an engineering-only activity. Product managers, designers, and commercial stakeholders are driving value and making deployments."

1. The Core Pattern: Search Playground

The clearest example is Search Playground. Previously, someone elsewhere in the business with an idea for a new customer experience would need to persuade an engineering team to prioritise a prototype — every experiment came with an opportunity cost: engineering time spent testing one idea was engineering time unavailable elsewhere. loveholidays wanted to break that dependency. Its engineers created Search Playground using the company's design system, frontend technologies, and Codex. It gives people across the business a way to turn an idea into a working customer experience, gather feedback, and test whether it delivers value. More than ten new search experiences have already been developed through the Playground — most built by non-engineers, and at least three are now running on the loveholidays website.

// The Search Playground pattern: a component registry
// plus Codex turns an idea into a working customer
// experience WITHOUT an engineering queue. loveholidays
// built it from the company design system + frontend tech.
const PLAYGROUND = {
  "components": ["search-bar", "result-card", "hero", "filter-chip", "inspire-grid"],
  "guards": {
    "onlyRegisteredComponents": true,   // no bespoke CSS drift
    "designTokens": "brand-tokens.css", // forced imports
    "analytics": "auto-instrumented"    // every variant measured
  }
};

// A PM describes the idea; the tool scaffolds a page from
// registered components; Codex fills the logic. Ten new
// search experiences were built this way -- most by
// non-engineers, at least three now live on the site.

2. Non-Engineers Are Actually Shipping

One example is Inspire Me, which helps travellers explore different kinds of trips, from beach breaks to foodie escapes. Another came from marketing: for its recent "Crisps from Abroad" activation, the team wanted an interactive microsite to gather entries for a competition and share holiday inspiration. Previously, it would have relied on an external agency to design and develop a standalone digital experience — adding cost and time. Using Codex and Search Playground, the team built the experience itself in hours, while maintaining loveholidays' existing design system. This is not a toy prototype; it is a live marketing experience.

// PR guardrails for non-engineer changes: the pipeline
// that let loveholidays scale 7% -> 79% AI-assisted
// changes without breaking the site. Gates run on every
// AI-assisted PR, not just human ones.
{
  "pr_guardrails": {
    "required_checks": [
      "build-passes",
      "design-token-lint",
      "a11y-snapshot",
      "bundle-size < 5% delta",
      "no-secrets-in-diff"
    ],
    "auto_approve": ["changes <= 200 lines", "only registered components"],
    "human_review": ["touches data-platform", "touches payments", "any delete"],
    "rollback": "instant via feature flag, all new experiences ship behind flags"
  }
}
// "Making changes to our applications, infrastructure, and
// deploying code is no longer an engineering-only
// activity." -- Dmitri Lerko, Head of Engineering

3. Why It Did Not Break: Guardrails

The fear with letting non-engineers write code is quality loss. loveholidays' answer is to lay the rails first: a registered component library (only registered components, no bespoke CSS drift), forced design tokens, auto-instrumented analytics. Pull requests run automated checks — build passes, design-token lint, accessibility snapshot, bundle size under 5% delta, no secrets in the diff. Small changes (up to 200 lines, registered components only) auto-approve; anything touching the data platform, payments, or any delete requires human review; every new experience ships behind a feature flag with instant rollback. These guardrails are how 79% AI-assisted changes did not break the site.

// Change-success measurement: you cannot scale AI-assisted
// changes without knowing whether they succeed. loveholidays
// reported Data Platform change success up from 58% --
// measure the same way: deploy -> observe -> verdict.
async function measureChangeSuccess(change) {
  const deployed = await deploy(change);
  const window = await observe(deployed, { durationMin: 30 });
  return {
    changeId: change.id,
    author: change.author,           // engineer | pm | marketing
    aiAssisted: change.aiAssisted,
    success: window.errorRate < 0.01 && window.latencyP95 < change.baselineP95 * 1.2,
    reverted: window.reverted,
  };
}
// Roll up by author type to prove the culture shift:
// non-engineer changes succeed at the same rate or the
// guardrails are wrong.

4. Engineering's New Job: Build Rails, Not Fix Cars

Lerko's framing is precise: "We wanted to decouple our ability to trial new ideas from actual engineering time." Engineering is no longer drowned in small requests; it focuses on harder problems — building what CTO Mike Jones calls the "general intelligence for travel": combining the company's technology with the expertise of its people, and making both more accessible through AI. The Data Platform story is telling: it was originally designed for technical users, and making changes required knowledge of specialist tools, repositories, source control, and internal processes; when someone got stuck, a specialist engineer had to step in. Now business teams make data and infrastructure changes directly — and change success improved from 58%.

5. Code Walkthrough: Playground, Guardrails, Metrics

The code blocks in this post unpack the pattern. Block one is the Playground config: a component registry plus guards (registered components only, forced design tokens, auto instrumentation). Block two is the PR guardrail JSON: automated checks, auto-approval thresholds, human-review red lines, and feature-flag rollback. Block three measures change success: deploy, observe for 30 minutes, then verdict (error rate under 1% and P95 latency within 1.2x of baseline), rolled up by author type — engineer, PM, marketing. Block four is the experimentation primitive: scaffold from registry, Codex implements the logic, create a feature flag, instrument, ship behind the flag. Block five is the "specialists build rails, everyone rides" ownership split.

// Decoupling ideas from engineering time: before Search
// Playground, every experiment had an opportunity cost --
// engineering time spent testing one idea was unavailable
// elsewhere. The decoupling primitive is a feature flag +
// a scaffolded page + an owner who is not an engineer.
async function tryIdea(idea) {
  const page = await scaffoldFromRegistry(idea);      // components
  const code = await codexImplement(page, idea.logic); // logic
  const flag = await createFlag("exp_" + idea.id);     // safe ship
  await instrument(page, flag);                        // measure
  return { url: await deployBehindFlag(page, flag), flag };
}
// "We wanted to decouple our ability to trial new ideas
// from actual engineering time." -- Dmitri Lerko

6. What Most Companies Can Copy

The loveholidays story is not "let AI write all the code." It is "distribute building capability across the organization while holding quality with engineering guardrails." Three takeaways: first, engineers build the platform first — component library, pipeline, guardrails, data contracts — then open it up. Second, all AI-assisted changes go through the same quality gates; no two-tier system. Third, prove the culture shift with data: track change success by author type, and if non-engineer changes do not succeed at the same rate, your guardrails are wrong. From 7% to 79%, what changed is not the share of code — it is how the organization builds.

// The specialist-on-tap pattern: engineers build the
// rails, everyone else rides them. The marketing team's
// "Crisps from Abroad" microsite used to need an external
// agency; with the playground they built it themselves in
// hours, on the company design system.
const RAILS = {
  "engineers_own": ["design system", "deployment pipeline", "guardrails", "data contracts"],
  "everyone_can": ["scaffold pages", "wire components", "set analytics", "ship behind flags"],
  "never_without_review": ["payments", "PII access", "infra changes"],
};
// Result (OpenAI): AI-assisted code changes 7% -> 79% in
// a year; deployment frequency up with no team growth;
// Data Platform change success 58% -> higher.