Will AI replace developers? What is true and what is false

On LinkedIn, the same debate comes back every week. On one side: “No AI will ever beat a developer who understands the business, who turns down a useless feature and who owns their choices in production. Code can be generated, the decision to write it cannot.” On the other, a mocking comment: nobody reads assembly any more, we trust the compiler; and a director does not review their teams’ code, they judge what goes in and what comes out. So, people or AI, what is the difference?

Both are right on one point. And both miss the same one.

What is true

The decision stays human. An AI produces five hundred lines in thirty seconds. It does not ask whether those lines should exist, whether the feature really serves the business, or what it will cost to maintain. That judgement is what you pay for, not the typing.

Managing by outcomes already existed. The technical director of a large team does not read every line. They judge deliveries, incidents and deadlines. From that angle, whether a team is made of developers or AI agents changes less than people say: you manage the input, the output and the errors.

The competitive field decides. Whoever cuts their budget because “AI codes now” stands still while their competitor keeps theirs and goes much further.

What is false, or half true

“Like assembly, we will end up trusting it.” The comparison is appealing, but it does not hold. A compiler is deterministic: the same input always gives the same output, and decades of testing have made it reliable. An AI gives two different pieces of code for the same request, and sometimes wrong code that looks right. Trust will not come from habit, it will come from automated tests, checks and targeted reviews.

“The team is already a black box.” True for management, false for accountability. Behind a human team, someone answers for an outage and knows why a choice was made. Behind an agent, accountability goes back to whoever plugged it in, and the explanation for the choice often exists nowhere.

“Just plug everything in, the AI codes for you.” Measurements say otherwise. In July 2025, a controlled study by the METR lab followed experienced developers on their own projects: with AI, they took about 19% longer, while believing they had gained 20%. Tools have improved since, and the study covered only sixteen people, but it is a reminder: feeling fast is not being fast.

Our position: review where it matters

Should every line produced by an AI be reviewed? No. That would throw away most of the gain. Should none be? No either. The right answer depends on the attack surface.

A static or headless brochure site is not genetics. It has no exposed database and no application server to break into. We ship lightly reviewed code there, generated then tested, and it generally goes well: we do it every day.

A human eye remains mandatory wherever a mistake is expensive:

• authentication and permissions: who can log in, who sees what;
• connections to other tools: APIs, webhooks, access tokens;
• secrets: a key slipped into code sent to the browser is public;
• forms: field validation, anti-spam, personal data and GDPR;
• payment: amounts, refunds, the provider’s webhooks;
• dependencies: a library added by the AI, sometimes unknown or abandoned, is third-party code entering your product.

The detail of the checks is in our article on application security, and why a static site exposes so little is in the one on the October 2026 PHP vulnerability.

Cheaper, or further?

This is no longer 2025: human work on a web project really has decreased. That gain has to be put to use, and the answer depends on the company’s situation.

1. Go further with the same budget: more features, more tests, more markets. That is the path for whoever competes on a crowded field.
2. Start faster and for less: a first product online in a few weeks, to test an idea before investing more.

We offer both paths to our clients. What we do not offer is the third one, heard far too often: cut the budget and count on AI to do the same work with nobody steering it. Our article on vibe coding tells how those projects end.

Our view

The old-school coders are wrong to believe that reviewing every line protects their trade. The enthusiasts are wrong to believe you can plug everything in and stop looking. The job is shifting: less writing, more decisions, architecture and verification. And what justifies a good developer’s rate is not the number of lines they type. It is their ability to say “these should not exist” and to know which ones to review. Our article on the human role alongside AI goes further on that judgement.

Sources

1. A controlled study by the METR lab (new tab)metr.org