The real value of a coding professional

01Why pay someone to write code, if a machine can write it too?

It is the question anyone commissioning a website, a portal or a management system asks today, and it is a legitimate question. Artificial intelligence tools write pages of tidy, commented code in a few seconds. Page builders promise a professional site by dragging blocks with the mouse. Marketplaces offer ready-made themes for a few tens of euros. All true.

And yet slow sites, hacked portals and management systems nobody can change anymore have not decreased: they have increased. The reason is simple to state and less simple to accept. Writing code has never been the hard part of the job. The hard part is deciding which code is needed, understanding what is already there, foreseeing what will happen when there are a thousand users instead of ten, and answering for what goes online.

In this chapter I take the comparison apart piece by piece: what artificial intelligence really does well, where it goes wrong without warning, why a site assembled with page builders and plugins costs more than it seems, and how to recognize work done properly. Not to defend a profession, but to give you the tools to choose.

02Artificial intelligence: a formidable assistant

Let me start with what needs to be said honestly: AI-based programming assistants are extraordinary tools, and people who write software for a living use them today. They save hours on repetitive work, propose solutions you had not thought of, explain in simple words a piece of code someone else wrote ten years ago.

Here is where they give the most:

• the grunt work: repetitive structures, format conversions, lists of fields, basic tests;
• the first draft: a starting point from which someone who can program removes, corrects and completes;
• explanations: “what does this function do?”, “why this error?”, questions it often answers well;
• research: finding the name of a concept, a library function, an alternative;
• review: a second pair of eyes that flags something to double-check.

In all these cases there is a common element: someone who can judge the result. The assistant proposes; whoever knows the craft chooses, discards, verifies. Take that person away and the tool stays the same, but the result changes in nature.

03Where AI goes wrong without saying so

A language model generates the most probable text given what you asked it. It does not know whether the code it writes is secure: it knows that it resembles code it has seen. This is why its most dangerous mistake is not code that does not work, which you notice right away, but code that works and also does something else.

OWASP, the international foundation that has been publishing the reference standards for web application security for twenty years, lists among the risks of language models precisely the generation of insecure code and overreliance: trusting generated content without verifying it. Here is how they show up in practice.

Try picturing it like this: a willing nephew prepares your booking form in an afternoon, with the help of artificial intelligence. It opens, it sends, the emails arrive. All perfect, for months. Then one day someone types into the “surname” field something that is not a surname, and your customer list ends up where it should not. The form worked: it also did something else.

1. The query that opens the database to anyone

You ask for “a page that searches customers by surname” and you get something that works. But if the surname typed by the user is pasted directly into the question to the database, anyone can type a piece of command in place of the surname and get the whole table back, or delete it. This is SQL injection, one of the oldest attacks and still among the most widespread.

The first defense recommended by OWASP is precisely parameterized queries (prepared statements). An assistant often uses them, but not always; and someone who cannot tell the difference does not notice until somebody takes advantage of it.

2. Secret keys written into the code

To connect to a payment service, to email or to the database you need passwords and keys. Generated code tends to write them directly into the file, because that way the example works immediately. But a file ends up in an archive, in a backup copy, in a shared repository: and the key with it. OWASP’s guidelines on secrets management say the opposite: keys stay outside the code, in protected configuration files or dedicated services, and can be changed without touching the program.

3. Libraries that do not exist

This happens too: the assistant suggests installing a package with a plausible name that has never existed. OWASP describes the scenario in which someone watches which invented names are suggested most often, publishes malicious packages under those names and waits for them to be installed. Whoever does not check where each library comes from brings into the house, with a single command, code written by strangers.

4. The happy path and all the others

Generated code covers the expected path well: the user fills in everything, the network works, the payment goes through. Real software lives in the other cases: the double click on the “Pay” button, the connection that drops halfway, two people booking the same table in the same second, the field left empty, the name with an apostrophe. Handling exceptions is half the work, and the assistant does not do it unless you ask, and you do not know to ask unless you know.

5. The context nobody gave it

The assistant does not know your database, the traffic you will have, the rules of your sector, the privacy regulations, the management system the site has to talk to. It produces a generic solution for a problem that is not generic. Someone who knows the project knows what to ask, what to discard and what is missing.

04Page builders and plugins: the site that weighs more than it shows

A page builder is a program that lets you build pages by dragging blocks: headings, columns, galleries, buttons. It is convenient and gives immediate results. The price is paid later, and it is paid by the people who visit the site.

The hidden weight of every block

To let you drag anything anywhere, the page builder has to anticipate everything. Every element is wrapped in several containers, each with its own classes and styles. The result is a page with a huge number of HTML elements (the so-called DOM) and large style sheets and scripts loaded in full even when the page uses only a small part of them.

Lighthouse, Google’s analysis tool built into Chrome, shows a warning when the body of the page exceeds about 800 elements and an error beyond about 1,400. More elements mean more memory, more style and layout calculations, slower responses to taps: everything the browser has to do before showing you the page and while you use it.

Code that gets loaded and never used

Besides the elements, there is the weight of the files. A page builder loads its style sheets and scripts for all the blocks it offers, even those the page does not use: the slider that is not there, the carousel, the animation. Chrome itself, in its audits, points to unused CSS and JavaScript as one of the first things to remove to speed up a page. More files, and bigger ones, mean a longer wait before the page is readable, especially on a phone with an ordinary connection. How these waits are measured I explain in the chapter on Core Web Vitals.

A plugin for everything

The second problem comes with plugins: one module for the contact form, one for caching, one for security, one for SEO, one for cookies, one for the gallery, one for translations. Twenty, thirty, sometimes more. Each one is:

