Job architecture in the ai era: loveholidays’ head of engineering says releasing code is no longer an engineering job.

Dmitri Lerko is head of engineering at loveholidays. For the past year he has watched people who are not engineers release code to a website that sells holidays to millions. Product managers. Designers. People from the commercial team.

“Everybody is a builder,” Lerko says. “Making changes to our applications, infrastructure, and deploying code is no longer an engineering-only activity.”

Any HR leader who has graded a role that changed again before the paperwork cleared knows the shape of this. It is arriving now for job architecture.

OpenAI published the case study and OpenAI makes Codex, the tool at the centre of it. Read the framing with that in mind. The numbers hold up.

• AI made 79% of code changes last year. The year before, it made 7%.
• Releases rose 73%. The engineering team did not grow.
• Changes to the data platform now succeed 93% of the time, up from 58%.

Employees have made more than ten new search experiences in an internal tool called Search Playground. Most of them are not engineers. Three of those experiences are live.

One shared interface changes who does what

The engineers spent the year writing down what they know. They turned it into workflows other people can run.

“We codify all the best practices,” Lerko says. “We codify validations, and continuously improve them as reality changes.”

So specialist knowledge stops being a person you wait for. It becomes a tool other people use. A product manager used to write a ticket and wait three sprints. She now opens the tool and releases the change on Thursday.

Mike Jones, the CTO, describes the effect on individual jobs: “The more work you can hand off to AI, the more your job elevates. Your job isn’t to be handed a solution and implement it anymore.”

That is a claim about seniority. A CTO made it. HR owns the job architecture it describes.

Job architecture assumes limits that no longer hold

Job architecture rests on one assumption. The limits between job families hold still long enough for a grading structure to track them. Grades measure decision scope, technical depth and span of control. Each measure assumes you can tell a designer from an engineer by what they can do.

Split any role into three parts:

• Permission to make the thing.
• Permission to put it in front of customers.
• Responsibility for repairing it at three in the morning.

Grades and pay track the first two. The accountability sits in the third. Companies have always given all three to the same person. AI tools separate them.

A commercial analyst at loveholidays can make a change and release it. She takes on no on-call duty at all. Most AI upskilling work has not touched the ownership half of this.

A designer can now release code to customers. Your grading structure describes a company that no longer exists.

Throughput arrives before stability does

The 2025 DORA report (https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) surveyed almost 5,000 technology professionals. It found AI adoption raises software delivery throughput. It also found AI adoption lowers software delivery stability. Same tools, both effects.

Nathen Harvey leads DORA. He puts it plainly: “AI doesn’t fix a team; it amplifies what’s already there.”

GitClear examined 623 million code changes (https://www.gitclear.com/ai-assistant-code-quality) between 2023 and 2026. GitClear sells code analytics, so it has a commercial interest in the finding. Duplicated code blocks rose 81%. Refactoring work fell 70%. Volume goes up. The tidying that keeps volume survivable does not.

So the sceptical read is a serious one. Ten search experiences in a quarter is a good quarter. Ten search experiences nobody can maintain in eighteen months is a liability. Neither version shows up in a job architecture review.

loveholidays has an answer, and it is the codification work. The guardrails came first. Access came second. Most companies copying this will skip that order, because writing down what your best engineer knows takes months and shows nothing for a quarter.

Someone still repairs it at three in the morning

So who owns the code when the person who released it does not report to engineering?

At loveholidays the platform owns it. The validations catch what a non-specialist misses, and engineering owns the validations. That works.

There is a second question sitting underneath it. Someone has to tell a product manager that the search experience she released last week is costing conversions. In an engineering team that conversation has a home. It happens in a review, between people who share a manager and a definition of good. Move the release to someone in a commercial team and that route has to be built from scratch. It is the same problem AI rollouts hit when there is no correction window (https://emexmag.com/every-ai-rollout-needs-an-employee-correction-window/).

It also means the real job change happened to the engineers. They moved from making products to making the conditions in which other people make products. Different job. Different skills. Most job architecture has no grade for it.

You will have seen an earlier version of this with spreadsheets. An analyst built something over a weekend. The business came to depend on it. She moved teams, and everyone spent a year unpicking it. The tools are better now, and far more people have them, which is the same distance unsanctioned AI use (https://emexmag.com/shadow-ai-42-of-employees-are-using-ai-in-secret/) already opened.

Three things to check at your next job architecture review:

• Whether release permission and repair responsibility are still written as one thing.
• Whether specialists doing codification work are graded for building capability or for shipping features.
• Whether people acquire abilities faster than they acquire accountability, which internal mobility frameworks (https://emexmag.com/the-internal-mobility-success-playbook-how-leading-companies-keep-and-grow-their-best-talent/) already struggle with.

Lerko’s engineers did not lose the year to the designers. They spent it writing down what they know, so a designer could use it on a Thursday without asking anyone. Specialists who get that time keep shaping how their expertise is used. Specialists still answering the same question fourteen times a week do not.

Worth knowing which of yours is which.