On November 30th, 2023, OpenAI rubbed the ChatGPT lamp, and the Generative AI genie was released into the world. Almost three years later, it’s safe to say that virtually every industry has been affected, including education, health, finance, legal, and many more. The genie is most definitely out of the bottle, and he is not going back in. It could be argued that the industry that has seen the greatest impact is Software Engineering. The important shift is not that machines can write code, but that engineering work is moving from writing lines and functions to defining intent, providing context, validating outcomes, and managing delivery. The question is what for the future of software engineering as a skill and for those who ply this trade. 

From copy and paste to engineering workflows 

The first phase was simple: ask ChatGPT for a code fragment, copy it into an editor, and adapt, test, and debug it. This worked for boilerplate, unfamiliar APIs, test scaffolding, and code explanations. It was limited because the underlying model lacked awareness of repository conventions, architecture, operational constraints, and the history behind a design decision. To be blunt, it was not much more than a faster version of Stack Overflow. I used it a lot for my personal projects and already saw its utility in helping work with some annoying APIs. 

The next phase saw a massive step forward with the embedding of this functionality into the IDEs. Usability jumped, with copy and paste no longer being the modus operandi. That said, the basic interaction remained request and response: the developer asked, the model suggested, and the developer integrated. This was the first time that I started to feel a bit less in control, that the GenAI was starting to write more code than me. 

The most important leap forward came with the addition of harnesses around the model. A coding harness gives an AI system-controlled access to repository context, coding standards, tests, build logs, documentation, source control, code search, and MCP servers. It defines what the agent can do and when human approval is required. At this point I was starting to feel like an observer, but the quantity and productivity was exploding. 

The task becomes: understand the request, inspect the codebase, propose a plan, implement it, run the checks, explain the result, and prepare the work for review. The model was now participating in a bounded engineering workflow. The objective at this stage was not necessarily maximum autonomy but reliable delegation. I began to feel like I had a really great senior developer as my coding partner. 

The rise of autonomous review and QA 

The next step forward was where developers were able to start stitching together a fabric of complementary agents to provide a more cohesive workflow, with each agent being able to handle a different task, all orchestrated by the developers.  

• A code-review agent can inspect a change, identify likely defects, request tests, and post findings directly into the review system.  

• A QA agent can generate test cases, run the suite, analyze failures, and distinguish a product regression from a flaky environment.  

• A migration agent can apply a repeatable transformation while an independent reviewer checks the result.  

The strongest workflows distribute responsibility: one agent plans, another implements, another tests, and another challenges the result. Cross-model or adversarial review is useful because the first system is often poor at identifying its own assumptions. 

Criteo is already moving in this direction. Virtually every developer is making significant use of these AI-driven approaches to increase their throughput, alongside more merged changes and shorter median merge times. At the same time, we see that these systems are not foolproof yet, so we pay great attention to rollback rates, defects, and other quality indicators. 

We have built an AI Registry of all the available tools, agents, and skills at our developers’ disposal. These include our CodeReview AI, migration and debt-removal agents, security review agents, and Beehive, our internally built framework which orchestrates Slack-invoked coding agents that can push changes to Gerrit. We also organize monthly show-and-tells, where each team can demonstrate what is working well that others could benefit from. Sharing is caring 😊

AI coding is becoming part of an operating model, not just a set of tools. Criteo is building shared orchestration, increasing engagement with coding agents, exploring self-hosted models, and tracking developer time savings. The objective is speed with quality, accountability, and clarity about how engineering roles evolve.  

The Risks of Gen AI Coding 

So, where’s the catch? One of the biggest issues that has plagued generative AI since its inception is how much trust we can have in what it produces. The concern is not that AI will occasionally be wrong. It is that low-quality work can become cheap, fast, and plausible. 

AI slop is code that looks reasonable, passes a narrow check, and still fails the broader test of engineering quality. GenAI coding may add unnecessary abstractions, duplicate functionality, mishandle edge cases, weaken security, or increase the cost of ownership. 

The answer is not to ban generated code. It is to strengthen the controls around it: 

• Keep changes small and reviewable. 

• Require tests that express intended behavior, not just higher coverage. 

• Run static analysis, security checks, integration tests, and production-like validation where appropriate. 

• Ask agents to explain assumptions, alternatives, and failure modes. 

• Use independent review for high-risk changes. 

• Treat generated code as untrusted until a responsible engineer understands and accepts it. 

• Measure defects, rollbacks, reliability, and customer impact—not lines of code or token consumption. 

AI can accelerate the loop. It cannot take responsibility for what we ship. 

Why fundamentals still matter 

There is a particular risk for junior engineers. If someone learns to produce working-looking code before learning how to reason about systems, they may become dependent on the tool where it is least reliable. Battle-hardened engineers developed their skills through many years in the trenches. Often the biggest learning came from the times when code that looked fine in review didn’t take into account the real-world realities of running at the scale of millions of QPS, at millisecond response times, whilst dealing with petabytes of data. 

Computer science fundamentals are necessary, but not sufficient. Engineers also need to decompose ambiguous problems, trace failures across services, understand performance trade-offs, design for operability, recognize security boundaries, communicate uncertainty, and decide what not to build. These skills are learned through incidents, code reviews, collaboration, and experience—not only in CS 101. 

A junior engineer who never wrestles with a confusing failure may not learn how to form hypotheses. A polished patch can create the illusion of understanding. 

The answer is deliberate apprenticeship. Junior engineers should use AI, but also explain the code, write plans before implementation, debug without immediate assistance at times, review generated changes line by line, and own small features through design, delivery, and operation. Automation should expand capability, not replace judgment. Mentoring has never been more important. Expect to see more articles from us soon on this very important topic. Stay tuned!!! 

A pragmatic optimism 

Engineering has always advanced by raising the level of abstraction. Higher-level languages, continuous delivery, cloud platforms, and observability tools changed what one engineer could accomplish. 

GenAI is another step in that progression. It can help engineers explore options, remove toil, test more thoroughly, understand unfamiliar systems faster, and turn ideas into reliable software with less friction. 

The winning model is skilled engineers using agents inside well-designed workflows, with strong review and enough technical depth to know when the machine is wrong. That combination can move us from repetitive mechanics toward more valuable creative work.