• code written by others, running on your server with the same permissions as the site;
• one more thing to update, often with an annual subscription for the commercial versions;
• a possible incompatibility with the others, which shows up the day one gets updated and the other does not;
• one more door: every vulnerability discovered in a popular plugin affects all the sites that use it, until they are updated.

The numbers confirm it. According to the annual report by Patchstack, a company specializing in WordPress security, 11,334 new vulnerabilities were discovered in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and just 6 in the core, all of low severity. The heart of the system, looked after by a very large community, is solid; the risk lies in what gets added to it. Every plugin installed “because it is convenient” is a bet on the diligence of whoever maintains it.

05WordPress done right: the core is never touched

WordPress is not the problem. It is a solid system, used by a huge part of the web, with a community that updates it regularly. The problem is how it is used. And here there is one rule that separates the professional from the amateur more than any other.

The WordPress core, that is, the system files, is never modified. The official documentation says so explicitly: changing the core files is not recommended, apart from the configuration file. The reason is practical: with every update the system files are replaced, and any change made there disappears, or, worse, prevents updating and leaves the site exposed to the flaws the update would have closed.

So where does a professional work?

WordPress is designed to be extended without being touched, in layers:

• The child theme inherits everything from the main theme and contains only the differences. The WordPress documentation says it clearly: it lets you update the parent theme without losing your changes.
• Custom plugins contain the features specific to the business, written for that project, without the thousand options of a commercial product designed for everyone.
• Hooks (actions and filters) are the attachment points provided by the system: they let you change a behavior without rewriting the file that contains it.

This way the site updates with one click, stays secure, and the customizations remain. Whoever suggests “fixing it directly in the core” is offering you, without saying so, a site that can never be updated again.

When WordPress is the right choice, and when it is not

WordPress is perfectly fine when you need to publish content often, with several people writing, and the features are those typical of an editorial site. It becomes a stretch when it is used as the base for a management system, a complex booking system or a portal with its own logic: there you end up fighting the tool, adding plugin upon plugin. In those cases an application written to measure costs less over time.

06What clean code really buys you

“Clean code” sounds like insider jargon. In reality it stands for three very concrete advantages for whoever owns the site or the software: security, the ability to grow and visibility on Google.

Security: less code, fewer flaws

Every line of code is a place where a mistake can hide. An essential project, containing only what is needed, has fewer weak points than one bloated with generic components. Tidy code is also code that can be checked: if nobody can read it, nobody can say whether it is secure.

Growth: adding without rewriting

A business changes: a new service, a second location, one more language, a connection to the management system or to the accountant. With well-designed software, adding one thing does not force you to rewrite another: there is a planned point where it attaches. With software that grew in layers of patches, every change breaks something else, and at some point it is better to start from scratch. That is where the initial saving turns into the highest cost.

Technical SEO: being read properly by Google

Google reads the page’s code before it reads your texts. Clean code helps it understand:

• the structure: a single main heading, section headings in order, real lists instead of lines formatted by hand;
• the meaning: structured data saying “this is an article”, “these are frequently asked questions”, “this is the business’s address”;
• the speed: light pages that respond quickly, on the server and in the browser (I talk about it in the chapter on infrastructure and in the one on speed);
• the languages: translated pages declared the right way, so that people searching in another language find the right page. I talk about it in the chapter on the multilingual website.

07The real cost: the bill over three years

The comparison between a professional and do-it-yourself is almost always made on the initial price. It is the wrong comparison. The cost of a site or a piece of software is measured over the years you use it, adding up things you do not see at the start.

08How to recognize a coding professional

You do not need to know how to program to understand whether the person in front of you works well. A few questions and attention to the answers are enough: a professional answers concretely, admits the limits of the tools and talks about your problem before their favorite technology.

1. “What happens when I need to add a feature?” A good answer points to where it will attach, without rewriting the rest.
2. “How do you protect my customers’ data?” You should hear precise words: encrypted connection, parameterized queries, passwords never stored in plain text, backups off the server.
3. “How many third-party components will you use, and who updates them?” Few is better, chosen and with someone responsible for them.
4. “Who owns the code and the domain?” You do, in black and white.
5. “Do you use artificial intelligence?” There is nothing wrong if the answer is yes: what matters is that they tell you who checks what it produces.
6. “Can you show me a project and how it is built inside?” Those who work well are not afraid to show their code.

The value of custom-written code shows above all when the site has to do more than display pages: when it has to take bookings, let customers into their own area, sync with a management system, work on the phone like an app. That is where custom code makes it possible to integrate a booking portal and a PWA securely, without relying on a stack of plugins competing for the same data. It is the subject of the next chapter: integrated portals, direct bookings and PWAs.

Frequently asked questions

Sources

1. OWASP GenAI Security Project, “LLM09:2025 Misinformation”: generation of insecure code, non-existent libraries suggested by models, overreliance.
2. OWASP, “SQL Injection Prevention Cheat Sheet”: parameterized queries as the first defense.
3. OWASP, “Secrets Management Cheat Sheet”: why keys and passwords do not belong in the code.
4. Chrome for Developers, “Avoid an excessive DOM size”: the thresholds of about 800 and 1,400 elements used by Lighthouse.
5. Chrome for Developers, “Remove unused CSS”: the cost of style sheets that are loaded and not used.
6. Patchstack, “State of WordPress Security in 2026”: the vulnerabilities discovered in 2025, broken down into plugins, themes and core.
7. WordPress Developer Resources, “Child Themes”: updating the parent theme without losing your changes.
8. WordPress Developer Resources, “Editing Files”: modifying core files other than wp-config.php is not recommended.

Chapter updated October 2026. The code and structure examples in the plates are simplified to show the principle; the thresholds and recommendations cited come from the official documentation listed.